️ 现代银行账户三层架构 层级 实体 功能 示例 客户层 Customer (CIF) 唯一客户标识 张伟、王静 合约层 Account Agreement 客户与银行协议 结算账户协议、信用卡协议 账务层 活期存款、定期存款 传统vs现代账户体系对比 特性 传统银行 现代银行 账户结构 扁平结构 分层结构 产品对应 一个账号对应一个产品 面向客户的多层账户 管理粒度 账户级管理 客户级管理 九、分层设计优势
交易过程中或者完结以后,记账工作就开始了,账务作为支付交易的基础设施非常重要,其关键并不是设计本身,而是账务的设计理念、规范和原则。 本文将详细介绍账务相关系统的设计方法,并从账务原理、账户子系统、热点账户、账户合并、会计日切原理、营销类账务处理、清结算的账务实现模型等10方面了解账务及账户的相关内容。 既然账务这么重要,那么搭建一套适合自己的账务核心是非常重要的1.1从场景中抽象能力从场景中的需求出发理解账务的本质,搞懂客户、客户的场景、客户在场景中的诉求,懂用户才能做出好产品,一切系统设计来源于需求首先是基于外部客户的账务诉求看账务服务 1.2账务总架构解析任何设计都要先俯视全局,一切从总架构出发,在总架构的指引下完成局部建设,账务全局架构非常关键的一点就是与外围系统所建立的往来关系。 所以说这里会有一个复杂的账务处理模型;不管这个模型怎么设计,要保证金业务上顺利完成账务记录要求,以及保证用户的使用体验,从而确保业务的正常进行。
交易过程中或者完结以后,记账工作就开始了,账务作为支付交易的基础设施非常重要,其关键并不是设计本身,而是账务的设计理念、规范和原则。 本文将详细介绍账务相关系统的设计方法,并从账务原理、账户子系统、热点账户、账户合并、会计日切原理、营销类账务处理、清结算的账务实现模型等10方面了解账务及账户的相关内容。 既然账务这么重要,那么搭建一套适合自己的账务核心是非常重要的1.1从场景中抽象能力从场景中的需求出发理解账务的本质,搞懂客户、客户的场景、客户在场景中的诉求,懂用户才能做出好产品,一切系统设计来源于需求首先是基于外部客户的账务诉求看账务服务 1.2账务总架构解析任何设计都要先俯视全局,一切从总架构出发,在总架构的指引下完成局部建设,账务全局架构非常关键的一点就是与外围系统所建立的往来关系。 所以说这里会有一个复杂的账务处理模型;不管这个模型怎么设计,要保证金业务上顺利完成账务记录要求,以及保证用户的使用体验,从而确保业务的正常进行。
当然还有一些表外科目,如下:科目分级一般按需求设计科目层级,也称为歪脖子树,对科目进行命名和编号,形成科目编号表。细分的项目称为叶子,细分的过程称为科目分级。 账务基础理论银行的账务系统由两个相辅相成的系统组成,明细核算和综合核算。明细核算明细核算: 相当于明细账本,在每个大科目下记录具体账户的变动。 核心作用是全面呈现银行当日的账务全貌,检验当日账务是否平衡,并作为后续账务核对和业务分析的基础依据。综合核算后面会提到,这里先把图放在这里。 账户明细:记录每一笔明细交易,一般设计的字段有账号,工作日期,发生额,借贷标志,对方账户,主要是进行插入操作。账户余额:记录账户的当前最新的余额,一般设计的字段有账号,工作日期,昨日余额,当前余额。 图中的日志 A 和日志 B 的设计,叫做双日志设计,实线是当前在用的日志,虚线是昨日日志,日终切换。有疑问吧?核对什么呢?这不是肯定是平的吗!
熟练View层、Service层、Dao层之间的方法相互调用操作 熟练使用工具类操作数据库表完成增删改查以及登录的功能 通过本项目,让我们了解公司项目开发的流程,充分的掌握项目需求分析、设计与功能的代码实现 二、项目环境搭建 2.1 数据准备 /* 创建账务管理的数据库 */ CREATE DATABASE account CHARACTER SET utf8; USE account; /* 用户表 字段,列 主键 分类名称 可变字符 金额 double 支付方式 可变字符 (支付,收入方法) 创建日期 date 账务描述 可变字符 */ CREATE TABLE AccountDao accountDao=new AccountDaoImpl(); Scanner sc=new Scanner(System.in); //为了后续,有很多的输入,直接在外面设计 sc控制台输入为成员变量; //接下来是界面的设计;简单的界面;操作:登录;其他查询?
接下来让我们看一看下一代的核心账务系统如何应对量变和质变的挑战。 3. 百万TPS压测实验 3.1 实验目标 下一代核心账务系统的首要设计目标是更好地支持电商业务。 由于我们是从零开始设计一个新的系统,没有历史负担,所以决定应用更为领先的系统设计来解决核心账务系统所面临的业务和系统复杂度问题。 4.1.1.1 业务复杂度处理 金融系统是一个典型的业务复杂系统。 4.1.2 分层设计 核心账务系统从上至下分为4层: 账务业务层 基础账务层 基础架构层 存储层 另外还有一个纵向贯穿始终的监控层,负责收集监控数据和跨层监控。架构示意图见图4.2: ? 图4.3(点击可查看大图) 4.2 Event Sourcing 4.2.1 原理 基础账务层和基础架构层是根据Event Sourcing的原则来设计的,这也是核心账务系统最重要的架构设计。 鉴于命令和事件都是通过消息系统来传输,加之CQRS设计模式中写和读两个操作之间也是通过消息系统来传输,一个自然的整体解决方案即为:用流处理的架构来设计整个账务系统的消息传送和处理。
我们每天在银行的存钱、转账、办贷款等等,其实银行基本都在进行账务处理。一、对内账和对外账银行的账务体系分为两条线,一条线管自己,一条线服务客户,两者互不干扰、又相互关联。 对内账务银行自己的账,核心是算清银行自己的资产和负债。 对外账务客户的账,银行给外部主体开的账,每一个账户都对应着具体的客户、企业、合作机构。比如储蓄卡账户、企业的经营性贷款账户、银行之间的资金拆借账户,都属于对外账务。 这种双向核对的机制,是银行账务不出错的关键。五、4 种分户账明细核算的核心载体是分户账,银行根据账户的业务特点,设计了 4 种分户账。 六、每日账务总结银行柜员常说轧不平账就不下班,这里的轧账就是每天营业结束后的账务总结。不管当天有多少笔业务,都必须通过三样东西把账轧平。
电信账务系统是电信运营商的核心系统 BOSS(业务运营支撑系统)的核心部分,属于电信行业最关键业务系统之一,承担着用户账务处理、账单生成和支付处理等核心职能。 账务系统的稳定和安全运行直接影响运营商的收入和用户满意度,任何系统故障都可能导致用户服务中断,进而引发经济损失和社会影响。 作为电信行业典型的 HTAP(混合事务/分析处理) 应用场景,账务系统不仅要高效地处理大规模在线事务,还需实时分析复杂查询以支持业务决策。 北京电信账务系统实施了两地三数据中心的数据库部署(包括北京亦庄、天津武清和北京酒仙桥),并采用了应用双活的容灾策略,满足了金融级别的高标准要求。 北京电信账务系统因此成为中国电信省分公司中的首个案例,能够在任意数据中心出现故障时,确保数据不丢失并实现秒级业务切换,成为符合集团规范要求的典范。
因此,在互联网金融账务核心系统中,更偏向于选择REDIS CLUSTER。 2.Redis在互联网金融账务核心系统的一些应用场景 互联网金融账务核心系统是一种特殊的账务系统,与传统金融的账务核心相比较,它具备数据的强一致性和业务耦合程度,具备数据传输的合规性,更具备某些场景下极高的访问密集度 以下列举Redis在互联网金融账务核心系统的一些典型的应用场景。 根据REDIS的锁服务设计,锁在数据结构中使用REDIS最简单的KEY,核心在于建立锁和释放锁,并保证绝对的安全。最简单的方法是用GET来检查锁,当获取不到信息,用SET来设置锁。 针对这种风险,我们的锁设计考虑使用SET NX PX来实现,如下:SET KEY 唯一随机数值 NX PX 固定毫秒。设置KEY的值,仅在不存在时生效,并设置存活期为一个固定毫秒。
上一期【跟着小帅学账务(9) 会计核算】中小帅学到了会计核算的基本原理,这也到了年底,小帅想用所学的东西做一个财务报表,但财务报表怎么做,还得请教一下会计专家大强。 资产负债表严格遵循会计恒等式资产=负债+所有者权益 参考:跟着小帅学账务(1) 复式记账法 利润表。简单说就是看一家公司到底多能赚钱 公司有钱不代表一定有能力赚钱,不然哪有那么多商场沉浮、兴衰成败? 在上一期【跟着小帅学账务(9) 会计核算】中已经说到,在会计日切的时候,会计科目逐级汇总,产生科目的发生额和期末余额,这些就是资产负债表的数据来源。 资产负债表长什么样? 到此跟着小帅学账务系列就完结了,这是我第一次写这么长的系列,感谢大家一路的陪伴和支持,这个系列收到大家很多的好评,也收到很多建议。我都一一记下了,后续还会有新的系列,敬请期待。
这样的对账系统应该怎么设计? 关注腾讯云开发者,一手技术干货提前解锁 鹅厂程序员面对面直播继续,这次将邀请鹅厂大佬讲讲自己从大专到腾讯的心路历程。 我们重点聊一聊明细对账,按照常规思路会把对账设计为一个批处理系统,每个步骤都是一个批处理任务: 明细对账流程 如果数据量不大,也没有时效性要求,这么设计完全可以。 但我们现在要处理的是每小时30亿的资金,还需要及时完成对账以免影响当日的账务核算。因此今天来介绍另一种流式对账引擎。 对账结果处理 汇总的结果需要进一步处置,但由于不在主流程内,可以异步进行: 进行相应的记账,不论对账是否存在差异,都需要在内部账务上进行登记,涉及到渠道费用的,也需要记录。
作者简介 本文为联合撰文,作者团队负责携程集团支付账务系统、消费金融账务系统、清结算和对账等工作的的开发、设计和运维工作。 4)扩容困难 基于以上问题,我们设计并实现了新的统一账务平台。 所以在设计统一账务中台化的工程中,进行了日志组件的设计: 1)统一使用高性能的log4j2替代logback; 2)通过spring aop和annotation,支持方法入参、出参、异常日志的自动打印 2.3.2 前置系统设计 账务前置位于整个账务体系的最上游,提供标准的交易接口,包括入款、入款返还、出款、出款返还、预授权类、转账以及批量接口。 2.3.5 日终系统设计 2.3.5.1 为什么需要日终系统 1)提供账务系统支撑 要保证账务系统能正常运转,账务的余额要100%准确。
实战干货:编程严选网 1 账务清结算系统职责概述 账务清结算系统是支付系统的资金控制管理模块,分为: 1.1 账务 账务系统为外部客户和内部管理者提供符合公司内部财务核算的各种会计凭证、账簿与财务报表, ,即使其中一个系统出问题,也可保证不产生资损,降低资金风险 账务清结算系统接收到支付的指令后,根据业务流程、账务规则和结算规则,设计账务清结算系统的组成结构: 一、前置接口 对外系统提供不同的协议服务, 以完成账务入账和结算逻辑。 商户资金流大,交易笔数多,要求日清日结,按商户+日期+订单号拆分,控制单笔记录几百万内,保证单日商户数据查询效率 小微商户,交易量小,查询时间跨度长,只按商户号一级拆分 6 结算规则 针对商户计费结算规则多变,设计个标准的算法指令 还设计一套算法组合标准,把若干算法按标准组装成算法执行策略,通过对算法策略包含的每个算法指令的执行,完成计费结算逻辑。 6.1 执行流程图
熟练View层、Service层、Dao层之间的方法相互调用操作、 熟练dbutils操作数据库表完成增删改查 通过本项目,让我们了解公司项目开发的流程,充分的掌握项目需求分析、设计与功能的代码实现。 查询账务 多条件组合查询账务 添加账务 编辑账务 删除账务 2. 项目环境搭建 2.1. 数据表创建 对一个项目而言,表设计是非常重要的,因为应用程序中所有的操作都是基于数据库表而进行的,所以我们第一步就是创建数据库表。 管家婆项目的数据库设计很简单,我们只需找到gjp.sql文件,然后执行之即可。下面是创建库及表的SQL语句: 2.3.1. 方法,用来将指定的账务信息进行更新 1.4 更新完毕后,使用输出语句,提示 “编辑账务成功!”
所以系统架构设计上需要构建稳定的基础业务服务,通过服务重用实现业务敏捷,同时保障核心安全稳定。 典型处理模式 ? 支付交易处理 支付交易的处理在上述流程下就很好理解了,首先,业务系统通过收银台或者支付API将交易发到支付系统,支付系统通过账务交易记录账务并给到会计系统,然后通过清算模块与银行渠道完成支付落地,最后将清算模块与会计记录进行核算 账务会计 ? 账务会计 账务和会计相关我之前专门有一篇文章分析,此处就不再赘述。 传送门:【支付系统设计从0到1】支付宝架构中记账功能设计分析 支付清算 ? 支付清算 在支付清算这页里我们看到,支付宝分了支付系统和清算系统作为联机交易,其实这就是我们之前讲的支付系统设计中的支付产品和支付渠道,然后通过记账指定给到账务系统里再做记账,联机记录交易流水,异步做复式记账 这其实也是我们在设计支付清算系统的时候的一个原则:为提高交易性能,交易必须与账务分离,以提高交易处理性能和效率,从而有针对性的分块解决复杂业务逻辑。
下面谈谈常用的账务处理方法。 1、购买方未付货款并且未作账务处理的 购买方须将原增值税专用发票第二联(发票联)和第三联(税款抵扣联)及产品(商品)销货单主动退还给我方,我方则应视不同情况作下述处理: (1)我方在会计上未入账时,应将所有专用发票联次注明作废 2、购买方已付货款或者货款未付但已作账务处理,发票联及抵扣联无法退还的情况: 购买方必须取得当地主管税务机关开具的进货退出或索取折让证明单,递交我方,作为我方开具红字(负数)专用发票的合法依据。 如果此时乙公司(购货方)未付款,并且未作账务处理,则须主动将发票联和税款抵扣联退还我公司,我公司应根据不同情况区别处理: (1)若我公司未入账,应将该发票所有联次注明作废,并将发票联和抵扣联粘贴于存根联后面 (a)我方在收到《证明单》后,应根据退回货物的数量、价款开出红字专用发票,并作账务处理,分录为: 借:产品销售收入200000 应交税金——应交增值税(销项税金)34000 贷:银行存款(应收账款
本文将分为四个模块, 为大家深入剖析关于账户体系的基础知识、及其在设计上需要了解的要点,希望本文对你有所帮助。目录:账户体系是什么?它能解决什么样的问题?常见的账户体系有哪些?如何设计账户体系? 同时需要阐述各个余额之间的关联关系;图片账务结构:账务明细是用于反映业务真实的变动资金情况,主要包括:业务交易时间、业务单号、业务类型、变动可用余额、变动不可用余额、变动类型、手续费、账务流水号、账户号 其实任何产品的设计都不能无中生有、胡乱设计的,每一种账户体系的结构设计也都是为场景而服务的。目前最常见的账户体系有电商账户体系,支付账户体系,以及银行账户体系。 三、如何设计账户体系?设计原则:1)划分业务逻辑相对的边界在这个产品设计过程中,应当明确 交易、账务处理、清算入账三个阶段。 2)账务处理原则由于账务主要是为整个交易流程所服务的,因此出现的每一种交易类型,都需要同步给账户系统进行账务处理。
有一点值得注意的是,有的银行有出款限额设置,但是客户方面很大可能会超过此限额,我们需要对明细进行拆分,而拆分的依据就是该笔出款明细收款人银行的金额限制; 由于拆分后,订单明细号重复,所以对于整体数据库设计来说 异步: 计算每一笔出款明细的手续费,手续费的配置可以是自己系统来设计,也可以交给单独的计费中心来处理。 需要注意的是,每一笔出款因为时间的不同,而手续费计费的费率也不同。 实际调用账务系统前,可以增加一个小配置,如果是测试商编,则直接标记为调用账务成功,而不会实际的去进行扣账操作。 调用账务系统,需要设置本方出款系统的回调地址,好让账务再处理完成后,回调我们实际出款结果; 一般来说,账务系统都有一系列交易码,交易相关字段,所以出款这边可能需要根据不同的业务方来传递不同的值; 给账务传递出款的金额和手续费 ,比较数据即可保证金额的准备性; 之后实际的调用账务系统,账务系统回进行余额的扣减操作,如果有失败,账务系统建议做成幂等操作,可以重复请求,但只会进行一次出款。
在银行、支付公司以及电商平台的支付系统中,如果不是只做交易转发,而是真正需要做账务处理清结算,一定会涉及到账户体系的设计,一套好的账户体系应该是与业务无关的。 在这一篇里我们主要讲讲支付系统的账户体系的产品设计,在下一篇里重点介绍技术设计中需要考虑的问题。 记账方式 金融机构核心账户/账务的设计一般采用复式记账法。如果要求不高或技术储备有限,也有很多公司直接采用单式记账法。 虽然都能满足业务需要,但相对于复式记账法,单式记账法无法从借/贷、科目/账户多维度来进行交叉检验,保证账务核心的平衡。 记账过程 为提高交易性能,交易必须与账务分离,以提高交易处理性能和效率,从而有针对性的分块解决复杂业务逻辑。
【资料关注公众号输入“支付设计”“知识地图”】 (本人补充:这需要在刚哥的公众号下回复,不是我的) 01 两条链路,支付架构 支付流程从行业内定义上来说,主要是“交易、清分、结算”这三个过程。 1.1、耦合架构 为了支持买卖双方在线交易,清结算系统采用了耦合架构的设计方案。鉴于资金无法如同订单一般直接通过互联网进行流转,本系统结合了交易链路和结算链路,形成了一种独特的清结算模式。 详情参考 支付小钢炮,公众号:刚说产品四句口诀,搞懂支付交易设计 04 三户模型、客户系统 4.1、三户模型 所谓的三户就是“客户、用户、账户”的简称,其中客户拥有唯一的身份,但是他可以通过不同账号来开通多个用户身份 详情参考 刚哥,公众号:刚哥白话商户体系设计,数字化的起点 05 一户多卡,钱包账户 要做个像支付宝一样的即能存放零钱,又能购买理财,消费时还能先享后付。 6.3、三级路由流程 分析完渠道设计后,下面我们就把流程、参数和模型进行串联,以此来了解其上下游的对应关系。 ①解析支付订单,提取路由因子,准备路由。