Skip to main content

Đặc Tả Nghiệp Vụ: Cơ Chế Tích & Tiêu Điểm (GPoint)

Ngày cập nhật: 20/06/2026
Nguồn dữ liệu: Review chính sách App - Cơ chế Point.csv

Tài liệu này đặc tả chi tiết cơ chế tích lũy, tiêu dùng, khấu trừ điểm thưởng (GPoint), đồng thời hướng dẫn tích hợp giữa hệ thống Client App và hệ thống quản lý tại quầy (POS) cho bộ phận kỹ thuật (Team Tech & POS).

1. Ba Nguồn Hình Thành Điểm & Chính Sách Hết Hạn​

GPoint trong ví của khách hàng được tích lũy từ 3 nguồn độc lập. Mỗi nguồn có chính sách vòng đời (expiration policy) riêng biệt:

1.1. Point Mua / Nạp trực tiếp tại quầy (Khách bỏ tiền mặt mua)​

  • Quy tắc an toàn (Rolling Expiry): Hạn sử dụng của số điểm nạp này là đúng 365 ngày kể từ ngày giao dịch nạp thành công.
  • Lưu ý kỹ thuật: Tránh thiết lập cứng theo ngày tham gia Membership (ví dụ: đăng ký ngày 1/1, nạp tiền ngày 25/12 mà bắt hết hạn vào ngày 1/1 năm sau sẽ gây khiếu nại gay gắt). Hệ thống phải tracking hạn dùng theo từng block điểm nạp.

1.2. Point tặng từ Chiến dịch Marketing / Minigame​

  • Quy tắc hiệu ứng FOMO: Thời hạn sử dụng sẽ hết hạn theo cấu hình riêng của từng chương trình Marketing (ví dụ: 7 ngày, 14 ngày hoặc 30 ngày).
  • Lưu ý kỹ thuật: Xây dựng phân hệ cấu hình Campaign trên CMS Backend, cho phép bộ phận Marketing tự đặt thời hạn hết hạn cho mỗi sự kiện tặng điểm.

1.3. Point hoàn tiền từ Hóa đơn (Cashback Point)​

  • Quy tắc tích lũy: Khách hàng thanh toán dịch vụ (Massage, Gội đầu, Ăn uống...) sẽ được hoàn lại một tỷ lệ điểm tương ứng với hạng thành viên (Silver / Gold / Diamond).
  • Thời hạn hết hạn: Mặc định là 365 ngày tính từ ngày thanh toán hóa đơn.

2. Nguyên Tắc Khấu Trừ Điểm: Thuật Toán FEFO​

Để tối ưu quyền lợi khách hàng, hệ thống bắt buộc áp dụng thuật toán FEFO (First Expire, First Out - Hết hạn trước, Trừ trước) khi khách hàng tiêu điểm.

Ví dụ thực tế:​

Khách hàng có 1.000 Point trong ví, bao gồm:

  • 200 Point (Điểm tặng từ Minigame) - Còn 5 ngày là hết hạn.
  • 800 Point (Điểm mua tại quầy) - Còn 300 ngày là hết hạn.

Khi khách sử dụng 300 Point để đổi voucher liệu trình Healing, API hệ thống phải:

  1. Trừ toàn bộ 200 Point từ nguồn Minigame trước (do sắp hết hạn).
  2. Trừ tiếp 100 Point từ nguồn mua tại quầy.
  3. Số điểm còn lại trong ví là 700 Point (thuộc nguồn mua tại quầy).

3. Thiết Kế UI/UX Màn Hình Đổi Điểm Trên App​

Không ẩn tính năng đổi điểm khi khách hàng chưa đủ điều kiện. Thay vào đó, hãy hiển thị ở trạng thái khóa để khuyến khích tiêu dùng.

3.1. Trạng thái Khóa (Khi số dư ví GPoint < 10.000)​

  • Nút gạt "Sử dụng điểm" bị làm mờ (Disabled).
  • Hiển thị dòng thông báo tiến trình bên dưới:

    “Bạn đang có [X] điểm. Cần tích lũy thêm [10.000 - X] điểm nữa để bắt đầu sử dụng thanh toán.”

3.2. Trạng thái Mở (Khi số dư ví GPoint >= 10.000)​

  • Nút gạt sáng lên (Enabled).
  • Khi kích hoạt, cho phép khách hàng chọn:
    • Dùng tất cả điểm: Hệ thống tự động điền số điểm tối đa có thể trừ vào hóa đơn.
    • Nhập số điểm thủ công: Khách hàng tự nhập số điểm mong muốn sử dụng.

