中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

前面介紹了根據商品流轉所涉及的系統模塊，供應商與合同的管理已經總結過，所以本篇繼續寫一下商品管理模塊。

關于商品管理系統的總結介紹在網能夠搜索出好多，這里也結合了接觸過的系統，借鑒了一些資料，根據個人的理解整理出來，希望能夠按計劃形成一個完整的供應鏈系列文章，目的是通過梳理總結讓自己原來懵懂的內容清晰，希望有緣看到此篇文章的人給出建議，共同學習進步。

我心自有光明月，千古團圓永無缺。山河大地擁清輝，賞心何必中秋節。

一、SPU與SKU

這個屬于老生常談，但還是溫習一下這兩個概念。

• SPU：標準化產品單元(Standard Product Unit),是商品信息聚合的最小單位，是一組可復用標準化信息的集合，我的理解它主要也是為了前端顯示為目的；
• SKU：最小的庫存單位(StockKeeping Unit),可以以件，盒，箱，千克等為單位存儲，商品的進貨、銷售、售價、庫存等最終都是以SKU為準的。

一個SPU可以包含多個SKU，SKU是一般是根據SPU的銷售屬性組合（笛卡爾乘積）；

如華為Mate30手機是一個產品，但是它有白色、金色、黑色三種顏色可選，根據規格屬性又有64G、128G、256G存儲，這時就共會產生9個SKU（3種顏色*3種內存規格）。

有的電商系統中是不設置SPU的，僅有SKU，這樣做的目的是增加商品的曝光率，讓用戶更直接的看到其商品，缺點就是像服裝、鞋類等商品不同尺碼的也顯示，讓用戶看起來不舒服（感覺滿屏都是同樣的商品）；

具體如何啟用SPU可以根據實際場景進行設計，下圖是一個簡單的spu、sku、分類及屬性的關聯。

二、商品管理系統組成

商品系統一般要包含以上幾部分信息，通過商品狀態的變化完成在整個供應鏈系統中的周轉；電商系統中所有的操作都是圍繞商品進行的或是為商品服務的，這樣理解也不為過。

商品搜索和商品緊密關聯，但是一般是通過商品信息、商品屬性設置關鍵詞單獨建立和部署的且與前端系統關聯更為密切，這里就不過多介紹了。

1. 分類管理

商品分類是系統中非常重要的部分，它分為前端分類與后端分類。

后端分類是基礎，進銷存業務都是和分類緊密關聯的，從商品進貨到商品庫存，再到商品銷售，最后到財務核算很多都是以后端分類為維度進行的；同時商品的很多屬性信息也是建立在商品分類上的。

前端分類是為了前端銷售而建立的，它是以后端分類為基礎，是為了在前端有效展示商品、用戶快的搜索，查找商品而建立的一套分類。

有的系統只有一套分類，雖然業務也能正常的進行，但這樣作對于網站運營同事來說可能極不方便，現在的電商網站都是前后端分類分離，前端分類負責商品展示用戶體驗的，后端分類用于內部ERP系統而建立的。

前端分類與后端分類層級，目前最常見的都是建立三級，分類內容：分類ID、分類名稱及分類編碼。

前后端分類關聯約束：

1. 一個前臺品類可關聯多個后臺的一級、二級和三級品類；
2. 后臺品類僅可以關聯在前臺的三級品類；
3. 一個后臺品類僅可以關聯一個前臺品類。

對于分類的維護等功能，可以采用樹狀的層級式，也可以采用三級聯系的方式（原型就略了大家都明白）。

此部分工作是先建后端分類，再建前端分類，然后設置分類映射關系(具體可以按實際業務進行規則設置)

2. 分類調整

前端分類涉及到商品的展示、搜索，主要是應對頻繁的變化的，所以會經常有些調整，以達到更好的用戶體驗，同時也是為了減少因為前端而影響到后端系統分類。

后端分類從供應鏈、財務方面考慮不建議調整，但是由于公司的組織調整、國家相關稅法調整等，不可避免的會進行分類的調整，調整的內容分為兩部分：

（1）分類的歸屬調整，原來屬于“酒水->白酒”下的三級分類“濃香型”調整到“酒水－>黃酒”下。

這種調整對于SKU與SPU無影響，但是對于相關的統計報表（歷史數據如果沒有記錄冗余分類信息）等會有顯示的影響。

（2）分類上的重要信息變化，如稅率變化；舊分類體系不適合新建立分類，這時所有的商品都要采用新的分類結構，同時前端分類也要進行調整。這部分對于系統影響是非常大的，涉及歷史數據、當前系統（前后端）。

應對辦法：

1. 在系統設計時增加必要的冗余字段，以應對分類調整對歷史數據的影響（業務單據、統計報表）；
2. 增加快照信息，即每月都有分類數據的快照表，在相關業務單據、報表等都關聯自己所屬的快照表，這樣程序邏輯要復雜些，不建議這樣做。

3. 屬性管理

商品屬性也是基礎信息，一般分為基本屬性、關鍵屬性和銷售屬性。

每個商品屬性又對應有不同的屬性值，辟如屬性“尺碼”，它就有“S、M、L、XL、XXL”等屬性值。

