Renault DESADV EDI 对接指南
© All rights reserved. • 西安知行软件有限公司 • 陕ICP备09022277号
在 Renault EDI 对接中,DELJIT 负责告诉供应商“要交什么、什么时候交、送到哪里”;DESADV 则负责告诉 Renault“实际发了什么、怎么装的、托盘和箱号是什么、对应哪张 DN 单”。
Renault DESADV 通常基于 EDIFACT DESADV D96A。本文示例使用 DESADV:D:96A:UN:A01053,其中 A01053 更适合理解为项目使用的消息配置或实施版本标识;除非 Renault 规范明确命名,不建议直接写成通用的“DESADV 53 场景”。
本文基于一份 Renault DESADV 测试报文和 2026 年 6 月项目验证记录整理。Label 前缀、UM/UC、DN 提交等要求具有项目属性,实际实施时应以当前 Renault 工厂、项目指南和客户最新确认结果为准。
DESADV 要解决什么问题?
DESADV(Despatch Advice Message)也常被称为 ASN(Advanced Shipping Notice)。它不是需求预测,也不是交付指令,而是供应商在货物发出前后向Renault提交的发运通知。
一份 DESADV 至少要回答四个问题:
| 问题 | DESADV 中的典型信息 |
|---|---|
| 发哪一单 | BGM+351 发运通知 / DN 编号 |
| 发给谁、卸到哪里 | NAD+CN 收货方、LOC+11 卸货点 |
| 发什么、发多少 | LIN 物料、QTY+12 发运数量、RFF+ON 订单 |
| 怎么包装、如何追踪 | CPS/PAC 包装层级、RFF+AAT 托盘号、GIR 箱号、GIN+ML Label 编号 |
DESADV 的难点不只是生成 EDI 格式,而是让 DESADV、Label、DN 单和前置 DELJIT 的关键字段一致。

