最近在负责电商后台的商品模块改造以及新增仓储物流功能，将工作内容梳理总结了一下，第一篇文章梳理改造的商品管理模块，第二篇将整理从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和仓库关系属性
销售库存，即前台界面显示的库存。
物理库存，影响物理库存库存的行为，最主要的就是入库、出库。
入库就是增加了多少商品数量，常见的有采购入库、退货入库、换货入库、调拨入库、生产入库、盘盈入库、其他入库等；出库就是减少了多少商品数量，常见的有销售出库、采购退货出库、调拨出库、盘亏出库、其他出库等 。
锁定库存，由实际业务决定的，无需人工维护。
库存减扣节点
假设用户下单购买100件商品
用户下单（确认订单）：销售库存-100；物理库存不变；冻结库存不变
用户付款：销售库存-100；物理库存不变；冻结库存+100
商品出库：销售库存-100；物理库存-100；冻结库存释放
2.业务功能
1）原有的一个库存扩展到三个，其中销售库存和锁定库存均需人工维护，客服根据实际库存和销售需求维护销售库存，业务稳定后，可以由系统根据超售比例自动维护，如销售库存=1.2*物理库存，仓库根据实际出入库数量维护物理库存。
2）组合活动商品
组合商品不算做新的sku，对应两个商品分别的sku，新建一个活动商品C 。
组合商品价格=a活动价格+b活动价格，可以这么理解
商品库逻辑功能这样解决，设置新的活动商品C，赋予一个活动商品的销售库存，这个库存可以根据实际业务需要来定（比如活动需要销售临近批次的产品，就可以将这部分的库存数量控制在该批次商品库存），实际扣减对应的a,b的物理库存。
以上是对于商品管理模块改造的简单总结，关于商品仓储物流的部分我会放在下一次继续介绍(｡◕ˇ∀ˇ◕)
作者：一枚电商产品妹子，坐标南京。（微信公众号见名片）
网友评论