Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Phân hệ tính lương không có trong Odoo mã nguồn mở, và bản 19 không liệt kê Việt Nam trong danh sách địa phương hóa lương. Khung quyết định và sáu câu hỏi.
Trong buổi khảo sát khối nhân sự ở một doanh nghiệp sản xuất vài trăm lao động, câu hỏi thường tới ở phút thứ mười: hệ thống này có tính lương được không. Người tư vấn mở danh sách ứng dụng, chỉ vào phân hệ Bảng lương, rồi trả lời có.
Câu trả lời đó không sai về chữ nghĩa, nhưng nó bỏ qua gần như toàn bộ phần khó. Cái giá thường tới muộn: đến kỳ lương đầu tiên trên hệ thống mới, phiếu lương lệch với bảng tính mà bộ phận nhân sự vẫn làm tay, không ai dám gửi cho người lao động, và hai bên chạy song song thêm nhiều tháng.
Do đó câu hỏi ở tiêu đề không nên trả lời bằng có hay không. Có doanh nghiệp nên đưa lương lên Odoo, có doanh nghiệp không nên, và thứ phân biệt hai nhóm là mấy trục dưới đây.
Cái khó nằm ở ba chỗ, và không chỗ nào nằm ở màn hình.
Cái khó thứ nhất là một phiếu lương ở Việt Nam không phải một phép nhân mà là chuỗi cộng trừ có thứ tự phụ thuộc. Thứ tự đó do doanh nghiệp và bộ phận nhân sự của họ xác định theo quy định đang áp dụng, còn việc của bạn là dựng hệ thống chạy đúng theo thứ tự họ chốt:
Đổi thứ tự một mắt xích thì các mắt xích sau mất dữ liệu đầu vào và cả phiếu lương sai.
Cái khó thứ hai là dữ liệu công. Doanh nghiệp có nhiều khối làm việc theo lịch khác nhau, có ca đêm, có tăng ca cuối tuần và ngày lễ với hệ số khác nhau, có ngày nghỉ nhà nước quy định và ngày nghỉ công ty tự cho. Ngày công chuẩn cũng không phải hằng số: tháng nhiều ngày lễ thì ngày công chuẩn giảm, mà đó là mẫu số nên đơn giá một ngày công tăng, kéo theo việc nghỉ không lương trong tháng đó bị trừ nặng hơn.
Cái khó thứ ba là các khoản trích theo lương và thuế thu nhập cá nhân. Biểu thuế lũy tiến từng phần không diễn đạt được bằng một tỷ lệ duy nhất hay một số tiền cố định, và điều đó có hệ quả trực tiếp lên loại quy tắc lương bạn chọn.
Các khoản trích thì phụ thuộc tình trạng của người lao động trong tháng, chẳng hạn người không làm việc và không hưởng lương từ mười bốn ngày làm việc trở lên trong tháng thì tháng đó không phải đóng bảo hiểm xã hội và bảo hiểm thất nghiệp, trừ khi hai bên thỏa thuận vẫn đóng bảo hiểm xã hội. Thêm vào đó là kỳ quyết toán cuối năm, và việc các con số được sửa gần như năm nào cũng có, như phần dưới sẽ cho thấy.
Câu hỏi đầu tiên là bản Odoo nào có gì.
Trên Odoo 19, phân hệ Payroll, tên kỹ thuật hr_payroll, không có trong bản Community mà thuộc bản Enterprise. Trong khi đó các phân hệ nhân viên, chấm công, nghỉ phép và lớp dữ liệu công hr_work_entry đều có trong bản Community với giấy phép LGPL-3. Nghĩa là phần thu thập dữ liệu đầu vào cho lương thì bản miễn phí có, còn bộ máy tính ra phiếu lương thì không.
Ranh giới giữa hai bản Odoo là một chủ đề riêng, ở đây bạn chỉ cần nhớ hệ quả đó, và nếu muốn tự kiểm thì cách kiểm là tra kho mã nguồn Community của đúng phiên bản.
Câu hỏi kế tiếp là dù có phân hệ lương thì Odoo có sẵn bộ quy tắc theo luật Việt Nam hay không.
Tài liệu chính thức của Odoo 19 có hẳn một trang về gói địa phương hóa cho tính lương, nói rõ rằng phải cài module theo quốc gia thì phân hệ mới xử lý đúng thuế và các khoản trích của nước đó, kèm danh sách khoảng hai chục quốc gia đã có gói ở nhiều châu lục, và Việt Nam không có tên trong danh sách đó, kể cả ở bản tài liệu mới nhất tính tới cuối tháng 10/2026.
Bộ localization Việt Nam mà chính Odoo duy trì gồm những gì là nội dung của một bài riêng. Kết luận cần giữ: bộ quy tắc lương sẽ do đội triển khai dựng, hoặc mua lại của bên thứ ba, mà trên chợ ứng dụng của Odoo thì có những gói tính lương Việt Nam do các đối tác trong nước phát hành. Trong trường hợp mua của bên thứ ba, phải hỏi ngay:
Toàn bộ phần dưới đây mô tả phân hệ lương của bản Enterprise.
Trên Odoo 19, cấu hình payroll đi theo một chuỗi có thứ tự phụ thuộc:
Odoo cài sẵn hai loại cấu trúc lương là Employee và Worker, nhưng đó là khung chung chứ không chứa cách tính đang áp dụng ở Việt Nam, nên với một doanh nghiệp Việt Nam thì chuỗi này gần như phải dựng lại từ đầu.
Trong chuỗi đó hai thứ dễ làm sai nhất là mã của từng quy tắc, bởi quy tắc sau lấy kết quả của quy tắc trước thông qua mã, và thứ tự chạy, bởi đặt lương cơ bản xuống cuối thì mọi quy tắc phía trên không có dữ liệu để tính.
Điểm cần nhớ nhất nằm ở loại tính toán của một quy tắc lương. Trên Odoo 19, ô Amount Type của một quy tắc có bốn lựa chọn là:
Vì biểu thuế lũy tiến từng phần không diễn đạt được bằng ba cách đầu, quy tắc thuế bắt buộc phải viết bằng mã.
Một người triển khai Odoo lâu năm nói thẳng rằng làm quy tắc lương thì phải có lập trình viên hỗ trợ.
Nghĩa là payroll không phải hạng mục cấu hình mà là hạng mục có code, phải kiểm thử, phải bàn giao tài liệu, và phải mang theo qua từng lần nâng cấp.
Trong cả chuỗi, lớp cuối cùng lại là lớp đáng học nhất. Tham số quy tắc lương, trong menu là Rule Parameters, là chỗ để tách các hằng số do pháp luật ấn định ra khỏi công thức: thay vì viết thẳng con số vào mã, bạn khai nó thành một tham số có mã riêng, có giá trị và có ngày bắt đầu hiệu lực, rồi công thức gọi tham số đó theo kỳ lương đang tính.
Cách làm này mang lại hai thứ cùng lúc: khi quy định đổi, người dùng nghiệp vụ vào thêm đúng một dòng giá trị mới nên không cần lập trình viên, đồng thời phiếu lương các kỳ trước vẫn giữ nguyên giá trị cũ vì hệ thống chọn tham số theo ngày hiệu lực chứ không lấy giá trị mới nhất.
Ngược lại, nếu con số bị viết cứng vào công thức thì mỗi lần quy định đổi, đội triển khai phải mở từng quy tắc trong từng cấu trúc lương để sửa, nên sót và nhầm gần như chắc chắn xảy ra.
Muốn thấy vì sao tham số quan trọng, chỉ cần nhìn những gì đã đổi trong khoảng một năm tính tới cuối tháng 10/2026.
Tỷ lệ trích thì vẫn giữ: người lao động đóng 8% bảo hiểm xã hội, 1,5% bảo hiểm y tế và 1% bảo hiểm thất nghiệp, tổng cộng 10,5%; doanh nghiệp đóng 17,5% bảo hiểm xã hội, 3% bảo hiểm y tế và 1% bảo hiểm thất nghiệp, tổng cộng 21,5%, chưa kể 2% kinh phí công đoàn. Thứ đổi liên tục là các con số xung quanh tỷ lệ đó:
Sáu thay đổi đó rơi vào ba mốc ngày khác nhau, có cái áp từ giữa năm, có cái áp ngược cho cả năm, và có cái chỉ đổi một ngưỡng mà không đổi tỷ lệ. Hai chỗ mà người làm lương hay vênh nhau nhất cũng nằm ở đây.
Chỗ thứ nhất là mức giảm trừ: bảng tính nào còn dùng cặp 11 triệu và 4,4 triệu là bảng tính dựng trước năm 2026 và chưa được cập nhật, chứ không phải hai cách hiểu luật khác nhau.
Chỗ thứ hai là thuế của lương thử việc, bởi thử việc theo hợp đồng thử việc riêng thường được xử lý như thu nhập của hợp đồng dưới ba tháng và khấu trừ 10% khi chạm ngưỡng, còn thử việc ghi trong hợp đồng lao động từ ba tháng trở lên thì khấu trừ theo biểu lũy tiến. Cách hiểu áp cho từng loại hợp đồng của doanh nghiệp phải do bộ phận nhân sự và người tư vấn thuế của họ chốt.
Do đó bạn đừng chép các con số trên vào công thức, kể cả khi chúng đúng vào ngày bạn đọc bài này. Hãy khai chúng thành tham số có ngày hiệu lực, và tra lại văn bản gốc tại thời điểm cấu hình.
Dữ liệu dùng để tính lương không phải dữ liệu chấm công mà là dữ liệu công, tức lớp trung gian Odoo sinh ra bằng cách gộp chấm công, nghỉ phép đã duyệt và ngày lễ theo lịch làm việc của từng khối.
Bẫy lớn nhất là dữ liệu công không tự đi theo mỗi lần bản ghi gốc bị sửa. Tài liệu chính thức của Odoo 19 hướng dẫn rằng khi có xung đột thì nên sửa ở ứng dụng gốc như chấm công hay nghỉ phép, rồi tạo lại dữ liệu công bằng chức năng Regenerate Work Entries, bởi nếu chỉ sửa ở lớp công thì lần tạo lại sau xung đột sẽ quay về.
Một người triển khai Odoo lâu năm gọi thẳng việc sửa chấm công mà lớp công không tự cập nhật là thiếu sót của Odoo, nên nhân sự phải nhớ làm cả hai bước. Hãy dựng lại đúng tình huống này trên bản dự án chạy rồi ghi nó thành một dòng rủi ro trong tài liệu.
Bẫy thứ hai là cách xử lý chỗ trùng giữa ngày nghỉ và chấm công. Cách Odoo diễn giải phần chấm công trùng ngày nghỉ đã từng đổi giữa các phiên bản, có bản hiểu nó thành tăng ca, nên trước khi dựa vào hành vi này bạn phải kiểm trên đúng phiên bản dự án chạy.
Nếu hệ thống hiểu chỗ trùng là tăng ca thì trường hợp đi làm ngày lễ được giải quyết, nhưng một lần nhập nhầm tệp chấm công cũng tự biến thành tiền tăng ca nếu không ai rà lại. Vì vậy hãy đưa bước rà dữ liệu công trước khi tạo đợt lương vào quy trình vận hành, kèm người chịu trách nhiệm ký xác nhận.
Một hệ payroll tự dựng là một tài sản phải nuôi.
Quy định thay đổi theo năm, như phần trên đã cho thấy, và mỗi lần thay đổi là một lần phải thêm tham số hoặc sửa công thức, kiểm thử lại trên dữ liệu thật của kỳ gần nhất và đối chiếu với bảng tính của kế toán. Đồng thời mỗi lần nâng cấp phiên bản là một lần phải kiểm lại toàn bộ mã của các quy tắc lương.
Chi phí mang vác của customize qua từng lần nâng cấp là chủ đề của bài về nợ kỹ thuật, ở đây chỉ cần nhớ bộ quy tắc lương tự dựng là một hạng mục đúng loại đó.
Phương án thay thế đáng cân nhắc là giữ việc tính lương ở phần mềm nhân sự chuyên dụng, rồi chỉ đẩy kết quả sang ERP dưới dạng bút toán tổng hợp theo kỳ. Bạn mất phần liên thông chi tiết tới từng nhân viên và mất khả năng lấy chi phí nhân công theo từng lệnh sản xuất hay từng dự án, nhưng đổi lại, trách nhiệm cập nhật quy định chuyển sang nhà cung cấp.
Một phương án trung gian là đưa lên Odoo phần chấm công, nghỉ phép và hợp đồng, còn phần tính ra tiền để bên ngoài.
Trước khi trả lời khách, hãy đi qua danh sách dưới đây và ghi vào tài liệu khảo sát.
Theo tôi, nếu doanh nghiệp có người đủ thẩm quyền ký nhận công thức lương, có đội kỹ thuật hoặc đối tác dài hạn, và thật sự cần chi phí nhân công chảy vào giá thành hay vào dự án, thì đưa lương lên Odoo là lựa chọn hợp lý. Ngược lại, nếu không ai nhận trách nhiệm cập nhật quy định và nhu cầu chỉ dừng ở việc trả lương đúng hạn, thì giữ lương ở phần mềm chuyên dụng là lựa chọn ít rủi ro hơn nhiều.
Các con số trong bài là những gì đang áp dụng vào cuối tháng 10/2026. Quy định về lương, bảo hiểm và thuế thu nhập cá nhân tại Việt Nam thay đổi thường xuyên, nên mọi con số phải được tra lại từ văn bản pháp luật gốc tại thời điểm bạn cấu hình hệ thống, không lấy từ bài viết này hay từ bất kỳ tài liệu đào tạo nào.
Cái giá của lựa chọn này, cũng như của mọi hạng mục khác, chỉ hiện ra đầy đủ khi bạn cộng cả phần triển khai lẫn phần nuôi hệ thống trong vài năm, và đó là chủ đề của bài về chi phí thật của một dự án ERP tại Việt Nam.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận