Odette核心报文格式解析与五阶段部署优先级排序实战

1. 一张对接需求表引发的思考：先做哪个报文真的值得认真排序

上个月，客户把一整套主机厂对接需求丢给我，清单里列了一长串报文格式，大部分都围绕 Odette 标准，光规范文档就有几百页。他们给的期限是三个月，要求覆盖 DELFOR、DELJIT、DESADV、RECADV、INVOIC 这些核心报文格式。团队里第一个问题就是：能不能先把 Odette 的核心报文格式梳理清楚，然后做一个部署优先级排序，我们按顺序推进？

这个问题乍一听像项目管理的常规操作，但真正回答起来并不简单。我先说一个容易被新入行的人搞混的点：Odette 并不是某一种具体的报文文件，它是一套由欧洲汽车行业相关组织制定和维护的标准体系，覆盖了传输层的 OFTP/OFTP2 协议、应用层的报文格式定义，以及一系列业务规则。我们平时嘴里的"Odette 报文"，实际指的是遵循 Odette 推荐规则、采用 UN/EDIFACT 语法编写的业务消息。DELFOR 是交付预测，DELJIT 是 JIT 交付指令，DESADV 是发货通知，这些才是真正意义上的报文格式。

为什么要单独讨论部署优先级？因为我见过太多项目把顺序搞反。有的团队觉得财务开票最着急，一上来就做 INVOIC，做完才发现发票需要引用 DESADV 的发货单号和 RECADV 的收货确认数据，而这两块还没搭起来，财务只能每天手工补数。也有团队一上来就啃价格目录 PRICAT，觉得主数据先做万事大吉，结果计划部门天天问"今天的 DELJIT 收到没有"，生产计划照样靠传真和邮件在跑。排序的本质是顺着业务依赖关系走，而不是顺着某个人觉得"哪个重要"来走。

这篇文章就想干两件事：第一，把 Odette 标准里那些核心报文格式掰开揉碎讲一遍，讲清楚每个报文的业务场景、关键字段、常见坑；第二，给出一套可以实际操作的部署优先级排序方法，并附上我个人多次反复调整后觉得比较稳妥的五阶段推进路径。不是书本上的标准答案，是踩过坑之后总结出来的实战思路。

1.1 Odette 是一套体系，不是某一种报文文件

Odette 这个名称的全称是 Organisation for Data Exchange by Tele Transmission in Europe，最初就是为了解决欧洲汽车行业供应链中各方系统不互通的问题。它解决的不是"报文长什么样"这一个问题，而是从连接方式、文件传输、报文内容到业务规则一整套都做了约束。这也是为什么你会在一个 Odette 项目里同时听到 OFTP2 协议、ODETTE ID、UN/EDIFACT 语法这些看起来像不同领域的东西。

报文格式只是这套体系的应用层。传输层上，Odette 推荐使用 OFTP（Odette File Transfer Protocol），升级版 OFTP2 加了 TLS 加密和证书认证，等价于现在很多行业用的 AS2 在传输安全上的角色。也就是说，你要和一家欧洲主机厂做 Odette 对接，通常先要把 OFTP2 连接打通，把双方的证书和 ID 交换好，然后才能在上面收发各种业务报文。传输层和应用层是两件事，但部署时一定要作为一个整体来考虑，因为它们互相依赖。

实际项目里经常出现一种局面：客户发来一页对接清单，里面写着"要求支持 OFTP2 连接，报文使用 Odette 标准，消息类型包括 DELFOR、DESADV、INVOIC 等"。不懂的人会把这几行字当成三种无关联的需求，懂的人会立刻意识到，这其实是一条从传输通道到业务语义的完整链路。排优先级的时候，不能只看报文种类，还要把连接方式、证书有效期、通道测试这些前置条件一起纳入规划，否则排出来的计划永远是空中楼阁。

1.2 为什么"先做哪个报文"是真实业务约束

很多人会觉得，开发嘛，多开几个线程并行做不就完了？在正规 IT 项目里，并行确实能加快速度，但 Odette 报文之间天然存在数据引用关系，这种关系决定了并行是有上限的。

