精华内容
下载资源
问答
  • 账户系统和会计系统的设计
    千次阅读
    2020-03-29 14:51:46

    账户系统和会计系统的设计是整个支付系统的底层基础,对外,为支付系统提供资金的充、提、转、管等服务,对内,为财务和资金方提供完整的内部记账凭证。

     

    一、交易模型

    账户的变动基于交易而发生,对于账户的处理,需要根据不同的业务规则,结合产品的规划,建立完整的交易模型。

     

    • 收银台

    资金入口,提供B2C网银、B2B网银、快捷支付、协议支付、身份验证等

    • 交易系统

    提供业务层的原子化接口,比如快捷支付,协议支付,出金、提现等,处理组合不同的业务,包括组合支付、拆单支付、多次支付等

    • 资产交换

    基于渠道层的接口提供原子化服务,动态编排组合账户指令和渠道指令,清结算指令等。

    • 账户系统

    基于交易发生的账户变动,比如C1转账100元给C2账户。

    • 会计分录

    根据不同的记账事务指令会产生不同的会计分录事件,一般需要支持一借一贷和一借多贷,即每笔交易都会至少生成一组会计分录。

    下面以快捷支付收单为列

    假设条件:

    1、用户使用招商银行做快捷支付向企业商户下单购买产品。

    2、支付公司结算至商户余额账户。

    产品简称交易阶段账户变动会计分录
    快捷支付收单银行应收至商户待结算户借:应收账款-待结算-招商银行
       贷:应付账款-待结算-企业商户
     结算商户待结算户转账至商户基本户借:应付账款-待结算-企业商户
       贷:应付账款-基本户-企业商户

     

    二、账户体系

    账户按照所有权可以分为个人账户、企业账户、内部账户。个人账户是面向个人开设的电子账户,比如余额记录用户在支付平台的余额,企业账户是面向商户开立的账户,比如待结算户,基本户,手续费户。内部账户是支付公司为自身业务开展而设立的账户,比如在央行开立的ACS 账户、长款户、短款户。除此之外,支付系统还可以根据自身业务的需要设立各种不同的账户类型。

    所有的账户都记录着两方面的信息。

    1、账户基本信息:账户号、账户类型、余额、币种、余额方向、账户状态、开户时间、还有些权限控制(是否允许余额为负数、是否允许充值、是否允许提现等)

    2、账户流水信息:自开户以来账户所有余额变动信息。何时存入资金,何时取出资金、何时资金冻结解冻。

    名词说明:

    开户:开设个人账户、企业账户、内部账户。

    变更账户信息:变更账户状态、变更账户信息。

    记账:实时记账、定时批量记账。

    查询:查询账户变动流水。

    账户用例(记录商户侧)

    1)开户

    • 商户A是一家电商平台,接入支付系统快捷支付、支持借记卡和贷记卡;

    对于手续费征收,采取收支两线,并预存手续费10000元,及交易手续费为1%;同时因为该商户资质较好,交易时采取D+0实时结算。这里涉及到了垫资。

    • 商户开户,根据交易特点,需要开通以下账户:

    待结算户:用户在商户交易完成后,资金进入该账户。

    基本户:商户的余额户,可体现。结算后资金进入该账户。

    手续费账户:专门用来存放手续费的账户。

     

    阶段待结算户基本户手续费户
    开户0010000

    2)收单交易

    用户上午9点在A电商平台上使用快捷支付购买1000元的商品,交易完成后,A商户结算户增加1000元。

    手续费按照1%标准收取,有商户支出,该笔交易手续费为1000*1%=10元,计入手续费账户,手续费剩余9990.

    支付公司设置D0结算时间为每天下午4点,下午4点后,待结算资金结转至基本户。

    账户变动如下:

    阶段时间节点待结算户基本户手续费户
    开户 0010000
    收单9:00100009990
    结算16:00010009990

    3)提现

    A商户在下午16:30提现600,商户提现手续费按笔征收,每笔2元。

    商户提现600元后,基本户剩余400,手续费账户剩余9988。

    账户变动如下:

    阶段时间节点待结算户基本户手续费户
    开户 0010000
    收单9:00100009990
    结算16:00010009990
    提现16:3004009988

    三、会计核算体系

    按会计科目所反映经济内容的不同一般可分为资产类科目,负债类科目、资产负债类共同科目、所有者权益科目,损益类科目。

    资产类科目余额在借方,借贷类科目余额在贷方,资产负债共同科目类根据实际情况可借可贷。

    会计科目分为总账科目和明细科目。总账科目又称一级科目,是总括反映会计要素的科目,比如银行存款,应收账款。

    明细科目是对总账科目的细化的科目,在明细科目中。根据需要设计二级科目,三级科目。其中,没有下级科目称之为叶子科目。

    常见会计科目

    1.资产科目类

    银行存款

    应收账款

    在途调拨

    2.负债类科目

    个人账户余额

    公司账户余额

    应付账户

    3.共同类

    待清算充值款项

    待清算提现款项

    待清算支付款项

    科目账户层级

    四、业务流程

    基于消费类型的记账流程

    • 交易系统(收单)

    基于商户模式的收单交易,针对购买商品消费类型,异步请求清结算系统。

    • 清结算系统

    A-交易清分,算出给每个账户打多少钱,同时从每个账户收多少钱;

    B-交易结算出款:调用银行/通道代付接口,自动出款。

    C-对账:核算通道与支付系统的应收应付。注:对账业务流程最好不要跟清算、结算勾连在一起,跟上游通道对账与给商户付多少钱最好不要业务先后关系。

    • 账户系统

    记录每笔交易的收付记录。

    • 会计系统

    按照企业会计分录流水记账,记账采用复式记账法。

     

    账户、会计处理流程

    一笔交易至少在账务系统中产生一条账户流水记录(明细账),同时会在会计系统中根据业务规则产生一套或者多套会计分录流水,账户余额与会计余额想对应。账务系统是对外客户提供账户支持,客户的查询余额,明细都是来源于此;会计系统是为了内部核算管理的需求设定的,所有银行资金清算与结转都需要会计系统的支撑,内部户与外部户的资金核算管理也需要会计系统,两个系统相互依赖,账户系统是会计系统的前置。

    交易流水达到账户系统后,账户系统为每笔交易分配账务流水,账务前置调用计费系统统计商户手续费。账户流水形成后,若是非实时记账,则直接通知业务系统记账完成,待定时任务跑批执行缓冲记账,若是实时记账,则系统开始记录分户账流水和更新分户账余额,余额更新完成后通知业务系统记账完成。账户系统记账完毕后,将定时或者准实时以批量接口发送至会计系统,会计系统会为每笔交易记录会计分录流水。对于会计记账,需要支持一借一贷,一借多贷模式,会计记账也分为记分户明细账和更新会计余额。

    会计记账完毕后,每日日终,进入批处理流程,日终处理是对日间没有处理完毕,以及不需要在日间处理的任务进行批处理的过程,在记账中日终处理主要是指业会核对,即账户系统余额与会计系统余额间的核对。

    更多相关内容
  • 账户系统的具体实现

    千次阅读 2019-05-16 17:47:53
    在上一篇文章中我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定义外,在具体系统实现上又该如何设计?又有哪些需要注意的地方呢?在本篇...

    在上一篇文章中我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定义外,在具体系统实现上又该如何设计?又有哪些需要注意的地方呢?在本篇内容中小码农就和大家一起讨论下账户系统的实现细节,希望可以和大家一起交流进步。

    事实上账户系统的业务逻辑是比较复杂的,对数据的一致性要求很高,特别是记账动作涉及强事务特性;另外,性能问题也是常常制约账户系统稳定性的一个比较突出的方面。在这种情况下,我们还需要考虑统的业务通用性设计问题,而这必然也会涉及很多配置项的设计,增加系统的逻辑复杂度。但是,也只有处理好了这些问题,账户系统才能保证业务的持续扩张,否则再好的理念也只是空中楼阁。然而,处理好这些复杂的问题,事实上并不只是某一点的设计就可以达成的,既需要逻辑流程设计上的优化,也需要采用合适的技术方案,更需要一个合理的系统结构。

    下面我们就从系统结构、整体流程、数据模型、记账规则,以及日终对账这几个方面与大家探讨从系统层面应该如何设计。另外对于账户系统中制约性能最常见的热点账户问题,也会和大家一起探讨。

    系统结构

    在之前的内容中,我们提到要设计一套可以满足互联网业务扩展的账户系统,所以账户是这套系统的基础,为了更好地支持不同业务、或同一业务不同账户的开户,我们需要将开户逻辑设计成独立的子系统,独立地提供包括开户、账户信息查询、余额查询在内的服务,以便逻辑复杂到一定阶段后可以更容易的扩展。在完成开账户动作后,就需要根据业务规则,设计好逻辑体系下不同交易类型的记账规则了,而这种规则配置是否智能,则是账户系统是否通用的关键;配置完规则后账户系统就可以接收业务发起的交易请求,并根据规则的配置完成业务资金流的处理了,所以,从系统结构层面也需要将记账核心服务设计成独立的子系统;此外,为了适配业务层不同的交易类型,主要是隔离记账逻辑与交易逻辑,还需要前置账户交易系统。

    最后,为了确保账户余额与流水之间的平衡,我们还需要在日终时对主要资金账户进行对账核算,确保账户流水发生额与账户余额的一致性。所以从系统结构层面,整个系统主要可以分为四个部分:

    之所以在账户系统、核心记账系统之上设置一层账户层交易系统,是为了将多变的业务交易逻辑与相对通用的记账逻辑进行隔离,避免在核心记账系统中冗余过多的业务逻辑导致后续出现臃肿的情况。例如业务层的交易类型可能是复杂多变的,如车费充值、押金支付之类,而这样的逻辑是没有必要让记账系统感知的,记账系统只需要根据交易系统传递的记账规则,根据会计分录完成资金流处理即可。

     

    整体流程

    为了确保系统能够正常Run起来,需要对系统整体的流程进行规划,这部分流程即包括线下流程,也包括线上流程,它是确保整个系统闭环的基础。例如,以账户系统需要支撑A公司打车业务为例,假设账户系统已经存在的情况下,那么它需要支撑这个业务应该经历以下两个阶段的流程:

    (一)、线下规划配置流程

     

    按照正常的流程设计,在业务开展之前,需要根据实际的业务资金流设计好具体的账户及交易资金逻辑,这部分逻辑一般是由PM与资金部门线下确认后形成正式的产品规格文档。之后,由具有权限的运营人员通过后台,或者前期在没有完善配置系统的情况下,由技术人员初始化到系统中,由于这部分配置关系到交易核心流程,所以在流程及操作规范的制定上要严格把控,避免配置错误导致的严重系统逻辑错乱问题。

    在这部分流程中我们首先需要配置业务主体,这里需要为A公司配置客户开户信息,之后需要按照之前业务模型定义的结构,在客户下为其开通表示打车业务线网约车用户,至此在系统中就完成了“谁?要干什么?”的定义。而具体“怎么干?”,则是在后面我们要重点配置的内容。

    那么具体需要配置什么内容呢?

    因为,账户系统本身是为交易逻辑服务的,所以我们需要明确业务中涉及账户逻辑的交易有哪些类型,例如在约车业务中主要涉及到司机端开户乘客开户、现金支付车费、余额充值、余额支付车费、司机提现等这些交易类型,所以我们需要为这些交易类型定义交易编码(tradeCode),并将其与之前开通的网约车业务用户进行关联,这样在后续的系统交易流程中,就可以进行交易权限控制,各业务线逻辑各自关联自身的交易类型,以免互相干扰了。

    而定义了这些交易类型以后,账户层交易系统具体接收到这样的交易请求后应该怎样执行逻辑呢?在互联网公司早期业务发展的过程中,很多都是将账户逻辑与交易逻辑耦合在一起的,这样会导致各个业务账户逻辑陷入要么继续耦合,要么各自定制、重复开发的怪圈。

    而要让这种逻辑变得通用,就需要将其规则化,即账户层交易系统接收到指定的交易请求类型后,会根据系统用户交易规则配置,获取开户、记账交易规则信息,然后记账系统和开户系统就会按照规则指定的逻辑执行了,这种执行逻辑识别规则,不感知具体业务逻辑。在上述流程中,我们将“平台层开户”也设计成了规则,只是这种开户动作接口并不对实时交易接口开放,一般是通过后台设置,即通过后台调用开户系统机构(平台)开户接口,开户逻辑根据网约车平台层开户规则,自动开立“服务费账户”、“代收付平台账户”、“结算账户”、“市场营销账户”这类开展网约车业务所需的平台层账户体系。

    其他开户交易类型,如司机端开户、乘客开户由于需要在具体用户注册、司机入驻时通过实时交易接口自动调用Api开通,所以这里需要配置好开户规则即可;至于,各个涉及资金变动的交易类型,如车费支付、余额充值之类,涉及到具体的记账规则的逻辑,也需要通过配置相应的交易记账规则,关于记账规则的配置设计涉及一点会计知识的细节,会在后面的内容中介绍到。

    (二)、线上系统交易流程

    完成系统级的数据定义及规则配置后,整个账户系统就会通过开放Api,为各个业务交易系统提供线上账户交易接口服务了。

     

    业务层交易系统向账户层交易系统发起交易请求后,系统会首先根据传递的客户、用户ID对请求权限进行识别,只有在(一)流程中设置了客户、用户主体信息的交易请求才被允许,之后账户层交易系统会根据传递的交易编码(tradeCode)识别交易数据开户交易类型,还是交易记账类型。开户交易类型则被转发至开户子系统进行开户处理,开户子系统根据tradeCode设置的开户规则,完成注册用户账户体系的开通,如:乘客张三,会依次为其开通客户身份、打车用户身份、以及打车用户涉及的余额账户,余额返现账户,押金账户的开通。

    而如果为交易记账类型,假设这里为乘客使用现金支付车费,则请求被转发至记账子系统,记账子系统根据业务线客户、用户ID、乘客业务用户ID以及tradeCode获取记账规则,完成资金逻辑记账处理。

    规则涉及的账户逻辑如下:

     

    记账规则

    在账户系统中,记账规则逻辑的设计是最为复杂的一项设计,需要在兼顾会计逻辑的情况下,还需要将其设计成较为通用的规则,以上面用户支付车费的账户资金逻辑为例,如何将其设计成规则配置呢?

     

    在以上记账规则表中,定义了业务线用户ID(merchUserId),表示该业务模式在系统中的唯一编码;记账交易类型(tradeCode)由具体的业务线交易模式定义,例如打车业务用户现金支付车费。这两个字段由定义客户用户信息、用户交易类型,可根据实际业务定义。

    后面的字段主要定义了账户交易逻辑的情况,例如changeType中定义的记账,表示按照规则正常的借贷方向进行余额更新,而冻结、解冻则是对账户余额进行冻结、解冻操作,增加、减少是根据规则直接对账户进行增加及减少操作,之所以定义上述不同类型,主要是为了适应不同账户操作逻辑,具体定义及含义,大家也可以根据自身公司的实际业务情况进行定义。

    可能这么解释大家会有比较大的疑问,我们以线上交易流程中涉及的网约车用户现金支付车费的资金逻辑为例:

    根据规则表的设计,以上规则描述了各账户资金流的变动逻辑,其中涉及账户类型、借贷方向、资金类型、记账科目以及记账步骤。当业务层交易发起至账户层交易系统后,账户层交易系统会获取以上记账规则,并根据规则描述的账户类型,找到普通消费用户、平台层用户、普通服务用户对应的账户信息,并按照规则逐条进行记账逻辑执行。

    通用数据模型

    在上面的流程及规则涉及中,以网约车业务为例,通过两个流程说明了账户系统应该如何支撑着项业务,虽然,看着并不是特别复杂,但是从系统设计上看却是涉及了很多实体信息,接下来我们从数据建模的角度,看看如何设计系统的数据模型。

    在模型中我们根据逻辑,抽象了客户、用户、账户相关实体,同时也抽象了账户流水、科目信息、记账规则、开户规则,交易类型等信息。系统通过这些实体设计相关表结构,系统就初步具备了运转能力了,大家可以根据实际情况增加其他实体信息。

    会计科目

    会计科目是账户系统中比较基础的概念,它的定义决定了账户的一些属性特征,例如是否可透支,属于资产类or负债类,可以根据不同公司财务的需求进行设计。

    记账策略

    大家知道记账动作是强事务的,按照正常记账逻辑以上规则执行过程中涉及的4个账户更新需要具有原子性,要么都执行成功,要么全部回滚,而对于普通消费账户、普通服务账户,这些账户都属于个人账户,在线上实时交易中的并发度是有限的。而对于平台层账户,包括代收付账户、服务费账户等,平台所有的交易都涉及这些账户的资金变动,所以如果在某一个交易过程中对其加锁,会导致该账户记录的加锁-更新动作非常频繁,成为热点账户,影响系统性能。

    所以在规则中我们加入了是否缓冲记账的配置,一旦配置为缓冲记账,则在执行该规则时,只是把该记账逻辑放入缓冲队列的逻辑与其他规则在一个事务中,而具体账户更新逻辑则是由缓冲记账系统完成,该逻辑可设置为日间完成,或日终完成。

    从而缓解热点账户问题导致系统性能瓶颈,但是需要注意,这种方案也对缓冲记账逻辑提出了比较高的要求,需要缓冲记账系统尽量保证记账动作执行成功,一旦执行失败前面同步执行成功的记账逻辑回滚起来会比较麻烦;另外,如果之前的同步记账逻辑在发送缓冲队列成功后,自身逻辑又失败了,则需要及时发送冲正机制,取消该缓冲记账动作。

    日终对账

    为了确保账户余额始终处于相对正确地状态,需要对日终账户流水进行各种试算核对,确保所有流水发生额累加后的余额+期初余额能够与当前余额匹配,这里会涉及到比较复杂的对账逻辑,需要大家在实际系统研发实践中加以考虑。

    技术点拓展

    在账户系统的研发设计过程中,还会涉及很多其他问题,例如账户流水数据量非常大,同时数据的留存时间又要求比较长,所以需要考虑数据的分布式存储,目前小码农所在公司,采用了TIDB这种分布式数据库,大家可在实践中根据自身情况进行选择。

    另外,账户的频繁更新,在系统并发量非常高的情况下,还会遇到性能瓶颈,如何在保证用户体验及数据正确性的情况下,采取更多的技术手段,如采用Redis/Codis进行缓存记账,也需要在实践应用场景中进行探索。

    后记

    由于账户系统逻辑相对比较复杂,涉及很多会计知识及细节逻辑,本文只是描述了一种理念与思路,真正做好这套账户系统还需要大家根据自身场景进行取舍与裁剪。由于作者水平有限,不足之处,还请多多包涵!

    转摘于:http://www.sohu.com/a/253132589_684445

    展开全文
  • 账户系统设计(上)

    千次阅读 2019-05-16 09:19:54
    在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持...

    在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持新业务的扩张,对现有业务的支持也适配困难,最终导致新业务系统不得不重新搭建自己的业务账户逻辑,造成重复建设不说,也往往给后续的财务资金核算造成混乱。

    以某互联网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公司的租车业务与打车业务法律主体尚未进行拆分属于同一家公司,但是财务上要求隔离两类业务的资金流,那么可以在账户系统上为租车业务开立租车业务用户,如果张三使用了租车业务则为张三设置租车业务用户并在该用户下开立余额、余额返现、押金三类账户并配置业务及记账规则,此外若希望业务资金在平台上也有个完整体现也可以在租车业务用户下设立相应的平台账户,只是业务流程上可以采用缓冲或异步记账的方式。

     

    而打车业务则需要根据普通客户信息为普通打车用户开立相应的个人账户,若是司机则需要开通司机相关的业务账户,而平台也需要开通相应的平台账户。在信息流上,客户信息为所有业务所共用,用户信息则是根据不同的业务设置,账户是根据业务挂在相应地业务用户下。如若各业务间没有横向地联系,各业务层账户体系根据自身业务分别运行、互不干扰,而如果存在联系,如租车余额可以进行打车,则可以设计为允许业务层间账户的互转,只是这种资金流会更复杂,需要配置的记账分录也会更加复杂。

     

    以上述模型的定义而设计的账户系统会初步形成一个具备支持多类业务账户逻辑并行的通用中台账户系统雏形,从财务角度看账户层次会相对清晰。另外,图中还定义了机构的概念以支持总公司-分公司这样具备层级关系的财务核算需求,当然这种情况在互联网公司的扁平化模式下并不常见,所以可以暂时忽略。

     

    本篇通过业务场景举例从业务模型上大概阐述了互联网账户系统如何设计得相对通用和清晰,事实上在系统设计上也需要进行更多的设计,并且需要根据公司实际业务情况进行一定的取舍。

     

    由于篇幅的关系,就先和大家讨论到这里,有关系统设计的细节会在下一篇文中进行讨论,敬请关注!

    转摘于:https://www.javazhiyin.com/17225.html#m

    展开全文
  • java银行账户管理系统

    2018-05-11 16:50:33
    支持管理员登录,存款,取款,注册账户,注销账户,转账操作,利息计算以及退出系统操作。
  • 账户体系是支付系统的基础,它的设计直接影响整个系统的特性。这里探讨如何针对电子商务系统的支付账户体系设计。我们从一些基本概念开始入手,了解怎么建模。账户体系设计首先要区分两个概念,支付账户和登录账号。...
  • 在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账...

    640


    在很多互联网公司业务发展的早期,业务模式比较单一的情况下,涉及用户账户资金交易相关的逻辑也比较简单,但是随着公司业务模式的不断创新及类型的多元化发展,会渐渐发现现有系统账户逻辑越来越雍肿,不仅难以支持新业务的扩张,对现有业务的支持也适配困难,最终导致新业务系统不得不重新搭建自己的业务账户逻辑,造成重复建设不说,也往往给后续的财务资金核算造成混乱。


    以某互联网A租车公司的业务发展路径为例?


    阶段A


    A公司在早期开展租车业务时根据用户使用场景规定用户必须在缴纳押金以后才可以租车,并且支持用户进行余额充值,余额可以支付租车费用以及购买相关优惠产品。所以账户资金流是这样子的:


    640


    通过上述设计基本上就满足了简单的业务需求,用户缴纳押金单独存放在一个押金账户,用户的每次押金冲退都记录账户流水(缴押金记+,退押金记-);用户余额充值单独存放在一个余额账户,用户的每次余额充值、消费、退款都记录账户流水(余额充值记+、余额消费记-、余额退款记-)。


    事实上,以上账户逻辑的设计基本已经能满足业务早期的发展的需要了,并且如果账户流水记录完整(例如记录必要的业务类型,如余额购买了一张租车次卡)那么后续也能基本满足早期业务的财务核算需求。遗憾的是,很多公司在类似以上简单账户逻辑的设计上都比较混乱,如有的公司将账户直接绑定在用户信息表上、有些直接更新账户余额,没有完整记录账户流水或账户流水记录业务信息缺乏等,这种情况即使业务没有多元化发展,也很难满足后续业务逻辑的扩展,特别是会造成严重的财务数据核算困难,更不用谈业务多元化发展后如何能够快速支撑了,造成这种问题的原因是多方面的,这里也就不在赘述。


    下面我们继续看A公司租车业务的发展演进情况!


    假设在A公司租车业务发展过程中为了鼓励用户进行余额充值,采用了充值+返现的形式进行活动,如:“充值100赠送20”,此时用户余额账户的总金额应该是120,那么账户逻辑如何支持呢?


    640


    这里注意,之所以需要区分余额中真实充值和赠送的原因在于,如果产品逻辑允许余额退款,那么清晰地区分了真实充值和赠送所对应的余额的话,退款逻辑的实现将会比较简单,否则就会变得比较痛苦,并且不清晰的逻辑也会增加造成公司资金损失的风险;另外如果余额返现账户变动流水记录得比较明确的话,对财务后续的收入核算也会方便很多。


    但是,是否这样就能满足业务需求了呢?


    显然,这样还不能让逻辑完全运行起来,因为增加了账户相应地交易逻辑与资金逻辑都需要进行相应的改变才行,以上业务场景中原来余额充值只需要调用余额账户记账一次,现在需要根据充返逻辑再调用余额返现账户记账一次;而余额消费则需要根据业务规则进行余额消费记账,假设业务规则为“余额消费优先扣减余额返现账户,再次扣减余额账户”,那么系统交易及记账逻辑如下图所示:


    640


    从逻辑上看业务交易系统需要根据业务规则多次调用余额账户及余额返现账户进行记账,并且需要从流程上保证两个账户记账调用的事务一致性,例如一笔消费订单金额为20元,此时余额账户余额为10元,余额返现账户余额为5元,在优先消费返现账户金额扣款5元后无法再从余额账户消费15元时,交易失败后需要回滚余额返现账户消费逻辑,余额返现账户“交易冲正 +5”。


    阶段B


    在阶段A中,单个业务会根据不同的产品设计进行账户逻辑的迭代,增加余额充返账户后虽然从账户逻辑层面只是增加了新的资金账户,但是交易逻辑却是进行了较大的变更和调整;如果此时该业务场景又出现新的逻辑变化,例如某一天该租车业务针对某些信用良好的用户进行免押金用车活动,并且支持这类用户在退押金时可以选择将押金的全部或部分金额进行余额充值,那么在流程设计上还会存在账户转账的情况(押金账户->余额账户)


    每次产品业务的迭代涉及用户资金逻辑,都不免会影响交易逻辑及账户逻辑本身,但如果业务品类单一,这种迭代及扩展通过硬编码方式多少还能继续支持。但是,如果随着公司业务向多元化发展,问题往往就变得复杂了。


    假设A公司在主营租车业务发展态势进入到趋于平缓的阶段后,为了扩展业务范围需要尝试新的业务,例如,某团队提出不能仅仅只搞租车也得弄个网约车平台,那怎么弄?


    640


    首先肯定是需要先集结队伍啦smiley_。集结完队伍就需要好好分析分析下业务场景了,我们先大概看看一个网约车平台的大概业务场景是什么样子的,其中涉及的资金交易的流程应该如何设计呢?


    在A公司的租车业务中,从参与角色角度来看涉及的逻辑并不算太复杂,只有“用户、车、租车公司(内部可称租车业务线)”,而从交易场景上看,用户缴纳押金、预存余额及余额消费都只是单向的C->B交易模型,如果不考虑公司层在线交易账户体系(这里是指公司层面的交易账户)业务复杂度还不算十分复杂,并且在这种单向业务模式下,没有公司层面的在线交易账户本身并不影响业务流程,收入核算只需要线下计算即可,这也就是为什么前面会特意强调账户流水业务关键信息不能缺失的原因了。


    而约车业务则是多向的C->B-C-B的交易模型,因为从参与角色上看除了普通打车用户外,还有司机、打车平台都会紧紧地参与到整个业务流程中;而从账户资金流上看用户支付的车费不会以C->C的模式直接支付给司机,而是会由打车平台代收,打车平台扣除订单抽成后剩下的车费才会打到司机在打车平台开的账户上,司机才能从个人账户提现。

    640

    从上图的分析中我们可以看到,我们需要为普通用户、司机账户、打车平台分别设置必要的账户逻辑,普通用户账户逻辑与之前的租车业务比较类似,用户可以直接支付打车费用、也可以通过余额充值后使用余额支付打车费用;而平台则需要代收用户的打车费用并且需要按照服务规则从代收的打车费用中扣掉部分服务费,然后通过代收/付平台账户将车费实时结算给司机端收款账户,司机通过个人收款账户发起提现后经过结算账户完成提现。资金流如下:


    640


    此外,为了满足产品逻辑的扩张,例如要具备冻结司机账户的业务功能,则需要设置冻结账户;平台为了进行市场营销活动,如发放红包则需要设置平台市场营销账户等。


    阶段C


    业务发展到这个阶段,初步看好像并没有太多的逻辑变动,并且看着只需要扩展下之前租车业务的账户逻辑就好了。但真的是这样吗?


    事实上从单纯的产品逻辑来看,同一套个人用户账户貌似是没有什么问题的,但是根据很多互联网公司业务发展的路径来看,不同的业务线根据发展情况不同往往会分别设置不同的法律主体,而且根据业务性质的不同监管层面的政策也是完全不一样的,例如在国内运营的租车业务司机车费代收代发这类业务是要求运营公司具备支付牌照的,没有则会牵扯到非法二清这样的法律风险,而一般来说在没有支付牌照又想继续运营的话,替代方案目前主要是采用银行资金托管的方式,即用户资金通过银行三类账户进行托管。


    一旦涉及这类业务,整个系统的业务复杂度会成倍地增长,所以如果采用同一套个人用户账户的话,资金流将会变得难以拆分,对整个系统的升级也会造成比较大的困扰。


    另外如果除了租车业务、打车业务外又尝试了别的新业务,如直播之类。业务类型完全不同,且财务本身就要求进行分类的话,只能重新设计新的账户逻辑了;但,从某种角度看这类账户逻辑实质上又是与之前业务存在共性的。如直播类平台也是普通用户充值,购买平台礼物后打赏给主播,此时平台会对用户赠送的礼物抽成后将其转换为可提现的余额结算给主播账户,这类账户逻辑与约车平台其实是很类似的。


    那么,是否存在既能统一财务数据又能良好地支持业务的横向扩展相对通用的账户系统模型呢?


    接下来继续和大家探讨一套可以持续扩展的业务账户系统该如何设计?


    业务模型


    首先我们分析下大多数在线资金业务涉及的逻辑实体,用户是第一存在,但是用户根据参与的性质不同又分为普通消费端用户、普通服务端用户,拿打车来说一个普通打车的人属于普通消费端用户,而司机个人则属于普通消费用户,并且司机身份也是可以转换为普通打车用户,另外就是平台用户,是指公司内部各个不同的业务主体,它们关联的法律主体可能是同一个也可能是不同的。


    所以综上所说,我们需要的可能是一套“为不同公司主体下,不同业务的同一个/不同用户提供不同账户交易逻辑支撑,并且可以满足业务及用户平滑扩张的系统”。


    事实上要达到这样的效果是很难的,需要在系统平台层面进行良好地系统及业务架构设计,并且确保在制定业务规则时遵循一定的制度及规范才行。


    以下图示为目前业内相对比较完整的通用账户体系模型,俗称“三户模型”,最早是电信行业为适配复杂通信业务场景而设计的一套账户体系模型;而大部分互联网公司业务的复杂度是低于复杂的电信业务的,所以在这里我们对此模型进行部分改进,以期形成适应互联网公司业务发展的通用账户体系模型。


    640


    在上述模型中信息被划分成了三个类型:客户、用户、账户。客户是用户身份信息的承载实体,例如张三这个人是一个客户;而客户也不仅仅只是针对个人,针对业务线所关联的法律主体也划分在客户的范畴,如某某打车公司。而有了基本的客户信息后,企业客户具体可以开展什么业务,普通个人用户是否使用了该企业客户提供的服务,在模型中是采用用户这个概念来承载的。企业客户开展该业务时根据业务的设计需要开通什么平台账户,普通个人用户使用该业务服务需要开通什么样的个人账户都可以根据业务的设计通过用户下设立相应地账户进行隔离区分。


    假设此时A公司的租车业务与打车业务法律主体尚未进行拆分属于同一家公司,但是财务上要求隔离两类业务的资金流,那么可以在账户系统上为租车业务开立租车业务用户,如果张三使用了租车业务则为张三设置租车业务用户并在该用户下开立余额、余额返现、押金三类账户并配置业务及记账规则,此外若希望业务资金在平台上也有个完整体现也可以在租车业务用户下设立相应的平台账户,只是业务流程上可以采用缓冲或异步记账的方式。


    而打车业务则需要根据普通客户信息为普通打车用户开立相应的个人账户,若是司机则需要开通司机相关的业务账户,而平台也需要开通相应的平台账户。在信息流上,客户信息为所有业务所共用,用户信息则是根据不同的业务设置,账户是根据业务挂在相应地业务用户下。如若各业务间没有横向地联系,各业务层账户体系根据自身业务分别运行、互不干扰,而如果存在联系,如租车余额可以进行打车,则可以设计为允许业务层间账户的互转,只是这种资金流会更复杂,需要配置的记账分录也会更加复杂。


    以上述模型的定义而设计的账户系统会初步形成一个具备支持多类业务账户逻辑并行的通用中台账户系统雏形,从财务角度看账户层次会相对清晰。另外,图中还定义了机构的概念以支持总公司-分公司这样具备层级关系的财务核算需求,当然这种情况在互联网公司的扁平化模式下并不常见,所以可以暂时忽略。


    本篇通过业务场景举例从业务模型上大概阐述了互联网账户系统如何设计得相对通用和清晰,事实上在系统设计上也需要进行更多的设计,并且需要根据公司实际业务情况进行一定的取舍。


    推荐阅读

    还有人不懂分布式锁的实现就把这篇文章丢给他


    又一个程序员倒下-程序员防猝死指南


    640?

    展开全文
  • 北科C++课程实现个人银行账户管理系统的实验报告。北科C++课程实现个人银行账户管理系统的实验报告。北科C++课程实现个人银行账户管理系统的实验报告。北科C++课程实现个人银行账户管理系统的实验报告
  • 用Python编写一个简易银行账户系统

    千次阅读 2021-01-21 23:26:18
    Python编写一个简易银行账户系统 文章中主要涉及的方法是Python中的open(filename, ‘r’)以读的方式打开文件open(filename, ‘w’)以写的方式打开文件我们用for * in *读取文件中的数据或者写入文件数据 用dict...
  • 互联网金融-资金账户系统设计

    千次阅读 2019-09-16 15:06:13
    互联网金融-资金账户系统设计 支付系统设计 互联网账户系统如何设计(上篇)? 互联网账户系统如何设计(下篇)? 支付对账系统怎么设计? 移动端支付系统如何设计有效地防重失效机制? 如何做一个对账系统 聊聊对账...
  • [提炼&总结]账户系统的设计

    千次阅读 2018-07-30 16:06:58
    一般而言,系统内都会有用户模块,如果涉及到钱、积分、兑换券之类的,那么最好搞一套账户模块。 简单的账户模块分为两部分,账户和流水记录。 在这种简单的模块内,典型的场景是用户做了某个操作,达到了预设...
  • 导读在上一篇文章中(互联网账户系统如何设计(上篇)?)我们通过场景举例的方式,讨论了一套相对通用的互联网业务账户系统,从业务模型上应该如何定义。那么除了从业务模型上进行定...
  • 互联网金融系统的核心是支付结算,而支付结算的基础又是账户系统。互金账户系统的特点是并发量大、响应快、交易金额大,热点账户问题突出。一个合格的账户系统既要解决上述问题,又必须绝对保证资金安全。作为这家...
  • 银行账户管理系统C++

    2012-10-20 10:18:42
    银行账户管理程序 主要内容: 问题描述 设计一个银行账户管理程序,账户的信息有账号(唯一)、姓名、余额、身份证号码、单位、电话号码、地址等, 允许用户进行如下操作:开户、销户、存款、取款、转账、查询...
  • 个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统个人资金账户管理系统...
  • 期末 C++ 课程设计作业。 使用C++完成一个银行账户管理系统
  • 账户账务系统架构与实践

    千次阅读 2019-07-05 15:40:13
    导致的问题就是资金池业务吻合严重,对账难,以及数据不统一,另外成本也非常高,为此我们做了统一的账户系统。账务系统作为到家业务线的基础服务,为到家业务提供统一清算、账户、对账、财务报表能力。 一、账务...
  • 软件工程作业项目(银行账户系统)完整源代码以及报告文档!绝对可以运行的代码!代码清晰,适用用于学习!
  • 设计一个银行账户管理系统 欢迎使用银行账户管理系统 1.登录 2.注册 3.退出 请输入要执行的操作 当前用户:xxx 1.查询账户余额 2.转入 3.支出 4.查询交易记录 5.退出 请输入要执行的操作 由于是Java萌新,所以本题...
  • 交易系统热点账户问题(一)

    千次阅读 2018-07-08 23:10:12
    热点账户就是高频进行扣款、入账的账户,也就是热点账户该条数据为热点数据,会被频繁更新。一般热点账户分为两种,一种是频繁扣款的热点账户,另外一种是频繁入账的热点账户。 二、热点账户常见问题 1、性能...
  • 金融系统的基础是结算,结算的核心是账户账户体系是最基础的也是最重要的部分,而众多的业务也都是围绕账户展开的,要了解现在众多的金融系统(包括互联网金融)就绕不开账户体系。一、先看一下结算系统的几个抽象...
  • javaWeb银行账户管理系统源码

    热门讨论 2014-04-24 21:31:05
    银行账户管理系统 系统采用 struts2.X 构架 数据库为 sqlserver 系统模块: 用户注册模块 用户登录模块 用户存款模块 用户取款模块 用户交易信息 用户信息更改
  • 电商账户体系

    千次阅读 2018-05-12 21:58:38
    同会计科目分类相对应,账户按其提供的信息详细程度和统驭关系不同分为总账账户和明细账户,请注意,在设计IT账户系统中,总账户和明细账户是非常重要的概念,后面会重点分析。 而按照账户反映的经济内容不同可分为...
  • c++银行账户管理系统,可执行长整型运算的操作。
  • 银行账户管理系统详细设计说明书

    万次阅读 多人点赞 2016-06-06 23:02:20
    银行账户管理系统详细设计,附源码于博主的GitHub个人主页中。
  • Android系统日历日程表_日历本地账户_事件_提醒的增加删除. 公司项目需要研究了几天系统的日历. 也拉出了系统内provider 下日历的数据库进行研究. 实现了添加本地账户, 基于本账户添加事件及提醒, 还有删除事件和...
  • Meteor 添加账户系统

    千次阅读 2015-03-13 11:40:27
    Meteor 添加账户系统我们给meteor添加一个账户系统 导入包 meteor add ian:accounts-ui-bootstrap-3 meteor add accounts-password在界面添加登陆按钮 {{> loginButtons}}result
  • 现要设计一网站账户系统,可以支持手机邮箱注册登陆,同时支持腾讯QQ微信及新浪微博等第三方账号绑定登陆,该如何设计网站的账户系统数据库?之前没有相关经验,不知道有哪些需要休息的地方,求高手指教!
  • 运行环境,jdk1.8或者jdk1.7、tomcat8或者tomcat8.5、mysql5.7、...3、银行个人账户定期交易系统最高管理员,登录主页,最高管理员可以管理银行柜员、存款种类、系统日志,如下所示: 4、银行个人账户定期交易
  • JAVA项目:简单的银行账户系统1

    千次阅读 2017-08-07 19:43:31
    这是我在初学Java的第一个实战项目,在很多视频也有相关的介绍, 这是非常适合新手的一个简单的代码,后续也有提升版本。 这里就不赘述,直接上代码!...//账户余额 public Account(double init_balance)
  • 银行账户管理系统 C# 编写

    热门讨论 2011-01-02 18:41:58
    银行账户管理系统 实验系统 四层架构 有户主和管理员双重功能,基本功能都已实现,户主对自己账户的管理,管理员对户主的管理。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 372,849
精华内容 149,139
关键字:

账户系统

友情链接: tuxiangpinjie.rar