Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Gói địa phương hóa Việt Nam của Odoo 19 gồm ba module. Kiểm kê thật cái gói nạp sẵn, cái dự án phải cấu hình thêm và cái buộc phải tích hợp hoặc lập trình.
Buổi presale nào với một doanh nghiệp Việt Nam cũng có một câu hỏi được hỏi gần như nguyên văn giống nhau, thường do người phụ trách hệ thống thông tin hỏi thay cho phòng kế toán ngồi ngay cạnh: Odoo có hỗ trợ Việt Nam không em.
Chỗ hỏng lộ ra muộn, và lộ ra ở đúng chỗ đau nhất. Tới buổi UAT, kế toán trưởng mở menu báo cáo tìm báo cáo tình hình tài chính theo mẫu vẫn nộp hằng năm và không thấy, hỏi tiếp mẫu phiếu thu phiếu chi in nhanh cũng không thấy, trong khi lại bất ngờ thấy dòng số tiền bằng chữ đã nằm sẵn dưới hóa đơn mà chẳng ai từng đưa vào phạm vi.
Ở thời điểm đó phạm vi đã chốt, lịch đã cam kết, và người phải ngồi giải trình là bạn chứ không phải người đã trả lời có ở buổi đầu.
Cách duy nhất tôi biết để không rơi vào cảnh đó là đếm xem gói địa phương hóa thật sự nạp cái gì vào database của đúng phiên bản sắp triển khai, đếm một lần trong kho mã nguồn Community và đếm lại lần nữa trên một bản cài thật.
Bài này là kết quả của một lần đếm như vậy trên Odoo 19, xếp thành ba nhóm để bạn dùng được khi ước lượng phần Việt Nam của một dự án. 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ớ.
Trên Odoo 19 có đúng ba module mang tiền tố l10n_vn, không hơn.
l10n_vn, tên hiển thị Vietnam - Accounting, tác giả ghi là General Solutions, phần ghi công nhắc thêm Trobz và Jean Nguyen từ The Bean Family cho phần VietQR.l10n_vn_edi_viettel, tên hiển thị Vietnam - E-invoicing, do chính Odoo S.A. viết.l10n_vn_edi_viettel_pos, phần mở rộng của module thứ hai cho phân hệ bán lẻ tại quầy.Cả ba đều mang giấy phép LGPL-3, nghĩa là chúng dùng được trên cả bản Community lẫn bản Enterprise; chuyện chọn bản nào tôi đã nói ở bài khác.
Cần lưu ý chuyện module nào tự vào và module nào phải cài tay. Module l10n_vn tự cài theo module kế toán khi công ty đặt ở Việt Nam, module cho bán lẻ cũng được khai tự cài, còn module hóa đơn điện tử thì không, trong khi tài liệu chính thức của Odoo 19 lại ghi rằng cả l10n_vn lẫn l10n_vn_edi_viettel đều được cài tự động.
Hai nguồn nói khác nhau thì bạn tin database của dự án, tức mở danh sách module ra xem cái nào đã cài, bởi nó ảnh hưởng tới kịch bản dựng môi trường và việc phải làm trong ngày go-live.
Trước khi đọc danh sách này, có một cái bẫy ngay từ bước cài mà vấp phải thì mọi con số dưới đây đều lệch.
Nếu bạn cài l10n_vn lên một database mà công ty vẫn đang để quốc gia mặc định, Odoo không kéo hệ thống tài khoản Việt Nam về mà lặng lẽ nạp biểu đồ tài khoản chung, và thứ bạn nhận được chỉ là năm mươi mốt tài khoản, không có nhóm tài khoản nào và vỏn vẹn hai nhóm thuế.
Vì vậy phải đặt quốc gia của công ty là Việt Nam trước rồi mới nạp gói. Nếu bạn đọc ở đâu đó một con số quanh mức năm mươi tài khoản thì nhiều khả năng người đếm đã rơi vào đúng tình huống này.
Thứ nặng ký nhất mà l10n_vn nạp vào là hệ thống tài khoản. Trên bản cài thật với quốc gia đặt đúng, database ra đúng số dòng của file tài khoản và file nhóm tài khoản, hiện là hai trăm mười tám tài khoản và một trăm lẻ sáu nhóm. Tôi nói hiện là vì con số này đổi ngay trong cùng phiên bản: cuối tháng tám tôi đếm được hai trăm mười sáu, và hai tài khoản chênh lệch là hai tài khoản về bán và thanh lý bất động sản đầu tư được bổ sung sau đó.
Các file có cột tên tiếng Việt bên cạnh tên tiếng Anh, nhưng tên tiếng Việt chỉ hiện khi database đã cài tiếng Việt và người dùng đang dùng tiếng Việt; với database để tiếng Anh thì danh sách mở ra là Cash, Demand Deposit, Money in transit, nên đừng hứa với kế toán trưởng rằng danh mục sẽ sẵn tiếng Việt ngay lần đầu mở lên.
Phần mô tả của module vẫn ghi rằng hệ thống tài khoản theo Thông tư 200/2014/TT-BTC, và đây là câu bạn không được chép nguyên vào tài liệu dự án. Thông tư 99/2025/TT-BTC do Bộ Tài chính ban hành ngày 27/10/2025 đã thay thế Thông tư 200 cho các năm tài chính bắt đầu từ ngày 01/01/2026, nên với một dự án go-live hôm nay thì căn cứ của hệ thống tài khoản là Thông tư 99.
Điều đáng chú ý là chính file dữ liệu đã mang những tài khoản chỉ có ở Thông tư 99, như 215 tài sản sinh học, 332 phải trả cổ tức và lợi nhuận, 82112 chi phí thuế thu nhập doanh nghiệp bổ sung theo quy định về thuế tối thiểu toàn cầu, hay tài khoản 112 mang tên tiền gửi không kỳ hạn; nghĩa là dữ liệu đã được cập nhật theo văn bản mới ít nhất ở những điểm này, còn dòng mô tả thì chưa.
Tôi chưa so từng tài khoản với hệ thống tài khoản ban hành kèm Thông tư 99, nên việc đó vẫn phải để kế toán trưởng làm trước khi chốt; còn cách cấu hình khung tài khoản cho khớp sổ sách đang chạy là một chủ đề riêng.
Tiếp theo là thuế. File thuế có sáu mươi dòng nhưng chỉ sinh ra mười lăm sắc thuế, bởi mỗi sắc thuế chiếm nhiều dòng để mô tả cách phân bổ vào tài khoản. Mười lăm sắc thuế đó chia thành năm thuế đầu ra và mười thuế đầu vào, gồm thuế giá trị gia tăng đầu ra và đầu vào ở các mức 0%, 5%, 8%, 10% cùng nhóm không thuộc đối tượng chịu thuế, cộng bốn sắc thuế giá trị gia tăng cho hàng nhập khẩu và một sắc thuế nhập khẩu, đi kèm sáu nhóm thuế.
Đây là các mức gói nạp sẵn chứ không phải phát biểu về thuế suất đang có hiệu lực; chẳng hạn mức 8% là mức giảm có thời hạn, theo Nghị quyết 204/2025/QH15 thì áp dụng tới hết ngày 31/12/2026, nên dùng nó tới khi nào là câu phải hỏi lại kế toán lúc go-live. Module còn kèm một bước nâng cấp riêng chỉ để nạp lại nhóm thuế và sắc thuế cho các database đã cài từ trước, dấu hiệu cho thấy phần thuế là phần bị sửa nhiều nhất qua các phiên bản.
Bên cạnh hai khối trên, gói còn nạp một định nghĩa báo cáo thuế gồm một bản ghi báo cáo, hai cột và hai mươi dòng, tách theo mua vào, mua nhập khẩu, thuế nhập khẩu và bán ra. Đây là định nghĩa báo cáo chứ không phải màn hình xem báo cáo, và tôi quay lại chỗ này ở nhóm thứ hai.
Phần còn lại nhỏ hơn nhưng vẫn đáng liệt kê.
Nhóm này là chỗ một BA thiếu kinh nghiệm hay tính bằng không, bởi nhìn từ ngoài thì thứ gì đã có trong gói cũng có vẻ dùng được ngay.
Bắt đầu bằng đồng tiền. Trong dữ liệu gốc của Odoo, đồng Việt Nam được khai với mức làm tròn bằng 1 nhưng mặc định chưa được bật, nghĩa là đồng tiền của chính thị trường bạn đang triển khai vẫn nằm ở trạng thái tắt, và ai đó trong dự án phải bật nó rồi kiểm tra lại các chỗ hiển thị số tiền. Đây là việc mất năm phút nếu biết trước và mất nửa ngày truy vết nếu phát hiện muộn.
Tiếp theo là VietQR, thứ nghe qua tưởng chỉ cần bật một công tắc. Trên Odoo 19, hệ thống chỉ sinh mã cho một tài khoản ngân hàng ở Việt Nam khi tài khoản đó:
Đồng thời giao dịch phải ghi bằng đồng Việt Nam, còn với hóa đơn ngoại tệ thì hệ thống báo lỗi chứ không âm thầm bỏ qua. Việc phải làm trong dự án vì thế là chuẩn hóa thông tin tài khoản ngân hàng nhận tiền ngay từ đầu, chứ không phải chờ tới lúc gửi hóa đơn đầu tiên mới phát hiện thiếu trường.
Chỗ thứ ba là danh mục ngân hàng, và đây là khoảng cách rõ nhất giữa lời mô tả và dữ liệu thật. Phần mô tả của l10n_vn nói rằng module bổ sung thông tin ngân hàng Việt Nam như tên và mã định danh theo công bố của Ngân hàng Nhà nước, nhưng module không có file dữ liệu ngân hàng nào, trong khi gói của UAE, Chile hay Ecuador đều có, và đếm trên bản cài thật cũng ra đúng con số không.
Nghĩa là danh mục ngân hàng vẫn là việc doanh nghiệp phải tự nhập, và bạn nên đưa nó vào danh sách master data ngay từ giai đoạn khảo sát.
Chỗ thứ tư là báo cáo thuế. Định nghĩa báo cáo có nằm trong gói, nhưng trên bản Community thì menu Reporting của phân hệ kế toán chỉ có các mục như Partner Reports, Taxes & Fiscal hay Statement Reports mà không gắn màn hình nào, còn module hiển thị báo cáo kế toán là account_reports thì không có trong kho Community. Do đó muốn xem báo cáo thuế này trên màn hình thì bạn phải tính tới bản Enterprise hoặc một giải pháp khác, và cách xử lý cụ thể thuộc bài về cấu hình kế toán.
Cuối cùng là hai thứ nhỏ hay bị nhầm với nhau. Odoo có sẵn ngôn ngữ tiếng Việt, nhưng dịch giao diện và địa phương hóa nghiệp vụ là hai việc hoàn toàn khác nhau, và việt hóa giao diện có bài riêng của nó.
Bên cạnh đó, dữ liệu tỉnh thành Việt Nam trên Odoo 19 hiện có ba mươi tư bản ghi, khớp với số đơn vị hành chính cấp tỉnh sau đợt sắp xếp năm 2025, dù vài tên vẫn là tên cũ như Thừa Thiên - Huế. Nếu phần mềm doanh nghiệp đang chạy còn giữ danh mục sáu mươi ba tỉnh thành cũ thì bạn phải dựng bảng ánh xạ trước khi nạp dữ liệu khách hàng và nhà cung cấp.
Nhóm này là phần bạn phải nói ra ở presale, bởi nó là phần tốn tiền và tốn người.
Về hóa đơn điện tử, gói có một module tích hợp sẵn với dịch vụ SInvoice của Viettel do chính Odoo S.A. viết, kèm một module mở rộng cho bán lẻ tại quầy, và trong ba module Việt Nam thì đó là nhà cung cấp duy nhất. Doanh nghiệp đang dùng nhà cung cấp khác thì phần kết nối là một hạng mục tích hợp thật sự; còn chuyện chọn nhà cung cấp, kiến trúc tích hợp và cách xử lý hóa đơn thay thế hay điều chỉnh là chủ đề của bài kế tiếp.
Về tiền lương, phân hệ Payroll thuộc bản Enterprise, và danh sách quốc gia có gói tiền lương địa phương trong tài liệu chính thức của Odoo 19 không có Việt Nam. Mức độ khả thi của việc chạy lương Việt Nam trên Odoo là một bài riêng.
Về báo cáo tài chính theo mẫu Việt Nam, l10n_vn chỉ có định nghĩa báo cáo thuế và không có định nghĩa báo cáo tài chính nào, nên bộ báo cáo theo chế độ kế toán hiện hành, với báo cáo tình hình tài chính thay cho tên gọi bảng cân đối kế toán quen thuộc, không có sẵn trong gói.
Module cũng không có mẫu in chứng từ nào, nghĩa là phiếu thu phiếu chi kiểu Việt Nam không nằm trong gói; và từ Thông tư 99 doanh nghiệp được tự thiết kế mẫu chứng từ, nên mẫu in là thứ bạn phải xin từ khách chứ không lấy từ đâu ra sẵn. Hai khoản này thường là hai dòng GAP đầu tiên của một dự án Việt Nam.
Và một chỗ nữa cần nói thẳng ngay từ buổi đầu, dù nó thuộc bài khác: hóa đơn trong Odoo là chứng từ kế toán nội bộ, không phải hóa đơn có mã của cơ quan thuế.
Từ ba nhóm trên, việc cần làm ở presale không phải là trả lời có hay không, mà là dựng một bảng ba cột ứng với ba nhóm, trước khi ai kịp hứa gì.
Checklist kiểm kê trước khi cam kết:
l10n_vnNguyên tắc tôi vẫn giữ khi làm việc này là chỉ ghi vào cột có sẵn những gì thấy được trong file dữ liệu hoặc trên bản cài thật, còn thứ chỉ nghe nói hoặc chỉ thấy trong phần mô tả thì ghi vào cột cần kiểm tra.
Phần mô tả của l10n_vn là ví dụ rõ nhất, bởi nó vừa nói tới danh mục ngân hàng không hề tồn tại, vừa dẫn một thông tư đã hết hiệu lực; nếu bạn đọc mô tả rồi hứa luôn thì tới lúc dựng dữ liệu bạn sẽ tự trả tiền cho lời hứa đó.
Bảng này chỉ có giá trị nếu bạn biết nó dựa trên cái gì, nên tôi nói rõ mấy chỗ nó không trả lời được.
l10n_vn và l10n_vn_edi_viettel, nhưng tôi không có mã nguồn bản Enterprise để khẳng định bản thuê bao không bổ sung gì thêm.Do đó trước mỗi dự án bạn nên đếm lại thay vì tin bảng kiểm kê của người khác, kể cả bảng này.
Khi bảng ba cột đã dựng xong, dòng nặng nhất trong cột thứ ba gần như luôn là hóa đơn điện tử, và đó là chỗ đáng đọc tiếp.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận