業務概述

在電子商務企業中，企業通過優質商品、促銷等手段核心追求的就是能與消費者進行交易，而訂單可以認為是一次交易的生命週期，交易開始生成訂單，結束的時候完成訂單。交易的核心要素：訂單上的商品資訊、發票（增值稅發票，還是普通發票）、運費、時效、預約、優惠等等相關內容，這些都是訂單履約的內容。為了承載這些履約內容，如何把客戶的一個訴求，最終以按時的效果交付到使用者手中，就產生了一個系統——即OFC（Order Fulfillment Center：訂單履約中心）

系統介紹

何為訂單履約

什麼叫做訂單履約？

從字面上的意思來說，所謂的訂單履約就是京東履行和消費者及客戶的一個承諾的約定。

為什麼叫做訂單履約呢？

在京東或者網站上買東西的（即B2C的業務），最終都會生成一張訂單。其實，這個訂單就是消費者與京東的一個簡單的合同，而合同上的東西都是我們履約內容，包括訂單上的資訊、發票（增值稅發票，還是普通發票）、運費是多少、時效、預約、訂單上的優惠等等相關內容。比如，訂單預計在前端就會顯示你的訂單會在什麼時間送達。京東現在對於時效來說，有自己的211（2011年開始）——京東在是中國第一家做出211這麼一個時效的公司。

何為211？

211就是上午11點前下單。然後當天送達。晚上11點（23點）下單是次日達。 除了211以外，我京東還有次日達，隔日達，還有前年推出的極速達——即411。411即3個小時送達，這個也是重新整理了業內的一個預約時效。

何為預約？

預約就是約時間的一個管理，在京東買東西就會發現，京東有一個預約日曆。在未來的7天內，可以選擇每天3個不同時段來送達，如北京上海等的一些城市，都會支援夜間配送。

關於OFC系統

這些都是京東的訂單履約的內容。為了承載這些履約內容，如何把京東客戶的一個訴求，最終以按時的效果交付到使用者手中，就產生了一個系統——即OFC（Order Fulfillment Center：訂單履約中心）。簡單來說，訂單履約中心就是連線的使用者下單，和訂單在庫房生產的一個系統。

OFC在什麼環節出現呢？其實，正常買東西都是從“網站的註冊–>搜尋商品–>選商品購買–>倉儲生產、物流配送”。其中OFC是在購買和倉儲生產這個環節之中的一個履約流程或者履約系統。

直白一點說就是——使用者在京東前臺選完商品進入購物車，到結算頁並點選提交訂單按鈕的時候，就進入了OFC這個環節，直到這個訂單由京東實際發給庫房（京東自有100個，協同倉+特殊倉可能將近200個）。怎麼把京東每天這麼多訂單量，發給具體的每一個庫房——就是OFC在做的事情。

針對OFC系統接下來會詳細介紹會這幾個環節：訂單的拆分、OCS（一個訂單金額的計算）、訂單的轉移、OFW（頂端全程控制）和訂單風控。

OFC系統框架圖

這是OFC系統的一個框架圖——OFC系統可能是非常技術化的，或者它是技術邏輯很多的一個系統。所以，我簡單的展示了一個OFC系統框架圖。展示這張圖，主要是想讓大家瞭解OFC系統在京東整個大系統裡，它的上下游關以及它資料流程的一個走向。在這裡，可以看到訂單的拆分、訂單的轉移和訂單計劃引擎。

其實，上下游互動的系統很多，因為在京東這麼一個體量的公司，它的研發有會很多不同的系統，比如Promise系統——這個系統就是客戶的承諾，即客戶下單的時效是什麼樣子，是通過Promise系統計算的，這個訂單具體什麼時間要放給庫房也是Promise系統來執行的。它是訂單和訂單客戶和我們實際行動的一個承諾的系統。此外，包括臺賬系統，訂單中介軟體、分揀、面單和發票，這些都屬於OFC的上下游相關的系統，

所以，通過這張圖我們可以理解到：OFC是京東的訂單相關裡最中間的一個環節啊。它上游有前臺（即頁面），有我的購物車，有我的結算頁，有我的交易（即生成訂單）；而下游就是實際的生產，即COO環節，如我的WMS，我的TMS。在京東TMS叫做青龍系統，有直接倉配系統。其實，OFC是在中間的一個可以說是隱形的，存在於在所有業務系統中一個系統。

