CBPS-SE应用系统构建方案与设计要求.doc

1. 范围
1.1 标识
项目名称：中国人寿核心业务处理系统（超强版）（暂定名）开发
项目代号：CBPS-SE
文档名称：CBPS-SE应用系统构建方案与设计要求
文档配置管理标识：COPIA_SW_2003_00_0001
1.2 项目概述
受中国人寿总公司委托，北京科比亚公司承担中国人寿核心业务处理系统的设计与开发。该系统的主要用户为省级集中的业务处理中心，系统要满足业务处理集中后的业务处理要求及业务处理模式，系统要具有与其它处理系统的数据接口能力。

系统在TUXEDO作为处理中间件的基础上构建，以满足集中后数据量及并发用户数规模。
1.3 文档概述
本文档的目的是确定技术的选择，确定业务逻辑的分配，确定主要的设计约束，确定进一步设计的规格要求。

进一步的系统设计及业务规格的设计应在本文档规定的条件下进行。
1.4 预期读者
项目负责人、SERVICES设计人员、界面设计人员、系统管理员、数据库设计与管理叫、方案评审组人员。
2. 引用文件
3. 定义
3.1 术语
用户控制块
是应用系统的内存存储区域，用以存放CBPS-SE的用户注册信息
活跃产品定义块
是应用系统的内存存储区域，用以存放目前仍在销售的险种的基本约束要求
业务代码字典
是业务中使用的各项代码，代码字典是企业标准化要求的一部分
业务代码字典块
是应用系统的内存存储区域，用以存放各项业务代码字典的数据
3.2 缩略语
CBPS-SE
Core Business Processing System – Super Excellence
UCB
User Control Block
APDB
Active Products Define Block
BCDB
Business Code Dictionary Block
4. 项目概述
CBPS-SE包括寿险的各项业务处理功能，支持业务要求的处理模式，提供数据接口标准使其它处理系统可以与核心业务系统进行数据交换或作为核心系统的客户端访问CBPS-DN

CBPS-SE用TUXEDO/T作为中间件保证系统的高可用性、可扩展性及好的系统响应能力。

CBPS-SE用TUXEDO/Q作为消息中间件来满足不同服务器间可靠的数据传输。

CBPS-SE用数据路由技术解决超大数据的存储与管理。

CBPS-SE用科比亚的任务管理平台来满足业务中的工作流管理要求。

CBPS-SE具备支持超大并发用户及超大数据访问的能力。
5. CBPS-SE目标分析
5.1 中国人寿背景
中国人寿保险公司是国务院直属企业，是目前中国最大的专业寿险公司，2002年的营业收入1287.19亿元，客户1.5亿人，占国内寿险市场近60%的份额。

中国人寿在全国拥有分支机构3400个，正式员工5.2万人，设立代办机构8万多个，聘请专兼职代理人65万人。

中国人寿保险公司的核心业务系统建设经过6年多的努力，取得了很大的成绩：
l 总颁条款的业务管理按总公司的实务管理办法，已经全部实现上机处理，并且正在向省级集中；
l 短意险的业务处理系统也已经开发完毕并正在全国推广使用；
l 老业务的处理系统正在测试中，将于2003年4月投入运行。
5.1.1 组织机构
中国人寿的组织结构是按行政区划设置的集团公司。

总公司为一级法人，主要负责公司各项规范的指定及执行情况的检查，除一些特大型的团体业务外，总公司并不具体负责产品销售。

对于超过规定的大额件承保或理赔，总公司负责案子的核查及处理。
5.1.2 业务现状及特点
目前中国人寿已经开办的业务或即将开办的业务有：
l 按产品类别分：普通寿险、两全险、意外险、健康险、养老年金
l 按业务性质分：团体业务、个人营销业务、代理业务
l 按缴费性质分：普通、投联、万能、基金、储金
l 按盈余分配性质分：红利、利差返还

CBPS及CBPS-O已经能够处理上述的各类产品。

目前的CBPS在支持的业务模式上主要是“申请-审核-生效”的模式。
5.1.3 业务量
由于中国人寿是全国性的公司，各分公司之间东西差异比较大，以中等规模的省作为依据，目前全省的并发用户数约为1,000-1,200 ，数据量约为30G（不包括影像数据）。

分地区的每天新单数、保全的业务数、理赔业务数、收付费交易笔数等的各项统计中国人寿信息技术部正在统计。
5.1.4 电子化现状
硬件
IBM-AIX，HP-UX，PC-SERVER等基于UNIX的小型机或服务器

软件
OS：UNIX
DBPS：INFOMIX
业务处理系统：CBPS
财务处理系统：CLAF
营销员管理系统：AMIS
5.2 业务目标
l 业务处理逐步集中
l 引入原始单证影像件管理后的工作流管理
l 客户服务的一柜制业务模式
5.3 技术目标
l 先进性：基于TUXEDO中间件的三层C/S模式是目前开发大型关键业务处理系统最为先进技术，同时也是成熟的技术。这项技术在支持超大并发用户，超大数据规模时是必不可少的
l 灵活性：由于业务逻辑与表示逻辑的分离，使得调整业务逻辑或增加业务逻辑时不会引起界面的调整；反之如果用户要求设计新的界面风格，而基本的业务逻辑不变时，不必修改服务逻辑。这对业务要求可能不断发生改进的企业来说是十分必要的
l 安全可靠性：系统除注册用户安全性检查外，增加了注册位置、注册时间的安全性检查，并且增加了安全性审计功能。在应用设计时增加了安全服务处理层来解决安全性检查，在必要时可加入数据传输加密及关键数据存储加密的服务
l 易操作性：前端界面全面以WINDOWS风险提供，操作上既提供鼠标操作又提供操作的操作方式。配合业务部门一柜制的管理要求，专门设计柜面业务处理子系统，使得窗口服务更为方便
l 开放性：系统设计中采用的技术都是基于标准的，并且都是运行在开放平台上。坚持开放性也就是坚持系统的可扩展性。在我们的应用系统中可以通过更换数据访问服务来存取不同的数据库
6. 总体解决方案
6.1 系统总体结构

系统架构中主要的的是把表示逻辑、业务逻辑通过事务处理中间件构建成“请求-响应”这样的服务形式。
6.2 分布计算环境
CLIENT端只反映表示逻辑，即数据的录入，并把请求发给TUXEDO服务，CLIENT不对输入的数据做任何加工处理。对于返回的结果，按要求组织数据并显示。

SERVER端为业务逻辑，所有的逻辑以TUXEDO SERVICES组织。多个SERVICES可组成一个SERVER，多个相同或不同的SERVER可分布在不同的物理的服务器上。服务的集群架构是应用系统具有高可用性及响应速度快的技术基础。

系统中可配置一个或多个数据库服务器，不同的数据可存放在数据库服务器中，同一数据对象可按一项或多项属性值分布在多个数据库服务器中，并通过数据路由透明访问数据库。

基于消息中间件可构造MSG-HUB，满足不同业务系统间的数据交换。

对于外部接入的服务请求，在系统中设置前置机，并且把前置机的请求程序作为CBPS-SE的一个CLIENT。
6.3 应用系统结构
应用系统的业务逻辑是分层设计的，每层都具有一定的独立性，要求任何一层的修改只要不修改调用接口的数据，就不会影响其它层的处理逻辑。
CBPS-SE应用按如下要求分层
6.3.1 CLIENT的启动及退出
启动CLIENT时首先要进行登录，登录时要输入“机构号”，“用户名”，“口令”，系统将自动获取用户登录的位置，如果需安全认证的，将读取安全证书号。

登录时首先发出CS_LOGIN请求：
l CS_LOGIN(BRANCHID，USERID，PWD，SUBSYSID，CID，认证码)，返回STATUS，UCBID

