订单整理设计

今天总算理解了采购订单的几种状态

� DELETE 在审批前，可以删除。不可逆操作。

� CANCEL 中止了合同。不可再接收、付款，但不影响对已接收的付款。不可逆操作。

� FINAL CLOSE 防止修改订单、行、发运。不能接收、检验、入库、开票、退

回。不可逆操作。

� FREEZE 冻结的目的是防止订单被修改，可以取消冻结。冻结后，可以接收、付款。

� HOLD 在取消暂挂前，不能打印、接收、开票。

� CLOSE 行上都关闭了接收、开票，头上就关闭了

� CLOSE FOR RECEIVING 表示物料已经接收完毕。

� CLOSE FOR INVOICING 表示物料已经开票，但没有接收。

� OPEN 可以在头、行、发运打开订单

� OPEN FOR RECEIVING 可以在头、行、发运重新打开订单

� OPEN FOR INVOICING 可以在头、行、发运重新打开订单

� UNFREEZE 可以在订单头、发放层解除冻结

经过测试取消的订单将无法做退货，取消和删除几乎是同一效果。

而关闭的订单也依然在接收区。所以对供应商拒收了不需要再送货的物料，只有两

种方法：1、修改订单；2、关闭，在分析时不考虑关闭的订单（人工判断或开发逻辑）。

从系统设计上可以这么理解：拒收后，即使不需要供应商补货，供应商仍可能出于

诚信将货送来，此时依然可接收。

自动关闭会考虑接收允差。如果允差为5%，你接收了96%时就会自动关闭，不再接

收。考虑了允差范围，只要发运行开票数、接收数在允差范围内，就会自动关闭行。

当用户成功下完订单后，订单会自动更新到订单列表页。而订单列表页，除了可以看到订单相关的主要信息，订单金额、下单时间、订单状态等。还会有订单的一些附属操作，如修改订单、取消订单、支付订单等。目的是便于用于便捷的处理订单操作。

从订单列表页进入的则是订单详情页，主要是订单包含的所有信息，另外同样会有附属操作，如支付、取消、修改订单等。

自动取消属于用户被动取消订单的行为。主要发生在先下单成功后，再进行支付。当此类预付订单、节假日订单、秒杀订单等在下单成功后，若一定时间内未进行支付则自动取消订单。支付时间多数是在30分钟之内。这段时间足够用户进行完成支付订单的操作。另外会有订单支付倒计时提醒以及短信提醒去支付。

人工取消属于用户主动取消订单的行为。一般是用户对于订单产生疑问、对订单服务不满意等因素导致主动取消订单。

对于企业而言，一方面是去调研为什么用户不下单，另外一方面是用户下单之后为什么取消。所以在用户主动取消订单时，会去获取用户取消订单的原因，便于企业自身做出应对措施，从而减少用户取消订单。

优先取消订单，之后让用户选择取消订单的原因，目的是使得用户快速取消订单，此取消流程比较适用订单在较短时间内则生效，繁琐的取消流程往往会影响到用户进行取消操作。一般常见于出行APP上，如滴滴、UBER、美团打车等。当订单被取消后，用户可仔细选择取消订单的原因，便于企业进行收集用户反馈。

优先选择取消原因，之后再进行取消订单。此取消流程主要适用于订单生效时间较长，取消原因的操作不影响用户取消订单。这类取消流程被多数APP所选择，主要是既不影响用户取消订单，又在取消过程中给用户更多思考时间。

3.取消原因细节设计：

一般来说，取消订单都存在一定的规则，而取消订单的规则多数在订单确认页进行展示。那么下单成功后，要进行取消订单的话有哪些影响呢？

红冲的弹窗提醒可设计原因填充，根据原因填充做判断（我之前只是询问状态）

二、客服评审思维的欠缺：

a、如果一个提货单只是一半先下给了贸易商，那么就红冲及返回一半

b、理想情况不影响

三、今日评审的思路：

a、对于贸易商来说，吨提货单就是虚拟仓库的概念，再加上参考发票的红冲思路，负数相冲返回去，这部分重新设计（虚拟仓库的重要性）

b、采销订单的红冲思路里，哪笔类型订单被红冲，则哪笔复选框内消失，例如采购订单被红冲，则复选框内的采购订单则消失

