李晓寒

摘要：自2015年以来，全国各地的住房公积金信息系统正在进行贯彻国家基础数据标准的升级改造，在贯彻基础数据标准，接入住房公积金银行结算数据应用系统的过程中，各地住房公积金中心也在以此为契机，不断探索、打造符合住房公积金行业改革发展的信息系统，在检查四川省贯标工作的过程中，就如何完善住房公积金信息系统也有了一些新的思路和想法，在这里提出以供大家交流、探讨。

关键词：住房公积金：SOA；多维核算：结算：核查

住房公积金信息系统应该具有四个基本的子系统。一是用于对外提供服务的综合信息服务平台：二是进行内部业务处理的核心业务系统：三是与银行进行资金和数据交互的银行结算平台：四是通过数据共享为信息系统提供协同辅助的联网核查系统。

一、综合信息服务平台

（一）硬件部署

图1为住房公积金综合信息服务平台硬件部署图。综合考虑系统安全与效率，平台应划分DMZ区作为综合信息服务平台的核心硬件区。DMZ区的隔离采用防火墙和网闸设备，互联网端隔离采用防火墙，核心业务系统端则采用网闸进行完全的物理隔离。在DMZ区中可部署多个服务器，如承担网站、服务等发布的应用服务器，存储数据的数据服务器，实现身份认证、电子签章等用途的功能服务器。这样在保证前台访问效率的同时，也确保了内部业务系统信息数据的安全。

在目前互联网+公积金概念引导下，综合信息服务平台硬件的前置也可以作为一种硬件建设的解决思路。平台中的防火墙及DMZ区可前置部署在相关企业的云服务器端。虽然此种硬件部署方式节省了硬件采购及维护费用，但是为保证数据安全，系统需对传输数据进行脱敏及加密操作，以避免硬件前置的数据安全风险。

（二）关键技术

1.整体架构

SOA、B/S和C/S架构是目前Web Service架构中最流行的三种，C/S架构多应用在早期的公积金业务系统中，B/S架构则应用于目前主流的公积金业务软件系统中，以提高系统维护管理能力。SOA是面向服务的体系架构，其所具备的耦合松散、粗粒度、高开放性等特点十分符合综合信息服务平台设计初衷。综合信息服

SOAP、WSDL、UDDI是Web Service重要的三要素，SOAP用来描述传递信息的格式，WSDL用来描述如何访问具体的接口，UDDI用来管理，分发，查询Web Service。

2.组件技术

平台基于模块化理念设计建设，采用面向对象的组件技术则是较好的解决方式。面向对象的组件技术可以实现跨硬件平台支持独立的软件开发和运行环境。组件如同一个“黑箱”，实现功能的技术方法将被忽略，工程师可以以“即插即用”的方式拿来使用，避免了传统API方式因编程模式不同而带来的使用不便。目前，组件技术已经得到了飞速的发展，一些主流标准如COM/DCOM、CORBA等在兼容性、可移植性、重用性和独立性上也得到了很多的突破。

（三）功能要点

平台业务办理应以即时办结为目标。利用网上业务大厅等服务渠道进行业务即时办结。目前，即时办结的最大困难是无法核实有关信息的真实性。离、退休支取、公积金贷款的提前还清等业务，信息来源于公积金业务系统的，经系统判断后可进行即时办结。公积金贷款申请、汇缴、其它原因支取等业务可通过单位身份认证及相应信息核查系统的协同进行业务的在线即时办结。

平台的信息发布必须严谨、规范。对于信息的发布，应设置审核、审批流程，并明确责任人操作权限。在进行系统操作留痕的同时，可选择信息发布渠道。确保平台发布信息的准确性和规范性。

平台对于职工及单位信息应进行充分保护。在对个人及单位公积金信息进行保护的同时，应采用加密、脱敏等技术手段加强对平台DMZ区用户注册信息的保护。

交流互动服务应及时和规范。可将需要交流互动的渠道如在线咨询、热线等，进行整合，由专人负责统一管理回复。在保证交流互动服务即时的前提下，回复内容应准确、专业。

二、核心业务系统

住房公积金内部业务系统的核心是财务核算。根据现代会计理念，信息系统应在原有基础上增加以事项为基础的多维核算功能，实现业务、资金、财务三账自动核算、平衡匹配，能够进行事后监督，并为将来的业务决策提供有力依据。

（一）归集业务

图3为优化后的信息系统归集业务办理流程图。理想状态的实现前提是在于对挂账的清理。整个流程本质可以归结为一个订单支付流程，每笔汇缴业务在单位确认清册、支付后所生成的订单号应具有唯一性，其作为辨识每笔业务的标识贯穿于整个业务过程中。这样才可能做到三账的自动平衡匹配。

（二）支取业务

因为支取业务量非常大，支取业务办理的系统优化关键点在于银行回单录入电子档案系统，并自动作为附件归档到相应凭证。其可采用具有ORC（光学字符识别）技术的高速扫描仪加以解决（如图4）。

（三）贷款发放业务

贷款发放业务改造主要任务是对银行返回结果的优化。传统公积金系统贷款发放是通过银行过渡户进行划转，其中涉及每笔资金两至三次的资金划转过程。其结果返回的时效性及可匹配度受到严重影响。银行应根据中心要求准确返回交易结果供中心核算使用（如图5）。

（四）贷款回收业务

贷款回收业务的系统改造流程相对较大，可从原有完全委托银行贷款模式调整为中心贷款自主核算。模式的调整可以解决每家银行计息方式的差异，无法自动对账的问题。方式的调整为对冲还贷、网厅即时办结提前还款等业务提供了可能性（如图6）。

三、银行结算平台

公积金与银行的结算平台，首先应提供多样化的现金交易渠道，如银行柜台、网银、POS机、支付宝等，并应具有实时性：与银行数据的交互应具有双向性，银行不但可以返回交易结果，中心也可以将辨识每笔业务的标识字段发送给银行，银行在相应的回单等凭证上呈现供中心使用：核心业务系统与银行结算平台的对接应以调用接口的方式，最大程度地保证交易安全的同时，可将结算功能嵌入到业务系统中加以控制、使用。

四、联网核查系统

目前各中心多采用分别与当地相关部门联网实现核查。中心应当积极接入各部委、各地政府建设较成熟的信息平台，实现大数据时代的信息共享。核查系统对外提供标准的Web Service接口。对内则根据自身核心业务系统技术特点采用J2EE平台下的应用或者axis、CXF等Web Service接口，实现对服务的调用，做到对数据的可控交互。

五、结束语

文中分别阐述了住房公积金信息系统的四个子系统，提出了相应子系统的设计理念。在实际应用中，这四个子系统的相互协同也至关重要，合理的接口设计、高度的数据共享、深度的系统嵌入将使子系统相得益彰。良好的系统协同将使住房公积金信息系统在效率及安全上达到极致。