企业官网建设流程全解析

在汽车供应链中，供应商通常不会只接收一种需求报文。

DELFOR 更偏向中长期预测，用于备料、产能和生产节奏规划；DELJIT 则更接近短周期的交付执行指令，用于告诉供应商：本次应按什么时间窗口、什么包装、什么叫料参考，把多少零件送到哪个 Renault 收货位置。

Renault 使用EDIFACT DELJIT D98B报文传递此类即时交付指令。Renault 规范中也将该报文称为CALDEL，业务类型为Shipping Instructions。

本文结合 Renault DELJIT D98B 规范与一份按规范整理的脱敏示例报文，说明 DELJIT 与 DELFOR 的区别、报文中各段的业务含义，以及供应商在 EDI 对接时应如何把它转换为可执行、可校验、可追踪的交付计划。

Renault DELJIT 是什么？

DELJIT（Delivery Just In Time Message）即即时交付报文。它面向更靠近执行层的物流协同，通常用于 Renault 向供应商发布短周期叫料、装运或交付要求。

一份 Renault DELJIT 不只是“交多少件”，还会同时说明：

• 本次交付指令的唯一编号和报文创建时间；
• 计划提货窗口与 Renault 预计收货窗口；
• 买方、收货方、发货/移除地点和供应商身份；
• 生产序列状态，本次是否为新的交付序列；
• 物料对应的 Renault 零件号、物料描述和采购订单号；
• 卸货点、目的地或装配点；
• 本次应交付数量、包装代码、每包装数量；
• RAN、补货号或包裹参考等执行层追踪信息；
• 当前流类型，例如 GPI、L3P、KAN、MOD、MPR 及其 RAN 变体。

对于供应商而言，DELJIT 是连接“客户需求”与“实际出货”的关键报文。它通常会驱动仓库拣货、包装、装车、ASN/DESADV 生成以及后续交付追踪。

Renault DELJIT 需求概览

DELJIT 与 DELFOR 的核心区别

DELFOR 和 DELJIT 都可以承载物料、数量、地点和时间，但它们在业务语义上不应混用。

可以简单理解为：DELFOR 帮供应商提前准备，DELJIT 推动供应商实际执行。

因此，系统设计时不建议把 DELJIT 直接塞进 DELFOR 的预测表里。DELJIT 应作为独立的交付指令或叫料明细进入 ERP、WMS、MES 或运输管理流程。

一份 Renault DELJIT 示例传递了什么？

以下示例用于说明字段含义和系统映射方式，发送方、接收方、物料号、订单号和地点等均已脱敏处理；时间和数量已按业务逻辑整理为自洽数据。

示例报文包含 1 个交换信封、1 个 DELJIT 消息、1 个生产序列、1 个物料、1 组包装信息和 1 条交付明细。

示例 EDIFACT 报文如下：

UNB+UNOC:3+RENAULT-DEMO+SUPPLIER-DEMO+260609:1542+000000001++RGPI' UNH+1+DELJIT:D:98B:UN:A1002' BGM+340+20260608152133833+9' DTM+137:202606091542:203' DTM+234:202606091643:203' DTM+235:202606091713:203' DTM+117:202606091744:203' DTM+128:202606091814:203' RFF+ADE:00123456' NAD+BY+BUYER-DEMO::92' NAD+CN+CONSIGNEE-DEMO::92' NAD+CZ+0012345602::92' NAD+SE+SUPPLIER-DEMO::92' SEQ+39' PAC+150+1+BAC-O-4325::92' QTY+52:35:PCE' LIN+1++PN-DEMO-001:IN' IMD+F++:::VR-BIELLETTE BARRE A' RFF+ON:PO-DEMO-001' LOC+11+168G7010' LOC+159+REFLEX' QTY+131:5250:PCE' RFF+CW:L12NK457' QTY+52:35:PCE' UNT+24+1' UNZ+1+000000001'

将报文还原成业务信息后，可以得到以下内容：

示例中的关键交付指令可以概括为：

Renault DELJIT 关键业务信息

1. 报文头与交付时间窗口

DELJIT 的报文头用于判断“这是哪一份交付指令，以及本次提货和到货应落在哪个时间窗口”。

示例中有两组时间：

DTM+137:202606091542:203' DTM+234:202606091643:203' DTM+235:202606091713:203' DTM+117:202606091744:203' DTM+128:202606091814:203'

它们分别表达：

• 报文创建时间：2026-06-09 15:42；
• 提货窗口：2026-06-09 16:43 至 17:13；
• 到货窗口：2026-06-09 17:44 至 18:14。

报文创建时间应早于或至少不晚于其指向的执行窗口。若实际项目中收到“创建时间晚于提货/到货窗口”的报文，应优先确认是否为补发、重发、测试数据或历史指令，避免把过期窗口误下发给仓库和承运商。

提货窗口和到货窗口也不能混淆。对 WMS 来说，提货窗口可能驱动备货完成时间；对 TMS 来说，它关系到车辆调度；对 Renault 收货来说，到货窗口通常是考核交付准时性的关键。

2. 业务参与方

Renault DELJIT 使用多个NAD角色表示不同业务主体。即使代码看起来相似，也应按限定符分别映射。

其中NAD+CZ很容易被忽略。Renault 规范说明它由供应商内部账号和零件移除地点代码组成，并且该信息在 PVS 场景下对后续 DESADV D96A 是强制信息。换句话说，DELJIT 中的发货/移除地点不只是参考字段，它可能会影响 ASN、发货地点、库存地点和物流路径。

3. 生产序列与包装信息

DELJIT 在SEQ下组织生产序列。Renault 规范定义SEQ+39表示 New，即新的生产序列。

示例包装段为：

SEQ+39' PAC+150+1+BAC-O-4325::92' QTY+52:35:PCE'

它表示本序列包含 Renault 包装代码BAC-O-4325，包装层级/类型代码为1，包装数量为 150，每包装数量为35 PCE。在本示例中，150 × 35 = 5,250，与交付数量一致。

4. 物料、订单与地点

DELJIT 中的计划物料由LIN开始，并通过RFF、LOC等段补充订单和地点。

LOC+11和LOC+159都是地点，但含义不同。LOC+11更接近车辆实际卸货位置；LOC+159表示 destination point 或 mounting point，可能对应 Renault 内部装配点、目的地或后续流转位置。系统映射时应保留两个字段，不能用后出现的地点覆盖前一个地点。

5. 交付数量与叫料参考

DELJIT 的执行明细主要体现在 Program Details 中，规范允许每个物料下出现多条明细。

示例中执行明细为：

QTY+131:5250:PCE' RFF+CW:L12NK457' QTY+52:35:PCE'

它表示本次指令要求交付5,250 PCE，并通过L12NK457进行叫料或补货追踪。

RFF+CW是 DELJIT 对接中非常重要的字段。它通常会成为仓库作业、标签、ASN 和客户收货核对的关联键之一。若 ERP 或 WMS 没有保存该字段，后续即使数量和物料正确，也可能无法匹配 Renault 的叫料记录。

对接 Renault DELJIT 最容易出错的地方

将 DELJIT 当作 DELFOR 预测处理

DELJIT 是 Shipping Instructions，不是中长期预测。如果把QTY+131直接写入预测需求表，可能导致正式交付指令被排产逻辑稀释，或者与 DELFOR 预测重复计算。

更合理的做法是：DELFOR 进入预测/计划模块，DELJIT 进入交付指令、叫料、出库或发运模块。

混淆提货窗口和到货窗口

DTM+234/235是提货窗口，DTM+117/128是 Renault 到货窗口。仓库、运输和客户交付考核使用的时间点不同，映射时应保留四个时间字段。

如果系统只存一个“交货日期”，会丢失 JIT 场景中最关键的时间约束。

忽略NAD+CZ发货/移除地点

NAD+CZ不是普通备注。它可能决定供应商从哪个 site、仓库或发货点移除零件，也可能影响 DESADV 中 PVS 相关字段。

覆盖LOC+11与LOC+159

卸货点和目的地/装配点需要同时保留。只保存其中一个，会影响收货预约、内部配送、标签打印或客户侧核对。

丢失 RAN 或补货参考

RFF+CW常用于 Renault 叫料追踪。很多项目中，客户收货、ASN 匹配和异常追溯都依赖这个参考号。它不应只作为备注文本保存。

机械校验包装数量与交付数量

包装数量、每包装数量与交付总数是最容易被业务人员复核的字段。本示例中PAC+150与QTY+52:35:PCE可计算出 5,250 PCE，和QTY+131:5250:PCE一致。

实施时建议分两层处理：

• 若项目确认PAC表示同一包装代码的包装个数，且QTY+52表示每包装件数，可配置强校验：包装数量 × 每包装数量 = 交付数量；
• 若项目存在多层包装、混托、返空器具或特殊包装规则，应保留软校验和异常提醒，并在规则表中注明适用流类型和客户场景。

无论采用强校验还是软校验，都不建议完全忽略该关系。它能帮助仓库提前发现少箱、多箱、包装容量配置错误等问题。

