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

開放平臺(tái)API接口的設(shè)計(jì)，主要是從功能需求的角度，設(shè)計(jì)滿足業(yè)務(wù)需求的接口及對(duì)應(yīng)的字段；

平臺(tái)與商家之間信息的對(duì)接，對(duì)接的方法有哪些？對(duì)接過(guò)程中需要可能會(huì)遇到什么問題；

同步開關(guān)及權(quán)限的設(shè)計(jì)，處理信息自動(dòng)同步和手動(dòng)設(shè)置之間的矛盾。

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

商品的上傳；

商品價(jià)格同步；

商品批號(hào)同步；

商品上下架同步。

1.1.1商品的上傳

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

商品上傳過(guò)程中需要處理的問題：

商品上傳的信息需要包含“ERP商品ID”作為該商品的唯一標(biāo)識(shí)；

很多平臺(tái)都會(huì)存在基礎(chǔ)商品，例如藥品，食品，水果等；如果出售的標(biāo)的是可以明確定義的，商家只是作為一個(gè)經(jīng)銷商存在的情況下，平臺(tái)可以統(tǒng)一定義基礎(chǔ)商品；

在存在基礎(chǔ)商品的情況下，商家的上傳的商品信息需要與平臺(tái)的基礎(chǔ)商品匹配生成出售的SKU。

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

可以根據(jù)商品的條碼，批準(zhǔn)文號(hào)，規(guī)格，廠家等進(jìn)行匹配，但是要求根據(jù)這些條件能完全確定這個(gè)商品和基礎(chǔ)商品是同一個(gè)商品；

對(duì)于一些商品來(lái)說(shuō)，沒有確定的規(guī)格供程序完成商品的匹配的時(shí)候，需要人工介入進(jìn)行判斷，然后在上傳的時(shí)候直接附加上“基礎(chǔ)商品ID”，通過(guò)“基礎(chǔ)商品ID”直接進(jìn)行關(guān)聯(lián)。

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

平臺(tái)不存在基礎(chǔ)商品的時(shí)候，不提倡商品直接上架，而是需要審核，因?yàn)榭赡苌碳疑蟼鞯纳唐肥瞧脚_(tái)不允許銷售的。

1.1.2修改商品價(jià)格

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

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

商品價(jià)格同步需要處理的問題：

接口需要能滿足商品需要同時(shí)修改多種類型的價(jià)格，包括默認(rèn)單價(jià)，建議零售價(jià)，地區(qū)價(jià)/客戶等級(jí)價(jià)的需求；

對(duì)于地區(qū)價(jià)或客戶等級(jí)價(jià)，需要在平臺(tái)中定義好規(guī)范的地區(qū)組或客戶組，同步價(jià)格的時(shí)候，接口中存在字段“地區(qū)組”或“客戶組”的ID來(lái)與平臺(tái)的商品價(jià)格進(jìn)行匹配。

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

1.1.3商品批號(hào)同步

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

商品批號(hào)同步需要處理的問題：

接口需要傳的字段主要包括批號(hào)，生產(chǎn)日期和有效期；

每次通過(guò)接口同步批號(hào)的時(shí)候，應(yīng)當(dāng)只同步正在出售的批號(hào)（可以根據(jù)庫(kù)存是否為0判斷），且每次全量更新，數(shù)據(jù)庫(kù)里面不能存在冗余批號(hào)數(shù)據(jù)；

批號(hào)同步除了每次都全量更新之外，也可以選擇每次只更新最新的或庫(kù)存最大的批號(hào)。

1.1.4商品上下架同步

庫(kù)存同步

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

庫(kù)存同步需要處理的問題：

同步時(shí)間間隔必須盡可能短且準(zhǔn)確；

有些ERP系統(tǒng)庫(kù)存是和批號(hào)關(guān)聯(lián)的，需要匯總求和該商品相關(guān)批號(hào)的庫(kù)存。

商戶ERP客戶同步

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

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

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

ERP客戶同步至平臺(tái)有多種方案：

平臺(tái)生成訂單后，商戶看到訂單對(duì)應(yīng)的客戶資料之后，基于平臺(tái)的客戶資料補(bǔ)充ERP客戶編號(hào)，平臺(tái)將訂單信息同步至商戶ERP時(shí)順便將ERP客戶編號(hào)也一起傳過(guò)去，商戶ERP可根據(jù)這個(gè)ERP客戶編號(hào)生成ERP訂單；

商戶ERP預(yù)先直接將ERP中所有的客戶全部同步至平臺(tái)，并與平臺(tái)客戶做匹配，訂單生成后若下單客戶存在ERP客戶編號(hào)，則該訂單直接同步至ERP系統(tǒng)生成ERP訂單，否則需要先在ERP系統(tǒng)中創(chuàng)建客戶資料并同步至平臺(tái)（ERP客戶資料和平臺(tái)客戶可基于營(yíng)業(yè)執(zhí)照的統(tǒng)一信用代碼進(jìn)行匹配）。

方案1可以更好地保護(hù)商戶的客戶資料，保證不外泄；方案2會(huì)比較方便，需要手動(dòng)操作的比較少。

訂單方面的同步，包含以下幾個(gè)方面：

查詢訂單列表；

同步物流信息；

同步發(fā)貨信息；

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

1.4.1查詢訂單列表

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

接口需要支持根據(jù)同步狀態(tài)查詢訂單，查詢訂單成功后，平臺(tái)方需要將對(duì)應(yīng)的訂單同步狀態(tài)改為“已同步”，這樣可以保證每次查詢的時(shí)候至查詢“未同步”的訂單；另外，如需查詢已同步的訂單也可指定對(duì)應(yīng)的狀態(tài)進(jìn)行查詢。

查詢的方式需要支持按照條件查找，如：開始時(shí)間、結(jié)束時(shí)間、訂單狀態(tài)、同步狀態(tài)等，同時(shí)也需要支持按照訂單編號(hào)精確查詢。

響應(yīng)的數(shù)據(jù)應(yīng)分為四部分：訂單基本信息；訂單金額信息；送貨信息；發(fā)票信息；訂單商品項(xiàng)信息。其中送貨信息和發(fā)票信息一般在商戶的ERP系統(tǒng)中已存在，但可能與平臺(tái)的信息不一致所以也需要一起返回給ERP系統(tǒng)。

商品項(xiàng)信息可以包括發(fā)貨的批號(hào)，客戶將客戶在下單時(shí)看到的批號(hào)信息傳輸給商戶ERP，這樣能很大程度減少客戶退款率。

1.4.2物流信息同步

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

商戶ERP系統(tǒng)中的物流商與平臺(tái)方的物流商必須一一對(duì)應(yīng)，才能進(jìn)行物流信息的傳遞和展示，所以平臺(tái)可以提供一份物流商編碼和物流商名稱給商戶ERP，ERP發(fā)貨時(shí)將對(duì)應(yīng)的物流商編碼及訂單號(hào)傳給平臺(tái)。

物流信息同步也代表著訂單肯定是已經(jīng)發(fā)貨了，如果不設(shè)計(jì)其他更改訂單狀態(tài)的接口的話，可以在ERP上傳物流信息的時(shí)候，平臺(tái)自動(dòng)將訂單將訂單狀態(tài)改為“已發(fā)貨”。

1.4.3發(fā)貨信息同步

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

同一個(gè)商品可能購(gòu)買多個(gè)，可能由于庫(kù)存的原因?qū)е虏糠稚唐啡必洠栽诎l(fā)貨的時(shí)候，可能會(huì)少發(fā)某種商品或某種商品的一部分?jǐn)?shù)量；

商戶ERP中商品由于不同批次的原因，生產(chǎn)日期和有效期可能會(huì)不一致，用戶付款成功后，需要看到發(fā)貨信息中商品批號(hào)對(duì)應(yīng)的有效期的情況，所以商戶ERP中需要在發(fā)貨時(shí)傳遞相關(guān)信息到平臺(tái)。

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

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

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

平臺(tái)可根據(jù)ERP訂單狀態(tài)單獨(dú)生成物流信息，展示給客戶，如：ERP訂單狀態(tài)變?yōu)椤耙烟釂巍眲t物流信息新增一條：訂單已處理，商家揀貨中。

特定的ERP訂單狀態(tài)可以與平臺(tái)訂單狀態(tài)關(guān)聯(lián)起來(lái)，如：ERP訂單狀態(tài)變?yōu)椤币押炇铡?，平臺(tái)接收到該條ERP訂單狀態(tài)的信息之后，可以將訂單狀態(tài)改為“交易完成”。

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

通過(guò)平臺(tái)提供的API接口對(duì)ERP系統(tǒng)進(jìn)行開發(fā)，實(shí)現(xiàn)和平臺(tái)的對(duì)接，適用于有專業(yè)技術(shù)開發(fā)能力的商家；

平臺(tái)統(tǒng)一開發(fā)服務(wù)系統(tǒng)，由平臺(tái)人員實(shí)施商家ERP與平臺(tái)的對(duì)接，適用于無(wú)專業(yè)的技術(shù)對(duì)接能力，有ERP系統(tǒng)且大批量信息不適合手工操作；

手動(dòng)在平臺(tái)提供的商家操作后臺(tái)，通過(guò)導(dǎo)入excel或直接手動(dòng)操作的方式，直接在平臺(tái)上創(chuàng)建或修改信息，適用于無(wú)專業(yè)的技術(shù)對(duì)接能力，商品SKU數(shù)和訂單數(shù)比較少的商家，同時(shí)也可作為技術(shù)對(duì)接的替代辦法。

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

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

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

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

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

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

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

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

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

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