银行核心业务系统总体设计说明书.doc

银行核心业务系统总体设计说明书

91
2020年5月29日
文档仅供参考

四川农信综合业务网络系统

总体设计说明书

四川省农村信用合作社
南天电脑系统有限公司
8月

1. 系统网络拓扑 4
2. 系统逻辑结构 5
3. 数据流说明 6
4. 核心系统逻辑架构 7
5. 交易模式 8
5.1. 通讯方式 8
5.2. 数据一致性保证 9
5.3. 复核交易处理 11
5.4. 抹帐交易处理 12
5.5. 授权交易处理 13
6. 机构逻辑结构 16
6.1. 清算机构逻辑 17
6.2. 机构的设置 17
6.3. 机构管理层次 18
6.4. 机构核算单元上收 19
6.5. 数据要素设计 19
7. 帐务结构与核算方式 22
7.1. 帐务组织结构 22
7.2. 数据模型和帐务登记 25
7.3. 帐号结构 30
7.4. 双边分录 31
7.5. 流水设置 33
7.6. 交易处理规则 33
8. 应用实现框架 34
8.1. 交易开发配置流程 34
8.2. 交易服务处理过程 36
8.3. 应用实现规则 38
9. 关键实现说明 44
9.1. 并行处理 44
9.2. 24小时处理 47
9.3. 费用处理 51
9.4. 资金清算 56
9.5. 数据安全 62
10. 总体需求说明 64
10.1. 支持商业规则可配置化和业务逻辑可配置化 64
10.2. 全面产品管理 68
10.3. 完整灵活的收费处理 70
10.4. 批处理控制平台 70
10.5. 历史数据及管理分析与核心相分离 71
10.6. 统一的外部系统API 73
10.7. 前台系统先进性要求 73

四川农信综合业务网络系统的目标是:结合四川农信具体情况,建立一套以客户为中心、账务核算统一、本外币一体化、业务、网点综合化、事中控制、支持24小时服务、支持全面产品管理、参数化、模块化设计的新一代综合业务系统。为了保证这一目标的达成,结合四川农信的新一代综合业务系统的要求,从底层开始对整个综合业务系统进行了设计和规划。

从内容来看,总体设计需要涉及的主题有以下一些方面。
n 系统网络拓扑
n 系统逻辑结构
n 数据流说明
n 核心系统逻辑架构
n 交易模式
n 机构逻辑结构
n 帐务结构与核算方式
n 应用实现框架
n 关键实现说明

1. 系统网络拓扑

系统网络拓扑如图所示,结构上划分为四层,包括:省中心、地市中心、县中心和网点。
省中心:全部业务系统都集中运行于省中心,包括:核心业务系统、综合前置系统等。关键应用参用数据库服务器与应用服务器分离的做法,而且双机互为备份。存储采用专业存储设备进行高速存储。在中心局域网上还有管理和监控前端等。
地市中心:四川省农信地市中心可能存在两种情况,一种是地市中心存在统一管理功能,此类地市中心在地市有统一的管理监控前端;另一种地市中心仅有网络汇集的功能。
县中心:具备县联社的统一管理功能;也是县内网络到地市或到省中心的网络汇集点;同时,全县的网络前端服务器集中于此。
网点:是对外直接服务的窗口,所有的网点终端经过远程网络连接的方式连接到县中心前端服务器进行业务处理,在将来一些自助服务设备也会在网络直接连接。
2. 系统逻辑结构
系统逻辑结构如图所示:

本次项目实施的四川省农信综合业务网络系统(SC6000),包括:后台核心业务系统OFP CoreBanking、中台交换前置和中间业务平台系统OFP PreBranch和前台柜面前端系统OFP AutoBranch。
后台核心业务系统CoreBanking:负责完成银行全面帐务管理和基础金融产品,是整个银行的帐务核心,并为银行后续的业务管理和分析提供基础分析数据。基于核心业务系统,传统柜面业务都获得服务支持,并支持以客户为中心、面向产品管理、高度参数化、全面支持24小时不间断服务等一系列新一代综合业务系统的优良特性。
中台交换前置和中间业务平台系统OFP PreBanch:负责完成后台应用间的交换和互联,并基于平台提供的成熟框架,连接系统外第三方应用并支持丰富的中间业务开发。
前台柜面前端系统OFP AutoBranch:负责完成所有柜服务的前端展现和处理。采用LINUX操作系统实现。
3. 数据流说明
如系统逻辑结构图中所示,在交易处理中:
当进行银行传统金融业务处理时(包括:活期、定期、贷款、结算等),柜员在前台发起交易,交易请求直接发送到后台核心业务系统中实现业务处理;
当进行中间业务和银行扩展金融业务处理时(包括:代收费、大额、小额等),柜员在前台发起交易,交易请求首先到达中台前置系统,由中台系统进行本地业务处理和业务调度,根据需要调用后台核心业务系统和第三方业务系统。
基于统一的业务系统接口规范和交换前置的应用处理,在中心后台的两个应用间不允许存在相互间的直接访问,必须经过交换前置系统进行请求的转发。例如:在将来的国际业务系统需要进行业务记账,业务请求首先到达中台交换前置系统,经过中台的应用解析,在将请求逐笔的传递到核心业务系统中实现记账。
除了柜面的请求,其它的服务渠道包括:ATM、POS、电话银行、网上银行等的业务交易全部都是首先上到中台交换前置系统,进行本地必要的业务处理,然后在向相应的服务端应用发出调用请求。
由于在三个应用平台系统中,核心业务系统是主要业务的处理端和服务端,也是整个系统框架的基础部分与核心部分,因此核心业务系统的设计至关重要,在下面的讨论中,我们也将主要面向核心系统进行阐述,对中台OFP PreBranch和前台OFP AutoBranch请参看相关文档,在此不再赘述。
4. 核心系统逻辑架构
核心系统在技术逻辑结构上设计如图:

逻辑架构上,核心系统分为核心服务层和金融产品层。两个层次相对隔离,经过标准调用接口,实现访问调用。
核心服务层包括提供全行的会计核算、客户管理、公共管理功能。稳定、高效,并具备前瞻性的设计,是确保四川农信综合业务系统可持续发展的重要保证。
p 会计核算的其中会计核算实现业务的综合核算功能;
p 客户管理收集全行客户信息,并建立客户与账户全面关联关系;
p 公共管理实现系统公共参数的统一管理,包括:机构管理、柜员管理等。

金融产品层设计上采用插件式的思想,新的业务可灵活、容易的”插入”到CoreBanking系统中来。在各金融产品服务中实现业务的明细核算功能。实现上,应用请求首先经过统一的交易分发管理,调用相应的处理服务流程完成服务。金融产品层中,提供的服务大致上包含三个主要的类型:
p 专门的核心调用接口提供给银行内部的其它应用群进行帐务处理调用
p 丰富的金融产品组件提供银行柜面调用,如:活期、定期、贷款等
p 核心层的专用调用组件,提供业务人员直接使用。如:报表管理、客户管理、前后台管理等。

5. 交易模式
交易模式描述的内容包括交易的通讯方式、数据一直性保证、复核交易的处理、抹帐交易的处理、授权交易处理。
5.1. 通讯方式
p 通讯协议采用TUXEDO－FML。
p 对于柜面交易采用同步短连接方式。
p 系统除了提供交易报文通讯外,还支持交易的文件传输,在文件传输时只允许前台申请上送或下传。当后台需要下发文件时,需在交易报文中带下传输文件名,由前端平台再进行文件传输处理。
p 为了保证系统的正常运行,减轻后台和网络压力,原则上柜台交易一般为一次通讯,有需要时原则上可进行一次查询,应尽量避免多次通讯。
p 在AutoBranch中,在tpinit时把详细的client端信息带到后台,以满足后台的管理要求。同时为了解决对一些前台提醒的通知信息的处理,在AutoBranch中增加通知的公共处理,方式为在柜面前端的固定位置进行提醒。
5.2. 数据一致性保证
p 事务处理
系统统一在后端启动事务处理。
在交易配置时,是否启动事务为后端SYSMNG配置。配置是否由主控启动事务。配置不由主控启动事务的交易,由应用自行在处理过程中启动事务处理。一般,对于交易类型为记账和管理的交易由主控启动事务;而查询和其它交易,则根据需要自行启动事务。规则上,查询交易无事务,而且需要使用脏读。
由PreBranch发起的交易,PreBranch和CoreBanking分别启动事务。
在交易过程中还有一种特例,部分处理(如:获取柜员流水号、账号顺序号、授权交易处理等)需要跳出事务处理块执行,此时需要数据库中建立另一个连接,在新连接中启动完成单独动作,然后在回到第一个事务处理块。详细请参见8.3.6. 数据库连接方法。
p 数据的一致性保证
不同的逻辑单元间,由于中途存在网络因素,有不同的事务处理,可能存在双方不一致的可能性。分两种情况描述如何处理不一致。
在柜台交易处理过程中,会出现因为网络等原因导致的前端交易上送后没有得到确定的成功失败返回(一般是超时退出),如果处理是记账交易,柜员必须查询后台,而且以后台交易的结果为准。为了保证资金的安全,在未能获取后台交易结果前,必须分情况进行处理,当办理的是需要收取客户资金的交易(如存款)则默认为交易成功,并收取客户资金;当办理的是需要支付客户资金的交易(如取款)则默认为交易失败,不支付客户资金。当网络恢复后,柜员查询后台的交易处理结果,根据后台的处理结果采用抹帐、冲正、重做、补登等手段完成后续处理。例如:柜员办理一笔存款交易时出现超时,这时柜员经过查询交易查询后台流水,如果发现该笔交易后台是未成功的,则再次办理一笔存款交易。如果发现是成功的,这申请补打存款凭条、存折(没有该功能时可柜员手工填写)。如果发现是网络不通,则手工填写凭条、存折给客户,等网络通了再处理。
当交易是由PreBranch发送后台的交易,则需建立应用间自动冲正机制或自动重发机制,在网络状态不明的情况下,中台自动发起抹帐交易(或重发动作),并返回前端失败。在中台日终时,需要启动PreBranch与CoreBanking的对帐,对帐中数据以PreBranch数据为准进行错帐处理。
因此在柜面前端,交易的一致性经过柜员的确认以及业务制度配合保证;在无人值守的后台应用间,交易的一致性经过交易时的自动冲正机制(自动重入)以及日终的交易对帐确保。

