简介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_YYYYYYYY 就是年份。比如今年年初跑完变式名就是 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 归档变式与作业参数一个保命习惯最后说个保命习惯每年复制完成后把变式参数和后台作业定义导出一份存档。某年我偷懒没归档年中有人调整过变式里的覆盖模式第二年年初直接沿用批量跑完才发现网络活动全重复了最后花了两天清理。从那以后每年的变式参数、作业步骤、执行日志我都会存成一份文档放进运维档案来年只改年份字段。归档的成本五分钟翻车的代价可能是几天。这套打法已经连续跑了好几个年初希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?