电商后台系列第9篇：订单生成流程及相关环节介绍

hwyzw

    关于电商平台的商品流通环节，我们已经做了不少介绍。商品已成功采购并入库，价格和税率也已设定，相关活动及模板亦已准备就绪。接下来，便是将商品上架进行销售。现在，让我们继续探讨订单的生成过程。本文是电商后台系列的第九篇，同时也是2019年的最后一篇。

    从订单生成至最终完成，需经过众多步骤，订单构成了电商系统的关键信息。销售活动带来收益，所有业务活动均围绕订单展开，并为其提供支持。

    本文主要探讨从订单生成至支付环节的整个过程，详细阐述其中所涉及的各种系统及其功能环节，并对这些基本内容进行回顾与总结，以供大家休闲消遣。

    订单生成流程

    这个流程对于熟悉电商或频繁网购的人来说并不陌生，操作起来十分简便。在设计和开发过程中，我认为需要从以下三个方面进行考虑。

    我们需要明确，从挑选商品至将其放入购物车，再到订单的提交，以及用户支付的全过程。这一系列步骤，在淘宝、京东等众多知名电商平台中均需遵循，因此，这一流程的核心竞争在于用户体验的优劣以及系统稳定性和性能的高低。

    再者，从产品运营的视角出发，需关注用户所处的具体阶段，思考如何有效维系用户，并促使他们完成购买和支付流程。因此，在产品设计和运营策略上需统筹兼顾，二者不可分割。

    最终，在订单生成流程中，用户的浏览和点击等动作均需记录，每个环节均需进行数据埋点操作。后台系统需计算出页面浏览量（PV）、独立访客数（UV）以及订单转化率等关键指标，这些数据将作为后续持续优化和改进的参考依据。

    在此，我将结合个人见解，对各个阶段进行阐述，如有不当之处，敬请各位留言提出纠正意见。

    购买渠道

    此处所指的渠道，实际上是指用户选购商品并完成订单的途径，即下单的起点。具体来说，就是用户在何处挑选商品并最终进行购买。接下来，请先查看下面的示意图。

    用户购买订单的渠道主要分为两类：一类是公司自主研发并推出的产品，另一类则是通过与第三方平台实现对接所获得的订单。

    我们需要与外部渠道对接，特别是那些已开放的第三方平台，以便将生成的订单导入至我们自身的系统，随后进行后续的订单履行工作。

    此处所涉商品对接及库存管理（需明确是采用实时共享库存还是划拨渠道库存，这需依据具体业务需求来决定，系统实现方式各异）、单据对接（包括转单、订单状态更新等操作、查询功能），大多数平台均设有开放接口，其功能和架构相对成熟，只需根据业务需求进行调整和设计，即可满足需求。

    支付结算和活动优惠的计算等方面，这些内容与财务系统FMS紧密相连。然而，在生成订单过程中，必须确保关键信息的完整性，并实现信息的可追溯性及不可更改性（若需调整，需遵循逆向流程或采用系统补偿措施）。此外，代收和佣金的结算流程需与合同及财务流程相协调，进行精心设计。

    大型电商平台若具备技术优势，其对外合作渠道主要目的在于提升品牌知名度，吸引客流并提升销售业绩，但核心盈利点实则在于自家的销售渠道。

    公司内部渠道，作为其核心的销售途径，不仅涵盖了一系列技术产品的研发，而且这些应用产品更是公司对外展示的窗口和形象代表。

    当前，众多零售企业正采纳线上与线下相结合的模式，以顾客为核心，开展社区化运营，其根本目的在于促进商品销售。在线上，主要依托APP和小程序，而网站的主要职能则转变为吸引流量和进行宣传，移动端产品则是其中的核心。

    线下经营模式类似于便利店，然而，当前众多零售企业正致力于探索如何有效管理实体店铺。与此同时，线上销售不受地域限制，而线下销售则受到经营范围的制约，因此，在产品构建方面也有所区别。

    应用程序和小程序在利用移动设备界面时需注重展示效果和购物流程的顺畅，然而，便利店运营应侧重于商品陈列布局、顾客的实际体验以及服务质量，其中服务质量尤为关键。

    在此处稍作总结，渠道指的是依据公司战略规划来研发和推广技术产品，同时也涵盖了商品在各个销售平台上的流通途径。接下来，我们将详细阐述在订单生成过程中各个阶段的一些看法。

    商品搜索

    在用户下单之前，必须先检索所需商品的信息。只有当商品有库存且已上架销售，这个问题才需要解决。如何在前端APP上高效地让用户找到这些商品，这需要我们进行周密的规划和精心设计。

    使用搜索引擎进行搜索时，必须设定相关关键词，对商品名称等特定内容进行词语拆分，这一过程需依托于构建搜索系统来完成。

    此外，商品展示需配备导航系统，并实施分类管理。需依据楼层差异展示相应商品，例如，促销商品可设立独立活动页面，或集中陈列于特定楼层之中。

    具体操作方法我不太熟悉，不过现在我发现无论是APP还是小程序，个人感觉大多数情况下都是通过分类或导航来查找商品。在淘宝、京东这类商品种类繁多的平台上，我们通常需要输入关键词进行搜索。因此，对于SKU数量不多的企业来说，搜索功能可以适当简化，更多地采用引导式的方式来帮助用户找到商品。至于我的这种想法是否正确，目前我还在摸索中，有时候感觉像是闭门造车。

    选择商品

    商品查到了，如何选择商品呢？

    这也需要我们的系统提供必要的信息。

    商品详情页，这部分在先前关于商品系统的介绍中已有提及。首先，每个商品需依据所上传的图片和商品模板来生成详尽的商品信息。鉴于网络购物无法直接接触实物，图片或短视频便成为展示商品的最直接且高效的信息传递手段。再者，商品规格参数的描述至关重要，如材质、尺寸等特性需明确突出；此外，还需包括商品的服务条款，例如保修政策、质量保证和使用指南等内容。用户对商品的评论中，好评率是众人关注的焦点，这是因为零售商销售的不仅仅是商品本身，服务同样至关重要，而服务的优劣正是由用户评价所体现。在撰写评论时，应从商家服务态度、商品品质、使用体验等多个角度进行全面评估。用户评论涉及客服领域，因此需设立专人负责对商品评价作出快速响应并解决问题，力求如实反映用户评价，减少负面评价，向用户传达准确信息。商品定价在价税管理中已有阐述，涉及售价的确定方式、依赖的指标等，其中毛利率和竞争对手的价格尤为关键。低价并不总是最佳选择，价格应与商品质量和服务水平相匹配。用户需明显看到价格，需进行对比，以便感知到优惠幅度，价格调整需经过严格审核并迅速实施，以防用户产生不满。各大网站普遍开展促销活动，此前已对促销策略进行了梳理，相关内容可参考《促销活动一览表》。

    经历了上面的一系列操作，此时就可以加入购物车了。

    购物流程

    购物流程直接影响用户体验的。

    尽管流程上都是挑选商品、加入购物车、提交订单以及完成支付，然而针对不同类型的商品，我们需采取差异化的处理方式。例如，对于秒杀商品，我们能够直接生成订单，无需经过购物车这一环节。

    其次，在购物环节中，我们应更加注重营销的引导作用，即根据用户已加入购物车的商品进行相应的推荐。由于用户已进入这一阶段，购买意愿较为强烈，若能提供更多优质建议或优惠信息，将更有助于订单的完成，从而提升转化率。

    第三，每次在购物车中进行商品数量的调整时，必须即时获取商品的价格、库存以及促销活动的相关资讯。此类金额的核算、促销活动的获取以及订单优惠的重新计算对系统性能提出了极高的要求。若系统响应迟缓，将影响用户体验；若数据获取存在误差，可能导致用户投诉，进而引发订单流失。

    第四，系统设计阶段需关注系统的相互依赖程度以及未来功能的拓展潜力。若耦合度过高，将导致后续项目实施难度加大，因此需对功能进行合理划分。此外，还需重视操作的顺序性；某些服务需优先调用，而另一些则可稍后进行，这些因素均需全面考量。

    购物流程团队对产品和技术有着严格的标准，代码质量只有开发者自己最清楚，言行一致是必须做到的，这一环节同样是对个人技术实力和抗压能力的考验。由于涉及用户的功能一旦出现问题必须迅速解决，同时对于已存在的错误数据也要迅速进行修复。

    我持续参与的是后端系统的业务及系统架构设计，同时也在对前端环节的流程进行深入的学习和整理。不过，我认为其中最为关键的部分，比如购物车数据的存储方式、用户信息的保存方法，以及如何避免活动超卖等问题，目前仍需进一步研究和解决。

    订单结算

    1）结算页

    首先需考虑的是支付手段的挑选，可选的支付手段众多，现今现金支付已较为罕见，即便是采用货到付款，也普遍是通过支付宝、微信转账或刷卡来完成交易。

    此处提及的支付手段包括：支付宝、微信支付、银行转账、优惠券使用、积分兑换、礼品卡以及红包等多种形式。针对这些不同的支付手段，需分别调用相应的支付接口。值得注意的是，这一过程发生在用户尚未提交订单，即尚未进入支付环节的阶段。

    2）优惠的重新计算

    此处主要任务是对订单进行优惠额度核算，涉及诸如满减等优惠措施。这一环节同样是购物流程中的重要组成部分。

    3）运费计算

    在计算此次商品的运费时，需参照之前制定的运费模板，同时，是否免除邮费还需考虑会员的等级以及其他相关信息。

    4）订单的提交

    只有提交了才产生用户订单。对于订单有哪些信息需要记录？

    如果是外部渠道的订单，还需要记录外部订单号、合作平台标识等

    在这个阶段，订单理应保持在初始的待支付状态，尽管订单已经生成，消费者仍有权利选择取消。

    订单一旦生成，即占用商品库存。在此阶段，需为用户预留支付时间，且需根据不同场景进行区分。一般订单用户需在30分钟内完成支付；而对于秒杀订单，则要求即时支付。至于限时抢购订单，支付时间可设定为1分钟或5分钟，若超时未支付，系统将自动取消订单，并释放相应库存。

    用户若自行取消订单，通常在“待支付”阶段并无特别限制，一旦取消，库存便会随即解冻。

    还有一个需要指明的情况，那就是当前订单的具体存储位置。它无疑位于数据库中。但关键在于，目前订单是存储在前端的订单库中，暂时无需传输至后台的ERP系统。为此，前端主库与后端订单号之间必须建立一项拉单服务。

    十多年前，我曾主导了这个订单拉取服务的开发工作，至今已有多年。期间，技术似乎一直在持续进步，但业务模式并未发生显著改变。具体来说，我们依旧依赖多线程技术，以确保订单从前端迅速传递至后端的生产数据库，为后续处理做好准备。

    订单一旦创建成功，便要求用户进行支付。在此环节，需明确支付金额、支付方式以及需要接入的支付平台等细节，这些均需进行周密的设计。毕竟，与金钱相关的事务不容忽视，对于我们的技术产品来说，这一点尤为关键。

    举个例子：

    在进行跨境电商交易时，若消费者以人民币结算，而支付宝国际平台需将款项转换为港币，这就要求我们在调用支付宝国际服务时，必须准确记录汇率并进行人民币至港币的换算。若汇率获取不准确或记录出现误差，将直接导致交易金额的偏差，进而对后续的财务结算工作产生不利影响。

    在支付环节，鉴于使用了第三方支付接口，支付结果确认的反馈可能存在一定延迟，因此，我们需对反馈状态进行多次尝试确认。此外，我们还需对订单实施状态锁定，以避免用户进行重复支付操作。

    如果用户支付成功，那么这时要记录哪些信息呢？

    支付流水标识、交易编号、支付时刻、支付状况、支付金额等详细信息，首先确保了信息的全面性，其次，这些数据便于与第三方进行账目核对，即财务系统中的应收账款核对环节，最后，它们还服务于用户的退货、换货及后续退款等操作。

    在确保支付流程顺畅的前提下，应尽可能详尽地记录相关信息，可采用非同步的方式进行记录，但绝不能遗漏任何细节。对于涉及金额的数据，我认为保留一定的冗余是必要的，相较于不足，多余的信息更有保障。

    订单支付流程已顺利完成，因此其当前状态理应标记为“待发货”。在接下来的流程中，订单将经历拉单、拆单等环节，并逐步向下传递，后续情况将进行详细汇总。

    总结

    关于订单的处理，目前计划依据订单的不同阶段进行整理。撰写一篇高质量的文章可能需要数日甚至一周的时间，速度相对较慢，因此采用纯文字的方式可以加快进度。这也是为何在本篇文章中未绘制流程图的原因，而且对于包含众多节点的每个环节，绘制详细流程图耗时较多，过于简略的图示参考价值不大（后续将针对各个环节逐一进行详细说明）。于是我便选择用文字的形式与你交流，所谈内容仅代表我个人的见解，对于具体细节，我们还需共同商讨和进行设计。

    自从我加入“人人都是产口经理”这个平台后，几个月的时间里发表文章的频率有所增加，但内容或许略显简略。在2020年，我计划调整发文节奏，更加注重内容的精雕细琢。在此，衷心感谢您的阅读与持续关注！