从0到1构建电商平台之订单系统（3）：处理订单

honghu2

从0到1构建电商平台之定单体系（3）：处置定单

电商平台重要会触及商家体系、商品体系、定单体系、售后体系、会员体系、营销体系、财政体系、数据体系等，这是系列文章的第三篇，处置定单。

固然每一个公司的详细需求与营业场景纷歧样，咱们平台的功效需求可能其他平台不尽不异，但全部定单的发生到竣事的，重要有如下3个流程：



起首，用户选好商品以后会提交定单，颠末一系列果断以后，用户乐成提交了定单，此时定单状况为待付款，而且会写入数据库（多商家的定单就按商家拆单后写入）；然后用户就起头付出定单，颠末一系列果断乐成付出后，这时候就必要商家处置定单，举行发货等操作，同时用户也能够举行一些操作。
1、完备定单字段1. 定单信息
1）定单编号

该定单的独一ID，对付办理/商家后台来讲便利查找；生陈规则是用的雪花算法，这里不做开展。

2）定单类型

可以分为“本身采办/老友代付/使命勾当”等。

标识表记标帜定单类型有两个目标：一是分歧的定单类型在客户端和后台可能有分歧的页面展现和操作流程，二是可以举行数据统计并阐发；以是定单类型可以分得越细越好。

这个字段可以就不放给商家后台了，仅限办理后台挑选。

3）定单备注

这个字段在后台定单详情里可以放在较显眼的位置，以防事情职员遗漏。
2. 商品信息
1）商品编号

添加商789交友网品时的编号，便利查找商品（但在数据库里不是商品的独一ID，由于商派别量够大时会发生反复的环境，但又不克不及做避免反复的限定）。

2）商品名称

商品名称是较大要率会发生反复的环境；从商家的角度来讲，名称怎样取，与搜刮引擎和举荐商品的匹配水平具备至关大的联系关系。

3）sku（商品的属性规格）

4）采办数目

4）商品来历

分为普互市品/勾当区域一/勾当区域；勾当区域是一个替换名词，在咱们平台会有几个分歧的勾当区域，在后台的营销体系里，可以直接往分歧的勾当区域里添加分歧的商品，并设置响应的如勾当代价/单人限购数目等信息；区别的感化主如果用于数据统计并阐发。

必要注重的是为甚么是商品来历而不是定单来历，好比用户在A勾当专区找到某商品，又在购物车参加了该商家此外的处于B勾当专区的商品，一并采办，如许就会分不清；以是来历随着商品走，可以更好地阐发某个专区的流量环境，和后续的运营和迭代。
3. 金额信息商品结算价金币抵扣邮费现实付出金额付出方法4. 用户信息
1）账户信息（昵称/账号）

2）收货人信息（收货人姓名/德律风/地域/具体地点）

（注：账户信息可不放给商家后台）
5. 时候信息下单时候付出时候发货时候确认收货时候6. 操作信息操作账号操作时候操作内容
若是呈现问题，便利后续对相干事情职员追责，

接下来是客户真个各定单状况对应操作，与后台的各商品状况对应操作。必要注重的是为甚么客户端是定单状况，尔后台是商品状况？

咱们可以先来会商一下：
为甚么客户真个定单状况是定单状况而不是商品状况？
商家发货必定有个前后次序，一个多商品的定单中必定会存在此中一部门发货了，而此外一部门没发货的环境，那此时该定单究竟是待发货仍是待收货？那末，是否是定单的状况随着商品走会更好一点？

若是设计成客户真个状况随着商品走，当一个定单中存在多个商品状况，用户取缔可以对商品取缔而不是全部定单（优惠券、抵扣等也能够防止），确认收货可以对商品而不是定单（好比定单中有3个商品，商家只有此中1个商品一向没货，而其他商品用户早就收货了，此时定单就一向不克不及确认收货，商家可能就会由于这一个商品，而迟迟不克不及结算其余的商品金额）等等一系列操作可能城市简洁一点。

我小我认为功效为甚么如许做：要末就是逻辑流程必需要如许做，要末就是如许做用户体验更好。

在客户端定单状况这个问题上，我临时没找到必需如许做的来由，只能认为如许做用户体验会更好，究竟结果古人总结的履历。以是，主流电商平台的客户端，用户看到的是定单状况而不是商品状况；但愿有大佬能指出，一块儿探究。

适才说的是客户端是定单状况，按照主流电商平台如许设计作为条件（固然用户也养成习气了，我不成能去更改），然厥后说后台的为甚么是商品状况。

起首，发货必定是对商品发货（好比一个定单中有A、B、C三个商品，A、B可能归并发成一个包裹，C拆分成两个包裹发出去），适才也说了对付多商品的定单来讲商家发货，填写物流单号必定有个前后次序。

为了便利商家检察哪些商品已发货，用户也能够晓得哪些商品是哪一个包裹，哪些商品已发货了，以是在后台一般状况是随着商品走，而不是定单走。

