生鲜配送ERP系统_对商品模块数据模型与界面设计的思考【Java 开源版】杭州生鲜配送系统_升鲜宝_SaaS全链路生鲜供应链管理系统_升鲜宝_15382353715

生鲜配送ERP系统_对商品模块数据模型与界面设计的思考及简要分析【Java 开源版】杭州生鲜配送系统_升鲜宝_SaaS全链路生鲜供应链管理系统_升鲜宝_15382353715

       一直在研究与改造自己的生鲜配送系统，越来越觉得后面的报表与统计都越来越依赖于系统的商品模块了，所以商品模块的好坏，关系到使用者的操作难易程度与学习成本。现在越来越多的软件设计者，把一些通用的模块，提升到一个单独的中心（一个单独的服务中心）来设计与维护。这样就形成现在市面上业务中台的概念。大体的业务中心可以划分为以下

          商品中心 （商品属性、商品档案、商品条码、商品类目、商品服务、商品单位管理）

          库存中心 （出库业务、入库业务、移仓业务、库存盘点、库存调整、库存策略）

          订单中心 （C端订单、B端订单、订单策略、订单处理、订单售后）

          财务结算中心（应付管理、应收管理、成本管理、业绩分成）

          会员中心/客户中心（会员清洗、会员标签、精准营销、客户来源、客户类别、客户授信、打印模块）

          报表中心（商品销售报表、商品采购报表、销售分析、财务分析、利润分析、数据看板/图像趋势展示）

          营销中心（营销活动、营销策略、营销分析、营销报表）

          商品价格中心（价格策略、价格执行、促销策略、促销执行）

          仓储物流中心（采购业务/供应商管理、批发业务、配货业务、分拣业务、打包业务、加工业务、盘点业务、配送业务、周转箱管理、物流管理）

          监控中心（业务监控、单据监控、服务器监控、日志分析）

 

下面就商品模块即商品中心进行分析：

       支持以商品ID及商品标准属性与属性值，根据行业的特性，来支持商品的属性商品模板管理，扩展动态属性，以方便多维度、多类目的商品数据分析与维护，追求实现对商品多维度的商品的视图管理。我一直从事生鲜物流配送系统的设计与开发，软件产品升鲜宝也在市面上流通，2019年曾遭到同行的恶意诋毁，想起来也恶心，一个年轻的小姑娘在我客户那里拍照我的软件，然后书面恶意夸大，甚至于弄一些不符合事实的言语来诋毁，具体细节后面的博文我再一一展现。10多年的生鲜配送行业的软件开发，熟知这个行业的一些特殊属性，始终认为软件只是工具，使用规范与正确，能加速业务的发展，但是能减少很多人员，我觉得不实际（市面上的软件过分强调了软件的作用，好像软件能代替人一样的，神吹）

       升鲜宝第一代产品商品设计的时候，就采用采购与销售分离的设计思想。因为生鲜商品，大部分都存在A进B出的业务场景，需要进行加工、分装，甚至分割，期间造成的损耗，全凭经验，再加上凌晨操作的特殊性与操作人员文化水平的限制，所以生鲜软件绝大部分对商品的管理如库存准确度是无法确定的。包括市面上吹逼比较历害的某东破，百度网站整天的广告，营销人员的电话推广，其实库存管理某东破也是没有做好的。当时第一版升鲜宝设计了采购商品、销售商品（每一种卖法，就是一个最小的售卖属性，比如产地，一些商品的产地不一样对客户的认知也不一样。包心菜（兰州包心菜市面上就比较多，但是其它地方也有包心菜，这样的话，这两种包心菜就应该算不同的卖法，所以某东破把这个产地属性设置到商品的基础属性是不对的。因为产地不是生鲜商品的通用属性）商品的单位对生鲜商品也是一个难点的问题，比如土豆的基础单位（最小单位）为斤，但是销售单位可能会出现（g、kg、斤、公斤、千克这样的单位，有些人不禁要问，为什么不能统一单位呢，我现在可以明确的告诉大家，这些单位都是由于各个系统中采用的计量单位不一样造成的，生鲜配送企业一定要满足他们客户的一些要求，这样方便他们的客户进行验收入库、对账等问题）所以当时设计的表的模型如下。

