京东订单号(用订单号怎样查订单物流信息)

前言产生后，还会继续一系列的流通，最终交付给用户。每个环节都有其对应的操作，数据信息也需要其完成。根据订单的每次状态变化，可以进行计算分析，进而优化供应链路径，提高订单处理效率和用户体验。本文根据经验从订单信息和订单状态两个方面描述订单涉及的系统或业务流程。

信息1。关键领域订单的流通效率取决于信息系统的数据流通结合仓库和快递的货物流通，所以有几个关键领域需要提前关注和了解。

订单是从哪流入到OMS（订单管理系统）的，这就是订单来源。不同来源的订单销卖渠道不同，而且有的流转也是不同的，如由第三方负责发货的订单，系统是需要根据开放平台来传递信息，对于发货、物流等控制与自营订单不同。订单是什么类型的，因为订单类型不同，在OMS系统中处理有所不同，有的可以有跨节点，有的可能是逆向流程，如退货订单在是从用户到商家的一个过程，它与正向订单的处理要复杂，因为它是要根据正向订单流转过程中产生的信息进行获取再根据规则进行计算处理。仓库，即订单来了要送到哪里去作业处理，在仓库中的流转需要有哪些标准流程，不同的仓可能归属不同的分公司，那么在成本核算上又会有哪些不同，虽然在OMS前期不关注，但要保证这些信息的准确性。而且对于有的商家在A仓缺货后，可能安排B仓发货即订单转仓，不通过仓间调拨的方式，所以订单中要记录最终的发货仓。支付状态，此字段与支付相关，不同的支付方式需要对接不同的接口，状态的回传是否及时等等。支付状态与订单状态可以合并成一个字段。 订单状态，即在不同的操作节点上订单所处的状态，有些信息是展示给用户的，有的是内部查看的。后续有详细的介绍。2.订单信息订单生成的时候，简单的说订单信息包括订单的基本信息和订单的商品信息，还包括很多附属信息，比如付款明细，关联用户，使用的礼品卡明细等。，如下图所示。

(1)订单的基本信息

订单信息是订单主表的信息。我会把它分成几个小部分:订单号、订餐用户信息、订单基本信息、付款信息、收货信息、物流信息。

1)订单号:单独列出。你可能有疑问。这里有一个解释。

订单号虽然只是一个单据号，但是这个号码格式是什么样的需要经过设计，因为有的公司订单号是年月日+序列号或随机号方式，这样设计没有什么问题，因为只要保证唯一性就可以了。但是，对于一些公司为了避免数据泄露（如友商通过订单号分析日订单量）在单据号格式进行了一些处理。此外，在履单过程中，单号是流转过程中非常重要的字段，所以如果好的OMS系统可以根据订单号进行分发流转，操作人员也可以根据单号来人为判断其订单类型或仓库等信息。附：Amazon中国的订单号格式：C01-2442712-9062228 ;京东订单号：106697775485;淘宝订单号：786699393282068525订单号的生成是需要有一个组件支撑的，首先要能够满足订单量的增长、用户并发等要求，其次随着数据量的增长订单表是要进行横向或纵向拆分进行分库分表，数据进行分布式存储（有兴趣的可以看下《大众点评订单系统分库分表实践》）。我们曾开启过分库分表项目实践，但因种种原因推进不顺利，最终仅上线了单号生成器及一些服务组件，挺遗憾的。

2)基本信息:

包括除订单号以外的主要信息，如来源、分类、状态、所有权、仓库等。由于未来订单表的数据量最大，所以要考虑每个字段的真实含义，是否能满足未来的扩展。

随着时间的推移和业务的快速变化和增长，有很多可能性会迫使你在未来第二次添加字段或重新定义原有字段，以至于在开发过程中只能不断地对这个表进行转义，这大大增加了代码的复杂度。我个人更喜欢预定义几个保留字段。我们来衡量一下设计时的利弊。

3)支付信息:

付款主要用于订单级别使用的优惠券、礼品卡、积分和折扣。前端订单进入结算页面时，会根据相关信息进行计算和记录。同时，在核对单据时，一般遵循以下规则:订单金额-优惠券-礼品卡-积分=应付金额；订单金额=订单商品金额+运费金额；订单金额=商品实际售价*售出商品数量。

