SAP S/4HANA MM模块培训 56 - 灵活工作流:采购订单审批、场景激活与My Inbox

灵活工作流是 SAP S/4HANA 采购审批中最容易“只看懂概念、却没有真正跑通”的主题之一。原因很简单:它同时跨越 IMG 基础激活、采购凭证类型、Fiori 工作流定义、组织责任、审批任务和异常处理。只要其中一层没有配置完整,最终现象往往都一样——采购订单保存了,但审批任务没有出现。
本课视频的价值,是把采购订单灵活工作流的概念、技术场景以及两项基础激活路径展示出来;但视频并没有完成工作流定义、采购订单创建和 My Inbox 审批。本文先严格还原视频实际讲到的内容,再用 SAP 官方教程补齐从定义、模拟到审批的完整闭环。这样既不会把视频未演示的步骤写成“讲师已经操作”,也能让读者获得一套可落地的实施框架。
视频来源:Video 56 - SAP S/4HANA Materials Management (MM) training - S/4HANA Flexible Workflows
视频时长:约 10 分 05 秒;本地媒体探测时长为 605.021 秒。文中时间点以逐条校对后的字幕时间轴为准。
一、先确认本课真正讲了什么
视频开头给出的议程包括灵活工作流介绍、必要设置、采购订单启用、完整设置与演示,以及采购申请工作流。实际内容只覆盖前三项的一部分:讲师解释了灵活工作流的基本概念,说明它与经典发布策略的关系,然后进入 SAP GUI 检查采购订单工作流场景和凭证类型的既有激活状态。

视频没有发生以下操作:
- 没有打开 Manage Workflows for Purchase Orders 创建工作流定义;
- 没有维护启动条件、步骤条件、收件人、截止时间或异常处理;
- 没有创建并保存一张用于触发审批的采购订单;
- 没有在 My Inbox 中接收、批准或拒绝审批任务;
- 没有演示采购申请的按项目审批或整体审批;
- 没有展示工作流日志、模拟结果和采购订单最终状态。
因此,本文把 00:00:01.020~00:10:03.180 视为“视频事实层”,后面的完整配置方法明确标注为 SAP 官方教程补充。
视频时间轴
| 时间 | 视频内容 | 实际边界 |
|---|---|---|
| 00:00:01~00:01:04 | 介绍议程 | 议程大于实际演示范围 |
| 00:01:04~00:03:57 | 定义灵活工作流 | 概念说明,无系统配置 |
| 00:03:57~00:05:08 | 用幻灯片说明条件、审批人和步骤 | 非 SAP 界面,已中文重制 |
| 00:05:08~00:06:14 | 说明采购文档范围、模板与经典发布策略关系 | 聚焦采购订单 |
| 00:06:14~00:06:56 | 展示初始激活路径 | 幻灯片说明 |
| 00:06:56~00:08:23 | 在 IMG 中检查采购订单场景激活 | 只查看既有状态,没有保存新配置 |
| 00:08:23~00:09:12 | 检查采购订单凭证类型激活 | 显示 NB 与自定义 ZNB 已激活 |
| 00:09:12~00:10:03 | 总结按凭证类型选择审批方式 | 视频结束,无端到端演示 |
二、灵活工作流到底是什么
视频把灵活工作流描述为 SAP Business Workflow 在寻源与采购业务中的扩展。它允许企业按采购凭证的业务条件决定审批流程,并配置谁来审批、需要几个步骤、步骤何时执行,以及异常时如何处理。

可以把它拆成四个问题:
- 何时启动:哪类采购订单、哪个公司代码、哪个采购组织、什么金额范围才需要进入该工作流;
- 谁来审批:指定用户、业务角色、经理、团队、成本中心责任人,还是自定义代理确定逻辑;
- 怎样流转:是一人审批、多人依次审批,还是在特定条件下跳过某一步;
- 异常怎么办:审批人不存在、任务逾期、采购订单被拒绝或关键字段被修改后,流程应如何继续。
这也是为什么“把工作流开关勾上”远远不够。开关只让系统允许某个场景和凭证类型使用灵活工作流,真正的业务审批仍由工作流定义决定。
三、它与经典发布策略是什么关系
视频反复强调:灵活工作流不是强制覆盖所有经典发布程序。对于采购订单,企业可以按凭证类型决定采用灵活工作流,还是继续采用带分类的经典发布程序。两种方式可以在同一系统中并存,但分界点应当清晰。

