2023年秋天，我接手了一个家居类目卖家的 Listing 恢复项目。他有 17 个 SKU 在亚马逊美国站被批量下架，后台提示是”无效的 GTIN”。他第一反应是平台抽风，第二反应是找服务商”申诉”。我让他把 GS1 证书发过来，他发来一张电商平台上买的”UPC 码清单”截图，120 个码，花了不到 300 块，卖家旺旺的 ID 已经注销了。

我们花了六周才把这 17 条链接救回来，代价是重开 Listing、丢历史评论权重、错过一个旺季的备货窗口。事后复盘，真正的问题不是”条码买得便宜”，而是他从头到尾没有把 UPC 当成一项需要日常管理的资产。买的时候是一次性交易，用的时候是一次性填充，出问题的时候才发现没有任何台账可以追溯。

这篇文章讲的就是这件事：UPC 码方案设计到底该怎么做，GS1 注册之后那些”每天都会发生”的琐事，新品分配、多平台分发、换规格、退市回收，该怎么管。我会把我这两年在几十个跨境卖家身上看到的做法、踩过的坑、以及一套能落地的台账结构完整写出来。

一、核心结论：UPC 方案设计的本质是”资产管理”，不是”买码”

先把结论放在最前面。如果你只记住三句话，就是下面这三句。

1. UPC 是资产编号，不是商品身份证

很多人把 UPC 理解成”商品的身份证号”，这个隐喻是错的，它会直接导致后面所有决策走偏。身份证号跟着人走，人没了号就作废；而 UPC 是跟着商品的生命周期走，商品下架了、码还在你自己的资产池里，但你已经不能把它给下一个商品用了。

更准确的类比是”门牌号”。你买了块地（公司前缀），然后自己给楼栋分门牌号（商品参考码）。门牌号一旦分配出去，理论上就永久绑定那一栋楼，楼拆了门牌号也不会回收再给新楼用。因为物流、零售、平台、消费者端的系统里，这个号码已经留下了历史痕迹。

2. 方案设计要提前定的，只有三个参数

我见过太多人把 UPC 方案设计做成一堆 Excel 模板和流程图。其实真正需要在动手之前拍板的，只有三个参数：

• 公司前缀（GCP）的位数，它决定了你未来十年能分配多少个 UPC，也决定了你每年的固定持有成本。
• 商品参考码的分配规则，是顺序递增、按品类分段，还是按渠道分段。这决定了你后面查码、核对、审计的效率。
• 码与 SKU 的映射主键，用你内部的 SKU 编号做主键，还是用 UPC 做主键。这决定了你换平台、换 ERP 时会不会一地鸡毛。

这三个参数一旦定下来，后面的日常管理就是执行问题；定不下来或者定错了，后面每一天都在还债。

3. 日常管理只有四个动作

GS1 注册场景下的日常管理，拆到底就是四个动作，循环往复：

1. 分配：新品立项时，从池子里取出一个未使用的 GTIN，绑定到具体 SKU。
2. 登记：把 GTIN 及商品属性同步到 GS1 数据库和各个销售平台。
3. 变更：换包装、换规格、换供应商、换品牌主体时，判断是”沿用”还是”新开码”。
4. 退役：商品退市时，把 GTIN 标记为停用、冻结，而不是删除或复用。

看起来很朴素，但我要强调：这四个动作如果没有一个统一的台账承载，它们就会散落在运营的微信聊天记录、美工的文件夹、代运营的邮箱里，最终变成一场灾难。

二、GS1 注册场景里，你到底注册了什么

要谈日常管理，先得把 GS1 体系里的几个概念彻底分清。我发现在实际沟通中，90% 的混乱都来自概念混用，很多人把 UPC、GTIN、公司前缀、商品码当成同一个东西。

1. 公司前缀（GCP）：一次注册，长期占用

你去 GS1 成员组织注册，拿到的不是”一批 UPC 码”，而是一个公司前缀。这个前缀是一串数字，长度在 6 到 10 位之间（美国市场），全球范围内 GS1 的 GCP 长度范围更宽。

关键在于：前缀是你租的，不是买的。每年要交年费，不交就失效。失效之后，你名下所有的 GTIN 都会变成”无主码”，平台校验时会直接判定失败。我见过至少三个卖家因为换了财务负责人、年费扣款失败，导致整个店铺的条码在一个月内集体报警。

2. 商品参考码（Item Reference）：这部分才是你自己分配的