4)接收信息:

订单的订购用户和收货人可能不同。为了更好的提升用户体验，部分订单可以预留发货时间等。，所以这部分信息可以单独列出，也可以用附属信息保护。

5)物流信息:

这里需要记录快递公司和物流号，用详细的物流信息打电话。

(2)订购商品信息

这个表是交易的详细商品信息，自然包括商品的基本信息，以及交易时的商品价格和优惠信息，还有交易时商品参与的活动。

商品信息表是订单从表，数据量是订单表的几倍甚至十几倍。同时，订单层面的一些优惠金额需要根据商品进行分摊。因为发票是基于商品信息的，分摊金额时要注意尾差；同时，订单退货时，要根据货物重新摊销，重新计算金额。

退货时的重新分享和重新计算是一个比较啰嗦的过程，针对的是用户下单时订单级别或商品的促销活动。退货或换货后商品发生变化时，订单级或换货商品不能再享受促销折扣，需要重新计算折扣金额。

(3)计费信息

账单信息，剪一张JD.COM的图，参考一下。

(4)付款细节

对于付款，订单生成时我们简单谈了一下。这里我们强调的是各种支付方式的支付明细数据。我之前说过，涉及钱的信息不能马虎，一定要记录清楚。应该有交易流水号(我们公司或者第三方机构的)，支付日志是状态变化的过程。

这部分后续会进入财务系统进行应收账款对账，发生退款时需要检查。如何设计开发支付系统就不啰嗦了。官方的话是保证数据的准确性和及时性以及异常发生后的补偿措施；结算时尽可能提高响应时间，即使需要1ms，用户体验也可能有很大提升。

对于，通常根据母订单进行付款。后续分单时，需要通过上级单据号关联相关付款信息。

(5)物流细节

按照下面的状态分解的时候还是会提到的，这里只展示一张图供参考。

(6)所附订单清单

这部分是根据实际业务情况设计的。比如订单支付过程中使用了购物卡，就要记录购物卡和订单号的关系，同时记录用了多少钱，余额多少，什么时候扣款的。这些需要与礼品卡系统相关联，以确保该用户名下礼品金额的变化是可追溯的。

同样，积分支付需要记录使用积分支付时支付了多少积分，这个订单使用了多少积分，用户还有多少积分等具体时间的信息。

还是那句话，金钱相关的信息不能马虎；对于其他需要记录的信息，如果不方便或者无法在订单或商品表格中记录，可以附表格。但是，很明显，子表越多，代码可能越复杂，但是移动表可能更容易。

此时，即使完成了订单信息的分解，一般也会将订单拆分成不同的子订单，即一个订单拆分成不同的子订单，订单的后续履行按照子订单进行。我们从地位的角度来梳理一下。

订单状态订单的状态，我把它分成三个部分:

用户相关的状态，即用户在我的订单中可以查看跟踪的订单状态变化；仓库/商家的状态，是指订单分配到仓库或商家后，在其作业过程中产生的状态；物流状态，即仓库/商家发货后，包裹发货到用户签收过程中的相关状态。

下面，我按照从新楼到用户签约的完整流程，来阐述一下我的理解。

新建:指用户选择商品并提交后生成的新订单。在订单生成之前，根据用户选择的收货地址，对用户选择的商品的库存判断、商品的优惠活动、订单的优惠活动、付款方式、开票信息进行判断。详细流程请参考电子商务后台-订单生成。

支付:当用户支付提交的订单时，需要记录支付明细。支付完成后，订单的状态将变为已支付。这时候订单还需要经过几个流程才能发货。

