上海
大厂即使就是个“草台”班子，但，依然阻碍不了其成为大厂
最近频繁跟头部机构的同学聊天，知道的越多，心越凉；哎呀，妈呀，辣眼睛——老大哥们的支付清结算都玩的这么拉胯么，我们这种小弟机构还在吭哧吭哧的追求“完美”的设计
下面，咱就唠一个看似“顶级拉胯式”的设计，但却深得民心，先看场景
一个撮合型交易平台，如京东、淘宝、美团等，必然会存在逆向业务，比如订单退款，出现投诉以后平台要扣商家一笔罚款等场景
如果商家账户余额不足，就形成了“欠款事实”，即使你不去扣他的账户，欠款已经发生，可以用商家保证金兜底，但，保证金也不是万能的
怎么记这笔账，我想有4种方法，看看你钟情能一种
01.亲爱的，商户余额不足，请您等待
这种方式最粗暴，业务请求扣减商家账户，余额不足时直接返回“余额不足，扣款失败”
账户简单了，难题甩给了业务，业务层收到了失败结果，就要想了：我该怎么办？
罚商家的钱还好说，毕竟是一笔意外之财，那就再等等，等商家余额充足时，再发起扣除
而对于订单退款来说，用户要退，而商家账户余额不足，那要不要给用户退，不退吧，对不起用户，退吧，对不起自己
如果不给用户退，那么就相当于用户发起退款时要校验商家余额是否充足，不足时便限制退款
这样的策略，对用户来说必然是体验的极大损失，毕竟现在大家都崇尚“仅退款”了，你还这么“霸道总裁”范
如果给用户正常退，因为账务系统并没有受理业务侧的扣款请求，那么，在业务层就会积压“待扣款”的业务单据，相当于业务不能及时完结
此种情况，相当于业务要关心“钱”了，业务肯定会骂了：都让我干了，要你们账务有何用
02.业务正常完结，账务侧排队
本方案将释放业务侧压力，业务请求过来以后，直接返回接受成功，业务侧不用关心账务层的处理结果，专人干专事
入账状态置为“待扣款”，等待商家账户有新的入账执行补扣
这个方案释放了业务侧的压力；但是，对于账务来说，那么多排队的，心里也不干净
一方面待扣款的凭证越积压越多，另一方面虽然商户余额不足，但是还有一点余额，这时候要不要有多少扣多少，极力减少损失；或者给商家冻上
如此一来账务处理变得非常复杂，永远有无法入账的凭据，逻辑复杂了，风险就来了
03.简单粗暴，直接干成“负”的
这下整个世界都安静了，简单至极
随便扣，直接让账户扣成负值，后续有收入直接抵扣了负值，非常简单
当看到一个商家的账户余额是负值时，就知道，他欠我们钱了，重点关注一下
这部分欠款，可以通过后续的收入自动偿还，也可以通过提供给商家充值的工具来偿还这部分欠款
当然，该方案也需要一些新的能力，比如风控的能力，能透支，但是不能无限透支，需要一定策略加以限制，比如设置透支限额，需要干点嘛
当然，有时候可能会有人反对扣成负值，如果是复式记账就还好，毕竟借贷只是符号，余额出现在借方，商家就欠我们钱了
还有一个办法
04.欠款，咱换个地儿记着
可以透支，但咱别记到原来的收入账户里，扣成0为止，剩下的走另一个账户
借贷分离，小鸡不尿尿，各有各的道
为商家开另一个账户，一个专门记透支部分的账户——欠款账户
借方账户，贷方账户，量子纠缠态；你不够我借你，你够了，要还我
为了在复杂中寻求简单，我们约定，欠款账户只允许与正常账户发生往来，不允许单独执行账务操作
也就是，欠款账户封闭在正常账户内，我称其为“量子纠缠户”
支出类场景
判断收入账户余额是否充足，如果不足，则，“欠款账户向收入户垫资”，让收入户余额充足，然后再进行扣款处理，相当于对于收入账户的支出永远是在余额充足时进行的
收入类场景
收入户正常入账，需要额外增加一个随后的子账务处理事务
判断欠款户是否存在余额，如果存在，由账务系统自己发起一个“还款”的账务处理动作，将一部分收入余额转入欠款户进行偿还
如果你是我的领导，你觉得怎么样？让做么
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
