Automatic BRS - External transaction Keys

Dear Gurus,
Please provide the standard external transaction keys used for MT490
are these external transaction types are common across all the banks or are they different.. ?
Regards,
Abhijeet

Hi Abhijeeth,
From your previous post it seems you are trying to configure Electronic Banking Statement Configuration and if i'm not wrong,looks like you are bit confused about the basic account determination objects used. Below is the high level understanding of these, let me know if you have any further questions.
As you might know about the functionality of EBS, lets not get into. Basic terminology used in this customizing 1. Internal Trans type 2. External Tran Type 3. Posting Rules 4. Posting Key 5. Account Symbols. Its important how this is interlinked and data flow from bank statement to GL.
1. Internal Trans Type: Typically bank provides data in various formats, few of these formats are BAI, MT940, SWIFT and MultiCash. Each formats differs by how data is provided by housebank. Most commonly in US we use BAI(2) format. You match these with ECC by configuring Internal Trans Type to correspond to bank these formats(BAI, MT940...). SAP ERP provides defaults with all these and as per your clients requirement, you can create additional ,if required. You can assign only one Internal Trans Type to one bank account. (For ex: BAI2 format to Chase)
2. External Trans Type: For each Internal Trans Type(Ex: BAI) you maintain multiple number of External Trans Types. Using these Ex Tran Type, we Identify different bank transactions in the EBS provided by bank(in this case, format is BAI). Few of the examples of are Incoming Payment by check, Incoming payment by wire, bank charges, etc: Typically, bank has few hundreds of these trans type's identify each of the individual trans type. As said in the above post, these Ex Trans types are provided by bank to you, depending up on your requirement(I believe, we don't need all of these). Here you might notice one thing, Interpretation Algorithm, Mainly this help in interpreting the reference document number in the trans data(Check number, Account doc. number). One thing to keep in mind, when we assign Internal trans type to you bank account, all these external types implicitly assigned. Hope you got the logic.
3. Posting Rule: This is basically a connector between Ex Trans type we discussed about to the GL account determination. We define the posting rule with Debit & Credit GL accounts(actually we use account symbols, in turn we assign this to GL a/c). Importan thing here is, knowing about determining posting area and Account Symbol(Instead of assigning GL accounts directly we assing account symbols to debit/credit posting keys.
4. Account Symbol: We create generic account(For ex: ++++++001) For ex: If you have multiple bank accounts in US, for all these bank accounts configuring individual step of configuring GL account takes time and efforts to make this process easy, we make use of this technique. Make sure, your COA is designed in such a way to match this.
As a recap of above,
1. We first assign Internal Trans Type to a bank account( For Ex: Chase - BAI2)
2. The above Internal Trans Type is assigned to multiple External Trans Type (BAI2 --> 101-Incoming Payment by check, 102, Incoming payment by wire transfer.....)
3. Transaction in the incoming data contains an External Tran Type (For Ex: 101 & 102)
4. As you might know from above, We connect the External Trans type to GL account using Posting rule. For that reason, we assign posting rule to Ex Trans type.
5. Posting rule is Assigned to Account Symbol which in-turn assigned to GL account.
6. Finally data flows to your respective bank GL account.
MBS & Check Depost: As you might observed or know, MBS and Check deposit, follows the same technique differs at few places.
Tran-Codes: Configuration: IMG, Import Bank Statement to ECC: FF_5
Helpful links:
http://srilogix.com/casesWhitepapers/Electronic%20Bank%20Statement.pdf
http://en.sap.darkduck.com/en-SAP-FI-FAQ/setting-up-the-electronic-bank-statment
http://sap-f2.blogspot.com/2009/08/functionality-of-electronic-bank.html
http://www.sap-topjobs.com/bankreco.pdf
most important, Previous threads in the forum.
Gurus, Do correct me if i missed at any point.
Hope this helps. Enjoy your day!.
Thanks
Srinath Challa

Similar Messages

Business transaction key in account determination..?

Hi all
Can anybody explain me in simple form form, what is business transaction key in account determination , for eg, GBB,BSA,BSX,PRD,VBR,.WRX....etc (Approximately 60 transaction keys in std SAP)
If i want to do configuration the for new client, what are all the business transaction key,,, How the configuration wil happen..?
Pls giv me expaination,
Reply will be rewardable..
Thanks
sap-mm

Hi MM,
Please Search in SDN threads solution is given already in lot of threads.
Go to SAP Library
SPRO> Help> SAP Library
Or go to SPRO> IMG> MM>Valuation and Account Assignment>Account determination> Account det without wizard> configure Automatic postings
Click on IMG ACTIVITY DOCUMENTATION
These transactions are important for Accounts.
Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting.
Example:
Posting lines are created in the following accounts in the case of a goods issue for a cost center:
Stock account
Consumption account
Agency business: income (AG1)
This transaction can be used in agency business for income deriving from commission (e.g. del credere commission). The account key is used in the calculation schemas for agency business to determine the associated revenue accounts.
Agency business: turnover (AG2)
This transaction can be used in agency business if turnover (business volume) postings are activated in Customizing for the payment types. The account key is specified in Customizing for the billing type.
Agency business: expense (AG3)
This transaction can be used in agency business for commission expenses. The account key is used in the calculation schemas for agency business to determine the associated expense accounts.
Expense/revenue from consumption of consignment material (AKO)
This transaction is used in Inventory Management in the case of withdrawals from consignment stock or when consignment stock is transferred to own stock if the material is subject to standard price control and the consignment price differs from the standard price.
Expenditure/income from transfer posting (AUM)
This transaction is used for transfer postings from one material to another if the complete value of the issuing material cannot be posted to the value of the receiving material. This applies both to materials with standard price control and to materials with moving average price control. Price differences can arise for materials with moving average price if stock levels are negative and the stock value becomes unrealistic as a result of the posting. Transaction AUM can be used irrespective of whether the transfer posting involves a transfer between plants. The expenditure/income is added to the receiving material.
Provisions for subsequent (end-of-period rebate) settlement (BO1)
If you use the "subsequent settlement" function with regard to conditions (e.g. for period-end volume-based rebates), provisions for accrued income are set up when goods receipts are recorded against purchase orders if this is defined for the condition type.
Income from subsequent settlement (BO2)
The rebate income generated in the course of "subsequent settlement" (end-of-period rebate settlement) is posted via this transaction.
Income from subsequent settlement after actual settlement (BO3)
If a goods receipt occurs after settlement accounting has been effected for a rebate arrangement, no further provisions for accrued rebate income can be managed by the "subsequent settlement" facility. No postings should be made to the account normally used for such provisions. As an alternative, you can use this transaction to post provisions for accrued rebate income to a separate account in cases such as the one described.
Supplementary entry for stock (BSD)
This account is posted when closing entries are made for a cumulation run. This account is a supplementary account to the stock account; that is, the stock account is added to it to determine the stock value that was calculated via the cumulation. In the process, the various valuation areas (for example, commercial, tax), that are used in the balance sheet are taxed separately.
Change in stock (BSV)
Changes in stocks are posted in Inventory Management at the time goods receipts are recorded or subsequent adjustments made with regard to subcontract orders.
If the account assigned here is defined as a cost element, you must specify a preliminary account assignment for the account in the table of automatic account assignment specification (Customizing for Controlling) in order to be able to post goods receipts against subcontract orders. In the standard system, cost center SC-1 is defined for this purpose.
Stock posting (BSX)
This transaction is used for all postings to stock accounts. Such postings are effected, for example:
In inventory management in the case of goods receipts to own stock and goods issues from own stock
In invoice verification, if price differences occur in connection with incoming invoices for materials valuated at moving average price and there is adequate stock coverage
In order settlement, if the order is assigned to a material with moving average price and the actual costs at the time of settlement vary from the actual costs at the time of goods receipt
Because this transaction is dependent on the valuation class, it is possible to manage materials with different valuation classes in separate stock accounts.
Revaluation of other consumption (COC)
This transaction/event key is required for the revaluation of consumption in Actual Costing/Material Ledger.
Revaluation of consumption valuates single-level consumption using the actual prices determined in the Actual Costing/Material Ledger application. This revaluation can either take place in the account where the original postings were made, or in a header account.
The header account is determined using the transaction/event key COC.
Del credere (DEL)
Transaction/event key for the payment/invoice list documents in Purchasing. The account key is needed in the calculation schema for payment/settlement processing to determine the associated revenue accounts.
Small differences, Materials Management (DIF)
This transaction is used in Invoice Verification if you define a tolerance for minor differences and the balance of an invoice does not exceed the tolerance.
Purchase account(EIN), purchase offsetting account (EKG), freight purchase account (FRE)
These transactions are used only if Purchase Account Management is active in the company code.
Note
Due to special legal requirements, this function was developed specially for certain countries (Belgium, Spain, Portugal, France, Italy, and Finland).
Before you use this function, check whether you need to use it in your country.
Freight clearing (FR1), provision for freight charges (FR2), customs duty clearing (FR3), provision for customs duty (FR4)
These transactions are used to post delivery costs (incidental procurement costs) in the case of goods receipts against purchase orders and incoming invoices. Which transaction is used for which delivery costs depends on the condition types defined in the purchase order.
You can also enter your own transactions for delivery costs in condition types.
External service (FRL)
The transaction is used for goods and invoice receipts in connection with subcontract orders.
If the account assigned here is defined as a cost element, you must specify a preliminary account assignment for the account in the table of automatic account assignment specification (Customizing for Controlling) in order to be able to post goods receipts against subcontract orders. In the standard system, cost center SC-1 is defined for this purpose.
External service, delivery costs (FRN)
This transaction is used for delivery costs (incidental costs of procurement) in connection with subcontract orders.
If the account assigned here is defined as a cost element, you must specify a preliminary account assignment for the account in the table of automatic account assignment specification (Customizing for Controlling) in order to be able to post goods receipts against subcontract orders. In the standard system, cost center SC-1 is defined for this purpose.
Offsetting entry for stock posting (GBB)
Offsetting entries for stock postings are used in Inventory Management. They are dependent on the account grouping to which each movement type is assigned. The following account groupings are defined in the standard system:
Purchase order with account assignment (KBS)
You cannot assign this transaction/event key to an account. It means that the account assignment is adopted from the purchase order and is used for the purpose of determining the posting keys for the goods receipt.
Exchange Rate Differences Materials Management(AVR) (KDG)
When you carry out a revaluation of single-level consumption in the material ledger for an alternative valuation run, the exchange rate difference accounts of the materials are credited with the exchange rate differences that are to be assigned to the consumption.
Exchange rate differences in the case of open items (KDM)
Exchange rate differences in the case of open items arise when an invoice relating to a purchase order is posted with a different exchange rate to that of the goods receipt and the material cannot be debited or credited due to standard price control or stock undercoverage/shortage.
Differences due to exchange rate rounding, Materials Management (KDR)
An exchange rate rounding difference can arise in the case of an invoice made out in a foreign currency. If a difference arises when the posting lines are translated into local currency (as a result of rounding), the system automatically generates a posting line for this rounding difference.
Exchange Rate Differences from Lower Levels (KDV)
In multi-level periodic settlement in the material ledger, some of the exchange rate differences that have been posted during the period in respect of the raw materials, semifinished products and cost centers performing the activity used in the manufacture of a semifinished or finished product are debited or credited to that semifinished or finished product.
Consignment liabilities (KON)
Consignment liabilities arise in the case of withdrawals from consignment stock or from a pipeline or when consignment stock is transferred to own stock.
Depending on the settings for the posting rules for the transaction/event key KON, it is possible to work with or without account modification. If you work with account modification, the following modifications are available in the standard system:
None for consignment liabilities
PIP for pipeline liabilities
Offsetting entry for price differences in cost object hierarchies (KTR)
The contra entry for price difference postings (transaction PRK) arising through settlement via material account determination is carried out with transaction KTR.
Accruals and deferrals account (material ledger) (LKW)
If the process of material price determination in the material ledger is not accompanied by revaluation of closing stock, the price and exchange rate differences that should actually be applied to the stock value are contra-posted to accounts with the transaction/event key LKW.
If, on the other hand, price determination in the material ledger is accompanied by revaluation of the closing stock, the price and exchange rate differences are posted to the stock account (i.e. the stock is revalued).
Price Difference from Exploded WIP (Lar.) (PRA)
If you use the WIP revaluation of the material ledger, the price variances of the exploded WIP stock of an activity type or a business process are posted to the price differences account with transaction/event key PRA.
Differences (AVR Price) (PRC)
In the alternative valuation run in the material ledger, some of the variances that accrue interest in the cost centers, are transfer posted to the semifinished or finished product.
Price differences (PRD)
Price differences arise for materials valuated at standard price in the case of all movements and invoices with a value that differs from the standard price. Examples: goods receipts against purchase orders (if the PO price differs from the standard pricedardpreis), goods issues in respect of which an external amount is entered, invoices (if the invoice price differs from the PO price and the standard price).
Price differences can also arise in the case of materials with moving average price if there is not enough stock to cover the invoiced quantity. In the case of goods movements in the negative range, the moving average price is not changed. Instead, any price differences arising are posted to a price difference account.
Depending on the settings for the posting rules for transaction/event key PRD, it is possible to work with or without account modification. If you use account modification, the following modifications are available in the standard system:
None for goods and invoice receipts against purchase orders
PRF for goods receipts against production orders and
order settlement
PRA for goods issues and other movements
PRU for transfer postings (price differences in the case
of external amounts)
Price Differences (Material Ledger, AVR) (PRG)
When you carry out a revaluation of single-level consumption in the material ledger during the alternative valuation run, the price difference accounts of the materials are credited with the price differences that are to be assigned to the consumption.
Price differences in cost object hierarchies (PRK)
In cost object hierarchies, price differences occur both for the assigned materials with standard price and for the accounts of the cost object hierarchy. In the course of settlement for cost object hierarchies after settlement via material account determination, the price differences are posted via the transaction PRK.
Price Difference from Exploded WIP (Mat.) (PRM)
If you use the WIP revaluation of the material ledger, the price and exchange rate differences of the exploded WIP stock of a material are posted to the price difference account with transaction/event key PRM.
Price differences, product cost collector (PRP)
During settlement accounting with regard to a product cost collector in repetitive manufacturing, price differences are posted with the transaction PRP in the case of the valuated sales order stock.
This transaction is currently used in the following instances only:
Production cost collector in Release 4.0
Product cost collector in IS Automotive Release 2.0 (product cost collector in connection with APO)
Offsetting entry: price differences, product cost collector (PRQ)
The offsetting (contra) entry to price difference postings (transaction PRP) in the course of settlement accounting with respect to a product cost collector in repetitive manufacturing in the case of the valuated sales order stock is carried out via transaction PRQ.
This transaction is currently used in the following instances only:
Production cost collector in Release 4.0
Product cost collector in IS Automotive Release 2.0 (product cost collector in connection with APO)
Price Differences from Lower Levels (PRV)
In multi-level periodic settlement in the material ledger, some of the price differences posted during the period in respect of the raw materials, semifinished products, and cost centers performing the activity used in a semifinished or finished product, are transfer posted to that semifinished or finished product.
Price differences for material ledger (PRY)
In the course of settlement in the material ledger, price differences from the material ledger are posted with the transaction PRY.
Expense and revenue from revaluation (retroactive pricing, RAP)
This transaction/event key is used in Invoice Verification within the framework of the revaluation of goods and services supplied for which settlement has already taken place. Any difference amounts determined are posted to the accounts assigned to the transaction/event key RAP (retroactive pricing) as expense or revenue.
At the time of the revaluation, the amounts determined or portions thereof) are posted neither to material stock accounts nor to price difference accounts. The full amount is always posted to the "Expense from Revaluation" or "Revenue from Revaluation" account. The offsetting (contra) entry is made to the relevant vendor account.
Invoice reductions in Logistics Invoice Verification (RKA)
This transaction/event key is used in Logistics Invoice Verification for the interim posting of price differences in the case of invoice reductions.
If a vendor invoice is reduced, two accounting documents are automatically created for the invoice document. With the first accounting document, the amount invoiced is posted in the vendor line. An additional line is generated on the invoice reduction account to partially offset this amount. With the second accounting document, the invoice reduction is posted in the form of a credit memo from the vendor. The offsetting entry to the vendor line is the invoice reduction account. Hence the invoice reduction account is always balanced off by two accounting documents within one transaction.
Provision for delivery costs (RUE)
Provisions are created for accrued delivery costs if a condition type for provisions is entered in the purchase order. They must be cleared manually at the time of invoice verification.
Taxes in case of transfer posting GI/GR (TXO)
This transaction/event key is only relevant to Brazil (nota fiscal).
Revenue/expense from revaluation (UMB)
This transaction/event key is used both in Inventory Management and in Invoice Verification if the standard price of a material has been changed and a movement or an invoice is posted to the previous period (at the previous price).
Expenditure/income from revaluation (UMD)
This account is the offsetting account for the BSD account. It is posted during the closing entries for the cumulation run of the material ledger and has to be defined for the same valuation areas.
Unplanned delivery costs (UPF)
Unplanned delivery costs are delivery costs (incidental procurement costs) that were not planned in a purchase order (e.g. freight, customs duty). In the SAP posting transaction in Logistics Invoice Verification, instead of distributing these unplanned delivery costs among all invoice items as hitherto, you have the option of posting them to a special account. A separate tax code can be used for this account.
Input tax, Purchasing (VST)
Transaction/event key for tax account determination within the "subsequent settlement" facility for debit-side settlement types. The key is needed in the settlement schema for tax conditions.
Inflation posting (WGB)
Transaction/event key that posts inflation postings to a different account, within the handling of inflation process for the period-end closing.
Goods issue, revaluation (inflation) (WGI)
This transaction/event key is used if already-posted goods issues have to be revaluated following the determination of a new market price within the framework of inflation handling.
Goods receipt, revaluation (inflation) (WGR)
This transaction/event key is used if already-effected transfer postings have to be revaluated following the determination of a new market price within the framework of inflation handling. This transaction is used for the receiving plant, whereas transaction WGI (goods receipt, revaluation (inflation)) is used for the plant at which the goods are issued.
WIP from Price Differences (Internal Activity) (WPA)
When you use the WIP revaluation of the material ledger, the price variances from the actual price calculation that are to be assigned to the WIP stock, an activity type or a business process are posted to the WIP account for activities.
WIP from Price Differences (Material) (WPM)
When you use the WIP revaluation of the material ledger, the price and exchange rate differences that are to be assigned to the WIP stock of a material are posted to the WIP account for material.
GR/IR clearing (WRX)
Postings to the GR/IR clearing account occur in the case of goods and invoice receipts against purchase orders. For more on the GR/IR clearing account, refer to the SAP Library (documentation MM Material Valuation).
Caution
You must set the Balances in local currency only indicator for the GR/IR clearing account to enable the open items to be cleared. For more on this topic, see the field documentation.
GR/IR clearing for material ledger (WRY)
This transaction/event key is not used from Release 4.0 onwards.
Prior to 4.0, it was used for postings to the GR/IR clearing account if the material ledger was active. As of Release 4.0, the transaction is no longer necessary, since postings to the GR/IR account in parallel currencies are possible.
Reg,
Ashok
assign points if useful.

