Skip to main content

​
1. Bối cảnh (Context)

Đây là một Module ngầm (Core Module) được gọi ra bất cứ khi nào Merchant thực hiện một thay đổi có rủi ro làm vỡ cấu trúc lịch trình đã có khách đặt trước. Các nghiệp vụ gọi đến Module này bao gồm (nhưng không giới hạn):
  • Sửa đổi thời lượng, sức chứa của Dịch vụ (US-MER-04).
  • Điều chỉnh giảm ca làm việc của Nhân sự (US-MER-05).
  • Bật chế độ Tạm nghỉ / Nghỉ lễ (Vacation Mode).

​
2. Tiêu chí chấp nhận (Acceptance Criteria)

Luồng kiểm tra và xử lý xung đột tuân thủ kiến trúc Xác nhận 2 Bước (Two-step Update):
  • Khi Merchant bấm nút [Lưu / Cập nhật] ở một nghiệp vụ gốc, hệ thống tạm thời chưa lưu dữ liệu.
  • Hệ thống quét toàn bộ Booking ở trạng thái Pending và Confirmed trong tương lai có liên quan đến thực thể bị thay đổi.
  • Kết quả an toàn: Nếu không có Booking nào bị ảnh hưởng, hệ thống trả về mã Success và lưu thay đổi ngay lập tức.
  • Kết quả Xung đột: Nếu phát hiện Booking bị đụng độ, hệ thống trả về mã HTTP 409 (Conflict) kèm theo danh sách chi tiết các Booking đó. Giao diện của nghiệp vụ gốc sẽ bị Khóa (Block Save).
  • Sau khi nhận mã 409, giao diện bật lên một Popup / Dialog mang tên “Cảnh báo Xung đột Lịch hẹn”.
  • Hiển thị danh sách các Booking bị ảnh hưởng (Mã đơn, Tên khách, Giờ hẹn, Dịch vụ).
  • Merchant bắt buộc phải xử lý thủ công từng Booking trong danh sách này để giải phóng slot. Hai hành động khả thi:
    1. Dời lịch (Reschedule): Merchant liên hệ khách và đổi giờ hẹn sang một khung giờ khác an toàn.
    2. Hủy lịch (Cancel): Nếu không thoả thuận được, Merchant tiến hành hủy Booking đó.
  • Sau khi Merchant đã hoàn tất việc “dọn dẹp” danh sách xung đột, họ đóng Popup và quay lại bấm nút [Lưu / Cập nhật] ở form nghiệp vụ gốc một lần nữa.
  • Lúc này, Client truyền thêm một cờ lệnh: ignore_conflict_check = true (Bỏ qua check xung đột).
  • Hệ thống tin tưởng rằng rủi ro đã được xử lý tay, do đó bỏ qua bước quét (Bước 1) và tiến hành ghi đè thông tin mới vào Database. Thành công!