83a6fd1f
 “wangming”
feat: 添加员工确认状态及相关...
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
# 工资条确认功能方案分析
## 需求概述
**业务流程**：
1. 系统自动计算工资 →
2. 导出Excel进行线下梳理处理 →
3. 导入Excel（包含调整后的数据）→
4. 形成工资条（锁定）给员工查看 →
5. 员工确认工资条 →
6. 确认后工资数据不可再修改
## 现有表结构分析
### 所有工资表共有的字段
- `F_IsLocked` INT - 管理员锁定状态（0=未锁定，1=已锁定）
- `F_CreatorTime` DATETIME - 创建时间
- `F_LastModifyTime` DATETIME - 最后修改时间
- **缺少**：员工确认状态、员工确认时间
### 涉及的工资表（9个）
1. `lq_salary_statistics` - 健康师
2. `lq_tech_teacher_salary_statistics` - 科技部老师
3. `lq_assistant_salary_statistics` - 店助/店助主任
4. `lq_store_manager_salary_statistics` - 店长
5. `lq_director_salary_statistics` - 主任
6. `lq_major_project_teacher_salary_statistics` - 大项目部老师
7. `lq_major_project_director_salary_statistics` - 大项目主管
8. `lq_tech_general_manager_salary_statistics` - 科技部总经理
9. `lq_business_unit_manager_salary_statistics` - 事业部总经理/经理
## 方案对比
### 方案1：在现有表上添加确认字段 ⭐ 推荐
**实现方式**：
- 在每个工资表中添加以下字段：
- `F_EmployeeConfirmStatus` INT DEFAULT 0 COMMENT '员工确认状态（0=未确认，1=已确认）'
- `F_EmployeeConfirmTime` DATETIME NULL COMMENT '员工确认时间'
- `F_EmployeeConfirmRemark` VARCHAR(500) NULL COMMENT '员工确认备注（可选）'
**优点**：
- ✅ 简单直接，符合现有架构
- ✅ 所有数据集中在一个表中，查询方便
- ✅ 不需要维护多表同步
- ✅ 实现成本低，修改范围可控
- ✅ 导出/导入逻辑清晰（保护已确认数据）
**缺点**：
- ⚠️ 导入时需要判断确认状态，已确认的数据不能覆盖
- ⚠️ 如果重新计算工资，需要处理已确认数据的冲突
**关键逻辑**：
1. **导出时**：正常导出，包含确认状态字段
2. **导入时**：
- 如果记录已确认（`F_EmployeeConfirmStatus = 1`），则跳过导入，保持原数据不变
- 如果记录未确认，则可以更新
3. **员工确认**：
- 只能确认未锁定的记录（`F_IsLocked = 0`）
- 确认后将 `F_EmployeeConfirmStatus` 设为 1，记录确认时间
- 确认后自动锁定（`F_IsLocked = 1`），防止后续修改
4. **计算工资**：
- 如果记录已确认，不能重新计算（或需要先解除确认）
- 或者：重新计算时，如果记录已确认，则创建新记录而不是更新旧记录
---
### 方案2：新建独立的工资条确认表
**实现方式**：
- 创建新表 `lq_salary_slip_confirm`，存储已确认的工资条快照
- 表结构：包含所有工资字段 + 确认相关字段
- 确认时将工资统计数据复制到确认表
**优点**：
- ✅ 计算表和确认表职责分离
- ✅ 可以保留确认历史（多次确认）
- ✅ 导出/导入不影响确认状态
**缺点**：
- ❌ 需要维护两个表的同步
- ❌ 查询时需要关联两个表
- ❌ 数据结构复杂，实现成本高
- ❌ 数据冗余，存储空间增加
- ❌ 修改字段时需要同步修改两个表
---
## 推荐方案：方案1（在现有表上添加确认字段）
### 实施步骤
#### 1. 数据库表修改
为所有9个工资表添加确认字段：
```sql
ALTER TABLE lq_salary_statistics
ADD COLUMN F_EmployeeConfirmStatus INT NOT NULL DEFAULT 0 COMMENT '员工确认状态（0=未确认，1=已确认）',
ADD COLUMN F_EmployeeConfirmTime DATETIME NULL COMMENT '员工确认时间',
ADD COLUMN F_EmployeeConfirmRemark VARCHAR(500) NULL COMMENT '员工确认备注';
-- 重复为其他8个表添加相同字段
```
#### 2. 实体类修改
为所有9个工资实体类添加属性：
```csharp
/// <summary>
/// 员工确认状态（0=未确认，1=已确认）
/// </summary>
public int EmployeeConfirmStatus { get; set; }
/// <summary>
/// 员工确认时间
/// </summary>
public DateTime? EmployeeConfirmTime { get; set; }
/// <summary>
/// 员工确认备注
/// </summary>
public string EmployeeConfirmRemark { get; set; }
```
#### 3. 服务类修改
**a. 导入功能修改**（如果存在）：
- 导入前检查：如果 `F_EmployeeConfirmStatus = 1`，跳过该记录，不更新
- 或者提示用户：该记录已确认，是否继续（需要管理员权限）
**b. 新增员工确认接口**：
```csharp
[HttpPost("confirm")]
public async Task<string> ConfirmSalary(string id, string employeeId, string remark = null)
{
// 1. 验证记录是否存在
// 2. 验证是否为该员工的工资
// 3. 验证是否已锁定或已确认
// 4. 更新确认状态和时间
// 5. 自动锁定记录（F_IsLocked = 1）
}
```
**c. 计算工资功能修改**：
- 计算前检查：如果记录已确认，需要先解除确认（管理员操作）或创建新记录
**d. 导出功能修改**：
- 导出时包含确认状态字段
#### 4. 前端功能
- 工资条查看页面：显示确认状态
- 确认按钮：员工点击确认后调用确认接口
- 已确认的工资条：显示确认时间和状态，不允许修改
---
## 方案确认
✅ **推荐使用方案1**，原因：
1. 实现简单，符合现有架构
2. 数据集中管理，查询方便
3. 修改范围可控，风险低
4. 满足业务需求：确认后不可修改
---
## 注意事项
1. **导入保护**：已确认的数据不能通过导入覆盖
2. **计算保护**：已确认的数据不能重新计算（或需要管理员解除确认）
3. **权限控制**：只有员工本人可以确认自己的工资条
4. **审计日志**：建议记录确认操作的日志
5. **解锁机制**：已确认的记录如果确实需要修改，需要管理员先解除确认
|
