【供应链架构day8】履约系统的架构长什么样子:从需求开始讲起

2020-03-06 投稿人 : www.neuun.cn 围观 : 708 次

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

Operation timed out after milliseconds with 0 out of -1 bytes received

?“从系统层面来看,一个实际订单将经过从销售平台到最终用户收据的10多个履行节点,包括销售平台、订单转换中心、履行系统、中央库存、配送系统、仓库路由中心、仓库/新零售系统和其他系统。因此,履行过程的核心要求是协调和顺畅。只有当所有系统相互配合,订单自始至终顺利执行,才能保证在约定的时限内完成。任何一个节点的卡住都会导致履行时限的延长,影响客户对平台的信任。”

▲?实物订单完成的全过程”1。新订单:订单系统收到的新订单的状态。根据业务,有两个逻辑流程:来自三个平台(如天猫和京东)的订单,客户在销售平台上完成交易后的状态,订单系统从销售平台接收同步订单;对于自营平台订单,订单系统将在客户提交订单后生成新订单。但是,如果订单是在线支付订单,则需要先付款,订单才能继续向下流动。

2。订单分割:为了获得更好的购物体验,大多数电子商务平台都支持合并支付提交。订单生成后,按照商户、仓库、商品、金额、物流等规则进行拆分。并以多个子订单发货。

3。订单预分配:为防止超卖,应尽快对已下订单进行库存预分配,以防止库存被其他订单占用。仓储过程由中央库存提供服务。订单预拆分可以提前锁定订单发货仓库。如果订单的核心信息发生变化,仓库可以重新拆分。如果企业允许将一个订单分割到多个仓库进行交货,则需要再次分割该订单。应该注意的是,只有满足实际库存的订单才能被成功地预分割。预售类订单可以在订单拆分后停止等待,也可以在真正的存货采购入库后转移。

?4.订单冻结处理:一些不符合业务规则的订单,如可疑的恶意订单,在订单系统中被标记为冻结标记,在人工批准之前不能发布。如果这显然是一个恶意的命令,该命令将被取消。

?(订单拦截规则应根据不同行业、公司和业务的实际业务情况进行分类,此处不再详述。

?另外,是先占领阵地还是先拦截订单?木笔认为仓库应该先分开。尽管恶意订单可能会占据部分库存,但订单会在处理后被取消并释放。这比一些可疑但非恶意订单因为被拦截而未被分割的情况要好,因为这样会导致后续库存被其他订单占用并导致超卖。)

5。合并订单处理:为了降低货运成本和仓库运营成本,在一定时间内满足合并条件的订单在订单系统中被合并为一个订单,并交付至仓库/商店进行装运。

6。订单审批:在某些业务规则下,手工审批后订单可能需要继续流转,如冻结订单和客户有特殊需求的订单。为了提高绩效效率,其他订单可以自动审核,无需人工处理。当然,这个审计功能可以直接放在客户服务绩效系统中,也可以为客户服务系统调用提供服务。

7。订单重组:如果客户服务修改了订单接收地址、货物和数量等相关信息。在手工审批过程中,影响预入库的结果,需要重新预入库,并清除原来的预入库结果。

8。订单分配:由于该国所有仓库的物流都是单独承包的,因此根据仓库的位置,承包的物流可能会有所不同。因此,在交货仓库被定义之后,履行系统调用由物流配送系统提供的物流服务来匹配物流供应商,并调用物流公司接口来获得电子面板的相关信息。

11.生成批领料单:系统或仓库操作员将订单打包(如相同的物流公司、相同的领料区等)。)可以在成功定位后一起挑选,以生成批量挑选订单。在非自动化操作模式下,一个批次领料单中有多少个订单是合适的?通常,拣选容器的上限可以根据拣选器推动拣选容器一次的性能来设定。例如,如果一个取货小车可以容纳12个取货集装箱,则一个批量取货订单可以设置为包含12个订单。

12。订单打印:订单员根据批量拣货单打印出每张订单的正面单、纸质发票和发货单,并根据订单进行整理和存储。

13。拣货:拣货员根据批次拣货单拣货任务(纸张或PDA),并根据拣货路径完成拣货任务(如果拣货区域太大,批次拣货单可以拆分成多个拣货任务,拣货可以按区域完成)。如果同时存在分拣模式,提货人将在提货时将货物分拣至每个集装箱,并在提货完成时完成分拣。如果采用先拣后拣的方式,拣货人拣完货后,货物将被收集和分拣。

14。审查和包装:审查人员将根据订单详细信息审查并确认货物,然后将货物交付给包装人员进行包装并粘贴物流运单。

15。订单发货:发货人将包裹交给快递员收取,并在系统中操作交货,从仓库发送订单。发货后,如果实际发货物流有任何变化,实际物流公司和物流单据号将被送回执行系统,执行系统通过订单转换中心将物流信息送回销售平台。

对于新零售下的自我推广业务,店员会打包,等待顾客到店内进行自我推广。

16。物流提货:收到包裹后,物流公司的快递员将在系统中操作提货。提货操作信息可通过配送系统调用物流公司提供的界面获取,分析后返回订单系统。

17。物流运输:包裹从物流公司的分拣中心配送。

18。物流配送:包裹到达配送站后,配送人员会按照路线将包裹送到门口。

19。物流签收:包裹被交付给客户,签收完成。

?以上是一个实际订单的完整流程。虚拟订单需要经过另一个系统流程,因为它们不涉及仓库交货和物流配送。"

03?订单属性

?需要将订单发送到每个系统,以获取订单执行整个流程中的各种执行信息,因此订单信息应该尽可能全面。以下是订单的一些核心属性:

?1.基本信息:订单号、来源号、销售平台和销售店、下订单时间、订单状态、支付方式(网上支付/货到付款)、买家信息、配送方式(物流配送/自助提取)、下订单账号、订单类型(实物订单/虚拟订单);

?2.财务信息:支付方式(微信、支付宝、银行卡、现金.)、支付平台、支付账户(微信账户、支付宝账户)、商户订单号、支付序列号、订单应付总额、已付金额、货到付款金额、商品总金额、运费、客服增减金额;

?3.收货信息:收货人、收货人的手机\电话号码、收货人的省份、收货人的城市、收货人的区\县、收货人的乡镇、收货人的详细地址;

?4.发票信息:要开票的订单应包括发票标题和发票详细信息:

发票标题信息:发票类型(纸质/电子)、发票号码、标题、发票税号、公司地址、电话号码、银行账号、发票金额、发票人

发票详细信息:详细类别详细信息、包装规格、包装单位、数量、含税单价、含税金额、税率;

?5.促销信息:促销类型(优惠券、积分、全额折扣等)。),促销标识,金额;

?6.物流信息:发货仓库、系统指定物流公司、系统指定电子运单

▲? 订单履约状态说明

?

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望着女孩不停抬手擦拭眼泪的背影,陷入了沉思….

?

? 众生皆苦,万般无奈。所有的美妙光鲜背后,都有着不为人知的难言苦楚。不过因果交加,如果不是一次次的艰难困苦,人生又当如何进阶?眼前的坎,掉下去了叫入坑,自己爬起来抹平了,就变成了自己的路。要相信所有让我们变好的选择,过程都不会很舒服。

?尼采说:凡不能毁灭我的,必使我强大!

?

=更多文章请参考: 《中国互联网业务研发体系架构指南》

=更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光':

公众号:关注更多实时动态 更多权威内容关注公众号:软件真理与光