Account:账户)模型" + 支付系统的"账户体系"的设计与记账处理

什么是"待结算账户"、"过渡账户"、"贷记记账"、"借记记账"，"应收账户"、"应付账户"...?
不知道你们怎么是理解的。

支付系统架构上，"账户核心系统" 以及 "会计核心系统"是两个平层的基础核心服务，
它们都包括各种各样的？账户，记载着不同主体的余额以及变动数据。
账户核心由业务的角度去记账，财务核心系统要由专业会计学角度去记账。

上图说明:

记账主体层面，账务核心记录的主要是外部用户，帮助商户以及个人记账；
会计系统记账主体，既包括外部用户，也包括内部，比如过渡户啊垫资户啊等。
记账法层面，我个人觉得这点是最突出的不同，账务核心从业务的角度出发，
上游是什么业务，对应余额是增是减少很好理解，我账户系统负责增减操作即可。
而会计系统，采用专业的会计学复式记账法，有借必有贷，借贷必等。
系统使用层面，账户是面向C端用户，
比如微信的余额，以及流水数据，不是流水记录是那种借X账户X元那种，不然普通用户怎么能理解？
会计系统的用户是支付公司财务人员，
不同行业有不同的交流术语，你以为的天书在他们眼里就是日常沟通。

那再问一下，两个系统之间的账户有什么关系？
答案是对应关系，前面提到的几点不同而已，由不同的层面去为主体记账。

* 账务系统，简单来说，快、准、稳。

快，要求用时低；
准，准确地记录账务数据；
稳，不能时不时出现问题的情况。

财务记账系统，对记账最大的要求是“对”。
其实会计系统的存在一部分是解决财务的专业问题，
还有很重要一个功能是帮助账务系统记“对”账把关的。

支付系统的"账户体系与记账处理"

账户体系和会计的设计是整个支付系统的底座基础，
是支付系统在基础支付服务的基础上，为个人用户及企业商户提供的对于资金收、付、管的服务。

本文的账户体系定义所有的操作都以交易的形式发生，
但从金融核心系统的发展来看，将由以交易驱动转变为以用户为中心的按照产品进行管理的账户体系。

一、交易模型

前文说道，本文的账户体系定义所有的操作均以交易的形式发生，即账户的变动都基于交易而发生。
对于账户的处理，需要依据业务，结合相应的产品体系，建立交易模型。如下：

产品：
如B2C网银、B2B网银、快捷支付、代收代付、身份验证、账户验证。
交易类型：
在产品的基础上，拆分出来的粒度更小的交易，如B2C网银支付可以拆分为收单、结算。
账户体系
基于交易发生的账户变动，如C1用户转账至C2用户。
会计分录
根据不同的交易类型对于会计科目进行设置，每笔交易会形成相应的会计分录，用于记账。
一般需支持一借一贷和一借多贷，即每笔交易都会至少生成一组会计分录。

支付公司的"B2C网银收单"为例：

以下是"支付公司角色"的，假设条件：

支付公司P与"企业商户B"签订"支付服务协议"并为其开设"待结算户"和"余额户"；
每一家"企业商户"在"支付公司P"都有"商家唯一编号"、"待结算户"与"余额户"。
用户C使用中国银行深圳分行B2C网银向企业商户B下单购买商品。
支付公司P通过"中国银行深圳分行"扣款有交易费用。
支付公司结算至企业商户余额户。

二、账户体系

账户按照所有权可以区分为个人账户、企业账户、支付公司账户。

个人账户:
是面向个人用户开设的电子账户，如余额户记录用户在支付平台的余额，
企业账户:
是面向商户开设的账户，如待清算户，基本户。
支付公司账户:
是支付公司为自身业务开展的需求而为自己设立的账户，如备付金账户、长款户、短款户。
此外，支付系统还可以根据业务需要设置各种不同的账户类型。

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

账户的基本信息
账户号、账户类型、余额、币种、账户状态、开户时间等，
此外还可以设置对账户的权限进行控制，如：是否允许"充值/提现/余额为负
账户的流水信息
包括开户以来的所有账户变动变动信息，何时存入资金，何时取出资金，何时发生账户金额冻结等。

1.账务流水
账务流水包括一个账户所有状态变化的过程信息。
账户管理系统对外提供了开户，记账、账户信息查询与变更、销户等一系列API服务。
如下表：

2. 结算时间
支付都是先记入在支付公司的开设的"交易方的待结算户"，
然后支付公司设计有"批量结算周期(例如D0当天某一时间点)"，
将"该周期(D0是24小时)的所有待结算交易"批量提交清算机构结算完成后，
并将"每个交易方的待结算户资金转至基本户"。
例如，可设计成下午4点后，待结算户资金结转至基本户(假设支付公司P设置D0结算时间节点为每天下午4点)。

