Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Automatic Account Determination

Automatic Account Determination

Ratings: (0)|Views: 804|Likes:
Published by hemant solanki

More info:

Published by: hemant solanki on Aug 17, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Automatic Account Determination
This is perhaps the part that causes the most heartache for the FI Configurer. For somereason, although it is an integration area, the FI team always ends up with responsibility for it. To do a good job you need a reasonable understanding of :1.the business processes in the source modules2.the FI account postings that they should be generating (what sort of account shouldbe debited or credited etc)3.the organisation structure and its relationships between the source modules4.the reporting requirements that are expected from the General Ledger or Profit CentreAccounting5.your chart of accountsSounds daunting doesn't it ? Here is a suggested approach ...The IMG section under 
GL / business transactions / integration
will take you through allthe necessary account determination for the automatic postings that the system may need topost. You may not need all of these.You could maintain on an
as needed
basis. As theproject teams test or prototype their expanding functionality, the SAP system will look for theaccounts to which it should post. The error message and the SAP documentation andconfiguration does not always explain clearly which piece of account determination is usedfor which type of functionality, so it is sometimes difficult to be pro-active.Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop anunderstanding of what the business transaction is and therefore where it should be posting.Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).I will be explaining each account determination area simply and clearly with postingexamples
SD to FI Account Determination (aka revenue account determination). This and MMseem to confuse people the most.
More later - This may take a while to complete........
 In the meantime, some general warnings:
Whenever you change the field status settings for an account, ensure that you haveverified that any automatic postings will be able to meet the requirements. EG: do notmake business area mandatory if your system may make a posting which cannotdetermine and post the business area.
Consider specifying that accounts that are posted to automatically can
be postedto automatically. This will simplify reconciliation between the source module and theGL account should you need to do this.
SD-FI Account Determination and Postings
This is known in the IMG as "revenue account determination", but it covers a lot more thanthat (discounts, taxes etc). This is what determines how the financial impact of your SDBilling document is posted into the FI General Ledger.
The integration is controlled both in SD and in FI.In SD there is a awesome area of configuration called the pricing procedures. The pricingprocedure determines the final price quoted to the customer for a particular product. Thiscould be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. Thiscondition techniqueis used in a number of areas of SAP.For now all we need to know is that each condition type is assigned to an account key (or inthe case of rebates two account keys). You can assign multiple condition types to the sameaccount key. There are a number of account keys that are pre-defined in the system. For example:
ERF freight revenues
ERL revenues
ERS sales deductions
EVV cash settlement
MWS sales taxNow we start getting to the integration by mapping the account keys to GL accounts. But it isnot as simple as that. It can be as flexible (ie: as complex) as you want. Start off with themost simple approach. Generally if one is using a good sales / revenue reporting tool (eg:CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that areposted to. The level of detail that you need in GL should be determined by your financialstatement reporting requirements - you may end up with only one Revenue account - it is agood bet!So, taking the simple approach we would ignore most of the configuration possibilities :procedures, access sequences, condition tables etc
(Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it inanother then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )
We have to decide which access sequences we want to use (Five access sequences aredefined in the standard SAP R/3 System). To keep it simple, let us assume we just use one -for example: the access sequence "chart of accounts/sales org./account keys".The chart of accounts part is standard in all account determinations, so let us look at therest. This access sequence allows us to specify different GL accounts for different SalesOrganisations.So if we had a billing document line item where the customer had some special deductionsfor one of the products he purchased, we could map accounts by Sales Organisation. Tomake it even simpler a document is within one Sales Organisation so we have an overallmapping as follows:
SDLineItemCondition typeSD AmountAccountKeySalesOrganisationGL Account
1Sales deduction for being such a nice guy$10ERSSales deduction for special promotion onparticular product$15ERSBase Revenue$200ERL1000800010 - Salesdeductions for 1000800000 - Revenuefor Sales Org 1000Total for item 1$1752Base Revenue$100ERL1000800000 - Revenuefor Sales Org 1000Total for item 2$ 100Document Total$ 275So the invoice that the customer gets (and that you can view in SD) will look something like:
Item (Note this is the SD Invoiceline item)Amount
Item 1: $175Item 2: $100
Total owing , 30 days terms etc: $275
The GL document posting that the system will make to FI will look something like this though:
FI LineItemDebit / Credit AccountAmount
1Debit(PK=01)Customer (AR Account)$ 2752Credit(PK=50)Revenue (GL Account)-$ 3003Debit(PK=40)Sales Deduction (GLAccount)$25
Balancing to 0 as all GL documents must....$
Note : There is
no direct relation between an SD Line item and an FI Line Item
- they aredifferent things.
Other considerations:
Remember that if you are using business areas, then depending on your configurationthere, the system may create additional FI line items if it needs to post to differentbusiness areas. This may be even more of a reason why you do not need additionalGL accounts. If your Sales Organisations already map to different business areas,you could use the GL accounts for all Sales Organisations.
Different access sequences will allow a broader variety of GL accounts (for example:by customer account) group. I strongly suggest having a good understanding of thereporting requirements expected to be supported from the General Ledger vs the SIS(Sales Information System) or CO-PA (Profitability Analysis) or (CO-PCA) ProfitCentre modules before you create too many GL accounts. At the risk of repeatingmyself, the SD to FI account determination should only be as detailed as your 

Activity (14)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Madan Mohan liked this
swayam liked this
susmita_099 liked this
kruthig liked this
mita.patel liked this
ssahu1979 liked this
ssahu1979 liked this
vidyadhar_k liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->