对于大型商家来说，与各平台的合作错综复杂，需要一个逻辑清晰的自营订单系统进行管理，笔者在本文分析了自营订单系统的业务逻辑。
当前各大电商平台竞争不断，各有各的标准，各有各的玩法，这对于供货的商家来说其实是一个很大的挑战。
当然，对于一些小的商家（例如在淘宝开一个淘宝店）而言，工作人员也就几个人，工作并未细致分工，内部运营还是比较好管理的。
但是对于一些大型的商家来说，往往不单单与一个平台合作，而是与各大平台皆有合作，且体量庞大，内部人员众多，分工细致明确。这样就需要依附于各大平台搭建起自己内部的管理系统，便于内部运营管理。
对于这类因为入驻各大电商平台搭建起来的运营管理系统，其实分为很多域。例如，与各大电商平台供应相关对应的：商品系统，库存系统，价格系统，营销系统；与各大电商交易相关对应的：订单系统，客服系统，财务系统，结算系统。当然，这些系统可能不单单用于对接各大电商平台，有可能还服务于商家自主的线下平台，或者其他销售渠道。
今天分享的是，订单中心，或者称之为“自营订单（区别于各大电商平台的平台销售订单）”，是商家与各电商平台交易的核心纽带，是商家交易后运营的起点与枢纽。其结构大致如下，这里分为三块来简单分析：信息翻译，正向业务，逆向业务。
信息翻译
“自营订单”是商家交易后运营的起点与枢纽，而“信息翻译”则是自营订单的起点。
为什么单独列出这一项，主要有两个原因：
各平台语言不一致，内部与外部的语言不一致，人员适应需要成本；
各平台语言不一致，内部与外部的语言不一致，后续系统适应需要成本。
信息翻译涉及的内容很多，基本包含交易履约环节的所有信息。
正向业务：分为拉取与推送
（拉取）订单相关信息：订单基本信息，会员信息，支付信息，商品信息，收货信息，优惠信息等；
（拉取）结算相关信息：销售平台分账信息，优惠分账信息，支付平台分账信息等；
（推送）履约相关信息：发货信息，物流明细等；
（拉取）履约相关信息：确认收货信息。
逆向业务：分为拉取与推送
（拉取）请求相关信息：退货请求，换货请求，仅退款请求等；
（拉取/推送）请求调度信息：同意退货，拒绝退货，同意退款，拒绝退款，顾客寄货/上门揽件，投诉制裁等；
（拉取）结算相关信息：退款结算信息等。
这些信息多种多样，并且各平台语言不一，所需要耗费的工作繁复复杂。虽说看上去并没有什么业务价值，却是后续所有业务流转的源头。
正向业务
我将正向业务分为了两个大的模块；
正向交易调度；
为什么这么分，其实也没什么意思；就是简单的前置条件，交易调度之后，其他调度才可开始，其他调度内部之间可并行执行，或者说交叉执行。
1. 正向交易调度
这里可能存在一个问题，各电商交易平台已经完成交易管理，支付管理了。
为什么还要做一个“正向交易调度”呢，“正向交易调度”做的是什么呢？
“正向交易调度”做的主要内容是同步的管理商家内部的核心资源（主要是指库存），尽量保证商家内部的核心资源与各销售平台保持一致。
为什么要做这件事呢？
主要原因是：尽量保证商家内部的核心资源与各销售平台保持一致，能够较为实时有效的了解各平台的销售情况，了解核心资源的消耗情况，作为运营调整的基本依据。
这里的这里简单举一个例子：
假设公司参与了一个京东平台的预售活动，顾客付完定金，公司肯定得做库存保留，顾客付尾款的时候才能保证有货，防止其他渠道占货，所以需要内部同步的管理库存。
因为各平台是隔离的，整个销售过程由平台接管，所以供各平台销售的库存是各平台独占的；所以有同学会问，这种情况下，不会存在其他渠道占货情况。
可问题是其他渠道真的想占货的时候，想从京东平台拉货回来到其他平台售卖时，不知道京东销售到底占了多少货，还剩余多少，那就肯定不知道能从京东拉多少货给其他平台。
当然，这里的核心资源主要就是“库存”，商家这么做还有一个核心的目的：运营智能化，能够知道各平台销售情况，库存剩余情况，做到库存的动态智能分配。
另外，还有一种情况，部分商家为充分售卖货品，因为无法实时和平台联通管理库存，会虚高供给库存。例如，商品A总库存实际就100个，结果商家同时给天猫供货70个，两个平台加起来就有140个。这种情况下，就需要较为实时监控销售情况，保证能够及时作出调整。
2. 其他调度
1)履约调度
销售订单的履约相关涉及的内容很多，包含了“发货履约”、“安装履约”、“发票履约”等核心调度。但一般商家主要只涉及“发货履约”，那这里核心说下发货履约。
当前各大平台与商家合作模式中，关于发货履约的方式也多种多样，大致可分为四类：
如京东一样，使用京东物流上门取件发货；
天猫菜鸟一样的平台，分配第三方承运商上门取件发货（各平台都存在这种模式）；
商家自主联系承运商发货；
商家自有物流，自主发货。
上门取件发货的模式，下发分拣、出仓指令，等待快递员上门揽件；
自主联系承运商情况，下发下发分拣、出仓指令的同时，会连通快递公司api下快递单；
自主发货的，可能就下发给自己的物流系统一个整体指令，由物流系统完成后续的履约过程。
调度过程中，“自营订单”还承载着一个商家与外部平台联通的角色，互通对应的履约过程信息，以供用户在各电商平台查询，以及商家内部查询与处理。
2)财务调度
“自营订单”是订单运营操作，履约操作的轴心；联系着内部与外部平台，同样也联系着内部各系统。
在财务流程中，公司记账往往比较繁复复杂，记账节点多，触发事件不一，如：
一般公司销售订单支付完成后，公司未收到货款，公司就会记录应收账款；这个时候，“自营订单”就联通了销售平台与内部财务系统；
商品出库时，需要记录商品账；这过程中，“自营订单”就联通了内部仓库系统与内部财务系统；
顾客确认收货时，又会记录一次账款往来；同理，是联通销售平台与内部财务结算系统。
这些节点的调度，都是由“自营订单”作为轴心来调度串联各业务环节。
3）结算调度
又如结算流程，这里可能涉及两块：
商家与销售平台的结算；
可能还涉及与更上游的供应商结算。
商家与上游供应商结算，往往是周期性的，但周期内哪些订单应该结算；仍然是基于一定的业务节点的，这里的调度，也是由“自营订单”作为轴心来调度串联各业务环节。
商家与电商平台结算，来得更为直观，因为对应的结算往往是实时分账，这就涉及分账结算的调度。
具体各平台是以哪个节点为分账结算点，结算货款如何拨付，后续如何对账，“自营订单”都会参与其中，或是作为调度的轴心，或是数据的提供者。
逆向业务
当前各大电商平台的逆向服务，可简单分为三类（部分公司还存在修改订单，保险理赔，安装维修等业务，这些流程较为偏僻，大部分商家不涉及，暂时不做分析）：
退货退款请求：无论何种原因，顾客退回货物，商家退回货款。
仅退款请求：货物存在一定瑕疵，顾客要求补偿部分货款。货物仍属于顾客。
换货请求：换货请求较为复杂，指的是货物置换，不涉及款项。商家与顾客虽然不涉及款项，但商家内部处理时，还是涉及新单、旧单的内部换算。因为可能存在换货前后的商品sku是不一致的，尤其是穿戴类商品，更换颜色、更换尺寸的情况。
逆向流程中，分模块其实是比较难的，因为各流程相互交叉，这里先按照主次强行分为两块：
核心模块，请求调度过程，管理商家&用户&平台三者之间的相互沟通，以此为整个逆向模块的引擎来推动逆向业务的推进与完成。
在请求调度过程中，同时延伸内部的“逆向交易调度”“逆向履约调度”“逆向结算调度”“逆向财务调度”。
但由于两块交互太过密切，用三张简单图进行介绍：
退货请求调度简略图（实际过程太复杂，这里只是简略画图）
仅退款请求调度简略图（实际过程太复杂，这里只是简略画图）
换货请求调度简略图（实际过程太复杂，这里只是简略画图）
这些过程有两个特点：
商家处理内容复杂；且操作人员角色繁多，涉及客服，物流，仓库；每个商家操作的节点，往往又都涉及后续的调度；
各平台往往是偏用户而压商家，所以这些过程中，商家需要更为细致，往往需要添加各类监控预警机制。
逆向业务中流程看似繁复，梳理时，需要注意主次，然后逐步分析即可。
把握核心轴心-请求调度。梳理清楚商家&平台&用户三者在流程中的角色，完成整体流程的串联。
分析每个节点，商家的工作任务，后续任务，然后联通请求调度各节点与各类交易、履约、财务、结算之间的调度。
完成整体分析梳理。
以上只是个人针对商家端内部“订单中心”搭建的简单业务分析。
当然，因为这个系统终究还是属于中台或者后台系统，真正要去搭建这个系统，就需要先把流程梳理完成后，逐步提炼抽象，最终形成比较完备的产品分析方案，逐步实施。
另外，公司一般是逐步与各平台合作，销售量来看的话，也可能是逐步增加的。所以，产品的搭建也是步步为营，很多操作可能一开始就是在电商提供的开放平台上操作的，内部人工联通；待到商家系统搭建完成后，再逐步切换到内部系统。