账户用例（仅记录商户侧）

1.开户

资格审查:
商户A是一家电商平台，接入支付系统快捷支付，支持借记卡和贷记卡；
对于手续费征收，经协商，
采取收支两线，并预存手续费10000元，交易手续费费率为1%；
同时因为该商户资质较好，交易时采取D0实时结算。
商户开户，根据商户交易特点，需开通以下账户：
待结算户：用户在商户交易完成后，资金进入该账户。
基本户：商户的余额户，可体现，交易结算后，资金进入该账户。
手续费户：专门用来存放手续费的账户。
账户初始化状态:
开户后各账户余额如下：

收单交易
某用户C上午9点, 在A电商平台上使用快捷支付购买1000元的手机，
交易完成后，A商户待结算户增加1000元, 手续费按照1%标准征收，由商户支出.

因此，该笔交易手续费为：1000*1%=10元，计入A商户的手续费户，
扣完手续费，A商户的待结算户，应收还有9990元。

假设，支付公司P设置D0结算时间节点为每天下午4点。
那么，下午4点后，待结算户资金结转至基本户。
提现
A商户在下午4：30时，发起提现600元，商户提现手续费按笔征收，每笔2元。
A商户提现600后，基本户剩400元，同时每笔需付出手续费2元，手续费户剩余9988元。
账户变动如下：

三、会计核算体系

按会计科目所反应经济内容的不同, 一般可分为:
- 资产类科目: 资产类科目余额方向在借方
- 负债类科目: 负债类科目余额方向在贷方
- 资产负债共同类科目: 资产负债共同类科目根据实际情况可借方可贷方
- 所有者权益类科目;
- 损益类科目.
会计科目分为总账科目和明细类科目：
- 总账科目，又称一级科目，
  是总括反应会计要素的科目，如银行存款、应收账款。
- 明细类科目，
  是对总账科目所包含的内容的细化所形成的科目。
  在明细科目上，根据需要设计二级科目、三级科目。
  注意: 没有下级的科目称之为叶子科目，只有叶子科目下才可以开账户。
常见会计科目：
- 资产类科目：银行存款、应收账款、在途调拨
- 负债类科目：个人账户余额户、公司（商户）账户余额户、应付账户
- 共同类(主要是待清算)：待清算充值款项、待清算提现款项、待清算支付款项

会计科目与账户的对应关系见下图

四、业务流程

总体交易流程

业务系统
- 交易网关：处理个人或者企业用户的充转提业务
- 资金调拨等系统：进行资金调拨时，调用账户记账；长短款的处理。
- 其他系统：其他业务系统的账户记账请求
账户系统
记录每笔交易的交易收付记录
会计系统
按照企业会计分录流水记账，记账采用复式记账法。
清结算系统
A. 交易清分: 算出给每个账户转多少钱，同时从每个账户收多少钱；
B. 交易结算出款：调用"银行/通道"代付接口，自动出款。
C. 对账：核算"通道"与"支付系统"的应收应付。
注意: 对账业务流程，最好不与清算、结算勾连在一起，和"上游通道"对账, 与给"商户"付多少钱，最好独立。

账户、会计处理流程

来自支付系统的一笔交易:

至少会在"账户系统"产生一条账户流水记录(明细账)，
同时会在"会计系统"根据业务的需要产生一套或者多套会计分录流水，
账户余额与会计余额对应。

概括之:

账户与会计两个系统相互依赖，账户系统是会计系统的前置
账户系统是提供对"外部客户"的账户需要，例如:客户的查询余额，账务明细；
会计系统是为"支付公司"的"核算管理的需要"而设立的，
与"支付公司"有交易的"银行/通道"的"资金清算与结转"都需要会计系统的支撑，
内部户与外部户的"资金核算管理"也需要会计系统。

记账过程：

要点

支付订单: 前端支付订单产生
- 支付系统按照订单内容封装成各类交易，并组成交易报文，通过银行通道提交到银行进行支付；
- 银行完成"支付交易指令"的处理后通知到支付系统，这是一"异步过程"，通过"异步消息"通知。
- 支付系统根据银行报文内容通知到商户订单的处理结果之后，交易处理过程即告完成。
交易必须与账务分离:
目的是为提高交易性能，以提高交易处理性能和效率，从而有针对性的分块解决复杂业务逻辑。
在支付交易处理完成之后，"前端交易处理系统"根据业务场景将交易分实时和非实时记账的方式，
将成功的交易以流水的形式提供给账户系统。
整个交易过程，在支付核心送账户系统时其实已完成。
账户记账:
账务的处理分账户系统处理和会计系统处理，账户是会计的前置。
- 账务流水号生成:
  交易流水到达账户系统之后，账户系统为每笔交易分配账务流水号，
  账务流水号的形成，需要账户前置调用计费服务算出商户的交易手续费。