可是这就触及到客户端定单状况与后台商品状况的对应瓜葛了，下面会举行先容。
2、客户端定单状况对应办理/商家后台商品状况


赤色虚线为对应瓜葛，我来诠释一下为甚么存在一对多的环境（待付款，待发货，已封闭都是一对一的环境就不诠释了），从客户真个状况来讲：
1. 待收货
对应后台多是部门发货和已发货；为甚么有部门发货这个状况？

由于后台的状况是随着商品走的，以是部门发货不是定单中一个商品发了一个没发的环境，而是商家发了此中一部门采办数目的环境；好比用户买的某商品采办数目为2，商家只发了此中1个，第二个得比及来日诰日再发，若是不标识表记标帜出来，商家可能就会不晓得。

固然用户在采办的时辰会锁库存，采办数目为2就代表着你此时库存体系中最少有2件，可是要斟酌到不少小商家操作可能其实不是那末正规，库存颇有多是乱填的其实不联动，也有可能商家临时堆栈里只有1件，可是库存仍是有的，咱们无法去规避如许的报酬环境。

为了对应，我认为可以加之部门发货这个状况。

为甚么客户真个定单中没部门发货这个状况？

一个是这类环境也是少数，加之去反而繁杂了用户的认知，可能会造成用户感觉怎样一些发了一些没发，低落用户体验；一个是后真个逻辑会更繁杂一些。

当定单中肆意一件商品发货后，客户端定单状况就会变成待收货，为甚么如许设计？

一个是上面说的，发货有个前后次序，定单中一部门发了，一部门没发，客户端展现为待收货必定比待发货更能减轻用户的发急生理（定单中有商品发了货，这个也没错误）；一个是待发货的定单，用户是可以无本钱的直接取缔定单的，有商品发出了，但用户确直接取缔了，这必定分歧理。

综上所述，好比用户在统一商家采办A商品2件，B商品2件，当用户看到定单处于待收货货状况时，现实有可能A商品只发了一件（A处于部门发货），A已发货B待发货，A,B都已发货。
2. 待评价、已完成
为甚么客户真个定单状况的待评价和已完成，都对应后台的已发货，而不是后台中的待评价和已完成？

是由于咱们在需求评审的时辰砍掉了后台的这两个状况，阐发一下为甚么商家必要看到待评价和已完成的定单，是由于他可能必要去找到这笔定单后再去看用户评价了吗？

缘由是，咱们如今平台用户量其实不是很大，评论的用户较少，以是商家与用户互动的功效可能用得比力少临时就没做，把精神放到更成心义的功效上，以是可能商家就不必要查对待评价和已评价的定单，这个功效优先级和互动功效一块儿放低了。

然后说一下，淘宝的后台有退款中这个定单状况，我没如许设计的缘由是，我把定单状况和售后单状况是彻底分隔的；好比采办数目为2，用户收到货后发明此中一个商品有问题，申请退货数目为1，那这个定单是待收货仍是退款中呢？

若是要加这个状况，又要加一些果断，好比申请数目为1的时辰，定单状况为待收货，申请数目为2的时辰，状况为退款中，就是说必要果断定单中是不是全数申请退款；又好比定单中两个商品都申请退款，这时候定单状况为退款中，可是此中一个退款单被打回，退款单状况变成已封闭，这时候又从退款中变成待收货，不但对后端逻辑，对用户来讲也很乱。

以是定单和售后单状况彻底自力，好比待评价的定单中只有一个商品，用户对该商品申请退款并乐成后，定单状况仍然为待评价，若是变成已封闭，我感觉分歧理，就算用户退货退款，也不克不及褫夺用户评价的权力。
3、客户端定单状况对应操作1. 待付款
1）去付出

付出时的果断流程与在付出页面的果断流程是同样的（商品状况/sku信息是不是更改），点击付出按钮后若是付出失败，则可以触发主动取缔定单。

2）取缔定单

取缔后状况变成已封闭，金币等抵扣原路返回，开释库存。

3）朋侪代付

流程较为繁杂，这里不做开展，我会在此外的文章中写出来。

待付款的时候是非需视营业场景而定，好比平台上商品的库存是不是充沛，是不是愿意留足够时候给商家与用户协商等；淘宝是24小时，京东严选是30分钟。
2. 待发货
1）取缔定单

待发货的定单用户可以无本钱的直接取缔，但必要斟酌一种情形是，此时商家已将包裹发出，只是还将来得及填写物流信息（报酬身分无律例避），定单状况仍为待发货，此时用户是可以取缔定单的；中心这段时候差是没法防止的，只能尽可能收缩（因为咱们平台暂未触及到满减之类的勾当，暂不斟酌这种场景下的取缔定单）。

若是大师有好的方案，咱们可以一块儿来会商一下。

2）提示发货

在后台以站内信的方法通知商家，但需设置距离@时%6UG8W%候或每%3613j%一%3613j%个@账号的次数；这个功效本色上对用户来讲只是一个抚慰剂功效。
3. 待收货
1）检察物流

当定单内有多条物流信息时，有如下几种环境：
单商品多物流：一个商品在发货时分为多个包裹发出，即填写了多个物流单号；多商品单物流：多个商品在发货时合为一个包裹，即填写了一个物流单号；多商品多物流：好比A、B商品合为一个包裹，C商品分为多个包裹。
以上几种环境都必要有零丁的页面来告诉用户，哪些商品在哪一个物流单号里。

2）确认收货

确认收货分为两种：用户自动确认与体系主动确认。

主动确认收货的时候为定单内最后一个商品填写物流单号起10日（详细时候是非可按照详细营业场景而定）。

前面说了，多商品的定单此中一个商品发货后，定单状况当即变成待收货；但如许一样会带来一个问题，当定单中存在未发货的商品时，当用户点击确认定单时，应不该该让用户确认收货呢？

我的做法是不让，同时给一条提醒语告诉用户，固然感受不大公道，但临时没想到更好的方案了。

3）申请售后

在此状况的申请售后必要做3个果断
点击时一样必要果断当前商品是不是已发货（后台商品状况处于待发货和部门发货则不克不及点击）；若是该商品有售后申请记实且处于举行中状况，则按钮置灰；好比快猫视频采办数目为5，申请数目为1，若是不做限定，则至多还可以申请4次售后，商家可能就会一次性处置5次售后单，以是在非彻底申请的环境下，只有当第一条售后单状况处于已完成或已封闭状况时才可继续申请；该商品是不是已彻底申请过售后，好比采办数目为5，已全数申请过售后且经由过程并彻底，则按钮置灰，不克不及再申请售后。4. 待评价
1）检察快猫视频物流

与待收货时的果断前提一致。

2）去评价

评价分为两种：用户自动确认与体系主动确认；主动评价时候为定单确认收货起15日（详细时候是非可按照详细营业场景而定）；主动确认收货后，在商品详情页里的评价中内心会显示该条主动评价的固定案牍。

3）申请售后

此状况的申请售后除必要果断该商品是不是有售后单处于举行中和是不是已彻底申请过，还必要果断该定单是不是已过可售后时候；可售后时候为定单确认收货起15日（详细时候是非可按照详细营业场景而定）。
5. 已完成
1）检察物流

2）申请售后

这两项操作的果断与待评价状况下一致。

3）再次采办

这项操作的目标是为了多一个进口来表示用户再买一次；若是该定单内有1个商品，点击后跳转至商品详情页，若是有多个商品，则跳转并参加至购物车；为甚么不是直接跳转至提交定单页面？

由于所有对商品状况，sku信息是不是更悔改的果断在详情页或购物车完成对用户体验必定更好一些。
6. 已封闭：分为3种类型用户自动取缔（待发货状况时用户在客户端取缔）商家自动取缔（待发货状况时商家在后台取缔）超时未付出体系取缔（待付款状况时跨越时候体系取缔）
这几种分歧类型的已封闭定单，必要在页面表现出取缔的缘由，以起到告诉用户的感化。
4、后台商品状况对应操作
咱们平台综合斟酌后，待付款的定单临时不进入后台
1. 待发货
1）发货

必要举行的操作有：选择发货数目/选择物流公司/填写物流单号；当发货数目小于采办数目时，商品运输状况会变成部门发货；发货可能举行的操作是添加物流，好比用户采办的一个套装，采办数目固然为1，但必要2个包裹发出，以是必要有添加多个物流的操作；发货后就必要扣除库存。

2）取缔定单

3）点窜收货信息若是用户接洽商家，但愿点窜收货信息，只要触及到地域的点窜，就有可能会影响到邮费的计较，好比用户提交定单的收货地域为重庆，邮费为10元，但但愿商家改成西藏，邮费为20元，多出来的10元就必要商家和用户线下解决。
2. 部门发货
1）发货

前面说了，此状况下的发货操作不会影响客户端定单的状况。

2）检察物流

检察物流弹窗必要加之点窜物流单号的操作，以防填错。
3. 已发货/已封闭
操作都为检察物流。

以上就是定单体系的全数内容了，做一个总结：
起首用户必要提交定单，在提交定单页面可以看到并选择哪些字段，同时后端必要颠末一系列果断以后才能乐成提交定单；用户在乐成提交定单后，该拆单就拆单，该写入数据库就写入，然后用户必要付出该笔定单，后端又颠末一系列果断以后才能付出乐成；最后就必要商家来处置定单了，正常流程就是商家发货，用户确认收货，异样流程就是用户或商家取缔定单，申请售后之类的操作。
若是有认为我在流程或逻辑上设计有问题，或不清晰的处所，接待列位大佬指出，一块儿来会商一下

下一篇：售后体系
#相干浏览#
从0到1构建电商平台之定单体系（2）：付出定单

从0到1构建电商平台之定单体系（1）：提交定单

本文由 @橘钻 原创公布于人人都是产物司理，未经作者允许，制止转载。

题图来自Unsplash，基于CC0协定。