举个最典型的例子：供应商收到主机厂的 DELFOR 或 DELJIT 之后，安排生产、备料、发货，发货时生成 DESADV 发给主机厂。DESADV 里要引用 DELFOR/DELJIT 中的订单号、行号、物料号、交付日期等信息。如果你的 DESADV 映射里没有任何计划类报文数据可参考，那业务人员就只能手工在发货界面录订单号。短期看能应付，时间一长必然出错。INVOIC 更明显，发票要引用订单号、发货通知号、收货差异数据，前面几个报文没跑通，发票的自动校验逻辑根本无米下锅。

所以排优先级的时候，得先看一个报文依赖哪些数据源，看它自己的业务数据会被哪些下游环节使用。数据依赖关系才是排顺序的硬约束，项目里程碑和人员安排都是跟着这个走的。

2. 报文格式的底层逻辑：先把 EDIFACT 语法这条命脉接上

2.1 EDIFACT 报文的五个层级和三个分隔符

要理解 Odette 核心报文格式，绕不开 UN/EDIFACT。EDIFACT 是联合国行政、商业和运输业电子数据交换规则，Odette 在汽车行业沿用了这套语法。EDIFACT 报文不是像 JSON、XML 那样有明显的标签层级，它是典型的"位置即语义"的紧凑型结构，用分隔符区分数据。

一个完整的 EDI 交换（Interchange）结构从外到内分为五层：交换（Interchange）包含功能组（Functional Group），功能组包含报文（Message），报文包含段（Segment），段由数据元（Data Element）组成，数据元又可能是复合数据元（Composite Data Element）。平时我们重点研究的对象是报文这一层，看到的一段文字如 LIN+1++OEM-99001:BP' 就是一个段，段名是 LIN，后面跟了三个数据元，第三个数据元是复合的，用冒号把 CODE 和 QUALIFIER 隔开。

EDI 报文里最常见的三个分隔符是：段终止符，默认是单引号 '；数据元分隔符，默认是加号 +；复合数据元分隔符，默认是冒号 :。这些分隔符可以在 UNA 段里覆盖，不同厂商的实现也可能有差异。你如果打开一个别人发来的报文发现"为什么每段结尾不是引号而是一个感叹号"，先别怀疑对方写错了，极有可能是在 UNA 里改了服务字符。

初学阶段最容易犯的错是试图用 XML 那种"看标签名"的方式去理解 EDIFACT。XML 里 <quantity>100</quantity> 一目了然，EDIFACT 里 QTY+113:100:PCE' 则要靠限定符 113 才知道这 100 是什么意思。这种紧凑设计带来的是传输效率，牺牲的是可读性。所以学习路径上，我建议先把段名和限定符的对应关系背熟，起码做到看到 QTY 知道是数量，看到 DTM 知道是日期，看到 NAD 知道是当事方。

用一个简短的 DELFOR 报文片段体验一下：

code复制UNH+1+DELFOR:D:97A:UN'
BGM+221+FP100123+9'
DTM+137:20250115:102'
NAD+SU+WUGO-LOGO+长沙某汽车部件有限公司::9'
NAD+BY+OEM-202+某欧洲乘用车制造公司::9'
LIN+1++OEM-99001:BP'
QTY+113:1000:PCE'
DTM+2:20250201:102'
UNT+9+1'

这个片段里，UNH 是报文头，表示报文类型是 DELFOR，版本是 D 版本 97A；BGM 是业务消息开始段，221 表示这个报文在业务上是一个交付预测；DTM 表示文档生成时间；NAD+SU 是供应商，NAD+BY 是买方；LIN 是行项目，物料号 OEM-99001；QTY 是数量，113 这个限定符通常表示订购量，PCE 是件数；DTM+2 表示要求的交货日期；UNT 是报尾。实际生产环境里还会出现大量 RFF、PAC、GIN 这种段，但看报文的思路就是先看骨架段，再逐层看细节段。

2.2 通用段位像个乐高积木：UNH/DTM/NAD/RFF/LIN/QTY

报文的种类千差万别，但常用的"基础段"就十来个，像乐高积木一样拼来拼去。搞懂这些，后面解析什么报文都有底。

UNH 和 UNT 是每个报文必有的头和尾。UNH 里有报文参考号和报文类型标识，消息类型标识像 DELFOR:D:97A:UN 这种，依次是类型、版本、目录、维护机构。看到这个标识你就能确认这份文件是哪个目录版本下的哪个报文。UNT 里有段计数和报文参考号，用于校验报文完整性。

BGM 是业务消息开始段，算是报文的"标题"。BGM+221 表示交付预测，BGM+351 表示发货通知，BGM+380 表示发票，不同报文类型对应的文档代号在 EDIFACT 里是标准化的。后面跟的字符串是业务单据号，比如发货单号、发票号，这个编号是后续对账和引用的关键索引。

DTM 是日期时间段。EDI 里的日期格式默认是 CCYYMMDD，时间还有 24 小时制 HHMM，后面带限定符 102 表示格式是 CCYYMMDD。关键是 DTM 前面带什么限定符，比如 DTM+137 是文档生成日期、DTM+2 是要求交货日期、DTM+11 是发货日期、DTM+50 是收货日期，不同限定符表示日期在不同业务环节的含义。解析 DTM 的时候要看清楚限定符，否则把要求交货日期当成实际发货日期，整个计划逻辑就乱了。

NAD 是当事方段，后面跟着当事方限定符和编号。SU 是供应商，BY 是买方，ST 是发货人，CN 是收货人，DP 是交货地。后面那个编号一般是双方的业务代码，比如主机厂供应商代码。RFF 是引用段，用来表示"本报文关联的其他单据"，比如 RFF+ON 表示采购订单号，RFF+SI 表示发货单号，RFF+AAU 表示交货单号。引用段是把不同报文串起来的关键。

LIN 是行项目段，代表一票业务里的明细行，每一行可能是不同物料。QTY 是数量段，限定符不同含义不同，有些限定符表示订货量，有些表示累计交货量。MOA 和 TAX 是金额和税段，主要在财务类报文里用。PIA 是附加产品编号段，常用来换同一物料在不同体系下的编号。

熟悉这些基础段的语义，看任何 Odette 报文都不会觉得是天书。就像练武术先学会马步，后面的套路都是这些基础动作的组合。

2.3 版本目录、代码表和报文样例的绑定关系

很多老工程师拿到一个新的 EDI 需求，第一件事不是问报文格式，而是问"用哪个版本"。原因很简单：EDIFACT 标准和 Odette 推荐都是一个持续演进的体系，不同年份有不同目录，比如 D97A、D99B、D00B、D01B。目录版本不同，报文里允许出现的段、数据元、代码值都会有差异。

打个比方，DELFOR 这个报文在 D97A 和 D00B 两个版本里的结构可能大体一致，但某个辅助段在旧目录里允许使用，新目录里被废弃或加了限制。供应商如果按旧版写映射，对接新版主机厂时会发现报文在验证器上大量报错。D97A 在汽车行业里至今还在大量使用，很多主机厂的接口文档一上来就写明"报文版本 D97A"，这不是因为新版本不香，而是存量系统太多，切换成本高。

代码表也很关键。同一份报文中出现的单位代码、包装代码、交货条款代码、国家代码，都要按照目录里的标准代码表来维护。比如单位代码 PCE 表示件，KGM 表示公斤，LTR 表示升，这些是按 UN/ECE 推荐标准来的。代码值传错了，轻则报文被拒，重则系统把 100 公斤当成 100 件入库，后果很严重。

所以规范文档通常会把三样东西绑在一起：目录版本、代码表、样例报文。解析任何 Odette 报文之前，先确认你手里的样例报文和代码表是不是同一版本。碰到不同主机厂用不同版本的情况，建议在系统里把版本作为参数配置管理，而不是写死在代码里，这为后面切换版本省了很多事。

3. 核心报文逐个拆解：从业务环节理解每个报文存在的意义

3.1 DELFOR/DELJIT：计划入口，先发制人

DELFOR（Delivery Forecast）是主机厂发给供应商的滚动交付预测。业务场景是：主机厂的生产计划部根据一段时间内的生产排期，把未来若干周的物料需求预测发给供应商，供应商据此排产能、备料、锁长周期物料。报文频率一般是每周或者每日，内容按物料、交付日期、数量排一个时间表。供应商系统收到 DELFOR 后，要把这些预测数据导入 ERP 或生产计划系统，作为物料需求计划（MRP）的输入。

DELFOR 里最关键的几个字段：物料编号（供应商编号或主机厂编号）、交货日期、预测数量、交货工厂/仓库代码、累计交付数量。累计交付数量是一个容易忽略的字段，它表示到某个时间点为止已经交付的总量，供应商端可以做累计校验，防止重复交货或漏交。有些主机厂会在 DELFOR 里区分不同类型的需求，比如"A 类预测"和"B 类确认订单"，类型不同责任约束不同，映射时要特别留意类型代码。

DELJIT（Delivery Just-In-Time）则完全不同，它是 JIT 生产模式下的交付指令，典型特征是频次高、提前期短、粒度细。主机厂按生产线的实时节拍，以小时甚至分钟节奏向供应商推送"今天下午 2 点到 3 点之间送 200 件、按顺序放在缓冲区的第 5 个工位"。这种场景下，DELJIT 里的时间信息不再是日期，而是精确到分钟的交货窗口；数量也不一定是固定值，有些排序件还会带整车序列号或者车型代码。

DELJIT 的优先级一定要高于其他报文，因为它直接连着产线。接收端一旦延迟或解析出错，产线可能停线，停线一小时的损失是以万计的。很多项目把 DELJIT 放在第一阶段做，不是因为简单，而是因为业务风险最大。DELJIT 的映射里，时间窗口、数量校验、重复消息处理这三个点是最容易出问题的，后面会细说。

3.2 DESADV/RECADV：发货与收货的镜像联动

DESADV（Dispatch Advice）是发货通知，逻辑上就是"我发了哪一票货、发了什么、发到哪里、怎么发的"。供应商在货物实际发运之前或装车同时，把发货信息通过 DESADV 发给主机厂仓库。主机厂仓库拿到这份通知后，可以在货物到货前做好收货准备，比如分配货位、预约卸货时间、比对预到货和实际到货。

DESADV 的报文结构比计划类报文复杂很多，因为它要描述运输和包装两个维度。运输维度用 TDT 段表示运输科次、运输方式，EQD 段表示设备（比如集装箱号、挂车号）；包装维度用 PAC 段表示包装层级，PAC 下面可以嵌套 GIN 段，用于标识外箱条码、托盘条码、序列号。一个典型的 DESADV 可能是：一个托盘上有 10 个纸箱，每个纸箱里某种零件 200 件，每箱有条形码。这个层级结构在报文里要完整表达，因为主机厂收货时是逐层扫描入库的。

在项目交付中 I 个常见的错误是只做了"零件-数量"的一维映射，忽略了包装层级。结果入库扫描时发现单号对上了，但托盘条码和箱条码的关联关系没传过来，仓库只能撤销重扫或者手工录。DESADV 的映射一定要和生产端的装箱逻辑对齐，事先和业务部门确认好包装粒度，绝不能拍脑袋。

RECADV（Receiving Advice）是收货通知，方向相反，主机厂在验收货物后把收货结果发给供应商。RECADV 包含哪些物料收到了多少、哪些有差异、差异原因代码是什么。它的业务价值主要体现在对账环节：供应商依据 RECADV 核对 DESADV 中的发货数量，确认差异，为后续发票和付款打基础。

很多项目会在前期故意放低 RECADV 的优先级，因为收货确认业务用网页端也能看。但从全链路自动化角度看，RECADV 是财务自动化的前提，没有它，发票匹配只能靠人工拿 Excel 对。所以我会把它放在财务闭环那一阶段做，而不是完全不做。

3.3 INVOIC/REMADV：财务闭环的最后一公里

INVOIC 是电子发票报文，供应商在发完货、开完票之后把发票信息通过 EDI 发给主机厂。INVOIC 里包含发票号、开票日期、供应商代码、买方代码、采购订单号、发货通知号、行项目（物料、数量、单价、金额）、折扣、税费、总金额等信息。

技术上 INVOIC 的映射比 DESADV 简单，难点在业务规则的准确性。开票金额必须和发货数量、价格协议一致，税务代码也要按当地税法配置。不同主机厂在 INVOIC 里使用的合同条款、付款条件和扣款逻辑不同，供应商的财务系统需要先做到这些规则的可配置。现实中很多项目做到这里卡住，往往不是因为 EDI 报文解析有问题，而是公司财务系统本身的税率、科目、冲销逻辑不支持那么细的规则。

REMADV（Remittance Advice）是付款通知，通常是主机厂发给供应商的银行付款明细。它告诉供应商"我已经发起了付款，金额是多少，扣了哪些款项，如果对账有差异要看这里的扣款代码"。REMADV 的解析难度低，但业务价值大——它解决了"钱为什么少付了"的问题。付款差额常常由赔付、返利、包装退回、质量扣款等组成，每个扣款项都有一个代码，供应商财务需要把这些代码映射到自己的费用科目里。

