SpringBoot 薪酬系统实战：从工资试算到员工工资条
同一个月，同一个员工，工资系统里出现了三个金额：8500 元、7386.20 元、10180 元。
员工关心自己能拿多少，HR 需要解释每项扣款，管理人员还要看公司承担了多少成本。如果系统只留一个“工资金额”字段，三个人看到的数字总有两个不合适。
这次从 RuoYi Office 的一笔教学工资讲起：先看到工资条，再回到试算，把金额、来源和状态逐项对上。页面背后是 SpringBoot 的批次核算服务、Vue3 管理端，以及员工使用的 UniApp 工资条入口。
案例取自 2026 年 10 月 18 日的教学实操，提前演示了 11 月工资，员工和金额都是教学数据。文中完整截图来自该次记录，代码按当前实现核对；本例没有真实银行付款。
一张工资条，先把三个金额说清楚
打开管理端工资条详情，顶部是员工、期间和汇总，下面是项目明细。最有用的一列其实是“说明”：基本工资对应 archive.fixed_salary，固定补贴对应 archive.allowance_amount。看到金额之后，可以继续查它从哪里来。
历史管理端完整画面：同一张工资条中，基础项目、汇总结果和公司承担项目分别列出。此时员工尚未阅读。
把这张工资条拆成四行，就容易核对了：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这里有一个开发时容易忽略的问题：工资条项目不能不分类型地全部求和。 明细既有基本工资这样的输入项，也有实发工资、人工成本这样的派生结果。把所有行加起来，等于把同一笔钱算了好几遍。
当前核算服务分别计算应扣、实发和企业成本，工资条展示这些结果。下面是 calculateEmployee 中的对应片段，其他计算步骤省略：
BigDecimal deductAmount = scale(attendanceDeduct.add(otherDeduct).add(punishDeduct).add(socialPersonal).add(fundPersonal).add(taxAmount));BigDecimal actualAmount = scale(payableAmount.subtract(deductAmount));BigDecimal companyCostAmount = scale(payableAmount.add(socialCompany).add(fundCompany));
这几行同时说明了“企业成本”的范围：当前这里统计应发加公司社保、公积金，并没有把招聘、办公场地等费用都计算进来。做报表时应沿用这个口径，不能把字段名字直接解释为企业的全部用工成本。
本例个税 73.80 元是教学配置及此前已确认记录共同产生的结果，不是一个可直接套用到其他员工的固定扣款。
从建批次开始，把人、月份和取数方式对齐
这次实操使用独立的“人力教学薪酬主体”，建立“教学-2026年11月固定月薪”批次，编号为 SA202610189091，只包含林晓禾一名教学员工。先用一个人把链路核对清楚，比一开始就看几十人的合计更容易发现问题。
批次保存后点击试算，打开“查看结果”，核对姓名、人数和项目。下面这张完整画面，已经能对上 8000 元基本工资、500 元补贴和三项扣款。
历史试算结果：横向滚动到金额区，右侧仍固定显示提示与异常，方便金额和取数条件一起核对。
后台的 runTrial 也按这个顺序组织：先校验批次能否试算，再读取薪酬主体下的员工薪资档案；批次年月生成计算区间，档案关联薪酬方案及当前版本，随后逐人计算并保存结果。
这里的“版本”值得单独看。当前实现通过档案的 currentVersionId 取版本，再检查它是否在工资期间生效。它并没有在这段入口里遍历所有历史版本，自动把一个月拆成调薪前后两段。二开时若要支持月中调薪分段计薪，必须另外设计分段取数和汇总，不能仅凭“有版本表”就认为已经具备。
同样，基本工资在页面上显示 8000，并不意味着它写死在 Java 代码中。教学工资条里的取数配置指向薪资档案；项目规则决定读哪个来源，档案版本提供本次使用的数据。排查金额不对时，可以沿着“项目说明→取数配置→关联档案版本”逐层查，而不是直接在工资条上改数字。
试算结果会记下 archiveId、archiveVersionId、salaryPlanId。这些关联让后面的排查能落到具体记录，但不等于所有配置都已经实现不可变历史存档。
提示还在，为什么教学工资可以继续？
本例试算完成后，右侧并非一片空白，而是保留了“考勤未锁定”“按实时打卡计算”“专项附加已用规则默认”等提示。
历史试算的另一横向位置：7386.20 元实发与来源提示同屏，提示没有为了截图好看而消除。
实际核对分了两条线。考勤这边，教学方案采用固定月薪，未启用考勤扣款；因此这次没有把“无打卡”解释成应扣掉整月工资。专项附加这边，教学假设为零，同时回查了该员工 10 月已确认的计税记录，再核对本期结果。
这两个判断都依赖本例配置。换成考勤参与计薪的方案，仍然沿用“忽略提示直接确认”的做法，就可能算出另一份工资。
当前源码也保留了这种来源差别：月份锁定且存在员工月报时可以使用月报，否则按对应分支读取打卡并记录提示。考勤计算结果会进入上下文；究竟形成多少扣款，还需要继续看方案项目和扣款规则。“读到了考勤”与“按考勤扣了钱”是两个需要分别验证的问题。
这次教学还遇到过一个实际前置问题：员工尚未生成系统用户，首次试算失败。操作记录中是在员工档案完成用户关联后，继续原批次重新试算，没有新建另一批相同工资。它说明员工主档、薪资档案和登录用户之间的关系，既影响员工最后查看工资条，也可能影响前面的计算取数。
因此，复核说明应写清“本批哪些项目参与计算、哪些提示已经核对、为什么可继续”，而不是只有一句“数据正确”。页面给出的颜色和提示帮助定位问题，真正的确认依据仍然是对应的业务记录。
可追溯的关键：员工结果与工资条各存一份快照
工资确认之后，员工档案和规则仍可能继续调整。下个月再打开旧工资条，如果页面临时读取当前档案重新计算，就可能看不到当时确认的那份结果。
这里把数据分成几层：批次管理期间与整批状态；员工结果保存个人金额和计算快照；项目明细保存逐项金额；工资条保存发布时的展示内容。
按源码对象整理的数据关系示意，省略无关字段；连线表示业务引用，不表示数据库外键约束。
员工计算快照 calcSnapshotJson 的重点是“这次怎样算”：档案版本、岗位及绩效摘要、考勤、异常、项目和税额上下文。下面是当前实现的部分字段，并非完整快照：
Map<String, Object> snapshot = new LinkedHashMap<>();snapshot.put("batchCode", batch.getBatchCode());snapshot.put("employeeId", archive.getEmployeeId());snapshot.put("archiveVersionId", version.getId());snapshot.put("position", buildPositionSnapshot(employee, positionRate));snapshot.put("performanceResult", buildPerformanceResultSnapshot(performanceResult));snapshot.put("attendance", attendanceSummary.toSnapshot());snapshot.put("attendanceRule", buildAttendanceRuleSnapshot(attendanceRule));snapshot.put("exceptionTags", exceptionTags);snapshot.put("summary", buildSummary(payableAmount, deductAmount,actualAmount, companyCostAmount));snapshot.put("items", items);
工资条的 snapshotJson 则面向已经发布的结果：员工、年月、项目列表和金额汇总。发布方法从批次员工结果及项目明细构造它，员工端读取快照展示，不在打开页面时重跑薪资规则。
这两份快照的用途不同。排查少了哪项补贴，要追到员工计算结果与项目来源；核对员工当时看到的工资条，要查看发布结果。只保留工资条总额，会丢掉前者；把所有计算上下文直接堆到员工页面，又会让后者难读。
快照也有实际边界：当前实现保存的是选定字段和引用，不能据此宣称任意历史规则都能完整重演。若项目要求完整复算，应再核验规则版本、原始输入及算法版本是否一起保留。
确认以后，为什么不能随手再点一次试算
教学操作先发起薪资确认，经过实际配置的两个审批节点，再对同一批次发起发薪登记。后者通过后，系统自动生成并发布工资条。
历史批次回查画面：仍是同一编号和 11 月期间，操作入口已随进度变化。教学记录中的“已发薪”不代表发生了银行转账。
这里最重要的工程问题，是防止确认人审核的结果被下一次试算悄悄替换。
当前试算在事务中先清理本批次旧试算结果，再重新写入员工结果、项目和试算台账。它并不是每点一次就追加一版。因此入口先检查：已发起确认审批、已确认、已发薪或已发布工资条的批次，不能继续走普通试算。
按当前服务调用整理的主路径，省略驳回、异常和权限分支；本图不包含银行支付接口。
发薪登记通过的业务回调依次调用 registerPayment 和 publishPayslipsIfNeeded。后者先看批次是否已发薪，再看工资条是否已发布，满足条件才调用发布。已经登记但历史上缺工资条的情形，也有补发判断。
这能解释为什么正常操作无需再手动发布一次，也解释了为什么出现异常时应先回查原单，而非反复提交新的登记。不过，状态检查并不自动证明并发请求下绝不会重复；高并发和重试场景仍应结合数据库约束与实际测试审视。
工资确认还有一个不那么显眼的动作：把本批次试算税额台账转成已确认，供后续月份累计读取。教学案例的 11 月结果引用 10 月已确认记录，正好展示了工资批次之间并不是完全独立的。
最后一公里：员工看到自己的工资条
工资条发布后，教学员工通过自己的账号打开员工端，查看 11 月记录。金额仍是 8500、1113.80 和 7386.20，项目明细来自发布快照；本人打开后，已读状态随之更新。
历史员工端 H5 的宽屏完整截图，保留原视口；不是本轮重新拍摄的手机尺寸画面。
这个入口要查的不只是页面有没有“我的”两个字。服务端根据登录用户查员工，列表查询覆盖请求里的员工条件，只取该员工已发布的工资条。查单条详情时，再比较工资条归属，不能只靠列表过滤。
已读动作也复用归属检查，核心实现如下：
(rollbackFor = Exception.class)public void readSalaryPayslip(Long id) {SalaryPayslipDO payslip = getMySalaryPayslip(id);salaryPayslipMapper.updateById(new SalaryPayslipDO().setId(id).setReadStatus(STATUS_YES).setReadTime(LocalDateTime.now()));}
其中 getMySalaryPayslip 会校验当前员工与记录的 employeeId 是否一致。管理员查看管理端详情不会走同一个本人已读动作，所以不能拿“HR 打开过”替代“员工已查看”。已读也仅表示查看记录，不等于员工认可金额或确认到账。
做一遍薪酬系统验收，可以用这笔案例的核对方法：在同一员工、同一批次下，先从项目说明定位取数，再核对试算明细和异常处理依据，最后到员工自己的入口查看发布结果。每个阶段都能解释金额为什么相同、状态为什么不同，这张工资条才真正接上了前面的业务。