自营订单业务逻辑分析步步为营逐步实施

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