识别不同应用参考和流类型

Renault DELJIT 的UNB应用参考可能出现GPI、L3P、KAN、MOD、MPR，也可能出现带 RAN 语义的RGPI、RL3P、RKAN、RMOD。不同流类型会影响后续仓库作业、标签、运输组织和 DESADV/ASN 生成方式。

建议在接口层不要只把应用参考当作备注保存，而是将其映射为可配置的业务字段：

如果同一供应商同时服务多个 Renault 工厂或多个流类型，应把“流类型 + 买方/收货方 + 卸货点 + 物料”作为规则匹配条件，避免一套包装校验或 ASN 规则误套到所有场景。

与 DESADV/ASN 的串联

DELJIT 的价值不止是生成交付任务，还在于为后续 DESADV/ASN 提供上下文。实施时应明确哪些字段会被传递到发运通知，例如 DELJIT 编号、采购订单、Renault 零件号、卸货点、目的地/装配点、包装代码、RAN/补货参考和发货/移除地点。

特别是NAD+CZ、LOC+11、LOC+159、RFF+CW这类字段，前端接收时看似只是参考信息，但在 ASN 匹配、客户收货核对、异常追溯时经常成为关键字段。建议在 DELJIT 入库、WMS 下发、发运确认和 DESADV 生成四个环节都保留同一业务键。

Renault DELJIT EDI 对接方案

供应商可以通过 EDI 系统自动接收 Renault DELJIT，并将其转换为 ERP、WMS、MES、TMS 或发运系统可识别的结构。

一套完整的 Renault DELJIT 自动化流程通常包括：

1. 接收并识别 Renault 发来的 DELJIT D98B 报文；
2. 校验BGM+340、UNH版本、应用参考和报文编号；
3. 解析提货窗口、到货窗口和报文创建时间；
4. 按NAD角色识别买方、收货方、发货/移除地点和供应商；
5. 解析生产序列、包装代码、包装数量和每包装数量；
6. 将 Renault 零件号、采购订单、卸货点和目的地正确关联；
7. 解析QTY+131交付数量和RFF+CW叫料/补货参考；
8. 将交付指令下发至 ERP、WMS、MES 或 TMS；
9. 在发运时复用 DELJIT 信息生成 DESADV/ASN；
10. 对缺少关键字段、未知物料、异常时间窗口或包装不一致进行告警。

建议 ERP 或集成接口至少保留以下业务层级：

DELJIT ├─ 交换信息 │ ├─ 发送方 / 接收方 │ └─ 应用参考 / 流类型 ├─ 报文信息 │ ├─ DELJIT 编号 │ ├─ 报文创建时间 │ ├─ 提货开始 / 提货结束 │ └─ 最早到货 / 最晚到货 ├─ 参与方 │ ├─ 买方 BY │ ├─ 收货方 CN │ ├─ 发货/移除地点 CZ │ └─ 供应商 SE / ADE └─ 生产序列 ├─ 序列状态 ├─ 包装 │ ├─ 包装数量 │ ├─ Renault 包装代码 │ └─ 每包装数量 └─ 物料 ├─ Renault 零件号 ├─ 物料描述 ├─ 采购订单号 ├─ 卸货点 ├─ 目的地/装配点 └─ 交付明细 ├─ 交付数量 ├─ 单位 └─ RAN / 补货参考

该结构可以保证每条交付指令都能追溯到正确的报文、参与方、生产序列、包装、物料、订单和地点，避免在后续出库、发运和 ASN 生成过程中丢失上下文。

推荐字段映射清单

实施 Renault DELJIT 对接的价值

实现 DELJIT 自动化后，供应商可以：

• 自动接收 Renault 即时交付指令，减少人工下载和录入；
• 准确识别提货窗口和到货窗口，降低 JIT 迟到风险；
• 将物料、订单、卸货点、目的地和 RAN 号完整传递至仓库；
• 自动生成拣货、包装、装车和发运任务；
• 在 DESADV/ASN 中复用 DELJIT 的关键参考，提升客户收货匹配率；
• 对异常数量、未知物料、缺失地点或包装不一致进行及时告警；
• 保留每份交付指令的版本和执行状态，方便后续追溯。

Renault DELJIT 的难点并不在于解析一串 EDIFACT 字符，而在于把短周期交付指令准确落到仓库和物流执行层。只有同时处理好时间窗口、参与方、物料订单、地点、包装、数量和 RAN 参考，DELJIT 对接才能真正支撑 JIT 交付，而不是只完成格式转换。

阅读原文