对于电商系统来说，商品模块的维护可以说是焦点功效了，整个系统都是围绕商品来举行运营的。以是能否设计一个天真便捷的商品模块，对于整个系统的操作都非常重要。

今天我们就来聊聊商品治理那点事，对于商品信息的维护，它的本质是对一堆属性和属性值的治理，理清其中的关联关系，就能将其玩转的游刃有余。

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

整理一下可以获得其中的属性：商品名称、品牌、品类、颜色、内存、价钱、图片、商品编码、CPU型号、机身存储、商品毛重、操作系统等等。

在上一篇《电商后台设计：属性治理》中，我们将这些属性分了四类：基础属性、销售属性、搜索属性、特有属性。除了其中的搜索属性被融合在特有属性中，其它的功效在商品信息维护中都有所涉及，接下来我们逐一举行讨论。

一、基础属性

对于所有商品包罗的属性，都可以归类到基础属性中，如商品名称、品牌、品类、状态等。对于基础属性的维护比较简朴，由于都是单一可以确定类型，通常凭据数据展示形式逐一维护即可。

其中有几个属性需要说明一下：

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

二、特有属性

在上一篇《属性治理》中，我们先容了商品特有属性的设置以及与品类的关联绑定。在商品信息维护时，当选定品类后，我们就能获得已经设置好的设置内容，接下来凭据设置将表单展示出来，并维护好其中的属性值即可。

品类绑定属性设置

规格参数维护表单

三、销售属性

在说销售属性前，我们先来领会两个基本观点：SPU和SKU。

SPU：Standard Product Unit (标准化产物单元)

SPU是商品信息聚合的最小单元，是一组可复用、易检索的标准化信息的聚集，该聚集形貌了一个产物的特征。

SPU通俗的来讲就是一类具有相同属性、属性值的商品，这些属性和属性值通常不介入商品的销售价确定。如iphone6s就是一个SPU，无论你在谁人平台或者实体店查询iphone6s，他们给出的商品属性信息都是一致的。

SKU： Stock Keeping Unit(库存量单元)

SKU即库存收支计量的单元， 可以是以件、盒、托盘等为单元。

SKU是物理上不能分割的最小存货单元，而这个不能分割是相对于储存场景的，对于相同的商品，在差别的仓储场景下，对SKU的治理是不一样的。

举个列子，我们平时去超市买早餐奶，可以买一袋，也可以买一箱。按最小单元来说，那么”袋”就是超市治理早餐奶的SKU。超市的货源是来自供应商的，供应商是按箱卖给超市的，以是”箱”是供应商治理早餐奶的SKU。

不知道人人有没有注重过，在物美、家福乐去买一箱奶，结账的时刻，收银员不是扫描箱子上的条码，而是打开箱子取出一袋来举行扫码，然后再输入数目最后结账，这也就能看出这些大超市的对奶制品的治理方式。

SKU可以简朴理解为：SKU = SPU + 销售属性，当在SPU上添加上商家、颜色、内存等影响销售加价的属性后，这个商品就成一个SKU。

看着和上面SKU的界说有点收支，若是仔细想想，商家对商品价钱的界说不就是根据商品的最小单元设置的吗？

以是当我们想要确定一个SKU时，首先需要明确有几个属性在影响价钱，找到对应的属性，列出每个属性的属性值，通过属性值的组合就能确定所有的SKU。

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

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

维护好销售属性和属性值后，就能通过组合产物唯一的SKU，之后商品的销售价钱、订单、库存等一些属性信息，都需要与SKU直接挂钩。

以是这里有一个稀奇需要注重的地方，一旦确定了组成商品的SKU销售属性后，就不能再做对销售属性举行修改；若是添加或删除销售属性，之前天生的SKU数据一定就不对了，而添加或删除某个详细销售属性的属性值仅会影响部门SKU的数据。

1. 商品价钱

在SKU维护时，有多个价钱的设置，需要注重每个价钱的用途：

1）采购价

采购职员从供应商那里采购商品时的价钱，系统中有几个处会使用采购价的地方：

1. 商品采购入库时，商品的采购价钱会同商品信息一起保留在入库单中；
2. 在填写商品的一样平常销售价和流动销售价时，会通过对比采购价，防止销售价钱过低而使企业受损失；
3. 商品完成订单销售后，系统盘算销售成本和应收金额时使用。

2）吊牌价

吊牌价通常是供应商在商品出厂时，为商品所设置的一个市场销售参考价，价钱通常会和商品的一些质检信息一同写在商品的吊牌上。吊牌价一样平常在线下使用的比较多，如阛阓里的服装时最为常见。

2B（批发）与2C（零售）电商小程序设计的不同之处

