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

編輯導語：商品在整個電商系統中處于核心位置，因此商品維護對于電商后臺設計的重要性不言而喻，本文作者以此為出發點，和我們聊一聊在電商后臺設計中關于商品維護的那些事。

對于電商系統來說，商品模塊的維護可以說是核心功能了，整個系統都是圍繞商品來進行運營的。所以能否設計一個靈活便捷的商品模塊，對于整個系統的操作都非常重要。

今天我們就來聊聊商品管理那點事，對于商品信息的維護，它的本質是對一堆屬性和屬性值的管理，理清其中的關聯關系，就能將其玩轉的游刃有余。

首先我們先來看看一個商品都有哪些屬性，下圖是某電商平臺的商品圖：

整理一下可以得到其中的屬性：商品名稱、品牌、品類、顏色、內存、價格、圖片、商品編碼、CPU型號、機身存儲、商品毛重、操作系統等等。

在上一篇《電商后臺設計：屬性管理》中，我們將這些屬性分了四類：基礎屬性、銷售屬性、搜索屬性、特有屬性。除了其中的搜索屬性被融合在特有屬性中，其它的功能在商品信息維護中都有所涉及，接下來我們一一進行討論。

一、基礎屬性

對于所有商品包含的屬性，都可以歸類到基礎屬性中，如商品名稱、品牌、品類、狀態等。對于基礎屬性的維護比較簡單，由于都是單一可以確定類型，通常根據數據展示形式一一維護即可。

其中有幾個屬性需要說明一下：

1. 品類：由于商品的特有屬性和搜索屬性都關聯在品類上，所以商品品類是必須選擇的。
2. 狀態: ?上架/下架，確定是否在前臺展示當前商品。這是整個商品的全局控制；如果上架，則之后關聯的SKU也一同上架；反之則一樣。
3. 商品類型：單品/復合商品;部分平臺上支持打包出售的模式，也就是一個商品實際上是包含多個關聯子商品的?？梢酝ㄟ^商品類型字段先標記出當前商品是單品還是復合商品；如果是復合商品，之后還需要關聯對應子商品。

二、特有屬性

在上一篇《屬性管理》中，我們介紹了商品特有屬性的設置以及與品類的關聯綁定。在商品信息維護時，當選定品類后，我們就能獲得已經設置好的配置內容，接下來根據配置將表單展示出來，并維護好其中的屬性值即可。

品類綁定屬性設置

規格參數維護表單

三、銷售屬性

在說銷售屬性前，我們先來了解兩個基本概念：SPU和SKU。

SPU：Standard Product Unit (標準化產品單元)

SPU是商品信息聚合的最小單位，是一組可復用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。

SPU通俗的來講就是一類具有相同屬性、屬性值的商品，這些屬性和屬性值通常不參與商品的銷售價確定。如iphone6s就是一個SPU，無論你在那個平臺或者實體店查詢iphone6s，他們給出的商品屬性信息都是一致的。

SKU： Stock Keeping Unit(庫存量單位)

SKU即庫存進出計量的單位， 可以是以件、盒、托盤等為單位。

SKU是物理上不可分割的最小存貨單元，而這個不可分割是相對于儲存場景的，對于相同的商品，在不同的倉儲場景下，對SKU的管理是不一樣的。

舉個列子，我們平時去超市買早餐奶，可以買一袋，也可以買一箱。按最小單元來說，那么”袋”就是超市管理早餐奶的SKU。超市的貨源是來自供應商的，供應商是按箱賣給超市的，所以”箱”是供應商管理早餐奶的SKU。

不知道大家有沒有留意過，在物美、家福樂去買一箱奶，結賬的時候，收銀員不是掃描箱子上的條碼，而是打開箱子取出一袋來進行掃碼，然后再輸入數量最后結賬，這也就能看出這些大超市的對奶制品的管理方式。

SKU可以簡單理解為：SKU = SPU + 銷售屬性，當在SPU上添加上商家、顏色、內存等影響銷售加價的屬性后，這個商品就成一個SKU。

看著和上面SKU的定義有點出入，如果仔細想想，商家對商品價格的定義不就是按照商品的最小單元設置的嗎？