一份脱敏 DESADV 示例
下面示例保留原测试报文的业务主线:2 个托盘,每托盘 75 个外箱,每箱 35 件,总计 5,250 件。发送方、接收方、物料号、订单号、托盘号和箱号均已脱敏。
为便于阅读,箱号列表只展示前几箱和最后一箱。省略号不是正式 EDIFACT 内容;生产报文应完整展开箱号,并按实际段数计算 UNT。示例中的 CPS+3++3 / CPS+4++3 是托盘包装标识层;其下 PAC+75++BAC-O-4325 仍对应该托盘上的 75 个外箱。
UNB+UNOB:3+SUPPLIER-DEMO+RENAULT-DEMO+260625:1206+000000001++++++1'
UNH+1+DESADV:D:96A:UN:A01053'
BGM+351+DN-DEMO-001'
DTM+137:202606241400:203'
DTM+132:202606251400:203'
DTM+11:202606241400:203'
MEA+AAX+AAD+KGM:13154'
RFF+CRN:CARRIER-REF-DEMO'
NAD+CN+CONSIGNEE-DEMO::92++RENAULT-DEMO'
LOC+11+UNLOADING-DEMO'
NAD+CZ+SHIPFROM-DEMO::92++SUPPLIER-SITE-DEMO'
NAD+SE+SUPPLIER-DEMO::92++SUPPLIER-NAME-DEMO'
RFF+ADE:SUPPLIER-DEMO'
EQD+TE+TRAILER-DEMO'
CPS+1++1'
PAC+75++BAC-O-4325::92'
QTY+52:35:PCE'
PCI+17'
RFF+AAT:PALLET-000001'
DTM+94:20260624:102'
GIR+3+BOX-000001:ML'
GIR+3+BOX-000002:ML'
...
GIR+3+BOX-000075:ML'
LIN+++PN-DEMO-001:IN++0'
PIA+1+SUPPLIER-PN-DEMO:SA+REV-DEMO:DR'
IMD+++:::PART-DESCRIPTION-DEMO'
QTY+12:2625:PCE'
ALI+CN'
RFF+ON:PO-DEMO-001'
CPS+2++1'
PAC+75++BAC-O-4325::92'
QTY+52:35:PCE'
PCI+17'
RFF+AAT:PALLET-000002'
DTM+94:20260624:102'
GIR+3+BOX-000076:ML'
GIR+3+BOX-000077:ML'
...
GIR+3+BOX-000150:ML'
LIN+++PN-DEMO-001:IN++0'
PIA+1+SUPPLIER-PN-DEMO:SA+REV-DEMO:DR'
IMD+++:::PART-DESCRIPTION-DEMO'
QTY+12:2625:PCE'
ALI+CN'
RFF+ON:PO-DEMO-001'
CPS+3++3'
PAC+1++PAC-O-4325::92'
PAC+75++BAC-O-4325'
PCI+17'
GIN+ML+PALLET-000001'
CPS+4++3'
PAC+1++PAC-O-4325::92'
PAC+75++BAC-O-4325'
PCI+17'
GIN+ML+PALLET-000002'
UNT+198+1'
UNZ+1+000000001'
这份 DESADV 可以还原为:
| 业务信息 | 示例值 | 说明 |
|---|---|---|
| DESADV / DN 编号 | DN-DEMO-001 |
本次发运通知编号 |
| 报文创建时间 | 2026-06-24 14:00 |
DTM+137 |
| 预计到货时间 | 2026-06-25 14:00 |
DTM+132 |
| 发货时间 | 2026-06-24 14:00 |
DTM+11 |
| 收货方 | CONSIGNEE-DEMO |
NAD+CN |
| 卸货点 | UNLOADING-DEMO |
应与 DELJIT、Label、DN 一致 |
| 托盘 | PALLET-000001、PALLET-000002 |
应与托盘 Label 编号一致 |
| 外箱 | BOX-000001 至 BOX-000150 |
每个托盘下逐箱列出 |
| 物料 | PN-DEMO-001 |
Renault 零件号 |
| 每托盘数量 | 2,625 PCE |
75 箱 × 35 件 |
| 总发运数量 | 5,250 PCE |
2 托盘 × 2,625 件 |
包装层级怎么理解?
本示例中的包装关系可以先按实物理解:
本次发运
├─ 托盘 PALLET-000001
│ ├─ BOX-000001 → 35 PCE
│ ├─ BOX-000002 → 35 PCE
│ ├─ ...
│ └─ BOX-000075 → 35 PCE
│
└─ 托盘 PALLET-000002
├─ BOX-000076 → 35 PCE
├─ BOX-000077 → 35 PCE
├─ ...
└─ BOX-000150 → 35 PCE