LOGIN成功后，发CS_CHKVER请求：
l CS_CHKVER(SUBSYSID)，返回STATUS，各程序、数据文件的版本列表
CS_CHKVER检查系统本地资源的版本，以清单方式发回，读到后可比对本地的资源版本清单，如果相同的则启动系统，如果不同则显示需重新下载的的资源名称，选择后启动FTP进行文件传输。本地资源列表可以正文方式存储，但为防止文件内容被修改，另需记录文件的CHKSUM，在比对前若CHKSUM不对，则要求重新下载全部本地资源。

系统退出时要求发CS_LOGOUT：
l CS_LOGOUT(UCBID)，返回STATUS
6.3.2 客户端程序
对于输入数据可通过定义域的属性对输入的域的格式（日期型，字母数字型、字符型、字母型、数字型等）进行检查

对于显示结果，如果是列表格式，可对显示结果按指定列排序，或按某属性值进行选择，也可调整列的显示位置。若某显示域为其它域的简单算术运算结果，则可在CLIENT端完成。

CLIENT功能一般不通过编方式，而是通过工具的属性定义完成。

对于服务请求，所有的CLIENT程序一律通过统一的接口函数调用，接口函数把VB的结构的数据转换成CARRAY结构，并发出TPCALL调用。

若数据需传输加密的，则加密逻辑封装在接口函数中。

在接口服务请求时，如果返回TIMEOUT，则要求发CS_RELOGIN请求：
l CS_RELOGIN(BRANCHID，UCBID，USRID，PWD，SUBSYSID，CID，认证码)，返回STATUS
6.3.3 登录与退出服务
任何一个CLIENT在请求服务前必须建立应用级的会话，这是通过CBPS LOGIN完成的。

登录时，服务将在内存为每个用户建立一个用户控制块（UCB），用以存放有关登录的状态及其它信息。当用户退出时，系统将UCB内容记入UCB的日志。UCB日志的结构为：
UCBID
BRANCHID
USRID
LOINING TIME
SUBSYSID
LOGIN CID
LAST CALL TIME
LOGIN TRY TIMES
LOGOUT TIME
FLAG

UCB是内存中的存储区，当用户LOGIN成功时建立，同一个用户在同一时刻只能登录一次。UCB内容与UCB日志内容基本相同，但不包括LOGIN TRY TIMES、LOGOUT TIME、FLAG。UCB空间在建立时动态分配，在LOGOUT时释放。在连续N 在CBPSCONFIG.INI中设定
分钟内没有服务请求时，系统将自动释放空间。登录完成时，系统同时要把登录信息写入用户登录日志；释放空间时，系统要把UCB信息、LOGIN TRY TIMES、LOGOUT TIME及FLAG写入登录日志表中，作为审计用。

UCB内容包括：
l UCBID为建立时系统分配的唯一标识，在以后的服务请求中，均要传递UCBID，系统将检查其操作权限；
l BRANCHID为登录用户的所在机构，USRID为登录用户帐号。BRANCHID+USRID唯一确定一个用户；
l LOGIN TIME为登录时间；
l SUBSYSID为登录子系统标识；
l LOGIN CID为登录CLIENT位置标识；
l LAST CALL TIME为最近一次服务请求时间；
l LOGIN TRY TIMES为试图LOGIN的次数，每LOGIN失败一次则+1，在N 在CBPSCONFIG.INI中设定
次失败后则将在M 在CBPSCONFIG.INI中设定
分钟内拒绝该用户再次LOGIN；
l LOGOUT TIME为退出时间。在UCB中没有该项，但在用户登录日志中有此属性，在退出时由服务写入；
l FLAG为退出原因：LOGOUT/自动释放/强制退出/超过LOGIN TRY TIMES