INVOIC 和 REMADV 放一起做的好处是：前者生成开票数据，后者接收付款明细，两个报文放到一张对账逻辑里看，财务人员才能完成"发票金额 vs 扣款明细 vs 实付金额"的三方核对。如果不放在同一阶段做，中间这段时间财务就只能手工对账，自动化率上不去。

3.4 ORDERS/ORDCHG/PRICAT：订单和主数据链路

很多人以为这个供应链里只有预测和发货，没有采购订单。实际上售后件、备件、维修件、项目开发阶段的采购，走的还是标准采购订单链路。ORDERS 是采购订单，ORDCHG 是订单变更，ORDCHG 和 ORDERS 的区别在于它只传变化的部分，供应商收到后要自动更新原订单。

PRICAT 是价格目录报文，主机厂或采购方通过它向供应商发布物料的最新价格信息。PRICAT 里的关键是价格有效期，起点日期和终点日期决定了这个价格适用于哪个时间段。供应商收到 PRICAT 后，ERP 里的价格主数据要按有效期刷新。价格数据是财务系统的基石，如果价格错了，后面 INVOIC 里出的金额全错，所以 PRICAT 虽然业务简单，在部署优先级里却属于"基础数据类报文"，要早于财务类报文。

ORDERS/ORDCHG 和 PRICAT 的共同点是都涉及主数据管理。供应商代码、物料代码、价格条款，这些主数据不一致，EDI 报文即使格式正确，业务上也无法落地。我建议在实施这些订单类报文之前，先做一轮主数据治理，特别是物料编号的映射表，因为同一个物料在主机厂编号、供应商内部编号、包装代码之间可能是三个完全不同的字符串。

3.5 小结：九种报文一张表看清方向

把常用的九种 Odette 核心报文串起来，覆盖了供应链里从"计划—发货—收货—财务"这么一条主线。见下表。

这张表不是让我们把九个报文当并列任务看，而是要顺着业务链路的先后去认识它们的依赖关系。下一部分直接说排序方法。

4. 部署优先级排序：我给客户定的五阶段推进法

4.1 排序的三个维度：业务风险、技术依赖、实施周期

我在给客户做方案时，从来不用拍脑袋的"重要程度"来排序，而是用三个维度的加权打分来定优先级：业务风险、技术依赖、实施周期。

业务风险，维度上考虑"这个报文如果不上线，对生产或交付的损失有多大"。DELJIT 延迟一天可能造成产线停线，风险分极高；INVOIC 晚做一个月，财务对账难度上升，但短期不至于停线，风险分略低；PRICAT 如果不上线，价格更新靠邮件也能撑一阵。业务风险越高，越要往前排。

技术依赖，维度上考虑"这个报文的数据源是否已经具备"。DESADV 要引用计划类报文的订单号，INVOIC 要引用 DESADV 数据。如果上游报文还没做，下游报文做出来的也只能是半自动。依赖性越强的报文，越应该排在依赖上游之后。

实施周期，就是评估映射和测试的工作量。DELFOR 的结构相对简单，实施周期短；DESADV 因为包装层级复杂，实施周期长；INVOIC 涉及财务系统和税法规则，周期也不短。两个候选报文如果在业务风险和技术依赖上打平，优先做实施周期短的，可以快速建立项目信心，同时为后续复杂报文积累经验。

这三个维度并不是等权的。业务风险权重最高，因为停线和交付违约是供应商承担不起的；技术依赖次之，它是硬约束；实施周期更多是在前两者相同情况下的调剂因素。

4.2 五阶段部署顺序：连接、计划、发运、财务、对账

基于上面的维度，我在多个项目里反复调整后，最常用的一套五阶段部署顺序是下面这样。

阶段零，先把 OFTP2 连接和证书交换做完。这一步不属于任何报文，但它是所有报文的地基。没有可靠的双向文件传输通道，后面所有开发测试都无从谈起。这里要完成的交付物不是代码，而是"测试文件能成功发送到对方测试服务器并收到回执"。很多项目把连接测试当成例行公事，压到最后一周才做，结果证书配置、防火墙策略一个个出问题，把整个上线计划拖垮。

阶段一，做计划类报文，重点说 DELJIT 和 DELFOR。原因很简单：业务风险最高，但实施难度中等偏下。做完这个阶段，计划部门就能摆脱传真和邮件，通过