UPC-A 一共 12 位数字，结构是这样的：

这里有一个非常实用的换算关系：GCP 每短一位，商品参考码就多一位，可分配的号码数量就乘以 10。一个 6 位前缀能出 10 万个 UPC，一个 10 位前缀只能出 10 个。这就是为什么”容量”这件事必须在注册时就规划好。

3. 校验位：不能靠人手算的那一位

UPC-A 的第 12 位是校验位。它的存在是为了让扫码枪和系统能在读错一位数字时立刻发现。算法本身不复杂，但我强烈建议你不要手算，因为一旦算错，这个码在平台端就是无效的。

算法规则是：取前 11 位数字，奇数位乘以 3、偶数位乘以 1，全部相加，用 10 减去和的个位数，再对 10 取模。

# UPC-A 校验位计算（Python 示意）
def upc_check_digit(first_11: str) -> int:

if len(first_11) != 11 or not first_11.isdigit():

raise ValueError("需要正好 11 位数字")

total = 0

for idx, ch in enumerate(first_11):      # idx 从 0 开始

weight = 3 if idx % 2 == 0 else 1    # 第 1、3、5... 位权重为 3

total += int(ch) * weight

return (10 - total % 10) % 10

以 03600029145 为例

print(upc_check_digit("03600029145"))  # 输出 2，完整 UPC-A 为 036000291452

你可以拿手上的任何一个 UPC 去验算一遍。如果算出来的校验位和条码最后一位对不上，那这个码的来源就很可疑，正规渠道生成的码几乎不可能出现校验位错误，而低价批量转售的码里，手抄录入导致的错误并不罕见。

4. 别把变量计量码、店内码、箱码混进 UPC 体系

这是我在培训运营团队时必讲的一节。下面这三类码，经常会被人误当成 UPC 来用：

• 变量计量码（Variable Measure）：通常以 2 开头，用于生鲜、散装称重商品，码里编码的是重量或价格，不是商品身份。这类码是给零售 POS 现场生成的，不是你在 GS1 注册的资产。
• 店内码（Store Internal）：通常以 04 或 2 开头，是零售商自己内部用的，出了这家店就不认。
• 箱码 ITF-14 / GTIN-14：这是给外箱用的，14 位，最前面多了一个”包装指示符”（0-8 表示不同包装层级，9 表示变量）。它是 UPC-A 的前面补 0 再加指示符得到的，属于同一套体系的延伸，但不能拿去上架单品链接。

我遇到过卖家把 ITF-14 箱码填进亚马逊的单品 GTIN 字段，结果链接被判定 GTIN 无效。单品用 UPC-A 或 EAN-13，外箱用 ITF-14，这两者不能互换。

三、真实场景还原：一个跨境卖家的 UPC 日常长什么样

概念讲完，我们进入真实场景。我以一个年销 800 万美元、SKU 数约 600 的家居卖家为例，把他的 UPC 日常拆解成四类事件。

1. 新品立项时的条码申请

他们内部有一个新品立项流程：产品经理提需求 → 采购确认供应商 → 运营提交上架计划 → 这时才需要 UPC。问题在于，前面三个环节经常拖两三周，等运营想起要条码时，工厂已经开始印包装了。

后来我们把条码分配这件事往前挪：只要产品经理提交了立项单，运营就必须在同一天从码池里取码，登记到台账，并把 GTIN 同步给包装设计。这一步提前之后，包装返工率从每季度约 4 次降到接近 0。

2. 上架时的多平台分发

一个新品可能要上亚马逊美国站、加拿大站、沃尔玛、独立站、eBay。这里有一个经常被搞错的问题：同一个实物商品，在这几个平台上用的 GTIN 必须一致，因为这些平台背后都在校验同一个 GS1 数据库记录。

如果你在亚马逊填了一个码，在沃尔玛填了另一个码，短期内可能都能上架，但一旦平台做跨平台品牌核验，就会出现”同一商品多码”的冲突，链接可能被合并、被判重复，甚至被下架。

3. 换规格、换包装、换供应商

这是 UPC 日常管理里最容易出错的一类事件。判断标准只有一条：对消费者和零售系统而言，这是不是”同一个商品”。

我整理了一张判断表，这是我在实际项目里反复用的：