Creation of new transaction keys

hi
experts this is ramakrishna new to this forum
when i am performing inwards goods movement for the material it triggers bsx transaction key and it post to the respective G/L account. my client requirement is create new trans key say yyy and it triggers my G/L account.
CAN any on esuggest me how to do this

HI,
You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction.
If you create it you have to make changes in Movement type level as well in following path which is not suggestible
SPRO -> MM -> Valuation and Acct Assignment -> Acct Dtermination -> Define accoutn grouping for movement types.
for more info check following link
[http://help.sap.com/saphelp_46c/helpdata/en/12/1a39516e36d1118b3f0060b03ca329/content.htm]
Regards
Kailas Ugale

Need advise for best practice when using Toplink with external transaction

Hello;
Our project is trying to switch from Toplink control transaction to using External transaction so we can make database operation and JMS operation within a single transaction.
Some of our team try out the Toplink support for external transaction and come up with the following initial recommendation.
Since we are not familar with using external transaction, I would like member of this forum and experts, to help comment on whether these recommendation are indeed valid or in line with the best practice. And for folks that have done this in their project, what did you do ?
Any help will be most appreciated.
Data Access Objects must be enhanced to support reading from a TOPLink unit of work when using an external transaction controller. Developers must consider what impact a global transaction will have on the methods in their data access objects (DAOs).
The following findSomeObject method is representative of a finder in the current implementation of our DAOs. It is not especially designed to execute in the context of a global transaction, nor read from a unit of work.
public findSomeObject(ILoginUser aUser, Expression queryExpression)
ClientSession clientSession = getClientSession(aUser);
SomeObject obj = null;
try
ReadObjectQuery readObjectQuery = new ReadObjectQuery(SomeObject.class);
readObjectQuery.setSelectionCriteria(queryExpression);
obj = (SomeObject)clientSession.executeQuery(readObjectQuery);
catch (DatabaseException dbe)
// throw an appropriate exception
finally
clientSession.release();
if (obj == null)
// throw an appropriate exception
return obj;
However, after making the following changes (in blue) the findSomeObject method will now read from a unit of work while executing in the context of a global transaction.
public findSomeObject(ILoginUser aUser, Expression queryExpression)
Session session = getClientSession(aUser);
SomeObject obj = null;
try
ReadObjectQuery readObjectQuery = new ReadObjectQuery(SomeObject.class);
readObjectQuery.setSelectionCriteria(queryExpression);
if (TransactionController.getInstance().useExternalTransactionControl())
     session = session.getActiveUnitOfWork();
     readObjectQuery.conformResultsInUnitOfWork(); }
