企业官网建设流程全解析

简介：这份 SAP PS 模块详细配置手册面向 ERP 实施顾问、项目系统管理员以及正在推进 SAP 项目上线的企业内部团队，聚焦项目从计划、执行到控制与结算全过程的系统配置实施，适合已具备一定 SAP 基础、需要按步骤完成定制化设置的中级读者参考。压缩包内共 1 个 PDF 文件，约 1.17MB，为 OCR 扫描整理的中文配置文档，按硬件环境与文档更改记录、企业结构、PS 模块三大板块编排，各章节标注事务代码，便于对照系统逐项操作。内容覆盖控制区域激活项目管理（OKKP）、项目编码掩码与项目类型定义（OPSJ）、WBS 优先级及项目参数文件创建（OPSA）、WBS 责任人指定与字段选择、用户自定义字段（OPS1），并延伸到网络类型、控制码与网络参数文件等执行层配置，以及同财务模块集成时的成本、预算控制与计划值计算要点。已有 155 人学习下载。读者可据此梳理配置顺序与依赖关系，理解关键参数含义，并形成可复用的实施检查清单与后期维护、审计依据。

1. 一份 OCR 过的 PS 配置手册，真正的价值在目录里

拿到 SAP PS 模块配置手册的人，第一反应往往是直接搜「OPSA 在哪一页」，然后照着截图一步步点。真正的坑不在某一个事务码，而在顺序：OKKP 里那个项目管理开关没打开，后面 OPSJ、OPSA 配得再漂亮，建项目时照样报错；企业结构里的控制范围货币设错，整套 Cost Management 的成本流到财务那边就是一笔糊涂账。这份手册把从企业结构到 WBS、网络、里程碑、成本、预算、结算的完整链条按顺序摊开，覆盖 ERP 实施中最容易返工的那几段配置。它适合正在做 Project Management 落地的顾问，也适合接手别人配到一半系统的运维——尤其是那种「项目能建、预算能下、结算跑不出来」的半成品现场。

2. 企业结构与 OKKP：把地基打平再谈项目

PS 的配置有一种很典型的现象：单看每一步都没问题，串起来跑不通。原因多半出在最前面那几步——企业结构和控制范围。这两块配完基本就固定在系统里了，后面所有项目定义、WBS、网络的成本归集路径都从它们身上长出来，改一次的代价远大于一开始多花半小时确认。

2.1 控制范围上的那个勾：OKKP 为什么不能后补

SAP 里项目定义和 WBS 元素本质上是 CO 的承接对象，成本、承诺、预算全部挂在控制范围这个维度下。OKKP 里激活项目管理的动作，做的就是告诉系统「这个控制范围要承载 PS 对象」。没激活之前，你在 CJ20N 里能进界面，但一保存就掉进一个很典型的报错循环：项目参数文件找不到可用的成本控制范围，或者干脆提示该控制范围未启用项目管理组件。

常见做法是先确认控制范围本身是不是已经跑着别的模块。一个已经上线 CO-PC 或者 CO-OM 的控制范围，激活 PS 组件通常没问题，但要留意货币和跨公司代码成本核算这两个设置——它们决定项目成本能不能跨公司代码归集。如果这家企业是多公司代码共用一套项目定义，跨公司代码成本核算必须打开，否则结算时提示找不到对应对账对象。

激活之后不要急着一路往下走，先在 OKKP 里把当前控制范围的状态看一遍，确认组件标识、货币、会计年度变式三者一致。我一般会顺手在 TKA01 里再核一次控制范围主数据，避免有人同时在另一个客户端改了配置——多客户端并行实施时，这类玄学问题出现的频率比想象中高。

提示：控制范围激活 PS 后不要指望能无痛回退。已有项目数据的情况下关闭组件，几乎必然要清理 CO 对象，这一步没有后悔药。

2.2 公司代码、控制范围、业务范围的三层对齐

