SpringBoot3+Vue3 财务管理系统如何设计：从业务单据到总账的模块划分

SpringBoot3+Vue3 财务管理系统如何设计：从业务单据到总账的模块划分

财务模块划分的起点，是确定哪一个服务有权改变哪一种事实。 费用单说明事情为什么发生，往来解释还欠多少，资金记录收付，会计凭证解释如何记账，账簿承接过账结果。

图 1｜财务领域关系示意，AI 生成，1500×1000。箭头表示责任交接，不是所有业务必须依次执行的固定流程；审批、付款、生成凭证与过账分别判断。它不是系统截图，也不代表本次完成核算验收。

一、一个"完成"按钮，为什么会让五个模块纠缠在一起？

产品评审里，常有这样一句话："报销通过后，顺便付掉，顺便生成凭证，再把余额更新一下。"

如果研发照着一个按钮实现，后续很快会遇到问题：款付了一部分，报销算完成吗？凭证模板缺科目，审批要不要退回？来源重推一次，会不会重复扣款？已经过账后改单，旧账由谁更正？

这些问题共同指向状态和数据的所有权。

产品负责人要明确每一步向谁交付；开发要知道哪些数据可以同事务修改；实施要知道失败后该补制度、补配置，还是找研发。

RuoYi Office 的现有产品位置能承载这类讨论：费用单保留票据和借款冲抵，资金单保留账户与业务来源，会计凭证保留借贷分录与来源依据。本文沿这些交接点核对源码，给出可复用的设计取舍。

证据分两层："源码核对"表示当前工作树中存在对应逻辑；"界面观察"表示本地既有运行包能读取相应记录。运行后端是资产教程专用包，未从最新源码重建，两者不能合成"最新版全链路已通过"。后文的新增方案均明确标为设计建议。

上一篇讨论财务、报销与 ERP 的范围，本篇只深入内部模块怎样合作；不再重复菜单参观或产品选型。

二、用所有权表划模块，而不是按页面数量划模块

一个对象可以被多个页面读取，但应有清楚的修改入口。 财务模块在这里指业务责任边界，可以先部署在同一个 Spring Boot 应用中，不要求拆成微服务。

模块	拥有的事实与核心对象	可以接受的命令	向其他模块交付什么
费用业务	申请、借款、报销、票据引用、费用承担明细	保存、提交、撤销、接收付款反馈	经业务规则确认的费用事实、待付款金额与来源
往来结算	应收应付、到期信息、结算关系、未结余额	从来源立账、核销、撤销核销	待收待付依据、结算金额及剩余余额
资金执行	收付款单、资金账户、资金流水	形成收付记录、确认执行、登记依据	执行结果、资金流水及来源关联
凭证衔接	来源队列、业务快照、生成状态和失败原因	提交来源、生成、重试、忽略或受控撤销	凭证关联、处理状态、可解释的失败原因
会计核算	凭证、分录、科目余额、期间	制单、审核、过账、受控更正	账簿结果和用于报表的核算数据
基础配置	账套、科目、期间、辅助核算与映射	配置与启停，按权限维护	其他模块校验所需的共同口径

这是一张责任设计表，不表示每个命令都已完成本次实测。预算也应有独立额度账：费用模块发起占用、释放和转实际请求，不能由页面直接累计预算余额。

几个容易混淆的余额，需要在字段名和接口中分开。

数字	由谁解释变化	不应被用来代替什么
报销应付额	费用单金额与借款冲抵	银行账户余额、全部供应商应付
往来未结额	立账与结算记录	未开票金额、未审批金额
资金账户余额	账户期初与资金收支	总账银行科目余额已经核对一致
科目期间余额	期初及过账分录	业务审批累计额、预计付款计划

"费用模块的应付员工金额"也不自动等于"已经生成一张通用应付单"。当前报销付款回写直接调用报销服务；建模时要画出实际调用关系，不能为了图好看，把所有业务强行接入同一张应付表。

三、领域关系图：来源、执行与记账要保留两条线

资金流转线和会计事实线相关，但不应合成一个无法拆分的状态。 某些业务形成往来后就需要核算，某些费用则按具体产品规则在后续时点交接。

下图把责任关系进一步展开，作为接口评审时可复用的文字图。它是概念关系，不是物理外键图；箭头不承诺每条业务路径已经落地。