四、关于后台思路的对接：

1、聚玻网下单的接收ERP传回来的审核状态并漏出，同时红冲操作漏出，接着走红冲思路，冲完以后生成负数申请单，且负数的订单状态为已发货（传给ERP，同时编辑及删除按钮隐藏），最后正负的红冲关系传给对账红冲管理箱，流程结束。

2、非聚玻网下单的订单，只做状态的漏出，首先接收ERP的审核状态并漏出（编辑及删除按钮隐藏），对账助手红冲后，状态变更为已红冲且备注内漏出红冲订单的订单号（红字订单同步以后）。

3、打上临时订单标签的订单，对账助手审异后，将申异状态传给后台订单，并漏出已审异字样（编辑及删除按钮隐藏），备注内漏出审异订单的订单号（申异订单同步以后）。

4、首先：已发货后的订单生成出库单、供应链产品尤其是聚易通（红冲思路需要重新下单），暂不执行红冲吧流程的，但是已审核以后，只能走售后订单流程，且售后的订单需传给ERP，对于聚易通（白条的）

四、今日评审思路：（10月5日）

1、细节的把控，例如聚玻网各种中心的处理，这个要考虑，这个的关键点是搞清楚每个链条

2、负数的执行怎么跳转，德华提的建议，如果点击取消按钮，如何跳转

3、发票负数的生成逻辑，单独存这个余额

4、表与表的存储关系

使用场景

在Zookeeper中的监听回调机制，以及分布式锁，都是使用了观察者模式。

基于zookeeper去做分布式锁

（1）系统A尝试获取zookeeper上的一个锁，获取到了

（2）系统B尝试获取zookeeper上的一个锁，被系统A给锁了，没有获取到锁，此时系统B在zookeeper上可以注册一个监听器（观察者）

（3）系统A一旦将锁给释放了，zookeeper感受到锁被释放了，就会立即通知系统B注册的那个监听器

（4）系统B就立即被通知到了，系统A释放了锁，系统B可以重新尝试在zookeeper上加锁

电商系统里，也有这种场景，如果两个系统之间走了异步请求，那么可以基于上面那种观察者模式现在一个进程内实现监听，以后拆分微服务分布式架构了，可以改成基于zookeeper来做分布式协调。

系统A发送了一条消息到内存队列，系统B获取了消息开始执行操作

但是系统A需要知道系统B的一个执行的结果如何，

此时系统A需要注册一个观察者到系统B上去，系统B执行完了之后，将执行的结果，反过来通知给系统

我们就可以基于观察者模式去做。

登录用户数、人均登录、访问登录比、订购量、订购频次、内容、转化率、取消订单    数、退货订单数、取消订单金额、退货订单金额等

但大多数产品经理，更关注正向订购环节的转化，通过用户行为、订购数据分析不断的优化正向流程，往往忽视了逆向流程中订单流失率及流失原因。从七天无理由退换货普遍实施到现在，用户的购物习惯也发生变化，被教育成：无论何时、何地 看到何物，只要觉得不错就先拍下，后面发现更适合的商品时，再发起订单取消；或者收到之后不喜欢、不合适再无理由退货......  。取消订单、退换货的比例日渐增大， 所以电商产品的逆向流程也必须要重视，不仅是在体验上服务好用户，更是节省公司客服、仓储方面成本；严谨、科学的逆向流程设计也为分析订单流失的原因提供支撑。 本文将主要讨论订单取消的产品设计

    1 未支付：用户提交订单后，超时未支付  系统自动取消订单

    2 未出库：已支付，但未发货的订单； 由用户发起取消，WMS 进行拦截，拦截成功后即可取消订单并退款

    1、2 取消订单 常见的原因：

          先拍下考虑考虑

          价格太贵

          发现更好的替代品

          拍错商品

          其它

    3  缺货： 已支付，但仓储商品数量不足、仓储商品分拣时发现不可售的待发货订单，用户要求取消订单

    流程说明：

    2.1 用户提交订单，未支付情况下，超时系统自动取消订单

    2.2 订单已支付后，定时货按照其他规则创建发货单至仓库

    2.3 发货单创建成功后，仓库即对订单商品进行下架、分拣、复核、打包、出库等操作

    2.4 如果以成功创建仓储发货的订单，发起了取消申请，系统按照相应的规则判断后，回执是否可取消； 可取消的订单，即取消成功，并退款、退还相关权益；不可取消的订单，反馈取消失败

  3.1 可操作订单取消规则

      3.1.1  超时未支付，系统自动取消订单

                如，顾客提交订单后24h内未支付，系统自动取消订单（时间按照平台规定设置）

      3.1.2  用户自发取消: 前端订单列表露出【订单取消操作入口】

      3.1.3  平台客服后台操作取消：

      前端【订单取消】操作入口，常置于订单列表或订单详情页，如下图：

      订单未出库前，用户可通过前端的订单取消入口发起申请，前端【取消订单】操作入口根据后台订单处理状态判断是否露出

    订单状态与订单处理各环节对应关系参考如下图，通常而言仓库复核完成后，用户就不能在发起订单取消（前端操作入口隐藏）。但用户可联系平台客服，从后台操作订单拦截

