生鮮配送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端的價格體系統，我們把它放在單獨價格體系中心來講解與說明）