费用业务 ──待付款依据──┐
  │                  │
  │费用事实          ▼
  │               收付款单 ──执行登记──> 资金流水
  │                  │                     │
  │                  └──付款事实───────────┤
  │                                        │
  ▼                                        ▼
凭证来源队列 <──立账事实── 应收应付 <──业务来源
  │                          ▲
  │                          └──收付匹配 / 核销
  ▼
凭证模板 ──科目和维度映射──> 会计凭证
                                 │
                                 │审核 / 过账
                                 ▼
                           科目余额与账簿
                                 │
                                 ▼
                            报表 / 期间检查

来源队列依赖业务事实快照，凭证依赖模板和财务配置，账簿更新依赖过账。核销关系解释往来如何减少，不能只靠资金流水总额推算每一笔应付的结清情况。

最值得保留的关联字段，往往不是页面上的名称

来源编号用于程序准确定位，来源单号用于人核对，版本用于区别同一事项的不同事实；三者职责不同。

对象	当前核对到的关联	对设计的启发
应付来源	bookId / sourceBizType / sourceBizId	来源类型与账套参与定位，不能只拿数字 ID 查重
付款明细	bizType / bizId / bizNo / amount	每行保留本次支付额和来源，不只在主表写一个备注
资金流水	sourceBizType / sourceBizId / sourceBizNo	把账户收支追到执行依据；交易号也不能代替业务主键
凭证来源	sourceType / sourceId / sourceVersion / payload	保存业务版本和制证取数快照
会计凭证	sourceQueueId	将生成结果接回来源，后续核查有明确入口

这些字段分别来自应付、付款、资金流水及凭证来源服务和数据对象。字段存在提供追溯基础，但"每页能一键跳回、跨账套无歧义、历史快照不被覆盖"仍应逐项验收。

当前来源查询中还有不显式传账套、取最高版本或最近记录的入口。若未来让同一业务进多个账套，设计建议是让调用方携带账套并明确查询目标，不能把便捷查询当成所有多账套场景的唯一索引。

四、从报销交给资金：传业务结果，别让出纳重新算一遍

费用模块应把冲抵后的待付结果交出去，资金模块负责本次从哪里付、付了多少。 这能避免出纳按票面总额再次付款。

图 2｜本次独立会话重新读取报销 id=3：报销 500.00、冲抵借款 200.00、应付 300.00。此历史记录曾出现流程实例不存在，仅用于观察单据与金额责任；不证明审批历史完整，不执行提交或付款。

这条记录里的三组数应分别保存其来源：500 来自报销明细，200 来自借款冲抵，300 是应付结果。不能只在 Vue3 页面用 500 - 200 算一个显示值，然后让后端接收任意付款金额。

当前报销服务的审批状态处理会调用借款冲抵，更新冲抵额和待付额。待付额为正时，单据进入待付款；无需再付款的分支则继续处理票据、预算转实际与凭证来源。

付款回写进入 addPaidAmount，累计已付金额；达到待付金额时处理相应业务状态、票据、预算和来源入队，部分付款进入部分支付状态。

这说明报销有自己的金额和状态规则，并不说明重复审批回调、超额付款或并发累加已通过测试。 尤其审批状态回调方法本身不能仅凭附近的事务注解，推断整个流程引擎与业务更新天然属于同一事务；还需要继续核对调用者和部署方式。

一张单据，至少四种状态需要分别回答

使用者问什么	该查的状态	为什么不能复用一个"已完成"
主管同意了吗？	审批状态	通过后可能仍待付款
员工的钱付齐了吗？	费用单已付、待付及付款关联	借款抵扣可能让本次无需现金付款
会计凭证生成了吗？	来源队列状态、凭证关联	已生成也可能尚未审核或过账
正式账簿更新了吗？	凭证过账状态与期间结果	审核通过仍不等于余额已更新

Vue3 页面可以集中显示这四类结果，但它们的修改命令应各自落回负责的服务；前端不应该通过改一个主状态顺带改完其他模块。

五、资金事务：账户流水、来源回写与财务衔接如何一起落地

先看本地事务包含什么，再讨论是否需要消息队列。 当前付款 pay 方法标注事务，执行资金流出、业务来源回写、凭证来源入队、付款状态更新，并对相关应付明细调用自动核销。

