银行核心业务系统总体设计说明书Word下载.doc
《银行核心业务系统总体设计说明书Word下载.doc》由会员分享，可在线阅读，更多相关《银行核心业务系统总体设计说明书Word下载.doc（76页珍藏版）》请在冰豆网上搜索。
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
-75-
四川农信综合业务网络系统的目标是：
结合四川农信具体情况，建立一套以客户为中心、账务核算统一、本外币一体化、业务、网点综合化、事中控制、支持24小时服务、支持全面产品管理、参数化、模块化设计的新一代综合业务系统。
为了保证这一目标的达成，结合四川农信的新一代综合业务系统的要求，从底层开始对整个综合业务系统进行了设计和规划。
从内容来看，总体设计需要涉及的主题有以下一些方面。
n系统网络拓扑
n系统逻辑结构
n数据流说明
n核心系统逻辑架构
n交易模式
n机构逻辑结构
n帐务结构与核算方式
n应用实现框架
n关键实现说明
1.系统网络拓扑
系统网络拓扑如图所示，结构上划分为四层，包括：
省中心、地市中心、县中心和网点。
省中心：
全部业务系统都集中运行于省中心，包括：
核心业务系统、综合前置系统等。
关键应用参用数据库服务器与应用服务器分离的做法，并且双机互为备份。
存储采用专业存储设备进行高速存储。
在中心局域网上还有管理和监控前端等。
地市中心：
四川省农信地市中心可能存在两种情况，一种是地市中心存在统一管理功能，此类地市中心在地市有统一的管理监控前端；
另一种地市中心仅有网络汇集的功能。
县中心：
具备县联社的统一管理功能；
也是县内网络到地市或到省中心的网络汇集点；
同时，全县的网络前端服务器集中于此。
网点：
是对外直接服务的窗口，所有的网点终端通过远程网络连接的方式连接到县中心前端服务器进行业务处理，在将来一些自助服务设备也会在网络直接连接。
2.系统逻辑结构
系统逻辑结构如图所示：
本次项目实施的四川省农信综合业务网络系统（SC6000），包括：
后台核心业务系统OFPCoreBanking、中台交换前置和中间业务平台系统OFPPreBranch和前台柜面前端系统OFPAutoBranch。
后台核心业务系统CoreBanking：
负责完成银行全面帐务管理和基础金融产品，是整个银行的帐务核心，并为银行后续的业务管理和分析提供基础分析数据。
基于核心业务系统，传统柜面业务都获得服务支持，并支持以客户为中心、面向产品管理、高度参数化、全面支持24小时不间断服务等一系列新一代综合业务系统的优良特性。
中台交换前置和中间业务平台系统OFPPreBanch：
负责完成后台应用间的交换和互联，并基于平台提供的成熟框架，连接系统外第三方应用并支持丰富的中间业务开发。
前台柜面前端系统OFPAutoBranch：
负责完成所有柜服务的前端展现和处理。
采用LINUX操作系统实现。
3.数据流说明
如系统逻辑结构图中所示，在交易处理中：
当进行银行传统金融业务处理时（包括：
活期、定期、贷款、结算等），柜员在前台发起交易，交易请求直接发送到后台核心业务系统中实现业务处理；
当进行中间业务和银行扩展金融业务处理时（包括：
代收费、大额、小额等），柜员在前台发起交易，交易请求首先到达中台前置系统，由中台系统进行本地业务处理和业务调度，根据需要调用后台核心业务系统和第三方业务系统。
基于统一的业务系统接口规范和交换前置的应用处理，在中心后台的两个应用间不允许存在相互间的直接访问，必须通过交换前置系统进行请求的转发。
例如：
在将来的国际业务系统需要进行业务记账，业务请求首先到达中台交换前置系统，通过中台的应用解析，在将请求逐笔的传递到核心业务系统中实现记账。
除了柜面的请求，其他的服务渠道包括：
ATM、POS、电话银行、网上银行等的业务交易全部都是首先上到中台交换前置系统，进行本地必要的业务处理，然后在向相应的服务端应用发出调用请求。
由于在三个应用平台系统中，核心业务系统是主要业务的处理端和服务端，也是整个系统框架的基础部分与核心部分，因此核心业务系统的设计至关重要，在下面的讨论中，我们也将主要面向核心系统进行阐述，对中台OFPPreBranch和前台OFPAutoBranch请参看相关文档，在此不再赘述。
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抹帐方式，其简单操作流程如下：
升级会员 