Zhejiang Second Hospital · Pharmacy Department

浙医二院药学部智慧医药精细化管理系统

覆盖人员档案、绩效分配、职级评定、审批流转的一体化人事管理系统。前后端分离,支持公网与内网双环境部署,绩效计算全部由服务端按可配置参数自动完成。

Spring Boot 2.7.12 MyBatis-Plus 3.5.1 Vue 3 + Element Plus MySQL · Redis · EasyExcel 三角色三级数据可见性
01 / PROJECT

项目概览

本系统面向药学部内部的人事与绩效管理,把过去靠 Excel 手工分算的月度绩效,转为"导入原始数据 → 服务端按规则计算 → 分级核对 → 审批归档"的标准流程。

后端 Java 类
165
13 个 Controller · 4 层分层
前端视图页
17
配套 15 个 API 模块
运行环境
dev/prod/intranet
三套 Spring Profile
服务端口
8803
前端 8080 · 内网 192.168.219.17

技术栈与分层

前端Vue 3 · Vue Router · Element Plus · Axios · Vue CLI
后端Spring Boot 2.7.12 · MyBatis-Plus 3.5.1 · Druid · Redis
数据MySQL 5.7+(库名 eryuan_person)· Redis(可选)
工具EasyExcel 3.2.1(导入导出)· Hutool · Lombok
后端按 common / data / web 三层组织:common 放配置、切面、异常处理、Excel 监听器;data 放 DTO / Request / Response / VO;web 放 Controller / Service / Mapper / Model。统一返回 Result<T>,异常由 GlobalExceptionHandler 兜底,实体统一 *DO 后缀。

目录与规模

backend/Spring Boot 工程,add.sql 为增量脚本,测试目录含 MyBatis-Plus 代码生成器
frontend/Vue CLI 工程,.env.development / .production / .intranet 三套环境变量
02-浙二项目/项目全过程档案:需求、研发、商务、汇报、验收、软著、部署
根目录deploy-intranet.sh / .bat 内网部署脚本 · check-config.sh · 内网部署说明
交付形态:内网单机部署(java -jar person-admin.jar --spring.profiles.active=intranet),由 application-intranet.yml 切换数据库、Redis 与文件服务地址,支持从公网 60.205.130.213 平滑迁移到院内网段。

功能模块与后端接口对照

业务域前端页面后端 Controller路径前缀
人员与权限人员档案、部门配置、角色管理UserController / DeptController/eryuan/user · /eryuan/dept
绩效参数绩效参数设置PerformanceArgumentController/eryuan/performance-Argument
个人绩效个人绩效管理、手动绩效上传、绩效申报IndividualPerformanceController / PerformanceController/eryuan/individual-performance · /eryuan/performance
部门绩效部门绩效管理DeptPerformanceController/eryuan/deptPerformance
职级评定基础职级规则、职级贡献规则、人员职级管理RankAssessmentRuleController / RankContributionRuleController / UserDetailController/eryuan/rankAssessmentRule · rankContributionRule · userDetail
审批流转审批管理、申请职级升级RankPromotionApplicationController/eryuan/rankPromotionApplication

角色与数据可见性

角色枚举值可见范围
管理员0全院全部部门与人员,可生成绩效、审批职级
组长1仅本部门(dept_id = 当前用户 deptId)
普通员工2仅本人(user_id = 当前用户)
可见性过滤写在查询构造器里(如 getPerformanceList),组长/员工的行级约束由后端强制,前端不传参也拦得住。

月度业务流程

步骤 1
原始数据导入
手动绩效上传 / 初始化绩效
步骤 2
组员绩效申报
写入临时绩效数据
步骤 3
组长绩效核对
逐人调整/确认
步骤 4
管理员审批
服务端生成绩效并落库
生成绩效前会校验本月各部门是否全部完成申报(checkDeclarationDept);同一月份重复生成时,先真删除上次的个人绩效与部门绩效再重算。
02 / ALGORITHM

绩效计算规程 · 分步动画

下图逐帧还原服务端 IndividualPerformanceServiceImpl.generativePerformance() 的真实计算顺序。所有数字由页面内复刻的同一套算法实时算出,改动任一参数即重新计算。

计算参数

生成绩效时管理员录入
绩效参数设定表
绩效参数设定表
折算进部门人数
从总池中扣减
从总池中扣减
分组各算点值
先行结算的部门
决定当月职级
计算流程1 / 8

个人绩效计算结果

共 0 人 · 口径为当月职级
工号姓名部门编制系数当月职级职级系数 岗位绩效部门绩效加班绩效夜班绩效绩效总额
已发放个人合计 元 总池扣减后 元 池内留存未分配 元
03 / NOTES

代码级计算口径说明

以下差异均来自对后端源码的逐行核对,会直接影响对账结果,使用前需与业务方确认口径。

  1. 编制系数和初值为 1。sumCoefficient 在 generativePerformance 中初始化为 new BigDecimal(1),导致岗位绩效实际只按 Σ编制系数 ÷ (1 + Σ编制系数) 发放,本例约少发 6.3%。
  2. 领导平均奖金逻辑当前不生效。代码中 leaderNum 被硬编码为 0(原按 RoleType.NORMAL 统计的语句已注释),领导扣除数为 0。
  3. 病产假是乘数且做加法。总额公式实际为 岗位 + 部门 + (加班 + 夜班) × 病产假系数 + 绩效调整,与注释里写的"−病产假"不一致;病产假系数为 1 表示全额,0.8 表示按 8 成计发加班夜班部分。
  4. 不计奖人员的折算份额不落到个人。其 5% 计奖比例计入了部门折算人数与部门分配额,但个人部门绩效按"平均奖 × 编制系数"发放,这部分形成部门留存。
  5. 点值分母与发放对象口径不一致。点值的系数和取自全部非管理员人员(含未导入加班夜班记录者),而绩效金额只写入有导入记录的人。
  6. 江干/非江干两组共用同一总编制系数和。两组各自独立摊销同一份岗位绩效总额,因此合计不足额,且开启江干单独计算时总发放比例与关闭时不同。
  7. 两个比例之和通常不等于 100%。岗位绩效与部门绩效分别按两个比例从"总绩效扣除数"中取,两部分之和未必等于扣除数,存在系统性结余。
  8. 扣除开关只作用于总池,不影响个人加班夜班金额。开启"扣除加班/夜班"仅从总绩效池中扣减,个人项下加班与夜班仍照常累加。
  9. 舍入口径。部门绩效总额、点值、部门分配额用 HALF_UP 保留两位;岗位绩效总额直接相乘相除未显式舍入。
← 返回首页