erp系统是什么意思？

很多第三方电商平台都有自己的管理系统，就像淘宝有自己的平台管理体系，很完善也很全；京东也有自己开发的ERP和CRM管理系统，各项数据也都很全面。

加入是你自己开发的电商平台的话，其实可以根据自己的需求自己做出想要的一些数据管理或者是客户信息管理；

不过像你说的客服管理 绩效提成管理 毕竟涉及到公司的一些数据提成和考核方案，大部分都是自己制作的表格。至于公开的，我就想问问作者 你敢把你公司的市场销售数据放到公共资源上吗，呵呵！

电商后台：商品管理系统

电商管理系统是为了能够让用户快速的找到商品，为同类型产品提供标准的属性、属性值，便于统一产品，使用户得到决策必须的消息，为运营童鞋方便管理商品的上下架。

最近正在做商品管理的需求，分享自己过程中的所得。

商品管理的目的：

能够让用户快速的找到商品（主要是通过关键词搜索与类目搜索，商品管理为其提供了基础）；为同类型产品提供标准的属性，属性值，便于统一产品，使用户得到决策必须的消息；为运营童鞋方便管理商品的上下架。

类目树：定义商品的分类，是T恤，还是笔记本，还是相机，类似于生物学的门纲科目属；

属性项：不同的基础类目之间是描述属性不同，描述T恤是用领型、型号，而描述笔记本则用屏幕、分辨率、CPU主频；

属性项分组：由于一个产品的分类属性有很多，我们将形容某一类特征的属性项归为一组，如：上图的屏幕；

属性值：特定的特征或参数，电脑屏幕尺寸一般有13.3英寸、15.6英寸等属性值。

一、 类目管理

由于平台涉及的产品数量级不是很大，所以后台类目树使用了三级，我们一般称类目树的最后一级类目称为叶子类目。类目管理主要分成了后台类目管理、前台类目管理。

1. 后台类目管理

主要用于基础目录的增删改查，以及同一目录下的排序。

如上图所示五金建材为一级类目、建筑材料为二级目录、电梯为三级目录，由于设置最多为三级目录，因此电梯也称为叶子类目，后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。

后台类目相对稳定，不能随便删除，叶子类目不能重复。每个类目下都可以添加新的类目、修改以及对相应类目进行排序。

2. 前台类目管理

前台类目是给广大用户看的，因此会随着营销政策发生变化，所以前台类目灵需是可重叠，可删除的。

前台类目与后台类目为多对多的关系，一个前台类目可以关联多个后台类目，同样一个后台类目也可以关联多个前台类目。

二、 属性管理

属性管理的目的在于，在商家添加商品时，只能在已有的属性项和属性值下进行选择，避免数字格式不对，单位不统一等所导致顾客购买的障碍，甚至会引起投诉。就比如：我们要描述一张桌子的长宽高，有的人单位用米，而有的人则用厘米。

主要流程为添加属性值-添加属性项-完成属性项与值的绑定-添加分组-完成属性组、属性项、叶子目录的绑定。

1. 属性项管理

属性项管理一般主要满足属性的查询、增删改的功能，以下为属性新增和修改的原型，当输入方式为单选或者多选时，只能在当前属性项所填的值中选择。

2. 绑定属性项

目的是完成类目树叶子目录与属性建立关联关系，完成之后，运营童鞋或商家发布商品时，选择好后台类目就可以根据绑定的属性，补充必填的商品属性信息，方可成功上传商品。

属性继承：由于所做的商城涉及叶子目录所包含的属性比较独立，均不予其他叶子目录属性重复，不像电脑类目下的笔记本电脑、台式电脑、超级本，都具备屏幕尺寸、CPU型号、内存等共有属性，因此在设计时就没有考虑属性继承的功能，直接选择将属性挂靠在叶子目录下。

同时将属性值挂靠在属性项下，在做此版本中，并没有单独的页面用于将属性项挂靠在属性项分类下，而是在绑定属性项中完成分类与属性项的绑定，如下图所示。

主要是考虑到，属性项分组对于大多数产品具有通用性，不需每一个属性项先挂靠在属性分组下，然后属性分组在挂靠在叶子目录下，这样会造成运营童鞋的工作量增加。

三、 品牌管理

品牌管理的意义在于：维护一个平台共有的品牌库，商品新增和编辑的时候，只能从品牌库勾选已有可用的品牌，从而避免前台一个品牌多个名称的出现。

