西安烽盈网站建设推广,给企业建设网站的意义,福建交科建设有限公司官方网站,深圳企业网站建设服务哪家公司好转载自 互联网账户系统如何设计
在很多互联网公司业务发展的早期#xff0c;业务模式比较单一的情况下#xff0c;涉及用户账户资金交易相关的逻辑也比较简单#xff0c;但是随着公司业务模式的不断创新及类型的多元化发展#xff0c;会渐渐发现现有系统账户逻辑越来越雍…转载自 互联网账户系统如何设计
在很多互联网公司业务发展的早期业务模式比较单一的情况下涉及用户账户资金交易相关的逻辑也比较简单但是随着公司业务模式的不断创新及类型的多元化发展会渐渐发现现有系统账户逻辑越来越雍肿不仅难以支持新业务的扩张对现有业务的支持也适配困难最终导致新业务系统不得不重新搭建自己的业务账户逻辑造成重复建设不说也往往给后续的财务资金核算造成混乱。 以某互联网A租车公司的业务发展路径为例?
阶段A
A公司在早期开展租车业务时根据用户使用场景规定用户必须在缴纳押金以后才可以租车并且支持用户进行余额充值余额可以支付租车费用以及购买相关优惠产品。所以账户资金流是这样子的 通过上述设计基本上就满足了简单的业务需求用户缴纳押金单独存放在一个押金账户用户的每次押金冲退都记录账户流水(缴押金记退押金记-)用户余额充值单独存放在一个余额账户用户的每次余额充值、消费、退款都记录账户流水余额充值记、余额消费记-、余额退款记-。
事实上以上账户逻辑的设计基本已经能满足业务早期的发展的需要了并且如果账户流水记录完整例如记录必要的业务类型如余额购买了一张租车次卡那么后续也能基本满足早期业务的财务核算需求。遗憾的是很多公司在类似以上简单账户逻辑的设计上都比较混乱如有的公司将账户直接绑定在用户信息表上、有些直接更新账户余额没有完整记录账户流水或账户流水记录业务信息缺乏等这种情况即使业务没有多元化发展也很难满足后续业务逻辑的扩展特别是会造成严重的财务数据核算困难更不用谈业务多元化发展后如何能够快速支撑了造成这种问题的原因是多方面的这里也就不在赘述。
下面我们继续看A公司租车业务的发展演进情况
假设在A公司租车业务发展过程中为了鼓励用户进行余额充值采用了充值返现的形式进行活动如“充值100赠送20”此时用户余额账户的总金额应该是120那么账户逻辑如何支持呢 这里注意之所以需要区分余额中真实充值和赠送的原因在于如果产品逻辑允许余额退款那么清晰地区分了真实充值和赠送所对应的余额的话退款逻辑的实现将会比较简单否则就会变得比较痛苦并且不清晰的逻辑也会增加造成公司资金损失的风险另外如果余额返现账户变动流水记录得比较明确的话对财务后续的收入核算也会方便很多。
但是是否这样就能满足业务需求了呢
显然这样还不能让逻辑完全运行起来因为增加了账户相应地交易逻辑与资金逻辑都需要进行相应的改变才行以上业务场景中原来余额充值只需要调用余额账户记账一次现在需要根据充返逻辑再调用余额返现账户记账一次而余额消费则需要根据业务规则进行余额消费记账假设业务规则为“余额消费优先扣减余额返现账户再次扣减余额账户”那么系统交易及记账逻辑如下图所示 从逻辑上看业务交易系统需要根据业务规则多次调用余额账户及余额返现账户进行记账并且需要从流程上保证两个账户记账调用的事务一致性例如一笔消费订单金额为20元此时余额账户余额为10元余额返现账户余额为5元在优先消费返现账户金额扣款5元后无法再从余额账户消费15元时交易失败后需要回滚余额返现账户消费逻辑,余额返现账户“交易冲正 5”。 阶段B
在阶段A中单个业务会根据不同的产品设计进行账户逻辑的迭代增加余额充返账户后虽然从账户逻辑层面只是增加了新的资金账户但是交易逻辑却是进行了较大的变更和调整如果此时该业务场景又出现新的逻辑变化例如某一天该租车业务针对某些信用良好的用户进行免押金用车活动并且支持这类用户在退押金时可以选择将押金的全部或部分金额进行余额充值那么在流程设计上还会存在账户转账的情况押金账户-余额账户。
每次产品业务的迭代涉及用户资金逻辑都不免会影响交易逻辑及账户逻辑本身但如果业务品类单一这种迭代及扩展通过硬编码方式多少还能继续支持。但是如果随着公司业务向多元化发展问题往往就变得复杂了。
假设A公司在主营租车业务发展态势进入到趋于平缓的阶段后为了扩展业务范围需要尝试新的业务例如某团队提出不能仅仅只搞租车也得弄个网约车平台那怎么弄 首先肯定是需要先集结队伍啦。集结完队伍就需要好好分析分析下业务场景了我们先大概看看一个网约车平台的大概业务场景是什么样子的其中涉及的资金交易的流程应该如何设计呢
在A公司的租车业务中从参与角色角度来看涉及的逻辑并不算太复杂只有“用户、车、租车公司(内部可称租车业务线)”而从交易场景上看用户缴纳押金、预存余额及余额消费都只是单向的C-B交易模型如果不考虑公司层在线交易账户体系这里是指公司层面的交易账户业务复杂度还不算十分复杂并且在这种单向业务模式下没有公司层面的在线交易账户本身并不影响业务流程收入核算只需要线下计算即可这也就是为什么前面会特意强调账户流水业务关键信息不能缺失的原因了。
而约车业务则是多向的C-B-C-B的交易模型因为从参与角色上看除了普通打车用户外还有司机、打车平台都会紧紧地参与到整个业务流程中而从账户资金流上看用户支付的车费不会以C-C的模式直接支付给司机而是会由打车平台代收打车平台扣除订单抽成后剩下的车费才会打到司机在打车平台开的账户上司机才能从个人账户提现。 从上图的分析中我们可以看到我们需要为普通用户、司机账户、打车平台分别设置必要的账户逻辑普通用户账户逻辑与之前的租车业务比较类似用户可以直接支付打车费用、也可以通过余额充值后使用余额支付打车费用而平台则需要代收用户的打车费用并且需要按照服务规则从代收的打车费用中扣掉部分服务费然后通过代收/付平台账户将车费实时结算给司机端收款账户司机通过个人收款账户发起提现后经过结算账户完成提现。资金流如下 此外为了满足产品逻辑的扩张例如要具备冻结司机账户的业务功能则需要设置冻结账户平台为了进行市场营销活动如发放红包则需要设置平台市场营销账户等。
阶段C
业务发展到这个阶段初步看好像并没有太多的逻辑变动并且看着只需要扩展下之前租车业务的账户逻辑就好了。但真的是这样吗
事实上从单纯的产品逻辑来看同一套个人用户账户貌似是没有什么问题的但是根据很多互联网公司业务发展的路径来看不同的业务线根据发展情况不同往往会分别设置不同的法律主体而且根据业务性质的不同监管层面的政策也是完全不一样的例如在国内运营的租车业务司机车费代收代发这类业务是要求运营公司具备支付牌照的没有则会牵扯到非法二清这样的法律风险而一般来说在没有支付牌照又想继续运营的话替代方案目前主要是采用银行资金托管的方式即用户资金通过银行三类账户进行托管。
一旦涉及这类业务整个系统的业务复杂度会成倍地增长所以如果采用同一套个人用户账户的话资金流将会变得难以拆分对整个系统的升级也会造成比较大的困扰。
另外如果除了租车业务、打车业务外又尝试了别的新业务如直播之类。业务类型完全不同且财务本身就要求进行分类的话只能重新设计新的账户逻辑了但从某种角度看这类账户逻辑实质上又是与之前业务存在共性的。如直播类平台也是普通用户充值购买平台礼物后打赏给主播此时平台会对用户赠送的礼物抽成后将其转换为可提现的余额结算给主播账户这类账户逻辑与约车平台其实是很类似的。
那么是否存在既能统一财务数据又能良好地支持业务的横向扩展相对通用的账户系统模型呢
接下来继续和大家探讨一套可以持续扩展的业务账户系统该如何设计
业务模型
首先我们分析下大多数在线资金业务涉及的逻辑实体用户是第一存在但是用户根据参与的性质不同又分为普通消费端用户、普通服务端用户拿打车来说一个普通打车的人属于普通消费端用户而司机个人则属于普通消费用户并且司机身份也是可以转换为普通打车用户另外就是平台用户是指公司内部各个不同的业务主体它们关联的法律主体可能是同一个也可能是不同的。
所以综上所说我们需要的可能是一套“为不同公司主体下不同业务的同一个不同用户提供不同账户交易逻辑支撑并且可以满足业务及用户平滑扩张的系统”。
事实上要达到这样的效果是很难的需要在系统平台层面进行良好地系统及业务架构设计并且确保在制定业务规则时遵循一定的制度及规范才行。
以下图示为目前业内相对比较完整的通用账户体系模型俗称“三户模型”最早是电信行业为适配复杂通信业务场景而设计的一套账户体系模型而大部分互联网公司业务的复杂度是低于复杂的电信业务的所以在这里我们对此模型进行部分改进以期形成适应互联网公司业务发展的通用账户体系模型。 在上述模型中信息被划分成了三个类型客户、用户、账户。客户是用户身份信息的承载实体例如张三这个人是一个客户而客户也不仅仅只是针对个人针对业务线所关联的法律主体也划分在客户的范畴如某某打车公司。而有了基本的客户信息后企业客户具体可以开展什么业务普通个人用户是否使用了该企业客户提供的服务在模型中是采用用户这个概念来承载的。企业客户开展该业务时根据业务的设计需要开通什么平台账户普通个人用户使用该业务服务需要开通什么样的个人账户都可以根据业务的设计通过用户下设立相应地账户进行隔离区分。
假设此时A公司的租车业务与打车业务法律主体尚未进行拆分属于同一家公司但是财务上要求隔离两类业务的资金流那么可以在账户系统上为租车业务开立租车业务用户如果张三使用了租车业务则为张三设置租车业务用户并在该用户下开立余额、余额返现、押金三类账户并配置业务及记账规则此外若希望业务资金在平台上也有个完整体现也可以在租车业务用户下设立相应的平台账户只是业务流程上可以采用缓冲或异步记账的方式。
而打车业务则需要根据普通客户信息为普通打车用户开立相应的个人账户若是司机则需要开通司机相关的业务账户而平台也需要开通相应的平台账户。在信息流上客户信息为所有业务所共用用户信息则是根据不同的业务设置账户是根据业务挂在相应地业务用户下。如若各业务间没有横向地联系各业务层账户体系根据自身业务分别运行、互不干扰而如果存在联系如租车余额可以进行打车则可以设计为允许业务层间账户的互转只是这种资金流会更复杂需要配置的记账分录也会更加复杂。
以上述模型的定义而设计的账户系统会初步形成一个具备支持多类业务账户逻辑并行的通用中台账户系统雏形从财务角度看账户层次会相对清晰。另外图中还定义了机构的概念以支持总公司-分公司这样具备层级关系的财务核算需求当然这种情况在互联网公司的扁平化模式下并不常见所以可以暂时忽略。
本篇通过业务场景举例从业务模型上大概阐述了互联网账户系统如何设计得相对通用和清晰事实上在系统设计上也需要进行更多的设计并且需要根据公司实际业务情况进行一定的取舍。