3.2 子订单取消规则

      多数电商系统支持订单部分取消，部分取消的订单，需要计算取消后生育订单是否仍满足订购条件（优惠是否满足等0，满足：可操作取消； 不满足：提示取消失败（告知可操作方法，如到货后拒收、或告知用户操作整单取消）

3.3 订单取消后资产退还

3.3.1 订单取消成功后，系统原路退还已支付的订单（子订单）金额

3.3.2 积分退还： 按照平台指定规则处理，如：全部退还积分、部分退还、不退还等

3.3.3 优惠券退还：

          整单取消的订单，返还已用优惠券

          子订单取消：如果多个子订单公用一个优惠券，当取消其中部分子订单后，不退还优惠券；

                                如果公用优惠券的子订单全部取消，则退还（具体情况视平台规则而定）

3.4  订单成功取消后，释放已冻结的库存（前端可销售库存即时增加）

订单管理包括以下几部分。

1、订单下单

2、订单拆单

3、订单售后（退款退货）

4、线下服务订单

5、订单数据统计

6、扩展：购物车

订单中包含商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据。通过订单中心，实现对线上订单、线下订单及第三方订单的管理，支持订单接收、订单自动合并与拆分、自动匹配仓库、库存控制、自动匹配快递、结算与支付等订单生命周期中的一系列协同作业。

扩展资料

依靠灵活多变的订单产品设计架构，可满足电商企业百万级的订单业务处理需求，提升订单流转的工作效率。

在订单生成之后，会随着订单的流转更新状态。不同业务类型的订单状态，例如机票、服务订单、商品服务订单等，和最常见的纯实物商品的订单状态会有所区别。以实物商品为例，我们来讨论一下订单状态的流转。

参考资料来源：百度百科-订单管理

场景一：使用平台通用购物津贴（满2.1减2元）同时购买两家店铺的商品，一家商品金额2元，一家商品金额1元，结果如下图：

结合图一和图四可知：订单是无法选择合并支付选择框的（该按钮已置灰），但是点其中任意一个付款按钮时，要求两个订单必须同时支付，因为这两个订单共同使用了平台购物津贴；

由图三可知：这两个订单必须一起取消，不能单独取消，原因也是因为两个订单共同使用了购物津贴导致；

由图四可知：这两个订单虽然必须一起支付，但是付完款之后就互相独立，互不影响。

场景二：看购物津贴的退款：

由此可以知道淘宝的购物津贴是按照每个商家的商品金额（和运费无关）按照比例分摊的，而且其购物津贴是可以部分退和部分使用的。

场景三：有些订单必须和其他订单一起下单，不能单独购买和退款，例如火车票（门票、飞机票）中的保险，订单提交未付款时订单列表如下图：

看起来和和其他订单列表没什么区别，但是可以看到列表中是没有付款按钮的（这个地方应该是淘宝设计上一个不好的地方），因为他们把付款按钮放到了火车票的订单详情页，该详情页是包含保险信息的；而保险的订单详情页中是没有付款按钮的，只有订单信息。如下图所示：

下面一个景点门票的本质逻辑和火车票是一样的，而且把付款按钮放在了订单列表中，这样更便于用户操作，如下图：