新建品牌时，需将品牌关联到类目下，可以是一对一，一对多、多对一的关系，这样添加产品时更加的快捷。

四、 商品管理1. 产品的新增

当我们建立好类目树、品牌、完成参数项的绑定之后，就可以新建一个产品了，上图为新增一个产品的流程，主要的产品状态分为：“待提交”、“待审核”、“待上架”、“已上架”，而相对应的工作为产品的新增、产品的审核、产品的上下架管理。

2. 系列的新增

大多数的产品都具有不同的型号大小，系列产品的新增，目前有两种方式：

将系列产品维护成一个SPU，SKU是附着在SPU下，类似于淘宝，一款产品只对应着一个链接，选择不同产品型号时，页面不会跳转；产品的每一个型号都维护成一个单独的SKU，然后在前台展示进行聚合，将多个SKU绑定在一起形成一个SPU，类似于京东，绑定之后，在前台选择不同的型号都时页面会发生跳转。

目前还没有做SKU的绑定，后期做完需求在做补充。

五、 总结

以上为一期商品管理的整理，希望给大家帮助，能少踩坑就少踩，坑队友是容易被打的。

本文由 @Demohour 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议

电商后台：FMS财务管理系统

文章对电商财务系统进行了系统的介绍，希望通过此文能够加深你对电商系统的认识。

目前互联网电商公司的系统非常多、系统间的关系也非常复杂，最近各公司都热衷于中台，应用的技术也相当之多，技术实力弱点的公司只能借助于各平台加快系统建设，尽快满足业务需求。

可是无论怎样变化，最终的数据要体现在财务系统中，目前专门介绍财务方面的内容不多，所以笔者计划针对电商财务系统写一个系列，希望这个砖能够引来大家的玉，共同学习进步。

认识财务进销存系统

首先先简单了解一下电商系统包括的相关系统，这里罗列的比较简单，实际中系统组成会更多。

目前大的公司都分为前台、中台、底盘，而每个平台又由若干系统组成，这些系统大部分应该都是自主开发或维护的；

此外还包括很多第三方系统如WMS、专业财务软件（用友NC、金碟、SAP等）、空间管理（如果有线下门店）、WEBLOG(日志系统)等等。

下图中标红框的“财务进销存FMS”即是接下来要介绍的所谓的电商财务系统。

电商核心系统组成图

1. 为什么这里叫财务进销存而不叫财务系统呢？

我个人理解是因为此系统是公司的业务系统，它是为专业的财务软件提供业务数据、报表、凭证数据的，与真正的财务软件（如用友NC、金蝶、SAP等）有一定的区别；

根据个人经验，电商系统业务变化快、需求紧急，所以一般都需要单独开发一个财务进销存系统以适应公司不同时期的业务变化。

2. 财务这么专业的软件系统开发难度大吗？

答曰：难度不大，与其他业务系统相同。

一提到财务软件，大家首先想到的也是用友、金蝶等，开发工程师也会说没学过财务，难度太大。

其实以我个人的工作经历来看，大家有些过虑且低估自己的能力了。

前面命名为“财务进销存系统”的原因主要就是因为它就是一个业务系统，是关于财务方面的进销存,只要我们学习了解一些简单的财务基础知识，开发一套财务系统还是比较容易的。

3. 开发财务系统需要了解哪些知识？

答曰：只需要了解相关的财务名词（见后面财务名词），并具备一些基础的财务知识即可。

对于财务书籍，可以看看关于财务会计的书即可，后续随着财务系统的开发了解，来不断深入学习是可以满足工作需要的。

4. 需要了解的财务名词有哪些？

声明：这里的相关名词可能与百度百科等有区别，但是表达的意思应该基本相同，详细的可以到百度百科查看（这里只罗列了主要的）

【应收】：是指在提供服务、销售产品等过程中应该向购买单位（用户）收取的款项；对于预付货款在财务中属于应收款，待结算后会进行结转，具体看财务业务要求。【应付】：是指企业应支付但尚未支付的款项（货款、佣金、服务费等），在电商系统中主要的款项是商品采购的货款或应付的提成佣金等；对于预收货款是属于负债，待订单完结时财务会进行结转。【销售收入】：是企业通过产品销售或提供劳务所获得的货币收入，以及形成的应收货款，我们这里主要是指销售商品产生的收入即企业的主营业务收入。【成本】：成本是指已销售产品的生产成本或已提供劳务的劳务成本以及其他销售的业务成本，成本有直接成本与间接成本，在我们的系统中主要是指商品的直接成本即采购商品的成本。【毛利】：毛利是指销售产品赚取的金额，我们这里主要指销售收入减去销售成本，在财务系统中可能会把相关的费用等分摊在成本中，这就是销售毛利。

销售毛利=销售收入-销售成本

【毛利率】：

毛利率=毛利/销售收入*100%=(销售收入-销售成本)/销售收入*100%

这里特殊说明一下，一般财务的金额在系统中都需要保留到４位小数，毛利率是２位小数。

【进项税率】：是商品税率，一般指在采购商品时的商品税率，根据进项税计算的税额称之为进项税额,是指纳税人购进货物、加工修理修配劳务、服务、无形资产或者不动产,支付或者负担的增值税额。

【销项税率】：是商品税率，一般指在销售商品时的商品税率，销项税额是指增值税纳税人销售货物和应交税劳务，按照销售额和适用税率计算并向购买方收取的增值税税额。

【增值税】：增值税是对商品生产、流通、劳务服务中多个环节的新增价值或商品的附加值征收的一种流转税；对于我们的系统主要是指采购时产生的增值税，以及销售过程中产生的销售项，企业每个月会根据进项税与销售税向税务局进行申报，经过进项税销项的抵扣，最终确定企业的纳税金额（这里都是根据税票及销售收入）。

【发票】：上面提到税率与增值税，就不得不得到发票，发票分为普通发票与增值税专用发票，普通发票是一般指小规模纳税人销售商品时开具的发票（如餐馆、服装等），增值税专用发票是具用普票的作用，专用于纳税人销售或者提供增值税应税项目的一种发票，随着国家增值税的改革，发票的作用越来越大，所以在财务系统中税票管理也要求比较严格。

对于财务进销存系统中的发票分为外部供应商给我们开据的增值税发票管理与我们给用户开据的发票（此部分目前基本都采用电子发票，纸质发票会慢慢消失）；

在SCM或财务系统中的发票管理是指进项税增值税专用发票管理，电子发票会调用税务接口用于在APP中显示、下载等，此部分会单独设计说明。

【经销】：在财务上一般按照货物所有权来划分的。如果货物采购入库后所有权属于我司，则属于经销，即我们买入商品进行零售处理，售价的定价权在我司，我们只根据实际采购与采购退货的单据进行与供应商结算；这种模式的缺点是如果销售不好，库存积压占用现金流很大。

【代销】：代销是指货物采购入库后，虽然货物的保管处理都由我司处理，但是我司会以实际销售出库的成本价（或结算价）与供应商进行结算，销售不了商品最终根据合同条款可以退还给供应商，这种模式的优点是卖一件结一件，只是我司会有管理货物的成本等，但库存占用现金流的风险没有。

【联营】：联营，顾名思义，就是供货商与零售商共同销售商品，零售商会根据销售的金额按照协定的扣点进行提成，这在百货商场等非常常见，像现在所说的扣率代销、佣金提成等基本与联营类似；目前像天猫、京东等平台的又是一种模式与联营非常像。

【移动加权平均】：最常用的成本核算方式之一，每年的审计部门是比较关注这部分的，因为成本影响到公司的利润、管理层的运营决策等；财务成本计算有其它几种如加权平均、先进先出、后进先出（在我国是不允许这种计价方式）

【含税金额、未税金额、税额】这几个是有关联的，而且是和税率有关的，前面说过成本一般是根据进项税率计算，销售金额是按销项税率计算，公式如下：

不含税金额=含税金额/(1+税率/100)

税额=含税金额-不含税金额=含税金额*(税率/100)/(1+税率/100)

【基准价】：系统中基准价是指基准进价，是采购订单(PO单)录入时默认的采购进价，商品的采购进价不能高于基准价，以控制采购风险。

【账期】：账期是指供应商商品到货至付款完成这一段时间，对于公司来说账期越长越有利（现金流）；财务系统中是以结算单生成到付款完成这一时间定义为账期（因为有的结算单是每月生成，有的是半月生成，有的是依赖销售单据生成如代销）。

【结算周期】：结算周期是指结算单什么时间生成，在我们的合同中有T+0即昨天当天数据当天生成，T+1即当天数据第二天生成，每周生成，每月生成（每月1日生成）或半月生成(16日生成)

【财务凭证】：此部分根据财务相关业务单据或财务报表，每天或每月根据财务会计科目生成的会记分录，目前我国使用的是借贷记账法（有借必有贷，借贷必相等）;编写财务记账凭证要根据以下两个恒等式进行。

