Target案例展示
整个流程
在我们以前对接Target的案例中，API和EDI两种方式我们都是支持的(取决于仓库更加倾向哪种)。下图是一个供应商有多个仓库去对接Target的业务，Chinlink直连Target，在中间做转发，如果有多个仓库的话可以进行数据的分发。 这个供应商在北美有两个仓库/工厂A和B，两家使用不同的方式来进行数据的交换：
- 仓库A并不支持EDI报文的形式，所以他们更加倾向于使用API进行数据交换；
- 仓库B是支持EDI，所以想让我们使用EDI的形式和他们进行数据交换;
业务流程
对于A和B来说，都需要做Routing、生成箱单、生成BOL，以仓库A为例，对于Target订单的处理一般包括以下步骤：
- 每周Target都有订单，发给Chinlink，Chinlink分发给仓库A，仓库A拿到订单
- 登录供应商分给他们的ShipIQ账户，在ShipIQ上做Routing并提交，等待Target分配load id(一个load代表一辆卡车，到时候会有卡车司机来提货的)
- Target分配好了提货日期和load id，仓库和承运人确认订单的提货日期，等待承运人来提货，这个时候仓库可以去给订单把箱贴整理好，以下是一个订单，这个订单有140箱，这是一个箱子的箱贴。
- 在约号提货日期之后，仓库这边可以做BOL提单，如果一个load id下挂着6个订单，那么就会做成一个主提单，这个主提单中包含6个子提单，这个到时候需要签字并交给承运人的，之后等待线下出货就行。
- 到第四步线下出货就完成了，之后就是在系统中将数据通过API提交给Chinlink，数据包括每个订单的箱单、提单、产品信息、重量、给哪个Target DC等信息，Chinlink会将发货整合成EDI并且回发给Target ASN(发货通知)和INV(发票)，至此整个发货流程就结束了。
数据流向
以下是核心业务的数据流向(850、856、810等核心业务)：
对于A仓库
- Target下850订单，Chinlink将A仓库和B仓库的订单分别转发给A和B；
- Chinlink将EDI数据转换为JSON，调用A仓库的接口，将订单发给A仓库；
- 仓库A使用上述业务流程中的步骤处理订单并且将数据以API的形式回复给Chinlink
- Chinlink拿到仓库A回复的数据，并将其转换为856发货通知、810发票回复给Target
入库预报：供应商在每次有新的货物到仓库之前，会提前在仓库A的系统做入库预报，仓库A可以提前知道这些即将入库的货物信息。
对于仓库B
- Target下850订单，Chinlink将A仓库和B仓库的订单分别转发给A和B；
- Chinlink将850订单转换为仓库B可识别的940仓库单并发给仓库B
- 仓库B也会进行上述的业务流程来处理整个业务流程并进行线下发货；
- 在发完货之后仓库B会回复Chinlink 945仓库发货单，ChinLink会将945转换为856发货通知和810发票发回给Target；
入库预报：供应商在每次有新的货物到仓库之前，会提前做入库预报，这个入库预报是以943的形式发给仓库的，我们做了一套模板，供应商上传Excel就可以。
总结
通过该第三方对接方案，Chinlink 在 Target 与供应商多仓库之间承担统一接入和数据中枢的角色，实现了在同一业务体系下同时支持 API 与 EDI 两种数据交互方式。针对不同仓库系统能力的差异，Chinlink 能够灵活完成订单、发货及发票等核心业务数据的分发、转换与整合，确保 Target 侧始终遵循其标准的 EDI 流程，而仓库侧则可采用最适合自身的对接方式。
该方案覆盖了从订单下发、仓库处理、线下出货到 ASN 与发票回传的完整业务闭环，同时支持入库预报等仓库前置业务场景，降低了供应商和仓库的系统对接成本，提高了整体对接的稳定性与可扩展性。对于存在多仓库、多系统形态的供应商而言，该方案具备较强的通用性。