数量关系很简单:
| 层级 | 包装数量 | 每包装数量 | 小计 |
|---|---|---|---|
托盘 PALLET-000001 |
75 箱 | 35 PCE/箱 | 2,625 PCE |
托盘 PALLET-000002 |
75 箱 | 35 PCE/箱 | 2,625 PCE |
| 合计 | 150 箱 | 35 PCE/箱 | 5,250 PCE |
对应到 DESADV 时,可以理解为两类层级:
这里有三个容易混淆的点:
PAC+75表示该层级下有 75 个指定包装,也就是 75 个外箱。RFF+AAT和GIN+ML都出现托盘号,但段组不同:RFF+AAT在托盘发运明细层,GIN+ML在托盘包装标识层。两者指向同一物理托盘,但不是简单“二选一”。CPS+1++1中,CPS01用于标识当前层级编号,CPS02用于关联父层级,CPS03表示包装层级代码。三个字段含义不同,不能根据数值位置简单判断父子关系。
字段来源与一致性要求
DESADV、Label、DN 单之间最容易出问题的不是语法,而是字段来源不一致。建议按下面方式确定数据源:
| 字段 | 建议来源 | 核对对象 |
|---|---|---|
| 收货方、卸货点 | DELJIT 或 Renault 主数据 | DESADV、Label、DN |
| Renault 零件号、订单号 | DELJIT / ERP 订单 | DESADV、DN、Label |
| 托盘号、箱号 | WMS / 包装绑定记录 | DESADV、Label |
| 包装代码 | Renault 包装规范 / Packaging Agreement | DESADV、Label、包装主数据 |
| 数量 | WMS 出库和包装结果 | DESADV、DN、Label |
| 物料描述 | 物料主数据 | DESADV、Label、DN |
| Label 条码内容 | 当前工厂 Label 规范 | 扫码结果、Label 样张 |
本项目验证中曾重点关注以下问题:
- 托盘 Label 编号要和 DESADV 中的
RFF+AAT/GIN+ML对得上; - 托盘上的箱号要能在 DESADV 的
GIR列表中找到; - 卸货点不能与 DELJIT 或 Label 不一致;
- 物料描述、生产日期、数量要在 DESADV、Label、DN 中保持一致;
- Label 条码内容通常不能只放裸值,需要参考Label规范给对应前缀;
- UM/UC、是否必须提供箱子 Label、DN 是否随同验证,都应以当前 Renault 工厂和项目确认为准。
常见错误
1. 包装数量写错
本示例主线是每托盘 75 箱,所以相关包装层级中的外箱数量应保持 PAC+75。
2. 只填托盘号,不填箱号
如果一个托盘上放了 75 箱,DESADV 里就应列出这 75 个外箱编号。托盘号和箱号不是同一层信息,不能互相替代。
3. Label 与 DESADV 不一致
托盘号、箱号、物料描述、日期、卸货点、数量,一旦 DESADV 和 Label/DN 不一致,就可能导致 Renault 验证失败,即使 EDI 语法本身没有问题。
4. 卖方、发货方、收货方混用
NAD+CN、NAD+CZ、NAD+SE、RFF+ADE 看起来都像公司或供应商代码,但角色不同:
NAD+CN:收货方;NAD+CZ:发货/移除地点;NAD+SE:卖方/供应商;RFF+ADE:供应商相关参考。
这些字段应从 DELJIT、客户主数据和项目配置中继承,不能人工随意互换。
知行之桥如何落地 Renault DESADV
在实际项目中,知行之桥可以把 DESADV 从“人工填 Excel 再转换”升级为自动化流程:

建议至少做四类校验:
- 数量校验:托盘数 × 每托盘箱数 × 每箱数量 = 总发运数量;
- 包装校验:托盘号、箱号、包装代码和 Label 编号一致;
- 主数据校验:收货方、卸货点、物料号、订单号来自同一业务来源;
- 文档校验:DESADV、Label、DN 单中的关键字段一致。
这样可以在发送前拦截包装数量错误、卸货点不一致、Label 条码不匹配、DN 单字段不同步等问题,减少 Renault 验证反复。
上线前检查清单
BGM编号与 DN 单号一致;LOC+11卸货点与 DELJIT、Label、DN 一致;NAD+CN/CZ/SE和RFF+ADE角色没有填反;PAC+75、QTY+52:35、QTY+12:2625、总数 5,250 能对应;RFF+AAT、GIN+ML与托盘 Label 编号一致;GIR箱号列表能对应实际托盘-箱号绑定;- Label 条码扫码结果符合当前 Renault Label 规范;
- 物料描述、日期、数量在 DESADV、Label、DN 中一致;
UNT段数按完整报文重新计算;- 如项目只提供托盘 Label 或唛头,应先取得 Renault 确认。
Renault DESADV 的关键不是“把数据拼成 EDI”,而是把实际出库、包装绑定、Label、DN 单和前置 DELJIT 统一到同一套数据源。只要托盘、箱号、数量和关键主数据能提前校验,DESADV 才能真正支撑 Renault 收货匹配和生产切换。