obj = (SomeObject)session.executeQuery(readObjectQuery);
catch (DatabaseException dbe)
// throw an appropriate exception
finally
if (TransactionController.getInstance().notUseExternalTransactionControl())
     session.release();
if (obj == null)
// throw an appropriate exception
return obj;
When getting the TOPLink client session and reading from the unit of work in the context of a global transaction, new objects need to be cached.
public getUnitOfWork(ILoginUser aUser)
throws DataAccessException
     ClientSession clientSession = getClientSession(aUser);
     UnitOfWork uow = null;
     if (TransactionController.getInstance().useExternalTransactionControl())
          uow = clientSession.getActiveUnitOfWork();
          uow.setShouldNewObjectsBeCached(true);     }
     else
          uow = clientSession.acquireUnitOfWork();
     return uow;
}

As it generally is with this sort of question there is no exact answer.
The only required update when working with an External Transaction is that getActiveUnitOfWork() is called instead of acquireUnitOfWork() other than that the semantics of the calls and when you use a UnitOfWork is still dependant on the requirements of your application. For instance I noticed that originally the findSomeObject method did not perform a transactional read (no UnitOfWork). Has the requirements for this method changed? If they have not then there is still no need to perform a transactional read, and the method would not need to change.
As for the requirement that new object be cached this is only required if you are not conforming the transactional queries and adds a slight performance boost for find by primary key queries. In order to use this however, objects must be assigned primary keys by the application before they are registered in the UnitOfWork.
--Gordon

