0bf53482
 “wangming”
feat: implement d...
|
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
|
# 库存使用记录 - 修复与测试报告
## 一、问题与修复概要
| 项目 | 说明 |
|------|------|
| 问题1 | 修改申请时，同一产品+门店出现多条记录 → 领用多算 |
| 修复1 | UpdateApplicationUsageRecords 按 ProductId+StoreId 合并 |
| 问题2 | 历史已有多算数据无法人工调整 |
| 修复2 | 新增 FixDuplicateUsageRecords 自动修复接口 |
| 验证点 | 作废记录不应参与领用统计 |
---
## 二、代码审查结论：作废记录是否会被统计？
### ✅ 结论：作废记录（IsEffective=0）**不会**被计入领用统计
所有涉及 `totalUsage`、领用数量统计的查询均包含 `IsEffective == StatusEnum.有效` 条件：
| 文件 | 位置 | 说明 |
|------|------|------|
| LqInventoryUsageService | GetReceivedBatchIdsAsync、MarkReceivedAsync、CalculateAveragePriceFromInventoryAsync 等 | `x.IsEffective == StatusEnum.有效.GetHashCode()` |
| LqInventoryService | 入库前检查、可用库存、平均单价计算 | `x.IsEffective == StatusEnum.有效.GetHashCode()` |
| LqProductService | 产品作废检查、库存明细 | `x.IsEffective == StatusEnum.有效.GetHashCode()` |
| GetStoreReceiveCostStatistics | whereConditions | `u.F_IsEffective = 1` |
| LqBusinessUnitManagerSalaryService | 原生SQL | `WHERE u.F_IsEffective = 1` |
| LqDirectorSalaryService | 原生SQL | `WHERE u.F_IsEffective = 1` |
| LqStoreManagerSalaryService | 原生SQL | `WHERE u.F_IsEffective = 1` |
**领用作废后可用库存会加回去**：作废使用记录后，该记录不再参与 totalUsage 统计，可用库存 = 总库存 - totalUsage 会自动增加。
---
## 三、数据库现状（MCP 查询结果）
- 有效使用记录总数：3240 条
- **存在重复数据**：至少 5 组同一 UsageBatchId+ProductId+StoreId 有多条有效记录，需执行修复接口
示例重复组：
- 批次 770197935005631749，产品 763991211127080197，门店 1649328471923847172：2条，总数量6
- 批次 770807754649502981，产品 763992934394627333，门店 1649328471923847187：2条，总数量4
- …
---
## 四、测试清单
### 1. 修复接口测试 FixDuplicateUsageRecords
```bash
# 1) 获取 Token
|
|
8daf47d0
“wangming”
修改访问地址
|
53
|
TOKEN=$(curl -s -X POST "http://localhost:2015/api/oauth/Login" \
|
|
0bf53482
“wangming”
feat: implement d...
|
54
55
56
57
|
-H "Content-Type: application/x-www-form-urlencoded" \
-d "account=admin&password=e10adc3949ba59abbe56e057f20f883e" | jq -r '.data.token')
# 2) 执行修复
|
|
8daf47d0
“wangming”
修改访问地址
|
58
|
curl -X POST "http://localhost:2015/api/Extend/LqInventoryUsage/FixDuplicateUsageRecords" \
|
|
0bf53482
“wangming”
feat: implement d...
|
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
|
-H "Authorization: $TOKEN" \
-H "Content-Type: application/json"
```
**验证**：
- 返回 `success: true`，`duplicateGroups`、`invalidatedCount` 合理
- 查库：同一 UsageBatchId+ProductId+StoreId 仅剩 1 条有效记录
- 查库：被合并的重复记录 `F_IsEffective = 0`
### 2. 修改申请防重复测试
1. 新建申请，同一产品+门店添加两条（或修改时故意提交重复）
2. 调用 `UpdateApplicationUsageRecords` 提交
3. 查库：该批次下同一产品+门店应只有 1 条有效记录，数量为合并值
### 3. 作废后不计入统计测试
1. 记录某产品当前可用库存 A
2. 新建申请并领用该产品若干数量，记领用后可用库存 B
3. 作废该领用记录
4. 再次查询可用库存，应恢复为 A（或接近 A，若存在其他领用）
### 4. 领用统计接口一致性测试
- 调用 GetStoreReceiveStatistics、GetStoreReceiveCostStatistics
- 与数据库直接 SUM 有效记录对比，结果一致
---
## 五、执行建议
1. **部署后立即执行**：`POST /api/Extend/LqInventoryUsage/FixDuplicateUsageRecords` 修复历史数据
|
|
8daf47d0
“wangming”
修改访问地址
|
91
|
2. **接口测试**：确保 API 已启动（localhost:2015），按上述 curl 执行
|
|
0bf53482
“wangming”
feat: implement d...
|
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
|
3. **查库验证**：按 mcp-mysql-and-sql-validation 规范，修复后必须查库核对
---
## 六、实际执行结果（2025-02-13）
### 1. 修复前数据库状态
- 有效使用记录：3240 条
- 无效使用记录：838 条
- **重复组**：5 组（同一 UsageBatchId+ProductId+StoreId 有多条有效记录）
| 批次ID | 产品ID | 门店ID | 重复条数 | 总数量 |
|--------|--------|--------|----------|--------|
| 784301392666821893 | 763979563993662725 | 1649328471923847179 | 2 | 20 |
| 787563597701055749 | 763987810846770437 | 1649328471923847176 | 2 | 270 |
| 770197935005631749 | 763991211127080197 | 1649328471923847172 | 2 | 6 |
| 784209727247615237 | 763991302353192197 | 1649328471923847188 | 2 | 10 |
| 770807754649502981 | 763992934394627333 | 1649328471923847187 | 2 | 4 |
### 2. 修复接口调用结果
```json
{
"success": true,
"message": "修复完成，处理 5 组重复数据，作废 5 条记录",
"duplicateGroups": 5,
"invalidatedCount": 5
}
```
### 3. 修复后数据库验证
- **重复组**：0 组 ✓（已清空）
- **有效记录**：减少 5 条（每组保留 1 条，作废 1 条）
- **无效记录**：843 条（原 838 + 新增 5）
- **合并验证**：以批次 787563597701055749 为例，保留 1 条有效（F_UsageQuantity=270, F_TotalAmount=1196.10），另 1 条已作废（F_IsEffective=-1）✓
### 4. 幂等性验证
再次调用修复接口，返回：
```json
{
"success": true,
"message": "未发现重复数据",
"duplicateGroups": 0,
"invalidatedCount": 0
}
```
✓ 幂等性正常，重复执行不会误伤数据。
### 5. 结论
- 修复接口工作正常
- 合并逻辑正确（数量、金额累加，保留 CreateTime 最早的一条）
- 作废记录 (F_IsEffective=-1) 不参与领用统计
- 无需后端代理修复，当前实现正确
|
