深度揭秘京东的订单体系

业务概述

在电子商务企业中，企业通过优质商品、促销等手段核心追求的就是能与消费者进行交易，而订单可以认为是一次交易的生命周期，交易开始生成订单，结束的时候完成订单。交易的核心要素：订单上的商品信息、发票（增值税发票，还是普通发票）、运费、时效、预约、优惠等等相关内容，这些都是订单履约的内容。为了承载这些履约内容，如何把客户的一个诉求，最终以按时的效果交付到用户手中，就产生了一个系统——即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来说，是更大的一个履约行为。这样的话才能在整个行业里，掌握资源并更好的利用起来做这个事。

本文章转载于PMCAFF.