华硕ASUS EDI 项目实施方案分享
© All rights reserved. • 西安知行软件有限公司 • 陕ICP备09022277号
1. 背景
本项目是一个围绕供应链协同展开的 EDI 报文交换项目，核心目标是通过标准化报文，实现物料、订单、变更、发货、确认、反馈等业务信息的自动流转。
项目涉及的主要报文遵循 ANSI X12 标准，覆盖从物料基础数据同步到采购订单下达、订单变更、仓库发货、ASN 发货通知、发票确认以及业务结果反馈的完整链路。
本项目的重点不只是完成 EDI 文件传输，而是确保每一类报文都能准确表达业务含义，并在处理过程中满足项目需求的前提下，保持方案的统一和完整性。
2. 需求
本项目需求可分为两大类：业务需求和方案需求。
2.1 业务需求：报文标准及业务释义
业务需求的核心是明确项目中涉及哪些 EDI 报文，以及每类报文在实际业务中的含义。
| 报文编号 | 报文标准名称 | 中文业务含义 | 所属阶段 | 业务说明 |
|---|---|---|---|---|
| 832 | Price/Sales Catalog | 物料信息 / 产品目录 | 基础数据阶段 | 用于传递物料主数据、物料清单、厂商主数据和来源清单等信息，是后续订单、BOM、发货等业务的基础。 |
| 850 | Purchase Order | 采购订单 | 采购阶段 | 用于客户向供应商下达正式采购需求，通常包含订单号、采购方、供应方、物料、数量、价格、交期等信息。 |
| 860 | Purchase Order Change | 采购订单变更 | 采购阶段 | 用于对已下达采购订单进行调整，例如数量变更、交期变更、物料行调整或订单取消等。 |
| 855 | Purchase Order Acknowledgment | 采购订单确认 | 确认阶段 | 用于供应方反馈采购订单是否接受，形成 850 订单的业务确认闭环。 |
| 865 | Purchase Order Change Acknowledgment | 采购订单变更确认 | 确认阶段 | 用于供应方反馈 860 订单变更是否接受，形成订单变更的业务确认闭环。 |
| 940 | Warehouse Shipping Order | 仓库发货指令 | 发货阶段 | 用于指示仓库执行发货动作，包含订单、物料、数量、收货信息及发货状态等内容。 |
| 945 | Warehouse Shipping Advice | 仓库发货确认 | 发货阶段 | 用于反馈仓库实际发货结果，需与原始 940 发货指令建立关联。 |
| 856 | Advance Ship Notice | ASN 发货通知 | 收货准备阶段 | 用于提前通知收货方即将到达的货物信息，包含 ASN 编号、PO 关联、包装层级、托盘 / 箱信息、拼板数量及发货明细等。 |
| 810 | Invoice | 发票 | 结算阶段 | 用于传递发票或账务确认相关信息，支撑采购与结算业务闭环。 |
| 824 | Application Advice | 应用处理结果反馈 | 反馈阶段 | 用于反馈业务报文的接收、解析或处理结果，包含处理 code、订单号、错误信息等内容。 |
2.2 方案需求
方案需求是在业务需求基础上，进一步明确系统需要具备的处理能力。
2.2.1 报文识别与分流能力
方案需要支持多类 ANSI X12 报文的接收、解析、生成与发送。系统在接收到报文后，需要根据交易集编号识别报文类型，再进入对应业务处理流程。
- 832 进入物料数据处理流程。
- 850 进入采购订单处理流程。
- 860 进入订单变更处理流程。
- 940 进入仓库发货指令处理流程。
- 824 进入结果反馈处理流程。
2.2.2 业务语义处理能力
方案需要准确表达不同报文的业务含义，不能只做字段搬运或格式转换。850 表示客户正式下达采购订单，860 表示对已有采购订单进行变更，855 表示对采购订单的确认结果，865 表示对订单变更的确认结果，940 表示仓库发货指令，945 表示仓库实际发货确认，856 表示 ASN 发货通知，824 表示业务处理结果反馈。
因此，方案需要确保每类报文中的关键字段能够准确承载业务语义，并与实际业务动作保持一致。
C 创建 -> F 取消 -> R 重置 -> A 接受
方案需要避免状态跳转错误，例如未创建就取消、未取消就重置等情况。
2.2.3 异常反馈与结果追踪能力
方案需要支持处理结果反馈、错误定位和关键编号追踪。当报文接收、解析、转换或业务处理出现异常时，需要通过 824 应用反馈报文返回处理结果。反馈内容应包含返回编号、处理时间、处理 code、订单号、错误信息、成功或失败标识。
同时，方案需要保留关键业务字段，包括订单号、ASN 编号、发货指令号、物料号等，便于后续核对业务结果和定位异常原因。
3. 方案简介
3.1 整体设计思路
整体方案采用“统一入口、按报文分流、按业务语义处理、按结果反馈闭环”的设计思路。系统首先接收或生成 EDI 报文，然后根据交易集编号识别报文类型。识别完成后，进入对应业务处理模块，完成解析、映射、业务校验、状态判断、确认生成或结果反馈。
3.2 总体流程图
3.3 分阶段方案说明
3.3.1 基础数据阶段：832 物料信息
832 是整个业务链路的起点，用于同步物料相关基础数据。该报文包含物料主数据、物料清单、厂商主数据、来源清单、BOM 层级关系，以及主料、辅料、替代料关系。
832 的处理重点是保证物料编码、BOM 层级、替代料逻辑和来源信息准确。由于 BOM 结构存在层级和替代规则，后续订单和发货能否准确处理，很大程度上取决于 832 数据是否完整、准确。
3.3.2 采购阶段：850 与 860
850 用于正式采购订单下达，代表客户发起采购需求。处理时需要关注订单头、采购方、供应方、物料行、数量、价格、交期等信息。
860 用于订单变更，必须与原始 850 建立关联。处理时需要识别变更对象和变更内容，例如数量变更、日期变更、物料调整或订单取消。
该阶段的重点是保证订单与变更之间的关联关系清晰，避免订单变更脱离原始订单单独处理。
3.3.3 确认阶段：855 与 865
855 是对 850 采购订单的确认，865 是对 860 订单变更的确认。两类确认报文的作用是形成业务闭环，明确采购订单或订单变更是否被接受。处理时需要保证确认报文能够准确引用原始订单或原始变更信息，确保双方对订单状态理解一致。
3.3.4 发货阶段：940、945 与 856
940 用于发送仓库发货指令，是发货阶段的重要起点。该报文不仅包含订单、物料、数量、收货信息，还包含发货状态。项目中 940 支持 C/F/R/A 等状态，必须按照业务顺序处理。
以 940 仓库发货指令为例，项目中支持以下状态：
| 状态 | 业务含义 | 处理要求 |
|---|---|---|
| C | Create，创建发货指令 | 必须作为发货业务的起始状态。 |
| F | Cancel，取消发货指令 | 必须在已有创建记录后才能执行。 |
| R | Reset，重置发货指令 | 通常用于取消后重新处理。 |
| A | Accept，接受发货指令 | 通常在重置后或符合条件时接受。 |
945 用于反馈仓库实际发货结果，需要与 940 建立明确关联。处理时需要保留原始发货指令中的关键字段，确保实际发货结果能够匹配到原始指令。
856 用于 ASN 发货通知。该报文用于提前告知收货方即将到达的货物信息，包括 ASN 编号、PO、包装层级、托盘或箱信息、拼板数量和发货明细。项目中需要特别关注一个 PO 对应一个 ASN、多个 PO 可共享同一 ASN 编号的业务规则。
3.3.5 结算阶段：810 发票确认
810 用于传递发票或账务确认相关信息，支撑采购与结算业务闭环。处理时需要确保发票信息能够与订单、发货结果建立对应关系，重点关注订单号、物料、数量、金额、发票编号等字段。
3.3.6 反馈阶段：824 应用处理反馈
824 用于反馈业务报文的接收、解析或处理结果。它不直接承载采购或发货动作，而是用于说明某一业务报文是否被成功处理。处理重点包括提取返回编号、处理时间、处理 code、订单号、错误信息，并区分成功或失败结果。
4. 业务测试流程及注意事项
4.1 测试目标
业务测试应围绕完整报文链路展开，验证报文格式、类型识别、字段映射、业务含义、状态顺序、确认闭环和异常反馈。
4.2 测试流程
4.2.1 832 物料信息测试
需要确认物料主数据、物料清单、厂商主数据、来源清单是否完整，重点检查物料编码、BOM 层级、主辅料关系、替代料关系和旧料优先规则。
4.2.2 850 与 855 测试
重点检查订单号、采购方、供应方、物料编码、数量、价格、交期等字段是否正确，并验证 850 与 855 是否形成完整业务闭环。
4.2.3 860 与 865 测试
测试时需要先准备已存在的原始订单，再发送变更报文，重点检查变更报文是否能关联原始订单、变更类型是否识别正确、变更前后数量和日期是否准确、物料行号是否匹配。
4.2.4 940 与 945 测试
940 重点验证状态流转：C 创建 -> F 取消 -> R 重置 -> A 接受。需要覆盖正常创建、创建后取消、取消后重置、重置后接受，以及未创建直接取消等异常场景。945 重点检查是否能关联原始 940，以及发货指令号、订单号、物料、数量和实际发货结果是否一致。
4.2.5 856 ASN 测试
重点检查 ASN 编号、PO 对应关系、包装层级、托盘或箱信息、拼板数量是否正确，并覆盖多个 PO 共用同一 ASN 编号的场景。
4.2.6 810 发票测试
重点检查发票编号、发票金额、订单号、发货结果、物料、数量和金额是否与业务单据一致。
4.2.7 824 反馈测试
需要覆盖成功和失败场景，确认返回编号、处理时间、处理 code、订单号、错误 code、错误信息是否准确，并判断是否能区分接收失败、解析失败或业务处理失败。
4.3 注意事项
- 报文格式需符合 ANSI X12 标准，包括 ISA、GS、ST 等控制结构完整。
- 交易集编号必须与业务场景一致。
- 订单号、物料号、ASN 编号、发货指令号等关键编号必须可追踪。
- 确认类报文必须与原始业务报文形成闭环。
- 状态类报文必须验证顺序约束，不能只验证字段是否存在。
- ASN 测试必须覆盖单 PO、多 PO、拼板数量等场景。
- 824 必须覆盖成功与失败反馈，确保异常可定位。
- 810 需要与订单和发货结果保持一致，避免账务信息与业务单据不匹配。
5. 总结
华硕 项目体现了 EDI 报文在供应链协同中的核心价值：通过标准化报文，让物料、订单、变更、发货、确认、结算和反馈等业务动作形成自动化闭环。
832 物料同步 -> 850 采购订单 -> 860 订单变更 -> 855 / 865 业务确认 -> 940 发货指令 -> 945 发货确认 -> 856 ASN 通知 -> 810 发票确认 -> 824 结果反馈
本项目的关键经验在于：EDI 项目实施中，报文标准只是基础，真正影响项目质量的是对业务规则、状态顺序、字段语义、异常反馈和跨报文关联关系的理解。
只有将报文格式与实际业务流程结合起来，才能保证华硕与客户之间的供应链数据交换稳定、准确、可追踪。
