很多团队刚开始对接 Amazon Vendor Central（VC）时，会把注意力放在“如何拉取采购订单”。
一张亚马逊 VC 订单，真正要跑通的是从 Amazon 采购订单、内部接单，到创建 Shipment、获取可用发货日期、生成箱唛与运输标签、推送仓库执行，最后回传发货状态的一整条履约闭环。
如下图所示，这条链路连接了 Amazon、订单系统、Shipment 系统和仓库 WMS。任何一个环节断开，都会变成履约风险。
一、订单进来，不等于仓库可以发货
订单进入内部 Order 系统后，系统需要完成接单、库存与商品资料校验，并向 Amazon 确认订单。这里要区分两个动作：
拉取订单：把 Amazon 的采购需求同步到内部。
确认订单：向 Amazon 返回哪些商品、数量和交期可以承诺。
如果订单只是“拉到了”，却没有被内部系统正确接住，后续很容易出现库存不足、SKU 映射错误、包装规则遗漏等问题。
因此，订单系统至少需要留住三类信息：采购订单号、商品与数量、履约时效要求。它们应成为后续 Shipment、仓库拣配和状态回传的共同依据。
二、为什么要先创建 Shipment
订单确认后，内部系统并不是直接让仓库发货，而是先创建 Shipment。
Shipment 可以理解为一次具体的履约执行单元：哪些订单行、哪些商品、预计由哪些箱子发出、发往哪里、采用什么运输方式，都需要在这里被组织起来。
这一步的重要性在于，它把“商业承诺”转成了“仓库可执行的发运任务”。
如果没有 Shipment 这一层，订单与仓库任务会直接耦合。一个订单拆箱、拆批、部分发货或合单发运时，系统就很难清楚地追踪：到底哪一部分已经出库，哪一部分仍待处理。
三、FRD 是履约节奏的关键节点
图中第 5 步是获取 Amazon 可用 FRD。
FRD 通常可以理解为可发货日期相关的履约约束。对 VC 来说，发货不是仓库“今天有货就马上发”，而是需要在 Amazon 给定或允许的节奏中完成。
这意味着系统不能只管理“预计出库日”，还要管理 Amazon 侧的履约窗口，并将其传递给仓库和物流团队。
仓库的拣货、打包和交接时间，是否落在 Amazon 要求的窗口内？
如出现缺货、延迟或拆分履约，系统能否及时调整并留痕？
很多履约问题，表面上看是仓库出货慢，根源却是订单承诺、FRD 和仓内排程没有形成同一套时间标准。
四、标签不是“打印动作”，而是发货信息的一部分
确定 Shipment 后，需要在 Amazon 侧创建对应的 Shipment，并获取两类标签：
Carton Label：箱级标签，解决“每一箱是什么、属于哪次发运”。
Shipping Label：运输标签，解决“这批货由谁运、发往哪里”。
不少团队会把标签当作一个简单的打印功能，但它实际上是 Amazon、内部系统、仓库和承运商之间的重要识别凭证。
标签生成过早，箱规或数量调整后容易失效；标签生成过晚，仓库又可能等标签才能出库。更合理的做法是：在包装方案和 Shipment 信息相对稳定后生成标签，并将标签和 Shipment 一起推送到 WMS。
五、推送 WMS，才是让订单真正被执行
图中的第 9 步，是将 Shipment 推送至仓库系统。
此时，WMS 接收到的不能只是一个“请发货”的指令，而应当是一份完整的作业任务，包括商品、数量、箱规、标签、履约时限和目的地等信息。
仓库完成拣货、复核、装箱、贴标和出库后，发货结果还需要回流到 Shipment 系统，再由系统向 Amazon 标记发货。
Amazon 订单 → 内部接单确认 → Shipment → 标签与仓库执行 → 发货回传 Amazon
最后一步“标记发货”尤其关键。它不是内部仓库出库完成的同义词，而是向 Amazon 正式确认履约状态。若回传不及时或信息不一致，可能影响后续对账、履约表现和异常处理。
最重要的是，把订单承诺、发货计划、仓库作业和平台状态统一到一条可追踪的履约链路中。只有这样，团队才能从“靠人盯订单”走向“系统管理履约”。
电商老王