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

1、四川农信综合业务网络系统总体设计说明书四川省农村信用合作社南天电脑系统有限公司2006年 8月总体设计说明书- TOC o 1-3 h z HYPERLINK l _Toc145127772 1.系统网络拓扑 PAGEREF _Toc145127772 h 4 HYPERLINK l _Toc145127773 2.系统逻辑结构 PAGEREF _Toc145127773 h 5 HYPERLINK l _Toc145127774 3.数据流说明 PAGEREF _Toc145127774 h 6 HYPERLINK l _Toc145127775 4.核心系统逻辑架构 PAGEREF _To

2、c145127775 h 7 HYPERLINK l _Toc145127776 5.交易模式 PAGEREF _Toc145127776 h 8 HYPERLINK l _Toc145127777 5.1.通讯方式 PAGEREF _Toc145127777 h 8 HYPERLINK l _Toc145127778 5.2.数据一致性保证 PAGEREF _Toc145127778 h 9 HYPERLINK l _Toc145127779 5.3.复核交易处理 PAGEREF _Toc145127779 h 11 HYPERLINK l _Toc145127780 5.4.抹帐交易处理

3、PAGEREF _Toc145127780 h 12 HYPERLINK l _Toc145127781 5.5.授权交易处理 PAGEREF _Toc145127781 h 13 HYPERLINK l _Toc145127782 6.机构逻辑结构 PAGEREF _Toc145127782 h 16 HYPERLINK l _Toc145127783 6.1.清算机构逻辑 PAGEREF _Toc145127783 h 17 HYPERLINK l _Toc145127784 6.2.机构的设置 PAGEREF _Toc145127784 h 17 HYPERLINK l _Toc1451

4、27785 6.3.机构管理层次 PAGEREF _Toc145127785 h 18 HYPERLINK l _Toc145127786 6.4.机构核算单元上收 PAGEREF _Toc145127786 h 19 HYPERLINK l _Toc145127787 6.5.数据要素设计 PAGEREF _Toc145127787 h 19 HYPERLINK l _Toc145127788 7.帐务结构与核算方式 PAGEREF _Toc145127788 h 22 HYPERLINK l _Toc145127789 7.1.帐务组织结构 PAGEREF _Toc145127789 h

5、22 HYPERLINK l _Toc145127790 7.2.数据模型和帐务登记 PAGEREF _Toc145127790 h 25 HYPERLINK l _Toc145127791 7.3.帐号结构 PAGEREF _Toc145127791 h 30 HYPERLINK l _Toc145127792 7.4.双边分录 PAGEREF _Toc145127792 h 31 HYPERLINK l _Toc145127793 7.5.流水设置 PAGEREF _Toc145127793 h 33 HYPERLINK l _Toc145127794 7.6.交易处理规则 PAGEREF

6、 _Toc145127794 h 33 HYPERLINK l _Toc145127795 8.应用实现框架 PAGEREF _Toc145127795 h 34 HYPERLINK l _Toc145127796 8.1.交易开发配置流程 PAGEREF _Toc145127796 h 34 HYPERLINK l _Toc145127797 8.2.交易服务处理过程 PAGEREF _Toc145127797 h 36 HYPERLINK l _Toc145127798 8.3.应用实现规则 PAGEREF _Toc145127798 h 38 HYPERLINK l _Toc145127

7、799 9.关键实现说明 PAGEREF _Toc145127799 h 44 HYPERLINK l _Toc145127800 9.1.并行处理 PAGEREF _Toc145127800 h 44 HYPERLINK l _Toc145127801 9.2.24小时处理 PAGEREF _Toc145127801 h 47 HYPERLINK l _Toc145127802 9.3.费用处理 PAGEREF _Toc145127802 h 51 HYPERLINK l _Toc145127803 9.4.资金清算 PAGEREF _Toc145127803 h 56 HYPERLINK

8、l _Toc145127804 9.5.数据安全 PAGEREF _Toc145127804 h 62 HYPERLINK l _Toc145127805 10.总体需求说明 PAGEREF _Toc145127805 h 64 HYPERLINK l _Toc145127806 10.1.支持商业规则可配置化和业务逻辑可配置化 PAGEREF _Toc145127806 h 64 HYPERLINK l _Toc145127807 10.2.全面产品管理 PAGEREF _Toc145127807 h 68 HYPERLINK l _Toc145127808 10.3.完整灵活的收费处理 P

9、AGEREF _Toc145127808 h 70 HYPERLINK l _Toc145127809 10.4.批处理控制平台 PAGEREF _Toc145127809 h 70 HYPERLINK l _Toc145127810 10.5.历史数据及管理分析与核心相分离 PAGEREF _Toc145127810 h 71 HYPERLINK l _Toc145127811 10.6.统一的外部系统API PAGEREF _Toc145127811 h 73 HYPERLINK l _Toc145127812 10.7.前台系统先进性要求 PAGEREF _Toc145127812 h

10、73四川农信综合业务网络系统的目标是：结合四川农信具体情况，建立一套以客户为中心、账务核算统一、本外币一体化、业务、网点综合化、事中控制、支持24小时服务、支持全面产品管理、参数化、模块化设计的新一代综合业务系统。为了保证这一目标的达成，结合四川农信的新一代综合业务系统的要求，从底层开始对整个综合业务系统进行了设计和规划。从内容来看，总体设计需要涉及的主题有以下一些方面。系统网络拓扑系统逻辑结构数据流说明核心系统逻辑架构交易模式机构逻辑结构帐务结构与核算方式应用实现框架关键实现说明系统网络拓扑系统网络拓扑如图所示，结构上划分为四层，包括：省中心、地市中心、县中心和网点。省中心：全部业务系统都集

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

12、辑结构系统逻辑结构如图所示：本次项目实施的四川省农信综合业务网络系统（SC6000），包括：后台核心业务系统OFP CoreBanking、中台交换前置和中间业务平台系统OFP PreBranch和前台柜面前端系统OFP AutoBranch。后台核心业务系统CoreBanking：负责完成银行全面帐务管理和基础金融产品，是整个银行的帐务核心，并为银行后续的业务管理和分析提供基础分析数据。基于核心业务系统，传统柜面业务都获得服务支持，并支持以客户为中心、面向产品管理、高度参数化、全面支持24小时不间断服务等一系列新一代综合业务系统的优良特性。中台交换前置和中间业务平台系统OFP PreBanc

13、h：负责完成后台应用间的交换和互联，并基于平台提供的成熟框架，连接系统外第三方应用并支持丰富的中间业务开发。前台柜面前端系统OFP AutoBranch：负责完成所有柜服务的前端展现和处理。采用LINUX操作系统实现。数据流说明如系统逻辑结构图中所示，在交易处理中：当进行银行传统金融业务处理时（包括：活期、定期、贷款、结算等），柜员在前台发起交易，交易请求直接发送到后台核心业务系统中实现业务处理；当进行中间业务和银行扩展金融业务处理时（包括：代收费、大额、小额等），柜员在前台发起交易，交易请求首先到达中台前置系统，由中台系统进行本地业务处理和业务调度，根据需要调用后台核心业务系统和第三方业务系

14、统。基于统一的业务系统接口规范和交换前置的应用处理，在中心后台的两个应用间不允许存在相互间的直接访问，必须通过交换前置系统进行请求的转发。例如：在将来的国际业务系统需要进行业务记账，业务请求首先到达中台交换前置系统，通过中台的应用解析，在将请求逐笔的传递到核心业务系统中实现记账。除了柜面的请求，其他的服务渠道包括：ATM、POS、电话银行、网上银行等的业务交易全部都是首先上到中台交换前置系统，进行本地必要的业务处理，然后在向相应的服务端应用发出调用请求。由于在三个应用平台系统中，核心业务系统是主要业务的处理端和服务端，也是整个系统框架的基础部分与核心部分，因此核心业务系统的设计至关重要，在下面

15、的讨论中，我们也将主要面向核心系统进行阐述，对中台OFP PreBranch和前台OFP AutoBranch请参看相关文档，在此不再赘述。核心系统逻辑架构核心系统在技术逻辑结构上设计如图：逻辑架构上，核心系统分为核心服务层和金融产品层。两个层次相对隔离，通过标准调用接口，实现访问调用。核心服务层包括提供全行的会计核算、客户管理、公共管理功能。稳定、高效，并具备前瞻性的设计，是确保四川农信综合业务系统可持续发展的重要保证。会计核算的其中会计核算实现业务的综合核算功能；客户管理收集全行客户信息，并建立客户与账户全面关联关系；公共管理实现系统公共参数的统一管理，包括：机构管理、柜员管理等。金融产品

16、层设计上采用插件式的思想，新的业务可灵活、容易的“插入”到CoreBanking系统中来。在各金融产品服务中实现业务的明细核算功能。实现上，应用请求首先通过统一的交易分发管理，调用相应的处理服务流程完成服务。金融产品层中，提供的服务大致上包含三个主要的类型：专门的核心调用接口提供给银行内部的其他应用群进行帐务处理调用丰富的金融产品组件提供银行柜面调用，如：活期、定期、贷款等核心层的专用调用组件，提供业务人员直接使用。如：报表管理、客户管理、前后台管理等。交易模式交易模式描述的内容包括交易的通讯方式、数据一直性保证、复核交易的处理、抹帐交易的处理、授权交易处理。通讯方式通讯协议采用TUXEDOF

17、ML。对于柜面交易采用同步短连接方式。系统除了提供交易报文通讯外，还支持交易的文件传输，在文件传输时只允许前台申请上送或下传。当后台需要下发文件时，需在交易报文中带下传输文件名，由前端平台再进行文件传输处理。为了保证系统的正常运行，减轻后台和网络压力，原则上柜台交易通常为一次通讯，有需要时原则上可进行一次查询，应尽量避免多次通讯。在AutoBranch中，在tpinit时把详细的client端信息带到后台，以满足后台的管理要求。同时为了解决对一些前台提醒的通知信息的处理，在AutoBranch中增加通知的公共处理，方式为在柜面前端的固定位置进行提醒。数据一致性保证事务处理系统统一在后端启动事务

18、处理。在交易配置时，是否启动事务为后端SYSMNG配置。配置是否由主控启动事务。配置不由主控启动事务的交易，由应用自行在处理过程中启动事务处理。通常，对于交易类型为记账和管理的交易由主控启动事务；而查询和其他交易，则根据需要自行启动事务。规则上，查询交易无事务，而且需要使用脏读。由PreBranch发起的交易，PreBranch和CoreBanking分别启动事务。在交易过程中还有一种特例，部分处理（如：获取柜员流水号、账号顺序号、授权交易处理等）需要跳出事务处理块执行，此时需要数据库中建立另一个连接，在新连接中启动完成单独动作，然后在回到第一个事务处理块。详细请参见8.3.6. 数据库连接方

19、法。数据的一致性保证不同的逻辑单元间，由于中途存在网络因素，有不同的事务处理，可能存在双方不一致的可能性。分两种情况描述如何处理不一致。在柜台交易处理过程中，会出现因为网络等原因导致的前端交易上送后没有得到确定的成功失败返回（通常是超时退出），如果处理是记账交易，柜员必须查询后台，而且以后台交易的结果为准。为了保证资金的安全，在未能获取后台交易结果前，必须分情况进行处理，当办理的是需要收取客户资金的交易（如存款）则默认为交易成功，并收取客户资金；当办理的是需要支付客户资金的交易（如取款）则默认为交易失败，不支付客户资金。当网络恢复后，柜员查询后台的交易处理结果，根据后台的处理结果采用抹帐、冲正

20、、重做、补登等手段完成后续处理。例如：柜员办理一笔存款交易时出现超时，这时柜员通过查询交易查询后台流水，如果发现该笔交易后台是未成功的，则再次办理一笔存款交易。如果发现是成功的，这申请补打存款凭条、存折（没有该功能时可柜员手工填写）。如果发现是网络不通，则手工填写凭条、存折给客户，等网络通了再处理。当交易是由PreBranch发送后台的交易，则需建立应用间自动冲正机制或自动重发机制，在网络状态不明的情况下，中台自动发起抹帐交易（或重发动作），并返回前端失败。在中台日终时，需要启动PreBranch与CoreBanking的对帐，对帐中数据以PreBranch数据为准进行错帐处理。因此在柜面前端

21、，交易的一致性通过柜员的确认以及业务制度配合保证；在无人值守的后台应用间，交易的一致性通过交易时的自动冲正机制（自动重入）以及日终的交易对帐确保。复核交易处理系统中的复核交易有两种，一种是对某些业务流程中要求的复核交易（如联行中的往帐报单复核交易），这些交易是复核后才完成帐务处理的，属于事中复核，这些交易通常是每种业务单独有自己的复核交易；一种是业务流程中没有复核要求，出于安全考虑而增加的事后复核（如对公的存取款），这些交易的复核使用公共的复核交易。不论是那一种复核，现在都采用后台复核的方式，待复核的数据都存在后台，不再在前端保留电子日志。对于非公共的复核交易，交易模式上与一般交易没有太多差别

22、，这里不再具体说明，下面主要对公共的复核交易进行说明。公共复核交易采用统一的交易入口,流程如下：公共复核交易基于后台柜员日志表（参看后台流水设置），需要公共复核的交易，在正常交易发起时，在后台柜员日志中会插入一条记录，标记为待复核，同时将需要复核的要素拼装成字符串后在后台存放。前台发起公共复核交易时，按照前端输入的查询条件查询待复核流水和每条流水对应的复核要素串一起下传前台，在前台完成复核要素的比对处理，在结束复核交易时将成功复核的流水批量发到后台修改对应柜员日志的复核状态。抹帐交易处理抹帐是指对原交易的取消处理，在业务发起当天，如果发现交易有错，在经过授权的条件下发起抹帐交易，取消原交易。抹

23、帐交易使用统一的交易入口（除个别批量发起的业务，如传票套记帐），以后台柜员日志表中的柜员日志号为索引完成抹帐处理。抹帐采用TRIGGER抹帐方式，其简单操作流程如下：根据交易时，TRIGGER及存储过程登记信息进行抹帐。基本流程为：定义抹帐规则生成TRIGGER和存储过程，执行交易时自动记载交易变化情况抹帐交易根据INSERT和UPDATE操作及特殊处理进行处理抹帐中，对于公共库表和公共处理的抹帐，可编写面向数据库表的业务抹帐程序，由统一抹帐主程序调用，而对应用自身登记的库表，则需要进行程序开发人员自行定义其抹帐规则。TRIGGER抹帐详细使用请参看基于数据库trigger机制的抹帐使用手册.

24、DOC。授权交易处理授权是指某个具有足够操作级别的柜员为另一个未具有相应操作级别的柜员授予操作权限的行为。其中，第一个柜员称为授权柜员，第二个柜员称为被授权柜员。按授权的物理操作模式可分为本地授权、异地授权。本地授权是授权柜员到被授权柜员终端直接进行授权操作。异地授权是授权柜员在本终端进行异地授权交易产生授权码，被授权柜员用授权码确认待授权交易并执行交易。交易的授权判断在后台进行。在授权过程中，当进行异地授权，其交易要素或交易界面在等待异地授权过程中将不得进行修改或变化，而且其授权人所在机构为管理上级，对分社而言，通常是其上级大社。授权人在接到通知后，可调出操作员的交易界面进行察看，授权后，该

25、交易界面的内容应该与授权前的交易界面一致。交易界面的传输内容以文本形式存在，待授权文本文件的文件名规则为“SQ交易码（4）柜员号（6）授权码（8）.txt”。已授权文本文件的文件名规则为“YS交易码（4）柜员号（6）授权码（8）.txt”。通过文件对比检查是否交易为原交易。异地授权信息表设计如下：要素说明授权码机构柜员号交易码交易日期界面文件名授权机构授权柜员授权柜员流水号授权标志0未授权、1已授权标志唯一索引：授权码唯一索引：授权柜员流水号复合索引：机构、交易日期、授权标志申请授权时，产生授权码登记本表，填写界面文件名，相应修改前台及后台待授权文件名。形成通知信息授权时，填写授权机构、柜员、

26、流水号和授权标志，可调阅交易界面文件，授权结束形成通知信息前台接到通知后，进行交易，填写授权编号，对比界面文件。一致后上送后台。本表每日删除。注意前后台授权交易文件的删除。在判断交易是否需要进行授权时，除了公共的判断条件（如：交易本身是否需要进行授权、交易级别和柜员操作级别是否匹配等）外，还有一些授权要素需要交易过程中进行检查，此时需要对这些授权要素进行参数化配置。系统提供统一调用接口进行授权检查。授权要素检查表设计如下：要素说明交易码条件(amt1000 & mm_flag = 1)说明有密码并且金额大于1000时需要授权标志select * from t_srm_desc where 条件

27、; 当sqlcode0时，条件为真，需要授权；当sqlcode100时，条件为假，无需授权；其他为错。对一个交易码，有多个或关系的条件表达式。实现中amt为缓冲池变量。机构逻辑结构针对于四川农信的机构设置及功能,机构的逻辑需要从管理、清算、报表汇总、清算出口等方面分别定义，因此我们必须在机构编码表中将这些逻辑关系描述清楚，并支持以后的灵活管理。实现的方法是将机构编码表中的汇总机构全码定义为上级管理机构全码，然后再增加报表汇总机构全码、对应核算单元机构码、清算机构码。这样就可以把几种逻辑关系描述清楚了。清算机构逻辑从图上可以看出，对于存在地市清算中心的机构，清算级别为4级，而不存在地市清算中心的

28、机构，清算级别为3级，根据成都农信的要求，大多数的县联社，直接上存款项到省清算中心实现清算。不同业务从清算的路径也是相同的，分社与大社之间通过社内往来、大社与联社通过存放联社、联社与地市中心通过存放地市、地市与省通过存放省中心实现清算，根据机构的灵活设置，清算层级和清算的关系也可实现灵活动态调整。机构的设置机构名职责及权限省联社管理中心负责全省各机构的维护（增加、删除、修改）工作；负责各级管理中心、省联社清算中心的柜员的维护工作；负责系统标准库的管理和维护工作；全省业务数据的查询及报表打印。银行卡部（省制卡中心）管理全省卡账户，负责与银联外联、对帐等。省联社清算中心负责全省信用社的资金往来和清

29、算、资金调剂、资金划拨及农村信用社重要空白凭证的管理。清算中心不对外办理存贷款业务。省联社机关省联社机关各部门帐务核算。(地市)办事处管理中心分类查询及打印辖内的各种报表，在省联社授权范围内开展相关系统管理工作。(地市)办事处机关（有帐）办事处机关帐务核算。县联社的管理中心负责县联社清算中心、机关各职能部门、营业部及辖内营业网点各柜员的管理和维护。县联社清算中心负责辖内信用社资金往来和清算、资金调剂、资金划拨及现金管理以及重要空白凭证的管理。清算中心不对外办理存贷款业务。县联社机关县联社机关帐务核算。联社、社营业部（室）办理银监局授权范围内的一切对外业务分社办理银监局授权范围内的一切对外业务。

30、机构管理层次机构管理层次如图所示：机构核算单元上收系统支持核算单元一本帐设计管理，可灵活定义核算机构层次，作为核算单元的机构不再为下属网点机构单独设立总帐，从而形成在本级机构内的一本帐管理。核算单元一本帐设计对实现扁平化管理、提高效率和资金利用率、规避金融风险、增强竞争能力等方面具有重大作用。核算单元层次的设定取决于银行的法人治理结构以及内部组织和管理的能力，实际过程中可以采用逐步上收核算单元的方法，最终实现全行一本帐。数据要素设计综上所述，机构的数据要素按如下进行设计要素说明机构号机构全码汇总机构全码核算单元机构码清算上级机构码区分码IP地址端口号全国特约汇兑号(可空)全国联行号(可空)省辖

31、联行号(可空)县辖联行号(可空)县辖联行号(可空)社内往来(可空)交换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-

32、省清算中心(可空)业务范围类型包括：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：

33、该机构是否允许参加现代支付业务不允许参加现代支付（大额）允许参加现代支付（大额）标志7：该机构是否允许参加小额支付业务不允许参加小额支付允许参加小额支付其他预留。(可空) 通兑标志(不可空)第一位：该机构是否参加通存通兑。=1时不参加，该机构不能与任何其他机构通存通兑。第二位：该机构的临时借款是否未超过限额。=1时超过限额，此时任何使该机构的备付金减少的通存通兑交易都不能进行。此标志只对大社和联社大社类型的机构(机构号后两位=0)有意义。第三位：该机构是否允许大社营业部通存通兑。=1不允许。对于大社分社，该标志=0表示在本机构开户的客户帐的支取方式是印章时，也允许在本机构所在大社的营业部通存通

34、兑。对于大社营业部，此标志恒=0。对于联社分社，联社营业部，大社和联社大社此标志无意义。第四位：该机构是否允许联社营业部通存通兑。=1不允许。对于大社分社，联社分社和大社营业部，该标志=0表示在本机构开户的客户帐的支取方式是印章时，也允许在联社营业部通存通兑。对于联社营业部，此标志恒=0。对于大社和联社大社(机构号后两位=0)此标志无意义。联机标志表示该机构是否存在业务前台,为0表示不存在为1表示存在该标志决定是否进行标准数据下载叶子标志not null0非叶子机构1叶子机构标志位(不可空)第一位：主从标志0主结点1从结点最后修改柜员最后作出修改的柜员(不可空)最后修改日期最后修改的日期(不可

35、空)帐务结构与核算方式帐务组织结构系统帐务组织结构如图所示：系统的帐务结构一级总帐、二级总帐、三级总帐（主帐）和各金融产品的分户帐。总帐部分支撑业务的综合核算，各金融产品各自管理相关产品分户帐，实现业务的综合核算。各级按科目及账户属性分类进行汇总。其中，三级总帐为对二级科目的进一步细分，系统中也称为主帐，通过此账目的设置，实现了几乎所有的报表都从综合核算层的数据库表中获得数据，实现了明细核算和综合核算的相对分离，确保了核算体系的相对稳定。综合核算中，科目作为重要的汇总关联参数，而明细核算中（也就是各种金融产品中）科目的出现，都通过科目代号进行表述。这样的设置方法，使得当科目发生变化是，对金融产

36、品的影响最小化，特别针对金融产品的各种重要参数表的调整变得更为简单。科目字典数据要素要素说明科目号(不可空)由银行指定的会计科目号科目名称(不可空)会计科目的名称科目级别(可空)科目1-一级科目2-二级科目汇总科目号(可空)表示在业务状况表上直接汇总科目号如1011汇总到01，注意：不要取1级汇总科目的汇总科目号，因为没有意义汇总级别(可空)表示在业务状况表上的汇总级别#-不参加0-一般项1-小计，从一般项合计而来2-大项，可由小记和一般项合计3-总计，可由大项和一般项合计4-大总记，对总计进行合计9-其他项目科目位置(可空)在业务状况表上的位置，数值为页号*1000+行号*10+列号,页号从

37、1开始编号,行号从1开始编号,列号从1开始编号帐类(可空)科目类别标志，包括：1-资产类科目、2-贷款科目、3-负债类科目、4-储蓄存款科目、5-对公存款科目、6-资产负债共同类、7-往来科目、8-所有者权益类、9-损益类、a-表外科目类、+-合计项科目属性非特殊科目存款类的自筹存款科目存款类的定期存款科目存款类的通知存款科目贷款类的无指标贷款科目贷款类的有财政贴息的科目销帐类科目表外科目类的“补充资料”科目联行往来类的“上年联行往来”科目投资科目a- 现金科目%其他(可空)余额方向两性、借、贷、借方可红字、贷方可红字、借贷双方共同反映(可空)主帐是否下设分户指该科目的主帐是否下设分户，修改交

38、易中应检查是否已下设分户，若已下设分户不能修改成不下设分户0-不下设多分户1-下设多分户(可空)帐页类型1-甲类帐2-乙类帐3-丙类帐4-丁类帐(可空)帐页打印方式0-不打印1-按页打印2-按月打印(可空)最后修改柜员(不可空)最后修改日期(不可空)科目代号数据要素要素说明科目代号科目代号科目号(不可空)由银行指定的会计科目号三级科目号三级科目名称(不可空)明细标志0不实时登记 1实时登记标志数据模型和帐务登记交易实现上，针对后台的若干业务数据和帐务数据，系统有如下图的数据模型和帐务登记流程。如图所示：核心系统完成全行帐务实时帐务处理，基于效率和应用实用性考虑，数据需保持在一个可控的规模下，并

39、且面向管理、分析的OLAP应用应该与实时业务系统群在系统及网络层隔离，也即在核心系统外需要建立后续管理分析应用和历史查询运用，其上的大量数据需要通过定时的ETL过程将主机上的数据，选择性的传输到相关应用中。ETL过程可配置实现对主机数据的清理、复制和迁移。核心系统内部数据模型，也按明细核算和综合核算的功能，划分到核心层和产品层进行管理，不同的金融产品，可灵活设置不同数据库表管理其相应业务。而核心层的总帐数据模型，不因业务的变化而发生变化。实现中，核心层数据与产品层数据通过分录流水作为桥梁，通过标准的数据访问通道关联业务的明细核算和综合核算，在产品层的业务处理中，只操作单一、标准的数据库表，屏蔽

40、了产品业务变化对核心层的影响。具体来看交易过程中的帐务登记流程如下：日常交易发生时，交易首先登记柜员日志，然后按交易码进入不同的服务处理流程，进行产品层的明细核算，最后登记系统统一的分录流水，记载相应的核算信息。日终交易处理时，系统从分录流水中获取核算信息，分别登记主机的主帐、二级科目总帐和一级科目总帐，由于系统主帐信息反映了分户的汇总归类，实现上几乎全部的报表都可以依据总帐数据进行生成。同时，基于24小时实现逻辑支撑，在日终过程中，分户信息将不被更改，因此可以通过一级总帐科目与分户的余额对比实现系统的总分检查。对于系统内部帐而言，当通过内部帐记账交易处理时，系统将实时登记内部帐分户及分户明细

41、；当内部帐记账为其他交易联动完成时，系统根据配置信息，确定内部帐是实时登记还是日终汇总登记。通过汇总登记可以简化内部帐帐页输出；同时还可以提高应用处理效率，规避业务处理瓶颈。面向核心的分录流水，除了完成日终的综合核算外，也为将来的管理分析应用提供了重要信息来源，因此，分录流水中除了记录核算信息外（机构、币种、科目代码等）还需记录交易的其他属性，包括：客户类型、产品码、部门。并基于上述维度创立面向核算的主帐结构和面向管理的产品总帐结构。核算主帐结构中含核算机构、币种、科目和子目维度；产品总帐结构中含核算机构、币种、科目代码、部门、产品、客户类型维度。将来的分析管理系统可以基于产品总帐数据。上述维

42、度的取值规则如下：按分录流水中的账号获取核算机构、币种、科目、子目；与客户帐有关的分录，按客户帐的资料和对应关系登记部门、产品和客户类型信息；涉及内部帐有关的分录，其部门、产品和客户类型等信息与客户帐相同；单纯涉及内部帐的交易，其部门、产品和客户类型设为省缺值。三个信息子段的省缺值均为“9999”。具体数据结构请参考数据字典。产品总帐数据要素设计机构号币种部门代码产品代码科目代号客户类型余额方向以下为日交易信息交易日借方发生额贷方发生额借方笔数贷方笔数借方余额贷方余额当日开户数当日销户数以下为月交易信息月借方发生额月贷方发生额月借方笔数月贷方笔数当月平均借方余额当月平均贷方余额当月开户数当月销

43、户数以下为年交易信息年借方发生额年贷方发生额年借方笔数年贷方笔数当年平均借方余额当年平均贷方余额当年开户数当年销户数备注：唯一索引：机构、币种、部门代码、产品代码、科目代号、客户类型本表采用动户记录和增加记录方式，在日终、月终和年终不会进行轮寻处理对部分长期未动的记录，可能信息以前数据，因此需要根据交易日期理解日、月、年交易信息帐务登记的原则是客户帐资料、登记簿、流水等在日间时产生并实时登记、更新。内部帐、主帐、总帐在日终时通过分录流水完成登记、更新。这样做的好处在于提供了交易的并发度支持，特别是将来核算单元上收后，对内部帐、主帐的高并发度要求，避免了这些资源的锁冲突。处理要求：实时产生分录流

44、水，分录流水中要有交易机构、核算机构、部门、产品码、客户类型、是否日终记内部帐标志。在内部帐分户中要有标志明确说明是否需要记录明细帐；该标志在科目代号字典中可以设置。手工发起的内部帐记帐（0911）实时登记内部帐及明细。对于部分需要进行余额控制的处理，例如：头寸控制等，可通过专门设置余额控制登记簿进行控制。帐号结构客户号：14位AAAA BBCCCCCC DD机构码(4)+客户种类(2)+顺序号(6)+校验位(2)其中：客户类型（2位）= 对象类型（1位）+ 正式临时标志（1位）对象类型：0 对私客户、1 对公客户、2 金融客户客户帐号：17位 AAAABBCDDDDDDDDEE=区分码(4)

45、+币种(2)+帐类(1)+顺序号(8)+校验位(2)内部帐帐号：AAAABBCDDDDDDDDEEEE=开户机构(4)+币种(2)+帐类（1）科目(8)+顺序号(4)借据区分码（4）序号（8）校验（2）帐类：1活期、2结算活期、3定期、4贷款、5内部帐、6股金其中客户帐号包括了活期、定期、结算活期、贷款、一本通区分码每个机构的区分码在机构网络管理表（t_srm_inst_mgmt）中定义，每个机构对应的区分码设立后不可以进行修改。双边分录系统中除了表外科目可以使用单边分录外，所有记帐都使用双边分录，达到每笔交易的自平衡。如果存在业务上的交易动作分离情况，将使用系统统一的机构挂帐户进行过渡处理，

46、在进行过渡处理时，系统除了记录该账户的分录，还需记录柜员临时存欠登记簿，登记簿采用销账方式管理。与丁种帐不同之处在于，该账户的销账允许部分销账，解决一借多贷或一贷多借情况，如果存在多借多贷情况，原则上必须自平衡或通过中间临时存欠账户管理，转换为上述两种情况。机构挂帐户记账规则采用机构挂帐户进行处理（标准数据中账号为机构码（4）币种（2）5046100020000）在正常交易情况下，每日账户余额应为0，但在特殊情况下，如：机构网络中断情况，该账户有可能存在余额不为0的情况。为避免虚增对机构挂帐户的发生额，规定对该账户的记账为转账、借贷标志只为借，也即交易时可能的分录为借方蓝字或借方红字。在记录机

47、构挂账户时需要同时进行柜员临时存欠登记簿的登记。柜员在签退时，除了上缴尾箱、进行柜员轧帐外，还需检查柜员临时存欠登记簿，检查柜员有无关联交易未完成。在交易进行抹帐处理时，必须首先检查该交易是否已被核销，若已被核销，首先对核销交易进行抹帐处理，或通过冲正交易完成对交易的调整。机构挂帐技术实现在双边分录处理过程中，最重要的是如何登记柜员临时存欠登记簿，以下进行简单技术说明。柜员临时存欠登记簿要素设计日期机构码柜员号柜员流水号交易码交易简名外部账号账户id借贷方向金额待冲销金额对方柜员流水号见备注冲销标志0待冲销交易 1冲销交易交易状态0正常 1取消标志唯一索引：日期柜员流水号复核索引：日期柜员交易

48、状态冲销标志每套交易，最少登记两条记录，待冲销交易和冲销交易，一对多和多对一情况按需要增加，多对多情况不支持临时存欠。日终时，本表快速清理生成新表，对未冲销完成记录进行打印对方柜员流水号规则：一对一时，互相登记柜员流水号。一对多时，在待冲销交易记录中，登记的对方柜员流水号为“total”，冲销交易记录中，登记的为对方流水号多对一时，在待冲销交易记录中，登记的对方柜员流水号为对方流水号，冲销交易记录中，登记的为“total”在交易时，如果交易为业务单边分录，根据会计先借后贷规则，业务发生方向为借方时，交易为待冲销；业务发生方向为贷方时，交易为冲销（必须输入待冲销交易柜员流水号）。记录柜员临时存欠

49、登记簿时，按照对方流水号规则记录相应记录，而且支持部分金额的冲销。在日终时需要对本表记录进行清理，并且对未完全冲销记录进行打印。流水设置后台增加一张柜员日志表，因此后台共有4张流水表（柜员日志表、储蓄业务流水表、对公业务流水表、分录流水表）。由柜员日志表为首，统驭其它流水，每一笔进入核心的交易度登记一条柜员日志。柜员日志表中应包含柜员日志号、交易码、交易类型、交易机构、产品码、交易日期、操作柜员、授权柜员、复核柜员、帐号、对方帐号、交易金额等信息，同时标志位中应有复核标志、冲正标志。交易处理规则交易类型前台公共规则特殊规则后台公共规则后台特殊规则记帐交易前台不记录日志、不生成前台流水号、不使用

50、前台事务、前台判断机构交易集和柜员交易集。生成MAC、生成复核编码、柜员流水号根据各个模块交易的实际要求打印或显示主控交易完成公共检查、授权检查等 。取消交易采集表、增加柜员日志表、并以柜员日志表来完成复核、抹帐和统计处理。1、启动后台事务、生成柜员流水号、登记柜员日志表。一笔柜员日志可产生多笔业务流水，一笔业务流水可产生多笔分录流水；2、明细核算帐务登记原则：分户帐、各种登记簿和流水表等在日间产生并实时登记、更新。3、综合核算帐务登记原则：日终根据分录流水登记主帐和总帐；完成总分核对4、手工发起的内部帐记帐（0911）实时登记及明细。5、丁种帐的处理原则上保持原有方式不变（待定）。6、交易发

51、起的内部帐计帐原则采用日终汇总产生分录记帐的模式，登记分户和明细。7、实时产生的分录流水信息中要有交易机构、核算机构，内部帐号和外部帐号等要素。9、在内部帐分户中要有标志明确说明是否需要记录明细帐；该标志在科目表（产品码和科目子目对应关系描述表）中可以设置。管理交易生成MAC、生成复核编码；1、管理交易启动后台事务、生成柜员流水号、登记柜员日志表；2、单笔管理交易支持复核机制；查询交易查询交易生成柜员流水号、登记柜员日志表应用实现框架交易开发配置流程面向金融产品的各类服务（交易），在系统中被封装为了应用服务（APSERVICE），同类业务的APSERICE又被封装称为了应用服务器。实现上，所有

52、的交易对TUXEDO而言都是一个SERVICE，SERVICE的别名设置为交易码，统一的交易服务名为“STDSVC”,交易请求到后台后，通过统一的交易分发管理进入不同的交易流程，进行业务处理。一个前台交易的开发配置过程，分三个部分进行工作：在前端AutoBranch进行必要的开发配置，最后配置交易上传报文，并编译缓冲池。进行SYSMNG配置开发，在管理配置完成服务、原子交易和交易后，从前台通过工具获取前台缓冲池，添加入后台需要的缓冲池内容，完成全部编译。新填写的变量注意顺序号在前台变量之后，这样编译结果不会与前台有冲突。全部配置完成后，生成服务的头文件、MAKEFILE文件。在SYSMNG中还

53、统一控制着交易服务主程序。进行具体交易服务开发时，首先从开发定制平台（SYSMNG）中获取服务主程序、头文件、MAKEFILE文件。然后进行新原子交易代码编写，最后根据MAKEFILE进行交易服务的编译。至此，交易服务开发完成。在核心服务中，有下列的交易服务：SERVER名称内容描述SERVER类型01普通活期处理包括2011和 2111在内的(存折) 活期开销户、存取款、帐户维护、查询等功能、主要有对一般存折活期和一本通活期的处理（多币种）。金融产品02结算活期处理包括2011和2111在内的结算帐户开销户、存取款、帐户维护、查询等功能金融产品03定期处理单位或者个人定期的开销户、存取款、帐

54、户维护、查询等功能，包括单位定期、一般存单定期和一本通定期的处理金融产品04信贷处理贷款和房屋按揭的业务。金融产品05批量提供网点/中心代收代发和相关的管理功能金融产品06同城处理包括佛山交换和广州交换两种类型金融产品07联行面向联行明细和联行报单进行处理。金融产品08结算处理人行规定的结算业务，包括汇兑、汇票、支票、本票及委托收款等金融产品09内部帐内部帐的开销户处理，帐户维护，综合记帐及查询打印等功能金融产品10总帐总帐和主帐的管理、维护功能核心服务之会计核心11清算完成辖内清算的处理金融产品12前台管理凭证管理和对网点的管理维护功能核心服务之公共管理13后台管理1提供对整个业务系统运行参

55、数、运行状态的管理核心服务之公共管理14后台管理2批量、日终、年终、结息核心服务之公共管理15后台管理3对报表进行处理核心服务之公共管理16出纳库存管理，尾箱管理，包括现金的收付、伪钞登记等金融产品17外汇买卖处理外汇买卖和外汇上划的业务金融产品18客户服务包括客户管理、客户资料维护等功能核心服务之客户管理交易服务处理过程具体描述核心系统CoreBanking的交易服务处理过程，可以用下面的逻辑图简单表示一个应用服务器接到交易请求后的处理过程。系统内部广泛采用可Tuxedo缓冲池技术FML，包括前后台数据传输和交易内部不同原子交易之间。交易从前台将数据传输给了后台后，首先进行应用初始化处理，然

56、后通过交易分发器按SERVICE的唯一标识（交易码）查出原子交易执行序列，逐一执行。执行过程中发生错误中断时，跳出执行序列，填写必要的交易状态标志，返回前台。考虑系统将来可能复杂度，系统中对每个交易可定义三个处理序列，通过全局变量交易状态选择不同的处理序列进行交易过程处理。应用实现规则库使用规则系统将程序库函数划分了不同的级别和类型，以下逐一进行说明。系统库指操作系统或专业软件所提供的标准库函数。如：数学库等。底层库由项目开发人员完成，与具体应用无关的函数库，包括：加密库、屏幕处理、时间处理、字符处理等。如：BASE库、ENC库等中间库有一定金融应用逻辑，但与具体金融产品无关的函数库，包括：D

57、AC处理，2月处理、到期处理、计息处理等。如：MUD库、DAC库等核心应用库含丰富的金融应用，是某产品或核心层提供给其他产品服务的业务应用调用库，包括：活期存款、内部帐开户、核心记账等，如：SHAREAPP库。日志规则系统中除了操作系统、数据库和中间件提供的日志外，应用还有三类日志。错误信息日志errlog系统应用程序错误时，要求必须调用错误信息日志，记录信息包括系统错误、TUXEDO错误、INFORMIX错误和应用错误，在错误信息接口中将记录错误的交易码、柜员、错误编号、简要解释、错误文件和错误行数。每次记录的内容为一行。大多数的程序中将上述错误简单包装成文四个函数，SYSERR、TUXER

58、R、SQLERR、APPERR。错误信息日志的内容记录在$WORKDIR/log目录下。文件名采用：log柜员号前两位(2)/柜员号前四位(4)/errlog.柜员号(6)如：柜员010203的errlog文件名为：$WORKDIR/log/log01/0102/errlog.010203交易日志runlog应用中也可根据程序需要随时书写交易日志runlog，日志函数名为CBSLog。通常在程序出现错误时，既要求书写errlog，又要求写runlog。每次记录的内容为一行。交易日志的内容记录在$WORKDIR/log目录下。log柜员号前两位(2)/柜员号前四位(4)/runlog.柜员号(6

59、)如：柜员010203的runlog文件名为：$WORKDIR/log/log01/0102/runlog.010203在runlog的记载中，需要按日志级别进行记载，日志级别定义在环境变量中LOGLEV，0为最低级别，记载时，按大于LOGLEV的日志进行记载。通常调试内容定义为0，过程日志内容定义为5，错误日志内容定义为9。报文日志pkg.log交易中的通讯数据系统在服务主程序自动记录在报文日志中。报文日志的内容记录在$WORKDIR/log目录下。文件名采用pkg.log应用服务编号(2)，如：pkg.log02并行日志并行处理的程序是单独的运行程序，由交易服务程序调用。并行处理程序包括并

60、行控制程序和具体的服务程序两部分。程序中记录日志需遵循以下规则。并行日志所有日志记录在$WORKDIR/log目录下。按并行任务分子目录，每个任务内按机构码的头两位分二级目录，再在目录下记录机构并行处理的日志。并行任务总日志文件名为：任务编号(8)/任务编号(8).log，如：$WORKDIR/log/62630001/62630001.log并发处理机构日志文件名为：任务编号(8)/机构码前两位(2)/机构码(4).log，如：$WORKDIR/log/62630001/10/1011.log任务编号的规则为：交易码（4）子任务编号（4）。传输打印文件规则在系统中大量的打印文件或其他资料需要