简介：SAP系统未内置项目计划数据年结功能，年度切换时需借助CJ9B事务代码完成数据结转。这份用户操作手册以版本1.0为基础，系统梳理了财务部在完成全部年结后，通过CJ9B将版本1-12的计划数据批量复制到目标版本0的完整流程，并明确了启动条件和菜单路径。资源包共含1个doc文件，大小142KB，轻量易用，适合企业财务人员、SAP关键用户、IT支持及ERP实施顾问快速查阅。目前已有65人学习。手册不仅列出触发条件、必要条件、字段规范（版本必须为1-12、目标版本必须为0、目标期间与模板期间一致、会计年度需为新打开年度），还提供操作示例与结果说明，帮助规避版本或期间配置错误。按步骤执行即可高效完成项目计划数据年度结转，保障财务新年度数据的准确启动。
1. 每年年初的“项目计划复制”为什么必须做成批量作业
每年一月初，几乎所有用 ERP 管项目的企业都会面对同一件事：把上一年度的项目计划数据搬到新年度。几十个项目，每个项目底下挂着 WBS、网络活动、里程碑和计划工时，如果靠人一条条复制，从元旦复制到春节也复制不完，而且每个人复制出来的编号规则、日期口径、工时结构都不一样，计划一汇总就乱。CJ9B 就是用来干掉这个重复劳动的批量功能代码——它把上一年度的整套项目计划结构原样复制到新年度项目里，再让日期按年度差自动顺延。这篇笔记把 CJ9B 的数据范围、选择屏幕参数、变式固化、年初自动调度和常见翻车点一次说清，适合给 ERP 项目模块做运维的 IT 支持，以及每年都要被计划复制折磨一遍的项目计划员。
2. CJ9B复制的到底是什么：数据范围与底层逻辑
要理解 CJ9B，先得搞清楚“项目计划数据”在 ERP 里到底指哪些东西。很多第一次接触这个功能的人以为它就是“把项目复制一份”，结果跑完发现目标项目里缺了网络关系、多了审批状态，这些问题都出在没搞清复制边界。我处理过几次年初复制事故，最后发现九成问题不是 CJ9B 跑不起来，而是没搞明白它复制的数据范围和哪些东西必须重建。
2.1 CJ9B复制的三类核心数据：WBS结构、网络活动与里程碑
第一类数据是 WBS 结构。WBS 是项目分解结构，是整套计划的骨架，通常以“项目-阶段-工作包”这样的层级编码呈现，比如 1000-10-10 代表某个工作包。CJ9B 复制时按源项目的层级关系，在目标项目下批量重建成相同的层级树。关键点在于：WBS 编号可以沿用源项目的编号体系，也可以通过编号范围重映射成新年度的编码，取决于系统里有没有配置新的年度编号范围。我一般建议沿用上一年的编号，这样源项目和目标项目对比起来最直观，后续校验也方便。
第二类数据是网络活动。网络活动是 WBS 下面真正“干活”的节点，包含工序描述、计划工时、资源用量，以及活动之间的依赖关系。复制网络活动最怕的是只复制了活动本身、没复制内部关系——比如“A 完成后 B 才开始”这种完成-开始关系一旦丢失，新年度项目的网络就变成一堆互不相干的散点，进度排程直接失效。CJ9B 的标准做法是整个网络连同关系链一起复制，前提是你在选择屏幕里勾选了网络复制范围，而不是只复制 WBS。
第三类数据是里程碑。里程碑一般挂接在 WBS 或网络活动上，代表项目里必须盯住的控制点，比如“设计评审完成”“设备到场”。复制后里程碑本身不会变，但日期会按你给的年度偏移量自动顺延。这一块最容易被忽略：很多人复制完一看 WBS 和网络都对，唯独里程碑日期还是去年，就以为 CJ9B 有 bug，其实只是日期偏移参数没设置。下面这个表总结了复制行为：
| 数据对象 | 复制行为 | 复制后要处理的点 | | WBS结构 | 按源层级批量重建 | 确认目标编号范围是否匹配 | | 网络活动 | 活动加内部关系链一起复制 | 检查漏复制的关系 | | 里程碑 | 结构复制、日期顺延 | 核对日期偏移量 | | 计划工时 | 随网络活动复制 | 确认工时口径与去年一致 |
CJ9B 能批量处理几十个项目，靠的是选择屏幕支持多项目范围。你可以输入单个源项目，也可以输入一整个项目区间，系统会逐个项目读取计划数据、在对应的目标项目下重建结构。这个多项目驱动的模式，正是每年年初一次作业跑完全部项目的基础。
2.2 批量复制与手工复制的边界：这些数据必须重建
用了 CJ9B 不等于把项目“克隆”了一份。复制是结构性的，很多字段状态必须在新年度里重新走流程。先说哪些必须复制：WBS 骨架、网络活动、内部关系、文本说明、计划工时和原计划成本版本。这些是计划的“白纸”，复制过来继续在上面做新年度的推演。
再看必须重建的：审批状态、预算锁定标志、实际发生的数据、跨年度的资源可用性。这里最坑的是审批状态。某次年初复制，A 同学直接用默认参数跑完，结果新年度项目批量带出了“已批准”状态，预算被锁死，计划员改什么都没权限。查了半天才发现，CJ9B 复制时把源项目里的审批状态字段也带了过去——它不会因为你换了年度就自动重置审批链。后来我们的做法是，要么在复制参数里显式排除审批状态字段，要么复制完成后跑一次批量状态重置。这块属于血泪经验，下面第 4 章我会专门讲。
还有实际数据。源项目上一年度可能已经发生了实际工时、实际成本、采购订单，这些绝对不能复制到新年度计划里。标准 CJ9B 复制流程里，实际值默认不会进入目标计划，但如果复制范围勾选太宽，把“带实际值的字段”也圈进去，就会出问题。我的习惯是每次复制前都看一眼范围参数：计划值带过去，实际值一律归零。
2.3 复制前的检查清单：目标项目与计划参数文件
CJ9B 复制的是“计划结构”，不是“创建项目”。目标项目的项目头必须已经存在。也就是说，跑 CJ9B 之前，要确认新年度项目在系统里已经创建好——哪怕只是一个只有项目编号的空壳。这一步往往不在 CJ9B 里做，而是项目批量创建的准备工作。
我一般会在每年年初复制前，把下面这张检查清单过一遍：
| 检查项 | 检查方法 | 漏掉会怎样 | | 源项目是否有未结算对象 | 查看项目结算状态 | 复制时带出脏数据 | | 目标项目头是否存在 | 按项目编号查询 | CJ9B批量报错 | | 年度编号范围是否配置 | 检查编号范围配置 | WBS编号冲突 | | 计划参数文件是否一致 | 对比源/目标参数文件 | 计划值字段漏复制 | | 变式参数是否沿用去年 | 打开变式查看 | 日期偏移口径错误 |
最后说计划参数文件。这东西决定了复制哪些计划值字段。不同计划参数文件对应的字段集不同，如果你的源项目用的是“严格工时控制”模板，目标项目却挂的是“简单里程碑”模板，CJ9B 跑完很多字段根本不会带过去。所以复制前务必确认源项目和目标项目挂在同一个计划参数文件下，或者至少确认字段集兼容。这个检查只要一次，但做错了一年都别扭。
3. 用CJ9B批量复制项目计划数据：选择屏幕参数与变式固化
这一章讲的就是跑 CJ9B 的具体操作。很多运维拿到这个功能代码，第一反应是“在哪儿输项目号”，但真正把它用顺的人都知道：跑 CJ9B 只是第一步，把这套运行参数固化下来、让每年年初都能用同一套口径跑完所有项目，才是这件事的核心。我先从前台单项目验证讲起，再讲批量选择和变式固化。
3.1 运行CJ9B的第一步：用单项目在前台跑通整套参数
不管你要批量复制多少个项目，我建议第一次永远用单个项目在前台跑。前台跑的好处是能直接看到日志、出错能立刻查，不必在后台作业里翻半天。具体流程：先在 ERP 系统的功能入口输入 CJ9B，进入选择屏幕。填上源项目和目标项目，复制范围先选“WBS+网络”，日期偏移按年度差设置成 1 年，覆盖模式选“覆盖已存在数据”，然后勾选“测试模式”执行。
* 这是选择屏幕参数快照，用于验证复制口径 源项目: MOCK-2024-100 目标项目: MOCK-2025-100 复制范围: WBS + 网络 + 里程碑 日期偏移: 按年度差自动顺延 (365天) 覆盖模式: 覆盖已存在数据 测试模式: 勾选 执行方式: 前台运行这段是参数记录时常用的写法——把选择屏幕的关键值抄成键值对，后续核对参数、写运维文档都很方便。填完执行后，系统会先产生一份模拟复制的结果清单，告诉你“将要复制多少个 WBS、多少条网络活动、多少个里程碑”。这一步就是参数验证：看清单里的数量和源项目预期一致，再退出测试模式、正式执行。
关键参数说明就几个：
| 参数 | 推荐值 | 说明 | | 复制范围 | WBS+网络+里程碑 | 只选WBS会丢掉网络关系 | | 日期偏移 | 按年度差顺延 | 不设则日期保留原值 | | 覆盖模式 | 覆盖已存在数据 | 追加模式会重复跑出两份数据 | | 测试模式 | 首次执行勾选 | 生成预执行清单，不落库 |
这里要特别提醒覆盖模式。CJ9B 的覆盖模式通常分几种：一种是“追加”，目标项目已有数据时再插入一份，结果就是重复；一种是“覆盖”，用源项目的数据覆盖目标项目里已存在的 WBS 或网络；“补充”则只填目标项目里空缺的字段。每年年初的目标项目应该是空白的，所以“覆盖”最安全——就算跑重复了，再跑一次也会用源数据把目标覆盖回正确状态，数据不会翻倍。
提示：年初的年度复制请优先使用“覆盖”模式。追加模式适合账号权限类复制，用在项目计划上几乎必然翻车。
3.2 用变式把参数固化：让每年年初运行不靠人肉记忆
参数验证通过之后，下一步就是把这套参数存成变式。变式是 ERP 里很常见的机制：把选择屏幕里填好的所有值保存为一个命名参数快照，下次调用同一个功能时，直接输入变式名，所有参数自动带出来。对于 CJ9B 这种每年只跑一次、但一次要跑几十个项目的操作，变式是最重要的省时间工具。
保存变式的方法很简单：在 CJ9B 选择屏幕上填好参数，不急着执行，先找到“保存为变式”的入口，给变式取一个能看懂的名字。我的命名习惯是 Y_CJ9B_OPEN_YYYY，YYYY 就是年份。比如今年年初跑完，变式名就是 Y_CJ9B_OPEN_2025，明年年初复制之前，把变式复制一份改成 Y_CJ9B_OPEN_2026，只改一个年度差异点。
变式命名示例： Y_CJ9B_OPEN_2025 = 2025年初复制参数（2024→2025） Y_CJ9B_OPEN_2026 = 2026年初复制参数（2025→2026）变式里有个很重要的字段叫“变式属性”：你可以设置哪些参数在运行时会再次提示输入，哪些被锁定。我建议把源项目和目标项目设为“可输入”，因为每年要复制的项目范围会变；把日期偏移、覆盖模式这类不常改的设成“不可输入”。这样做的好处是，年初跑的时候，计划员打开变式只需要确认项目范围，其他参数全部沿用，又省事又不容易改错。
3.3 复制结果的检查：日志、差异对比与重跑策略
CJ9B 批量跑完后，第一件事不是急着看数据，而是看日志。前台运行的话，日志会直接显示在屏幕上，列出每个源项目的复制结果：成功多少条、警告多少条、失败多少条。后台运行的话，日志会进到作业日志里，输入作业名就能翻出来。这个日志是唯一的“过程证据”，我每年都会把日志导出一份存档，万一后续发现数据不对，能反查是哪一批复制出了问题。
日志里看到警告不必紧张——复制 WBS 时如果目标 WBS 已经存在，警告只是提示“已存在”，不一定是错误。但看到失败就必须处理。最常见的失败原因是目标项目编号不存在，或者源项目里存在不允许复制的对象状态。处理方式是把失败的项目挑出来，修好前置条件后单独重跑，不要让整个批量重来。
结构复制完，还要做一次数据量对比。我的做法是用一条简单的查询，分别统计源项目和目标项目的 WBS 数量、网络活动数量、里程碑数量，然后做差。数量能对上，说明结构复制完整；数量对不上，哪怕只差一条，也要翻日志：
-- 对比源项目与新年度项目的WBS数量 SELECT '源项目' AS 口径, COUNT(*) AS WBS数量 FROM prps WHERE pspid LIKE 'MOCK-2024-100%' UNION ALL SELECT '目标项目' AS 口径, COUNT(*) AS WBS数量 FROM prps WHERE pspid LIKE 'MOCK-2025-100%';这段 SQL 的字段名是按常见 ERP 后台表写的，不同系统表名会有差异，但思路通用——找到对应的项目结构表，把表名和编号规则换成实际的就行。数量一致后再看总计划工时，工时的对比能暴露“WBS 复制了但网络活动缺失”这类结构看不出来的问题。
4. CJ9B批量复制避坑指南：5个年初必踩的坑
CJ9B 本身很稳定，真正让年初复制翻车的，往往是参数、前置准备和运行习惯。这几年我处理过的问题翻来覆去就那么几个，写在这里就当给后来人探路。每一条都按“现象→原因→解决”来写，遇到类似情况直接照方抓药。
4.1 目标项目还没建好，批量提交后部分项目直接失败
现象：批量提交后日志里一半项目失败，报错提示目标项目不存在，但源项目明明都在。这种情况通常发生在每年年初第一次跑 CJ9B 时，也是最容易忽略的前置准备问题。
原因：CJ9B 复制的是计划结构，它不会自动创建目标项目头。新年度项目如果只记录在表格里、没有在系统里正式创建，批量程序在目标端找不到落点，只能把对应项目标成失败。而且失败不是整批失败，是单个项目失败，所以日志前半段成功、后半段失败的情况特别多。
解决：跑 CJ9B 之前先做一次目标项目头检查，确认所有新年度项目都已创建。不需要往项目头里填任何计划数据，只要保证系统里有这条项目记录，并且 WBS 编号范围已经匹配就行。预检查这步可以交给批量作业，见第 5 章。
4.2 复制后里程碑日期全部停在去年
现象：WBS 和网络活动都复制成功，里程碑数量也对，但日期还是上一年度的，新年度计划完全没法用。计划员一看里程碑日期全是去年，第一反应就是 CJ9B 有 bug。
原因：没设置日期偏移参数，或者偏移量设成了自然日而不是按年度差。CJ9B 默认可能不改变日期，必须显式告诉它“新年度比上年度晚一年”。日期偏移这个参数在变式里如果不显眼，很容易沿用去年的旧值，导致今年跑出来日期还是去年的。
解决：在选择屏幕的日期偏移参数里，把顺延方式设为“按年度差自动顺延”，偏移量按实际年度差填。改完参数后重新跑一遍覆盖模式，日期就会整体推到新年度。这个坑最隐蔽，也最好修。
4.3 同一批数据重跑两次，网络活动翻倍
现象：年初第一次跑完正常，因为某些原因重跑了一遍，结果网络活动和计划工时数量翻倍，WBS 却还是那么多。查日志看不出明显报错，因为程序告诉你“复制成功”。
原因：重跑时复制范围里的追加模式没有关掉。追加模式会在目标项目已有数据的情况下再插入一份网络活动，造成“结构不翻倍、作业翻倍”的怪象。
解决：重跑前把覆盖模式换成“覆盖已存在数据”。如果已经翻倍，先把目标项目里复制过来的网络活动全部清理掉，再以覆盖模式重跑一次。千万别在已经重复的数据上继续追加，那会把问题滚成雪球。
4.4 新年度项目批量带出“已批准”状态，预算锁死
现象：复制完成后，新年度项目全部处于“已批准”状态，计划员想调整预算、修改计划工时都没权限，运维这边还要一个个排查是谁批准的。
原因：默认复制范围包含审批状态字段，源项目上一年度已经走完的审批状态被原样搬到了新项目上。CJ9B 不会自动区分“这是去年的审批”和“这是今年的审批”，它只认字段。
解决：在 CJ9B 的复制参数里，把审批状态相关字段排除在复制范围外。如果已经复制完，批量重置这些项目的审批状态，重新从“编制中”开始走新年度的审批流。这个坑最伤预算，年初务必先确认状态字段不在复制范围内。
4.5 后台日志显示成功，但计划工时少了一截
现象：后台作业跑完显示全部成功，但后续校验发现部分项目计划工时明显少了，甚至为零。如果只信日志，这个问题可能拖到编制预算时才暴露。
原因：后台批量模式下，系统把很多项目合并成一个日志条目，成功只是“整体执行完成”，某个项目因参数文件不一致导致计划值字段没复制，并不会让整体日志报错。这是黑匣子效应：日志只告诉你程序跑完了，不告诉你每个字段都带过去了。
解决：做数据量对比时，不光对比 WBS 和网络数量，还要对比总计划工时。发现异常后，把该项目单独在前台重跑，看具体复制了哪些字段。批量执行时按“每项目一条日志”的方式运行，让日志更啰嗦一点，换数据完整。
5. 把年初复制做成无人值守：后台调度与数据校验
5.1 用后台作业把CJ9B固定在每年年初自动执行
参数用变式固化之后，CJ9B 就可以交给后台作业了。我的做法是每年年底把变式复制一份、改成新年度的项目范围，然后建一个后台作业，定在 1 月 2 日凌晨执行。作业分三步：第一步先跑预检查报表，确认所有目标项目头存在；第二步调用 CJ9B，读取 Y_CJ9B_OPEN_YYYY 变式执行批量复制；第三步跑一致性校验脚本。三步串成作业链，任何一步异常都自动停止，避免出错之后继续覆盖数据。这样元旦上来，计划员看到的已经是复制好的新年度计划结构，省掉一整天的等待时间。
5.2 复制后的一致性校验脚本
作业跑完，我还会跑一遍校验 SQL。除了数量对比，重点看总计划工时和里程碑数量，这两项最能暴露“结构完整但字段缺失”的问题。偏差超过 0.1% 就要翻日志，找出是哪个项目造成的。这个校验脚本我会一直留在运维文档里，每年只用改年度参数。
-- 校验目标项目的WBS数量与计划工时总量 SELECT SUBSTRING(pspid, 1, 12) AS 年度项目, COUNT(DISTINCT posid) AS WBS数量, SUM(plgxx) AS 计划工时总量 FROM prps WHERE pspid LIKE 'MOCK-2025%' GROUP BY SUBSTRING(pspid, 1, 12);这里 plgxx 是计划工时字段的占位写法，实际字段名以系统的数据字典为准。重点是分组口径：按年度项目前缀分组，每条记录对应一个项目的 WBS 总数和工时总量，源项目和目标项目各跑一遍后对比，数量一致就算通过。
5.3 归档变式与作业参数：一个保命习惯
最后说个保命习惯：每年复制完成后，把变式参数和后台作业定义导出一份存档。某年我偷懒没归档，年中有人调整过变式里的覆盖模式，第二年年初直接沿用，批量跑完才发现网络活动全重复了，最后花了两天清理。从那以后，每年的变式参数、作业步骤、执行日志我都会存成一份文档放进运维档案，来年只改年份字段。归档的成本五分钟，翻车的代价可能是几天。这套打法已经连续跑了好几个年初，希望帮到你。
本文还有配套的精品资源，点击获取