图 3｜本次重新读取既有付款 FK2099168496360493056，金额 800.00、已出款，来源 AP2099168441612242944。与图 2 报销不是同一笔业务；界面状态不证明本次执行银行转账，未点击出款、保存或核销。

在资金流水服务中，能看到锁定资金账户行、验证账套和账户状态、校验透支条件、写入流水、更新账户余额的逻辑。这里的行锁针对账户余额更新，不能推导为同一付款单并发执行已被完整防重。

付款方法先检查已付款状态，重复串行请求会被拒绝；同时到达的请求还涉及付款记录本身、流水来源和结算的并发约束，需要专项验证。账户行锁解决的是另一层问题。

当前代码还明确拒绝在线转账通道，返回通道不可用错误。因此，网银线下记录、银行文件导出和银行直连是不同能力，本文不把前两者写成银行自动扣款已落地。

哪些失败该回滚，哪些失败该留下待处理？

位置与失败	当前源码观察	实施与研发应怎样理解
资金账户不存在、停用或禁止透支	资金流水服务抛出业务异常	当前本地付款事务应失败，不留半张成功流水
付款来源回写失败	在付款事务内调用来源服务	同库本地调用按实际事务传播处理；不是远程银行回滚承诺
来源账套无法解析	来源提交可能抛异常	入队并非所有配置错误都吞掉，不能说永不影响业务
期间不存在或不可记账	submitSource 保存失败原因和失败状态	这类期间问题保留在来源记录，交给财务处理
自动生成凭证失败	自动路径在提交后调用生成并记录失败	与"付款事务里同步生成全部分录"有区别
同步提交并生成失败	另有 submitAndGenerate 事务入口	调用者要知道自己选的是同步路径，不能套用异步隔离结论

"先提交，稍后生成"的价值，是减少业务事务与科目模板错误的直接耦合；但需要有持久来源记录和后续处理入口，不能只把异常写进日志。

如果未来拆成远程财务服务，设计建议采用本地待发送记录、可靠投递、消费防重和状态核对，再考虑补偿。当前这里核对到的是本地数据库事务与提交后回调，不是跨服务分布式事务，也不是已验证的可靠消息方案。

六、会计入口：来源队列不是资金流水的另一个名字

凭证来源保存的是"准备怎样参与核算的业务事实"，资金流水保存的是账户收支。 没有资金收付，也可能有核算事项；一笔资金收付也不必再次确认一遍费用。

当前来源记录包含业务日期、期间、主金额、业务字段快照、生成状态、凭证关联与失败原因。amount 的数据对象注释仍写"仅用于列表展示与核对"，但执行代码并不止于此：FinanceVoucherTemplateServiceImpl.buildEnv 同时构造业务 payload 与来源元数据的表达式环境，并将 source.getAmount() 注入 sourceAmount。当前缺省报销和付款模板使用 sourceAmount 计算分录金额，主金额确实参与制证；不能仅凭这条注释排除它的核算用途。其他业务字段、明细与科目如何参与，仍由实际模板和来源契约决定。

去重先分清"重试"与"新版本"

当前 submitSource 先按账套、来源类型、来源 ID 和版本查询，命中直接返回既有记录。数据库基线另有包含租户、账套、来源类型、来源 ID、版本及删除标记的唯一键。

下面摘录真实入口的关键片段；省略后续建对象和保存部分。它解释重复推送为何先返回现有状态，不等于并发插入冲突一定被转换成同样的成功响应。

@Override
@Transactional(rollbackFor = Exception.class)
public FinanceVoucherSourceRespDTO submitSource(FinanceVoucherSourceReqDTO reqDTO) {
    Long bookId = resolveBookId(reqDTO);
    Integer sourceVersion = ObjUtil.defaultIfNull(reqDTO.getSourceVersion(), 1);

    // 幂等：同一来源和版本重复推送，返回已有状态
    FinanceVoucherSourceDO exists = voucherSourceMapper.selectByIdempotentKey(
            bookId, reqDTO.getSourceType(), reqDTO.getSourceId(), sourceVersion);
    if (exists != null) {
        return convert(exists);
    }
    // 后续构建来源快照，检查期间并保存；此处省略
}

来源：FinanceVoucherSourceServiceImpl.submitSource，注释和缩进为阅读整理。数据库唯一约束可以阻止同键重复落库，但"查后插"的并发请求仍可能遇到冲突；本次没有做并发验收，也没有核对运行库是否与该基线一致。

更值得提前谈清的是业务版本。当前报销和付款的来源提交固定设置 sourceVersion=1，autoGenerate=false。它们不会仅仅因为底层有版本字段，就自动实现改单后递增版本、重算分录和更正旧账。

**设计建议：**为允许修订的来源明确版本递增者、快照冻结时点、旧凭证处置和新版本生效条件。先处理已核算版本，再提交修订事实，不能把同键重试当成覆盖更新。

两个来源类型，不代表两次确认同一费用

付款服务既会回写报销，也会提交付款来源；报销在付齐等分支中还会提交费用来源。也就是说，同一业务链可能产生不同来源类型的核算事实。

来源唯一键只能防止同类型同版本重复，不能代替会计语义去重。费用事实与付款事实分别使用什么模板、确认什么内容，必须成对检查；不能让两套模板都再次确认同一笔费用。

这不是本文已经判定的产品故障，而是源码暴露出的验收重点。本次没有生成这两类凭证，也没有验证它们组合后的账务结果。

设计取舍	建议方案	必须付出的管理成本
业务服务直接写分录，还是交业务事实	保留来源与模板边界	维护来源字段契约和模板映射
重试覆盖原快照，还是返回原状态	同版本重试返回原状态	修改业务必须另有受控修订流程
付款就生成全部账务，还是按事实类型处理	为费用、往来、资金定义各自核算责任	财务共同确认模板组合，防止重复确认
一个状态管到底，还是状态分层	分审批、执行、来源生成与过账	页面要解释下一步和失败责任人
先拆微服务，还是先稳定本地契约	先把单体内所有权和事务讲清	服务化时重新设计投递与一致性

七、生成凭证之后，账簿仍有自己的门槛

来源标记已生成，只表示已经有凭证，不表示正式余额已经更新。 当前模板生成方法创建凭证后，仅在 autoAudit=true 时调用 autoAuditAndPost，并由 autoPost 决定审核后是否继续过账；不能把"关闭自动过账"一概描述为"停在暂存"。以下是该生成路径成功返回时的配置组合，不代表本次执行过这些动作。

自动审核 autoAudit	自动过账 autoPost	此生成路径的结果
关闭	关闭或开启	不进入自动审核和过账，凭证暂存
开启	关闭	已审核、未过账
开启	开启	审核后继续过账，须通过相关校验

来源在生成成功后标记已生成，以避免重复建凭证；核算是否完成还要查看凭证实际状态。当前缺省报销、付款模板将两个开关均设为开启，实际账套模板仍需单独核对。

图 4｜本次重新打开既有凭证 2026-08 转-0001，借贷各 500.00，备注来源 FI504-2026090600008。与图 2、图 3 均为不同记录；仅展示分录和来源，不表示本次执行生成、审核或过账。

当前过账实现先判断凭证是否已过账、是否已审核，再验证账套和期间，调用余额服务过账，更新凭证状态并写审计。反过账则另走受控入口，调用余额反向处理；已被红冲的凭证也有额外限制。

对于产品设计，重点不是多加几个按钮，而是保证业务撤销不越过会计边界直接删除已经形成的账。来源撤销入口对已生成记录有模式限制，并提供红冲路径；实际操作还要看凭证状态和期间约束，不能理解为任何凭证都能随时一键撤回。

来源中的版本、凭证中的状态、期间中的可操作条件，需要一起解释。只盯着业务单据上的"撤销成功"，很容易遗漏账务更正责任。

把异常恢复写成下一位负责人的工作

异常	建议接手人	应保留的证据与下一步
来源缺维度或日期错误	业务负责人、实施	原始单据、字段缺口；受控修订后重新交接
科目或模板映射缺失	会计、实施	账套、来源快照、失败原因和模板；补配置后重试
来源已经生成，再次点击生成	财务操作人	返回已有凭证或明确拒绝；检查是否误操作
凭证尚未审核却请求过账	会计审核人	当前状态和审核依据；完成审核后再处理
已结账期间需要更正	财务负责人	原凭证、期间、允许的更正方式与审批依据
业务成功但缺财务来源	业务与财务集成负责人	单据和队列核对清单；查明未提交还是投递中断