OFC系統流程

聊到OFC流程，這裡用了兩個圖：一個是老流程，一個是新流程。這裡，主要就是介紹一下新的流程，該流程於11年上線。圖中可以清楚的看到OFC所處於的環節。

新流程主要的一個特點就是——系統會採用一個並行互動的方式。在以前的時候，一個訂單下來是序列的：訂單下來以後通過訂單管道，接著通過OFC拆分，轉移，下傳，全程資料序列，就會造成的效果就是時效特別長。當時，老劉下一張單子，從下單到這張訂單實際傳給庫房用了兩個小時的時間。毫無疑問，這樣的客戶體驗是肯定是不可行的，在京東做什麼樣的事，永遠是客戶體驗優先！為了解決這個問題（包括應對業務量的不斷壯大），我們改造了一個流程——在資料互動時候，提出了‘系統間採用互動服務’的一個方式，即我們所有業務的東西、我們的系統，都是通過拆分服務、轉移服務、翻譯處理服務等服務都採用並行的一個互動。

現在，我們速度比較快的一張訂單，即之前京東一個移動倉的訂單為18分鐘，而最快的訂單還達到過七八分鐘——從客戶下單到送達客戶手中，不到10分鐘的時間。而在我們系統端可能就是毫秒級的操作，就直接到倉庫了。

OFC系統運營資料

說到系統，產品經理肯定都要看資料，由於涉及商業機密不便多說。在這裡簡單說一下，其實OFC系統現在支援了京東24種實體訂單，實體訂單即我需要真正到庫房生產的訂單。

10種不同的訂單流程，舉一個例子，在今年618的時候，OFC這個拆分下單系統處理的訂單是3300萬，階段峰值達到6.8萬單/分鐘，訂單量是1500萬單/天。所以，對於這麼龐大的一個業務體量的一個系統，OFC在整個京東體系當中是什麼樣的一個地位？

底部圖片中展示的是一個簡單的各個機構不同的訂單的趨勢圖，有自營的訂單，和POP的訂單以及海外的訂單。

自營就不多說了，自營就是京東自己採購，自己銷售的一個訂單，沒有自己的定價權，這個叫京東自營。京東的POP是京東的開放平臺，開放平臺即使用者在京東上購買的商品都是商家的。

POP又分為幾種模式，有一種最常用的模式就是：商家把東西放在京東的前臺網站並用於售賣，而東西的庫存以及東西的配送都是由商家自行承擔，包括開票都是商家自行承擔，而京東在這裡只負責了網上銷售的一個動作，最終以返利來記錄這個交易金額。

為什麼要區分這塊？因為自營是要入自己的倉庫，然後要自己去進行倉儲生產，進行配送。而對於POP來說，京東只需要把訂單發給具體的POP商家，就像天貓那種模式一樣就可以了。

簡單說明一下京東的幾個區域，京東分為的北京、上海、廣州、武漢、西安、瀋陽、成都這幾大區域的。這些區域下面有自己獨立的配送中心，即RDC(區域物流中心)和FDC(分倉)這麼一個結構。

可以看出，到現在為止，京東的各大區域裡POP的訂單量已經越來越多，而自營的訂單量會逐漸的減少——這是一個未來的一個趨勢。

下面具體講一下OFC系統的一些業務。

訂單拆分

什麼叫訂單的拆分？

不知道大家在京東下單的時候，注意到這個情況沒有：使用者下完單後，在我的訂單詳情頁會看到這麼一句話，即‘您的訂單由於不在同一部分，或者不在同一個商家需要拆分’這麼一句話。而在拆分原因會顯示：因為不在同一庫房，或不是同一商家，訂單被拆成多個子單分開配送。

這個會對客戶帶來什麼？尤其像雙11或者618等這種大促的時候，我們的購物車可能一次性會有10個甚至有若干個東西要購買。然而，為什麼會拆這個訂單？

維度1：庫房

首先，京東有不同的、分品類的庫房。京東的庫房現在依然是以品類倉為主，就算我們有亞一（亞洲一號），但我們最主要、最關注的還是品類倉。

因為，不同的品類，比如像大家電、圖書、IT、3C類產品、食品母嬰類產品，在倉儲間要求上有不同的生產特點。比如，食品母嬰類產品在京東有自己的恆溫倉，諸如奶粉等此類商品要保持一定的溫度，而有一些生鮮要符合保持低溫倉的特點，再比如大件的擺放和圖書的擺放是完全不同。所以，現在京東最主要的還是品類倉。

對於品類倉有這麼一個特點，舉個例子：使用者買了一個電視，然後又買了一個食品，而食品屬於食品倉。如果使用者下了這張訂單，在購物車裡看雖然是兩個商品，但是實際上會產生兩張訂單——一張訂單是要給大家電倉庫，一張訂單要提交給食品母嬰倉。這樣就會帶來一個拆分，這是最主要的一個維度，即庫房。

維度2：商家

另外一個維度就是商家，京東現在有自營和POP。而POP裡邊有不同的商家，京東為了要給不同的商家進行結算，不可能在一張訂單上同時存在兩個商家的商品，這將導致京東無法跟商家做結算。因而，京東會根據商家去進行拆單。

以上就是最基本的兩個拆分訂單維度——庫房和商家。比如，使用者的一張訂單上，有自營的商品，有商家的商品，且有多個商家的商品。那麼，這張訂單就會拆成很多的子單，而之前的那張訂單則稱之為父單。其實，在京東OFC往下的一些下游系統裡，那張父單是沒有任何作用的。父單僅是客戶在購車環節中的訂單快照——即只是在下單時點的那個快照。具體到庫房，往庫房下游，比如說配送環節、售後環節，實際上都是參照子單去進行操作。

所以，訂單拆分在這裡做的過程就是——通過客戶在前臺提交的訂單，把客戶承諾的合同或履行約定，拆成京東可生產的一系列子單。

關於先款訂單和先貨訂單

現在，關於訂單又分為兩個類別，一個是先款訂單（先款後貨），另一個先貨訂單（先貨後款）。先貨訂單即京東自營，包括京東POP有一部分是支援貨到付款的。所以，會有先貨訂單。先貨訂單在點選提交訂單的按鈕以後，立即就進入了拆分。而先款訂單是在付款完成之後做拆分的操作。

拆分系統業務架構

這個是訂單拆分業務的一個框架——即拆分系統的框架和流程。框架這塊涉及的研發層面的事情比較多，因而不說的特別細。在這裡，就簡單說一下這個訂單是怎麼到拆分系統的。

訂單如何進入拆分系統

從使用者下單開始，在京東有一個叫做訂單管道的東西，所謂的訂單管道相當於構建了一張訂單，通過訂單管道OFW——它是訂單的全流程的管理，工作流的管理，它會負責去接到這張訂單，然後把這張訂單推送給訂單的拆分系統，由訂單系統進行相應的拆分操作。在這裡，訂單的拆分系統又被分為兩塊：一塊是一次拆分，一塊是二次拆分。

什麼叫做一次拆分，而什麼又稱之為二次拆分？

一次拆分是把一些相關的訂單通通在訂單提交以後立刻拆分，相當於是一個拆分服務——即前面談到的那次流程的升級，就用會把它做一個拆分的服務，直接拆分掉，而二次拆分需要做的，比如沒有付款的訂單（後款）。如果一次沒有拆乾淨，會進入到一個定時任務裡，即拆分worker裡——這是一個大的訂單池子。所有沒拆乾淨的單子，都會進入到這個池子裡，然後通過二次拆分——輪循看訂單什麼時候付款、什麼時候滿足了訂單的拆分條件，再去進行拆分的這麼一個流程。

訂單拆分流程

通過獲取訂單資訊，然後進行拆分，和構建。真正的訂單拆分動作做的是——根據拆分的業務邏輯，按照業務邏輯的條件去生成滿足倉儲生產的訂單。相當於構建子單之後將父單取消，再調取管道重新生成一張訂單——即根據業務的條件，重新生成倉儲可以生產的一些訂單。同時，會有一些其他操作，比如取消父單。以上是拆分的一個大體的業務流程。

訂單金額拆分

訂單金額拆分叫OCS，金額拆分是在兩年前單獨獨立出來。以前它是在訂單拆分裡，後來突然發現在訂單拆分的過程中，不能把訂單的商品行金額拆分。因為京東的訂單是以Xml的形式去記錄的，一旦MQ有訊息發過來，Xml就開始進行每行的記錄。三年前我們發現訂單的拆分，其實不光是對於Xml裡邊SKU的拆分，更多的下游系統會依賴一個訂單拆分的東西叫做訂單金額的計算。

現在可以這麼分，SKU拆分是一種，還有一種是訂單金額的拆分。在京東買過東西就會知道，京東一個特點就是——基本365天都會有不同型別的促銷，最簡單的直降，又滿減、用自己的東卷、我的京豆，還有各種各樣的促銷等等。比如買個東西，滿199減 100啊（活動預熱），大家都會湊單湊到199。於是，使用者就會買食品湊夠199然後減掉100。假如使用者買了10件商品，減了100元，那麼具體這100塊錢怎麼減呢？對於客戶來說，他們不理會京東怎麼操作這個優惠折扣，只要這100塊錢在自己結算的時候抵扣即可。比如，使用者花了200塊錢，而實際只是收了使用者100塊錢，這就可以了。但對於京東來說，這100塊錢並不是直接減100這樣來登記的，其不在訂單裡，是以商品的金額訂單裡，商品金額的比例分拆優惠的錢——這就是OCS在做的一個工作。

OCS的基本原則就是按SKU的金額比例去分攤並取整數。這裡面不光包括優惠，還有各種運費，虛擬資產（如京豆）等。比如這次花了1000京豆來抵扣10元，這1000個京豆抵的這10塊錢就會分攤到使用者具體的每一個SKU上。其實，現在前臺會直接顯示減幾塊錢幾塊，記得不是特別細，其實在後臺都是會具體的記錄每行減多少錢，包括運費——像我們在北京，買自營的商品體驗不是特別那個深，如果在偏遠山區，在京東是要收特殊的運費，或者買商家的商品會收運費，運費怎麼分攤也都是在這裡計算的。

OCS最終對外提供了一個訂單金額查詢服務，包括售後系統，比如發票系統，還有外圍系統都會去調這個服務。舉個例子，比如售後系統中，使用者要退的一個東西，那使用者買的時候是什麼錢？買的時候用了什麼樣的優惠？優惠攤了多少錢？最後售後要退款的時候實際退多少錢？都是通過OCS這麼一個金額計算的服務去算出來的。

通過以上的解說，訂單拆分就是按照客戶履約的行為，將訂單拆成符合京東生產一系列的可生產的子單。所謂的生產對於京東自營來說就是定位的是不同庫房；對於京東商家來說，定位的是不同商家。OFC最直接的兩個下游系統，對於自營來說，下有系統就是WMS即倉儲系統；對於POP來說，下游系統就是POP訂單系統。所以京東的單子都會發給這兩個系統。

訂單轉移

本環節講下訂單的轉移，訂單的轉移含義不太好解釋，拆分大家可能還能清楚地理解為什麼拆分——因為有不同的庫房。

何為訂單轉移？

訂單轉移可以理解為訂單的計劃。通過資料可以看到，一分鐘就要接幾百萬萬單。不同的訂單通過不同的渠道下單，比如，京東有PC端，app端，微信端等等各種不同的渠道下的訂單，統一都堆積在京東OFC的大池子裡。京東通過怎樣的方式和客戶履約，其實轉移是履約的一個核心環節。以什麼樣的方式和客戶履約，而客戶約定是什麼，京東要分給誰都是在訂單轉移這個環節進行的。

說白了，它是訂單的一個分發機制，或者說訂單的分發一個計劃，訂單要給哪個庫房去生產，怎麼生產都是在訂單轉移中進行的。訂單轉移架構圖在此不詳細說，主要說兩塊就是跟它關係最密切的兩個系統：

一個是Promise系統，之前提到過——拿自營舉例子：

Promise系統通過庫房生產的一個波次，算出每一個庫房的接單時間點，然後告訴訂單轉移系統，這個訂單在什麼時間，下發給客戶是最妥當的——即能正常的履約的。

為什麼要這麼說呢？京東訂單有時效的概念，比如，我211的訂單，有411的訂單，有次日達，隔日達的訂單，還有預約訂單。那麼，若干的訂單下來以後，什麼時候去生產211訂單，什麼時間去生產411訂單。

舉一個例子， 411訂單是極速達，使用者付費49塊錢就能享受到3個小時送達的一個服務。所以，對於411的訂單是半個小時之內，就要把所有的資訊流程都走完，而剩餘的時間是要給倉儲生產也好，配送在路上也好。所以，對於411訂單，我們有一個特殊的處理流程。而對於211訂單，比如是上午11點前下的訂單， Promise系統會算出這個211的訂單，在上午每個庫房不同的結單的時間——即庫房截至收到這個訂單的時間點也會算出來，並告訴京東每一張訂單什麼時間下發庫房是最合適的。

在京東的庫房有波次的生產的概念（JIT波次生產），對於庫房來說，不可能來了一張訂單就生產一個訂單，這樣的庫房是沒有計劃性的。他也是工人操作，有生產的環節，這樣操作容易導致生產混亂。所以，京東的庫房採取的是波次生產——即訂單都會成堆生產，而不是單獨去生產。因而，會有Promise系統，或轉移系統。

另一個就是庫存的服務：

京東的庫存是大家在前臺下單的時候看的有貨和沒貨的提示（在北京看基本都是有貨，無貨的很少）。京東也不會寫具體的庫存數量是多少，比如還剩幾百件幾千件商品不會寫這個數——只能這麼說，寫這個數肯也是不準的，不像某些電商前臺寫還剩餘幾件庫存，但實際上他自己根本不知道他剩下多少條褲子。

好比京東，全國有多少件庫存？其實，庫存有不同的庫存項，所以庫存數肯定是不準的，因而，我們也不會寫具體有多少庫存，只是告訴你這個東西這有沒有貨，只要在京東前臺下的訂單。只要是有貨，而使用者也正常了提交了訂單。無論如何，京東在OFC這個環節，都會去幫使用者搞定，並生產這個訂單。

什麼叫庫存系統？

京東有3套庫存，講解一下最主要的一套庫存即前臺庫存——就是使用者在主站下單的時候，能看到這物品有貨還是沒貨。這個就是庫存系統算出來的。比如，使用者在天津，京東會先看這個東西在天津有沒有貨，如果天津沒有貨，就會看在北京有沒有或，而如果北京也沒有貨，且這個東西如果開通了平行庫存的圖層屬性的話，就會去檢視全國各個地方有沒有貨，然後，再返回來告訴你這個東西有沒有貨。具體的說，使用者在前臺買了一個東西顯示是有貨，具體這個東西是在天津生產，還是在北京生產，這個是由訂單轉移在做的。

訂單轉移流程

在講訂單轉移流程之前，需要詳細的把京東的二級共享庫存模型給大家講解一下，如果不理解這個模型，就不知道為什麼要做訂單轉移。

這裡主要講的是京東的RDC，這也是在京東成立後的一段時間內，才做的這麼一個二級庫存。最早就是一個一級庫存——全國就那麼幾個大的庫房，北京就看北京的庫存，上海看上海的庫存。當京東發展到一定體量的時候，我們會發現這種一級庫存的概念無法正常的滿足我們這麼龐大的一個訂單體量。所以，就做了二級庫存——FDC是我們的前置層，舉個例子：濟南就是一個FDC，天津也是一個FDC。RDC是我們的中心倉，也叫綜合倉。

京東現在有7大區域：北上廣重武沈西（北京、上海、廣州、成都、武漢、西安、瀋陽）。比如，濟南是屬於北京這個區域的，也就是說啊。濟南市一個FDC，北京是一個RDC。如果濟南的使用者下單，首先看濟南本地的有沒有貨，如果濟南本地有貨，就從本地區發貨，如果本地沒貨就從北京去檢視——這樣的支援關係。

為什麼要有這樣支援關係？因為京東前期最早的業務都會在一線城市，比如北上廣深這些城市下單的比較多，隨著現在體量的不斷的增加，我們在做渠道下沉也好，我們再向下探，更多的去滿足二三線城市的一些使用者下單。所以，我們要有FDC——我們不是備全量的貨，根據二八原則，有一些比較暢銷的商品，能滿足基本滿足這片區域（如：濟南）、這個覆蓋範圍的使用者的下單。但是，有一些比較長尾的商品怎麼辦？——就從北京去發，由北京支援濟南。

既然有了這套支援關係，即訂單為什麼要轉移——訂單在使用者下單的時候，庫存在我們前臺來看我都是一個一個商品新增到購物車的，然後這個商品京東會看有沒有貨就好了。但是，在提交訂單到了OFC環節都會形成一張訂單。所以，你的訂單是有一個或多個商品的。即京東看庫存的規則，和前臺使用者下單時候看庫存的規則是不一樣的。在前臺看都是以SKU的維度去看這個庫存，而OFC裡是以訂單的維度看庫存。

所以，訂單的緯度看庫存有1個特點：就是整單生產。即如果可以整單生產的話，就不會去拆分訂單。舉個例子，使用者買了兩個商品，一個商品在濟南有貨，另一個商品在北京有貨，正常的話，一個商品要在濟南發出，一個要在北京發出，這樣就形成兩個訂單。如果我們有一個整單滿足的條件的話，假如兩個商品北京都有貨，那麼這張訂單會定位在北京整單生產，然後，從北京直接發給客戶。這樣會減少一個拆單率。

轉移的整個流程就是要去判斷庫存，因為在剛開始說到拆分環節是不看庫存的，看的只是這個訂單能在哪兒生產。這要說到一個京東有貨備貨的一個概念。備貨就是說，這個商品備在濟南這個地方了，證明在濟南是可以生產的，即可以進入濟南庫存，然後從濟南庫出，但是具體有沒有貨不確定。有貨就是庫存的數量到底是是不是有，庫存是零啊，還是是一二這具體指有貨。

所以，講到備貨和有貨，在拆分環節是不看有沒有貨的，只看能不能備貨，能備貨就證明這個東西是可以在這兒生產的，但具體有沒有我不知道。在訂單轉移環節，才實際上和庫存打交道，看訂單的狀態，看訂單庫存，具體去看訂單是要在哪個地方生產，這就是訂單的轉移。

訂單全流程管理

接下來了解下訂單的全流程管理——訂單會有一個工作流的東西，我們叫做OFW（訂單工作流系統）

框架圖其實主要講的訂單工作流的有兩塊內容：一塊是叫做訂單資訊回傳，另一個是訂單資訊的下傳。訂單資訊下傳即剛才說到的OFC系統是連線上游和下游的一箇中心的系統。京東要接全國100多個將近200個庫房，每一個庫房是怎麼接的，我單子是怎麼推給庫房的，都是由OFW系統去做的。

OFW這個系統主要做的一個操作就是從訂單管道過來以後先負責接單，然後去呼叫拆分服務、轉移服務等下游系統的服務。比如，給下游系統封裝資料，封裝面單的資料，封裝發票的資料。好多下游系統是不去看訂單詳細資訊的，都是通過OFC把訂單的詳細資訊（如你想要什麼）封裝好了給你。比如，你要什麼樣的發票內容，然後把發票按內容做好給客戶。

OFC為什麼接這麼大體量？比如，每新增一種發票型別，裡面修改一個東西都是跟OFC息息相關的。所有的下游系統需要的資料，都是京東給他做組裝封裝的。

還有一個叫做訂單的回傳，訂單的回傳資訊就是所有的下游系統在接到這張訂單以後，這個環節不是說就結束了，下游系統會給我反饋一些狀態，包括訂單的什麼樣的資訊，都會通過我這兒再回傳，再返給上游系統。大家在下完單後發現京東的訂單有訂單全程跟蹤，還有定位。你的訂單幾點幾分下傳了，到達了京東的某一個庫房，比如食品母嬰倉，使用者的訂單幾點幾分進行了打包，幾點幾分進行了分揀，然後又到了那個地方——整個的過程管它叫做訂單呢全程跟蹤。這個訂單全程跟蹤裡所有的資訊都是由這統一資訊，並做彙總，然後統一就是反饋給上游，然後在前臺頁面展示給大家。這就是OFW整體的系統。

訂單風控業務

什麼叫訂單的風控？

風控主要做的一個事就是防止惡意的套贈。京東有很多促銷，比如一些贈品、滿減、抵用劵等。體量大了總會有‘不法之徒’，或者惡意的人發現京東的機制有問題，從而去套一些贈品。

簡單舉一個例子，他們知道京東的訂單可能要拆分，在下了一個單的時候，因為一些產銷的促銷不規範，當用戶買了一個大家電，一個冰箱，而冰箱贈送一個插線板，冰箱是在大家電的庫房，而插線板是在小家電的庫房/3C庫房。因為庫方不同，肯定要拆成兩個單生產，而插線板是贈送，京東記錄時候記得是0元，即沒有價值。拆成兩個訂單對於京東來說，配送的時候也不知道哪個先哪個後，尤其大家電好多都是第三方配送的，經常會有贈品簽到了，大家電沒配送的。就會出現一個問題：贈品收了，大家電取消了——直接在網站前臺訂單取消了，或者說拒收了。這樣就叫做惡意套贈。

之前沒有上贈品或者說沒有風控系統，每年惡意套贈的金額是一個非常客觀的數目。

贈品流程的優化

圖片上部分就是以前的一個簡單的流程：一個訂單拆分成兩單，一個主一個增的，然後會到不同的倉庫去生產，由不同的站點配送。甚至是不同的配送的人員，不同的配方的方式去配送，最終到客戶手裡。這樣，就會導致這個兩張單子呢有先有後，如果贈品在前的話就會套贈。

為了防止惡意套贈，我們作了一套風控系統，它是怎麼做的？系統也能支援使用者正常下單，因為不能影響使用者體驗。但在拆分環節，會把第一張訂單主品的單的和第二張贈品的單建立一個關係。因為，知道是怎麼拆的，它的上游父單是清楚的，因而也清楚知道1和2這兩個單是什麼樣一個關係，也會記著密切關係，然後讓下邊兒去生產，再進行一個合流。換句話說，客戶現在要取消這張訂單（套贈要取消）的時候，會告訴客戶將聯動取消。

其實，最主要的一個核心思想就是聯動取消，即在今年618的時候，為了湊夠1萬塊錢用一張劵，我下了一張被拆成了30多張子單的訂單。當時不是惡意套贈，是有一個訂單確實有問題，想取消了不要了。那個提示我看見了，但沒注意，因為618那天特別忙，我就取消了。而點完以後就覺得這出問題了——聯的那30多張子單可能就全都陸續都被取消了。因為，我用了一張東劵——1萬減500的東劵，然後就被取消了。因為所有的訂單都會有一個促銷關係，在前臺會提示你：xx訂單和xx訂單有促銷關係，如果取消了會怎麼著。當時我也比較著急，沒仔細看就都取消了。

主贈關係

這是主贈關係系統，其實最初的是一個父單，父單會拆成若干的主單，主單會去記住它什麼是贈品單（訂單的維度去判斷）。對於促銷來說，它是以SKU緯度會去嫉妒哪些SKU是主品，哪些是贈品——即以訂單的維度去講，哪些訂單是主單，哪些訂單是贈單。然後，我們把這個單和單之間關係建立一個服務，包括現有一些下游系統，比如客服系統，售後系統、退款系統，都會呼叫這個關係在取消這塊兒。

舉個例子，使用者一共買了ABCD4個商品啊。B這個商品是買A贈的，相當於使用者買了ACD這3個商品贈了一個B的商品。而京東有不同的庫房，A商品在第一個庫房，BCD商品的第二個庫房，正常拆的話，A商品肯定是單獨的一個訂單，因為它在自己的一個庫房裡，而BCD商品按說應該是在一起的，因為是在第二個庫房裡。但是，B商品是一個贈品，他是一個贈單，因而就會把B的商品和CD的商品單獨拆出來。然後，去記錄一個關係叫做：A商品是主單，B是贈單——即第一張訂單和第三張訂單之間的贈品關係。這樣的話，如果使用者收到了B，想退A的話，這些相關聯的商品會聯動取消。這就是一個主贈關係的記錄。

訂單取消流程

即通過統一訂單取消入口，所有外圍系統都會呼叫訂單取消服務，實現訂單取消業務的統一及關聯訂單的聯動取消，防止惡意套贈。

有幾個點需要注意：

比如，我們在訂單的面單列印的環節、倉儲生產配送的環節，在面單上寫現在寫的是的一個贈字，即哪些是贈單會記錄一個贈字，在包裹這一塊也會有標識。而配送環節如果遇到主單和贈單，現在都是主贈單合流一起配送的。

以上就是訂單的風控。

未來發展之路

最後說一下OFC未來的、也是京東在規劃的一個方向。京東是以大資料驅動的，智慧零售的零售平臺，同時這兩點也是我們零售平臺的一個宗旨。所以，OFC系統在零售平臺裡的定位是訂單履約的一個環節。

對於零售系統是怎麼樣的呢？

訂單資料視覺化

對於京東這種海量的訂單來說，每天那麼多的訂單量對於產銷、對於京東的一些高層或者京東所有需要關心訂單的人來說，他們不可能每單都去看。他們也不可能通過一些以前簡單的一些報表，或者是用Excel如何去統計，或者做統籌的規劃。

對於OFC來說，我們未來的一個方向就是資料的視覺化，通過大資料的驅動指導我們的流程。OFC系統其實就是一個流程驅動的系統，但是它背後隱藏的資料量是非常可觀的。現在，我們設想有一個東西叫做監控看板，這裡就能看到所有訂單的全流程的看板，包括履約的實效、智慧的提醒訂單的問題，還包括主動的應急預案，比如我們在每年的618、雙11大促期間，都會有一些應急預案（比如我們要降級——有些東西要下降一個層面去做一些主動應急的預案）在裡頭去進行。

另一個就是全國的庫存的布控。由於京東現在的庫房太多，全國這麼多點，每一個點的訂單是從哪出從哪入的，我們現在是想做一個統一的入口去展示，包括的訂單量，訂單金額。主要是指導採銷人員也好，或者公司層面的一些領導層——全國的我補貨計劃、鋪貨計劃是怎麼樣——以點會面。這個是資料可視的一個產品，也是我們正在規劃的一個產品。

FTP、ATP系統建設

其實，京東現在做的就叫FTP。這個FTP、ATP在供鏈體系裡，包括國外一些產品，是已經是比較成熟的東西。

我們現在做的是FTP，即Fulfill to Promise，即可以以現貨，京東有的東西怎麼去更好的履約，去做了一個所謂的FTP的計劃。ATP（Availableto Promise）是什麼意思？就是我們未來要做的——京東有貨的，我可以去給你做極速送 （可以給使用者做411）。但要是京東沒貨怎麼辦？京東現在面臨最大的一個問題，以及我的競爭對手最大問題就是：我是做自營的我們不是做平臺的，貨不可能全都掌握在京東手裡，會導致供鏈過重。

那麼，京東沒貨怎麼辦？怎麼做零庫存？而ATP的計劃是其中的一個環節——即就是怎麼把供應商的庫存，怎麼把在途的庫存，怎麼把一些計劃裡的東西，怎麼把全國的庫存都能實際的用起來。

舉一個實際例子，大促的時候，我們的競爭對手，他們也在做預熱。比如，也在做大家電，然後打著口號當天下單當天裝運之類的——我理解它是不可控的，因為東西都不在自己的手裡，怎麼控制那些東西啊？

而京東現在要做的ATP是怎麼做？京東讓我們所有供應商（如美的——深度協同）把他們的庫存計劃實時的共享給我們。在大促期間，使用者的第一的需求是我能買到這個貨（因為便宜）。可能就對時效的要求就不是那麼高。比如，這個東西可以不是211，不是非得雙11當天上午11點前買東西，我非要當天收到。那麼，這塊在這時候就會起到作用——有一些東西會通過讓使用者選擇犧牲時效，而把一些在途的庫存，在供應商倉庫裡的庫存，都會去把這個東西認為是有京東的庫存，認為是我可控的庫存。然後，會讓消費者真正的能享受到這個實際的優惠。

其實，這個ATP的一個計劃——即是我們控的。整個供應鏈環節裡，我們可以掌握的東西都放到這個計劃。對於現在FTP來說，是更大的一個履約行為。這樣的話才能在整個行業裡，掌握資源並更好的利用起來做這個事。

說到這裡，也給大家推薦一個架構交流學習群：828545509，裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析
，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，相信對於已經工作
和遇到技術瓶頸的碼友，在這個群裡會有你需要的內容。

點選連結加入群聊【Java高階架構師學習群】：https://jq.qq.com/?_wv=1027&k=5T2kMGl