【申明在先】：原文中全部工作流程及系统设计方案均由电子商务作业流程更新改造，不具备一切商业服务共性。
许多企业，除开直营商城系统之外，也有其他方式（如天猫商城、京东商城等），好几个平台的订单该怎样集中化履约？订单履约全步骤是什么样的？然后小Q的小故事，为您公布多服务平台订单履约系统的系统设计理念。 因为篇数关联，文中仅详细介绍正方向履约步骤，反向步骤置放后面文章内容中升级~
「 下列情节及角色均为创作者虚构，若有类同，如有雷同：
小Q：某药业互联网公司后台管理产品运营，下手整体规划构建企业的供应链管理及电子商务后台管理有关系统」
三九极寒，一夜北风吹，好朋友圈中国内各地网民都是在迎接2019年的第一场瑞雪，希望明年有一个好奔头，唯有皇都空中一片孤寂，冷风席卷另加雾霾天气猖狂，气体弥漫着流行性感冒的气焰嚣张，温度比昨日愈发冰冷，可见度也低了许多。西北风呜呜呜的搅面划过，从头发到颈部，但凡曝露在外面的身体一部分都好似冰刀刮体，冻的直疼；口中哈出的白气像一把还击的利刃，半空中凝结，随着渐渐地消退沦落雾霾天气的奴隶；鼻内里弥漫着尘霾的糊味，随意嚼一口都能感覺到牙缝里的碎石子刺啦直响。尽管衣着羽绒衣，依然能感受到凉气由外部内快速渗入，若不是有棉帽和鸭绒护体， 做为北方人的小Q与如此极端的气温压根斗不赢10分鐘。
01 订单履约系统构架及关键作用
此次来北京市外出的任務是给技术性GG们解读订单履约系统要求。
“所说订单履约，就是以订单买卖造成之后，到客户最后接到产品，包含售后服务的整个过程。因此大家的订单履约系统的关键达到目标是能高效率且全透明的进行订单履约整个过程，确保客户体验。”
“在宣布解读要求以前，我们先来了解一下企业的业务流程现况，”，小Q感觉就算是程序猿，也十分必须先了解一下业务流程环境，以市场需求为立足点，才可以设计方案出更迎合业务流程的系统，并且也会愈发有参与性。
“①我们有两类业务流程：三方电子商务平台和直营服务平台；三方平台是大家在天猫商城、京东商城等服务平台上切的电商平台店面，已有服务平台是我们自主构建的商城系统，和一些对外开放的sdk、API等方式；
②我们中下游有好几个库房，覆盖全国全国各地，各地派送地区不一样；
③直营服务平台上，我们也有一些新零售业务，适用客户到店自取，及其极速送到的派送业务流程。”
“融合这种现况，我给大伙儿解读一下订单履约系统的设计构架”，小Q打开了优先写好的prd。
▲ 订单履约系统构架设计图纸
“ 从订单数据信息左右传安全通道看来，全部订单履约从上向下涉及到3层系统：订单变换中心、订单履约中心、仓储物流路由器中心。
订单履约系统的上下游是订单变换中心，用于连接每个销售网站，由于各网站的订单构造各有不同，为了更好地能统一在履约系统中对订单开展管理方法，确保订单内部结构运转的规范化，不会由于某一服务平台的更改而动了主体工程，因此在订单变换中心中对于每个服务平台配备不一样的电源适配器，将订单规范化之后再与履约系统开展通信。必须兼容的信息包含产品、详细地址、订单情况、货运物流公司等。
履约系统的中下游是仓储物流路由器中心，用于与每个库房系统和店面新零售系统开展互动，将订单路由器派发至总体目标仓库开展生产制造，与此同时将总体目标仓库的送货信息搜集并传回至订单履约中心；
订单履约系统承担解决订单履约的整个过程，对上根据订单变换中心与销售网站开展信息同歩，对下根据仓储物流路由器中心将订单信息左右传，内部结构根据生产调度中间库存量、派送系统等好几个外部系统对订单信息开展逐层拆卸和拼装，将订单生产加工为达到履约标准的可运行命令。
依据以上构架，整理出订单履约系统的主要作用如下所示：
▲ 订单履约系统关键作用”
02 订单履约全步骤详细说明
“从系统方面看，一张实体类的订单从销售网站提交订单，到终端用户查收，会历经10多个履约连接点，涉及到销售网站、订单变换中心、履约系统、中间库存量、派送系统、仓储物流路由器中心、库房/新零售系统等好几个系统，因此履约步骤最主要的需求是协作和畅顺，仅有各系统相互配合，订单从始至终很顺畅的实行完每个连接点，才可以确保在承诺时效性内进行履约，在其中任意一个结点发生卡住，都是会造成履约时效性变长，危害的是顾客对网站的信赖。”
▲ 实体订单履约全步骤
“ 1.新订单：订单系统收到新单的情况。这里依据业务流程分成二块逻辑性解决：三方服务平台（如天猫商城、京东商城）的订单，顾客在销售网站上完成了买卖，由订单系统收到销售网站同歩的订单后的情况；直营服务平台的订单，顾客递交订单后，订单系统便转化成一张新订单，但是此订单需分辨若为线上支付订单，需支付之后能够再次往下滴转。
2.订单分拆：为了更好地更快的消费感受，绝大多数电子商务平台适用合拼递交付款，在订单转化成之后，需依照店家、库房、产品、额度、货运物流等标准开展订单分拆，分成很多个子订单送货。
3.订单预分仓：为避免超售，早已提交订单的订单需尽早开展库存量预占，以防库存量被其他订单占有。跳仓全过程由中间库存量给予服务项目。订单预分仓可以提早锁住订单送货库房，若订单关键信息产生变化，再再次跳仓。若业务流程上容许一个订单被拆分成好几个仓库送货，订单需再度分拆。必须留意的是，仅有实体库存量达到的订单才可以预分仓取得成功，预购类的订单，可在订单分拆后开展截停等候，待真正库存量采购入库之后再开展跳仓运转。
4.订单阻拦解决：一些不符业务流程标准的订单，如疑是故意订单，在订单系统中加上阻拦标识，待人力审核通过后能够再次海关放行。若确立为故意订单，则将订单撤销。
（订单阻拦标准由于领域、企业、业务流程不一样，要依据具体工作状况开展整理，没有在这儿详细描述。
此外，到底是先跳仓预占，或是先阻拦订单？木笔觉得应当先开展跳仓，尽管故意订单很有可能会占有一部分库存量，但解决完之后，订单会被撤销释放出来库存量，此类处理方法好过一些疑是但并不是故意的订单由于被阻拦了而沒有跳仓，造成后面库存量被其他订单占有而造成超售的状况。）
5.合拼订单解决：为减少运输费成本费和仓库工作成本费，在一定时间段内，达到合拼标准的订单，在订单系统中合拼为一单下达仓库/店面送货。
6.订单审批：一些业务流程标准下，会规定订单在人力审批解决后才能再次运转，例如被阻拦的订单、顾客有特别需要的订单等。为提高履约高效率，其他订单可全自动审批而不用人力一一解决。自然此审批作用可以同时放到履约系统时供在线客服应用，还可以给予服务项目供在线客服系统启用。
7.订单再次跳仓：若在人力审批解决阶段，在线客服改动了订单收件地址、产品及总数等跳仓有关信息，进而影响到了预分仓的結果，必须再次开展跳仓预占，并消除原预分仓結果。
8.订单分货运物流：因为国内各仓的货运物流是独立签订，依据库房所在的地方不一样，签订的货运物流很有可能各有不同，因此在确定了送货仓库之后，履约系统启用物流运输系统给予的物流配送服务开展货运物流商的配对，及其启用货运物流公司插口获得电子面单有关信息。
9.下达仓库：货运物流公司分派进行之后，订单履约必须的信息已拼装彻底，订单履约系统依据订单间距和货运物流信息试算履约时效性（履约时效主要运用于服务保证，为仓库波次给予参照），并将订单下传仓储物流路由器中心，经此系统路由至总体目标仓库或店面生产制造送货。
10.波次下达：库房/店面系统收到订单后，依据派送方位、时效性服务承诺、订单种类等原因将订单转化成波次，并依照出入库对策对波次开展精准定位，转化成仓库拣货每日任务。在这里全过程中，若库房零散储位库存量不够而整个储位库存量充足，会造成波次备货。
11.转化成批拣单：系统或仓库操作工将精准定位取得成功后可以一起拣货的订单（如同样货运物流公司、同样拣货地区等）装包转化成一张批拣单，在非自动化技术作业模式下，一张批拣单中含是多少订单适合？一般依照拣货员拉着拣货器皿一次特性学会放下的拣货箱限制就可以。例如一个拣货小轿车上可以学会放下12个拣货箱，则可以设置1张批拣单含12张订单。
12.订单打印出：打印快递单员依照批拣单将每份订单的快递面单、纸版税票、发货清单打印出出去并按订单次序梳理储放。
13.拣货：拣货员按批拣单领到拣货每日任务（纸单或PDA），并按拣货途径进行拣货每日任务（若拣货地区过大，可将批拣单再拆分成好几个拣货每日任务，按地区进行拣货）。倘若边拣边分方式，拣货员一边拣货一边将批拣的产品快递分拣到每一个拣货箱,拣货进行也快递分拣进行；倘若先拣后分方式，待拣货员拣货进行后再聚集开展集拼快递分拣。
14.核查装包：核查员依照订单的提交订单清单对产品开展审核确定，准确无误后交给装包员打包并黏贴货运物流货运单。
15.订单送货：发货员将包囊交给快递小哥收揽，并在系统中实际操作送货，意味着订单从仓储传出。送货之后，若具体送货货运物流有转变，传回具体的货运物流公司及快递单号至履约系统，履约系统再根据订单变换中心将货运物流信息传回销售网站。
若是新零售下的自取业务流程，则由店面营业员装包之后，等候顾客上门服务自取。
16.货运物流揽收：货运物流公司快递小哥接到快递包裹后，在系统中实际操作揽收，揽件实际操作信息可由派送系统启用货运物流公司给予的插口获得，分析完后传回订单系统。
17.物流运输：包囊从货运公司的快递分拣中心分拔传出。
18.货运物流揽件：包囊抵达派送网站，揽件员依照线路开展揽件上门服务。
19.货运物流查收：包囊送到顾客手上，进行查收。
以上就是一个实体订单的履约全流入，虚似订单由于不牵涉到仓库送货和物流运输等阶段，需走此外的系统步骤。”
03 订单特性
“一张订单在订单履约全流入中，必须生产调度每个系统获得履约的各种各样信息，因此订单信息应当越全方位越好，这儿展现一些订单的主要特性：
1.基本上信息：订单序号、由来序号、销售网站与市场销售店面、提交订单時间、订单情况、付款方式（线上支付/到付）、顾客留言板留言、派送方法（物流运输/自取）、提交订单账户、订单种类（实体订单/虚似订单）；
2.会计信息：支付方式（手机微信、支付宝钱包、储蓄卡、现钱…）、支付系统、付款帐户（微信帐号、支付宝帐号）、商家订单号、付款订单编号、订单应付总额度、已付款额度、到付额度、产品总额度、运输费、在线客服提升/免减额度；
3.取货信息：收件人、收货人手机电话、收件人省区、收件人市、收货人县区、收件人城镇、收件人详细地址；
4.税票信息：开税票的订单，应包括开票信息和发票明细信息：
发票抬头信息：发票类型（纸版/电子器件）、发票号、仰头、税票纳税识别号、公司总部、联系电话、开户银行、银行账户、税票额度、开税票人发票明细信息：清单品类清单、包裝规格型号、包裝企业、总数、价税合计价格、价税合计额度、征收率；5.营销信息：促销种类（优惠劵、積分、立减等）、营销ID、额度；
6.货运物流信息：送货仓库、系统分派货运物流公司、系统分派电子面单号、具体送货货运物流公司、具体送货快递单号、货运物流公司月付款号、大头笔信息；
7.商品明细信息：sku编码、sku名字、商品规格、市场销售价格、券后价格（各种各样折扣优惠测算完之后的价格）、总数、券后额度（券后价格*总数）；
8.订单全程跟踪信息：纪录订单履约的每一步的操作人、实际操作時间及实际操作內容 ”
04 订单履约系统情况
“订单履约系统应该是全部订单的集中地，统一管理方法订单履约的全步骤，依照订单的履约全过程，大家整理了履约系统的所有情况，及其相匹配到客户侧的展示情况，如下图所示：”
▲ 订单履约情况表明
05 订单撤销
“在电子商务系统中，撤销情景具体有3类：
①、消费者进行的撤销：顾客在局端进行的撤销；
②、在线客服委托撤销：在线客服替代消费者撤销订单，此实际操作一般在后台管理在线客服系统或是在订单履约系统中立即实际操作；
③、系统撤销：若顾客提交订单后中断未付款，或系统判断为故意订单，会全自动撤销订单。
因为订单撤销会由好几个阶段开启，在系统设计方案的过程中需要充分考虑实用性，将订单撤销制成一个公共文化服务，可供好几个系统和情景按需启用。这也是合乎SOA设计构思。”
▲ 订单撤销服务项目
“依据订单在撤销时有可能出现于订单系统工作流引擎、库房工作、派送等众多阶段，撤销订单时要依据订单所处不一样的情况实行不一样的系统解决逻辑性：
1.订单处在预分仓以前的情况：立即撤销，升级订单情况为“已撤销”，并分辨是不是必须退钱开启退钱步骤；
2.订单已跳仓，但并未下达仓库：撤销订单，并通告中间库存量消除订单预占；
3.订单已下达仓库，但并未送货：由履约系统对仓储物流系统进行了解，若仓储物流系统未发货且阻拦订单取得成功，履约系统再撤销订单，并通告中间库存量消除订单预占；
4.订单已配送但并未查收：若是直营派送，或是派送系统已与货运物流公司插口连通，则送货之后仍可以撤销订单，履约系统了解派送系统，若配送系统阻拦包囊取得成功，则履约系统升级订单情况为“已撤销”，此环节不用解决库存量；
5.订单已查收：早已查收的订单，不兼容撤销，若想将货退回，只能走售后退货流程。”
06 订单拆分
“订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。所以订单拆分也应该设计为一个公共服务。常见的拆分业务如下：
▲ 订单拆分服务
拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。拆分过程中，对订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等公共信息）：将父单信息 ** 到子单 。
2.财务信息： 订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。
3.商品信息：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。
4.促销信息：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。”
07 订单合并
“将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。
履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。
▲ 订单ABC合并为D
订单合并条件：同销售平台、同下单会员账号、同收货地址、同收货人、同手机号、同支付方式（在线支付/货到付款/到店支付）、同出库仓库、同订单类型（如普通订单、预售订单）、同客户备注（客户备注一样or无备注）、同开发票方式（都开发票，且抬头信息一样；或者都不开发票）、同配送方式（自提/配送）
合并以后，各原单作废，合并后生成一张新单继续完成后续履约过程，但要求在销售平台上客户仍看到的是多张订单，仅发货时的物流公司和物流单号都是一样的。合并订单的处理逻辑如下：
1.基本信息（下单人、收货人、渠道等信息）：取任意一张子单（因为信息都一样）
2.财务及发票信息：订单应付总金额/已支付金额/发票金额/物流运费=各子单金额相加
3.商品信息：所有需要合并的子单SKU及数量进行汇总
4.促销信息：将所有子单促销明细集中至父单中 ”
08 订单反审核
“在订单履约过程中，已经审核过的订单，常常会被要求修改信息（例如客户要求修改地址、库房要求拆包裹发货等），客服需要将订单拉回至审核之前的状态，然后修改之后重新审核下发，此动作即为反审核。
反审核的系统处理逻辑为：
①将原订单做取消处理；
②根据要求修改后生成一张新订单重新下发完成履约流程。
新订单是否需要生成新的单号？ 取决于下游的仓库/门店系统是否兼容多个相同的订单号。若兼容，则无需更改单号，若不支持，则生成一个新订单号。订单在未下发仓库系统之前，原则上无需重新生成单号，系统记录一条反审日志即可。”
09 订单暂停与加急
“在某些业务场景下，需要临时将正在履约过程中的订单暂停处理，一般由客服发起，若订单在库房发货之前，可暂停成功，将订单拦截在仓库里，等待客服下一步操作（取消暂停/取消订单/反审核等），暂停的系统流程如图所示：
▲ 订单暂停逻辑
与暂停功能类似，某些订单需要临时提升出库优先级，加急出库，故订单履约系统需提供加急功能供客服使用，一旦订单被加急，库房在出库作业环节中均优先处理。优先级越高，出库越靠前。加急的系统流程如下：
▲ 订单加急逻辑
以上暂停和加急功能主要供客服内部使用，无需对客户开放。”
此次来北京出差，小Q从酒店出发步行到办公室，区区10分钟路程，好像走了半个世纪，看着形形 ** 的上班一族在寒潮和雾霾中穿梭，每个人都包裹的严严实实，棉衣棉帽棉口罩是标配，只留一副凝重的眼神与寒风对峙，像怀揣着救世使命一般神秘。不远处一位很时尚的女孩儿因为赶路太匆忙被路旁的共享单车绊倒，刚买的热包子和红豆粥洒落一地，白色的羽绒服被污染了一大片，女孩趴在地上30秒后，红着双眼慢慢爬起来，掏出包里的纸巾将自己脸上和身上收拾干净，又礼貌的将掉在地上的包子拾起来丢进了旁边的垃圾桶，然后满脸泪痕又故作坚强的前行。小Q望着女孩不停抬手擦拭眼泪的背影，陷入了沉思….
众生皆苦，万般无奈。所有的美妙光鲜背后，都有着不为人知的难言苦楚。不过因果交加，如果不是一次次的艰难困苦，人生又当如何进阶？眼前的坎，掉下去了叫入坑，自己爬起来抹平了，就变成了自己的路。要相信所有让我们变好的选择，过程都不会很舒服。
尼采说：凡不能毁灭我的，必使我强大！
文章来源于供应链产品笔记
扫码咨询与免费使用
申请免费使用