chore: remove legacy specification documents and internal rules file

docs/knowledge-refs/catalogue/fulfillment_lifecycle.md

@@ -0,0 +1,49 @@
+---
+ref_id: "catalogue/fulfillment_lifecycle"
+parent_card: "catalogue/voucher_code"
+title: "Chi tiết Vòng đời Fulfillment của Voucher (Fulfillment Lifecycle)"
+domain: "catalogue"
+ref_type: "process_detail"
+tags: ["voucher", "fulfillment", "status", "lifecycle"]
+---
+
+# Chi tiết Vòng đời Fulfillment của Voucher (Fulfillment Lifecycle)
+
+## Thuộc về
+
+catalogue/voucher_code — Card tóm tắt 5 trạng thái vòng đời nhưng chưa giải thích rõ event nào trigger việc chuyển đổi trạng thái và hệ thống xử lý thế nào. Reference này bổ sung chi tiết luồng chuyển trạng thái Fulfillment Status của từng Voucher No.
+
+## Chi tiết
+
+### Các trạng thái Fulfillment Status
+
+Mỗi Voucher Detail (Voucher No) đều có một trạng thái theo dõi suốt vòng đời, được hệ thống cập nhật dựa trên các sự kiện (events):
+
+| Trạng thái (Status) | Giải thích | Trigger Event (Sự kiện kích hoạt) |
+|---|---|---|
+| **New** | Mã chưa được sử dụng, đang nằm trong kho. | Khi Voucher được khởi tạo tự động hoặc upload từ file vào OLS. |
+| **Issued** | Mã đã được cấp phát cho khách hàng. | Khi khách hàng thao tác đổi điểm lấy mã này thành công trên hệ thống OLS. |
+| **Fulfilled** | Khách hàng đã dùng mã thành công tại đối tác. | Khi đối tác gửi xác nhận (qua API hoặc file batch) rằng mã đã được chấp nhận và thanh toán. |
+| **Cancelled** | Mã bị hủy sau khi đã Issued. | Khi khách hàng chủ động hủy giao dịch đổi điểm, hoặc hệ thống phát sinh lỗi cần rollback giao dịch. |
+| **Rejected** | Đối tác từ chối sử dụng mã này. | Khi đối tác trả về lỗi (Mã vi phạm T&C, đã đổi ở nơi khác, v.v.). |
+
+### Luồng chuyển trạng thái (State Transition Flow)
+
+1. **Upload/Generate**: `(Chưa có) -> New`
+2. **Redeem (Đổi điểm)**: `New -> Issued`
+3. **Usage (Sử dụng)**: 
+   - Hợp lệ: `Issued -> Fulfilled`
+   - Bị từ chối: `Issued -> Rejected`
+4. **Cancel (Hủy đổi)**: `Issued -> Cancelled`
+
+### Xử lý Ngoại lệ (Error Handling)
+
+| Ngoại lệ | Hành động của hệ thống |
+|---|---|
+| Hủy mã (Cancelled) | Tuỳ thuộc cấu hình hệ thống, mã bị Cancelled có thể được tái tạo lại (trở về New) để cấp cho người khác, hoặc bị khóa vĩnh viễn và hoàn điểm lại cho khách hàng. |
+| Từ chối (Rejected) | Ghi log giao dịch lỗi, nhân viên vận hành sẽ phải đối soát lại với Vendor. |
+
+## Ví dụ cụ thể
+
+- **Luồng thành công**: Khách hàng đổi điểm lấy mã Grab. OLS lấy 1 mã từ kho đang ở trạng thái `New` và gán cho khách, đổi thành `Issued`. Khách nhập mã vào app Grab đi xe thành công. Grab gọi API thông báo về OLS, OLS đổi trạng thái mã thành `Fulfilled`.
+- **Luồng thất bại do Hủy**: Khách đổi mã CGV (`Issued`) nhưng ứng dụng gặp lỗi mạng (timeout) không hiển thị được vé. Hệ thống tự động rollback giao dịch hoàn điểm, voucher chuyển thành `Cancelled`.

docs/knowledge-refs/catalogue/redemption_pricing_detail.md

@@ -0,0 +1,44 @@
+---
+ref_id: "catalogue/redemption_pricing_detail"
+parent_card: "catalogue/item_price"
+title: "Chi tiết Tính toán Partial Redemption (Partial Redemption Calculation)"
+domain: "catalogue"
+ref_type: "edge_cases"
+tags: ["partial redemption", "cash per point", "pricing"]
+---
+
+# Chi tiết Tính toán Partial Redemption (Partial Redemption Calculation)
+
+## Thuộc về
+
+catalogue/item_price — Card có đề cập cơ bản về đổi một phần (Partial Redemption) nhưng thiếu công thức toán học chính xác và các ngoại lệ. Reference này bổ sung chi tiết công thức tính số tiền mặt cần bù và các validation rule khi cấu hình.
+
+## Chi tiết
+
+### Công thức tính tiền bù (Cash Calculation)
+
+Khi chức năng `Partial Redemption Allowed = ON`, hệ thống cho phép khách hàng đổi quà bằng cách kết hợp Điểm và Tiền mặt. Số tiền mặt phải bù được tính theo công thức:
+
+`Số tiền mặt = (Price_in_point - Số_điểm_khách_hàng_dùng) * Cash_per_point + Applicable_Taxes`
+
+| Tham số | Ý nghĩa | Ràng buộc |
+|---|---|---|
+| **Price_in_point** | Giá trị món quà quy ra điểm (Full redemption price) | Phải > 0 |
+| **Số_điểm_khách_hàng_dùng** | Số điểm mà khách hàng chọn để đổi (thường khách sẽ dùng tối đa điểm mình đang có) | Phải `>= Minimum Partial Redeem Points` VÀ `<= Price_in_point` |
+| **Cash_per_point** | Số tiền phạt/bù cho mỗi 1 điểm còn thiếu | Phải > 0 |
+| **Applicable Taxes** | Tiền thuế tương ứng với phần tiền mặt giao dịch | Dựa theo cấu hình Tax Rate Maintenance |
+
+### Các Rules đặc biệt
+
+| Rule / Ngoại lệ | Giải thích |
+|---|---|
+| **Đổi 100% bằng tiền mặt** | Chỉ được phép nếu `Minimum Partial Redeem Points = 0`. Khi đó khách hàng có thể dùng `Số_điểm_dùng = 0`. |
+| **Full Redemption ưu tiên** | Nếu khách hàng có đủ điểm (Số dư >= `Price_in_point`), khách hàng vẫn có quyền chọn Partial Redemption để giữ lại điểm (miễn là phần điểm dùng lớn hơn mức Minimum). |
+
+## Ví dụ cụ thể
+
+- **Tình huống**: Quà tặng "Tai nghe Bluetooth" có giá Full (`Price_in_point`) là 10,000 điểm. Cấu hình Partial cho phép tối thiểu `Minimum = 2,000` điểm, `Cash_per_point = 50 VND/điểm`.
+- **Trường hợp hợp lệ**: Khách hàng A có 3,000 điểm. Khách hàng dùng toàn bộ 3,000 điểm (thoả mãn `>= 2,000`).
+  Số điểm thiếu: 10,000 - 3,000 = 7,000 điểm.
+  Số tiền mặt cần thanh toán: 7,000 * 50 = 350,000 VND (Cộng thêm thuế nếu có).
+- **Trường hợp bị Reject**: Khách hàng B chỉ có 1,500 điểm. Hệ thống chặn giao dịch vì 1,500 < 2,000 (Minimum limit). Khách hàng B không thể đổi quà dù có sẵn tiền mặt.