拉单服务:是将前端服务器生成的订单拉至后端生产数据库(一般称为内部ERP数据库)，意思是要求快，不能有订单积压。拆包服务:折单分为两部分。前端下单的时候会进行预拆包单，也就是将不同的商品按照规则进行堆标，用于后续的拆包服务。付款完成后进行拆分。这时候就会根据商品的属性，发货条件的要求或者是否缺货来拆分。这时候会把货堆起来，然后会产生子订单。普通订单主表中的相关金额信息将根据子订单的商品重新计算。账单拆分的规则很多，本文就不深入梳理了。订单发布服务:WMS系统独立于OMS系统或ERP。如果使用第三方仓储系统，数据传输必不可少。目前，如何设计文档分发和状态返回系统是定时任务+消息队列的方式。订单可以根据仓库下发的WMS系统发货，也可以通过开放平台发货给合作商家。在JD.COM下单后，你会清楚地看到一条类似“你的订单已经配送到XXX仓库……”的系统信息给用户。订单拦截服务。在用户创建或支付订单之后，在订单打开之前，还应该有一个订单拦截服务。这项服务的目的是判断恶意订单，特殊订单的批准取决于相关规则。当订单被拦截时，可能会强制取消订单，以释放库存或避免用户刷单。这个过程有些叫订单回滚期，我理解类似于回收站。等待交付:处于此状态的订单可能没有交付到仓库，或者可能已经交付。但此时，所有订单都可以取消。

看上图，订单在发货前的每个状态理论上都可以取消(用户主动或被动)。

订单取消后，状态变为“已取消”，我认为这是订单的最终状态之一(已取消、无效、关闭或已签收)。

如果取消订单还没有开通，可以按照付费或者不付费进行，即是否涉及用户退款；如果一个订单被拆分，那么这个订单会根据子订单进行取消，在取消过程中会判断是否可以取消，这涉及到促销或者赠品或者订单分类等信息，所以细节就不多说了。

这里有一个订单状态补充，就是如果一个订单拆分了，那么它的母订单状态是什么？一般设置为无效订单，也是订单的一种结束状态。

已收订单:此状态在WMS系统中可以定义为待分拣或其他名称，在上层系统中可以定义为已发出或待装运。此时，订单开始在WMS系统中循环，但用户一般不会关注你具体的履行节点。他最关心的是你送不送。

分拣/打包/发货:这些状态是仓储或商家的操作流程，发货速度是用户关心的问题。一般上层系统只关注什么时候发货，如果没有及时操作会提醒。这些状态变化虽然在入库，但我觉得需要同步到OMS系统中，可以分析订单的时效，对售后也有帮助。

一般来说，用户或系统仍然可以在订单排序前取消订单，这取决于订单取消流程的设计。

已发货:当仓库或商家操作发货时，订单将进入下一个状态流程，即物流状态。此时订单已经打包，此时不能取消订单。如果用户不想要，只能拦截拒绝。

物流状态信息:主要是四个节点，“已收->:在途->:已发->；签收”，这些都是对接第三方物流信息获得的。这些状态信息一般与订单的主要状态分开，记录在订单信息的物流清单中。和物流公司对接的时候，他们会有很多状态码，显示给用户，哪些不显示给用户可以根据情况进行筛选。但是最好和官方物流保持一致，因为有些用户会去官网快递查询，如果有异常会进行投诉。

因为是对接快递公司的开放接口，所以有些信息需要脱敏，有些信息需要保存，物流状态需要及时更新，让用户看到最新的信息。

签收:用户收到货物后签收，这个订单就完成了。如果后续涉及质量等问题，需要走售后流程。

拒绝:淘宝订单一般很少被拒绝，因为商家一般要求先签收照片再去售后(部分商品可以)。一般放在大型垂直电商网站的自营商品都可以拒收。现在基本上没有货到付款了。前几年进货可以选择货到付款。有问题或者对商品不满意的用户，可以很坦然的拒绝，因为你没付钱。虽然现在有支付宝等第三方支付，但是拒绝支付很麻烦，因为这涉及到与快递员和商家的沟通。

货物拒收后，第三方物流属于新单，快递费谁出是个问题(用户还是商家)，所以一般是第一签第二签。

写到这里应该能简单理解订单生成，根据相关状态再一次了解单据流转过程。

总结

了解了订单信息的构成和相关状态，相信对后续业务的理解和方案设计会有一点帮助，但这些都是非常笼统的理解，并没有退货逆向流程的总结。一般在设计产品时，处理正向标准流程相对容易，复杂的都是逆向或者非正常的考虑。

为什么要考虑那么多异常情况？其实最重要的是责任和信任。结合客服系统总结后续订单的售后退货流程。

感谢您的阅读！

作者:倔强的萝卜；微信官方账号:倔强的萝卜

本文由@倔强的萝卜原创发布。每个人都是产品经理。未经作者允许，禁止转载。

来自Unsplash的图像，基于CC0协议。