登录及退出SERVICE是按名调用的，数据为CARRAY结构。登录及退出SERVICE的功能：
1） CS_LOGIN(BRANCHID，USERID，PWD，CID，认证码)，返回STATUS，UCBID
根据BRANCHID，USERID，读取用户表，检查PWD，认证码，如果找不到用户、口令不对、证书不对或过期，返回出错状态，记LOGIN TRY TIMES+1，如果LOGIN TRY TIMES 超过系统规定次数，则写UCB日志，并返回状态；检查用户的子系统访问权限，如果不正确返回状态；如果检查正确，则建立UCB，记LOGIN TIME，初始化LAST CALL TIME为LOGIN TIME，返回UCBID。

2） CS_RELOGIN(BRANCHID，USERID，PWD，SUBSYSID，CID，认证码)，返回STATUS，UCBID
功能与CS_LOGIN类似，只是不用建立UCB。

3） CS_LOGOUT(UCBID，FLAG)
读用户表中的LOGIN TRYTIMES，取系统时间，修改UCB日志。

4） CS_CHKVER(SUBSYSID)
读取指定子系统的资源列表，并返回列表内容。
6.3.4 接口服务
由CLIENT端发出的服务请求称为接口服务。在按提交功能键（F12）或CLICK“确认”键后发出的服务请求。

接口服务的SERVICES以CI_SVRnnn命名，每个CI_SVRnnn具有相同的结构，分组的目的主要是为协同开发，同时具有相同优先级的交易可以组织在同一个SERVICES中，方便系统的配置。

数据类型统一为CARRAY格式。

CI_ SVRnnn的输入参数为：
l UCBID：LOGIN时获得的UCBID
l TXID：交易号。在设计时，对于每一个请求，将分配唯一的编号
l TXNAME：交易名。在设计时，对于每一个请求，将有唯一的命名
l CID：请求CLINET的ID
l SUBSYSID：请求的子系统ID
l INDATA：交易请求数据

CI_ SVRnnn的返回数据为：
l STATUS：状态
l OUTDATA：交易结果数据

所有的请求都要求编号与命名
l UCBID：LOGIN时系统返回的UCBID
l TXID：交易编号，长整数型，为6位数字。1-2位是00-79时为功能组编号，其中第3位是0-4时为更新服务请求，5-9时为非更新服务请求，4-5位为该功能模块的交易序号。1-2位是80-89时为公共的非更新服务请求，是90-99时为公共的非及时更新服务请求。非更新服务请求在交易恢复时不作处理
l TXNAME：交易名，按业务取有意义的英文命名，为32位字符串
l DATA：交易数据是批本次请求需要的数据

按业务逻辑组织的接口服务有 这是与用户需求直接相关的，在需求没有最终确定前，我们很难作进一步的设计
：
l 00nnn，MIO_XXXXXXX：收付费管理
l 01nnn，ENT_XXXXXXX：数据录入管理。录投保单，清单等，复核，差错管理
l 02nnn，TXW_XXXXXXX：交易窗口管理。收单登记，各种批改及保全项目（如果需提交审核或核保的项目只包括申请受理），理赔报案及简易理赔，贷款、权益转换。
l 03nnn，CSV_XXXXXXX：服务窗口管理。生成金给付及其它需审核的给付？？？，咨询服务，理赔收益人身份确认（一部分可与窗口管理调整，最后根据业务需求定）
l 04nnn，CLM_XXXXXXX：理赔管理。立案、调查报告、理算，结案，理赔流程调度
l 05nnn，UWR_XXXXXXX：核保管理。提取待核保件（按下一个未核保的，按投保单号或保单号），加费处理，参数化的特别约定、文字型的特别约定，团单协议书核保，约定费率
l 80nnn，GET_XXXXXXX：获取业务对象数据，作为公共的查询处理。按健值读取。GET一个保单，GET投保人，GET保单全部被保人，GET一个被保人， GET……
l 90nnn，QRY_XXXXXXX：查询统计日结管理。各种报表生成请求，统计报表打印，查询请求与结果显示，各岗位的日结及日结表打印