5.3. 复核交易处理
系统中的复核交易有两种,一种是对某些业务流程中要求的复核交易(如联行中的往帐报单复核交易),这些交易是复核后才完成帐务处理的,属于事中复核,这些交易一般是每种业务单独有自己的复核交易;一种是业务流程中没有复核要求,出于安全考虑而增加的事后复核(如对公的存取款),这些交易的复核使用公共的复核交易。
不论是那一种复核,现在都采用后台复核的方式,待复核的数据都存在后台,不再在前端保留电子日志。对于非公共的复核交易,交易模式上与一般交易没有太多差别,这里不再具体说明,下面主要对公共的复核交易进行说明。
公共复核交易采用统一的交易入口,流程如下:

公共复核交易基于后台柜员日志表(参看后台流水设置),需要公共复核的交易,在正常交易发起时,在后台柜员日志中会插入一条记录,标记为待复核,同时将需要复核的要素拼装成字符串后在后台存放。前台发起公共复核交易时,按照前端输入的查询条件查询待复核流水和每条流水对应的复核要素串一起下传前台,在前台完成复核要素的比对处理,在结束复核交易时将成功复核的流水批量发到后台修改对应柜员日志的复核状态。

5.4. 抹帐交易处理
抹帐是指对原交易的取消处理,在业务发起当天,如果发现交易有错,在经过授权的条件下发起抹帐交易,取消原交易。抹帐交易使用统一的交易入口(除个别批量发起的业务,如传票套记帐),以后台柜员日志表中的柜员日志号为索引完成抹帐处理。

抹帐采用TRIGGER抹帐方式,其简单操作流程如下:
根据交易时,TRIGGER及存储过程登记信息进行抹帐。
基本流程为:
定义抹帐规则
生成TRIGGER和存储过程,执行
交易时自动记载交易变化情况
抹帐交易根据INSERT和UPDATE操作及特殊处理进行处理

抹帐中,对于公共库表和公共处理的抹帐,可编写面向数据库表的业务抹帐程序,由统一抹帐主程序调用,而对应用自身登记的库表,则需要进行程序开发人员自行定义其抹帐规则。

TRIGGER抹帐详细使用请参看<基于数据库trigger机制的抹帐使用手册.DOC>。

5.5. 授权交易处理
授权是指某个具有足够操作级别的柜员为另一个未具有相应操作级别的柜员授予操作权限的行为。其中,第一个柜员称为授权柜员,第二个柜员称为被授权柜员。
按授权的物理操作模式可分为本地授权、异地授权。本地授权是授权柜员到被授权柜员终端直接进行授权操作。异地授权是授权柜员在本终端进行异地授权交易产生授权码,被授权柜员用授权码确认待授权交易并执行交易。
交易的授权判断在后台进行。

在授权过程中,当进行异地授权,其交易要素或交易界面在等待异地授权过程中将不得进行修改或变化,而且其授权人所在机构为管理上级,对分社而言,一般是其上级大社。授权人在接到通知后,可调出操作员的交易界面进行察看,授权后,该交易界面的内容应该与授权前的交易界面一致。
交易界面的传输内容以文本形式存在,待授权文本文件的文件名规则为”SQ＋交易码(4)＋柜员号(6)＋授权码(8).txt”。已授权文本文件的文件名规则为”YS＋交易码(4)＋柜员号(6)＋授权码(8).txt”。经过文件对比检查是否交易为原交易。
异地授权信息表设计如下:
要素
说明
授权码

