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