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

中图分类号： 学校代码： 10055 密级： 公开 硕 士 专 业 学 位 论 文 住房 公积金综合业务管理系统的设计与实现 文作者 指导教师 申请学位 工程硕士 培养单位 软件学院 学科专业 软件工程 研究方向 答辩委员会主席 评 阅 人 南开大学研究生院 二一三年 八 月 南开大学学位论文使用授权书 根据南开大学关于研究生学位论文收藏和利用管理办法，我校的博士、硕士学位获得者均须向南开大学提交本人的学位论文纸质本及相应电子版。 本人完全了解南开大学有关研究生学位论文收藏和利 用的管理规定。南开大学拥有在著作权法规定范围内的学位论文使用权，即： (1)学位获得者必须按规定提交学位论文 (包括纸质印刷本及电子版 )，学校可以采用影印、缩印或其他复制手段保存研究生学位论文，并编入南开大学博硕士学位论文全文数据库； (2)为教学和科研目的，学校可以将公开的学位论文作为资料在图书馆等场所提供校内师生阅读，在校园网上提供论文目录检索、文摘以及论文全文浏览、下载等免费信息服务； (3)根据教育部有关规定，南开大学向教育部指定单位提交公开的学位论文； (4)学位论文作者授权学校向中国科技信息研究所 及其万方数据电子出版社和中国学术期刊 (光盘 )电子出版社提交规定范围的学位论文及其电子版并收入相应学位论文数据库，通过其相关网站对外进行信息服务。同时本人保留在其他媒体发表论文的权利。 非公开学位论文，保密期限内不向外提交和提供服务，解密后提交和服务同公开论文。 论文电子版提交至 校图书馆网站： 。 本人承诺：本人的学位论文是在南开大学学习期间创作完成的作品，并已通过论文答辩；提交的学位论文电子版与纸质本论文的内容一致，如因不同造成不良后果由 本人自负。 本人同意遵守上述规定。本授权书签署一式两份，由研究生院和图书馆留存。 作者暨授权人签字： 2013年 10月 22 日 南开大学研究生学位论文作者信息 论文题目 住房公积金综合业务管理系统的设计与实现 姓 名 学号 答辩日期 论文类别 博士 学历硕士 硕士专业学位 高校教师 同等学力硕士 院 /系 /所 软件学院 专业 软件工程 联系电话 通信地址 (邮编 )： 备注： 是否批准为非公开论文 否 注：本授权书适用我校授予的所 有博士、硕士的学位论文。由作者填写 (一式两份 )签字后交校图书馆，非公开学位论文须附南开大学研究生申请非公开学位论文审批表。 I 南开大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下进行研究工作所取得的 研究成果。除文中已经注明引用的内容外，本学位论文的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任由本人承担。 学位论文作者签名： 2013 年 10 月 22 日 非公开学位论文标注 说明 (本页 表 中填写内容须打印 ) 根据南开大学有关规定，非公开学位论文须经 指导教师同意 、作者本人申请和相关部门批准方能标注。未经批准的均为公开学位论文，公开学位论文本说明为空白。 论文题目 住房公积金综合业务管理系统的设计与实现 申请密级 限制 ( 2年 ) 秘密 ( 10 年 ) 机密 ( 20 年 ) 保密期限 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 In by in on of of by of to to of as of of on is In of of 录 录 第一章 绪 论 . 1 言 . 1 究背景和意义 . 1 究目标及内容 . 2 文组织结构 . 4 第二章 系统的需求分析 . 6 求概述 . 6 能需求 . 7 要系统需求 . 7 心业务功能需求的结构 . 8 取业务需求 . 8 务核算业务需求 . 10 集业务需求 . 13 款业务需求 . 14 纳帐业务需求 . 16 统数据 需求 . 17 统运行环境的需求 . 17 行环境 . 17 能需求 . 18 第三章 系统的总体设计 . 19 体设计思路 . 19 统架构设计 . 19 统功能模块设计 . 21 据库结构设计 . 22 据结构设计要点 . 22 辑结构设计 . 24 统涉及的技术介绍 . 27 第四章 系统的详细设计以及实现 . 30 统的部署环境 . 30 统主要模块详细设计 . 31 集模块 . 31 取模块 . 36 款模块 . 40 算模块 . 46 理模块 . 51 计模块 . 59 目录 统的界面设计 . 63 户界面 . 63 关的管理操作界面 . 63 第五章 系统运行测试与后期分析 . 65 试过程及结果 . 65 术难题及解决方案 . 66 期分析 . 67 第六章 总结与展望 . 68 目开发总结 . 68 术展望 . 68 参考文献 . 69 致 谢 . 71 个人简历 . 72 第一章 绪 论 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 集业务 需求 归集业务 办理住房公积金缴存登记、账户设立、汇缴变更、核定缴存比例、结算利息等业务的总称 。 归集业务 是公积金业务的核心模块，所有业务的基础，涉 及每个缴存职工的账户的缴存和变动。 用例说明见表 表 集 业务需求 用例名称： 归集 业务需求 用例参与者： 缴交个人 用例说明： 单位注册 ： 对申请注册的单位进行基本信息的录入，填写相应的表格，并进行审定，审核通过后方可办理后续业务。 个人注册： 个人新开户，并采集个人基本信息。 建立账号由公积金的业务人员办理，为避免重复的工作，单位可以代录入申请信息，尽量不再需要公积金中心重新再录入一遍申请信息。申请过程 为 ： 1、设立公积金账户 2、设定缴交比率（个人、单位）（有条件判别：本地区最高、最低缴交比例 ） 3、审定缴存基数（工资额，是否超过中心出台的缴存政策） 4、核定资金渠道（个人、自筹） 。 汇缴 ： 对单位按照个人账户当月或数月应缴人数的月应缴额总数划转缴存的资金，完成个人住房公积金账户登记的业务操作行为 。 补缴 ： 对单位为缴存人补足应缴差额的资金登记个人住房公积金账户的业务操作 。 查询 ： 提供基本的按条件查询界面 ； 查看历史缴交的情况 ； 查询缴交变动情况 。 进行缴交 : 由于单位账号的淡化，可以继续使用单位号，但是单位不参与核算。可以考虑将个人与缴交单位视同一种缴交团体（性质）。为方便个人缴交，对同一个人员有缴交情况 ，中心可以对缴交人员定义缴存的银行，而且可以变更。当前公积金为了避免缴交出现 分 钱的情况，使用缴交基数的四舍五入，避免小数位，减少公积金操作出错几率。设置多种缴交基数计算缴交额的方式，方便各单位进行计算。 停缴 : 单位办理停缴，需提供停缴申请，停缴单位不参与统计。 缓缴 : 通过申请，经过中心同意单位进行缓缴，缓缴需要设定缴交个人的缴存状态为封存。缓缴单位不参与统计 。 部分汇缴 ： 单位汇缴公积金的资金部分分为单位自筹、财政拨款以及个人部分，各部分资金会发生先来后到的情况，就形成了部分汇缴。部分汇缴需要记录缴存 审定时的基数、汇缴金额，审定完成之后便不可再修改。后续到达资金以欠缴补齐的形式进行业务处理。 单位缴存名册变更 ： 单位缴存名册的变更包括了缴存金额的变更和缴第二章 系统的需求分析 14 存比例以及缴存职工状态的变更。 账号合并 ： 对于个人可能存在多账号合并的问题，对于单位来讲，两个单位合并后，单位信息发生变化，其单位成员也产生了增减 。 转移 ： 转移时个人不允许提取，需要在转移到目的地进行转移操作，转移过程中不更改账号，保证个人账务的延续性。 外 转入 ： 个人因职位调迁，调动工作发生的业务。在一个单位发生停缴而进入新的单位继续缴存。转入是指系统管理 的范围外的资金转入。 归集处理 ： 归集业务都遵循相同的业务处理过程，由审核名册 -生成汇缴月份的名册 -统计 -生成收据 -打印进账单 -进账单确认 -入账。 归集处理用例活动图 如下 所示。 变更处理 ： 变更缴交银行