B端平台产品建设手记-订单中心篇（上）

导语：订单中心是很多B端平台都不可缺少的一个模块，本文作者结合自己多年的B端产品项目工作经历，将自身的平台建设经验与反思进行总结，希望可以与大家一起分享交流。

订单中心是多数B端平台都会涉及的一个模块，本质上为单据管理，而销售订单是单据管理内的一个类目，其分析逻辑可拓展到其他类目，如订货单、意向单等。

笔者之所以选择订单中心作为第一篇总结，也是由于订单中心业务实际上牵涉到平台内多方业务人员参与，如销售、市场、库管、财务、物流团队、商家甚至领导团队，具有更广的普适性与讨论价值。

从订单业务层面上，本人将订单数据流转过程总结为四个阶段，分别是订单创建阶段、订单支付阶段、订单完成阶段和订单售后阶段，这四个阶段将串联起订单业务的整个生命周期，涵盖商品中心、营销中心、库存中心、财务中心和物流中心五个业务模块。

一、订单创建阶段：状态与库存的处理逻辑

首先是订单创建阶段，从用户开始进入平台购物界面开始，订单业务便开始了。商品展示界面通过商品中心和营销中心拉取信息，并将信息运算结合后展现到用户眼前，供用户挑选。

用户在选中商品加入购物车后，图中有一步校验商品库存是否充足的逻辑，该逻辑目前在市面上存在多种缺货处理方式，如京东商城是在用户进入界面上便提示用户已缺货，禁止用户加入购物车，而淘宝/天猫商城是提示无货后，依然支持用户加入购物车，本人则更偏向于后者，因为京东商城在缺货商品无法加入购物车的情况下，用户想要保留下次快速找到商品的途径，大部分都是通过收藏商品来实现。

而实际情况下，大部分用户对购物车的关注度普遍高于收藏夹，这也就相应减少了缺货商品后续的曝光频率。

如果用户可将缺货商品加入购物车，那么用户下次看到商品到货，即可直接在购物车界面发起购买操作，而不需要像收藏夹一样，进入商品详情页发起购买，这也可以减少操作环节，增加成交几率。

用户发起支付后，订单中心将根据最新的商品信息和营销信息，计算实际支付价格后生成未支付订单，有些朋友可能疑惑订单为何还要区分未支付和已支付两种状态，而不是在支付成功后直接创建已支付订单。

我的理解是这样的，首先是用户发起支付动作后，到支付成功存在时间间隔，用户可能在这个间隔内完成支付，也可能在这个间隔内由于各种原因（卡机、接电话、余额不足等）退出支付界面导致支付失败。而此时为了让用户在支付中断后可以找到原商品进行支付，则需要保留一条未支付的订单。

这个时候有的朋友可能又会疑惑，为何用户不直接重新购买商品呢？

我认为主要原因是优惠，优惠一般来源于平台、商家或商品的促销策略，且该策略具备时效性。用户在挑选商品时可能由于优惠而下单，如果支付失败，那么用户下次找到商品支付，则可能面临促销失效而支付价格提升的情况，用户将大概率不再继续购买该商品，如果支付失败为平台责任，甚至会导致用户对平台的体验感直线下降。

另外，在下单到支付的时间间隔中，用户都有可能面临促销策略已失效的情况，若等到支付时再计算优惠生成支付订单，将可能导致用户支付金额与下单金额不匹配的情况，最典型的便是用户晚上12点前下单，12点后支付的场景。

讲完未支付订单，这里将来到订单创建阶段的最后一个业务环节-锁定库存。

锁定库存的概念是，商品的物理库存数量不变，但该库存数量已被锁定为不可变更移动的状态。通俗的说就是，这个库存被预定了，不能卖给别人。他的作用在于防止订单支付数大于商品库存数，导致最终无法出货的情况。

另外，并非所有平台商家都会加入锁定库存的概念，该概念是由于订单未支付状态的存在而设计，而部分商家为了避免竞争对手恶意制造大量未支付订单导致正常买家无货可买的情况，也会对该锁定库存策略进行一些限制，如锁定库存比例告警、非强制无货状态等。

二、订单支付阶段：订单的拆分和财务记账

用户支付完成订单后，订单中心将同步该订单为已支付状态。与此同时，若用户单笔订单内存在多个商家，且商家之间为独立运营，那么订单会做拆分处理，拆分一般为母订单根据各商家的商品价格与促销活动，对商品和支付价格进行拆分，此处需要注意的是，拆分过程中可能遇到优惠金额无法直接整除的场景，需要明确好余数应如何处理。

如用户购买A商家商品共10元，B商家商品共20元，且使用了1元优惠券，那么简单的按比例划分优惠额即为A商家优惠1*10/（10+20）=0.333…元，B商家优惠1*20/（10+20）=0.666…元，若直接去尾数，将直接导致0.3333…=0.33，0.666…=0.66，总优惠=0.33+0.66=0.99的情况，与实际优惠不符。

那么四舍五入行不行呢，上面的案例是没问题的，但若遇到三个商家各10元，优惠1元的场景，就会遇到同样的问题，最后的优惠额会等于0.33+0.33+0.33=0.99元。因此，在这个时候，一般会引入盈亏池的概念。

盈亏池的概念即为，不论你采用的是直接去尾数、向上下取整还是四舍五入的算法，如果算出来的实际优惠额大于订单优惠额，那么平台将承担该部分损失，记为亏损；如果实际优惠额小于订单优惠额，那么平台获得该部分差价盈利。

总体上，总的盈利和亏损是不大的，只是为了保证实际财务收入与单据保持一致而已。

而在不引入盈亏池的情况下，一般会这么处理，当存在多个商家享受同一个优惠时，系统将计算前两个商家的优惠额，并将最后的差额作为第三个商家的优惠额，如此便可保证用户支付金额总和等于总商家收入金额总和。

如上面案例A/B/C三个商家，共同享受1元优惠，那么A/B商家享受的优惠额为0.33，C商家享受的优惠额则为1-0.33-0.33=0.34。

说完拆单，另外一个需要注意的便是财务记账，一般来讲，用户支付完订单，财务中心将会增设一笔收入数据，该收入数据一旦确认，便不可再次更改，原因便是为了保证财务数据与流水数据保持绝对一致。

流水数据常见于第三方支付场景，如财付通、支付宝和银联等，用户通过第三方支付，支付完成后第三方服务商将提供与该笔订单相对应的流水单号，因此流水单号也是财务对账中，出现差异时可依赖的重要校对手段。

另外，订单在财务模块还涉及到另一个分支-手续费，目前大部分第三方支付服务商会收取收款商家一定的手续费用。那么该部分费用在用户支付完订单的时候，系统也会同步根据手续费率计算该笔订单手续费，并登记到支出项。

需要注意的是，手续费需要先明确由平台方还是商家承担，若商家承担，也会遇到按比例平均后，实际总费用高于或低于登记费用的情况，这时候也可以引入盈亏池进行处理。

那么本篇文章主要总结了订单创建阶段和订单支付阶段的流转过程与相关概念，要点包括：

• 缺货状态下的交互处理
• 订单状态的定义逻辑
• 锁定库存的基本概念与作用
• 订单的拆分与记账
• 优惠额拆分的处理方式（盈亏池/按整额取余数）

那么，B端平台产品建设手记-订单中心篇（上）就到此结束，下篇将就订单业务中的完成阶段和售后阶段进行论述，欢迎大家提出意见与问题，进行更深层次的交流。

本文由 @RB产品手记 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议