SAP S/4HANA MM模块培训 55 - 新输出管理：BRFplus、OPD与采购订单输出

采购订单保存以后，系统究竟要不要产生一条输出、发给哪个供应商、使用打印还是邮件、套用哪张表单，以及失败后在哪里查看状态，这些问题共同构成了采购输出控制。经典 SAP 采购通常通过 NAST 条件技术、事务码 NACE、应用 EF、输出过程和条件记录完成消息确定；SAP S/4HANA 又提供了以决策规则和 Output Parameter Determination 为核心的 Output Control。两套框架的对象、配置入口和运行时模型不同，但不能简单理解为“进入 S/4HANA 后旧框架立即消失”。

本课视频先介绍新输出管理与 BRFplus，比较经典 NAST/NACE 的配置思路，列出采购领域可能涉及的询价、采购订单和采购合同，然后提出“应用配置、技术准备、OPD 规则”三类活动。视频最后进入 SAP GUI 的经典输出控制，选中应用 EF，查看采购订单输出过程 RMBEF1 和输出类型 NEU。讲师刚准备从第一项配置继续讲解，源视频就在句中结束；全片没有打开 OPD，也没有创建决策规则、配置渠道、生成采购订单输出或发送邮件。

因此，本文前半部分严格按视频真实内容和原始 SAP 画面整理；从第一个“SAP 官方教程补充”章节开始，再依据 SAP Help Portal 与 SAP Learning 补齐当前标准概念、采购订单八步参数确定、决策表优先级、渠道与表单、输出项目状态、测试和运维方法。视频里没有出现的操作不会写成讲师已经演示。

版本提示：Output Control 的支持范围、激活方式、字段、渠道和表单与 SAP S/4HANA 版本、部署形态及应用对象有关。实施前必须以目标系统对应版本的官方文档为准。旧资料中的 BRFplus 文件或 ZIP 导入只适用于特定版本或集成场景，不能当作所有当前系统的固定前提。

本课目标与阅读方法

学完本文，应当能够回答以下问题：

1. 经典 NAST/NACE 输出控制和 SAP S/4HANA Output Control 的核心对象分别是什么？
2. 视频真正完成了哪些讲解和 SAP 操作，缺失的演示从哪里开始？
3. BRFplus 与 Output Parameter Determination 分别承担什么角色？
4. 为什么采购订单的输出参数要分成输出类型、接收方、渠道、打印、邮件、表单和相关性等步骤？
5. 决策表为何要把具体规则放在一般规则之前？
6. Print、Email、EDI 分别依赖哪些业务数据和技术配置？
7. 从采购订单业务事件到输出项目、表单渲染和最终传输，完整链路如何运作？
8. 输出项目未生成、参数错误、状态 Error 或接收结果错误时，应按什么顺序排查？
9. 新旧输出框架共存时，项目怎样避免重复输出、遗漏输出和不可维护的规则？

本文使用三层证据：

源视频容器时长为 00:05:47.681，最后一条字幕结束于 00:05:46.759，音视频能够正常解码到结尾。这说明课程中断不是本地下载损坏，而是 YouTube 上的源文件本身就在讲师说“首先看配置”时结束。

1. 视频中的课程议程：新输出管理、差异与业务规则

视频开场把主题称为 SAP S/4HANA 新输出管理，也称为 BRFplus，并给出三项计划：

• 介绍 SAP S/4HANA 新输出管理；
• 比较新框架与前一课已经讲过的经典输出管理；
• 说明如何设置 BRFplus 业务规则，并据此产生采购输出。

这里需要先区分两个容易混用的名字。BRFplus 是业务规则框架，用来表达条件与结果；Output Control 是业务输出能力；Output Parameter Determination 则是业务用户维护和查看输出参数规则的入口。把整套新输出管理简单叫作“BRFplus”便于口头交流，但实施文档中应使用准确名称，否则很容易把规则引擎、配置应用和运行时输出项目混成一个对象。

