SAP PS操作手册：新能源项目WBS分解到预转固的11个业务动作

简介《新能源项目-2017年6月SAP项目 SAP PS模块用户操作手册》面向新能源项目实施团队、SAP PS初学者及项目管理人员系统梳理Project System模块在项目规划、预算控制、资源分配与进度跟踪中的基础操作。手册以项目创建为主线覆盖手工创建项目定义、在项目定义下创建WBS元素、按项目类型复制标准网络及输入项目概况信息并配有系统菜单、交易代码、操作步骤、范例和结论便于对照系统界面逐步练习。压缩包仅含1个docx文件约6.01MB共67页目录清晰适合作为实施现场速查与新手培训材料。已有778人学习读者可从中了解项目结构搭建和标准网络复用的流程理解图标说明与注意事项提升SAP PS操作的规范性。1. 新能源项目上线前的真实需求2017 年 6 月一个新能源项目准备上线数字化系统财务、采购、工程三拨人围着一张 WBS 表争论了半天项目定义谁来建、预算谁来批、采购申请挂在哪个 WBS 上、成本最后怎么落到在建工程。争论的焦点是没有人能说清同一个项目被十一个人经手之后数据还能不能对得上。这份共 67 页的 SAP PS 模块用户操作手册就是给这个问题准备的答案把项目创建、预算、采购申请、结算、进度确认、状态管理、预警、预转固、报表查看这十一个动作按真实业务顺序拆成可照做的操作单元。它适合三类人要给甲方交付手册的 SAP 顾问、接手新能源项目财务与项目模块的从业者以及拿 ERP 项目管理做课程设计的学生。2. 手册结构拆解十一个业务动作怎么串成一条可复用主线一份操作手册最容易出问题的地方是把功能清单按系统菜单顺序排列。用户翻到第三页就迷路因为它回答的是「系统有什么」不是「我要干什么」。这份手册的结构反过来先按业务动作分章再在每个动作里给操作路径。2.1 从项目创建到报表查看的全链路地图十一个业务动作可以压成四段链路这条链路决定手册的章序阶段手册对应章节核心动作交付物计划段项目创建建项目定义、建 WBS、复制标准网络、维护逻辑关系、排程、下达一个状态为已下达、带日期和 WBS 结构的项目资源段项目预算建立、创建采购申请录预算、审核增加预算、提采购申请经批准的年度预算、挂到 WBS 的采购申请执行段项目进度确认、项目状态管理、项目进度调整、项目预警确认进度、改状态、调日期、写预警文本可追踪的实际进度与状态记录收尾段项目结算、预转固、项目报表查看维护结算规则、转在建工程、看汇总进度表结转到资产的项目成本、可对外的报表这条链路有一个隐含约束后一段能否做取决于前一段是否做干净。项目没下达采购申请发不出去WBS 没打记账标识成本根本记不进来结算规则没维护项目结算会直接报错。手册按链路排章读者按顺序读一遍就等于走了一遍完整项目周期。我在给类似项目写手册时会先把这张四段表贴在文档第一页之前作为阅读地图。它不占篇幅但能让第一次翻手册的人知道自己在哪一段。2.2 四段式操作单元范例、菜单与事务代码、步骤、结论手册里每个操作单元都固定四段这是整份文档最值得参考的部分范例说明这一步在什么场景下做、用什么数据做读者能对照自己的项目替换。系统菜单及交易代码菜单路径和事务代码同时给出老手直接用代码新手走菜单。操作步骤一步一步写每步对应一个界面字段。结论做完之后系统里应该看到什么怎么判断成功。为什么四段都要有因为手册的使用者不只一种人。项目关键用户需要范例来理解业务IT 支持需要事务代码来快速定位新入职的财务需要步骤来照做审计或验收方需要结论来核对。缺任何一段就有一类人用不了。这四段也天然形成验收单元。验收时逐条抽查范例是否对应当前业务场景、事务代码是否还能进得去、步骤截图和当前系统版本是否一致、结论描述的系统状态是否可验证。我一般会把这份检查做成脚本避免手工翻 67 页漏条目import re from pathlib import Path # 每个操作单元必须出现的四个固定小节名 REQUIRED [范例, 系统菜单及交易代码, 操作步骤, 结论] def split_units(text: str) - dict: 按 1.1.1 范例 这类三级编号标题切分操作单元 pattern re.compile(r^(\d(?:\.\d){2,})\s(.)$, re.MULTILINE) marks [(m.start(), m.group(1), m.group(2)) for m in pattern.finditer(text)] units {} for i, (pos, no, title) in enumerate(marks): end marks[i 1][0] if i 1 len(marks) else len(text) key ..join(no.split(.)[:2]) # 用二级编号归组如 1.1 units.setdefault(key, []).append(text[pos:end]) return units def check(path: str) - None: text Path(path).read_text(encodingutf-8) for unit_no, blocks in split_units(text).items(): joined \n.join(blocks) missing [name for name in REQUIRED if name not in joined] if missing: print(f单元 {unit_no} 缺少{、.join(missing)}) if __name__ __main__: check(ps_manual.txt) # 传入从 Word 导出的纯文本脚本做两件事用三级编号把文档切成操作单元再检查每个单元里四个固定小节名是否齐全。REQUIRED列表就是验收标准改成你们项目的段落名即可split_units里的no.split(.)[:2]控制归组层级如果手册只有两级编号改成[:1]。输出的是缺失清单不是分数——验收要的是能改的具体位置。提示从 Word 导出的纯文本常带全角空格和自动编号残留正则匹配不上时先做一次空格归一化再跑脚本。2.3 业务流程说明表跨 OA 与 SAP 的责任边界手册开头有一张业务流程说明表按活动编号列出活动名称、活动说明、责任岗位、责任部门、输入输出和涉及系统。这张表看着朴素实际是整份文档里最容易被低估的部分。从表里能读出两条边界。第一条是系统边界项目建立流程的申请在 OA 里提交审批意见也在 OA 里产生SAP 只负责创建项目本身。第二条是岗位边界项目创建、导入标准 WBS、修改 WBS、复制标准网络这几步责任岗位集中在分公司财务部输入是项目开发协议、项目编号、公司代码、工厂。把这两条边界写清楚能省掉大量扯皮。上线初期最常见的对话是「项目怎么还没建」答案往往卡在 OA 审批环节而不在 SAP 里。手册里把「项目建立流程申请」列为 01 号活动、涉及系统写 OA就是提前把责任划开。我在实际项目里会在这张表后面加一列「失败时找谁」填岗位而不是人名。手册是要活几年的文档人名会变岗位相对稳定。3. 项目创建与 WBS 分解项目定义、标准网络与甘特图排程项目创建这一段是整份手册的基础也是问题最集中的地方。项目定义建错后面预算、采购、结算全部要返工。我见过的返工案例里八成不是操作不熟而是建之前没想清楚编码和结构。3.1 手工创建项目定义手册把「手工创建项目定义」放在最前面用事务代码进入项目编辑器填入项目定义编号、描述、项目参数文件、公司代码、工厂、计划开始与结束日期。这几个字段里真正决定后续行为的是项目参数文件Project Profile它控制了编号范围、状态参数文件、组织数据和是否启用预算可用性控制。字段填写有几个硬规则写进手册比口头交代有效字段填写规则填错的后果项目定义编号按公司代码 年度 流水号拼编号重复导致创建失败或后续报表按公司代码统计时漏项项目参数文件按项目类型选择不混用状态流转规则不一致同一批项目出现两种状态口径公司代码 / 工厂与采购申请、资产卡片保持一致采购申请保存时报组织数据错误计划开始 / 结束日期覆盖整个项目周期含预转固排程后甘特图显示不全关键路径判断失真项目定义编号我一般不建议让用户手工敲。手工输入迟早出现重号、错位、大小写混用后面做报表统计要写一堆容错逻辑。更稳的做法是让系统按规则生成或者至少给一个校验函数放在手册附录里from datetime import date def build_project_code(company: str, year: int, seq: int) - str: 按 公司代码-年度-三位流水 的规则生成项目定义编号 if not (1 len(company) 4) or not company.isalnum(): raise ValueError(公司代码只能是 1-4 位字母数字) if not (2000 year 2099): raise ValueError(年度超出合理范围) if not (1 seq 999): raise ValueError(流水号必须在 1-999 之间) return f{company.upper()}-{year}-{seq:03d} # 示例某分公司 2024 年第 7 个项目 print(build_project_code(hf, 2024, 7)) # 输出 HF-2024-007这个函数只做三件事校验公司代码、校验年度和流水号范围、按固定格式拼接。seq:03d补足三位保证编号长度一致排序时不会出现 10 排在 9 前面的问题。手册里把这段放在「编号规则」小节用户创建前先调一次比事后查重省事。3.2 WBS 元素分解与标准网络复制项目定义只是外壳WBS 元素才是真正承载成本和进度的地方。手册在项目定义建完后紧接着讲在项目定义下创建 WBS 元素这个顺序不能颠倒。WBS 的层级通常控制在三层第一层是阶段或子项目第二层是工作包第三层是执行活动。层级不是越多越好超过四层之后成本归集和报表汇总的复杂度会明显上升而管理收益有限。关键是给每个需要记成本的 WBS 打上记账标识没打标识的 WBS 只能做结构节点不能挂采购申请、不能接成本。标准网络的复制是这一段里效率最高的动作。手册 1.2 讲「根据项目类型复制相应标准网络」业务含义是把一类项目的标准作业流程预先维护成模板新项目建好后直接复制作业、逻辑关系、资源一次性带过来。手册里区分了「项目公司成立前采购标准网络」和「项目公司成立后标准网络」两套模板对应项目不同阶段的采购行为。复制时有三个细节必须写进手册否则用户复制完会发现问题复制范围要明确是复制整个网络还是只复制作业是否连带关系。日期处理要说明模板里的日期是相对偏移还是固定日期复制后需要重排程。复制后要检查作业数量、逻辑关系条数、是否有孤立作业。我一般建议在手册里给一张复制前后的对照表列出「复制前模板值 / 复制后应有值 / 检查方法」比纯文字描述好核对。3.3 计划节点逻辑关系与时间排程手册 1.4 讲输入项目计划节点的工作时间和逻辑关系1.5 讲排程并展现计划甘特图。这两步是项目管理模块区别于普通财务模块的地方——它真的在算时间。逻辑关系常用四种完成-开始FS、开始-开始SS、完成-完成FF、开始-完成SF。实际项目里绝大多数是 FS配提前量和滞后量使用。提前量表示后道作业可以提前开始滞后量表示必须等待。这两个值是排程结果对不对的关键写手册时要明确单位天还是工作日和正负号含义。排程要依赖工厂日历。工厂日历没配节假日排出来的完成日期会把周末算成工作日甘特图看着正常实际交期差两三天。这类错误在验收时很难发现上线后才暴露。甘特图的作用不只是好看。它把关键路径显性化让项目经理知道哪几个作业动一天、整个项目就动一天。手册里把甘特图放在排程之后讲逻辑是对的先有排程结果才有图可看。3.4 项目下达从计划态到执行态手册 1.6 讲项目下达这一步是整条链路的分水岭。下达之前项目是计划态可以改结构、改日期、改预算下达之后WBS 才能接收成本、才能提采购申请。下达前要检查四件事项目参数文件是否正确、WBS 结构是否完整且记账标识齐全、计划日期是否覆盖全周期、预算是否已录入如果项目参数文件启用了预算检查没有预算就下达不了。系统状态一般走「创建 → 已下达 → 技术完成 → 关闭」这条线。技术完成表示业务上不再发生成本但财务结算可能还没做完关闭表示项目彻底结束。手册里要把这几个状态的含义和触发条件写清楚因为很多用户会把「技术完成」当成「关闭」用导致后续结算做不了。注意下达是不可逆操作。下达后发现 WBS 结构错了只能冲销或调整不能恢复成创建态。手册里这一步要加粗提醒并给出下达前的自查清单。4. 预算、采购与结算一条成本链条怎么闭环计划段解决「什么时候做什么」资源段解决「钱从哪来、花到哪去」。这一段是三段里跨部门最多的财务、采购、工程都要参与手册写得含糊就会出现预算批了但采购发不出去、采购发了但成本记不进来的情况。4.1 预算录入、审核与增加预算在 WBS 层级上按年度维护录入的是原始预算后续调整走预算增加。手册把「录入项目预算」和「预算审核及增加」分成两个操作单元对应两个不同岗位前者是预算编制后者是预算审批。原始预算和补充预算要区分清楚。原始预算是项目立项时批准的总盘子补充预算是因为范围变更、价格调整等原因追加的部分。两者在系统里可能走不同的交易代码报表上也要能分开看。混在一起录后面做预算执行率分析就没有基准。预算可用性控制是否启用在项目参数文件里设定。启用后采购申请、采购订单、发票校验、实际过账都会做预算检查超预算时按容差设置决定是警告还是报错。容差通常分三层警告、错误、绝对错误。这个分层设计很实用——小额超支给警告让人知道大额超支直接拦住。我在手册里会把容差规则单独列一张表写清「超过预算百分比 / 系统行为 / 需要谁审批」因为用户最常问的就是「为什么这笔能过那笔过不了」。4.2 采购申请创建与预算可用性检查手册第 3 章讲创建采购申请账户分配类别选项目然后填 WBS 元素。这一步看着简单实际是错误高发区。常见错误有三类。第一类是 WBS 填错层级填到了非记账元素上系统直接不让保存。第二类是预算不够采购申请保存时被预算检查拦住。第三类是组织数据不一致采购申请里的公司代码、工厂和项目定义里的对不上。第二类错误的排查路径要写进手册先看项目该年度有没有预算再看预算是否已释放如果启用了预算释放流程最后看这笔采购申请是否把预算吃超了。三步走完问题基本能定位。采购申请之后的链路是采购订单、收货、发票校验每一步都会产生实际成本并记到 WBS 上。手册可以不展开采购模块的细节但要在结论里写清楚「这一步做完在哪里能看到成本已经记到项目上」给一个查看实际成本的事务代码或报表路径。4.3 资产卡片、结算规则与成本转在建工程项目结算这一段是整份手册里技术含量最高的。业务目标是把项目归集的成本转成在建工程再预转固成固定资产。三个动作有严格先后先建资产卡片再维护结算规则最后执行结算。顺序错了就报错。资产卡片用资产主数据的事务代码创建资产类别选在建工程。卡片号要回填到结算规则里。结算规则维护在 WBS 元素上指定结算接收方。接收方类型可以是资产、成本中心、内部订单、总账科目。新能源项目最常见的是结算到在建工程资产。规则里还要设结算百分比和结算类型全额结算还是按比例结算直接影响转过去的金额。执行结算时系统把 WBS 上归集的实际成本按规则转出。结算前要做三件事检查该期间成本是否已全部过账、检查结算规则是否覆盖所有需要转出的 WBS、检查结算期间是否已打开。想核对结算规则和 WBS 的对应关系可以从系统标准表里取数做交叉检查。下面这段查询思路用于只读报表工具目的是找出「有成本但没有结算规则」的 WBS-- 找出本期有实际成本、但缺少结算规则的 WBS 元素 SELECT w.bukrs AS 公司代码, w.objnr AS 对象号, w.posid AS WBS元素, w.post1 AS WBS描述 FROM prps w WHERE w.pkokz X -- 只取打了记账标识的WBS AND EXISTS (SELECT 1 FROM cosp c WHERE c.objnr w.objnr AND c.wkg001 0) -- 本期有实际成本 AND NOT EXISTS (SELECT 1 FROM cobrb r WHERE r.objnr w.objnr) -- 没有结算规则 ORDER BY w.bukrs, w.posid;prps是 WBS 主数据表cosp存成本汇总cobrb存结算规则三张表通过对象号objnr关联。pkokz X过滤记账元素cosp.wkg001是本期实际成本列不等于零说明有发生额。输出结果就是结算前必须补规则的对象清单。字段名按你们系统版本核对一次再用不同版本的成本汇总表列名会有差异。预转固是结算之后的动作把在建工程余额转到固定资产。手册第 9 章单独列了「预转固」说明这一步在业务流程里有独立节点不是简单的资产类别变更涉及转固时点、转固金额和折旧起算。写手册时要把触发条件写清楚项目达到预定可使用状态验收手续完成才能转固。5. 运行期维护与常见问题排查进度确认、状态管理与五个翻车点项目下达、预算到位、采购发出之后手册进入运行期。这一段的内容看起来零散实际都在回答同一个问题项目执行过程中系统里的数据怎么跟现场保持一致。5.1 进度确认与项目文档挂接进度确认是把现场完成情况写回系统的动作。手册第 5 章讲确认进度操作上是在网络作业上确认实际开始日期、实际完成日期、完成百分比和实际工时。确认之后项目进度报表和甘特图才会反映真实情况。确认有两个容易混淆的概念里程碑确认和作业确认。里程碑确认只标记某个节点达成不涉及工时作业确认会带回工时影响成本和资源分析。手册里要写清楚哪类作业用哪种确认方式。文档挂接是把合同、验收单、图纸这类文件关联到项目对象上。操作上先建文档信息记录再在项目里挂对象链接。挂接的价值在于审计和验收时能一键调出原始凭证不用翻共享盘。文档挂接要注意两点文档类型要选对否则挂上去查不到链接建立后不要随意移动源文件链接会断。5.2 状态管理、进度调整与预警文本状态管理分系统状态和用户状态。系统状态由操作自动触发比如下达、技术完成、关闭用户状态是业务自定义的比如「待财务复核」「待工程确认」。用户状态通过状态参数文件定义可以控制某些操作在特定状态下是否允许。这个机制很实用但配置不好会出事。如果用户状态设成「锁定」却没有对应的解锁权限分配项目会卡在一个谁都动不了的状态。手册里要写明每个用户状态的允许操作和解除条件。进度调整是修改活动日期。项目延期是常态改日期本身不难难的是改完之后要重排程让后续作业日期跟着动。只改一个作业不重排甘特图就跟实际脱节了。预警用 PS 文本实现在项目上创建文本记录风险事项配合报表做红黄绿灯。文本本身不触发系统动作价值在于把口头预警变成可追溯的记录。写法上建议固定格式预警事项、影响范围、责任人岗位、计划关闭日期。格式统一后面汇总才有意义。5.3 五个最容易翻车的点第一WBS 没打记账标识成本记不进来。现象是采购申请保存时报账户分配错误或者发票校验时提示 WBS 无效。原因是建 WBS 时只当结构节点用没勾记账标识。解决方法是回到 WBS 主数据补标识但要注意已经有业务数据的 WBS 改标识可能受限通常的做法是新建一个正确的 WBS把业务迁移过去。第二项目没下达就发采购申请。现象是采购申请能填完但保存失败。原因是 WBS 还处于计划态不接受承诺。解决方法是先执行项目下达再做采购申请。血泪经验是这一步在培训时一定要现场演示一遍失败的样子用户记住报错比记住规则快。第三跨年项目只做了第一年预算。现象是第二年一开年所有采购申请全被预算检查拦住。原因是预算按年度维护新的一年没有预算额度。解决方法是在年度切换前做一次预算滚动把下一年度预算录进去。这件事要写进手册的年度例行操作清单不能靠人记。第四结算规则没维护就执行结算。现象是结算运行后报错或者成本留在项目上没转出去。原因是有成本的 WBS 缺少结算规则。解决方法是结算前先跑一次规则完整性检查把缺规则的 WBS 补齐。上面那段查询就是干这个的。第五复制标准网络时把模板日期一起带过来。现象是新项目的作业日期全是很久以前的日期甘特图排出来是负工期。原因是复制时选择了带日期复制。解决方法是复制后立即执行一次排程用项目计划日期重算所有作业。这类问题很玄学第一次遇到会查很久写进手册就一句话的事。6. 验收与答辩用一条完整数据链证明手册能落地手册类交付物的验收最怕变成「页数对不对、格式好不好看」。我带过的项目里比较有效的验收方式是让使用方现场走一遍完整数据链从建项目定义开始到建 WBS、下达、录预算、提采购申请、确认进度、维护结算规则、执行结算最后打开报表看汇总。走通了手册就是能用的走不通卡在哪一步就改哪一段。验收清单可以按下面这张表逐项打勾每项都要有可观察的结果不接受「应该没问题」验收项通过标准检查方式章序与业务链路一致十一个动作能按顺序串起来按章序现场走一遍每个操作单元四段齐全范例、菜单与事务代码、步骤、结论都在用脚本跑一遍缺失清单事务代码可进入手册里的事务代码在当前系统能打开对应界面随机抽 10 个验证关键字段有填写规则项目定义、WBS、预算、结算规则四类字段有规则表对照字段表核对结论可验证每步做完能指出在哪个界面看到什么状态现场操作确认异常场景有指引至少覆盖预算不足、未下达、缺结算规则三类报错制造一次报错复现答辩场景下演示策略比内容多少更重要。三个技巧一是只演示一条链路不要贪多从建项目到看报表一条走完比展示十个功能点有说服力二是提前准备好一个「故意失败」的场景比如在未下达的项目上提采购申请让评委看到你理解系统约束三是报表放在最后打开用数据证明前面所有操作真的产生了结果。我吃过一次亏早年交付一份手册验收时被问「预算超了会怎样」我答不上来具体是警告还是报错因为写的时候只照着成功路径写没跑过异常分支。从那以后我每次写操作手册都强制走一遍「故意做错」的流程把报错信息和处理办法一并写进结论段。这个习惯后来救过好几次场用户遇到问题时翻手册能自己解决比打电话问快得多。希望这套结构能帮到你把手上那份手册从功能清单变成真正能交付的方案。本文还有配套的精品资源点击获取