在接口服务中，在按交易码调用实际的处理逻辑前，首先要执行一系列请求检查服务。对于业务数据如果有合规性要求的须调用数据检查服务。
6.3.5 系统检查服务
对于每一个CI_SVRnnn SERVICES，首先要调用传输数据的解析函数，把CARRAY结构的数据解析成C STRUCTURE的数据。

如果数据是加密传输的，则需在解析前先把数据解密。

解析完成后，首先要调用如下服务：
1） CS_CHKTXID（TXID，TXNAME） 可设调试开关，在调试时检查是否交易号与交易名匹配不对，防止编程时误写

读取交易列表，检查交易号与交易名是否匹配。

2） CS_NEWCALL(UCBID，SUBSYSID，CID，FLAG)，返回STATUS，TIMESTAMP
检查发送的SUBSYSID，CID是否与登录时一致，如果FLAG=CHKTIMEOUT，则检查是否超时，若FLAG=NOCHKTIMEOUT，则不检查超时。修改UCB的LAST CALL TIME

3） CS_CHKOPGRANT（USRID，TXID，CID）
检查该用户的操作权限。检查该交易是否是开放交易（开发交易表启动服务时在内存建立表格），若不是则读取用户权限表，检查用户对指定交易的操作权（包括时间限制、位置限制），如果无权限则返回出错状态。若有权限，但有值约束，则构造值约束条件子句，用于以后的值约束检查。

4） CS_CHKXOPGRANT（SUBSYSID，BRANCHID，OPPBRANCHID） 跨机构操作只对操作层的服务请求。对于如工作调度、考核、统计等管理层的服务请求不允许跨机构操作。对于统计查询，允许上级机构对下级机构的操作。

检查该用户的跨机构操作权限。上级机构的操作员自动具有下级机构操作员的相同交易操作权，非上下机构的跨机构操作要定义跨机构操作表（按子系统划分），只有列入表中的机构操作人员才具有同交易的跨机构操作权。机构间的交叉操作权约定要求对待的。如果跨机构操作权表只有一条记录，机构为最高层的机构号，则表示系统内的全部机构具有完全的跨机构操作权。
本服务总在是更新操作前调用。在调用该项检查前，要根据不同的交易号，取得对手机构号（OPPBRANCHID），根据返回结构决定是否允许作更新操作。

5） CS_GETOPPBRANCHS（SUBSYSID，BRANCHID），返回OPPBRANCHIDS
得到OPPBRANCHIDS。根据对手机构列表，构造查询条件子句，用于以后的查询。该项服务总是在查询前调用。

6） CS_GETSUBBRANCHS（SUBSYSID，BRANCHID），返回SUBBRANCHIDS
得到SUBBRANCHIDS。

6.3.6 数据检查服务
对于传入的数据进行数据合规性检查。命名为CK_XXXXXX，数据为CARRAY格式。
l CK_TOPINSURAMNT
l CK_TOPAGE
l ……

全部的数据检查服务一律由业务处理的服务调用。

6.3.7 计算服务
对于与业务逻辑有关的计算，这些计算一般需要从库中读取相关数据，命名为CC_XXXXXX，数据为CARRAY格式.
l CC_REFUND001
l CC_REFUND002
l ……
l CC_CASHVALUE001
l CC_CASHVALUE002
l ……
l CC_PREMIUM001
l CC_PREMIUM002
l ……
6.3.8 数据对象访问服务
如果需要访问数据库，则要求一律通过数据对象访问服务完成。命名为CO_XXX_XXXX，数据为CARRAY格式。这类服务以对象来构建，与具体的交易不一定是1-1对应的关系。如：团单增加一个被保人，新契约与保全的团单增人都有相同的处理。
如果数据访问有值约束的，则需传递约束条件子句，并在本服务中，与形成SQL语句，根据权限表，对于数据访问的范围权限是以扩展的条件子句作为输入参数由调用者传入的。
l CO_GET_A_CONTRACT
l CO_PUT_A_ BENEFICIARY
l ……

6.3.9 基本函数
如果某项逻辑具有一定的独立性，可设计成基本函数。基本函数独立管理并建立函数库用于程序的联接编译。

基本函数以CF_XXXX命名。
l CF_YEARS
l CF_QUARTERS
l CF_MONTHS
l CF_WEEKS
l CF_DAYS
l CF_CORRDAY_YEAR
l CF_CORRDAY_QUARTER
l CF_CORRDAY_MONTH
l CF_COMP_INTEREST
l CF_SIMP_INTEREST
6.4 系统的启动与关闭
基于TUXEDO的C/S结构的应用系统与传统的二层的C/S结构有启动时有较大的区别。CBPS-SE服务必须启动后，CBPS-SE的客户端程序才能进行联接并请求服务的响应。
CBPS-SE启动最主要的工作是初始化全局量或内存数组，使某些处理只需通过查询内存中的数据而无需访问数据库，这样的处理是为提高系统的响应速度。系统启动及控制时的相关参数通过读取CBPSCONFIG..INI文件获得。
CBPS-SE的关闭的主要工作是要把记入在内存中的数据或状态写回数据库。
6.4.1 启动
1) 系统参数中要设立系统关闭状态（数据库值），在全局量中也要设立系统运行状态（系统运行状态可考虑按机构设置，使得系统可暂停对某个机构的服务，但机构级别要有所限制，以防止状态过多）。
2) 正常启动：如果系统关闭状态是“正常关闭”，则允许正常启动。初始化全局量，建立APCB 另一选择是，全部险种的基本信息读入内存，建立PCB，不算地方老险种，现在大概有100个左右总颁险种，即使每年增加20个险种，10年内增加200个，这样的规模还是可以接收的。
，读入各计数器初始值并建立计数器全局变量。启动完成后设置系统运行状态为“正在运行”，写系统关闭状态为“正在运行”。如果系统关闭状态为“非正常关闭”，则不能正常启动。
3) 恢复启动：如果系统关闭状态是“正在运行”，则系统可恢复启动，若是“正常关闭”则提示是否要恢复启动。由于系统非正常停机（如CORE DUMP等），则启动时除初始化全局量，建立APCB外，首先要从各种表中找到计数器的最大值并恢复（写入计数器表），再建立建立计数器全局变量。启动完成后设置系统运行状态为“正在运行”。写系统关闭状态为“正在运行”。
4) 取消暂停：如果服务没有退出，只是系统状态为暂停，则状态恢复正常。
6.4.2 关闭
1) 正常关闭：检查是否还有活动用户，如果有则提示是否要强行关机或广播关机通知，如果没有，则要反需保存的状态写回库中。系统关闭状态改为“正常关闭”。
2) 非正常关闭：不可预料与控制，但系统关闭状态改应仍为“正在运行”。
3) 暂停：把系统运行状态设为“正在运行” （如果状态按机构设定，则可暂停某一机构的服务）。
4) 强制中止用户：从UCB中清除指定用户的记录。
6.5 数据库
本项目核心数据库结构基本保持不变，但为配合工作流管理，对于新契约的投保申请数据的存储从原“投保单与保单”数据存储中分离出来，单独存为“新投保申请”，在合同生效后转为“保险合同”，对于未生效的申请转为“未受理投保申请”。

为加快工作流中各岗位的任务查询，对每个岗位建立任务表。
7. 应用系统功能设计
7.1.1 业务模式支持
支持多种工作流模式 要求实务中规定各阶段的模式类别
。可按机构设置（要求业管确定设置的机构级别）。
7.1.2 CLIENT端子系统划分 子系统的划分与实务是密切相关的，要求尽快确定