最后一行的自动核对、告警和补投能力在本文中是设计建议。提交后回调不等于可靠消息：若进程在业务提交后、自动调用前终止，需要检查来源记录并有人工或任务恢复机制，不能只依靠一次内存回调。

八、分期实现：每一期减少一种耦合，交一份可复核结果

分期不是先做页面再补账，而是逐步收紧交接契约。 已有正式核算系统应继续承担原责任，替换之前先约定并行核对和切换条件。

期次	本期聚焦的技术边界	交付物	进入下一期的门槛
第一期：单据所有权	费用、往来、资金分别修改自己的事实	对象责任表、状态字典、来源编号规范	同一业务的审批额、待付额、执行额能分别解释
第二期：可靠的本地交接	资金流水与来源回写的事务，来源入队和失败状态	事务边界图、故障用例、来源核对清单	失败不留下半笔本地成功结果，重复请求行为明确
第三期：核算规则	业务快照、模板、凭证与过账责任	字段契约、模板组合表、修订与更正流程	来源能追，费用与付款不重复确认，账簿可核对
第四期：恢复与服务化准备	漏单核对、批量重试、跨服务投递方案	差异队列、责任人、恢复记录、投递协议	中断后能恢复，不依赖人工猜测是否已经处理

第二期可以先把一类来源做深，不必一开始覆盖所有采购、销售、资产与合同场景。第三期若发现付款与费用模板口径还没统一，就停下来补口径，别继续堆报表。

对开发团队，可按下面的最小接口卡评审每一个交接。以下是建议格式，不是新增产品接口说明。

卡片项	应写的内容	例子或检查问题
输入身份	租户、账套、主体、来源类型、ID、版本	相同 ID 来自不同模块如何区分？
输入事实	日期、金额口径、维度、明细与快照	含税、待付、冲抵金额分别叫什么？
前置条件	来源状态、权限、期间、主数据	失败时谁能补，补完从哪里继续？
重复行为	返回已有、拒绝，还是创建新版本	网络超时后重试能否得到可解释结果？
原子范围	同库事务内修改的对象	是否夹带远程银行或其他系统调用？
返回结果	状态、目标 ID、失败原因	业务成功与财务待处理能否分别展示？
更正方式	撤销、修订、冲销与版本规则	已过账时，谁有权执行哪种更正？

这张接口卡的价值，是让产品、开发、实施和财务共同签清含义。它比"提供一个通用同步接口"更容易减少后续争议。

九、可以直接用于评审的异常验收清单

下面全部是待验用例。本次只读源码和页面，没有执行财务写入，不能把这张表当作已通过报告。

编号	场景	需要观察的结果	初始状态
01	不同模块出现相同数字来源 ID	按类型、账套正确区分，不互相覆盖	待验
02	同一来源同版本串行重复提交	不重复入队，返回原处理状态	待验
03	同一来源同版本并发提交	无重复记录，冲突响应与重试策略明确	待验
04	同一付款单重复或并发执行	无重复资金流出、来源累加或重复核销	待验
05	流水已写后来源回写失败	在约定本地事务内一起回滚	待验
06	来源期间不存在或已关闭	按已选入口保留失败或返回错误，责任清楚	待验
07	模板缺科目或辅助核算	可定位来源和配置，修复配置后可受控重试	待验
08	同一业务同时产生费用与付款来源	模板组合无重复费用确认，资金与往来口径一致	待验
09	已生成但未审核、未过账	来源与凭证状态分别正确展示，不重复制证	待验
10	原始业务修订或撤销	版本和旧凭证处理遵守既定规则，保留轨迹	待验
11	业务提交后进程中断	可发现待处理来源，恢复动作不重复产生结果	待验
12	过账和期间检查	凭证、账簿、报表分别核对，失败不被其他成功项掩盖	待验

每个未通过项都应记录影响、接手人、复验环境和证据。不要把唯一索引存在、事务注解存在或一张凭证借贷平衡，直接填进"全部通过"。

十、如何用这份设计看产品与源码

对产品负责人，先选一种费用和一种应付业务，按责任表标出每次金额变化由谁解释。对实施，准备账套、科目、模板和部门项目映射，让每一个失败都能交到具体人手里。