4. Logic Tính Toán Khấu Trừ (Backend & POS)​

4.1. Thứ tự xếp chồng khuyến mãi (Discount Hierarchy)​

Để tránh tranh chấp số tiền bill, luôn tính toán theo trình tự:

  1. Áp dụng Voucher giảm giá (hoặc chiết khấu % theo thẻ thành viên) trước.
  2. Lấy số tiền sau giảm giá làm Số tiền cuối cùng cần thanh toán (Final Amount).
  3. Áp dụng khấu trừ GPoint trực tiếp vào số tiền Final Amount này.
  4. Quy tắc chặn âm: Số Point quy đổi ra tiền tối đa được sử dụng không được vượt quá số tiền Final Amount.

4.2. Logic Kế toán trên POS (Payment Method)​

  • Vấn đề: Hầu hết các máy POS không cho phép đóng bàn hoặc in bill nếu số tiền khách cần trả bằng 0đ (khi trừ sạch bằng điểm).
  • Giải pháp: Ghi nhận việc trừ điểm dưới dạng một Phương thức thanh toán (Payment Method) độc lập (ngang hàng với Tiền mặt, Chuyển khoản, Thẻ ngân hàng), tuyệt đối không ghi nhận dưới dạng Giảm giá hóa đơn (Discount).
  • Ví dụ in hóa đơn:
    • Tổng tiền dịch vụ: 1.000.000đ
    • Thanh toán bằng Ví GPoint: 1.000.000đ
    • Tiền mặt/Thẻ cần thu thêm: 0đ (POS vẫn đóng bàn, kho nguyên liệu vẫn trừ bình thường và dòng tiền thực tế được hạch toán chính xác).

4.3. Loại trừ tích lũy Status Point (Điểm xét hạng)​

  • Phần tiền hóa đơn được thanh toán bằng GPoint không được tính vào thanh tiến trình tích lũy chi tiêu lên hạng. Tiến trình xét hạng chỉ tính dựa trên dòng tiền thực tế (Cash / Card / Chuyển khoản).

5. Cơ Chế Thanh Toán Hỗn Hợp (POS Split Payment)​

Lễ tân tại quầy cần hỗ trợ khách hàng thanh toán hóa đơn bằng cách kết hợp nhiều phương thức thanh toán (ví dụ: Point + Tiền mặt).

sequenceDiagram
    autonumber
    Lễ tân->>POS: Mở hóa đơn thanh toán (Ví dụ: 1.000.000đ)
    Lễ tân->>POS: Chuyển qua Tab Point & Nhập số điểm trừ (Ví dụ: 200.000 Point)
    Note over POS: POS hiển thị: "Còn phải thu: 800.000đ"
    Lễ tân->>POS: Chuyển qua Tab Tiền mặt/Thẻ & Nhập 800.000đ
    POS->>POS: Khớp tổng tiền thanh toán (1.000.000đ)
    POS->>Lễ tân: Kích hoạt nút "In hóa đơn / Đóng bàn"
  • Lưu ý: Team App và Team POS cần thống nhất thiết kế màn hình lễ tân của máy POS hỗ trợ cơ chế cộng dồn (Accumulation) của Split Payment này trước khi vận hành.

6. Thiết Kế UI Tab Point Dành Cho Lễ Tân Trên POS​

Giao diện Tab Point trên máy POS lễ tân cần tối giản hóa và hiển thị chính xác 3 trường thông tin:

  1. Điểm khả dụng (Read-only):
    • Tự động lấy số điểm hiện có của khách hàng từ server hệ thống (Ví dụ: 1,250 GPoint).
  2. Số điểm muốn sử dụng (Input):
    • Cho phép thu ngân nhập số điểm muốn trừ (Ví dụ: 1,000).
    • Cài đặt logic chặn: Không cho phép nhập số điểm lớn hơn Tổng hóa đơn hoặc Điểm khả dụng. Chặn sử dụng nếu số điểm khả dụng của khách hàng nhỏ hơn 10.000 GPoint.
  3. Quy đổi (Read-only):
    • Hiển thị số tiền tương ứng được quy đổi từ số điểm muốn sử dụng (Ví dụ: = 1.000 VNĐ).