我要特别提醒”更换代工厂”这一条。很多卖家觉得换了工厂就该换码，其实不用。UPC 绑定的是品牌方和商品，不绑定工厂。反过来，如果工厂帮你印了包装，包装上的条码是他自己给你的，那就完全是另一回事了，这种情况你实际上是在用别人的资产。

4. 退市与条码回收

商品退市时，正确的做法是把 GTIN 在台账里标记为”已退役”，在 GS1 数据库里把商品状态更新为停售，但绝不把这个号码重新分配给新产品。

原因很直接：这个码可能还存在于零售商的库存系统、比价网站的历史价格记录、消费者的购物历史里。如果你把它复用给另一个商品，就会造成数据污染，用户搜到旧价格、零售商的收货系统识别成另一个 SKU、平台的类目匹配出错。

我见过一次比较严重的：一个卖家把退役的家纺 UPC 复用给了新上的厨房用品，结果沃尔玛的供应商系统里同一个 GTIN 对应两个不同类目，直接触发了合规审查，整个供应商账号被冻结了两周。

四、六个常见误区，我几乎每年都遇到

下面这六个误区，是我在实际项目里反复见到的。我按照”踩坑频率”和”后果严重程度”排序。

1. 误区一：UPC 可以回收复用

这是最普遍也最危险的误区。持这种想法的人通常的逻辑是：”这个商品都不卖了，码空着多浪费。”

但 UPC 不是稀缺资源。你真正稀缺的是”商品身份的唯一性”。一个码复用之后，你在所有下游系统里的数据一致性就被破坏了。省下的是一个码的成本，赔上的是整条数据链的可信度。

2. 误区二：第三方转售的条码便宜又省事

市面上一直有大量低价 UPC 在流通。有的是别人注册了大容量前缀之后拆零转售，有的是批量导入产生的”孤儿码”。价格可能只有官方的十分之一甚至更低。

问题在于，这些码的归属权不在你手里。GS1 数据库里记录的公司名称不是你的公司，品牌也不是你的品牌。当平台开始做 GTIN 归属校验时，亚马逊的品牌注册流程中这一步做得越来越严，这些码就会被标记为异常。

3. 误区三：GS1 数据库填一次就不用管了

很多人注册完之后，只在 GS1 数据库里填了一两条最基础的信息，之后再也不登录。

问题是，GS1 数据库记录是平台校验 GTIN 时的重要数据源。如果你的商品信息在数据库里缺失、过期、品牌名与实际不符，平台的自动校验就会失败。尤其当你在多个平台使用同一个 GTIN 时，数据库记录是它们互相核对的公共参照。

我的建议是：把 GS1 数据库更新纳入新品上架 SOP，和图片拍摄、Listing 撰写放在同一个检查清单里。每次商品属性发生实质变化，都要同步更新。

4. 误区四：EAN 和 UPC 可以随意互换

EAN-13 是 13 位，UPC-A 是 12 位。在美国市场上，EAN-13 前面加一个 0 就是 UPC-A，它们本质上是同一套编号体系的不同表示。所以严格说，美国站上 UPC-A 和 EAN-13 是可以互相转换的。

但这里有两个坑。第一，不是所有 EAN-13 前面都是 0，比如以 69 开头的中国前缀、以 45/49 开头的日本前缀，它们转成 UPC-A 时前面的数字不为 0，就被称为 EAN-13 而非 UPC-A，部分老平台只接受 UPC-A。第二，格式转换不能改变码本身，把 EAN-13 的前缀截掉重新凑 12 位，那是直接毁码。

5. 误区五：设计公司或代运营会帮我管条码

这是我在接手项目时最头疼的一类情况。卖家把条码交给包装设计公司，设计公司印在包装上，但双方从来没有确认过条码的归属和台账。

结果是：卖家不知道自己的 GCP 是什么，不知道用了多少码、还剩多少码，不知道每个码对应哪个 SKU。一旦要换设计公司，这条线就彻底断了。

我的原则很明确：条码台账的所有权必须在品牌方手里，任何外部合作方都只是使用者。设计公司可以拿到某个 SKU 的 GTIN 用于排版，但不能拥有码池的管理权。

6. 误区六：条码图片能生成就能用

条码图片有明确的技术标准：条空宽度比例、静区留白、边缘对比度、印刷尺寸、放大系数。用免费在线工具生成的条码图片，很多在尺寸和静区上不符合 GS1 通用规范，打印机一印出来扫码枪就读不出来。

我建议的做法是：条码图片交给有 GS1 认证资质的条码生成软件或印刷厂生成，并在打样阶段用至少两台不同品牌的扫码设备实测。尤其是小尺寸包装，条码缩得太小是扫码失败的头号原因。

五、专业判断逻辑：怎么选才不出事

说完误区，我讲我实际做选型判断时的逻辑框架。这个框架我用在至少三十个项目上，基本能覆盖绝大部分决策场景。

1. 判断的五个维度

我评估任何一套 UPC 方案，都看这五个维度：

1. 渠道覆盖：要上哪些平台？有没有线下零售、批发、分销？后者对 GTIN 的规范性要求比电商高一个等级。
2. SKU 增长曲线：未来三年 SKU 数量会增长到什么量级？是线性增长还是变体爆炸式增长？
3. 合规等级：是自有品牌还是白牌？要不要做品牌注册？目标市场有没有 GS1 强制要求？
4. 主体复杂度：一个公司主体还是多个？多个品牌是不是同一主体？这决定了要不要多个 GCP。
5. 变更频率：一年换几次包装、上几个新规格？变更越频繁，台账的自动化程度要求越高。

2. 容量规划的计算方法

容量规划不是”我今年有 100 个 SKU，就买 100 个容量”。正确的算法是这样的：

先算当前活跃 SKU 数，然后乘以变体系数，再乘以三年增长系数，再乘以安全冗余系数，最后加上已退役但需保留编号的历史 SKU。

所需 GTIN 容量 ≈ (当前活跃 SKU 数 × 变体系数 × 三年增长系数 × 安全冗余) + 历史退役码数
举例：

当前活跃 SKU：180

变体系数：2.5（颜色/尺寸/套装）

三年增长系数：1.8

安全冗余：1.3

历史退役码：约 60

所需容量 ≈ 180 × 2.5 × 1.8 × 1.3 + 60 ≈ 1,113

结论：应选择容量 10,000 的档位，而不是容量 1,000

因为 1,113 已经超过 1,000，且未来仍有增量

这个算法里，最容易低估的是变体系数。一个看起来只有 30 个产品线的品牌，加上颜色、尺寸、套装、渠道特供版本，实际 SKU 数往往是产品线数的 2-3 倍。很多卖家在第二年就撞到容量上限，根源就在这里。

3. 成本结构拆解

UPC 的成本有三块，很多人只算了第一块：

• 注册费与年费：GS1 成员组织收取，与容量档位相关，属于固定成本。
• 管理成本：台账维护、数据库更新、跨平台核对投入的人力时间，这是最容易被忽略的一块。
• 风险成本：条码失效导致的下架、重开 Listing、申诉、备货延误、旺季错失。

4. 数据主权的判断

我在每个项目里都会问一个问题：如果明天你换了 ERP、换了代运营、换了三个平台，这套条码数据还能不能用？

能，说明数据主权在你手里。不能，说明你只是在使用别人给你的号码。

数据主权体现在三个地方：GS1 数据库里的注册主体是你；台账文件在你的可控存储里；GTIN 与 SKU 的映射关系由你定义和维护。这三点缺任何一点，你的条码体系就是脆弱的。

六、数据观察：用数跨境搭一套 UPC 台账的实践

前面讲的都是原则。接下来我讲一个具体的落地做法：把 UPC 台账从 Excel 搬到数据工具里，做成可持续更新的看板。

我在几个项目里用的是数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）。选它的原因不是它专门做 UPC 管理，而是它适合做跨境场景下的多源数据汇总，把 GS1 导出的码池、平台的 Listing 数据、内部的 SKU 主数据拉到一张表里对齐，然后做异常检测。这恰好是 UPC 日常管理最需要的。

1. 台账需要哪些字段

不管用什么工具，UPC 台账的字段设计是核心。我在多个项目里反复迭代后，固定成了下面这几组：

这七组字段里，最容易被忽略、但价值最高的是”GS1 同步”和”平台校验状态”。前者保证公共数据源不出错，后者是你发现问题的雷达。

2. 看板看什么指标

把台账搭起来之后，我通常在这类工具里做四个视图：

1. 码池健康度：已使用 / 未使用 / 冻结 / 退役的分布，剩余可用容量和预计耗尽时间。
2. 平台一致性：同一 SKU 在各平台的 GTIN 是否一致，不一致的单独列出来。
3. 同步时效：距离上次 GS1 数据库更新的天数，超过阈值的高亮。
4. 变更流水：最近 30 天新增、变更、退役的码，用于周会review。