子系统的划分是以业务模式作为基础的，根据南京研讨会的讨论结果，总公司有意引入一柜制的管理办法，基于这样的要求，我们在设计系统的功能分配，建议对于业务管理的功能分成以下几个子系统：
1) 数据录入/复核子系统
数据录入/复核子系统提供批量数据录入与复核的功能，其录入的内容与具体的业务部门无关。系统除提供上述基本功能外，另提供岗位日结，工作考核等管理功能
2) 新契约管理子系统
团体投保计划书
新契约管理子系统可提供从投保申请到回执登记的业务跟踪。如果新申请在核保通过后为手动生效，则提供生效处理
3) 核保子系统
团体投保计划的预核保、健康加费、职业加费、特约、责任特约、约定免赔额、免赔比例、免责期等。发体检通知、特约与要求加费通知。
业务日结、工作考核。
4) 柜面子系统
是直接面向客户服务的功能集合。包括：收付费（与收单登记合二为一，要求收费与收单登记必须在当日业务结束前完成）；各项批改的申请受理与处理；对于需提交其它部门的保全业务的受理；理赔报案的受理；简易理赔。
柜面业务日结、工作考核。业务单证领用与收回、备用金领用与收回。
5) 理赔子系统
立案、调查、理算、结案。
业务日结、工作考核。
6) 客户管理与客户服务子系统
新建客户档案、已建客户档案的整理（归并、订正）、合同的订正。小批量通知、清单的打印。客户状态、合同状态的跟踪。
非标准退保金、生存金、养老金的调整给付处理。
结案后赔付金额的追加处理。
7.1.3 后台批作业
1) 自动核保
2) 首期对帐
3) 生效处理
4) 养老金首期申请后处理：生成养老金给付计算表
5) 理赔结案后处理：生成理赔周期性给付计算表
6) 生成生调清单（按被保人年龄，扣调比例，按被保人、被保人联系地址、被保人所有保单（保单号、保单的联系地址））
7) 生成续期收费的应收记录（生成12个月的续期收费）
8) 生成生存金给付的应付记录 一柜制后，生成金及养老金首期给付（及生存金现金领取方式的续期给付）的确认是否还需在保全岗完成还是在柜面完成要定一下。确认与非确认在手续上究竟有多少差别，譬如首期是否要提交身份证复印件？是否要本人亲自办理而不能委托办理等。
（首期或领取方式为非银行转帐的续期：生成待确认记录；领取方式为银行转帐的续期非终身生成金：生成应付记录，2、终身生成金：被保人年龄小于等于系统参数设定的年龄时生成应付记录，大于时按比例抽查生调，但未抽中的生成应付记录，抽中的生成待生调确认记录）
9) 生成养老金给付的应付记录（首期：生成待确认记录；续期：1、有保证领取年龄或期限的，在保证期内，生成应付记录；2、无保证领取的，被保人年龄小于等于系统参数设定的年龄时生成应付记录，大于时按比例抽查生调，未抽中的生成应付记录，抽中的生成待生调确认记录）
10) 生成理赔周期性给付的应付记录（对于终身给付的，生成到系统指定的年龄，以后的生成确认记录）
11) 根据生调结果生成生成金的应付记录
12) 根据生调结果生成养老金的应付记录
13) 根据调查结果生成周期性给付的应付记录
14) 满期处理
15) 失效处理
16) 永久失效处理
17) 生成各类统计结果
18) 生成各种打印记录
8. 下一步设计要求
按本设计报告给出的框架，列出系统服务层的SERVICES清单与界面清单，对于业务逻辑目前可列出与流程无关的计算型SERVICES的清单，与流程有关的界面及SERVICES目前无法进一步设计，要求中国人寿尽快提供实务，并在分析的基础上才能确定。
在列出清单后，对于系统服务及SERVER的启动与关闭等处理应当进行规格说明，对于计算型的SERVICES则可直接进行概要设计。
各项设计要按下列要求进行，并遵守公司的设计规范。
8.1.1 CLIENT端设计要求
开发工具是VB。
在界面设计时必须按要求填写界面设计表（见附表）。每个界面有一唯一编号，如果界面是通过父类继承的，则要写明父类的编号。对于有上下调用关系的界面要填写上级编号与下级编号。对于有触发服务请求的要填写请求的接口SERVICES编号。
如果是操作型主窗口则需填写操作码。
8.1.2 SERVICES设计要求
开发工具为TUXEDO，UNIX/C。
在SERVICES设计时必须按要求填写SERVICES设计表（见附表）。每个SERVICES有一唯一SERVICES名，对于接口SERVICES，由于同一个SERVICES有多个CASE，每个CASE对应于由CLIENT发出的一个服务请求，因此在设计时应进一步说明请求的编号与名称。对于数据库对象操作的SERVICES要说明支持的数据库类型。
在设计时要说明调用的上下游关系。
8.1.3 函数设计要求
开发工具为UNIX/C。
在函数设计时必须按要求填写函数设计表（见附表）。若是基本函数有一唯一的函数名，若是子函数，则在主函数下要求有唯一的函数名。
在设计时要说明调用的上下游关系。
8.1.4 批作业设计要求
开发工具为UNIX/C。
批作业是可独立运行的可执行程序，其源程序形式为C的main()函数。批作业设计时必须按要求填写批作业设计表（见附表）。每个批作业有一唯一的可执行程序名。对于批作业，要说明运行的时间（日终/月终/年终/任何时候等）、运行条件（作业的先后次序）及业务约束（用于什么业务，在什么情况下运行等）。
在设计时要说明批作业中调用的函数或SERVICES。
9. 结束语
本文是应用系统的构建方案，下一步的设计要求在本方案的框架下进行，并满足规范要求。

