Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
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á.
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ớ.
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á.
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.
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.
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.
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.
Đâ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à:
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 đó.
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.
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.
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 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.
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.
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á.
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á.
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.
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.
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ơ.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận