一、先讲一个真实的场景
晚上八点，计划员小张还在加班。
客户的交付计划改了三次，他要登录 Portal 一条条核对；仓库说明天要发货，他要把发货单号、物料明细、包装信息逐项录进系统；财务催库存数据，他又得从 ERP 里导出来，整理成 Excel 发邮件。
如果你是一家汽车零部件供应商，对这一幕一定不会陌生。
客户那边轻飘飘一句"以后请通过 EDI 对接"，落到供应商头上，就是一连串灵魂拷问：
- EDI 到底是个啥？跟我现在的 Portal 操作有什么区别？
- DELFOR、DESADV、INVRPT 这些报文分别管什么？
- 听说要走 SupplyOn 平台，它是干什么的？我们自己能不能直连客户？
- 项目要投入多少人、多少时间？测试不通过会不会影响交付？
二、先搞懂：EDI 到底解决了什么问题？
EDI（Electronic Data Interchange，电子数据交换），说白了就是：让客户的系统和你的系统"直接对话"，中间不经过人。
以前的信息流是这样的：
客户系统 → 打印/导出 → 邮件或 Portal → 人工下载录入 → 你的 ERP
用了 EDI 之后变成：
客户系统 → 标准报文 → 你的 ERP（全自动，零人工）
别小看这个变化。人工环节每少一个，就少一类错误：录错数量、看错日期、漏掉订单变更、发货通知录晚了导致客户收货异常……这些坑，做汽车供应链的都踩过。
更重要的是，汽车主机厂和一级供应商的交付节奏是以小时计的。需求计划凌晨下发、当天上午就要响应，靠人工根本跑不赢。EDI 不是"锦上添花"，而是进入客户供应链体系的入场券。
三、SupplyOn 是什么角色？为什么客户都选它？
很多供应商第一次听到 SupplyOn，会以为它只是又一个要注册账号的 Portal。这是最大的误解。
准确地说，SupplyOn 在这个链路里是"B2B Integration Hub"——一个站在客户和你之间的供应链协同枢纽。你可以把它理解成一个"翻译官 + 分拣中心 + 调度台"：
- 翻译官：把客户系统的数据格式，翻译成你 ERP 能读懂的语言（Message Mapping）；
- 分拣中心：根据工厂代码、供应商代码等信息，把报文准确路由到对应对象（Routing）；
- 调度台：管理你和客户之间的连接参数、证书、测试环境、报文监控（Partner/Entity Configuration）。
为什么客户喜欢用这个模式？因为对供应商来说，点对点直连意味着每接一个大客户就要重建一套连接、重做一套映射。而通过 SupplyOn，连接和映射框架可以复用，新增客户或报文时按配置扩展就行。
一句话总结：供应商不是直接连客户，而是通过 SupplyOn 这个"枢纽"接入客户的供应链网络。
四、三条核心数据流，一次讲明白
整个 EDI 对接，90% 的业务量都集中在三类报文上。先把这张表看懂，项目就懂了一半：
报文代码 | 业务含义 | 传输方向 | 里面装的是什么 |
DELFOR | 交付计划 / 需求预测 | 客户 → 供应商 | 未来几周/几个月要交什么料、交多少、在哪个时间窗口交付、冻结期和预测期怎么划分 |
DESADV | 发货通知（ASN） | 供应商 → 客户 | 我发了什么货、什么时候发的、走哪家物流、多少箱/多少托、对应哪张订单 |
INVRPT | 库存报告 / 库存变动 | 客户 ↔ 供应商（视客户规范） | 工厂/库位的库存数量、在途、已分配、消耗记录 |
这三者串起来，正好是一条完整的供应链闭环：
客户告诉你"要多少"（DELFOR）→ 你按需求备货发货，并告诉客户"我发了"（DESADV）→ 双方同步"还剩多少"（INVRPT）
再补充一个高频问题：INVRPT 的方向没有统一标准。有的客户用它看供应商库存（主动要你报），有的用于寄售/VMI 场景回传消耗。项目启动第一天就要和客户确认清楚，别想当然。
五、SupplyOn 的六个亮点，供应商要会用
把 SupplyOn 当成"传文件的网盘"，那就亏大了。这几个能力用好了，能省大量返工：
能力 | 实际价值 | 供应商该做什么 |
标准连接（AS2 / OFTP2） | 传输通道成熟稳定，有 QAS 测试和 PRD 生产两套独立环境与证书 | 提前开通 QAS，证书有效期、更换流程建台账，别等过期才发现 |
汽车行业流程沉淀 | DELFOR / DESADV / INVRPT 等场景有标准实施路径和 Dummy Message 测试样例 | 用足官方测试资产，别自己拍脑袋造数据 |
主数据路由治理 | 靠 Plant、OrgCode、Supplier Code、物料号、PO 号、行项目等字段精确分拣报文 | 建立"客户编码 ↔ ERP 编码"对照表，指定唯一维护人 |
Mapping 支持 | 把客户报文结构转换成你的 ERP 能处理的格式 | 以客户最新 Message Guideline 为唯一依据，邮件口头承诺不算数 |
SIT / UAT 实施服务 | 从系统集成测试到用户验收，有完整支持流程 | 拉着计划、物流、仓储、采购一起测，别让 IT 单独扛 |
多客户复用 | 一套连接框架可复用到多个客户和业务场景 | 新项目评估时先看能否复用已有配置，控制边际成本 |
六、从签约到上线，全流程怎么走？
SupplyOn Seller EDI 的标准实施路径，可以概括为一句话：
范围确认 → 项目启动 → 搭建连接 → 映射开发 → QAS 测试 → UAT 验收 → 生产配置 → 上线 → 稳定期
阶段 | 核心任务 | 容易踩的坑 |
① Scope 确认 | 锁定客户范围、工厂、物料、报文类型、传输协议、时间表 | 范围含糊，测试阶段不断加需求 |
② Kick-off | 双方项目经理、EDI/ERP/物流/采购接口人到齐，建沟通机制 | 只有 IT 参加，业务后期不认账 |
③ Connectivity | 开通 QAS，交换证书/IP/端口，跑通连通性 | 防火墙、IP 白名单没提前申请，卡几周 |
④ Mapping | 按 Guideline 做字段映射，准备样例数据 | 按旧版文档开发，客户已升级规范 |
⑤ QAS 测试 | Dummy Message 端到端测试，覆盖正向和异常场景 | 只测正常流程，异常一上线就抓瞎 |
⑥ SIT/UAT | 业务方验证结果并签字 | 业务没人参与，签字流于形式 |
⑦ PRD 配置 | 生产环境路由、证书、主数据切换 | QAS/PRD 参数混用 |
⑧ 上线 + 稳定期 | 首批报文重点监控，2-4 周并行对账 | 上线就撒手，小问题积累成大故障 |
七、五个最容易翻车的地方（血泪经验）
结合大量汽车供应链 EDI 项目的共性问题，我总结了五个高发坑位：
坑 1：主数据不一致——头号杀手
ASN 发出去，客户系统匹配不上订单；库存报出去，被平台拒收。十有八九是 Plant Code、物料号、PO 行项目这些主数据对不上。
对策：上线前冻结一版主数据映射字典，双人复核；新增物料/工厂，先走完映射再启用业务。
坑 2：只测"能通"，不测"能用"
文件在系统间跑通了，但业务侧看到的单据是错的——数量单位不对、日期差一天、订单行对不上。技术验收 ≠ 业务验收。
对策：QAS/UAT 必须由计划、物流、仓储、采购一起签字，谁用谁验。
坑 3：异常场景没想全
重复发货怎么办？订单取消但货已备了怎么办？证书到期正好是周末怎么办？这些不在测试里预演，上线后就是事故。
对策：测试用例必须覆盖取消、变更、重发、超交、短交、断连、证书过期等异常分支。
坑 4：时区和单位这种"小事"
交付窗口差 8 个小时，客户看到的是"严重延迟"；数量单位差一个数量级，库存直接变天文数字。
对策：时区、单位、小数位、日期格式写进映射规范，用真实样例数据回归验证。
坑 5：并行期没有退出标准
上线后新旧流程并行，数据两边不一致，出了问题互相甩锅。
对策：上线前就约定并行期对账口径、差异处理时限，以及"达到什么条件算正式切换"。
八、写在最后
回到开头的小张。上了 EDI 之后，他的晚上八点会变成什么样？
客户的交付计划自动流进 ERP，系统直接生成采购和生产建议；发货过账的瞬间，ASN 自动生成并推送；库存数据按约定频率自动同步。他要做的，从"录入员"变成了"异常处理员"。
这就是 EDI 对供应商的真正价值：不是多上一套系统，而是把人从重复劳动里解放出来，去管那些真正需要人判断的事。
而 SupplyOn 的价值，在于它把"连接、翻译、路由、治理"这些脏活累活平台化了——供应商不用 reinvent the wheel，专注把自己的数据和流程理顺就行。
最后送一张 Go-live 检查清单：
☐ 拿到客户最新版 EDI 规范和 Message Guideline（含代码表）
☐ 主数据映射字典完成并冻结版本
☐ QAS 连通性测试通过，证书台账建好
☐ 三类报文正向 + 异常场景全部通过
☐ UAT 业务四方（计划/物流/仓储/采购）签字
☐ 监控、告警、失败重发、应急预案就绪
☐ 并行期对账口径和切换条件书面确认
