From cd523cced02a3fa163fdb832ae66b9eb451609ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=8D=8E=E4=BD=97?= Date: Fri, 12 Jun 2026 16:31:36 +0800 Subject: [PATCH] =?UTF-8?q?docs(bug):=20=E8=AF=B8=E8=91=9B=E4=BA=AE?= =?UTF-8?q?=E5=88=86=E6=9E=90=E6=8A=A5=E5=91=8A=20Bug=20#761?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- MD/bugs/BUG_761_ANALYSIS.md | 132 ++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 MD/bugs/BUG_761_ANALYSIS.md diff --git a/MD/bugs/BUG_761_ANALYSIS.md b/MD/bugs/BUG_761_ANALYSIS.md new file mode 100644 index 000000000..6fbe7a73d --- /dev/null +++ b/MD/bugs/BUG_761_ANALYSIS.md @@ -0,0 +1,132 @@ +# 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行:``,将 `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 + + + + + + + +``` + +**改动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 + + + + + +``` + +#### 无需修改的部分 +- `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 分析决策