快好知 kuaihz

电商系统前后台设计全面解析——订单管理

订单管理系统是电商系统中最为复杂的系统,其作为中枢决定着整个商城的运转,我们设计商城的目的就是让用户下单,然后发货,然后订单完成。订单系统是电商系统最重要的模块,没有之一。

订单系统设计的好坏,决定了商城的可用性,与使用价值;订单系统贯穿于整个商城系统,其他各个系统的设计也是为订单系统提供数据支撑。订单的核心是流程问题,涉及资金流、物流、信息流,从用户提交订单的那一刻到订单完成,到售后,都需要订单管理系统来管理。

讲解订单管理系统就必须从它的流程来说,订单订单从无到有、流程分为这样几个流程:

阶段一、订单数据流程:用户选择商品信息,优惠信息等,生成订单价格,点击提交订单,这一非常小的一步,需要后台处理很多的数据,将最终的订单金额计算出来。这属于订单的第一个阶段;

阶段二、订单物流流程:用户支付成功,到发货,收货,订单完成;这属于订单的第二个阶段,如果没有异常流程,订单到这里已经完成,正常的订单分为这两个大的流程;

异常阶段、售后流程:用户在以上两个阶段中发生取消支付、退款、退货、换货等售后服务,这时订单就会走异常流程;异常流程要比正常流程还要复杂。

不管订单系统系统如何复杂,如何拓展,我将订单流程分为以上三个部分,而这三部分之间相互独立而又相互联系。第一阶段用户提交订单,系统处理订单数据;第二阶段付款成功,订单走物流系统,直到订单完成;第三阶段是从一或者二阶段中产生的异常流程

一、订单数据流程

这个阶段线上的操作并不是很多,主要是体现在系统对数据的处理上,我们在商城选择想要的商品,选择商品规格、数量、优惠券、然后系统会为我们生成最终的订单价格。这个流程属于系统内部的数据处理流程,需要调取系统各个模块的数据,流程如下:

首先,是用户在商城内选购商品,这个阶段可以叫做前置用户行为。

然后,是系统调取各个系统的数据,计算订单的最终价格,这个阶段可以叫做后置数据处理。

最后,是将订单价格在用户端显示,这个阶段叫做表现层显示。

1.1 前置用后行为

这个过程比较简单,是属于订单流程的前置条件,只有触发此行为,才会生成订单,系统才会记录订单数据;

需要流程如下:

用户进入商城,浏览商品,进入商品详情页面,点击购买商品,选择商品规格、数量,点击提交订单,然后进入订单详情页面。

1.2 后置数据处理

订单详情页面系统会做大量的数据处理来计算订单的最终价格,而订单的最终价格也是可以随之变动的。比如:当用户选择是否使用优惠券,修改商品数量,订单的价格都会发生变化。

后置数据处理的流程如下:

1.2.1 从商品管理系统获取商品的SKU信息

首先,第一步会先获取用户所选择商品的SKU信息,用户选择不同的规格对应不同的SKU信息,而不同的SKU对应不同的商品价格,根据用户选择的规格和商品数量生成商品总价。

订单详情页面展示商品数量、规格信息、商品总价格。

1.2.3 从会员中心获取会员权益信息

第一步、根据当前用户的信息:获取用户的成长体系——也就是用户的会员权益,会员等级是多少折扣,会员等级折扣金额的计算金额是在商品总价的基础之上的。

1.2.4 从物流中心获取运费信息

第二步、获取用户的运费信息:因为添加商品时肯定是要选择运费模板,根据运费模板和用户的收货地址计算运费,若是商品统一包邮,或者促销活动条件满足包邮,则不计算运费。

1.2.2 从促销中心获取商品的优惠信息

第三步是从促销中心筛选当前商品是否在已有的促销活动之下(创建促销活动需要指定商品):若有所属的促销活动则在用户端显示所有的促销活动、若没有所属的促销活动则获取商品所有可用的优惠券,并展示所有可用的优惠券。

(促销活动与优惠券不可以同时使用,首选判断商品是否有促销活动,若有促销活动并且当前状态满足促销活动规则,则优惠券不可用;若有促销活动,但是当前状态不满足促销条件,则优惠券可用;若选择了优惠券,即便订单由于变动满足促销活动条件,促销活动优惠不生效。)

订单详情页面显示商品当前的促销活动,可使用的优惠券信息,同时显示已经获取的优惠信息:什么优惠券优惠多少金额?或者,什么活动优惠多少金额?

优惠金额的计算是在商品总价的基础之上的。

说明:到此为止,订单金额已经计算出来了,我们可能知道哪些地方需要计算优惠金额,但是关键的问题在于最终的优惠金额如何计算。

订单金额的计算有两种方式,不过一般来说使用第一种方式,第二种方式仅做了解。

(1)统一以订单金额为基础:就是所会员权益、优惠券金额、促销活动金额的计算、都是在订单金额的基础之上的。

