实例图解利润中心层的应付处理
在讨论企业分权管理和责任会计时,就不得不提到利润中
心,SAP 提供了强大的利润中心业务处理功能,在该 ERP 系统
中,你可以方便地制定企业的利润中心制度, 建立以利润为中
心的综合考核评价体系,出具利润中心资产负债表、利润中心
损益表、利润中心资金预计表及利润中心成本费用分摊表等
各种利润中心报表。
如何实现利润中心模块呢？以利润中心资产负债表和损益
表来说,为了达到目的,则在实际业务中必须将每笔业务都对
应正确利润中心,然而,这并不容易,下面以应付帐款的几个实
例来说明这个问题。
一．两个利润中心对应一笔应付帐款。
在上图采购发票校验时间(Tcode:MIRO)，同一工厂下的采购
订单 4500000044 采购了两个物料，不幸的是，这俩物物料
分别对应到两个利润中心 9188010000 和 9188020000,注意
到在”细节”页,我故意输入了业务范围 3000,发票校验后产生
的会计凭证如下:
注意：
上面的凭证反应出应付暂估(GR/IR)对应的业务范围/利润中
心 2000/9188010000|9188020000
和应付帐款对应的业务范围/利润中心 3000/SINO-DUMMY,
帐户 50000001 是供应商名称它对应的即是应付帐款,SAP 认
为应付帐款科目是统驭科目,供应商就类似”明细”科目。
强 调 一 下 应 付 帐 款 的 业 务 范 围 3000 和 利 润 中 心
SINO-DUMMY，接下来将对此进行付款！
理论上，上同一工厂既可对应不同利润中心(直接维护在物料
主数据),还可对应不同业务范围(Tcode:OMJ7 可设置工厂+
产品组决定业务范围)，假设以上两个采购物料连业务范围也
不同，发票校验产生的凭证如下，注意应付帐款我故意输入
了另一业务范围 A001。
引申的问题是：
(1).为什么在确定应付帐款时可以输入业务范围而不能输入
利润中心?
系统考虑可能会出现本例中同一应付跨利润中心的问题?那
么包含多个采购项目的同一采购单显然也可能跨多个业
务范围,凭什么业务范围就记录在会计凭证?而且,假设同
一供应商为多个工厂供货,而且假设 MIRO 是根据供应商
进行发票校验即多个采购单项汇总产生一笔应付,跨业务
范围不很正常吗?
(2).为什么应付帐款(注意供应商帐户 50000001 行)不带采购
订单?
企业通常是比较严格控制付款的,试想将钱大把掏出腰包谁
能痛快?一位 CFO 就给我提出要求,预付应付都要落实到
采购单,特别是使用采购单付工程款给承包商,这个要求并
不过份,事实上,用户任何需求都不为过,当然也包括 BT 的
让你头疼的需求,把用户侍侯的爽歪歪不正体现了顾问的
价值所在吗？设想一下,如果预付和应付能根据采购订单
互相对清,一目了然，那用户心理估计比喝了蜜还爽。
但是,从上图中应付帐款显然看不到采购单,从技术实现角
度来看,我可以举出两个简单理由:如果需要在应付帐款中
记录采购订单和行项目,一个采购单多个行项目你说记录采
购单尚可行项目记录哪个? 有人说那就只记录采购单,现在
是第二个理由,SAP 提供了多种发票校验方式,假设发票校
验不是根据采购单而是根据供应商或其它就可能会出现多
个采购单汇总对应到一笔应付帐款，这道理类似应付帐款
对应利润中心的问题，所以，系统干脆让应付帐款不带利
润中心和采购订单。
这样的设计思路我很理解,可惜的是,这样的思路郁闷的差
点让很多 FICO 顾问含冤而亡,他会告诉你我发票校验只是
根据采购订单,况且同一采购单中只为一个工厂采购,并且
该工厂绝对唯一对应到一业务范围和利润中心,我要的就是
让应付帐款实时带上利润中心和采购订单,至于行项目不要
也罢，为什么这个小小愿望就不能实现呢？
如果应付帐款产生时未带利润中心，那么付款和清帐如何
对应到利润中心呢？
二．设置清帐格式（Tcode：O7Z4S）
O7Z4S 设置一清帐行格式假设名叫 ST，将业务范围和利润
中心全部带出。
在付款(Tcode:F-53)或清帐(F-44|FB1K)时选择”编辑选项”,在”
未清项目”页的”用于结清事务的行格式变式”的供应商栏选
择行格式”ST”。
做一个测试，假设用业务范围 4000 利润中心 9188040000 的
银行存款科目 1001010000 去付带了业务范围 3000 没带利
润中心(即 DUMMY 利润中心 SINO-DUMMY)的应付，
两笔付款共 1100 元产生凭证如下，此时注意到应付帐款的
利润中心还是 SINO-DUMMY。
这 1000 元银行存款科目 1001010000 输入了业务范围 4000
利润中心 9188040000
这 100 元银行存款科目 1001010000 输入了业务范围 4000
和未输入利润中心。
付款凭证编号分别为 1500000000/1500000001。
三．期末调整（Tcode：
后 产生的凭证。
调整凭证 1200000003 凭证的第 5/6 行正是上面两笔付款的
调整凭证，理解为：
业 务 范 围 4000 为 业 务 范 围 3000 付 了 1100 元 款 ，
6100000000 即内部应付科目，实际上它不仅是调整跨业范围，
也调整跨利润中心甚至功能范围，哪位可爱的老兄将它取名
业务范围调整是认为剥夺人家的基本权力。注意到，调整凭
证没有利润中心调整！
这 就 是 47C 或 以 前 版 本 的 毛 病 , 即 使 是 利 润 中 心 调 整
也失效的业务场景有以下几个:
1. 象上例一笔应付帐款涉及多个利润中心 ,调整后还是
DUMMY.
2. 预付清应付时,假设预付也没有利润中心,两个 DUMMY
就彻底 DUMMY 了.
3. 假设供应商同时为客户,系统提供应收和应付对清功能,而
应收应付一样的道理,是产生时
不带利润中心的, 两个 DUMMY 有瞎到一起了。
设想一下，如果连应收应付都遭成一团利润中心资产负债表
还能用吗？很多人说，能分清损益表马马虎虎就行了，资产
负债表项要分清确实不容易，比如管理部门的所有固定资产，
为各利润中心服务的公用物料怎么能绝对在各利润中心分
的明明白白？
总之，如果没有实时保证到每笔应付应收都带利润中心，然
后你说你家的利润中心应收应付绝对准确估计多半是自欺
欺人。
四.只涉及一个业务范围和一个利润中心的业务。
比较幸运的是，通常同一笔应付可能只涉及 One BA，One
Profit center 。
看上面 MIRO 后的这一笔应付帐款，只涉及业务范围 2000
和利润中心 9188020000。
F．5D/ 后,产生凭证如下,通过 6100000000 将应付帐款和
税金的 SINO-DUMMY 调整平衡。
理论地，F．5D/，SINO-DUMMY 这个利润中心科目余
额都应该平衡。
有个好友问，如果付款时银行科目也输入业务范围和利润中
心，并且和应付的业务范围/利润中心不同，F．5D/ 会
从银行科目吗？
下图可以回答这个问题，假设银行科目走业务范围 6000，和
上面的业务范围 2000 不同，F．5D/ 产生的凭证如下：
注意到应付出始终找到发票校验时应付产生时的原始业务
范围和利润中心，因为银行存款走业务范围 6000，产生了业
务调整凭证 1200000011 。
五．统驭科目的设置(Tcode:OBXM)
使用 ECC6 的在线分割实时保证每笔应收应付都带利润中
心（也包括业务范围）
ECC6 的凭证分割有两大功能，一是特征派生，保证将业务
范围/利润中心派生到忘记输入或自动/后台过帐时不方便输
入的凭证行项目，二是分割，分割后实现零余额平衡，所谓
的零余额平衡就是保证每个完整的会计凭证一定按分解特
征平衡，假设业务范围和利润中心都是零余额平衡，也就是
说，每个会计凭证不仅仅是公司代码层平衡（借贷平衡三岁
小孩现在都知道），也保证被设置为分解特征的业务范围层
和利润中心层次都是平衡的。
设计看起来很巧妙，实际应用存在什么问题呢？
现在，在 ECC6 同样是发票校验,同样是一个采购单的两个行
项目涉及两个利润中心,产生的凭证如下图,上部是分割前的
凭证,注意和以前版本一样,应付帐款只有业务范围没有利润
中心，增值税业务范围和利润中心都没有。
而下半部分是分割后的分割凭证，注意带应付帐款和增值税
都带上了业务范围和利润中心，分别按照不同利润中心给分
成了两笔。
从中可以看出，分割凭证无论是公司代码层/业务范围层/利
润中心借贷都是平衡的。
应付帐款 2574 元，不带利润中心
那么如果使用其它业务范围/利润中心的银行存款付款会出
现什么情况呢？
F-53 使用业务范围 3020/ 利润中心 PRCT1 的银行存款
1001010000 对上面的应付帐款付款 1000 元 ，付款方式：剩
余付款。
你注意到即使在行项目格式中拉出利润中心，应付帐款 2574
元，依旧不带利润中心，你很纳闷，不是已经分割了吗？怎
么不是两笔分别带业务范围和利润中心的而依旧是一笔总
数？
分析人士（杀猪的我）认为，一是应付应收已清未清依旧保
留在表 BSIK/BSAK|BSID/BSAD，SAP 还没有来的及考虑这
些情况，二是它根本就不想考虑，你爱怎的怎的。
起码到目前为止，对按利润中心分析应付应收依旧很不方便。
产生的原始凭证如下。
因为是采用剩余清帐,先全部清 2574 元,再剩 1574 元为未清
项。
有个 0RMB 的汇兑损益，RMB 和 RMB 怎么会有汇兑损益，
都是启动了 USD 做附加本位币的原因，选择“显示货币”看
USD， 1000 元/汇率(保留 2 位) <> 1574/汇率(保留 2 位) -
2574/汇率(保留 2 位) ,在 USD 层多出 ,都是小数位
的原因，通常凭证打印的是原始凭证,0 元的行项显的非常难
看,ABAP 老兄在开发打印程序时也不过滤本位币的零行, 真
是懒的出奇!
现在来看看分割后的凭证,如下图
如上图，注意到业务范围 3020/利润中心 PRCT1 的银行存款
1001010000 的 3020 和 PRCT1 是平衡的,同时系统找到原始
凭证分割后的应付帐款按两个业务 2574 先清掉，问题是，
一个总的应付帐款系统如何知道按业务范围/利润中心各清
多少？看似是按 MIRO 产生各业务范围/利润中心金额去清
的。
测试：
一笔应付对应 3 笔费用到 3 个不同业务范围/利润中心，分割
后凭证。
付款 33 元，业务范围 2010/利润中心 PRCT1：
实务中，如果想分按照业务范围付款这样的情形就大有问题，
为了防止这种情形产生，在以上三笔不同业务范围的费用确
定应付就应该分出三笔，可惜应付不能输入利润中心，如此
看来只能是是分业务范围做 3 笔凭证了。
每个业务范围/利润中心付 11 元，这是付款只付部分的情况，
真是服了。
如果当时一个业务范围的银行存款将 3 笔 300 元全部付了，
就直接全清除了 3 个业务范围的应付。
由于分割和凭证类型相关，可能你的机器测试会产生不同的
结果，总之，分割千万不能滥用！
业务场景：
I．某家具公司要求财务按部门核算收入和成本，确定五金部，
油漆部，木器部等各部门的利润。现在五金部需要一批
木箱，向木器部下一个内部加工单，直到完工入库，希
望核算两部门间的内部收入和利润。假设将各部门建成
业务范围或利润中心。
II．某公司有 2 个新工厂和 2 个旧工厂,对应 4 个业务范围,利
润中心对应产品,其中工厂 FRA4 生产 4 种产品系列,对
应 4 个利润中心。
假设系统设置如下： 业务 范 围 2010 和 3010 属于旧
厂,2020 和 3020 属于新厂,使用段区
分,因为新工厂有地方税务优惠,所以分别出新旧业务范围
的财务报表。同时,根据利润中心(对应产品类别)出产品成
本利润表。
要求使用转移价格(比如参考市场价格)核算跨业务范围
和跨利润中心的转移业务,从而体
现出业务范围和利润中心的内部利润,假设业务范围和利
润中心的组织结构如下表:
工厂 业 务 范
围
段 利润中心
FRA1 2010 3000(旧厂) 9233110000
FRA2 2020 2000(新厂) 9233110001
FRA3 3010 3000(旧厂) 9233120001
FRA4 3020 2000(新厂) 9233120100
FRA4 3020 2000(新厂) 9233120200
FRA4 3020 2000(新厂) 9233120300
FRA4 3020 2000(新厂) 9233120400
*小小的回顾
人们通常喜欢将事业部在 ERP 系统对应到业务范围，国内
有些集团采用不完全的事业不们制，有人说事业部这种管
理制度已经落后，也有人认为业务范围和利润中心是两个
相 似 概 念 ， 于 是 新 总 帐 引 进 一 个 新 的 组 织 单 元 -> 段
-Segment,据说说是用其来取代业务范围的，段现在被设置
在利润中心主数据中。有人说段就是分部,通常，当分部营
业收入/利润/亏损/总资产占总营业收入/利润/亏损/总资产
总计 10%或以上时就需要出具分部报告。
其实这些概念本身并不重要，段的引入比业务范围高明在
什么地方呢？比如，上表只建立了新旧两个段，假设放弃
2 个 新 工 厂 和 2 个 旧 工 厂 对 应 4 个 业 务 范 围
2010/2020/3010/3020 而建立 3000/3001/2000/2001 四个段
的话，这四个段分别加在利润中心主数据中，其实就相当
于在利润中心主数据层次里扩大了一个组织单元的分析维
度，这么一个小改进大大简化了相关配置和操作，叫嚷了
多年的业务范围现在可以被段来替代，从而不用业务范围
和利润中心两边去配置两边去调整，道理就是这样。
如果在新总帐中，在废除利润中心模块，其实也建议这样
做，除非你想 Ledger 8A 的垃圾数据充斥硬盘，这样利润
中心只要使用一下起主数据就行。
Ok，上面两个场景实际上就是一个内部转移价格问题，ERP
提供了多种方法，现在看看使用凭证分割实现内部的
Transfer price，分两部分，配置和操作。
凭证分割配置
为了让你更明白凭证分割是什么玩意，剖析分割嘛，就要象
杀猪一样，一步步屠宰，现在，
先玩一个简单点的配置，如图 1，6 个步骤，注意配置顺序。
图 1-[1]：自定义凭证拆分方法比如叫 ST00000001。
图 1-[2]：编辑未分配处理常量，假设定义一个常量分配名
称 ST，在此分配业务范围，利润中心和段的默认值，
我们应该还能记得旧系统设置默认利润中心的
Tcode 3KEH，现在，因为很可能废除 Ledger 8A，
新系统中则使用 Tcode：FAGL3KEH 来替代，比如
一个资产科目它没有填写利润中心，则优先权分别
是可能存在的利润中心替代（Tcode：OBBH）>
FAGL3KEH > 凭证分割常量中利润中心值。
图 1-[3][4]:激活和按公司代码激活凭证分割,如图 3。
图 3-[1][2]：选上“凭证分解“标志激活凭证分割，设置需要凭
证分割的公司代码。
图 3-[3][4]：凭证分割有两种级别，继承和标准科目分配常量，
常量选择刚才定义的常量 ST，继承是什么意思呢？
ERP 系统默认可使用业务范围/利润中心/段 3 个组
织单元做分解特征，举一个简单的例子，有这样一
笔会计分录：
Dr：费用科目 +成本中心（从成本中心主数据得出
业务范围，利润中心，
在从利润中心得出段，
3 者都有了）
Cr：某资产科目（业务范围，利润中心，段假
设都未输入）
则系统将自动从费用科目继承业务范围，利润中心
和段。
你可以以同时选择两者，如果继承起作用，则常量值
自动失效。
图 1-[5] ： 定 义 业 务 交 易 变 式 （ Tcode ： SE16 ：
V_T8G03|V_T8G02|V_T8G29）,三个专门的分割评
估小概念绕一下你:
I. 会计业务交易: 决定记帐时可使用何种行项目项目
类别。
II. 业务交易变式:一个业务交易可有多个变式, 可以
在变式中对会计记帐业务使用的项目类别进行更
进一步的限制,通过项目类别和会计科目挂钩比如
将系统默认的业务交易 0200 客户发票和应收帐款
科目挂钩,就可限制象 DR,DZ 这样的凭证一定得
使用应收帐款科目(实际上就是一定要输入客户)。
III. 项目类别：可以将科目分配到项目类别，系统预
定义了一系列项目类别，ERP 公司强烈建议不要删
除这些项目类别，最好也不要自定义项目类别，如果
要定义就和他们联系，当然如果要和他们联系，估计
银子那就不能少的。
如果使用“继承“分割级别，项目类别可以从其包含的
基本项目类别中的分割特征获得业务范围，利润中心
和段。
如果您读到这里，估计基本已经不知道俺在自言自语说些什
么，现在自己来定义下这 3 个东
东，透视一下凭证分割究竟是么子玩意,你需要使用 SE16 直
接按“新建“按钮而非在图 1-[5]自定义这些东西.
: V_T8G03 定义 Z998,Z999 两个业务交易,如图 4。
B. SE16: V_T8G02 定义 3 个项目类别 09999，A3838，A9999，
如图 5。
C. SE16:V_T8G29 分配项目类别给业务交易 Z999，如图 6。
D: 为业务交易 Z999 定义一个业务交易变式 Z001, 如图 7。
最后回到图 1-[5]定义业务交易变式画面,图 7-[1]表示项目类
别 0300 在此变式是强制的,你还
可定义某项目类别出现且仅能出现在某业务交易变式中一
次；也可以禁止某项目类别不能出
现在某业务交易变式。
图 1-[6]：定义凭证拆分规则，如图 8，这是一个合成图。
图 8-[1]：因为在此使用的凭证分割方法是 ST00000001，假
设为交易 Z999 定义了两个变式 Z001，Z002，理论上你可
为一个业务交易设置 N 个变式。业务交易变式有这么些个
作用，一是如上图 7 包括一些允许限制必输的项目类别，
二是可为每个交易变式定义不同的零平衡会计科目，在此
画面双击就可，使用 Tcode:GSP_KD->项目类别 01001(零
余额过帐科目定义)，接下来会详细介绍，三是可为同一业
务交易不同变式设置不同的分割用类型。
图 8-[2][3][4][5]：你选择该变式下的项目类别 A9999，分割
处理类别的用户类型有 0、1、2 三种：
选择 0，刚才在说明图 3 的固定值配置我引入了一个会计
分录，那无业务范围利润中
心和段的资产科目将使用固定值 ST 设置的业务
范围利润中心和段。
假设业务交易 A9999 和变式 Z002 使用固定值进行
凭证分割，零余额科目确定码 000，对应科目 970000。
选择 1，则按设置的凭证分解特征并取基本项目类别科
目特征来分割凭证，也是那个分录，假设那
个资产科目被分配到项目类别 A9999，费用
科目被分配到 A3838，因为 A3838 是 A9999
的基本项目类别，则系统自动取费用类科目
的业务范围利润中心和段。
假设业务交易 A9999 和变式 Z001 使用按分割特
征惊醒凭证分割，零余额科目确定码 000，对应科
目 970001。
选择 2，同样是那个分录，无业务范围利润中心和段的资
产科目似乎也使用了固定值 ST 设置的业务范
围利润中心和段，但是，经过测试，基于当前
科目余额分解的分割凭证估计只有神仙才能读
懂。
总结几点：
1．凭证分割可是分激活并选择是采用继承还是常量，公司
代码层激活和业务交易变式中为每个项目类别选择用户
类别是是使用常量 0，继承 1 和按余额分解三个层次。
2．可以为一个业务交易定义 N 个变式，理论上，似乎只要
定义一个业务交易在整一堆变式就可，在一个交易变式
因为包含 N 个项目类别，可为每个项目类别选择采用 0，
1，还是 2 用户类型。
3．可定义多个余额科目确定码并对应多个科目，这可以适
合一些非常 BT 的场合。
接下来再看图 9 的分割凭证配置。
图 9-[1]：将科目分配给项目类别，系统已经内定义了费用收
入现金供应商客户等等项目类别，通常并不需要自定义
项目类别。系统不是有默认识的项目类别吗（对应图 10
的分类）？现在，假设将应收帐款科目分配 02000->客户，
将其它应收/预收科目分配给项目类别 02100->客户: 特
别总帐交易,假设再为默认的业务交易 0200->客 户 发 票
设置变式,实际上默认的业务交易 0200 默认的变式 0001
的项目类别 02000 就是强制的,如果在在图 11 中将凭证
类型比如 DZ 设置业务交易 0200 和变式 0001,实际上就
表示该凭证行项目一定要包括一个应收帐款科目,也就是
包含一个客户行项目,整了半天就这破东西,什么玩意?
图 10 将科目 261100/261200 （费用科目）分给项目类别
A3838，29999（假设是资产科目）
分配项目类别 A9999,我设置 A3838/A9999 项目类别是为了
反证凭证分割设计思路的可笑。
图 9-[2]:将业务交易和变式分配给凭证类型,如图 11,假设将
业 务 交 易 Z9999 的 变 式 Z001/Z002 分 别 分 配 给
SA,SB.
图 9-[3]：定义零余额凭证科目，如图 12。
可以定义多个科目确定码并分配给相应科目，项目种类系统
默认是 01001。
图 9-[4]：定义总帐会计的凭证分割特征，如图 13。
图 13 表示财务凭证将同时根据业务范围利润中心和段进行
零余额平衡，通俗地讲，就是一
个会计凭证将不仅仅保证借贷平衡，而且还将使用图 12 定
义的零余额平衡中间科目在图 13
定义的零余额凭证分解特征层面也保证余额平衡。图 12-[2]
则表示在记帐时该字段必须强制
输入，这个输入值可以是配置比如利润中心默认设置
FAGL3KEH，可以是替代 OBBH 获得，
也可以是成功通过凭证分割功能的固定值或继承而来，如果
都失败了，系统就会报告该字段
是强制字段。
图 9-[5]：定义 CO 模块的凭证分割特征，系统默认使用了成
本中心/订单/获利段做分割特征。
凭证分割小议：
凭证分割功能配置完了吗？明白了没有？现在俺发表一下
个人看法，凭证分割的固定值有什
么用呢？什么业务居然会使用固定值呢？就算有这样的业
务，使用 OBBH 替代不就得了？
对于用户类型 2->基于当前科目余额的分解，分解后的凭证
我看了半天也没大弄明白，弄的
俺现在自己都开始怀疑自己的智商了，所以只剩下一个用户
类型 1->按图 13 定义的分割字
段分割凭证了,那么为什么要整那么些业务交易,业务交易变
式,项目类别晃悠干啥呢?比如将
科目对应项目类别,将业务交易和变式对应到凭证类型,有什
么实质意义吗?除了做点类似
OB28 的 Validation 的功能根本没有任何实质意义?在图 12
中看似可定义多个零平衡科目并
分配到业务交易和交易变式(即对应到凭证类型),通常实务中
也许会有为不同利润中心定义
不同零平衡科目的需求,但是俺目光短浅还从未听说过根据
凭证类型去定义多个零平衡科目
的,而且从理论上我可以将所有的科目都分配给我定义的两
个业务交易 A3838,A9999,实际上
凭证分割只要有几个简单配置就行:
(1).设置允许使用分割凭证的公司.
(2).定义凭证分割特征,允许组合使用业务范围/利润中心/段
而已.
(3).定义零平衡科目,如果需要可以根据不同的业务范围/利润
中心/段去定义不同科目,要不给个出口.
原来一大堆配置不过是忽悠绕着你玩而已,俺现在甚至怀疑
很多所谓的配置其实是 ERP 设计
师们的自愚自乐，软件工程师们对将简单的东西复杂化这项
工作似乎乐此不彼，凭证分割这东西使俺明白了什么叫
化神奇为腐朽；据说 ERP 咨询业也是这样，善于
将 1 绕成 1-2+3+4-5-6+7+8-9 能把用户绕昏的，就成了行内
老大业内专家。
凭证分割的业务场景：
SKIP。。。
