去年底我帮一家做家居品类的跨境卖家做数据审计，发现他们 ERP 里有 1400 多个在售 SKU，但 GS1 后台里登记的产品只有 900 多条。也就是说，有 500 多个 SKU 的 UPC 要么是从第三方转售商买的，要么是早期用 Excel 手工算出来的，还有 30 多个 UPC 干脆被两个 SKU 共用。这个问题被发现时，他们已经被亚马逊驳回过两次品牌备案，理由是 GTIN 与 GS1 数据库记录不匹配。
这件事让我意识到，UPC 码方案设计这件事，大家讨论的重心一直放错了。绝大多数内容都在讲”要不要买 GS1 官方 UPC””第三方 UPC 能不能过品牌备案”，但真正的工程难题在后面：当你的 SKU 从 200 涨到 2000，GS1 注册这件事怎么从”一个人手工录入”变成”系统自动跑”。这篇文章只讲第二件事。
我先把判断抛出来：UPC/GS1 注册的自动化不是一个脚本能解决的问题，它是三个层次的事情，而且每一层的失败模式完全不同。很多人一上来就想写代码调 API，结果发现 GS1 对中小账号根本没有开放的写接口，项目就停在那里了。
这一层的目标很简单：给定 GS1 分配给你的公司前缀，批量、无重复、可追溯地生成 GTIN，并且保证校验位计算正确。这一层纯计算，不涉及网络请求，也不涉及任何平台的合规判断。
我通常用一个 200 行以内的 Python 脚本就能覆盖：读前缀容量表、维护已用号段、计算校验位、输出带版本号的分配记录。这一层的工程量大概半天到一天，但它解决的是一类最隐蔽的批量事故，重复分配和校验位错误。
说它隐蔽是因为它不会立刻报错。一个校验位算错的 UPC，在你自己仓库里能扫、在打包单上能打印、在 ERP 里能存，直到亚马逊或沃尔玛做 GTIN 有效性校验时才一次性爆出来。等到那时候，你面对的是几百条被下架的商品链接。
这一层才是真正的分水岭。目标是把”生成好的 GTIN”上报到 GS1 的产品数据库，并且带上正确的品牌名、产品名、品类描述。它涉及到登录、表单填写、文件上传、回执下载，而 GS1 面向中小账号提供的主要是手工后台和批量文件上传，开放写接口的覆盖面非常有限。
所以这一层的自动化，本质上是把”人点鼠标”降级为”人准备数据 + 工具做提交 + 人做结果校验”。听起来没那么性感，但真实项目里 80% 的收益来自这一层。
第三层是把 GS1 登记数据、你的 ERP 主数据、各个销售平台（亚马逊、沃尔玛、Wayfair 等）的商品信息做成同一份真相源。任何一头改了品牌名或产品名，其他两头要能被检测出漂移并触发修正。
这一层最容易被忽略，因为它的故障是”慢性的”。第三方转售的 UPC 之所以在品牌备案时被识别出来，通常就是因为 GS1 记录里的品牌名和亚马逊后台填的品牌名对不上。不是号码假，是号码背后的登记数据和你自己声称的身份不一致。
要设计自动化方案，先得把 GS1 的机制拆清楚。我发现很多卖家对 GS1 的理解停留在”买 UPC 的地方”，这会导致后面所有的方案设计都建立在错误前提上。
GS1 给你的核心资产是公司前缀（Company Prefix），一个 6 到 10 位的数字。你用这个前缀 + 你自己分配的商品参考号 + 校验位，拼出一个完整的 GTIN。前缀越短，你能分配的商品位越多，容量越大，年费也越贵。
举个具体的：如果你的前缀是 7 位，那么 GTIN-12（也就是 UPC-A）的结构就是 7 位前缀 + 4 位商品号 + 1 位校验位，理论容量 10000 个。如果前缀是 9 位，结构变成 9 + 2 + 1，容量只剩 100 个。这直接影响你要买哪一档。
| GS1 提供的前缀长度 | GTIN-12 可用商品位 | 理论容量 | 适用判断 |
|---|---|---|---|
| 6 位 | 5 位 | 100,000 | SKU 数超万、有子品牌矩阵的集团 |
| 7 位 | 4 位 | 10,000 | 多数中大型跨境卖家的甜点区 |
| 8 位 | 3 位 | 1,000 | SKU 千级、增长可预期的卖家 |
| 9 位 | 2 位 | 100 | 只做少量精品的品牌 |
| 10 位 | 1 位 | 10 | 几乎只适合试点或极小型卖家 |
我见过最典型的踩坑是：卖家早期为了省钱买了 100 个 GTIN 的档位，两年后 SKU 涨到 800，不得不重新申请更长前缀。新款前缀和老前缀无法合并，结果库存里同时存在两套编码体系，ERP 里的商品主键一度混乱了三个月。
很多人以为 GS1 的费用就是”按 GTIN 数量一次性买断”。实际上 GS1 US 的定价是初始注册费 + 按年度缴纳的续费，续费金额同时受 GTIN 容量档位和公司年收入档位影响。下面是行业里比较常见的参考区间，具体以 GS1 US 官网实时报价为准：
| GTIN 容量档位 | 初始费用（参考） | 年费区间（参考） | 单 GTIN 首年成本 |
|---|---|---|---|
| 单个 GTIN | 30 美元/个 | 无年费 | 30 美元 |
| 10 个 | 约 250 美元 | 50-250 美元 | 约 30 美元 |
| 100 个 | 约 750 美元 | 150-750 美元 | 约 9 美元 |
| 1,000 个 | 约 2,500 美元 | 500-2,500 美元 | 约 3 美元 |
| 10,000 个 | 约 6,500 美元 | 1,500-6,500 美元 | 约 0.8 美元 |
| 100,000 个 | 约 10,500 美元 | 2,500-10,500 美元 | 约 0.13 美元 |
这张表里最关键的一列是”单 GTIN 首年成本”。它说明一件事：档位选得太小，单位成本会成倍上升；档位选得太大，你为用不上的容量白交年费。这个决策点应该在自动化方案设计之前就定下来，因为它直接决定了你的号码池是 100 个还是 10000 个，而号码池大小会影响你整个分配脚本的数据结构设计。
我做过一个不太严谨但很有说服力的对照：把 2021 年到 2024 年间我经手的、因为 GTIN 问题被平台拦下的案例做归因。样本不大，只有 47 起，但分布很清楚。
这四类里，只有第一类跟”你从哪买”有关，后三类都跟你自己的流程有关，而且都可以通过自动化彻底消除。这也是我为什么坚持先做第一层和第二层，再纠结采购渠道。
GS1 的授权是按年续费的。年费断缴，前缀授权失效，你名下所有基于该前缀生成的 GTIN 都会在 GS1 数据库里变成无效记录。这时候你的商品可能还在卖，但一旦平台做定期校验，就会出现”GTIN 无效”的下架风险。
我见过一家做宠物用品的卖家，2022 年因为财务交接漏缴了年费，2023 年重新付费后以为记录会自动恢复，结果发现部分 GTIN 需要重新登记，而已经在亚马逊上线的 200 多条链接因为 GTIN 状态变更触发了审核。年费这件事，应该写进你的财务日历，而不是靠人记。
校验位不是给内部用的，是给扫描设备和平台校验用的。UPC-A 的算法是固定的：前 11 位里奇数位（第 1、3、5、7、9、11 位）乘 3，偶数位乘 1，求和后对 10 取模，再用 10 减去余数，结果如果是 10 就取 0。
def upc_check_digit(eleven_digits: str) -> str:
"""
计算 UPC-A 的第 12 位校验位
eleven_digits: 11 位数字字符串，例如 "03600029145"
"""
if len(eleven_digits) != 11 or not eleven_digits.isdigit():
raise ValueError("输入必须是 11 位纯数字")
total = 0
for idx, ch in enumerate(eleven_digits):
digit = int(ch)
索引 0 对应第 1 位，奇数位乘 3
weight = 3 if idx % 2 == 0 else 1
total += digit * weight
remainder = total % 10
check = (10 – remainder) % 10
return str(check)
验证：03600029145 应该得到 2
print(upc_check_digit("03600029145")) # 输出 2
这段代码我用了三年，从来没出过问题。我会把校验位计算放在分配流程的最后一步，并且在上报 GS1 之前做一次全量回验：把已分配的 GTIN 全部重新算一遍校验位，任何一个不匹配就中止整批提交。这一步能在 5 秒内拦下 99% 的手工错误。
现在亚马逊在品牌备案环节会去 GS1 数据库做核对，重点看品牌名是否与备案品牌一致。第三方转售的 GTIN 即便号码本身有效，登记在数据库里的品牌名也不可能是你的品牌，这是结构性矛盾，不是靠申诉能绕过去的。
所以我的判断很直接：如果你打算做品牌备案、做品牌旗舰店、做 A+ 页面，那就别在 UPC 采购上省这个钱。1,000 个 GTIN 一年的成本，往往还不到一次品牌备案被驳回后重做 listing 的人工成本。
亚马逊的变体体系里，父 ASIN 不需要 GTIN，但每一个子 ASIN 都需要独立的、唯一的 GTIN。把同一个 UPC 分配给红色和蓝色两个变体，属于典型的重复分配，会触发平台的重复商品检测。
更麻烦的是，一旦两个子 ASIN 共用一个 GTIN，你后面做库存同步和销量归因时数据会互相污染。我在做数据审计时遇到过这种情况：一个 UPC 下挂着 3 个 SKU 的销售数据，导致补货模型完全失效。
这是最影响方案设计的一个认知偏差。GS1 US 的 Data Hub 确实有面向企业的接口能力，但对中小账号来说，开放写接口的可用性远没有想象中那么高。很多账号能拿到的仍然是后台界面加批量文件上传。
这意味着你的自动化方案必须做两手准备：优先走官方提供的批量文件通道，其次是受控的浏览器自动化，最后才是人工兜底。一上来就指望 API 全自动，通常会卡在权限申请或者账号层级上，白白浪费两三周。
我不建议所有卖家都上系统化方案。我见过年新增 20 个 SKU 的卖家硬要做一套全链路自动化，结果维护成本比人工还高。判断的核心变量有三个：年新增 SKU 数、在售 SKU 总数、销售渠道数。
我的经验公式是这样的：把每年花在 UPC 分配、登记、核对、纠错上的总人时估算出来，如果超过 120 人时（约 15 个工作日），就值得考虑至少第一层自动化。
120 人时这个数字不是拍脑袋定的。一个熟练运营处理单个 SKU 的完整流程，分配 GTIN、算校验位、去 GS1 后台登记、回填 ERP、在平台后台填写、后续核对，平均需要 40 到 50 分钟。年新增 150 个 SKU 就基本触到这条线。
| 年新增 SKU 数 | 估算年人工耗时 | 推荐方案层级 | 理由 |
|---|---|---|---|
| < 50 | < 40 人时 | 只做第一层（校验位脚本） | 分配量小，重复风险低于人工核对的便利性收益 |
| 50 – 150 | 40 – 120 人时 | 第一层 + 表格模板规范 | 建立统一分配记录即可，无需系统化 |
| 150 – 500 | 120 – 400 人时 | 第一层 + 第二层 | 批量上报的收益开始明显超过实施成本 |
| 500 – 2000 | 400 – 1600 人时 | 完整三层 | 多平台一致性成为主要风险点，必须有漂移检测 |
| > 2000 | > 1600 人时 | 完整三层 + 独立编码治理角色 | 编码管理已经是一个需要专职负责的职能 |
这是我强烈建议的一条顺序原则：不要在一堆脏数据上做自动化，那只会把错误放大。自动化系统会忠实地把你已有的错误以更快的速度、更大的规模复制出去。
正确的顺序是：
跳过前三步直接写代码，是这类项目最常见的失败原因。我见过一个团队花了三周开发自动登记工具，上线第一天批量提交了 600 条记录，其中 100 多条因为品牌名不一致被拒，反而制造了一次更大的清理工作。
下面这个案例是我参与过的项目，数据来自实际记录，做了脱敏处理。这家卖家做 3C 配件，主要渠道是亚马逊北美加沃尔玛，2023 年初在售 SKU 约 620 个，年新增约 480 个。
他们最初的流程是：运营在共享 Excel 里登记新品的 UPC，这个 Excel 由 3 个人共同维护，没有版本控制。每季度做一次抽查，平均每次抽查都能发现 5 到 8 条异常，包括重复分配、校验位错误、还有个别 UPC 是早期从转售商买的。
最严重的一次是 2023 年 4 月，一个新品在亚马逊上线后两周被系统判为”与已有商品重复”，原因是这个 UPC 在半年前已经被分配给另一个品类的产品，而 Excel 里的记录被后来的人覆盖掉了。这次事故导致该链接的历史评论和排名全部清零。
阶段一（第 1-2 周）：数据清理与规则固化。拉出全部 620 个在售 SKU 的 GTIN，与 GS1 后台记录逐条比对，最终修正了 47 条不一致记录，清理出 6 个重复分配的 UPC，并把 12 个来源不明的 UPC 替换为官方 GTIN。同时把共享 Excel 换成带权限和版本记录的集中表。
阶段二（第 3-6 周）：第一层和第二层自动化。开发了号码分配脚本，输入产品线代码和批次号，自动从号码池取号、算校验位、写回分配表，并生成 GS1 批量上传所需的 CSV 模板。同时写了一个回执解析脚本，把 GS1 返回的处理结果自动比对到分配表，标记成功和失败。
阶段三（第 7-14 周）：第三层一致性检查。建立了一个每日跑的对账任务，比对 GS1 数据库记录、ERP 商品主数据、亚马逊与沃尔玛后台商品信息三者之间的品牌名、产品名、GTIN 三项字段，发现不一致就生成工单。
这个项目里我接触到的一个思路，是把这类”跨境编码与商品数据管理”的活儿，交给专门的跨境数据服务平台来做，比如数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm_plan=est&utm_unit=gys）。它的定位是跨境场景下的数据管理服务，核心价值在于把原本散落在 Excel、ERP、各平台后台的编码与商品数据做集中管理。
我的判断是：如果你团队里没有稳定的数据开发资源，而年新增 SKU 又在 300 以上，那么用现成的跨境数据管理平台承接编码数据的集中管理，通常比自建划算。原因不是自建做不出来，而是自建方案需要有人长期维护，脚本会随 GS1 后台改版、平台接口变更而失效，这部分运维成本经常被低估。
反过来，如果你已经有成熟的数据团队，且核心诉求是和现有 ERP 深度耦合，那么自建的灵活性仍然更高，不需要为了统一管理去迁就外部平台的数据模型。
| 指标 | 改造前 | 改造后（第 14 个月） | 变化 |
|---|---|---|---|
| 累计异常 UPC 条数（季度抽查） | 5-8 条 | 0-1 条 | 下降约 88% |
| 单个 SKU 从取号到可上架耗时 | 平均 3.5 天 | 平均 0.6 天 | 缩短约 83% |
| UPC 相关人工工时（月） | 约 52 人时 | 约 11 人时 | 下降约 79% |
| 因 GTIN 问题导致的链接下架 | 年均 4 次 | 0 次 | 消除 |
| GS1 记录与平台后台字段一致率 | 约 84% | 约 99.3% | 提升 15.3 个百分点 |
这个量级我建议只做三件事：一是用统一的分配记录表，二是把校验位计算交给脚本而不是心算，三是至少每季度做一次 GS1 后台与平台后台的比对。
记录表的关键字段我建议至少包含：GTIN、分配日期、分配批次、对应 SKU、产品线、品牌名、GS1 登记状态、平台填写状态、备注。字段看起来多，但每一条异常排查时你都会用到。
这个量级的核心问题不是单条处理速度，而是批次管理。建议按季度或者按产品线分批取号，每批生成独立的号码段和上传文件。好处是出问题时影响范围可控，而且批次号能作为后续追溯的锚点。
这个阶段不需要开发系统，但需要一个人固定负责。我见过很多卖家在这个阶段失败，原因不是技术，是责任不清晰，三个运营都能改分配表，等于没人负责。
到了这个量级，逐条在后台录入的时间成本已经不可接受。核心动作是：把 GS1 的批量上传模板固化成一个自动生成的输出，把回执解析自动化，把失败项自动生成待处理工单。
这三个动作里，回执解析最容易被低估。GS1 返回的处理结果文件格式并不总是友好，也不总是即时可用，很多项目卡在这里。我的建议是把它做成幂等的任务，同一个批次重复解析不应该产生重复工单。
这个量级下，UPC 管理已经不是某个运营的附带工作，而是一个需要明确责任人和明确 SLA 的职能。我建议设立一个”商品编码治理”角色，哪怕只是兼职，也要有明确的职责说明和对账节奏。
同时，这个量级必须考虑和销售渠道的接口打通。亚马逊、沃尔玛等平台在商品信息校验上的严格程度在持续提高，靠人工核对已经跟不上校验频率。
我在这一条上的立场很明确：只要你的业务涉及品牌备案、品牌旗舰店、A+ 内容、或者任何依赖品牌资产的运营动作，就必须用官方 GTIN，没有中间地带。
转售 GTIN 的诱惑在于价格差，一个号码可能只要一两美元。但这个差价买到的是一份无法验证来源、无法控制品牌名的登记记录。当平台开始做 GTIN 与品牌名的交叉核验时，这些号码会变成负债而不是资产。
唯一的例外是纯铺货、不做品牌、随时准备换链接的玩法。但这种模式本身在当前平台环境下空间已经很小，我不建议围绕它设计编码方案。
这两者的取舍不在功能，而在你有没有能力承担长期维护。
我见过最糟糕的中间态是：自建了一套脚本，但没人维护，两年后 GS1 后台改版，脚本失效，团队又退回手工，同时还要处理脚本时代留下的不规范记录。这种情况不如一开始就选平台化。
不是所有环节都值得自动化。我的取舍原则是：高频、规则明确、错误后果严重的环节优先自动化；低频、需要判断、错误可逆的环节保留人工。
| 环节 | 是否建议自动化 | 判断理由 |
|---|---|---|
| 校验位计算 | 强烈建议 | 纯规则，零判断，错误后果严重 |
| 号码分配与去重 | 强烈建议 | 高频操作，重复分配后果不可逆 |
| GS1 批量上传文件生成 | 建议 | 模板固定，纯格式转换 |
| 上传回执解析 | 建议 | 规则可枚举，人工逐条核对极其枯燥 |
| GS1 后台登录与提交 | 视接口开放度 | 如果只能用浏览器自动化，维护成本偏高，需评估 |
| 品牌名与产品名填写 | 不建议全自动 | 涉及品牌表述，一旦批量写错影响面大 |
| 异常工单处理 | 不建议 | 需要判断，自动化只会制造更多误判 |
我的建议是按三年预期容量买，而不是按当前容量买。理由是前缀一旦确定很难更换，而升级档位通常意味着重新申请前缀，导致新旧编码体系并存。
但同时要注意不要买得过大。100,000 个档位的年费对中小卖家是明显浪费，而且更大的容量并不带来更好的功能。我的判断区间是：估算三年后的 SKU 峰值，向上取最接近的档位，最多再上一档作为缓冲。
写到这里，我把整篇文章的判断收敛成一条可执行的路径。
导出所有在售和备货中 SKU 的 GTIN 清单，去 GS1 后台下载完整的产品记录，做一次全字段比对。重点看三件事：有没有重复、有没有不在 GS1 数据库里的、品牌名是否一致。这一步通常一到三天，但它决定了后面所有工作的起点质量。
核对当前的 GTIN 容量档位，估算三年内的 SKU 峰值，判断是否需要提前升级。同时把 GS1 年费到期日写进财务系统的固定提醒，这件事的代价和收益完全不成比例，漏缴一次可能意味着一批链接的合规状态出问题。
不用等方案完全成型，先做第一层。一个能自动算校验位、能检测重复分配的脚本，通常一天内就能上线，却能拦掉相当比例的严重错误。这一步的投入产出比是整条路径里最高的。
年新增低于 150 的，把批量模板和记录规范做好就够了。年新增超过 150 的，评估自建还是平台化，参考上一节的取舍框架。不要跳过数据清理直接上工具，脏数据会被自动化放大。
最后说一个我反复验证过的判断：UPC 方案设计的问题从来不是技术问题，而是数据治理问题。技术手段能让你更快地分配和登记号码，但只有清晰的编码规则、明确的责任归属、固定的对账节奏，才能让这套体系在两年后依然可信。工具是杠杆，规则才是支点。
我们团队做跨境自有品牌，SKU 一多就想着把条码申请也接进内部系统自动跑，结果发现光一个申请入口就卡了好几天。我一直搞不清到底哪些步骤是脚本能干的，哪些是必须人工签的。
要把边界划在拿到公司前缀这条线上。前缀申请这一步，各地 GS1 分支机构基本都是会员制：要提交营业执照、品牌或产品证明、签署会员协议、按年费或按量付费，这里涉及法律主体和资质审核，多数地区仍走线上表单加人工审核，接口开放程度也不一致，所以别在这段硬做自动化，用清单加材料模板把准备时间压到最短就够了。
前缀到手、拿到会员编号这类标识之后的所有环节，都是纯数据动作、规则确定，可以百分之百自动化：号段切分、GTIN 分配、校验位计算、条码图生成、产品主数据同步、渠道上传。判断依据很简单，凡是需要第三方做资质判断和合同确认的，人工；凡是本地有唯一确定答案的，脚本。
这样设计的好处是申请流程即使延迟，也不影响你已经开工的编码和排版工作。
我第一次写生成脚本的时候，觉得不就是拼字符串加个校验位吗，结果生成的两千个码被渠道退回来一批。后来才发现 UPC-A 和 EAN-13 的加权算法根本不是一回事，而且并发一高号段还会撞号，坑特别集中。
三个坑要提前防。第一是校验位算法的加权起点：UPC-A 是把 11 位数据位从左数奇数位乘 3、偶数位乘 1，求和后取 10 减和值模 10 再模 10；
EAN-13 是从右往左以 3 起交替加权，所以 EAN-13 等于 0 加 UPC-A 这个等式成立，但你把 EAN-13 的加权规则套到 11 位数据上就一定算错，这是最常见的一类批量废码。
第二是并发撞号，正确做法是建一张号段池表，记录前缀、起始号、结束号、当前指针，取号时用数据库事务加行锁，同时给最终 GTIN 加唯一索引兜底，不要用内存计数。
第三是别硬编码前缀长度，不同注册地拿到的前缀长度不一样，有的 6 位、有的 7 到 9 位，拼接商品参考码时要用类型长度减前缀长度动态算，固定写死 6 位前缀迟早出事。条码图建议直接生成 SVG 而不是位图，避免缩放失真，并留足静区。
最后写一个自检脚本，生成后把图片解码回来比对原字符串，这一步能拦住九成低级错误。
我们内部已经有一套商品主数据了，但每次上新品都要在产品编码中心的平台手工填一遍，再导出表格上传给渠道，重复劳动特别多。我一直在找有没有官方接口能一次打通，但查下来各地情况好像差很多。
分三块看，别指望一条链路通到底。GS1 侧的能力高度取决于属地：有些地区的商品数据服务平台提供批量导入甚至接口，能把 GTIN 和产品属性直接发布出去，有些地区在实操中仍以 Excel 批量导入为主，接口能力需要向当地编码中心确认。
所以我的架构是把 GS1 侧当成一个可替换的发布适配器，本地先维护一份 GTIN 主数据：前缀、GTIN、内部商品编号、品名、规格、品牌、净含量、图片，然后导出成符合各地模板的 CSV，有接口就走接口，没有就人工上传一次，脚本只负责生成、校验和导出。
渠道侧要特别注意来源合规：主流电商平台的 GTIN 校验只认可从 GS1 直接获得前缀的编码，用第三方批量买的码，listing 上线后可能被下架或被要求提供授权证明，返工成本远高于自己申请。
同步动作本身必须幂等，以 GTIN 作为主键做 upsert，每次同步前先跑一遍校验位和前缀归属核对，避免把脏数据推上去。
我们有一批早期靠代工厂拿到的条码，现在连前缀归属都说不清了，渠道那边偶尔会报编码无效。同时还有老品下架、换包装上新这些情况，我拿不准旧码是删掉、留着还是能给新品复用。
校验做三层：本地跑一次校验位算法确认格式合法；对着编码表跑唯一性检查，防止同一码绑两个商品；再抽样到公开的条码查询服务和编码中心查询平台核对前缀归属，确认这个前缀确实登记在你或你的供应商名下。有条件的话加一层实扫验证，用两三种不同扫码枪加手机各扫一遍印刷稿，纸箱和曲面包装都要测。
生命周期管理的核心口径是：GTIN 绑定的是具体商品加具体包装规格，不是绑定内部 SKU。所以换包装、改净含量、改口味、改规格必须换新 GTIN；只改价格、文案、主图不用换。
停用的 GTIN 我建议直接按不复用处理，行业里保守的说法是停用后至少保留数年不回收，我干脆把设计做成永久不复用，因为复用会让历史订单、退货、平台目录和零售商主数据产生歧义，风险远大于省下的几个号。
落地就是在编码表里给停用码打上停用状态、停用日期和原因，保留与原商品的映射关系，号段不够就向 GS1 申请扩展前缀或加购容量，而不是回头捡旧号。
读者评论
做过多店运营，第二层的定位很准：人准备数据、工具提交、人做校验。补充一点，GS1 批量上传模板的字段校验很死，产品名里带逗号、品牌名大小写不一致都会整批回执报错，人工耗时实际压在异常复核上。图里单 SKU 0.15 小时我觉得偏乐观，我们那边接近 0.3，头几个月还要加上磨合期。
成本表里 1000 档年费区间 500 到 2500，跨度太大了。真正的风险不是 GTIN 数量档位，是跟营收挂钩的续费档位跳档。我们去年营收翻倍，续费直接从低位跳到高位，预算完全没预留。文章说一次选够三年，但收入这一项不可控，建议把年费上涨单独做压力测试，而不是只看单 GTIN 成本。
起样本里 32 起是转售 UPC 引起的，这个比例说明采购渠道还是主因，自动化的收益得排在渠道合规之后。另外对 SKU 只有两三百的卖家，第三层 25 人天基本回不了本，第二层 8 人天也要算一算。想问下什么规模以下其实不建议上自动分配，直接买够档位手工维护更划算？