Sapdup Blogging about SAP

27Oct/0643

SAP MM Automatic Account Determination

Sometimes I wonder how many implementations it would take to get the Automatic Account Determination process down-pat.

Every consultant I've dealt with has had to brush up on the account determination process before implementing it, no matter their experience level.

So, for my sake, and yours, here's a simple (as much as it can be) explanation of what Automatic Account Determination is, what it does, and how to do it.

Why do I need Automatic Account Determination?

Every time a transaction with financial implications is run, postings must be made to financial accounts. I'm a logistics consultant, so to be honest, I don't care. But it has to happen, so since this is an integration point between us and FI, unless you can make the FI consultant do it, we have to fight through it.

We could let the user enter the GL account each time we post an invoice or goods receipt, but SAP is supposed to be a productivity tool, so that's not really acceptable.

So, the idea is that the system will determine (based on our config) what account to post to depending on a number of factors, namely; company code, valuation area (plant vs company code), material / material type, transaction or business event and movement type.

So, with five variables, the determination system must be pretty complex?

Yes. When you come to understand the way SAP have done it, it is an elegant solution, but it is pretty damn complex.

Before you begin, sit down with the FI consultant, find out what accounts there are and in a business sense, how and when each of the accounts should be posted to. Discuss all five of the categories above. With this info set in concrete in front of you, you can begin the SAP config.

Here's the lowdown, try and stay with me.

Essentially all that is happening is that SAP are allowing us to maintain a record of "if x and y happen, then use account z" and "if a and b occur then use account q".

I can just imagine the conversation many years ago in Germany (translated for your convenience):

"Ok, we need a table of possible outcomes for account determination."

"That's faaarrr too easy. Let's break it into fifty different tables, come up with many interchangeable names for the same thing, and hide the tables beneath several different, unimaginable directory paths."

Configuration Steps

First up, since we have to do something first, let's specify our valuation control. This is done via IMG > Materials Management > Valuation and Account Assignment > Account Determination > Account Determination Without Wizard > Define Valuation Control.

All that we're doing here is specifying whether the system should consider the valuation grouping code in it's determination procedures.

"What's the valuation grouping code?" I hear you asking?

The valuation grouping code (vgc) is a collection of valuation areas that will have the same account determination. Since a valuation area can be a company code or plant, we can say that a vgc represents a group of plants or company codes that have the same account determination.

If you don't use the valuation grouping code, you'll have to set up account determination for each plant or company code in SAP.

If you're using the vgc, then jump into "group together valuation areas" and assign your company codes or plant a code (any code). They should be somewhere in the list automatically, all you should need to do is give them a code.

The next step is to manage different account determination per material type. This is where it can get complicated if you let it.

The valuation class is linked to an account category reference. The account category reference (acr) is an artificial code which allows flexibility in linking material types with valuation classes.

"Huh?" I hear you asking. Let's consider the alternatives.

We could relate the GL account directly to the material type. This would be easy to setup for a few material types, but would take a huge amount of time for many material types, and would be hard to understand if changes needed to be made.

We could use the valuation class, assign the GL account to it, and then assign valuation classes to material types. This is better, since we could for instance have a "Raw Materials" vc and a "Finished Materials" vc and then simply link all the various material types under each category to the valuation class. This would make updates and initial loads easier, but there is still one thing missing, a material type can only be part of one valuation class and can only post to one account.

However, in the real world, a material type may post to different accounts depending on things other than just the material type, such as plant, movement type or indeed any of the factors above.

So, we have an account category reference which is linked to a material type. This acr is then linked with a valuation class and the GL account is linked to the valuation class. So a material type can be linked to one or more valuation classes (and hence GL Accounts) and in turn, a valuation class can be linked to multiple material types (enabling ease of understanding and updates).

Now that you (hopefully) understand that, the actual updates are pretty simple.

Go to transaction: IMG > Materials Management > Valuation and Account Assignment > Account Determination > Account Determination Without Wizard > Define Valuation Classes and begin by defining your valuation classes. Then define your account category references and go back into your valuation classes and assign them (or you could do the acr's first). Then go into your material types and assign your acr's to your material types and done! For the moment.

At this point we should consider another factor, the actual business event that is occurring and it's effect on account determination. This is another area where you have to try and see through the impenetrable fog of terminology.

Each time "something" occurs in the system it produces a "key" for each of the postings that need to be made (i.e. debit and credit). This "key" is entered in our account determination procedure so that postings for credit and debit go to different accounts. Simple aye?

Well when (as far as I understand) the "something" can be called 'transaction (key)' or 'event (key)' and the "key" can be called 'value string', 'posting rule' or 'posting string for values' and the column header in SAP for the "key" says "Trans". Fun, fun, fun.

The combinations of movement type and "keys" and how they are determined are all internally programmed by SAP, so we don't really care. What we do care about is the account modifier or 'account grouping code'.

This is the topic I spent the most time on, and I'm still not completely clear, so don't feel bad if you're confused.

The account grouping code (aka account modification code, modifier or (in SAP) general modifier) is a three character code (which rather oddly has no link with the posting strings ("key")) which we use to break account determination down by movement type.

For example, by default in SAP, the system says for movement type 101 and posting key PRD there is no modification. So the account determination is not different based on movement type. However, I can enter a code (e.g. AAA) against movement type 101 and posting key PRD and code BBB against movement type 102 and PRD.

Then in 'Configure Automatic Postings' when we go into posting key PRD, we will make entries for 'general modifier' AAA, account 100000 and BBB of 100001 (there will also need to be an entry for a "blank" modifier which should cover all the other movement types).

So, make sense? Hopefully.

Now you need to go through and for each posting key that we're concerned with, record each of the defining factors mentioned above (you don't need to enter them if you're not using them) and enter a GL account for each permutation.

You should now find that your account determination is working. I wouldn't put any money on that promise. My hope is that having read this guide, you're a little bit closer to having your account determination working, and that in conjunction with a number of other resources you'll get there eventually.

---

PS: I will be updating this article periodically, and would appreciate your constructive criticism by commenting below.

Comments (43) Trackbacks (1)
  1. Dear Pete,
    Really I should appreciate the way you have tried to make the Automatic Account Determination easy and clear. Well this is also my favourite topic and lets share and make the understanding more clear and also share this with whole world. You can contact me at anilrajuin@gmail.com

    Thanks & Regards,

    Anil

  2. Thanks for your comments. I’m a bit busy at the moment to discuss or refine this topic, but I’ll keep it in mind. Cheers.

  3. Hi Pete,

    Great stuff and expalantions.why not compile stuff and release in pdf format. Possible keep for sale on net.
    virender

  4. Hi Pete,
    I have a question on the transcaction “OMWN”
    Value string field, How we get values in to this field?!!!. Can you please elaborate thispoint a little more.
    Posting string for values.
    I got confused with the above explanation and clueless like where we are defining the values like WE01, WE06 etc….
    Thanks in Advance
    Ram.

  5. Hi Ram, I think the area you’re confused in is easily the most difficult.

    The answer (I believe) is that you DON’T change or enter values in the “value string” field. These are unique combinations specified by SAP.

    You can only specify differing account postings for movement types and value string combinations where SAP have already listed them and allow you to specify an account modifier.

    I’m sure that doesn’t make sense, but suffice it to say that SAP is putting some limits in place here. Try it out and hopefully it will make some more sense.

    Cheers.

  6. Pete,

    Absolutely fantastic. I am a PP consultant,trying to make sense of automatic account determination. First time, i feel i have made som headway in understanding this stuff.
    Keep up the good work.
    Thanks

    Sonik

  7. Pete,
    This is a very helpful guide and well written. Humour is always good at times like these..
    I have one suggestion and that is how about a diagram showing all of the possible interdependencies between these objects? That ought to clear up the understanding of this area once and for all.
    I am going to try and compile something myself based on the details above and will feedback if I have any success.
    cheers,
    Stuart

  8. Pete,

    Thanks for crystal clear explanation. I am a PS consultant and everytime I have our MM and FI guys pondering over these issues. Now I can use this to understand why they try to confuse me also.

    Thanks,
    Pradeep

  9. Pete you are awesome, it was crystal clear.

  10. Pet,
    Thats a awesome piece on Automatic account determination from MM perspective. Even though I have limited knowledge of MM, every thing was crystal.
    The only thing I want to clear is Is Account Modifier and Valuation group code are different terms for the same thing. Thats what I can make out from your article but couldn’t find a any other piece on net supporting that?
    Your reply will be appreciated.

    Thanks any ways
    Vic

  11. Hi ,

    I am an Abaper and really understand how the MM integrates with FI .

    Sriram

  12. very good explinations, and expecting more postings for you.

    Thank you

  13. very good explinations, and expecting more postings form you.

    Thank you

  14. Is someone can send me a file which is already configured with automatic account determination mm with screen shots.

    Thank you.

  15. Hello Pete,
    Really good one..flowchart kind of thing will help to understand this complex topic. Keep posting more and more such articles.
    datta

  16. great job pete. really appreciate this.

  17. Simply Awesome.I say 9/10.
    Even a layman can understand AAD by this article.

  18. I am an MM novice. I followed your instructions and was able to update my material valuation code to process my goods receipt. Many thanks!

  19. Thank you Pete! A very nice explanation on MM- Fi interface and it is very valuable one .

  20. Pete, great explanation. I have had problem in the past explaining this issue during a training session.

  21. Hi,

    I must say its a really very good article uploaded by you.

    But wht i feel is if you can also provide the screen shot and t code info. then it will be more clear n more useful.

    Regards,
    Krupesh Kothari.

  22. Thanks for all your comments. I won’t be updating this article any further as I no longer work in a technical SAP role. I would really like to publish some similar guides written by you. If you have something you would like to publish, please send it to pete@peteandmegan.com. Thanks.

  23. Hi

    This artcle is very simple and superb. The way u have nerrated also simply excellent.I hav got a prolonged doubt abt the General modifier. ur article its simply melted the doubt.

    thanks lot…..
    keep doing such a wonderful job…

    Anbesivam

  24. Hi

    Thank you for such a wonderful explanation. I have a question though, What is posting String WA01…WA14. where are they defined and how are they used in account determination?

    Thanks

  25. Absolutely neat piece of Information.
    Kudos to Pete.
    Please keep this good work for the benefit of others.

  26. Great job! Thank you, Pete….

  27. Hi Pete,

    At a point you say “If you’re using the vgc, then jump into “group together valuation areas” and assign your company codes or plant a code (any code). They should be somewhere in the list automatically, all you should need to do is give them a code.”

    Well, the problem I’m facing is that one of my Plants does not appear in this list… How can I make appear here?

    I’ve already checked T-codes OX18 and OX01 and all the assignement is done regarding this plant…

    Any suggestion?

    Kind regards,
    Miguel

  28. It’s been quite a while since I was hands on with this. But I would suggest you check the precursor steps. I believe the code gets into that list during one of the definition steps from earlier in the process described in this post. So if it’s not there, I would suggest you missed it earlier…Beyond that, hopefully some other reader might be able to provide an answer…

  29. hello,
    i am encountering this problem regarding account determination:

    “account determination for entry GBCA WRX not possible”.

    Could you please advice me what to do in order to fix this error?

    Mae

  30. Hi Mae, as I’ve mentioned a couple of times, I’m not involved with SAP in a technical role anymore. So I can’t recall the detail I would need to in order to answer this question. All I can suggest is that you go back through this guide and make sure you have executed all the steps for the entry you’re talking about.

    Thanks
    Pete

  31. Hi,
    The summary of auto a/c detmn is:

    An ac cat ref has —>one or more val clas assigned to it.
    An ac cat ref has —>one or more matl types assigned to it.

    Val class for material is assigend through acr:
    That means, mat type –> ac cat ref –> val class

    Movmt types r grouped by SAP by giving their own codes, which you cannot do.

    Combo of a val class and a ‘mvmt type grp’ is assigned to a G/L account.
    This way a/c is determined.

    Matl type–>acr –> val class–>
    Movmt type –> mvmt type group –>

    Combo of val class– mvmt type grp —> GL ac.

    Praveen N

  32. Dear Pete ,

    can you send me SAP MM Automatic Account Determination Guide on my ID?

    I am very thank ful to you

    Regards,

    Sam

  33. Hi, sorry, this guide is all I have. Thanks.

  34. hi,

    pete i have done certification in procurement and i have come across this topic but it was rather complicated.

    your job here is really cool, i would sujjest you to come up writing books on MM that would be really helpful

    “its a gods gift to explain things simplest”

  35. Hi Prasad. Thanks for your positive feedback. These days I spend my time managing a support team and encouraging them to write these sort of articles. It’s a good encouragement though to keep the blog going and at least writing something!

  36. Hi! I jumped here in search for info, and I think I can add a little explanation to help understand those famous “posting strings”… or value strings… or whatever; to avoid confusion: check the field name is BUSTW (F1 + click on the hammer button + check field name).

    The posting strings link the movement types to the accounting key this way:

    1) In table T156 you have all the movement types (BWART) and their correspondent “posting string reference” (BUSTR, which usually, but not always, is equal to the movement type). For instance: movement type = 101 –> posting string reference = “101”

    (You can check all tables with trans. SE16, pretty easy)

    2) Now you can go to table T156SY and with this posting string reference (BUSTR) you can locate the famous “posting string” (BUSTW), but of course you will for sure get more than one entry, since it depends also on:

    – If you are posting to special stock
    – If value and/or quantity is updated in the valuation area (plant). You can check that through OMS2 –> material type.
    – If you post with reference to a document (for instance PO)
    – If you update consumption.

    3) Congratulations! now let’s say you located posting string WE01. Now you are ready to jump again to table T156W, i9n which you can see all the possible posting keys that can be used:

    BSX / WRX / PRD / KDM… etc.

    4) Now… no more tables: a valuation program reads all the possible postings and determines a value for all of them. Those keys with value = 0 are not included in the FI document. For instance: if BSX and WRX match, then no posting for PRD.

    You have also table T156X, which is pretty much the same as what OMWN shows, but handling the table with SE16 allows you to locate registers in a much more flexible way than the customizing transaction. For instance you would want to know which are the movement types for account modificator PRA, you cannot get that with OMWN.

    Cheers!

  37. pete
    really vital document on AAD.I read this topic in book several times, but was very difficult to understand.
    You have made it as simple as breathing
    uday

  38. No one can explain better than this…..on AAD

  39. Hi Pete,

    Well written. Hats-off!
    Thanks for the endeavor.

    Regards
    Sathish

  40. Dear Pete,

    It was simply a superb explanation from you, you are really great!!!
    If you write any such articles on Pricing schema and any other topics on MM,pl do share with with, i would be really thankful to you if you do so.

  41. Hi pete, you really did well, you explained the complexed in a very easy and simplest way.

    Thanks & Regards
    Gaurav Mehta

  42. It would be great if the topic on Account Determination, Valuation Class, Valuation Group, Material Type and GL Accounts are all depicted a diagram for better understanding. If you could mail me one to the above email id that would be great.

  43. Great read, and a nice strtaightfoward guide – you made it all crystalk clear and patted my back for the effort. thanks a lot! i need it. Mx


Leave a comment