3. 上线前后的变化

我记录过一个 600 SKU 的家居卖家上线台账看板前后的对比。需要说明的是，这是我在实际项目中记录的观察值，属于单案例情景数据，不是行业统计。

七、不同情况下的行动建议

下面按卖家所处的阶段给出具体动作。我建议你直接对号入座，不要跳着看。

1. 起步期（活跃 SKU 少于 50）

这个阶段的建议是：直接向 GS1 成员组织注册公司前缀，不要买第三方转售码。

1. 估算三年内可能的最大 SKU 数（含变体），在此基础上乘 1.5 的冗余。
2. 如果估算结果在 1,000 以内，可以先注册对应容量档位；如果预计会超过，直接跳到更大档位，避免二次申请。
3. 建一个最小台账：GTIN、内部 SKU、商品名称、分配日期、状态、绑定平台。用表格即可。
4. 注册完成后立刻在 GS1 数据库登记第一批商品，把同步动作写进上架 SOP。

这个阶段最常见的错误是”先买几个单码应付一下”。单码采购在起步期看起来灵活，但一旦你要做品牌注册，归属权这条就过不去，最后还是要重新注册 GCP，前面的码全部作废。

2. 成长期（活跃 SKU 在 50 到 1,000 之间）

这个阶段的关键动作是把台账从个人表格升级为团队共享、可追溯的资产台账。

1. 补齐台账的七组字段，重点是平台校验状态和 GS1 同步状态。
2. 定义取码规则：谁可以取码、从哪里取、取完必须登记什么信息。
3. 建立退役流程：退役码必须标记状态并写原因，禁止任何形式的复用。
4. 开始做周检：每周花 30 分钟核对新增码、状态变更、同步缺失。

我在这个阶段见过最多的失败模式是”台账只有一个运营在维护，她一休假就断档”。解决办法不是找人备份，而是把台账变成任何团队成员都能读、能查、能自助取码的共享结构。

3. 多品牌、多主体运营

如果你旗下有多个品牌，且品牌归属不同公司主体，这里有一个必须搞清楚的判断：GS1 的注册主体应当与商品包装上标注的品牌方一致。

这意味着，如果 A 公司和 B 公司是两个品牌主体，理论上应该分别注册 GCP，各自持有自己的条码。用一个 GCP 覆盖多个不同品牌主体，会在品牌注册和平台核验时产生归属冲突。

• 如果多个品牌同属一个法人主体，可以共用一个 GCP，但建议按品牌划分商品参考码的号码段，便于区分。
• 如果品牌分属不同法人主体，建议分别注册，避免后续股权变更、品牌转让时出现资产纠缠。
• 无论哪种情况，台账中都必须有”主体公司”和”品牌”两个独立字段，不能合并。

4. 已有历史条码，需要迁移

迁移是最麻烦的场景，因为你要处理”旧码还在流通”这件事。我的建议是分三步走：

1. 盘点：把当前所有在售、在库、在途商品的 GTIN 全部列出来，标注来源（自有 GCP / 第三方 / 未知）。
2. 分类处理：自有 GCP 的码继续沿用，只补台账；第三方来源的码，按销量分批处理，高销量的优先迁移。
3. 迁移方式：新品用新码；老品可以通过换包装的时机自然切换，同时在平台侧更新 GTIN 需要谨慎操作，避免触发链接审核。

这里要提醒一句：平台侧的 GTIN 修改不是随时可以做的，很多平台对已上架商品的 GTIN 变更有严格限制。所以迁移节奏必须和包装更新节奏、平台规则一起排期。

5. 已经在用第三方转售条码

这是我最常接到的求助场景。我的处理顺序是：

1. 先做风险分级：把用了转售码的 SKU 按销量和平台数量排序，找出”高销量 + 多平台”的高风险品。
2. 对高风险品，优先启动迁移，不要等平台通知。
3. 对低风险品（单一平台、低销量），可以跟随下次包装更新自然切换。
4. 同时立刻注册自有 GCP，建立台账，确保新品不再使用转售码。

我不建议”一次性全部换掉”，因为那会造成巨大的包装浪费和平台审核风险。分批迁移、以包装更新为触发点，是成本最低的路径。

八、不同情况下的取舍

行动建议之后，我把几个关键的取舍点单独拎出来讲，因为这些地方没有标准答案，只有适合你的答案。