经典发布程序的配置重心通常在 IMG、分类特征、发布组、发布代码和发布策略。灵活工作流则把业务可读的启动条件、审批步骤和收件人配置集中到 Fiori 应用中,并提供收件箱、模拟、期限和异常处理等能力。
实际设计时应先回答三个问题:
- 哪些采购订单凭证类型继续沿用经典发布程序;
- 哪些凭证类型启用场景式灵活工作流;
- 在途单据和已批准后再修改的单据,迁移时如何处理。
如果没有先确定凭证类型边界,而是在工作流定义中不断试错,容易造成同一业务在不同系统或不同时间段表现不一致。
四、一个完整工作流定义包含哪些部分
视频中的英文幻灯片列出了名称、收件人和前提条件等元素。为了便于实施,可以把一条采购订单工作流定义整理为六类配置。

1. 名称、描述与有效期
名称应能表达审批规则,而不是只写“PO Workflow”。例如“1710 公司代码高金额采购订单审批”。描述中最好写清业务目的、金额口径、适用组织和变更责任人。有效期用于控制新版本何时生效。
2. 启动条件
启动条件用于选择工作流定义。采购订单保存后,系统根据公司代码、凭证类型、采购组织、采购组、币种、物料组、账户分配和总净额等属性判断是否匹配。
3. 步骤顺序
步骤表示审批链。企业可以只设一个审批步骤,也可以按金额或组织设计多级审批。步骤的顺序直接影响谁先收到任务。
4. 步骤条件
工作流已经匹配后,系统还可以判断某个步骤是否需要执行。例如金额大于 100,000 时才进入财务负责人步骤,金额较小时跳过。
5. 审批人或收件人
审批人可以是固定用户,也可以按角色、经理层级、团队、成本中心、项目或 BAdI 动态确定。动态确定更灵活,但依赖组织和责任主数据完整。
6. 截止时间与异常处理
审批任务多长时间算逾期、拒绝后取消还是重启、某一步没有审批人时如何处理,都应在上线前明确。只设计“正常批准”路径,不算完整的工作流设计。
五、视频用采购订单示例解释了什么
视频中的逻辑是:采购订单创建者先创建采购订单;当单据满足预设条件时,工作流被触发,指定审批人收到任务;只有审批完成后,单据才能继续后续受控业务活动。

图中的 50,000 USD 和公司代码 1710 是 SAP 官方课程中常见的规则示例,用来解释条件结构,不应直接作为企业生产规则。真正的金额阈值必须结合授权制度、币种换算、采购类型和审计要求确定。
还要注意,视频只是用幻灯片描述这个过程,并没有创建采购订单或生成审批任务。因此,不能从该视频判断讲师系统中工作流定义是否真的完整,也不能据此确认审批人、状态回写或异常处理是否正常。
六、视频实操第一步:进入 IMG 找到采购订单灵活工作流
讲师从 SPRO 进入 SAP Reference IMG,依次展开:
Materials Management → Purchasing → Purchase Order → Flexible Workflow for Purchase Orders

该节点下可以看到多项活动,包括标准设置、客户端相关配置、场景激活、为采购订单激活灵活工作流,以及管理灵活工作流重启条件等。视频只进入了“场景激活”和“为采购订单激活灵活工作流”两项活动。
图中是视频 00:08:25 左右的 1920×1080 SAP 原帧,保持原始分辨率,未裁剪、未放大,也没有叠加中文标注。
七、视频实操第二步:检查场景 WS00800238
在“Activating a scenario”界面中,讲师定位到 WS00800238。该行的 Active 复选框已经选中,所以讲师没有重新勾选,也没有保存。

这里有一个容易混淆的编号口径:视频口头和幻灯片中常省略 WS 前缀,写成 00800238;SAP 官方功能概览给出的完整技术模板标识是 WS00800238。两者指向同一个采购订单灵活工作流模板。
视频把场景激活描述为一次性活动。更准确地说,它通常属于系统基础启用,不是采购员每天操作的业务步骤。但是否需要传输、在哪个客户端维护、升级后是否需要重新核查,仍应遵循目标系统版本和变更管理规范。
八、视频实操第三步:按凭证类型启用灵活工作流
完成场景检查后,讲师返回 IMG,进入“Activate Flexible Workflow for Purchase Orders”。在这里,系统按采购订单凭证类型维护是否使用场景式工作流。
视频先短暂打开采购订单创建界面,说明日常常用的标准采购订单凭证类型是 NB。随后返回配置表,显示 NB / Standard PO 已勾选。

继续向下滚动后,视频显示一个自定义凭证类型 ZNB / Standard PO 也已勾选。

这里必须说明一处自动字幕错误:英文自动字幕把画面中的 ZNB 识别为 ZLP,但 00:08:58~00:09:05 的 SAP 表格清楚显示为 ZNB。本文和中文字幕均以软件界面可见值为准,已统一修正为 ZNB。
九、视频结论:两层激活缺一不可
视频展示的基础启用可以概括为两层:
- 激活采购订单技术场景
WS00800238; - 对需要使用灵活工作流的采购订单凭证类型勾选场景式工作流。

