Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Invoice trong Odoo là chứng từ kế toán nội bộ, hóa đơn đỏ là chứng từ pháp lý ra bên ngoài. Ba kiểu quan hệ giữa hai thứ và câu hỏi cho kế toán trưởng.
Buổi khảo sát nào ở 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 rơi vào cuối buổi khi mọi người đã mỏi, và người hỏi gần như luôn là kế toán trưởng: Odoo xuất được hóa đơn đỏ không em.
Nếu bạn nói được, thì tới buổi UAT kế toán bấm nút vào sổ hóa đơn và không thấy tờ hóa đơn nào được phát hành ra ngoài cả. Nếu bạn nói không được, doanh nghiệp giữ nguyên cách làm cũ ở một phần mềm khác, và tới lúc go-live bạn có hai nơi cùng ghi nhận doanh thu mà không ai từng thiết kế đường nối giữa chúng.
Câu trả lời đúng không phải có hay không, mà là một chuỗi phân biệt.
Theo tôi đây là hiểu lầm đắt nhất trong các dự án Odoo tại Việt Nam, và cái làm nó đắt là thời điểm nó lộ ra, thường là sau khi phạm vi đã chốt và lịch đã cam kết. 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ớ.
Hai thứ cùng mang chữ hóa đơn, nhưng một thứ là sổ sách nội bộ còn thứ kia là chứng từ ra bên ngoài.
Invoice trong Odoo là một chứng từ kế toán nội bộ. Nó ghi nhận doanh nghiệp đã phát sinh doanh thu với đối tác nào, số tiền bao nhiêu, thuế suất nào, hạn thanh toán ngày nào, và từ đó doanh nghiệp theo dõi được khoản phải thu.
Trên Odoo 19, chứng từ đi từ nháp sang vào sổ, còn chuyện khách đã trả tiền hay chưa nằm ở một trạng thái thanh toán riêng. Chỉ khi được vào sổ thì công nợ mới thực sự được ghi nhận, và ngay cả hóa đơn đã vào sổ cũng đưa về nháp được bằng nút Reset to Draft nếu không vướng khóa sổ; chính sự mềm dẻo đó là thứ hóa đơn pháp lý không có.
Hóa đơn đỏ là cách gọi quen miệng từ thời hóa đơn giấy, còn thứ doanh nghiệp dùng hôm nay là hóa đơn điện tử, có mã hoặc không có mã của cơ quan thuế tùy đối tượng, và nó là một chứng từ pháp lý. Nó thường được lập qua một tổ chức cung cấp dịch vụ hóa đơn điện tử, mang ký hiệu mẫu số và ký hiệu hóa đơn, được ký số.
Sau khi phát hành, nó nằm ở nơi cơ sở dữ liệu Odoo của bạn không kiểm soát: người mua tra cứu được, cơ quan thuế nhìn thấy, và việc xử lý sai sót đi theo thủ tục riêng chứ không phải bấm sửa một bản ghi.
Phần kết nối kỹ thuật giữa hai bên là khối lượng của một dự án con và có bài riêng. Ở đây chỉ cần nhớ rằng bản Community của Odoo 19 đã có sẵn module l10n_vn_edi_viettel do chính Odoo S.A. viết để tích hợp với SInvoice của Viettel, nhưng ngay cả khi dùng nó thì hóa đơn pháp lý vẫn sinh ra ở phía Viettel, còn với mọi nhà cung cấp khác thì phần tích hợp phải được tính vào phạm vi ngay từ đầu.
Đây là phần mà phần lớn tài liệu dự án bỏ qua, và cũng là phần đẻ ra nhiều tranh cãi nhất sau go-live.
Phía Odoo, thời điểm lập hóa đơn phụ thuộc vào chính sách lập hóa đơn cấu hình ở cấp sản phẩm, với hai lựa chọn là theo số lượng đã đặt hoặc theo số lượng đã giao, và hệ quả của lựa chọn đó tôi đã nói ở bài phân biệt ERP với phần mềm kế toán. Đồng thời, quan hệ giữa đơn và hóa đơn vốn đã không phải một đổi một, như bài về dòng chảy dữ liệu đã nói.
Phía pháp lý, khung quy định vừa đổi. Từ ngày 01/07/2026, văn bản chính về hóa đơn, chứng từ là Nghị định 254/2026/NĐ-CP, thay thế cả Nghị định 123/2020/NĐ-CP lẫn Nghị định 70/2025/NĐ-CP, cùng Thông tư 91/2026/TT-BTC hướng dẫn đi kèm, nên tài liệu nào còn dẫn các văn bản cũ thì phải sửa trước tiên.
Theo cách tôi đọc, các mốc chính vẫn giữ tinh thần cũ:
Tuy nhiên, việc của bạn không phải kết luận doanh nghiệp phải làm gì theo luật, và người xác nhận cách hiểu văn bản phải là kế toán trưởng chứ không phải bạn. Việc của bạn là trả lời câu hỏi sự kiện nào trong Odoo tương ứng với sự kiện mà quy định mô tả, xác nhận phiếu giao hàng, ký biên bản nghiệm thu, hay chốt sản lượng cuối kỳ. Trả lời được câu đó thì bạn biết phải gắn cơ chế phát hành vào chỗ nào trong luồng, còn không thì mọi phương án tích hợp phía sau chỉ là đoán.
Hai thời điểm lệch nhau là chuyện bình thường, không phải lỗi. Một hợp đồng triển khai phần mềm trả trước ba mươi phần trăm khi ký có ngay một hóa đơn trả trước trong Odoo dù phần dịch vụ mới chỉ bắt đầu, qua một nút ít người để ý: khi đơn đang ở trạng thái không có gì để xuất hóa đơn, màn hình vẫn còn một nút Create Invoice thứ hai bấm được, mở trình hướng dẫn tạm ứng và sinh ra một hóa đơn tạm ứng một dòng.
Phía pháp lý thì nếu khoản đó là tiền thu trước của dịch vụ, hóa đơn phải lập ngay lúc thu, còn nếu là tiền đặt cọc bảo đảm thực hiện hợp đồng thì chưa phải lập, và hóa đơn tạm ứng trong Odoo không phân biệt được hai thứ đó. Cái sai không nằm ở chỗ lệch, mà ở chỗ không ai ghi lại rằng chúng lệch và lệch theo quy tắc nào.
Theo tôi, mối quan hệ này thực tế chỉ có ba hình dạng. Chọn hình dạng nào là quyết định thiết kế phải chốt ở giai đoạn khảo sát và ghi vào tài liệu, không phải một ô cấu hình bật lên là xong.
Mỗi hóa đơn được vào sổ trong Odoo tương ứng với đúng một hóa đơn pháp lý được phát hành, và thao tác phát hành được gắn ngay vào màn hình hóa đơn để kế toán chỉ làm việc ở một nơi; module SInvoice đi đúng theo kiểu này.
Cách này gọn nhất, nhưng nó chỉ chạy được khi chính sách lập hóa đơn trong Odoo đã khớp với sự kiện mà quy định gắn vào, nếu không thì kế toán sẽ tự chế ra một quy trình ngầm để chữa và bạn mất khả năng kiểm soát.
Thứ bắt buộc phải đặc tả ở đây là trạng thái trung gian, bởi một hóa đơn đã vào sổ nhưng chưa phát hành được ra ngoài là trạng thái có thật. Module của Viettel có hẳn một trường SInvoice Status với giá trị Ready to send cho trường hợp này, và khi hóa đơn đã gửi đi thì nút Reset to Draft biến mất, muốn hủy phải đi qua yêu cầu hủy.
Với nhà cung cấp khác thì bạn phải tự thiết kế trạng thái đó, bởi thiếu nó thì hóa đơn chưa phát hành trông y hệt hóa đơn đã phát hành, và cuối ngày không ai biết còn bao nhiêu chứng từ đang treo.
Nhiều nghiệp vụ trong kỳ của cùng một khách được gộp thành một hóa đơn pháp lý, trong khi bên trong Odoo vẫn có nhiều chứng từ nội bộ theo từng lần để theo dõi công nợ và đối chiếu sản lượng. Cái giá phải trả là quan hệ giữa hai bên trở thành nhiều đổi một, nên mọi báo cáo phải nói rõ mình đang đếm theo chứng từ nào.
Cần lưu ý rằng kiểu này đụng thẳng vào quy định về thời điểm, bởi hàng hóa giao nhiều lần thì mỗi lần giao phải có hóa đơn tương ứng. Kiểu gộp chỉ đứng vững ở những trường hợp quy định cho phép lập theo kỳ, chẳng hạn một số loại dịch vụ phải đối soát dữ liệu giữa hai bên rồi mới chốt được số tiền, nên doanh nghiệp đang gộp hóa đơn hàng hóa theo tháng là câu hỏi cho kế toán trưởng trước khi là câu hỏi thiết kế.
Khi đã được xác nhận, hai thứ phải đặc tả là quy tắc gộp, tức theo khách hàng hay theo hợp đồng, theo tháng hay theo chu kỳ đối soát, và nơi lưu số hóa đơn pháp lý cùng cách nó trỏ ngược về các chứng từ nội bộ đã gộp vào, bởi khi khách hỏi về một tờ hóa đơn thì kế toán phải tìm ra ngay những nghiệp vụ nằm trong đó.
Kế toán phát hành hóa đơn trên cổng của nhà cung cấp dịch vụ hoặc trên phần mềm kế toán đang dùng sẵn, sau đó số hóa đơn được ghi ngược trở lại Odoo bằng tay hoặc bằng một lần nạp dữ liệu định kỳ. Người triển khai hay coi thường phương án này, nhưng nó hợp lý khi công cụ kế toán đang dùng không nằm trong phạm vi thay thế, hoặc khi dự án cần go-live gấp mà phần tích hợp chưa kịp làm.
Rủi ro là cùng một nghiệp vụ được nhập ở hai nơi, nên điều phải chốt bằng văn bản là hệ thống nào giữ vai trò nguồn sự thật, ai ghi ngược số hóa đơn về Odoo, ai chạy đối soát định kỳ và xử lý chênh lệch ra sao. Nếu ba câu đó chưa có câu trả lời kèm tên người, thì đây không phải một phương án thiết kế mà chỉ là việc hoãn vấn đề lại.
Luồng thuận thì còn dễ, luồng ngược mới là chỗ lộ ra rằng hai chứng từ này khác nhau về bản chất.
Khi khách trả hàng, kho tạo phiếu nhập ngược từ chính phiếu giao gốc, còn phía kế toán trên Odoo 19 có hai đường cho ra hai kết quả khác nhau. Đường quen thuộc nhất là mở hóa đơn đã vào sổ rồi bấm Credit Note, và điều làm người dùng ngạc nhiên là giấy báo có sinh ra theo đường này chép lại hóa đơn gốc chứ không điền số lượng khách trả, bởi nó không nối gì tới phiếu trả hàng bên kho.
Một đơn hàng có thể có nhiều phiếu giao và nhiều hóa đơn, nên hệ thống không biết chắc số lượng trả thuộc về hóa đơn nào, và kế toán phải tự sửa tay. Đây là thiết kế, không phải thiếu sót của bản cài đặt.
Đường thứ hai chỉ có với sản phẩm lập hóa đơn theo số lượng đã giao: phiếu trả hàng mặc định cập nhật ngược số lượng về đơn, nên số đã giao giảm xuống, và bấm tạo hóa đơn từ đơn thì hệ thống sinh ra giấy báo có đúng phần khách trả. Do đó tài liệu đặc tả phải chốt dùng đường nào cho loại sản phẩm nào, nếu không thì cùng một nghiệp vụ trả hàng sẽ được hai kế toán xử lý theo hai cách.
Phía pháp lý thì đường ngược lại còn khác nữa. Hóa đơn đã phát hành mà sai hoặc phải giảm trừ thì xử lý bằng hóa đơn điều chỉnh hoặc hóa đơn thay thế, và với người mua là doanh nghiệp thì hai bên thường phải có văn bản thỏa thuận ghi rõ sai sót trước khi điều chỉnh; chi tiết cho từng trường hợp thì kế toán trưởng xác nhận theo văn bản hiện hành.
Module SInvoice phản ánh đúng chỗ này, bởi khi tạo giấy báo có cho một hóa đơn đã gửi đi, trình hướng dẫn hỏi thêm loại điều chỉnh cùng tên và ngày của văn bản thỏa thuận. Nghĩa là một thao tác vài giây trong Odoo tương ứng với một thủ tục có khách hàng tham gia ở bên ngoài hệ thống, nên bạn phải mô tả rõ ai khởi tạo trước, và trạng thái nào trên hệ thống thể hiện thủ tục bên ngoài đã hoàn tất.
Những gì viết ở trên chỉ có giá trị nếu bạn hỏi được đúng người, và người đó là kế toán trưởng chứ không phải người dùng ở phòng kinh doanh.
Đặc biệt, có hai câu nên để dành tới cuối vì chúng hay làm lộ ra nghiệp vụ mà không ai kể trong buổi khảo sát. Câu thứ nhất là báo cáo nào đang lấy số từ hóa đơn pháp lý, báo cáo nào lấy từ sổ nội bộ, và khi hai con số lệch thì ai giải trình.
Câu thứ hai là có nghiệp vụ nào phát hành hóa đơn mà không đi qua đơn bán hàng hay không, chẳng hạn bán lẻ tại quầy hoặc phí phát sinh; nếu có thì bạn vừa tìm ra một luồng nằm ngoài năm chặng của đơn hàng mà tôi đã mô tả ở bài về dòng chảy dữ liệu, và luồng đó phải được thiết kế riêng.
Trước khi rời buổi làm việc với kế toán, hãy chốt xong đúng những việc sau:
Có ba chỗ bài này không giải quyết được cho bạn.
Đầu tiên, tôi không phải người tư vấn thuế và bài này không phải tư vấn pháp lý; mọi mốc thời gian và cách hiểu quy định phải được đối chiếu với văn bản hiện hành rồi được chính bộ phận kế toán xác nhận, còn việc của bạn là thiết kế hệ thống chạy đúng theo cách hiểu đó.
Tiếp theo, quy định về hóa đơn điện tử thay đổi nhanh hơn mọi tài liệu nội bộ, và nhanh hơn cả phần mềm: chỉ trong hơn một năm đã có hai lần đổi văn bản, trong khi module SInvoice trên Odoo 19 được viết từ trước lần đổi thứ hai, nên những luồng như yêu cầu hủy hay điều chỉnh phải được đối chiếu lại với nhà cung cấp và với kế toán. Tài liệu đặc tả có nhắc tới quy định thì phải ghi rõ văn bản nào và ngày đối chiếu ngay trong tài liệu.
Cuối cùng là giới hạn của chính hệ thống. Hóa đơn của Odoo không được sinh ra để làm chứng từ pháp lý của một quốc gia cụ thể, có module tích hợp thì chứng từ pháp lý vẫn sinh ra ở phía nhà cung cấp, và sẽ không có phiên bản nào biến hóa đơn nội bộ thành hóa đơn đỏ chỉ bằng một ô cấu hình.
Thứ bạn thiết kế được là quan hệ giữa hai chứng từ, còn thứ bạn phải chấp nhận là chúng vĩnh viễn là hai chứng từ.
Điều đó dẫn thẳng tới một câu hỏi rộng hơn mà mọi dự án Odoo tại Việt Nam đều phải trả lời, đó là bộ localization Việt Nam của Odoo thực sự có sẵn những gì và còn thiếu những gì.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận