（业务管理）核心业务系统
业务开发规范
核心业务系统业务开发规范
文档修订记录
修订日期 变更编号 变更描述 修订方法 修订说明 修订人
20131023 新增文档
20150605 修改文档 修改
完善编码规则、冲抹账
交易处理说明，新加了
超时时间一小节。
陈乾
修订方法：新增/修改/删除
目录
1 前言 .........................................................................1
2 名词解释 .....................................................................1
基础版版本 ................................................................1
项目版版本 ................................................................1
3 环境清单 .....................................................................1
前台硬件要求 ..............................................................1
前台软件要求 ..............................................................1
后台硬件要求 ..............................................................2
后台软件要求 ..............................................................2
4 提交工具说明 .................................................................2
5 版本管理方案 .................................................................2
基础版版本 ................................................................2
提交流程 .............................................................3
基础版版本管理制度 ...................................................6
项目版版本 ................................................................8
接收和提交流程 .......................................................8
项目版版本管理制度 ..................................................12
6 项目版本交互方案 ............................................................14
中心与项目版本交互方案 ...................................................14
中心与项目 Bug交互方案 ...................................................14
中心与项目优化交互方案 ...................................................15
中心与项目需求交互方案 ...................................................15
中心与项目上线后交互方案 .................................................15
7 多项目支持方案 ..............................................................16
8 缺陷管理方案 ................................................................17
1 历史数据清理
采用外挂任务，逐笔完成历史数据清理。原分区切换方式，在分区被使用、表被锁时，
会造成切换失败。
设计模块时，应注意明细表和历史表的设置。
2 多法人
独立法人模式
独立法人模式下，各法人间相互独立，均可作为独立系统运行，法人间业务交互采用系
统间往来方式完成，法人间数据隔离。
存在系统开关量及参数表，可为多个法人指定使用何种参数与产品体系。
准分行模式
准分行模式下，各法人作为主体法人的分支机构存在，由系统参数决定各法人间、法人
与主体法人间的数据是否隔离或共享。法人间业务交互采用系统内往来方式完成。
但同样存在系统开关量及参数表，为多个法人指定使用何种参数与产品体系。
技术层面
多法人的法人代码应对开发人员透明，平台应能根据参数配置，自行选择对账户表、对
参数表、对登记簿、对系统表使用何种法人代码。
3 多层机构管理
机构分类
机构应支持多层级关系和网状关系。
机构应可分为管理机构、账务机构、营业机构几种大类。
机构关系
系统应支持多种类机构关系定义，各机构间不存在明确上下级关系，均由参数表配置决
定机构系统。各业务处理应遵守参数决定的机构关系。
机构关系应可灵活扩展，可随意调整。
机构关系应支持但不限于如下关系种类。
账务关系
管理关系
报表关系
凭证关系
制卡关系
4 交易设计
交易分类
系统应对系统内使用的交易有严格的划分，从业务来源上至少分为如下几大类。
账务交易
查询交易
维护交易
联机批量
日终批量
不同交易应使用不同的流程号，以便于日结时流水勾对。所以交易处理应优先考虑效率
问题。
交易流程
所有交易中，应只通过不同条件，处理调用不同业务构件完成业务处理。即交易中不存
在业务处理，交易是业务处理流程的体现。
事务控制
所有事务控制均由平台统一完成，对于有特殊要求的，应使用平台统一提供的事务控制
方法，完成局部事务控制。
对账机制
所有外围、渠道业务处理，应有统一的流水表或业务日志表登记，以便于各渠道日终对
账要求。
5 账户管理体系
系统内应有统一的账户登记表，用于记录各客户账户和系统账户。对于负债分户账，应
形成客户账户到系统账户的对照表，以便于检索。
客户账户
卡
活期一本通
定期一本通
存折
系统账户
现金分户账
凭证分户账
资金账户
负债分户账
贷款分户账
会计内部账
集团账户
6 业务风险控管
录入复核制
在交易定义中，交易应支持录入+复核、直通+授权多种处理模式。此模式应可以通过系
统参数动态调整。
录入复核制的交易统一登记，统一商定，统一模式处理。
权限控制
系统应从多个角度完成业务操作的权限控制，如：
柜员角色及权限，用于在柜员层定义柜员可以操作哪些交易 ---长亮已有
交易使用权限，定义哪些交易哪些级别的柜员可做。
产品使用权限，定义哪些交易、哪些机构可以使用哪类产品。
币种及限额使用权限，定义哪些机构、哪些柜员可以使用哪些币种及使用的额度。
分行使用权限，定义哪些产品、哪些交易可以在哪些机构使用。
科目使用权限，定义哪些科目可以在哪些机构、哪些交易中使用。
授权机制
系统支持以下 3种授权驱动模式：
1、前台交易流程驱动。
前台交易流程驱动，由交易开发人员在前台程序中编写代码触发，授权后交易发往后台，
平台检查授权合法性。
交易开发人员根据业务个性逻辑，可以在域后事件、或者通信前处理中编写代码，实现
授权。
交易开发人员调用公共处理模块提供的构件，传入参数：授权柜员级别、授权提示信息。
前台授权只支持本终端授权。
2、参数驱动。
参数驱动，由交易开发人员针对本交易配置授权参数，平台触发，授权后，平台检查授
权合法性。
如果触发条件配置为无条件授权，则不管交易发生的金额大小，均提示授权。
如果触发条件配置为有条件授权，需要继续配置触发条件符号、条件字段值，如金额档
次等，满足条件则提示授权。
如果授权终端配置为跨机构授权，需要继续配置授权机构级别、授权机构等。
参数驱动授权支持本终端授权、跨终端授权、跨机构授权。
3、后台交易流程驱动
后台交易流程驱动，由交易开发人员在后台程序中编写代码触发，授权后，平台检查授
权合法性。
交易开发人员调用公共处理模块提供的构件，传入参数：授权柜员级别、授权提示信息、
授权终端标志等参数。
后台交易流程驱动授权支持本终端授权、跨终端授权、跨机构授权。
多种授权驱动同时存在时：
触发的先后顺序为：前台交易流程驱动、参数驱动、后台交易流程驱动。依次检查授权
合法性。
授权方式由最后一种驱动模式决定。
授权合法性，按模式中最高的级别进行检查。如授权柜员级别，该授权柜员的级别需满
足所有模式的要求。
警告机制
在交易过程中，系统提供警告机制，当柜员操作时遇到警告信息，程序不会继续执行，
当取消这次操作时，程序会以回滚的方式执行，抹掉前面执行的痕迹。
提示机制
在交易过程中，系统提供提示信息的机制，但提示并不会影响交易的进行，仅仅起到
提示的作用。
业务查证
所有业务应在前台留有原始业务界面，以便于后续监督要求时，能够打开原业务界面检
查。
事中监督
系统应有参数可控制交易是否需要进行事中监督，且系统应有统一处理过程完成事中监
督。事中监督应有明细记录可查。
事后监督
事后监督应与事中监督类似。
身份证核查
核查结果登记在客户层，核查明细信息登记在账户层。
1、系统以前台按钮方式提供统一的身份证核查入口。
2、交易开发人员在后台程序中调用公共处理模块提供的构件，完成客户层的核查结果、
账户层的核查明细信息登记。
3、平台在系统流水表中登记该笔流水是否有身份核查。
黑名单
黑名单包含客户层、账户层两种不同维度。
1、黑名单登记。系统提供黑名单录入交易。
2、黑名单检查。交易流程中进行客户信息和账户信息检查时，对于存在黑名单中的客户
或账户返回对应的提示、警告，或拒绝交易。
客户不良信息
1、不良信息登记：
手工登记。系统提供不良信息录入交易。
自动登记。交易开发人员在客户发生欠息、欠费用、账户司法冻结等不良记录的业务场
景中，调用系统提供的不良信息登记构件，登记不良信息。
2、不良信息检查：交易流程中进行客户信息检查时，对于存在不良信息的客户返回对应
的提示、警告，或拒绝交易。
7 日历管理
系统应提供日历管理，用于登记本年度的工作日与节假日，系统应提供生成函数，统一
生成标准日历，再交由管理人员自行调整特殊节假日。
系统应提供统一的日历处理方法，用于处理到期日遇节假日的顺延问题。
8 编码规则管理
编码规则
系统内的编码应统一管理，由系统提供方法统一生成。编码中可定义总长度、组成元素、
各元素长度、及元素特定值。
简要说明
编码规则生成支持参数界面化配置，开发人员可以通过前台参数维护交易配置。
编码规则支持核心公用字段处理、如交易日期、机构号、柜员号、币种等。
编码规则支持公用参数定义必须传入，不传入的情况下报错。
编码规则支持非公用字段参数传入处理、模块自定义特殊处理。
编码规则支持非公用字段参数固定值处理，如存款证明-CKZM。
编码规则支持序号种类、校验位标志处理等。
表结构说明
编码规则表
kapp_bmguiz：
字段名 类型 中文描述 是否可为空 说明
ZHSCDAIM VARCHAR2(10) 编码生成代码 否 编码规则唯一标识，与编码
规则组成表中对应。
ZHSCDMMS VARCHAR2(200) 编码生成码描
述
否 编码规则中文描述。
BMCHANGD NUMBER(19) 编码总长度 否 定义编码的总长度，必须与
编码规则组成表中对应编码
组成代码总长度相等。
SUOSHUMK VARCHAR(4) 所属模块 否 定义的编码属于哪个模块，
用于各模块特殊处理传入。
CZZHOUQI VARCHAR(1) 重置周期 否 序号重置周期，列表值：
0-无需重置
D-按日重置
M-按月重置
Y-按年重置
用于登记变更系统序号参数
表记录。
编码规则组成表
kapp_bmgzzc：
字段名 类型 中文描述 是否可为空 说明
ZHSCDAIM VARCHAR2(10) 编码生成代
码
否 编码规则唯一标识，与编码
规则表中对应。
XUHAOOOO NUMBER(19) 序号 否 自定义编码各组成代码顺
序号定义。
BMZCLIEB VARCHAR2(8) 组成代码 否 组成编码规则最小单元。
目前定义成静态列表，开发
人员不可自定义。
JIOYRIQI-交易日期
JIGOUHAO-机构号
GUIYDAIH-柜员代号
HUOBDAIH-币种
XUHAOOOO-序号
CANSZH01-参数值 01
CANSZH02-参数值 02
CANSZH03-参数值 03
CANSZH04-参数值 04
CANSZH05-参数值 05
CANSZH06-参数值 06
CANSZH07-参数值 07
CANSZH08-参数值 08
CANSZH09-参数值 09
CANSZH10-参数值 10
BMZCMIOS VARCHAR2(200) 组成代码中
文描述
否 对上述组成代码的中文描
述，便于理解，如 CANSZH01-
卡 BIN号
QISWEIZH NUMBER(19) 起始位置 是 定义组成代码所取值的起
始位置，不定义默认为 0
（从第一位开始截取）
ZCCHANGD NUMBER(19) 组成长度 否 组成代码长度定义。
BUWEIZHI VARCHAR2(100) 补位值/固定
值
是 组成代码实际所取值长度
小于组成代码长度定义时，
左补位值定义，不定义时默
认为 0；如果特殊处理标志
定义成 2-固定值，此值即为
定义的固定值（不定义报错）
BUWFANGS VARCHAR2(1) 补位方式 是 列表字段，0-左补位，1-
右补位。默认为左补零。
ZHZCLEIX VARCHAR2(1) 组成类型 否 列表字段，0-无关 ，1-校
验位，2-序号种类。
如果定义成 1-校验位，获取
校验位值；
如果定义成 2-序号种类，将
作为序号种类传入序号生
成方法获取序号。
TSCHULBZ VARCHAR2(1) 特殊处理标
志
否 列表字段，1-是，0-否，2-
固定值。
如定义成 0-否，除公共字段
（交易日期、机构号、柜员
号、币种）外，传入参数必
须输入；如果定义成 1-是，
各模块特殊处理，并将对应
处理方法注册 IOBUS,同时
通知管理员；
如定义成 2-固定值，补位值
/固定值必须定义。
开发人员需要完成
开发人员可通过前台编码规则参数维护交易定义所需编码。
录入成功后，可以通过 0003交易查询出编码组成，如图：
实例说明
界面配置编码规则如下：
如自定义卡号生成编码规则：
卡号编码配置说明:
卡号编码：KAHAO99001 ，长度：18 ，所属模块：CD ，重置周期：0
卡号编码组成：卡 BIN号 + 卡号种类 + 分行代码 + 序号 + 校验位
（1）卡 BIN号组成代码：CANSZH01，组成长度：6，组成类型：2，特殊处理标志：1
（2）卡号种类组成代码：CANSZH02，组成长度：2，组成类型：2，特殊处理标志：1
（3）分行代码组成代码：CANSZH03，组成长度：2，组成类型：2，特殊处理标志：0
（4）序号组成代码：XUHAOOOO，组成长度：7，补位值：0，组成类型：0，特殊处理标
志：0
（5）校验位组成代码：CANSZH04，组成长度：1，组成类型为：1，特殊处理标志：1
1、手工准备数据插入编码规则表(kapp_bmguiz)
2、手工准备数据插入编码规则组成表(kapp_bmgzzc)
3、编码生成使用事例代码：
IoApGenCodeRule ApGenCodeRuleAPI =
();
IoApCodeRuleStru
cplIoApCodeRule=();
(sZhscdaim);
(sFenhdaim);
(sChanphao); //卡模块特殊处理字段，其他模块不需要。
String sBmguiz = (cplIoApCodeRule);;
("GenCodeRule: %s", sBmguiz);
注意事项
1、请严格按照表结构说明配置代码规则。
2、如果组成代码配置为公用字段“JIOYRIQI”，将会与重置周期进行强制匹配，如果
按天重置，拼日期字段；如果按月重置，截取前 6位，右补零；如果按年重置，截取前 4位，
右补零。
3、如有他模块特殊处理，在 iobus上注册、本模块服务实现后，及时通知管理员。
序号管理
系统中序号应由统一参数表统一生成，以规范序号使用。不同序号提供自身序号种类及
生成规则，系统由统一方法生成。
序号参数表
序号参数表（kapp_xuhocs）：
字段名 类型 中文描述 是否可为 说明
空
XUHOZLEI VARCHAR2(32) 序号种类 否 序号参数表唯一标识。
XUHAOOMC VARCHAR2(32) 序号名称 是 序号种类对应的中文描述
CZZHOUQI VARCHAR2(1) 重置周期 否 序号重置周期，列表值：
0-无需重置
D-按日重置
M-按月重置
Y-按年重置
用于登记变更系统序号参
数表记录。
SCJIOYRQ VARCHAR2(8) 上次交易日期 否 上次交易日期，与重置周期
一并使用，决定是否新增还
是修改序号参数表记录。
XUHAOOOO NUMBER(19) 序号 否 保留已获取序号的下一序
号值
SUOSHUMK VARCHAR2(4) 所属模块 否 用于标识序号参数记录归
属模块记录。
ZHSCDAIM VARCHAR2(10) 编码生成代码 是 关联编码规则表中编码生
成代码
ZHSCDMMS VARCHAR2(200) 编码生成代码
描述
是 编码生成代码中文描述
事例说明
如生成存款证明序号：
IoApSeqGenStru cplIoSeqGenStru = ();
IoApGenSeqNo ApGenSeqNoAPI = ();
(()); //非必传
(sXuhozlei); //必传
(sXuhominc); //必传
(); //必传
(); //必传
long seq = (cplIoSeqGenStru);
("GenSeqNO: "+seq);
柜员流水号管理
系统内柜员流水号应分类管理，不同类型交易使用不同的流水号规则以便于日终流水勾
对。
流水号的生成应注意其连续性，同时应注意获取流水号时数据库锁的问题。
业务编号管理
系统内对于不同业务，应统一生成对应的业务编号，以便于查询和统计。
中间业务代码管理
系统内对于中间业务的处理，应统一生成对应的中间业务代码，以便于查询和统计。
9 摘要及备注管理
系统交易应提供统一的摘要代码及摘要信息，以便于统计分析需要，同时系统应允许柜
员在交易时对交易内容进行备注。
强制要求。
10 账单管理
电子回单
系统针对对公账户应提供电子回单功能，应可针对母账户、子账户提供不同的回单内容。
系统应支持电子回单的自动打印，如条件许可，应支持电子回单的自动分发。
应支持打印次数记录，及费用收取。
对账单
系统针对对私账户应提供如下两类对账单：
余额对账单
明细对账单
系统应支持对账单的周期自动打印，如条件许可，应支持对账单的自动分发。
应支持打印次数记录，及费用收取。
11 综合签约管理
系统应提供统一的签约信息登记，各模块完成本模块的签约后，应同时登记综合签约登
记簿，以便于在客户账号变更、销户时准确检查。
12 通知机制
短信通知
对于账户余额变动、关键信息变更、密码变更应提供可参数定制的短信通知机制。
1、模块开发人员在程序中调用短信通知构件，作为短信通知的入口。
2、模块开发人员配置短信发送条件参数表，满足条件的才进行短信登记和发送。
3、模块开发人员配置短信内容参数表。
客户/账户备注
备注主体可以为: 账户、客户、借据。
平台统一检查备注信息，根据备注类型返回强制备注、提示备注。
信息发布
系统应支持机构内、机构间、柜员间的信息发布，信息发布应能够做到自动提示，信息
发布应支持广播机制和点对点机制。
此类信息发布应考虑远程授权的使用。
13 参数管理
参数管理机制
对于参数表的维护，系统应提供统一工具，生成统一风格的参数维护交易。
参数变更明细
对于参数数据变更，系统应能够准确登记参数变更明细备查，应能够登记时间、操作人
员、授权人员、变更内容。
14 加密管理
敏感数据分类
系统应对数据库中敏感数据在查询后进行脱敏处理，如特殊客户的姓名、特殊账户的户
名，行内员工的工资信息等。
系统也应支持从生产库数据导出后的脱敏处理。
密钥管理
系统应提供统一的密钥管理机制，所有密钥统一存放，统一分发，确保密钥的安全。
文件加解密
系统应提供软加密功能，对于系统提供的带有敏感数据的文件，应提供统一方法进行加
密处理，对于外系统进入的加密文件，应由统一方法进行解密，以减少维护成本。
系统应提供开关量，指定是否加密、是否验密、是否加密验密。
密码管理
密码是进过加密处理后存放在系统数据库表中的客户的交易口令。
1、密码设置：调用公共处理模块提供的密码设置构件，传入参数：密码载体、密码类型、
密码、密码所属渠道。系统检查是否满足设定的密码风险化管理规则。
2、密码改密：调用公共处理模块提供的密码改密构件，传入参数：密码载体、密码类型、
新密码、密码所属渠道、原密码。系统校验原密码，检查新密码是否满足系统设定的
密码风险化管理规则。
3、密码校验：调用公共处理模块提供的密码校验构件，传入参数：密码载体、密码类型、
密码、密码所属渠道。系统对密码进行校验，密码错误时，进行最大错误次数的控制。
15 日志管理
总体说明
V7系统在应用层以 Log4j作为日志输出机制，采用分类分级方法，完成不同类型日志的
输出与控制。
日志分类
V7系统中将日志分为：
Debug-调试日志
Info-关键信息日志
Error-错误日志
Method-方法标记日志
Parm-参数日志
SQL-数据库日志
Profile-性能日志
日志分级
V7系统中，日志的分级由客户自定义，日志级别不限制，可由不同的日志分类组合而成。
日志级别在 文件中进行配置，在该文件的<busiLogConfig>业务日志配
置标签下的<levelDefine>业务日志级别定义标签下的<level>开始标签和</level>中定义日
志级别值，分别为 debug调试日志、info关键信息日志、error错误信息日志、method方法
标记日志、parm参数日志、sql数据库日志、profile性能日志；并且给<level>标签加个
ID,接下来在<levelConfigs>标签下的<levelConfig>给 type=“busi_onl”和 type=
“busi_batch”配置上对应的<level>标签 ID即可，如下图所示：
日志输出
V7系统中，所有日志均采用对应的日志方法完成打印。
Debug-调试日志
Info-关键信息日志
Error-错误日志
Method-方法标记日志
Parm-参数日志
SQL-数据库日志-由平台层统一控制，应用层不处理。
Profile-性能日志-由平台层统一控制，应用层不处理。
日志使用规范
1、方法进出前，必须使用 标记方法的进出。
2、进入方法后，必须使用 打印方法的输入参数。
3、方法中所有调试信息必须使用 打印。
4、对于 日志，仅限于关键流程节点处使用。
5、对于 日志，应用层可不打印，由平台统一输出。
6、SQL日志仅在出现数据库异常时由平台统一打印。
7、Profile日志为平台统一性能调优日志，一般不开启。
16 业务日志
交易日志
系统在平台级应提供交易日志，详细记录交易的输入输出报文，交易日期、交易时间，
以及交易成功与否、交易错误信息。
业务登记簿
系统内各业务模块应提供业务明细登记簿，对模块内的业务处理过程应能准确、明晰的
登记。以便于后续的统计分析和报表需求。
参数修改日志
对于系统内参数维护更新，应提供登记簿，记录其变更信息。
数据更新日志
对于系统内数据维护更新，应提供登记簿，记录其变更信息。
业务处理日志
系统应提供统一的日志打印函数，以便于开发人员打印调试日志。也便于日志分级。
系统对于业务处理日志应按交易分类存放，业务处理日志中应只包含业务处理过程、调
试信息和报错信息，平台处理过程应尽量简化，便于查阅。
系统对于平台处理信息，应记录明晰的日志，以便于监控平台分析系统运行状态。平台
处理日志应分类存放，如错误日志、启动日志、通讯日志、工具使用日志、文件传输日志等。
17 冲抹账交易处理
一般冲抹账机制
一般冲抹账采用数据库物理操作过程反向来完成，所有使用标准 DAO完成的数据库操作，
其记录均会被平台方法记录在对应的记录表中，而自定义更新 SQL，应在使用前调用平台方法，
记录更新的前值与后值。
冲正时，系统会根据冲正先后顺序，逆向完成数据库操作。
特殊冲抹账机制
特殊冲抹账机制是指在使用一般冲抹账机制的情况下，不能达到正确的冲正结果，需要
开发人员二次加工的冲正机制。
该机制提供两种方案：
1、 采用回调函数方式，开发人员针对特殊节点，编写特殊处理函数，由平台
在对应节点调用该函数完成特殊处理。
2、 采用特殊冲正交易，由开发人员针对原正交易，自行编写冲正交易完成原
交易的冲正。
系统冲抹账机制
系统提供了统一的冲抹账机制及冲抹账入口，此类机制通过简单配置完成大部分的冲正
功能，对于特殊业务，允许在总体冲抹账流程中加入自定义处理过程。
冲抹账交易应能控制冲抹账业务范围，控制冲抹账的日期间隔。系统内能保留冲抹账的
处理过程。
冲正控制表
冲正控制表（kapp_bzrvkz）中约定了一些对表冲正的一些基本控制参数，如能不能冲，
怎么冲，冲前需要做一些检查，冲后要做什么处理以及表级操作，字段级操作。
字段名 字段中文名 字段作用 字段使用说明
CHONGZJB 冲正级别 定义冲正的级别，表级冲正是
对表中所有的字段，配置表级
冲正要配置冲正相关标志为
函数相关
0-表级冲正
1-字段冲正
SJKBMNGC 数据库表名称 需要被冲正控制的表名称 表级冲正时使用
SFZHGDMX 是否账单明细标志 如果选是的话，对插入动作不
会执行删除动作，而是调用下
面的明细冲正实现类来完成
冲正
1-是
0-否
BJLSCBZH 表记录是否删除标志 当是否账单明细选择为否时，
才需要配置这个字段。
是就真正的删除表中记录，否
则就保留这条记录，将记录状
态改为-1
1-是
0-否
ZIDUANMC 字段名称 需要被冲正控制的字段名称 字段冲正时使用
CHZHXGBZ 冲正相关标志 如果是 0-无关，就是保留当
前值；1-参数相关则需要考虑
ZIDGXFSH，ZDBZKCBZ，
BZFGFSHI，TSHZXZBZ这几个
字段的配置；函数相关就是自
0-无关
1-参数相关，
2-函数相关
己自定义的一些冲正实现类。
注：如果该字段没有填写，则
对于数值型字段，默认处理是:
更新数值= 当前值-(原交易
后的值-原交易前的值)
对于字符型字段，默认处理是:
恢复到更新前的值
ZIDGXFSH 冲正字段更新方式 对于字符型字段只有覆盖这
种方式，差值只有数值型字段
才会考虑。
0-覆盖需要配置 BZFGFSHI字
段
0-覆盖，1-差值
ZDBZKCBZ 字段变值可冲标志 拒冲，字段变值不改变。
当变值可冲时，变值的冲正方
式有五种，未定义，无关，覆
盖，差值，其他保留当前值。
0-拒冲，1-可冲
BZFGFSHI 变值覆盖方式 这个字段当 ZIDGXFSH为覆盖
是才有意义。
如果是 1-恢复到交易前的值，
首先要判断变值是什么类型
的，如果变值是数值型时，可
以覆盖也可以差值。如果是字
符型，则没有差值这种方式。
如果变值是BigDecimal对象，
则要拿精度去格式化变值进
行处理。
0-保持当前值
1-恢复到交易前的值
TSHZXZBZ 特殊值冲正标志 根据特殊值的范围，以及特殊
值冲正标志判断特殊值可不
可冲。
特殊值的范围在 TSHZCZLB中
定义。
0-不包函时拒冲，
1-不包函时拒冲
2-包函时可冲
3-包函时拒冲
TSHZCZLB 特殊值冲正列表 定义特殊值的范围，和特殊值
冲正标志相对应
参数相关时使用
CHONGZHL 冲正实现类 当冲正相关标志为函数相关
时：
函数相关时使用
表或字段冲正函数
CHZQSHXL 冲正前实现类 表或字段冲正前调用的函数
CHZHSHXL 冲正后实现类 表冲正后调用的函数，字段级
不用
MXCHGZHL 明细冲正实现类 当使用账单明细的时候，冲正
插入时调用的冲正函数。
函数相关时使用
YUXUCZBJ 表允许冲正标志 这里约束了是否允许表冲正
的机制，视具体业务而定。
0-不允许冲正
1-可当日冲正
2-可隔日冲正
3-可跨年度冲正
总得来说，冲正控制表定义了字段级以及表级的冲正方式，以及冲正流程。
在冲正的时候，我们要了解表中存在的三个字段：
交易前的值：要冲的这笔流水在交易发生前的值。
交易后的值：要冲的这笔流水在交易发生后的值
当前值：字段当前的值，如果还有后续交易，这个值还会变化。
重点说下一下几个字段：
1，冲正相关标志
如果为 0-无关的话则保持字段的值不变；
如果为 1-参数相关时，则需要考虑冲正控制表中其他一个字段的配置，如字段变值，特殊
值；
如果为 2-函数相关时，调用冲正实现类来完成冲正处理；
2，考虑是否拒冲，有两种情况会导致拒冲
a,字段的值被后续交易改变过，并且字段变值可冲标志为拒冲；
b,字段的当前值为特殊值，而特殊值根据特殊值列表检查出为拒冲；
3，如果认为该字段可以冲正，则需要考虑其他字段的配置，按照以下流程：
（1）对于数值型字段：
a，如果冲正相关标志没配置的话，则默认处理：
更新数值=当前值-（原交易后的值-原交易前的值）
b,如果为无关则保留当前值
c,如果为覆盖并且字段被后续交易改变了，我们还要考虑变值覆盖标志：
0-保持当前值 1-恢复到交易前的值
如果为覆盖并且字段的值没有被后续交易改变，则恢复到交易前的值
d,如果为差值则同默认处理: 更新数值=当前值-(原交易后的值-原交易前的值)
其他情况保持当前值不变
（2）对于字符型字段:
a, 如果冲正相关标志没有配置的话默认处理: 恢复到更新前的值
b, 如果冲正相关标志为无关,保持当前值
c, 如果冲正字段更新方式为覆盖并且字段的值被后续交易改变了,则需要考虑
变值覆盖方式
0-保持当前值 1-恢复到交易前的值
如果冲正字段更新方式为覆盖并且字段的值没有被后续交易改变，则恢复到交易
前的值
对于字符型字段来说冲正字段更新方式不会为差值，所以程序中没有考虑这个值
冲正交易开发流程
配置冲正控制表
自定义冲正实现类
如果想使用自定义的冲正特殊处理方法，要实现 aplt上的 ApBzrvCallbackIntf接口,在
实现类中定义自己的方法让冲正主处理方法去调用。如果选择账单明细，需要重写
prcDetailProcess方法；如果不选择账单明细，需要重写 prcMainProcess方法；如果是字段
级的处理，需要重写 prcFieldProcess方法。
进行冲正
输入错账流水和交易日期即可进行冲正操作。
18 超时时间
系统支持多层级超时时间设置，主要包括接入层超时时间、平台级超时时间、应用级（交
易级）超时时间、数据库级超时时间等设置。
Tuxedo超时时间：ubbltts中 SVCTIMEOUT值设置(单位为秒) ，最少设为应用中处理请
求耗时最长的服务所需时间的两到三倍。
平台级超时时间：用于设定联机/批量交易处理时间最大值控制（单位为毫秒），目前在
中配置。
应用级(交易级)超时时间：用于设定指定交易超时时间设置（单位为毫秒）。目前在交
易信息表中配置。
数据库级超时时间：用于设定 JDBC连接超时时间设置（单位为毫秒）。目前在
中配置。
优先级：数据库级 > 交易级 > 平台级 > 接入层。
19 特权记账
系统应提供特权记账交易，以备特殊时期调账用，此类交易应严格控制其使用权限及所
有使用的科目。此类交易应包括如下类型的账务处理：
红蓝字记账
一记双讫
多借多贷
表外账务
所涉及账户应包括客户账、系统内账户、表外账、现金及待销账。
20 凭证打印
系统应提供统一的凭证打印模式。由后台统一提供打印数据，由前台定制打印格式。对
于通用凭证，系统应提供工具自动生成打印格式。
对于凭证中共性数据，平台应自动提供数据源，后台仅提供必要的业务数据源。
21 补打印
系统需要提供补打印功能，以应对打印时的异常情况。此类打印应有严格的权限控制及
使用限制，如开户类交易不得重打、补打印超过两次后需要更高级柜员授权等。
22 业务信息查询及打印
总体要求
系统内业务信息查询应有统一的实现模板，应支持业务信息查询及打印的要求。系统内
业务信息查询分为如下两方面：
业务查询
明细查询（笔数自动返回）
查询范围应支持指定日期范围内的查询，支持模糊条件查义，查询时应考虑查询效率问
题。
业务信息查询应支持历史库数据查询。对于历史库数据查询应支持收费处理。
打印要求
业务信息查询打印应支持多次打印，也应支持文件生成，同时应支持对打印操作的收费
处理。
23 报表及批处理
系统应提供统一的日终批量处理服务，批处理交易应确保高效、准确，同时也应支持出
错数据的再次处理。
批处理交易应能支持跨日处理，批处理时应尽量减少换日时间，所有批处理及联机业务
均应考虑 7*24小时业务支持。
系统对于报表处理应提供统一的报表文件生成方法，开发人员应仅关注业务数据的选取
和加工，报表样式应能够做到灵活配置。
批处理及报表平台应支持交易分组及组内、组间并发。
报表及批处理应支持单独交易的独立运行，独立运行时也应支持并发。
24 联机批量业务
系统应提供统一的联机批量处理平台，该平台的业务处理应以不影响正常联机业务为前
提，同时确保高效、准确。
联机批量业务应包含容错处理，对于出错数据，允许调整后再次处理。
联机批量业务应支持定点触发和任务触发两种模式。如代扣业务可采用定点触发，报文
处理可采用任务触发。
25 客户合并
支持参数化的客户合并功能，通过指定参数表配置需要合并的内容及处理方式，由交易
发起，自动完成客户信息的合并。
1、各模块库表的设计时，应该考虑到客户合并功能，合并的库表应登记客户号。
2、各模块参与配置客户合并参数表。
26 机构撤并
支持参数化的机构撤并功能，通过配置参数表，由交易发起，自动完成业务数据和账务
的撤并操作。
1、各模块库表的设计时，应该考虑到机构撤并功功能，撤并的库表应登记营业机构号和
账务上级机构号。
2、会计模块设置科目时应该有一个属性，用来标识该科目的账务是否属于对外营运核算
还是行内核算科目，当账务机构并入营业机构时，可以通过该属性知道该科目的账务
是并入营业机构，还是并入营业机构的账务上级。
27 历史明细管理
大表拆分
系统在设计时应考虑大数据量的表，应对大数据量的表拆分为实时表和历史表两类。
数据清理
系统在设计时应对历史数据清理有一套完成的处理机制，该机制应安全、高效，不影响
日常业务处理。
历史库查询
系统在设计时应考虑历史数据及历史库的查询方案，应考虑历史数据库不同表、不同库
的不同处理方案，也应考虑前台界面是否统一入口。
28 数据处理
数据脱敏
系统在对特殊数据查询、导出时，应存在统一机机制对特殊数据进行脱敏处理，以确保
数据安全性。
数据采集
系统应存在完整的数据采集机机制，以便于向第三方、数据中心、监管等提供符合要求
的数据。
数据移植
系统应提供一整套数据移植机制，提供旧系统中间表新系统的移出、移入机制。同时
系统应提供基于中间表的数据有效性验证机制。
数据移植应确保安全、高效，支持组内并发处理。
外系统数据导入
系统应提供统一的数据导入接口，以便于第三方数据的接入。
29 绩效考核
系统在设计之初应考虑对柜员的绩效考核机制，同时也应考虑如客户经理、揽存量等考
核指标。
30 界面操作风格
账号录入方式
系统对客户账号的录入风格应保持统一，有统一的方式处理是否刷磁、是否读卡、是否
手输。
对于特殊项的录入，如频率、周期等，应采用统一按钮，方便柜员录入。
系统整体操作风格要保持一致，同类要素的录入、检查风格应保持一致。
账号后面必须跟序号域。
界面排列
界面排列风格应统一一致，界面元素长度、高度、排列顺序等应按统一要求摆放。
帮助/提示信息
系统应对柜员提供界面元素的录入提示信息，也应对交易事项、交易功能提供帮助。
辅助按钮
系统应提供多种辅助按钮，帮助柜员录入复杂信息。
联动查询
系统对联动查询应采用统一机制触发，统一调度。联动查询的返回信息，系统也应统一
处理。
身份证核查及验印
身份证核查结果应在后台登记，同一交易中多次核查应能够统一登记。
验印结果同上。
31 交易发布管理机制
交易准入的时间范围、渠道、机构控制。
参数化渠道的启用关闭时间。
32 行内报文规范
报文格式说明
为了更好地规范银行各应用系统间的通讯，采用统一的通讯报文格式规范，并使统一的
报文格式与各应用系统当前所支持的格式尽量兼容，使各应用系统做到最少的修改就能达到
规范格式，使系统间通讯的使用和管理简单方便。
通讯报文格式由三部分组成：通讯报文头、通讯报文体、通讯扩展体组成，如下所示：
通讯扩展体咱不使用。
通讯报文头
此部分内容使用固定长度格式，所有字段使用统一的规范，为公共使用系统间管理字段，
由以下字段组成：
字段格式如下：
字段名 字段中文名 字段类型 字段长度 使用说明
PKGLEN 报文总长度 CHAR 8 前补 0
PKGMAC 报文校验码 CHAR 16 计算全报文得到
PKGSNO 报文标识号 CHAR 20 全行唯一
PRCSCD 交易码 CHAR 8 交易码，不足 8位右补空
格
TIMEOUT 超时时间 CHAR 6 整数值转换成字符串填
充本域，不足6位左补"0"，
单位：秒。
PKGCLI 发起节点名 CHAR 9 按统一命名
PKGSRV 接收节点名 CHAR 9 按统一命名
PKGVER 密钥版本号 CHAR 8 安全管理统一发布
PKGCHN 发起渠道号 CHAR 3 按统一规范命名
PKGSYS 系统标识号 CHAR 3 按统一规范命名
PKGSAV 报文头保留 CHAR 34 增加头内容时使用
报文头中各字段内容，由各应用系统平台通讯部分统一管理。
报文总长度（8字节）
不包括自身 8直接的报文中长度，不足 8位左补 ”0”。
报文校验码（16字节）
（1）由加密厂商提供 API计算 MAC值。
（2）原始数据：仅通讯报文体（XML）
报文标识号（20字节）
报文标识号全行唯一，按每个发起渠道独立编号，具体编码格式如下：
报文标识号 = 发起渠道（3位） + 8位日期(yyyymmdd) + 9位序号（在指定日期内唯一）
交易码（8字节）
填写交易码，不足 8位右补空格。
超时时间（6字节）
整数值转换成字符串填充本域，不足 6位左补"0"，单位：秒。
用于发起节点控制交易的执行时间，若不限制交易执行时间则填写固定值“000000”。
发起节点名（9字节）
全行统一命名，用于识别渠道节点，不足 9位右补空格。对于每一个发起节点，若节点
传输消息携带有与节点特定相关的信息（如报文校验码 MAC，密码信息 PIN），则该节点需要
参与同一编号定义。
具体编码格式如下：
发起节点名 = 渠道（3位） + 6位节点号（例如：000001）
使用场景：每个节点密钥都不一样，密文数据在节点在传输需要转换处理。
要求：每个柜面终端加密密钥不一样，传输的消息 MAC计算的 KEY也不一样；每台 ATM设备
加密密钥和计算 MAC的密钥也不一样；各交易和管理系统（服务端系统）各自分配一个加密
密钥和计算 MAC的密钥。
规划：每个柜面终端分配一个节点；每台 ATM设备分配一个节点；每个交易或管理系统分配
一个节点；
渠道 节点 描述
0GM000001 柜面节点 0000010GM
0GM000002 柜面节点 000002
ATM000001 ATM节点 000001ATM
ATM000002 ATM节点 000002
0QZ 0QZ000001 大前置
0WY 0WY000001 网上银行
0HX 0HX000001 核心系统
节点加密数据流转：
注: PIK和 PVK的说明参考 节。
PIK为加密 PIN（交易密码、查询密码）的密钥，每个节点密钥是不一样的。
PVK为主机节点（核心系统）用于存储密码的密钥，与 PIK不一样，后者主要用于节点间的传
输，前者仅在主机节点使用。PVK使用的加密算法采用业界标准的算法，与 PIN加密的算法区
分开。
接收节点名（9字节）
编码格式同”发起节点号”，参考 节。
密钥版本号（8字节）
加密平台统一发布，用于获取渠道相关的密钥，不足 8位右补空格。如果加密平台对此
不作要求，该域可以填写固定值。
要求密钥管理平台对于密钥的管理能够按如下方式组织：
/密钥版本号
/节点 1（3位渠道号 + 位节点号）
/PIK PIN加密密钥
/MAK 计算 MAC密钥
/节点 2（3位渠道号 + 位节点号）
/PIK PIN加密密钥
/MAK 计算 MAC密钥
/PVK 计算 PIN OFFSET的密钥（详见后文）
/密钥版本号
/节点 1（3位渠道号 + 位节点号）
/PIK PIN加密密钥
/MAK 计算 MAC密钥
/节点 2（3位渠道号 + 位节点号）
/PIK PIN加密密钥
/MAK 计算 MAC密钥
/PVK 计算 PIN OFFSET的密钥
同时密钥管理平台需提供如下 API用于日常 PIN、MAC的操作。
发起渠道号（3字节）
该笔业务的原始发起渠道号，渠道号全行统一编号，具体见业务编码规范。
系统标识号（3字节）
保留，目前与发起渠道号一致。
报文头保留（34字节）
该域值可自行扩展，应用平台底层不使用此域信息值，由业务程序自行获取和处理。
通讯报文体
因此报文体部分使用标准 XML格式，XML节点名以服务端为准，客户端按服务器数据字
典打包。
报文体的内容由几个对象组成，按报文的流向分为输入报文和返回报文，不同类型的报
文具有的对象内容不同。
xml报文格式语法说明
字符集
XML报文字符集固定为：UTF-8。
基础结构
禁止报文体中再嵌入报文。即 xml报文里的报文体不能含有可拆解的报文。
XML报文元素的名称规范化。
Xml报文结构支持对象和数组两种结构，通过这两种结构可以表示各种复杂的结构。
1、对象：表示为"object"元素，name属性为对象名称。
<object name="A">
</object>
表示对象 A。
2、数组：表示为"array"元素，name属性为数组名称，length属性表示数组大小。
<array name="C" length="10">
</array>
表示数组 C，数组大小为 10。空数组，请将 length属性值设置为"0"。
注意：同一数组的元素类型必须保持一致，由服务端自行校验，报文解析程序不做处理。
3、普通字段：表示为"field"元素，name属性表示属性名称，value属性表示属性值。
<object name="A">
<field name="a1" value="v1"/>
</object>
表示对象 A拥有属性字段 a1，值为 v1。
对象内部可包含普通属性、嵌套对象、嵌套数组，例如：
<object name="a">
<field name="a1" value="xxxx"/>
<field name="a2" value="xxxx"/>
<object name="b">
<field name="b1" value="xxx"/>
</object>
<array name="c" length="1">
<object name=""> <!—array元素内部的 object元素 name属性为空-->
<field name="c11" value="c11_value"/>
<field name="c12" value="c12_value"/>
</object>
<object name=""> <!—第 2条明细-->
<field name="c21" value="c21_value"/>
<field name="c22" value="c22_value"/>
</object>
</array>
</object>
表示对象 a，拥有属性 a1、a2、对象 b、数组 c。对象 b拥有属性 b1。
注意： 数组内部只能嵌套对象或数组，不能包含普通属性;数组内部嵌套的对象或数组的 name
属性约定为空。
输入报文
输入报文是指渠道发往后台的通讯数据报文，由交易系统对象、交易公共请求对象和交
易业务输入对象组成。
a)交易系统对象（sys）
对象的主键为 sys，其中包含的字段有：
序号 字段名称 中文描述
1 prcscd 交易码（4位交易码）
2 debug 固定值：0
3 timeout 交易执行时间。
（参考报文头“超时时间”域）
b)交易公共请求对象(comm_req)
对象的主键为 comm_req，包含的内容为业务上定义的公共请求变量。
说明：渠道接入的公共请求要素，请参考《核心系统标准对外服务接口》文档。
c)交易业务输入对象(input)
对象的主键为 input，包含的内容为交易输入信息。
d)报文示例
注意：此处仅包括报文正文，不包括固定长度的报文头信息。
<?xml version="" encoding="UTF-8"?>
<root>
<object name="sys">
<field name="prcscd" value="5021"/>
<field name="timeout" value="30"/>
</object>
<object name="comm_req">
<field name="userid" value="010001"/>
<field name="brchno" value="000001"/>
</object>
<object name="input">
<field name="acctno" value="6223443214321432"/>
</object>
</root>
返回报文
输出报文是指后台交易完成后返回给前台的通讯数据报文，由交易系统信息、交易公共
响应对象、业务输出对象、业务打印数据对象组成。
a)交易系统信息(sys)
对象的主键为 sys，其中包含的字段有：
序号 字段名称 中文描述
1 pckgsq 报文流水
2 erorcd 错误码
3 erortx 错误信息
b)交易公共响应对象(comm_res)
对象的主键为 comm_res，包含的内容为业务上定义的公共响应变量。
说明：渠道接入的公共响应要素，请参考《核心系统标准对外服务接口》文档。
c)交易业务输出对象(output)
对象的主键为 output，包含的内容为交易输出信息。
d)交易业务打印数据对象(printer)
对象的主键为 output，包含的内容为交易打印信息。
e)报文示例
注意：此处仅包括报文正文，不包括固定长度的报文头信息。
<?xml version="" encoding="UTF-8"?>
<root>
<object name="sys">
<field name="pckgsq" value=""/>
<field name="erorcd" value=""/>
<field name=“erortx” value=""/>
</object>
<object name="comm._res">
<field name="brchno" value="000001"/>
</object>
<object name="output">
<field name="trandt" value="20120513"/>
<field name="transq" value="0001000801"/>
</object>
<object name="printer">
<field name="tranam" value=""/>
</object>
</root>