企业结构这块，手册里通常只给一张图，图上画着公司代码、控制范围、业务范围三个圈。实际配置时真正要盯住的是它们和项目之间的取值关系：项目定义上的公司代码决定采购和发票走向，控制范围决定成本归集，业务范围（或利润中心）决定报表口径。三层之间有一个对不上，最后做项目利润分析时数字就是散的。

我倾向的做法是先把这三个维度在一张纸上画成矩阵，标清楚每个项目类型对应哪个公司代码、哪个控制范围，再动手配。手册里 2.1 节的那张 enterprise structure graphics 图看着简单，真要落到几十个项目类型上，没有这张矩阵表很容易漏。

这里还有一个容易被忽略的点：项目参数文件里可以预设公司代码，但项目定义创建时允许覆盖。如果企业的实施策略是「项目定义必须跟随销售订单的公司代码」，就不能只在参数文件里设死，还得配校验或者字段选择把公司代码锁成显示状态。这条在手册的字段选择章节里没有展开，但在实际项目里踩过的人不少。

2.3 编码掩码 OPSJ：三秒钟定下的规则会跟三年

OPSJ 定义项目编号的编辑掩码，形式上就是长度 + 分隔符 + 特殊字符的组合。这一步在手册里只占半页，但它是整套 PS 配置里最不该拍脑袋的一步。项目编号一旦开始使用，改掩码意味着存量项目的编号规则和新建项目对不上，历史数据的检索、报表的筛选条件全部受影响。

一个常见的掩码设计是「两位年份 + 两位公司代码简码 + 四位流水」，这样编号自带时间信息，做年度分析的时候直接按前缀筛。代价是同年流水超过 9999 就得扩位，所以位数要按企业未来三到五年的项目量估，而不是按现在。

掩码配完要做一次真实创建测试，别只在 OPSJ 里看预览。用 CJ20N 建一个测试项目，编号按掩码规则手工输入一遍，确认系统接受；再故意输一个不符合规则的编号，确认系统拒绝。这两步都过了，掩码才算真正生效。手册里 3.2.1 节只写了「定义项目编码掩码」，没写验证方法，而这一步恰恰是后面 WBS 编号能不能自动带出来的前提。

2.4 项目参数文件 OPSA：把下游配置一次性挂上去

项目参数文件是 PS 配置的总枢纽，它把计划参数文件、预算参数文件、结算参数文件、日期参数文件、网络参数文件、编码掩码全部串在一条链上。手册 3.2.4 节把 OPSA 单列出来是合理的——这里配漏一个字段，下游对应的功能就是整块不可用。

配 OPSA 时的顺序建议是：先选编码掩码，再挂计划参数文件，然后预算参数文件，最后结算参数文件。原因在于结算参数文件依赖前面的成本要素和分配结构，属于链条末端。反过来配的话，往往要回到 OPSA 改好几次。

几个必须一次定死的字段：项目定义的编号范围、WBS 的编号范围、计划参数文件、预算参数文件、结算参数文件、日期参数文件、网络参数文件。还有两个容易被跳过但影响很大的：项目定义的字段选择键和 WBS 的字段选择键，它们决定哪些字段在项目创建时必输。

实际项目里我见过一种情况：参数文件建了两套，一套给内部项目、一套给客户项目，结果项目定义创建时选错了参数文件，导致预算控制逻辑完全没生效。防这种错的办法是把参数文件命名做成可辨识的规则，比如加前缀区分业务线，而不是用 Z001、Z002 这种编号。

2.5 字段选择 OPUJ/OPUK 与用户字段 OPS1

字段选择分两级：项目定义一级（OPUJ）、WBS 一级（OPUK）。每一级都可以把字段设成必输、可选、隐藏、只显示。这套机制的价值在于把业务规则前移到录入环节，而不是靠事后报表发现问题。

