筆者所負責的產品是一個醫藥電商平臺，撮合采購商和供應商在平臺上進行線上交易，其中采購商主要是藥店、診所、醫院；供應商主要是各大醫藥公司經銷商；本文主要先講解電商與商家之間信息同步及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接口對接

商家存在技術開發能力的情況下，按照平臺提供的接口調用說明文檔，進行業務系統的設計與修改，通過直接請求調用API接口并獲取返回數據，實現商家與平臺之間的信息流通。

2.2 平臺統一服務系統

主要的實現方式為：平臺技術人員對商家ERP系統業務邏輯進行修改，并在商家的ERP系統上單獨創建符合平臺接口功能的視圖，存儲過程或中間表，調用平臺的接口傳遞視圖，存儲過程中的信息給平臺，并將平臺接口的響應數據存儲在中間表中。

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

2.3 商家后臺手動操作

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

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

三、同步開關及權限的設計

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

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

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

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

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