Coupang 订单行：一行不等于一件

不，不能安全地这样处理：Coupang 订单行是面向客户的商业选项，并不能证明仓库只需扣减一件实物。自动生成的数量选项可能代表多个基础单位。在 ERP 过账库存或生成履约任务之前，必须识别选项类型，追踪它与原始商品的关系，并根据结构化订单数据计算处理数量。

Coupang 为何打破“一行一件”的假设

许多西方 ERP 映射从一条简单链路开始：一个目录商品对应一个 SKU，一条订单行对应一个单位，随后执行一次库存扣减。只有在面向客户的选项与仓库计量单位完全相同时，这条链路才是安全的。

Coupang 的官方通知将自动生成选项描述为：为符合条件的类目按需求生成的购买数量选项。因此，卖家创建的商品可能获得一个面向客户的数量或套装选项，尽管品牌并未创建新的实物商品。该功能并非普遍适用，因此连接器必须按商品发现其状态，不能套用一条全局规则。

必须分开识别以下三种身份：

• 原始商品或商品项： 卖家在平台创建的商品刊登，是目录关系的锚点。
• 生成选项： Coupang 创建的、面向客户的数量或套装选择。
• 基础实物单位： 仓库、3PL 或履约作业实际拣选、发运和计数的单位。

生成选项在商业上可以是独立选项，但不一定是新的仓库 SKU。如果选项包含多个基础单位，却仍将订单行按一个单位处理，就会少扣库存，并向履约系统发送不完整的履约指令。反过来，如果把每个选项都视为全新的 SKU，则会造成目录记录重复、销售历史分散，以及不必要的库存编码。

实际判断很简单：连接器是否能在不读取商品标题的情况下，解释一个面向客户的选项如何对应到明确的实物数量。如果不能，它就还没有准备好自动处理这部分订单流程。

哪些 Coupang 字段应控制映射？

应使用结构化的 Product API 和订单表响应数据作为映射依据。请在 Coupang 官方 Open API 开发者文档 中核对 Product API 和订单响应模式，同时参考 Coupang 关于自动生成选项的官方通知。

必须区分接口端点。卖家商品响应由 GET /v2/providers/seller_api/apis/api/v1/marketplace/seller-products/{sellerProductId} 返回；订单表响应由 GET /v2/providers/openapi/apis/api/v4/vendors/{vendorId}/ordersheets 返回。开始编码前，请在 Coupang 文档中确认当前路径和版本。

下表中的角色名称只是概念说明；以代码格式标出的内容是实现时应检查的实际字段或响应路径。Coupang 可能因接口端点或 API 版本不同而使用不同的生成选项标记，因此应同时保存接口实际返回的字段名和值，以及诸如 generated_option_state 这样的规范化字段。不要在标记缺失时默默用选项名称替代它。

如果当前接口返回的生成选项标记使用了不同的字段名，应将该名称记录在连接器的版本化映射配置中。重要的实现决策不在于规范化字段是否称为 generated_option_state，而在于原始响应字段名、值、端点和 API 版本是否始终可审计。

必须区分选项数量和处理数量。如果响应表明套装规格（即每个购买选项包含的基础单位数）为 B，订购数量为 Q，则基础单位的库存变动为 B × Q，除非另有单独定义的仓库规则。例如，若 B = 3 且 Q = 2，订单会产生六个基础单位的变动（3 × 2），而面向客户的选项数量仍为 2。

计算应使用 Coupang 返回的结构化值，而不是尝试解析名称。除规范化后的 ERP 结果外，还应保存原始平台标识符和响应值。这样，当生成选项被新增、修改或停用时，后续仍可进行复核；同时也能避免数据修复破坏解释库存变动为何被过账的证据。

目录通过 API 创建时，同样存在这一边界：Coupang Open API 能否上传商品目录？ 说明了能够上传目录数据，并不意味着可以省略映射和验证。导入一条记录并不等于决定它在仓库中代表什么。

建立关系，而不是凭空创建仓库 SKU

可靠的数据模型应将生成选项视为叠加在原始商品之上的一种关系，而不是自动将每个平台选项提升为新的内部 SKU。

至少应将以下记录或字段分开保存：

这种模型支持一对多关系：一个基础 SKU 可以对应一个普通平台商品项，以及一个或多个面向客户的生成选项。选项可以拥有自己的价格或折扣，用于销售报告，同时仍将实物变动回溯到基础 SKU。

有一个重要例外。如果品牌确实将该数量选项作为独立的预包装商品进行生产、贴标、存储和拣选，企业可以选择为其分配专用仓库 SKU。这是库存政策的选择。Open API 提供平台层面的关系，但不会决定该套装属于预包装库存、拣货指令，还是虚拟商业选项。

不要让映射在 Coupang 更改选项时悄然变化。应保留当前状态、生效的套装规则以及历史关系，以便核对历史订单。新增或变更的选项应生成可见的映射事件，而不是无痕改写历史订单。

在库存、履约和结算之前应用映射

在扣减库存之后才进行映射，为时已晚。在任何下游系统将订单视为可执行之前，都必须先解析这层关系。

安全的处理顺序如下：

1. 持久化源订单数据。 保存平台订单、订单行、商品/商品项引用、选项标记、数量字段、价格和折扣。
2. 对订单行进行分类。 判断它是普通卖家商品，还是自动生成的数量选项。
3. 解析关系。 找到原始商品项、内部基础 SKU 和适用的套装规则。
4. 计算执行数量。 将套装规则应用于订购数量；如果响应提供了发运数量，则将其作为独立事实保存。
5. 以幂等方式过账。 只有映射成功后，才扣减库存并创建履约任务；同一订单重试时不得再次扣减库存。
6. 同时维护两套报表口径。 在面向客户的选项层级保留收入和折扣，并根据品牌的会计政策，将实物单位和单位利润归集到基础 SKU。

这一顺序对履约服务和品牌自有仓库同样重要。平台可能展示一条商业订单行，但履约指令却要求多个基础单位。如果连接器只传递订单行数量，仓库就会收到不完整的指令；如果连接器把选项误判为独立 SKU，又对数量重复相乘，传出的数量就会膨胀，同一订单可能因此被超量履约。

结算也需要保持同一关系。订单记录应让财务能够追溯：

• 哪条平台订单行产生了收入；
• 涉及哪个原始商品项和生成选项；
• 应用了什么价格和折扣；
• 哪个基础 SKU 接收了实物单位变动；以及
• 哪条数量规则产生了这次变动。

这比在对账时根据商品名称重新还原套装规格更可靠。这种方法与 Coupang 结算周期：Kontactic 如何完成对账 中的记录关联原则一致：平台证据和分配记录在结算复核期间始终保持关联。

如果订单进入 Coupang Rocket Growth 或其他履约流程，这一点在下游流程中仍然适用。为何 Coupang Rocket Growth SKU 仍显示不可用 提醒我们，平台库存状态必须与平台记录的库存（或平台侧可用库存）进行核对，而不能根据订单行或内部补货意图推断。

在正式上线前测试连接器

在正式上线前，应使用卖家账户或受控环境中的真实响应结构测试映射。仅测试普通订单导入还不够；还要验证选项状态发生变化时，连接器是否仍能保留这层关系。

只有在 ERP 和集成层支持一对多商品映射、可变的套装规格、防重复更新、监控，以及针对未映射情况的复核路径时，自建连接器才是合理选择。如果通用连接器的核心假设是一个平台商品项对应一个内部 SKU 和一个整数数量，那么使用它就存在风险。

应要求供应商展示规范化记录，而不只是订单界面。真正有价值的证据，是原始商品项、生成选项、基础 SKU、套装规则和已过账数量之间被保存的关系。如果供应商无法展示这些值，即使导入看似成功，也可能隐藏着不安全的库存决策。

控制生成选项，保护 API 连接

如果品牌不希望使用自动生成选项，可以在商品注册后使用 Product API 控制，停用特定生成选项或全部生成选项。这可以简化目录政策，但不能替代检测机制。流程仍应重新检查选项状态，并在 Coupang 新增、修改或停用选项时发出提醒。

重新同步流程还必须遵守 Coupang 的 API 行为。Coupang 警告称，过度调用商品接口可能返回 HTTP 429 响应，甚至导致接口访问受限。因此，选项发现和重新同步应遵守限流要求，采用带退避的重试，保存上次已知状态并设置告警，而不是反复进行不受限制的调用。

运营监控应回答以下四个问题：

• 商品的生成选项状态是否发生了变化？
• 是否有订单带有生成选项标记，却没有对应映射？
• 计算出的实物数量是否不同于实际过账到库存或履约系统的数量？
• 重试、限流响应或部分更新是否使订单处于未知状态？

这些检查能将一个目录功能转化为可管理的集成问题。没有这些检查，连接器可能表面稳定，却在持续积累错误的库存和利润数据。

关于 Coupang 数量选项的常见问题

每个自动生成的数量选项都是新的 SKU 吗？
不是。它是面向客户的平台选项。只有当品牌的仓储和拣选政策将其视为独立的预包装商品时，才应为其分配独立的仓库 SKU。

连接器可以根据选项名称映射数量吗？
不应这样做。应使用生成选项标记、关联商品项引用、套装规格、订购数量或发运数量，以及平台标识符。展示名称可以帮助复核人员，但不应驱动库存计算。

Coupang 会为每个商品创建这些选项吗？
不会。该功能面向符合条件的类目，必须按商品检测。连接器不应假设整个账户只有一种状态。

停用生成选项能消除集成风险吗？
对于应用了该控制的商品，它可以消除数量变化的一个来源；但连接器仍应验证状态，并正确处理已有订单或过时响应。

Open API 会决定会计处理方式吗？
不会。它提供商品和订单关系，并提供相应控制。品牌仍需自行定义该选项应映射到基础 SKU、预包装 SKU 还是履约数量，以及应采用何种报告口径。

何时通用连接器才足够？
只有当它能够保留一对多映射、可变的套装规则、防重复更新、监控机制，并支持人工复核未映射情况时才足够。如果它假定一条平台订单行就是一个内部单位，应将其视为未经验证的方案。