电商后台之订单生成

　　结合商品流转的电商系列介绍了一些了，商品已经采购入库、价格税率设置好了、活动及相关模板也已经准备完毕，下面就应该上架销售了，现在接着聊下订单的生成。此篇是电商后台系列的第9篇，也作为2019年的最后一篇。
　　订单从产生到最终的关闭需要经历很多的环节，订单也是电商系统的核心数据，有销售才有收入，所有的工作都是围绕着订单开展的，为订单服务的。
　　本篇主要聊下从订单创建到订单支付完成这部分，介绍下涉及的系统的各个环节，回顾总结下这些简单的内容，供大家娱乐。
　　订单生成流程
　　上面这个流程相信接触到电商或经常购物的人都特别熟悉，特别简单，在设计开发时要我个人觉得要从以下三方面考虑。
　　首先，我们要清楚从搜索选择商品到加入购物车，然后提交订单，再到用户支付完成。就这么几步，你在淘宝、京东等任何一定电商网站也要遵循这个过程，所以这个过程比拼的是用户体验以及系统的稳定与性能。
　　其次，从产品运营的角度来讲，应该要考虑到用户在进入到哪个环节了，应该如何留住用户，最终让用户下单并支付。所以在产品与运营要兼顾考虑，不能脱离开。
　　最后，订单生成流程中用户的浏览、点击等行为都需要保存，每个过程要进行数据埋点，后台最终要计算出其页面PV、UV、以及订单转化率等指标，用于后续持续改进的依据。
　　下面结合自己的认识来说下各个环节，有不对的欢迎大家留言指正。
　　购买渠道
　　这里说的渠道，可以理解为下单来源即用户从哪挑选商品并下单购买的，先看下下图。
　　用户下单的来源可以分为内部（公司开发的相关产品）与外部（与第三方平台的对接）两种。
　　外部渠道，需要我们与第三方平台进行对接（目前都有第三方开放平台），将生成的订单导入到我们内部平台，然后进行履单。
　　这里涉及商品对接及库存（此部分是要求实时共享还是划拨渠道库存的方式，需要根据业务要求而确定，系统的实现是不一样的）、单据对接（转单、订单状态的更新等、查询），一般的平台都有开放平台，功能和架构都比较成熟，只要按业务进行调整设计应该就可以。
　　涉及支付结算、活动优惠的计算等，这些都与财务系统FMS息息相关，但是在产生订单的时候要将关键信息记录完整，要求可追溯而且要不可变（有调整要走逆向流程或系统补偿方案），代收和佣金的结算流程要结合合同与财务流程进行设计。
　　对于大的电商公司如果有一定的技术积累，外部渠道只是为了扩大影响力，用于引流和增加销售额，真正的收入还应该是内部渠道。
　　内部渠道，这是公司的主营业务销售渠道，涉及公司一些技术产品开发，而且这些应用产品就是公司的名片。
　　目前，零售公司都在实行线上线下的方式，以用户为中心进行社区化的经营，本质上就是为了卖货。线上以APP小程序为主，网站目前应该以引流和宣传为主了，移动端的产品是核心产品。
　　线下就是便利店模式，但现在如何经营好门店是众多零售企业在追寻的，线上销售无边界，线下销售有经营半径，所以对于产品的建设也不同。
　　APP小程序要求有效的利用移动设备的界面，更注重的产品的展示和整个购物流程的流畅性，但便利店应该以商品货架的规划、用户的亲身体验以及服务为主，服务应该更重要。
　　聊到这里小结下，渠道就是根据公司的战略来开发公司的技术产品，也是商品在哪个平台上进行销售的渠道。下面正式来说下订单产生时每个环节的一点理解。
　　商品搜索
　　用户下单前首先要查询需要的商品，商品有库存并且已经上架销售了，如何在前端APP上让用户快速的查看到是需要详细规划与设计的。
　　搜索需要用到搜索引擎，要设置关键字，对于商品名称等要进行分词，这部分是要通过搭建搜索平台来实现。
　　此外，商品展示时有导航，要有分类，要根据不同的楼层展示不同的商品，比如有促销的可以单独做活动页、可以归集在一个楼层里。
　　搜索具体咋做没接触过，但现在在APP或小程序上我个人感觉都通过分类或导航去找商品的，在淘宝或京东这种品类多的网站还是需要输入关键词查找商品的。所以对于SKU不多企业，搜索可以稍弱化点，更多的采用引导方式去寻找商品（不知道我的这种想法是否正确的，目前我很多时候是闭门造车哈哈）。
　　选择商品
　　商品查到了，如何选择商品呢？
　　这也需要我们的系统提供必要的信息。
　　商品详情页，此部分在前面介绍商品系统时说过，首先每个商品要根据上传的图片，商品的模板生成商品详细信息。由于网上购物是看不到实物的，所以只能通过图片或小视频来显示，这是最直接有效的信息传递方式。其次，要有规格参数的描述，如材质、大小等特性要突出；最后就是关于商品的服务条款，如保修、质量及使用说明等。
　　用户评论，目前商品的好评率是用户非常关注的，因为零售企业售卖的不仅是商品，更重要的是服务，但服务的好与坏是通过用户来反馈的。评论要从商家服务水平、商品质量、商品使用情况等不同维度进行。用户评论是与客服相关的，所以要有专门的人针对商品评论进行及时回馈与问题的解决，尽可能的真实的显示用户评论，降低差评，给用户真实的信息。
　　价格，在商品价税管理中介绍过商品的售价如何制定，依赖于哪些指标，最主要的是毛利率以及竞争对手的价格。低价不一定是好的选择，价格是要与商品品质及服务关联的。价格要醒目的展示给用户，要有对比，让用户感觉到优惠力度，价格的变动有严格的审核流程且要及时生效，避免用户投诉。
　　促销活动，没有哪个网站不搞促销的，促销的玩法前段时间整理过一篇，大家可以参照《促销活动一览表》。
　　经历了上面的一系列操作，此时就可以加入购物车了。
　　购物流程
　　购物流程直接影响用户体验的。
　　首先，虽然都是选品amp；gt；加入购物车amp；gt；提交订单amp；gt；支付结算，但不同的商品我们应该有所区别，比如秒杀商品就可以直接生成订单，不需要加入购物车。
　　其次，在购物流程中，我们应该更侧重于营销引导即让用户根据添加到购物车的商品给予相关推荐。因为用户走到这个流程，购买的愿望已经很强了，如果能够给出一些更好的建议或优惠，可以更好促进订单的达成，提高转率。
　　第三，在购物车中每次的商品的增与减都需要实时的获取商品的价格信息、库存信息以及优惠活动信息。这些金额的计算，促销活动的获取、订单优惠重新计算对系统要求是非常高的，响应慢了用户体验不好，数据获取不准确会造成用户的投诉，都会导致订单的流失。
　　第四，在系统设计时要考虑系统耦合度及功能的扩展性。如果这部分耦合度太高，会增加后续项目的难度，要合理划分功能。同时要注重时序性；有的服务先调、有的后调这些都要综合考虑。
　　购物流程组对产品、技术要求都很高，代码的好坏只有自己知道，说与做要做到知行合一，这部分也考验一个人的技术水平和抗压能力。因为与用户有关的功能出现问题要能够及时去解决，并对已有错误数据要快速修复。
　　一直参与的是后端系统的业务与系统设计，对前端的这部分的流程也在学习和梳理中，但此部分是我觉得最核心的如购物车的数据如何保存，用户的SessionId如何保存，活动如何防止超卖等等。
　　订单结算
　　1）结算页
　　首先是支付方式的选择，支付方式有很多种，目前很少有现金支付了，即便是货到付款也是支付宝、微信或刷卡了。
　　这里说的支付方式有以下几种：支付宝、微信、银行卡、优惠券、积分、礼品卡或红包等。不同的支付方式需要调用不同的支付接口，这时没有提交订单还没有到支付的环节。
　　2）优惠的重新计算
　　这里主要就是进行订单级别的优惠计算，是否有满减等优惠等。此部分也是购物流程的一部分。
　　3）运费计算
　　这个需要调用前期商品的运费模板进行计算，是否免邮还要结合会员等级等信息。
　　4）订单的提交
　　只有提交了才产生用户订单。对于订单有哪些信息需要记录？
　　订单的头信息，即订单号等基本信息，用户的基本信息，订单的来源，订单的生成时间，订单级的活动信息记录。
　　订单的行信息即商品信息，商品的购买数量、商品编码、商品原价、售价、优惠价以及商品级的促销活动信息。
　　如果是外部渠道的订单，还需要记录外部订单号、合作平台标识等
　　在此阶段，订单应该处于第一个状态即待支付状态，此时订单虽然创建，但是仍可以取消。
　　订单创建后就占有商品库存了，此时要给用户支付的时间，这个也要区分场景。普通订单可以30分钟内支付，秒杀订单需要立即支付，限时抢购订单可以设置1分钟或5分钟内支付，否则订单就需要系统自动取消，释放库存。
　　用户主动取消订单，在待支付状态一般没有限制，取消后即可释放库存。
　　还有一个问题，需要在此说明，即此时的订单保存在哪里？肯定是数据库，要确定的是订单此时保存在前端订单库中，还不需要向后台ERP系统传递，前端主库与后端订单号之间需要有一个拉单服务。
　　早在十几年前自己负责过这个拉单服务的开发，这么多年好似只是技术的不断升级，业务方式没有太大变化。主要是仍是采用多线程方式及时快速的将前端产生订单拉到后端生产库用以后序的作业。
　　最后，订单创建完成后，需要用户支付。此时支付多少钱、如何支付、支付需要对接哪些支付平台这个也是需要进行详细设计的。涉及到钱的就没有小事，这点对于我们技术产品尤为重要。
　　举个例子：
　　如果我们在做跨境电商，用户用人民币支付，但是支付宝国际需要转化为港币，那么在调用支付宝国际时就需要将汇率记录下来，并进行人民币与港币的转换。如果此部分汇率获取的不对或记录错误，直接影响到交易的金额，对后续的财务结算等都会产生影响。
　　在支付过程中，由于调用第三方的支付接口，支付成功与否的状态回传可能会有延时，所以此时需要对回传状态要尝试多次，同时我们要将订单进行状态锁定，防止用户重复支付。
　　如果用户支付成功，那么这时要记录哪些信息呢？
　　支付流水号、第三方交易号码、支付时间、支付状态、支付金额等，此部分信息第一是为了保证信息的完整性，第二是用于与第三方进行对账即财务系统中的应收对账部分，第三是用于用户的退换货等后续退款等。
　　此部分信息要在不影响支付流程的效率前提下，尽可能的详细记录，可以采用异步方式进行，但不能少记或不记，在涉及金额的信息我认为数据的冗余是必要的，多比少好。
　　至此，订单支付成功了，订单的状态应该是待发货状态。订单会经过拉单、拆单等操作向下流转，后续会接着总结。
　　总结
　　关于订单的部分，目前是想根据订单的状态去梳理下，目前要输出一篇好文章可能要几天或一周，有点慢，所以纯文字的会快点。这也是在本篇中没有画相关的流程图的原因，而且对于节点多的每个环节都画好比较费时，画的不细参考意义不大（后续会再针对一个个环节进行细化）。所以便采用文字描述的方式和你唠，唠的只是我个人的一些理解，涉及细节需要共同探讨与设计。
　　自加入人人都是产口经理平台的几个月来输出的文章频率有点高，质量可能有些粗糙，2020年会控制节奏，深耕细作。最后，感谢您的阅读与关注！
　　相关文章
　　1。《通过商品流转了解系统模块组成》
　　2。《电商系统之供应商管理》
　　3。《电商系统之合同管理》
　　4。《电商后台：商品管理系统》
　　5。《电商后台之价税管理》
　　6。《电商后台：采购管理模块》
　　7。《电商后台：商品上架前的最后准备》
　　8。《电商系统：仓储软件功能的简单设计》