Account grouping/Transaction keys PRD/DIF

Hello Gurus
I have a situation that some MIRO posting are using PRD and some are using DIF transaction keys. For some reason The postings with DIF are not picking up the material thus resulting in putting dummy profit center.
Please advise the difference between PRD and DIF and how these are triggered during MIRO transactions.
Many thanks
MSJ

HI Jayaram/Surabhi
The see what you are saying and it make sense after I read your reply.
The reason that I say that few MIRO postings are using DIF is because the posting key 83 debit and 93 credit are defined in the OBYC for DIF.
So when I looked at the document in the Vendor acct (after I post MIRO), I see the profict center and material missing for posting keys 83 and 93 for some postings.
Wheras I can see the profict center and material for posting keys 86 and 96 for some othe MIRo postings which use these posting keys.
Of course all these postings are generated automatically
So my question is where do I make a setting to have the material and profict center generated for posting keys 83 and 93.
I appreciate your help on this critical issue for me.
Please advise.

Transaction key FRL and FRN

hello all,
In case of goods recipt of subconracting po.the transaction event key FRL or FRN is hitted as sap standard process.
FRL External activity.
FRN Incidental costs of external activities.
IN OBYC SAME G/L IS assignes to both keys.i want to know that,the value goes to this g/l is loaded into inventory or goes anywhere?
What is the use of these transaction key and how it effect the inventory value?
thanx in advance.
regards
SIMRAN

