Files
his/MD/bugs/BUG_761_ANALYSIS.md

133 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Bug #761 诸葛亮分析报告
> **文档类型**: Bug分析
> **分析时间**: 2026-06-12 16:31:36
> **分析模型**: mimo-v2.5 (LLM深度分析)
---
## 基本信息
- **Bug #**: 761
- **标题**: [住院护士站-汇总领药]领药明细列表,“领药时间”显示逻辑异常且早于医嘱开立时间
- **模块**: 病区护士工作站
- **提出人**: 陈显精
---
I now have a complete understanding of the bug. Let me produce the analysis.
---
### 一、Bug 理解
用户在"住院护士站 → 汇总领药"页面看到"领药时间"列显示了错误的日期("06-09"早于医嘱开立时间06-10 05:18:44和实际执行时间06-10 05:18。期望①列名改为"执行时间";②时间值应与医嘱执行界面的执行时间一致;③未发药/未汇总前不应展示"领药时间"。
### 二、根因分析
**全链路追踪:**
```
前端 prescriptionList.vue → API: getPrescriptionList
→ 后端 MedicineSummaryController.getMedicineDispenseFormPage
→ MedicineSummaryAppServiceImpl.getMedicineDispenseFormPage
→ MedicineSummaryAppMapper.selectMedicineDispenseFormPage (SQL)
→ 返回 MedicineDispenseFormDto.medicineSummaryParamList
→ 其中 dispenseTime 来自 med_medication_dispense.planned_dispense_time
```
**核心问题2处**
**问题1数据源错误 — `planned_dispense_time` ≠ 执行时间**
- Mapper XML 第39行`<result property="dispenseTime" column="planned_dispense_time"/>`,将 `med_medication_dispense.planned_dispense_time` 映射为 `dispenseTime`
- `planned_dispense_time` 是在 `AdviceProcessAppServiceImpl` 调用 `generateMedicationDispense()` 时通过 `parseExecuteTime(executeTime)` 设置的,来自前端传入的执行时间字符串
- 实际执行时间存储在 `cli_procedure.occurrence_time``Procedure.java` 第54行这才是医嘱执行界面显示的"执行时间"
- `planned_dispense_time` 的值可能因时区转换、字符串解析精度等原因与 `occurrence_time` 不一致(差一天即 "06-09" vs "06-10"
**问题2列名语义错误 — "领药时间"应为"执行时间"**
- `prescriptionList.vue` 第164行`title="领药时间"`,此列展示的是每条医嘱的执行时间点,不是"领药时间"
- 在未生成汇总领药单之前,不存在"领药"动作,显示"领药时间"不符合业务逻辑
**涉及文件:**
| 文件 | 行号 | 问题 |
|------|------|------|
| `prescriptionList.vue` | 164 | 列名 "领药时间" 应改为 "执行时间" |
| `MedicineSummaryAppMapper.xml` | 39, 78, ~125, 203 | `planned_dispense_time` 应改为 `cli_procedure.occurrence_time` |
| `MedicineSummaryParam.java` | 22 | 字段名 `dispenseTime` 可保持不变(仅改数据源) |
### 三、修复方案
#### 修改1后端 Mapper XML — 改用执行时间
**文件**: `healthlink-his-server/healthlink-his-application/src/main/resources/mapper/inhospitalnursestation/MedicineSummaryAppMapper.xml`
**改动A**resultMap collection 映射,将 `dispenseTime` 的数据源从 `planned_dispense_time` 改为 `occurrence_time`(来自 `cli_procedure` 表):
```xml
<!-- 第36-41行collection 改为: -->
<collection property="medicineSummaryParamList" ofType="com.healthlink.his.web.inhospitalnursestation.dto.MedicineSummaryParam">
<result property="procedureId" column="procedure_id"/>
<result property="dispenseId" column="dispense_id"/>
<result property="dispenseTime" column="execution_time"/>
<result property="dispenseStatus" column="dispense_status"/>
</collection>
```
**改动B**:内层 SQL 增加 `cli_procedure` JOIN 并选取 `occurrence_time`
在内层 SELECT约第98行 `mmd.status_enum AS dispense_status` 之后)添加:
```sql
cp.occurrence_time AS execution_time,
```
在 FROM 子句中 `med_medication_dispense AS mmd` 之后添加 LEFT JOIN
```sql
LEFT JOIN cli_procedure cp
ON cp.id = mmd.procedure_id
AND cp.delete_flag = '0'
```
**改动C**:外层 SELECT第78行`ii.planned_dispense_time` 改为 `ii.execution_time`
```sql
ii.execution_time,
```
**改动D**ORDER BY第203行`mmd.planned_dispense_time` 改为 `cp.occurrence_time`
```sql
ORDER BY cp.occurrence_time )) AS ii
```
#### 修改2前端列名 — "领药时间" → "执行时间"
**文件**: `healthlink-his-ui/src/views/inpatientNurse/drugDistribution/components/prescriptionList.vue`
第164行
```vue
<!-- 修改前 -->
<vxe-column title="领药时间" field="times">
<!-- 修改后 -->
<vxe-column title="执行时间" field="times">
```
#### 无需修改的部分
- `MedicineSummaryParam.java` — 字段名 `dispenseTime` 保持不变,仅后端数据源改变
- `MedicineSummaryAppServiceImpl.java` — 无变化(`medicineSummary()` 方法提交时自行用 `new Date()` 覆盖)
- 前端时间格式化逻辑 — `item.dispenseTime?.substring(5, 10)` 从 "yyyy-MM-dd HH:mm:ss" 截取 "MM-dd",格式兼容
### 四、路由决策
**FIXER: guanyu后端开发**
**REASON**: 修复核心在 Mapper XML SQL 改写JOIN `cli_procedure``occurrence_time` 替代 `planned_dispense_time`),属于后端数据查询层改动。前端仅改一个列名文本,可一并处理但主要工作量在后端 SQL。
---
## 路由决策
- **修复 Agent**: guanyu
- **原因**: LLM 分析决策