电商系统最终的目的还是下单支付，所以对于订单系统的设计也成了重中之重，本文站在从0到1的角度上概述订单系统搭建时需要重点处理的功能点，希望能给大家带来一点收货，同时也给自己做一个总结。

下面分别从以下几个方面讲解：

1. 支付后订单拆单处理；
2. 商品优惠分摊；
3. 订单价格体系；
4. 销售订单处理流程；
5. 售后订单处理流程。

一、支付后订单拆单处理

1. 为什么需要拆单？

客户同时在多家店铺下单，不同的店铺的商品在正常情况下是要拆开的，否则无法跟踪物流信息，无法分开收款和对账。

物流信息的跟踪：即便是同一商家的不同的货物，如果订单的商品分别需要从不同的仓库中发出，那么会存在多个发货单，多个包裹；不同包裹物流信息和状态肯定是不一致的，而且在系统中也需要分开收货和结账。

2. 拆单的处理细节点

需要根据电商平台的实际情况，确定拆单的维度，是根据不同的店铺进行拆单还是根据不同的包裹拆单，还是两者都需要。

拆单的节点：如果生成订单之后没有直接去支付，那么就会存在待付款的订单，从用户体验的角度上来说，用户肯定是更期望多个子订单一起支付的，这里建议在订单列表中可以以母订单的形式展示。

拆单的价格：如果被拆开的多个订单同时享受同一项优惠，如果处理好优惠金额在不同子订单的分摊也是需要注意的，剩余的误差需要放至一个子订单中。

二、商品优惠分摊

1. 为什么要对订单金额进行分摊？

首要因素是退款，在订单付款成功之后，如果不针对单个商品进行金额分摊，那么如果用户需要退订单中的部分商品，没法计算需要退的金额，需要分别退给商家和平台多少钱等。

财务对账：将优惠金额分摊到每个商品上，能核算统一母订单下的子订单分别分摊的优惠金额，比如：平台券，一个使用平台券的母订单最终需要计算每个子订单分摊的优惠金额，以确定每个子订单的实际付款金额和享受平台优惠的金额，否则无法与商家进行账务核对。

核算成本：通过把优惠金额分摊到每个商品上去，运营，财务或采购人员可以评估营销活动的成本。

2. 优惠金额分摊逻辑

按照最小粒度进行分摊：即优惠金额需要分摊到每个商品，且同一个商品采购数量大于1时，该商品最终只能有一个分摊后的价格。

优惠分摊比例：按照商品金额分摊对应比例的优惠，保证不同商品享受优惠的公平性，否则会出现商品应分摊的优惠大于商品的销售价或影响用户体验。

分摊顺序：先分摊多商品的优惠，再分摊店铺维度的优惠，最后分摊平台层面的优惠。

误差处理：减小误差主要途径是在算法层面上进行优化，同时也无法避免误差，多余的误差需要按照不同的优惠活动分别存储起来，在财务对账和退款的时候需要用到。

三、订单价格体系的设计

该部分是贯穿整个订单流程中最核心的部分，订单相关信息在需要展示在不同操作系统，如：平台总后台、商家端、APP、PC端、小程序、公众号，需要结合数据库的结构一起设计。

订单系统在数据库设计层面至少需要存在以下几个表：订单表、订单明细表、售后订单表、售后订单明细表（也可以把售后订单和销售订单结合起来设计表结构），分别需要定义各个不同表的字段及其含义。

比如，在我们系统中会定义订单中商品存在的价格层次：

1. 原价：即后台设置的商品初始销售价格；
2. 销售价：没有参加单品活动的商品的销售价为原价，参加特价/买降活动的商品的销售价为促销价；作为订单详情中商品统一展示的价格，还用来计算商品总额；
3. 结算价：商品经过店铺优惠活动分摊之后的价格；可以用来展示给店铺，作为他们的成本价，也用来计算该订单需要支付给商家的金额，该字段不能展示给采购用户；
4. 实际价：商品经过店铺优惠和平台优惠分摊之后的价格；主要用来展示给平台，从平台的角度衡量成本，关键是可以用作退款时实际退款给采购商金额的计算；
5. 满减分摊：商品经过满减分摊，分摊的金额；主要用于退款时计算需退还满减优惠；
6. 店铺券分摊：商品经过店铺券分摊，分摊的金额；主要用于退款时计算需退还店铺券优惠；
7. 平台券分摊：商品经过平台券分摊，分摊的金额；主要用于退款时计算需退还平台券优惠；
8. 已退数量：商品发生部分退货或退款的总数量（生成待审核的退款单时减数量，取消订单或退款关闭则把数量加回来）。

同理在订单列表和售后订单列表，也需要设计相关字段，限于篇幅和隐私限制，仅就核心事项进行说明：

1. 同一个字段，母订单和子订单分别需要有不同的解释；
2. 子订单金额之和要=母订单金额（否则影响用户体验且在退款时无法处理干净）；
3. 字段设计时必须兼顾所有系统相关页面需要展示的信息，对于销售订单，售后订单来说，用户、店铺平台各自分别需要看到什么信息，不能看到什么信息；
4. 字段设计时需要考虑订单优惠金额和退款时限制的最高可退金额；
5. 平台优惠未分摊完的金额需要放至子订单中。

四、销售订单处理流程

对于订单流程的设计，是电商系统设计中最基础的环节，不同业务场景的订单流程会有不同，最终核心离不开以下几个点：

1. 生成订单：一般来说在确认订单页面点加购物车按钮时生成订单，同时也进行库存的相关操作
2. 付款成功：从确认订单页面或订单列表中进来收银台页面选择支付方式进行支付；（订单销售数据一般也是基于已付款的订单进行统计）
3. 发货：付款成功和发货之间，可能涉及平台确认订单，ERP相关操作（订单状态变为已发货），同时需要进行库存的相关调整
4. 收货：点击确认收货按钮，进行确认收货，订单完成且状态变为交易完成
5. 取消订单：取消订单后需要生成退款订单，同时订单状态变为交易关闭（交易关闭可以定义为交易未达成，不涉及财务对帐，这个有时间再讲一下财务系统相关设计）
6. 申请售后：售后订单完成且退款成功后，如果是整单退款，那么订单需要变为交易关闭
7. 订单状态超时：包括超过一定的时间自动取消订单和自动确认收货等

在设计好各个订单处理环节及订单状态之后，需要定义不同状态下的操作按钮，操作按钮包括：立即付款、申请售后、确认收货、查看物流，当然需要注意一点就是用户操作的界面与后台商家或平台处理订单的按钮是不一样的。

此外订单流程往往需要涉及电商系统与ERP对接的问题，这一块也比较复杂，后面单独再聊聊开放平台的设计经验。

五、售后订单处理流程

售后订单的状态及操作按钮设计的思路与销售订单基本一致，值得重点注意的是：

1. 售后流程的设计需要结合实际的需求去考虑，是否支持部分退货，什么情况下可以退货，流程是怎样的，是否需要审核等；
2. 支付及财务清算方案会影响到退款的逻辑，所以需要结合一起考虑；
3. 退款时，如何处理分摊的优惠金额，按照什么金额给用户退钱，怎么和商户之间针对售后订单进行结算；
4. 退款时也涉及服务费退还，平台优惠退还等。

以上是本人对于订单系统的一点经验总结，讲的较为笼统，对于售后流程的处理还有很多细节值得去探讨，以后有时间可以单就售后的流程在详细介绍一下。

有补充或不对之处，欢迎大家指正探讨！

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

题图来自Unsplash，基于CC0协议