电商后台：商品管理系统

前面介绍了根据商品流转所涉及的系统模块，供应商与合同的管理已经总结过，所以本篇继续写一下商品管理模块。

关于商品管理系统的总结介绍在网能够搜索出好多，这里也结合了接触过的系统，借鉴了一些资料，根据个人的理解整理出来，希望能够按计划形成一个完整的供应链系列文章，目的是通过梳理总结让自己原来懵懂的内容清晰，希望有缘看到此篇文章的人给出建议，共同学习进步。

我心自有光明月，千古团圆永无缺。山河大地拥清辉，赏心何必中秋节。

一、SPU与SKU

这个属于老生常谈，但还是温习一下这两个概念。

• SPU ：标准化产品单元(Standard Product Unit),是商品信息聚合的最小单位，是一组可复用标准化信息的集合，我的理解它主要也是为了前端显示为目的；
• SKU ：最小的库存单位(StockKeeping Unit),可以以件，盒，箱，千克等为单位存储，商品的进货、销售、售价、库存等最终都是以SKU为准的。

一个SPU可以包含多个SKU，SKU是一般是根据SPU的销售属性组合（笛卡尔乘积）；

如华为Mate30手机是一个产品，但是它有白色、金色、黑色三种颜色可选，根据规格属性又有64G、128G、256G存储，这时就共会产生9个SKU（3种颜色*3种内存规格）。

有的电商系统中是不设置SPU的，仅有SKU，这样做的目的是增加商品的曝光率，让用户更直接的看到其商品，缺点就是像服装、鞋类等商品不同尺码的也显示，让用户看起来不舒服（感觉满屏都是同样的商品）；

具体如何启用SPU可以根据实际场景进行设计，下图是一个简单的spu、sku、分类及属性的关联。

二、商品管理系统组成

商品系统一般要包含以上几部分信息，通过商品状态的变化完成在整个供应链系统中的周转；电商系统中所有的操作都是围绕商品进行的或是为商品服务的，这样理解也不为过。

商品搜索和商品紧密关联，但是一般是通过商品信息、商品属性设置关键词单独建立和部署的且与前端系统关联更为密切，这里就不过多介绍了。

1. 分类管理

商品分类是系统中非常重要的部分，它分为前端分类与后端分类。

后端分类是基础，进销存业务都是和分类紧密关联的，从商品进货到商品库存，再到商品销售，最后到财务核算很多都是以后端分类为维度进行的；同时商品的很多属性信息也是建立在商品分类上的。

前端分类是为了前端销售而建立的，它是以后端分类为基础，是为了在前端有效展示商品、用户快的搜索，查找商品而建立的一套分类。

有的系统只有一套分类，虽然业务也能正常的进行，但这样作对于网站运营同事来说可能极不方便，现在的电商网站都是前后端分类分离，前端分类负责商品展示用户体验的，后端分类用于内部ERP系统而建立的。

前端分类与后端分类层级，目前最常见的都是建立三级，分类内容：分类ID、分类名称及分类编码。

前后端分类关联约束：

1. 一个前台品类可关联多个后台的一级、二级和三级品类；
2. 后台品类仅可以关联在前台的三级品类；
3. 一个后台品类仅可以关联一个前台品类。

对于分类的维护等功能，可以采用树状的层级式，也可以采用三级联系的方式（原型就略了大家都明白）。

此部分工作是先建后端分类，再建前端分类，然后设置分类映射关系(具体可以按实际业务进行规则设置)

2. 分类调整

前端分类涉及到商品的展示、搜索，主要是应对频繁的变化的，所以会经常有些调整，以达到更好的用户体验，同时也是为了减少因为前端而影响到后端系统分类。

后端分类从供应链、财务方面考虑不建议调整，但是由于公司的组织调整、国家相关税法调整等，不可避免的会进行分类的调整，调整的内容分为两部分：

（1）分类的归属调整，原来属于“酒水->白酒”下的三级分类“浓香型”调整到“酒水－>黄酒”下。

这种调整对于 SKU 与 SPU 无影响，但是对于相关的统计报表（历史数据如果没有记录冗余分类信息）等会有显示的影响。

（2）分类上的重要信息变化，如税率变化；旧分类体系不适合新建立分类，这时所有的商品都要采用新的分类结构，同时前端分类也要进行调整。这部分对于系统影响是非常大的，涉及历史数据、当前系统（前后端）。

应对办法：

1. 在系统设计时增加必要的冗余字段，以应对分类调整对历史数据的影响（业务单据、统计报表）；
2. 增加快照信息，即每月都有分类数据的快照表，在相关业务单据、报表等都关联自己所属的快照表，这样程序逻辑要复杂些，不建议这样做。

3. 属性管理

商品属性也是基础信息，一般分为基本属性、关键属性和销售属性。

