zoukankan      html  css  js  c++  java
  • 第三方支付账务系统设计难点(云时代架构文章读后感13)

    第三方支付账务系统设计

    首先谈一下支付公司账务系统如何设计。关于如何记账,国内长期以来有两个发展方向,一个是以金蝶、用友为代表的财务系统,另一个是以银行为代表的银行账务核心系统。

    这两种账务系统都是用来记账,但设计理念上有很大差别,财务系统以科目为中心,记账必谈科目,银行账务系统以账户为中心,记账必谈账户。从账户数量来讲,支付公司几千万甚至上亿的账户数量,金蝶、用友这种财务系统是支撑不起来的。基本上,对于支付公司的账务系统应该参考银行账务核心系统来设计,这一点在业界已经达成共识。

    这里谈的的账务系统,是说的复式记账(有借有贷,借贷相等),但是不采用复式记账,而是采用单式记账,是否可以呢?首先说答案,是可以的。但是,单式记账不科学,也存在一些缺陷。采用单式记账,存在以下一些问题:

    1. 资金的来龙去脉不清晰。记账是一门技术,有专门的方法,从刻字记事、结绳记事,发展到现在,借贷复式记账是目前为止最科学的一种记账方法。借贷复式记账能够清楚记录每笔资金从哪来、到哪去,这一点,单式记账是无法做到的。

    2. 单式记账无法进行资产、负债平衡检查。资金不会凭空而来,也不会凭空而去。对于一个会计主体,有多少资产,就有多少负债,资产 = 负债 (所有者权益是对股东的负债)。

    比如用户充值业务,在支付机构的账务体系中,采用复式记账,用户余额增加,同时支付机构在银行的存款科目余额增加,日终进行总账平衡检查,银行存款科目余额 = 用户余额 (不考虑支付手续费)。而如果采用单式记账,一笔充值业务,只记录用户余额增加,而不记录银行存款,那么,用户的余额是否等于支付机构的银行存款呢?采用单式记账,是没有办法进行这种平衡检查的。

    3. 从业务模型来讲,也需要复式记账。还用上面的例子来讲,比如,支付公司对接了100家银行,用户在每家银行都有充值,如果每笔充值,只记录用户余额是多少,而不记录支付公司在银行的存款是多少,那该如何核对支付公司在每个银行有多少余额呢?只能是把所有用户余额汇总在一起,然后把所有的银行对账单的余额汇总在一起,核对一个总数。

    这种核对方法,由于时间差或各种原因,是很难核对出具体每个银行账户存款的差异的。而如果采用复式记账,对于每笔充值,都记录了对应银行存款科目余额(或者是应收账款科目)的变化,账务系统总账借贷平衡之后,再用银行存款科目余额与银行对账单核对,就很容易核对出对应银行端每个账户余额差异了。

    在日常财务处理的工作中,财务人员也是用银行存款科目余额与银行对账单来核对,出具余额调节表,来核对与银行对账单的差异。所以说,从现实业务模型来讲,支付账务系统也应该采用复式记账的方法来进行记账。

    账务系统有以下几个作用:

    1. 提供业务支撑。记录余额的变化,保证业务正常运转。业务驱动账务,没有业务也就没有账务,账务要保证业务能正常运转,账务的余额要100%准确。

    2. 为用户提供账单。用户数量太多,不会为每个用户发送账单,用户可以查询账户的余额和明细。

    3. 为商户提供账单。商户对于开在支付公司的账户与在银行的对公账户是同等看待的,账务系统需要为商户提供资金对账单。

    4. 内部核算。记录银行存款、应收账款、手续费、利息收入等科目余额,与银行或第三方提供的账单进行核对,核对余额与发生额。

    5. 为企业大财务提供汇总记账凭证。支付公司的账务系统记录的是业务账,这些数据是整个企业财务数据的一部分,需要合并到公司的大财务系统中去。可以把支付账务系统的会计分录映射为大财务的分录,然后汇总,直接对接企业ERP总账。这一点与银行非常类似,银行账务核心记录的是存款、贷款、汇款这些业务数据,这些业务账也是要与银行财务系统合并到一起的。

  • 相关阅读:
    前端知识点--CSS overflow 属性
    js排序——sort()排序用法
    vue知识点---element el-date-picker 插件默认时间属性default-value怎么赋值?
    vue知识点----element UI+vue关于日期范围选择的操作,picker-options属性的使用
    JS_点击事件_弹出窗口_自动消失
    Echarts +ajax+JSONPObject 实现后台数据图表化
    Floyd弗洛伊德算法
    线程中join方法和Sleep方法的举例
    循环注册十个账号,保证程序重启之后,使用这十个账号都能登录成功
    替换文本文件内容
  • 原文地址:https://www.cnblogs.com/chch157/p/11050688.html
Copyright © 2011-2022 走看看