交易不只是简单的算账

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