在 Aptiv EDI 项目实施中，供应商经常会遇到 ASN（DESADV）被 APERAK 拒绝的情况，例如：

CALL-OFF ITEM IS INVALID
SEGMENT NUMBER 000026
CALL-OFF NO, MATERIAL, SA

很多时候，问题并不在 ASN 报文格式本身，而在于 ASN 与 DELJIT 中的 Call-Off（交付指令）对应关系不符合 Aptiv 的业务规则。

本文结合 Aptiv 官方说明，整理不同业务模式下的 ASN 发送要求，帮助项目实施和上线前排查常见问题。

关键结论

• 并非所有 Aptiv 工厂都使用相同的 ASN 规则
• 如果工厂启用了 Lean Ordering，通常需要做到一个 COF 对应一个 ASN
• 如果工厂未启用 Lean Ordering，ASN 可以按实际发运情况汇总
• 上线前先确认工厂是否使用 Lean Ordering，往往比单纯检查报文格式更重要

一、什么是 Lean Ordering

Aptiv 部分工厂采用 Lean Ordering（精益订货）模式。

在这种模式下：

• DELJIT 中会包含一个 COF（Call-Off Number）
• 一个 DELJIT 可能包含多个物料（多个 LIN）
• 所有物料均属于同一个 COF

示例：

DELJIT
 ├─ COF: 12345678
 ├─ LIN: PN-A
 ├─ LIN: PN-B
 └─ LIN: PN-C

这意味着：

• 一个 COF 代表一个发运指令
• ASN 需要围绕 COF 进行生成

二、Lean Ordering 项目的 ASN 规则

对于启用了 Lean Ordering 的 Aptiv 工厂，核心规则是：

一个 COF 对应一个 ASN。

正确做法

例如，DELJIT 1：

COF = 100001

PN-A
PN-B
PN-C

应发送：

ASN #1
 ├─ COF 100001
 ├─ PN-A
 ├─ PN-B
 └─ PN-C

再如，DELJIT 2：

COF = 100002

PN-D
PN-E

应发送：

ASN #2
 ├─ COF 100002
 ├─ PN-D
 └─ PN-E

错误做法

如果实际发货时，将多个 COF 的物料装在同一车次中：

COF 100001
PN-A

COF 100002
PN-D

仍然不能发送为：

ASN
 ├─ PN-A
 └─ PN-D

原因是 ASN 中混合了多个 COF，系统通常会返回类似错误：

CALL-OFF ITEM IS INVALID

或：

CALL-OFF NO, MATERIAL, SA

三、CYPRIUM / VERSIGENT 项目的特殊要求

根据 Aptiv EDI 团队说明，CYPRIUM / VERSIGENT 工厂采用 Lean Ordering。

因此，这类项目需要遵循以下要求：

• 一个 COF 对应一个 ASN
• ASN 必须携带对应的 COF
• 不允许将多个 COF 合并到同一个 ASN

即使这些货物实际装在同一辆车中发运，也仍然需要拆分生成多个 ASN。

四、APTIV 普通工厂的规则

并非所有 Aptiv 工厂都使用 Lean Ordering。

对于未启用 Lean Ordering 的工厂：

• DELJIT 中可能出现多个 LIN
• 不使用 COF
• 不存在 COF 限制

示例：

DELJIT

LIN PN-A
LIN PN-B
LIN PN-C

在这种情况下，供应商可以根据实际发运情况生成 ASN。

例如允许：

ASN

PN-A
PN-B
PN-C

也允许：

ASN

PN-A（来自 Release 1）
PN-B（来自 Release 2）
PN-C（来自 Release 3）

只要属于同一次实际发运，就可以合并到同一个 ASN 中。

五、为什么 ASN 会被拒绝

APTIV ASN 被拒绝，常见原因通常有以下几类。

1. 多个 COF 被合并到同一个 ASN

例如：

COF 100001
PN-A

COF 100002
PN-B

却生成：

ASN #1

PN-A
PN-B

系统无法识别唯一的 Call-Off，从而导致 APERAK 拒绝。

2. 物料与 Call-Off 不匹配

ASN 中填写的以下信息与 DELJIT 中记录不一致：

• Material Number
• Call-Off Number
• Schedule Agreement

这类情况下，系统会直接校验失败。

3. 错误引用历史 DELJIT

如果 ASN 引用了以下内容，也可能触发报错：

• 已关闭的 Call-Off
• 已完成交付的 Release
• 已失效的计划

常见返回信息仍可能是：

CALL-OFF ITEM IS INVALID

六、实施建议

在 Aptiv 项目实施过程中，建议优先确认工厂采用的是哪一种订货模式，再决定 ASN 的生成逻辑。

如果工厂使用 Lean Ordering

系统设计建议如下。

ASN 分组规则

应按照：

COF

进行分组。

而不应按照以下维度分组：

• Shipment
• Truck
• Delivery Date

ASN 生成逻辑

FOR EACH COF

    Generate ASN

NEXT

也就是说，一个 COF 生成一个 ASN。

如果工厂不使用 Lean Ordering

系统设计建议是按实际发运进行汇总。

可以合并的范围包括：

• 多个 Part Number
• 多个 JIT Release
• 多个 DELJIT Line

前提是这些内容属于同一次实际发运。

七、项目上线前检查清单

发送 ASN 前，建议至少确认以下内容：

• 工厂是否使用 Lean Ordering
• DELJIT 是否包含 COF
• ASN 是否引用了正确的 Call-Off
• 一个 ASN 是否只对应一个 COF
• ASN 中物料是否与 DELJIT 中物料一致
• ASN 中数量是否与 DELJIT 中数量一致
• ASN 中 Schedule Agreement 编号是否正确
• ASN 是否已经通过测试环境验证

总结

APTIV ASN 实施中最容易被忽略的一点是：

不同工厂的 DELJIT 和 ASN 规则并不完全相同。

对于采用 Lean Ordering 的工厂（如 CYPRIUM / VERSIGENT）：

• 一个 COF 对应一个 ASN
• ASN 必须引用对应 COF
• 不允许多个 COF 合并发送

对于未采用 Lean Ordering 的工厂：

• 不使用 COF
• 允许多个物料、多次 Release 合并到同一个 ASN
• ASN 可以按实际发运进行汇总

因此，在项目实施和上线前，先确认工厂是否启用了 Lean Ordering，往往是避免 ASN 被 APERAK 拒绝的关键一步。