北京科比亚公司系统设计组

2003/3/20

界面清单
序号
类型
编号
名称
调用者
父类
主要功能
备注

类型：MDI/MDIHELP/MAIN/CHILD/POPUP/RESPONSE/确认窗口/提示窗口/警告窗口

SERVICE清单
序号
类型
名称
交易号
交易名
调用者
主要功能

类型：0：系统服务/1：接口服务/2：数据检查服务/3：计算服务/4：数据库对象服务

函数清单
序号
调用者
类型
名称
主要功能

类型：0：基本函数/1：子函数（子函数清单以一个批作业或SERVICE为单位做一清单，概要设计时较为复杂的需附加结构图）

批作业清单
序号
名称
主要功能

界面设计表
项目标识

项目名称

设计人

设计日期

界面编号

界面名称

类别

操作码

上级编号

父类

功能描述

页号

调用
操作
界面编号
交易编号
操作
界面编号
交易编号
操作
界面编号
交易编号

说明：
界面文件联接：
界面：
评审意见：

注：类别：MDI/MDIHELP/MAIN/CHILD/POPUP/RESPONSE/确认窗口/提示窗口/警告窗口

设计图表
项目标识

项目名称

设计类别

设计编号

页号

功能描述

类型

设计人

设计日期

评审意见：

SERVICE设计表
项目标识

项目名称

设计人

名称

类型

相关数据库

设计日期

交易编号

交易名称

通讯数据类型

功能描述

页号

附图

源文件

文件联接

被调
类别/编号：
调用
类别/编号：
外部数据结构
编号：
设计描述
输入：

返回：

逻辑说明：

评审意见：

类型：CS /CI/CK/CC/CO
返回数据结构中第一个数据为结果状态：0表示成功，其它为错误代码

函数设计表
项目标识

项目名称

设计人

设计日期

函数类型

函数名称

调用者类型

调用者名称

功能描述

页号

附图

源文件

文件联接

库名

函数原型

调用
函数名：
外部数据结构