1、導語：訂單中心是很多 B 端平臺都不可缺少的一個模塊，本文作者結合自己多年的 B 端產(chǎn)品項目工作經(jīng)歷，將自身的平臺建設經(jīng)驗與反思進行總結，希望可以與大家一起分享交流。訂單中心是多數(shù)B 端平臺都會涉及的一個模塊，本質上為單據(jù)管理，而銷售訂單是單據(jù)管理內的一個類目，其分析邏輯可拓展到其他類目，如訂貨單、意向單等。筆者之所以選擇訂單中心作為第一篇總結，也是由于訂單中心業(yè)務實際上牽涉到平臺內多方業(yè)務人員參與，如銷售、市場、庫管、財務、物流團隊、商家甚至領導團隊，具有更廣的普適性與討論價值。從訂單業(yè)務層面上，本人將訂單數(shù)據(jù)流轉過程總結為四個階段，分別是訂單創(chuàng)建階段、訂單支付階段、訂單完成階段和訂單售后階

2、段，這四個階段將串聯(lián)起訂單業(yè)務的整個生命周期，涵蓋商品中心、營銷中心、庫存中心、財務中心和物流中心五個業(yè)務模塊。首先是訂單創(chuàng)建階段，從用戶開始進入平臺購物界面開始，訂單業(yè)務便開始了。商品展示界面通過商品中心和營銷中心拉取信息，并將信息運算結合后展現(xiàn)到用戶眼前，供用戶挑選。用戶在選中商品加入購物車后，圖中有一步校驗商品庫存是否充足的邏輯，該邏輯目前在市面上存在多種缺貨處理方式，如京東商城是在用戶進入界面上便提示用戶已缺貨，禁止用戶加入購物車，而淘寶/天貓商城是提示無貨后，依然支持用戶加入購物車，本人則更偏向于后者，因為京東商城在缺貨商品無法加入購物車的情況下，用戶想要保留下次快速找到商品的途徑，

3、大部分都是通過收藏商品來實現(xiàn)。而實際情況下，大部分用戶對購物車的關注度普遍高于收藏夾，這也就相應減少了缺貨商品后續(xù)的曝光頻率。如果用戶可將缺貨商品加入購物車，那么用戶下次看到商品到貨，即可直接在購物車界面發(fā)起購買操作，而不需要像收藏夾一樣，進入商品詳情頁發(fā)起購買，這也可以減少操作環(huán)節(jié)，增加成交幾率。用戶發(fā)起支付后，訂單中心將根據(jù)最新的商品信息和營銷信息，計算實際支付價格后生成未支付訂單，有些朋友可能疑惑訂單為何還要區(qū)分未支付和已支付兩種狀態(tài)，而不是在支付成功后直接創(chuàng)建已支付訂單。我的理解是這樣的，首先是用戶發(fā)起支付動作后，到支付成功存在時間間隔，用戶可能在這個間隔內完成支付，也可能在這個間隔內

4、由于各種原因（卡機、接電話、余額不足等）退出支付界面導致支付失敗。而此時為了讓用戶在支付中斷后可以找到原商品進行支付，則需要保留一條未支付的訂單。這個時候有的朋友可能又會疑惑，為何用戶不直接重新購買商品呢？我認為主要原因是優(yōu)惠，優(yōu)惠一般來源于平臺、商家或商品的促銷策略，且該策略具備時效性。用戶在挑選商品時可能由于優(yōu)惠而下單，如果支付失敗，那么用戶下次找到商品支付，則可能面臨促銷失效而支付價格提升的情況，用戶將大概率不再繼續(xù)購買該商品，如果支付失敗為平臺責任，甚至會導致用戶對平臺的體驗感直線下降。另外，在下單到支付的時間間隔中，用戶都有可能面臨促銷策略已失效的情況，若等到支付時再計算優(yōu)惠生成支付

5、訂單，將可能導致用戶支付金額與下單金額不匹配的情況，最典型的便是用戶晚上12點前下單， 12點后支付的場景。講完未支付訂單，這里將來到訂單創(chuàng)建階段的最后一個業(yè)務環(huán)節(jié)-鎖定庫存。鎖定庫存的概念是，商品的物理庫存數(shù)量不變，但該庫存數(shù)量已被鎖定為不可變更移動的狀態(tài)。通俗的說就是，這個庫存被預定了，不能賣給別人。他 的作用在于防止訂單支付數(shù)大于商品庫存數(shù)，導致最終無法出貨的情況。另外，并非所有平臺商家都會加入鎖定庫存的概念，該概念是由于訂單未支付狀態(tài)的存在而設計，而部分商家為了避免競爭對手惡意制造大量未支付訂單導致正常買家無貨可買的情況，也會對該鎖定庫存策略進行一些限制，如鎖 定庫存比例告警、非強制無

6、貨狀態(tài)等。用戶支付完成訂單后，訂單中心將同步該訂單為已支付狀態(tài)。與此同時，若用戶單筆訂單內存在多個商家，且商家之間為獨立運營，那么訂單會做拆分處理，拆分一般為母訂單根據(jù)各商家的商品價格與促銷活動，對商品和支付價格進行拆分，此處需要注意的是，拆分過程中可能遇到優(yōu)惠金額無法直接整除 的場景，需要明確好余數(shù)應如何處理。如用戶購買A 商家商品共10 元， B 商家商品共20 元，且使用了 1 元優(yōu)惠券，那么簡單的按比例劃分優(yōu)惠額即為A商家優(yōu)惠1*10/ (10+20) =0.333元，B商家優(yōu)惠1*20/ (10+20) =0.666元，若直接去尾數(shù)，將直接導致 0.3333=0.33 0.666=0

7、.66總優(yōu)惠=0.33+0.66=0.99的情況，與實際優(yōu)惠不 符。那么四舍五入行不行呢，上面的案例是沒問題的，但若遇到三個商家各 10 元，優(yōu)惠 1 元的場景，就會遇到同樣的問題，最后的優(yōu)惠額會等于0.33+0.33+0.33=0.99元。因此，在這個時候，一般會引入盈虧池的概念。盈虧池的概念即為，不論你采用的是直接去尾數(shù)、向上下取整還是四舍五入的算法，如果算出來的實際優(yōu)惠額大于訂單優(yōu)惠額，那么平臺將承擔該部分損失，記為虧損；如果實際優(yōu)惠額小于訂單優(yōu)惠額，那么平臺獲得該部分差價 盈利?？傮w上，總的盈利和虧損是不大的，只是為了保證實際財務收入與單據(jù)保持一致而已。而在不引入盈虧池的情況下，一般會

8、這么處理，當存在多個商家享受同一個優(yōu)惠時，系統(tǒng)將計算前兩個商家的優(yōu)惠額，并將最后的差額作為第三個商家 的優(yōu)惠額，如此便可保證用戶支付金額總和等于總商家收入金額總和。如上面案例 A/B/C 三個商家，共同享受1 元優(yōu)惠，那么 A/B 商家享受的優(yōu)惠額為0.33, C商家享受的優(yōu)惠額則為1-0.33-0.33=0.34說完拆單，另外一個需要注意的便是財務記賬，一般來講，用戶支付完訂單，財務中心將會增設一筆收入數(shù)據(jù)，該收入數(shù)據(jù)一旦確認，便不可再次更 改，原因便是為了保證財務數(shù)據(jù)與流水數(shù)據(jù)保持絕對一致。流水數(shù)據(jù)常見于第三方支付場景，如財付通、支付寶和銀聯(lián)等，用戶通過第三方支付，支付完成后第三方服務商將提供與該筆訂單相對應的流水單號， 因此流水單號也是財務對賬中，出現(xiàn)差異時可依賴的重要校對手段。另外，訂單在財務模塊還涉及到另一個分支-手續(xù)費，目前大部分第三方支付服務商會收取收款商家一定的