结合这两个门票订单和火车票订单可以看出，保险也都是以独立订单的角色存在，这样应该是为了便于结算，因为门票、火车票、保险的供应商都是不同的。而且我又在景点门票订单中同时选择了两份保险，如果这两个保险由不同的保险公司提供，那他应该共有3笔订单：门票订单、保险1订单、保险2订单，结果的确如此，如下图：

可以得出结论：

1、淘宝做为综合性平台，有很多商家入驻为了便于结算订单均是在商家维度上进行主订单拆分，每个主订单下会根据商家的不同商品进行子订单拆分。订单列表是在商家维度展示的，也就是主订单；

2、为了满足平台型通用的购物津贴，淘宝在独立拆单后会存在订单关联，这些订单在付款前必须一起支付才能共同享用平台津贴，共同取消才能释放购物津贴；付款后，各个商家的订单互相独立可单独退款；如果没有共同使用平台购物津贴而一起提交订单的，淘宝就是按照商家维度去拆单，各个店铺的优惠独立计算，支付和取消、退款时也不存在关联关系。订单结构应该有3层。

3、购物津贴是根据每个商家的商品销售总金额按照比例分摊的，平台的津贴优惠在每个子订单上都是单独的字段记录。退款时，如果退某个商家的订单，那么可以将该订单中使用的购物津贴部分退还用户（对平台来说是被薅羊毛）。

4、对于类似火车票和保险这样的订单，拆单规则应该都是通用的，因为我们可以在订单列表中看到订单是独立显示的而且也是在商家维度进行拆单的，但是订单之间建立了强关联关系，有些订单不能独立操作，必须依附于其他订单进行状态变更，这个是由商品是否可独立购买和独立退款决定的（例如保险）。这种订单的下单场景本质上和购物车订单一样，但是在商品上又增加了一步逻辑校验。

5、淘宝的订单列表是不能按照业务类型去筛选订单的，只能按照订单状态，那是应该是因为淘宝还是主打电商，在满足电商场景需求的同时去支持其他业务类型的下单，例如：OTA业务

6、门票和火车票、保险的商家都是不一样的，猜测飞猪的发展方向应该是往OTA平台方向发展，等同于淘宝、天猫这样的电商平台。

      只是表面上体验了一下淘宝的订单，个人做出以上总结，至于到底该如何设计订单，需要产品经理们根据各自平台的不同特性去设计，例如京东和淘宝就有所差别。如有不对欢迎指正，也期待一起探讨。

    另外关于共同使用购物津贴的订单曾猜想，用户一起下单后直接进入收银台支付的话支付金额肯定是扣除购物津贴后的，如未支付进入订单列表各个订单也是互相独立的，订单金额应该是按照不使用购物津贴来计算的，用户使用合并支付功能时如果满足购物津贴的使用条件，会从待支付总金额中减掉。认为这样用户使用购物津贴会更灵活，去支付订单时体验也会更好。但淘宝没这么做，肯定有自己的道理，推测为：

1、会涉及到订单金额的二次计算，这样虽然用户体验上会更好，但是不符合订单的计算规则。订单提交后会生成快照，这个快照信息生成后就不会再变更，是双方交易的凭证，以后商品信息变更都不会影响该笔订单信息，避免纠纷也便于以后的订单数据统计。

2、可能觉得这样的功能对于订单支付成功转化率来说并没有提升吧，所以没有投入成本去开发，毕竟涉及到快照信息的保存开发成本还是挺大的。

在做订单流程这一块，参考了很多大神的文章，还有各种开源的商城软件，都过于理论化，实操性不强，对于新手来说没有一个实操的axure原型讲解，都是在用流程图告诉大家退款售后有哪些步骤，但是没有一个具体的案例来分析。相信我，你是不可能一上来就做到像很多文章里写得很完美订单管理系统的，况且文章中连原型图都没有。其实，即使是天猫和京东，在售后方面也是有取舍的，设定好规则才能让系统跑通，而不是说能够应付所有的异常情况。在设计之前，要考虑很多看似基础，却需要重视的规格，比如：

1.是否支持部分退款，部分退货？

2.是否支持换货？

3.是否支持多次申请退款/退货？

