URD: Định giá
| Module | Phiên bản | Cập nhật |
|---|---|---|
CORE-14 | v0.4 | 2026-07-15 |
Module Định giá làm gì
Xác định các yêu cầu hướng người dùng cho bộ máy Định giá - cách một merchant đặt giá, cách tính thuế, cách theo dõi giá vốn biến thể, và cách cấu hình khuyến mãi. Kết quả là mọi dòng hàng và mọi đơn hàng đều được định giá nhất quán và có thể kiểm toán, cả khi chủ merchant cấu hình lẫn khi luồng bán hàng hỏi giá lúc thanh toán.
Năm ý cần hiểu trước
Đây là phần quan trọng nhất của tài liệu. Hiểu năm ý dưới đây là hiểu 80% module.
1. Chọn fare là một cuộc thi loại trực tiếp qua ba vòng
Một biến thể có thể mang nhiều fare cùng lúc: giá gốc, một fare theo mùa, một fare cho khách quen. Bộ máy không tự hỏi "fare nào đẹp nhất" - nó chạy đúng ba vòng loại, theo thứ tự cố định, không đổi.
| Vòng | Việc làm |
|---|---|
| 1. Gạn tầng | Trong số mọi fare hợp lệ (đã qua hết quy tắc điều kiện) cộng với giá gốc, chỉ giữ lại tầng ưu tiên cao nhất. Fare ở tầng thấp hơn bị loại thẳng, dù giá của nó rẻ tới đâu. |
| 2. Ưu tiên OVERRIDE | Trong tầng còn lại, nếu có ít nhất một fare kiểu OVERRIDE thì nó thắng luôn - không cần so giá với fare kiểu SALE trong cùng tầng. Có nhiều OVERRIDE thì cái rẻ nhất trong số chúng thắng. |
| 3. Rẻ nhất trong tầng | Không có OVERRIDE nào trong tầng thì fare rẻ nhất trong tầng đó thắng - có thể là một fare SALE, cũng có thể là chính giá gốc nếu giá gốc lọt vào tầng này. |
Giá gốc không đứng ngoài cuộc thi. Nó tham gia ở một mức ưu tiên riêng của chính nó, mặc định là 0. Nghĩa là một fare con cũng ở mức ưu tiên 0 không tự động thắng giá gốc - hai bên vẫn phải so giá như hai đối thủ ngang hàng.
Ví dụ chạy bằng số - vòng 2 quyết định:
Biến thể có giá gốc 100.000đ (ưu tiên 0). Chủ merchant thêm một fare SALE con giá 80.000đ và một fare OVERRIDE con giá 90.000đ, cả hai cùng đặt ưu tiên 1 và cùng đang hợp lệ (qua hết quy tắc điều kiện của chúng).
- Gạn tầng: tầng cao nhất trong số các ứng viên hợp lệ là ưu tiên 1. Giá gốc đứng ở ưu tiên 0 nên bị loại khỏi vòng này ngay từ đầu, dù nó vẫn là một lựa chọn hợp lệ về nguyên tắc.
- Trong tầng 1 có một OVERRIDE (90.000đ) đang hợp lệ.
- OVERRIDE thắng ngay - bộ máy không buồn so 90.000đ với 80.000đ của fare SALE. Khách trả 90.000đ, dù fare SALE rẻ hơn 10.000đ.
Lý do thiết kế: OVERRIDE là một ý chí ghi đè cứng của chủ merchant - giá theo hợp đồng, giá combo đã chốt, giá không ai được mặc cả thêm. SALE chỉ là một mức giảm đang cạnh tranh với các mức giảm khác. Khi cả hai cùng có mặt trong một tầng, ghi đè luôn thắng cạnh tranh.
Ví dụ thứ hai - quy tắc điều kiện quyết định fare có được vào vòng đấu hay không:
Cùng biến thể, giá gốc 100.000đ. Lần này chỉ có một fare SALE con giá 80.000đ, mang quy tắc "số lượng mua từ 10 trở lên".
- Khách mua 12 đơn vị: quy tắc số lượng đúng, fare SALE hợp lệ. Tầng cao nhất trong số ứng viên hợp lệ giờ có cả giá gốc lẫn fare SALE (nếu cùng mức ưu tiên) - không OVERRIDE nào trong tầng, nên fare rẻ nhất thắng: 80.000đ.
- Khách mua 5 đơn vị: quy tắc số lượng sai, fare SALE bị loại ngay từ vòng lọc quy tắc, còn coi như chưa từng dự thi. Không còn fare con nào hợp lệ, bộ máy trả thẳng về giá gốc: 100.000đ.
Không có fare con nào hợp lệ thì bộ máy không đi tìm phương án nào khác - nó quay ngay về giá gốc, không báo lỗi, không chặn giao dịch.
2. Ảnh chụp định giá là bất biến - mọi con số được sao chép, không tham chiếu ngược
Mỗi lần định giá xong, kết quả không lưu một đường link trỏ về cấu hình fare hay thuế đã dùng. Nó sao chép hẳn: tên hiển thị, giá trị cơ sở, số tiền, ai chịu khoản đó, có gộp trong giá hay không - tất cả đóng băng ngay tại thời điểm tính.
Vì vậy nếu sau này chủ merchant đổi tên một loại thuế, hay tắt hẳn một fare đã dùng để bán hàng hôm qua, đơn hàng hôm qua vẫn hiển thị đúng y như lúc bán: đúng tên thuế, đúng số tiền, đúng fare đã áp. Ảnh chụp chỉ giữ lại một mã tham chiếu tới bản ghi gốc để tra cứu khi cần, nhưng mọi con số hiển thị đều lấy từ bản sao đã đóng băng, không tính lại từ cấu hình hiện tại.
Đây là điều bắt buộc cho hóa đơn, đối soát và giải quyết tranh chấp - một hóa đơn không được phép đổi số theo thời gian.
3. Thuế: đã gộp trong giá và cộng thêm lên giá là hai cách tính ngược chiều nhau
Một khoản thuế có thể đứng theo hai cách:
- Cộng thêm (exclusive): thuế được tính trên giá rồi cộng thêm lên trên. Tổng tăng lên đúng bằng số tiền thuế.
- Đã gộp (inclusive): thuế nằm sẵn trong giá đang hiển thị, bộ máy tính ngược ra để biết trong đó có bao nhiêu là thuế. Tổng khách trả không đổi.
Ví dụ bằng số: một dòng giá 110.000đ, thuế suất 10%.
- Nếu thuế này là cộng thêm: thuế = 110.000 x 10% = 11.000đ, khách trả tổng 121.000đ.
- Nếu thuế này là đã gộp: thuế = 110.000 - 110.000 / 1,1 = 10.000đ, khách vẫn chỉ trả 110.000đ như giá niêm yết - thuế đã nằm sẵn trong đó, tách ra chỉ để biết phần nào là thuế.
Một dòng có thể mang nhiều thuế xếp theo thứ tự ưu tiên, và một thuế có thể là lũy tiến - tính trên tổng đang chạy đã gồm các thuế ưu tiên trước nó, thay vì tính trên giá gốc ban đầu. Ví dụ hai thuế cộng thêm xếp theo thứ tự: 10% rồi tới 5% lũy tiến, trên nền giá 100.000đ. Thuế đầu tính trên 100.000đ, ra 10.000đ, đẩy tổng đang chạy lên 110.000đ. Thuế thứ hai lũy tiến trên 110.000đ (không phải 100.000đ ban đầu), ra 5.500đ. Tổng thuế là 15.500đ, không phải 15.000đ nếu tính riêng từng khoản trên nền gốc.
Một dòng hàng chưa gắn thuế nào vẫn định giá được bình thường - phần thuế chỉ đơn giản bằng 0, không có gì bị chặn lại vì thiếu cấu hình.
4. Sổ cái theo bên chịu - mỗi khoản tiền phải ghi rõ ai trả
Mỗi khoản trong một dòng đã định giá (giá, thuế, giảm giá, phí) đều gắn với một bên chịu cụ thể - hiện tại đã đấu nối hai bên là người mua và người bán, còn nền tảng trung gian, nhà cung cấp thượng nguồn, và cơ quan thuế vẫn đang dự phòng cho những khoản phí chưa mở.
Phần lớn khoản thuế do người mua gánh, cộng thêm hoặc đã gộp vào số khách trả. Nhưng chủ merchant cũng có thể cấu hình một khoản thuế do chính merchant gánh - khoản đó không được cộng thêm vào hóa đơn khách nhận, mà ghi riêng vào phần của người bán trong sổ cái.
Ví dụ: một dòng giá 100.000đ, thuế VAT 10% cộng thêm do khách chịu = 10.000đ. Khách trả tổng 110.000đ. Nếu cùng dòng đó có thêm một khoản 2.000đ mà merchant phải tự gánh (không tính vào giá bán cho khách), khoản này không cộng vào 110.000đ khách trả - nó chỉ xuất hiện trong phần của người bán trên sổ cái, để chủ merchant biết chính xác mình còn lại bao nhiêu sau khi trừ đi nghĩa vụ đó.
Ảnh chụp của cả dòng lẫn cả đơn đều cuộn số tiền lên theo đúng cách chia bên này - số khách phải trả một cột, phần mỗi bên gánh một cột khác - để đọc báo cáo không phải tự cộng lại từ đầu.
5. Giá vốn là một trục hoàn toàn tách biệt với giá bán
Fare quyết định khách trả bao nhiêu. Giá vốn trả lời một câu hỏi khác hẳn: merchant đã bỏ ra bao nhiêu cho một đơn vị hàng đó. Hai con số này không liên quan gì tới nhau trong bộ máy chọn fare - đổi giá vốn không làm đổi giá bán, và ngược lại.
Giá vốn được theo dõi theo từng khoảng thời gian hiệu lực, không phải một con số tĩnh. Tại một thời điểm, một biến thể chỉ có đúng một bản ghi giá vốn đang mở (chưa kết thúc) - đó là giá vốn hiện tại. Khi chủ merchant cập nhật giá vốn mới, bản ghi cũ được đóng lại (gắn ngày kết thúc), và một bản ghi mới mở ra thay thế, không ghi đè lên bản ghi cũ.
Ví dụ: biến thể đang có giá vốn hiện tại 50.000đ, bản ghi này chưa có ngày kết thúc. Ngày 10/07, chủ merchant cập nhật giá vốn thành 60.000đ. Bản ghi 50.000đ được đóng lại với ngày kết thúc là 10/07; một bản ghi mới 60.000đ mở ra, không có ngày kết thúc, trở thành giá vốn hiện tại. Toàn bộ lịch sử giá vốn được giữ nguyên, phục vụ tính biên lợi nhuận theo thời gian - không phải chỉ biết giá vốn "bây giờ" mà còn tra lại được giá vốn "lúc đó".
Module có những gì
Năm nhóm feature. Bấm vào mã AREA để sang tab Chi tiết đọc yêu cầu của nhóm đó.
AREA | Tên | Trạng thái |
|---|---|---|
FARE | Fare & Fare Set | Đã dựng |
TAX | Tính thuế | Đã dựng |
COST | Theo dõi giá vốn | Đã dựng |
SIM | Mô phỏng & Xem trước định giá | Đã dựng |
PROMO | Khuyến mãi & Quy tắc | Một phần |