ERP SAP MM Automatic Account Determination

ADempiere/Compiere 的對應方式該學學 SAP
簡單設定又有彈性

用廠商集合碼對應 會計科目
用料品類別碼對應 會計科目

用廠商碼對應 會計科目
用料品碼對應 會計科目

設了一大堆
只用 DocBaseType 區分
又無法區分 MovementType

DocBaseType 又太單純太可笑

以下是由 SAP 物流(MM) 顧問寫的
SAP 的顧問普遍是愚笨且無知
(對財務會計與成本會計 FI/CO)
細膩分工大家有飯吃
顧問多人作業更顯其偉大與複雜
就像大甲媽祖的眾多信徒苦力付出彰顯其神威顯赫

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.

以下就是 SAP 有一些很笨顧問 不懂 ERP的精隨講的鬼話
商人無祖國
企業無國界
哪來本位幣
更不能只做一套帳
一個交易事件要立多套帳
國際佈局下的財會人員都由
當地總經理或財務經理招聘
ERP 就是要全球佈局下要有
一致性的財務會計科目歸屬
不會因為
不同會計人員立不同會計科目
不同會計人員用不同成本計算
追求全球佈局下可統一的評估標準

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.

假如 過帳碼 PRD (料品) 沒設定 修正碼 (modification)
那麼 過帳碼 PRD 在異動碼 101 / 102 (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.

假如 過帳碼 PRD (料品) 有設定 修正碼 (modification)
異動碼 (movement type) 101 修正碼 (modification) 是 AAA
異動碼 (movement type) 102 修正碼 (modification) 是 BBB
那麼 過帳碼 PRD 在異動碼(movement type) 101 / 102 會對應不同會計科目
AAA 會計科目 100000
BBB 會計科目 100001

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.