Coupang 商品 ID：一个 ID 无法覆盖所有变体

不能。企业资源计划（ERP）系统不应把一个 Coupang 商品 ID 作为所有尺码或颜色的永久主键。应将品牌的库存量单位（SKU）作为 ERP 中的主键。将 Coupang 的五个字段——sellerProductId、productId、vendorItemId、sellerProductItemId 和 externalVendorSku——分别存放在 listing 记录或对应的变体记录中。

从品牌 SKU 开始

品牌 SKU 应当是 ERP 中的主代码。团队已经用它采购、盘点、补货，并为每种实物商品生成报表。

Coupang 的这些 ID 描述的是商品在 Coupang 平台内的身份。它们不能取代品牌在自有系统中使用的编码。连接器应关联两个系统，而不是把 Coupang 可变的商品分组 ID 当作唯一关联键。

以一家销售一款 500 ml 马克杯、提供两种颜色的饮具品牌为例：黑色使用 MUG-500-BLK，白色使用 MUG-500-WHT。

品牌实际有两个库存项。买家可能在一个 Coupang listing 下看到这两种商品，但黑色和白色仍必须分别统计库存，并分别匹配订单。

如果连接器只为该 listing 保存一个 productId，就无法表明 Coupang 的哪个选项对应 MUG-500-BLK 或 MUG-500-WHT。库存更新可能会落到错误的库存项，返回订单行时，连接器也可能无法可靠地匹配到品牌 SKU。

更稳妥的模型是：每个可售变体对应一条 ERP 记录。将选项层级的 Coupang 值保存在该记录中，同时单独保存 listing 层级的值。如果 Coupang 更改显示的商品分组，连接器可以更新这个平台字段，而不必改变品牌内部 SKU。

如果 Coupang 的应用程序接口（API）接受 externalVendorSku 字段，可以将品牌 SKU 写入该字段。这样在采购订单查询中，Coupang 可能会返回卖家自己的编码。这并不意味着连接器可以丢弃 Coupang 的 ID。品牌编码和 Coupang 值解决的是不同问题。

这是评估连接器时的第一项检查：它能否清楚展示一个品牌 SKU 对应到一个 Coupang 可售选项的完整路径？如果不能，就无法确保商品、库存和订单更新始终对应正确的 SKU 和选项。

Coupang 的五个商品字段分别代表什么

这些字段定义来自 Coupang 官方 Open API 开发者文档。请针对所使用的具体 API 调用检查请求和响应。用于识别 listing 的字段，不一定就是编辑选项或匹配订单所需的字段。

最常见的两个错误很容易概括。第一，连接器把 productId 当作永久值，即使 Coupang 可以更改它。第二，连接器把 vendorItemId 和 sellerProductItemId 当成同一个字段的两种叫法。

两者并不相同。vendorItemId 识别最小粒度的可售选项；sellerProductItemId 来自商品查询，在更改选项值时需要使用。要编辑选项的连接器必须将两个值分别保存在不同字段中。

创建 listing 与 ID 映射是两回事。Coupang Open API 可以上传商品目录，但连接器仍需要在 listing 及其选项创建完成后，保存返回的字段值。“能够创建商品”并不代表它能够在创建之后维护商品。

为什么 productId 不适合作为永久主键

productId 很有用，但不适合作为唯一的长期关联键。Coupang 表示，在合并或拆分商品时，这个值可能会改变。

合并可能会把多个商品归入一个显示分组。拆分则可能将一个分组拆成不同商品。无论哪种情况，如果 ERP 只保存了旧的 productId，就可能无法再判断当前哪个 Coupang 商品分组对应该 listing。

解决办法不是忽略 productId。应将它作为当前的 Coupang 值保存，并在平台返回新值时刷新它。同时还要保存以下关联：

• sellerProductId：对应整个注册商品
• vendorItemId：对应每个最小粒度的可售选项
• sellerProductItemId：用于编辑选项值
• externalVendorSku：用于卖家侧查询中的品牌自有编码

品牌 SKU 仍然是 ERP 中的主键。Coupang 的这些值告诉连接器，该 SKU 当前对应平台上的哪个商品或选项。

vendorItemId 是实用的选项级主键，但并不能单独完成映射。它不能替代 listing 级的 sellerProductId、用于编辑选项的 sellerProductItemId，也不能替代用于匹配卖家编码的 externalVendorSku。连接器必须分别保存这些值，因为它们在 API 中的用途不同。

工作示例：两个马克杯变体如何通过 ERP 流转

下面沿着上述示例，跟踪两个马克杯选项在 ERP 中的流转。Coupang 实际返回的值会是平台标识符。下面的说明展示连接器应保存哪些内容，以及每个字段应如何使用。

1. 创建 listing 记录。 连接器为注册商品保存一个 sellerProductId。它还保存当前的 productId，作为显示的商品分组。这些值描述的是 listing 层级，而不是两个独立的颜色库存。

2. 为每个可售变体创建一条选项记录。 黑色记录将 MUG-500-BLK 保存为品牌 SKU，并保存自己的 vendorItemId。白色记录保存 MUG-500-WHT 和另一个 vendorItemId。当两种颜色位于同一 listing 下时，两条记录都关联到同一个 sellerProductId。

3. 保存编辑引用。 创建后，商品查询会为每个选项返回一个 sellerProductItemId。连接器将该值保存到对应的选项记录中。如果 Coupang 接受后续的选项变更，就使用 sellerProductItemId 进行编辑。不要用猜测的 vendorItemId 替代它。

4. 更新正确选项的库存。 如果 ERP 需要减少黑色马克杯的库存，连接器会找到 MUG-500-BLK，根据已保存的 vendorItemId 更新黑色选项的库存。它不会只发送一个 listing 层级的 productId，然后希望 Coupang 自行推断发生变化的是哪种颜色。

5. 匹配订单行。 当采购订单查询返回 externalVendorSku 时，连接器可以将 MUG-500-BLK 匹配到品牌的黑色马克杯 SKU 记录。随后，ERP 会从对应 SKU 的库存中扣减，而不是从共享 listing 的总库存中扣减。

6. 处理商品分组变化。 如果 Coupang 合并或拆分商品并返回不同的 productId，连接器就更新当前的分组值。它会保留品牌 SKU、sellerProductId 和 vendorItemId 这些关联；Coupang 表示后两者不会变化。

ID 匹配并不能解决订单处理的全部问题。一条 Coupang 订单行可能包含多个实物单位。连接器必须将它映射到正确的 SKU 和数量；请参见为什么一条 Coupang 订单行不一定代表一个单位。ID 设计是第一步，但找到 ID 后，数量映射仍然重要。

评估连接器时的检查

不要把“支持 Coupang ID”当作完整答案。要求连接器供应商展示它保存的字段，以及每项操作所使用的值。

1. 是否保存全部五个值？ 你应该看到 sellerProductId、productId、vendorItemId、sellerProductItemId 和 externalVendorSku，而不只是一个笼统的“Coupang 商品 ID”字段。

2. 是否为每个可售 SKU 保留一个选项关联？ 要求对方展示一个包含两种颜色或两种尺码的 listing。每个变体都应有自己的 vendorItemId 和品牌 SKU。

3. 合并或拆分后会发生什么？ 回答应该说明连接器如何在保留品牌 SKU 和稳定的选项关联的同时，更新当前的 productId。“我们使用 productId 作为主键”是一个警示信号。

4. 创建后能否编辑选项值？ 如果能，询问它将 sellerProductItemId 保存在哪里，以及哪个查询会提供该值。只提到 vendorItemId 的供应商并没有回答选项编辑问题。

5. 如何匹配采购订单行？ 询问采购订单查询返回 externalVendorSku 时，连接器是否会读取它，并将其映射到 ERP 中的品牌 SKU。

6. 能否展示每次更新使用的 ID？ 创建商品、更新库存、编辑选项和匹配订单可能需要不同字段。连接器应向团队展示每项操作使用哪个字段。

保存这些 ID 后，仍需为每项操作选择正确的 API 调用。检查连接器针对每项操作发送的是哪个 Coupang 字段。不要只检查它能否创建 listing。价格和库存使用不同的 Coupang API 调用；请参见Coupang 的价格和库存调用是分开的。

只保存 productId 的连接器无法可靠地更新商品和订单。单独使用 vendorItemId 可能足以处理变体库存，但它本身无法覆盖 listing、选项编辑或卖家编码匹配。

关于 Coupang 商品 ID 的常见问题

我可以为每个变体都使用 sellerProductId 吗？

不可以。它识别的是注册商品，并将相关选项归在一起。每个尺码、颜色或其他最小粒度的可售选项，都应保存一个单独的 vendorItemId。

productId 没有用吗？

不是。应将它保留为当前的显示商品分组，并在具体 API 调用要求时传入。不要把它作为永久 ERP 主键，因为 Coupang 可能在合并或拆分商品时更改它。

vendorItemId 对连接器来说够用吗？

不够。它是实用的选项层级值，但完整的映射还需要 listing 层级的 sellerProductId、编辑层级的 sellerProductItemId，以及品牌 SKU 或 externalVendorSku。

externalVendorSku 可以替代 Coupang 的 ID 吗？

不可以。它是卖家自己的商品编码，有助于将采购订单结果匹配到 ERP。Coupang 的 ID 仍然负责将卖家 SKU 关联到 Coupang 的 listing 和选项。

Coupang 合并或拆分商品时应该怎么办？

连接器应刷新当前的 productId，并保留品牌 SKU、sellerProductId 和 vendorItemId 关联。显示的商品分组可以变化，但 ERP 中的 SKU 不应变化。

保存全部五个值就能保证同步吗？

不能。这五个值为连接器提供了所需的关联信息，但它仍必须发送正确的 API 调用，并将每个响应匹配到正确的 SKU 和数量。请使用 Coupang 官方开发者文档，核实每项操作所需的字段。