两层都满足后,系统才会把该凭证类型交给灵活工作流框架处理。但这仍然不表示审批一定会启动。系统还必须存在有效、已激活且条件能够匹配的工作流定义,并且能够找到审批人。
按凭证类型做治理分界,可以避免经典发布程序和灵活工作流在同一类采购订单上发生职责不清。

到这里,视频的系统演示就结束了。下面所有关于 Manage Workflows、条件、审批人、模拟、My Inbox、重启和采购申请的内容,均来自 SAP 官方教程与帮助文档,不属于视频实操。
SAP 官方教程补充:基础激活与工作流定义必须分开验证
基础激活回答的是“这个场景和凭证类型能不能使用灵活工作流”;工作流定义回答的是“哪张采购订单触发、由谁审批、经过哪些步骤、异常时怎么办”。这两层属于不同配置对象,排障时不能混为一谈。
SAP Learning 的采购课程说明,自 SAP S/4HANA 1709 起,采购场景可使用灵活工作流;采购订单模板为 00800238,它可以替代带分类的发布程序,也可以在不同凭证类型上作为补充。凭证类型基础启用后,还必须在 Manage Workflows for Purchase Orders 中维护工作流定义。SAP Learning:Setting Up Flexible Workflows in Purchasing
实施验证时建议把问题拆成两张检查表:
| 基础激活检查 | 工作流定义检查 |
|---|---|
| 技术场景是否激活 | 定义是否保存并激活 |
| 凭证类型是否启用场景式工作流 | 有效期是否覆盖测试日期 |
| 配置是否已正确传输到目标系统 | 启动条件是否与测试单据一致 |
| 客户端和系统环境是否正确 | 工作流顺序是否让正确规则优先 |
| 是否与经典发布程序边界冲突 | 审批人、步骤和异常是否完整 |
SAP 官方教程补充:系统如何选择一条工作流
Manage Workflows 中可以存在多条已激活定义。系统不是把所有匹配定义都执行一遍,而是按照定义顺序查找,并选择第一条满足启动条件的工作流。因此,越具体、优先级越高的规则通常应排在前面,宽泛规则放在后面。

假设有四条定义:
- 净额大于 100,000 的高金额采购;
- 净额大于 5,000 的中金额采购;
- 公司代码 1710 的特殊流程;
- 无条件自动批准。
如果“净额大于 5,000”排在“净额大于 100,000”之前,那么一张 150,000 的采购订单会先命中第二条,后面的高金额审批永远没有机会被选择。问题表面看是“高金额工作流没触发”,根因却是定义顺序错误。
SAP 官方 Cloud 配置文档说明,活动工作流不能直接编辑;可以停用、复制或创建新定义。文档同时说明,系统按顺序选中第一条满足前提条件的工作流。若没有其他定义匹配,可使用最后的 Automatic Release 作为默认工作流。SAP Help:How to Configure the Flexible Workflow for Purchase Orders
不同部署和版本的默认行为可能不同。生产实施时必须以目标系统帮助文档和实际配置为准,不要只根据示例环境推断。
SAP 官方教程补充:在 Manage Workflows 中创建采购订单定义
SAP S/4HANA on-premise 官方帮助将 Manage Workflows for Purchase Orders 标识为 App ID F2872。该应用用于维护工作流属性、有效期、启动条件、步骤序列、收件人、通知和部分版本中的重启或返工相关能力。SAP Help:Manage Workflows for Purchase Orders(on-premise)
建议按以下顺序创建定义:
- 创建新工作流,填写可读名称和描述;
- 维护有效起止日期;
- 设置启动条件和替代条件组;
- 创建一个或多个步骤;
- 为每一步选择类型、属性、收件人和步骤条件;
- 配置截止时间、异常处理与通知;
- 保存后使用模拟功能检查匹配;
- 将定义放到正确顺序并激活;
- 用真实测试采购订单验证 My Inbox 与状态回写。
不要用“先激活再慢慢补内容”的方式配置生产工作流。定义一旦进入活动状态,就可能影响新保存的采购订单。
SAP 官方教程补充:启动条件如何组合
SAP 官方课程列出的采购订单启动条件包括账户分配类别“成本中心”或“项目”、公司代码、物料组、币种、凭证类型、采购组、采购组织,以及采购订单总净额的上下限等。

上图来自 SAP Learning 官方课程原图,属于 SAP 软件界面截图,保持原始 1600×882 分辨率,未放大或重绘。界面中可以看到两组条件:第一组要求“以下所有前提条件均满足”,第二组以“或”方式提供替代组合。
可把条件组合理解为:
- 同一组内通常按 AND 处理,例如“公司代码 = 1710”并且“总净额 > 50,000”;
- 多个替代组之间按 OR 处理,例如“高金额采购”或者“项目账户分配采购”;
- 条件越宽泛,越需要谨慎安排顺序;
- 金额条件要明确币种、汇率和边界值;
- 物料组、项目和成本中心条件依赖单据行项目与账户分配数据是否完整。
测试时至少覆盖:恰好等于阈值、低于阈值、高于阈值、不同币种、多个行项目、不同公司代码以及缺少可选字段等边界情况。
SAP 官方教程补充:启动条件与步骤条件不是一回事