Hi Sumit,
Kindly look into the note 108844 which explains the posting logic foe subcontracting with Purchase ACcounT Management
active
If the purchase account management is active, and if is GR or IR for the
subcontract order are concerned, the system uses posting keys FRL and
BSV instead of posting keys EIN and EKG.
>> If the purchase account management is active, and if is GR or IR for
>> the subcontract order are concerned, the system uses posting keys
>> FRL and BSV instead of posting keys EIN and EKG.
= no postings to EIN/EKG/FRE -> EINEKGFRE = 0
regards,
Lalita

Transaction key - ZDI, what is it?

Dear SAP-team and specialists,
I was trying to look for information about ZDI - transaction key or BSEG-KTOSL.
...What is ZDI? Where can we get info about ZDI?
Thanks... my search is failed)
Best regards.
Eugene.

Hi,
Transaction Key is one of the processing keys for automatic posting which links two GL accounts or links tax codes
with the gl account to be posted. You see a list of these keys in OBCN where it is created. You can also create
a transaction key of your own. These keys are also called accounting keys to capture the amounts calculated through the pricing procedure or tax calculation procedure to post in the respective GL accounts. The accounts are assigned normally through OB40.
Regards,
Sadashivan

Posting transaction key PRD

Good morning,
I should do a little analysis about our G/L accounts definition for transaction key PRD. What I would like to understand is how SAP configures the automatic posting procedure or, in a better way, how SAP determines which transaction keys must be used in a particular situation.
I think that these tables should be involved in the procedure:
T156SC
T156SY
T156X
T156W
Does someone have more information?
Thank you in advance.
Francesco Alborghetti