- 通知与记账:
  账户流水号形成后，
  对"非实时记账": 则先通知"业务系统"记账完成，后开始记录"分户账"和"更新余额"，
  对"实时记账": 则系统先开始记"分户账"与"生成账户余额"，余额更新完毕，后通知业务系统记账完成。
会计记账:
账户系统记账完毕后，定时以"批量文件的方式"送会计记账，
同理，会计记账也将为每笔交易分配会计流水，
对于会计记账，需支持一借一贷、一借多贷和多借一贷的记账模式。
会计记账也分为记分户明细账和更新会计余额。
日终批处理:
会计记账完毕后，每日日终时，进入日终批处理过程，
日终批处理是对日间没有处理完毕，以及不需要在日间处理的任务进行批量处理。
在记账上，日终批处理主要指业会核对，即账户系统余额与会计系统余额的核对。

至此，整个账务处理过程才算真正结束。

支付的“账户”历史与进化

现在支付清算体系是站在账务核心之上，账务核心在“账户”。
略复杂一些的支付清算也是围绕着各“账户”进行资金操作：

交易与货币的发展

价值载体角度

物物交换 -> 一般等价物

物物交换时代	“一般等价物”时代

支付媒介角度看：

铸币时期	硬币纸币时期	电子货币时期	现代信息社会
交易支付时，交易用户A从存放铸币的容器中取出铸币，交给交易用户B，B收到货币，放在自己的存放容器中；	交易支付时，交易用户A从存放纸币的容器（比如钱包）中取出纸币，交给交易用户B，B收到货币，放在自己的存放容器（钱包）	交易用户A从存放电子货币的容器（想一下是什么）“取”出电子货币，交给交易用户B，B收到，放在自己的存放容器（？？）	存放电子货币的容器是什么呢？是“账户(记账簿)”。

所以我们可以得出，账户(记账簿)的本质是什么？账户(记账簿)的本质是电子货币的载体。
业务(金融)角度，账户是数据载体，可以理解为账户是"记账簿"，
用于记录某个主体的、某类资金的余额、以及余额变动明细的“数据载体”。
抽离出一些关键词：某个主体、余额、变动明细。试着去窥探一下“账户”。
主体很重要，账户需要有一个主体作为所有人，记录的这些钱是谁的。

主体: 可以是个人，可以是法人，可以是一个组织。比如:
- 央行清算账户，是央行的账户核心系统，记录着X银行为主体的资金余额以及变动信息。
- 银行的结算账户，是商业银行的账户核心系统，记录着X自然人/法人为主体的资金余额以及变动信息。
- 支付账户，是持牌的支付公司的核心系统，记录着X自然人/法人为主体的资金余额以及变动信息。

不同机构的账务系统管理着不同资金属性的“账户”。
支付的创新和变革，支付产品的设计都是建立在一套新模式账务体系之上；
账务的核心在账户，做一个支付业务，先要明白账务、账户。

“三户”模型及 "常见实践"模型

见细刨一下“账户”。

哪三“户”：Customer / User / Account

最早起源于eTOM(增强型电信运营图)，在电信行业得到广泛使用。
eTOM 引入是"电信行业营销模型"转向“以客户为中心”的理念而产生的成果。
围绕Customer(客户)建立User(用户)和Account(账户)。

三个实体, 本身是相互独立的，分别是体现完全不同的几个域的信息:

customer：一个自然人或一个法人就称之为一个客户
Customer体现了社会域的信息，是真实世界的身份。
user：是因为对Product(产品)/Service(服务)的交易或使用而产生的实体。
假设，一个Customer使用了Many Product，那么一个Customer就会对应 Many User.
User体现了产品业务域的信息，是某产品域的使用身份。
更多是体现"Use(使用)/Deal(交易)"的角度。
account：Account概念起源于金融业，是一个Customer存放资金的实体。
Account需要进行"Accounting(会计记账)"，一个Customer可以拥有一个或多个Account。
Account体现的是资金域的信息。是资金的使用身份。
也就由事务型的 Product/Service 的 "单次/短期" 的 "Use/Deal"
转成关系型的 "Networking/Relationship"。