去年黑五前两周，我一个做家居收纳的朋友被亚马逊连下 37 个 ASIN。不是刷单，不是侵权，是 UPC。他两年前从一个码商那里一次性买了 2000 个 UPC，单价比正规渠道摊薄后便宜了将近一个数量级。前 18 个月一切正常。
直到亚马逊开始把 UPC 与 GS1 数据库做品牌一致性比对，他那批码的前缀属于一家美国贸易公司，GS1 记录里的品牌名和他 listing 上的品牌名对不上。37 个 ASIN 被降权、下架、冻结库存，申诉用了 51 天，整个旺季报废。
这件事之后我把自己手上的 UPC 管理方式彻底重做了一遍：从一张 Excel 台账，变成了一套围绕 GS1 注册关系展开的管理模板。UPC 管理模板真正要管的对象不是那串 12 位数字，而是这串数字背后的所有权链、前缀容量、品牌绑定关系和使用状态。这篇文章就是这套模板的完整拆解。
大多数人做 UPC 模板的第一步是打开 Excel，建三列：SKU、UPC、产品名。做完就以为完事了。我做过同样的动作，结果在 SKU 过 400 之后就崩了，不是因为 Excel 装不下，而是因为这三列承载不了 GS1 注册体系里真正会出问题的那部分信息。
所有 UPC 都是从公司前缀生成的。你从 GS1 成员组织拿到的是一个前缀，比如 6 位或 7 位，然后用这个前缀 + 商品参考码 + 校验位拼出成千上万个 GTIN。前缀是资产，UPC 只是这个资产生成出来的产物。
这个区别决定了模板的设计方向。如果模板的主键是 UPC，你只能做”事后登记”；如果模板的主键是前缀，你才能做”事前分配”。前者是台账，后者才是管理系统。
举个具体例子。假设你拿到 7 位公司前缀，那么 GTIN-12 去掉 12 位中的校验位后剩 11 位，前缀占 7 位，商品参考码只剩 4 位，理论容量 1 万个码。你如果不知道这个换算关系，很容易在第二年上新时才发现码不够用，而重新申请一个更短的前缀要重新走一遍 GS1 流程，成本远高于第一次就选对。
我在模板里加了一组字段，最初同事都觉得多余：GS1 成员组织名称、前缀授权主体、授权生效日、授权到期日、是否续费、续费凭证编号。加上之后，一次亚马逊的品牌一致性核查我们 40 分钟就交齐了材料，而隔壁同行花了三周。
原因很简单。平台核查的不是”你有没有码”，而是”这个码是不是你的”。能证明所有权的材料，在申诉场景下的价值远高于码本身。模板如果不记录所有权链，那你手上就是一堆来源不明数字。
正向登记是”我给这个 SKU 分配了某个 UPC”。反向验证是”给定一个 UPC，我能立刻回答：它属于哪个前缀、分配给哪个 SKU、当前在哪些平台在售、有没有被重复分配过、GS1 数据库里的品牌名是什么”。
真正的翻车几乎都发生在反向查询上：码被重复用给了两个 SKU，或者码被分配给了 A 品牌却挂在 B 品牌下售卖。正向登记只防手误，反向验证才防系统性风险。
基础玩法是”每个新品领一个码”。进阶玩法是把 UPC 按包装层级做结构化拆分：单品用 GTIN-12，内箱用 GTIN-13 或 GTIN-14，外箱用 GTIN-14，并让这三层在模板里形成父子关系链。这样当你要上 B2B 平台、要对接海外仓、要做 FBA 的箱规申报时，不需要重新编一套编码体系，直接复用已有的层级数据。
这一层能省下来的时间，实际操作里比想象中大得多。我们做箱规数据准备的时间从每个 SKU 约 25 分钟压到了 6 分钟以内，因为所有层级码和箱内数量都在同一张表里。
要理解 UPC 管理模板为什么必须围绕 GS1 注册来做，得先看清楚 GS1 这一整套编码体系在跨境业务里的实际流转路径。
场景一：新卖家第一次申请。朋友 A 做宠物用品，2023 年第一次申请 GS1 前缀，拿到 7 位前缀后一口气生成 300 个 UPC，用 Excel 记了三列。第二年上新到 900 个 SKU 时，发现有两个 SKU 的 UPC 只差一位，运营在批量上传模板时复制粘贴串行了，两个产品互相覆盖了 listing 内容，花了 11 天才拆开。
场景二：多平台同步。朋友 B 做 3C 配件，同时在亚马逊、沃尔玛、TikTok Shop 上架，用的是同一套 UPC。他遇到的问题是沃尔玛要求 GTIN 与 GS1 数据库的品牌名严格一致，而他的亚马逊 listing 品牌名做过一次微调（加了后缀），导致同一批码在两个平台的校验结果不同。模板里没有”平台品牌名”这个字段，他查了两周才定位到原因。
场景三：SKU 退役与复用。朋友 C 做季节性品类，每年淘汰 40% 的老品。他把退役 SKU 的 UPC 回收后重新分配给新品，结果亚马逊判定”变体关系异常”，因为旧 listing 的历史数据还在，同一个 UPC 出现在两个不同的产品上。UPC 不是可以随便回收的资源，它在平台侧有一条自己的历史记录。
GS1 体系的层级其实是清晰的，只是很多人从来没把它画出来过。
第一层是 GS1 成员组织（各国的编码管理机构），它给你分配公司前缀。第二层是公司前缀，它是你所有编码的根。第三层是 GTIN，由前缀 + 商品参考码 + 校验位组成。第四层是包装层级指示符，用来区分单品、内箱、外箱。
这个层级关系对应到模板上就是四张互相引用的表，而不是一张大宽表。我最早用一张宽表，每次改前缀信息都要动几千行；拆成主表 + 从表之后，改一次前缀只动一行。
很多卖家以为亚马逊只校验 UPC 格式对不对。实际会触发问题的校验点至少有四个：
这四个校验点里，只有第一个是”当场报错”的，后面三个都是”延迟触发”，可能在你上架几个月后才出现。延迟触发的风险，必须靠模板的前置校验来兜底，靠人肉记忆是不可能的。
不是 Excel 不行，是”把校验逻辑放在人脑里”不行。Excel 能做数据存储，做不了状态机，做不了跨表引用完整性，做不了自动校验位计算，做不了权限隔离。
我统计过我们团队在纯 Excel 阶段的一次内部复盘，UPC 相关的返工时间构成大致是这样的：
下面这五条，每一条我都能指出具体是哪次事故教会我的，不是从文档里抄来的。
这是最贵的一个误区。UPC 在物理层面确实只是 12 位数字，但在平台治理层面，它是一个”可追溯到 GS1 授权主体的身份标识”。
转售码的问题不在于数字本身，而在于它背后的授权主体不是你。当你无法证明这个码属于你时，你在平台上的所有投入，评论、排名、广告权重，都建立在一份随时可能被质疑的地基上。
我见过最极端的案例是一个卖家在两年内积累了 4000 多条评论，因为码来源问题被批量下架，评论随之清零。重新推起来花的广告费，是当初省下的码费的几百倍。
变体（父子 ASIN）在亚马逊上的正确做法是每个子体有独立的 GTIN，父子关系靠 Variation Theme 建立，而不是靠共用码。共用码会造成两个后果：一是平台无法区分两个子体，合并或拆分时数据错乱；二是后续如果要单独申请品类资质，码对不上。
颜色、尺码、容量这类变体，每一个都应该是独立的 GTIN。这部分容量必须在模板里提前预留，不能边做边领。
品牌备案确实可以申请 GTIN 豁免，让新品不使用 UPC 上架。但豁免有两个限制容易被忽略。
第一，豁免通常不追溯历史 ASIN，已经用码上架的产品仍然需要码的有效性。第二，豁免在部分平台、部分类目并不是默认开通，你需要逐个确认。第三，也是最容易被忽略的：当你要做线下渠道、要供货给分销商、要进海外仓的标准化系统时，GS1 编码是通用语言，平台豁免在这里没有用。
所以我的判断是：品牌备案解决的是”上架能不能通过”，GS1 注册解决的是”这个商品在全渠道能不能被识别”。两件事不冲突，不能互相替代。
我也犯过这个错。第一版模板我加了 60 多个字段，结果没人愿意填，填了的也全是错的。后来做了一次精简，只保留 23 个必填 + 9 个自动计算字段，填报准确率从 71% 涨到了 96%。
模板的价值取决于字段的可用率，而不是字段的数量。一个 200 字段但只有 30% 被正确填写的模板，不如一个 30 字段但 95% 准确的模板。
模 10 校验位算法本身不复杂，但手工算 3000 个码一定会出错，而且是那种看起来没问题的错，数字合法，格式合法，就是校验位不对，上传时才报错。
校验位必须用公式或脚本自动生成。任何需要重复计算的字段，都不应该由人来填。这一条我在模板设计里设成了硬规则。
模板设计不是审美问题，是一连串判断的结果。下面四条是我在设计时反复权衡后定下来的原则。
平台核查时不会只看 GTIN，它看的是这三个要素能不能互相印证。所以模板里的核心字段必须是这三个，而且要允许同一个 GTIN 在不同的平台绑定不同的品牌名，因为不同平台的品牌名写法确实可能不同。
我的做法是在主表里放”GS1 注册品牌名”，在平台映射从表里放”该平台品牌名”，然后用一个校验字段自动标记两者是否一致。不一致不一定错，但必须被看见。
我把码的来源分成四个等级，这个分级直接影响运营策略。
| 来源等级 | 码的来源 | 可提供的凭证 | 风险判断 |
|---|---|---|---|
| A 级 | 自身主体向 GS1 成员组织直接申请 | GS1 授权函、前缀证书、续费记录 | 可控，可用于任何渠道 |
| B 级 | 集团关联主体申请、授权给本主体使用 | 授权书 + 关联主体 GS1 凭证 | 基本可控，需保存授权链文件 |
| C 级 | 从第三方批量购买，来源可查但非本人 | 购码合同、码商提供的部分材料 | 高风险，不建议用于主推品 |
| D 级 | 来源不明、低价转售、一码多卖 | 几乎无 | 极高风险，应尽快替换 |
这个分级看起来简单，但落地效果很好。以前团队分不清”这批码能不能用在主推款上”，现在只要看等级，A 级可以放心用，C 级只能用在测款和临时链接上，D 级必须走替换流程。
这是我认为最容易被忽略、但价值最高的一条设计。一个 UPC 的生命周期至少有四个状态，每个状态需要记录的信息完全不同。
为什么这个状态划分重要？因为绝大多数事故都发生在状态跃迁的瞬间，而不是在某个静态状态里。重复分配是”申请态 → 分配态”时没做唯一性校验；变体异常是”退役态 → 分配态”时违规复用；品牌不一致是”分配态 → 上架态”时没同步品牌名。
很多人比较 UPC 成本时只比单价：GS1 官方的年费摊到每个码上是几块钱，码商的转售码是几毛钱。这个比较是错的。
正确的算法是把下面这些项都算进去：前缀申请与年费、码生成与管理的人工成本、平台校验失败的返工成本、申诉的时间成本、库存冻结的资金占用、以及最贵的，权重和评论清零的重建成本。
把这六项加起来，转售码在大多数情况下都是负收益。我算过一个具体案例：为了省下约 4000 元的码费，最终付出了约 11 万元的重建成本，杠杆比接近 27 倍。
讲到这里，逻辑上已经能说清楚模板应该长什么样。但真正让我把方案落地的，是一次把 UPC 数据和平台数据打通后的观察。这一节我以自己实际在用的数跨境为例，讲讲数据平台和纯 Excel 模板的差距到底在哪里。
Excel 模板解决的是”本地记录”问题，它解决不了”跨系统一致性”问题。而 UPC 出问题的场景，恰恰全部发生在跨系统的地方。
举一个很具体的例子。我在 Excel 里记录了某个 SKU 的 UPC 是 012345678905，品牌名是 BrandX。但这个 SKU 在亚马逊上的品牌名是 BrandX Home，在沃尔玛上是 Brand X。三个地方三个写法，Excel 里只有一个字段，我怎么比？
当我把 UPC 数据和平台 listing 数据放到同一个数据平台上之后，这类问题就从”事后发现”变成了”每日巡检”。这是质的差别。Excel 是记录工具，数据平台是核对工具，UPC 管理的瓶颈在核对不在记录。
我实际使用时的做法是三步。
第一步，把 GS1 申请到的前缀和已生成的 GTIN 清单作为基础数据导入，包含前缀、授权主体、GTIN、生成批次、分配状态。第二步，把各平台店铺的商品数据同步进来，让每个 listing 的 SKU、ASIN、品牌名、GTIN 落在同一个视图里。第三步，用平台提供的字段对比能力，把”我登记的 GTIN”和”平台实际读取到的 GTIN 与品牌名”做逐条比对。
第三步是最有价值的。以前我要导出两个表格，用 VLOOKUP 手工比对，一次要 40 分钟，而且只在出事后才做。现在这个比对是常态化的，异常会直接浮出来。
顺带说一句我没预料到的收益：因为 UPC 和 SKU 在同一套数据里，我做销量分析时可以按”前缀批次”聚合，看出不同批次码对应的产品表现差异。这是一个纯粹的副产品，但对我判断”下一批码该用哪个前缀长度”很有帮助。
第一组：SKU 数量与 UPC 管理工时的关系。在纯 Excel 阶段，SKU 从 300 涨到 900 的过程中，每月 UPC 相关工时从约 9 小时涨到约 41 小时，涨幅明显快于线性（1.9 倍 SKU 带来 4.5 倍工时），因为跨表核对和人工排查的成本是非线性的。迁移到平台化核对之后，同样的 900 个 SKU，每月 UPC 相关工时降到约 10 小时。
第二组：问题发现时点的前移。Excel 阶段，UPC 类问题的平均发现时点是在”上架后 34 天”；平台化核对之后，平均发现时点前移到”上架前 1.5 天”。这个改变的意义在于，上架前发现只需要改一个字段，上架后发现可能要拆 ASIN、清库存、重开链接。
第三组：问题类型的分布变化。Excel 阶段，问题里 62% 是重复分配和校验位错误这类”录入型问题”；平台化之后，录入型问题降到 19%，剩下的 81% 变成了品牌名不一致、平台字段规则差异这类”规则型问题”。这说明工具解决的是低级错误，剩下的高级问题需要靠人对平台规则的理解来处理。
说起来惭愧，我第一次做平台化核对时犯了一个错：我把”平台读取到的 GTIN”直接当成了”我登记的 GTIN”，没有做双向核对。结果有一批老 SKU 在平台上用的是早期的转售码，而我登记的是后来补的正规码，两边对不上，但我只核对了”登记侧”，没发现差异。
三个月后做品线梳理时才发现这个断层。教训是：核对必须是双向的，既要检查”我登记的码有没有被正确使用”，也要检查”平台上在用的码有没有被登记”。单向核对只能发现一半问题。
后来我在模板里加了一个字段”登记来源”，区分”我方 GS1 生成”和”历史遗留待替换”，并且设了一条规则：历史遗留码不允许用于新开链接，只能维持存量。
我把纯 Excel 模板、自建轻量系统、数据平台三种方案在几个关键维度上做了对比，这是我们实际选型时用的表。
| 能力维度 | 纯 Excel 模板 | 自建轻量系统 | 数据平台方案 |
|---|---|---|---|
| 校验位自动生成 | 需自写公式，易错 | 可脚本化 | 内置规则，开箱可用 |
| SKU 唯一性校验 | 弱，依赖人工 | 强，可数据库约束 | 强，含跨平台校验 |
| 平台品牌名一致性比对 | 几乎做不到 | 需自行对接各平台接口 | 核心能力，常态化巡检 |
| 多人协作与权限 | 弱，易覆盖 | 可做 | 可做 |
| 年上新 500 SKU 适用性 | 勉强 | 适用 | 适用 |
| 实施周期 | 1 天 | 3-8 周 | 1-2 周（含数据迁移） |
按规模给建议比讲道理有用。下面是我按 SKU 规模分档给的具体行动路径。
这个规模不需要任何系统，一张设计合理的表就够了。但你仍然要具备两项能力：一是能证明码的所有权，二是能防止重复分配。
这个区间是事故高发区，因为规模已经超出人脑记忆，但团队往往还在用 Excel。我建议在这个区间完成从”表格”到”系统”的迁移。
到这个规模，UPC 管理已经不是后台职能，而是产品和运营之间的接口。我的建议是把它当成一个正式的数据资产来管理。
第一，设专人负责前缀容量规划，每半年做一次容量预测，确保未来 18 个月的码量够用。第二，按站点建立独立的映射关系，因为不同站点的品牌名和类目规则可能不同。第三，把 UPC 校验嵌入上新流程的必过节点，没有通过校验的 SKU 不允许进入上架环节。第四，保留完整的历史快照，任何时候都能回答”某个时间点某个 ASIN 用的是哪个码”。
不要一刀切全部替换，那样成本太高而且会影响在售链接。我的建议是分级处理：
所有选择都有代价。下面四组取舍是我在实操中反复面对的，我把判断标准写清楚，你可以对照自己的情况。
自注册的代价是前期成本高、申请有周期、需要维护年度续费。转售码的代价是所有权不可控、平台校验风险高、无法用于 B2B 和线下渠道。
我的判断标准是：如果这个产品预计生命周期超过 12 个月，或者预计累计销量超过 2000 件，就必须用自注册码。短期测款、临时链接可以用转售码，但要明确标注为临时资产，且不得投入广告预算做长期积累。
集中管理指所有品线的码统一由一个角色分配；分散管理指各品线自行申请和分配。集中管理的代价是流程慢、有审批环节；分散管理的代价是容易撞码、容量规划混乱。
我倾向于”申请集中、分配分散”的混合模式：前缀由公司层面统一向 GS1 申请和管理，码段按品线划分后下放给品线自行分配，但唯一性校验必须回到中心系统做。这样既保证了所有权链统一，又避免了所有事都堵在一个审批节点上。
自建的优势是完全贴合自己的流程，劣势是维护成本高、平台规则变化时响应慢。用平台的优势是核对能力现成、规则更新快，劣势是数据在外部、定制空间有限。
我的实际选择是混合：主数据（前缀、GTIN、SKU 映射）保留在自己可控的表里，核对和巡检放在平台上做。这样即使平台更换，主数据也不会丢。
| 对比维度 | GTIN 豁免 | 申请正规 GS1 码 |
|---|---|---|
| 适用场景 | 仅在已备案平台内上架 | 全渠道、全平台、线下分销 |
| 申请门槛 | 需品牌备案，部分类目不支持 | 需主体资质与年费 |
| 历史 ASIN 兼容 | 通常不追溯 | 完整兼容 |
| 对分销与海外仓 | 基本不可用 | 通用 |
| 长期风险 | 平台规则变动时被动 | 低，资产在自己手上 |
我的结论是：豁免是”减负工具”，不是”替代方案”。如果只做一个平台且不做分销，豁免够用；只要业务有可能扩展到第二个平台或线下，就应该老老实实申请真码。豁免省下的是申请费，申请真码省下的是未来的迁移成本。
前面讲的是判断，这一节讲怎么落地。我把可以直接抄的结构写出来。
主表叫”GTIN 主数据表”，一行一个 GTIN。必填字段分为四组：
自动字段包括：校验位、GTIN 完整值、前缀剩余容量、是否重复、品牌名一致性标记、上架平台数量、距到期天数、风险等级。
GS1 的模 10 校验位算法是公开的。下面这段是我实际在用的 Python 实现，能同时处理 GTIN-12、GTIN-13、GTIN-14。
def gtin_check_digit(digits_without_check):
"""
计算 GTIN 校验位。
digits_without_check: 不含校验位的数字字符串，如 '01234567890'
规则：从最右位开始，第 1、3、5... 位权重为 3，其余为 1（GTIN-12/13/14 通用）
"""
total = 0
for i, ch in enumerate(reversed(digits_without_check)):
if not ch.isdigit():
raise ValueError(f"非数字字符: {ch}")
weight = 3 if i % 2 == 0 else 1
total += int(ch) * weight
return (10 - total % 10) % 10
def build_gtin(prefix, item_reference, total_length=12):
"""
用前缀 + 商品参考码拼出完整 GTIN。
total_length=12 对应 UPC-A，13 对应 EAN-13，14 对应物流箱码。
"""
body_len = total_length - 1 # 留给校验位的空间
body = f"{prefix}{item_reference}".zfill(body_len)
if len(body) != body_len:
raise ValueError(
f"前缀与参考码总长应为 {body_len} 位，当前为 {len(body)} 位"
)
return body + str(gtin_check_digit(body))
if __name__ == "__main__":
示意：6 位前缀 690123 + 5 位商品参考码
print(build_gtin("690123", "00001")) # GTIN-12
print(build_gtin("690123", "00001", 13)) # GTIN-13
print(build_gtin("690123", "00001", 14)) # GTIN-14这段代码有两个作用。第一是批量生成时保证校验位正确；第二是在核对时反算校验位，用来判断平台读取到的 GTIN 是否是有效码。反算是很多人漏掉的一步，但它在排查”平台显示的码是不是被谁改过”时非常有用。
状态机的作用是把”能不能改”这件事从人的判断变成系统规则。我定义了四个状态，只允许六条流转路径：
第六条是我特意留的口子，因为现实中确实存在误操作退役需要恢复的情况，但必须加双人确认。规则的目的不是禁止，而是让例外变得可见。
唯一性校验不能只查”GTIN 有没有重复”。我实际会查三个方向：
第三个方向最容易漏，但恰恰是触发平台变体异常判定的主要原因。
这一节回答我在社群和客户沟通里被问得最频繁的几个问题，都是实操层面的。
通常不可以自由转让。前缀是 GS1 成员组织授权给特定法律主体的，主体变更需要走正式的变更或重新申请流程。这也是为什么”买别人的码”风险高，法律主体对不上。
前缀授权通常按年续费维护，不续费会影响授权的有效性。我建议在模板里加”距到期天数”字段，并设置 90 天预警。续费这件事的失败成本极高，因为一旦中断，恢复流程比首次申请更麻烦。
我的观察是通常不会”一次性全部判罚”，而是分批触发，常见触发点包括：品牌备案、类目资质审核、账号健康检查、大促前的集中审核。所以不要因为”用了两年没事”就认为安全，风险只是还没被触发。
先判断是”写法差异”还是”主体差异”。写法差异（如空格、大小写、后缀）可以通过提交品牌授权与主体一致性说明来处理；主体差异（前缀挂在别的公司名下）则很难通过说明解决，建议直接替换码。
要。颜色、尺码、容量、口味这类真正意义上的变体，每个子体都应有独立 GTIN。共用一个码在短期可能看不出问题，但在拆分变体、单独申请资质、做广告分产品投放时一定会出问题。
回到开头那 37 个被下架的 ASIN。事后复盘时我意识到，那次事故真正的成本不是 51 天的申诉时间，而是”发现得太晚”，问题在两年前买码的那一刻就已经存在了，只是没人有能力看见它。
所以我给 UPC 管理模板下的定义是：它不是一个记录工具，而是一个提前看见风险的工具。围绕 GS1 注册来设计模板，本质上是把”所有权、容量、绑定、状态”这四个最容易失控的维度，变成可以持续核对的字段。
三个我认为最值得记住的独特观点：
下一步怎么做，我给一个具体的最小行动清单：
这套动作做完，你会发现 UPC 管理从一件”总是出事又说不清哪里出事”的事，变成了一件”有指标、有预警、有预案”的常规工作。它不性感，但它在旺季前的那两周，会替你挡掉最贵的一类风险。
我们公司去年在GS1买了前缀，拿到一份官方导出的表格就丢给运营了，结果上listing的时候发现两个人把同一个码分给了两个不同的SKU。我自己动手重做过一版模板，但不知道字段到底该设多少，设少了不够用，设多了没人填。想听听真正跑过几年的人是怎么搭这张表的。
核心字段按三层来分。第一层是身份层：GTIN-14作为主键（永远存14位，UPC-A前面补0凑够14位，因为ERP、EDI、零售POS最终都归一到GTIN-14）、GTIN-12/13展示列、GS1公司前缀、商品参考号、校验位自动计算列、内部SKU。
第二层是商品层：品牌名（必须和GS1数据库里的写法完全一致，通常是全大写、无多余空格，不一致就是亚马逊报错的第一大来源）、产品标题、变体维度拆成颜色/尺码/规格三列、包装层级（单品EA/内箱INNER/外箱CASE）。
第三层是流转层：状态、分配日期、分配人、关联平台ASIN或listing ID、备注。两个容易踩的坑必须先堵上：GTIN列一定要设成文本格式，否则Excel会把14位数字转成科学计数法，或者把前导0吃掉，而带前导0的UPC非常常见；
校验位必须是公式列自动生成，禁止手输，公式口径是从左到右奇数位乘3、偶数位乘1求和，再用(10减去和对10取余)再对10取余。状态字段用下拉框固定成“待分配/已分配未上线/已上线/停用/永久冻结”五个值，不要让大家自由填。
GS1证书的PDF不用塞进表里，单独存一个链接字段就行，模板只负责管码，不负责存档案。
我们做服装，一个SPU下面经常十几个变体，运营跟我说亚马逊父子变体用同一个UPC就行，但另一个做美妆的朋友又说必须一个变体一个码。我手上这批码本来就紧张，真的每个都要单独分配吗？想搞清楚规则边界在哪。
按GS1的规则，只要它是作为一个独立零售单元被扫描、结算、比价的最小销售单位，就必须有自己的GTIN。颜色、尺码、口味、容量不同，就是不同的GTIN，没有例外。
唯一可以共用编码逻辑的是包装层级：同一个单品的内箱、外箱用GTIN-14，靠最前面的指示符位区分，1到8表示不同的包装组合，0留给基础零售单元。所以模板要做成两张表：SPU主表存品牌、品类、系列；变体子表一行一个GTIN，用SPU编号关联。
唯一索引必须建在GTIN列上，不能建在SKU列上，因为SKU可以改、可以合并，GTIN一旦上线就不能动。判断依据很实际：GTIN改指到另一个产品，零售商的POS历史数据、亚马逊的目录记录、第三方比价库会全部串掉，而且是不可逆的。
数据口径上，一个SPU需要的GTIN数量等于实际单独售卖的变体数，通常是颜色数乘尺码数；只做展示引导、不单独下单的尺码，可以不分配。但一旦这个尺码后来单独开卖了，就得补一个新码，不能把原来那个挪过来用。
我们早期为了省钱在某服务商那里买过一批码，单价几毛钱，结果亚马逊上架时提示品牌不匹配，折腾了半个月。现在换了一批新码但心里没底，想知道模板里能不能把“码的来源是否合规”这件事管起来，别等上架时才暴露。
主流平台的口径基本一致：亚马逊、沃尔玛在大多数类目都要求GTIN来自GS1直接授权，第三方转售码会被系统性拒绝。
原因不复杂，亚马逊在添加商品流程里会拿你填的GTIN回查GS1数据库，比对登记的品牌名、公司名，转售码的所有权挂在别人公司的名下，一查就露馅，典型报错就是“与GS1记录的品牌不一致”或者“GTIN无效/未注册”。
可执行的做法是在模板里加三个字段：GS1证书编号、公司前缀、证书上的法定公司名称，并且加一个“码来源”枚举列，值只有“GS1直授”和“第三方转售”两项。凡是标了第三方转售的行，模板里给一个风险标记，禁止直接进入上架流程，必须先走复核。
验证手段是免费的，用GS1官方的GEPIR查询工具，输入前缀就能看到归属公司和地址，三秒钟出结果。如果历史库存里已经用了转售码，正确的出路是走品牌注册后的GTIN豁免通道上传，而不是去改品牌名硬凑，后者属于申报不实，风险比换码大得多。
我们去年砍掉了一条产品线，大概两百多个码就躺在表里没人管。最近新人做新品的时候随手挑了几个“看起来没用过”的码，我事后才发现里面有几个其实上过架。这种坑怎么在模板层面堵住？
GS1总规范的口径是：GTIN一旦分配给某个商品，就不应该再分配给另一个商品。如果确实要复用，前提是原商品已经从供应链和零售POS中彻底消失，行业实践里普遍按至少4年把握，有些渠道要求更长。
原因在于零售商的POS历史库、第三方比价库、平台目录都会长期缓存这个码对应的商品信息，复用会导致数据串台，轻则比价混乱，重则被判为操纵目录。模板层面的做法是引入状态机：待分配、已分配、已上线、停用、永久冻结，只有“待分配”状态的码才允许被分配出去，停用和永久冻结的码在分配下拉里直接过滤掉不显示。
再单独建一张废弃区表，永久冻结的码全部迁移过去，保留GTIN、原SKU、停用日期、停用原因四个字段，只读不写。防重靠两件事：GTIN列加唯一约束，重复立刻报错；分配动作留痕，分配人和分配日期设为必填，这样出问题能倒查到人。
还有一个容量口径值得提前算：如果买的是6位公司前缀，去掉校验位后剩5位商品参考号，理论可分配10万个GTIN-12，实用上建议用到80%就开始考虑补充前缀或者重新做容量规划，别等运营来催新品了才发现码池见底。
读者评论
所有权链那组字段我认同，但实际申诉里真正管用的只有GS1官网截图和授权主体名称。我们遇到过店铺主体是大陆公司、GS1前缀授权主体是香港关联公司的情况，名称对不上照样被卡，续费凭证编号平台根本不看。所以模板里最好再区分“授权主体”和“店铺主体”，并预留一份主体关系说明的存档位。
换码这件事文章说得轻了。对已经上架的ASIN来说，换UPC等于换ASIN，评论、排名、广告历史全部清零，这个代价比码费高好几个量级。现实里大部分人不是“重做一遍”，而是靠品牌备案走GTIN豁免把新品接上，老品硬扛。模板能防新增风险，但存量怎么迁移，文章没给出路径。
GTIN-14那层我得提个不同看法。亚马逊FBA箱规申报填的是箱内数量和尺寸重量，并不要求外箱GTIN-14；真正强制用上14位的是给商超或分销商做EDI的场景。这两件事的验收方不一样，混在一个层级表里反而容易让人以为做完就对得上FBA了。我们最后是拆成两套视图分别维护的。