前言
很多大牛说SAP设计精妙，换言之就是配置起来可以灵活的应对各种业务情况。搞过软件开发的同学应该都知道，灵活的架构设计往往是通过解耦来实现的，就像搭积木，积木块越多，能搭出来的形状就越多。
SAP如此精妙，积木数量一定是那些个专家深思熟虑的结果，多一块少一块都不妙。自学SAP以来我就发现，它里面有很多Type、Group、Category之类的东东，就好像这次要说的自动科目确定（Automatic Account Determination）的过程中，Type、Group、Category一个都没落下。这次的自动科目确定比前面两篇文章中的编号范围、字段选择那是复杂多了，这么复杂的主题，一篇文章肯定是理不清的，我打算尽力多水几篇，向灵活的SAP设计致敬。
什么是自动科目确定（Automatic Account Determination）？
这里很好理解，企业管理中涉及到物料的钱和数量方面的变化都需要记账。所谓自动科目确定，以下图为例，就比如收到货物需要记账的时候，SAP能够通过自动科目确定（Automatic Account Determination）自动匹配好相关的会计科目帮用户把账给记好。
SAP是如何进行自动科目确定（Automatic Account Determination）的？
上图中那个箭头，SAP内部进行了一系列的匹配才最终为收到货物这项业务找到对应的会计科目。综合网络上各国大牛的意见，我觉得最终的自动科目确定是和下图中的4个因素相关的：
为什么说是这4个因素？请参看下图和Automatic Account Determination相关的设置画面，从该画面可以看出 ❶ Transaction key通过 ❷ Valuation class和最终的 ❸ Account就是科目关联起来了。只是这里为什么4个因素只出现了2个（ ❶ 和 ❷ ）？且听我慢慢道来...
什么是评估类（Valuation class），用来干嘛？
首先登场的当然是我上篇文章【思爱普（SAP）真难之大神帮我来解惑之搞懂物料主数据的字段选择】中的大冤种Valuation class，就是它促成了我写这篇文章。和它相关的设定画面参照下图。可以看到系统将它和物料类型（Material Type）关联起来了。请参考我上一篇文章，每次在新建物料的时候，新物料的Accounting 1这个View里面的Valuation class都是必填的，如果新物料对应的Material Type有多个对应的Valuation class，那么在填写新物料的Valuation class的时候系统就会弹出小画面让你从多个里面选择一个供这个物料使用。N个Material Type可以对应N个Valuation class，为了增加灵活性，SAP在它们中间加了一层叫做Account Category Reference，因为每个Material Type和Valuation class都只能设置一个Account Category Reference，于是这3者的关系就成了Material Type : Account Categroy Reference : Valuation class = N : 1 : N。
什么是评估分组代码（Valuation Grouping Code），用来干嘛？
图3中Valuation Grouping Code并没有出现，但是图3中出现了科目表（Chart of Accounts）。科目都是属于某一个科目表的，而如下图所示，科目表都是挂到某一个具体的Valuation Area（其实就是Plant，SAP推荐以Plant为单位设定Valuation Area，很多网文都有涉及，本篇不做赘述）。如果某几个Plant使用相同的科目匹配，那么可以把这几个Plant通过Valuation Grouping Code分到一起，那么SAP内部存储数据的时候，在某个表里面只需要将科目对应到Valuation Grouping Code就行了，不用对应到具体的Plant（万一有集团选择按照Company Code为单位设定Valuaton Area，还需要考虑对应到具体的Company Code，加了一层Valuation Grouping Code，换来了更灵活的存储架构...）。
什么是事务码（Transaction key），用来干嘛？
事务码（Transaction key）用来代表具体的某个业务，这个具体的某个业务最后通过匹配关系找到对应的会计科目就是自动科目确定的最终目的。但其实还有一个科目分组（Account Grouping），具体参加下图。当某个业务发生的时候，SAP内部是通过移动类型（Movement Type）来多次触发直到找到最终的Transaction key（下图的Tran. /event key）的，然后由Transaction key通过图3匹配到具体科目。据我观察，Account Grouping应该就是下图的Value String，每个Value String会对应1个或者几个Transaction key。
什么是科目修改（Account Modifier），用来干嘛？
我们可以看到图6中只有科目修改（Account Modifier）是可以设置的，那是因为SAP将Value String和Trans. /event key以及它们的关系都写死了，用户想要自己再发挥一下的话，那只有通过科目修改来完成了。相应的，图3中如果选择的Transaction key有对应的科目修改的话，可以为科目修改设定专门的对应科目。
后记
至此理论篇结束，欢迎有缘人批评指正。后面暂时想到会先来一个实践篇，有可能还能再水一个设定篇，容我考虑考虑先...