對于這部分我也找了一些資料，個人感覺在系統設計上來講，屬性可以建立兩個表，即“商品屬性”和“屬性項”字典表（如果畫ER圖它們的關系是1對多）。

我們還要明確商品屬性是建立在SPU上，還是SKU上，還是在分類上？在上圖中我列出的關系中，分類、產品與商品都有屬性，這容易誤導，這里解釋一下。

1. “商品屬性”與“屬性項”是字典信息即基礎信息，這個信息創建時不是孤立的，它是要選中后臺分類的“三級分類”后才能創建的；
2. SPU創建時也是要選擇商品分類的（后臺分類），所以這時就確定了SPU所有的商品屬性；每個商品屬性都有屬性項，需要進行選擇其屬性項（值）；
3. SKU也可以通過商品分類來確定它擁有的商品屬性，每個SKU都有對應的屬性項。

注：上面的ER圖上在產品上沒有增加“SPU的屬性項關系”

4. 品牌管理

品牌是用以識別某個產品或服務，并使之與競爭對手的產品或服務區別的商業名稱或標識；它在系統中也是一種基礎信息與屬性類似，但因為屬性可以自定義靈活度比較高，所以品自牌與之區分，單獨管理。

它主要包括品牌名稱、英文名稱、品牌Logo以及品牌網站、品牌說明等信息；SPU在建立時確定其品牌，同時在搜索系統建立引及關鍵詞，方便用戶進行搜索。

5. 產地管理

產地作為一個重要的屬性，單獨進行管理可能更好的補充完善商品信息，在目前電子商務發展的今天，大家在購買商品時更加關注于品牌與產地（國內、國外及國內各省市）；如秋季上市的大閘蟹，大家首先要判斷是不是江蘇陽澄湖的。

同時產地同樣也屬于搜索的關鍵字段，在前端銷售的網站、APP或小程序上可以產地頻道或搜索入口。產地的主要字段如編號，中文名稱，英文名稱，國家編碼，洲/國家，是否顯示等，在創建SPU時進行設置。

6. 商品信息

商品的分類、屬性基礎信息（關鍵屬性、銷售屬性）已經確定了，下面可以建立SPU與SKU了。

前端已經介紹了SPU與SKU的相關定義及關系，下面主要說一下商品除了分類、屬性、品牌與產地外的其它相關信息。

由于SKU是根據SPU的銷售屬性不同而生成的，所以SKU的很多信息都是繼承于SPU（除庫存、價格等）；

SPU與SKU編碼規則：產品SPU可以采用8位碼（6位分類碼+2位隨機碼），商品SKU可以采用SPU碼+2位遞增碼。

（1）下圖是SPU與SKU的基本信息供參考：

（2）如果商品是稱重銷售的，還應該增加稱重編碼字段

編碼規則：商品條碼+稱重編碼+重量（具體的可以根據對接的電子秤進行設計）

（3）商品歸屬供應商

是否存在一品多商的情況，即一個商品可以從多家供應商進貨（國條碼相同，如礦泉水）。

對于只有一個供應商供貨的商品，對于采購進貨、補貨或先銷后采的模式都非常容易，但現實的場景中一個商品肯定會存在多個供應商供貨的情況，這時無論在供應鏈的進銷存管理中，還是在財務結算中都需要確定每一筆出入庫的商品歸屬供應商。

在商品管理系統中需要先維護其所屬的供應商（商家商品一般不會存在一品多商），如果有多個供應商需要設置主供應商。

（4）父子商品

父子商品與供應商中的父子賬號、框架合同與子合同的關系類似，即一個父商品可以衍生出多個子商品，每個子商品中包括2個或2個以上父商品。

舉個例子：燕京啤酒每一罐是一個父商品(規格330ml,國條碼60033022),但在超市中既可以按罐買，也可以按提（6個為一提）或按箱買。

如果有人購買，你可能想，輸入數量就可以了嘛，沒有什么難的。沒錯這是一種解決方式，而且多數時我們都這樣購買。

但有另一種場景即商家為了促銷（9.9元/提，單個買2.5元/罐）如何處理？仍然可以采用設置促銷活動，也可以采用建立子商品方式進行。

這個其實就是一個商品組合，生成一個新的商品編碼（倉庫要根據物料單進行作業）。對于父子商品我一直也是有些異議，但是從系統的全流程上考慮，它不僅涉及銷售還涉及到倉庫的作業，所以大家可以權衡確定是否采用這種方式。

（5）其它輔助信息

• 角標的設置：商品的標簽信息（適用人群、養生等），用于搜索；這部分同樣也可以通過屬性來實現。
• 商品質檢信息：檢驗方式、檢驗嚴格度、檢驗規則、檢驗方案、抽檢數量、抽檢比例
• 商品進出口信息：英文名稱、英文規格、進口關稅稅率、進口消費稅稅率、進口增值稅科率

7. 商品圖片

圖片是商品管理系統中的重要部分，在APP、網站上瀏覽一件商品時，我們最直接的判斷商品的好壞是通過商品圖片來辨識的。