机构

柜员号

交易码

交易日期

界面文件名

授权机构

授权柜员

授权柜员流水号

授权标志
0－未授权、1－已授权
标志

唯一索引:授权码
唯一索引:授权柜员流水号
复合索引:机构、交易日期、授权标志

申请授权时,产生授权码登记本表,填写界面文件名,相应修改前台及后台待授权文件名。形成通知信息
授权时,填写授权机构、柜员、流水号和授权标志,可调阅交易界面文件,授权结束形成通知信息
前台接到通知后,进行交易,填写授权编号,对比界面文件。一致后上送后台。

本表每日删除。注意前后台授权交易文件的删除。

在判断交易是否需要进行授权时,除了公共的判断条件(如:交易本身是否需要进行授权、交易级别和柜员操作级别是否匹配等)外,还有一些授权要素需要交易过程中进行检查,此时需要对这些授权要素进行参数化配置。系统提供统一调用接口进行授权检查。
授权要素检查表设计如下:
要素
说明
交易码

条件
(~amt~>1000 && ~mm_flag~ = 1)
说明
有密码而且金额大于1000时需要授权
标志

select * from t_srm_desc where 条件; 当sqlcode＝＝0时,条件为真,需要授权;当sqlcode＝＝100时,条件为假,无需授权;其它为错。对一个交易码,有多个或关系的条件表示式。实现中～amt～为缓冲池变量。

6. 机构逻辑结构
针对于四川农信的机构设置及功能,机构的逻辑需要从管理、清算、报表汇总、清算出口等方面分别定义,因此我们必须在机构编码表中将这些逻辑关系描述清楚,并支持以后的灵活管理。
实现的方法是将机构编码表中的汇总机构全码定义为上级管理机构全码,然后再增加报表汇总机构全码、对应核算单元机构码、清算机构码。这样就能够把几种逻辑关系描述清楚了。
6.1. 清算机构逻辑

从图上能够看出,对于存在地市清算中心的机构,清算级别为4级,而不存在地市清算中心的机构,清算级别为3级,根据成都农信的要求,大多数的县联社,直接上存款项到省清算中心实现清算。
不同业务从清算的路径也是相同的,分社与大社之间经过社内往来、大社与联社经过存放联社、联社与地市中心经过存放地市、地市与省经过存放省中心实现清算,根据机构的灵活设置,清算层级和清算的关系也可实现灵活动态调整。
6.2. 机构的设置
机构名
职责及权限
省联社管理中心
负责全省各机构的维护(增加、删除、修改)工作;负责各级管理中心、省联社清算中心的柜员的维护工作;负责系统标准库的管理和维护工作;全省业务数据的查询及报表打印。
银行卡部(省制卡中心)
管理全省卡账户,负责与银联外联、对帐等。
省联社清算中心
负责全省信用社的资金往来和清算、资金调剂、资金划拨及农村信用社重要空白凭证的管理。清算中心不对外办理存贷款业务。
省联社机关
省联社机关各部门帐务核算。
(地市)办事处管理中心
分类查询及打印辖内的各种报表,在省联社授权范围内开展相关系统管理工作。
(地市)办事处机关(有帐)
办事处机关帐务核算。
县联社的管理中心
负责县联社清算中心、机关各职能部门、营业部及辖内营业网点各柜员的管理和维护。
县联社清算中心
负责辖内信用社资金往来和清算、资金调剂、资金划拨及现金管理以及重要空白凭证的管理。清算中心不对外办理存贷款业务。
县联社机关
县联社机关帐务核算。
联社、社营业部(室)
办理银监局授权范围内的一切对外业务
分社
办理银监局授权范围内的一切对外业务。

6.3. 机构管理层次
机构管理层次如图所示:

6.4. 机构核算单元上收
系统支持核算单元一本帐设计管理,可灵活定义核算机构层次,作为核算单元的机构不再为下属网点机构单独设立总帐,从而形成在本级机构内的一本帐管理。核算单元一本帐设计对实现扁平化管理、提高效率和资金利用率、规避金融风险、增强竞争能力等方面具有重大作用。
核算单元层次的设定取决于银行的法人治理结构以及内部组织和管理的能力,实际过程中能够采用逐步上收核算单元的方法,最终实现全行一本帐。

6.5. 数据要素设计
综上所述,机构的数据要素按如下进行设计
要素
说明
机构号

机构全码

汇总机构全码

核算单元机构码

清算上级机构码

区分码

IP地址

端口号

全国特约汇兑号
(可空)
全国联行号
(可空)
省辖联行号
(可空)
县辖联行号
(可空)
县辖联行号
(可空)
社内往来
(可空)
交换1
交换1的交换号(可空)
交换2
交换2的交换号(可空)
名称
(不可空)
地址
(可空)
邮政编码
(可空)
电报挂号
(可空)
电话
(可空)
联系人
(可空)
交易集号
指向交易集表(可空)
网络结点名
系统进行网络连接的结点名
(可空)
机构类型
网点的类别:
1-联社
2-财务部
3-联社大社
4-联社营业部
5-大社
6-大社营业部
7-分社
8-储蓄所
9-运行中心
0-清算中心
另外增加特殊机构包括:
a_省辖清算中心
b-全国汇兑清算中心
c-凭证印制机构
d-省机关
e-地市机关
f-联社机关
g-授权卡发卡中心
h-代办中心
i-盈余亏损联社
j-地市中心
k-地市清算中心
m-省中心
o-省清算中心
(可空)
业务范围类型
包括:
0-全能机构(当前)
1-对私机构
2-对公机构
缺省为0
(不可空)
机构现金帐号
现金科目帐号(可空)
本年利润帐户
(可空)
机构挂帐帐户
(可空)
开户机构
指储蓄所的开户机构,对其它类型的机构无意义(可空)
机构运作状况
标志1:0—关机、1—营业、2—待扎帐、3—暂退、4—撤消、
5—删除(不可空)
缺省是0
标志2:0-未完成外汇上划
1-已完成外汇上划
标志3:0-未完成协议转存
1-已完成协议转存
标志4:0-无旧折
1-有旧折
标志5:该机构是否允许参加电子汇兑业务
0-不允许参加电子汇兑
1-允许发生大社内的电子汇兑
允许发生联社内的电子汇兑
允许发生地市内的电子汇兑
允许发生区内的电子汇兑
标志6:该机构是否允许参加现代支付业务
不允许参加现代支付(大额)
允许参加现代支付(大额)
标志7:该机构是否允许参加小额支付业务
不允许参加小额支付
允许参加小额支付

其它预留。
(可空)
通兑标志
(不可空)
第一位:该机构是否参加通存通兑。=1时不参加,该机构不能与任何其它机构通存通兑。
第二位:该机构的临时借款是否未超过限额。=1时超过限额,此时任何使该机构的备付金减少的通存通兑交易都不能进行。此标志只对大社和联社大社类型的机构(机构号后两位=0)有意义。
第三位:该机构是否允许大社营业部通存通兑。=1不允许。对于大社分社,该标志=0表示在本机构开户的客户帐的支取方式是印章时,也允许在本机构所在大社的营业部通存通兑。对于大社营业部,此标志恒=0。对于联社分社,联社营业部,大社和联社大社此标志无意义。
第四位:该机构是否允许联社营业部通存通兑。=1不允许。对于大社分社,联社分社和大社营业部,该标志=0表示在本机构开户的客户帐的支取方式是印章时,也允许在联社营业部通存通兑。对于联社营业部,此标志恒=0。对于大社和联社大社(机构号后两位=0)此标志无意义。
联机标志
表示该机构是否存在业务前台,
为0表示不存在
为1表示存在
该标志决定是否进行标准数据下载
叶子标志
not null
0－非叶子机构
1－叶子机构
标志位
(不可空)
第一位:主从标志
0－主结点
1－从结点
最后修改柜员
最后作出修改的柜员(不可空)
最后修改日期
最后修改的日期(不可空)

7. 帐务结构与核算方式
7.1. 帐务组织结构
系统帐务组织结构如图所示:

系统的帐务结构一级总帐、二级总帐、三级总帐(主帐)和各金融产品的分户帐。总帐部分支撑业务的综合核算,各金融产品各自管理相关产品分户帐,实现业务的综合核算。
各级按科目及账户属性分类进行汇总。其中,三级总帐为对二级科目的进一步细分,系统中也称为主帐,经过此账目的设置,实现了几乎所有的报表都从综合核算层的数据库表中获得数据,实现了明细核算和综合核算的相对分离,确保了核算体系的相对稳定。
综合核算中,科目作为重要的汇总关联参数,而明细核算中(也就是各种金融产品中)科目的出现,都经过科目代号进行表述。这样的设置方法,使得当科目发生变化是,对金融产品的影响最小化,特别针对金融产品的各种重要参数表的调整变得更为简单。
科目字典数据要素
要素
说明
科目号
(不可空)由银行指定的会计科目号
科目名称
(不可空)会计科目的名称
科目级别
(可空)科目
1-一级科目
2-二级科目
汇总科目号
(可空)表示在业务状况表上直接汇总科目号如1011汇总到01,
注意:不要取1级汇总科目的汇总科目号,因为没有意义
汇总级别
(可空)表示在业务状况表上的汇总级别
{#-不参加}
{0-一般项}
{1-小计,从一般项合计而来}
{2-大项,可由小记和一般项合计}
{3-总计,可由大项和一般项合计}
{4-大总记,对总计进行合计}
{9-其它项目}
科目位置
(可空)在业务状况表上的位置,数值为页号*1000+行号*10+列号,页号从1开始编号,行号从1开始编号,列号从1开始编号
帐类
(可空)科目类别标志,包括:
1-资产类科目、2-贷款科目、3-负债类科目、4-储蓄存款科目、5-对公存款科目、6-资产负债共同类、7-往来科目、8-所有者权益类、9-损益类、a-表外科目类、+-合计项
科目属性
0- 非特殊科目
1- 存款类的自筹存款科目
2- 存款类的定期存款科目
3- 存款类的通知存款科目
4- 贷款类的无指标贷款科目
5- 贷款类的有财政贴息的科目
6- 销帐类科目
7- 表外科目类的”补充资料”科目
8- 联行往来类的”上年联行往来”科目
9- 投资科目
a- 现金科目
%—其它
(可空)
余额方向
0- 两性、
1- 借、
2- 贷、
3- 借方可红字、
4- 贷方可红字、
5- 借贷双方共同反映
(可空)
主帐是否下设分户
指该科目的主帐是否下设分户,修改交易中应检查是否已下设分户,若已下设分户不能修改成不下设分户
0-不下设多分户
1-下设多分户
(可空)
帐页类型
1-甲类帐
2-乙类帐
3-丙类帐
4-丁类帐
(可空)
帐页打印方式
0-不打印
1-按页打印
2-按月打印
(可空)
最后修改柜员
(不可空)
最后修改日期
(不可空)

科目代号数据要素
要素
说明
科目代号
科目代号
科目号
(不可空)由银行指定的会计科目号
三级科目号

三级科目名称
(不可空)
明细标志
0－不实时登记 1－实时登记
标志

7.2. 数据模型和帐务登记
交易实现上,针对后台的若干业务数据和帐务数据,系统有如下图的数据模型和帐务登记流程。如图所示:

核心系统完成全行帐务实时帐务处理,基于效率和应用实用性考虑,数据需保持在一个可控的规模下,而且面向管理、分析的OLAP应用应该与实时业务系统群在系统及网络层隔离,也即在核心系统外需要建立后续管理分析应用和历史查询运用,其上的大量数据需要经过定时的ETL过程将主机上的数据,选择性的传输到相关应用中。ETL过程可配置实现对主机数据的清理、复制和迁移。
核心系统内部数据模型,也按明细核算和综合核算的功能,划分到核心层和产品层进行管理,不同的金融产品,可灵活设置不同数据库表管理其相应业务。而核心层的总帐数据模型,不因业务的变化而发生变化。实现中,核心层数据与产品层数据经过分录流水作为桥梁,经过标准的数据访问通道关联业务的明细核算和综合核算,在产品层的业务处理中,只操作单一、标准的数据库表,屏蔽了产品业务变化对核心层的影响。具体来看交易过程中的帐务登记流程如下:
日常交易发生时,交易首先登记柜员日志,然后按交易码进入不同的服务处理流程,进行产品层的明细核算,最后登记系统统一的分录流水,记载相应的核算信息。
日终交易处理时,系统从分录流水中获取核算信息,分别登记主机的主帐、二级科目总帐和一级科目总帐,由于系统主帐信息反映了分户的汇总归类,实现上几乎全部的报表都能够依据总帐数据进行生成。同时,基于24小时实现逻辑支撑,在日终过程中,分户信息将不被更改,因此能够经过一级总帐科目与分户的余额对比实现系统的总分检查。
对于系统内部帐而言,当经过内部帐记账交易处理时,系统将实时登记内部帐分户及分户明细;当内部帐记账为其它交易联动完成时,系统根据配置信息,确定内部帐是实时登记还是日终汇总登记。经过汇总登记能够简化内部帐帐页输出;同时还能够提高应用处理效率,规避业务处理瓶颈。
面向核心的分录流水,除了完成日终的综合核算外,也为将来的管理分析应用提供了重要信息来源,因此,分录流水中除了记录核算信息外(机构、币种、科目代码等)还需记录交易的其它属性,包括:客户类型、产品码、部门。并基于上述维度创立面向核算的主帐结构和面向管理的产品总帐结构。核算主帐结构中含核算机构、币种、科目和子目维度;产品总帐结构中含核算机构、币种、科目代码、部门、产品、客户类型维度。将来的分析管理系统能够基于产品总帐数据。
上述维度的取值规则如下:
p 按分录流水中的账号获取核算机构、币种、科目、子目;
p 与客户帐有关的分录,按客户帐的资料和对应关系登记部门、产品和客户类型信息;涉及内部帐有关的分录,其部门、产品和客户类型等信息与客户帐相同;
p 单纯涉及内部帐的交易,其部门、产品和客户类型设为省缺值。三个信息子段的省缺值均为”9999”。

具体数据结构请参考数据字典。

产品总帐数据要素设计
机构号

币种

部门代码

产品代码

科目代号

客户类型

余额方向

××××以下为日交易信息××××
交易日

借方发生额

贷方发生额

借方笔数

贷方笔数

借方余额

贷方余额

当日开户数

当日销户数

××××以下为月交易信息××××
月借方发生额

月贷方发生额

月借方笔数

月贷方笔数

当月平均借方余额

当月平均贷方余额

当月开户数

当月销户数

××××以下为年交易信息××××
年借方发生额

年贷方发生额

年借方笔数

年贷方笔数

当年平均借方余额

当年平均贷方余额

当年开户数

当年销户数

备注:
唯一索引:机构、币种、部门代码、产品代码、科目代号、客户类型

本表采用动户记录和增加记录方式,在日终、月终和年终不会进行轮寻处理
对部分长期未动的记录,可能信息以前数据,因此需要根据交易日期理解日、月、年交易信息

帐务登记的原则是客户帐资料、登记簿、流水等在日间时产生并实时登记、更新。内部帐、主帐、总帐在日终时经过分录流水完成登记、更新。这样做的好处在于提供了交易的并发度支持,特别是将来核算单元上收后,对内部帐、主帐的高并发度要求,避免了这些资源的锁冲突。
处理要求:
p 实时产生分录流水,分录流水中要有交易机构、核算机构、部门、产品码、客户类型、是否日终记内部帐标志。
p 在内部帐分户中要有标志明确说明是否需要记录明细帐;该标志在科目代号字典中能够设置。
p 手工发起的内部帐记帐(0911)实时登记内部帐及明细。
p 对于部分需要进行余额控制的处理,例如:头寸控制等,可经过专门设置余额控制登记簿进行控制。
7.3. 帐号结构
客户号:14位
AAAA BBCCCCCC DD＝机构码(4)+客户种类(2)+顺序号(6)+校验位(2)
其中:
客户类型(2位)= 对象类型(1位)+ 正式临时标志(1位)
对象类型:'0' 对私客户、'1' 对公客户、'2' 金融客户

客户帐号:17位
AAAABBCDDDDDDDDEE=区分码(4)+币种(2)+帐类(1)+顺序号(8)+校验位(2)
内部帐帐号:
AAAABBCDDDDDDDDEEEE=开户机构(4)+币种(2)+帐类(1)＋科目(8)+顺序号(4)
借据＝区分码(4)＋序号(8)＋校验(2)
帐类:‘1’活期、‘2’结算活期、‘3’定期、‘4’贷款、‘5’内部帐、‘6’股金
其中客户帐号包括了活期、定期、结算活期、贷款、一本通

p 区分码
每个机构的区分码在机构网络管理表(t_srm_inst_mgmt)中定义,每个机构对应的区分码设立后不能够进行修改。

7.4. 双边分录
系统中除了表外科目能够使用单边分录外,所有记帐都使用双边分录,达到每笔交易的自平衡。如果存在业务上的交易动作分离情况,将使用系统统一的机构挂帐户进行过渡处理,在进行过渡处理时,系统除了记录该账户的分录,还需记录柜员临时存欠登记簿,登记簿采用销账方式管理。与丁种帐不同之处在于,该账户的销账允许部分销账,解决一借多贷或一贷多借情况,如果存在多借多贷情况,原则上必须自平衡或经过中间临时存欠账户管理,转换为上述两种情况。
7.4.1. 机构挂帐户记账规则
p 采用机构挂帐户进行处理(标准数据中账号为机构码(4)＋币种(2)＋5＋0461000 0)
p 在正常交易情况下,每日账户余额应为0,但在特殊情况下,如:机构网络中断情况,该账户有可能存在余额不为0的情况。
p 为避免虚增对机构挂帐户的发生额,规定对该账户的记账为转账、借贷标志只为借,也即交易时可能的分录为借方蓝字或借方红字。
p 在记录机构挂账户时需要同时进行柜员临时存欠登记簿的登记。
p 柜员在签退时,除了上缴尾箱、进行柜员轧帐外,还需检查柜员临时存欠登记簿,检查柜员有无关联交易未完成。
p 在交易进行抹帐处理时,必须首先检查该交易是否已被核销,若已被核销,首先对核销交易进行抹帐处理,或经过冲正交易完成对交易的调整。
7.4.2. 机构挂帐技术实现
在双边分录处理过程中,最重要的是如何登记柜员临时存欠登记簿,以下进行简单技术说明。
柜员临时存欠登记簿要素设计
日期

机构码

柜员号

柜员流水号

交易码

交易简名

外部账号

账户id

借贷方向

金额

待冲销金额

对方柜员流水号
见备注
冲销标志
0－待冲销交易 1－冲销交易
交易状态
0－正常 1－取消
标志

唯一索引:日期＋柜员流水号
复核索引:日期＋柜员＋交易状态＋冲销标志
每套交易,最少登记两条记录,待冲销交易和冲销交易,一对多和多对一情况按需要增加,多对多情况不支持临时存欠。
日终时,本表快速清理生成新表,对未冲销完成记录进行打印
对方柜员流水号规则:
一对一时,互相登记柜员流水号。
一对多时,在待冲销交易记录中,登记的对方柜员流水号为”total”,冲销交易记录中,登记的为对方流水号
多对一时,在待冲销交易记录中,登记的对方柜员流水号为对方流水号,冲销交易记录中,登记的为”total”

在交易时,如果交易为业务单边分录,根据会计先借后贷规则,业务发生方向为借方时,交易为待冲销;业务发生方向为贷方时,交易为冲销(必须输入待冲销交易柜员流水号)。
记录柜员临时存欠登记簿时,按照对方流水号规则记录相应记录,而且支持部分金额的冲销。
在日终时需要对本表记录进行清理,而且对未完全冲销记录进行打印。
7.5. 流水设置
后台增加一张柜员日志表,因此后台共有4张流水表(柜员日志表、储蓄业务流水表、对公业务流水表、分录流水表)。由柜员日志表为首,统驭其它流水,每一笔进入核心的交易度登记一条柜员日志。

柜员日志表中应包含柜员日志号、交易码、交易类型、交易机构、产品码、交易日期、操作柜员、授权柜员、复核柜员、帐号、对方帐号、交易金额等信息,同时标志位中应有复核标志、冲正标志。
7.6. 交易处理规则

交易类型
前台公共规则
特殊规则
后台公共规则
后台特殊规则
记帐交易
前台不记录日志、不生成前台流水号、不使用前台事务、前台判断机构交易集和柜员交易集。
生成MAC、生成复核编码、柜员流水号根据各个模块交易的实际要求打印或显示
主控交易完成公共检查、授权检查等 。

取消交易采集表、增加柜员日志表、并以柜员日志表来完成复核、抹帐和统计处理。
1、启动后台事务、生成柜员流水号、登记柜员日志表。一笔柜员日志可产生多笔业务流水,一笔业务流水可产生多笔分录流水;
2、明细核算帐务登记原则:分户帐、各种登记簿和流水表等在日间产生并实时登记、更新。
3、综合核算帐务登记原则:日终根据分录流水登记主帐和总帐;完成总分核对
4、手工发起的内部帐记帐(0911)实时登记及明细。
5、丁种帐的处理原则上保持原有方式不变(待定)。
6、交易发起的内部帐计帐原则采用日终汇总产生分录记帐的模式,登记分户和明细。
7、实时产生的分录流水信息中要有交易机构、核算机构,内部帐号和外部帐号等要素。
9、在内部帐分户中要有标志明确说明是否需要记录明细帐;该标志在科目表(产品码和科目子目对应关系描述表)中能够设置。
管理交易
生成MAC、生成复核编码;
1、管理交易启动后台事务、生成柜员流水号、登记柜员日志表;
2、单笔管理交易支持复核机制;
查询交易

查询交易生成柜员流水号、登记柜员日志表

8. 应用实现框架
8.1. 交易开发配置流程
面向金融产品的各类服务(交易),在系统中被封装为