启动条件发生在选择工作流定义时。步骤条件发生在已经选中工作流之后。如果把本应属于步骤的金额判断全部放到启动条件中,往往需要创建大量相似定义;如果把本应区分不同治理流程的条件全部放到步骤中,又会让一个定义承担过多职责。
一个较清晰的设计示例是:
- 启动条件:公司代码 1710、凭证类型 NB;
- 步骤 1:采购经理审批,所有匹配单据都执行;
- 步骤 2:财务负责人审批,仅当净额大于 100,000 时执行;
- 步骤 3:项目负责人审批,仅当存在项目账户分配时执行。
这样,工作流定义表达“1710 公司代码的标准采购订单”,步骤条件再表达审批深度。规则更容易读,也更容易测试。
SAP 官方教程补充:如何确定审批人
收件人是灵活工作流最常见的失败点之一。SAP 官方界面允许按用户、角色、团队或扩展逻辑确定审批人;可用选项随产品版本、业务场景和配置而变化。

上图来自 SAP Learning 官方原图,保持原始 1600×878。示例列表中包含发起人经理、上一审批人经理、运营采购、战略采购、工作流管理员,以及通过 BAdI 确定代理人等方式。

固定用户
适合少量、稳定且职责明确的审批人。优点是结果容易预测;缺点是人员离职、调岗或休假时需要维护,并且容易形成个人依赖。
业务角色
适合战略采购、运营采购等职责型审批。关键不是只在工作流中选择角色,还要确认用户是否被正确分配、角色范围是否覆盖目标组织,并拥有打开任务和业务对象的授权。
经理层级
可以基于工作流发起人的经理、上一审批人的经理等关系逐级确定。它依赖人员主数据与主管关系准确。如果组织关系缺失,工作流定义看起来正确,也可能无法创建任务。
团队与责任定义
适合按采购组织、公司代码、品类或责任区域管理审批。团队成员和责任范围需要持续治理,不能只在上线时维护一次。
成本中心或项目责任人
适合费用采购和项目采购。系统必须能够从单据账户分配找到正确业务对象,并从主数据中解析责任人。
BAdI 扩展
Cloud 官方帮助列出 MMPUR_WORKFLOW_AGENTS_V2 作为代理人确定扩展。只有标准规则无法表达真实业务逻辑时才应使用扩展,并为无返回值、多返回值和异常输入设计明确行为。SAP Help:Manage Workflows for Purchase Orders(Cloud)
SAP 官方教程补充:步骤属性、截止时间与异常处理

一个审批步骤至少要确认以下设置:
- 是任意一名收件人完成即可,还是所有收件人都必须完成;
- 是否允许该步骤成为可选步骤;
- 是否排除采购订单创建者,避免自建自批;
- 任务主题是否能让审批人快速识别单据与风险;
- 多长时间后标记逾期;
- 逾期后是提醒、升级,还是执行其他动作;
- 拒绝后取消工作流、继续、重复当前步骤、重启工作流,还是进入下一步;
- 审批人无法确定时如何暴露错误并通知管理员。
SAP Learning 的配置课程还提到,可使用电子邮件模板,例如 MMPUR_PO_WFL_APPROVAL_EMAIL,向审批人发送采购订单工作流通知。是否启用、模板可用性和可编辑范围取决于目标版本与配置。SAP Learning:Setting up Configuration for Workflows
期限不能只写“4 天”而不说明口径。要确认是日历日还是工作日、从工作流开始还是步骤创建开始计算、跨时区如何处理、代理和转发是否影响期限,以及逾期后谁负责处理。
SAP 官方教程补充:激活前先用模拟验证
Manage Workflows 的模拟功能可以输入采购订单业务对象,检查系统会匹配哪一条工作流、当前状态以及预计步骤和收件人。

上图是 SAP Learning 官方软件截图,保持原始 1600×683。示例中选择业务对象后,系统返回匹配工作流和审批步骤预览。
模拟至少应覆盖以下测试集:
| 测试类型 | 目的 |
|---|---|
| 每条工作流的正向样本 | 确认该定义能够被命中 |
| 相邻阈值边界 | 确认 >、>=、<= 的口径 |
| 多条规则可能同时匹配 | 验证顺序是否正确 |
| 无条件默认样本 | 验证自动批准或默认流程 |
| 无审批人样本 | 验证错误是否可见、是否有管理员处理路径 |
| 变更后重新提交 | 验证重启条件和版本切换 |
模拟不是端到端测试的替代品。它能验证选择逻辑,但仍需真实创建采购订单、接收 My Inbox 任务、完成审批,并检查采购订单状态和工作流日志。
SAP 官方教程补充:完整端到端流程