商品分為列表頁（進入商城主頁或頻道頁或通過搜索后顯示的商品列表顯示的多個商品）與詳情頁（點擊某一個商品后進入到詳細介紹的頁面）。

列表頁中的商品圖片一般顯示主圖，詳情頁中的圖片分為商品主圖與其它圖片（也可以設置為主圖）。

1. 對于圖片，需要限制大小，同時要要求上傳的圖片質量；
2. 圖片服務器的存儲容量要進行監控，同時圖片要保存在CDN上，以保證商品圖片的加載速度；
3. 商品維護完基本信息后，需要進行商品圖片維護，沒有圖片的商品是不允許上架的；
4. 圖片狀態：商品需要設置一個圖片狀態字段，新品時為“待上傳”，如果已經上傳圖片后狀態為“待審核”，審核的狀態有“審核通過、審核不通過”。

8. 商品資質管理

在供應商管理部分介紹過資質管理的部分，同樣對于有些商品的銷售也需要提供必要的資質證書才可以進貨或銷售。

1. 商品資質一般包括：商品標簽、商標注冊證、授權書、入境商品檢驗證明等；在創建商品基本信息時可以選擇需要的資質模板；
2. 根據資質模板所需要的資質由供應商或運營編輯部同事進行資質文件的上傳，然后進行審核即可生效；
3. 如果商品的資質未上傳或審核不通過，則在商品由新品轉為正?？射N售商品時會有系統提示。

9. 商品庫存管理

1. 在商品系統中分類、屬性、品牌、商品信息、資質都創建完成后，商品即可以進行采購了，有商品庫存下一步就可以進行銷售了；
2. 商品庫存管理不僅在商品管理系統中，在整個供應商系統中及財務系統中都關注庫存的數量與金額；
3. 創建商品信息時，需要設置商品的安全庫存，以便進行及時的商品補貨；
4. 對于商品的庫存一般分為正品庫存與殘次品庫存，正品庫存又可以分為正常庫存與贈品庫存；
5. 正品庫存可以上架銷售、殘次品庫存可以報損、退貨返廠或內銷；
6. 庫存又分為總庫存和分倉庫存，如果有門店則又有門店庫存，所以對于商品庫存的管理是非常重要的，它不僅要記錄數量的變理同時要記錄成本的變化；
7. 在商品管理系統主要還是庫存報表的展示，對于變化是依賴于系統中的各業務單據的，庫存管理模塊主要功能如下圖。

對于庫存成本部分，可以看一下《FMS第十一篇：財務存貨管理 關注公眾號：倔強的大蘿卜》。

三、商品相關服務

• 商品信息服務接口：用于提供查詢商品基本信息的接口。
• 商品圖片服務接口：用于前端各渠道顯示商品圖片和圖片上傳的接口。
• 商品庫存查詢接口：這個是商品管理系統部分非常重要的接口，它與商品銷售區域模板結合提供商品是否可售，此部分要求極高，響應時間如果過長會影響到用戶體驗。
• 商品庫存更新接口：下單時更新庫存占有，出庫時減庫存、減庫存占有，入庫時增加庫存。
• 商品緩存服務：將商品的相關信息更新到緩存服務器，以便快速響應查詢及瀏覽。

與商品相關的服務需要統一管理，商品庫存查詢服務是最關鍵的，要進行壓力測試以達到高可用（緩存、負載、必要時服務降級等技術這些我都不懂慚愧，只能說說）；

對于庫存數據的更新需要記錄詳細的關鍵日志，以便出問題能夠分析并跟蹤處理。

四、商品創建過程

前面描述了商品涉及的相關信息，新建一個商品具體需要哪些操作，下圖是一個簡單的過程僅供參考。

可以根據描述的設計系統功能和一個個操作界面，商品管理部分涉及到商品部與運營、質檢部共同協作。

審批的流程也會貫穿整個過程，個人覺得在系統操作功能上盡可能提供詳細的明確的信息提示－“說人話”，以便用戶更容易上手操作。

針對上圖再補充一下：

1. 新建商品/導入新品時，只是商品的基本信息，不涉及圖片、資質等，所以此時還沒有生成產品編碼（如果有SPU）或商品編碼；
2. 如果有SPU，我們需要新建SPU與SKU，審核后在設置SPU的銷售屬性時，會根據銷售屬性進行SKU的生成，有些共用的屬性是繼承自SPU的，當生成了SKU后，維護SKU的價格、供應商等信息；
3. 對于實際設計商品系統時，要綜合考慮區分SPU與SKU,簡單的流程達到生產效果即可，太復雜了不僅我們亂，使用都也會亂。

總結

本篇可能與網上關于商品管理介紹有很多重疊的，看過之后可能也會覺得又是羅列了大的框框，個人覺得每個公司的業務場景是不同的，需要根據主要模塊進行詳細設計，需要借助業務、產品、運營、研發等所有人的智慧，有了整體的框架與概念后，再去細化相信能夠設計出一個通用的商品系統，共同努力，最后感謝大家的閱讀！

作者：倔強的大蘿卜；公眾號：倔強的大蘿卜

本文由 @倔強的大蘿卜 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議