1. 官方 GCP、单码采购、第三方转售，怎么选

我的判断很直接：只要你打算长期做品牌，唯一正确的选择是官方 GCP。单码采购只是过渡手段，第三方转售码应该被视为技术债，而不是省钱方案。

2. 自建表格 vs 工具化看板

这个取舍的临界点不是 SKU 数量，而是平台数量 × 变更频率。

• 单平台、低变更频率、SKU 少于 100：表格足够，不必上工具。
• 两到三个平台、有变体、SKU 超过 200：开始出现核对漏项，建议工具化。
• 四个以上平台、多主体、SKU 超过 500：人工已不可靠，工具化是必需品。

需要说清楚的是，工具化不是要买一套专门的”UPC 管理系统”。我用的做法是把它挂在已有的数据工具里，复用已有的 SKU 主数据和平台数据，只新增 UPC 相关的字段和视图。这样的好处是数据源统一，不用维护两套 SKU 信息。

3. 集中管理 vs 分散管理

有些公司让每个事业部自己管自己的码，有些公司统一由总部管理。我的判断依据是品牌主体的独立程度。

同一主体下的多品牌，建议集中管理，因为共享同一个 GCP，分散管理必然导致号码段冲突。不同主体下的品牌，建议各自独立管理，但用统一的数据结构，方便集团层面汇总查看。

4. 提前扩容 vs 按需扩容

扩容意味着重新申请 GCP、迁移所有商品、更新所有平台的 GTIN，成本极高。所以我的建议是：容量规划要至少向前看三年，宁可多买，不要卡边。

多买的成本是每年固定的年费差额，通常就是几百到几千美元的级别；而扩容一次的成本，包括重印包装、更新平台、可能的链接重建，往往是前者的几十倍。

5. 2027 年 2D 条码迁移：现在准备还是再等等

GS1 推动的 Sunrise 2027 计划，是要让零售端从一维条码逐步过渡到 GS1 2D 条码（带 GS1 Digital Link 的二维码形态）。这不是一个”要不要做”的选择题，而是一个”什么时候排期”的问题。

我的判断是：现在不需要立刻改包装，但必须现在把 GTIN 台账和商品数据整理干净。因为 2D 条码承载的信息远多于 12 位 GTIN ， 批次、效期、序列号都可能进去。如果连最基础的 GTIN 与 SKU 映射都是乱的，迁移时就是一场灾难。

九、我的核心判断与下一步动作

写到这里，我想把最核心的判断再收拢一次。

UPC 方案设计的难点从来不在”注册”这一步，而在注册之后那三千次日常判断。新品该不该开新码、老码能不能复用、平台之间对不上怎么办、换了代工厂要不要换码，这些问题每天都会冒出来，而且每一次判断错了，代价都会在几个月后以链接下架、库存积压、旺季错失的形式回来找你。

第二个判断是：UPC 管理的成熟度，本质上是这家公司的 SKU 主数据成熟度的投影。如果你的 SKU 主数据本身就是乱的，那么不管用什么工具管条码，都只是在乱上加乱。所以真正该先做的，是把”一个 SKU 只有一个唯一编号、一个 GTIN 只绑定一个 SKU”这条规则立起来。

第三个判断是：把 UPC 从”运营的私人表格”升级为”公司的公共资产台账”，是性价比最高的一次管理投入。它不改变产品，不改变供应链，但它能让你在平台规则越来越严的环境下，少掉很多本不该掉的链接。

如果你现在就要动手，我建议按这个顺序：

1. 今天：确认你的 GCP 注册主体是谁、年费什么时候到期、GS1 数据库里的品牌名是否和包装一致。
2. 本周：把当前所有在售 SKU 的 GTIN 列成一张表，标出每一条的来源，把来源不明的单独标红。
3. 本月：建立七组字段的台账，确定取码、登记、变更、退役四个动作的责任人。
4. 本季度：把台账接入你已有的数据工具，做码池健康度、平台一致性、同步时效、变更流水四个视图，开始周检。
5. 今年内：完成容量规划复盘，确认当前档位能不能撑过三年；把 2D 条码迁移的数据准备工作排进年度计划。

UPC 这件事，做得好的时候你完全感觉不到它的存在；做得不好的时候，它会以最不讲道理的方式，在你最忙的季节给你制造麻烦。它值得被当成一项正经的日常管理工作来对待。