在线上系统设计时，吊牌价仅仅为销售价设定起到一个参考作用，现实价钱我们一样平常接纳另一个观点——销售价，销售价又分一样平常销售价和流动销售价。

3）一样平常销售价

商品在没有介入流动时所设置的出售价钱就是一样平常销售价钱，商品在上架时代一样平常流动价会一直存在的。

若是是个体商户，户主自己凭据进货价设定价钱，若是是大的自营电商，通常由采购职员凭据采购价和期望利润来确定一样平常销售价。

4）流动销售价

商品介入流动时所设置的销售价钱就是流动销售价，流动销售价只有在流动时代有用；流动过时，商品售价又会使用一样平常销售价。大的自营电商内里，通常由采购职员来维护。

5）预警价

预警价钱的设计主要是为了防止商品运营职员录入失误，将商品出售价钱设置的过低，导致企业损失而设置的预警功效。

这个和采购价有部门类似，一样平常低于采购价是允许出售的。如一些即将过时的产物或拉新做的流动，然则低于预警价通常是不让出售的。

常用的两个地方：一样平常销售价维护和流动价维护，这两个价钱在保留前都需要和预警价举行比对，若是低于预警价，系统会给出提醒，以确保价钱设置准确。

2. 库存

对于SKU的出售自然就涉及到了库存，在商品维护界面仅有一个对库存数维护的地方，也就是现实可售库存。

对于大平台的入驻商户来说，通常接纳手动录入方式(有开发能力的可以做系统对接)，让商户自己维护SKU的销售数目。详细填写若干由商户自己决议，这个填写的数字就是现实可售库存。

而对于平台自营来说，公司通常都有自己的仓储系统，每个SKU都有明确的存储纪录，而且部门SKU介入内部义务(如调拨、摄影、战略储存等)使得当前时间不能售。

因此现实的SKU库存可能并不等于所有可售，详细现实可售库存需要通过仓储系统经由统计同步到商户模块中，而不是由买手自己手动维护。

3. 上架/下架

除了在商品的基础属性上设置有商品的上架/下架操作，通过在详细的SKU上也设置一个上架/下架操作，可以加倍细粒度的治理到详细的SKU上下架状态。

4. 第三方编码

平台在天生SKU时，会为每个SKU也分配响应的拣货码(可能是商品身上的条码，也可能是公司内部自己界说的编码)，以利便拣货时使用。

若是是自营平台，买手采购时供应商会提供给采购平台以便录入系统；若是是平台商户，一是平台没有办法采集数据，二是各商户各自在拣货时使用的规则各不相同，以是仅给一个可以让商户自己维护的字段。

当有订单发生时，在订单模块中导出的拣货单中会带有维护的第三发编码以供商户举行拣货操作。

5. 图片维护

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

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

小知识点：图片在展示时，为了能够提升图片展示速率，优化页面展示速率，商品图片在上传时通常会通过缩放，将图片保留成多个差别的尺寸，以利便差别页面举行挪用。

6. 导入功效

电商平台上的商品成千上万，若是都通过通例的表单一个一个维护，维护职员就得被累死了(看一下一个电子产物有若干产物规格)，通常系统都市设计导入功效供维护职员使用。

在商品信息的导入功效里有两个限制：

一是一次只能导入一个品类，由于不用品类的特殊属性不一样，没有办法合并在一起；

二是仅能导入基础属性和特殊属性信息，销售属性信息不支持通过导入天生，由于销售属性需要通过属性值组合成SKU信息，系统需要天生唯一ID， 内部逻辑比较复杂。

【#】后面为需要导入的特殊属性列表。

上面先容的内容，基本涵盖了一个商品的焦点信息，人人有需要的可以凭据自己的现实营业场景再举行优化修改。

四、商品维护流程

最后我们再来看一下商品的维护流程。

在电商平台上的个体商户，由于自家SKU数目比较少，从录入商品参数到商品摄影、上架一个人基本都能解决。

然则对于自营平台过万的SKU，这样的方式显然是不行的。大平台对一个商品的维护需要多个部门协同互助来完成，基本流程如下：

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

以上四个步骤中，除了第三步采购入库、设置价钱会经常使用，其它的三步仅在商品第一次录入系统的时刻需要维护。

对于上述操作流程有人可能有疑问，通常不是运营在做产物销售吗，这里怎么是买手呢？

在电商企业中买手的事情范围主要是维护商品信息、采购、维护销售价钱以及下上架；而运营职员主要卖力构建流动、专题框架、流动和专题中的详细商品由买手来决议是否来介入，最终的利润由双方来分(运营和买手的薪资是和销售额有关的)。

客服微信：（ 181628402）本文链接： https://www.n5w.com/309802.html