我一般会把「项目负责人」「利润中心」「工厂」这类影响后续成本归集和采购的字段设成必输。反过来，那些由系统自动带出的字段（比如对象号、状态）设成只显示，避免有人手工改出脏数据。手册 3.2.6 节把 OPUJ 和 OPUK 放在一起讲是对的，但要注意两者的作用范围不同：项目定义的字段选择不会自动继承到 WBS，需要分别配置。

OPS1 用来给 WBS 增加用户自定义字段，本质是在 CI_PRPS 里追加 ZZ 开头的字段。追加完字段只是有了「格子」，要让这个格子变成必输或者校验规则，还得配增强。下面这段 ABAP 报表是配完之后的自检工具，用来查一级 WBS 上的自定义字段有没有漏填：

REPORT zps_check_wbs_field. * 检查一级 WBS 的用户自定义字段填写情况 * 字段名 ZZOWNER 为示例，按系统里 CI_PRPS 的实际追加字段替换 DATA: lt_prps TYPE TABLE OF prps. SELECT posid pspid stufe objnr FROM prps INTO TABLE lt_prps WHERE pspid IN s_proj. LOOP AT lt_prps ASSIGNING FIELD-SYMBOL(<ls_prps>). " STUFE = 1 表示一级 WBS，只校验这一层 IF <ls_prps>-stufe = '1'. " 取附加字段需要用动态方式，这里示意校验入口 " 实际写法：ASSIGN <ls_prps> TO <ls_ci> CASTING，再判断 ZZOWNER IF <ls_prps>-objnr IS INITIAL. WRITE: / <ls_prps>-pspid, <ls_prps>-posid, '对象号为空'. ENDIF. ENDIF. ENDLOOP.

这段代码的重点不在输出格式，而在两个参数：s_proj是项目编号的选择屏幕，按项目范围过滤，避免全表扫描；stufe = '1'把校验范围锁在一级 WBS，因为二级以下的 WBS 很多字段本来就是从上级带下来的，全层校验会产生大量误报。真正接自定义字段时，用ASSIGN ... CASTING把内表行指向 CI_PRPS 结构即可，字段名按 OPS1 里追加的实际名字改。

字段选择配完之后，建议用两个测试用例走一遍：一个把必输字段留空的 WBS，确认系统拦住；一个把只显示字段尝试手工改，确认改不动。这两条过了，字段控制才算落地。

3. 网络、里程碑与成本链：把执行层接到 WBS 上

WBS 只是骨架，真正产生成本的是网络里的作业、物料和确认。从这一步开始，配置的复杂度明显上升——每个参数都对应一条业务规则，规则和规则之间还会互相影响。手册把这一大块拆成 3.3 到 3.15 十几节，实际配的时候可以按「网络 → 里程碑 → 计划 → 预算 → 结算」这条主线走。

3.1 网络类型 OPSC 与网络参数 OPUV

网络类型决定网络的业务属性和编号范围，OPSC 里定义，OPUV 里给每个网络类型挂参数。这一步的关键是不要把网络类型建得太细。常见做法是按业务场景分三类：内部作业类、采购驱动类、跨模块集成类。分得太细，后面每个类型都要配一遍控制码、参数文件和号码段，维护成本翻倍。

OPUV 里几个必须确认的参数：网络类型的编号范围、是否允许无作业的网络、默认控制码、是否启用能力计划。如果企业不做产能排程，能力计划相关的开关可以关掉，减少后面作业确认时的校验负担。

3.2 控制码 OPSU：确认和成本之间的开关

控制码挂在每个作业上，决定这个作业允不允许确认、确认后要不要产生成本、要不要触发能力需求。手册 3.3.3 节单列控制码是对的，因为它是网络配置里最容易被复制粘贴带错的地方。

我一般会建三到四个控制码：一个用于内部工时作业（允许确认、产生成本、需要能力），一个用于外部采购作业（不允许确认、成本由采购订单带），一个用于纯里程碑性质的作业（不允许确认、无成本），再加一个用于服务类作业。每个控制码建完，用 CN22 建一个只有单个作业的网络测一遍，确认在 CN25 里的可确认状态符合预期。