视频把经典输出管理概括为一组条件技术对象：条件表、访问顺序、输出类型、过程以及条件记录。它们分别回答“用哪些字段查找”“按什么顺序查找”“要产生什么消息”“哪些消息组合适用于当前应用”和“实际业务取值是什么”。新 Output Control 则把输出参数组织为决策规则，并围绕接收方、渠道、表单和输出相关性形成输出项目。

可以用下面的表格理解视频的对比重点：

视频把新框架描述为比经典条件技术更集中、更容易理解。这可以作为讲师的课程观点，但不能推导出“所有项目都更简单”。如果企业已经拥有成熟的 NACE 配置、定制程序、打印基础设施和外部接口，迁移框架会涉及回归测试和运维模式变化；如果企业新建支持 Output Control 的应用，新框架的决策表和输出项目模型又可能更适合业务规则透明化。真正的复杂度取决于应用范围和现有资产，而不是名称新旧。

2. 视频 SAP 实操：进入经典输出控制应用 EF

视频在 00:04:55 左右进入 SAP S/4HANA 系统，打开经典 Conditions for Output Control。主界面列出多个应用代码，其中 EF 对应 Purchase Order。这个画面非常重要，因为它证明讲师此时是在回顾旧框架，而不是已经进入新 Output Parameter Determination。

应用代码决定一组条件技术对象所属的业务范围。采购订单使用应用 EF，询价、库存管理和发票校验等对象各有自己的应用。即使某些对象名称相近，也不能跨应用直接复制输出过程或条件记录；访问字段、业务事件和处理程序可能完全不同。

讲师随后选择 EF。界面上方仍然是 Condition records、Procedures、Output types 和 Access sequences 等经典页签，这些就是前一课输出确定所使用的对象。

进入 Procedures 后，视频出现采购订单过程 RMBEF1，描述为 Purchase Order。过程相当于一个输出类型容器，它定义哪些输出类型参与当前应用、顺序如何，以及是否带有需求例程等控制。只有定义过程还不够，项目还需确认过程怎样分配给具体业务场景，以及条件记录是否能找到有效结果。

随后讲师进入 Output Types，画面列出 NEU，名称为 Purchase order。经典输出类型还可能带有伙伴功能、处理程序、表单、媒介和时间等设置。视频只是打开列表，没有进入 NEU 明细，也没有创建条件记录或实际打印采购订单。

因此，这四张 SAP 原始画面能够支持的结论只有：

1. 目标环境仍可进入经典输出控制；
2. 经典采购订单使用应用 EF；
3. 视频中存在过程 RMBEF1 和输出类型 NEU；
4. 讲师以此说明旧框架仍然可用。

它们不能支持“新 Output Control 已启用”“OPD 已配置”“采购订单已经成功输出”或“经典框架已完成迁移”等结论。

3. 视频提到的采购业务范围

从 MM 视角，讲师提到新输出管理可用于询价、采购订单和采购合同。这三个对象都可能需要把业务文件发送给供应商，但它们的触发时点、输出类型、字段、表单和业务后果不同。

3.1 询价

询价输出通常向一个或多个供应商发送询价内容。项目要核对询价应用是否使用目标输出框架、供应商接收地址是否完整、邮件或 EDI 渠道是否可用，以及回标过程是否依赖特定格式。不能因为采购订单支持某个字段，就假定询价决策表具有相同字段。

3.2 采购订单

采购订单是本课重点。输出可能在创建、审批完成或变更后触发，也可能先生成待处理输出项目，再由调度任务或用户提交。项目应明确首次发送、变更订单、催单、撤销或重新发送的规则，避免供应商收到重复或前后不一致的版本。

3.3 采购合同

采购合同属于长期协议，输出内容和有效期控制与单次采购订单不同。合同修改后是否重新输出、发送给哪个伙伴、是否需要附加条款，都应依据合同应用的官方配置和企业流程设计，不能直接套用采购订单参数。

视频中“可用于这些采购对象”的表达应理解为课程概览。真正实施时，必须在目标版本文档中逐个确认应用对象是否支持 SAP S/4HANA Output Control、需要怎样激活，以及有哪些功能限制。

4. 视频中的输出参数概念图

讲师用一张非软件示意图解释 Output Parameter Determination：系统根据采购订单数据决定输出类型、接收方、渠道、表单和相关设置。原图是英文概念图，因此本文按原意用中文重新制作，没有直接使用英文截图。

这组参数可以按四个问题理解：

参数并不是彼此独立的。例如选择 Email 后，系统还需要接收地址、发件人、主题、正文和附件表单；选择 Print 后，还需要打印机、假脱机设置和表单渲染；选择 EDI 后，需要接收系统、通信通道、消息映射和接口监控。决策表只解决业务规则的一部分，不能替代底层技术服务。

5. 视频提出的三类准备活动

讲师把启用新输出管理归纳为三项工作：先做应用配置，再完成一次性 BRFplus 技术准备，最后在 OPD 中建立规则。这个思路有助于把技术底座与业务规则分开，但第二项必须加上版本边界。

5.1 应用配置

项目首先要确认目标采购应用是否支持 Output Control、是否需要激活应用对象类型，以及表单、邮件、打印或 EDI 的基础设置。这里的“配置”不是只切换一个开关，还包括角色权限、输出表单、主表单、发件人域、打印队列等关联对象。

5.2 BRFplus 技术准备

视频提到由 BASIS 团队上传 Excel 文件并完成一次性活动。部分旧版或特定集成文档确实包含 BRFplus 文件、ZIP 或存储库对象导入步骤，但这些步骤不是所有当前系统的统一操作。实施人员应只在目标版本官方文档明确要求时执行，并记录对应 SAP Note、应用对象和传输路径。不能从视频口述直接推导出要在任何系统中手工导入文件。

5.3 OPD 业务规则

业务或功能顾问在 Output Parameter Determination 中维护决策表，确定输出类型、接收方、渠道、各渠道设置、表单模板和输出相关性。规则需要经过模拟、代表性采购订单测试和实际传输验证。

5.4 视频未提完但项目必需的第四项：端到端验证

即使三类配置都保存成功，也不能证明采购输出可用。项目还要创建或变更采购订单，检查是否生成正确的输出项目，预览表单，提交或调度处理，再确认打印机、邮箱或 EDI 接收端得到预期结果。只有业务规则、表单渲染和技术传输同时成功，输出链路才算完成。

6. 视频结束边界：没有出现 OPD 实操

视频末尾，讲师再次强调经典输出仍然存在，随后回到讲义，把旧输出写成 NACE、新输出写成 BRFplus，并列出 Configuration、BRFplus one-time activity、Set up the rules - OPD。最后一句是准备先看配置，源视频随即结束。

全片没有出现以下动作：

• 打开 Output Parameter Determination；
• 选择采购订单业务对象；
• 维护任意决策表条件或结果；
• 建立输出类型、接收方、渠道、打印机或邮件规则；
• 选择采购订单表单模板；
• 运行规则模拟；
• 创建或变更采购订单；
• 预览、提交、重试或调度输出项目；
• 查看 Completed 或 Error 状态；
• 验证打印、邮件或 EDI 接收结果。

从下一节开始，内容不再声称来自视频演示，而是依据 SAP 官方教程补齐。

SAP 官方教程补充 1：新旧输出框架如何选择

SAP 官方的 SAP S/4HANA Output Control 说明，新输出控制与既有输出框架可以并存，并不存在把所有应用同时强制迁移的通用要求。企业应按应用对象决定是否采用 Output Control，并核对该对象在目标版本中的功能范围。

一个稳健的框架决策应依次回答四组问题。

1. 目标应用是否支持

先明确是采购订单、询价、合同还是其他业务对象，再查询目标版本文档。不要只看系统中能否打开某个通用应用，也不要用销售订单教程替代采购订单支持说明。应用对象不支持时，决策表再完整也无法产生预期运行时结果。

2. 当前系统已经使用什么

盘点经典 NAST 配置、输出类型、条件记录、表单、处理程序、用户出口、增强、打印设备、邮件接口和外围系统。已有资产越多，切换框架的回归范围越大。对新实施而言，也要确认 Best Practice 或预交付配置是否已经激活。

3. 业务要求是否超出新框架范围

列出所有渠道、接收方、表单、语言、附件、签章、批量调度、变更重发、归档和合规要求，并逐项对照支持范围。不能把“支持 Email”理解为企业所有邮件格式、附件和加密需求天然可用。

4. 如何避免双重输出

如果同一采购应用同时留下经典和新框架的触发路径，可能出现重复发送。迁移方案必须明确切换点、回退策略、规则冻结和监控责任，并使用同一组测试采购订单验证只产生一套预期输出。

SAP 官方教程补充 2：BRFplus、OPD与输出项目的职责

Output Control 并不是一张决策表。它至少包含业务单据、参数确定、表单生成、输出项目处理和传输渠道五个层次。BRFplus 用于表达条件与结果；Output Parameter Determination 提供规则维护入口；业务单据保存或达到某个业务状态后，系统依据规则形成输出项目；随后输出项目经过表单渲染和渠道处理。

SAP Learning 的官方软件界面示例展示了决策表单元格、条件列、结果列以及多条件表达方式。下图原图来自 SAP Learning，属于 SAP 软件界面，因此保留英文原始画面；它是销售场景的教学示例，用于理解决策表结构，不能当作本文采购订单的实际配置截图。

在决策表中，每一行把一组输入条件映射到结果。例如，单据类型、组织数据和业务伙伴属性可能共同决定渠道；另一张表再根据渠道确定对应设置。SAP Learning 的 Determining Output Parameters 强调规则顺序和条件组合的重要性。

为了避免职责混乱，可以把对象分工写入设计文档：

当“采购订单没有发出去”时，先判断是哪一层没有产物：没有输出项目通常偏向应用或规则；有输出项目但表单失败偏向渲染；表单正常但邮件失败偏向传输。这样的分层比反复修改决策表更有效。

SAP 官方教程补充 3：采购订单的八个输出参数确定步骤

SAP Help Portal 的 How to configure output parameter determination for purchase orders? 按八个步骤组织采购订单参数确定。它们可以归纳为业务对象、渠道、呈现和相关性四组依赖。

第 1 步：Output Type

确定要产生哪种业务输出。采购订单常见标准输出类型为 PURCHASE_ORDER，官方示例还会限定适用的采购单据类型。输出类型不是表单文件名，而是业务输出的语义入口。

第 2 步：Receiver

确定接收方和伙伴角色。采购订单通常面向供应商，官方示例中可见伙伴角色 LF。实际地址仍来自业务伙伴或供应商主数据；决策表返回正确角色并不等于地址一定有效。

第 3 步：Channel

确定 Print、Email、EDI 等渠道。规则可以根据采购组织、单据类型、供应商或其他可用字段选择渠道。可用渠道必须以目标应用文档为准。

第 4 步：Printer Settings

当渠道为 Print 时，确定打印机、输出设备或相关打印设置。若打印队列不可达，参数确定仍可能成功，但输出项目会在处理阶段失败。

第 5 步：Email Recipient

当渠道为 Email 时，确定收件人。规则可能使用业务伙伴地址或特定接收方式。项目要测试主收件人、抄送、无邮箱、多个地址和失效地址等情况。

第 6 步：Email Settings

确定邮件主题、正文模板、发件人和附件相关设置。官方采购订单说明中会出现标准邮件模板，例如 MM_PUR_PO_DEFAULT_TEMPLATE；实际可用名称与版本相关。

第 7 步：Form Template

确定表单模板。官方采购订单示例可见 MM_PUR_PURCHASE_ORDER。模板需要能够绑定当前采购订单数据，并与表单服务和主表单配置协同工作。

第 8 步：Output Relevance

判断当前业务情形是否应当产生或处理输出。相关性规则可以阻止不应发送的文档进入后续处理。它不是“邮件是否发送成功”的状态，而是业务层面的输出资格判断。

八个步骤之间存在依赖。没有渠道，就无法判断需要打印还是邮件设置；没有接收方，邮件即使生成也无处发送；没有表单模板，渠道正常也可能得不到附件；相关性为否时，前面参数再完整也不应产生实际输出。

SAP 官方教程补充 4：决策表优先级与默认规则

决策表的可维护性取决于规则粒度和顺序。一般原则是把条件更具体的例外放在前面，把适用范围更广的一般规则放在后面，最后才是默认规则。

假设企业希望：特定采购组织下的某个供应商使用 EDI；同一采购组织的其他供应商使用 Email；其余情况使用 Print。规则设计可以是：

如果把“采购组织 1010 → Email”放在供应商例外之前，供应商 A 可能永远命不中 EDI。若默认规则过于宽泛，也可能把本应阻止的采购订单自动打印。规则评审不应只检查语法，而应检查覆盖关系、不可达行和业务后果。

规则设计的五项检查

1. 条件来源明确：每个字段在采购订单保存时是否有值，值来自主数据还是用户输入？
2. 例外可解释：为什么某供应商、组织或单据类型需要不同结果，谁批准？
3. 默认结果安全：未命中任何明确规则时，是不输出、进入人工处理，还是选择一个默认渠道？
4. 顺序可验证：使用边界值和重叠条件模拟，确认实际命中行。
5. 变更可追踪：规则修改通过传输或受控配置流程进入生产，并保留审批和回归记录。

最小测试数据集

一张决策表至少要有：每条具体规则一个正向样例、一个不应命中的反向样例、一般规则样例、默认规则样例、必填字段缺失样例和主数据异常样例。仅用一张“正常采购订单”测试，无法发现覆盖顺序和例外泄漏。

SAP 官方教程补充 5：采购订单规则示例的正确读法

SAP 官方采购订单配置说明给出了标准值和条件示例。它们适合帮助理解对象关系，但不能脱离目标版本直接复制。

一个可验证的采购订单输出设计可以写成以下矩阵：

示例不是生产规则

生产规则必须从业务场景反推。比如企业要求采购订单只有审批完成后才允许外发，那么测试就要覆盖未审批、部分审批、最终审批、审批后变更和撤回。若供应商 A 只接收 EDI，系统还必须处理其接口不可用时的失败状态，不能默默改用 Email，除非业务明确批准了替代渠道。

接收方质量比规则更早

很多“邮件没有发出”的根因不是规则，而是供应商主数据缺少邮箱、邮箱被维护在错误地址用途、伙伴角色不正确或采购订单使用了不同伙伴。上线前应对需要电子输出的供应商做完整性检查，并把无有效地址的记录纳入整改清单。

变更订单要单独设计

采购订单首次发送成功，不代表后续变更一定正确。项目要明确哪些字段变更需要重新输出、是否标记为变更版本、供应商如何识别差异，以及重复保存是否会产生重复消息。真实测试应至少覆盖数量、价格、交货日期、交货地址和删除标识等企业关心的变更。

SAP 官方教程补充 6：Print、Email与EDI的渠道依赖

渠道决定后，系统还要得到该渠道所需的全部参数。官方采购订单配置说明提供了不同渠道的必填关系，项目应据此建立自己的渠道矩阵。

Print

打印输出通常依赖输出设备、假脱机系统、表单渲染和网络打印队列。测试不能停在 PDF 预览；还要在目标打印机上验证纸张、分页、条码、字体、双面、份数和高峰期队列。生产系统中的打印设备名称也可能与质量系统不同，因此传输后要做环境级复核。

Email

邮件输出至少涉及接收地址、发件人、允许的域、主题、正文、附件表单和 SMTP/邮件服务。项目应验证中文和英文主题、长供应商名称、多个收件人、退信、垃圾邮件策略、附件大小和敏感信息要求。预览 PDF 成功只能证明表单层正常，不能证明邮件已投递。

EDI

EDI 输出需要目标接收系统、消息格式、伙伴协议、通信通道、映射和接口监控。决策表确定 EDI 只是业务选择；真正的发送、确认和重处理仍由集成链负责。测试应覆盖技术确认、业务确认、重复消息、顺序和失败重发。

多渠道和排他性

部分场景允许同一业务单据产生多个接收方或多个渠道，部分场景要求排他。企业要明确“供应商同时收到 EDI 和 PDF 邮件”是需求还是重复。如果只允许一个渠道，应通过规则和测试确保不会同时命中；如果需要多个渠道，应分别跟踪状态，而不是把一个渠道成功当作整单成功。

SAP 官方教程补充 7：基础配置与官方 SAP 界面示例

Output Control 的规则之下还有基础配置。SAP Learning 的公有云教程展示了 Central Business Configuration 中 Output Management 相关活动，包括默认邮件发件人、允许的发件和收件域、为输出分配单据类型、表单模板和邮件模板等。下图是 SAP 官方软件界面原图，属于 Cloud 配置示例；本地部署系统的入口和活动可能不同，不能照图寻找完全相同菜单。

这张界面提醒我们把配置分为三层：

1. 应用激活层：目标应用对象是否启用 Output Control，是否有预交付内容和必要角色；
2. 共享基础层：表单服务、主表单、邮件发件域、打印管理和接口基础设施；
3. 业务规则层：Output Parameter Determination 中的条件和结果。

当项目只维护第三层而忽略前两层时，常见现象是规则模拟看起来正确，但业务单据没有输出项目，或者输出项目有参数却无法生成和发送。

关于旧版 BRFplus 导入步骤

部分 SAP 官方集成资料描述过 BRFplus ZIP、Excel 文件或特定存储库对象的导入与绑定刷新。这些资料可以解释视频里“BASIS 一次性活动”的来源，但必须同时记录其适用版本、产品组合和 SAP Note。当前项目只有在目标版本官方安装或集成指南明确要求时才执行；否则不应把旧教程步骤主动移植到新系统。

权限也属于基础条件

规则维护、表单配置、采购订单处理、输出项目查看、调度和重试通常属于不同角色。测试用户权限过大可能掩盖生产权限问题。上线前应按真实岗位验证：配置人员能否维护规则，采购员能否预览和提交，运维人员能否查看错误和重试，普通用户是否被限制访问不应看到的输出内容。

SAP 官方教程补充 8：输出项目状态与处理动作

SAP Help Portal 的 Working with Output Items 说明了输出项目的运行时状态。常见状态包括 In Preparation、To Be Output、Completed 和 Error。不同应用可用动作可能不同，但状态能够帮助确定问题发生在业务准备、待处理、已完成还是错误阶段。

In Preparation

输出项目已经存在，但仍处于准备阶段。用户可能还可以调整某些输出参数。若项目长期停留在该状态，应检查应用业务状态、是否需要用户提交，以及是否存在未满足的前提。

To Be Output

项目已准备好等待处理。它可能由立即处理、用户提交或计划任务发送。若长时间不动，应检查调度任务、处理时间和后台作业，而不是先改决策表。

Completed

系统处理成功，但“Completed”不必然等于外部业务方已经阅读或接受。Email 可能已经交给邮件服务，EDI 可能还需要对方确认，Print 可能只进入打印队列。关键输出应保留接收端验证。

Error

处理失败。应先读取输出项目的具体消息，再决定检查表单、打印、邮件或接口。没有错误文本就直接重试，往往只会产生重复失败，甚至造成重复发送。

SAP Help 的 Manage Purchase Orders 还说明，应用界面可能提供添加、删除、提交、重试、复制或预览输出项目等动作。动作可用性取决于状态和应用版本，例如删除通常只允许在特定准备状态下进行。培训和操作手册必须以实际系统按钮为准。

SAP 官方教程补充 9：从采购订单到打印、邮件或EDI的完整链路

SAP 官方 How Does Output Control Work? 把 Output Control 放在业务应用、参数确定、表单与渠道之间。完整链路可拆成四段。

第一段：业务事件

采购订单创建、变更、审批或达到其他业务状态后，应用决定是否触发输出处理，并提供采购组织、单据类型、供应商、金额、语言和状态等上下文。若字段在触发时尚未确定，规则可能得到意外结果。

第二段：参数确定

系统读取决策表，组合输出类型、接收方、渠道、渠道设置、表单和相关性。多张表之间可能存在依赖，所以排障时要找出具体哪一步返回空值或错误值。

第三段：表单生成

表单服务使用业务数据和表单模板生成 PDF 或其他输出内容。主表单可能负责企业标识、页眉页脚和通用片段。表单错误可能来自缺少模板、数据绑定、字体、服务不可用或自定义字段不兼容。

第四段：渠道传输

Print 进入假脱机和打印队列，Email 进入邮件服务，EDI 进入集成通道。传输成功后仍需按业务风险决定是否检查实际接收结果。

链路的关键控制点如下：

SAP 官方教程补充 10：端到端测试与故障定位

测试必须覆盖业务规则、内容和技术传输三个维度。只在 OPD 中看决策表，不能证明采购订单会产生输出；只在采购订单中预览 PDF，不能证明邮件或打印成功；只看到 Completed，也不能证明供应商收到正确版本。

情形一：没有输出项目

按以下顺序检查：

1. 目标采购应用是否支持并已激活 Output Control；
2. 当前采购订单业务状态是否触发输出；
3. 输出相关性是否返回允许；
4. 输出类型和接收方规则是否命中；
5. 单据字段、伙伴和组织数据是否与测试预期一致；
6. 是否仍有经典框架或其他配置影响触发路径。

情形二：有输出项目但参数不正确

检查每个确定步骤的命中行、条件覆盖和默认规则。特别关注：供应商伙伴角色、地址用途、单据类型、采购组织、渠道、表单模板和语言。使用规则模拟时保存输入和结果，确保测试采购订单的数据与模拟输入完全一致。

情形三：预览或表单生成失败

检查表单模板是否存在并分配正确、表单服务是否可用、数据绑定是否包含必填数据、自定义字段是否已经扩展到表单、字体和语言是否支持。若标准模板成功而自定义模板失败，应把问题定位到模板或扩展，而不是继续修改渠道规则。

情形四：输出项目状态 Error

先读取错误消息和技术日志，再根据渠道检查：Print 查看假脱机和设备，Email 查看发件配置、域和邮件服务，EDI 查看接口消息和接收确认。修复后再重试，并确认重试不会产生重复业务消息。

情形五：状态成功但供应商结果不正确

核对实际收件地址、附件版本、PDF 内容、语言、采购订单变更号和接收端时间。对 EDI 要比较发送消息与对方确认；对 Email 要查看退信或网关日志；对 Print 要确认实际队列和纸张结果。

推荐测试矩阵

SAP 官方教程补充 11：实施与运维治理

输出控制横跨 MM 业务、主数据、规则、表单、BASIS 和集成。若没有清晰责任边界，业务会把所有失败都交给功能顾问，技术团队又可能只证明服务在线而没有验证采购结果。

设计阶段

建立应用与框架决策、业务场景清单、规则矩阵、渠道矩阵、表单清单和接收方数据要求。每条规则写明业务理由、优先级、责任人和测试用例。对经典框架已有资产做完整盘点。

配置阶段

分别维护应用激活、OPD 规则、表单、邮件、打印和接口，并记录传输或配置变更。不要让生产规则依赖未记录的手工步骤，也不要直接在生产中试错。

测试阶段

从规则模拟开始，进入采购订单业务测试，再执行真实渠道传输和接收端验证。测试证据至少包含采购订单号、输入条件、命中规则、输出项目参数、预览内容、状态、技术日志和接收结果。

上线阶段

冻结规则，核对生产环境设备、域、模板和接口；明确切换时间，避免经典和新框架重复触发；准备失败监控、人工替代和回退方案。上线后重点观察首次发送、变更订单和批量处理。

运维阶段

为规则变更建立审批和回归机制，定期复核默认规则、无效接收地址、长期 Error 输出和重复发送。业务变化、供应商接入方式变化或表单调整都可能要求重新测试。

规则变更的回归影响分析

Output Parameter Determination 的一条规则往往同时影响多个采购组织、单据类型和供应商。修改前应先计算规则覆盖范围，而不是只拿提出需求的那张采购订单验证。比如把采购组织 1010 的默认渠道从 Print 改为 Email，会影响所有没有命中更具体规则的订单；如果其中部分供应商没有邮箱，变更可能把原本可以打印的订单转成 Error。变更申请应附上受影响条件组合、预计单据数量、主数据完整率、回归用例和回退值。

回归测试还要检查规则之间的相互遮挡。新增一条范围较宽的规则可能让后面的具体规则变成不可达，删除一条规则又可能使订单落入默认结果。测试人员应保存变更前后的模拟结果，对同一批代表性输入做差异比较，并逐项确认差异是否符合批准的业务需求。对于高风险采购输出，还应在质量系统执行真实邮件、打印或 EDI 测试，而不是只比较 OPD 返回值。

表单变更也会产生跨层影响。增加自定义字段可能导致数据绑定、分页、字体或附件大小变化；修改邮件主题可能触发外部网关策略；更换打印设备可能改变纸型和字符集。因此，规则、表单和渠道配置虽然由不同团队维护，生产变更窗口和回归证据应统一管理。只有这样，团队才能判断一次失败究竟来自业务规则还是同时上线的技术配置。

SAP 官方教程补充 12：可直接执行的上线检查表

框架与范围

• 已确认目标版本、部署形态和采购应用对象支持范围；
• 已明确继续使用经典框架、采用 Output Control 或分阶段迁移；
• 已识别并控制经典与新框架的重复触发风险；
• 已记录视频或旧资料中版本相关步骤，不把它们当成通用配置。

规则与主数据

• 八个参数确定步骤均有设计和责任人；
• 具体规则、一般规则和默认规则顺序已评审；
• 每条规则都有正向、反向和边界测试；
• 供应商伙伴、地址、邮箱、语言和 EDI 属性已检查；
• 变更订单、重新发送和重复输出策略已明确。

表单与渠道

• 表单模板和主表单在目标环境可用；
• 标准与自定义字段均能正确渲染；
• Print 已验证真实设备和队列；
• Email 已验证发件域、收件地址、主题、正文、附件和退信；
• EDI 已验证消息、接口、确认和重处理；
• 多渠道或排他规则符合业务要求。

运行与运维

• 能在采购订单中看到并解释输出项目；
• 能识别 In Preparation、To Be Output、Completed 和 Error；
• 调度任务和处理时间已验证；
• 错误日志、重试权限和人工替代流程已建立；
• 生产监控、规则变更审批和定期复核责任已落实。

SAP 官方教程补充 13：关键结论

1. 视频讲清了新输出管理、BRFplus 与经典 NAST/NACE 的概念差异，但实际 SAP 操作只回顾了应用 EF、过程 RMBEF1 和输出类型 NEU。
2. 源视频在正式配置展开前结束，没有任何 OPD、决策表、渠道、表单或采购订单输出演示。
3. SAP S/4HANA Output Control 与经典输出框架可以按应用共存，不能写成进入 S/4HANA 后必须全量替换。
4. BRFplus 负责业务规则，Output Parameter Determination 是规则维护入口，输出项目负责运行时处理，表单和渠道负责内容与传输。
5. 采购订单参数确定可按输出类型、接收方、渠道、打印设置、邮件接收方、邮件设置、表单模板和输出相关性八步理解。
6. 决策表应把具体规则放在一般规则之前，并通过模拟和真实采购订单做双重验证。
7. Print、Email 和 EDI 各自依赖不同基础设施；参数确定成功不等于最终接收成功。
8. 排障要沿业务触发、参数确定、表单生成、渠道处理和接收端逐层定位。
9. 输出管理上线需要 MM、主数据、表单、BASIS 和集成团队共同验收，并持续治理规则和失败输出。

SAP 官方教程补充 14：官方参考资料

• SAP S/4HANA Output Control
• Output Parameter Determination
• How to configure output parameter determination for purchase orders?
• How Does Output Control Work?
• Determining Output Parameters
• Introducing SAP S/4HANA Output Control
• Working with Output Items
• Manage Purchase Orders
• Classic purchasing output based on the condition technique