发布时间：2020-11-12 分类： 行业资讯
最近，我负责电子商务后台商品模块的改造以及新的仓储和物流功能。我总结了工作内容。第一篇文章梳理了转换后的商品管理模块，第二篇文章将物流存储模块从0到1计划整理出来。 。
背景介绍
电子商务是自营B2C模式，基本订单业务流程是：
订单由前端APP销售生成，订单被发送到中间订单模块。订单中心处理生成的交货订单，并通过离线计划将其分配给物流公司。系统仅管理从产品创建货架，而不管理购买货物的过程。因此，系统中的库存数据不准确，所以我们希望仓库物流模块能够从源头管理商品采购流程，解决系统中的商品库存问题。数据不准确的问题，其次是商品分销问题，最终形成了闭环产品。未来的商业计划需要扩展到分站的销售模式，因此商品数量将大大增加，同一产品在不同地区或仓库尺寸可能具有不同的销售价格。
为了满足未来商业模式的扩展，我们决定从商品模块开始。
系统现状分析
1.创建产品时只有一个库存字段。在设计之初，希望代表实际库存。生成货物时，会直接扣除库存。 （事实上，对于销售业绩，经过多次手动修改后已经虚拟化。库存）这显然无法控制实际的仓库库存。
2.商品管理维度为SKU，前景显示也遵循SKU维度，包括前端搜索功能。 SPU的概念在系统中不存在。如果商品数量增加，则难以维护前景的类别显示，搜索和后台管理。
3.产品属性是固定的。只有规格，颜色和测量单位直接连接到产品SKU。不支持扩展产品属性分类。每种产品的属性都是相同的。产品属性表与产品之间没有对应关系。
4.目前，每种商品只存储在一个仓库中，每个SKU只有一个价格，不能支持未来多仓多销售多价格的商业模式。
系统转型范围
系统级设计通常分为从大到小的四个级别：
1.系统与其他外部系统之间的关系（如何合作，功能界限）
2.系统中的底层数据库结构设计
3.系统中的应用程序逻辑
4.构建系统中的每个接口层
一般来说，当我们通常设计产品时，我们可能会有更多的功能和界面。如果我们培养自己开始考虑底层数据结构的功能和界面设计，那么设计的功能通常更具可执行性。拆除该计划的机会将会降低。
转型过程
（1）商品类别属性的转换
1.数据结构变化
SPU被添加到数据结构中，商品属性直接链接到SPU。商品属性保持在SPU维度中，并且在SPU下新创建SKU，并且关联SPU的商品属性。后端商品销售类别直接用作前端销售类别，下一步是将后端类别映射到前端销售属性（不在此时间）。
部分表结构设计
2.需要修改的相关功能过程
新产品流程
产品装卸过程
产品权利管理
流程图的这一部分不会扩展描述。
3，在界面上进行转换，优化用户体验
前端产品列表从SKU更改为SPU，SKU在产品详细信息页面中进行区分。由于我们的产品属性目前很少，为了减少用户操作，前端显示器上SKU的销售属性值显示在一个类别下。
后端电子商务界面类似，因此不会扩展说明。
4.处理旧产品数据
我们总共没有超过1,300个SKU。我们需要在重建系统后将这些旧数据集成到SPU中。我们首先要求销售部门首次进行数据集成。毕竟，销售人员在班级分类方面更专业，然后请销售部门根据用户的购买习惯进行第二次分类。最后，财务部门需要确认数据，以避免对财务报表造成不必要的损害。 ^^
（二）商品库存转换
1.库存数据结构
库存从一个字段增加到三个，实际库存，销售库存，冻结库存，货物和仓库是多对多关系，库存为SKU和仓库关系属性。
销售库存，即前屏幕上显示的库存。
实物库存，影响实际库存库存的行为，最重要的是进入仓库，走出库。
仓储是指货物数量的增加，普通采购仓储，退货仓储，交换仓储，转移仓储，生产仓储，磁盘仓储，其他仓储等;出境是多少商品减少数量，共同销售出仓库，购买退出库，转出库，磁盘丢失出库，其他出库。
根据实际业务确定的锁定库存不需要手动维护。
库存扣除节点
假设用户订购了100件物品
用户订单（确认订单）：销售库存-100;实物库存不变;冻结库存不变
用户付款：销售库存-100;实物库存不变;冻结库存+100
商品缺货：销售库存-100;实物盘点-100;冷冻库存释放
2.业务职能
1）原始库存扩展为三个，其中手动维护销售库存和锁定库存。客户服务根据实际库存和销售需求维护销售库存。业务稳定后，系统可以根据超卖率自动维护，如销售。库存=1.2 *实际库存，仓库根据入库和出库的实际数量维护实际库存。
2）结合活性产品
合并的产品不计入新的sku，并且创建对应于两种产品的sku的新的活性产品C.
合并商品价格=活动价格+ b活动价格可以理解为这样。
商品库逻辑功能通过设置新的活动商品C并给出活动商品的销售库存来解决该问题。该库存可以根据实际业务需求确定（例如，如果活动需要销售相邻批次的产品，则可以使用该部分的库存数量。控制批次商品的库存），物理扣除a，b的相应实物盘点。
以上是商品管理模块转型的简要总结。我将继续介绍商品仓储物流的下一部分。
