Odoo 18 POS bị lag khi gõ số tiền trên Payment Screen: nguyên nhân và cách fix an toàn

Trong quá trình vận hành POS, có những lỗi không gây crash, không hiện thông báo lỗi, nhưng lại ảnh hưởng trực tiếp đến tốc độ thao tác của thu ngân. Một trong số đó là hiện tượng lag khi gõ số tiền trên Payment Screen của Odoo 18 POS.

Thoạt nhìn, lỗi này rất dễ bị nhầm với vấn đề render chậm, format tiền tệ nặng, hoặc thiết bị yếu. Nhưng khi phân tích sâu hơn, nguyên nhân thực sự lại nằm ở cách Odoo core xử lý buffer input trên frontend.

Bài viết này sẽ đi thẳng vào 3 vấn đề:

• Hiện tượng thực tế là gì
• Vì sao Odoo 18 POS bị lag khi nhập số tiền nhanh

• Cách fix an toàn, ít rủi ro nhất
  

  

Hiện tượng thực tế

Một tình huống khá phổ biến tại quầy thu ngân:

• Hóa đơn cần thanh toán: 46.000đ
• Khách đưa: 50.000đ
• Thu ngân nhập nhanh 50000 trên Payment Screen

Kỳ vọng đúng là hệ thống phải hiển thị ngay 50.000đ.

Tuy nhiên, trên một số hệ thống Odoo 18 POS, số tiền lại hiển thị theo kiểu nhảy nấc:

• 500
• rồi 5.000
• rồi mới đến 50.000

Điều đáng nói là giữa các bước này có độ trễ nhìn thấy rõ, khiến người dùng có cảm giác bị ăn phím, lag máy hoặc nhập sai.

Đây không chỉ là vấn đề trải nghiệm. Trong môi trường bán lẻ, dược phẩm hoặc siêu thị mini, thao tác thanh toán chậm đi vài giây ở mỗi hóa đơn có thể làm giảm đáng kể hiệu suất làm việc.

Vì sao lỗi này dễ bị chẩn đoán sai

Khi nhìn thấy số tiền nhảy chậm, phản xạ đầu tiên của nhiều dev là nghĩ đến:

• re-render quá nặng
• formatter tiền tệ chạy chậm
• custom module patch màn PaymentScreen
• thiết bị POS cấu hình yếu

Những giả thuyết đó không sai hoàn toàn, nhưng không phải nguyên nhân cốt lõi trong trường hợp này.

Dấu hiệu quan trọng nhất là số tiền không chỉ hiển thị chậm, mà còn có xu hướng đi theo từng cụm phím. Đây là pattern rất điển hình của input buffering, chứ không phải render lag thông thường.

Gốc rễ nằm ở NumberBuffer của Odoo 18

Ở Odoo 18 POS, Payment Screen dùng NumberBuffer để nhận input số.

Điểm đáng chú ý là Payment Screen đang cấu hình buffer với:

useWithBarcode: true

Chỉ riêng cấu hình này đã kéo theo hai hệ quả quan trọng:

1. Có debounce giữa các lần gõ phím

Khi useWithBarcode được bật, NumberBuffer sẽ dùng timing của barcode service để quyết định khi nào xử lý input.

Điều đó có nghĩa là:

• hệ thống không xử lý từng phím ngay lập tức
• thay vào đó, nó chờ một khoảng thời gian ngắn để gom phím vào buffer

Trên thực tế, điều này phù hợp với input kiểu barcode scanner, nhưng lại không tối ưu cho thao tác gõ tay nhanh của thu ngân trên Payment Screen.

2. Một số lô input có thể bị clear theo cách không trực quan

Đây mới là phần nguy hiểm nhất.

Khi nhiều key event đi vào quá nhanh trong cùng một khoảng buffer timing, hệ thống có thể xử lý chúng theo từng cụm nhỏ hoặc bỏ qua logic xử lý như người dùng kỳ vọng. Kết quả là UI không phản ánh từng phím ngay thời điểm người dùng nhập.

Hệ quả nhìn thấy trên màn hình là hiện tượng:

• số tiền tăng theo từng nấc
• có delay giữa các nấc
• tạo cảm giác nhập nhanh thì bị “ăn phím”

Vì sao điều này ảnh hưởng mạnh ở Payment Screen

Payment Screen khác với Product Screen.

Ở Product Screen:

• barcode scanning là nghiệp vụ chính
• việc dùng timing kiểu barcode là hợp lý

Nhưng ở Payment Screen:

• nhu cầu chính là nhập số tiền thủ công thật nhanh
• người dùng cần phản hồi tức thì theo từng phím
• trải nghiệm tốt phải là “gõ tới đâu, số hiện tới đó”

Khi áp logic buffer kiểu barcode vào màn thanh toán, hệ thống vô tình làm chậm một thao tác vốn cần tốc độ và độ chính xác cao.

Cách fix an toàn nhất

Thay vì sửa sâu toàn bộ service hoặc động vào backend, cách an toàn nhất là:

• chỉ patch riêng PaymentScreen
• override cấu hình _getNumberBufferConfig
• đặt lại:

useWithBarcode: false

Khi đó:

• input số tiền trên Payment Screen không còn bị xử lý theo nhịp barcode
• mỗi phím được xử lý gần như ngay lập tức
• hiện tượng nhảy nấc hoặc delay giảm rõ rệt
• phạm vi ảnh hưởng được giới hạn rất nhỏ

Vì sao đây là cách fix nên ưu tiên

Giải pháp này có nhiều ưu điểm:

Phạm vi nhỏ

Chỉ tác động tới Payment Screen, không đụng toàn bộ POS.

Ít rủi ro

Không thay đổi database, không cần migrate dữ liệu, không ảnh hưởng backend.

Dễ rollback

Nếu cần, chỉ cần gỡ module patch là hệ thống quay về hành vi core ban đầu.

Không ảnh hưởng logic thanh toán

Phần tax, rounding, payment method hay accounting entry đều không bị động tới.

Khi nào cần kiểm tra thêm custom module

Dù nguyên nhân core đã khá rõ, bạn vẫn nên kiểm tra thêm nếu hệ thống có custom POS:

• patch PaymentScreen
• override NumberBuffer
• custom numpad
• listener keydown, keyup
• formatter tiền tệ riêng
• popup hoặc overlay chặn input
• logic async chạy khi đổi amount

Lý do là core behavior có thể là nguyên nhân gốc, nhưng custom module hoàn toàn có thể làm triệu chứng nặng hơn.

Kết luận

Lỗi lag khi gõ số tiền trên Odoo 18 POS Payment Screen không đơn thuần là vấn đề giao diện chậm. Nó xuất phát từ cách frontend xử lý input buffer, cụ thể là việc Payment Screen dùng cấu hình phù hợp cho barcode hơn là nhập tay.

Nếu hệ thống của bạn có hiện tượng:

• nhập số tiền nhanh bị trễ
• số nhảy theo từng nấc
• thu ngân có cảm giác bị ăn phím

thì đây là một điểm rất đáng kiểm tra trước khi nghi ngờ tới backend hay database.

Trong đa số trường hợp, một patch nhỏ ở Payment Screen để tắt useWithBarcode là hướng optimize đơn giản, an toàn và hiệu quả nhất.

Gợi ý triển khai: trước khi apply fix lên production, hãy test trên staging với 3 tình huống:

• nhập số tiền chậm
• nhập số tiền rất nhanh
• thử thao tác trong nhiều trình duyệt hoặc thiết bị POS khác nhau

Như vậy bạn sẽ xác nhận được fix có thực sự giải quyết vấn đề mà không gây side effect ngoài ý muốn.