B2B電商開(kāi)放平臺(tái)API接口設(shè)計(jì)指南

13 評(píng)論 21603 瀏覽 167 收藏 18 分鐘

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

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

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

一、開(kāi)放平臺(tái)API接口的設(shè)計(jì)

1. 商品

商品方面的同步,主要是考慮到:

  1. 商品的上傳;
  2. 商品價(jià)格同步;
  3. 商品批號(hào)同步;
  4. 商品上下架同步。

1.1.1 商品的上傳

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

商品上傳過(guò)程中需要處理的問(wèn)題:

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

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

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

正常情況下,商品上傳之后不能馬上上架并出售,而是先要同步庫(kù)存之后通過(guò)調(diào)取批量上下架接口上架或手動(dòng)點(diǎ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à)格同步需要處理的問(wèn)題:

  1. 接口需要能滿足商品需要同時(shí)修改多種類型的價(jià)格,包括默認(rèn)單價(jià),建議零售價(jià),地區(qū)價(jià)/客戶等級(jí)價(jià)的需求;
  2. 對(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)同步需要處理的問(wèn)題:

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

1.1.4 商品上下架同步

商品上下架同步接口主要用來(lái)進(jìn)行批量的商品下架或下架的操作,尤其是新商品剛剛上傳的時(shí)候,商品處于待上架的狀態(tài),需要進(jìn)行批量的上下架;此外,如需同時(shí)上下架多個(gè)商品,通過(guò)接口操作會(huì)比在界面上一個(gè)個(gè)點(diǎn)擊的效率更高。

2. 庫(kù)存

庫(kù)存同步

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

庫(kù)存同步需要處理的問(wèn)題:

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

3. 客戶

商戶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客戶同步需要處理的問(wèn)題:

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

  1. 平臺(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訂單;
  2. 商戶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)操作的比較少。

4. 訂單

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

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

1.4.1 查詢訂單列表

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

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

1.4.2?物流信息同步

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

  1. 商戶ERP系統(tǒng)中的物流商與平臺(tái)方的物流商必須一一對(duì)應(yīng),才能進(jìn)行物流信息的傳遞和展示,所以平臺(tái)可以提供一份物流商編碼和物流商名稱給商戶ERP,ERP發(fā)貨時(shí)將對(duì)應(yīng)的物流商編碼及訂單號(hào)傳給平臺(tái)。
  2. 物流信息同步也代表著訂單肯定是已經(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)生以下問(wèn)題:

  1. 同一個(gè)商品可能購(gòu)買多個(gè),可能由于庫(kù)存的原因?qū)е虏糠稚唐啡必?,所以在發(fā)貨的時(shí)候,可能會(huì)少發(fā)某種商品或某種商品的一部分?jǐn)?shù)量;
  2. 商戶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)主要指訂單在ERP中處理環(huán)節(jié)的各個(gè)狀態(tài),訂單傳至ERP系統(tǒng)之后,可能需要進(jìn)行提單、分揀、出庫(kù)、配送等環(huán)節(jié),在客戶收到貨之后,物流公司也會(huì)反饋回簽收信息。

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

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

二、商家信息同步至平臺(tái)的渠道

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

  1. 通過(guò)平臺(tái)提供的API接口對(duì)ERP系統(tǒng)進(jìn)行開(kāi)發(fā),實(shí)現(xiàn)和平臺(tái)的對(duì)接,適用于有專業(yè)技術(shù)開(kāi)發(fā)能力的商家;
  2. 平臺(tái)統(tǒng)一開(kāi)發(fā)服務(wù)系統(tǒng),由平臺(tái)人員實(shí)施商家ERP與平臺(tái)的對(duì)接,適用于無(wú)專業(yè)的技術(shù)對(duì)接能力,有ERP系統(tǒng)且大批量信息不適合手工操作;
  3. 手動(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ì)接的替代辦法。

2.1 API接口對(duì)接

商家存在技術(shù)開(kāi)發(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)之間的信息流通。

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

主要的實(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ì)。

2.3 商家后臺(tái)手動(dòng)操作

商家后臺(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)更改等。

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

由于商家的商品、客戶、價(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ù)給覆蓋。

為了解決以上的問(wèn)題,我們需要根據(jù)不同的功能模塊分別做一個(gè)開(kāi)關(guān),即針對(duì)某個(gè)功能設(shè)置是否開(kāi)啟自動(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é)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 我也是電商平臺(tái)的產(chǎn)品經(jīng)理,可以加你聯(lián)系方式交流學(xué)習(xí)么,vx:li4033057

    來(lái)自浙江 回復(fù)
  2. 商品上傳時(shí),平臺(tái)的基礎(chǔ)商品指的是啥啊?平臺(tái)目錄么?

    回復(fù)
    1. 指標(biāo)品,對(duì)于平臺(tái)售賣的商品進(jìn)行標(biāo)準(zhǔn)化,不同的商家可以賣同一個(gè)標(biāo)品

      來(lái)自廣東 回復(fù)
  3. 為什么沒(méi)有提交訂單的接口?難道要時(shí)時(shí)查詢已付款的訂單列表?不是有一個(gè)單就同步過(guò)來(lái)一個(gè)單?

    來(lái)自浙江 回復(fù)
    1. 有訂單狀態(tài)回傳的接口

      來(lái)自廣東 回復(fù)
  4. 太棒了,下午正好要跟客戶去對(duì)接口,正愁呢,就看到了這個(gè)文章,可否加一個(gè)微信咱們沒(méi)事的時(shí)候溝通一下

    來(lái)自北京 回復(fù)
    1. 可以啊18908471270

      回復(fù)
  5. 文中的erp系統(tǒng)的平臺(tái)統(tǒng)一服務(wù)功能的接口,不需要在平臺(tái)設(shè)計(jì)一個(gè)接口模塊嗎?單獨(dú)放那些接口字段的展示之類的

    回復(fù)
    1. 需要的,弄成中間表或視圖

      回復(fù)
  6. 如果商家的erp系統(tǒng)是用的市面上別的提供商的產(chǎn)品,這樣我們的平臺(tái)也能夠通過(guò)如同文中說(shuō)的修改商家erp系統(tǒng)的什么邏輯獲取數(shù)據(jù)嗎?

    回復(fù)
    1. 可以的,但是需要先弄清楚對(duì)方ERP系統(tǒng)表結(jié)構(gòu)和相關(guān)功能邏輯

      回復(fù)
  7. 13076927381

    來(lái)自廣東 回復(fù)
  8. 可否加微,我最近正在做庫(kù)存同步項(xiàng)目

    來(lái)自廣東 回復(fù)