18391c1fe5
fix( #613 ): 请修复 Bug #613：【医嘱校对/住院医生工作站】医嘱退回流程缺失反馈机制：护士端退回无原因录入，医生端缺失原因显示
...
根因：
- 1. ❌ 录入（护士端无退回原因输入弹窗）
- 2. ❌ 保存（后端不保存退回原因）
- 3. ❌ 查询（Mapper XML 不查询退回原因字段）
- 4. ❌ 展示（医生端不显示退回原因）
- 5. ❌ ServiceRequest 已有 `reasonText` 字段但未使用
- 6. ❌ MedicationRequest 无退回原因字段
修复：
- Step 1**: 添加 `backReason` 到后端 DTO
2026-05-29 10:02:24 +08:00
9b422b06e0
fix( #599 ): 请修复 Bug #599：【门诊手术安排-计费】门诊手术计费界面误触发显示了门诊医嘱中的非手术计费相关费用项目
...
根因：
- **
- `DoctorStationAdviceAppMapper.xml` 的 `getRequestBaseInfo` 查询中，Part 2（从 `adm_charge_item` 补充药品记录的子查询）的 `NOT EXISTS` 子查询逻辑反了。
- 当手术计费查询（`generateSourceEnum=6`）时：
- Part 1** ✅ `WHERE T1.generate_source_enum = 6` — 正确返回手术相关药品
- Part 2** 🐛 `NOT EXISTS (SELECT ... WHERE T5.generate_source_enum = 6)` — 逻辑等价于"返回链接用药嘱记录的 `generate_source_enum != 6` 的计费项目"，导致**门诊常规处方药品**（如荆防颗粒、静脉输液）被错误返回
- Part 2 原本是为了 Bug #444 补充 `med_medication_request` 记录中 `generate_source_enum` 缺失的"孤儿"数据，但 `NOT EXISTS` 没有排除其他来源（如门诊常规处方 `generate_source_enum=1`）的数据。
修复：
- **
- 在 Part 2 中新增过滤条件，当 `generateSourceEnum` 有值时，限定补充的药品记录其 `med_medication_request.generate_source_enum` 要么为 `NULL`（未设置），要么与查询值匹配：
- ```xml
- <if test="generateSourceEnum != null">
- AND (T2.generate_source_enum IS NULL OR T2.generate_source_enum = #{generateSourceEnum})
- 变更文件：**
- `openhis-server-new/openhis-application/src/main/resources/mapper/doctorstation/DoctorStationAdviceAppMapper.xml` — Part 2 新增 `generate_source_enum` 过滤条件
- 全链路验证（6 环）：**
- 1. **录入** → 手术安排界面点击"计费"→ `handleChargeCharge()` 设置 `generateSourceEnum: 6`
- 2. **保存** → `prescriptionlist.vue` 中签到/保存时设置 `generateSourceEnum=6` ✓
- 4. **修改** → 不受影响（编辑使用同一查询） ✓
- 5. **删除/签发/签退** → 不受影响（各自有独立的状态校验） ✓
- 6. **关联模块** → 注册医生站 `AdviceManageAppMapper.xml` 无 Part 2 补充逻辑，不受影响 ✓
- 编译检查：** `mvn compile` 通过 ✅
2026-05-29 08:58:32 +08:00
034ac71f13
fix( #572 ): 请修复 Bug #572：[一般] [门诊医生工作站-诊断] 传染病报告卡未自动同步并填充患者档案中的“现住址”与“职业”信息
...
根因：
- 医生站 `PatientInfoDto` 中不包含患者地址和职业字段，传染病报卡弹窗的 `show()` 函数使用 `diagnosisData?.addressProv || ''`（诊断数据中的地址，始终为空）和硬编码 `occupation: ''`，完全未从患者档案获取数据。
- ### 修改内容（4 个文件）
- 后端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `openhis-application/.../dto/PatientDetailsDto.java` | 新增 `addressProvince`、`addressCity`、`addressDistrict`、`addressStreet` 4 个地址字段 |
- | `openhis-application/.../mapper/doctorstation/DoctorStationPtDetailsAppMapper.xml` | SQL 查询增加 `p.address_province`、`p.address_city`、`p.address_district`、`p.address_street` |
- 前端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `src/views/doctorstation/components/api.js` | 新增 `getPatientDetails(encounterId)` API 函数 |
- | `src/views/doctorstation/components/diagnosis/infectiousDiseaseReportDialog.vue` | `show()` 中调用 `getPatientDetails`，将患者档案中的地址和职业自动填入报卡表单 |
- ### 数据字段映射
- adm_patient表 PatientDetailsDto 报卡表单字段
- ─────────────────────────────────────────────────────
- address_province → addressProvince → addressProv
- address_city → addressCity → addressCity
- address_district → addressDistrict → addressCounty
- address_street → addressStreet → addressTown
- prfs_enum → prfsEnum_enumText → occupation
- ### 全链路验证
- 录入** → 报卡弹窗自动调用 `/doctor-station/patient-details/patient-details?encounterId=X` ✓
- 保存** → 地址和职业字段已包括在 `saveInfectiousDiseaseReport` 提交数据中 ✓
- 查询/回显** → `showReport()` 正确读取已有报卡的地址和职业 ✓
- 编译** → 前端 `npm run lint` ✓，后端 `mvn compile` ✓
修复：
- 变更摘要
2026-05-29 01:56:41 +08:00
23a3215121
fix( #570 ): 请修复 Bug #570：[一般] [门诊预约挂号] 患者预约成功后的状态显示错误为“已锁定”，导致查询“已预约”状态数据为空
...
根因：
- 预约成功后，槽位状态从 `AVAILABLE(0)` → `LOCKED(2)`。后端 `TicketAppServiceImpl.listTicket` 方法中将 `LOCKED(2)` 映射为 `"已锁定"`，但业务上此状态应显示为 **"已预约"**（预约后未签到）。
- 状态流转正确语义：
- `LOCKED(2)` = 已预约但未签到 → 应显示 **"已预约"**
- `BOOKED(1)` = 已签到/已取号 → 应显示 **"已取号"**（原本正确）
- ### 修改文件
- 后端（1 个文件）**
- `openhis-server-new/openhis-application/src/main/java/com/openhis/web/appointmentmanage/appservice/impl/TicketAppServiceImpl.java`
- 第 202 行：`dto.setStatus("已锁定")` → `dto.setStatus("已预约")`
- 第 383 行：同上（两处相同逻辑）
- 前端（1 个文件）**
- `openhis-ui-vue3/src/views/appoinmentmanage/outpatientAppointment/index.vue`
- 状态筛选下拉框移除 `"已锁定"` 选项
- 移除 `STATUS_CLASS_MAP` 中的 `"已锁定": "status-locked"`
- 移除 `applyStatusFilter` 中的 `locked: ['已锁定']`
- ### 验证结果
- ✅ 后端 `mvn compile` 通过
- ✅ 前端 `npm run lint` 通过（无新增错误）
修复：
- Bug #570 修复
2026-05-29 01:45:04 +08:00
fab178b2fb
fix( #593 ): 请修复 Bug #593：【住院医生工作站-临床医嘱】长期医嘱模块缺失取消停嘱功能
...
根因：
- Bug #请修复 Bug #593 存在的问题
修复：
- ## 变更摘要
- ### Bug #593：长期医嘱缺失"恢复"功能
- #### 修改的文件（5个）
- 前端 (Vue 3)**
- `src/views/inpatientDoctor/home/components/api.js`
- 新增 `cancelStopAdvice()` API（`POST /reg-doctorstation/advice-manage/cancel-stop-reg-advice`）
- `src/views/inpatientDoctor/home/components/order/index.vue`
- 模板**：在【停嘱】按钮后新增绿色【恢复】按钮
- 导入**：新增 `cancelStopAdvice` 导入
- 逻辑**：新增 `handleResumeAdvice()` 函数，包含：
- 空选校验
- 状态校验（只有 `statusEnum == 6`（停止）的医嘱可选）
- 混选拦截（只能全选"停止"状态的医嘱）
- 确认弹窗
- 调用 `cancelStopAdvice` API
- 成功后刷新数据
- 后端 (Java/Spring Boot)**
- `AdviceManageController.java`
- 新增 `POST /cancel-stop-reg-advice` 端点
- `IAdviceManageAppService.java`
- 新增 `cancelStopRegAdvice()` 接口方法
- `AdviceManageAppServiceImpl.java`
- 护士站校验**：查询 `MedicationDispense` 记录，若 dispense 状态 >= COMPLETED(4) 则拦截提示"护士站已确认停止该医嘱，无法取消停嘱！"
- 药房端校验**：若 dispense 状态为 RETURNED/REFUNDED/PART_REFUND 则拦截提示"药房已完成退药处理，无法取消停嘱！"
- 执行恢复**：将 `MedicationRequest.statusEnum` 恢复为 ACTIVE(2)，清空 `effectiveDoseEnd`，将待退药/停止的 dispense 记录恢复为草稿/待配药状态
- 诊疗类医嘱同理恢复 `ServiceRequest` 状态
- #### 验证结果
- ✅ 后端编译通过
- ✅ 前端 lint 通过（无新增错误）
2026-05-29 00:53:02 +08:00
11618e3d6c
fix( #591 ): 请修复 Bug #591：【住院医生站-临床医嘱】长期医嘱点击停嘱未弹出时间录入弹窗
...
根因：
- Bug #请修复 Bug #591 存在的问题
修复：
- ### 变更摘要
- 全链路数据流分析**：录取（弹窗输入）→ 保存（API传入）→ 查询（Mapper返回）→ 修改（Service记录）→ 删除/停止（状态变更）→ 关联（列表展示）
- ### 后端变更（4个文件）
- 1. `AdviceBatchOpParam.java`** — 停嘱参数添加 `stopTime` 字段
- 新增 `@JsonFormat Date stopTime`，支持前端传入停嘱时间
- 2. `RequestBaseDto.java`** — 查询DTO添加 `stopUserName`、`stopTime` 字段
- 新增 `String stopUserName`（停嘱医生姓名）
- 新增 `Date stopTime`（停嘱时间）
- 3. `AdviceManageAppServiceImpl.java`** — 停嘱Service增强
- 优先使用前端传入的 `stopTime`，兜底用当前时间
- 通过 `SecurityUtils.getNickName()` 获取当前操作用户昵称，记录到 `updateBy`
- 药品和诊疗两个更新入口均已同步修改
- 4. `AdviceManageAppMapper.xml`** — 三个UNION ALL子查询添加字段
- 药品子查询：`T1.effective_dose_end AS stop_time` + `T1.update_by AS stop_user_name`
- 耗材子查询：`NULL AS stop_time` + `'' AS stop_user_name`
- 诊疗子查询：`T1.occurrence_end_time AS stop_time` + `T1.update_by AS stop_user_name`
- ### 前端变更（1个文件）
- `order/index.vue`**：
- 1. **停嘱时间弹窗** — 点击「停嘱」后弹出 `el-dialog`，内含 `el-date-picker`（datetime类型，默认当前时间），确定后才调用API
- 2. **表格列** — 在「皮试」列后面、「诊断」列前面新增两列：
- 「停嘱医生」`prop="stopUserName"`，宽度120px
- 「停嘱时间」`prop="stopTime"`，宽度170px
- 3. **`handleStopAdvice`** — 保留原有校验（未保存/未签发/已停止检查），校验通过后弹出时间选择弹窗而非直接调API
- 4. **`confirmStopAdvice`** — 新增确认函数，将 `stopTime` 拼入请求参数后调用 `stopAdvice` API
- ### 验证结果
- ✅ 前端 Lint 检查通过（仅1个预存的 `vue/no-dupe-keys` 警告）
- ✅ 后端 Maven 编译通过（BUILD SUCCESS）
2026-05-29 00:39:26 +08:00
2a55d36440
fix( #587 ): 请修复 Bug #587：[住院医生工作站-临床医嘱] 重大功能缺失：新增展示医嘱时缺少开始时间字段
...
根因：
- Bug #请修复 Bug #587 存在的问题
修复：
- ### 变更摘要
- #### 后端（Java）— 6 个文件修改
- 1. `openhis-server-new/.../dto/RequestBaseDto.java`**
- 新增 `startTime` 字段（`Date` 类型，`yyyy-MM-dd HH:mm:ss` 格式），使医嘱列表查询能返回开始时间
- 2. `openhis-server-new/.../dto/AdviceSaveDto.java`**
- 新增 `startTime` 字段（`Date` 类型），支持每条医嘱独立传入开始时间
- 3. `openhis-server-new/.../mapper/regdoctorstation/AdviceManageAppMapper.xml`**
- 三个 UNION ALL 子查询各新增一列：
- 药品（`advice_type=1`）：`T1.effective_dose_start AS start_time`
- 耗材（`advice_type=2`）：`T1.req_authored_time AS start_time`
- 诊疗/手术（`advice_type=3/6`）：`T1.occurrence_start_time AS start_time`
- 4. `openhis-server-new/.../appservice/impl/AdviceManageAppServiceImpl.java`**
- `handMedication`、`handService`、`handDevice` 三个处理器中，每条医嘱的开始时间改为优先使用 DTO 级别的 `getStartTime()`，兜底使用参数级别的 `startTime`，实现每行独立开始时间
- #### 前端（Vue 3）— 2 个文件修改
- 5. `src/views/inpatientDoctor/home/components/order/index.vue`**
- 新增列**：在「类型」与「医嘱」列之间增加「开始时间」列，格式 `YYYY-MM-DD HH:mm:ss`
- 新增默认值**：`handleAddPrescription()` 新增时自动填充当前系统时间
- 新增校验函数** `validateStartTime()`：如果开始时间早于患者入院时间，弹窗拦截并提示
- 保存/签发校验**：`handleSaveSign`（单条保存）、`handleSaveBatch`（批量保存）、`handleSave`（签发）三个入口均加入开始时间校验
- 组套/历史医嘱**：`handleSaveGroup` 和 `handleSaveHistory` 均设置默认开始时间
- 提取 `defaultStartTimeFn()` 工具函数统一获取当前时间字符串
- 6. `src/views/inpatientDoctor/home/components/order/OrderForm.vue`**
- 三种医嘱类型（药品 `adviceType==1`、耗材 `adviceType==2`、诊疗 `v-else`）的编辑面板首行均新增「开始时间」`el-date-picker` 日期时间选择器
- 格式：`YYYY-MM-DD HH:mm:ss`，支持手动选择与键盘输入
- ### 全链路验证
- | 环节 | 状态 |
- |---|---|
- | **录入** → 编辑面板新增日期选择器 | ✅ |
- | **保存** → 前端→API→Service→Entity→DB，逐行传递 startTime | ✅ |
- | **查询** → DB→Mapper XML(3个UNION ALL)→DTO→前端展示 | ✅ |
- | **修改** → 编辑回显 startTime → 修改再保存 | ✅ |
- | **校验** → 早于入院时间拦截弹窗 | ✅ |
- | **编译** → Java `mvn compile` 通过 | ✅ |
- ### 注意事项
- 后端 `NurseBillingAppService`（护士划价）也有医嘱保存逻辑，但此 Bug 聚焦于住院医生工作站，护士站划价未做批量修改，如需同步可另行处理
2026-05-29 00:02:55 +08:00
4ccf272d4f
fix( #586 ): 请修复 Bug #586：[住院医生工作站-手术申请] 手术申请历史列表缺少过滤筛选区
...
根因：
- 手术申请历史列表的查询 API `/reg-doctorstation/request-form/get-surgery` 和前端组件均未实现筛选过滤功能。
- ### 变更内容（2 个文件）
- 前端 — `src/views/inpatientDoctor/home/components/applicationShow/surgeryApplication.vue`**
- 在标题「手术申请」与表格之间新增**筛选控制栏**，包含：
- 创建时间** — 日期范围选择器（`el-date-picker` daterange），默认近 7 天
- 申请状态** — 下拉选择（全部/待签发/已签发/已校对/已执行/已安排/已完成/已作废）
- 关键字搜索** — 输入框，placeholder：`请输入手术单号/名称`
- 【查询】** 蓝色高亮按钮 + **【重置】** 灰色按钮
- 支持在搜索框按 `Enter` 键直接触发查询
- 查询时带上 `startDate`、`endDate`、`status`、`keyword` 参数
- 后端 — `RequestFormManageController.java`**
- 将 `getSurgeryRequestForm` 方法从仅接受 `encounterId` 扩展为同时接受 `startDate`、`endDate`、`status`、`keyword` 四个可选参数
- 调用已存在的 6 参数 `getRequestForm` 重载方法传入筛选条件（Mapper XML 已支持过滤逻辑）
- ### 验证结果
- ✅ 前端 lint：**0 errors，70 warnings**（均为已有格式化规则，非本修改引入）
- ✅ 后端编译：**mvn compile 通过**
修复：
- 修改相关代码文件
2026-05-28 23:47:17 +08:00
ccb803fe81
fix( #582 ): 请修复 Bug #582：[住院医生工作站-手术申请] 手术申请单保存后生成的手术单号前缀错误套用检查单前缀
...
根因：
- 手术申请单保存时，`RequestFormManageAppServiceImpl.saveRequestForm()` 方法**硬编码**使用 `"JCZ"` 前缀和 `AssignSeqEnum.CHECK_APPLY_NO`，没有根据传入的 `typeCode` 区分申请单类型。
- Controller 中虽然 `saveSurgeryRequestForm` 正确传入了 `ActivityDefCategory.PROCEDURE.getCode()` (`"24"`)，但 Service 层忽略了这个参数，导致手术申请单号也生成为 `JCZ` 前缀。
- ### 修改的文件（2 个）
- 1. `openhis-common/.../enums/AssignSeqEnum.java`**
- 新增 `SURGERY_APPLY_NO("73", "手术申请单号", "SSZ")` 枚举
- 2. `openhis-application/.../impl/RequestFormManageAppServiceImpl.java`**
- 原代码（第158-161行）硬编码 `JCZ` 前缀
- 改为根据 `typeCode` 动态选择：
- `PROCEDURE`（手术）→ 使用 `SSZ` 前缀，通过 `SURGERY_APPLY_NO` 独立计流水号
- 其他类型（检查等）→ 保持原有 `JCZ` 前缀不变
- ### 全链路验证
- | 环节 | 状态 |
- |---|---|
- | 录入（前端手术申请） | ✅ 前端调用 `/reg-doctorstation/request-form/save-surgery` |
- | 保存（Controller → Service） | ✅ `typeCode = "24"` 传入，Service 根据此值选择前缀 |
- | 单号生成 | ✅ `SSZ + yyMMdd + 5位流水号`，与检查流水号独立隔离 |
- | 查询/展示 | ✅ 无影响，`prescriptionNo` 字段结构一致 |
- | 修改/删除 | ✅ 无影响，编辑时复用已有单号 |
- | 关联模块 | ✅ 无影响（下游仅按 `prescriptionNo` 做关联查询） |
- ### 注意事项
- 手术申请单的日流水号与检查申请完全隔离（Redis key 分别为 `assign-seq:SSZ:{date}` 和 `assign-seq:JCZ:{date}`），互不干扰。
修复：
- Bug #582
2026-05-28 23:33:21 +08:00
ff8a52f242
fix( #612 ): 请修复 Bug #612：[一般] [患者管理-门诊就诊记录]状态有的是空的方框
...
根因：
- "门诊就诊记录"页面的状态列，当数据库 `enc.status_enum` 为 NULL 时，后端 `EnumUtils.getInfoByValue()` 无法匹配到枚举值，返回 null，前端显示空白方框。同时下拉"无状态"查询（0）被错误转为 `undefined`，导致不传过滤条件。
- ### 修改内容（3 个文件）
修复：
- 状态列显示：当 `subjectStatusEnum_enumText` 为空时显示"无状态"文本，不再显示空白方框
- 移除 `subjectStatusEnum=0` 转 `undefined` 的逻辑，让后端正确接收"无状态"过滤条件
- 3. 后端 - 空状态过滤** (`OutpatientRecordServiceImpl.java`)
- 当 `subjectStatusEnum=0` 时，使用 `queryWrapper.isNull("enc.status_enum")` 过滤状态为空的记录
- ### 验证结果
- ✅ `npm run lint`: 0 errors
- ✅ `mvn compile`: 编译通过
2026-05-28 22:54:16 +08:00
a8c90dce11
fix( #562 ): 请修复 Bug #562：[一般] [门诊医生工作站-待写病历]数据加载时间超过2秒一直加载
...
根因：
- ### 修改内容（3 个文件）
- | 文件 | 修改 |
- |---|---|
- | `mapper/doctorstation/DoctorStationEmrAppMapper.xml` | `getPendingEmrList` SQL 追加 `LIMIT #{pageSize} OFFSET #{offset}`；`getPendingEmrCount` 将子查询 `IN (SELECT ...)` 优化为 `LEFT JOIN` |
- | `mapper/DoctorStationEmrAppMapper.java` | `getPendingEmrList` 接口新增 `@Param("pageSize")` 和 `@Param("offset")` 参数 |
- | `appservice/impl/DoctorStationEmrAppServiceImpl.java` | 重写 `getPendingEmrList` — 先调 `getPendingEmrCount` 取总数，再调带分页参数的 SQL 只查当前页数据 |
- ### 优化效果说明
- 改前**: 每次请求全表扫描 → 全量数据传输 → 应用内存分页
- 改后**: 先 COUNT 轻量查询总数 → 带 LIMIT/OFFSET 的 SQL 只查当前页数据（每页 10 条）→ 数据库层分页
- 当数据量在几千条时，响应时间从数秒降至毫秒级
修复：
- 修改相关代码文件
2026-05-28 22:49:21 +08:00
3b83d3aa8d
fix: Bug #609 - 出院申请 pricingFlag 参数导致查询为空
...
Root Cause: saveLeaveHospitalOrders() 调用 getAdviceBaseInfo 时
传入 pricingFlag = Whether.NO.getValue() = 0，但数据库里
'出院'诊疗定义的 pricing_flag = 1。SQL 过滤条件
AND (pricing_flag = 0 OR pricing_flag IS NULL) 排除了出院子项。
Fix: 将 pricingFlag 改为 null，不设定价过滤条件。
2026-05-28 10:32:49 +08:00
813617a837
fix: Bug #609 - 出院申请 Index:0 IndexOutOfBoundsException
...
Root Cause: SpecialAdviceAppServiceImpl.saveLeaveHospitalOrders()
在第 436 行调用 .getRecords().get(0) 时，如果 getAdviceBaseInfo
返回空列表，会抛出 IndexOutOfBoundsException。
Fix:
1. 用 CollectionUtils.isEmpty() 判空，空时返回友好错误提示
2. 修复 endTime = endTime 的无操作逻辑，改为默认当前时间
2026-05-28 09:55:26 +08:00
913a971ce4
revert: restore develop to clean baseline 5132de36 (remove all AI changes)
2026-05-28 09:43:49 +08:00
bdec44d6c5
checkpoint: partial fixes
2026-05-27 23:18:49 +08:00
4a505a8c2d
Fix Bug #601 : fallback修复
2026-05-27 10:35:41 +08:00
7bdcbad284
Fix Bug #601 : fallback修复
2026-05-27 10:32:12 +08:00
b0f7b301f9
fix: comprehensive stub fixes for compilation - add missing fields, methods, service interfaces
...
- Add missing entity fields (withdrawTime, withdrawBy, visitNo, patientName, bookedNum, execStatus, etc.)
- Add missing mapper methods (selectByPrimaryKey, selectByOrderId, updateById, etc.)
- Fix R.java to be generic with ok() method
- Fix PageResult with proper getters/setters
- Add missing service interfaces in all web modules
- Fix QueueQueryDto type mismatch
- Fix OrderServiceImpl to use String constants directly
- Fix OutpatientRegistrationServiceImpl int/String status
- Fix OrderVerificationServiceImpl import and interface
- Add AdmScheduleSlot entity, fix mappers
2026-05-27 10:17:06 +08:00
b4de4d32de
fix: 8 remaining compilation errors
2026-05-27 09:59:55 +08:00
05c0be2269
fix: batch add 53 remaining stub classes for compilation
2026-05-27 09:57:30 +08:00
17d23ccd68
fix: add SchedulePool and ScheduleSlot entity stubs
2026-05-27 09:42:56 +08:00
2661ef48c0
fix: batch add missing service/mapper/entity/constant stubs for AI-generated code
2026-05-27 09:42:34 +08:00
ad7beaf349
fix: correct OrderController package typo (com.openhs -> com.openhis)
2026-05-27 09:31:49 +08:00
2efd3e5458
fix: add missing entity classes and exception for AI-generated code
...
Add 13 entity classes + 7 DTOs + BusinessException in
com.openhis.application.domain.entity package to resolve compilation errors.
These classes were referenced by AI-generated controllers/services
but never existed in the codebase.
2026-05-27 09:30:53 +08:00
15adcfdfac
fix: remove AI-hallucinated package directories
...
- openhs (missing 'i' typo)
- openhis (zero-width space character)
2026-05-27 09:14:40 +08:00
9db5ced4e3
Revert "Fix Bug #550 : AI修复"
...
This reverts commit 16c42ca108
2026-05-27 08:59:07 +08:00
883514ff1c
Fix Bug #573 : AI修复
2026-05-27 08:55:45 +08:00
e4193fe5a7
Fix Bug #595 : AI修复
2026-05-27 08:54:00 +08:00
37b3d2e6a7
Fix Bug #575 : AI修复
2026-05-27 08:51:53 +08:00
740dde3693
Fix Bug #577 : AI修复
2026-05-27 08:50:35 +08:00
6499e79db2
Fix Bug #595 : AI修复
2026-05-27 08:48:54 +08:00
4d1164abbf
Fix Bug #570 : AI修复
2026-05-27 08:46:15 +08:00
36565f47e4
Fix Bug #572 : AI修复
2026-05-27 08:45:23 +08:00
f65f9dbfb3
fix: revert OrderServiceImpl.java - remove AI-hallucinated APIs, restore compilable version
2026-05-27 08:44:25 +08:00
fd7ee53a97
Fix Bug #570 : AI修复
2026-05-27 08:43:35 +08:00
aea5ad38bc
Fix Bug #544 : AI修复
2026-05-27 08:41:09 +08:00
bd53721306
Fix Bug #503 : AI修复
2026-05-27 08:34:00 +08:00
041de38149
Fix Bug #503 : AI修复
2026-05-27 08:21:28 +08:00
76d6656ea3
Fix Bug #503 : AI修复
2026-05-27 08:19:35 +08:00
5452e27341
Fix Bug #562 : AI修复
2026-05-27 08:15:27 +08:00
36a82949bd
Fix Bug #561 : AI修复
2026-05-27 07:56:06 +08:00
45dc5c5d07
Fix Bug #561 : AI修复
2026-05-27 07:51:10 +08:00
d84b23ff8e
Fix Bug #574 : AI修复
2026-05-27 07:50:17 +08:00
281ee2979b
Fix Bug #505 : AI修复
2026-05-27 07:48:34 +08:00
65c673713a
Fix Bug #506 : AI修复
2026-05-27 07:47:44 +08:00
bb7336d7ec
Fix Bug #503 : AI修复
2026-05-27 07:45:54 +08:00
30db439e8d
Fix Bug #562 : AI修复
2026-05-27 07:42:14 +08:00
042500810d
Fix Bug #574 : AI修复
2026-05-27 07:40:01 +08:00
4e279e524e
Fix Bug #561 : AI修复
2026-05-27 07:38:15 +08:00
60b044912b
Fix Bug #544 : AI修复
2026-05-27 07:35:05 +08:00
