订单管理系统是电商系统中最为复杂的系统，其作为中枢决定着整个商城的运转，我们设计商城的目的就是让用户下单，然后发货，然后订单完成。订单系统是电商系统最重要的模块，没有之一。
订单系统设计的好坏，决定了商城的可用性，与使用价值；订单系统贯穿于整个商城系统，其他各个系统的设计也是为订单系统提供数据支撑。订单的核心是流程问题，涉及资金流、物流、信息流，从用户提交订单的那一刻到订单完成，到售后，都需要订单管理系统来管理。
讲解订单管理系统就必须从它的流程来说，订单订单从无到有、流程分为这样几个流程：
阶段一、订单数据流程：用户选择商品信息，优惠信息等，生成订单价格，点击提交订单，这一非常小的一步，需要后台处理很多的数据，将最终的订单金额计算出来。这属于订单的第一个阶段；
阶段二、订单物流流程：用户支付成功，到发货，收货，订单完成；这属于订单的第二个阶段，如果没有异常流程，订单到这里已经完成，正常的订单分为这两个大的流程；
异常阶段、售后流程：用户在以上两个阶段中发生取消支付、退款、退货、换货等售后服务，这时订单就会走异常流程；异常流程要比正常流程还要复杂。
不管订单系统系统如何复杂，如何拓展，我将订单流程分为以上三个部分，而这三部分之间相互独立而又相互联系。第一阶段用户提交订单，系统处理订单数据；第二阶段付款成功，订单走物流系统，直到订单完成；第三阶段是从一或者二阶段中产生的异常流程
一、订单数据流程
这个阶段线上的操作并不是很多，主要是体现在系统对数据的处理上，我们在商城选择想要的商品，选择商品规格、数量、优惠券、然后系统会为我们生成最终的订单价格。这个流程属于系统内部的数据处理流程，需要调取系统各个模块的数据，流程如下：
首先，是用户在商城内选购商品，这个阶段可以叫做前置用户行为。
然后，是系统调取各个系统的数据，计算订单的最终价格，这个阶段可以叫做后置数据处理。
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.1 订单拆分
可能大家也都知道订单拆分，而怎么拆分，为什么拆分，大家可能都不清楚，但这也是我们需要知道的。
讲一个小故事：首先我们先来说说订单这个东西，现在有这么个情况，小张在商家小红的店铺购买了一双运动鞋，那么商家小红肯定是要为小张发货的，所以他就需要联系物流公司。
比如申通小李，为了跟踪这双运动鞋在系统中的物流情况，在发货的时候需要为鞋子匹配唯一的订单号和运单编号（订单号电商系统生成，运单号快递公司生成），为什么有订单号了还要运单号呢，订单号是电商系统用于记录当前小张提交的这一笔订单信息，而运单号是为了跟踪鞋子的物流信息。
过了一段时间，小张又在小红这里买了一双运动鞋，不过同时买了一个皮球，方便玩耍，所以将一双鞋、一个球加入购物车，统一购买。然后提交订单，生成一个订单号。
这个时候虽然是两件商品，但是小红为了图方便，就将皮球和运动鞋放在一起发货了，那么申通小李看到的其实还是一个包裹。
但是他不知道的是，包裹里面有两个物品，所以就会创建一个运单编号，这也是为什么我们在网上购物的时候明明买了两件商品，但是收货信息只有一条，因为放在一起了。这种情况是一个订单编号，一个运单编号，两件商品。但是在运输的过程中由于鞋和球放在一起了，车辆过于颠簸，鞋子就把皮球炸爆了，当小张收到货后非常生气，小红也感觉非常的惭愧并为小张做售后。
又过了一段时间，小张还是在小红这里买了一双鞋和一个皮球，但是为了防止拿到货时皮球又被鞋子炸爆，所以小张要求小红将这两件商品分别发货。
小张同时又在店铺小王的店铺里买了两个篮球，那么这一次买的有点多——一双鞋、一个皮球、两个篮球，并且还是在两个店铺里面，因为电商平台需要为每个商家进行资金结算，所有需要通过订单号记录每个商家的订单信息。但是，显然如果这次所有的东西都用一个订单号那就乱了，因为结算是通过订单查询商家信息每笔订单对应一次结算，两个商家这笔订单的钱应该结给谁呢，所以这个时候就会出现第一次拆单。
如果用户一次提交订单，但是订单包含多个商家，或者商家和平台自营同时出现，那么就需要拆单。
小张提交的5件商品分为2个订单，每个订单号对应一个商家，同时如果小张另外在平台自营买了一件商品，道理也是一样，也需要拆单。
因为平台自营的商品是不需要结算的，如果把平台的订单放到商家一起，那么给商家结算的时候，岂不是平台卖得东西算到商家头上了。
回到上面，刚说拆分成了两个订单：第一个订单我们叫他订单号001，这个订单下面是商家小红的商品，一双鞋，一个皮球；第二个订单号002，这个订单下面两个篮球；小红将这两件商品分别发货，于是申通小王发鞋子，另外喊来小王的同事申通小明发皮球。
显然我们就知道了，鞋子会对应一个运单号，皮球也会对应一个运单号（也就是二次拆单），这两件物品的物流信息分别记录。但是，这两个物品对应的是一个物流单号001，也就是说一个订单，一个订单编号下可能对应多个运单编号。
同时也就可以解释这么一个现象，利用订单编号是查询不到物流信息的，只能靠运单编号（叫法问题，运单编号也叫物流单号），想一下我们在购物时看自己的未收货商品时，我们可能就会想到，每一条信息的展示是对应一条运单号的，而上下排列的两件商品列表，很有可能订单编号是相同的。
也就是说，我们在购物车购买多个商品提交订单时，可能会有多个订单号（一次拆单，拆业务订单，原因上不同商家、平台所导致的），同时一个订单号可能会有多个运单编号（二次拆单，拆发货单，用户端拆开显示）
以上步骤是生成订单：
提交订单系统就会生成订单，此时订单是待付款订单，用户付款完成之后，流转成待发货订单。而当用户提交订单长时间没有支付的话，订单就会自动取消，生成已取消订单。同时用户对于待付款订单也可以主动取消，生成已取消订单。
用户付款完成之后，后台就会显示买家已付款，这个时候就需要进行发货，发货需要填写运单编号、物流公司，运单编号物流公司提供。
发货完成之后系统就会跟踪物流信息，同时订单状态变为待收货状态。
只要商品发货完成，用户以后都可以查看物流信息。
2.4 用户进行收货，或者时间段内自动收货，待收货订单流转为已完成订单
用户通过查看物流信息，进行线下取货，确定商品完好之后可以进行确认收货操作，确认收货之后，订单变已完成状态。
用户在确认收货操作之前可以进行申请退货操作，却已经确认收货则不可以申请售后。
三、异常阶段、售后流程
在整个购物流程当中除了正常的流程，有时候还会后异常的流程，这些流程会改变订单应该有的流转状态。
3.1 取消支付
当用户提交订单的时候系统就会同时生成待付款订单，这个时候拉起支付页面，如果用户支付成功，订单流转为待发货状态，如果用户支付失败或者退出支付，那么订单就会保持待付款状态。
对于待付款的订单，用户可以继续进行支付，一般来说待付款是有支付剩余时间的，就是在一定时间内如果用户没有支付成功，那么订单就会关闭，流转为已关闭订单，对于已经关闭的订单用户仅可执行删除操作。
3.2 退款
用户付款完成在没有发货之前申请退款：
当用户付款完成，订单就会流转为待发货状态，这个时候后台是要准备发货的。那么在用户付款之后，商家发货之前，这个时候用户可以申请退款。
申请退款需要填写退款理由，然后提交商家审核，如果是多商户，所有的售后流程都由商家来进行审核，平台无需干涉。后台会看到用户的审核状态为申请退款中，这个时候商家要确定是否已经发货了，没有发货的话同意退款，资金按原路返还给客户。拒绝申请需要给客户说明拒绝理由，比如订单已经发货，无法退款。
3.3 退货
发货之后，用户在未确认收货之前申请退货：
当商品发货，但是用户未确认收货前可以申请退货，申请退货一般是在用户已经收到货了，但是对商品不太满意。
比如：衣服不太合身，这个时候就需要申请退货，首先提交退货申请，填写退货原因，后台初步审核通过后，订单状态变为待退款，退货订单；用户联系快递公式发货，填写发货信息，主要是快递单号，当商家收到货后会查看商品是否完好，确认后，在后台执行确认退货退款操作，资金自动返还给用户。
3.4 换货
发货之后，用户在未确认收货之前申请退货：
换货的流程与退货相似，用户申请换货，审核通过后，用户进行发货，商家收到货后订单完成；在从新为用户进行新的发货。
四、线下服务订单
线下服务订单就很简单了，用户付款完成系统会生成唯一的核销码，比如：6为数字，然后用户线下到店消费，出示核销码，商家进行核销，订单完成。
