Đơn đặt 100 bộ có thể nhận thành nhiều chuyến và được lập hóa đơn theo tháng. Nếu chỉ cộng số trên các file, hệ thống dễ tính lại cùng một phiếu nhận hoặc coi số đã đặt là số đã giao. AI nên hỗ trợ nối đúng dòng chứng từ; phần tính số lượng còn mở cần quy tắc rõ ràng và người phụ trách xác nhận.
Giao hàng từng phần cần sổ ở cấp dòng
Khóa đối chiếu nên xuống đến mã đơn hàng và dòng PO, thay vì chỉ dùng tên vật tư. Một đơn có thể có hai dòng cùng mặt hàng nhưng khác lịch giao hoặc điều kiện. Mỗi phiếu nhận cũng cần mã riêng và dòng riêng. AI đọc ra tên gần giống chưa đủ để khẳng định chúng thuộc cùng một cam kết.
Microsoft mô tả việc ghép hóa đơn với các dòng phiếu nhận và cho phép ghép số lượng từng phần. Tài liệu cũng phân biệt số đã đặt với số đã nhận. Bài này chỉ lấy ranh giới nghiệp vụ đó làm cơ sở cho sổ đối chiếu, không hướng dẫn tự động hạch toán hay khẳng định mọi ERP có cùng cách xử lý.
Ba số phải được giữ riêng
Mẫu sổ đề xuất có số lượng đặt, số lượng nhận đã xác nhận và số lượng nhận đã được phân bổ cho hóa đơn. Với một dòng PO, không lấy số đã đặt làm căn cứ chứng minh giao hàng. Số còn có thể phân bổ chỉ được tính từ các phiếu nhận hợp lệ theo quy tắc của doanh nghiệp.
| Khóa | Dữ liệu cần giữ |
|---|---|
| PO_id + PO_line | Mặt hàng, đơn vị, số đặt và phiên bản đơn |
| receipt_id + receipt_line | Số nhận xác nhận, ngày nhận, chứng cứ nguồn |
| invoice_id + invoice_line | Số đề nghị đối chiếu, đơn vị, nguồn |
| allocation_id | Số phân bổ, phiếu nhận được dùng, người duyệt |
| exception_id | Trả hàng, hủy phiếu, đổi đơn vị hoặc thiếu nguồn |
Quan hệ phân bổ cần chống ghi lặp: cùng một sự kiện xử lý lại không được tạo thêm một lượng đã dùng. Đây là yêu cầu dữ liệu và quyền ghi của hệ thống, không thể giải quyết chỉ bằng một câu lệnh cho mô hình.
Ví dụ mô phỏng với hai chuyến nhận
PO-L1 đặt 100 bộ; phiếu R1 xác nhận 40 bộ và R2 xác nhận 35 bộ. Hóa đơn I1 đề nghị 50 bộ. Một phương án minh họa là phân bổ 40 từ R1 và 10 từ R2, còn 25 bộ đã nhận chưa phân bổ. Số chưa giao theo đơn là 25 bộ, nhưng đó là đại lượng khác.
Nếu sau đó có phiếu trả 5 bộ thuộc R2, không sửa lặng lẽ lịch sử thành “R2 nhận 30”. Giữ sự kiện trả và liên kết với dòng gốc để người phụ trách xác định ảnh hưởng. Ví dụ này là mô phỏng logic sổ; cách ghi nhận thực tế phải theo quy trình và hệ thống được sử dụng.
Những trường hợp AI nên dừng ghép
- Tên giống nhau nhưng đơn vị khác, chưa có quy tắc quy đổi được duyệt.
- Phiếu nhận thiếu mã PO hoặc có nhiều dòng có thể phù hợp.
- Số lượng yêu cầu vượt lượng nhận còn mở.
- Phiếu bị hủy, sửa hoặc có hàng trả chưa được xử lý.
- Hàng nhận có điều kiện nhưng chứng từ không cho biết đã chấp nhận hay chưa.
Với mỗi trường hợp, kết quả tốt là một câu hỏi cụ thể kèm dòng nguồn. “Thiếu phiếu nhận cho 10 bộ” hữu ích hơn “dữ liệu không khớp”. Hệ thống cần để người nhận việc bổ sung chứng cứ mà không mất các phân bổ đã được xác nhận trước đó.
Kiểm thử tính bảo toàn trước khi nối ERP
Chạy các tình huống nhận một lần, nhận nhiều lần, cùng phiếu gửi lại, hóa đơn chia nhỏ và phiếu trả đến sau. Với mỗi lần chạy, đối chiếu tổng phân bổ trên một phiếu không vượt phần có thể dùng theo quy tắc. Thử xử lý lại cùng dữ liệu để kiểm tra có phát sinh phân bổ trùng không.
Nên lưu nhật ký trước/sau cùng người duyệt. Độ chính xác đọc chữ và độ đúng của sổ phân bổ là hai phép kiểm khác nhau: đọc đúng “35” không có nghĩa hệ thống đã gắn đúng dòng PO. Khi một khóa bị sửa, phải kiểm tra lại các quan hệ liên quan.
Khi nào nên mở rộng sang đối chiếu chứng từ
Nếu doanh nghiệp đã có sổ nhận và phân bổ rõ, có thể bàn tiếp về AI hỗ trợ đối chiếu chứng từ mua hàng. Nếu file đầu vào chưa thống nhất, bước chuẩn bị dữ liệu từ tài liệu cần được xác định trước.
Để trao đổi phạm vi, hãy chuẩn bị một dòng PO có nhiều lần nhận và một ngoại lệ thật đã ẩn thông tin nhạy cảm. Điều cần thống nhất là khóa nối, quyền xác nhận và cách giữ lịch sử, thay vì yêu cầu AI “khớp hết” bằng suy đoán.
Nguồn tham khảo
Tài liệu chính thức: Có thể ghép số lượng từng phần giữa dòng hóa đơn và dòng phiếu nhận; số đặt khác số nhận. Truy cập ngày 13/10/2026. Các mẫu sổ, tình huống và đề xuất kiểm soát trong bài do người biên tập xây dựng; không phải tính năng Onter đã nghiệm thu.
