# Tích hợp đối soát ngân hàng vào phần mềm quản lý kho - Link: https://mail.hoadontudong.com.vn/tich-hop-doi-soat-ngan-hang-vao-phan-mem-quan-ly-kho/ - Published: 2026-10-16T01:11:45+07:00 - Author: Hóa Đơn Tự Động Tiền đã về không đồng nghĩa kho có thể xuất hàng ngay. Đơn có thể hết hàng, đã hủy, mới nhận đặt cọc hoặc đang chờ kiểm tra địa chỉ. Nếu thông báo được gửi lại, một luồng thiếu kiểm soát còn có thể tạo hai yêu cầu xuất. Vì vậy, tích hợp đối soát ngân hàng với phần mềm kho phải kết nối ba trạng thái: khoản thu, đơn hàng và tồn kho. Với doanh nghiệp có hệ thống quản lý đơn hàng và WMS, cần xác định hệ thống nào quyết định nhả hàng trước khi nối API. Kiến trúc dưới đây trên hoadontudong.com. vn dùng các trạng thái và bảng ánh xạ như một mô hình thiết kế. Phạm vi thực hiện còn phụ thuộc API WMS, quyền cập nhật tồn và dịch vụ Pay2S doanh nghiệp đang sử dụng. ## Tích hợp đối soát ngân hàng vào phần mềm quản lý kho bắt đầu từ ranh giới trách nhiệm ![Rõ vai trò ngân hàng, đơn và kho](https://hoadontudong.com.vn/wp-content/uploads/ 2026/10/060-tich-hop-doi-soat-ngan-hang-vao-phan-mem-quan-ly-kho-inline-1.png) Rõ vai trò ngân hàng, đơn và kho Hệ thống thanh toán ghi nhận bằng chứng khoản thu. Hệ thống quản lý đơn hàng, thường gọi là OMS, quyết định khoản thu thuộc đơn nào và đơn đã đủ điều kiện thực hiện chưa. WMS quản lý hàng, vị trí, giữ hàng, lấy hàng và xuất hàng theo lệnh hợp lệ. Khi tách rõ trách nhiệm, kho không phải tự suy đoán khách đã trả đủ từ một dòng thông báo ngân hàng. Nếu doanh nghiệp dùng một phần mềm kết hợp các vai trò, vẫn nên phân biệt ba nhóm dữ liệu trong thiết kế. Khoản thu có mã giao dịch riêng; đơn có mã và số còn phải thu; lệnh kho có mã thực hiện. Một mã đơn có thể liên quan nhiều khoản thu và nhiều đợt giao, vì vậy không nên ép tất cả vào một trạng thái đã thanh toán rồi coi quy trình hoàn tất. Chủ dự án cần thống nhất nơi có quyền tạo và hủy lệnh xuất. Nếu cả phần mềm bán hàng và bộ nhận webhook đều gửi lệnh trực tiếp tới kho, cùng một đơn có thể bị xử lý hai lần. Nên chọn một điểm điều phối, lưu quyết định nhả hàng và giao cho kho thực hiện theo định danh lệnh duy nhất. ## Chuẩn hóa dữ liệu trước khi kết nối API ![Chuẩn hóa dữ liệu đơn và kho](https://hoadontudong.com.vn/wp-content/uploads/2026/ 10/060-tich-hop-doi-soat-ngan-hang-vao-phan-mem-quan-ly-kho-inline-4.png) Chuẩn hóa dữ liệu đơn và kho Bảng dữ liệu tối thiểu nên có tổ chức, mã đơn, mã khoản phải thu, mã giao dịch, số tiền, loại tiền, trạng thái xác minh và thời điểm cập nhật. Phần kho cần thêm mã lệnh, kho xuất, danh sách mã hàng, số lượng và trạng thái giữ hàng. Không đưa số tài khoản ngân hàng đầy đủ vào màn hình lấy hàng nếu nhân viên kho chỉ cần biết đơn đủ điều kiện. Mã hàng và đơn vị tính phải được ánh xạ rõ. Một hệ thống bán theo hộp còn kho lưu theo chiếc sẽ dễ xuất sai dù thanh toán hoàn toàn đúng. Nếu đơn được sửa sau khi tạo yêu cầu thanh toán, cần lưu phiên bản đơn liên quan. Số tiền khách trả theo phiên bản cũ phải đi qua kiểm tra chênh lệch trước khi tạo lệnh xuất theo nội dung mới. Bảng trách nhiệm dữ liệu đề xuất | Dữ liệu | Nơi chịu trách nhiệm | Kho cần nhận | | Khoản thu ngân hàng | Bộ phận thanh toán | Kết quả xác minh tham chiếu | | Phân bổ công nợ | OMS hoặc hệ thống tài chính | Điều kiện nhả hàng đã duyệt | | Giữ hàng | WMS | Số lượng và thời hạn giữ | | Lệnh xuất | Điểm điều phối đơn | Mã lệnh duy nhất, phiên bản | | Kết quả thực hiện | WMS | Đã lấy, đã xuất hoặc cần xử lý | ## Nhận thanh toán và xác định điều kiện nhả hàng [Tài liệu IPN Pay2S](https://mail.hoadontudong.com.vn/tai-lieu-pay2s/) mô tả cơ chế thông báo thanh toán tới máy chủ. Ứng dụng cần xác thực thông báo trước khi dùng kết quả để cập nhật đơn. Sau bước đó, điểm điều phối kiểm tra khoản thu đã được phân bổ đúng chưa, đơn còn hiệu lực không, số tiền đạt điều kiện nào và hàng có còn được giữ hay không. Doanh nghiệp nên định nghĩa điều kiện cho từng loại đơn. Đơn trả trước toàn bộ có thể chờ thu đủ; đơn đặt cọc chỉ được giữ hàng hoặc đặt lịch; đơn công nợ cần hạn mức và phê duyệt riêng. Không dùng một quy tắc chung có tiền vào là được xuất cho mọi khách. Những điều kiện này phải được chủ quy trình tài chính và vận hành thống nhất. Sau khi đủ điều kiện, tạo lệnh kho có mã duy nhất. Nếu gửi lệnh lỗi do mạng, điểm điều phối có thể thử lại cùng mã thay vì tạo lệnh mới. WMS cần trả lại kết quả đã biết nếu lệnh đó đã thực hiện. Trường hợp phần mềm kho chưa hỗ trợ cơ chế này, cần lớp trung gian quản lý trạng thái và bước kiểm tra trước khi gửi lại. Đội triển khai có thể dùng bài [phân biệt redirect và IPN](https://hoadontudong.com.vn/cong-thanh-toan-tu-dong-pay2s-redirect-va-ipn/) để thống nhất nguồn quyết định. Việc khách quay về trang cảm ơn không nên là tín hiệu duy nhất cho kho. Tương tự, một thông báo thanh toán hợp lệ vẫn cần đi qua quy tắc đơn hàng, thay vì kích hoạt trực tiếp việc xuất vật lý. ## Xử lý đơn hủy, thanh toán muộn và hết thời gian giữ hàng ![Thanh toán muộn cần kiểm tra tồn](https://hoadontudong.com.vn/wp-content/uploads/ 2026/10/060-tich-hop-doi-soat-ngan-hang-vao-phan-mem-quan-ly-kho-inline-2.png) Thanh toán muộn cần kiểm tra tồn Thời gian giữ hàng nên được lưu riêng với thời hạn thanh toán. Khi hết thời gian giữ, WMS có thể trả hàng về lượng sẵn bán theo chính sách. Nếu sau đó tiền đến, ứng dụng phải kiểm tra lại tồn và khả năng thực hiện. Không phục hồi giữ hàng cũ bằng cách đổi một trạng thái nếu số hàng đó đã được cấp cho đơn khác. Với đơn bị hủy trước khi nhận tiền, khoản thu muộn cần được lưu thành ngoại lệ liên quan đơn hủy. Nhân viên có thể xác nhận giao lại khi còn điều kiện, chuyển sang đơn mới hoặc trình hoàn tiền. Mỗi lựa chọn cần ghi lý do. Tác vụ hủy đơn trên ứng dụng và việc khách thực sự chuyển tiền là hai diễn biến có thể xảy ra không cùng thời điểm. Nếu một đơn giao nhiều đợt, điều kiện thanh toán cần gắn với từng đợt hoặc toàn hợp đồng theo thỏa thuận. Đợt đầu đã giao không khiến đợt sau tự được xuất. Hệ thống cần kiểm tra số lượng còn phải giao, số tiền đã phân bổ và quyết định nhả hàng của đúng đợt. Đây là nơi bảng theo dõi đơn–khoản thu–lệnh kho mang lại giá trị rõ rệt. ## Tình huống giả định: tiền về sau khi hàng đã được giải phóng Giả định doanh nghiệp giữ hai sản phẩm cho đơn A đến 16 giờ. Khách thanh toán lúc 16 giờ 10, sau khi kho đã giải phóng lượng giữ và một sản phẩm được dành cho đơn B. Nếu nhận tiền là tự xuất hai sản phẩm, hệ thống sẽ hứa giao số lượng không còn sẵn. Luồng đúng cần đưa A vào trạng thái cần kiểm tra tồn sau thanh toán. Nhân viên có thể xác nhận giao một phần và đặt lịch phần còn lại nếu khách đồng ý, hoặc xin duyệt hướng xử lý khác. Khi quyết định xong, điểm điều phối tạo lệnh cho số lượng thực tế. Khoản tiền vẫn được ghi nhận đầy đủ; trạng thái thực hiện đơn thể hiện phần chưa giao. Không sửa khoản thu để làm nó bằng giá trị hàng đang có trong kho. Tình huống giả định này cho thấy nghiệm thu phải xem cả tồn hàng và cam kết giao, thay vì dừng ở màn hình thanh toán thành công. Đơn có hàng khan hiếm, giá trị cao hoặc nhiều đợt giao cần phép thử riêng, bởi mỗi loại có thể yêu cầu một điều kiện nhả hàng khác nhau. ## Chống xử lý lặp từ thanh toán đến lệnh kho ![Một lệnh kho được thực hiện một lần](https://hoadontudong.com.vn/wp-content/uploads/ 2026/10/060-tich-hop-doi-soat-ngan-hang-vao-phan-mem-quan-ly-kho-inline-3.png) Một lệnh kho được thực hiện một lần Một hệ thống cần chống lặp ở ít nhất hai điểm: lưu khoản thu và thực hiện lệnh kho. Bản tin thanh toán có thể đến lại; lệnh kho cũng có thể bị gửi lại khi bên gọi không nhận được phản hồi. Khóa theo giao dịch ngân hàng không tự bảo vệ lệnh kho nếu chương trình cứ tạo mã lệnh mới sau mỗi lần thử lại. Với tác vụ dài như lấy hàng hoặc đóng gói, nên phản hồi đã tiếp nhận rồi theo dõi kết quả qua trạng thái riêng. Tuy nhiên, chỉ phản hồi sau khi đã lưu yêu cầu bền vững. Nếu trả thành công trước khi lưu và tiến trình bị dừng, đơn có thể mất lệnh xử lý. Cách tổ chức cụ thể phụ thuộc API và khả năng giao dịch dữ liệu của WMS. Tham khảo [nguyên tắc nhận webhook và chống ghi nhận trùng](https://hoadontudong.com.vn/webhook-giao-dich-ngan-hang-pay2s/) khi thiết kế đầu vào. Sau đó kiểm tra thêm bước đồng bộ kết quả kho: ứng dụng có phân biệt đang lấy hàng, đã xuất và giao thất bại hay không? Một khoản thu chỉ chứng minh tiền đã nhận, không chứng minh khách đã nhận đủ hàng. ## Nghiệm thu theo kịch bản vận hành kho Bộ thử cần có đơn trả đủ, trả thiếu, đặt cọc, gửi lại thông báo, đơn hủy nhận tiền muộn và hàng giữ đã hết hạn. Thêm tình huống API kho lỗi, lệnh đã thực hiện nhưng mất phản hồi, người dùng sửa đơn và giao nhiều đợt. Với mỗi kịch bản, kiểm tra số tiền, số lượng giữ, lệnh xuất và thông điệp gửi khách. Báo cáo cuối ngày nên nối giao dịch đã nhận với đơn và lệnh đã thực hiện, đồng thời liệt kê khoản thu chưa có đơn, đơn đủ tiền chưa có lệnh và lệnh đã xuất nhưng thiếu trạng thái phản hồi. Những danh sách này cần người phụ trách riêng. Không cộng các trạng thái chờ thành lỗi chung vì nguyên nhân và cách xử lý khác nhau. Trong ngày chuyển đổi, nên xác định một mốc bắt đầu rõ ràng và chốt danh sách đơn còn mở trước mốc đó. Đơn cũ có thể tiếp tục theo quy trình đang dùng hoặc được nhập sang có kiểm tra; không để cả quy trình cũ và mới cùng gửi lệnh cho một nhóm đơn. Khi cần tạm dừng kết nối, vẫn giữ tiếp nhận khoản thu và xếp các yêu cầu kho vào hàng đợi có theo dõi. Quyền sửa quy tắc nhả hàng cũng cần giới hạn. Người vận hành kho có thể báo thiếu hàng; người tài chính có thể xác nhận khoản thu; việc cho phép xuất khi chưa đủ tiền phải theo quyền phê duyệt của doanh nghiệp. Kiểm tra nhật ký đổi cấu hình cùng các thay đổi dữ liệu, vì một quy tắc bị sửa nhầm có thể ảnh hưởng nhiều đơn hơn một thông báo thanh toán lỗi. Đợt thử tại một kho nhỏ nên kết thúc bằng việc truy lại từng đơn từ tiền nhận đến chứng từ xuất, bao gồm các lần thử lại và lần bị từ chối. [Checklist test thanh toán](https://hoadontudong.com.vn/cong-thanh-toan-tu-dong-pay2s-test-sandbox/) giúp chuẩn bị phần đầu vào; tài liệu API WMS và quy tắc nhả hàng xác định phần còn lại. Với phạm vi đã rõ, [đội triển khai trên hoadontudong.com.vn](https://hoadontudong.com.vn/contact/) mới có cơ sở đánh giá công việc và chi phí tích hợp.