对于电商系统来说，商品模块的维护可以说是重点作用，整个系统都是围绕商品来操作的。所以能否设计出一个简单方便的商品模块对整个系统的运行至关重要。

今天，我们来谈谈商品管理。对于商品信息的维护，其本质是管理一堆属性和属性值，理清它们之间的关系，才能玩的得心应手。

首先，我们来看看一个产品有哪些属性。下图是某电商平台的产品图:

整理出来得到属性:产品名称、品牌、类别、颜色、内存、价格、图片、产品代码、CPU型号、机身存储、产品毛重、操作系统等等。

在上一篇文章《电子商务后台设计:属性治理》中，我们将这些属性分为四类:基础属性、销售属性、搜索属性和唯一属性。除了搜索属性集成到唯一属性中，其他功能都涉及到商品信息的维护。接下来，我们将逐一讨论它们。

一、基础属性

商品所包含的所有属性都可以归为基本属性，如商品名称、品牌、类别、状态等。基本属性的维护相对简单，因为它们都是单一的可确定类型，通常可以逐个维护凭证数据的展现形式。

有几个属性需要解释:

品类：由于商品的特有属性和搜索属性都关联在品类上，以是商品品类是必须选择的。
状态: 上架/下架，确定是否在前台展示当前商品。这是整个商品的全局控制；若是上架，则之后关联的SKU也一同上架；反之则一样。
商品类型：单品/复合商品;部门平台上支持打包出售的模式，也就是一个商品现实上是包罗多个关联子商品的。可以通过商品类型字段先标记出当前商品是单品照样复合商品；若是是复合商品，之后还需要关联对应子商品。

二、特有属性

在上一篇文章“属性治理”中，我们首先介绍了商品唯一属性的设置及其与类别的关联和绑定。在商品信息的维护中，当选择了类别后，我们就可以得到设置的内容，然后凭据设置会显示表单并维护属性值。

类别绑定属性设置

规格参数维护表

三、销售属性

在谈销售属性之前，我们先了解两个基本点:SPU和SKU。

SPU:标准产品单位

SPU是商品信息聚合的最小单位，是一组可重用、易于检索的标准化信息聚合，体现了一个产品的特性。

一般来说，SPU是一种具有相同属性和属性值的商品，通常不参与商品销售价格的确定。比如iphone6s就是一个SPU。无论你在平台上还是在实体店查询iphone6s，他们给出的产品属性信息都是一致的。

SKU:库存股

SKU是存货收入和支出的计量单位，可以以件、箱、盘等为单位。

SKU是最小的不能物理划分的库存单位，这种划分是相对于存储场景而言的。对于同一种商品，在不同的存储场景下，SKU的管理是不同的。

比如我们平时去超市买早餐奶，要么是袋装的，要么是盒装的。按照最小单位，那么“袋”就是超市经营早餐牛奶的SKU。超市的货源来自供应商，供应商按箱卖给超市，所以“箱”是供应商管理早餐奶的SKU。

不知道大家有没有关注到。物美和家福乐去买一盒牛奶结账的时候，收银员不扫描盒子上的条形码，而是打开盒子拿出一个袋子扫码，然后输入数字，最后结账。这也可以看出这些大超市对乳制品的管理方法。

SKU可以简单理解为:SKU = SPU+销售属性。当影响销售价格增加的属性被添加到SPU时，该产品就成为SKU。

看看上面对SKU的定义，这是一种平衡。仔细想想，商家对商品价格的定义不就是按照商品的最小单位来定的吗？

所以我们要确定一个SKU，首先需要明确有多少属性在影响价格，找到对应的属性，列出每个属性的属性值，通过属性值的组合确定所有的SKU。

对于销售属性的维护，也是通过属性和属性值来操作的，但是有两个特殊的地方需要处理:

在完成属性值的维护后，需要凭据属性值组合来天生SKU：这个是整个商品模块最要害的地方，由于后面的价钱、库存、图片都依赖于天生的SKU。
属性值的个性化设置：犹如一款手机中的相同红色，不用商户的叫法各不相同，如炫彩红、玫瑰红守候，以及差别的颜色上会上传差别的名目的手机样式图。

维护完销售属性和属性值后，可以结合产品的唯一SKU，然后需要将商品的销售价格、订单、库存等一些属性信息直接链接到SKU上。

所以，有一个奇怪的地方需要注意。一旦确定了产品的SKU销售属性，就不能再修改销售属性。如果你增加或删除一个销售属性，那么原来的SKU数据一定是错误的，增加或删除一个详细销售属性的属性值只会影响SKU部门的数据。

1. 商品价钱

在SKU维护中，有多个价格设置，需要注意每个价格的用途:

1)购买价格

2)标价

3)普通售价

4)当前售价

5)预警价格

预警价的设计主要是为了防止商品经营者出现失误，将商品的销售价格定得过低，导致企业亏损。

