Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Hai mô hình tích hợp hóa đơn điện tử với ERP theo chiều dữ liệu, trường phải khớp giữa hai hệ thống, và các tình huống hủy - thay thế - điều chỉnh.
Trong bảng phạm vi của một dự án Odoo tại Việt Nam, hạng mục hóa đơn điện tử gần như luôn xuất hiện dưới dạng đúng một dòng, và được ước lượng bằng một con số ngày công nhỏ tới mức không ai buồn tranh luận.
Tới buổi cấu hình thật thì dòng đó nở ra. Đội dự án phát hiện:
Đây là mẫu hình lặp lại ở mọi hạng mục tích hợp tôi từng làm, tức là cái tên nghe như một công tắc còn khối lượng thật nằm ở thủ tục và dữ liệu phía sau nó.
Cần chốt trước một phân biệt: hóa đơn trong Odoo là chứng từ kế toán nội bộ, còn hóa đơn điện tử là chứng từ pháp lý phát hành ra bên ngoài, và quan hệ giữa hai chứng từ đó thuộc về một bài riêng.
Ở đây tôi chỉ nói phần kỹ thuật của đường nối, gồm dữ liệu nào đi qua, đi theo chiều nào, hỏng thì ai sửa, và cuối tháng lấy gì đi đối soát. 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ớ.
Có nhiều cách chia, và tôi chọn cách chia theo nơi dữ liệu được khởi tạo.
Ba kiểu thiết kế quan hệ giữa hóa đơn nội bộ và hóa đơn pháp lý, tức một hóa đơn ứng với một lần giao, một đơn hay một kỳ, thuộc về bài riêng. Trục ở đây là nơi dữ liệu sinh ra và chiều nó di chuyển, bởi nó quyết định ai thao tác hằng ngày và cuối kỳ bạn cầm cái gì đi đối chiếu.
Người dùng bấm phát hành ngay trên chứng từ trong ERP, hệ thống dựng gói dữ liệu rồi gọi sang dịch vụ của nhà cung cấp và nhận về số hóa đơn, mã tra cứu, ngày phát hành cùng các tệp.
Trên Odoo 19 có sẵn một bản triển khai đúng mô hình này, là module l10n_vn_edi_viettel do chính Odoo S.A. viết, nối với dịch vụ SInvoice của Viettel. Module này đáng đọc kỹ vì mọi phương án nối với nhà cung cấp khác đều phải giải đúng những bài toán nó đã giải.
Kế toán chỉ thao tác một nơi, nhìn danh sách chứng từ là biết còn bao nhiêu cái chưa ra được, và đối soát gần như miễn phí vì hai bên dùng chung một bản ghi gốc; đổi lại, mọi khiếm khuyết của master data đều dội thẳng vào kế toán đúng lúc họ cần phát hành và đang chịu áp lực nhất.
Kế toán phát hành hóa đơn ngoài ERP, trên cổng của nhà cung cấp như đã quen, rồi số hóa đơn cùng ký hiệu và ngày phát hành phải được đưa ngược vào chứng từ nội bộ, bằng một lần nạp tệp định kỳ, một kết nối đọc dữ liệu theo lịch, hoặc đơn giản là gõ tay.
Cách này hay bị coi là bước lùi, nhưng nó hợp lý khi kế toán đang phát hành cho nhiều pháp nhân trên cùng một cổng, khi số hóa đơn mỗi tháng nhỏ tới mức chi phí tích hợp không đáng, hoặc khi cần một phương án tạm sau go-live.
Nếu ghi ngược tự động thì cái giá nằm ở khâu đối soát, và khâu đó rẻ hay đắt tùy vào việc hai hệ thống có khóa chung hay không: có khóa thì đó là phép nối máy móc, không có thì phải khớp tay theo mã số thuế, ngày và số tiền, mà ba tiêu chí đó trùng nhau ở nhiều dòng hơn bạn tưởng.
Còn nếu gõ tay thì hãy đặt ngày kết thúc cho phương án tạm, bởi phương án tạm không có hạn sẽ thành thiết kế vĩnh viễn; ràng buộc tối thiểu khi đó là chống trùng trên số hóa đơn và không cho đóng kỳ khi còn chứng từ chưa điền.
Cần lưu ý rằng hai mô hình không loại trừ nhau. Một chuỗi vừa bán sỉ vừa bán lẻ tại quầy có thể phát hành từ ERP cho luồng sỉ và giữ luồng lẻ ở cơ chế khác, nên tài liệu phải nói rõ luồng nào đi đường nào.
Cách nhanh nhất để ước lượng đúng phần này là đọc chính danh sách điều kiện mà bên nhận đặt ra.
Trên Odoo 19, module chặn việc gửi:
Danh sách đó chính là danh sách master data phải làm sạch trước go-live.
Chi tiết làm nhiều BA bất ngờ nhất lại là một trường không nằm trong danh sách chặn, đó là ô điện thoại. Hệ thống không báo lỗi khi số điện thoại có ký tự lạ mà lặng lẽ đổi dấu cộng thành hai số không rồi xóa mọi ký tự không phải chữ số, nên một số máy ghi kèm số máy lẻ phía sau sẽ bị nối thành một dãy số dài và nằm luôn trên tờ hóa đơn pháp lý.
Trường mà cả dự án coi như thông tin trang trí không làm hỏng việc phát hành, nhưng làm hỏng nội dung tờ hóa đơn, và loại lỗi đó khó phát hiện hơn nhiều so với một thông báo chặn.
Gói dữ liệu gửi đi gồm thông tin chung của hóa đơn, bên mua, bên bán, thanh toán, các dòng hàng và bảng phân tách thuế. Việc của bạn là ánh xạ từng trường về đúng một trường trên hệ thống rồi chỉ định người nhập cho trường chưa có chủ.
Có hai chi tiết nên ghi thẳng vào tài liệu: hình thức thanh toán luôn được gửi cố định là TM/CK, nên khách muốn ghi đúng hình thức thanh toán thì đó là một dòng GAP; và ngày phát hành lấy theo thời điểm gửi chứ không theo ngày hóa đơn nhập trong Odoo, nên kế toán quen lùi ngày hóa đơn cần được nói trước.
Ngoài ra, mẫu và ký hiệu hóa đơn một khi đã dùng để phát hành thì hệ thống chặn thẳng thao tác sửa, nên khai sai ở bước đầu thì bạn phải tạo bản ghi mới rồi chuyển các chứng từ sau sang dùng nó.
Cuối cùng, đừng vẽ luồng này thành một mũi tên một chiều. Ngoài chiều đẩy đi, hệ thống còn:
Mỗi chiều thêm vào là một hạng mục xử lý lỗi thêm vào.
Có ba loại lệch, và chúng không nguy hiểm như nhau.
Loại thứ hai nguy hiểm nhất vì nó sinh ra từ một chuyện rất tầm thường là mất kết nối giữa chừng.
Cách module xử lý chuyện đó đáng để bạn mang vào mọi tài liệu đặc tả tích hợp: hệ thống sinh một mã giao dịch và lưu lại trước khi gọi đi, rồi ở lần gửi sau nó dùng chính mã đó tra cứu xem hóa đơn đã được tạo bên kia hay chưa, và chỉ gửi mới khi không thấy gì. Thiếu cơ chế ấy thì mỗi lần thao tác lại sau lỗi mạng là một lần bạn có nguy cơ phát hành trùng một tờ hóa đơn ra bên ngoài.
Đồng thời, có một trạng thái lệch được thiết kế sẵn chứ không phải sự cố: khi yêu cầu hủy thành công phía dịch vụ nhưng thao tác hủy trong ERP thất bại vì vướng ngày khóa sổ, hệ thống ghi sự việc vào lịch sử trao đổi của chứng từ rồi dừng ở đó.
Về phân vai, cách chia tôi vẫn dùng là:
Ranh giới ấy phải viết ra trước go-live, bởi khi một tờ hóa đơn không ra được vào chiều cuối tháng thì không còn thời gian để bàn lỗi của ai.
Luồng thuận chỉ chiếm phần nhỏ khối lượng thật, và cả bốn tình huống dưới đây đều đã có chỗ trong module, nên bạn đặc tả được mà không cần đoán.
Hủy đi qua một trợ lý riêng, trong đó lý do hủy là trường bắt buộc còn tên và ngày của văn bản thỏa thuận là hai trường đi kèm. Sau khi hủy, nếu chứng từ được đưa về nháp thì hệ thống xóa số hóa đơn, mã tra cứu, ngày phát hành cùng các tệp đã nhận để có thể gửi lại.
Tuy nhiên, nút có sẵn không có nghĩa là cách xử lý đúng, bởi từ Nghị định 70/2025/NĐ-CP quy định đã bỏ cách hủy hóa đơn lập sai rồi lập hóa đơn mới, nên tài liệu phải ghi rõ khi nào nút này còn được dùng và ai được bấm, sau khi kế toán xác nhận cách hiểu.
Tình huống thứ hai và thứ ba là thay thế và điều chỉnh. Hai loại khác nhau ở mã loại mang trong gói dữ liệu, cả hai đều kèm số, ngày cùng mẫu của hóa đơn gốc, và điều chỉnh còn tách thành điều chỉnh tiền và điều chỉnh thông tin. Trên Odoo 19, thay thế đi qua thao tác đảo chứng từ rồi tạo hóa đơn mới, còn điều chỉnh đi qua giấy báo có.
Tài liệu của Odoo phân hai đường theo việc hóa đơn gốc đã kê khai thuế hay chưa, nhưng đó là hướng dẫn của Odoo chứ không phải quy định.
Theo Nghị định 254/2026/NĐ-CP và Thông tư 91/2026/TT-BTC có hiệu lực từ ngày 01/07/2026, hóa đơn sai ở mã số thuế, hàng hóa, số lượng, đơn giá, số tiền hay thuế suất thì người bán được chọn điều chỉnh hoặc thay thế, nhưng đã chọn cách nào thì những lần sửa sau phải theo đúng cách đó. Còn hóa đơn chỉ sai tên hoặc địa chỉ người mua thì thông báo cho người mua và cơ quan thuế chứ không lập lại.
Module không ràng buộc chuyện giữ đúng cách đã chọn, nên đó là quy tắc nghiệp vụ bạn phải viết vào tài liệu, kèm người chọn loại và căn cứ để chọn.
Cả hai đều gắn với văn bản thỏa thuận, bởi quy định yêu cầu người bán và người mua là tổ chức hoặc hộ kinh doanh lập văn bản ghi rõ nội dung sai trước khi điều chỉnh hay thay thế, còn người mua là cá nhân thì chỉ cần thông báo.
Yêu cầu nằm ngoài hệ thống ấy đã thành hai ô tên và ngày văn bản thỏa thuận trên trợ lý, nhưng cần lưu ý rằng nếu để trống thì hệ thống không chặn mà tự điền chữ NA cùng thời điểm hiện tại rồi gửi đi, nên muốn bắt buộc thì phải đặc tả thêm.
Tình huống thứ tư là hóa đơn cho đơn đã trả hàng một phần. Hệ thống chỉ chấp nhận gửi một giấy báo có khi nó liên kết tới một hóa đơn đã phát hành trước đó, nên việc xác định phần khách trả thuộc hóa đơn nào, chuyện đã nói ở bài về hai chứng từ, trở thành điều kiện chặn của luồng gửi. Trong trường hợp chứng từ nội bộ cần sửa sau khi hóa đơn đã phát hành, hãy nói trước với kế toán rằng nút đưa về nháp sẽ không hiện lên như thường lệ.
Danh sách dưới đây lấy đủ trong một buổi, và thiếu bất kỳ dòng nào thì phần ước lượng ở trên không dùng được.
Đặc biệt, có một câu tôi luôn để tới cuối vì nó quyết định phạm vi nhiều hơn cả, đó là khi hệ thống mới chạy thì cổng của nhà cung cấp còn được ai dùng trực tiếp nữa hay không. Nếu còn, bạn đang thiết kế cho hai nơi cùng phát hành và phải có cơ chế đối soát ngay từ ngày đầu.
Hai giới hạn đáng nói ra trước khi bạn mang bài này vào tài liệu.
Đầu tiên, mọi dữ kiện kỹ thuật ở trên là của đúng một module trên Odoo 19, nên chúng đúng với module đó chứ không đúng với mọi nhà cung cấp; tôi không so sánh và không khuyến nghị chọn ai, và bạn vẫn nên chạy thử luồng phát hành, thay thế, điều chỉnh trên môi trường thử của nhà cung cấp trước khi chốt đặc tả.
Tiếp theo, đây không phải tư vấn pháp lý hay kế toán, và quy định về hóa đơn điện tử đổi nhanh hơn bạn tưởng: Nghị định 70/2025/NĐ-CP sửa Nghị định 123/2020/NĐ-CP từ ngày 01/06/2025, rồi chỉ hơn một năm sau Nghị định 254/2026/NĐ-CP cùng Thông tư 91/2026/TT-BTC thay thế toàn bộ khung cũ từ ngày 01/07/2026.
Vì vậy số hiệu văn bản trong bài chỉ là điểm khởi đầu để tra cứu, và trước khi đưa quy tắc nào vào tài liệu đặc tả, hãy đối chiếu văn bản đang có hiệu lực và để kế toán của doanh nghiệp xác nhận cách hiểu.
Khi đường nối ra bên ngoài đã rõ, phần việc còn lại quay vào bên trong, tức là cấu hình hệ thống tài khoản và các bút toán kết chuyển theo chế độ kế toán doanh nghiệp Việt Nam sao cho sổ sách chạy được trên chính nền tảng này.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận