Coupang 拆分发货：会生成两个订单吗？不会

不会。从运营角度看，Coupang 拆分发货是一个客户订单对应多个履约事件，而不是两个相互独立的订单或销售。应将原始订单引用保留为父级，并在其下核对受影响的订单行、包裹、配送事件、索赔和退款。

Coupang 的两个拆分发货标记究竟表示什么

Coupang 提供了两个名称相近但回答不同问题的信号。ableSplitShipping 表示该订单可以拆分发货；splitShipping 表示拆分发货实际上已经处理。前者描述的是能力，后者提示你应查找由此产生的履约记录。

具体 payload 和状态行为，应根据账户所使用的端点和版本，查阅 Coupang 官方 Open API 开发者文档。不要从字段名称推断出超出文档支持范围的信息。

仅具备拆分资格并不能证明存在多批发货。订单可能支持拆分，但最终仍以一个包裹发出。系统不应仅因 ableSplitShipping 存在就创建第二个订单或子包裹。

当 splitShipping 表明已完成处理时，应检查关联的商品和配送记录。如果包裹详情尚未传入系统，应使用内部“待核对”状态。不要臆测订单已全部送达、全部丢失或财务上已经结清。

建立一个父订单及多个履约记录

最稳妥的数据模型是父子关系：一个原始 Coupang 订单，其下关联受影响的订单行、包裹、配送事件和索赔。包裹是订单下的履约记录，而不是订单本身的替代物。

至少应保留以下记录：

这种关系应支持双向追溯：

一个客户订单 → 受影响的订单行 → 包裹（一个或多个）→ 配送事件 → 订单行级索赔或退款

如果 ERP 或仓储系统要求为每个包裹创建一个发货对象，应将这些发货对象作为同一父订单的子记录。保留父订单层级的原始订单总额。不要将完整的商业订单复制到每条包裹记录中，否则可能重复计算销售额、促销、库存变动和退款风险敞口。

除了标准化状态，还应保留源事件数据。当前状态能说明商品现在处于何处；事件历史则有助于解释客户为何只收到部分商品、索赔是否发生在配送异常之后，以及是哪一个系统修改了记录。如果多个工具接入同一个卖家账户，连接器设计同样重要；Coupang Open API：两个系统可以共用一个 Seller ID 吗？ 说明了为什么分别直接解读数据可能造成冲突。

履约：不要在第一个包裹送达后关闭订单

内部履约状态应细化到订单行。父订单状态应根据子订单行和包裹推导，而不是在第一个配送事件到达时覆盖这些明细。

一个实用流程如下：

1. 记录原始订单以及两个拆分发货信号。
2. 将每个受影响的订单行映射到对应包裹；如无法映射，应明确标记为待审核。
3. 在包裹和订单行层级记录发货及配送状态。
4. 根据所有订单行推导父订单状态：仍有订单行待处理时，状态为部分履约；只有在每个订单行都已送达，或通过 Coupang 支持的流程形成单独的终结结果后，才标记为完成或已解决。
5. 当事件相互冲突、停止推进或无法映射时，针对受影响的订单行或包裹创建异常。

设想一位客户购买了商品 A 和商品 B。商品 A 先发货并送达，商品 B 仍在运输途中。此时客户只有一个订单，其中一行已送达，另一行仍未解决。你的运营系统中的父订单应保持“部分履约”或开放状态。不应将其标记为全部送达，也不应触发整单退款或退货流程。

同样的逻辑也能保护库存。包裹记录只能推进其中包含的订单行。根据第二个包裹创建第二个订单，可能导致仓库对同一笔商业订单重复预留或扣减库存；将所有包裹合并为一个状态，则可能让未送达的订单行看起来已经完成。即使客户看到的是一个订单页面，也应将订单行数量、包裹分配和异常状态分开管理。

客服与退货：先诊断受影响的商品

买家感受到的是部分配送，而不是数据库关系。因此，韩语客服回复应明确受影响的商品和包裹，而不是笼统地说“订单”延迟或丢失。

回复前应检查：

• 原始订单引用；
• 买家所称缺失商品的 SKU、变体和数量；
• 分配给该订单行的包裹或物流追踪引用；
• 该包裹最近的发货和配送事件；
• 同一订单中其他订单行的状态；以及
• 是否已经存在索赔、退货、取消或退款。

随后，韩语客服回复应说明哪个商品已经送达、哪个商品仍在运输途中或存在尚未解决的异常，以及下一步可执行的流程。只有在实际的拆分处理记录和包裹记录支持这一判断时，才能向客户说明该笔购买将分成多个包裹送达。仅凭 ableSplitShipping，不足以告知客户有两个包裹正在途中。

这一点对部分配送投诉至关重要。仍在配送中的商品，与没有任何有效配送进展或已确认丢失的商品，并不是同一种运营案件。应先检查事件记录，再按照相应的 Coupang 索赔流程处理。不要仅因一个包裹延迟，就提供整单取消、退货或退款。

退货记录也应保留相同的层级关系。将退货或索赔关联到受影响的商品和包裹，保留其 Coupang 引用和状态，并让其余订单行继续各自的履约路径。在 Rocket Growth 模式下，平台可能负责面向客户的退货、取件和退款，但退回商品及其处理结果仍需映射回你的订单和库存记录；Coupang Rocket Growth 下的退货由谁处理？ 解释了这一运营边界。买家退款也可能在实物退货到达前就已记录，因此应将财务事件与仓库收货作为两条独立记录处理；参见 Coupang 即时退款：为什么买家在退货到达前就能收到退款？。

结算：核对订单和索赔记录，而不是第一次配送

结算是拆分发货的控制点，而不是包裹计数器。应根据 Coupang 的订单、索赔、退款和结算记录核对财务结果，而不是从首次配送事件推断结果。

对于每个父订单，应按以下顺序处理记录：

1. 确认原始订单引用和已购买的订单行。
2. 将每个订单行与其发货、配送、取消或退货结果匹配。
3. 将任何包裹级异常和索赔引用关联到受影响的订单行。
4. 将销售额、扣款、取消和退款匹配到相关的 Coupang 记录。
5. 确认该订单在结算结果中只被计入一次，并且仅根据已记录的订单行结果进行调整。

两个包裹引用并不能成为计算两笔销售的依据。相反的错误也很常见：把首个已送达包裹当作所有订单行都已完成财务结算的证明。如果 Coupang 在订单层级提供扣款或退款记录，应保留源记录，并在平台支持该对应关系的情况下，利用索赔或订单行明细在内部进行分摊。如果无法确定分摊关系，应将其标记为待审核，而不是把同一笔调整分配给每个包裹。

关于 Coupang 何时确认销售收入这一独立问题，请参阅 Coupang 何时将您的销售确认为收入。对于拆分发货运营，实际规则更简单：仓库状态、面向客户的配送状态、索赔状态和结算状态必须彼此关联，但不能相互替代。

上线前测试：验证订单与包裹的对应关系

应在真实客户反馈部分配送之前完成这项测试。使用一个在你的运营设置下确实可以作为拆分发货处理的受控多商品订单，并在执行前记录预期状态。

1. 创建一个包含多个商品的订单，使用可以分配到不同包裹的不同 SKU 或订单行。
2. 记录原始订单引用、受影响的订单行以及两个拆分发货标记。确认 ableSplitShipping 本身不会创建第二个订单，也不代表已经存在多个包裹。
3. 通过 Coupang 支持的流程，或账户可用的测试能力，处理拆分发货，然后记录每个包裹的引用及其订单行映射关系。
4. 将第一个包裹标记为已送达，或观察其变为已送达，同时保持另一个包裹在运输途中。确认 ERP、仓库视图和 Coupang 账户都将父订单保持为开放或部分履约状态。
5. 通过韩语客服流程处理一宗部分配送投诉。确认回复识别的是缺失商品、包裹、当前状态和下一步行动，而不是把这次购买当成两笔互不相关的订单。
6. 仅针对受影响的订单行测试索赔或退货。确认索赔、库存处理结果和退款仍关联到该订单行及包裹，且不会自动冲销整笔订单。
7. 将产生的销售额、扣款和退款与 Coupang 的订单、索赔及结算记录进行核对。确认包裹数量的变化没有改变销售笔数。

只有在每个团队都能从同一个原始订单引用出发，追溯到相同的受影响订单行、包裹、事件、索赔和财务结果时，测试才算通过。保存每一步的原始源响应和预期内部状态；否则，后续的集成变更可能在不易察觉的情况下，将部分配送压平为已完成订单。

关于 Coupang 拆分发货的常见问题

ableSplitShipping 是否意味着已经存在两个包裹？

不。这表示可以拆分发货。在告知买家存在多批发货之前，应先查找实际的拆分处理状态和包裹级记录。

splitShipping 是否意味着我应创建第二个 Coupang 订单？

不。保留一个父订单，并创建或更新用于跟踪受影响订单行和包裹的子履约记录。

第一个包裹到达后，我可以将整笔订单标记为已送达吗？

不。只更新已送达的订单行，并让其余订单行保持开放、运输中或异常状态，直到它们各自达到 Coupang 支持的结果。

包裹延迟是否应触发整单退款或退货？

不应自动触发。应先确定包裹仍在运输途中还是确实丢失，然后针对受影响的商品或货件，按照 Coupang 支持的索赔流程处理。

财务应如何核对拆分发货？

应结合原始订单、订单行结果、索赔记录和结算记录进行处理。整笔购买只计一次；在可能的情况下，将调整映射到受影响的订单行；不要根据首次配送事件推断财务结果。