Quản lý phiên bản chứng từ: đặt tên file, lưu vết, chống gửi nhầm bản
SOP quản lý version invoice, packing list, B/L draft, C/O và bộ chứng từ để tránh gửi nhầm, sửa nhầm hoặc mất căn cứ khi tranh chấp.
Vì sao quản lý version quan trọng
Một lỗi rất đời thường trong chứng từ là gửi nhầm bản: invoice draft cũ, packing list chưa sửa số kiện, B/L draft chưa đổi consignee, hoặc C/O theo invoice number trước đó. Khi có nhiều người cùng sửa file, nếu không có quy tắc version, lỗi nhỏ có thể thành lỗi lớn.
Quản lý phiên bản không cần phức tạp. Mục tiêu là ai nhìn vào shipment folder cũng biết bản nào là draft, bản nào đã gửi buyer, bản nào là final và ai duyệt.
Quy tắc đặt tên file gợi ý
[ShipmentID]_[Document]_[Buyer]_[Version]_[Date].pdf
EF2407-001_Invoice_BuyerA_v03_20260704.pdf
EF2407-001_PackingList_BuyerA_final_20260704.pdf
Nên tránh tên như invoice final final new.pdf hoặc PL sửa mới nhất.pdf, vì sau vài ngày không ai biết bản nào thật sự cuối.
Trạng thái chứng từ nên dùng
| Trạng thái | Ý nghĩa |
|---|---|
| Draft | Đang soạn, chưa gửi |
| For review | Chờ nội bộ/buyer kiểm |
| Revised | Đã sửa theo phản hồi |
| Approved | Đã được duyệt |
| Issued | Đã phát hành chính thức |
| Sent | Đã gửi đi |
| Final | Bản cuối cùng để lưu hồ sơ |
Checklist trước khi gửi chứng từ
- File gửi đi có đúng shipment ID không?
- Version có phải bản mới nhất không?
- Có ai duyệt bản này chưa?
- Nội dung đã khớp với các chứng từ liên quan chưa?
- File PDF có đúng với file Excel/Word nguồn không?
- Email gửi có đính kèm đúng file không?
- Đã lưu bằng chứng gửi chưa?
Cấu trúc shipment folder nên dùng
Một folder shipment nên đủ dễ hiểu để người mới vào vẫn lần được lịch sử. Cấu trúc tối giản có thể chia thành:
| Thư mục | Nội dung |
|---|---|
01_Input |
PI, hợp đồng, booking, SI, draft từ supplier/buyer |
02_Draft |
File đang soạn, chưa gửi chính thức |
03_Review |
Bản gửi buyer, forwarder, ngân hàng hoặc nội bộ rà |
04_Issued |
Bản đã phát hành chính thức |
05_Sent |
Bản đã gửi kèm email/bằng chứng gửi |
06_Archive |
Bản cũ, bản thay thế, log chỉnh sửa |
Không cần biến folder thành hệ thống phức tạp. Điểm quan trọng là bản final không nằm lẫn với bản draft, và mọi bản đã gửi ra ngoài đều có dấu vết.
Version log tối thiểu
Với lô hàng rủi ro cao, nên có một bảng log rất ngắn:
| Version | Người sửa | Nội dung sửa | Người duyệt | Gửi cho ai |
|---|---|---|---|---|
| v01 | Docs | Tạo draft invoice/PL | Sales | Chưa gửi |
| v02 | Docs | Sửa gross weight, CBM | Manager | Buyer |
| final | Docs | Khóa file PDF | Manager | Buyer + forwarder |
Log này đặc biệt hữu ích khi có tranh chấp: buyer nói chưa nhận bản sửa, forwarder dùng SI cũ, hoặc ngân hàng hỏi vì sao invoice number thay đổi.
AI hỗ trợ được gì
AI có thể tạo discrepancy log, checklist version và email tóm tắt thay đổi giữa hai bản text. AI không nên được dùng để tự quyết bản final nếu chưa có người phụ trách chứng từ duyệt trên file gốc.
Prompt mẫu
Bạn là trợ lý document control.
Hãy so sánh hai phiên bản chứng từ dưới đây.
Output:
- Trường đã thay đổi
- Rủi ro nếu gửi nhầm bản cũ
- Checklist trước khi phát hành bản final
- Email tóm tắt thay đổi cho buyer/forwarder
Lỗi thường gặp
- Sửa file nhưng không tăng version.
- Gửi file Excel thay vì PDF final.
- Không lưu phản hồi buyer/forwarder về bản draft.
- Nhiều người sửa song song một file.
- Không có shipment folder chuẩn.
Nguyên tắc chốt bản final
Một file chỉ nên được gọi là final khi đủ ba điều kiện: nội dung đã khớp bộ chứng từ liên quan, người có trách nhiệm đã duyệt, và file đã được khóa ở định dạng gửi đi. Nếu còn đang chờ buyer, forwarder, hãng tàu hoặc ngân hàng xác nhận, hãy dùng trạng thái For review hoặc Revised, không dùng final.
Trong đội nhỏ, chỉ cần quy định một người owner cho mỗi lô. Người này không nhất thiết tự làm hết chứng từ, nhưng chịu trách nhiệm kiểm bản mới nhất trước khi gửi ra ngoài. Đây là điểm giúp document control không biến thành việc “ai cũng sửa, không ai chịu trách nhiệm”.