今天來給大家分享一些關(guān)于電商方面的問題，如何為我們的用戶搭建電商訂單系統(tǒng)？接下來給大家分析一下這個問題。

一個好的訂單系統(tǒng)一定要保證訂單狀態(tài)的靈活切換，以此覆蓋用戶網(wǎng)購的所有正逆向流程。

對于中小型創(chuàng)業(yè)公司，沒有特別強大的貨源、供應(yīng)鏈支持，接入頭部電商的API接口，與自有商城實現(xiàn)對接，是一個很好的選擇。

以自有電商平臺提供自營商品，第三方代發(fā)商品，同時與京東開普勒api接口對接提供京東商品為例，詳述訂單狀態(tài)流轉(zhuǎn)全過程。

用戶下單生成訂單

在用戶下單時，涉及到減庫存，有兩種方式：一種在用戶下單后，鎖庫存;一種在用戶支付后，減庫存。

京東采用的是下單后的24小時內(nèi)鎖庫存，天貓采用的是支付后才減庫存，兩種方式各有利弊。

第一種方式的好處是用戶體驗好，有一種顧客即時上帝的感覺，只要用戶在下單24小時內(nèi)付款，商戶將一直未用戶保留。缺點是對于緊俏稀缺商品，存在惡意侵占庫存的風險，通過對稀缺商品限定下單數(shù)量等方式可以盡量避免。

第二種方式好處是不存在侵占庫存，但需要給未付款用戶提示“商品緊俏，請及時付款，以防沒貨”，給用戶營造出一種緊張的氛圍，刺激用戶及時付款。缺點是用戶未及時下單造成商品缺貨，用戶體驗不佳，而且需要在支付時對商品是否缺貨做校驗。

支付訂單

因多個商城共用一個電商后臺等現(xiàn)實原因，無法在前后端同步實現(xiàn)拆單。訂單支付成功后的拆單功能暫時擱置，實際應(yīng)該按照不同倉庫進行拆分訂單。目前是只要訂單中一個包裹的物流狀態(tài)發(fā)生改變，整個訂單物流狀態(tài)同步改變。

缺點：給用戶展示的訂單狀態(tài)和訂單中每個包裹的實際物流狀態(tài)不一致。

如果包裹拆單，可以按照實際物流狀態(tài)展示，關(guān)于一筆訂單的運費如何展示有兩種方式：一是計入一個子訂單內(nèi)，二是平攤到每個子訂單上。

當當采用的是第一種展示方式，缺點是平臺或者商家承擔運費。對不包郵訂單(包括兩個包裹)，用戶如果拒收計入運費的包裹，當當自動原路退款，相當于用戶包郵買了其中一個包裹的商品。

訂單狀態(tài)流轉(zhuǎn)

由于商品類型不同(包括京東、自營、代發(fā)商品)，一個訂單下的物流狀態(tài)不同，如何兼容不同包裹的物流狀態(tài)，按照訂單狀態(tài)統(tǒng)一展示，需要產(chǎn)品經(jīng)理去規(guī)定狀態(tài)流轉(zhuǎn)規(guī)則。

對于京東商品，因為接入了京東開普勒api接口，京東會返回包裹狀態(tài)：待收貨、已收貨、已拒收狀態(tài)。

對于自營商品，包裹狀態(tài)包括：已發(fā)貨。

取消訂單

取消訂單包括兩種情況：待付款取消訂單和待發(fā)貨取消訂單。

待付款取消訂單，因為沒有實際給第三方付款，邏輯相對簡單。

待發(fā)貨取消訂單，本質(zhì)上是攔截訂單，但付款后第三方響應(yīng)迅速，所以在用戶付款后并不實際給第三方付款，訂單狀態(tài)實際暫停在待付款階段。

以上基本就是如何為用戶搭建電商訂單系統(tǒng)的全部流程，弄清楚這些流程，搭建一個簡單的訂單系統(tǒng)還是很輕松的，希望能對大家有所幫助。若有其他咨詢請聯(lián)系安菲云。