前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >订单下单

订单下单

作者头像
普通程序员
发布2019-10-23 14:14:25
3.2K0
发布2019-10-23 14:14:25
举报
文章被收录于专栏:普通程序员普通程序员

先回想一下我们平时在网上购物的场景。

某天准备出远门时,想到没有充电宝,就打开京东或天猫超市,选择一个心仪的充电宝,“哎哟,居然还有一个10元的优惠券”,下单付款,下午快递员敲门,充电宝就到家了。

用户的一小步,系统的一大步。在用户选择商品之后提交订单的一瞬间,订单实际上经过了各系统之间的漫长回路,如图所示的订单下单流程。

(1)在订单过程中进行安全校验,主要是检测用户是否在黑名单上、用户购买行为是否正常等,当检测到不正常时,终止下单。

(2)从商品中心获取商品信息(SKU、规格、价格等)。

(3)从营销中心获取商品、订单促销信息(优惠券、促销活动),判断是否满足优惠条件,计算出优惠金额。

(4)在会员中心获取会员权益,例如平台抵扣积分、折扣条件等。

(5)在调度中心校验销售层库存,按照调度规则锁定区域库存。

(6)根据拆单规则(商家、仓库、订单类型等)将订单拆分成若干个子订单,根据运费模板计算运费,根据商品金额、运费、优惠金额计算应付金额(实付款)。

用户在瓜子下单买车远没有这么简单。二手车不是快消品,属于重决策,客户不可能在网上简单看看信息就下单。更多的情况,用户在App上浏览车辆,然后跟销售人员约定现场看车的时间和地点,看车之后再决定要不要。这个过程中,销售人员会有很复杂的撮合和客户维护工作。用户看车就买车的比率不高,加上撮合过程流程不确定(一次搞定,也可能多次带看,或者用户看上其他车了),这个阶段直接用订单来串联,并不合适。这个阶段需要更合适的做法。

一旦用户确定要买车,下单过程也很可能是销售代客操作。客户端的App能够看到订单,下单过程反而更多在销售端App上执行。

全国购的业务下单过程会更复杂,客户在异地不能现场看车,怎么解决信任问题变得很重要。客户在App上下单买车(意向),销售人员上门或者邀约客户到当地门店,对客户进行专业咨询辅导。客户向销售确定购买车,生成订单,客户缴纳意向金。

至此生成订单,此时订单状态为待付款。如下图所示,在存储的订单信息中,主要包含以下内容:用户信息、订单基础信息、收货信息、商品信息、优惠信息、支付信息、物流信息、其他信息等。订单的内容复杂精细,在存储时除了表结构的设置,还应该注意信息冗余。特别是商品信息,由于商品的内容不断编辑变化,要保存下单时的商品快照,避免过长时间后,商品信息丢失。

订单包含的所有信息内容如下

用户信息:用户账号、用户等级。

订单基础信息:父订单与子订单、订单编号、订单状态。

收货信息:收货地址、收货人姓名、联系电话、邮编。

商品信息:SKU信息、规格、商品数量、价格、商品图片、商家(店铺)。

优惠信息:优惠券、促销活动、虚拟币抵扣金额。

支付信息:支付方式、支付单号、商品总金额、实付金额、运费、虚拟币抵扣金额、优惠券优惠金额、总优惠金额。

物流信息:物流公司、物流单号、物流状态。

其他信息:发票信息、下单平台、分销渠道。

二手车一车一况,商品(车辆)的信息要丰富得多,起码得有验车报告。

【父订单与子订单】

当从购物车选中多件商品时,例如选中三个店铺中的商品,会将这次购买行为拆分成三个店铺的订单。这次整体的购买行为记录在父订单下,当系统首次提交订单结算时,会合并子订单,针对父订单进行结算。当提交订单后结算中断,或结算之后,系统在更新订单状态、物流追踪时,针对的就是子订单。

父订单与子订单这里描述更像是因为履约阶段的需要,必须进行拆分。瓜子的订单现在拆分是否合理,按照什么拆分更好呢?

【优惠分摊】

在计算订单应付金额时:

订单实付金额=商品金额(SKU金额合计)+运费-总优惠金额

其中:

总优惠金额=促销活动优惠金额+优惠券优惠金额+虚拟币抵扣金额

到这里,算是完成了订单计算的第一步。但是这里又出现了一个问题。当优惠后的订单发生部分退货时,应该怎么退款给用户?

1.优惠后订单发生部分退货如何处理

产品经理遇到的情况是:促销活动(如满减)涉及很多商品,优惠券也涉及很多商品,有时甚至跨店优惠。甚至还有整单能享受优惠,部分退货后就不满足优惠条件了,这时候怎样平衡用户、商品、平台之间的利益,在退货、退款时应该怎么处理?

其中涉及用户与平台之间的博弈,也考验着产品规则设计者的智慧。目前的处理规则基本都是“优惠分摊,偏向用户”。

我们先看一下两个场景。

(1)发生售后有可能是平台的原因,不是用户不买,而是店铺的商品有问题。

(2)假设双11时,用户分别在A和B店铺跨店买了参加满1000减200活动,各买了500元的货品,后来在A店退了价值100元的东西。这种情况下,退货后已不满足活动条件,是否要求用户给补100元?如果用户补款,又补给谁?

从上面的例子可以看出,如果将退货没达到条件的促销优惠条件考虑进去,系统复杂度会成倍增加。从人性的角度,我们相信绝大部分用户不会为了达到优惠条件故意多买,然后恶意退货。

最合适的处理方法就是下单时就将优惠金额按比例分摊到子订单、商品上,同样实付金额也分摊到子订单、商品上。退货时退还用户实付金额,而不会去追究用户因退单而没满足促销条件,允许用户占平台的便宜。

2.优惠分摊原则

关于优惠分摊原则,不但应该按比例分摊,还应在满足优惠条件的商品上,按照商品金额的比例分摊,而不是盲目分摊。

先来看一个案例场景。

订单中有甲、乙两店的商品A、B、C、D、E,包邮。商品A、D参加跨店满200减40的活动(活动1),商品B、C参加满100减10的活动(活动2),另外用户还使用了100元的现金券。

如表所示,订单总共优惠150元,其中活动1优惠40元,活动2优惠10元,优惠券100元。并不是将优惠完全平均分摊至每个商品上,而是按照优惠分摊原则,比如活动1在商品A、D的优惠金额分别是40×(80/320)=10元、40×(240/320)=30元,其他优惠金额详见表中。

根据表中的数据,我们能够清晰地计算出店铺、商品在每次促销活动中的收入。另外在用户部分退货时,也能按照其实付金额进行退款。例如用户退商品A、B时,只退款82元(54元+28元)。这样还能避免与用户发生纠纷。

二手车暂时没有那么丰富的促销活动,有些优惠券、意向金之类的。由于每单都是较大额的交易,有专门销售人员跟进。优惠分摊这块面对的挑战要相对小些。但如何平衡卖家、买家、平台之间的利益,仍然是非常具有挑战的。

本节主要介绍了订单的正向流程,但是在实际应用中又会衍生出许多变化。例如支付服务:有第三方支付、分期付款、货到付款等,都影响订单的状态;还有自营平台会将出库状态加入到订单状态中;还有从其他渠道(线下订单、京东等第三方订单)导入到系统的订单,不仅涉及与第三方平台的打通,还有对这些订单的管理,以及同步状态至第三方平台。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-04-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 普通程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档