最近在對接電商供應鏈，說說開放平臺API介面

B2B電商開放平臺的設計需要從以下幾面去思考：

1. 開放平臺API介面的設計，主要是從功能需求的角度，設計滿足業務需求的介面及對應的欄位；
2. 平臺與商家之間資訊的對接，對接的方法有哪些？對接過程中需要可能會遇到什麼問題；
3. 同步開關及許可權的設計，處理資訊自動同步和手動設定之間的矛盾。

一、開放平臺API介面的設計

1. 商品

商品方面的同步，主要是考慮到：

1. 商品的上傳；
2. 商品價格同步；
3. 商品批號同步；
4. 商品上下架同步。

1.1.1 商品的上傳

商品上傳同步的目的在於把商家需要出售的商品同步到平臺，平臺把商家上傳的商品顯示在前端頁面，下單成功之後，商品明細資訊跟著訂單資訊一起傳給商家。

商品上傳過程中需要處理的問題：

• 商品上傳的資訊需要包含“ERP商品ID”作為該商品的唯 一標識；
• 很多平臺都會存在基礎商品，例如藥品，食品，水果等；如果出售的標的是可以明確定義的，商家只是作為一個經銷商存在的情況下，平臺可以統一定義基礎商品；
• 在存在基礎商品的情況下，商家的上傳的商品資訊需要與平臺的基礎商品匹配生成出售的SKU。

匹配的方法可以分為兩種：

1. 可以根據商品的條碼，批准文號，規格，廠家等進行匹配，但是要求根據這些條件能完全確定這個商品和基礎商品是同一個商品；
2. 對於一些商品來說，沒有確定的規格供程式完成商品的匹配的時候，需要人工介入進行判斷，然後在上傳的時候直接附加上“基礎商品ID”，透過“基礎商品ID”直接進行關聯。

正常情況下，商品上傳之後不能馬上上架並出售，而是先要同步庫存之後透過調取批次上下架介面上架或手動點選上架。

如果商品上傳之後如果需要直接可以上架出售，介面必須還包含商品銷售資訊如：價格和庫存，所以商品上傳的介面必須包含預設單價和庫存，其中預設單價必填，庫存可以為空並預設為0（同時可以設定規則：庫存為0的商品不自動上架銷售而庫存不為0的商品自動上架銷售）。

平臺不存在基礎商品的時候，不提倡商品直接上架，而是需要稽核，因為可能商家上傳的商品是平臺不允許銷售的。

1.1.2 修改商品價格

商家在平臺出售的商品的價格並不是固定的，對於SKU比較多的商家而言，商品的價格往往是在ERP直接進行修改，然後同步到各個第三方平臺，所以價格同步是不可或缺而且對於實時性，準確性的要求比較高。

另一方面，商品的銷售價格往往由於成本的因素或市場的側重點不同，往往需要針對不同的地區，客戶型別設定不同的價格，而這些設定同樣往往是在ERP中設定好的，同樣需要同步到平臺。

商品價格同步需要處理的問題：

1. 介面需要能滿足商品需要同時修改多種型別的價格，包括預設單價，建議零售價，地區價/客戶等級價的需求；
2. 對於地區價或客戶等級價，需要在平臺中定義好規範的地區組或客戶組，同步價格的時候，介面中存在欄位“地區組”或“客戶組”的ID來與平臺的商品價格進行匹配。

地區組的概念：由於行政區劃的單位比較多，所以不可能為每一個行政區設定一個價格，通常由於不同商品對於地區價的定義都是一樣的，如在A,B兩個商品在廣東，廣西的定價一樣而不同於其他地區，那麼就可以將廣東和廣西設定為一個地區組；商品就可以針對每個地區定義價格了

1.1.3 商品批號同步

同一個商品可能由於生產批次不同會存在不同批號的貨品，尤其是對於存在有效期的商品，商品的有效期是和批號是直接掛鉤的；商品的批號上傳至平臺之後，可以直接展示在商品詳情中，客戶能知道其購買商品有效期的情況，在生成訂單之後可以跟著訂單資訊一起傳至商家ERP系統中，作為商家發貨的依據。

商品批號同步需要處理的問題：

1. 介面需要傳的欄位主要包括批號，生產日期和有效期；
2. 每次透過介面同步批號的時候，應當只同步正在出售的批號（可以根據庫存是否為0判斷），且每次全量更新，資料庫裡面不能存在冗餘批號資料；
3. 批號同步除了每次都全量更新之外，也可以選擇每次只更新最新的或庫存最大的批號。

1.1.4 商品上下架同步

商品上下架同步介面主要用來進行批次的商品下架或下架的操作，尤其是新商品剛剛上傳的時候，商品處於待上架的狀態，需要進行批次的上下架；此外，如需同時上下架多個商品，透過介面操作會比在介面上一個個點選的效率更高。

2. 庫存

庫存同步

庫存同步是使用最頻繁且實時性，準確性要求最高的介面；庫存同步的不及時或不準確可能會造成商品負賣或客戶無法下單購買。

庫存同步需要處理的問題：

1. 同步時間間隔必須儘可能短且準確；
2. 有些ERP系統庫存是和批號關聯的，需要彙總求和該商品相關批號的庫存。

3. 客戶

商戶ERP客戶同步

正常來說，商戶的ERP系統中儲存的客戶是不需要傳給平臺，只需要訂單存在收貨人，收貨電話和送貨地址及客戶在下單時留的發票資訊，即可完成發貨的操作。

但對於一些特殊產品和特殊行業來說，由於商業原因或行業規則需要（如醫藥B2B採購要求採購商有相關資質證件），ERP系統中生成訂單時需要先存在ERP客戶資訊，那麼ERP客戶編號必須先給到平臺，然後與平臺的客戶進行匹配對映，在同步訂單需要同時把ERP客戶資訊一起傳輸給ERP，商戶ERP根據ERP客戶資訊生成新的ERP訂單。

商戶ERP客戶同步需要處理的問題：

ERP客戶同步至平臺有多種方案：

1. 平臺生成訂單後，商戶看到訂單對應的客戶資料之後，基於平臺的客戶資料補充ERP客戶編號，平臺將訂單資訊同步至商戶ERP時順便將ERP客戶編號也一起傳過去，商戶ERP可根據這個ERP客戶編號生成ERP訂單；
2. 商戶ERP預先直接將ERP中所有的客戶全部同步至平臺，並與平臺客戶做匹配，訂單生成後若下單客戶存在ERP客戶編號，則該訂單直接同步至ERP系統生成ERP訂單，否則需要先在ERP系統中建立客戶資料並同步至平臺（ERP客戶資料和平臺客戶可基於營業執照的統一信用程式碼進行匹配）。

方案1可以更好地保護商戶的客戶資料，保證不外洩；方案2會比較方便，需要手動操作的比較少。

4. 訂單

訂單方面的同步，包含以下幾個方面：

1. 查詢訂單列表；
2. 同步物流資訊；
3. 同步發貨資訊；
4. 同步ERP訂單狀態。

1.4.1 查詢訂單列表

該介面用於商家ERP系統請求同步平臺已付款的訂單，查詢訂單列表介面需要處理的問題：

1. 介面需要支援根據同步狀態查詢訂單，查詢訂單成功後，平臺方需要將對應的訂單同步狀態改為“已同步”，這樣可以保證每次查詢的時候至查詢“未同步”的訂單；另外，如需查詢已同步的訂單也可指定對應的狀態進行查詢。
2. 查詢的方式需要支援按照條件查詢，如：開始時間、結束時間、訂單狀態、同步狀態等，同時也需要支援按照訂單編號精確查詢。
3. 響應的資料應分為四部分：訂單基本資訊；訂單金額資訊；送貨資訊；發票資訊；訂單商品項資訊。其中送貨資訊和發票資訊一般在商戶的ERP系統中已存在，但可能與平臺的資訊不一致所以也需要一起返回給ERP系統。
4. 商品項資訊可以包括髮貨的批號，客戶將客戶在下單時看到的批號資訊傳輸給商戶ERP，這樣能很大程度減少客戶退款率。

1.4.2 物流資訊同步

訂單在商戶ERP系統發貨後，需傳遞對應的物流資訊給平臺，用於展示給客戶檢視，物流資訊同步介面需要處理的問題：

1. 商戶ERP系統中的物流商與平臺方的物流商必須一一對應，才能進行物流資訊的傳遞和展示，所以平臺可以提供一份物流商編碼和物流商名稱給商戶ERP，ERP發貨時將對應的物流商編碼及訂單號傳給平臺。
2. 物流資訊同步也代表著訂單肯定是已經發貨了，如果不設計其他更改訂單狀態的介面的話，可以在ERP上傳物流資訊的時候，平臺自動將訂單將訂單狀態改為“已發貨”。

1.4.3 發貨資訊同步

對於B2B電商來說，在平臺產生的訂單傳到ERP系統的時候，可能產生以下問題：

1. 同一個商品可能購買多個，可能由於庫存的原因導致部分商品缺貨，所以在發貨的時候，可能會少發某種商品或某種商品的一部分數量；
2. 商戶ERP中商品由於不同批次的原因，生產日期和有效期可能會不一致，使用者付款成功後，需要看到發貨資訊中商品批號對應的有效期的情況，所以商戶ERP中需要在發貨時傳遞相關資訊到平臺。

發貨資訊同步介面主要是在ERP系統訂單出庫之後，將出庫的商品明細傳至平臺，需要傳遞的欄位包括：ERP商品編號、發貨數量、批號、生產日期、有效期。

1.4.4 同步ERP訂單狀態

ERP訂單狀態主要指訂單在ERP中處理環節的各個狀態，訂單傳至ERP系統之後，可能需要進行提單、分揀、出庫、配送等環節，在客戶收到貨之後，物流公司也會反饋回簽收資訊。

ERP訂單狀態同步至平臺後有以下兩方面作用：

1. 平臺可根據ERP訂單狀態單獨生成物流資訊，展示給客戶，如：ERP訂單狀態變為“已提單”則物流資訊新增一條：訂單已處理，商家揀貨中。
2.  特定的ERP訂單狀態可以與平臺訂單狀態關聯起來，如：ERP訂單狀態變為”已簽收”，平臺接收到該條ERP訂單狀態的資訊之後，可以將訂單狀態改為“交易完成”。

二、商家資訊同步至平臺的渠道

按照商家的技術能力，可以為商家提供多種對接方案：

1. 透過平臺提供的API介面對ERP系統進行開發，實現和平臺的對接，適用於有專業技術開發能力的商家；
2. 平臺統一開發服務系統，由平臺人員實施商家ERP與平臺的對接，適用於無專業的技術對接能力，有ERP系統且大批次資訊不適合手工操作；
3. 手動在平臺提供的商家操作後臺，透過匯入excel或直接手動操作的方式，直接在平臺上建立或修改資訊，適用於無專業的技術對接能力，商品SKU數和訂單數比較少的商家，同時也可作為技術對接的替代 辦法。

2.1

商家存在技術開發能力的情況下，按照平臺提供的介面呼叫說明文件，進行業務系統的設計與修改，透過直接請求呼叫API介面並獲取返回資料，實現商家與平臺之間的資訊流通。

2.2 平臺統一服務系統

主要的實現方式為：平臺技術人員對商家ERP系統業務邏輯進行修改，並在商家的ERP系統上單獨建立符合平臺介面功能的檢視，儲存過程或中間表，呼叫平臺的介面傳遞檢視，儲存過程中的資訊給平臺，並將平臺介面的響應資料儲存在中間表中。

由於不同的ERP系統的資料庫結構，業務邏輯會有一定的差異，所以平臺需要研究不同客戶的ERP系統，進行統一的設計。

2.3 商家後臺手動操作

商家後臺手動操作不僅僅適用無法進行系統對接的客戶，同時也是作為介面同步出故障時的臨時替代 辦法，所以手動操作的功能需要滿足系統對接的所有需求。

手動操作的功能包括：建立新商品（批次上傳），商品的上下架，商品價格修改，商品庫存修改，ERP客戶編碼上傳，訂單批次下載，訂單狀態更改等。

三、同步開關及許可權的設計

由於商家的商品、客戶、價格、庫存、訂單等資訊都有手動同步和自動同步兩種模式，當兩種模式同時存在並進行的同時，可能會導致資料比較亂，而且不方便，如：由於庫存不足，頁面無法進行下單的操作。而此時商家需要進行負賣，那邊這個時候需要手動修改庫存，但是修改完之後，庫存很快會被同步系統傳過來的新庫存資料給覆蓋。

為了解決以上的問題，我們需要根據不同的功能模組分別做一個開關，即針對某個功能設定是否開啟自動同步。如剛剛那個例子，如果此時該商品需要臨時修改庫存並維持一段時間（保證客戶有足夠的時間下單付款），可以暫時關閉庫存同步服務。

此外，許可權的設計可以設計得更細，即針對某個商品設定是否自動同步庫存，這樣的話，在關閉該商品庫存同步功能的時候，不會影響其他商品庫存的同步