【毕业学位论文】(Word原稿)公积金综合业务管理信息系统的设计与实现-软件工程

1 中图分类号： 学校代码： 10055 密级： 公开 硕 士 专 业 学 位 论 文 公积金综合业务管理信息系统的设计与实现 of of 文作者 指导教师 副教授 申请学位 工程硕士 培养单位 软件学院 学科专业 软件工程 研究方向 答辩委员会主席 评 阅 人 南开大学研究生院 二一三年 八 月 2 南开大学研究生学位论文作者信息 论文题目 公积金综合业务管理信息系统的设计与实现 姓 名 李亚男 学号 2220110968 答辩日期 论文类别 博士 学历硕士 硕 士专业学位 高校教师 同等学力硕士 院 /系 /所 软件学院 专业 软件工程 联系电话信地址 (邮编 )： 备注： 是否批准为非公开论文 否 注：本授权书适用我校授予的所有博士、硕士的学位论文。由作者填写 (一式两份 )签字后交校图书馆，非公开学位论文须附南开大学研究生申请非公开学位论文审批表。 保密期限 20 年 月 日至 20 年 月 日 审批表编号 批准日期 20 年 月 日 南开大学学位评定委员会办公室盖章 (有效 ) 注： 限制 2年 (可少于 2年 );秘密 10年 (可少于 10 年 );机密 20年 (可少于 20年 ) 摘 要 I 摘 要 随着中国经济的不断发展和人民生活水平的日益提高，购买住房已经成为涉及千家万户切身利益的热点、重点问题。商品房作为一种特殊的商品，如何利用公积金在其购房过程中起到了重要的作用。同时，如何安全、方便、全面、统一管理住房公积金也成为公积金管理者迫切需要解决的问题。 本文将通过工作中的实际案例， 在符合国家相关管理 规定的基础上 ， 结合用户的具体需求，从系统架构、信息安全、良好兼容、便于管理、易于操作和使用等方面进行研究并提供完整的 公积金综合业务管理信息系统 解决方案。 住房公积金 综合业务信息管理系统 的建 设采用基于开放的 持跨平台、跨数据库运行。采用基于组件的开发和集成方式，提供工作流、表单、数据、业务逻辑、报表的定制及其他用户自定义组件，通过 制不同角色拥有不同的权限。 实现住房公积金管理中心“统一决策、统一管理、统一制度、统一核算”的目标。 关键字： 住房公积金 I s s on to of As a of to in an of to of by in in of on of of to to a of on is In of of 2录 录 第一章 绪 论 . 1 言 . 1 究背景和意义 . 1 究目标及内容 . 2 文组织结构 . 4 第二章 系统的需求分析 . 6 求概述 . 6 能需求 . 7 要系统需求 . 7 心业务功能需求的结构 . 8 取业务需求 . 8 务核算业务需求 . 10 统数据需求 . 13 统运行环境的需求 . 13 行环境 . 13 能需求 . 14 第三章 系统的总体设计 . 15 体设计思路 . 15 统架构设计 . 15 统功能模块设计 . 17 据库结构设计 . 18 据结构设计要点 . 18 辑 结构设计 . 20 统涉及的技术介绍 . 22 第四章 系统的详细设计以及实现 . 25 统的部署环境 . 25 统主要模块详细设计 . 26 集模块 . 26 取模块 . 31 款模块 . 35 算模块 . 41 理模块 . 46 计模块 . 54 统的界面设计 . 58 户界面 . 58 关的管理操作界面 . 58 第五章 系统运行测试与后期分析 . 60 目录 试过程及结果 . 60 术难题及解决方案 . 61 期分析 . 62 第六章 总结与展望 . 63 目开发总结 . 63 术展望 . 63 参考文献 . 64 第一章 绪 论 1 第一章 绪 论 言 随着中国经济的不断发展和人民生活水平的日益提高，购买住房已经成为涉及千家万户切身利益的热点、重点问 题。商品房作为一种特殊的商品，如何利用公积金在其购房过程中起到了重要的作用。同时，如何安全、方便、全面、统一管理住房公积金也成为公积金管理者迫切需要解决的问题。 我国 于 1991年开始 试 行住房公积金制度 以来，到现在 已 经 有了二十多年的历史。随着国家住房体制改革的逐渐 深入， 以及国家相继颁布并实施的 住房公积金管理条例 、 住房公积金行政监督办法 、 关于完善住房公积金决策制度的意见 、 全国住房公积金监督管理信息系统管理暂行办法 、 关于住房公积金管理若干具体问题的指导意见 等相关法规 ，对 住房 公积金管理工作中的 存 在的 问题提出了指导 性 意见。要求 各住房公积金管理中心发挥职能，进一步 加强 住房公积金 的 管理，提出对 现有 的公积金管理模式了 进行人事和制度方面的 机构改革，完成公积金管理中心 从 地方 的 集中管理，实现 住房公积金中心 “统一决策、统一管理、统一制度、统一核算 ”的 四统一管理 。 究背景和意义 本项目的需求单位某市住 房公积金管理中心按行政区划下设 1个中心、 13个管理部，原有系统采用 C/每个管理部和中心都安装一套系统，各管理部数据存放在本地，需要的时候抽取中心需要的数据上传到中心。 面对公积金发展的新形式，为了 支持公积金管理机构的改革要求，就 需要实现 以住房公积金管理中心为主的集中统一管理模式，统一管理整个中心的资金流、业务流和数据流 ，解决 以前系统中广泛存在的 业务依赖性问题， 提升住房公积金管理中心的管理水平和服务质量 。 为了实现强化管理，提升管理水平，就必须 对现有的归集、提取、贷款、核算等 业务 流程进行流程分析、优化、重组 ， 依据统一的行业标准为各业务流程建立 统一 的 业务规范，并建立完善的辅助决策体系 和 完备的资金保障体系和第一章 绪 论 2 风险控制体系，以实现 住房公积金管理 中心从业务 流程 到服务的统一规范，形成中心完整的业务及管理支持平台。 为了实现公积金集中管理的需要，在机构实现集中管理后，急需实现数据的集中管理。统一的集中管理需要有统一规范的数据，以及为了提升管理水平所必须的具备的数据源。在数据集中的同时，也必须集中 规范 统一 公积金管理中心 以及 其分支机构、业务经办网点的职责权限 ，并在此基础上实现中心整体的业务规范整合 究目标及内容 本论文的主要研究目标是在原有系统的基础上通过对用户需求的详细分析，设计一个基于开放的 持跨平台运行的业务系统 ,以实现住房公积金 “统一决策、统一管理、统一制度、统一核算”的目标。 具体研究内容如下： 1、 建立完善的核心业务系统 通过对 住房公积金 整个 业务流程 进行全面 重组 ， 全面贯彻 相关国家有关公积金的法规 ，规范业务操作 和管理 ，确立 住房公积金管理 中心对住房公积金的主体地位 。 住房公积金的基础业务是整个系统平台顺利运作的保障，只有建立了完善的业务系统才谈得上后续的管理层次。对公积金的每一个业务进行建模分析，将固定的国家政策和相对灵活的地方特色结合在一起制定出符合实际情况的业务模型。在保证遵循国家政策的前提下，实现具有地方特征的业务需求。 将 住房公积金委托银行管理 的委托 模式调整为 “ 中心主体、银行 前台，中心核算、银行结算 ” 的间接直收管理模式 ， 实现中心对业务流与资金流的全面实时管理 。 集中 管理 住房公积金银行账户，在每家受委托银行只选一个网点开立银行存款账户（即主办网点），撤消其他网点的归集户和周转户（只保留委贷基金户）。各网点归集的住房公积金 “通存 ”到主办网点账户，住房公积金的提取、外部转出、贷款发放由中心通过主办网点办理资金划拨。中心根据相关原始凭证进行会计核算，记账到单位和个人，并与业务信息、资金信息核对，确保账证、第一章 绪 论 3 账账、账实相符。 建立财务统计和分析体系，利用系统信息，进行自由组合条件的查询及统计分析，自动生成标准化或自定义格式的数据信息图表，为中心管理决策提供依据。 2、 建立 集中的 数据中心 建立唯一数据中心，实现全市数据集中存储。 不仅方便了数据的管理，提高了数据的利用率，还 为 管理 中心在规避风险、降低成本方面提供系统保障。 3、 实现直归 和委 托相结合的 灵活的归集 管理 模式 不仅需要实现在中心下的直归模式，也要能够实现委托银行归集的委托模式，或者两者都有的混合模式， 允许 中心 可以按实际情况设置管理模式。 4、 建立 标准 的财务管理核算平台 财务核算平台 需要实现中心 统一、 管理部 分级的多账套模式。 提供 包括三栏总账、三栏明细 账、单位帐、个人明细账、内部往来 经费 帐等 。 5、 建立对数据存取的一致性、完整性和优化存取的保障体系 建立有效索引、使用存储过程、清除垃圾数据、使用专用工具优化 满足范式要求的数据库 设计 ，保证数据 结构 的清晰和一致性以及完整性的约束 ，同时避免数据冗余和操作异常 ，保证数据复制、数据抽取的正确。 6、 建立统一 、灵活的权限管理 系统 采用 心可以灵活定义菜单、角色、用户和对应的权限 。 7、 规范个人帐 户管理，树立以 个人帐 户为中心的管理理念 个人账户 管理原则上应确保 身份证唯一 （根据 实际情况，可以适当加上士兵证、外国人员身份证等其他证件类型） ；单位账户 确保 组织机构代码唯一。 并提供身份证清理功能和稽核功能，有效清理系统中不规范的数据。 8、 提供全方位综合服务，强化服务意识 针对各类用户群体推出多元化的服务渠道，根据客户群体的需求和主流趋势的发展， 依托 机 话语音、安全认证等手段，支持随时随地对 公积金 信息的多种查询方式 ，使客户能够享受到全方位多层面的公积金相关服务。通过呼叫中心，用户可以进行业务咨询、投诉、电话查询、语音催缴公积金、催收贷款。通过短信平台可以及时告知 单位、贷款人、职工 ，第一章 绪 论 4 个人的公积金情况。通过邮件通告平台发送公积金帐单，发送通告、通知、警告等其他必要的告知信息。 从而全面提升 中心 的业务经营、管理水平。 9、 防范贷款风险，建立风险评估平台 根据信用、收入变化情况、抵押率或质押率、担保方式、借款人信息变动情况、还款记录、出现逾期情况等风险评估要素评估借款人风险度，以此提高管理的预见性。 10、 提升管理水平，建立内部控制体系 为了防范风险，确保中心自身发展及其经营管理目标的全面实现，查错防弊，堵塞漏洞，消除隐患，保证业务稳健运行，建立包括内部审计、风险预警、会计控制 、授权审批、稽核检查、员工管理的全面内部控制体系，监督管理各项业务的执行过程，降低操作风险，提高控制和化解风险的能力。 11、 适应业务发展需要， 实现业务功能的平滑扩容和升级 采用 基于 术 ，将数据存储和业务逻辑分离，业务逻辑和页面展现分离。采用模块化和层次化的设计思想，使系统有良好的可扩展性和可维护性。 采用 工作流技术，实现业务流程的自动流转和动态配置，大大提高工作效率和用户感受。模块化的设计，能够实现不同业务模块的动态加载。实现系统业务功能的平滑扩容和升级。 12、 提供标准的数据 扩展 接口 提供丰富而 规范的数据 扩展 接口，包括与 委托 银行、缴 交 单位、监管系统、个人征信系统、 短信通知 ，实现资源共享与异地数据交换。 13、 强化管理与过程控制 提供强大的分析和决策支持。为领导提供丰富的信息查询，并为领导关心的重要财务指标进行基准分析，提供决策帮助。领导可以根据自己的工作分工选择关心的信息，并且可以由宏观到微观地追溯分支机构的数据情况。 文组织结构 本论文 共分六章， 各章节结构安排如下： 第一章 是绪论， 介绍项目的 的背景和意义，以及项目的研究目标和主要内容 。 第一章 绪 论 5 第二章分析了市场和用户的需求，通过用户的各项要求 来分析具体功能模块的可行性设计。 第三章是从系统设计的角度来初步架构该系统。一个软件系统的需求分析和系统设计工作做得越充分，后期检测和变更问题就会越少。系统设计从总体思路入手，分析了系统的架构和数据库的架构以及相关的应用技术。 第四章是系统详细设计和系统各模块的界面建设，系统一共分为 系统管理 、归集 、 提取 、 贷款、财务核算 等多个不同要求的模块，详细介绍各模块需要实现的功能要求。另外还图文并茂地解说了具体实现后的相应界面，使用户可以直观的看到模块操作的步骤，然后在项目实现过程中提出更深一步的需 求。 第五章是系统运行测试和后期分析，通过系统 上线 后的试运行以及进一步的难题突破来实现更完整、更符合要求的系统。通过分析发现系统能够很好地满足日常工作的需求。 第六章是针对新技术和新趋势的展望以及对该项目建设中遇到问题的总结 ，通过总结和展望来做好进一步 开发 的准备。通过 系统运行 表明，系统的开发运行得到了终端用户的肯定。 第二章 系统的需求分析 6 第二章 系统的需求分析 需求分析是软件工程中最重要的组成部分，如果需求分析出现偏差或者出现模糊点，都会造成整个系统设计的大差错和大修改，这样可能带来很多不必要的物 质损失和声誉损失。所以，设计软件的先行事项便是需求分析。 而需求分析必须建立在对于客户需求的足够了解和认识上，所以在系统开发前的需求分析主要是与客户的各个部门作深入而广泛的交流，以求弄懂客户的工作流程，细节要求，喜好的方式等等。因此一定要取得客户的支持和帮助。 求概述 本项目的需求单位某市住 房公积金管理中心 ， 其原有管 理规范化程度较高，信息化系统建设已经具备一定基础，新一代信息系统建设应该在解决原有系统问题的同时，考虑到未来 几 年内的业务发展需求，在全国具备先进性和代表性。所以 在本次系统的 开发设计 中 ， 除了满足日常业务需求外， 应主要关注点三个方面的问题： 第一、从系统对 公积金新兴 业务发展支持的角度 来 考虑，系统需要解决包括 核心 业务、 全方位 服务、 广泛 合作 等 方面的 以下 问题： 数据信息的有效 性和一致性 问题 ； 业务产品开发周期及业务开发的系统复杂性问题 ； 全面掌握客户风险问题 ，比如冒提公积金、贷款风险控制等； 与其他合作机构（如电话查询）广泛合作的问题； 第二、从系统对 公积金 管理 与 决策的角度考虑，系统需要在数据及平台 两个 层面 都 提供管理层面的支持，主要表现在 以下两个方面 ： 风险防范与 风险控制问题 ； 资金运作的系 统支持问题 ； 第三、从系统的扩展性 和可维护性 角度考虑，系统需要注意的 以下两个问题 ： 系统 架 构的不合理导致的系统 不能随着业务需求的变化很好 扩展 的 问题 ； 第二章 系统的需求分析 7 系统运行、维护与二次开发的成本 不好 控制问题 ； 能需求 要系统需求 本系统的主要系统需求包括公积金的归集 （汇缴、补缴、转移） 、提取 （支取、偿还） 、贷款 （发放、收回） 、 财务核算 、出纳帐等，具体功能要求如 表 统功能 前台业务 住房公积金归集 住房公积金业务查询和统计报表 住房公积金提取 住房公积金贷款 住房公积金出纳账务核算 其它收付业务 后台核算 住房公积金会计核算 住房公积金财务查询和报表管理 住房公积金绩效考核 系统管理（各项业务参数、组织机构、人员岗位权限等） 其中各部分功能简述如下： 1、 归集：住房公积金归集系统包括了单位注册 、单位停缓缴、单位销户 、公积金汇缴 、公积金补缴、公积金 调动转移 以及 归集统计 查询等业务。 2、 提取：公积金提取业务主要是处理 满足 7大类及各种自定义提取条件下的职工个人公积金的支取、偿还 业务，包括批量提取、委托提取还贷等。 3、 贷款： 主要包括 贷款受理（申请人基本信息的录入、借款事由，借款情况、还款情况、担保抵押情况等）；贷款分级审批（信贷员初审、管理部主任审批、信贷科审批、审贷委员会审批、中心主任审批）；贷款发放（发放前审核、贷款资金出账、贷款资金出账确认）；贷款收回（按计划还款、提前还款、批量收回、重算还款计划表）；贷后管理（贷款逾期、风险状态控制） 。 第二章 系统的需求分析 8 4、 财务：包括财务帐 套、财务科 目的初始设置和财务凭证的自动和手工生成与审核，以及财务凭证的记帐、结帐、对账、 打印 等功能。 5、 出纳账： 中心和银行的出纳帐记账、对账和结账以及账簿打印等 。 心业务功能需求的结构 本系统的核心业务 的功能 需求 的结构 如图 图 心业务功能需求 接下来从以下 3个方面对提取业务和财务核算业务 两个示例 进行需求的详细描述 ，具体从工作流程、功能需求分析、用例描述与分析三个方面进行事例介绍。 取业务需求 提取业务用例图 如图 前台业务 地县管理部 1 地县管理部 2 归集 提取 贷款 后台财务及管理 财务核算 出纳账 系统管理 管理 公积金管理中心 核心业务系统的需求功能组成 第二章 系统的需求分析 9 图 积金提取用例图 表 积金提取用例图 用例名称：提取业务需求 用例参与者：缴交个人 需求说明：支取分 为部分支取与全部支取（偿还）。部分支取需要按照提 取条件的设定进行不同条件选项的录入，并计算出不同的提取 限额。全部支取为销户提取，应根据个人账务计算出定期活期 利息。 第二章 系统的需求分析 10 用例说明： 1、审核提取资格 （ 1）审定购、建、修房提取条件需要满足的条件； （ 2）需要有购、建、修房的房屋产权证号，如果购买二手房的还需要有二手房的购房合同号。如果是新购商品房的需要有购房楼盘的预售许可证号； （ 3）如果申请人的公积金处于抵押状态，则公积金只能以偿还购房贷款条件提取； （ 4）提取是要检测申 请人的个人账户的状态。比如贷款和担保状态，不能销户提取 （ 5）如果申请人的个人账户为冻结、封存的状态不允许提取 （ 6）现有提取的条件不能满足的情况，如允许低保户子女入学、重大疾病的提取等，可以作为自定义提取条件来提取 2、打印支付款凭证：打印支付款凭证（或者转账凭证，提取不了现金，如果是还贷还会出现三套凭证（提取凭证、还款凭证，差额凭证）。凭证上需要有个人的身份识别，再凭证上加个人身份证。支付款凭证要标记是用现金和用支票支付。 3、付款：付款（出现、支付款），提取方式之一可以是个人的账户 与公积金账户直接划账。 4、出账确认：凭证确认，确认款项已经被提走。 务核算业务需求 财务核算 的核心业务 用例 如图 第二章 系统的需求分析 11 图 务核算用例图 财务 核算体系的编码 规则 ： 普通核算 财务 科目设置 ，设定为 322345格式的 5级科目 ： 0级 财务 科目 3位 ，如 122表示 逾期贷款 1级 财务 科目 2位 ，对应银行编码 2级 财务 科目 2位 ，对应管理部门编码 3级 财务 科目 3位 4级 财务 科目 4位 5级 财务 科目 5位 住房公积金 财务 科目设置： 第二章 系统的需求分析 12 总会计科目具体明细科目（管理部 、银行 ） 个人核算科 目： 6位 行政区划 + 7位系统内个人 账户 单位核算科目： 6位 行政区划 + 6位系统内单位 账户 用例说明见表 表 务核算业务需求 用例名称：财务核算业务需求 用例参与者：主管会计、会计 用例说明： 账套设置：对整个系统涵盖的账套进行定义。 账务类别设置：对定义好的账套进行账务体系、级别的设置。 科目维护：科目的增加、关联银行、关联管理部门、启用日期、科目状态的设置和修改。 凭证属性设置：根据前台不同的业务类型定义不同的凭证种类，凭证样式根据核算要求进行设置。要考虑跨管理部的各类业务资金走向 和中间方凭证的处理。 填制凭证：填制凭证分为机制凭证和手工凭证； 机制凭证：通过系统的前台业务产生的业务数据根据相应的凭证模板自动产生凭证。 手工凭证：分为根据未设置过凭证格式的收付业务填制，和直接填制手工凭证而没有其他任何附件的方式。 审核凭证：对所有凭证进行上下级和借贷方平衡性的校验。手工凭证只能单张审核，凭证明细需要列出。 汇总凭证：将所有凭证进行分管理部，分时段汇总，产生汇总凭证。 记账：根据凭证科目进行账务的登记。 结账：当前所有启用科目进行月、季度、年度结账。 对账：根据科目的上下级一致、借贷方 一致的关系进行账务的核对处理。特殊科目，如银行存款还要和出纳账进行核对，财政匹配资金、单位挂账等和相关台账进行核对。 年度账务结转：针对特定时点进行账务的结转： 6月 30日结息后做公积金的个人账务结转； 12月 31日年度结账后，做所有三栏明细的账务结账。 结息： 6月 30日对所有公积金个人账户进行利息的结算。 特殊账务模板：根据各种业务进行模板设置，基本业务：公积金利息的计提、贷款手续费的计算、归集手续费的计算、增值收益的划转、业务收入支出的结转。 特殊账务处理：自动产生特殊业务的业务表单，并填制凭证。 会计报表 定义：根据各种会计报表进行模板设置，基本报表：资产负债表、增值收益表、增值收益分配表。 会计报表编制：通过模板自动读取数据生成会计报表。 第二章 系统的需求分析 13 统数据需求 本公积金系统要能够满足对原有系统的数据使用， 要能够提供监管系统的数据和征信系统的数据，系统在功能上需要加入“数据迁移程序”、“监管数据采集程序”、“征信数据采集程序” ，如图 图 据需求 另外，系统在应用譬如银行、单位、网上业务的数据时， 需要内置数据接口，以便对数据的 导入利用和输出查询。 统运行环境的需求 行环境 本系统采用的是 用的编程语言是 服务器端安装的操作系统是 据库管理系统采用的是客户端安装的操作系统是 原公积金中心系统数据 公积金监管系统数据 征信系统数据 转换迁移程序 住房公积金综合信息管理系统 满足其他数据需求的数据接口 监管数据采集程序 征信数据采集程序 第二章 系统的需求分析 14 能需求 1、 时间特性的要求： （ 1） 普遍情况下： 搜索时间最大不超过 5秒 平均时间在 1 3秒以内 （ 2） 前台业务办理： 页面调用不超过 1秒 页面搜索与打开合计时间不超过 3秒 平均在 1秒内 （ 3） 后台财务及管理 页面调用不超过 3秒 页面搜索与打开合计时间不超过 5秒 平均在 3秒内 2、 系统容量要求 静态用户（注册用户）： 200以上 动态用户（在线用户）： 200以上 并发数： 200以上 。 第三章 系统的总体设计 15 第三章 系统的总体设计 体设计思路 住房公积金管理中心 综合业务信息管理系统 的建 设采用基于开放的 持跨平台、跨数据库运行。采用基于组件的开发和集成方式，提供工作流、表单、数据、业务逻辑、报表的定制及其他用户自定义组件，通过权限约束，控制不同角色拥有不同的权限。通过定制组件，实 现不同的网上业务和公积金综合业务。 数据层的构架是将数据分为基础数据库、历史（查询）库和数据仓库，有效保障基于大数据量、大访问量的数据存取高效快捷，提高系统整体响应性能。客户端采用 过配置管理工具对系统的行为进行配置，按照不同用户的具体需求制作的组件可以通过该配置工具加载到系统。 使用基于组件配置的系统运行方式，可以满足众多客户群体的需要，对于职工个人、单位、中介机构、公证机构、贷款保险办理的公司，根据配置的不同可以在网上业务平台中办理所需的公积金业务。对于公积金营业网点和银行各 代办点，可以通过公积金综合业务平台，受理和办理业务。 统架构设计 住房公积金整体框架决定了系统要采用一种稳定的、高效的、便于扩充的、适应于多种访问渠道的架构，为了满足这样的需要，我们采用三（ N）层结构基于 。 数据库层 选用市场占有率较高的、成熟、稳定的大型数据库 保证数据集中后的大数据量的快速 读写、存储。 业务逻辑层 以 纯 应用层基于组件配置 方式实现不同的业务， 如归集、提取、贷款等。 展现层基于 间件如 负责发布应用和接入前端客户业务操作请求。 客户端一般通过 使用 浏览器 实现 。 系统提供了二次开发的 标准 扩展 接口 ， 中心可以 通过组件配置 、和 组件开第三章 系统的总体设计 16