鞋服企业的商品主数据，绕不开两个问题：款、色、码三层编码怎么定，每个字段的源头归谁。把编码收在主数据平台里产生，各业务系统只取不改，订货、库存、对账才算得准。
一、同一件衣服为什么会有多个编码
同一件冲锋衣，在不少鞋服企业的系统里能查到五个编码（示意场景）：
- 研发在 PLM 里立款，给一个款号；
- ERP 建物料，又编一个物料号；
- 门店收银系统录一个商品码；
- 电商后台再建一个商品编码；
- 仓库为了收发货，自己编一套物流码。
这些码各管各的，谁也不认谁。同一件衣服被算成好几种商品，门店说缺货、仓库说有货，月底对账只能导出表格一行一行翻。
码多只是表面，根子上是两个问题：
- 没有统一出口。 每个系统都能自己编码，规则各不相同。
- 没有统一层级。 研发按款管，订货按颜色管，仓库和收银按尺码管。几个层级混在一张表里，系统之间自然对不上。
所以鞋服商品主数据要先定层级，再定每个字段的源头。
二、款、色、码的三层结构
鞋服商品天然分三层：
| 层级 | 业务含义 | 主要字段 | 谁最常用 |
|---|---|---|---|
| 款（SPU） | 一个设计款 | 品牌、品类、年份季节、面料成分、执行标准、吊牌价 | 研发、商品企划 |
| 色（SKC） | 款＋颜色 | 颜色、色号、上市波段、陈列图 | 订货、铺货、补货、陈列 |
| 码（SKU） | 款＋颜色＋尺码 | 尺码、国标码、物流码 | 仓库、收银、电商 |
SKC 是鞋服特有的一层，也最容易漏。很多 ERP 只有"物料"一层，只能把 SKU 当商品管。可订货会按颜色下单，门店按颜色陈列，动销分析也按颜色看，这些都要落在 SKC 这一层。在一个鞋服零售企业的方案设计中，我们专门在款和码之间加了 SKC 层，把"款→色→码"补完整。
编码可以这样设计（示例）：
| 层级 | 编码示意 | 组成 | 谁生成 |
|---|---|---|---|
| 款 | M2601 | 品牌码 M＋年份 26＋年内流水 01 | 主数据平台（PLM 立款时申请） |
| 色 | M2601-BK | 款号＋颜色码（BK 为黑色，取自集团色卡） | 主数据平台 |
| 码 | 80001234 | 无含义流水号，尺码作为属性挂在下面 | 主数据平台 |
表中位数只是示意。真实项目里，流水位要按品牌一年最多出多少款来留，宁长勿短。
码这一层为什么用流水号：
- 尺码体系太多。 服装有字母码、身高码，鞋有鞋码，童装还有年龄段，硬塞进编码会越编越长。
- SKU 数量最大、生命周期最短。 用流水号最稳，改尺码表也不用改码。
- 可读性交给款号和属性。 业务看到示意编码 M2601-BK 加上尺码 L，就知道是哪一件。
几条要写进制度的规矩：
- 款号一经生成不改，改款就立新款，旧款号停用、不复用；
- 颜色码用集团统一色卡，各品牌共用一张颜色字典；
- 尺码按品类设尺码组（上装、下装、鞋、童装），建 SKU 时只能从尺码组里选；
- 老编码做映射，不推倒重来，新旧码在平台里一一对应。
三、吊牌价、国标码、物流码以哪个为准
层级定了，第二件事是定源头：每个字段只有一个系统能写，其他系统只读、不改。下面这张表可以直接拿去用，按企业实际调整：
| 字段 | 层级 | 源头系统 | 负责人 | 下游怎么用 |
|---|---|---|---|---|
| 款号、色号、SKU 码 | 款 / 色 / 码 | 主数据平台生成 | 主数据管理员 | 所有系统只读 |
| 款名、品类、年份季节 | 款 | PLM（研发立款） | 研发、商品企划 | ERP、电商、收银 |
| 面料成分、执行标准、安全类别 | 款 | PLM | 研发技术 | 打印吊牌、电商详情页 |
| 颜色 | 色 | PLM 选色（色卡字典在主数据平台） | 研发 | 订货、陈列 |
| 尺码 | 码 | PLM 选码（尺码组在主数据平台） | 研发 | 仓库、收银 |
| 吊牌价 | 款（个别品牌到色） | 主数据平台审批 | 商品部 | ERP、收银、电商 |
| 国标码 | 码 | 主数据平台从码池分配 | 主数据管理员 | 吊牌、收银、仓库 |
| 物流码 | 码 | 主数据平台生成 | 主数据管理员 | 仓库、物流 |
| 品牌、品类分类 | 款 | 主数据平台分类字典 | 主数据管理员 | 所有系统 |
配套三条规矩：
- 吊牌价进主数据，促销价留在业务系统。 吊牌价印在吊牌上，一款一价，由商品部在主数据平台审批；促销价、折扣价是交易数据，留在价格或营销系统里。
- 国标码建码池，由平台分配。 企业申请到的国标码统一放进码池，SKU 审批通过后由平台分配；停用商品的码不随意转给新商品，避免一码两用。
- 能自动生成的，不让人手填。 研发数据一来，平台自动生成物流码和国标码，人只负责审核。
第三条，我们在一家运动品牌集团做过：研发系统一来数，平台自动生成物流码和国标码；商品主数据覆盖吊牌、价格、条码，2024 年 6 月 30 日切换上线。
四、多品牌的品类如何归一
多品牌集团最头疼的是分类：每个品牌一棵品类树，集团层面汇总不起来。我们的做法：
- 集团一套分类骨架。 大类、中类、小类由集团统一定，例如"鞋 / 跑步鞋 / 竞速跑鞋""服 / 上装 / 羽绒服"（示例）。
- 品牌单独做一个维度。 品牌不放进品类树第一层，否则同一个"羽绒服"会在每个品牌下各出现一次，集团看不到总量。
- 字典集团共用。 颜色、尺码组、面料成分、年份季节这些字典只有一份，品牌只能选，不能自建。
- 品牌可以扩展末级，但要登记。 某个品牌确实需要特殊小类，在主数据平台申请，审批后全集团可见。
- 字段做减法。 进主数据平台的只放跨系统共用的字段，只给一个系统用的，留在那个系统。
在一个休闲服饰集团的方案设计中，我们按 SPU/SKU 拆分建模，商品字段从 234 个精简到 122 个，分类按品牌拉通。字段越少，维护的人越容易填准。
五、实施顺序
- 盘点。 列出所有会出码的系统，以及每个系统现在的编码规则。
- 定标准。 款色码规则、分类骨架、颜色和尺码字典、字段源头表，一起定。
- 洗存量。 在售款优先，老款做映射。
- 接来数。 PLM 立款自动进主数据平台，不再人工搬。
- 上流程。 新款建档、改吊牌价、商品停用，这几类审批先上。
- 切分发。 ERP、收银、电商、仓库改为从平台取数，定好旧编码规则停用的日期。
- 盯质量。 按唯一性、一致性、完整性、准确性定质量标准，平台定期清洗，自动出质量监控报告。
附：三层模型的表结构与编码校验
款、色、码落成三张表，字段源头靠"谁能写"来约束。下面是示例 DDL，字段名按各自系统改。
三张表
sql
-- 款：一个设计款一行
CREATE TABLE mdm_style (
style_code VARCHAR(16) PRIMARY KEY, -- 例：M2601
brand_code VARCHAR(8) NOT NULL, -- 品牌是字段，不进编码
category_leaf VARCHAR(32) NOT NULL, -- 集团分类骨架的末级
season_code VARCHAR(8) NOT NULL, -- 年份季节字典
material_comp VARCHAR(200), -- 面料成分
exec_std VARCHAR(64), -- 执行标准
tag_price DECIMAL(10,2), -- 吊牌价，一款一价
status VARCHAR(16) NOT NULL,
owner_dept VARCHAR(64) NOT NULL
);
-- 色：款 + 颜色，订货和陈列挂在这一层
CREATE TABLE mdm_color (
skc_code VARCHAR(24) PRIMARY KEY, -- 例：M2601-BK
style_code VARCHAR(16) NOT NULL REFERENCES mdm_style,
color_code VARCHAR(8) NOT NULL, -- 取自集团色卡字典
launch_wave VARCHAR(16), -- 上市波段
status VARCHAR(16) NOT NULL
);
-- 码：款 + 色 + 尺码，仓库和收银挂在这一层
CREATE TABLE mdm_size (
sku_code VARCHAR(24) PRIMARY KEY, -- 无含义流水号
skc_code VARCHAR(24) NOT NULL REFERENCES mdm_color,
size_code VARCHAR(8) NOT NULL, -- 从尺码组里选，不手写
logistics_code VARCHAR(32) UNIQUE,
national_code VARCHAR(32) UNIQUE -- 国标码，由码池分配
);三层拆开的实际好处：订货按 SKC 汇总，库存按 SKU 记账，动销分析按颜色看，三个口径不用互相折算，也不会把 SKU 当成商品管。
编码规则与校验
sql
ALTER TABLE mdm_style
ADD CONSTRAINT ck_style_code CHECK (style_code ~ '^M[0-9]{2}[0-9]{2,4}$');
-- SKC = 款号 + '-' + 颜色码，拼错直接拒绝
ALTER TABLE mdm_color
ADD CONSTRAINT ck_skc_code CHECK (skc_code = style_code || '-' || color_code);颜色和尺码只能从字典里选：
sql
CREATE TABLE dict_color (
color_code VARCHAR(8) PRIMARY KEY,
color_name VARCHAR(32) NOT NULL
);
CREATE TABLE dict_size_group (
group_code VARCHAR(16) NOT NULL, -- 上装 / 下装 / 鞋 / 童装
size_code VARCHAR(8) NOT NULL,
seq INT NOT NULL,
PRIMARY KEY (group_code, size_code)
);分发报文
审批通过后一次把三层发给下游，下游只需要处理一个接口：
json
{
"objectType": "PRODUCT",
"styleCode": "M2601",
"brandCode": "M",
"categoryLeaf": "鞋/跑步鞋/竞速跑鞋",
"tagPrice": 899.00,
"colors": [
{
"skcCode": "M2601-BK",
"colorCode": "BK",
"launchWave": "2026Q1-1",
"sizes": [
{ "skuCode": "80001234", "sizeCode": "L",
"logisticsCode": "LG26010034", "nationalCode": "6901234567890" }
]
}
],
"version": 3,
"effectiveDate": "2026-01-15"
}两条落地细节值得提前定。老编码映射表要带 src_sys 维度，同一个旧码在收银和 ERP 里可能不是同一件商品；国标码用码池分配，唯一性约束只能防重，停用的码不回收才能防一码两用。
说明：本文按企业主数据项目的实施经验整理，客户信息已做匿名处理，文中表结构、报文、编码和数字均为技术示意，仅作同行交流，不构成采购建议。