最近在负责电商后台的商品模块改造以及新增仓储物流功能，将工作内容梳理总结了一下，第一篇文章梳理改造的商品管理模块，第二篇将整理从0到1规划的物流仓储模块。

　　背景介绍

　　该电商为自营B2C模式，基本订单业务流程是：

　　由前端APP销售产生订单，订单传到中台订单模块，由订单中心处理生成配送单，通过线下调度方式，派发给物流公司。系统上仅从商品创建上架开始管理，并没有对商品采购等流程进行管理，因此系统中的商品库存数据一直不准确，所以我们希望仓储物流模块可以从源头管控商品采购流程，解决系统中商品库存数据不准确的问题，其次解决商品配送问题，最终形成产品闭环。未来业务规划需要拓展到分站分仓的销售模式，那么在商品的数量上将会大大增加，而且同一商品在不同地域或仓库维度上可能分别有不同的销售价格。

　　系统为了满足未来业务模式的拓展，我们决定先从商品模块开始改造。

　　系统现状问题分析

　　1.在创建商品时仅有一个库存字段，设计之初是希望代表物理库存，在商品生成订单时，直接减扣该库存，(实际上为了销售业绩，经过了人工多次修改后已经是虚拟库存)这显然是不能掌控实际仓库库存的。

　　2.商品管理维度为SKU，前台显示也按照SKU维度，包括前台的搜索功能，系统中不存在SPU的概念，如果商品数量增多，那么前台的类目展示、搜索、后台管理都会很难维持。

　　3.商品属性固定，仅有规格、颜色、计量单位，直接挂在商品SKU上，不支持扩展商品属性分类，每种商品的属性都是一样的，商品属性表与商品不存在对应关系。

　　4.目前每种商品只存放在一个仓库中，并且每个SKU仅有一个价格，不能支持未来多仓库多销售站点多价格的业务模式。

　　系统改造范围

　　系统级的设计从大到细一般分为四个层次：

　　1.该系统与外部其他系统的关系(如何协作、功能边界)

　　2.系统内底层数据库结构设计

　　3.系统内应用功能逻辑

　　4.系统内各界面层建设

　　一般从我们平时做产品设计的时候，可能会比较多在功能和界面上，而如果培养自己习惯从底层数据结构开始去思考这个功能和界面的设计，往往设计出来的功能可执行性会更高，与程序猿撕逼的机会会更低。

　　改造过程

　　(一)商品类目属性改造

　　1、数据结构变化

　　数据结构上增加SPU，直接将商品属性挂在SPU上，商品属性在SPU维度进行维护，SKU直接在SPU下新建，关联所属SPU的商品属性。后端商品销售类目直接作为前端销售类目，下一步再由后端类目映射到前端销售属性(不在本次进行)。

　　附部分表结构设计

2、相关需要改造的功能流程

　　新建商品流程

　　商品上下架流程

　　商品权限管理

　　此部分流程图不展开说明了。

　　3、界面上的改造，优化用户体验

　　前端商品列表由SKU变为SPU，商品详情页内区分出SKU，因为我们的商品属性目前很少，为了减少用户操作，所以在前端展示上SKU的销售属性值展示在一个类别下。

　　后端电商界面大同小异，便不展开说明。

　　4、老商品数据的处理

　　我们商品数量还不多共1300多个SKU，需要在我们系统改造后，将这些老数据整合成SPU，我们首先请采销部门进行数据初次整合，毕竟采销人员对于商品分类更专业，然后请销售部门根据用户购买习惯进行二次整理，最后请财务部对这些数据进行最后确认，避免对财务报表影响导致不必要的撕逼^^

　　(二)商品库存改造

　　1、库存数据结构

　　库存由一个字段增加为三个，物理库存、销售库存、冻结库存，商品与仓库是多对多的关系，库存作为SKU和仓库关系属性。

　　销售库存，即前台界面显示的库存。

　　物理库存，影响物理库存库存的行为，最主要的就是入库、出库。