例如:商品SKU价格45元、数量2、运费10、会员优惠8折、促销活动优惠5折、会员权益优惠15元,那么最终的订单价格为?

我们首先要定义“订单金额”,订单金额=商品SKU价格*购买数量+运费=100元;

订单金额为基础,计算其他费用,那么应支付就会这样:

应支付金额=订单金额-优惠券优惠金额-促销活动优惠金额-会员权益优惠金额

现在的问题关键在于优惠金额的计算,如果是满减就好说了,优惠金额一定,打折都是以订单金额为基础的。

应支付金额=100-(100*(1-0.8))-(100*(1-0.5))-(15)

也就是说,每项的优惠金额计算都是以订单金额为基础进行计算。

一般来说用这种方式比较好,能够很好的体现每种金额优惠的价值,并且拓展性强,计算的顺序不会影响最终的优惠效果,因为都是在订单总价的基础之上的,并且易于理解和计算。

(2)以顺序计算订单总金额:

——就是每一笔的计算都是在上一步金额的基础之上的,具体算法如下:单价45元、数量2、运费5、会员9折、优惠8折。

首先,加上运费((20*2)+5)=45元

然后,在上一步基础上减去会员折扣45-45*0.1=40.5

最后,在上一步的基础上减去会员权益的优惠金额40.5-40.5*0.2

这种方式不建议使用,计算顺序会影响最终的优惠金额,比如:先计算促销活动的优惠,和先计算会员权益最后导致的订单价格是有很大差别的

1.3 表现层显示

当系统计算出订单金额,就需要在页面上显示,订单详情页面要显示最终的订单金额、同时还要显示:

物流方式,运费

优惠券信息,优惠金额

促销活动信息,优惠金额

会员权益,优惠金额

二、订单物流流程

用户提交订单就进入了物流流程,这个阶段主要体现在商品的物流流转以及物流信息的变更和记录,订单状态的管理。

订单物流流程如下:

2.1 用户提交订单,生成待付款订单

用户提交订单之后,虽然没有支付,但是系统就会生成待付款订单,对于生成订单这个地方主要涉及这么一个问题,就是订单拆分的问题。

2.1.1 订单拆分

可能大家也都知道订单拆分,而怎么拆分,为什么拆分,大家可能都不清楚,但这也是我们需要知道的。

讲一个小故事:首先我们先来说说订单这个东西,现在有这么个情况,小张在商家小红的店铺购买了一双运动鞋,那么商家小红肯定是要为小张发货的,所以他就需要联系物流公司。

比如申通小李,为了跟踪这双运动鞋在系统中的物流情况,在发货的时候需要为鞋子匹配唯一的订单号和运单编号(订单号电商系统生成,运单号快递公司生成),为什么有订单号了还要运单号呢,订单号是电商系统用于记录当前小张提交的这一笔订单信息,而运单号是为了跟踪鞋子的物流信息。

过了一段时间,小张又在小红这里买了一双运动鞋,不过同时买了一个皮球,方便玩耍,所以将一双鞋、一个球加入购物车,统一购买。然后提交订单,生成一个订单号。

这个时候虽然是两件商品,但是小红为了图方便,就将皮球和运动鞋放在一起发货了,那么申通小李看到的其实还是一个包裹。

但是他不知道的是,包裹里面有两个物品,所以就会创建一个运单编号,这也是为什么我们在网上购物的时候明明买了两件商品,但是收货信息只有一条,因为放在一起了。这种情况是一个订单编号,一个运单编号,两件商品。但是在运输的过程中由于鞋和球放在一起了,车辆过于颠簸,鞋子就把皮球炸爆了,当小张收到货后非常生气,小红也感觉非常的惭愧并为小张做售后。

又过了一段时间,小张还是在小红这里买了一双鞋和一个皮球,但是为了防止拿到货时皮球又被鞋子炸爆,所以小张要求小红将这两件商品分别发货。

小张同时又在店铺小王的店铺里买了两个篮球,那么这一次买的有点多——一双鞋、一个皮球、两个篮球,并且还是在两个店铺里面,因为电商平台需要为每个商家进行资金结算,所有需要通过订单号记录每个商家的订单信息。但是,显然如果这次所有的东西都用一个订单号那就乱了,因为结算是通过订单查询商家信息每笔订单对应一次结算,两个商家这笔订单的钱应该结给谁呢,所以这个时候就会出现第一次拆单。

如果用户一次提交订单,但是订单包含多个商家,或者商家和平台自营同时出现,那么就需要拆单。

小张提交的5件商品分为2个订单,每个订单号对应一个商家,同时如果小张另外在平台自营买了一件商品,道理也是一样,也需要拆单。

因为平台自营的商品是不需要结算的,如果把平台的订单放到商家一起,那么给商家结算的时候,岂不是平台卖得东西算到商家头上了。

回到上面,刚说拆分成了两个订单:第一个订单我们叫他订单号001,这个订单下面是商家小红的商品,一双鞋,一个皮球;第二个订单号002,这个订单下面两个篮球;小红将这两件商品分别发货,于是申通小王发鞋子,另外喊来小王的同事申通小明发皮球。

显然我们就知道了,鞋子会对应一个运单号,皮球也会对应一个运单号(也就是二次拆单),这两件物品的物流信息分别记录。但是,这两个物品对应的是一个物流单号001,也就是说一个订单,一个订单编号下可能对应多个运单编号。

同时也就可以解释这么一个现象,利用订单编号是查询不到物流信息的,只能靠运单编号(叫法问题,运单编号也叫物流单号),想一下我们在购物时看自己的未收货商品时,我们可能就会想到,每一条信息的展示是对应一条运单号的,而上下排列的两件商品列表,很有可能订单编号是相同的。

也就是说,我们在购物车购买多个商品提交订单时,可能会有多个订单号(一次拆单,拆业务订单,原因上不同商家、平台所导致的),同时一个订单号可能会有多个运单编号(二次拆单,拆发货单,用户端拆开显示)

以上步骤是生成订单

2.2 用户付款完成,待付款订单流转为待发货订单

提交订单系统就会生成订单,此时订单是待付款订单用户付款完成之后,流转成待发货订单。而当用户提交订单长时间没有支付的话,订单就会自动取消,生成已取消订单。同时用户对于待付款订单也可以主动取消,生成已取消订单

用户可以对待付款订单进行付款操作。

2.3 后台选择物流进行发货,待发货订单流转成待收货订单

用户付款完成之后,后台就会显示买家已付款,这个时候就需要进行发货,发货需要填写运单编号、物流公司,运单编号物流公司提供。

发货完成之后系统就会跟踪物流信息,同时订单状态变为待收货状态。

用户可以对待收货订单进行收货/申请退货操作。

只要商品发货完成,用户以后都可以查看物流信息。

如果用户付款之后但是还没有进行发货,用户可以执行退款操作。

2.4 用户进行收货,或者时间段内自动收货,待收货订单流转为已完成订单

用户通过查看物流信息,进行线下取货,确定商品完好之后可以进行确认收货操作,确认收货之后,订单变已完成状态。

用户在确认收货操作之前可以进行申请退货操作,却已经确认收货则不可以申请售后。

三、异常阶段、售后流程

在整个购物流程当中除了正常的流程,有时候还会后异常的流程,这些流程会改变订单应该有的流转状态。

3.1 取消支付

用户提交订单但是取消支付:

用户提交订单的时候系统就会同时生成待付款订单,这个时候拉起支付页面,如果用户支付成功,订单流转为待发货状态,如果用户支付失败或者退出支付,那么订单就会保持待付款状态。

对于待付款的订单用户可以继续进行支付,一般来说待付款是有支付剩余时间的,就是在一定时间内如果用户没有支付成功,那么订单就会关闭,流转为已关闭订单,对于已经关闭的订单用户仅可执行删除操作。

对待支付订单用户可以主动取消订单,生成已关闭订单

3.2 退款

用户付款完成在没有发货之前申请退款:

用户付款完成,订单就会流转为待发货状态,这个时候后台是要准备发货的。那么在用户付款之后,商家发货之前,这个时候用户可以申请退款。

申请退款需要填写退款理由,然后提交商家审核,如果是多商户,所有的售后流程都由商家来进行审核,平台无需干涉。后台会看到用户的审核状态为申请退款中,这个时候商家要确定是否已经发货了,没有发货的话同意退款,资金按原路返还给客户。拒绝申请需要给客户说明拒绝理由,比如订单已经发货,无法退款。

3.3 退货

发货之后,用户在未确认收货之前申请退货:

当商品发货,但是用户未确认收货前可以申请退货,申请退货一般是在用户已经收到货了,但是对商品不太满意。

比如:衣服不太合身,这个时候就需要申请退货,首先提交退货申请,填写退货原因,后台初步审核通过后,订单状态变为待退款,退货订单用户联系快递公式发货,填写发货信息,主要是快递单号,当商家收到货后会查看商品是否完好,确认后,在后台执行确认退货退款操作,资金自动返还给用户

3.4 换货

发货之后,用户在未确认收货之前申请退货:

换货的流程与退货相似,用户申请换货,审核通过后,用户进行发货,商家收到货后订单完成;在从新为用户进行新的发货。

四、线下服务订单

线下服务订单就很简单了,用户付款完成系统会生成唯一的核销码,比如:6为数字,然后用户线下到店消费,出示核销码,商家进行核销,订单完成。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:电商  电商词条  前后台  前后台词条  解析  解析词条  订单  订单词条  全面  全面词条  
设计

 网页设计正在失去灵魂

推荐语:如今,产品首页设计趋同的现象愈发常见。是什么让自诩为创意工作者的设计师们走向了同一个方向呢?让这片文章提醒设计师们,应该打破现成的设计框架,不要让我们的...(展开)