
在汽车供应链中,需求并不是一张下完就不再变化的采购订单。
整车厂会根据生产计划,持续向供应商发送未来数周的物料需求。供应商需要及时识别需求变化,安排原材料、产能与交付节奏。Renault 使用 EDIFACT DELFOR D96A 报文传递此类预测计划。
本文结合 Renault DELFOR 规范与一份真实示例报文,说明 Renault 如何表达预测需求,以及供应商在 EDI 对接时需要重点处理哪些信息。
DELFOR(Delivery Schedule Message)即交付计划报文。Renault 通过 DELFOR 向供应商发送指定物料在未来一段时间内的预测需求。
一份 DELFOR 不只是“什么时候交多少货”,还会同时说明:
对于供应商而言,准确处理 DELFOR,是做好备料、排产和交付的第一步。
项目 | Renault DELFOR 要求 |
|---|---|
报文标准 | EDIFACT DELFOR D96A |
业务用途 | 发送未来交付预测 |
报文类型 | BGM+34,交付计划报文标识 |
计划状态 | SCC+4,预测计划状态 |
物料标识 | Renault 零件号 |
订单关联 | 采购订单或补充订单号 |
更新方式 | 周计划删除并替换;日计划或多日内计划周期更新 |
计划频率 | W 表示 Weekly;Y 表示 Daily |
需求数量 | QTY+113 |
数量单位 | 使用 ODETTE 计量单位,例如 PCE |
示例报文包含 1 个物料、1 个收货方和 5 个预测时间窗口。将报文还原成业务信息后,可以得到以下内容:
业务信息 | 示例值 | 含义 |
|---|---|---|
DELFOR 编号 | 20260607232081254 | 本次预测计划的唯一编号 |
报文生成时间 | 2026-06-10 16:42 | Renault 创建本次报文的时间 |
预测有效期 | 2026-06-15 00:00 至 2026-07-19 23:59 | 本次计划覆盖的时间范围 |
供应商内部账号 | 00609733 | Renault 系统中的供应商账号 |
买方代码 | 09459813295 | 提出需求的 Renault/Dacia 工厂代码 |
收货方代码 | 09459813295CI | 实际收货方的 ODETTE 代码 |
Renault 零件号 | 546182936R | Renault 使用的物料编号 |
物料描述 | VR-BIELLETTE BARRE A | 订购物料描述 |
卸货点 | 168G7010 | 物料交付的具体卸货位置 |
采购订单号 | 0000693244 | 需求对应的采购订单或补充订单 |
计划状态 | 4 | Forecast,预测需求 |
计划频率 | Y | Daily,按日计划 |
这条报文的核心不是一个单独日期,而是一组连续的预测区间:
序号 | 预测开始时间 | 预测结束时间 | 需求数量 |
|---|---|---|---|
1 | 2026-06-15 11:00 | 2026-06-15 23:00 | 7,000 PCE |
2 | 2026-06-22 11:00 | 2026-06-22 23:00 | 10,500 PCE |
3 | 2026-06-29 00:00 | 2026-06-29 23:59 | 12,250 PCE |
4 | 2026-07-06 00:00 | 2026-07-12 23:59 | 12,250 PCE |
5 | 2026-07-13 00:00 | 2026-07-19 23:59 | 10,500 PCE |
合计 | 52,500 PCE |
从这组数据可以看出,Renault DELFOR 既可以表达单日需求,也可以表达跨多日的预测周期。供应商不能只读取数量和某一个日期,而应将开始时间、结束时间、数量和单位作为一组完整计划处理。
报文头用于判断“这是谁发出的哪一版计划,以及计划覆盖到什么时候”。
EDIFACT 内容 | 业务含义 | 处理建议 |
|---|---|---|
BGM+34+... | Forecast 报文及 DELFOR 编号 | 使用 DELFOR 编号识别本次计划 |
DTM+137 | 报文生成时间 | 用于判断计划版本先后 |
DTM+157 | 有效期开始时间 | GPI 场景下可能出现 |
DTM+36 | 有效期结束时间 | GPI 场景下可能出现 |
DTM+2 或 DTM+10 | 到货或发运指令性质 | 2 表示 Arrival,10 表示 Departure |
其中,Arrival 与 Departure 会直接影响计划时间的理解:
10(Departure)时,计划时间表示预计发运时间;2(Arrival)时,计划时间表示预计到货时间。这一区分应进入业务映射或排产逻辑,不能只作为无意义代码保存。
Renault DELFOR 使用不同的 NAD 限定符区分参与方。
EDIFACT 内容 | 业务含义 |
|---|---|
NAD+BY | 买方/提出需求的工厂 |
NAD+IV | 开票方或开票地点 |
CTA+NT | 开票联系部门 |
NAD+SE | 供应商 |
NAD+CN | 收货方 |
RFF+ADE | Renault 系统中的供应商内部账号 |
买方、开票方和收货方可能使用相近的代码,但业务角色不同。对接时应按限定符分别映射,避免全部写入同一个“客户代码”字段。
每个计划物料需要与 Renault 零件号、订单号和卸货点正确关联。
EDIFACT 内容 | 业务含义 | 示例 |
|---|---|---|
LIN ... :IN | Renault 零件号 | 546182936R |
LIN/1229 | 更新动作 | 3 或 9 |
RFF+ON | 采购订单或补充订单号 | 0000693244 |
IMD | 物料描述 | VR-BIELLETTE BARRE A |
PIA ... :SA | 供应商物料号 | 规范定义,可选 |
PIA ... :DR | 图纸版本号 | 规范定义,可选 |
LOC+11 | 卸货点 | 168G7010 |
Renault 规范对更新动作给出了明确含义:
3:周计划采用 Delete and Replace,新计划替换原计划;9:日计划或多日内计划采用 Cycle Updating,按周期更新。因此,系统收到新 DELFOR 后,不能简单把所有计划行持续累加。应先根据更新动作与业务规则,决定替换还是更新原计划。
每条预测计划由 QTY、SCC 和 DTM 共同表达。
EDIFACT 内容 | 业务含义 |
|---|---|
QTY+113 | 计划交付数量 |
SCC+4 | Forecast,预测计划状态 |
SCC/C329/2013 | 计划频率:W 周计划,Y 日计划 |
DTM+64 | 预测开始时间 |
DTM+63 | 预测结束时间 |
DTM+2 | 单一交付周期时间,可选 |
在真实示例中,一条典型计划为:
QTY+113:7000:PCE'
SCC+4++Y'
DTM+63:202606152300:203'
DTM+64:202606151100:203'它表示:该物料存在一条 Forecast 计划,数量为 7,000 件,预测时间从 2026 年 6 月 15 日 11:00 开始,到当日 23:00 结束。
SCC+4 表示 Forecast。它用于支持备料和产能规划,不应在没有业务确认的情况下直接等同于正式发货指令。
周计划和日计划的更新逻辑不同。若系统只追加、不替换,可能造成需求重复累计,进一步导致过量备料或发货。
DTM+64、DTM+63 和 QTY+113 属于同一条计划。映射时必须保留三者的关联关系,尤其是在一个物料下存在多条计划时。
同一组开始和结束时间,在 Departure 与 Arrival 场景下代表不同业务含义。系统需要结合报文中的指令性质解释时间。
同一物料可能对应不同订单或交付位置。Renault 零件号、采购订单号、收货方和卸货点应作为关联信息共同进入 ERP。
Renault 规范将计划频率定义为必填信息,而真实报文中后续 SCC+4 可能未重复携带频率。实施时应结合 Renault 实际发送逻辑确认继承规则,同时保留异常监控,避免静默丢失计划频率。
供应商可以通过 EDI 系统自动接收 Renault DELFOR,并将报文转换为 ERP、SRM 或生产计划系统可识别的格式。

一套完整的 Renault DELFOR 自动化流程通常包括:
建议 ERP 接口至少保留以下业务层级:
DELFOR
├─ 报文信息
├─ 买方 / 开票方 / 供应商
└─ 收货方
└─ 物料
├─ Renault 零件号
├─ 采购订单号
├─ 卸货点
└─ 预测计划
├─ 计划状态与频率
├─ 开始时间
├─ 结束时间
├─ 数量
└─ 单位该结构可以保证每条预测需求始终归属于正确的收货方、物料和订单,避免在转换过程中丢失上下级关系。
实现 DELFOR 自动化后,供应商可以:
Renault DELFOR 的难点并不在于“收到一串 EDIFACT 字符”,而在于正确理解计划周期、更新动作和业务关联。只有把报文转换为可执行、可追踪的生产与交付计划,EDI 对接才真正产生价值。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。