Dear Francesco,
Go to T.code - OBYC.
Select the posting key - PRD.
Give the concern chart of Account and go inside.
You will see Valuation modification and Valuation class assigned to GL accounts.
If you want to include the movement types into this, you need the Account modifier. If so, click rules,
select the check box of Account modifier also and save the screen first.
Then go into the trasnaction, where you will find the Account modifier will also be included. You can select the correct account modifier which is in turn assigned with the movement type.
Hope this helps.
Reward points if satisfied.
Thanks.
Augustine Ponraj.

Query on OBYC Transaction key

Dear Experts ,
I have a few queries regarding automatic postings :
1.What process triggers the transaction key AUM ? what type of account should be assigned here ?
2.What process triggers the transaction key BSV? what type of account should be assigned here ? Hw different is it from GBB-VBO ?
3. What is the difference between DIF , PRD & UMB ?
4. Is GBB-VKA relevant for make to stock scenario ?
Regards
Anis

Hi
1) AUM is triggered if the material iin supplying planrt is maintained either in MAP or Standard price and material in recieving plant is in stamdard price and there should be a price difference.The differencial amount will be posted to the Expense/Income account through AUM
2)BSV will be triggered during subcontracting GR.it is the Transaction event key which defines the Change in stock account .This is maintained to accomodate the credit side entry for the output material during GR.Whereas GBB-VBO is for input material consumtion during subcontracting GR.It provides the Debit side entry for Input material consumption
3)DIF is triggered during IV if there is balance and you still want to post it
PRD is triggered if the material is maintained as Standard Price and the value is differenet from the PO value .
UMB is triggered if you want to revaluate the material th MR21
4) GBB-VKA is for make to order scenario where you make a PO directly with reference to sales order
Regards
Sandeep

