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

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

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

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

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

1.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)之間的信息流通。

1.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)需要研究不同客戶(hù)的ERP系統(tǒng)，進(jìn)行統(tǒng)一的設(shè)計(jì)。

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

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

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

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

1. 開(kāi)放平臺(tái)API接口的設(shè)計(jì)，主要是從功能需求的角度，設(shè)計(jì)滿(mǎn)足業(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)銷(xiāo)商存在的情況下，平臺(tái)可以統(tǒng)一定義基礎(chǔ)商品；

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

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

1. 可以根據(jù)商品的條碼，批準(zhǔn)文號(hào)，規(guī)格，廠(chǎng)家等進(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)擊上架。

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

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

1.1.2 修改商品價(jià)格

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

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

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

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

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

地區(qū)組的概念：由于行政區(qū)劃的單位比較多，所以不可能為每一個(gè)行政區(qū)設(shè)置一個(gè)價(jià)格，通常由于不同商品對(duì)于地區(qū)價(jià)的定義都是一樣的，如在A(yíng),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)之后，可以直接展示在商品詳情中，客戶(hù)能知道其購(gòu)買(mǎi)商品有效期的情況，在生成訂單之后可以跟著訂單信息一起傳至商家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ù)賣(mài)或客戶(hù)無(wú)法下單購(gòu)買(mǎi)。

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

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

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

3. 客戶(hù)

商戶(hù)ERP客戶(hù)同步

正常來(lái)說(shuō)，商戶(hù)的ERP系統(tǒng)中保存的客戶(hù)是不需要傳給平臺(tái)，只需要訂單存在收貨人，收貨電話(huà)和送貨地址及客戶(hù)在下單時(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客戶(hù)信息，那么ERP客戶(hù)編號(hào)必須先給到平臺(tái)，然后與平臺(tái)的客戶(hù)進(jìn)行匹配映射，在同步訂單需要同時(shí)把ERP客戶(hù)信息一起傳輸給ERP，商戶(hù)ERP根據(jù)ERP客戶(hù)信息生成新的ERP訂單。

商戶(hù)ERP客戶(hù)同步需要處理的問(wèn)題：

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

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

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

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

4. 訂單

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

1. 查詢(xún)訂單列表；

2. 同步物流信息；

3. 同步發(fā)貨信息；

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

1.4.1 查詢(xún)訂單列表

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

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

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

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

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

1.4.2?物流信息同步

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

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

2. 物流信息同步也代表著訂單肯定是已經(jīng)發(fā)貨了，如果不設(shè)計(jì)其他更改訂單狀態(tài)的接口的話(huà)，可以在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)買(mǎi)多個(gè)，可能由于庫(kù)存的原因?qū)е虏糠稚唐啡必?，所以在發(fā)貨的時(shí)候，可能會(huì)少發(fā)某種商品或某種商品的一部分?jǐn)?shù)量；

2. 商戶(hù)ERP中商品由于不同批次的原因，生產(chǎn)日期和有效期可能會(huì)不一致，用戶(hù)付款成功后，需要看到發(fā)貨信息中商品批號(hào)對(duì)應(yīng)的有效期的情況，所以商戶(hù)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é)，在客戶(hù)收到貨之后，物流公司也會(huì)反饋回簽收信息。

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

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

2. ?特定的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)改為“交易完成”。

?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-739325.html

到了這里，關(guān)于電商API接口對(duì)接電子商務(wù)平臺(tái)實(shí)現(xiàn)電商供應(yīng)鏈一鍵對(duì)接的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！