对 Java/Vue 开发，先沿现有页面、API、服务和数据对象追踪一条来源，再决定新增接口。当前工程使用 Java 17、Spring Boot 3.5.x、Vue3 与 Vben；同一套组织、权限和流程基础可以用于业务扩展，但财务契约仍需逐项核对。

本地接手可以按交付文档配置数据库、流程与基础数据，再分别启动后端和 PC 应用；下面只是现有工程启动入口，不代表完成安装初始化或商业模块交付。

# 后端工程：先按交付文档配置环境并构建，再启动约定产物
cd ruoyi-office
mvn -P boot -DskipTests compile

# PC 管理端：在另一个终端进入完整前端工作区
cd ruoyi-office-vben
pnpm dev:antd

在线体验可先用演示账号 admin / admin123，依次只读查看"财务 → 费用报销""资金管理 → 付款单""凭证管理"的详情；实际菜单和数据以账号权限、运行版本为准。演示地址见文尾。本次没有运行上面的构建或启动命令，也没有重启共享服务。

RuoYi Office 适合希望在 Java/Vue 企业平台上继续二开的团队作为评估对象。财务模块、商业源码、初始化资料、授权和服务范围按具体采购版本确认；公开仓库入口不代表本文展示能力全部免费包含。

需要先判断产品边界，可读第04篇：财务、报销与ERP如何分工；希望看页面位置，可读第03篇：财务产品全景；准备接手源码，可读第02篇：完整源码交付清单。

常见问题（FAQ）

SpringBoot3 财务管理系统必须拆成微服务吗？

不必。先在同一应用内明确单据所有权、来源契约、状态和本地事务，通常更容易验证业务。未来拆服务时，还需要重新设计可靠投递、消费防重和异常恢复，不能直接把本地调用换成 HTTP 就认为一致性不变。

每张报销都必须先生成通用应付单吗？

取决于企业模型与实际实现。当前核对到付款服务可直接回写报销，不能据此虚构所有报销都先转成应付。若要统一往来中心，应定义员工往来、冲抵、结算及历史迁移规则，并验证新增路径不会重复立账。

凭证来源有唯一索引，就能保证绝不重复记账吗？

不能。唯一索引约束同一来源键，不代替不同来源之间的会计语义校验，也不覆盖付款、过账等所有并发路径。还要验证冲突响应、模板组合、凭证生命周期和更正流程。

凭证已生成，为什么账簿还可能没有更新？

生成和过账是不同动作。当前模板生成路径中，关闭自动审核时凭证暂存；开启自动审核、关闭自动过账时，凭证已审核但未过账；两个开关都开启且校验通过时才继续过账。来源生成成功后会标记已生成，正式余额更新仍需核对凭证实际状态和期间条件。

现有系统支持业务版本号，是否就能直接改单重制证？

不能据字段存在判断。当前报销与付款来源调用固定传版本 1。允许修订时，还要明确谁递增版本、旧快照是否冻结、原凭证怎样处理，以及期间限制；本文将这部分作为设计与验收要求。

资料与验证边界

源码核对和界面获取日期为 2026 年 11 月 1 日。本文为产品架构分析，不提供针对企业具体业务的会计处理建议；科目、核算时点和模板需由企业财务确认。关键结论来自本地来源服务、付款、报销、资金流水、凭证服务及数据库基线；完整路径、核对位置和配图记录见随稿《资料与配图来源》。

三张系统截图均为独立会话只读打开的既有记录，覆盖费用、资金执行与会计凭证三个位置，不拼成同一笔成功链路。未改 DOM、金额、状态或数据库，未执行提交、审批、付款、核销、制证、过账、结转或结账。

后端运行包未从最新源码重建。报销历史流程缺失、P1 学习账套 2026-08 报表差额 -500 未定性、损益未结转阻断月结等已知限制仍保留，本文未复验或修复，也不宣称完整核算通过。并发、进程中断恢复、模板组合和银行接口均未实测。

本篇领域图、接口卡、分期路径和验收用例属于设计建议；源码中已存在的入口与运行页面观察分别说明。没有引用外部产品图，也没有将设计图当成系统截图。

你们在业财衔接时最难确定的，是来源所有权、重复处理，还是已经过账后的更正责任？