这样设计的好处就是采购与销售分离，就是说销售人员不管你采购人员采购什么样的商品，销售人员可以按自己的想法与市面的需要销售商品，不受限采购商品的限制来满足客户的要求。变得灵活进来。但是这样设计的软件，使用人员使用了几个月，发现采购商品与销售商品分离的话，维护的工作量太大了。比如客户要上架一种新商品，我们的后台管理员，则需要新增一种采购商品，然后再新增一种卖法（最小的销售商品维度），还要对应采购商品与销售商品之间的关系，最后感觉使用起来不方便了。所以使用人员强烈要求我改商品的设计。基于用户使用体验，升鲜宝又做了第二次商品模块的设计，设计的时候，就直接把采购商品与销售商品放在一起了（每一种卖法就形成一种商品，这样商品列表中就有了很多商品，同一种商品，就有很多卖法，就形成了很多最小商品卖法）。可以用以下图来表示：

 

 

      基于第二版的升鲜宝商品模块的设计，使用者感觉最不方便的时候地方，商品的条数太多了，维护起来，很不方便，客户下单的时候，也不方便筛选（其实系统中是可以根据客户指定特定的商品销售的，这样的话就简单单一了，比如商品库中有8000种卖法，其实有可能对A客户只有800-1200种，甚至更少，因为每个客户需要的商品卖法是长期不变的。常购买的清单，随季节性的改变而改变，但是大多数是用依据可循的）每一种卖法形成一条商品记录，这样做的好处就是方便与第三方系统对接，也方便第三方系统与本系统对接，因为系统与系统之间的对接，主要对接的主要是以下方面（1.客户资料 2 商品资料 3 仓库资料 4 销售订单 5供应商资料 6 采购订单 再就是一些基础性设置的资料，如部门、会计科目，税率等等）因为现在企业都想把系统一体化，各个信息系统之间的数据一气呵成，方便各渠道统计与生产操作的安排。所以现在提倡线上线下一体化，B2C订单，B2B订单一体化，所以对商品模块的要求更高了，有些商品在B客户中不能出现，有些商品在C端客户中不能出现，各种卖法，不同的体量，导致对商品模块的要求越来越高，为此升鲜宝第三个版对商品模块进行大规模的改变，对商品进行大变更，来同时满足B端客户，C端客户的订单要求。也方便配送公司同时兼顾B客户业务与C端客户业务。升鲜宝第三版商品中心，为了提升用户体验、减少使用成本，更好地为全社会服务，针对这个特殊的用户群体，复杂的信息化软件也不一定适用，也为了加快生鲜配送行业的信息化发展，特将升鲜宝Java版本开源、同时也是为了破灭一套软件满足全中国生鲜配送公司的神话、集思广义，同时也可以配合C/S客户端升鲜宝软件使用，这样大大提升了用户体验。

      第三版升鲜宝供应链管理系统，采用先进的云技术，大量采用开源的技术，本着人人为我，我为人人、积水成渊的理念，高度抽象，采取自主与指派的方式，引入商品索引库的概念即云商品中心，为使用者提供常见的商品明细与图片，减少使用者的使用成本。自主生成商品与平台完善商品的拉取操作结合。第三版商品中心的设计如下：

      

            

 

 

 

 

     商品模块的一些基础设置，直接影响到后面的一些操作，如分拣、仓储、价格体系等操作，所以第三版商品中心模块是集前二次改版，加上深入研究与思考生鲜配送行业而作出的改进。然而在生鲜配送行业，生鲜商品的不标准性，客户所需要商品任意性与随意性，一直束缚着整个生鲜配送系统数据统计的准确性，影响库存的可操作性，市面上主流的生鲜配送系统的推广方式(基本上是通过百度网站推广，会员营销会议，头脑风暴、夸大行业的信息化必要性，整个行业互联网变革性、营销成份过分地夸大了系统的功能性，而忽略了这个行业的特殊性，可以不客气地讲，整个行业生鲜配送软件正在面临信任危急，使用者对系统的期望值远远大于系统提供商所表述的效果，纵观整个生鲜配送行业，对比生鲜配送软件的实施普及程度，这样的比例确实很小。导致很多生鲜配送公司在选择生鲜配送系统的时候，存在对比与观望的态度。所以生鲜配送系统应该实事实求地向使用者呈现真实有效的功能性，而不是一味要求使用者来适用通用软件的情况，搞一刀切。因为毕竟每个配送企业多多少少存在一些特殊的操作，很顺畅的流程。很好的做法。

 

 商品的价格体系（C端与B端的价格体系统，我们把它放在单独价格体系中心来讲解与说明）