External transaction control and ability to find new registered objects

Hello, We are using Toplink with external transaction control and have a process inserting a complex hierarchy of objects. During the process we either do a registerObject or deepmergeClone depending on if the instance is already in the db. With external transaction control the registerObject does not actually do the commit to db until the global transaction (Container) issues the commit. Unfortunately we end up doing creating multiple instances of same objects ( because the assumption that registerObject would have written the row to the db ) with the same keys and when the container issues the commit we end up with duplicate key violation. Is there a way to find out if an object with a particular key is already registered?

This sounds like the kind of question that can only be answered with a whiteboard and a good review of your architecture.
In general, there should be no problem registering objects multiple times. I.e.,
x = some object
x1 = uow.registerObject(x);
Then x1==uow.registerObject(x), and x1==uow.registerObject(x1), etc. When you register an object with the UOW, based on PK it'll always return that same one.
Do you have multiple units of work on the go? (that may explain this behavior).
In any case, I think the real problem here is that you're somehow registering objects that are no longer cached. I.e., some object is serialized or rebuilt and then registered after it's gone from the cache. By default, TopLink determines if an object is new or existing (to determine INSERT vs UPDATE) by hitting the cache. You can change this default behavior in the Mapping Workbench, open the advanced property for "Identity" and change existence checking to "check database". Although, this can be a slow and tedious process to have to keep hitting the DB.
A little trick I use sometimes is to take advantage of the "readObject" API that will read the object from the databaes if it's not already in cache, and just return it from cache if it is in cache. Check out the UOW primer at http://otn.oracle.com/products/ias/toplink/index.html for more info, but the jist is that I would do this if I were you:
x = some object that you're not sure is cached and you want to register in UOW;
x' = uow.readObject(x);
IF the object was in cache, you'd get back a working copy, nice and fast. IF it's not in cache, you hit the database, it goes in cache, and you get your working copy. Now you don't have to change the existence checking option which could slow everything down.
- Don

New transaction key with the posting key 24 and 34

Hi,
i want to create a new transaction key with the posting key 24 and 34.
the corresponding table is T030B.
but what is the Tcode/ IMG path to create it?
Regards,
Swetha

Hi,
Go to FBKP. Click on Automatic Postings.
Suppose you want to see the Exchange Rate diff. then click on it. You will see the transaction. Suppose KDB. Then double click on it. Now click on posting keys. The same will be defined in the table which is given by you.
Regards,
Jigar

Transaction Keys Description in MM(BSX, GBB etc)

Hi all,
I was going through many documents for FI/MM Integration but i could not understand what exactly are these transaction keys used for. for ex if thr is a movement type 101, GR agnst PO. then we have two things to do go to BSX- give the debit account and go to GBB-AUM to credit, if i am not wrong. I appreciate if someone please explain the usage in normal terms quoting some examples.
Thanks
Shriya

Hi,
some of the key descriptions -
Expense/revenue from consumption of consignment material (AKO)
     Expenditure/income from transfer posting (AUM)
     Provisions for subsequent (end-of-period rebate) settlement (BO1)
     Income from subsequent settlement (BO2)
     Income from subsequent settlement after actual settlement (BO3)
     Change in stock (BSV)
   Stock posting (BSX)
Revaluation of "other" consumptions (COC)
   Small differences, Materials Management (DIF)
   Purchase account(EIN), purchase offsetting account (EKG), freight purchase account (FRE)
External service (FRL)
External service, delivery costs (FRN)
Offsetting entry for stock posting (GBB)
-   AUA:     for order settlement
-   AUF:     for goods receipts for orders (without account assignment) and for order settlement if AUA is not maintained
-   AUI:     Subsequent adjustment of actual price from cost center directly to material (with account assignment)
-   BSA:     for initial entry of stock balances
-   INV:     for expenditure/income from inventory differences
-   VAX:     for goods issues for sales orders without account assignment object (the account is not a cost   element)
-   VAY:     for goods issues for sales orders with   account assignment object (account is a cost element)
-   VBO:     for consumption from stock of material provided to     vendor
-   VBR:     for internal goods issues (for example, for cost     center)
-   VKA:     for sales order account assignment       (for example, for individual purchase order)
-   VKP:     for project account assignment (for example, for individual PO)
-   VNG:     for scrapping/destruction
-   VQP:     for sample withdrawals without account assignment
-   VQY:     for sample withdrawals with account assignment
-   ZOB:     for goods receipts without purchase orders (mvt type 501)
-   ZOF:     for goods receipts without production orders (mvt types 521 and 531)
Regards,
Sridevi
<i><b>* Pls. assign points, if useful</b></i>
<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/wiki?path=/display/profile/sridevi+pattabiraman">me!</a>

Restricting Transaction Keys while calling SAP Movement Types via MIGO

Hi Experts
I have a requirement which is stated below:
When ever I will call movement type 561 via MIGO, system will check if PRD transaction key is going to be hit & throw an error.How to achieve this.Plz advice.
Regards
Soumick

Hi Soumick Basak
Can you clarify us?
In sap standart , price difference is occured when you post a movement with differences in a standart price controled material master. If there is not a configuration in OBYC (automatic account assignment) , sap gives an error message which consists of like a PRD account not determinated for Valuation class XXXX ...
What you want to control ?
Regards.
M.Ozgur Unal

Account / Transaction key for Services

Dear Sappers,
I am maintaining a condition for services. IMG MM - External Services Management -> Maintain Condition for services . Here i have created condition type and maintained in conditions: Schemas for services. But i cannot create Account key / Transaction key here. Can anyone guide me where i can create account / transaction key for external service management.
Account / Transaction key can be maintained for normal PO conditions in IMG MM -> Purchasing -> Conditions -> Price Determination but those account keys are not appearing in External Service Management calculation schema for services.
Thanks.
Shahzad Shakoor

Using OMGH the transaction key can be maintained but it doesnt appears in Service Management calculation schema.
Using SM30 V_T687 transaction key is maintained and it is accepted in Service Management caculation schem but now i have to assign GL accoutn to it.
Kindly guide me where i can assign GL account for this newly created transaction key as this one is not appearing in OBYC.
Thanks a lot.

PRD - PRA transaction Key

Dear All,
I hav one doubt regarding transaction key PRD - PRA.
When actually it hits . I think it is used while using goods issue and other movements.
But tell me the functionaly of it.
Also I found in OMJJ for movement type 201,221 posting like
PRD PRA and check box is unticked (a/c assignment)
Why is it so?
Pls clear my doubt.
Thanks in advance.
Regards,
Gitesh

Hi,
Price differences arise for materials valuated at standard price in the case of all movements and invoices with a value that differs from the standard price.
Examples:
Goods receipts against purchase orders (if the PO price differs from the standard price),
Goods issues in respect of which an external amount is entered,
Invoices (if the invoice price differs from the PO price and the standard price).
Price differences can also arise in the case of materials with moving average price if there is not enough stock to cover the invoiced quantity. In the case of goods movements in the negative range, the moving average price is not changed. Instead, any price differences arising are posted to a price difference account.
Depending on the settings for the posting rules for transaction/event key PRD, it is possible to work with or without account modification.
If you use account modification, then you can use this modification.
"PRA for goods issues and other movements "
thanks,
Prashant Rathore.

Automatic BRS - External transaction Keys

Similar Messages

Maybe you are looking for