银行核心业务系统总体设计毕业论文.doc

核心系统项目文档总体设计银行核心业务系统总体设计毕业论文1 综述在全面覆盖传统银行业务的基础上，突出“金融产品”概念，银行可方便定制新的业务品种或更改业务模式；系统整合了银行的业务服务渠道，方便银行增值服务范围的扩展，在无须更改系统内核的情况下方便实现与外部系统的互联互通。系统在深化“大集中”、“大会计”、“一本帐”、“以客户为中心”、“综合柜员制”等成熟的设计思想的基础上，建立了从“客户”、“产品”到“服务”、“渠道”的集约化经营管理模式，提供了真正的面向客户的服务模式，作到了为客户定制差别化的服务。从而实现了银行集中经营、规范业务、个性服务、丰富渠道、减少风险、辅助决策、降低成本的目标。系统实现原则满足了银行业务系统所要求的：先进性、实时性、可靠性、完整性、安全性、网络化、开放性、易扩展性、易维护性、易移植性。2 系统总体结构2.1 系统运行环境l 主机/操作系统HP UNIX 或 IBM-RS6000 AIXl 前置机/操作系统HP UNIX 或IBM-RS6000 AIXl 数据库INFORMIX 或DB2l 中间件CICS 或TUXIDOl 网点前台PC SCOUNIXl 应用数据维护服务器PC SERVER Windows2000/XP TOMCAT（或WEBSPHERE）通过IE登录访问2.2 系统网络总体架构2.3 应用逻辑结构应用系统逻辑结构3 核心系统技术结构4 综合前置系统构架5 系统设计总体目标5.1 技术设计思想5.1.1 三层结构，从面向交易过渡到面向客户、面向服务系统设计分为三层结构：核心管理层、应用服务层和服务渠道层。核心管理层是整个系统的数据中心，存放着客户信息数据、总帐会计数据、公用信息数据，控制信息数据等，负责会计核算、客户信息管理、授信额度管理、资金清算管理、费率管理、机构管理、库房管理和公共数据管理等；应用服务层由存款系统、贷款系统、结算系统、卡业务系统、中间业务系统、资金市场系统、外汇市场系统等应用系统组成，分别完成银行对客户的各种不同服务手段；通过多渠道接入平台系统连接着各种各样的服务渠道，包括柜员界面、客户经理界面、ATM、POS、电话银行界面、自助银行界面、网络银行界面等，是核心业务系统的客户界面，是银行柜台业务的延伸。这样的层次结构划分，可以使得系统的数据更加集中、更加安全，使系统的核心尽可能的坚固和稳定；可以使得系统对客户的应用服务更加具有可拓展性，满足市场快速变化和银行因应增加服务品种的需要；可以使得系统支持的服务渠道更加广泛；从而达到由以前的面向交易过渡到现在的面向客户、面向服务的目标。5.1.2 全面贯彻以客户为中心的设计思想建立具有深度和广度的关系型客户信息中心，降低银行的客户风险；为实现更高级的客户管理方式（如客户信用等级制度的建立），为实现客户分析提供了全面基础信息。采用面向客户提供差别化服务的设计思想，根据来自客户经理的分析资料及时地给操作人员以客户关怀提示或风险预警；根据管理分析系统提供的客户等级评定接口、根据产品定价系统提供的客户优惠价格接口在核心系统中提供个性化服务及控制。5.1.3 多渠道接入平台系统的采用系统采用了多渠道接入平台VisionBanking MCP来完成各种终端设备（字符终端、图形终端）和自助服务设备（ATM、POS、电话银行、手机银行、自助银行、网络银行等）的接入、管理功能。系统能够支持各种通信协议，提供全辖的网络监控、设备控管和应用监控，能处理各种各样的数据报文格式，具有强大的功能扩展性、严格的安全控制机制。5.1.4 银行服务形式“产品化”及产品定制在核心业务系统的设计中，引入了“银行产品”的概念。银行所提供的服务是以产品的形式出现的，系统中把所有经办的存款、贷款等业务根据业务的属性、业务的主要组成要素按照业务流程的不同阶段分层次制定相应的处理计划，根据各处理计划的不同组合灵活地定制产品，并分配相应的产品代码进行唯一的标识。银行业务“产品化”的优点在于让最终用户（而非IT人员）更灵活地根据市场需求定制有自身特色的银行产品，满足不同客户群体的需要，快速适应市场的变化。5.1.5 服务模块组织“构件化”、“构件封装”及构件驱动平台核心业务系统对交易服务的设计基于“构件化”的模式，本着“降低耦合”“功能内聚”的原则，将业务处理功能划分为完成某一具体功能的最小单元，形成“积木”式构件库，这些构件可以以一定形式按照要求搭建在一起形成完成某一业务功能的“组件”，每项交易服务均由“构件”及“组件”依据一定次序的集合组成，完成一项交易服务对构件的组装过程称为“交易封装”，这些组装过程是由填制配置脚本来实现的，而无需单独编程。已经封装的交易服务通过系统提供的“构件驱动平台”统一驱动。提高业务处理程序（构件）的共享；可以灵活地进行构件的组织而定制出新的交易服务，缩短了新服务功能推出的时间；减少了系统维护的工作量。5.1.6 “引领式”操作模式、流程定制及流程再造系统可以通过前台的操作流程定制，实现“引领式”的操作模式。对核心业务系统联机交易操作的过程细分为具体的单一步骤，为每个步骤用一个唯一的步骤编号进行标识，其中每个步骤都包括其独立的必须的输入输出项目，柜员交易就是通过将步骤编号按照一定顺序有条件地组织在一起而形成，而组装的过程只需要简单地配置相应的脚本，不需要编写代码，这样，根据不同的业务要求，可以灵活地对操作流程进行重组，以实现流程的定制和再造。同时，由于每个操作步骤本身的产生都是通过工具定制的方式，对于新的原来没有的操作描述也可以方便地扩充。这种流程定制的方式使前端交易体现出人性化的特色，能够方便地制定出符合操作人员习惯的流程及界面风格，临柜人员的操作可以不再是呆板的录入、提交产生结果，而是通过人机交互的模式引导操作人员逐步达到完成交易服务的目的。5.1.7 批处理控制平台，增强批处理的并发程度，缩短批处理的时间系统将批处理业务（例如：日终批处理、批量结息、预提利息、年终结转等）分成若干个处理模块，每个处理模块都以作业方式运行；相同功能的作业放入同一个队列中，队列内顺序执行；不同功能的作业放入另外的队列中，不同的队列之间是并行执行的，互不影响。由批处理控制平台来完成作业的提交和作业执行顺序的控制，作业之间的制约关系也可在平台中进行预先的定义。这样安排批处理业务，有效地增强了批处理的并发程度，使系统资源得到很大的利用，减少了批处理的时间。5.1.8 标准的外部系统接口系统提供了标准的外部系统接口，能够方便地与其他系统（如同城清算系统、电子联行系统、人行现代化支付系统、证银转帐系统、银联系统、代理业务系统、国际结算系统等）进行接口。5.2 业务设计思想5.2.1 一体化的会计核算体系及核算主体定义系统采用大会计模式，实现了对公、对私一体化，本币、外币一体化，自营性会计和政策性会计一体化，多币种、多帐套的会计核算方法，实现了会计核算集中和应用系统的统一。系统支持核算主体上移的“一本帐”模式。“一本帐”模式有利于银行简化资金调拨流程，实现精细核算，推行专业化和扁平化管理，达到增加利润、控制成本、强化绩效、提供决策的目的。这是一项系统工程，不仅需要观念更新，还需要机构更新、制度更新。所以在实际执行过程中，要循序渐进，逐步实施。例如：有些银行尝试采用核算主体逐步上移的方式，先实现，可以以支行为一本帐，实现同一支行辖内的各网点之间资金的通融，改变了旧系统中支行辖内网点之间频繁的资金清算。因应此种情况，系统支持系统内任意级别的核算主体上移，可以将核算主体定义到任意级别层次的机构。5.2.2 支持全天候“7X24小时”不间断营业 核心业务系统支持“7X24小时”不间断营业，不仅包括ATM、POS、电话银行、网上银行等自助设备，也支持营业网点不间断营业，实现“夜间银行”，保证对客户服务渠道的畅通，满足各地区不同的服务时间要求，实现全天候的变现能力。5.2.3 支持多分行，支持多级清算单一系统支持多分行的运作，把多个分行的业务数据集中到一个数据库中；支持从总行到省行到分行到支行网点的多级清算，全面的支持“大集中”的目标；系统也支持跨系统的清算。系统对于清算支持可定义的清算模式，在系统中提供独立的清算系统进行清算支持，以清算路径、资金帐户、清分方式等为主线，对清算流程及方法进行拆分后实施组装，来确定具体的清算种类，按照清算种类实现系统的自动多级清算，同时通过定义清算模式可以支持实时清算和日终批量清算。5.2.4 “全功能柜员”系统满足了全行实行综合柜员制的需要，由柜员直接负责每笔业务的全过程，在权限允许的范围内，不分业务种类，顾客可以选择任意一个窗口办理所需的全部业务。为今后实行“客户经理”的服务奠定了基础。采用综合柜员制有如下优点：提高工作效率；减少柜员人数；提高员工素质；方便客户；改善服务质量；方便绩效考核。 同时，考虑到国内的实际情况，系统也支持传统的柜员管理方式。5.2.5 客户信息集中，统一的客户授信体系，实行额度管理客户信息集中管理，使银行可以综合掌握客户状况，以便提供全面的客户追踪和决策分析手段，如资信评估、风险评估。也可以为客户提供全方位多功能的代客理财服务。系统通过额度管理功能，根据客户的信用情况，给客户分配一定的额度，决定为客户提供的某些业务服务的范围和程度，使银行降低为客户提供某些服务而带来的风险；同时，银行也可以根据自身的情况，通过额度管理系统决定本身所进行的一些业务的范围和程度。5.2.6 加强了内控体系，强化柜员权限管理，完善的系统安全性和灵活的交易授权机制系统加强了内控管理，突出了安全保障意识，系统中对业务监督方面倡导的思想是尽可能规避风险的发生，及时发现经办风险，减少因业务监督产生的银行运营成本。系统中强化了柜员管理的力度，采用柜员操作权限控制、授权、双敲复核与事后复核等方式综合控制的模式。对柜员操作权限提供灵活的参数化管理，建立严格的柜员类别与等级管理体系，从柜员经办交易、客户类别和等级、经办金额等多种角度控制柜员的经办权限。对柜员经办业务加强授权、复核与监督，系统提供了即时授权、异步授权等多种授权模式，业务办理期间突出的风险点可通过授权的方式规避风险；业务管理部门也可采用系统提供的双敲复核的方式减少操作风险，同时考虑操作工作量，采用大额授权、超大额双敲复核的方式进行管理规划，也可以采用事后复核的方式，对规定金额的业务进行逐笔核对，确保在最短时间内发现风险。 5.2.7 灵活的计息模块，支持“利率市场化”核心业务系统中，对于利率的管理采用利率指标的方式管理，并考虑对于利率市场化后银行能够对利率的浮动进行有效的控制，在利率指标中按实点浮动及百分点浮动分别设定浮动上下限。同时，为了使系统计息方式更为灵活，更能适应银行利率政策的变化，系统采用利息计划的理念，按照不同业务种类设定利息计划参数；目前系统的利息计划制定兼顾了国内及国外的多种计息模式：支持全额计息、分段计息、金额分档计息、按利率调整周期计息等；可定义成本核算时机：先预算、后入帐等。在每个业务种类中对于不同的产品可以采用不同的利息计划，业务部门可以根据业务发展需要开发新的产品时，制定相应的利息计划。系统内部设计中，考虑利息计划使用的灵活性和可扩展性，改变了原来单一的积数法计息模式，采用计息明细的方式，使利息的计算入帐等动作独立于帐务系统之外，便于计息模式的扩充。5.2.8 灵活的收费模块，支持银行自主地制定收费政策核心业务系统提供统一的收费模块，在系统中设置费率种类及使用“费率种类”的“收费计划”，以费用的计算方式、收取方式、核算方式、收费时机及控制方式等信息设定费率种类，并可按照客户的类别级别、产品、服务、渠道等要素制定相应标准的收费计划。5.2.9 提供“以客为尊”的一站式服务客户到柜台办理业务以用身份证件或帐号登录系统的方式，系统根据该客户的类别和级别和帐户性质提供特定交易供使用；从开始到退出，控制客户交易范围，全程记录客户交易的全过程，统一提供交易确认凭证。5.2.10 合理利用计算机优势，减轻业务人员的工作量系统具有友好的用户界面，可根据客户和柜员定制不同的功能菜单，新推出的浏览器前台还具有个性化工作界面配置和信息沟通等功能，便于柜员的操作；针对特定业务设计交易，增大主机统计数据存储，减少大量的手工帐簿；大量的机制凭证由主机统一定义管理，自动打印；会计分录也由系统自动完成；批量处理采用批处理控制平台自动提交作业，大大提高了主机资源的利用率，缩短了主机批处理时间，减少了主机操作员的工作量。6 系统功能要点逻辑设计6.1 运行平台和交易组装6.1.1 核心交易平台的总体结构逻辑网络信息存储信息展现交易驱动报文拆组通讯传输交换控制控制信息前台信息流程功能展现通讯传输信息存储控制信息交换控制报文拆组交易驱动后台信息流程6.1.2 核心交易平台设计要求1、 信息展现模块：实现信息的录入和输出，实现对屏幕及各种设备的控制。l 包括对多种设备的支持，如屏幕（键盘）、磁盘、网络、磁条读写器、打印机（各种型号存打、行打）、密码键盘、IC卡读写设备等，同时需支持各种设备复合使用情况。l 实现对信息的多种展现形式，包括交易响应信息如正常应答信息（可能多条）、提示信息（可能多条）、拒绝信息（可能多条）、授权信息（可能多条）、复核信息等的支持，也包括多页式查询返回的信息、返回的多条编辑信息、带格式文本信息等。2、 交易驱动模块：实现原交易的启动、已定制交易联动流程的控制。l 实现原/子交易联动控制；l 实现字段启动交易的控制；l 实现子交易本身为原交易（组交易）的控制；l 实现自动启动现金、凭证打印、收费等公用模块组交易的控制；l 需要评估系统灵活性与系统效率之间的矛盾。3、 报文拆组模块：实现对应用收发的报文进行组织和拆解，组织后的报文供通讯收发，拆解的报文供应用使用。l 对报文格式的支持：支持自定义报文格式、ISO8583报文格式、类ISO8583、类HTML等；l 也可考虑应用系统内采用统一的一套内部报文格式，对外提供多种格式支持；l 支持同一交易返回多条不同格式报文的处理；l 对报文定义的支持：前后台统一定义一套报文格式；l 需要考虑拆组的效率和通讯数据包的精简。4、 交换控制模块：完成路由分捡、多服务器信息交换功能。l 对于前台模块支持子交易/字段启动交易级别的个性路径选择；l 对于后台模块同时考虑对多个分布在不同主机上的独立系统实现集中清算模式的支持；5、 通讯传输模块：完成通讯传输的功能。l 支持多中通讯协议，如TCP/IP、SNA等；l 支持不同交易采用不同的通讯协议；l 支持通讯报文的加密/解密；l 支持通讯报文的校验，如MAC码；l 不论前台还是后台，均需支持主动/被动通讯模式；6、 功能展现模块：完成真正的具体交易功能，本着提高功能内聚、降低模块耦合的原则进行结构划分，由核心构件资源库及组装交易所需的接口模块组成。处于应用级别，不属于平台范畴。7、 信息存储模块：l 需要考虑不同交易数据的信息隔离；l 需要考虑同一原交易下交易数据的信息共享；l 需要考虑部分特定类型信息的历史数据存储，如凭证打印信息；l 临时存储的数据实现自动清理。8、 控制信息的定制：此处所指的控制信息，包括菜单定义、交易定义、屏幕定义、数据字典定义、通讯传输格式定义、授权信息定义、提示信息定义、列表定义、打印格式定义、输出信息格式定义、设备定义等以及其他平台所需的控制信息。l 各种与具体交易相关的控制信息的定义数据可以以交易为主线进行卸载和安装；l 定义的控制信息需要满足系统性能上的要求，既保证系统开发的灵活性，又保证访问的快捷，以确保系统整体运行效率。9、 特殊交易的实现统一的当日冲销（抹帐）模式统一的双敲复核模式统一的授权模式统一的事后复核模式前台外挂交易的实现后台直通式交易的支持6.1.3 核心构件库的组成核心构件库由两部分组成：子交易、API。其中每个子交易由四部分组成，子交易可大致分为五类：帐务类、事物类、查询类、数据准备、组合类。API可大致分为三类：帐务类、事物类、查询类。6.1.4 构件形成及使用原则l 每个业务系统包含的内容，由各自提供的核心子交易、API及相应的独立对外展现交易组成；l 每个业务系统都有其独立的数据库体系，相互之间拒绝数据库的直接访问，确保数据文件的隔离。对于联机交易，如需使用其他系统的数据，通过联动子交易或调用对应系统提供的API实现。对于后台批量交易，少量数据交易采用API调用方式，大量数据处理则采用对应系统提供的接口文件方式由相应的系统进行处理，在7X24模式下，大量数据处理也可以采用API方式；l 核心业务系统功能由各个业务系统提供的核心构件资源库中相应的构件（子交易、API、接口数据文件）进行组装定制而成，任何系统提供的构件中都只包括对其自身系统功能的处理和数据库文件的操作，核心构件的划分，按照各业务系统提供的具体服务类别划分，具体的划分不在此处详细描述；l 根据具体业务特点，各系统实现帐务一体化，客户类别、币种类别、帐务类别、做为具体业务系统的属性出现，从数据结构底层实现一体化，只区分不同服务功能，对于同一种服务功能以单一交易处理，对于前台，交易组装时对部分交易要考虑可操作性，以引领式模式实现。6.1.5 交易驱动设计结构通讯传输报文拆组交换处理交易驱动交易输出空间|多格式存储。多条存储。原交易空间共享空间子交易空间联动入口联动入口联动入口子交易子交易子交易联动出口联动出口联动出口图中兰色单线箭头方向表示信息的流转方向原交易出口子交易输出6.1.6 交易驱动设计要求1、 做到原交易空间、子交易空间、共享空间信息的独立性；2、 交易输出空间为整个原交易共享，信息可能为多格式，考虑其中存储访问的条理性；3、 各个级别层次的交易模块都由交易驱动主控统一驱动；4、 如果某个子交易本身为组交易，基于组交易本身既是独立的原交易，需考虑联动过程中对原始原交易空间和原始共享空间数据的保存和恢复；5、 交易联动组装实现主要是通过联动入口和联动出口的编制完成的，对于交易入口，一般可通过定义启动条件和参数转换规则的定制方式来实现，不需要编写入口程序，如有特殊情况，则也可以通过编写新的子交易，通过联动出入口或子交易输出子交易输出空间实现，考虑未知情况，在平台中保留通过入口函数启动子交易的控制；6、 可考虑在平台中支持公共启动交易的参数化定制；7、 在交易输出空间信息发送前台前，进行平台统一的信息检查和整理处理，如统一授权产生、事前复核、交易平衡性、信息的优先级处理等。6.1.7 交易驱动实现方法根据具体的业务功能需要，选择性地将一系列的子交易和API组织起来，通过定义组装的方式联动在一起，构成一个原交易。下图以柜台归还贷款为例来说明：每个子交易我们称为PU，每个原交易称为MU，驱动规则称为RuleSet，驱动主控称为TPloader。6.1.7.1 数据关联对每一交易调用过程，WU、PU、RuleSet之间共享一个全局的数据空间(DataPool)。DataPool的形式 存储方式 DataPool使用全局内存变量的方式进行数据的存储，在一个交易执行过程中不会释放，其大小可随时增加。 数据结构 DataPool采用HashMap(散列表)的存储方式和数据提取算法。 数据区域 DataPool划分为公共区域(PubArea)和共享区域(ShareArea)两大块，其中公共区域存放系统流水号、系统日期、交易号、输入报文等全局信息，共享区域存放个WU、PU之间需要交换的中间数据或输出数据。DataPool的生命周期 创建 DataPool由TPLoader创建，并进行初始化， TPLoader应提供相关的操作函数进行DataPool的访问。 使用 在TPLoader执行一个脚本，即完成一个交易的过程中，除了各个功能单元的自有变量外，所有的需要传递的数据都通过DataPool进行存储。DataPool根据名字匹配的相关规则和算法提供数据的调入、调出。DataPool的大小是变化的。 释放 DataPool由TPLoader进行释放。DataPool与其他模块的关联DataPool是整个交易过程的数据调度中心。任何需要交换或存储的数据都通过DataPool进行，各个模块通过DataPool的接口进行数据处理。条件规则一.1.1.1.1.1.1.1.1 RULESET交易主控一.1.1.1.1.1.1.2 MUName Value DataTypeName Value DataTypeName Value DataType 流程单元一.1.1.1.1.1.1.3 WUDataPool工作单元一.1.1.1.1.1.1.4 WU6.1.7.2 交易调度、组装过程交易调度的实现由TPLoader根据交易联动表的配置，根据RuleSet的相关条件与逻辑，并结合交易环境的具体形式，调用PU与WU，以实现完整的交易流程实现业务。TPLoader的对条件逻辑的判断、对PU的调用、对WU的调用，通过Assemble层提供的接口实现组装过程。在整个调度过程中的数据存储和共享通过DataPool及其相关的接口完成。TPLoader的调度过程 启动TPLoader TPLoader作为一个PG（在CICS环境下），当CICS接收到请求报文后，根据ServiceName启动TPLoader。当TPLoader与不同的PU、WU绑定时，对应与不同的Service。 TPLoader载入交易配置 TPLoader将对应的配置载入，并进行自身的初始化处理。 根据交易配置表中的内容进行预处理 根据交易配置表中内容，进行相关的交易预处理如检查、报文解析、获取流水号、获取系统日期等。 进行交易处理 根据交易联动表的内容和逻辑判断条件调用PU或WU进行交易处理。 进行异常处理 若功能处理异常或其他不确定情况，进行特定的异常处理。 根据交易联动表中的内容进行结束处理 根据交易配置的内容，进行相关的交易结束处理如打包、提交事务等。 结束TPLoader 流程结束，并释放资源。交易联动表的作用方式系统通过交易联动表的配置作为执行交易过程的定义。在交易联动表中体现交易过程中的功能和执行条件规则。在集成基本的PU和WU及RuleSet功能的前提下，通过交易联动表组装交易。交易联动表与其他模块的关联交易主控一.1.1.1.1.1.1.4.1 TPLoader条件规则RuleSet工作单元WU数据池DataPool交易代码 *工作单元 *执行条件 *联动属性 *Load MU 交易联动表数据的分类和交换方式 TPLoader的私有数据 TPLoader的私有数据包括，当前调用的MU 、PU、WU名称，Script中的变量等。这些变量以特殊的标记存放在DataPool中，一般有TPLoader进行使用或提供特殊接口为各模块使用。 交易的公用数据 在一个交易过程中一般不变的，各个模块、工作单元需要使用的公共数据，如流水号、系统日期、请求报文数据等。这些数据在整个交易过程中，供各模块和功能单元调用获取信息，一般不能改动。 共享数据 对于个工作单元、流程单元、条件规则功能模块需要互相交换、共享、存储的数据，通过DataPool进行。数据的名称转换、存储、提取、数据预处理等通过DataPool提供的接口和相关的配置数据库进行。TPLoader的生成方式TPLoader的主程序只有一个，将TPLoader与不同的交易流程和功能单元绑定在一起就可以实现多个可供调用的、实现完整交易功能的可执行体（TPLoader1、TPLoader2、TPLoadern），通过不同的TPLoader通过调用不同的脚本实现不同的交易功能。同时TPLoader的功能实现还需要TPCommon、DataPool、Assemble、RuleSet等模块的支撑功能，因此TPLoader的生成过程还需要绑定这些基本库。由于使用函数指针的方法调用相关的工作单元，因此，对于每一个具体的TPLoader的生成过程，需要载入不同的头文件和获取函数指针的函数，以完成函数名称与函数指针的映射关系。6.2 报文接口及拆组包6.2.1 主报文格式采用类HTML格式，使用KeyValue方式(散列表)描述数据，对Key使用“”进行标注。针对核心交易平台，采用这种报文结构的优点在于：l 增强报文适应能力；l 适应报文的灵活可扩充；l 方便报文数据提取；l 提高系统的可调试能力。6.2.2 系统拆包流程根据交易报文头信息进行如下处理：l 从原交易定义表中根据交易代码读出MACChk标志，决定是否进行MAC检查；l 如果需要MAC检查，调用HSM提供的API进行MAC检查；MAC检查出错，返回前台提示信息：MAC出错；l 根据交易代码检索交易字典(TranDataDic)，根据交易字典定义表，进行报文解包。如果交易字典定义的是M信息，报文中必须上传。没有上传，返回前台提示信息：必要的输入信息不全；l 根据KEY值解包。6.2.3 系统组包流程l 根据交易代码检查交易字典（TranDataDic）,根据交易字典定义表，找出KEY；l 根据KEY，查询交易输出数据定义表(MUOutData)，根据交易输出定义表内容组织数据；l 根据MACChk标志，调用HSM提供的API进行MAC计算；6.3 操作流程定制6.3.1 操作流程定制设计构架交 易 主 控某 个 子 交 易 处 理屏幕入口屏幕处理屏幕出口复核授权本地交易处理交易签名交易上传交易下传信息转换、分析、存放、处理输出处理交易出口交易入口字段入口字段处理字段出口SERVER柜 员处理函数输出设备交换处理交易动态使用空间交 易 定 义数 据 字 典交易菜单屏幕字段上传信息结构下传信息结构授权复核输出格式配 置 定 义6.3.2 操作流程定制设计要求1、 交易入口主要完成交易的启动条件判断和交易入口参数赋值，正常情况下不需要编写函数，而是通过启动条件定义和入口参数映射的定义实现定制；2、 屏幕入口、字段入口的实现同交易入口的实现模式；3、 为实现开发过程的定制，必须采用统一的数据字典；4、 平台提供自动启动子交易的应用定义，而不是将个别功能集成在平台中，应用只需定义入口/出口；5、 实现交易权限定义的灵活性，通过柜员类别/级别、客户类别/级别、交易类别/级别、菜单类别/级别控制显示和操作，实现个性化菜单定制；6、 实现凭证格式的共用，建立凭证格式库，提供凭证输出的统一接口，提高凭证格式的复用率，并实现事后凭证的重复打印功能；7、 用定制方式实现前台列表信息的动态显示，避免编写函数；8、 授权模式统一，前台可以实现简单的授权定义，需将授权信息统一存储在后台，便于统一管理授权记录；9、 提供集成在运行平台内的终端间、结点间消息通知功能，便于下一步实现工作流程定制；10、 支持子交易循环启动、原交易循环启动；11、 支持菜单项目的出入口执行交易功能，实现真正面向客户的设计模式，按照客户类别、级别等控制信息实现对不同客户允许执行交易的控制；12、 支持当日冲销、复核、事后复核、异步授权等特殊交易模式；13、 支持前台平台外挂其他交易系统。6.4 分录接口设计6.4.1 分录接口模式总帐报表总帐分录流水分录接口分录代码定义子交易交易分录代码联动交易信息平衡检查交易主控子交易子交易帐户、登记簿处理，分录接口的启动6.4.2 设计准则l 多维度，可扩展帐务交易登记分录流水，非帐务交易登记非分录流水，通过流水中的分录标志来区分。流水接口中有原交易流水号和子交易流水号，对一笔交易产生一个原交易流水号，子交易有不同的子交易流水号。分录流水中除设置机构、币种、核算科目、借贷、金额等主要要素外，还设置了产品、客户种类等要素，便于向产品、客户总帐平滑过渡，同时，为了支持商业银行自身的统计分析需要，增加了可以由银行自行定制的统计编码，使分录可以从多个角度、多个维度进行分析处理，使分录更具扩展能力。 l 独立性，完整性存款、贷款、内部账等帐务系统均使用统一的分录流水接口来登记分录，使分录流水的登记统一、规范，统一分录接口也意味着分录信息规范的统一，使分录更具可分析性。对具体的交易来说，交易组装就可以完成分录接口的调用。6.5 总账设计 6.5.1 总账设计结构l 独立的总账系统设计l 按原始货币记账l 内部预留多账套机制l 与分录接口模式相结合，可扩展为多维度的总账系统l 科目分级设置：便于核算，统计l 本外币一体化l 对公、对私一体化l 整个系统按照大会计思想设计，根据用户需求可以将账务核算主体定义到任意一级机构，例如：支行一账帐分行一本账总行一本账商业银行将银行整体或一个城市中心或一个支行作为会计核算单位，在一个会计核算系统内，不再有会计网点的概念，而形成在会计核算单位内的一本帐。会计帐由具有较强管理能力的总行或中心或支行来统一管理，同时核算单位之间也不存在往来科目，会计核算单位以下的单位变成了一个个营业网点而非会计网点，它只专心关心自己的业务，而不能涉及会计帐。从而产生一系列优点：1. 减少核算层次2. 提高资金使用效率3. 便于银行作为一个整体开展业务，重新定位各分支行的主营业务方向4. 便于总行有充足的对外支付能力5. 降低金融风险6.5.2 核心总账的处理模式存款业务贷款业务结算业务内部账业务中间业务批量业务。所有账务交易修改分户账余额写分录流水（账务）汇总汇总本日发生额汇总昨日总帐各科目余额+=？本日总帐各科目余额平衡检查总帐科目动态日总帐周期总帐（旬，月，季，半年，年）6.5.3 总账汇总口径虚拟科目A=科目a+科目b-科目c科目a科目b科目c。虚拟科目汇总科目a科目b科目 c。 机构一机构二机构三虚拟机构汇总机构一机构二机构三美元日元欧元英镑港币。人民币（本币）外币折本币合计折本币虚拟币种汇总（本外币折人民币）外币折美元l 虚拟机构汇总多支行及多网点核算，通过设置虚拟机构与其他机构关系可以实现任意层汇总。l 虚拟币种汇总多币种总帐，提供外币帐折算为本币、美元及任意虚拟币种的处理，即提供单一货币结算和单一货币余额的功能l 虚拟科目汇总按会计核算需要，对最底层的明细科目进行运算汇总来设置虚拟科目。从而简单的可以统计出该核算单位的数据。l 其他口径汇总按照分类汇总原则，可以从产品、客户等角度对总帐进行汇总，满足银行未来核算及管理的要求。（保留）6.6 帐务体系6.6.1 帐务结构6.6.2 帐户设置建立以客户为中心的统一帐务体系，以客户号为为主导，联系所有与客户相关的帐户信息，所有帐户共用唯一的客户信息。银行自身的帐务做为一类特殊的帐户，客户缺省为银行自身，在此称其为内部帐。帐户管理体系采用统一的多分户模式，不论对私对公，均采用客户帐号+款项代码方式，以客户帐号做为面向外部客户的唯一形式，由系统内部管理其下的所有款项，使系统从底层基础支持多重帐户的管理，并可为每个款项建立与其他帐户的相关性，实现不同层次类别的帐户管理。l 客户帐号： 1. 是指面向客户，客户能够实际看到的帐号，也可以称为主帐号。例如：存折上打印的活期存款帐号、单位客户购买和签发支票时使用的用于结算的支票户帐号、储蓄卡卡号、一本通的主帐号、定期存单的帐号等。2. 客户帐户存储帐户的静态信息 。l 款项代码1. 款项是形成帐户的最基本元素。2. 每个款项对应一具体的银行业务产品。3. 因此款项具有归属机构、归属产品、归属核算代码、归属币种等属性，对具体款项属性及具备功能的规定是从产品参数中定义的。例如存入一笔人民币1000元的活期存款，系统为其自动建立对应的一个存款类款项代码，管理这笔存款。4. 划分款项后，可通过对各种款项的整合建立综合帐务管理。6.6.3 建立以“款项”管理为基础建立综合账务管理体系l 每个产品下允许有哪些款项可根据需要进行配置 , 也可具有单一款项l 对基础款项按照子产品配置，银行进行产品包装，组成具有单一功能或具有组合功能的产品l 从帐户的角度说，即为客户提供具备各种不同功能组合的户口l 款项代码客户不可见，而是由系统提供列表形式给操作人员选择款项由客户确认6.6.4 内部账户体系l 帐号的组成规则：为便于记忆，一般不同于客户帐号，如一般可为：机构号币种科目编号顺序号l 标准户：系统核算需要统一开立的帐户。自动产生会计分录。例如现金帐号、应收利息、应付利息等需要自动记帐的帐户。l 销帐类帐户：管理逐笔明细，支持部分销帐。例如应解汇款帐户。l 清算帐户：用于结算不同金融机构之间债权、债务关系的帐户允许透支，系统自动结息透支可自动强制拆借清算帐户为标准户l 过渡帐户：基于核算和管理需要设置如：通存通兑过渡户，电子汇兑过渡户等l 凭证帐户：表外管理，分为在库户，在用户，待销毁户重要空白凭证：记录张数，一张代表一元有价单证：记载有价单证的余额。余额有价单证张数有价单证面额l 手工帐户:手工管理，面向传票记帐 6.7 产品化模式6.7.1 设计目标在核心业务系统中，银行为客户提供的服务是以产品形式出现的，设计的目标是：l 让业务人员制定符合市场的银行服务产品l 更快推出新产品，占领市场先机l 使银行服务更为贴近客户，满足客户不同需求l 保持系统核心稳定，减少系统维护难度6.7.2 产品分类我们技术性地将产品分为如下几个大类：l 存款类产品l 贷款类产品l 卡类产品l 债券类产品l 其他类产品6.7.3 产品结构设计银行最终提供给客户的产品，是经过这些产品规则描述以及有关的宣传包装形成的：l 存款类产品产品代码存款产品属性定义存款产品服务定义l 贷款类产品产品代码贷款产品属性定义贷款产品服务定义存款类产品的结构如下图所示：贷款类产品的结构如下图所示：6.8 724小时营业设计6.8.1 不间断营业设计架构6.8.2 724小时营业任务序列正常运行状态NORMAL切换日期，进入日终处理状态日终批处理状态CUTOFF日终批处理结束，进入追帐状态追帐状态APPEND追帐结束，切回正常状态联机交易在同时进行前一工作日下一工作日1. 系统24小时的帐务处理完全由系统的底层函数处理，程序开发员在开发交易时只需要调用子交易，不需要考虑24小时的帐务。2. 系统状态公共系统控制参数中的系统状态分为：N：日间运行状态(normal) C：日切运行状态(cutoff) A：追帐运行状态(append) S：系统关闭(shutdown)系统的C，A，N状态是系统日终处理时进行的状态切换。3. 系统关闭核心业务系统处于关闭时，禁止所以业务运行。此状态在出现特殊情况时。4. 系统日间运行状态系统做完日终批量处理后，状态未日间运行状态，此时所有的交易实时修改分户帐的余额。5. 系统日切状态系统日终操作在做完当天的自动转存等帐务处理后，在系统入总帐前，将系统的状态改为日切状态。在该状态下的所有交易，不修改分户帐的余额，其发生额写入影子分户。保持分户帐余额不变，是为了机构入总帐时进行总分平衡的检查。6. 系统追帐状态系统日终入机构总帐结束后，系统状态改为追帐。在这个状态下的所有交易，实时修改分户帐余额。日终处理的追帐交易，对影子分户里帐户的发生额进行分户帐余额的修改。在所有分户追帐完成之后，系统状态改为日间运行状态。6.8.3 724小时营业设计要求l 系统只要不是运行在日终批处理状态(CUTOFF状态),也就是系统运行在正常状态（NORMAL状态）或追帐状态（APPEND状态），帐务处理API可修改分户帐余额；l 系统只要是运行在日终批处理状态(CUTOFF状态)，记帐API就不能直接更改分户帐余额，而只能更改影子帐户余额。注意：在日终批处理状态下,任何联机交易都可能发生，所以开户程序在写分户余额时，只能将余额记为0,而真正的余额必须记入影子帐户中;同样，销户时，不能将分户余额记为0，而必须将发生额（也就是余额）记入影子帐户中。冲正交易的处理相同.l 系统只要不是运行在N状态（正常状态），计算帐户可用余额时，必须将影子帐户中的余额和分户帐中的余额一起合并计算。l 由于日切后，系统进入下一个帐务周期，所以帐务处理流水（如：分户帐明细，分录流水，子交易流水）中均记录了帐务日期，因而不会和前一帐务日期相混淆。在备份这些库表时，只要根据帐务日期处理即可。l 任何帐户，包括客户帐，内部帐，处理方法是一样的。l 由后台主机按照交易来确定哪些交易允许在日终期间可以开通。l 如果柜台开通24小时业务，需要考虑柜员及网点轧帐交易的支持，业务需考虑传票装订与柜员轧帐的模式。6.9 统一冲销模式设计6.9.1 实现方式核心系统采用统一的当日冲销（抹帐）用户接口，使操作人员对系统中的任何交易的冲销，均使用统一的一个专门用于冲销的交易码。当日冲销实现对当天的帐务进行冲销，包括帐务类冲销和非帐务类冲销，在系统中采用“反交易存储过程”的模式实现。即，分为流水冲销（置成被冲销状态）、反交易（生成新的流水，状态为冲销，借贷方向同原先的交易）、登记簿冲销（自动完成），请注意：非当日的帐务不能用此交易处理。当日冲销可以冲销帐务的和非帐务的交易，帐务的交易必须有流水记录，非帐务的交易可以有也可以没有流水记录,但必须产生一个流水号（因为银行需要统计柜员的业务量及对特殊交易记录进行稽核，所以系统中所有处理登记簿的交易都要登记一条非帐务流水，方便查询）。反交易一般针对处理帐户的子交易专门设定，每一个记帐子交易或API必须有一个对应的反交易函数。6.9.2 反交易的编写冲销程序存放在 src/cancel/下，其中主程序放在api下，所有的反交易函数放在func下，反交易的函数原型如下：Int cnXXXXXX( struct glssubtranslog * pSublog)其中：XXXX是正子交易函数名，表示可对XXXX子交易函数冲销反交易函数的source文件命名采用在其对应的子交易文件名前增加cn。入口参数是表glssubtranslog的指针。冲销时，对交易流水按照子交易流水序号进行从大到小的排序，即降序排列，冲销主控程序依据流水中冲正子交易代码revsubtran找到在子交易定义表中定义的反交易函数，如果函数名为空不调用，非空调用。每一条流水都调用一次。编写要求：l 反交易函数对应于子交易或API，每一个子交易或API有且只能有一个函数。l 冲销主控交易对每一条流水都调用反交易函数，这就涉及到一个问题：在原始交易时有可能一个子交易产生多笔流水，这就要求在编写反交易函数时有特殊处理，有一定的控制机制。（主要是在贷款业务中）l 可以利用流水表中一些字段如memo和memo1保存原始交易的一些信息，但需要按照公共制定的统一规范使用，不要滥用。l 帐务性反交易也会生成流水（由主控程序自动