Statistical VS Real CO account assignments-CSDN博客

Statistical versus "Real" CO account assignments

Why does SAP talk about statistical assignments in CO - why are these different from real Cost Accounting assignments ?

The reason is to facilitate reconciliation between FI and CO. The sum of all 'real' assignments in CO should add up to the sum of all expense and revenue postings (where cost/revenue elements have been created for the GL account of course) in FI. A normal expense invoice posting to expense accounts / cost elements will be a 'real' posting. If the system is displaying an error message insisting on a 'cost accounting assignment' and you think you have entered one, then possibly you have specified a statistical assignment. A common error is in thinking that the business area will do - Business areas are FI elements not CO elements.

Note that the word 'statistical' occurs in a number of different contexts which can be confusing. We are not talking about key figures here.

So how do 'statistical' postings come about? Strictly speaking the whole document is not 'statistical' but one or several of the cost accounting assignments on a line item may be statistical. SAP have defined a number of 'rules' which determine what is statistical and what is not. Briefly these are as follows:

All Profit Centre assignments are statistical	EC-PCA is defined as statistical, therefore if posting to a revenue element, the system will insist on a real cost accounting assignment even if profit centre is specified. A cost centre will not do, since revenue elements are statistical in cost centres. The system will accept the following as 'real' : CO-PA profitability segment, sales order, customer project or a revenue bearing order.
An assignment to a statistical internal order will be 'statistical' - sounds obvious doesn't it!	The system will continue to demand a cost accounting assignment until a non-statistical assignment is made. For example a cost centre as well as the statistical order.
Revenue elements assigned to cost centres will always be statistical	'Revenue' when defined to the system by setting up a revenue element is always statistical in a cost centre. If however you have setup your revenue accounts as primary cost elements then the assignment will be 'real'.
Specifying multiple 'real' cost accounting assignments	If you assign to more than one 'real' account assignment objects (usually only allowed where one is a cost centre), then one of them will be made statistical - the cost centre

The CO cost and revenue element module is where you find the reconciliation ledger. There are some standard reports that will list by 'object type' (cost centre, order etc) the CO postings (real assignments) against the FI postings for a cost element.

Any differences should be due to the use of CO reposts, or distributions, or late setup of cost elements once postings have been made to a GL expense account.

三.核算项目 Vs Coding block (Account assignment)

内部订单使用实例在前面已经介绍过内部订单模块功能，下面举几个实例说明如何使用内部订单
1．
实际费用归集
和成本中心通常用来归集部门发生的费用不同，（实际）内部订单通常用来归集某个专项的费用，这个专项可以是公司的一次春游，一次年会甚至某个建设项目，通常这个专项是跨成本中心的，比如年会，可以建立一实际内部订单，可以将组织这次年会所有的费用全部记入该内部订单，在期末根据一定规则再结算到成本中心，同样也可将各项费用计入一个项目订单，待项目完成后在统一结算至各个资产。
在一个ERP项目中，项目组有30多个成本中心，职工薪酬差旅费等从HR自动过帐，还有些劳保费用，期末需要将这些成本中心的费用按照职工薪酬资产业务类型，差旅费资产业务类型等转入待摊以便统计资产的各项费用（使用资产业务类型做统计），如果需要将这30多个成本中心一一转平，工作量大，所以事先使用分配将30多个成本中心的各项费用先分配到一实际内部订单，再从内部订单统一根据各中资产业务类型转走费用（注意，兼顾报表需求，暂时不能使用结算功能结算到资产，因为结算只使用一个资产类型），工作量减少30倍。
2．
辅助核算和统计过帐
内部订单的统计过帐实质上就是使用内部订单做辅助核算，和国内ERP不同的是，国外ERP的成本对象实际上是扩展了的辅助核算，常用的成本对象有成本中心，内部订单，WBS元素，实际上类似3个辅助核算项目，再加上客户/供应商/物料随时可在字段状态组放开从而在记帐上选择，一般核算到这份上也就可以，我在相关章节已经讨论过成本对象和辅助核算的区别，系统中永远只有一个实际过帐的成本对象，当存在多个成本对象时，系统预先设置了一个优先级，最典型的，如果某费用同时计入成本中心和内部订单，如果内部订单是实际的，则成本中心为统计过帐，如果内部是统计性的，则成本中心实际过帐，这样的最大好出是费用结算非常方便，例如成本中心的实际费用可以非常方便结转到其它成本中心。
内部订单建立非常灵活，比如，在ERP中，除了将员工建立成特别供应商/客户外，你甚至可将某些员工一一对应到一个内部订单。
如果不实施PP或不想使用BOM（有的企业需要配方保密，那就索性不使用BOM）的企业，可将各项目费用计入成本中心，期末将制造费用辅助生产成本中心费用结转到基本生产成本中心，最后再将各种费用按一定系数分摊到各产成品的工单。
重点：
I.
只设一个实际过帐对象,设计思路将非常简洁明了,费用结转方便.
II.其它辅助核算字段说白了只是做费用统计方便管理和报表需求而已，

惜乎，很多系统将辅助核算字段实际上做成了“明细”科目，有这样的系统有理由相信在费用的分配分摊结算重过帐功能上可能就会大打折扣。
启示：ERP中科目只设一级，只有一个实际过帐成本对象，允许多个统计对象，ERP不是财务软件，在遵守会计准则的条件下，科目只是个记帐符号。
3．
项目预算控制
同样，可以使用内部订单做粗略的整体预算控制功能，比如为每个项目建立一内部订单并给予预算就能控制该项目的整体预算，这种预算控制一般不到科目级别，ERP有专门的预算控制模块处理这些业务，请参考本书相关章节。

某ERP宣称其核算项目可以增加999个,真是服了,俺有一比,就好比某高级餐厅宣传大米饭可以吃999碗一样,花了一堆银两
就来吃你几碗米饭,实际上你会发现科目整好后需要的核算项目并不多,无非就是应收应付挂客户/供应商 +物料+某个项目,
比如对应收应付最主要是对应客户/供应商 , 则索性在记应收应付时要求输入客户/供应商带出应收应付(用户第一去选客户/供应商,应收应付自动带出) 想象一下,和记帐时先输应收应付再去将客户/供应商做成核算项目是有区别的,Why?你好可能选错(用户首先选择应收应付, 再去搞客户/供应商), 同样,存货类科目你输入存货自动带出对应的各种消耗类科目,也就是上说: 将客户/供应商/物料/资产看成科目类型,以国内观点,核算项目实际上也类似科目->明细化科目,

· 应收应付挂客户/供应商 +物料+某个项目(如果需要核算,可使用内部定单或WBS)通常就足够了,3个核算项目, 如果要再家员工(可使用客户/供应商的Partner),够了吧,所以在财务凭证行项目将客户/供应商 +物料+项目固化, 无论有没有数据,
对于大部分企业,通常就不再需要什么核算项目主表明细表了, 一个财务行项目包含科目和最常用核算项目字段(比如物料+项目+成本中心->部门)一起搞定,如果你硬要整核算，这个最常用的几个字段就叫"专"项核算, 如果实在还有变态的需求，再启动"辅助核算"功能, 当然国外管这叫什么Coding blcok什么什么的....
有的科目2个核算项目,有的3个,显然最后对数都会出问题, 当然SAP也提供客户化字段的(类似国内的核算项目), 但是通常你根本用不到, 当然,极少企业有一堆BT的报表，将8个客户化字段全部占用还掀不够的!