交易不只是简单的算账
在商业世界中，交易是企业盈利的核心环节，而交易流程的复杂性往往被忽视。本文深入探讨了交易流程中的各种细节，揭示了交易背后的复杂性和重要性，供大家参考。
交易里，其实糊涂账挺多。
01
产品中大多数的业务，最直接的盈利点都是来自：交易中的差价。
这个比较好理解，假设在电商应用中下了一单，支付了100块，该笔交易的资金并不会全部给到卖家，通常会采用分账的模式，服务平台会从中收取一定比例的金额。
对于供货商家来说，扣除掉各种成本之后，剩下的才是店铺盈利，每一笔交易在多个中间环节都可能产生差价，其它服务或者咨询类的交易场景也会遵循这个基本模式。
差价不会消失，没有或者减少中间商，也会流向某个环节。
当一笔交易发生之后，需要给涉及的多方都创建交易账单，用来跟踪资金的流转和状态以及最后的结算，比如电商场景中的购买，通常包括销售商家、服务平台、下单用户，交易的资金通过平台的支付渠道托管在第三方，到了指定的账期之后，才会执行真正的结算流程。
在这个过程中，参与方都需要资金的明细记录和对账。
值得说明一点的是，交易流程更侧重资金层面的管理，订单流程更侧重商品和销售服务层面的管理，交易并不一定全是来自业务订单，业务订单也并非一定产生资金流水，只是常规购买场景下，订单和交易两者的记录和状态是同步进行。
参考积分兑换场景，用户使用服务平台的积分系统，免费兑换了某个店铺的商品，虽然没有直接产生交易资金，但是平台和商家之间有积分结算规则，可以围绕单品或积分设定各自的结算规则，只是对用户来说可见性并不明显。
据研发同学说，编程的自信都是交易流程锻炼出来的。
02
交易在大部分场景中，都会有相应的关联订单，所以理解订单的逻辑，自然也就明白交易的流程，但是在不同的产品中又有各自的运营策略和业务特征，产生交易的场景自然花样百出，不过最基础的逻辑不会改变。
资金在什么场景中，出哪些账户，进哪些账户。
从订单交易流程来看，当用户预下单的时候，会生成一笔待支付的订单，实际上交易记录也是待支付的状态，只不过产品的切入口是订单业务场景。
当用户完成订单支付时，产品对接的第三方支付渠道，会回调和通知系统支付成功的结果，交易记录也就会转换到支付成功的状态。
如果是多个商家分账的交易模式，此时交易记录也会根据订单的拆分模型进行拆分创建，比如电商场景中，在多个店铺同时下单，支付成功后自然要生成店铺的交易账单，然后才能进行分账结算。
在指定期限内当用户取消订单时，围绕订单所创建的交易记录也会转换为已退款状态，订单取消的期限自然小于分账结算的期限，以此确保资金的安全交易。
交易在业务中很常见，但是在不同的场景中流程上的差异又很明显。
03
不论是B2C交易，还是B2B交易，又或者是B2B2C的模式，虽然都很复杂，但基本原理是相似的。
复杂的场景，还是要先从结构模型分析。
交易账单的结构模型，其复杂程度丝毫不输订单，订单虽然复杂，但是其管理流程的边界在产品系统的内部；然而交易依赖的支付能力，可能走线下支付或者线上对接第三方支付渠道，如果集成的渠道过多，还会增加对账的难度。
从产品的角度看，交易的结构模型至少分为下面几个大模块：账户资金、交易记录、支付渠道、对账结算；每个模块的管理和流程逻辑都具有相当的复杂度。
【一】账户资金
商户想在一个平台进行交易，必须先入驻平台集成的支付渠道并创建结算账户，账户资金通常涉及总金额、保证金、可结算金额、冻结中金额等几个关键指标，商户可以在平台系统内查看资金情况，也可以直接在第三方支付系统查询，理论上两个系统内的账户应该保持一致，但是也无法排除异常情况，需要系统自动完成对账或者人工平账。
通常来说，C端用户可能也有账户或者钱包的概念，但是更多是用来存放平台或者商家发放的红包，一般是不允许用户直接充值，这样存在资金池的风险隐患。
【二】交易记录
交易记录的结构本身并不复杂，无非就是账户在什么时间，什么业务场景中，向什么账户支付了多少金额，需要生成完整准确的记录，不同的业务场景中可能会存在支出、收入、退款、提现等记录类型，同时记录要关联交易场景的业务单号，方便查询详情信息。
【三】支付渠道
如果是B2C业务，支付渠道通常对接微信和支付宝，方便用户交易；如果是B2B业务，那支付渠道的可选项就很多，甚至不排除走线下合同结算；在支付平台也有账户明细和交易记录，并且会作为对账的依据，需要定期下载并导入平台的对账系统中。
【四】对账结算
定期对交易相关的账户进行统计对比，比如平台账户、商家结算账户、消费账户。
从支付渠道下载交易流水作为标准，对比平台的交易记录，分析相关账户的资金收支是否平衡，如果没有异常情况，则按照指定的账期完成对应的金额结算；如果存在异常情况，则以支付流水作为依据，对相关交易进行调整并对账户资金进行平账，分析系统存在的问题并且优化。
值得一提的是，产品层面要明确交易资金的计算规则。
金额计算通常是保留两位小数，实际在计算时很难保证都是精确的两位小数，而且金额一般不执行四舍五入的算法。
所以在交易计算时，采用高精度的数值且计算过程保留多位小数点，在相关账户汇总之后再截取两位小数，然后对比交易的金额是否有误差，将误差的金额再分配即可。
其实产品的自信，也是交易场景炼出来的，复杂的事情干多了擅长闪避，也称经验。
04
在B2C的交易场景中，交易流程从产品和系统层面分析具有复杂度，不过这种可见的复杂相对好管理，流程自然也稳定和可控；而在B2B的交易场景中，复杂度并不直接体现在产品研发上，难度却比B2C交易高很多。
B2C交易高频周期短额度低，B2B交易低频周期长额度高。
B2B的交易中，由于交易金额偏大且商品库存周期长，买方肯定希望付全款的时间越晚越好，卖方肯定希望付全款的时间越早越好，双方都希望优化运营资金提高利用率，这样就会形成财务诉求的冲突。
最近几年，多少企业倒在了财务走OA的路上。
解决买卖双方利益冲突的模式也不复杂，引入一个资本方，在完整的交易周期中，资方短期内先向卖方支付货款，然后按交易账期向买方收取货款，即供应链金融中的反向保理模式。
复杂的是，哪些企业可以被资方认可，使用该模式。
反向保理的基本流程：供应链中信用好的核心企业（买方）与保理商（资方）签订协议，指定可以参与反向保理计划的供应商（卖方），当供应商与信用企业交易会生成应收账款，供应商可以选择将收款单出售给保理商提前获得资金，到达付款期限后信用企业向保理商支付款项。
理论上这是合作共赢的局面，资方可以赚取一定的回报，卖方双方缓解现金流压力，提高了资金运营效率，有助于公司的积极正向发展。
但是在实践中，理论一般都不是对手。
在这种交易模式中，如何鉴定核心的信用企业是关键问题，基于信用评估模型或者财务指标分析等手段，也只是从理论上能获得一个似乎客观的报告，信用的本质会占星术都未必算的明白，可以了解一下某知名电商的供应链金融诈骗事件，只有想不到没有做不到。
05
面对常规的B2B2C的业务模式，去全面的分析和理解整个供应和交易链路，再从功能模块入手做流程设计，这样可以提升产品和系统的容错率。
无论是B2C还是B2B交易，虽然从企业的组织协作上看是两个环节的事情，但是其基础流程就是商品的买进和卖出，提高全流程的协作效率，就可以促使交易的快速完成。
此前参与过某个供应链交易的项目，在梳理整个业务链路后，将产品初期的迭代节奏规划了如下几个版本。
- B端供应商和销售商入驻，开店审核流程，C端用户注册登录模块，即产品核心角色的接入。
- 商品体系的搭建，实现供销两端商品的上架管理，以及B2B和B2C的商品浏览和搜索。
- 基于不同环节的交易场景设计订单管理，集成第三方支付渠道，实现订单管理的完整流程。
- 根据产品初期需求，实现简单的营销工具管理，涉及优惠券发放与核销、限时低价抢购活动。
这样供应链交易线上的基本流程就搭建完成，很多线下可以手动操作的模块初期都不涉及，后续在产品迭代中又依次实现了物流仓储接入，商品评价，订单结算，数据埋点分析等模块。
产品体系的初期，以线上业务交易为核心主线。
其中的基本逻辑就是：目标用户的接入，不同用户对于产品的关键需求，然后打通各个场景的衔接流程，这样就形成了最基本的业务模式。
对于交易这个场景来说，供采销的链路就初具人形了。