这和进价差不多，通常允许低于进价卖出。比如一些即将淘汰的产品或者新做的流量，但是通常不允许低于警戒价格销售。

常用的两个地方:平时销售价维护和浮动价维护，两者都需要和预警价进行比较后才能预留。如果低于预警价，系统会给出提醒，保证价格设置的准确。

2. 库存

SKU的销售自然涉及到库存，在商品维护界面中维护库存的地方只有一个，那就是现实的可销售库存。

对于大平台的入驻商家，通常接受手工录入(有开发能力的可以做系统对接)，让商家自己维护SKU的销售数量。由商家自行斟酌填写若干明细，这个数字就是实际可售库存。

对于平台自营，公司通常有自己的仓储系统，每个SKU都有明确的仓储记录，部门SKU参与内部义务(如调拨、摄影、战略仓储等。)，导致目前无法销售。

因此，实际SKU库存可能不会全部可供销售，详细的实际可用库存需要通过统计通过仓库系统同步到商家模块，而不是由买家自己手工维护。

3. 上架/下架

除了在商品的基本属性上设置商品上架/货架操作，通过在详细的SKU上设置货架/货架操作，可以将细粒度的治理加倍到详细的SKU货架/货架状态。

4. 第三方编码

平台在创建自然SKU时，还会给每个SKU分配一个对应的提货代码(可以是产品上的条形码，也可以是公司自己定义的代码)，方便提货。

如果是自营平台，供应商在买家采购时提供给采购平台录入系统；如果是平台商家，一是平台无法采集数据，二是每个商家使用的规则不一样，所以商家只能维护一个字段。

当有订单时，订单模块派生的提货清单会提供第三个维护代码，供商家提货。

5. 图片维护

通常有三个地方维护商品各个位置的显示图片:列表图片、SKU图片组和默认图片组。

列表图：主要是搜索列表所展示的图片；
SKU图组：为每个详细的SKU上传对应的一组展示图片，主要用在商品详情页的展示上；
默认图组：若是对应的SKU未设置展示图片，则显示默认的这组图片举行展示。

小知识点:为了提高图片显示率，优化图片显示时的页面显示率，产品图片在上传时通常会进行缩放，图片以多个不同大小保存，以方便不同页面的挪用。

6. 导入功效

电商平台上的商品成千上万。如果都是通过通用的表格一个一个的维护，维护人员会累死的(看看一个电子产品有多少产品规格)。通常，系统城市设计引入了维护人员使用的功能。

商品信息的导入效果有两个局限:

第一，一次只能导入一个品类，非供应品类由于特殊属性不同，没有办法合并；

第二，只能导入基本属性和特殊属性信息，不能自然导入销售属性信息。由于销售属性需要通过属性值组合成SKU信息，系统需要唯一的ID，内部逻辑复杂。

[#]后面是要导入的特殊属性列表。

上面介绍的内容基本涵盖了一个商品的焦点信息，大家可以根据自己的实际业务场景，在必要的情况下进行优化和修改。

四、商品维护流程

最后，我们来看看商品的维护流程。

电商平台上的个体商户，由于自身SKU数量相对较少，基本可以解决从录入产品参数到产品拍照上架的问题。

但对于自营平台过万的SKU来说，这种方式显然是不行的。大平台对一个商品的维护需要多个部门的配合，基本流程如下:

采购部：买手先维护好后端品类，为每个品类绑定关联属性，并设置好属性输入方式、搜索方式等基础设置信息。
采购部: 买手从供应商获取采购商品基本信息，并将商品基本信息导入系统中，并凭据销售属性天生SKU。
采购部：买手通过采购单采购商品，并协同堆栈一同将商品录入堆栈完成商品采购，系统完成SKU同步库存信息，买手完成一样平常销售价钱的维护。
采购部：买手在系统提交商品图像采集工单。
图像采集部：图像采集部同事凭据工单申请仓储图像采集调拨工单(将之前录入的SKU每件调拨出来一件)。
仓储部：凭据图像采集调拨单，准备调拨商品。
图像采集部：图像采集部同事和仓储部举行交接出库，拿到样品、举行摄影、修图，完成后再上传到系统中。
图像采集部：摄影完成后，将商品再还回堆栈中。
仓储部：将商品重新放回堆栈中。
采购部：买手检测商品信息完善后，就可以举行一样平常上架销售了。

上述四个步骤中，除了第三步采购入库和设置价格，其他三个步骤都是在商品第一次录入系统时才需要维护。

可能有人会对上面的操作流程有疑问。平时运营不就是做产品销售吗？怎么会是这里的买家呢？

在电商企业中，买手的事务范围主要是维护商品信息、采购、维护销售价格和下架；运营人员主要专注于移动、主题框架的搭建，移动、主题问题中的详细商品，由买手决定是否介入，最终利润由双方分成(运营和买手工资与销售相关)。

客服微信:(181628402)本文链接:https://www.n5w.com/309802.html