ARTICLE · 1306965
SAP-CO-Overhead配置文档上手就会!作业类型超过6个7个如何处理.
"
费用表最多只能挂 6 个作业类型，模板分摊不受这个限制。
—— SAP Overhead 模板分摊全解析
带图配置手册在知识星球。
做成本核算的人，多半都撞过这么一堵墙： 项目中作业类型超过6个，第 7 个加不进去，配置就卡在这儿了。
这不是配置没到位，是标准费用表本身的设计限制。SAP 提供了另一条路——Overhead 模板（Overhead Template） ，用数量公式驱动分摊， 一行一个成本中心与作业类型的组合，想加多少加多少 。
但模板分摊不是「换个地方配置」那么简单。它有一套独立的配置链路、一套独立的执行时点、还有一套容易和费用表打架的坑。而且它有个特别的地方——期末分摊和实际单价计算是分两个阶段做的，中间夹着一个「过吸收」余额，这个机制不搞清楚，成本中心余额永远归不了零。
这一篇把模板分摊的十四个配置与执行步骤完整拆开，并用一个带数字的例子把两阶段计算的每一步都算给你看。文中出现的 CPT1、OKZ2、KTPF、CPTD等均为 SAP 公开事务代码，可直接查阅引用。
📌 本文看点
01
模板分摊与费用表的本质区别
02
两阶段计算：过吸收是怎么被冲平的
03
期末六步顺序：颠倒一步全乱
WHY
为什么模板分摊能突破 6 个的限制
先说清一件事：「6 个」不是 SAP 随便定的数，而是费用表的数据结构决定的。费用表的行是固定结构：基价行（BASE）+ 若干个间接费用行（Overhead），每个间接费用行挂一个作业类型。这套结构在标准设计里最多支持有限的几行。
而模板分摊走的是完全不同的路子。它的每一行只描述「哪个成本中心 + 哪个作业类型 + 什么数量规则」，一行一个组合，不受 6 个限制。
「费用表是『按比例摊』，模板是『按数量算』。前者回答『这个成本中心费用按 15% 摊给谁』，后者回答『这张订单实际用了多少个机时，值多少钱』。」
这个区别决定了模板分摊的真正价值：当一个成本中心要对应多个不同成品，或者同一类成本在不同订单上消耗量差异很大时，固定比率摊出来的成本会失真，而数量驱动的方式能算出更接近实际的分摊结果。
文档里也明确提到了一个延伸问题：当作业类型超过 6 个时，第 7 个如果是报工数量驱动分摊的，理论上不需要单独报工——因为模板里的数量公式可以直接取订单的报工量。但如果这个作业类型确实需要单独的报工记录，那就得在订单里真实报工，否则公式取不到数。
关键前提
模板中的作业类型必须为作业类型类别 1（手工录入/手工分配），这与生产订单确认中使用的作业类型设置相同。选错类别，模板分摊直接跑不出数。这是配置时最该先确认的一条。
CONFIG
配置链路：八步串起来
模板分摊的配置是环环相扣的：模板本身不生效，它必须通过「Overhead Key → Overhead Group → 费用表」这条链，最后挂到物料和订单上才被调用。这条链有 8 个环节，漏一个就白配。
定义模板（CPT1/2/3）：输入模板名称与环境（Environment）。环境 001 用于成本估算与生产订单，环境 009 用于流程订单。
模板行里 Type 列选 Cost Center / Activity Type，Object 列逐行输入成本中心与作业类型的组合，每行一个。
分别维护 Plan Quantity 与 Actual Quantity，可手动输入固定值，也可用公式（点数量列右下角公式编辑器）。
维护 Plan Activation 和 Actual Activation 激活条件（如仅对半成品/成品激活）。
实操细节
类型选成本中心/作业类型，描述不填会自动根据对象带出，单位也自动带出。公式编辑器里有个「选择类型参数」：1是当期总的计划数量，2是所有汇总，一般选 1。成本中心和作业类型要依次选择，选完点绿色勾。
这里有个容易搞混的点值得单独说：以作业类型为例，模板里的「计划数量」取的是 KP26 维护的计划数量，不是报工数量。报工数量是另一个来源，两者别混。
中间四个对象：一个都不能少
然后是挂载环节：步骤 6在物料主数据（MM02成本核算 1 视图）填入 Overhead Group；步骤 7在生产订单的成本核算标签页确认 Costing Sheet 与 Overhead Key 已正确派生（通常自动带入，可手动改）；步骤 8期末执行实际分摊。
好消息
物料主数据里配好 Overhead Group 之后，系统执行标准成本估算（CK11N/CK40N）时会自动读取 Overhead Group → Overhead Key → 费用表 → 模板，完成计划模板分摊，无需单独执行。这条自动链路是模板分摊相比手工费用表最大的便利之处。
必须避开的坑：费用表和模板同时激活
这是文档里专门用大段篇幅警示的一个问题，值得完整讲一遍。
评估变式（Valuation Variant）中：
├─ 费用单（Costing Sheet）：已配置并激活
└─ Overhead 模板（通过 KTPF 分配）：也已配置并激活
两者均对同一作业类型定义了分摊规则：
→ 费用单计算一次 G 行
→ 模板分摊又计算一次 G 行
→ G 行出现重复
原理说白了就是：费用表和模板的作用是一样的，都是「把成本中心的费用摊到订单上」。如果模板已经算过了，费用表里再配一遍就是同一个费用被摊两次，成本直接翻倍。
解决办法
模板分摊场景下，费用表行不需要配置，只需要建一个空的费用表（KZS2里只填代码和名称）作为模板分摊的载体。文档里给的例子是 CS_TMPL「模板分摊费用表」——名字本身就说明了它的定位。
为了说明「正常费用表该长什么样」，文档里给了一个以 15% 物料间接费为例的完整结构：
行号 类型 代码 说明
10 BASE B001 物料消耗成本要素 400000~400999
20 Overhead OVH1 15%，OH Type=2（计划）
From=10, To=10 对第10行 BASE 计提
Credit Key=C001 贷记至 CC-PROD_OVHD/941000
30 Totals — 汇总第10~20行合计（可选）
它的执行逻辑是：读取生产订单中成本要素 400000~400999 的金额（BASE）→ 乘以 15%（Overhead Rate，OH Type=2）→ 借记生产订单间接费用，贷记成本中心 CC-PROD_OVHD / 科目 941000。看清楚这个贷方——它就是后面「成本中心余额」要清零的那个账户。
MECHANISM
CPTD 的分摊逻辑
这是模板分摊的核心机制，也是它和费用表最本质的差别。执行 CPTD时，系统对每个接收方对象（生产订单）执行这样一套流程：
通过搜索规则找到正确模板：系统根据接收方对象上的 Costing Sheet + Overhead Key 组合，动态确定用哪个模板。Overhead Key 可直接维护在成本对象上，也可从物料主数据的 Overhead Group 自动派生。
找到发送方：模板的 Object 列定义了发送方成本中心和作业类型。同一个成本中心/作业类型可以同时作为多个不同成品订单的发送方。
逐订单独立计算所需数量：系统针对每个生产订单，根据模板中的数量公式，独立计算该订单应消耗的作业数量。公式可读取该订单对应物料的主数据、BOM、工艺路线、确认数量等信息。
设定分摊期间并检查激活条件：确定分摊所属期间，检查模板行的激活条件（如仅对 FERT/HALB 激活）是否满足。
计算费用并过账：费用 = 该订单计算出的作业数量 × 成本中心作业计划价格，以二次成本要素过账：借记接收方（生产订单），贷记发送方（成本中心）。
「每个订单的分摊金额由该订单自身的驱动因子数量决定，而非按订单数量平均分摊或按某个比例分摊。这正是模板分摊相比费用表的核心价值所在。」
文档里还提到一个标准函数：ORDER_TARGET_PROCESS_QUANTITY，它基于当前标准成本计算每个订单的目标流程数量。配合 BomItemAlternativeQuantity等函数，公式的编写空间很大。
另外提醒一个实操细节：如果作业类型是按产量报工的，那么计划数量可以直接维护订单的计划产量（CK11N和订单 CPTA/D计算都取这里）；而实际数量选择「已完成计数业务」。这两处配错，模板分摊出来的数就会偏离预期。
CLOSING
期末关账顺序：颠倒一步全乱
这是全文我最想强调的一段。模板分摊的期末处理是严格分阶段的，六步顺序不可颠倒。因为每一步都依赖上一步的结果，跳一步或者换个顺序，成本中心余额就永远归不了零。
CO11N/CO15：生产订单确认，录入实际作业工时。此时系统使用计划单价记录直接作业费用。
CPTD（模板分摊）：按实际报工数量 × 计划单价分摊间接费用。成本中心可能出现正余额（欠吸收）或负余额（过吸收）。
KSS2（成本中心分摊结构计算，可选）：按分摊结构规则将成本中心费用分割至各作业类型，为 KSII 计算实际单价提供正确的分子分母数据。
KSII（实际作业价格计算）：实际费用 ÷ 实际总作业数量 = 实际单价，计算出单价差异（实际单价 - 计划单价）。
CON1/CON2（按实际价格重估）：单价差异 × 各订单实际数量 = 差异金额，将差异回冲至各生产订单，成本中心余额归零。
结果验证：生产订单最终承担 = 实际单价 × 实际数量；成本中心余额 = ¥0（完全吸收）。
为什么第 3 步是可选的
KSS2 是「成本中心分摊结构计算」，负责把成本中心的费用按分摊结构规则分割到各个作业类型。只有当成本中心下面挂了多个作业类型、需要先拆分再算单价时才必须做。作业类型单一的场景可以跳过。
把第 2 步和第 5 步连起来看，就明白模板分摊为什么要分两阶段了：CPTD 用的是「计划单价」，但最终该承担的其实是「实际单价」。两个单价之间的差额，就靠第 5 步的重估回冲。所以中间出现暂时的余额不平是正常的、阶段性的，不是错误。
EXAMPLE
完整算一遍：两个产品一个成本中心
光讲机制容易抽象，用文档给的这个例子走一遍，每一步数字都清清楚楚。
第一步：计划单价
计划单价由成本中心计划费用除以计划总作业数量得出：
计划单价 = 成本中心计划费用 ÷ 计划总作业数量
本例：计划单价 = ¥10/HR
反推计划费用：¥10/HR × 400 HR = ¥4,000
第二步：CK11N 标准成本估算
计划阶段用「计划单价 × 计划数量」算计划间接费用：
A 产品 = ¥10/HR × 100 HR = ¥1,000
B 产品 = ¥10/HR × 300 HR = ¥3,000
合计 = ¥4,000
第三步：CPTD（实际数量 × 计划单价）
期末执行时实际单价还没算出来，所以先用计划单价记账：
A 产品 = ¥10 × 150 HR = ¥1,500
B 产品 = ¥10 × 400 HR = ¥4,000
分摊合计 = ¥5,500
成本中心余额 = 实际发生费用 - 分摊金额
= ¥4,000 - ¥5,500
= -¥1,500（过吸收）
原因很直白：实际总报工 550 HR 大于计划总报工 400 HR，按计划单价摊出来的 ¥5,500 大于成本中心实际费用 ¥4,000，于是成本中心出现负余额。这个负余额不是错误，是「先按计划单价摊、实际单价还没算出来」的阶段性结果。
第四步：KSII 计算实际单价
实际单价 = ¥4,000 ÷ 550 HR = ¥7.27/HR
单价差异 = ¥7.27 - ¥10.00 = -¥2.73/HR
（实际单价低于计划单价）
第五步：CON1 按实际单价重估
重估差异 = 单价差异 × 该订单实际报工数量
A 产品 = -¥2.73 × 150 HR = -¥409.09
B 产品 = -¥2.73 × 400 HR = -¥1,090.91
合计 = -¥1,500 ✓ 恰好等于过吸收余额
第六步：最终结果
计划阶段（CK11N）
├ A 产品：¥10 × 100 HR = ¥1,000
└ B 产品：¥10 × 300 HR = ¥3,000
第一阶段：CPTD（实际数量 × 计划单价）
├ A 产品：¥10 × 150 HR = ¥1,500
├ B 产品：¥10 × 400 HR = ¥4,000
└ 成本中心余额：-¥1,500（过吸收）
KSII：计算实际单价
└ ¥4,000 ÷ 550 HR = ¥7.27/HR
单价差异 = -¥2.73/HR
第二阶段：CON1（差异回冲）
├ A 产品：-¥2.73 × 150 HR = -¥409.09
├ B 产品：-¥2.73 × 400 HR = -¥1,090.91
└ 成本中心余额：-¥1,500 + ¥1,500 = ¥0 ✓
最终结果
├ A 产品最终承担：¥1,090.91（= ¥7.27 × 150）
├ B 产品最终承担：¥2,909.09（= ¥7.27 × 400）
└ 成本中心余额：¥0（完全吸收）✓
「看这个例子就明白了：A 产品计划只要 100 小时却实际用了 150 小时，B 产品计划 300 实际用了 400。按计划单价摊，多的钱被摊超了；按实际单价重估，多摊的部分再冲回来。两次动作下来，成本中心的账和订单的账才对得上。」
PRACTICE
实操与排查
模板追踪：排查问题的第一工具
配置模板分摊最痛苦的时候，是模板明明配了，却没取到数据。这时候靠猜是没用的，得用 Template Trace。
测试执行 CPTA，点模板追踪，可以看到具体是什么原因导致模板没有取到数据。
执行 CK11N 后看成本明细，确认各作业类型的间接费用均已正确计入。
用 Template Trace 逐行检查每个模板行的数量计算结果是否符合预期。
检查发送方成本中心余额，确认费用已被完全吸收（Full Cost Absorption）。
CPTA 与 CPTD：单笔与批量
CPTA（单个处理）：按实际报工数量 × KP26 计划作业价格计算，测试单个订单时用。
CPTD（批量处理）：选工厂 + 期间，系统自动对所有相关生产订单执行模板分摊。比如选工厂 1000、期间 2026/10，自动把质检、仓储、工作排程等费用分别从各成本中心分摊出去。
执行后查 3611 报表和 CO 凭证，重估完成后订单和成本中心金额应该已经是实际成本。
还有一个实操提醒：测试时的数据量要够。文档里给的测试场景是订单收货 1000、报工 800——数量规模不同，模板里取的数量公式结果就不同，测试数据太小的会掩盖公式配置的问题。
常见问题速查
CK11N 出现两行 G（内部作业 G 间接费用）：费用表和模板同时激活、计算对象重叠。解法是清空费用表行，只留空表作载体。
模板取不到数据：用 Template Trace 查原因。常见是激活条件不满足、Overhead Key 没挂上、或者作业类型选错了类别（必须是类别 1）。
成本中心余额不为零：检查六步顺序是否颠倒，尤其是 KSII 和 CON1/CON2 有没有跑。
分摊金额与预期差很远：先确认计划数量取的是 KP26 维护的计划数量（不是报工数量），再看数量公式的「选择类型参数」是选 1 还是 2。
THE END
写在最后
模板分摊这个功能，在 SAP 里属于「知道的人不多、用了就停不下来」的那一类。多数人遇到 6 个作业类型加不进去，第一反应是「SAP 不支持」，然后妥协回固定比率的分摊——而固定比率在多品种、成本结构差异大的场景下，分摊结果往往离真实很远。
但它要付出的代价也不小：八个配置环节、一条不能颠倒的关账顺序、还有一个需要小心避开的重复计算坑。所以我的建议是——先确认业务上真的需要按数量分摊，再上模板。如果成本中心单一、作业类型固定、比例也很稳定，老老实实用费用表反而更省事。
工具没有高下之分，只有适不适合眼前这套业务。
这一篇是SAP 成本线的第二篇。上一篇讲的是物料账差异怎么产生和分摊，这一篇讲的是间接费用怎么摊到订单上——两篇正好串起成本核算的上下游。
如果你正在做 SAP 成本上线，或者正被「成本中心余额怎么都清不掉」困扰，欢迎在评论区聊聊——这类问题十有八九出在关账顺序和重复计算上，而这两件事文档里往往写得很轻描淡写。
知识星球
本文涉及的FS、TS与 ABAP原始代码，我已同步更新到自己的知识星球。如果你对实现细节感兴趣，或者手上正好有相关的环境需求，欢迎加入我的星球一起深聊。
星球内持续更新：财务共享 × SAP 接口的完整设计文档、ABAP 实现代码、可运行环境与踩坑记录。
现在关注我加入知识星球，更有上百份免费学习资料免费赠送，免费资料获得方式如下
星球链接：https://t.zsxq.com/zEfoi
— 微信扫码加入星球
精彩合集推荐
商务合作
商务合作洽谈、添加联系方式，以及各类广告合作，欢迎通过下方二维码与我直接联系。
同时承接：SAP 入职培训、集团财务人员培训、报表开发、需求实现与 SAP 项目实施
公众号：思AI普 ｜ 长期更新 SAP、财务共享与企业数字化领域的实战内容。
我是 David.Gao，专注财务共享与 SAP 集成落地。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
