Đưa giao dịch ngân hàng vào ERP chưa có nghĩa khoản phải thu đã được gạch đúng. ERP còn phải biết khách hàng, chứng từ, đơn vị nhận tiền và kỳ ghi nhận. Nếu gửi thẳng mọi khoản tiền vào thành phiếu thu, doanh nghiệp có thể tự động tạo sai chứng từ nhanh hơn trước.
Cách tích hợp đối soát ngân hàng vào phần mềm ERP nên được thiết kế như một luồng dữ liệu có điểm kiểm soát: nhận, chuẩn hóa, đối chiếu, duyệt và đồng bộ kết quả. Đội phát triển cần thống nhất với tài chính nơi nào giữ dữ liệu gốc, nơi nào quyết định khớp và nơi nào ghi sổ. Các mô hình dưới đây là thiết kế đề xuất để nối nguồn Pay2S được giới thiệu trên hoadontudong.com.vn với ERP; khi triển khai phải ánh xạ chúng sang contract của từng hệ thống.
Chốt ranh giới giữa nhận giao dịch và ghi sổ
Trước khi viết adapter, thống nhất đầu ra của dự án. Chỉ cần nhập sao kê để người dùng đối chiếu, tự ghép công nợ hay tạo chứng từ được phép ghi sổ? Mỗi mức đòi hỏi dữ liệu và quyền khác nhau. Người phụ trách kế toán cần duyệt quy tắc, còn đội kỹ thuật chịu trách nhiệm triển khai đúng hợp đồng đã chốt.
ERP có thể hỗ trợ API, import file hoặc cơ chế mở rộng riêng. Xác minh đúng sản phẩm, phiên bản và quyền của tài khoản tích hợp. Không tự dựng endpoint “tạo phiếu thu” từ một ví dụ của hệ thống khác. Nếu chỉ có import, kiến trúc vẫn cần theo dõi lô và kết quả từng dòng.
Pay2S cung cấp lớp kết nối dữ liệu ngân hàng theo tài liệu Partner API. Có thể đọc BankHub và cách tiếp cận API ngân hàng để hiểu đầu nguồn. Phần chuyển dữ liệu thành đối tượng nghiệp vụ ERP vẫn phải được xây và nghiệm thu riêng.
Tạo hợp đồng dữ liệu trung gian, giữ nguyên nguồn gốc
Đừng buộc toàn bộ ERP hiểu trực tiếp payload của từng ngân hàng hoặc nhà cung cấp. Một lớp chuẩn hóa giúp chuyển các nguồn về cùng khái niệm: tài khoản nhận, chiều tiền, số tiền, đơn vị tiền tệ, thời gian và tham chiếu. Lưu cả bản gốc để điều tra khi mapping thay đổi.
Ví dụ dưới đây là đối tượng trung gian giả định. Các tên trường do đội triển khai lựa chọn; phải viết adapter ánh xạ từ tài liệu nguồn đã xác minh:
{
"schema_version": "1",
"source_transaction_id": "DEMO_TX_001",
"account_ref": "BANK_ACCOUNT_ALIAS",
"direction": "credit",
"amount": "450000",
"currency": "VND",
"occurred_at": "2026-10-15T09:00:00+07:00",
"business_reference": "DEMO_ORDER_001"
}Số tiền dùng biểu diễn thập phân chính xác theo hợp đồng nội bộ, không tính bằng số thực tùy tiện. Định danh là chuỗi; không chuyển số tài khoản thành số làm mất ký tự. Tách thời điểm giao dịch, lúc nhận dữ liệu và kỳ kế toán do ERP quản lý.
Staging giúp dữ liệu chưa rõ không lọt vào công nợ
Staging là vùng nhận giao dịch trước khi tạo nghiệp vụ chính thức. Mỗi bản ghi có trạng thái đã nhận, đã chuẩn hóa, chờ đối chiếu, đã ghép hoặc cần kiểm tra. Tên trạng thái tùy ứng dụng, nhưng phải biết bản ghi đang dừng ở bước nào và vì sao.
Nhận thông báo hợp lệ rồi lưu bền vững trước khi xác nhận thành công. Nếu ERP đang bảo trì, dữ liệu vẫn nằm ở staging hoặc hàng đợi, không mất theo vòng đời request. Ngược lại, phản hồi đã nhận mà chưa lưu được ở đâu sẽ tạo khoảng trống khó phục hồi.
Tài liệu webhook biến động số dư Pay2S giúp xác định đúng loại dữ liệu đầu vào. Cần phân biệt webhook ngân hàng với IPN Collection Link, vì kết quả một đơn thanh toán không thay thế toàn bộ giao dịch trên tài khoản.
Ánh xạ khách hàng, chứng từ và đơn vị nhận tiền
Ưu tiên tham chiếu rõ như mã đơn hoặc mã phải thu được doanh nghiệp kiểm soát. Sau đó kiểm tra tài khoản nhận, chủ thể pháp lý, khách hàng và số tiền còn phải thu. Không tự ghép một giao dịch vào chứng từ chỉ vì cùng số tiền và ngày gần nhau.
Giữ bảng ánh xạ mã khách hàng giữa hệ thống bán hàng và ERP nếu chúng khác nhau. Tên người chuyển có thể không trùng tên khách mua, đặc biệt khi nhân viên hoặc người thân trả hộ. Dữ liệu này hỗ trợ kiểm tra, không phải khóa duy nhất để tự quyết định công nợ.
Các chiều phân tích như cửa hàng, bộ phận hoặc dự án cũng phải có quy tắc. Một tài khoản ngân hàng dùng chung không tự cho biết doanh thu thuộc điểm nào. Khi tham chiếu thiếu hoặc mâu thuẫn, giữ bản ghi chờ người có trách nhiệm xác nhận thay vì chọn giá trị mặc định cho mọi khoản.
Phân bổ khoản thu cần hỗ trợ quan hệ nhiều chiều
Một khách có thể trả một khoản cho nhiều hóa đơn; một hóa đơn có thể được thanh toán nhiều lần. Tách bảng giao dịch với bảng phân bổ để thể hiện quan hệ đó. Mỗi phân bổ giữ số tiền, đối tượng phải thu, người duyệt và phiên bản quy tắc đã sử dụng.
Kiểm tra tổng số tiền phân bổ không vượt khoản nhận và không vượt công nợ theo chính sách cho phép. Khi có chiết khấu, phí hoặc bù trừ, cần chứng cứ và quy tắc nghiệp vụ riêng. Không làm tròn hoặc tự xóa phần lệch để biến một giao dịch không đủ điều kiện thành khớp.
Khoản chuyển giữa các tài khoản của doanh nghiệp cần được nhận diện, tránh cộng thành thu khách hàng. Tương tự, khoản hoàn, vốn góp hoặc tiền vay không nên đi qua quy tắc doanh thu mặc định. Việc phân loại do nghiệp vụ kế toán quyết định, không suy ra chỉ từ chiều tiền vào.
Thiết kế chống trùng ở cả dữ liệu và tác vụ ERP
Khóa duy nhất của giao dịch nên gồm phạm vi tenant hoặc đơn vị, nguồn dữ liệu và định danh nguồn ổn định. Không mặc định ID ở hai hệ thống độc lập là duy nhất toàn bộ. Lần nhận lại phải trả về bản ghi đã tồn tại, không tạo khoản thu mới.
Chống trùng giao dịch chưa đủ nếu tác vụ tạo chứng từ được chạy lại. Mỗi nghiệp vụ gửi ERP cần khóa idempotency hoặc định danh đối chiếu theo khả năng ERP hỗ trợ. Lưu request, kết quả và mã chứng từ được tạo để lần thử lại biết phải tìm cái gì.
Hai worker đồng thời không được cùng giành một khoản thu để phân bổ hết vào hai chứng từ. Dùng ràng buộc và cơ chế khóa/cập nhật có điều kiện phù hợp cơ sở dữ liệu. Kiểm thử cạnh tranh thực tế quan trọng hơn chỉ thêm một câu lệnh “nếu chưa xử lý” trước khi ghi.
Timeout là kết quả chưa rõ, không phải chắc chắn thất bại
Khi ERP chưa trả response, request có thể đã tạo chứng từ hoặc chưa đến nơi. Tạo request mới với định danh mới ngay lập tức có thể sinh trùng. Adapter cần giữ định danh nghiệp vụ ban đầu và kiểm tra trạng thái theo cơ chế ERP cho phép trước khi quyết định gửi lại.
Không có transaction cơ sở dữ liệu chung bao trùm backend của bạn và ERP từ xa. Có thể dùng outbox để giữ tác vụ cần gửi, worker thực hiện và tiến trình đối soát kiểm tra kết quả chưa rõ. Lỗi kéo dài chuyển sang hàng đợi ngoại lệ có người phụ trách, thay vì retry vô hạn.
Log cần đủ để nối giao dịch nguồn, phân bổ và chứng từ ERP, nhưng phải che bí mật cùng dữ liệu cá nhân không cần thiết. Tham khảo cách quan sát calls, log và lỗi API cho đầu nguồn; adapter ERP cần có quan sát riêng tương ứng.
Đảo và điều chỉnh mà không sửa mất lịch sử
Nếu khoản thu đã ghép sai, quy trình nên tạo điều chỉnh có lý do và quyền duyệt. Không sửa bản ghi ngân hàng gốc để che lỗi. Khi ERP đã ghi sổ, cách đảo hoặc thay chứng từ phụ thuộc chính sách và khả năng của ERP; đội kỹ thuật không tự xóa record để “làm lại từ đầu”.
Giao dịch đến sau khi kỳ đã khóa cần được báo cho người có thẩm quyền. Tách ngày phát sinh từ nguồn với kỳ hạch toán được chọn theo quy trình. Việc tự lùi ngày hoặc mở khóa kỳ làm sai kiểm soát ngay cả khi tổng tiền cuối cùng nhìn khớp.
Với hóa đơn điện tử, giữ trạng thái thanh toán và phát hành riêng. Một khoản thu được phân bổ không tự cho biết mọi điều kiện lập hóa đơn đã đủ. Nếu có bước hóa đơn đi cùng thanh toán, cần thống nhất một nơi chịu trách nhiệm kích hoạt để tránh hai hệ thống phát hành cho cùng nghiệp vụ.
Quyền tích hợp và quyền duyệt phải được nghiệm thu
Tài khoản tích hợp chỉ nên được quyền thực hiện những đối tượng và đơn vị cần thiết. Người sửa mapping, người duyệt ngoại lệ và người phát hành chứng từ có thể cần các vai trò khác nhau. Hãy thử bằng tài khoản thật của từng vai trò, gồm cả hành vi bị cấm.
Khóa và token đặt trong hệ thống quản lý bí mật của backend, không ở file import hoặc bảng dùng chung. Với Pay2S, đọc cơ chế xác thực và quản lý khóa theo đúng luồng. Quyền ERP cũng cần quy trình cấp, xoay và thu hồi tương ứng.
Khi thay người vận hành, tài liệu bàn giao phải chỉ rõ nguồn dữ liệu, lịch đối soát, trạng thái lỗi và cách tìm một giao dịch xuyên hệ thống. Một adapter chạy tốt nhưng chỉ một người biết sửa sẽ trở thành điểm nghẽn khi có sự cố.
Nghiệm thu bằng dữ liệu lệch, không chỉ dữ liệu đẹp
Bộ thử cần có thanh toán gộp, trả từng phần, sai tham chiếu, hai đơn cùng giá, chuyển nội bộ, thông báo trùng và giao dịch đến muộn. Thử tiếp ERP timeout, worker chạy lại và kỳ đã khóa. Mỗi tình huống phải chỉ ra trạng thái mong đợi, chứng từ được phép tạo và ai xử lý ngoại lệ.
Đối chiếu theo mã giao dịch và phân bổ, không chỉ tổng tiền. Một bản ghi bị thiếu và một bản ghi thừa cùng giá trị có thể khiến tổng khớp giả. Khi nghiệm thu, kế toán cần truy được từ chứng từ ERP về giao dịch nguồn, còn kỹ thuật cần chứng minh có thể phục hồi mà không tạo thêm nghiệp vụ.
Luồng tích hợp sẵn sàng khi những trường hợp chưa rõ được giữ lại đúng chỗ và những trường hợp đủ điều kiện đi qua nhất quán. ERP không cần đoán ý nghĩa của một khoản tiền; dữ liệu và quy tắc phải cung cấp đủ căn cứ để giải thích quyết định đó.
Nguồn kỹ thuật: Pay2S liên kết ngân hàng; Pay2S webhook; SDK V2 và giới hạn xử lý phía merchant. Contract, staging, outbox và mapping trong bài là kiến trúc đề xuất, cần đối chiếu tài liệu ERP cụ thể.
