加入收藏 | 设为首页 | 会员中心 | 我要投稿 源码网 (https://www.900php.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 创业 > 点评 > 正文

“先试穿再购买”的电商平台订单模块的重构心得

发布时间:2020-03-01 22:09:34 所属栏目:点评 来源:做站长
导读:副标题#e# 当原有系统过于冗杂且原有功能不再适用当前需求时,重构系统的需求油然而生。于是笔者就和我们分享了订单管理模块重构的心得。 从事电商行业,是一个女装类自营电商平台,结合虚拟试衣技术,和线下试穿服务,为用户提供一种不用出门就可以享受逛
副标题[/!--empirenews.page--]

当原有系统过于冗杂且原有功能不再适用当前需求时,重构系统的需求油然而生。于是笔者就和我们分享了订单管理模块重构的心得。

“先试穿再购买”的电商平台订单模块的重构心得

从事电商行业,是一个女装类自营电商平台,结合虚拟试衣技术,和线下试穿服务,为用户提供一种不用出门就可以享受逛店试穿的服务。

用户首先购买平台会员,在会员有效期内可以在平台上将喜欢的衣服加入试衣盒子,盒子满5件时可以在不付任何费用的情况下寄给用户,用户拿到盒子后,试穿这些衣服,再决定是否购买,然后将不买的衣服装入盒子再寄回平台,往返包邮。

这篇文章产生的背景,这篇文章是在做订单管理模块重构的时候产生的,好像所有系统建立的第一个版本都是暂时符合现在版本的APP,然后需求越来越多,不停的往原来的系统上加功能。

有一天终于发现加不了了,老系统由于可扩展性太弱,承受不了奇奇怪怪的功能。

于是开始想办法一个模块一个模块地梳理,开始着手重构的事情。

但是此时重构已经工作量巨大,任何一个功能都已经在线上运行,一个都不能砍,耗时巨长。

所以我认为,重构的事情越早进行越好,做不到第一个版本就规划得很清楚的时候,功能越少,越没有历史遗留问题的时候,做重构的事情越好。所以就借订单部分重构的档口,来小结下订单管理相关的问题。

重构必要性:

  1. 当前将单一原始单拆分不同状态的产品形态已经无法覆盖所有交易类型的订单处理。
  2. 将订单拆分为不同类型,不同类型分别定义后台状态,方便不同业务部门有针对性的处理订单。
  3. 订单拆分将可扩展性增强,随着业务形态多样化,可以在不同类型的订单及其状态上优化,如“7天无理由”需求可能涉及的“售后”类型的订单问题。

重构步骤:

  1. 原始订单拆分为不同类型的订单
  2. 分别梳理不同类型订单的流程和相应状态
  3. 类比常规电商各节点把控的关键信息,并根据业务特殊性将其移植嫁接

先来梳理下常规电商的状态流转:

1. 待付款:

用户选好商品下单,但未付款的状态。

预判到用户下一步可能是付款行为,所以在下单同时锁定库存,但由于用户未付款,我们不知道用户是否会买下,所以仓库只是暂时替用户留货,但不会扣减,当用户付款后,货才会真正成为用户的货。

但是由于用户有可能下单但迟迟未付款,被占用的货不能卖给其他用户,造成了损失,所以待付款订单会有实效性,只为用户保留一小段时间。

这段时间的长短根据不同平台有不同的考量,比如外卖平台由于时效性更高,可能只保留15分钟的订单;对于服装电商对时效性要求也是很高,所以通常都会给出24小时的锁定时间,24小时后再不付款就自动取消订单了。

2. 待发货:用户付款后,商品未发货的状态。付款后,库存扣减,仓库备货。

3. 待收货:仓库包好商品并交到快递小哥手中,订单开始更新物流信息。

4. 待评价:用户确认收货后,钱款打给卖家,用户可以评价订单。

5. 售后:用户付款后,不管货有没有发出,用户都可以将钱款退回,此时的退款或退货申请均作为售后状态,创建相应的售后工单,会有对应的售后服务人员跟进。

值得注意的是用户在每个订单状态下的退款和退货行为:

首先,下单未付款状态下,用户可以直接取消订单,订单终态是“已取消”,不会再流转至后续的订单状态中;

在付款后,未发货的状态下,用户申请退款可以直接退,仓库拦截出库成功就可以直接退款,订单终态也是“已取消”或者叫“已关闭”;

在发货后,用户再取消订单会直接走售后流程,创建退换货单,推到仓库,仓库根据退换货单给退回的货品审核并做入库处理,再给用户替换出新货。

以上是常规电商的订单状态的梳理,下面来看看我们平台的订单中,哪些流程可以直接抄,哪些流程具有自己的特点。

首先,我们的盒子,是一去一来(平台 → 用户 → 平台)是一个正常的流程,因为我们提供的服务是让用户挑选5件衣服,打包成一个盒子,然后寄回家中试穿,试好后再决定是否购买,然后再把不喜欢的衣服退回来,而且往返运费全免。

经过一定的调研和统计,最终用户5件衣服全买的概率是很小的,留货量在2、3件的用户居多。

也就是说,退货的行为是一个常规的行为,退货发生的概率可以达到九成,盒子的一个来回也可能不涉及交易,而交易订单也有可能不与盒子关联(比如购买会员服务或其他增值服务等)。

所以我暂且把盒子订单和交易订单分开,此文主要详细说盒子订单。我方的盒子订单正向流程如下图所示:

“先试穿再购买”的电商平台订单模块的重构心得

一、待发货状态

在一般电商中,用户选货后进入“确认订单”的页面,目的是为了让用户检查所选SKU是否有误,以及给用户一个最终决定的过程,因为他的下一步是去付款,要谨慎为好。当用户确认订单后,生成交易单,同时锁定库存,用户在一个时间段内支付后库存扣减,取消订单或超时未支付则锁定库存释放。

与一般电商相同的是,订单创建后,要占用实际的库存,所以看起来确认订单同时锁库存的操作是相同的。

但是,订单创建后用户不需要支付任何费用(因为本质是试穿,到货才可能产生交易),不生成支付单,这是相比于一般电商不同的地方,就是我们在这一步没有“从支付单创建到支付/不支付”的过程,也就是锁定库存的过程。

因此,我们可以不做锁定库存的操作。

但是这会遇到的问题是:用户在选货到创建订单那一步,可能会发生选到的SKU被别人选走导致缺货的情况,这样就要返回重新选择,再重新生成新的订单,体验不太友好。

所以在没有支付订单的情况下,我们是否需要在生成原始订单前、在选款结束到订单最终确认前做库存锁定操作?

锁的话锁定多久?会不会让别的想要这件SKU的用户想选的时候可用库存已经没了,而犹豫半天的用户最终又没要,为这部分用户锁定库存造成了资源的浪费?

(编辑:源码网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读