这里有个细节：控制码里的「确认」开关和网络参数文件里的确认参数（OPST）是两层控制。控制码关掉确认，参数文件里开得再宽也确认不了。排错时先看控制码，再看参数文件，顺序别反。

3.3 网络参数文件 OPUU 与号码段 CO82

OPUU 定义网络的默认参数，包括默认控制码、日期参数、确认参数、是否允许物料组件、是否允许能力需求。它最终会通过 OPSA 挂到项目参数文件上，所以配 OPUU 的时候要清楚它服务的是哪一类项目。

号码段 CO82 是很多人会漏的一步。网络类型建好但号码段没分配，建网络时提示编号范围不存在，报错信息又不直接指向 CO82，新手很容易在 OPSC 里来回找。做法是：先在 CO82 里给每个网络类型维护编号范围，再回 OPSC 确认类型和范围的对应关系。

注意：号码段一旦被使用就不能改小上限，扩号只能往上加。测试环境和生产环境要用不同的号段规划，避免测试数据吃掉生产号段。

3.4 里程碑与选择参数文件

里程碑的作用是把项目进度和开票、收款的触发点绑起来。配置上分两步：先在 OPS1 之外的里程碑配置里定义用途（比如「开票里程碑」「验收里程碑」），再定义选择参数文件，决定哪些里程碑状态可以被后续流程取到。

这一步配错的典型表现是：里程碑在项目里建出来了，但开票计划取不到它。原因多半是选择参数文件里没有勾选对应的用途，或者里程碑的用途和销售订单里的开票计划类型不匹配。排查的时候从选择参数文件往回倒查，比在销售模块里猜要快。

3.5 计划参数文件 OPSB 与简易成本计划 OKKT

计划分两条路：一条是 OPSB 里的计划参数文件，控制 WBS 上能不能录计划成本、用哪种计划方法、计划版本怎么管；另一条是简易成本计划（Easy Cost Planning），通过 OKKT 建成本核算变式和成本组件结构。

OPSB 里我建议把计划版本和实际版本分开，至少要有一个「原计划」版本和一个「当前计划」版本。原因很实际：项目执行到中期，计划改了三四版，没有版本区分的话，事后根本说不清预算超支是因为执行不力还是计划本身变了。

OKKT 和 OKTZ（成本组件结构）这一组配置，对应的是「用成本组件来拆计划成本」的场景。如果企业只需要一个总量计划，这套可以简化；如果要做详细的成本构成分析（材料、人工、外协各占多少），就必须把成本组件结构配完整。手册 3.5.4.3 这一串小节看着琐碎，实质上就是在搭这条分析链路。

3.6 预算 OPS9 与容差

预算参数文件 OPS9 决定预算的可用性控制方式、容差上下限、是否允许年度预算分配。这一步的核心参数是容差：超预算 5% 提醒还是 10% 直接阻断，取决于企业的管控强度。

常见做法是设置两级：提醒线放在 90%，阻断线放在 100% 或 105%。提醒线让项目经理有缓冲，阻断线防止预算被彻底击穿。容差配在 OPS9 里，但真正生效还要看预算是否已经下达——没有下达预算的项目，可用性检查是空跑。

另外 OPTK 里的豁免成本要素值得单独提一句。有些成本要素（比如某些财务分摊科目）不应该占用项目预算，如果没加到豁免清单里，预算会被这类成本吃掉，项目经理看到的可用金额会莫名其妙变少。

3.7 结算与结果分析的链条

到了结算这一环，配置的依赖关系最密。需要按顺序做：先用 KA06 建结算用的次级成本要素，再建分配结构，再建 PA 传输结构（KEI1），然后建结算参数文件并挂到项目参数文件上，最后定义结算规则的确定策略。