公式1：资产＝负债+所有者权益公式

公式2：收入－费用＝利润

【财务总账与明细账】：每月财务都会进行月结，然后生成凭证，最终为总账，相对于详细的财务账为明细账，具体看公司财务部的要求。

【账套】：这是财务软件中的重要部分，可以按分公司、分部门建立多个账套，不同账套间可能会产生公司间交易，这个根据财务规划确定的。

【权限发生制】：权责发生制又称“应收应付制”。它是以本会计期间发生的费用和收入是否应计入本期损益为标准，处理有关经济业务的一种制度；权责发生制是以权利和责任的发生来决定收入和费用归属期的一项原则

【收付实现制】：收付实现制亦称“收付实现基础”或“现收现付制”。是“权责发生制”的对称。在会计核算中，是以款项是否已经收到或付出作为计算标准，来确定本期收益和费用的一种方法。

【存货】：就是库存，主要是指商品在仓库的库存金额与数量，高库存会占有现金所以风险很高，供应链中有些都在追求零库存（特殊行业除外）。

【成本】：在FMS中主要是主营业务成本，不包括人工费、管理费以及财务费用等，在财务进销存中主要进货的金额经过“成本核算方法”而计算出来的成本。

【库龄】：是指存货商品在库时间，商品出库正常是按其生产日期先进先出的，统计库龄能够很好的判断商品在库情况（30天、60天、90天）

【账龄】：是针对应收款与应付款的统计，根据账龄报表可以很的监控到财务状况，如超过1年的应收款很可能转换为坏账。

【库存周转天数】：是老板与财务极为关注的重要指标。

公式为：库存周转天数＝销售收入/((期初库存+期末库存)/2)

在财务分析上一般采用：库存周转天数＝销售成本/((期初库存+期末库存)/2)

库存周转天数越小越好，证明商品的流转非常快。

库存周转率＝360/库存周转天数。

总结

本篇只是一个开头，主要介绍了下我个人对于财务系统的理解（简称FMS-Finanacial Management System，你可以命名属于您的财务系统）；没有太多实质内容，后续在各篇中会详细解释各财务术语和名词。

您也可以关注我的微信公众号：倔强的大萝卜 来了解电商财务相关内容，在这时我会将之前的内容再次整理分享给大家，最后感谢您的阅读。

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

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

题图来自Unsplash，基于CC0协议

电商后台：商品管理系统

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

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

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

一、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、分类名称及分类编码。

前后端分类关联约束：

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

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

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

2. 分类调整

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

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

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

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

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

应对办法：

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

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

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

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

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

“商品属性”与“属性项”是字典信息即基础信息，这个信息创建时不是孤立的，它是要选中后台分类的“三级分类”后才能创建的；SPU创建时也是要选择商品分类的（后台分类），所以这时就确定了SPU所有的商品属性；每个商品属性都有属性项，需要进行选择其属性项（值）；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、网站上浏览一件商品时，我们最直接的判断商品的好坏是通过商品图片来辨识的。

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

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

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

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

商品资质一般包括：商品标签、商标注册证、授权书、入境商品检验证明等；在创建商品基本信息时可以选择需要的资质模板；根据资质模板所需要的资质由供应商或运营编辑部同事进行资质文件的上传，然后进行审核即可生效；如果商品的资质未上传或审核不通过，则在商品由新品转为正常可销售商品时会有系统提示。 9. 商品库存管理在商品系统中分类、属性、品牌、商品信息、资质都创建完成后，商品即可以进行采购了，有商品库存下一步就可以进行销售了；商品库存管理不仅在商品管理系统中，在整个供应商系统中及财务系统中都关注库存的数量与金额；创建商品信息时，需要设置商品的安全库存，以便进行及时的商品补货；对于商品的库存一般分为正品库存与残次品库存，正品库存又可以分为正常库存与赠品库存；正品库存可以上架销售、残次品库存可以报损、退货返厂或内销；库存又分为总库存和分仓库存，如果有门店则又有门店库存，所以对于商品库存的管理是非常重要的，它不仅要记录数量的变理同时要记录成本的变化；在商品管理系统主要还是库存报表的展示，对于变化是依赖于系统中的各业务单据的，库存管理模块主要功能如下图。

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

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

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

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

四、商品创建过程

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

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

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

针对上图再补充一下：

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

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

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

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

题图来自Unsplash，基于CC0协议