4.如果在售中时申请退款被拒绝了，还可不可以申请售后？

5.部分退款时，自动收货时间到了怎么办？如果退款申请拒绝了，订单状态怎么继续走？

我这些只是举例了冰山一角，对于订单管理的确有很多异常分支情况和用户错误操作。那我在这里既然说要用案例具体去讲订单的逆向流程，我就先要规定好我们商城的订单规则：

1.待发货前可以申请一次退款，发货后可以申请一次售后（退货/退款）

2.一笔订单多种商品只能分开申请退款，不支持对订单申请退款，意思是有一种商品时就是全退，有多种商品时就是只能部分申请退款。

3.订单中暂不含优惠券，只包括运费，在待发货时部分退款，最后一笔申请会退运费；在已发货后申请售后就不再退运费，其他原因走人工客服

以上就是我对订单的设置的前提条件，有了前提条件，我再去跟技术评审，就让他们心里也感觉到靠谱一些，毕竟第一次的时候他们提出了很多漫无边际，非常离谱但是也会出现的异常情况，一开始得时候我真的很苦恼，后来才发现是我没有设定规则，没有规则，技术同学当然怕出现出现异常情况程序不知道怎么跑了。

用户端订单页面

关于订单的具体流程我就不多讲了，大家都知道的，待付款，待发货，待收货，交易成功，待评价，那我们先来看看我是如何对订单设置布局的

图片所展示的，一笔订单分为商品操作栏，交易状态栏和操作栏，对于商品操作栏我是分开的，所以一笔订单有多种商品时在申请退款的时候，一定是单个申请的；交易状态栏是合并在一起的，这是对订单整体进度的状态显示，在部分退款时显示的订单状态；最后操作栏在确认收货前都是合并在一起的，对整个订单的签收，当状态为交易成功时，则会显示商品的评价入口。

那么这里就涉及这三块的状态和操作功能的切换，我们先来看一下 退款单过程状态 对商品操作栏的显示影响

我前面有讲，当处于待发货状态时，商品操作入口为“申请退款”；当已发货后，商品操作就为“申请售后”，那退款单的状态先去影响了商品操作栏的显示。具体的细分状态我在图片中已经详细列出来了，包括异常情况该如何处理。

在看完退款单对商品操作的影响后，再来看看退款单对订单状态的影响，注意，退款单与订单是多对一的关系，退款单和商品也是多对一的关系，所以才会有申请一次退款被拒绝了，还可以申请一次售后（退款/退货）。下图是 退款单结果状态 对订单状态的影响

可以看出来每一种订单都有部分和全部两种影响，这里要注意，全部并不是一次对订单提交的退款申请，而是查看到订单中是不是所有商品都有退款单，并且都有结果。通过这样表格的分析整理，会很清晰理解订单状态随退款单的变化。

用户端退款单界面

前面讲了订单页面中订单状态的变化，具体的订单详情我就不做过多说明了，因为大家参考其他网站也可以很直观的看到，接下来看退款管理的界面

根据我之前的设置的退款规则，这里的退款单一定是一种商品一个退款单（可能包含多件，因为规定申请退款是不能选择退款数量，要么全退，要么客服联系，因为后台可以修改退款金额）。退款单分为两种，仅退款和退货退款，在待发货时只能申请仅退款，在发货后可以选择申请退款或者是申请退货，但是只有一次机会！

这里很多人就会说我不考虑用户体验问题，首先我想说京东一上来退款退货规则也不完善，当然发展到今天他仍然还有很多不好的地方，当用户的退货申请被拒绝了你作为用户怎么办？京东的客服什么时候上线过，那个时候你只能网上发发牢骚。商城是从0到1，订单模块第一版的计划就是用户能下单，能退款，能退货。至于为什么用户不能一次申请所有商品的退款，为什么不能设置一种商品的退货数量等，后期会加上批量选择退款商品，设置退货数量等，不断优化退款和退货的流程图。

这篇文章很适合产品新人来了解基础的退款退货的原型图设计，毕竟这里不包含优惠券，没有拆单，也没有调仓等等，所以大家看了文章觉得还可以的点个赞~不喜勿喷

这里就没有展示具体的详情页面，所以可以底下留言找我要原型图~