结果分析（OKG1 到 OKG5）是另一条链：成本要素、结果分析码、版本、估值方法、行标识、分配、更新规则、过账规则。手册 5.5.5 这一串小节基本就是按这个顺序排的，照着走能跑通，但有两个地方要特别留意：结果分析码要指定给项目定义，估值方法里的成本组件要和 OKTZ 里配的对上。这两处对不上，跑 KKA2 的时候要么出不来数，要么出来的数是反的。

下面这段 ABAP 用来在建完一个最小项目后验证配置链是否打通：

REPORT zps_create_min_project. * 用 BAPI 建一个最小项目，验证 OPSA/OPSJ/OPUU 的配置链 * 结构名以 SE37 里 BAPI_PROJECT_MAINTAIN 的当前签名为准 DATA: ls_project_def TYPE bapi_project_definition, ls_project_ret TYPE bapi_project_definition, lt_wbs TYPE TABLE OF bapi_wbs_element, ls_wbs TYPE bapi_wbs_element, lt_return TYPE TABLE OF bapiret2. ls_project_def-project_definition = 'ZTEST0001'. ls_project_def-project_profile = 'Z00001'. " 对应 OPSA 里定义的项目参数文件 ls_project_def-start_date = sy-datum. ls_project_def-finish_date = sy-datum + 90. ls_wbs-wbs_element = 'ZTEST0001.01'. ls_wbs-description = 'test wbs level 1'. ls_wbs-wbs_level = '1'. APPEND ls_wbs TO lt_wbs. CALL FUNCTION 'BAPI_PROJECT_MAINTAIN' EXPORTING i_project_definition = ls_project_def IMPORTING e_project_definition = ls_project_ret TABLES i_wbs_element = lt_wbs return = lt_return. LOOP AT lt_return INTO DATA(ls_ret) WHERE type CA 'EAX'. WRITE: / ls_ret-type, ls_ret-message. ENDLOOP. IF sy-subrc <> 0. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'. ENDIF.

三个关键点：project_profile必须对应 OPSA 里已配置的参数文件，传错或者传空会直接触发配置校验失败；wbs_element的编号要符合 OPSJ 里定义的掩码规则，不符合时返回的错误信息通常只说「编号无效」，不会提示掩码；提交用BAPI_TRANSACTION_COMMIT并带wait = 'X'，否则后面的检查可能读不到刚建的数据。这套跑通，说明 OPSA、OPSJ、OPUU 三层是连着的；跑不通，就从返回消息里第一个报错往下拆，别一次改好几个配置。

4. 避坑：五类最容易在上线前夜翻车的配置

配置手册给的是「正确路径」，实际项目里出问题的地方往往在路径之外——两个各自正确的配置组合在一起就冲突了。下面这五条是 PS 实施里反复出现的翻车现场，每条都按「看到什么 → 为什么 → 怎么修」来拆。

4.1 项目能建，WBS 报「编码不符合掩码」

现象：CJ20N 里建项目定义成功，加 WBS 时提示编号不符合编辑掩码，换几个编号都不行。

原因基本是两个。一是 WBS 的编号规则和项目编号规则不是同一套，OPSJ 里配的掩码管的是项目定义编号，WBS 的编号由项目参数文件里的 WBS 掩码单独控制，两套规则没对齐就必然报错。二是掩码里用了特殊字符或分隔符，而 WBS 编号在系统内部还会拼上级编号，拼接后的长度超过掩码上限。

解决办法：先用 CJ20N 建一个不带 WBS 的空项目，确认项目编号这层没问题；再检查项目参数文件里挂的 WBS 掩码，把它和 OPSJ 的规则对齐，特别注意长度是否够容纳「上级编号 + 分隔符 + 下级序号」。改完掩码后，已经建成的项目不受影响，但新加 WBS 会按新规则校验。

4.2 计划成本录得进去，预算下达后不占用

现象：CJ30 里预算下达成功，但后续采购申请提交时没有任何预算检查提示，超支了也没人拦。

原因通常是预算参数文件没有真正挂到项目定义上，或者可用性控制的开关没打开。还有一种情况是预算虽然下达了，但下达到的是错误的年度，项目期间跨年时尤其容易出。