所以當我們想要確定一個SKU時，首先需要明確有幾個屬性在影響價格，找到對應的屬性，列出每個屬性的屬性值，通過屬性值的組合就能確定所有的SKU。

對于銷售屬性的維護，也是通過屬性和屬性值來操作的，但是有兩個特殊的地方需要處理:

1. 在完成屬性值的維護后，需要根據屬性值組合來生成SKU：這個是整個商品模塊最關鍵的地方，因為后面的價格、庫存、圖片都依賴于生成的SKU。
2. 屬性值的個性化設置：如同一款手機中的相同紅色，不用商戶的叫法各不相同，如炫彩紅、玫瑰紅等待，以及不同的顏色上會上傳不同的款式的手機樣式圖。

維護好銷售屬性和屬性值后，就能通過組合產品唯一的SKU，之后商品的銷售價格、訂單、庫存等一些屬性信息，都需要與SKU直接掛鉤。

所以這里有一個特別需要注意的地方，一旦確定了組成商品的SKU銷售屬性后，就不能再做對銷售屬性進行修改；如果添加或刪除銷售屬性，之前生成的SKU數據肯定就不對了，而添加或刪除某個具體銷售屬性的屬性值僅會影響部分SKU的數據。

1. 商品價格

在SKU維護時，有多個價格的設置，需要注意每個價格的用途：

1）采購價

采購人員從供應商那里采購商品時的價格，系統中有幾個處會使用采購價的地方：

1. 商品采購入庫時，商品的采購價格會同商品信息一起保存在入庫單中；
2. 在填寫商品的日常銷售價和活動銷售價時，會通過對比采購價，防止銷售價格過低而使企業受損失；
3. 商品完成訂單銷售后，系統計算銷售成本和應收金額時使用。

2）吊牌價

吊牌價通常是供應商在商品出廠時，為商品所設置的一個市場銷售參考價，價格通常會和商品的一些質檢信息一同寫在商品的吊牌上。吊牌價一般在線下使用的比較多，如商場里的服裝時最為常見。

在線上系統設計時，吊牌價僅僅為銷售價設定起到一個參考作用，實際價格我們一般采用另一個概念——銷售價，銷售價又分日常銷售價和活動銷售價。

3）日常銷售價

商品在沒有參與活動時所設置的出售價格就是日常銷售價格，商品在上架期間日?；顒觾r會一直存在的。

如果是個體商戶，戶主自己根據進貨價設定價格，如果是大的自營電商，通常由采購人員根據采購價和期望利潤來確定日常銷售價。

4）活動銷售價

商品參與活動時所設置的銷售價格就是活動銷售價，活動銷售價只有在活動期間有效；活動過期，商品售價又會使用日常銷售價。大的自營電商里面，通常由采購人員來維護。

5）預警價

預警價格的設計主要是為了防止商品運營人員錄入失誤，將商品出售價格設置的過低，導致企業損失而設置的預警功能。

這個和采購價有部分類似，一般低于采購價是允許出售的。如一些即將過期的產品或拉新做的活動，但是低于預警價通常是不讓出售的。

常用的兩個地方：日常銷售價維護和活動價維護，這兩個價格在保存前都需要和預警價進行比對，如果低于預警價，系統會給出提示，以確保價格設置正確。

2. 庫存

對于SKU的出售自然就涉及到了庫存，在商品維護界面僅有一個對庫存數維護的地方，也就是實際可售庫存。

對于大平臺的入駐商戶來說，通常采用手動錄入方式(有開發能力的可以做系統對接)，讓商戶自己維護SKU的銷售數量。具體填寫多少由商戶自己決定，這個填寫的數字就是實際可售庫存。

而對于平臺自營來說，公司通常都有自己的倉儲系統，每個SKU都有明確的存儲記錄，并且部分SKU參與內部任務(如調撥、拍照、戰略儲存等)使得當前時間不可售。

因此實際的SKU庫存可能并不等于全部可售，具體實際可售庫存需要通過倉儲系統經過統計同步到商戶模塊中，而不是由買手自己手動維護。

3. 上架/下架

除了在商品的基礎屬性上設置有商品的上架/下架操作，通過在具體的SKU上也設置一個上架/下架操作，可以更加細粒度的管理到具體的SKU上下架狀態。

4. 第三方編碼

