基于springboot电子报销系统第二章 相关技术介绍2.1 Spring Boot框架Spring Boot框架以约定优于配置为思想用自动装配、依赖管理、内置容器来组织应用结构使后端服务在统一的工程规范下可以快速启动和迭代。其组件扫描和配置绑定机制把控制层、服务层、数据访问层的职责边界落在了清晰的包结构和注解语义上使报销申请管理的校验、流程状态、权限策略可以固化成可维护的业务服务。利用Spring生态的事务管理能力在票据信息的写入、申请状态的变更、反馈记录的落库等场景下可以形成一致性的边界减小了由于跨表更新而引起的异常传播范围。Spring Boot对外部化配置的支持把运行参数和环境差异从代码中分离出来适应开发、测试和生产不同的部署需求。Actuator体系具有运行指标和健康检查的功能[13]生产级特性使得接口错误、资源占用、线程状态等更容易被观测到为后台首页运行监控和故障定位打下了基础。2.2 Vue.js框架Vue.js框架采用响应式数据驱动视图渲染的方式用虚拟DOM和组件化组织界面结构来保证前端页面状态改变时保持一致的交互性。单文件组件把模板、脚本和样式放到同一个开发单元里方便把报销规则管理的表单编辑、校验提示和交互流程做成可复用的组件。计算属性和侦听器机制可以把票据信息的金额汇总、字段联动、输入约束等用确定的依赖关系表达出来减少手工刷新造成的错漏。路由和状态管理方案支持多页面切换以及权限可见性控制使员工用户和管理员在相同的界面骨架下有不一样的操作入口。Vue.js的渐进式架构特点在[14]的相关论述中被提到是可控的工程演进路径使得系统在需求扩展的时候保持组件边界和依赖关系的可读性减少由于界面逻辑和业务接口耦合而造成的维护成本。2.3 MySQL数据库MySQL数据库用关系模型来组织数据用表结构、索引和约束来表达业务实体之间的联系适合于对一致性、可追溯性要求高的财务类数据存储。电子报销系统数据对象有很强的结构性报销申请、票据信息、意见反馈在字段完整性、关联关系、查询条件上存在稳定的规则MySQL主外键约束和事务隔离可以将这些规则落到存储层减少应用层重复校验的复杂度。InnoDB引擎使用行级锁和崩溃恢复机制可以保证在频繁的读写操作下仍然可以保持一定的冲突粒度。就后台首页统计、检索而言联合索引、覆盖索引以及执行计划的改善能加快按员工、时间段、状态等进行筛选的速度。MySQL的复制和备份体系给数据容灾和审计留存提供实现途径[15]中提到的存储引擎以及事务特性给系统在资金相关数据处理过程中可靠性设计提供技术支持。2.4 前后端分离架构前后端分离架构把界面交互和业务服务解耦成独立交付单元接口用HTTP和JSON等常用格式来承载数据交换在团队协作时可以清楚地划分出各自的责任。该架构下后端为资源建模和权限校验提供稳定接口前端为路由、组件、状态管理提供用户体验报销申请管理流程状态和操作权限可以依靠接口层统一鉴权和返回码语义来保持一致。接口版本化、网关策略可以对需要变更的功能进行限制防止由于页面修改而影响到服务的内部实现。跨域访问、令牌认证和刷新机制使得员工用户端和管理员端即使部署方式不一样也能使用同一个认证系统。日志链路和请求追踪把问题定位从页面跳转扩大到接口调用和数据库访问[16]中有关分层解耦和接口治理的观点给该架构在复杂业务迭代时的可维护性、可扩展性赋予了方法上的支持。第三章 系统需求分析3.1 可行性分析3.1.1 技术可行性本系统使用前后端分离的架构采用Spring Boot和Vue.js进行开发可以提高开发效率也可以增强系统的扩展性。各个组件之间就数据交互、业务处理等环节而言是完全一致的保证整个系统的模块间能够协同工作。目前技术体系被广泛地应用在企业级信息化系统的开发当中稳定性以及兼容性也已经得到了大量的实践证明。利用MySQL数据库系统数据管理具有较好的可靠性可以满足高并发以及持续扩展的要求。整个系统符合目前主流的互联网应用发展趋势很好地保证了系统的持续稳定运行。3.1.2 操作可行性本系统界面设计以实用为原则根据员工和管理员不同的业务需求来设置不同的布局。菜单结构清楚、功能入口分层分明简化操作过程减小新用户的学习难度。报销申请、规则管理、票据处理等重要的模块用简洁的交互引导用户进行日常操作。用户在处理业务的时候只需要按照系统的指引完成简单的步骤就可以完成信息的提交和审批从而提高工作效率减轻个人的操作压力。3.1.3 经济可行性本系统所用的大部分软件都是开源软件不需要额外支付授权费从而大大降低项目的开发成本。开发周期因为技术栈成熟而受益人力成本降低后期运维压力小。系统部署的环境使用的是常见的硬件和网络环境成本低。后续维护主要是对功能进行更新、字段进行调整并且不包含复杂的硬件升级或者大规模的技术改造从而可以保证整体的预算支出合理符合企业信息化项目投资的合理性要求。3.2功能需求分析3.4.1 员工用户功能员工用户在后台首页可以查看个人报销记录和待办事项使用报销规则管理模块可以查看可以报销的范围、标准、流程。员工用户对报销申请的发起、修改、查看办理情况和结果。员工用户对票据信息进行录入、上传票据影像、维护票据清单并和申请关联。员工用户可以向意见反馈管理系统提交问题和建议也可以查看反馈的受理情况以及回复的内容。员工用户用例图如图3-1所示。图3-1员工用户用例图3.4.2 管理员功能管理员对报销规则进行管理对报销制度内容、报销制度适用范围以及报销制度审核要求进行维护并将更新后的信息发布给员工用户查看和执行。管理员对于报销申请展开受理察看申请明细及相关票据审核退回驳回和归档申请单并追踪申请的流转情况。管理员对票据信息进行审核核验票据的真实性、完整性检查票据要素是否一致处理异常票据记录。管理员对意见提出者提交的意见进行查看、登记、反馈结语的录入、维护反馈状态。管理员用例图如图3-2所示。图3-2管理员用例图第四章 系统设计4.1 系统架构设计电子报销系统使用的是前后端分离的架构分成用户界面层、应用服务层、数据持久层、系统支持层。用户界面层用Vue.js来实现后台首页以及报销规则、报销申请、票据信息、意见反馈等模块的交互给员工用户和管理员提供操作入口。应用服务层使用Spring Boot提供鉴权、业务编排、审批流转、接口服务对规则和票据做校验处理[17]。数据持久层用MySQL实现规则、申请、票据、反馈、用户数据的存储系统支持层提供日志、异常处理、配置管理、接口文档等能力。系统架构图如图4-1所示。图4-1系统架构图4.2 系统结构功能设计电子报销系统主要是为员工用户和管理员这两个角色服务的。员工用户可以访问后台首页、报销规则管理、报销申请管理、票据信息管理、意见反馈管理等各个功能模块从而达到自助式报销流程操作、票据上传和反馈提交的目的。管理员主要完成报销规则管理、报销申请管理、票据信息管理以及意见反馈管理等工作是对系统规则进行维护、对报销进行审核并给出处理意见的人员。经过角色分离之后系统就能够在一定程度上实现各方面的业务权限合理分配和流程运转高效。该系统的功能结构如图4-2所示。图4-2系统功能结构图4.3 业务流程设计4.3.1 报销规则管理流程设计该流程用以规定报销规则的添加、发布。员工或者管理员先维护规则内容系统根据是否完整进行校验不完整的转入补充完善完整的进入合规校验。合规通过后发布不合规则终止提交确保规则可执行、可追溯报销规则管理流程图如图4-3所示图4-3报销规则管理流程图4.3.2 报销申请管理流程设计该流程就是指报销申请的提出和审批。员工提交申请之后系统会判断材料是否齐全齐全就进入审批环节缺少就转入补正并结束。审批阶段判断结果是否通过通过则生成报销单并结束未通过则退回并结束保证申请处理闭环和结果明确报销申请管理流程图如图4-4所示图4-4报销申请管理流程图4.3.3 票据信息管理流程设计该流程是票据的采集和有效性控制。员工或者管理员录入票据信息之后系统先对信息是否齐全进行判断如果缺少就进入补录阶段并结束。完整之后进行真伪、规范校验有效才入档无效标记异常结束处理保证后续报销核验的准确性票据信息管理流程图如下图4-5所示图4-5票据信息管理流程图4.3.4 意见反馈管理流程设计该流程是关于意见反馈提交和处理闭环的。用户提交反馈之后系统会判定内容是否清楚如果不清楚就提示补充结束。清晰之后进行分类分派处理完成后判断是否已经解决已经解决的反馈结果并结束未解决的转为升级处理并结束提高问题响应效率和可追踪性意见反馈管理流程图如图4-6所示图4-6意见反馈管理流程图4.3.5 报销申请复核流程设计该流程用于管理员对报销申请进行审核和确认。管理员收到待复核申请之后系统会判断票据是否一致不一致则标记为异常并结束。一致就执行金额和规则复核通过后确认入账结束不通过则驳回处理结束保证报销支付前的合规性和数据一致性报销申请复核流程图如图4-7所示图4-7报销申请复核流程图4.4 数据库设计4.4.1 概念模型设计概念模型是把现实世界抽象成信息世界的活动就是对系统中实体、属性、联系进行识别把实际业务对象和它们之间的交互关系转化为可以表达、可以实现的数据结构。本系统以报销业务闭环为主线将员工用户、报销申请、票据信息、报销规则、意见反馈等作为主要的实体进行抽象梳理它们之间的创建、关联、审核、约束关系从而得到一个清晰的数据组织方式。概念模型用E-R图来表达用实体表示业务对象用属性刻画对象的特征用联系表达对象之间的依赖和流转关系以支持后面逻辑结构的设计和数据库的实现一致性、可维护性也为系统的功能扩展提供稳定的数据基础和边界约束[18]。全局的ER模型如图4-8所示图4-8全局ER图根据系统的分析系统主要的实体有票据信息、员工用户、报销申请、意见反馈、报销规则等每个实体的具体属性如下图所示。报销规则实体主要是报销规则id、报销类目、类目额度、票据要求等属性。实体属性图如下图4-8所示。图4-8报销规则实体属性图报销申请实体包含报销申请id、报销类别、报销金额、审核状态、报销日期等属性。实体属性图如下图4-9所示。图4-9报销申请实体属性图票据信息实体主要包含票据信息id、票据名称、票据编号、票据附件等属性。实体属性图如图4-10所示。图4-10票据信息实体属性图员工用户实体由员工用户id、员工姓名、员工工号、部门名称、员工电话组成。实体属性图如图4-11所示。图4-11员工用户实体属性图意见反馈实体包含意见反馈id、反馈内容、处理回复、处理进度、反馈日期等属性。实体属性图如下图4-12所示。图4-12意见反馈实体属性图用户账户实体主要是由用户id、用户名、密码、用户组、账户状态等组成的。实体属性图如下图4-13所示。图4-13用户账户实体属性图用户组实体主要包含用户组id、名称、描述等属性。实体属性图如图4-14所示。图4-14用户组实体属性图4.4.2 数据库逻辑设计本系统逻辑结构设计是以概念E-R模型为基础把员工用户、报销申请、票据信息、报销规则、意见反馈这五个实体映射成关系表并确定主键标识和关键关联字段支持提交、附带、约束、反馈等业务链路的完整落库。各表以id为主键保留创建用户ID、创建时间、更新时间等审计字段把审核状态、处理进度等状态字段加入到流程控制和统计查询中同时对名称、编号、附件、金额等核心业务字段设置合理的类型和长度保证数据的一致性、可追溯性、扩展性满足以后查询和维护的需求[19]。报销规则表主要用来存储各个报销类别的额度限制和票据凭证的要求。主要是包含报销规则ID、报销类别、类目额度、票据要求等字段。表4-1为结果数据。表4-1报销规则表序号字段名类型长度是否非空是否主键备注1reimbursement_rules_idint11是是报销规则id2reimbursement_categoryvarchar64否否报销类目3category_quotadouble-否否类目额度4document_requirementstext65535否否票据要求报销申请表是记载员工提交的报销申请内容以及审核情况的表格。主要是报销申请id、报销类别、报销金额、审核状态、报销日期等字段。表4-2所示。表4-2报销申请表序号字段名类型长度是否非空是否主键备注1expense_reimbursement_application_idint11是是报销申请id2reimbursement_categoryvarchar64否否报销类目3reimbursement_amountdouble-否否报销金额4examine_statevarchar16是否审核状态5reimbursement_datedate-否否报销日期票据信息表主要是用来保存员工上传的报销凭证附件以及编号。主要包含票据信息id、票据名称、票据编号、票据附件等字段。表4-3中给出的是。表4-3票据信息表序号字段名类型长度是否非空是否主键备注1bill_information_idint11是是票据信息id2bill_namevarchar64否否票据名称3invoice_numbervarchar64是是票据编号4document_attachmentvarchar255否否票据附件员工用户表主要用来存储企业内部员工的基本人事信息。主要包含员工用户ID、员工姓名、员工工号、部门名称、员工电话等字段。如表4-4所示。表4-4员工用户表序号字段名类型长度是否非空是否主键备注1employee_user_idint11是是员工用户id2employee_namevarchar64否否员工姓名3employee_work_numbervarchar64是是员工工号4department_namevarchar64否否部门名称5employee_phonevarchar16否否员工电话意见反馈表主要记录员工提出的意见、疑问以及管理员给出的答复。主要包含意见反馈id、反馈内容、处理回复、处理进度、反馈日期等字段。如表4-5所示。表4-5意见反馈表序号字段名类型长度是否非空是否主键备注1feedback_idint11是是意见反馈id2feedback_contenttext65535否否反馈内容3handling_replytext65535否否处理回复4processing_progressvarchar64否否处理进度5feedback_datedate-否否反馈日期用户账户表主要用来存储系统登录凭证和账户状态信息。主要包括用户id、用户名、密码、用户组、账户状态等字段。如表4-6所示。表4-6用户账户表序号字段名类型长度是否非空是否主键备注1user_idint11是是用户id2usernamevarchar16是否用户名3passwordvarchar64是否密码4user_groupvarchar32否否用户组5statesmallint6是否账户状态用户组表主要是用来分隔各种不同的用户权限集的。用户组ID、名称、描述等信息一起构成用户组表。表4-7为数据。表4-7用户组表序号字段名类型长度是否非空是否主键备注1group_idmediumint9是是用户组id2namevarchar16是否名称3descriptionvarchar255否否描述第五章 系统实现5.1 员工用户功能实现5.1.1 后台首页功能实现后台首页功能主要是对系统的整体信息进行集中展示系统提供核心功能入口和信息总览。员工用户可以迅速地到达各个业务模块从而达到操作的方便性。本功能可以对有关的状态信息做实时的更新。后台首页界面如图5-1所示。图5-1后台首页界面5.1.2 报销规则管理功能实现报销规则管理功能是对报销相关规定进行配置和调整该功能可以对规则表进行录入和修改的操作。员工用户可以查看最新的规则内容可以对规则的状态进行变更并且可以使用规则。系统可以对历史规则数据进行维护。报销规则管理界面如图5-2所示。图5-2报销规则管理界面5.1.3 报销申请管理功能实现报销申请管理功能是对报销申请流程进行处理和记录对申请信息进行归档、审核状态的管理。员工用户可以提交新的申请并且可以查看审核进度该模块实现申请数据的更新和同步。在此处可以对申请历史进行追踪和管理。报销申请管理界面如下图5-3所示。图5-3报销申请管理界面5.1.4 票据信息管理功能实现票据信息管理功能是对报销票据数据进行集中管理系统具有票据分类和编辑的功能。员工用户可以上传、修改和查看票据信息从而对票据的状态进行监控。在该功能里系统会对票据内容做规范化的处理。票据信息管理界面如下图5-4所示。图5-4票据信息管理界面5.1.5 意见反馈管理功能实现意见反馈管理功能是对用户反馈的内容进行收集、整理该模块完成反馈信息的录入、跟踪。员工用户可以提出意见并查看处理情况系统对反馈数据进行归档和统计。该功能可以实现反馈状态的动态更新。意见反馈管理界面如图5-5所示。图5-5意见反馈管理界面5.2 管理员功能实现5.2.1 报销规则管理功能实现报销规则管理功能主要是对规则参数进行配置和维护该功能实现规则内容的增加、修改。管理员可以修改有效的规则系统对规则的状态进行实时的管理。本模块可以对规则信息进行同步与更新。报销规则管理界面如下图5-6所示。图5-6报销规则管理界面5.2.2 报销申请管理功能实现报销申请管理功能主要是对员工报销申请数据进行审核和处理管理员可以进行审批操作。系统对于申请记录的状态进行管理实现申请进度的跟踪。在该模块里可以对申请数据进行归档和更新。报销申请管理界面如下图5-7所示。图5-7报销申请管理界面5.2.3 票据信息管理功能实现票据信息管理功能是对报销的相关票据进行集中管理系统有票据审核、记录的功能。管理员可以核对票据内容实现了票据状态的更改和修正。本模块是对票据数据进行分类的。票据信息管理界面如下图5-8所示。图5-8票据信息管理界面5.2.4 意见反馈管理功能实现意见反馈管理功能主要是对用户反馈的信息进行监督和处理该模块完成反馈记录的审核和回复。管理员可以查看反馈详情系统对反馈状态进行管理。此功能能完成反馈数据的统计、保存。意见反馈管理界面如图5-9所示。图5-9意见反馈管理界面第六章 系统测试6.1 系统测试目的系统测试的主要目的就是检验电子报销系统各个功能模块的业务逻辑和设计规格是否一致。测试时主要对系统的鲁棒性以及边界容错能力进行校验在不同的操作流程下考察系统看各个业务规则是否严格遵守保证数据流转过程的正确性、一致性提高系统的稳定性以及模块间的低耦合性。全链路覆盖测试可以对各个模块在实际运行环境下的交互准确性做进一步的评价也可以对系统的访问安全以及异常处理能力进行有效的检验从而保证上线风险可控[20]。6.2 系统测试的原则与方法系统测试遵循闭环、全面覆盖、分层执行原则。从功能上来说是用例驱动的逐步测试核心流程主要是各个模块间的数据交互、规则匹配、流程完整性的测试。边界条件和异常情况采用白盒和黑盒测试相结合的方式从输入校验、数据有效性和安全防护三个方面考虑根据实际业务场景设计出覆盖性的用例。测试过程中将人工监督和自动脚本一起使用对系统的响应速度、稳定性和容错性做多次检验。每一轮测试之后对缺陷进行整理并回溯流程的设计保证最后的产品达到设计规范以及业务目标。6.3 测试用例(1)后台首页功能后台首页功能实现系统主面板展示功能测试如下表6-1所示。表6-1后台首页功能测试表测试内容测试步骤预期结果实际结果首页信息加载登录系统后进入首页显示当前业务数据统计符合预期模块入口跳转从首页点击任一模块入口正确进入对应模块符合预期数据实时刷新业务变动后首页数据更新首页数据即时反映变化符合预期(2)报销规则管理功能报销规则管理功能可以实现业务规则的录入、修改和查看功能测试结果如表6-2所示。表6-2报销规则管理功能测试表测试内容测试步骤预期结果实际结果新建规则填写规则内容并保存新规则信息记录完整符合预期规则修改编辑已有规则进行更改修改内容同步更新符合预期规则删除选中规则并删除规则即时移除符合预期(3)报销申请管理功能报销申请管理功能是流程申请数据登记和审核的功能功能测试见表6-3。表6-3报销申请管理功能测试表测试内容测试步骤预期结果实际结果新申请提交填报并提交申请信息申请记录生成并展示符合预期申请审核审核人员操作流程审批状态审核结果正确反馈符合预期申请查询根据条件查询申请记录查询结果完整准确符合预期(4)票据信息管理功能票据信息管理功能是对票据数据进行采集和归档的其功能测试结果如表6-4所示。表6-4票据信息管理功能测试表测试内容测试步骤预期结果实际结果票据上传系统录入票据信息并上传票据信息存储并显示符合预期票据校验自动校验票据信息有效性校验结果准确反馈符合预期票据关联申请将票据与报销申请绑定绑定关系完整记录符合预期(5)意见反馈管理功能意见反馈管理功能是用户反馈信息的收集与处理该功能测试结果如表6-5所示。表6-5意见反馈管理功能测试表测试内容测试步骤预期结果实际结果反馈提交用户填写并提交意见反馈信息即时保存符合预期反馈响应管理端处理反馈并回复回复内容准确推送用户符合预期反馈查询按条件查询历史反馈查询结果完整一致符合预期6.4 测试结果分析测试结果说明电子报销系统各个主要的功能模块都达到了预期的业务目的。功能闭环性、模块数据一致性得到保证在边界情况下系统具有较好的容错性。所有的测试用例实际运行情况都符合设计规格没有发现影响业务流程的严重缺陷。测试结果说明系统架构的稳定性、交互的准确性达到了上线标准为业务发展、不断优化打下了基础。喜欢本项目的朋友可以点赞关注我私信发【源码】就能免费领取完整项目代码
