本文将详细介绍账务相关系统的设计方法,并从账务原理、账户子系统、热点账户、账户合并、会计日切原理、营销类账务处理、清结算的账务实现模型等10方面了解账务及账户的相关内容。 账务处理过程中需要进行线程控制,无论是收钱、付钱还是转账,为了保证账务的准确性,每次账务处理都是一个单独的事务,就算是多个请求同时发生,对账户的操作也需要一个一个的进行处理,当一笔入账请求开始处理时账户资源会被加锁 ,就得到了如下图所示的,各段数据源与账务核心的账务处理关系。 账务处理要素:账务处理的要素就是要做账务处理,需要关注那几个维度的信息,主要是5个维度:什么业务、什么时候记、用什么数据记、记账规则是什么。 10.4账务处理规则及示例先看整个全局核算是如何做账务处理的,我们以收款业务为例,整个收款业务的账务处理涉及到4个环节、3类差错:支付交易环节、渠道清算核算环节、商户结算环节、渠道结算核算环节、客户差错
我们每天在银行的存钱、转账、办贷款等等,其实银行基本都在进行账务处理。一、对内账和对外账银行的账务体系分为两条线,一条线管自己,一条线服务客户,两者互不干扰、又相互关联。 对内账务银行自己的账,核心是算清银行自己的资产和负债。 对外账务客户的账,银行给外部主体开的账,每一个账户都对应着具体的客户、企业、合作机构。比如储蓄卡账户、企业的经营性贷款账户、银行之间的资金拆借账户,都属于对外账务。 四、账务组织银行每天要处理几十万笔业务,怎么保证账不会记错?答案是双重保险。 六、每日账务总结银行柜员常说轧不平账就不下班,这里的轧账就是每天营业结束后的账务总结。不管当天有多少笔业务,都必须通过三样东西把账轧平。
本文将详细介绍账务相关系统的设计方法,并从账务原理、账户子系统、热点账户、账户合并、会计日切原理、营销类账务处理、清结算的账务实现模型等10方面了解账务及账户的相关内容。 账务处理过程中需要进行线程控制,无论是收钱、付钱还是转账,为了保证账务的准确性,每次账务处理都是一个单独的事务,就算是多个请求同时发生,对账户的操作也需要一个一个的进行处理,当一笔入账请求开始处理时账户资源会被加锁 ,就得到了如下图所示的,各段数据源与账务核心的账务处理关系。 账务处理要素:账务处理的要素就是要做账务处理,需要关注那几个维度的信息,主要是5个维度:什么业务、什么时候记、用什么数据记、记账规则是什么。 10.4账务处理规则及示例先看整个全局核算是如何做账务处理的,我们以收款业务为例,整个收款业务的账务处理涉及到4个环节、3类差错:支付交易环节、渠道清算核算环节、商户结算环节、渠道结算核算环节、客户差错
一、银行的账户体系概述 方面 传统模式 现代模式 核心理念 以账户为中心 以客户为中心 架构特点 账户孤岛 结构化体系 业务支撑 单一业务处理 全面资金流转、风险管控、合规保障 银行账户体系建设价值 结果 柜面系统 发起"开立活期账户"交易 请求核心系统 核心系统 关联客户号,生成Account记录 存入账户主数据系统 卡务系统 账户与借记卡绑定 完成卡账户关联 六、账户使用场景示例 工资入账处理流程 ️ 现代银行账户三层架构 层级 实体 功能 示例 客户层 Customer (CIF) 唯一客户标识 张伟、王静 合约层 Account Agreement 客户与银行协议 结算账户协议、信用卡协议 账务层 资金交易处理 POST /transactions Transaction 总账管理 会计分录生成 POST /ledger-entries GeneralLedger 核心技术组件 组件 技术栈建议 关键特性 ECIF系统 微服务架构 高可用、实时数据同步 账户中心 分布式数据库 强一致性、高并发处理 交易引擎 事件驱动架构 异步处理、最终一致性
二、项目环境搭建 2.1 数据准备 /* 创建账务管理的数据库 */ CREATE DATABASE account CHARACTER SET utf8; USE account; /* 用户表 字段,列 主键 分类名称 可变字符 金额 double 支付方式 可变字符 (支付,收入方法) 创建日期 date 账务描述 可变字符 */ CREATE TABLE view层作用: 视图层,即项目中的界面 controller层作用: 控制层, 获取界面上的数据,为界面设置数据; 将要实现的功能交给业务层处理 service层作用(可省略): 业务层, 功能的实现 , 与controller控制层和数据访问层DAO交互, 将对数据库的操作交给DAO数据访问层来处理 dao层作用: 数据访问层, 用来操作数据库表的数据 entity 实体包: 存放JavaBean void transferMoney() { } //4.5取款界面 private void drawMoney() { } //4.4 存款界面;去对账户做处理
退货与销售折让是企业经常性的经营行为,若不正确处理这些业务,将会在会计核算上带来很多不便。 下面谈谈常用的账务处理方法。 1、购买方未付货款并且未作账务处理的 购买方须将原增值税专用发票第二联(发票联)和第三联(税款抵扣联)及产品(商品)销货单主动退还给我方,我方则应视不同情况作下述处理: (1)我方在会计上未入账时,应将所有专用发票联次注明作废 2、购买方已付货款或者货款未付但已作账务处理,发票联及抵扣联无法退还的情况: 购买方必须取得当地主管税务机关开具的进货退出或索取折让证明单,递交我方,作为我方开具红字(负数)专用发票的合法依据。 如果此时乙公司(购货方)未付款,并且未作账务处理,则须主动将发票联和税款抵扣联退还我公司,我公司应根据不同情况区别处理: (1)若我公司未入账,应将该发票所有联次注明作废,并将发票联和抵扣联粘贴于存根联后面 ——乙公司)234000 我方收到退回的货物后,应作冲减销售成本的账务处理: 借:产成品150000 贷:产品销售成本150000 (b)购买方(乙方)在退还对方红字发票和退货后,也调整相应的会计处理
账务基础理论银行的账务系统由两个相辅相成的系统组成,明细核算和综合核算。明细核算明细核算: 相当于明细账本,在每个大科目下记录具体账户的变动。 核心作用是全面呈现银行当日的账务全貌,检验当日账务是否平衡,并作为后续账务核对和业务分析的基础依据。综合核算后面会提到,这里先把图放在这里。 2、现金类科目因未达账项(如柜员尾箱未及时上缴)不平由相关柜员对尾箱进行核对并完成上缴操作,之后在系统中重新发起轧账,系统会自动处理未达账项,使现金日记簿、库存现金模块与总账 “现金” 科目达成平衡3、 系统批量处理故障(如隔夜利息计提错误)引发不平在系统主管授权后,通过 “批量交易回溯” 功能找到异常批次,重新执行该批次的批量处理,系统会自动修正因计提错误导致的相关科目余额,实现账务平衡。 可以实现支持客户查询流水、追溯单笔交易来源处理纠纷处理、基于每日余额进行利息计算。账户流水明确区分本金转出(100 万元)和手续费支出(100 元),与实际清算路径一致。
电信账务系统是电信运营商的核心系统 BOSS(业务运营支撑系统)的核心部分,属于电信行业最关键业务系统之一,承担着用户账务处理、账单生成和支付处理等核心职能。 作为电信行业典型的 HTAP(混合事务/分析处理) 应用场景,账务系统不仅要高效地处理大规模在线事务,还需实时分析复杂查询以支持业务决策。 MyCat 作为中间件实现了分库分表,但其在以下方面表现不佳,包括但不限于:系统高可用性,系统灵活扩展性,开发透明性、在线 DDL、复杂 SQL 处理 、跨分片 JOIN 处理性能、非常复杂的配置维护。 TiDB 投产后业务平均处理性能实现 30% 以上的提升,数据存储空间由原先三副本 40TB 的存储空间缩减至三副本 10TB,节省了 300% 的存储成本。 作为一款 HTAP 数据库,TiDB 同时满足了交易处理或大数据库分析型的业务需求,彻底解决了分库分表方案的分布式事务、大 SQL 大事务、维护复杂等问题。
从键的过期时间逐步细化、实现增量复制到推出分布式集群Redis CLUSTER,LUA脚本的功能不断增强,再到4.0版本支持MODULE,由此可见,Redis的发展更多的拥抱了数据处理的大潮。 因此,在互联网金融账务核心系统中,更偏向于选择REDIS CLUSTER。 2.Redis在互联网金融账务核心系统的一些应用场景 互联网金融账务核心系统是一种特殊的账务系统,与传统金融的账务核心相比较,它具备数据的强一致性和业务耦合程度,具备数据传输的合规性,更具备某些场景下极高的访问密集度 以下列举Redis在互联网金融账务核心系统的一些典型的应用场景。 redis7.png (2)对Redis进行全局数据化处理,基于Redis内存高读写高QPS的特性,解决热点数据的高并发问题。
上一期【跟着小帅学账务(9) 会计核算】中小帅学到了会计核算的基本原理,这也到了年底,小帅想用所学的东西做一个财务报表,但财务报表怎么做,还得请教一下会计专家大强。 资产负债表严格遵循会计恒等式资产=负债+所有者权益 参考:跟着小帅学账务(1) 复式记账法 利润表。简单说就是看一家公司到底多能赚钱 公司有钱不代表一定有能力赚钱,不然哪有那么多商场沉浮、兴衰成败? 在上一期【跟着小帅学账务(9) 会计核算】中已经说到,在会计日切的时候,会计科目逐级汇总,产生科目的发生额和期末余额,这些就是资产负债表的数据来源。 资产负债表长什么样? 到此跟着小帅学账务系列就完结了,这是我第一次写这么长的系列,感谢大家一路的陪伴和支持,这个系列收到大家很多的好评,也收到很多建议。我都一一记下了,后续还会有新的系列,敬请期待。
图4.2(点击可查看大图) 最上层的账务业务层提供外部访问接口,负责处理最上层的业务逻辑,有一定的对外I/O请求,内部无状态。业务会被分解为多个条件转账请求发给下层的基础账务层。 基础账务层处理完的结果为会计账本,会输出给存储层。完整的分层架构图如下图4.3所示: ? 图4.4(点击可查看大图) 图4.5展示了多个事件处理时的时序图: ? 图4.5(点击可查看大图) 举一个账务系统的例子。 鉴于命令和事件都是通过消息系统来传输,加之CQRS设计模式中写和读两个操作之间也是通过消息系统来传输,一个自然的整体解决方案即为:用流处理的架构来设计整个账务系统的消息传送和处理。 业务层主要处理账务业务逻辑,为无状态节点,容易横向扩展,由Java实现。核心业务层和基础架构层负责处理和维护业务状态,为有状态节点,有稳定性、强一致性及性能表现等需求,由C++实现。
特别是在超大型项目中,一天需要处理等同数百亿USD的资金流水。今天我就来分享一下在超大型项目中对账怎么做。 我们重点聊一聊明细对账,按照常规思路会把对账设计为一个批处理系统,每个步骤都是一个批处理任务: 明细对账流程 如果数据量不大,也没有时效性要求,这么设计完全可以。 但我们现在要处理的是每小时30亿的资金,还需要及时完成对账以免影响当日的账务核算。因此今天来介绍另一种流式对账引擎。 对账结果处理 汇总的结果需要进一步处置,但由于不在主流程内,可以异步进行: 进行相应的记账,不论对账是否存在差异,都需要在内部账务上进行登记,涉及到渠道费用的,也需要记录。 断点处理 清算明细文件较大,如果解析过程中发生中断重新开始解析,在时效性上就无法达到要求。可以在缓存中记录下当前的解析进度,恢复时就可以从断点处继续处理。
前置系统:账务的业务处理系统,主要负责对上游业务系统的对接,完整账户的拆分等工作。 账务核心系统(原子系统):主要负责账户记账,记录对商户、用户、内部户等客户账的动账及明细。 我们经过研究,发现账务处理是有共性的,对于交易顺序、原子交易类型都是可以提取出属性的。所以我们建立了场景码模型。 首先,我们定义子账户id,按账户类型+币种+业务类型唯一定义一个子账户。 2.3.2.4 异常处理 高并发场景下的异常处理一直都是各方研究的课题。为了适应高并发场景,前置做了如下的异常处理: 1)幂等机制:所有接口都支持幂等操作。 2.3.3 原子系统设计 原子系统流程处理中,主要有以下几步:订单参数预处理,分单,同步执行器,异步执行器,后处理,最后封装参数返回。 一 三、后记 账务中台建设到现在,已经完成了携程体系内账务中台的基本建设,这只是中台建设的第一步,后续规划还包括分布式事务、热点账户的处理;新机构业务接入如何更简洁等等。
二、账务清结算业务处理,账务结算的核心处理模块。 若数据库异常重试或交易故障的人工恢复等处理导致的高频,一般不作热点账户。 账务处理避免不了数据库行锁。 若一次账务处理数据库事务10ms,对热点账户处理TPS最大 100,一旦超过阈值,频繁锁竞争会使数据库性能骤降。 热点账户分类: 4.1.1 入款热点 入款热点常用的做法是缓冲入账,将入款交易缓冲,按照一定的处理速度做账务处理,使得账务处理速度低于 tps 的阈值,保证数据库性能稳定;如果在逐笔缓冲处理仍有压力,可以使用汇总缓冲 本文账务清结算系统采用分布式缓存方案,包括:账户余额实时处理模块、账户余额缓存处理模块和定时补偿处理模块。
图23 2001段数据的账务处理逻辑将所有数据段以及核对差异产生的差错处理数据的账务处理规则进行了梳理,并绘制出了如图24所示的各段数据源与账务核心的账务处理关系图。 图26 清结算体系的账户业务流程全貌有了上述会计科目后,为了清晰理解账务处理,我们需要明确账务处理的要素和基础原理。 账务处理的要素涉及进行账务处理时需关注的几个关键维度,主要包括以下四个方面:业务类型、记账时机、记账数据以及记账规则。 表5 清结算账务处理环节为了加深对上述各环节账务处理的理解,我们通过一个实际的收款例子来进行说明。案例:平台收到两笔款项,每笔均为10元。 由于平台补单的数据属于平台的支付记录范畴,因此其账务处理规则与平台正常支付记录的账务处理规则保持一致,具体记账流程如图31所示。图31 交易差错处理账务处理至此,所有账户的记账情况如图32所示。
实际调用账务系统前,可以增加一个小配置,如果是测试商编,则直接标记为调用账务成功,而不会实际的去进行扣账操作。 调用账务系统,需要设置本方出款系统的回调地址,好让账务再处理完成后,回调我们实际出款结果; 一般来说,账务系统都有一系列交易码,交易相关字段,所以出款这边可能需要根据不同的业务方来传递不同的值; 给账务传递出款的金额和手续费 ,比较数据即可保证金额的准备性; 之后实际的调用账务系统,账务系统回进行余额的扣减操作,如果有失败,账务系统建议做成幂等操作,可以重复请求,但只会进行一次出款。 (只有打款中心手动操作,我们无权处理) 与调用账务时,失败的时候类似,当打款失败时候,我们需要进行退款操作,其实退款操作就是对商户当时扣减的账户余额进行调增处理,手续费和出款的金额都要给用户增加回来; 思考: 在商户维度下,增加一些配置,更加细粒度的控住出款的金额时间,收取手续费的大小; 逻辑补偿: 调用账务处理 通知商户处理 调用退款处理
查询账务 多条件组合查询账务 添加账务 编辑账务 删除账务 2. 项目环境搭建 2.1. view层作用: 视图层,即项目中的界面 controller层作用: 控制层, 获取界面上的数据,为界面设置数据; 将要实现的功能交给业务层处理 service层作用: 业务层, 功能的实现, 与controller 控制层和数据访问层DAO交互, 将对数据库的操作交给DAO数据访问层来处理 dao层作用: 数据访问层, 用来操作数据库表的数据 db数据库: 这里指MySQL domain 实体包: 存放JavaBean 方法,用来将指定的账务信息进行更新 1.4 更新完毕后,使用输出语句,提示 “编辑账务成功!” Controller层的作用是“调度”,调度的是表现层view和业务层Service,主要功能分为:一是把表现层的数据交给业务层处理;二是把业务层返回的数据交给表现层显示。
,支付处理再到清算处理和账户会计处理,最后通过渠道通信前置调用银行渠道完成支付交易落地。 支付交易处理 支付交易的处理在上述流程下就很好理解了,首先,业务系统通过收银台或者支付API将交易发到支付系统,支付系统通过账务交易记录账务并给到会计系统,然后通过清算模块与银行渠道完成支付落地,最后将清算模块与会计记录进行核算 账务会计 ? 账务会计 账务和会计相关我之前专门有一篇文章分析,此处就不再赘述。 传送门:【支付系统设计从0到1】支付宝架构中记账功能设计分析 支付清算 ? 支付清算 在支付清算这页里我们看到,支付宝分了支付系统和清算系统作为联机交易,其实这就是我们之前讲的支付系统设计中的支付产品和支付渠道,然后通过记账指定给到账务系统里再做记账,联机记录交易流水,异步做复式记账 这其实也是我们在设计支付清算系统的时候的一个原则:为提高交易性能,交易必须与账务分离,以提高交易处理性能和效率,从而有针对性的分块解决复杂业务逻辑。
特性 说明 时间特征 T+1日及以后发现的差错 处理限制 无法直接修改历史账务 核心方法 通过新账务"抵消"和"调整"前期错误 本质 会计修正程序的特殊形式 由于金融机构的日终批处理完成后,账务已更新到新的日期 ,系统不允许直接修改历史账务记录,因此必须采用专门的差错处理流程进行修正。 会计分录: text 借:其他应收款-待处理差错款项 贷:客户存款账户 后续处理:如果追回资金,再做反向冲销处理。 典型场景: 季度结息日(3月21日)系统bug导致利息少算 4月1日发现问题 无法修改3月21日账务 隔日处理: text 借:利息支出 贷:客户存款账户 四、隔日差错处理核心特点 保障账务准确性:确保金融机构账务的最终正确性 ✅ 维护客户权益:及时纠正差错,保护客户资金安全 ✅ 强化内部控制:通过严谨流程防范操作风险 ✅ 提升服务质量:建立客户对金融机构的信任
2)账务核心: 负责内场的记账和会计账务处理,账务核心为了提升性能采用了异步账务处理的方式,先单边更新客户余额,然后异步复试记账,最后通过内外部客户账同步实现一笔联机账务的处理。 1、入款结算流程 收单为入款交易,因此他实时联机交易先发送到渠道上,支付成功后完成账务处理。 ,他是个业务作业系统,产品架构上本身没有特别的复杂度,复杂度还是在对账和清结算的账务处理。 详细内容参看 刚哥,公众号:刚哥白话资金搬运工,清结算系统 10 最终一致,账务核心 账务核心是支付平台的账务的基准。他日间与支付引擎配合记录联机交易清算账务,日终与对账中心配合处理期末的总账核算。 10.1、缓冲记账 日间联机交易分为内场结算和外场清算,账务核心负责内场结算账务的处理。为了实现支付高性能账务核心采,通过单边记账来更新客户余额,通过异步和缓冲记账的方式来更新内部户和客户月。