平臺在生成SKU時，會為每個SKU也分配相應的揀貨碼(可能是商品身上的條碼，也可能是公司內部自己定義的編碼)，以方便揀貨時使用。

如果是自營平臺，買手采購時供應商會提供給采購平臺以便錄入系統；如果是平臺商戶，一是平臺沒有辦法采集數據，二是各商戶各自在揀貨時使用的規則各不相同，所以僅給一個可以讓商戶自己維護的字段。

當有訂單產生時，在訂單模塊中導出的揀貨單中會帶有維護的第三發編碼以供商戶進行揀貨操作。

5. 圖片維護

商品各位置的展示圖片，圖片維護通常有三個地方：列表圖、SKU圖組和默認圖組。

1. 列表圖：主要是搜索列表所展示的圖片；
2. SKU圖組：為每個具體的SKU上傳對應的一組展示圖片，主要用在商品詳情頁的展示上；
3. 默認圖組：如果對應的SKU未設置展示圖片，則顯示默認的這組圖片進行展示。

小知識點：圖片在展示時，為了能夠提升圖片展示速度，優化頁面展示速度，商品圖片在上傳時通常會通過縮放，將圖片保存成多個不同的尺寸，以方便不同頁面進行調用。

6. 導入功能

電商平臺上的商品成千上萬，如果都通過常規的表單一個一個維護，維護人員就得被累死了(看一下一個電子產品有多少產品規格)，通常系統都會設計導入功能供維護人員使用。

在商品信息的導入功能里有兩個限制：

一是一次只能導入一個品類，因為不用品類的特殊屬性不一樣，沒有辦法合并在一起；

二是僅能導入基礎屬性和特殊屬性信息，銷售屬性信息不支持通過導入生成，因為銷售屬性需要通過屬性值組合成SKU信息，系統需要生成唯一ID， 內部邏輯比較復雜。

【#】后面為需要導入的特殊屬性列表。

上面介紹的內容，基本涵蓋了一個商品的核心信息，大家有需要的可以根據自己的實際業務場景再進行優化修改。

四、商品維護流程

最后我們再來看一下商品的維護流程。

在電商平臺上的個體商戶，由于自家SKU數量比較少，從錄入商品參數到商品拍照、上架一個人基本都能解決。

但是對于自營平臺過萬的SKU，這樣的方式顯然是不行的。大平臺對一個商品的維護需要多個部門協同合作來完成，基本流程如下：

1. 采購部：買手先維護好后端品類，為每個品類綁定關聯屬性，并設置好屬性輸入方式、搜索方式等基礎配置信息。
2. 采購部: ?買手從供應商獲取采購商品基本信息，并將商品基本信息導入系統中，并根據銷售屬性生成SKU。
3. 采購部：買手通過采購單采購商品，并協同倉庫一同將商品錄入倉庫完成商品采購，系統完成SKU同步庫存信息，買手完成日常銷售價格的維護。
4. 采購部：買手在系統提交商品圖像采集工單。
5. 圖像采集部：圖像采集部同事根據工單申請倉儲圖像采集調撥工單(將之前錄入的SKU每件調撥出來一件)。
6. 倉儲部：根據圖像采集調撥單，準備調撥商品。
7. 圖像采集部：圖像采集部同事和倉儲部進行交接出庫，拿到樣品、進行拍照、修圖，完成后再上傳到系統中。
8. 圖像采集部：拍照完成后，將商品再還回倉庫中。
9. 倉儲部：將商品重新放回倉庫中。
10. 采購部：買手檢測商品信息完善后，就可以進行日常上架銷售了。

以上四個步驟中，除了第三步采購入庫、設置價格會經常使用，其它的三步僅在商品第一次錄入系統的時候需要維護。

對于上述操作流程有人可能有疑問，通常不是運營在做產品銷售嗎，這里怎么是買手呢？

在電商企業中買手的工作范疇主要是維護商品信息、采購、維護銷售價格以及下上架；而運營人員主要負責構建活動、專題框架、活動和專題中的具體商品由買手來決定是否來參與，最終的利潤由雙方來分(運營和買手的薪資是和銷售額有關的)。

這個在后期的運營篇中會給大家繼續講解！

作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)

本文由 @Jack 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Pexels，基于CC0協議。