Trên một nhóm cộng đồng Odoo tại Việt Nam gần đây có một câu hỏi ngắn nhưng làm hơn trăm người vào tranh luận: "Odoo bản thân nó dở hay do bên triển khai gà mờ?"
Bối cảnh phía sau câu hỏi đó là một doanh nghiệp đã bỏ ra gần 3 tỷ đồng, chưa kể thời gian và công sức của cả đội, và đến giờ vẫn chưa dùng được một ngày. Phần kế toán đã phải tách ra làm riêng để cứu sổ sách. Phần còn lại vẫn nằm đó.
Câu trả lời trong thread chia làm hai phe rất rõ. Một phe nói Odoo là mã nguồn mở, mạnh, nếu dở thì đã biến mất khỏi thị trường từ lâu — lỗi ở bên triển khai không hiểu nghiệp vụ. Phe kia nói bản thân Odoo có những chỗ làm sai chuẩn kế toán Việt Nam, dev sửa hoài không dứt điểm.
Bài này lập luận rằng cả hai phe đều đang nhìn vào triệu chứng.
ℹ️ Info: Nguồn quan sát: thảo luận công khai trên nhóm cộng đồng Odoo Việt Nam, tháng 8/2026. Bài viết tổng hợp lại các luận điểm, không trích dẫn đích danh và không nêu tên doanh nghiệp hay cá nhân nào. Phần phân tích và số liệu triển khai là kinh nghiệm của Diginno trên dự án Odoo 19 Community.
Câu trả lời ngắn
Nguyên nhân gốc làm một dự án ERP tiêu ba tỷ mà không go-live được thường không phải phần mềm dở, cũng không phải đối tác kém năng lực kỹ thuật. Nó là ranh giới hệ thống bị vẽ sai ngay từ lúc ký hợp đồng: doanh nghiệp cố nhét toàn bộ hoạt động vào một phần mềm duy nhất, rồi tiêu ngân sách custom vào những chỗ không tạo ra tiền, trong khi phần lõi — kế toán và kho — vẫn sai.
Ba tầng nguyên nhân, xếp theo mức độ giết dự án:
- Ranh giới sai — bắt tất cả phòng ban bỏ công cụ đang quen để học một giao diện mới.
- Thứ tự custom sai — làm cái sếp thích trước, cái ra tiền sau.
- Khoảng trống nghiệp vụ kế toán Việt Nam — đây là vấn đề kiến trúc, không phải bug, nên không dev đơn lẻ nào "fix dứt điểm" được.
Ba tầng này cộng lại thì phần mềm nào cũng chết, không riêng Odoo.
Tầng 1: Ranh giới hệ thống — nguyên nhân giết dự án nhanh nhất
Một comment trong thread mô tả rất chính xác một tình huống thực tế: khách mua gói training, nhưng vào việc thì yêu cầu tất cả phòng ban đều phải dùng được hết, không thì không trả tiền.
Đây là cái bẫy phổ biến nhất. Nó nghe hợp lý — đã mua ERP thì phải dùng toàn bộ. Nhưng hệ quả thì thế này:
- Nhân viên bán hàng đang chốt đơn trên Zalo và LarkBase, giờ phải mở Odoo nhập lại.
- Thủ kho đang ghi sổ tay và Excel, giờ phải học một luồng phiếu nhập/xuất mới.
- Quản lý đang duyệt đề nghị thu chi bằng một nút trên điện thoại, giờ phải đăng nhập vào một hệ thống nữa.
Chi phí đào tạo và phản kháng thay đổi là lý do số một làm dự án ERP thất bại — điều này đúng với mọi ERP, không riêng Odoo. Và nó là chi phí ẩn: không nằm trong báo giá, nhưng ăn hết ngân sách qua đường "triển khai kéo dài".
Có một điểm ít người nói ra: càng nhiều người thao tác trực tiếp vào hệ kế toán, rủi ro sai sổ càng cao. Thu hẹp cửa vào không phải là làm dự án nhỏ đi — nó chính là cách giữ sổ sạch.
Cách vẽ ranh giới đúng là tách hai lớp:
| Lớp | Ai dùng | Dùng để làm gì |
|---|---|---|
| Lớp vận hành (LarkSuite, Base, công cụ đang quen) | Toàn công ty | Chat, duyệt đề xuất, đơn hàng, CRM, dashboard cho sếp |
| Lớp sổ sách pháp lý (Odoo) | Chỉ kế toán | Ghi sổ, đối chiếu, khóa kỳ, báo cáo tài chính, tờ khai thuế |
Hai lớp đồng bộ tự động với nhau. Nhân viên không đổi cách làm việc. Kế toán có sổ sạch. Sếp vẫn xem được số đã chốt ngay trong công cụ đang dùng hằng ngày.
Chi tiết cơ chế đồng bộ và vì sao không nên làm kế toán ngay trên LarkBase, xem bài Đang chạy LarkSuite, thêm Odoo có phải bỏ Lark không?
Tầng 2: Thứ tự custom — tiêu tiền vào chỗ không ra tiền
Một bạn làm kế toán trong thread kể một ví dụ đắt giá: công ty có hàng tồn kho, chỉ 5 nhân sự, nhưng bỏ tiền custom tính năng theo dõi giờ làm — trong khi 5 người đó là nhân viên sale đi ngoài, không ngồi văn phòng. Phần kho, thứ quan trọng nhất, thì không tập trung.
Kết quả: tính năng chấm công không ai dùng, mà kho vẫn sai.
Đây là lý do vì sao một comment khác ví Odoo như "súng lục — dễ dùng, nhanh gọn, nhưng cũng rất dễ tự bắn vào chân". Odoo custom được gần như mọi thứ. Chính vì custom được mọi thứ nên nếu không có người giữ thứ tự ưu tiên, ngân sách sẽ chảy về phía ai nói to nhất trong phòng họp, chứ không phải về phía rủi ro tiền lớn nhất.
Thứ tự nên làm, xếp theo mức thiệt hại khi sai:
| Ưu tiên | Hạng mục | Sai thì mất gì |
|---|---|---|
| 1 | Kho và giá vốn | Bán dưới giá vốn, tồn ảo, mất hàng không biết |
| 2 | Công nợ phải thu / phải trả | Mất tiền thật, không đòi được nợ |
| 3 | Sổ sách và báo cáo tài chính theo thông tư | Không nộp được thuế, rủi ro pháp lý khi thanh tra |
| 4 | Quy trình duyệt chi | Chi sai thẩm quyền |
| 5 | Báo cáo quản trị, dashboard | Ra quyết định chậm |
| 6 | Chấm công, KPI, tiện ích nội bộ | Bất tiện, không mất tiền |
Nếu hợp đồng triển khai của bạn đang làm hạng mục 6 trước hạng mục 1, đó là dấu hiệu cảnh báo sớm nhất — và nó xuất hiện từ rất lâu trước khi tiền cạn.
Tầng 3: Odoo gốc không phải phần mềm kế toán Việt Nam
Đây là phần mà phe "Odoo dở" có lý — nhưng họ mô tả sai bản chất vấn đề.
Cũng bạn kế toán đó liệt kê ba thứ rất cụ thể:
- Khoản trả trước khi ghi nhận thì không thể hiện trên bill, muốn xem phải vào sổ chi tiết.
- Từ phiên bản 18–19 trở đi, báo cáo equity không tách vốn chủ sở hữu ra riêng mà trộn chung với lợi nhuận chưa phân phối.
- Liên hệ 4–5 developer ở khắp nơi, có lỗi sửa được một tháng, tháng sau bị lại. Cuối cùng vừa làm trên Odoo vừa làm Excel — một việc làm hai ba lần.
Điểm quan trọng: đây không phải bug. Odoo được xây cho thị trường quốc tế. Nó có sẵn gói bản địa hóa Việt Nam (l10n_vn), nhưng gói đó chỉ làm hai việc: nạp hệ thống tài khoản theo Thông tư 200 và khai báo các loại thuế GTGT cơ bản.
Toàn bộ lớp biểu mẫu pháp lý Việt Nam vốn không có sẵn:
| Cái còn thiếu trên bản gốc | Vì sao doanh nghiệp bắt buộc phải có |
|---|---|
| Báo cáo tài chính đúng mẫu (B01, B02, B03, B09) | Bắt buộc nộp theo biểu mẫu Bộ Tài chính |
| Sổ kế toán đúng mẫu in (Nhật ký chung S03a, Sổ Cái, sổ chi tiết) | Phục vụ lưu trữ, thanh tra, kiểm toán |
| Tài sản cố định và khấu hao theo TT45 | Trích khấu hao đúng quy định |
| Công cụ dụng cụ, chi phí trả trước (TK 242) | Phân bổ dần đúng kỳ |
| Tờ khai thuế GTGT 01/GTGT theo TT80 | Kê khai thuế |
| Kết chuyển lãi lỗ cuối kỳ qua TK 911 | Chốt sổ cuối kỳ |
Khi thiếu cả một lớp như vậy, thuê thêm developer thứ sáu cũng không giải quyết được. Mỗi người sẽ vá một chỗ, theo một cách khác nhau, và vá thẳng vào lõi Odoo. Đó chính là lý do "sửa được một tháng, tháng sau bị lại": Odoo ra phiên bản mới mỗi năm, mỗi lần cập nhật là các bản vá lõi bị ghi đè hoặc xung đột.
Cách xử lý đúng là xếp lớp, không sửa lõi: module bổ sung nằm bên trên phần kế toán có sẵn, không đụng vào mã lõi. Khi Odoo cập nhật, lớp bên dưới thay đổi mà lớp bên trên vẫn còn.
⚠️ Warning: Nếu đối tác triển khai của bạn đang sửa trực tiếp vào mã nguồn lõi Odoo để làm báo cáo Việt Nam, hãy hỏi họ một câu: khi Odoo lên phiên bản kế tiếp thì ai chịu chi phí làm lại? Câu trả lời cho bạn biết bạn đang mua một hệ thống hay đang thuê một khoản nợ kỹ thuật.
Chi tiết bộ biểu mẫu cần xây và nguyên tắc xếp lớp: Odoo không phải phần mềm kế toán Việt Nam — và cách vá đúng
Quy trình – Con người – Phần mềm: tự chấm điểm trước khi ký
Một comment trong thread tóm rất gọn, và đây là khung đánh giá tốt nhất tôi đọc được trong cả thread:
Quy trình đã chuẩn chưa, con người đã đáp ứng được quy trình chưa, rồi mới đến phần mềm. Con người và quy trình chưa chuẩn thì có dát vàng vào cũng không dùng được.
Tự chấm ba trục này trước khi xuống tiền:
| Trục | Câu hỏi kiểm tra | Chưa đạt thì làm gì |
|---|---|---|
| Quy trình | Viết ra được luồng từ đơn hàng đến ghi sổ, ai làm bước nào, ai duyệt không? | Chuẩn hóa quy trình trước, chưa mua phần mềm |
| Con người | Có ai trong công ty hiểu cả nghiệp vụ lẫn hệ thống, đủ sức làm đầu mối với đối tác không? | Chỉ định và đào tạo người này trước |
| Phần mềm | Đã rõ phần nào để ERP làm, phần nào giữ trên công cụ hiện tại chưa? | Vẽ lại ranh giới hai lớp |
Có một gợi ý rất thực tế cũng từ thread đó: thuê một kế toán giỏi, tốt nhất là có nền kiểm toán, vào làm sổ trong 1–3 tháng để hiểu doanh nghiệp vận hành thế nào, rồi mới cho người này làm việc với developer. Khi đó chỉ tập trung xây những cái cần xây — vừa tiết kiệm chi phí, vừa đảm bảo phần cốt lõi được làm đúng ngay từ đầu.
Ngược lại, nếu để developer tự suy diễn nghiệp vụ từ một bản mô tả yêu cầu mơ hồ, kết quả gần như chắc chắn là làm lại.
Tám câu hỏi nên trả lời trước khi ký hợp đồng ERP
Đây là checklist tôi dùng khi tư vấn. Nếu doanh nghiệp không trả lời được quá ba câu, chưa nên ký.
Bước 1: Ai ghi sổ, ai chỉ được tạo nháp?
Nếu câu trả lời là "ai cũng nhập được", sổ sẽ bẩn trong vòng một quý. Chứng từ do hệ thống hoặc nhân viên tạo nên dừng ở trạng thái nháp; chỉ kế toán bấm ghi sổ.
Bước 2: Sau go-live, sếp xem số liệu ở đâu?
Nếu câu trả lời là "đăng nhập vào ERP", khả năng cao sếp sẽ không xem. Số đã chốt nên đổ ngược về nơi ban lãnh đạo đang làm việc hằng ngày.
Bước 3: Doanh nghiệp áp Thông tư 200, 133 hay 99?
Ba chế độ kế toán khác nhau, biểu mẫu khác nhau, tên mẫu sổ in ra cũng khác nhau. TT99 áp dụng từ năm tài chính 2026. Đối tác không hỏi câu này ngay từ đầu là dấu hiệu đáng lo.
Bước 4: Số dư đầu kỳ lấy từ đâu và đối chiếu thế nào?
Phải có kế hoạch nạp số dư từ hệ thống cũ và đối chiếu từng tài khoản với bảng cân đối tài khoản hiện tại. Tài khoản lưỡng tính phải tách được dư Nợ / dư Có theo từng đối tượng.
Bước 5: Ai chịu trách nhiệm khi Bảng cân đối kế toán không cân?
Câu này để lộ ngay đối tác có hiểu kế toán hay chỉ biết cài phần mềm. Hệ thống tốt phải có công cụ tra ngược từ chỉ tiêu trên B01 xuống các tài khoản cấu thành.
Bước 6: Thật sự bao nhiêu người cần tài khoản ERP?
Con số này thường nhỏ hơn nhiều so với dự tính ban đầu. Với mô hình hai lớp, chỉ đội kế toán cần thao tác trực tiếp.
Bước 7: Nếu đối tác triển khai biến mất, ai đọc được dữ liệu?
Kiểm tra: mã nguồn có bàn giao không, dữ liệu xuất ra được không, hệ thống chạy trên hạ tầng của ai. Đây là câu hỏi về rủi ro, không phải về sự nghi ngờ.
Bước 8: Hợp đồng có mốc chạy song song một kỳ không?
Không có mốc này thì không có cách nào biết hệ thống mới đúng hay sai trước khi cắt chuyển. Đây là điều khoản đáng giá nhất trong toàn bộ hợp đồng.
Vậy Odoo hợp với ai, không hợp với ai?
Nói thẳng, để tránh biến bài này thành một bài quảng cáo Odoo:
| Odoo phù hợp khi | Nên cân nhắc lựa chọn khác khi |
|---|---|
| Vừa vận hành (bán hàng, kho, sản xuất) vừa cần kế toán, muốn số liệu liền mạch không nhập tay hai lần | Chỉ cần ghi sổ kế toán, thuê dịch vụ kế toán ngoài, ít giao dịch — phần mềm kế toán đóng gói gọn hơn |
| Nhiều chi nhánh, nhiều pháp nhân, cần tách bạch dữ liệu trong một hệ thống | Một pháp nhân, quy trình đơn giản, không có kho |
| Muốn làm chủ dữ liệu, không bị khóa vào thuê bao | Không có đội kỹ thuật và không muốn phụ thuộc đối tác nào |
| Cần tích hợp sâu với hệ thống khác qua API | Ngành đặc thù cần thuế tiêu thụ đặc biệt, thuế tài nguyên, hoặc giá thành công trình xây dựng chuyên sâu |
Đối chiếu chi tiết với MISA SME theo 24 danh mục, gồm cả những chỗ MISA đang làm tốt hơn: Odoo kế toán vs MISA SME
Còn nếu doanh nghiệp chưa chắc mình đang ở đâu trên bản đồ này, hãy đọc thêm Base.vn, 1Office hay LarkSuite: chọn theo bài toán nào — nguyên tắc chọn nền tảng vận hành cũng áp dụng nguyên vẹn cho ERP.
Cách chúng tôi làm khác
Diginno đang xây một bộ module kế toán Việt Nam trên nền Odoo 19 Community, theo đúng ba nguyên tắc rút ra ở trên:
- Hai lớp, không đập đi lớp nào. LarkSuite giữ vai trò vận hành hằng ngày, Odoo là lớp chốt sổ pháp lý cho kế toán, hai bên đồng bộ tự động hai chiều qua n8n và webhook. Nhân viên không phải học phần mềm mới.
- Xếp lớp, không sửa lõi. Bộ báo cáo tài chính, sổ kế toán, tài sản cố định, tờ khai thuế nằm trên một lớp module riêng đặt trên
l10n_vn. Hỗ trợ ba chế độ TT200, TT133 và TT99. - Chạy song song trước khi cắt chuyển. Nạp danh mục và chứng từ từ hệ cũ, đối chiếu số dư từng tài khoản, chạy song song một kỳ, khi số khớp mới cắt.
Trạng thái trung thực: phần lớn tính năng hiện chạy đúng trên dữ liệu mẫu và đã qua kiểm thử tự động, nhưng chưa đối chiếu với sổ sách thật của từng doanh nghiệp cụ thể — đó là việc quan trọng nhất còn lại, và nó chỉ làm được cùng với kế toán của khách. Phần xuất XML nộp thuế đang chờ đối chiếu XSD chính thức của cơ quan thuế trước khi dùng để nộp thật.
Nếu bạn đang chuẩn bị ký một hợp đồng ERP, hoặc đang mắc kẹt giữa chừng một dự án như trường hợp đầu bài, việc đáng làm trước tiên không phải đổi đối tác — mà là vẽ lại ranh giới hệ thống: cái gì để ERP làm, cái gì giữ nguyên trên công cụ đang chạy, và hai bên nối với nhau ở đâu.
Đặt lịch trao đổi về ranh giới hệ thống — một buổi, không bán license, không báo giá trước khi hiểu quy trình.
Câu hỏi thường gặp
Odoo có thật sự dở không?
Không. Odoo là ERP mã nguồn mở trưởng thành, được hàng triệu người dùng trên thế giới. Nhưng nó được xây cho thị trường quốc tế, nên phần biểu mẫu kế toán pháp lý Việt Nam — báo cáo tài chính theo mẫu, sổ kế toán đúng mẫu in, khấu hao TT45, tờ khai TT80 — không có sẵn và phải xây thêm.
Vì sao dự án ERP tốn tiền tỷ mà vẫn không dùng được?
Ba nguyên nhân phổ biến nhất theo thứ tự: ranh giới hệ thống vẽ sai khiến toàn bộ nhân sự phải đổi cách làm việc và phản kháng; ngân sách custom chảy vào tính năng không tạo giá trị trong khi kho và kế toán vẫn sai; và khoảng trống nghiệp vụ kế toán Việt Nam bị vá lẻ tẻ vào lõi phần mềm nên hỏng lại sau mỗi lần nâng cấp.
Có nên bắt tất cả phòng ban dùng ERP không?
Không nên. Càng nhiều người thao tác trực tiếp vào hệ kế toán thì rủi ro sai sổ càng cao, đồng thời chi phí đào tạo và mức phản kháng thay đổi tăng mạnh. Mô hình an toàn hơn là tách hai lớp: nhân viên tiếp tục làm việc trên công cụ vận hành đang quen, chỉ kế toán thao tác trên ERP, hai lớp đồng bộ tự động.
Nên custom Odoo cái gì trước?
Theo thứ tự thiệt hại khi sai: kho và giá vốn, công nợ, sổ sách và báo cáo tài chính theo thông tư, quy trình duyệt chi, báo cáo quản trị, cuối cùng mới là các tiện ích nội bộ như chấm công hay KPI. Làm ngược thứ tự này là nguyên nhân phổ biến khiến ngân sách cạn trước khi phần lõi chạy đúng.
Làm sao biết đối tác triển khai có hiểu nghiệp vụ kế toán Việt Nam không?
Hỏi ba câu ngay buổi đầu: doanh nghiệp áp Thông tư 200, 133 hay 99; số dư đầu kỳ nạp và đối chiếu thế nào; và khi Bảng cân đối kế toán không cân thì tra ngược từ chỉ tiêu xuống tài khoản bằng cách nào. Đối tác chỉ biết cài phần mềm sẽ trả lời chung chung ở cả ba câu.
Đang dùng LarkSuite, thêm Odoo có phải bỏ Lark không?
Không. Hai hệ thống giải hai bài toán khác nhau: LarkSuite là lớp vận hành và cộng tác cho toàn công ty, Odoo là lớp sổ sách pháp lý cho kế toán. Chúng đồng bộ hai chiều tự động, số liệu đã chốt sổ đổ ngược về dashboard trên Lark cho ban lãnh đạo xem.
Đọc tiếp trong series
- Đang chạy LarkSuite, thêm Odoo có phải bỏ Lark không? Kiến trúc hai lớp
- Odoo không phải phần mềm kế toán Việt Nam — và cách vá đúng
- Odoo Community hay Enterprise: bóc chi phí thật
- Odoo kế toán vs MISA SME: đối chiếu 24 danh mục
- Chuyển từ MISA sang Odoo: lộ trình 6 bước và chỗ dễ vỡ nhất
- Giá thành theo từng lệnh sản xuất: biết lô nào lời, lô nào lỗ
Nguồn tham khảo
- Odoo Editions — phân biệt Community và Enterprise: https://www.odoo.com/page/editions
- Odoo Pricing: https://www.odoo.com/pricing
- Odoo Community source license LGPLv3: https://github.com/odoo/odoo/blob/19.0/LICENSE
- Thảo luận công khai nhóm cộng đồng Odoo Việt Nam, tháng 8/2026 (tổng hợp luận điểm, không trích dẫn đích danh)
Bài viết hữu ích?
Chia sẻ để nhiều người biết đến!
>_ LLM-Friendly Copy
Copy as Markdown to use with ChatGPT, Claude, or other AI tools
