---
title: "Pricelist trong Odoo: thứ tự ưu tiên giá"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/pricelist-odoo-thu-tu-uu-tien-gia"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Pricelist trong Odoo: thứ tự ưu tiên giá

> Một sản phẩm có giá niêm yết, giá theo nhóm khách, giá theo bậc số lượng và giá khuyến mãi. Odoo chọn quy tắc nào trước, và chỗ hay gãy khi demo giá.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/pricelist-odoo-thu-tu-uu-tien-gia
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: Phân hệ Odoo

Buổi nghiệm thu ở một doanh nghiệp phân phối hàng tiêu dùng. Người phụ trách kinh doanh in hai đơn hàng của cùng một mặt hàng, đặt lên bàn và hỏi vì sao đơn này ra chín mươi sáu nghìn còn đơn kia ra một trăm nghìn, trong khi cả hai đều là khách sỉ và đặt trong cùng một tuần.

Cả đội triển khai đều biết hệ thống đã được cấu hình đúng, nhưng không ai chỉ ra được ngay dòng cấu hình nào đã sinh ra con số kia, và buổi nghiệm thu bị treo lại nửa tiếng để mở từng màn hình ra dò.

Câu hỏi vì sao đơn này ra giá này thì dự án nào có bán hàng cũng gặp, thường là ở buổi demo, đôi khi muộn hơn là ở tuần đầu vận hành thật, và người phải trả lời được nó là người phân tích chứ không phải lập trình viên.

> Trả lời được câu đó không đòi hỏi thuộc màn hình; nó đòi hỏi nắm được thứ tự mà hệ thống dùng để chọn một mức giá trong nhiều mức cùng hợp lệ.

Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ.

## Bài toán giá trước khi có hệ thống

Hãy bắt đầu từ chỗ doanh nghiệp đang vướng, không phải từ chỗ Odoo có gì.

**Một mặt hàng trong thực tế gần như không bao giờ chỉ có một giá.**

* Nó có giá niêm yết dùng để in catalog và báo cho khách lẻ
* có giá riêng cho khách sỉ và một mức khác cho đại lý cấp một
* có giá giảm dần theo bậc số lượng
* có giá theo đợt như dịp lễ
* và trên tất cả, đôi khi còn một chương trình khuyến mãi cộng thêm vào phút chót.

Khi những chính sách này còn nằm trong file Excel và trong trí nhớ của trưởng phòng kinh doanh thì mâu thuẫn giữa chúng không lộ ra, vì con người tự phân xử: nhân viên nhìn đơn, biết khách này là đại lý lâu năm đang mua số lượng lớn trong đợt khuyến mãi, rồi tự quyết một con số hợp lý. Đưa lên hệ thống thì chỗ mập mờ đó không còn nữa, bởi phần mềm buộc phải chọn đúng một con số theo một trật tự đã lập trình sẵn chứ không theo cảm nhận của người bán.

> Do đó việc đầu tiên của người phân tích không phải là hỏi khách có bao nhiêu bảng giá, mà là hỏi khi hai chính sách cùng đúng thì bên nào thắng.

Không hỏi câu này ở giai đoạn khảo sát thì nó quay lại tìm bạn ở giai đoạn nghiệm thu, và lúc đó chi phí sửa đã khác hẳn.

## Bảng giá và các quy tắc bên trong nó

Từ nhu cầu trên, Odoo đưa ra đối tượng **bảng giá (Pricelist)**, và nó cần được hiểu là **một cái hộp chứa quy tắc** chứ không phải một danh sách hai cột gồm mã sản phẩm và đơn giá.

Một bảng giá có nhiều dòng quy tắc, mỗi dòng khai báo ba nhóm thông tin.

* **Nhóm thứ nhất là phạm vi**: quy tắc áp cho tất cả sản phẩm, cho một danh mục, cho một sản phẩm hay cho một biến thể.
* **Nhóm thứ hai là điều kiện**, gồm số lượng tối thiểu và khoảng ngày hiệu lực.
* **Nhóm thứ ba là cách tính giá**, gồm giá cố định, chiết khấu theo phần trăm, và công thức cho phép cộng thêm chiết khấu, làm tròn, phụ phí và biên lợi nhuận tối thiểu, tối đa trên một mức giá gốc.

Cần lưu ý một chi tiết nhiều người mới bỏ qua: **một dòng quy tắc không chọn sản phẩm nào cũng không chọn danh mục nào không phải là dòng vô nghĩa, mà là dòng áp cho tất cả sản phẩm** của doanh nghiệp. Đây là cách dựng chương trình đồng giá hay giảm phần trăm cho cả một nhóm khách, và cũng là cách người ta vô tình phá hỏng bảng giá của mình khi thêm một dòng thử nghiệm rồi quên xóa.

