> ## Documentation Index
> Fetch the complete documentation index at: https://tomotek.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# US-MER-37: Xử lý Xung đột Booking (Booking Conflict Management)

> Module cốt lõi xử lý các thay đổi rủi ro (Breaking Changes) của Merchant nhằm bảo vệ tính toàn vẹn của các Lịch hẹn đã được khách đặt.

## 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)**:

> [accordion] Bước 1: Quét và Phát hiện (Conflict Detection)
>
> * 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)**.

> [accordion] Bước 2: Giao diện Xử lý Cục bộ (Manual Resolution UI)
>
> * 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 đó.

> [accordion] Bước 3: Lưu đè (Force Update)
>
> * 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!


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.