完整流程可以按六步验证:
- 基础激活:场景
WS00800238和目标采购订单凭证类型均已启用; - 维护定义:创建启动条件、步骤、审批人、期限和异常;
- 排序并激活:把具体定义放到正确位置,确认有效期;
- 创建采购订单:使用明确测试数据保存单据,记录公司代码、组织、凭证类型、金额和账户分配;
- My Inbox 审批:确认正确审批人收到任务,并测试批准、拒绝、转发、认领、挂起等允许动作;
- 结果与审计:检查采购订单审批状态、业务后续动作、工作流日志、通知和变更记录。
视频只完成第 1 步的状态核对,而且没有修改或保存配置。第 2~6 步都需要单独实施和测试。
SAP 官方教程补充:审批人在 My Inbox 中做什么
SAP 官方课程说明,采购订单审批任务可以进入 My Inbox。审批人可根据授权和任务配置执行批准、拒绝、认领、转发、挂起、查看历史和日志等操作;可用动作以目标版本和任务定义为准。

上图来自 SAP Learning 官方原图,保持原始 1600×717。界面中可以看到采购订单号、净额、状态、供应商、公司代码、采购组、采购组织以及底部的 Approve、Reject、Show Log、Claim、Forward、Suspend 等动作。
审批任务能打开,并不等于审批人拥有所有后端业务权限。实施时要分别验证:
- 用户能否进入 My Inbox;
- 用户能否看到目标任务;
- 用户能否读取采购订单详情;
- 用户能否执行批准或拒绝;
- 完成动作后任务是否消失或进入已完成列表;
- 采购订单状态是否正确更新;
- 代理人和替代审批人在有效期内是否收到任务。
SAP Learning 还介绍了 My Outbox,可用于查看已完成或挂起的流程以及工作流日志。SAP Learning:Introducing Flexible Workflows for Sourcing and Procurement
SAP 官方教程补充:工作流变更、重启与返工

工作流定义变更
活动定义通常不直接修改。更稳妥的做法是复制旧定义,调整名称、有效期、条件和步骤,完成模拟与联调后再切换顺序和激活状态。这样可以保留历史规则,方便审计某张采购订单当时使用了哪个版本。
采购订单关键字段变更
采购订单在批准后可能再次修改金额、供应商、公司代码、采购组织、账户分配或项目。哪些变更必须重新审批,应通过重启条件明确。重启过于敏感会让无关小改动反复触发审批;重启不足又可能让重大变更绕过授权。
拒绝与返工
不同版本可提供取消工作流、继续、重复步骤、重启或返工等能力。返工开关和具体行为必须以目标系统官方文档为准。有些配置一旦启用可能存在不可逆限制,不能只在生产系统中试验。
切换或升级时要分别考虑:新创建单据、正在审批的在途单据、已批准后再次修改的单据。三类对象不一定采用同一规则。
SAP 官方教程补充:采购申请不是采购订单模板的简单复制
视频议程提到采购申请工作流,但没有演示。SAP Learning 官方采购课程列出两个采购申请模板:
WS00800173:按采购申请行项目审批;WS00800157:采购申请整体审批。

按项目审批适合不同物料组、成本中心、项目或责任人分别处理的场景,同一张采购申请中的各行可能得到不同结果。整体审批适合统一预算责任、整单放行的场景。两种粒度会影响启动条件、审批人、任务数量和状态解释,必须在配置前确定。
采购订单模板 WS00800238 的字段、步骤类型和业务状态不能直接套到采购申请。即使审批政策相似,也应分别设计和测试。
SAP 官方功能概览列出了采购订单模板完整标识 WS00800238,并提供不同采购对象的灵活工作流能力说明。SAP Help:Flexible Workflow Features - Overview
SAP 官方教程补充:常见故障与排查顺序

