Mục lục

Trong bài này

Chứng từbasicCập nhật 18/4/2026

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”.