140 lines
5.9 KiB
Markdown
140 lines
5.9 KiB
Markdown
# Bug #712 诸葛亮分析报告
|
||
|
||
> **文档类型**: Bug分析
|
||
> **分析时间**: 2026-06-13 02:46:37
|
||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||
|
||
---
|
||
|
||
## 基本信息
|
||
- **Bug #**: 712
|
||
- **标题**: 【收费工作站-预交金管理】“预交金管理”页面缺失展示“支付方式”列及患者“床号”、“费用类型”
|
||
- **模块**: 住院登记管理
|
||
- **提出人**: 陈显精
|
||
|
||
---
|
||
|
||
分析完成。以下是完整的 Bug #712 分析报告。
|
||
|
||
---
|
||
|
||
## 一、Bug 理解
|
||
|
||
**Bug 标题**：【收费工作站-预交金管理】"预交金管理"页面缺失展示"支付方式"列及患者"床号"、"费用类型"
|
||
|
||
**重现步骤**：
|
||
1. 登录系统，进入"收费工作站" → "预交金管理"页面
|
||
2. 输入住院号查询关联患者（如"三太子"）
|
||
3. 检查患者基本信息卡片及下方收支明细列表
|
||
|
||
**期望结果**：
|
||
1. 患者卡片区增加展示"床号"（如：012床）与"费用类型"（医保类型，如：职工医保）
|
||
2. 明细列表区在"票据类型"与"收款时间"之间新增"支付方式"字段列
|
||
|
||
**附图分析关键信息**：
|
||
- 图2492/2493 显示患者卡片区域"在院科室/病区: 呼吸内科病房/呼吸内科一区"，**没有独立展示床号和费用类型**
|
||
- 收支明细列表列头为：序号、收据号、金额、票据类型、收款时间、收款员 —— **缺少"支付方式"列**
|
||
- 截图中有红色标注："增加患者床号和费用类型"、"增加支付方式字段列"
|
||
|
||
**综合总结**：用户在预交金管理页面查询住院患者后，患者信息卡片只显示了科室/病区，无法看到该患者的具体床号和医保费用类型；下方流水明细列表缺少支付方式列，无法知道每笔交易的支付渠道（现金/支付宝等）。这两个信息对打印收据和财务核对都是必需的。
|
||
|
||
---
|
||
|
||
## 二、根因分析
|
||
|
||
经过全链路 6 环分析，问题分布在前端和后端两个层面：
|
||
|
||
### 缺陷 1：费用类型（费用类型/医保类型）缺失
|
||
|
||
**前端** `index.vue:88-110`：患者信息卡片区域没有展示"费用类型"字段。
|
||
**后端** `AdvancePaymentInfoDto.java`：DTO 缺少 `ybClassText`（医保类别文本）字段。
|
||
**后端** `AdvancePaymentManageAppMapper.xml`：`getAdvancePaymentInfo` SQL 查询未 SELECT `ae.yb_class_text`。
|
||
**数据库**：`adm_encounter` 表已有 `yb_class_text` 字段（保险类型文本，如"职工医保"）。
|
||
|
||
### 缺陷 2：床号显示不突出
|
||
|
||
**后端** SQL 已查询 `alb.name AS bed_name`，DTO 已有 `bedName` 字段。
|
||
**前端** `index.vue:115-120`：床号被拼在"在院科室/病区"字符串中（`wardName + houseName + bedName`），没有独立展示为"床号：012床"。
|
||
|
||
### 缺陷 3：支付方式列缺失
|
||
|
||
**前端** `index.vue:147`：`<vxe-column field="payWay" title="支付方式" />` 被注释掉了。
|
||
**后端** `AdvancePaymentFlowRecordDto.java`：DTO 缺少支付方式字段（`payEnum` / `payWay`）。
|
||
**后端** `AdvancePaymentManageAppMapper.xml:90-99`：`getAdvancePaymentFlowRecordList` SQL 只查了 `fin_payment_reconciliation` 主表，**未 JOIN** `fin_payment_rec_detail` 子表（`pay_enum` 字段在子表中）。
|
||
**数据库**：`fin_payment_rec_detail` 表有 `pay_enum`（支付类型编码，如现金/支付宝/微信）。
|
||
|
||
**涉及文件清单**：
|
||
|
||
| 文件 | 修改内容 |
|
||
|------|---------|
|
||
| `AdvancePaymentInfoDto.java` | 新增 `ybClassText` 字段 |
|
||
| `AdvancePaymentManageAppMapper.xml` | `getAdvancePaymentInfo` SQL 加 `ae.yb_class_text` |
|
||
| `AdvancePaymentFlowRecordDto.java` | 新增 `payEnum` + `payWay` 字段 |
|
||
| `AdvancePaymentManageAppMapper.xml` | `getAdvancePaymentFlowRecordList` SQL JOIN `fin_payment_rec_detail`，取 `pay_enum` |
|
||
| `AdvancePaymentManageAppServiceImpl.java` | 流水记录返回后增加 `payWay` 枚举映射 |
|
||
| `index.vue` | 卡片区域新增"床号"和"费用类型"展示；取消注释支付方式列 |
|
||
|
||
---
|
||
|
||
## 三、修复方案
|
||
|
||
### Step 1：后端 — DTO 新增字段
|
||
|
||
**`AdvancePaymentInfoDto.java`**：新增字段
|
||
```java
|
||
/** 费用类型（医保类型文本，如：职工医保） */
|
||
private String ybClassText;
|
||
```
|
||
|
||
**`AdvancePaymentFlowRecordDto.java`**：新增字段
|
||
```java
|
||
/** 支付方式编码 */
|
||
private Integer payEnum;
|
||
/** 支付方式文本（如：现金、支付宝） */
|
||
private String payWay;
|
||
```
|
||
|
||
### Step 2：后端 — Mapper XML 修改
|
||
|
||
**`AdvancePaymentManageAppMapper.xml`**：
|
||
|
||
1. `getAdvancePaymentInfo` 子查询中加 `ae.yb_class_text AS yb_class_text`
|
||
2. `getAdvancePaymentFlowRecordList` SQL 加 JOIN `fin_payment_rec_detail`，取 `prd.pay_enum`
|
||
|
||
### Step 3：后端 — ServiceImpl 枚举映射
|
||
|
||
**`AdvancePaymentManageAppServiceImpl.java`**：
|
||
|
||
在 `getAdvancePaymentFlowRecord` 方法中增加支付方式枚举映射：
|
||
```java
|
||
e.setPayWay(EnumUtils.getInfoByValue(YbPayment.class, e.getPayEnum()));
|
||
```
|
||
|
||
### Step 4：前端 — 页面字段补充
|
||
|
||
**`index.vue`**：
|
||
1. 在"在院科室/病区"行下方（或同行），新增展示：
|
||
- `床号: {{ patientInfo.bedName }}`（独立标签）
|
||
- `费用类型: {{ patientInfo.ybClassText }}`
|
||
2. 取消注释支付方式列，改为：
|
||
```html
|
||
<vxe-column field="payWay" title="支付方式" align="center" min-width="100" />
|
||
```
|
||
3. 插入位置：在 `paymentEnum_enumText`（票据类型）列之后、`operateTime`（收款时间）列之前
|
||
|
||
---
|
||
|
||
## 四、路由决策
|
||
|
||
**FIXER**: zhaoyun（赵云 — 前端开发）
|
||
**REASON**: 本次修复核心在于前端页面展示（卡片字段补充 + 表格列取消注释），后端改动量较小（DTO 加 2 字段、SQL 加 2 列、Service 加 1 行映射），属于前后端联动的 UI 展示修复，赵云可一并处理前端和后端轻量改动。无需 DBA 审查（无建表/加字段迁移）。
|
||
|
||
---
|
||
|
||
## 路由决策
|
||
- **FIXER_ID**: guanyu
|
||
- **修复 Agent**: guanyu（后端）
|
||
- **原因**: LLM 分析决策
|
||
|
||
> ⚠️ 修复人员请先验证以上分析是否正确，再执行修复。
|