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

　　订单管理系统是电商系统中最为复杂的系统，其作为中枢决定着整个商城的运转，我们设计商城的目的就是让用户下单，然后发货，然后订单完成。订单系统是电商系统最重要的模块，没有之一。
　　订单系统设计的好坏，决定了商城的可用性，与使用价值；订单系统贯穿于整个商城系统，其他各个系统的设计也是为订单系统提供数据支撑。订单的核心是流程问题，涉及资金流、物流、信息流，从用户提交订单的那一刻到订单完成，到售后，都需要订单管理系统来管理。
　　讲解订单管理系统就必须从它的流程来说，订单订单从无到有、流程分为这样几个流程：
　　阶段一、订单数据流程：用户选择商品信息，优惠信息等，生成订单价格，点击提交订单，这一非常小的一步，需要后台处理很多的数据，将最终的订单金额计算出来。这属于订单的第一个阶段；
　　阶段二、订单物流流程：用户支付成功，到发货，收货，订单完成；这属于订单的第二个阶段，如果没有异常流程，订单到这里已经完成，正常的订单分为这两个大的流程；
　　异常阶段、售后流程：用户在以上两个阶段中发生取消支付、退款、退货、换货等售后服务，这时订单就会走异常流程；异常流程要比正常流程还要复杂。
　　不管订单系统系统如何复杂，如何拓展，我将订单流程分为以上三个部分，而这三部分之间相互独立而又相互联系。第一阶段用户提交订单，系统处理订单数据；第二阶段付款成功，订单走物流系统，直到订单完成；第三阶段是从一或者二阶段中产生的异常流程
　　一、订单数据流程
　　这个阶段线上的操作并不是很多，主要是体现在系统对数据的处理上，我们在商城选择想要的商品，选择商品规格、数量、优惠券、然后系统会为我们生成最终的订单价格。这个流程属于系统内部的数据处理流程，需要调取系统各个模块的数据，流程如下：
　　首先，是用户在商城内选购商品，这个阶段可以叫做前置用户行为。
　　然后，是系统调取各个系统的数据，计算订单的最终价格，这个阶段可以叫做后置数据处理。
　　最后，是将订单价格在用户端显示，这个阶段叫做表现层显示。
　　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（10。8））（100（10。5））（15）
　　也就是说，每项的优惠金额计算都是以订单金额为基础进行计算。
　　一般来说用这种方式比较好，能够很好的体现每种金额优惠的价值，并且拓展性强，计算的顺序不会影响最终的优惠效果，因为都是在订单总价的基础之上的，并且易于理解和计算。
　　（2）以顺序计算订单总金额：
　　就是每一笔的计算都是在上一步金额的基础之上的，具体算法如下：单价45元、数量2、运费5、会员9折、优惠8折。
　　首先，加上运费（（202）5）45元
　　然后，在上一步基础上减去会员折扣45450。140。5
　　最后，在上一步的基础上减去会员权益的优惠金额40。540。50。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为数字，然后用户线下到店消费，出示核销码，商家进行核销，订单完成。