排查顺序：先看项目定义上的参数文件是不是 OPS9 里配的那一个，再看预算参数文件里的可用性控制是否勾选，最后查预算表 BPGE（总预算）和 BPJA（年度预算）里有没有实际数据。三处都正常还不检查，就要看成本要素是否在 OPTK 的豁免清单里。

4.3 结算规则跑出来是空的

现象：CJ88 跑结算，提示没有结算规则或者结算金额为零，但成本明明已经挂在项目上了。

原因八成在结算参数文件和分配结构这一组。结算参数文件要求指定分配结构，分配结构里要把成本要素映射到结算接收方；如果成本要素的类别没有在分配结构里覆盖到，这部分成本就不会被结算，系统也不报错，只是静默跳过。

查法很直接：用 SE16N 看 COBRB 表里这个项目的结算规则是否存在、接收方是否被维护。规则为空说明结算参数文件没挂上或者没生成规则；规则有但金额为零，就去查分配结构里的成本要素映射。

4.4 作业确认后成本跑到别的期间或别的对象

现象：CN25 确认了作业，但成本在当月报表里查不到，跑到下个月去了，或者挂到了另一个 WBS 上。

期间问题多半是确认日期和过账日期的关系没处理对，网络的确认参数（OPST）里可以控制确认时是否直接过账、过账日期取哪个字段。对象问题则常出现在作业的分配上——作业默认分配到哪个 WBS，由网络参数文件里的默认值和作业本身的分配共同决定。

处理办法是先在 CN25 里确认单笔作业，出结果后用 CO03 或报表查这笔成本的对象号和期间，确认它到底挂到了哪里，再回去改确认参数或作业分配。不要在没定位清楚之前批量重跑确认，容易产生重复成本。

4.5 结果分析出来的数和财务对不上

现象：KKA2 跑出来的项目结果和财务口径的利润差异明显，或者出现负数。

原因通常是估值方法里用的成本组件结构和 OKTZ 里配的结构不一致，或者结果分析码没有正确指定给项目定义，系统用了默认码在做估算。另外，WIP 计算和结果分析是两套逻辑，混在一起看也容易误判。

修法：先确认项目定义上的结果分析码，再核 OKG3 里估值方法引用的成本组件结构版本，最后把 KKA2 的结果和 CO 的实际成本做一次对账。对不上时不要急于调参数，先把差异拆到成本要素级别，大部分差异会集中在一两个要素上，定位很快。

5. 用最小项目做端到端验收：我固定跑的那一遍

配置改完不验收，等于没配。手册里没有专门的验收章节，但这是每个 PS 顾问都该养成的习惯：新建一个最小项目，把「立项 → 挂网络 → 计划 → 预算 → 采购或确认 → 结算 → 结果分析」这条线完整走一遍，全程不超过半天，能提前发现八成配置问题。

我的做法是固定一张验收清单，每次改完配置都从头跑，不跳步：

这张表最有价值的地方是最后一列。出问题时大多数人会盯着报错信息找，但 PS 的报错经常指向表象，按最后一列的顺序回查，命中率高得多。

还有一个技巧值得单独说：批次跑验收时用 BAPI 而不是手工点。前面第 3.7 节那段BAPI_PROJECT_MAINTAIN就是干这个的，把项目创建、WBS 创建自动化，每次改完配置重跑一遍，五分钟出结果。手工点的话，人会自动避开那些「上次报错的地方」，反而漏掉问题。

血泪经验是这么来的：早期做实施时，我在测试环境配完结算，手工点了一遍，一切正常，就直接上了生产。结果生产环境的第一笔结算是空的，原因是测试环境里我手工补过一条结算规则，而配置本身并没有生成它的逻辑。从那以后我每次改完结算相关配置，都强制从空项目走一遍 CJ88，不允许在已有测试项目上验证。希望帮到你。

本文还有配套的精品资源，点击获取