![Dòng quy tắc không chọn sản phẩm nào là dòng áp cho mọi sản phẩm](https://bahub.vn/uploads/2026/11/1793631184176-ad6f0i-pricelist-odoo-thu-tu-uu-tien-gia-1.webp "Dòng quy tắc không chọn sản phẩm nào là dòng áp cho mọi sản phẩm")

Về mặt hiển thị với khách thì các cách tính giá không giống nhau, và đây là chỗ đáng nhớ khi dựng bản demo. Khi quy tắc dùng kiểu chiết khấu theo phần trăm thì phần trăm giảm đó hiện thành một cột chiết khấu riêng trên báo giá, với điều kiện tính năng chiết khấu trên dòng đơn hàng đã được bật trong cài đặt của phân hệ Bán hàng; còn khi quy tắc dùng kiểu công thức thì hệ thống chỉ trả ra đơn giá cuối cùng và khách không thấy phần giảm.

Cùng một kết quả tiền, hai cách cấu hình, nhưng cảm nhận của người nhận báo giá thì khác hẳn, nên đây là thứ phải hỏi khách chứ không phải thứ bạn tự chọn.

## Thứ tự Odoo chọn quy tắc

Đây là phần lõi của bài, và cũng là phần tôi khuyên bạn dựng lại trên hệ thống thật trước khi đem đi giải thích cho khách.

Trên Odoo 19, cơ chế lấy giá gồm hai bước. Bước thứ nhất, hệ thống lọc ra tập các dòng quy tắc còn áp được cho sản phẩm đang xét, theo danh mục, sản phẩm, biến thể và khoảng ngày hiệu lực; số lượng tối thiểu chưa được xét ở bước này.

Bước thứ hai, hệ thống duyệt tập đó theo một thứ tự cố định, kiểm từng dòng xem số lượng có đạt mức tối thiểu không, **gặp dòng đầu tiên thỏa điều kiện thì lấy dòng đó và dừng ngay**. Nó không xét tiếp các dòng còn lại và không so sánh xem dòng nào cho giá rẻ hơn.

Thứ tự cố định đó là:

1. phạm vi từ hẹp tới rộng, tức biến thể rồi tới sản phẩm rồi tới danh mục rồi mới tới tất cả sản phẩm
2. trong cùng một phạm vi thì số lượng tối thiểu lớn đứng trước nhỏ
3. sau đó còn một tiêu chí phụ theo danh mục
4. và cuối cùng dòng tạo sau đứng trước dòng tạo trước.

Hệ quả của việc **phạm vi được xét trước số lượng** là thứ đáng giá nhất trong cả bài, bởi nó là nguyên nhân của một lỗi cấu hình rất khó nhìn ra.

Giả sử bảng giá sỉ có giá bậc thang cho danh mục quần jean bằng hai dòng khai ở mức danh mục, một dòng từ mười một cái và một dòng từ ba mươi cái trở lên. Rồi có người thêm một dòng gán đích danh một mã quần jean với số lượng tối thiểu để trống, nhằm chốt giá riêng cho mã đó.

Từ lúc đó trở đi, với mã này thì dòng gán đích danh luôn thắng, kể cả khi khách đặt năm mươi cái, vì nó hẹp hơn về phạm vi và hệ thống dừng ngay khi gặp nó. Toàn bộ bậc số lượng dựng công phu phía trên trở thành vô hiệu với mã đó mà không có thông báo lỗi nào, và người dùng cuối chỉ biết là giá bị sai.

Nguyên tắc rút ra khá ngắn gọn. **Các bậc của cùng một thang số lượng phải khai ở cùng một mức phạm vi**; còn nếu buộc phải trộn hai mức thì phải khai lại đầy đủ các bậc ở mức hẹp hơn. Khách có quá nhiều ngoại lệ theo từng mã hàng thì cách bền hơn là tách hẳn một bảng giá riêng cho nhóm khách đó.

![Hệ thống dừng ở dòng hẹp nhất thỏa điều kiện, bậc số lượng phía dưới bị bỏ qua](https://bahub.vn/uploads/2026/11/1793631187504-i97le5-pricelist-odoo-thu-tu-uu-tien-gia-2.webp "Hệ thống dừng ở dòng hẹp nhất thỏa điều kiện, bậc số lượng phía dưới bị bỏ qua")

Trường hợp không dòng quy tắc nào thỏa thì hệ thống rơi về giá bán khai trên chính sản phẩm, và đây là lý do của một tình huống người mới hay gặp. Bảng giá mà Odoo tự tạo cho mỗi công ty khi bật tính năng bảng giá là **một bảng trống, không có dòng quy tắc nào**, nên mọi đơn hàng vẫn ra đúng giá niêm yết và người dùng kết luận nhầm rằng tính năng bảng giá không chạy.

## Đường đi của bảng giá từ khách hàng xuống đơn hàng

Biết quy tắc nào thắng mới là một nửa câu trả lời; nửa còn lại là bảng giá nào đang được dùng trên đơn.

Bảng giá được gắn ở hồ sơ khách hàng, trong tab Bán hàng và Mua hàng, và khi nhân viên chọn khách trên báo giá thì hệ thống tự điền nó xuống. Đây là một ví dụ của nguyên tắc kế thừa: **thứ cấu hình ở master data tự chảy xuống transaction data**, nên nếu khách muốn nhân viên không phải nhớ khách nào giá nào thì việc cần làm là gán bảng giá vào từng hồ sơ khách, không phải viết thêm chức năng.

Đường tìm bảng giá của một khách hàng có nhiều nấc chứ không phải một nấc như nhiều người tưởng.

1. Hệ thống lấy bảng giá được gán riêng trên hồ sơ khách trước
2. nếu hồ sơ không gán riêng thì lấy bảng giá gắn với nhóm quốc gia chứa quốc gia của khách
3. phía sau còn hai nấc dự phòng nữa là bảng giá mặc định chung và bảng giá đầu tiên tìm được.

Vì vậy trên hồ sơ khách gần như không bao giờ thấy ô bảng giá để trống, và thấy một bảng giá trên đó chưa có nghĩa là ai đó đã chủ động gán nó.

Đồng thời, bảng giá là một trong những trường được đồng bộ theo pháp nhân của khách, nên các liên hệ con dưới một công ty dùng chung một bảng giá với công ty đó và bạn không gán được bảng giá riêng cho một liên hệ con; [cấu trúc cha con của danh mục đối tác](https://bahub.vn/khoa-hoc/erp-cho-ba/contact-customer-vendor-odoo) là chủ đề của một bài riêng.

Về phía đơn hàng có ba hành vi cần nắm.

* **Thứ nhất, bảng giá chỉ được tự điền lại theo khách khi đơn còn ở trạng thái báo giá nháp.**
* **Thứ hai, đổi bảng giá trên một đơn đã có dòng sản phẩm thì các dòng cũ giữ nguyên giá**, chỉ dòng thêm mới sau đó mới lấy theo bảng giá mới; muốn giá cũ tính lại thì phải bấm nút Cập nhật giá, và nút này chỉ hiện ra ngay sau khi bạn đổi bảng giá trên một báo giá đã có dòng.
* **Thứ ba, đơn đã xác nhận thì hệ thống chặn hẳn việc đổi bảng giá.**

Nút Cập nhật giá còn có một tác dụng phụ phải nói trước với người dùng. Khi nút này chạy, hệ thống tính lại đơn giá của toàn bộ các dòng theo bảng giá hiện tại và đưa cột chiết khấu về để tính lại từ đầu, tức là **những dòng nhân viên đã sửa đơn giá hay sửa chiết khấu bằng tay để chốt với khách cũng bị ghi đè theo**.

Hệ thống có hiện một câu hỏi xác nhận trước khi chạy, nhưng câu đó không nhắc gì tới giá sửa tay. Với đội kinh doanh quen thương lượng từng dòng thì đây là một cú sốc, nên cách an toàn là dạy họ chọn đúng bảng giá trước khi thêm dòng, và chỉ bấm Cập nhật giá khi thật sự muốn dựng lại toàn bộ giá của đơn.

![Nút Cập nhật giá dựng lại toàn bộ giá, kể cả những dòng đã sửa tay](https://bahub.vn/uploads/2026/11/1793631192133-ptfla1-pricelist-odoo-thu-tu-uu-tien-gia-3.webp "Nút Cập nhật giá dựng lại toàn bộ giá, kể cả những dòng đã sửa tay")

## Vị trí của khuyến mãi so với bảng giá

**Khuyến mãi là một tầng khác chứ không phải một loại quy tắc bên trong bảng giá**, và ranh giới này cần nói rõ ngay từ buổi khảo sát.

Bảng giá quyết định đơn giá của từng dòng sản phẩm, còn chương trình khuyến mãi sinh thêm một dòng riêng mang giá trị âm hoặc một dòng hàng tặng, tức là nó cộng vào sau khi đơn giá đã được xác định.

Mỗi chương trình khuyến mãi có một trường cho phép giới hạn chương trình theo một tập bảng giá, nên chính sách kiểu chương trình này chỉ dành cho khách sỉ dựng được bằng cấu hình. Phần còn lại của khuyến mãi là một chủ đề riêng; ở đây chỉ cần nhớ **nó nằm trên bảng giá chứ không nằm trong bảng giá**.

## Bộ câu hỏi khảo sát chính sách giá

Những gì ở trên chuyển thành một danh sách việc phải làm khi khảo sát phần bán hàng, và nên chạy hết trước khi hứa bất cứ điều gì về giá.

* Hỏi doanh nghiệp có bao nhiêu chính sách giá và mỗi chính sách áp cho nhóm khách nào
* Hỏi khi hai chính sách cùng đúng trên một đơn thì bên nào thắng, và bắt khách nêu một ví dụ thật
* Hỏi giá theo bậc số lượng đang tính theo từng dòng hàng hay theo tổng đơn
* Hỏi chính sách nào có thời hạn và ai được quyền bật tắt nó
* Hỏi nhân viên có được sửa giá tay trên báo giá hay không, và ai duyệt
* Hỏi khách muốn phần giảm hiện ra cho người mua hay chỉ hiện giá cuối
* Hỏi một pháp nhân có nhiều chi nhánh thì dùng chung một mức giá hay khác nhau

**Câu hỏi về bậc số lượng theo dòng hay theo tổng đơn hay bị bỏ sót nhất và cũng tốn tiền nhất.** Trên báo giá, Odoo lấy giá cho từng dòng bằng chính số lượng của dòng đó, nên số lượng tối thiểu trong bảng giá được xét theo từng dòng sản phẩm; nếu khách muốn cộng dồn nhiều dòng trong cùng một đơn rồi mới xếp bậc thì đó là khoảng trống phải xử lý bằng cách khác, không phải bằng cấu hình bảng giá.

Cách kiểm nhanh nhất là tạo một đơn có hai dòng cùng một mã hàng, mỗi dòng dưới ngưỡng nhưng cộng lại thì vượt, rồi xem hệ thống ra giá nào.

## Cách giải thích một dòng giá cho khách

Cuối cùng là phần thao tác, tức là thứ bạn làm khi khách chỉ vào một con số và hỏi vì sao.

1. **Đầu tiên, mở đơn hàng và đọc bảng giá đang gắn trên đơn**, vì nhiều trường hợp câu trả lời dừng ngay ở đây: nhân viên chọn nhầm khách, hoặc đơn được tạo từ trước lúc bảng giá được gán.
2. **Tiếp theo, mở sản phẩm xem giá bán niêm yết** để có mốc so sánh.
3. **Sau đó, mở bảng giá đang gắn và đọc các dòng quy tắc** theo đúng thứ tự đã nói ở trên.
4. **Cuối cùng, kiểm tra xem trên đơn có dòng khuyến mãi nào không**, vì nếu có thì con số cuối cùng đã bị một tầng khác tác động.

Bốn bước này nên dựng thành một màn hình minh họa trong buổi demo, với đúng một mặt hàng và ba dòng quy tắc, chứ đừng demo bằng dữ liệu thật vốn có hàng chục dòng chồng lên nhau.

> Mục tiêu của buổi demo giá không phải là chứng minh hệ thống tính đúng, mà là làm cho người ngồi đối diện tự đọc được cấu hình và tự giải thích con số cho cấp trên sau khi bạn rời đi.

Cũng nên nói rõ với khách một giới hạn ngay từ đầu. Cơ chế bảng giá của Odoo mạnh ở việc chọn một mức giá theo phạm vi, số lượng và thời gian, nhưng **nó không được thiết kế để giải thích chính nó**: không có màn hình nào cho biết dòng quy tắc nào vừa được chọn và vì sao các dòng khác bị loại, nên phần diễn giải vẫn là việc của con người.

Chuyện gắn bảng giá vào hồ sơ khách hàng dẫn thẳng tới câu hỏi mà khách gần như luôn hỏi trong buổi khảo sát đầu tiên: một đối tác vừa là khách hàng vừa là nhà cung cấp thì phải tạo mấy hồ sơ.

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/pricelist-odoo-thu-tu-uu-tien-gia — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.