济南市住房公积金管理中心结算应用系统建设项目技术要求Word格式.doc

济南市住房公积金管理中心结算应用系统建设项目技术要求Word格式.doc

《济南市住房公积金管理中心结算应用系统建设项目技术要求Word格式.doc》由会员分享，可在线阅读，更多相关《济南市住房公积金管理中心结算应用系统建设项目技术要求Word格式.doc（25页珍藏版）》请在冰豆网上搜索。

2.1.1准备阶段 15

2.1.2实施阶段 16

2.1.3测试阶段 17

2.1.4上线阶段 17

2.2项目实施周期 18

2.3项目进度安排 18

2.4项目的工作内容及成果文档的提交 18

2.5系统测试 19

2.6项目验收 22

2.7风险分析及规避措施 22

2.8项目人员配置要求 22

三服务要求 23

II

一、技术要求

1.1项目名称

济南市住房公积金管理中心结算应用系统建设项目

1.2项目总体情况

1.2.1建设背景

为了贯彻落实《住房公积金基础数据标准》（以下简称《基础数据标准》）建立科学、合理、规范的住房公积金业务数据体系，提高住房公积金管理信息化水平，促进住房公积金监管系统建设，提升住房公积金服务能力，2014年12月9日住建部发布了《关于贯彻落实住房公积金基础数据标准的通知》，通知要求之一：

为确保资金安全，提供便捷服务，各地公积金中心信息系统在贯彻《基础数据标准》过程中，要同时接入全国统一的住房公积金银行结算数据应用系统，与受托银行进行直联支付结算，实时获取银行结算数据，实现资金、业务和财务信息的自动平衡匹配，建立先进、实用、安全的信息系统。

为落实住建部《关于贯彻落实住房公积金基础数据标准的通知》的要求，济南市住房公积金管理中心在已建设的基础数据贯标的基础上完成结算贯标建设。

1.2.2建设目标

按照《关于贯彻落实住房公积金基础数据标准的通知》要求，建立科学、合理、规范的住房公积金业务数据体系；

通过住建部统一系统实现与银行的联网结算，实现业务驱动资金结算，业务账、资金账、财务账自动平衡校验，三账统一、自动对账、日清、日结等功能，提高住房公积金信息化水平，提高住房公积金业务办理效率，实现资金高效运作、安全管理的目标。

1.2.3建设要求

按照住建部《关于报送全国住房公积金结算应用系统上线工作计划的通知》、《关于贯彻落实住房公积金基础数据标准的通知》《住房公积金银行结算数据应用系统-与中心公共接口标准V1.1.11》的要求，公积金中心须在2016年年底前完成结算应用系统接入工作。

结合济南中心实际，按照通知要求，公积金中心该项目主要建设要求为：

1、对济南住房公积金管理中心现核心业务系统进行升级改造，核心业务系统的软件平台BSP和工作流平台支撑的资金类交易全面改造，实现现资金结算平台及住建部结算应用平台的同时应用；

结算应用系统开发建设同时，确保核心业务系统安全稳定运行，实现无缝平滑切换；

完成帐务处理体系升级改造，完善资金对账、异常处理等机制，确保公积金财务核算体系安全、稳定、高效。

2、按照《住房公积金基数数据标准》及结算应用系统建设要求，全面满足住建部数据贯标要求，严格按照标准要求实现各类交易的对接工作，利用原有结算系统的软件平台FSP完成结算系统改造，缩短实施时间，确保数据的安全、稳定、高效。

3、投标方必须按照建设要求提供详细的建设方案。

1.3总体设计要求

本次项目必须严格按照《住房公积金银行结算数据应用系统-与中心公共接口标准V1.1.11》的要求开发标准接口实现接入。

具体要求如下：

1.3.1总体架构要求

公积金中心在中心管理信息系统中必须按照《住房公积金银行结算数据应用系统-与中心公共接口标准V1.1.11》的标准新建支付结算中心端标准接口，中心信息管理系统通过标准接口实现与银行结算数据应用系统端到端的连接。

1.3.2结算平台改造要求

改造前为模式一，改造后为模式二。

改造完成后FSP向住建部结算平台发出和接收的报文和文件格式以住建部结算平台规定的格式为标准。

具体见1.3.4和1.3.5节。

1.3.3交易报文规范设计要求

1.3.3.1交易报文格式

交易报文应采用XML格式，遵循XML规范。

交易报文由两部分组成，交易报文头和交易报文体。

其中交易报文头信息在报文头（head）节点内，交易报文体信息在报文体（body）节点内。

需要作加密处理。

1.3.3.2交易文件传输

交易文件经过编码处理后，嵌入到交易报文中，和交易报文一起发送或接收。

文件格式使用GBK字符集编码，按换行符’\n’划分记录，按分割符’|’划分字段，数据项中不能有半个汉字、分割符’|’、换行符’\n’。

相同文件名不能多次提交。

n文件内容压缩编码

发送方传输联机文件时：

将文件内容读出进行ZIP压缩，再进行BCD编码，得到文件内容报文域。

接收方接收联机文件时：

将文件内容报文域取出BCD码字符串,再进行ZIP解压缩，得到原始文件内容。

n长度限制

根据实际的交易情况，以及通信方式来定最大长度限制。

现系统最大定义为10M.

1.3.4接口规范及设计要求

1.3.4.1公积金中心系统发起

n输入控制信息

节点

节点属性

中文描述

数据类型

必输

说明

HEAD

SendDate

发送方日期

Char（8）

M

yyyymmdd

SendTime

发送方时间

Char（6）

Hhmmss

SendSeqNo

发送方流水号

Char（26）

全局唯一

TxUnitNo

交易机构号

Char（15）

机构编号

SendNode

发送方节点号

发送方在系统中注册的编号

公积金中心节点号

TxCode

交易代码

参见服务列表

ReceiveNode

接收方节点号

接收方在系统中注册的编号

银行节点号

CustNo

客户编号

Char（32）

银行给公积金中心的客户编号

由银行决定是否需要

OperNo

操作员编号

Char（21）

n输出控制信息

TxStatus

交易状态

Char

（1）

0成功；

1失败

RtnCode

返回码

Char（20）

00000-为成功

RtnMessage

返回信息

Char（160）

ReceiveDate

接收方日期

ReceiveTime

接收方时间

ReceiveSeqNo

接收方流水号

BDCDate

采集系统日期

BDCTime

采集系统时间

BDCSeqNo

采集系统流水号

1.3.4.2采集系统发起

n输出格式报文头

YYYYMMDD

HHMMSS

由采集系统WEB方式提交的，这里同发送方日期

由采集系统WEB方式提交的，这里同发送方时间

由采集系统WEB方式提交的，这里同发送方流水号

n输入格式报文头

接收方节点编号

1.3.5结算平台接口和公积金业务系统交易设计要求

接口应包括公积金中心发起的服务接口、结算采集系统发起的服务接口。

交易开发改造包括公积金业务系统发起接口数据前和接收结算平台数据后的业务和账务处理。

具体设计要求如下：

1.3.5.1公积金中心业务系统服务接口和交易开发改造

公积金中心各类资金交易均为实时联机完成，驱动财务系统完成记账，本次项目建设内容中，各类交易均需关联核心系统改造，在相关内容如下：

l接口探测

用于测试系统服务是否正常。

l单笔付款

公积金中心直联发送付款交易（如住房公积金提取业务，包括销户支取业务、外部转移业务），结算银行同住建部签约后，核心系统BSP首先根据原交易日期原交易流水号向FSP发送‘交易结果查询’，中心FSP侧向住建部FSP发起查询，如果OldTxStatus（原交易状态）为0（成功）核心BSP直接记账，不再发送单笔付款申请，如果OldTxStatus为1（失败），BSP会重新组装报文通过FSP向住建部发起付款申请，提取原因为销户提取时，本金由归集账户支出，打入收方账号（CrAcctNo），利息发生额须单独体现（IntAmt），另注明付息账号（DeIntAcctNo）以及收息账号（DeIntCrAcct），中心记账成功后登记公积金个人提取登记簿、个人明细账、单位明细账，更新个人分户账、单位分户账。

l单笔收款

公积金中心发起的收款交易（比如住房公积金归集业务），结算银行同住建部签约后，核心系统BSP首先根据原交易日期原交易流水号向FSP发送‘交易结果查询’，中心FSP侧向住建部FSP发起查询，如果OldTxStatus（原交易状态）为0（成功）核心BSP直接记账，不再发送单笔付款申请，如果OldTxStatus为1（失败），BSP会重新组装报文通过FSP向住建部发起付款申请，待住建部返回成功后，BSP完成记账。

l批量付款

支持公积金中心发起批