筆者所負責(zé)的產(chǎn)品是一個醫(yī)藥電商平臺，撮合采購商和供應(yīng)商在平臺上進行線上交易，其中采購商主要是藥店、診所、醫(yī)院；供應(yīng)商主要是各大醫(yī)藥公司經(jīng)銷商；本文主要先講解電商與商家之間信息同步及API接口設(shè)計的規(guī)范及需要注意的問題。

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

1. 開放平臺API接口的設(shè)計，主要是從功能需求的角度，設(shè)計滿足業(yè)務(wù)需求的接口及對應(yīng)的字段；
2. 平臺與商家之間信息的對接，對接的方法有哪些？對接過程中需要可能會遇到什么問題；
3. 同步開關(guān)及權(quán)限的設(shè)計，處理信息自動同步和手動設(shè)置之間的矛盾。

一、開放平臺API接口的設(shè)計

1. 商品

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

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

1.1.1 商品的上傳

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

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

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

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

1. 可以根據(jù)商品的條碼，批準(zhǔn)文號，規(guī)格，廠家等進行匹配，但是要求根據(jù)這些條件能完全確定這個商品和基礎(chǔ)商品是同一個商品；
2. 對于一些商品來說，沒有確定的規(guī)格供程序完成商品的匹配的時候，需要人工介入進行判斷，然后在上傳的時候直接附加上“基礎(chǔ)商品ID”，通過“基礎(chǔ)商品ID”直接進行關(guān)聯(lián)。

正常情況下，商品上傳之后不能馬上上架并出售，而是先要同步庫存之后通過調(diào)取批量上下架接口上架或手動點擊上架。

如果商品上傳之后如果需要直接可以上架出售，接口必須還包含商品銷售信息如：價格和庫存，所以商品上傳的接口必須包含默認單價和庫存，其中默認單價必填，庫存可以為空并默認為0（同時可以設(shè)置規(guī)則：庫存為0的商品不自動上架銷售而庫存不為0的商品自動上架銷售）。

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

1.1.2 修改商品價格

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

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

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

1. 接口需要能滿足商品需要同時修改多種類型的價格，包括默認單價，建議零售價，地區(qū)價/客戶等級價的需求；
2. 對于地區(qū)價或客戶等級價，需要在平臺中定義好規(guī)范的地區(qū)組或客戶組，同步價格的時候，接口中存在字段“地區(qū)組”或“客戶組”的ID來與平臺的商品價格進行匹配。

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

1.1.3 商品批號同步

同一個商品可能由于生產(chǎn)批次不同會存在不同批號的貨品，尤其是對于存在有效期的商品，商品的有效期是和批號是直接掛鉤的；商品的批號上傳至平臺之后，可以直接展示在商品詳情中，客戶能知道其購買商品有效期的情況，在生成訂單之后可以跟著訂單信息一起傳至商家ERP系統(tǒng)中，作為商家發(fā)貨的依據(jù)。

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

1. 接口需要傳的字段主要包括批號，生產(chǎn)日期和有效期；
2. 每次通過接口同步批號的時候，應(yīng)當(dāng)只同步正在出售的批號（可以根據(jù)庫存是否為0判斷），且每次全量更新，數(shù)據(jù)庫里面不能存在冗余批號數(shù)據(jù)；
3. 批號同步除了每次都全量更新之外，也可以選擇每次只更新最新的或庫存最大的批號。

1.1.4 商品上下架同步

商品上下架同步接口主要用來進行批量的商品下架或下架的操作，尤其是新商品剛剛上傳的時候，商品處于待上架的狀態(tài)，需要進行批量的上下架；此外，如需同時上下架多個商品，通過接口操作會比在界面上一個個點擊的效率更高。

2. 庫存

庫存同步

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

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

1. 同步時間間隔必須盡可能短且準(zhǔn)確；
2. 有些ERP系統(tǒng)庫存是和批號關(guān)聯(lián)的，需要匯總求和該商品相關(guān)批號的庫存。

3. 客戶

商戶ERP客戶同步

正常來說，商戶的ERP系統(tǒng)中保存的客戶是不需要傳給平臺，只需要訂單存在收貨人，收貨電話和送貨地址及客戶在下單時留的發(fā)票信息，即可完成發(fā)貨的操作。

但對于一些特殊產(chǎn)品和特殊行業(yè)來說，由于商業(yè)原因或行業(yè)規(guī)則需要（如醫(yī)藥B2B采購要求采購商有相關(guān)資質(zhì)證件），ERP系統(tǒng)中生成訂單時需要先存在ERP客戶信息，那么ERP客戶編號必須先給到平臺，然后與平臺的客戶進行匹配映射，在同步訂單需要同時把ERP客戶信息一起傳輸給ERP，商戶ERP根據(jù)ERP客戶信息生成新的ERP訂單。

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

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

1. 平臺生成訂單后，商戶看到訂單對應(yīng)的客戶資料之后，基于平臺的客戶資料補充ERP客戶編號，平臺將訂單信息同步至商戶ERP時順便將ERP客戶編號也一起傳過去，商戶ERP可根據(jù)這個ERP客戶編號生成ERP訂單；
2. 商戶ERP預(yù)先直接將ERP中所有的客戶全部同步至平臺，并與平臺客戶做匹配，訂單生成后若下單客戶存在ERP客戶編號，則該訂單直接同步至ERP系統(tǒng)生成ERP訂單，否則需要先在ERP系統(tǒng)中創(chuàng)建客戶資料并同步至平臺（ERP客戶資料和平臺客戶可基于營業(yè)執(zhí)照的統(tǒng)一信用代碼進行匹配）。

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

4. 訂單

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

1. 查詢訂單列表；
2. 同步物流信息；
3. 同步發(fā)貨信息；
4. 同步ERP訂單狀態(tài)。

1.4.1 查詢訂單列表

該接口用于商家ERP系統(tǒng)請求同步平臺已付款的訂單，查詢訂單列表接口需要處理的問題：

1. 接口需要支持根據(jù)同步狀態(tài)查詢訂單，查詢訂單成功后，平臺方需要將對應(yīng)的訂單同步狀態(tài)改為“已同步”，這樣可以保證每次查詢的時候至查詢“未同步”的訂單；另外，如需查詢已同步的訂單也可指定對應(yīng)的狀態(tài)進行查詢。
2. 查詢的方式需要支持按照條件查找，如：開始時間、結(jié)束時間、訂單狀態(tài)、同步狀態(tài)等，同時也需要支持按照訂單編號精確查詢。
3. 響應(yīng)的數(shù)據(jù)應(yīng)分為四部分：訂單基本信息；訂單金額信息；送貨信息；發(fā)票信息；訂單商品項信息。其中送貨信息和發(fā)票信息一般在商戶的ERP系統(tǒng)中已存在，但可能與平臺的信息不一致所以也需要一起返回給ERP系統(tǒng)。
4. 商品項信息可以包括發(fā)貨的批號，客戶將客戶在下單時看到的批號信息傳輸給商戶ERP，這樣能很大程度減少客戶退款率。

1.4.2?物流信息同步

訂單在商戶ERP系統(tǒng)發(fā)貨后，需傳遞對應(yīng)的物流信息給平臺，用于展示給客戶查看，物流信息同步接口需要處理的問題：

1. 商戶ERP系統(tǒng)中的物流商與平臺方的物流商必須一一對應(yīng)，才能進行物流信息的傳遞和展示，所以平臺可以提供一份物流商編碼和物流商名稱給商戶ERP，ERP發(fā)貨時將對應(yīng)的物流商編碼及訂單號傳給平臺。
2. 物流信息同步也代表著訂單肯定是已經(jīng)發(fā)貨了，如果不設(shè)計其他更改訂單狀態(tài)的接口的話，可以在ERP上傳物流信息的時候，平臺自動將訂單將訂單狀態(tài)改為“已發(fā)貨”。

1.4.3?發(fā)貨信息同步

對于B2B電商來說，在平臺產(chǎn)生的訂單傳到ERP系統(tǒng)的時候，可能產(chǎn)生以下問題：

1. 同一個商品可能購買多個，可能由于庫存的原因?qū)е虏糠稚唐啡必?，所以在發(fā)貨的時候，可能會少發(fā)某種商品或某種商品的一部分數(shù)量；
2. 商戶ERP中商品由于不同批次的原因，生產(chǎn)日期和有效期可能會不一致，用戶付款成功后，需要看到發(fā)貨信息中商品批號對應(yīng)的有效期的情況，所以商戶ERP中需要在發(fā)貨時傳遞相關(guān)信息到平臺。

發(fā)貨信息同步接口主要是在ERP系統(tǒng)訂單出庫之后，將出庫的商品明細傳至平臺，需要傳遞的字段包括：ERP商品編號、發(fā)貨數(shù)量、批號、生產(chǎn)日期、有效期。

1.4.4 同步ERP訂單狀態(tài)

ERP訂單狀態(tài)主要指訂單在ERP中處理環(huán)節(jié)的各個狀態(tài)，訂單傳至ERP系統(tǒng)之后，可能需要進行提單、分揀、出庫、配送等環(huán)節(jié)，在客戶收到貨之后，物流公司也會反饋回簽收信息。

ERP訂單狀態(tài)同步至平臺后有以下兩方面作用：

1. 平臺可根據(jù)ERP訂單狀態(tài)單獨生成物流信息，展示給客戶，如：ERP訂單狀態(tài)變?yōu)椤耙烟釂?#8221;則物流信息新增一條：訂單已處理，商家揀貨中。
2. ?特定的ERP訂單狀態(tài)可以與平臺訂單狀態(tài)關(guān)聯(lián)起來，如：ERP訂單狀態(tài)變?yōu)?#8221;已簽收”，平臺接收到該條ERP訂單狀態(tài)的信息之后，可以將訂單狀態(tài)改為“交易完成”。

二、商家信息同步至平臺的渠道

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

1. 通過平臺提供的API接口對ERP系統(tǒng)進行開發(fā)，實現(xiàn)和平臺的對接，適用于有專業(yè)技術(shù)開發(fā)能力的商家；
2. 平臺統(tǒng)一開發(fā)服務(wù)系統(tǒng)，由平臺人員實施商家ERP與平臺的對接，適用于無專業(yè)的技術(shù)對接能力，有ERP系統(tǒng)且大批量信息不適合手工操作；
3. 手動在平臺提供的商家操作后臺，通過導(dǎo)入excel或直接手動操作的方式，直接在平臺上創(chuàng)建或修改信息，適用于無專業(yè)的技術(shù)對接能力，商品SKU數(shù)和訂單數(shù)比較少的商家，同時也可作為技術(shù)對接的替代辦法。

2.1 API接口對接

商家存在技術(shù)開發(fā)能力的情況下，按照平臺提供的接口調(diào)用說明文檔，進行業(yè)務(wù)系統(tǒng)的設(shè)計與修改，通過直接請求調(diào)用API接口并獲取返回數(shù)據(jù)，實現(xiàn)商家與平臺之間的信息流通。

2.2 平臺統(tǒng)一服務(wù)系統(tǒng)

主要的實現(xiàn)方式為：平臺技術(shù)人員對商家ERP系統(tǒng)業(yè)務(wù)邏輯進行修改，并在商家的ERP系統(tǒng)上單獨創(chuàng)建符合平臺接口功能的視圖，存儲過程或中間表，調(diào)用平臺的接口傳遞視圖，存儲過程中的信息給平臺，并將平臺接口的響應(yīng)數(shù)據(jù)存儲在中間表中。

由于不同的ERP系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)，業(yè)務(wù)邏輯會有一定的差異，所以平臺需要研究不同客戶的ERP系統(tǒng)，進行統(tǒng)一的設(shè)計。

2.3 商家后臺手動操作

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

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

三、同步開關(guān)及權(quán)限的設(shè)計

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

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

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

本文由 @?不橈 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。