在电商平台中交易系统是最核心、最复杂的系统之一，涉及商品、订单、支付、营销、库存等不同领域的业务逻辑，本文对自己在负责中台的交易中心的过程中对业务思考的一些记录。
交易的本质是一个信息流、物流和资金流的转换过程，商家通过平台展示商品信息，用户获取商品信息后做出购买决策，用户付钱交换商家提供的商品和服务，商家通过物流或快递把货权转移给用户，如果用户对商家交付的商品或服务不满意可以根据平台运营规则进行退换货处理。
具体业务过程如下图：
而我们的交易系统就是要把整个交易过程中涉及的业务完整的记录下来，以备买卖双方随时进行跟踪、查看。
为了让我们记录的信息成结构性，我们把承载不同阶段的业务信息的对象划分成如下几类：
订单——记录交易双方的主体信息、交易品信息、交易的关键节点信息以及订单本身特有的信息；
发货单——记录卖家对订单履约过程的信息；
退款单——记录退换货信息处理过程的完整的信息；
资金流水——记录用户付款、商家收款、商家退款、用户收款以及与订单的关系的信息。
整体业务流程图如下：
下面以以上三个单据为核心，对相关业务进行分解。
一、订单业务分析
首先，我们看下订单的基本信息结构，如下图：
在订单的基本信息中我们会包涵订单号、订单创建时间、订单状态等关键信息。
其中订单一般会有主子订单号之分，这是订单拆单业务的产物（拆单在订单中是一个关键业务，后面单独进行说明）；
其中待审核状态在有些业务中存在，有些业务又不存在，我们在做中台时该状态是一个可选择的节点。
买家和卖家信息一般记录其相关的ID、名称或等级等信息，卖家还需要记录其店铺的信息。
开票信息指的是用户在下单是选择的开票类型以及提交的开票资料，普票和增值税、个人和企业其所需的开票资料不同。
支付信息只记录支付时间以及支付流水号，该流水号是能够贯穿交易、支付以及第三方的一个表示。
订单结算信息一般的结构如下图：
每一项优惠或者折扣都需要分开记录，而优惠、折扣和抵扣都是由对应的业务系统进行业务处理后的返回值。
收货人则指的是收货人的名称、手机号以及地址信息。物流信息明细一般都是通过第三方接口获取，再记录到系统中。
最后还有一部分则是交易品明细，需要注意，订单中记录的交易品明细一定是下单那一刻确认的交易品信息，包括交易品的基本信息、价格信息、数量等。
这就要求我们在系统中需要有交易品版本的管理，能够准确的记录在某一个时间段内，任何一个交易品的准确信息。
订单中的交易品明细一般的信息结构如下：
在整个信息结构中最难的时如何获取优惠、折扣和抵扣，而在一般的系统设计的逻辑步骤如下（以优惠券优惠为例）：
在提交订单时，需要把订单中的商品及商品相关的信息和用户选择的优惠券信息提交给营销系统；
营销系统校验优惠券的合法性并校验能够使用商品
根据可使用的商品按“（商品金额/Σ能使用的商品金额）*优惠券优惠金额”进行分摊
若有除不尽的情况，则使用最后一个商品补全的方法进行处理
系统需要校验订单商品的优惠金额不能超过商品的售价
返回分摊结果给订单
在这个分摊的业务过程中，需要注意的有两步：第3步和第5步。
第3步，一般各个结算位对应的分摊独立进行计算，以商品售价位基准进行分摊，独立计算的好处是各个结算位互不影响，优惠金额是可预估的；
第5步主要是考虑多种优惠叠加使用，可能会导致订单商品优惠超额的问题；
例如：平台优惠券规则：满1000减900，店铺优惠券规则：满1000减700，此时叠加使用就会出现超额问题，在一般规模不大的电商平台中直接限制优惠不能叠加使用规避这种问题，但我们在设计中台时，是需要充分考虑各种业务方的需求。
最后，在订单这部分的业务中还有一个十分重要的业务逻辑需要进行说明，那就是订单拆单。
拆单主要为了满足在财务结算以及物流发货上的相关需求，也能够让每个商家更好的完成履约。在电商的交易、物流流程中有可能需要拆单的环节有：购物车、订单提交、发货/配送、发包裹。
前两个环节属于交易业务内，后两个环节属于物流配送环节，在此我们仅对前两个环节的拆单进行说明。
在交易环节拆单主要有这几个常见的因素：交易模式（海外购）、品类（药物、生鲜或一些特殊品类）、店铺。交易模式拆单是因为其在订单确认时需要进行操作和展示的信息完全与普通交易不一样；
例如：海外购需要进行一些必要的资质认证、关税以及对金额的一些限制等等，会员店需要进行资质认证或有特殊的结算方式等；而品类主要会影响下单的环节，例如：药物需要先有处方，在审核通过后才能下单等；而店铺则是因为要分成不同的商家进行履约、结算而需要拆分订单。
在拆单时我们需要考虑一些几个业务：
主子订单的数据结构，以及状态对应关系；
拆单后订单与支付单的对应关系；
拆单后用户支付的操作处理，一般如果一次下单过程中有使用优惠券、活动等则需要进行合并支付。
关于订单相关的业务处理到这里算是告一段落，其核心是订单状态以及订单金额相关的数据结构和分摊逻辑设计，下面我们进入履约交付环节。
二、订单发货履约
订单履约业务从商家进行发货操作开始，一直到用户签收并完成订单为止。
严格意义上的履约应该包涵如下步骤：发货-拣货-出库-配送-签收这几个环节，但拣货-出库-配送这三个环节是属于物流管理系统（WMS）所负责的业务，我们在此不做过多的阐述。
在发货时，我们需要注意的是这是从信息流转换到物流的过程，在当前大家都追求线上线下融合的大趋势下，我们需要提供一个灵活的发货业务处理逻辑。
首先我们能够满足一个订单多次发货、多个订单合并发货这些场景；
其次在电商系统对接了物流系统后，我们需要能够做到发货单具备路由的功能，即系统能够根据客户的地址和仓库的地址、货物在仓库的库存情况以及仓库业务处理的能力等因素进行自动选择，以达到库存效益和用户体验之间的最大收益。
有发货路由的整体业务流程：
发货单需要记录：发货单基本信息、订单基本信息、收货人信息、货品信息、发货仓信息以及最终的物流配送信息。
用户即能在订单中查看商品的物流情况，而一般的订单中的物流信息都是通过在发货单上面记录的快递单号/运单号在通过第三方物流信息对接平台获取的。
在商家进行发货操作后，用户能够对商品进行签收，签收操作的目的是确定货物物权的转移，很对企业会以该节点作为财务中收入确认的触发节点。
三、退款相关的业务
1. 退款的整体介绍
退款业务可分为三个大的类型：仅退款、退货退款、换货，本期不实现换货业务。
仅退款指的是指对资金流进行处理，不产生物流；退货退款指的是需要处理物流及资金流。
那再什么情况下会产生退款业务呢？首先我们回顾下整个交易流程是怎么样的，如图：
这是业务简化后的状态图，在业务中订单支付后只要进入待发货（如果有待审核，也可）状态以后，在订单状态为已完成之前，都能发生退款业务。
具体场景如下：
商家还未发货，用户发现购买的商品不是自己需要的，申请退款，可对已提交的订单中的部分商品进行退款，也可整单进行退款；
商家已发货，但用户还未签收时用户进行退款申请，可对订单中的部分商品进行退款或整单进行退款；
用户已经签收，但订单还未进入已完成状态时用户进行退款申请，可对订单中的部分商品或整单进行退款；
2. 具体场景的业务分析
对于场景一，商家还未发货，故无物流过程的处理，我们只需要处理退款商品的库存及资金即可，逻辑如下：
用户申请退款，选择需要选择进行退款的商品（有状态限制：待审核、待发货、待收货、待签收、已签收），并填写相关信息（退款金额、原因、凭证等），提交退款申请，此时需要在订单中的商品维度标识改商品状态为“退款中”
商家对退款申请进行审核，审核不通过则打回给用户，改变订单中的商品状态为“待发货”；商家审核通过退款申请后，可进行确认退款操作，确认退款后系统按支付渠道原路退回，并产生退款资金流水记录，确认退款成功后联动订单，处理商品状态（修改为：“已退款”）及订单状态（见订单与退款申请单联动说明）
退款成功时还需要对商品库存进行处理，自动返还退款商品数量到库存
若订单下的所有商品均为“已退款”，则需要进行优惠券、积分等资产的返还，若活动有资格限制，也在整单都退完是才返还资格
对于场景二与场景三可使用同样的逻辑进行处理
用户申请退款，可选择退款类型：仅退款、退货退款；仅退款的流程与场景一 一样，唯一不同是不需要进行库存返还。选择退货退款时需要选择进行退款的商品（有状态限制：待审核、待发货、待收货、待签收、已签收），并填写写相关信息（退款金额、原因、凭证等）提交退款申请，此时需要在订单中的商品维度标识改商品状态为“退款中”
商家对退款申请进行审核，审核不通过则打回给用户，改变订单中的商品状态为“待发货”；商家审核通过退款申请后，用户进行确认退货操作，填写快递相关信息，确认后申请单状态为“待收货”
商家在收到用户寄送的快递后，可进行确认收货操作，申请单状态为“待退款”
商家可在退款申请单商家进行确认退款操作，退款统一为原路退回（使用第三方支付平台的退款接口进行退款）
退款成功时还需要对商品库存进行处理，自动返还退款商品数量到库存
若订单下的所有商品均为“已退款”，则需要进行优惠券、积分等资产的返还，若活动有资格限制，也在整单都退完是才返还资格
申请退款在售后周期结束之前，但审核在售后周期结束之后。
订单签收时的处理逻辑：订单到已签收状态时，需要判断订单中是否有商品是否有状态为“退款中”，若有，则不启动售后结束时间；若没有，则启动售后周期。
售后申请单结束时的处理逻辑：在每一次申请售后单确认退款后，需要通知订单，改变商品状态，对订单中的商品进行扫描看是否所有商品状态都为“已退款”或“已签收”，若是，则启动售后结束时间；若不是，则不启动售后结束时间。
五、总结
交易系统勿用质疑是电商中最核心的模块，它是信息流、物流、资金流三流合一的关键，一个灵活且设计合理的交易系统是企业业务运行和用户获得良好购物体验的基础。
在做交易系统的设计的过程中深刻的认识到业务的复杂性是客观存在的，作为产品我们要做的就是管理这种复杂，如何管理呢？
把业务需求结构化，产品信息结构化以及让所有的功能都符合业务人员实操逻辑是关键，而这种结构化的思维方式就需要我们产品能够在设计之初并对业务进行抽象划分好阶段、类别，输出的产品说明文档要保持逻辑和表述一致，使用通用的产品语言。
而关于资金相关的业务在交易系统中未进行详细阐述，后期在总结支付结算相关业务时再行说明。