没有触发审批
按顺序检查:场景是否激活、凭证类型是否启用、工作流是否在有效期内并已激活、启动条件是否匹配、工作流顺序是否被更宽泛规则截走。不要一开始就修改审批人。
触发了错误的工作流
重点检查定义顺序、条件组 AND/OR 关系、金额边界、币种、公司代码和凭证类型。使用模拟功能输入同一业务对象,确认实际匹配结果。
工作流匹配但没有审批任务
检查收件人确定结果、用户和经理主数据、团队与责任定义、角色分配、BAdI 返回值以及工作流管理员处理机制。无审批人通常属于人员或责任数据问题,而不是场景激活问题。
审批人看到任务但打不开单据
检查 My Inbox 访问、采购订单读取权限、后端业务授权、相关服务和系统连接。任务授权与业务对象授权属于不同层。
审批完成但采购订单状态不对
检查后续步骤是否仍在等待、是否要求所有收件人完成、异常处理是否把流程继续或重启、工作流日志是否记录错误,以及单据是否在审批期间发生关键变更。
变更后没有重新审批
检查重启条件是否覆盖该字段、变更是否达到阈值、变更发生时工作流处于什么状态,以及目标版本对重启和返工的支持边界。
在进入最终检查清单前,下面用一套完整但纯示例的规则,把条件、顺序、审批人和测试方法串起来。示例仅用于说明设计思路,企业必须用自己的授权制度替换金额、组织与角色。
SAP 官方教程补充:用分层审批案例串起所有配置
假设公司代码 1710 的标准采购订单 NB 采用灵活工作流,内部制度规定:5,000 以下由采购业务自行负责;5,000~100,000 需要采购经理审批;超过 100,000 还需要财务负责人审批;如果使用项目账户分配,则无论金额大小都需要项目负责人参与。
第一步:先设计工作流选择规则
可以设计两条业务工作流和一条默认工作流:
| 顺序 | 工作流 | 启动条件 | 目的 |
|---|---|---|---|
| 1 | 1710 项目采购 | 公司代码 = 1710;凭证类型 = NB;使用项目账户分配 | 先截取治理要求更特殊的项目采购 |
| 2 | 1710 一般采购 | 公司代码 = 1710;凭证类型 = NB;不属于项目特殊流程 | 处理一般费用或库存采购 |
| 最后 | 自动批准 | 无附加业务条件 | 避免没有定义匹配,具体是否使用依版本与制度决定 |
为什么项目采购放在前面?因为它比“一般采购”更具体。如果一般采购条件写得过宽并排在第一条,项目采购可能先命中一般流程,项目负责人步骤就不会出现。
第二步:在工作流内部设计步骤
“1710 一般采购”可以有两个步骤:
- 采购经理审批:步骤条件为总净额大于或等于 5,000;
- 财务负责人审批:步骤条件为总净额大于 100,000。
“1710 项目采购”可以有三个步骤:
- 项目负责人审批:从项目责任关系确定收件人;
- 采购经理审批:金额达到内部阈值时执行;
- 财务负责人审批:高金额时执行。
这样,启动条件负责把采购订单送到正确治理流程,步骤条件负责决定审批深度。规则分工清楚后,业务人员可以从名称和步骤直接理解为什么某人收到任务。
第三步:明确“一个人”还是“所有人”
如果采购经理角色下有三名用户,要明确任务是任意一人批准即可,还是三人都必须批准。前者适合共享责任池,后者适合集体会签。不要仅因为系统能返回多人,就默认业务制度要求多人全部完成。
项目负责人可能因多个项目或多条账户分配返回多人。此时还要决定:所有项目负责人都审批,还是只让最高金额项目的责任人审批。标准角色和责任规则能否表达这一要求,应在选择 BAdI 前先验证。
第四步:设计异常路径
对于每一步,至少给出以下业务答案:
- 审批人拒绝后,采购订单是回到创建者修改,还是直接取消流程;
- 创建者修改金额后,流程从头开始还是从当前步骤继续;
- 审批人四天未处理,是标记逾期、发送提醒,还是升级给经理;
- 找不到项目负责人时,是立即报错给工作流管理员,还是进入备用角色;
- 审批人恰好是采购订单创建者时,是否排除并寻找替代审批人;
- 代理人审批后,日志中如何体现原审批责任与实际执行人。
只有这些答案明确后,才应该把规则录入系统。否则配置人员只能凭经验猜测,最终流程虽能启动,却不一定符合内控要求。
SAP 官方教程补充:建立可复用的测试矩阵
灵活工作流测试不能只创建一张“刚好会成功”的采购订单。至少要覆盖规则边界、重叠匹配、责任主数据和异常处理。
金额边界测试
以上述阈值为例,应分别测试 4,999.99、5,000、5,000.01、99,999.99、100,000 和 100,000.01。这样才能确认“高于”“高于或等于”“低于或等于”的配置是否符合制度。
如果采购订单币种不同,还应确认总净额条件按哪种币种比较、系统如何换算、使用哪个日期的汇率,以及舍入后落在哪个区间。不能因为测试环境只使用一种币种,就忽略生产中的多币种采购。
组织与凭证类型测试
至少准备:同一金额但不同公司代码、不同采购组织、不同采购组、NB 与未启用的其他凭证类型。目标是证明工作流不仅“该触发时触发”,还要“无关单据不触发”。
账户分配与多行项目测试
分别测试库存物料、成本中心、项目以及混合账户分配。多行项目要验证条件是看任意一行、所有行还是汇总结果。对于物料组条件,也要覆盖一张采购订单包含多个物料组的情况。
收件人与授权测试
准备正常审批人、缺失经理、团队无成员、责任范围不覆盖、审批人无采购订单读取权限、创建者与审批人相同等样本。每个失败都应得到可识别的错误或管理员处理路径,不能让任务静默消失。
流程动作测试
对每个关键步骤测试批准、拒绝、转发、认领、挂起、代理和逾期。多人步骤还应测试第一人完成后任务是否仍保留,以及所有人完成后何时进入下一步。
变更与重启测试
采购订单批准前后分别修改金额、供应商、公司代码、采购组织、账户分配、项目和文本。把每种变更的预期结果记录为“无影响、重启当前步骤、从头重启或禁止变更”,再与实际行为比对。
建议测试记录至少包含:采购订单号、输入字段、预期工作流、实际匹配定义、实际审批人、每步时间、最终状态、工作流日志位置和截图。这样升级或变更后可以重复执行回归测试。
SAP 官方教程补充:权限与责任主数据要分层治理
灵活工作流涉及的“权限”不是一项。至少有四层:
- 配置权限:谁能进入 Manage Workflows 创建、排序、激活和停用定义;
- 任务权限:谁能进入 My Inbox、读取任务并执行允许的动作;
- 业务对象权限:审批人是否能查看采购订单、供应商、金额、账户分配和附件;
- 责任主数据:角色、团队、经理、成本中心或项目责任人能否正确解析到用户。
SAP Learning 的公共云实施课程以 Configuration Expert 业务角色 SAP_BR_BPC_EXPERT 说明工作流配置职责。该角色示例不能直接当作所有部署的授权方案;on-premise、私有云和不同发行版需要使用各自的业务目录、角色和后端授权对象。SAP Learning:Defining Workflows In Sourcing and Procurement
职责分离方面,配置人员不应同时随意改变审批规则并批准自己的采购订单。生产变更应至少保留需求提出、业务批准、配置实施、测试确认和传输记录。对高风险流程,还应定期导出或审阅活动工作流、顺序和有效期。
审批人无法打开任务时,不要立即扩大角色权限。应先确认缺少的是 My Inbox 入口、任务动作、采购订单读取、附件访问还是后端组织范围,再进行最小范围授权。
SAP 官方教程补充:通知、My Outbox 与日常运营
工作流上线不是项目结束,还需要明确谁负责日常运营。建议至少定义工作流管理员、业务流程负责人、组织与责任主数据维护人、权限管理员和技术支持的职责。
通知与邮件
邮件和 Launchpad 通知用于提醒审批人,但不能替代 My Inbox 中的正式任务状态。邮件链接失效、用户邮箱未维护或通知发送失败时,审批任务可能仍然存在。因此排障时要分别检查“任务是否创建”和“通知是否送达”。
邮件主题应包含足够业务信息,例如采购订单号、公司代码、供应商和金额,但要避免在不安全渠道暴露敏感内容。模板语言、时区、发件人、重发策略和退信处理也应在上线前确认。
My Outbox 与日志
创建者或流程参与人可以通过 My Outbox 和相关日志查看已完成、挂起或进行中的流程,具体功能依版本和授权而定。运营团队应知道从哪里确认:当前步骤、实际收件人、任务创建时间、审批动作、异常信息以及工作流使用的定义版本。
代理与休假
审批人休假前应设置合法代理或替代关系,并明确代理有效期。测试不能只验证代理人能看到任务,还要确认原审批人恢复后任务归属、历史记录和职责分离是否正确。
逾期与积压
建议建立按流程、组织、审批人和逾期天数统计的待办监控。积压可能来自审批人长期不处理,也可能来自收件人规则返回错误人员、任务无法打开或后续步骤失败。运营指标要能区分业务等待与技术错误。
SAP 官方教程补充:版本与部署方式决定可用能力
本文同时引用 SAP S/4HANA Cloud、SAP S/4HANA on-premise 和 SAP Learning 当前课程,目的是补齐概念与配置闭环,而不是暗示所有界面和选项在每个系统中完全相同。
实施前必须确认:
- 产品是 SAP S/4HANA Cloud Public Edition、Private Edition 还是 on-premise;
- 具体发行版、Feature Package Stack 或季度版本;
- Manage Workflows 应用版本和 App ID 是否一致;
- 可用的启动条件、步骤类型、角色和 BAdI 是否存在;
- 重启、返工、通知、模拟和可选步骤是否受版本限制;
- 基础激活是在 IMG、配置活动还是其他配置入口完成;
- 默认自动批准行为和默认工作流要求是什么。
视频录制于 2023 年,界面是 SAP GUI 传统 IMG 与当时系统状态。SAP 官方课程原图可能来自更新的 Fiori 界面。两者放在同一篇文章中用于解释不同层次,不代表读者系统一定与任一截图完全一致。
最稳妥的方法是先在 SAP Help Portal 选择目标产品和版本,再查对应应用帮助;同时在 SAP Fiori Apps Reference Library 核对应用、业务角色、目录和前提条件。配置名称相同也不代表功能细节完全相同。
版本核对不能只停留在“系统里能看到这个菜单”。实施文档中应记录产品全名、发行版、支持包、客户端、应用技术标识、配置入口和官方帮助链接;测试证据也要注明来自哪个系统。开发、质量和生产系统若补丁级别不同,同一工作流定义可能出现字段、选项或校验差异。升级前应重新执行工作流顺序、条件边界、收件人、My Inbox 动作、通知、重启和日志的回归测试,并确认废弃功能或新增默认行为不会改变现有审批制度。若官方资料只描述 Cloud 能力,而目标是 on-premise,必须在目标版本文档中找到对应依据后再采用;反向亦然。
SAP 官方教程补充:工作流命名、版本与变更记录
良好的命名能显著降低后续排障成本。建议名称至少包含业务对象、组织范围和审批特征,例如:
PO-1710-NB-HighValue-v2:1710 公司代码、NB、高金额采购订单第二版;PO-Project-AllValue-v1:所有金额的项目采购订单审批;PO-AutoRelease-Default:最后的默认自动批准流程。
描述中记录业务制度编号、金额口径、币种处理、规则负责人和生效原因。不要把测试名称“Workflow 1”直接带入生产。
每次变更应记录:旧定义、复制得到的新定义、差异、测试证据、批准人、生效时间、顺序变化和回退方案。若只是直接覆盖名称相同的定义,日后很难解释历史采购订单为什么走了不同审批人。
有效期和顺序应作为同一个发布包验证。新定义即使内容正确,只要有效期尚未开始或顺序放错,生产结果仍然错误。停用旧定义前,还要确认它是否影响在途实例;工作流定义状态与已经启动的实例状态不能简单等同。
SAP 官方教程补充:实施前最终检查清单
基础配置
- 采购订单场景
WS00800238已在正确系统和客户端激活; - 目标采购订单凭证类型已启用场景式工作流;
- 与经典发布程序的凭证类型边界已书面确认;
- 配置传输和生产变更窗口已安排。
工作流定义
- 名称、描述、责任人和有效期明确;
- 启动条件覆盖正向、反向和边界样本;
- 工作流顺序经过重叠匹配测试;
- 最后一条默认工作流按目标版本要求配置;
- 步骤条件与启动条件职责清晰;
- 活动定义的变更采用版本化策略。
审批人与任务
- 用户、角色、团队、经理和责任主数据完整;
- 排除采购订单创建者等职责分离要求已落实;
- 任意一人或所有人完成的规则已确认;
- 代理、转发、挂起、逾期和无审批人场景已测试;
- My Inbox 与采购订单后端授权均已验证。
异常与审计
- 拒绝、重复步骤、取消、继续和重启行为已定义;
- 关键字段变更后的重新审批规则已测试;
- 通知、邮件模板和截止时间口径已确认;
- 工作流模拟、日志和变更记录可供审计;
- 新单据、在途单据和已批准后变更单据的切换方案明确。
SAP 官方教程补充:本课结论
第 56 课真正完成的是采购订单灵活工作流的概念介绍和两项基础状态核对:技术场景 WS00800238 已激活,标准凭证类型 NB 与自定义凭证类型 ZNB 已启用场景式工作流。视频没有创建工作流定义,也没有形成采购订单审批任务。
要把灵活工作流真正落地,必须继续完成五件事:用 Manage Workflows 建立有序定义;区分启动条件和步骤条件;保证审批人责任数据与授权完整;用模拟和真实采购订单验证匹配;在 My Inbox 完成批准、拒绝、异常和日志闭环。
最重要的实施原则不是“先把所有开关勾上”,而是让每一层都有可验证的输入和输出:激活层决定能否使用,定义层决定匹配哪条规则,人员层决定任务发给谁,任务层决定如何处理,审计层证明整个过程发生了什么。
主要 SAP 官方资料
- SAP Learning:Setting Up Flexible Workflows in Purchasing
- SAP Learning:Defining Workflows In Sourcing and Procurement
- SAP Learning:Setting up Configuration for Workflows
- SAP Help:How to Configure the Flexible Workflow for Purchase Orders
- SAP Help:Flexible Workflow for Purchase Orders
- SAP Help:Manage Workflows for Purchase Orders(on-premise)
- SAP Help:Manage Workflows for Purchase Orders(Cloud)


