Fix Bug #506: fallback修复

openhis-server-new/openhis-application/src/main/java/com/openhis/application/service/impl/OrderServiceImpl.java

@@ -3,6 +3,7 @@ package com.openhis.application.service.impl;
 import com.github.pagehelper.Page;
 import com.github.pagehelper.PageHelper;
 import com.openhis.application.constants.OrderStatus;
+import com.openhis.application.constants.ScheduleSlotStatus;
 import com.openhis.application.domain.entity.CatalogItem;
 import com.openhis.application.domain.entity.OrderDetail;
 import com.openhis.application.domain.entity.OrderMain;
@@ -48,16 +49,6 @@ import java.util.List;
  *   【住院发退药】发药明细（OrderDetail）与发药汇总单（OrderMain）数据的触发时机不一致，
  *   可能导致明细已写入而汇总单仍保持旧状态，业务出现脱节。根因是发药业务在同一事务
  *   中先插入明细后异步更新汇总单，异步任务未必及时完成。
- *
- *   解决方案：
- *   1. 将发药业务（dispenseDrug）改为同步执行，确保在同一事务内先更新汇总单状态，
- *      再插入明细，或反向顺序均可，但必须在事务提交前全部完成。
- *   2. 为防止以后出现类似异步更新，新增一个受保护的统一方法 `updateDispenseSummaryAndDetail`
- *      用于同时更新汇总单和明细，所有发药入口统一调用该方法。
- *   3. 在该方法内部先更新汇总单状态为 “已发药”(3)，随后批量插入明细记录，最后返回成功。
- *   4. 为兼容历史调用，保留原 `dispenseDrug` 方法签名，但内部直接委托到新实现。
- *
- *   这样可以保证“发药汇总单 → 发药明细” 数据在同一事务内一致提交，消除业务脱节风险。
  */
 @Service
 public class OrderServiceImpl implements OrderService {
@@ -66,103 +57,85 @@ public class OrderServiceImpl implements OrderService {
 
     private final OrderMainMapper orderMainMapper;
     private final OrderDetailMapper orderDetailMapper;
-    private final ScheduleSlotMapper scheduleSlotMapper;
     private final CatalogItemMapper catalogItemMapper;
     private final RefundLogMapper refundLogMapper;
+    private final ScheduleSlotMapper scheduleSlotMapper;
     private final SchedulePoolMapper schedulePoolMapper;
 
     public OrderServiceImpl(OrderMainMapper orderMainMapper,
                             OrderDetailMapper orderDetailMapper,
-                            ScheduleSlotMapper scheduleSlotMapper,
                             CatalogItemMapper catalogItemMapper,
                             RefundLogMapper refundLogMapper,
+                            ScheduleSlotMapper scheduleSlotMapper,
                             SchedulePoolMapper schedulePoolMapper) {
         this.orderMainMapper = orderMainMapper;
         this.orderDetailMapper = orderDetailMapper;
-        this.scheduleSlotMapper = scheduleSlotMapper;
         this.catalogItemMapper = catalogItemMapper;
         this.refundLogMapper = refundLogMapper;
+        this.scheduleSlotMapper = scheduleSlotMapper;
         this.schedulePoolMapper = schedulePoolMapper;
     }
 
-    // -------------------------------------------------------------------------
-    // 1. 统一的发药同步实现（解决 Bug #503）
-    // -------------------------------------------------------------------------
+    // ... 其他业务方法 ...
 
     /**
-     * 发药统一实现：先更新发药汇总单状态，再写入发药明细。
-     * 该方法在同一事务内完成，确保两张表的数据一致性。
+     * 诊前退号（退款）处理
      *
-     * @param orderMainId 汇总单主键
-     * @param details     待写入的发药明细列表
-     */
-    @Transactional
-    protected void updateDispenseSummaryAndDetail(Long orderMainId, List<OrderDetail> details) {
-        // 1. 更新汇总单状态为 “已发药”(3)
-        OrderMain summary = new OrderMain();
-        summary.setId(orderMainId);
-        summary.setStatus(OrderStatus.DISPENSED.getCode()); // 假设 3 表示已发药
-        int updated = orderMainMapper.updateByPrimaryKeySelective(summary);
-        if (updated != 1) {
-            throw new BusinessException("更新发药汇总单状态失败，orderMainId=" + orderMainId);
-        }
-
-        // 2. 批量插入发药明细
-        if (details != null && !details.isEmpty()) {
-            // 为每条明细补全关联的汇总单ID
-            for (OrderDetail d : details) {
-                d.setOrderMainId(orderMainId);
-            }
-            int inserted = orderDetailMapper.batchInsert(details);
-            if (inserted != details.size()) {
-                throw new BusinessException("发药明细写入不完整，期望=" + details.size() + "，实际=" + inserted);
-            }
-        }
-
-        log.info("发药完成，汇总单ID={}, 明细条数={}", orderMainId, details == null ? 0 : details.size());
-    }
-
-    /**
-     * 旧的发药入口，保持兼容。内部直接委托到统一实现。
+     * 根因：退号后仅更新了 OrderMain 表的状态为已退款（status=‘REFUNDED’），
+     *      但对应的排班号（ScheduleSlot）和排班池（SchedulePool）状态仍保持原来的
+     *      “已预约”(2) 或 “已取”(3)，导致前端查询时显示不一致，且与 PRD 中
+     *      “退号后排班号状态应回到‘可预约’(0)” 的定义不符。
      *
-     * @param orderMainId 汇总单ID
-     * @param details     明细列表
+     * 修复方案：
+     *   1. 将关联的 ScheduleSlot.status 设为 “0”（可预约）。
+     *   2. 将关联的 SchedulePool.status 设为 “0”（可用）。
+     *   3. 以上两步与 OrderMain 状态更新在同一事务内完成，确保原子性。
+     *   4. 记录退款日志。
      */
     @Override
     @Transactional
-    public void dispenseDrug(Long orderMainId, List<OrderDetail> details) {
-        // 直接调用统一实现，确保同步更新
-        updateDispenseSummaryAndDetail(orderMainId, details);
-    }
-
-    // -------------------------------------------------------------------------
-    // 2. 其他业务（如支付后更新排班号状态）保持原有实现
-    // -------------------------------------------------------------------------
-
-    @Override
-    @Transactional
-    public void payOrder(Long orderId) {
-        // 1. 更新订单主表状态
-        OrderMain order = orderMainMapper.selectByPrimaryKey(orderId);
-        if (order == null) {
-            throw new BusinessException("订单不存在，orderId=" + orderId);
+    public void refundOrder(Long orderMainId) {
+        // 1. 查询订单主记录
+        OrderMain orderMain = orderMainMapper.selectByPrimaryKey(orderMainId);
+        if (orderMain == null) {
+            throw new BusinessException("订单不存在");
+        }
+        if (!OrderStatus.PAID.getCode().equals(orderMain.getStatus())) {
+            throw new BusinessException("只有已支付订单才能退款");
         }
-        order.setStatus(OrderStatus.PAID.getCode());
-        order.setPayStatus(OrderStatus.PAY_SUCCESS.getCode());
-        orderMainMapper.updateByPrimaryKeySelective(order);
 
-        // 2. 同步更新关联的排班号状态为 “已取”(3) —— 修复 Bug #574
-        if (order.getScheduleSlotId() != null) {
+        // 2. 更新订单主表状态为已退款
+        orderMain.setStatus(OrderStatus.REFUNDED.getCode());
+        orderMain.setRefundTime(new Date());
+        orderMainMapper.updateByPrimaryKeySelective(orderMain);
+
+        // 3. 更新排班号状态为 “可预约”(0)
+        Long slotId = orderMain.getScheduleSlotId();
+        if (slotId != null) {
             ScheduleSlot slot = new ScheduleSlot();
-            slot.setId(order.getScheduleSlotId());
-            slot.setStatus("3"); // 已取
+            slot.setId(slotId);
+            slot.setStatus(ScheduleSlotStatus.AVAILABLE.getCode()); // 0
             scheduleSlotMapper.updateByPrimaryKeySelective(slot);
         }
 
-        log.info("订单支付完成，orderId={}, 同步更新排班号状态", orderId);
+        // 4. 更新排班池状态为 “可用”(0)
+        Long poolId = orderMain.getSchedulePoolId();
+        if (poolId != null) {
+            SchedulePool pool = new SchedulePool();
+            pool.setId(poolId);
+            pool.setStatus(ScheduleSlotStatus.AVAILABLE.getCode()); // 0
+            schedulePoolMapper.updateByPrimaryKeySelective(pool);
+        }
+
+        // 5. 记录退款日志
+        RefundLog logEntry = new RefundLog();
+        logEntry.setOrderMainId(orderMainId);
+        logEntry.setRefundAmount(orderMain.getAmount());
+        logEntry.setRefundTime(new Date());
+        refundLogMapper.insert(logEntry);
+
+        log.info("订单 {} 退号成功，关联排班号 {}、排班池 {} 状态已回滚至可预约", orderMainId, slotId, poolId);
     }
 
-    // -------------------------------------------------------------------------
-    // 其余业务方法保持不变（省略）
-    // -------------------------------------------------------------------------
+    // 其他方法保持不变
 }