每个商品属性又对应有不同的属性值，辟如属性“尺码”，它就有“S、M、L、XL、XXL”等属性值。

对于这部分我也找了一些资料，个人感觉在系统设计上来讲，属性可以建立两个表，即“ 商品属性 ”和“ 属性项 ”字典表（如果画ER图它们的关系是1对多）。

我们还要明确商品属性是建立在SPU上，还是SKU上，还是在分类上？在上图中我列出的关系中，分类、产品与商品都有属性，这容易误导，这里解释一下。

1. “商品属性”与“属性项”是字典信息即基础信息，这个信息创建时不是孤立的，它是要选中后台分类的“三级分类”后才能创建的；
2. SPU创建时也是要选择商品分类的（后台分类），所以这时就确定了SPU所有的商品属性；每个商品属性都有属性项，需要进行选择其属性项（值）；
3. SKU也可以通过商品分类来确定它拥有的商品属性，每个SKU都有对应的属性项。

注：上面的ER图上在产品上没有增加“SPU的属性项关系”

4. 品牌管理

品牌是用以识别某个产品或服务，并使之与竞争对手的产品或服务区别的商业名称或标识；它在系统中也是一种基础信息与属性类似，但因为属性可以自定义灵活度比较高，所以品自牌与之区分，单独管理。

它主要包括品牌名称、英文名称、品牌Logo以及品牌网站、品牌说明等信息；SPU在建立时确定其品牌，同时在搜索系统建立引及关键词，方便用户进行搜索。

5. 产地管理

产地作为一个重要的属性，单独进行管理可能更好的补充完善商品信息，在目前电子商务发展的今天，大家在购买商品时更加关注于品牌与产地（国内、国外及国内各省市）；如秋季上市的大闸蟹，大家首先要判断是不是江苏阳澄湖的。

同时产地同样也属于搜索的关键字段，在前端销售的网站、APP或小程序上可以产地频道或搜索入口。产地的主要字段如编号，中文名称，英文名称，国家编码，洲/国家，是否显示等，在创建SPU时进行设置。

6. 商品信息

商品的分类、属性基础信息（关键属性、销售属性）已经确定了，下面可以建立SPU与SKU了。

前端已经介绍了SPU与SKU的相关定义及关系，下面主要说一下商品除了分类、属性、品牌与产地外的其它相关信息。

由于SKU是根据SPU的销售属性不同而生成的，所以SKU的很多信息都是继承于SPU（除库存、价格等）；

SPU与SKU编码规则：产品SPU可以采用8位码（6位分类码+2位随机码），商品SKU可以采用SPU码+2位递增码。

（1）下图是SPU与SKU的基本信息供参考：

（2）如果商品是称重销售的，还应该增加称重编码字段

编码规则：商品条码+称重编码+重量（具体的可以根据对接的电子秤进行设计）

（3）商品归属供应商

是否存在一品多商的情况，即一个商品可以从多家供应商进货（国条码相同，如矿泉水）。

对于只有一个供应商供货的商品，对于采购进货、补货或先销后采的模式都非常容易，但现实的场景中一个商品肯定会存在多个供应商供货的情况，这时无论在供应链的进销存管理中，还是在财务结算中都需要确定每一笔出入库的商品归属供应商。

在商品管理系统中需要先维护其所属的供应商（商家商品一般不会存在一品多商），如果有多个供应商需要设置主供应商。

（4）父子商品

父子商品与供应商中的父子账号、框架合同与子合同的关系类似，即一个父商品可以衍生出多个子商品，每个子商品中包括2个或2个以上父商品。

举个例子：燕京啤酒每一罐是一个父商品(规格330ml,国条码60033022),但在超市中既可以按罐买，也可以按提（6个为一提）或按箱买。

如果有人购买，你可能想，输入数量就可以了嘛，没有什么难的。没错这是一种解决方式，而且多数时我们都这样购买。

但有另一种场景即商家为了促销（9.9元/提，单个买2.5元/罐）如何处理？仍然可以采用设置促销活动，也可以采用建立子商品方式进行。

这个其实就是一个商品组合，生成一个新的商品编码（仓库要根据物料单进行作业）。对于父子商品我一直也是有些异议，但是从系统的全流程上考虑，它不仅涉及销售还涉及到仓库的作业，所以大家可以权衡确定是否采用这种方式。

（5）其它辅助信息

• 角标的设置：商品的标签信息（适用人群、养生等），用于搜索；这部分同样也可以通过属性来实现。
• 商品质检信息：检验方式、检验严格度、检验规则、检验方案、抽检数量、抽检比例
• 商品进出口信息：英文名称、英文规格、进口关税税率、进口消费税税率、进口增值税科率

7. 商品图片

图片是商品管理系统中的重要部分，在APP、网站上浏览一件商品时，我们最直接的判断商品的好坏是通过商品图片来辨识的。

商品分为列表页（进入商城主页或频道页或通过搜索后显示的商品列表显示的多个商品）与详情页（点击某一个商品后进入到详细介绍的页面）。

列表页中的商品图片一般显示主图，详情页中的图片分为商品主图与其它图片（也可以设置为主图）。

1. 对于图片，需要限制大小，同时要要求上传的图片质量；
2. 图片服务器的存储容量要进行监控，同时图片要保存在CDN上，以保证商品图片的加载速度；
3. 商品维护完基本信息后，需要进行商品图片维护，没有图片的商品是不允许上架的；
4. 图片状态：商品需要设置一个图片状态字段，新品时为“待上传”，如果已经上传图片后状态为“待审核”，审核的状态有“审核通过、审核不通过”。

8. 商品资质管理

在供应商管理部分介绍过资质管理的部分，同样对于有些商品的销售也需要提供必要的资质证书才可以进货或销售。

1. 商品资质一般包括：商品标签、商标注册证、授权书、入境商品检验证明等；在创建商品基本信息时可以选择需要的资质模板；
2. 根据资质模板所需要的资质由供应商或运营编辑部同事进行资质文件的上传，然后进行审核即可生效；
3. 如果商品的资质未上传或审核不通过，则在商品由新品转为正常可销售商品时会有系统提示。

9. 商品库存管理

1. 在商品系统中分类、属性、品牌、商品信息、资质都创建完成后，商品即可以进行采购了，有商品库存下一步就可以进行销售了；
2. 商品库存管理不仅在商品管理系统中，在整个供应商系统中及财务系统中都关注库存的数量与金额；
3. 创建商品信息时，需要设置商品的安全库存，以便进行及时的商品补货；
4. 对于商品的库存一般分为正品库存与残次品库存，正品库存又可以分为正常库存与赠品库存；
5. 正品库存可以上架销售、残次品库存可以报损、退货返厂或内销；
6. 库存又分为总库存和分仓库存，如果有门店则又有门店库存，所以对于商品库存的管理是非常重要的，它不仅要记录数量的变理同时要记录成本的变化；
7. 在商品管理系统主要还是库存报表的展示，对于变化是依赖于系统中的各业务单据的，库存管理模块主要功能如下图。

对于库存成本部分，可以看一下《FMS第十一篇：财务存货管理 关注公众号：倔强的大萝卜》。

三、商品相关服务

• 商品信息服务接口：用于提供查询商品基本信息的接口。
• 商品图片服务接口：用于前端各渠道显示商品图片和图片上传的接口。
• 商品库存查询接口：这个是商品管理系统部分非常重要的接口，它与商品销售区域模板结合提供商品是否可售，此部分要求极高，响应时间如果过长会影响到用户体验。
• 商品库存更新接口：下单时更新库存占有，出库时减库存、减库存占有，入库时增加库存。
• 商品缓存服务：将商品的相关信息更新到缓存服务器，以便快速响应查询及浏览。

与商品相关的服务需要统一管理，商品库存查询服务是最关键的，要进行压力测试以达到高可用（缓存、负载、必要时服务降级等技术这些我都不懂惭愧，只能说说）；

对于库存数据的更新需要记录详细的关键日志，以便出问题能够分析并跟踪处理。

四、商品创建过程

前面描述了商品涉及的相关信息，新建一个商品具体需要哪些操作，下图是一个简单的过程仅供参考。

可以根据描述的设计系统功能和一个个操作界面，商品管理部分涉及到商品部与运营、质检部共同协作。

审批的流程也会贯穿整个过程，个人觉得在系统操作功能上尽可能提供详细的明确的信息提示－“说人话”，以便用户更容易上手操作。

针对上图再补充一下：

1. 新建商品/导入新品时，只是商品的基本信息，不涉及图片、资质等，所以此时还没有生成产品编码（如果有SPU）或商品编码；
2. 如果有SPU，我们需要新建SPU与SKU，审核后在设置SPU的销售属性时，会根据销售属性进行SKU的生成，有些共用的属性是继承自SPU的，当生成了SKU后，维护SKU的价格、供应商等信息；
3. 对于实际设计商品系统时，要综合考虑区分SPU与SKU,简单的流程达到生产效果即可，太复杂了不仅我们乱，使用都也会乱。

总结

本篇可能与网上关于商品管理介绍有很多重叠的，看过之后可能也会觉得又是罗列了大的框框，个人觉得每个公司的业务场景是不同的，需要根据主要模块进行详细设计，需要借助业务、产品、运营、研发等所有人的智慧，有了整体的框架与概念后，再去细化相信能够设计出一个通用的商品系统，共同努力，最后感谢大家的阅读！

作者：倔强的大萝卜；公众号：倔强的大萝卜

本文由 @倔强的大萝卜 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: