AI-OCR chứng từ xuất khẩu: đối chiếu Invoice và Packing List

Khi triển khai AI-OCR cho chứng từ xuất khẩu, câu hỏi đầu tiên nên là dữ liệu nào phải đối chiếu với nguồn nào và ai sẽ phê duyệt trước khi chuyển sang ERP hoặc quy trình giao hàng. Commercial Invoice (hóa đơn thương mại) và Packing List (phiếu đóng gói) mô tả cùng một lô hàng từ hai góc nhìn khác nhau. Việc chuyển cả hai thành văn bản chưa đem lại nhiều lợi ích nếu nhân viên vẫn phải tự ghép mã hàng, số lượng và kiện hàng. Bài viết này dành cho doanh nghiệp sản xuất xuất khẩu từ Thái Lan và các thị trường khác, trình bày cách trích xuất, đối chiếu liên chứng từ, phê duyệt bởi con người, tích hợp ERP, lập RFP và kiểm thử FAT/SAT. Khai báo hải quan và xác định xuất xứ là các nghiệp vụ chuyên môn riêng.

Tách khâu đọc chứng từ khỏi khâu kiểm tra nghiệp vụ

AI-OCR đọc chữ trên ảnh hoặc PDF và trả về các trường dữ liệu có cấu trúc. Với Invoice, hệ thống có thể trích số chứng từ, ngày, bên bán, bên mua, tiền tệ, các dòng hàng, số lượng và giá trị. Amazon Textract trả về các trường tổng quát và nhóm dòng hàng, kèm vị trí trên trang cùng điểm tin cậy. Microsoft Document Intelligence có mô hình Invoice để trích trường quan trọng và các dòng hàng. Những tính năng được công bố không đồng nghĩa mô hình Invoice có sẵn sẽ đọc hoàn hảo mẫu Invoice xuất khẩu hay Packing List riêng của doanh nghiệp. Cần thử trên bộ chứng từ thực tế. Tài liệu AWS và tài liệu Microsoft.

Kiểm tra nghiệp vụ là bước tiếp theo: cộng các dòng với tổng chứng từ, ghép Invoice với Packing List và đối chiếu cả hai với lệnh xuất hàng hoặc đơn hàng đã duyệt trong ERP. Điểm tin cậy OCR cao không chứng minh con số trên bản gốc là đúng; điểm thấp cũng không có nghĩa giá trị đọc ra chắc chắn sai. Dùng điểm này để ưu tiên việc kiểm tra của người, không dùng nó thay cho quy tắc nghiệp vụ. Hướng dẫn đánh giá của Google Document AI mô tả sự đánh đổi giữa precision và recall khi thay đổi ngưỡng tin cậy. Tài liệu Google.

Nên xác định ba lớp phạm vi: tiếp nhận và trích xuất chứng từ; chuẩn hóa, ghép và phát hiện ngoại lệ; cuối cùng là phê duyệt rồi chuyển dữ liệu sang ERP hoặc hệ thống giao hàng. Bản demo chỉ đọc chữ không chứng minh được hai lớp sau. RFP cần nêu đầu vào, đầu ra, người phụ trách và cách phục hồi lỗi của cả ba lớp. Để xem bối cảnh OCR trong văn phòng rộng hơn, tham khảo bài AI-OCR cho back office. Bài này đi sâu vào đối chiếu chứng từ xuất khẩu.

Cần lấy những dữ liệu nào từ Invoice và Packing List?

Invoice thể hiện thông tin thương mại và giá trị; Packing List thể hiện cách đóng hàng thực tế. UN/CEFACT công bố chuẩn Cross Industry Invoice và Cross Industry Packing List riêng biệt. WCO Data Model đưa ra các định nghĩa dữ liệu hài hòa cho trao đổi xuyên biên giới. Đây là nguồn tham khảo để xây danh mục trường nội bộ, nhưng không nên biến mọi trường trong chuẩn thành bắt buộc cho mọi giao dịch. Danh mục chuẩn UN/CEFACT và WCO Data Model.

Danh mục trường ban đầu nên có bốn cột: chữ trên bản gốc, giá trị đã chuẩn hóa, nguồn đối chiếu và bộ phận phụ trách. Với Invoice, các trường ứng viên gồm số và phiên bản chứng từ, ngày lập, người bán, người mua, nơi giao, tham chiếu đơn hàng, tiền tệ, mã hàng, mô tả, số lượng, đơn vị, đơn giá, giá trị từng dòng và tổng tiền. Với Packing List, đó là số chứng từ, tham chiếu Invoice hoặc đơn hàng, mã hàng, số kiện, số thùng, số lượng trong từng thùng, tổng số lượng, trọng lượng tịnh, trọng lượng cả bì và kích thước. Ưu tiên các trường mà sai sót gây ảnh hưởng lớn hoặc tốn nhiều thời gian nhập lại.

Không ép một dòng Invoice ghép đúng một dòng Packing List. Một mặt hàng có thể nằm trong nhiều thùng, còn một thùng có thể chứa nhiều mặt hàng. Cần gộp nội dung kiện theo tổ hợp phù hợp như mã lô hàng, mã sản phẩm, lot và cấp đóng gói trước khi so sánh. Tên hàng gần giống nhau không phải khóa ghép đủ mạnh. Dòng chưa ghép được phải trở thành ngoại lệ thay vì để AI tự đoán.

Chỉ định nguồn dữ liệu có thẩm quyền theo từng trường

ERP có thể là nguồn chuẩn cho mã hàng và giá bán đã duyệt, trong khi biên bản đóng hàng là nguồn chuẩn cho số thùng thực tế. Quy tắc “lấy tập tin mới nhất” không đủ. Hãy ghi rõ thứ tự ưu tiên và quyền sửa từng trường quan trọng. Bản Invoice cũ và bản sửa có thể cùng tồn tại trong email. Lưu số chứng từ, lần sửa, thời gian nhận, trạng thái duyệt và dấu vân tay tập tin cùng kết quả trích xuất. Nếu chứng từ thiếu thông tin phiên bản, phải có người xác nhận trước khi hệ thống cập nhật lô hàng.

Quy trình OCR và đối chiếu chứng từ xuất khẩu

Chuỗi vận hành gồm tiếp nhận → phân loại → xử lý đầu vào → trích xuất → chuẩn hóa → ghép đối chiếu → xử lý ngoại lệ → phê duyệt → tích hợp → lưu vết. Mỗi bước cần ghi rõ đầu vào, đầu ra và cách chạy lại sau lỗi.

1. Tiếp nhận và phân loại

Liệt kê email, cổng khách hàng, thư mục chung, máy quét và tải lên thủ công. Xác định cách xử lý PDF ghép nhiều chứng từ, trang đảo thứ tự, ảnh chụp, tập tin có mật khẩu và trang bị thiếu. Phân loại thành Invoice, Packing List, loại khác và chưa xác định. Không tự coi tập tin chưa xác định là Invoice. Lưu bản gốc với nguồn nhận, thời gian, tên tập tin và mã xử lý để người duyệt có thể quay về bằng chứng.

2. Chuẩn bị ảnh và trích xuất

Trang bị nghiêng, độ phân giải thấp, bóng đổ, ghi chú viết tay, nhiều ngôn ngữ và bảng chạy qua nhiều trang đều có thể làm giảm chất lượng. Phân biệt PDF có lớp văn bản với bản quét ảnh. Kiểm thử bố cục nhà cung cấp, bảng nhiều trang, cách ghi tiền tệ, ghi chú và lần sửa bằng mẫu thật. So sánh mô hình Invoice dựng sẵn với cách trích xuất tùy chỉnh, tính cả công bảo trì chứ không chỉ kết quả demo.

Giữ nguyên chuỗi ký tự, số trang, vị trí trên trang và điểm tin cậy của mỗi trường. Trong màn hình kiểm tra, người dùng nhấn vào giá trị thì vị trí tương ứng trên bản gốc cần được làm nổi bật. Khi đổi “1,000” thành số 1000, vẫn giữ cả hai dạng. Gắn phiên bản mô hình, prompt và bộ quy tắc với mã xử lý để giải thích được các lần sửa sau này.

3. Chuẩn hóa và tra cứu dữ liệu chủ

Chuẩn hóa ngày, dấu phân cách hàng nghìn, dấu thập phân, mã tiền tệ, đơn vị số lượng và trọng lượng, chữ hoa/thường trong mã hàng, cùng tên viết tắt của khách hàng trước khi ghi vào ERP. “PCS” và “pieces” có thể cùng chỉ một đơn vị, nhưng đổi bộ thành chiếc cần hệ số đã duyệt. Ký hiệu “$” một mình không xác định được mã tiền tệ. Mô tả giống nhau không chứng minh cùng mã hàng.

Ghép mã hàng theo thứ tự: trùng chính xác, bí danh đã duyệt, rồi danh sách gợi ý để người quyết định. Lưu người thêm bí danh và ngày áp dụng. Đôi khi cải thiện mẫu chứng từ hoặc dữ liệu chủ sẽ giảm ngoại lệ hiệu quả hơn huấn luyện lại mô hình.

4. Ghép chứng từ và ERP

Trước hết xác nhận chứng từ cùng lô hàng. Nếu thiếu mã tham chiếu chung, ngày xuất, đối tác và hàng hóa chỉ nên dùng để gợi ý cặp khả dĩ; người dùng vẫn phải xác nhận. Cộng các dòng đóng gói theo đúng mã hàng và đơn vị. So sánh tiền từng dòng và tổng Invoice riêng với điều kiện thương mại trong ERP. Packing List có thể không có trường giá, vì vậy không tạo lỗi cho dữ liệu vốn không tồn tại.

Phân kết quả thành “khớp”, “trong dung sai đã duyệt”, “cần xem xét” và “không thể so sánh”. Không áp dụng một dung sai cho mọi trường: sai tiền tệ khác hoàn toàn sai số cân nặng. Chủ quy trình phải phê duyệt dung sai theo hàng hóa, phương pháp đo và thỏa thuận; không có tỷ lệ chung phù hợp cho mọi công ty.

5. Kiểm tra ngoại lệ và phê duyệt

Màn hình nên đặt cạnh nhau ảnh gốc, giá trị đọc, giá trị chuẩn hóa, nguồn so sánh, chênh lệch và bước cần làm. Khi người dùng sửa, lưu giá trị trước/sau, lý do, người sửa và thời gian. Có cần tách người sửa khỏi người phê duyệt hay không phụ thuộc mức độ quan trọng và kiểm soát nội bộ.

Đặt điều kiện tự phê duyệt thận trọng: đủ trường bắt buộc, liên kết lô hàng chắc chắn, các phép đối chiếu trọng yếu đạt, và phiên bản chứng từ được chấp thuận. Điểm tin cậy thấp chỉ là một loại ngoại lệ; còn có thiếu trường, bản sửa xung đột, số chứng từ trùng, mã hàng chưa biết và số lượng khác nhau. Microsoft nêu cách kết hợp điểm tin cậy với bước người kiểm tra, song ngưỡng thực tế phải rút ra từ dữ liệu riêng của doanh nghiệp. Hướng dẫn Microsoft.

6. Kết nối ERP và hoạt động giao hàng

Chỉ chuyển dữ liệu đã xác nhận sau phê duyệt. Vùng dữ liệu trung gian giữ mã xử lý và ID chứng từ nguồn để phát hiện xung đột với lô hàng đã có. Dùng khóa idempotency để chạy lại sau sự cố không tạo bản ghi trùng. Nếu Invoice được sửa, giữ lịch sử bản cũ và quan hệ thay thế thay vì xóa.

Nếu công ty đã tạo PDF từ ERP, cần xác định vì sao phải OCR lại PDF đó. Kiểm tra bản do khách hàng hoặc đơn vị vận chuyển chỉnh sửa có thể hữu ích. Chỉ đối chiếu giá trị ERP với PDF do chính ERP tạo ra có thể lặp lại cùng một sai sót. Hãy xác định thông tin nào còn thay đổi sau khi xuất PDF và đặt điểm kiểm tra tại đó.

Những khác biệt nào cần kiểm tra, những gì không nên để AI quyết định?

Khi số lượng lệch, kiểm tra mã hàng và đơn vị trước. Gộp số lượng theo các thùng rồi đối chiếu cả từng dòng và tổng. Hàng mẫu, phụ tùng hoặc hàng không tính tiền có thể cần quy tắc riêng. Tổng khớp không đảm bảo cơ cấu mặt hàng đúng.

Với số kiện, trọng lượng và kích thước, phải phân biệt trọng lượng tịnh và cả bì, thùng và pallet, số dự kiến và số đo thực tế. Cần thống nhất định nghĩa cùng thời điểm đo trước khi phát cảnh báo.

Với mô tả sản phẩm, ưu tiên mã trùng hoặc bí danh đã duyệt. Mã khách hàng và mã nội bộ có thể cùng xuất hiện; bản dịch tên hàng chỉ là chứng cứ hỗ trợ. Hai chứng từ có thể dùng hệ thống đánh số khác nhau nên số khác không mặc nhiên sai; điều cần chứng minh là đúng phiên bản cho cùng lô hàng.

Giá, tiền tệ và điều kiện thương mại có thể trích xuất, nhưng quyết định đúng sai phải theo hợp đồng và thẩm quyền nội bộ. Xác định xuất xứ, phân loại mã hàng và nội dung khai hải quan nằm ngoài phạm vi tự phê duyệt ở đây. Tham khảo bài về hệ thống xác định xuất xứ FTA như một quy trình riêng.

Đo cả lỗi bỏ sót lẫn cảnh báo sai

Chỉ đếm các sai lệch đã phát hiện có thể ưu ái một hệ thống cảnh báo quá nhiều; chỉ giảm ngoại lệ có thể khiến hệ thống kiểm tra quá ít. Theo dõi sai lệch quan trọng phát hiện được, sai lệch bỏ sót, cảnh báo sai và thời gian giải quyết. Cảnh báo sai lặp đi lặp lại làm nhân viên dễ bỏ qua cảnh báo thực sự quan trọng.

Bộ kiểm thử cần gồm chứng từ bình thường và tình huống sai có chủ ý: số trên bản gốc sai, trộn bản sửa, ghép kiện sai và mã hàng mới; không chỉ gồm lỗi OCR đọc nhầm. Cảnh báo phải chỉ đúng trường và dòng để người xử lý. Sau khi sửa mô hình hoặc quy tắc, chạy lại cùng bộ thử để phát hiện lỗi tái xuất hiện.

Cải thiện chính chứng từ đầu vào

Nếu có thể làm việc với đối tác, số chứng từ và lần sửa rõ ràng, mã hàng trên từng dòng kiện, đơn vị thống nhất và PDF có lớp văn bản sẽ giảm cả lỗi đọc lẫn lỗi ghép. Nếu một số đối tác không thể đổi mẫu, tách nhóm đó trong RFP để nhà cung cấp ước tính đúng phần trích xuất tùy chỉnh, quy tắc và công kiểm tra của người.

RFP triển khai OCR chứng từ xuất khẩu cần nêu gì?

RFP chỉ ghi “muốn dùng AI-OCR” không đủ để so sánh báo giá. Cần đưa cho các nhà cung cấp cùng điều kiện về chứng từ, trường dữ liệu, quy tắc đối chiếu, duyệt, tích hợp và cách nghiệm thu.

Mẫu thử nên bao trùm đối tác, nhà máy, sản phẩm, ngôn ngữ, bảng nhiều trang, kiện pha trộn, giảm giá, bản sửa và bản quét xấu. Nhân viên nghiệp vụ tạo dữ liệu chuẩn từ bản gốc. Tách đáp án “OCR đọc gì” khỏi đáp án “nghiệp vụ nên xử lý ra sao”, và giữ riêng bộ đánh giá cuối cùng với bộ dùng để tinh chỉnh mô hình.

Đánh giá từng trường, dòng bị thiếu, dòng ghép sai, khả năng nối đúng lô hàng, phát hiện sai lệch trọng yếu, cảnh báo sai, thời gian con người kiểm tra và lỗi gửi ERP. Một điểm số “đọc được chứng từ” che khuất vấn đề thật. Hướng dẫn Google giải thích việc xem precision, recall và ngưỡng tin cậy cùng nhau. Hướng dẫn Google.

So sánh tổng chi phí: phí giấy phép hoặc trang, chuẩn bị mẫu, xây quy tắc, tích hợp ERP, giao diện duyệt, bảo trì mô hình khi biểu mẫu đổi và giờ nhân viên xử lý ngoại lệ. Tính cả tải cao điểm và số lần chạy lại. Dùng số liệu nền của công ty và báo giá thực thay vì tỷ lệ tiết kiệm lao động chung.

Có thể bắt đầu bằng mẫu ổn định và sản phẩm có mã rõ, sau đó mở rộng sang đối tác có mẫu khác nhau và đóng gói phức tạp. Chỉ tăng phạm vi tự phê duyệt khi kết quả đo cho phép. Chỉ định người phụ trách mô hình, quy tắc, nghiệp vụ xuất khẩu, dữ liệu ERP và quyền truy cập. Lưu phiên bản thay đổi, thử trên bộ chứng từ cố định trước khi triển khai và chuẩn bị cách quay lại phiên bản cũ.

Quy tắc vận hành cần chốt trước khi chạy thật

Thử nghiệm đọc chứng từ thành công không bảo đảm nhân viên xử lý được mọi ca hằng ngày. Xác định thứ tự ưu tiên và thời hạn xử lý ngoại lệ. Chứng từ gần giờ chốt lô, sai số lượng hoặc thiếu bản gốc có thể cần ưu tiên hơn chứng từ chỉ có điểm OCR thấp. Hiện rõ lý do ưu tiên trên màn hình và chỉ định người thay khi người phụ trách vắng mặt. Khi ca ngoại lệ quá hạn, chuyển lên người chịu trách nhiệm chứ không tự động duyệt.

Gán trạng thái cụ thể cho các ca không xử lý trọn vẹn: đã nhận, chưa xác định loại, trích xuất lỗi, chờ chứng từ đối ứng, chờ xem, đã duyệt, gửi ERP lỗi và hoàn tất. Xác định thao tác kế tiếp cho mỗi trạng thái. Khi phân loại lại chứng từ, quyết định có bỏ kết quả trích xuất cũ hay không. Ca chờ Packing List sẽ không được giải quyết bằng cách chạy lại OCR. Hiện nguyên nhân giúp tránh làm lại vô ích.

Theo dõi mỗi ngày số chứng từ theo kênh nhận, số chưa phân loại, lỗi trích xuất, ngoại lệ đối chiếu, tồn đọng phê duyệt và lỗi chuyển ERP. Nhờ đó có thể phân biệt nhà cung cấp đổi mẫu với danh mục mã hàng chưa được cập nhật. Mỗi chỉ số cần dẫn về mã xử lý và bản gốc; số tổng hợp không có bằng chứng từng ca khó dùng để cải tiến.

Trong cuộc họp cải tiến, phân nguyên nhân thành chất lượng nguồn, mẫu đối tác, dữ liệu chủ, quy đổi đơn vị, quy tắc ghép, quyền phê duyệt hoặc gián đoạn tích hợp. Đổi mẫu thì thu thập chứng từ mới; thiếu mã thì sửa danh mục. Kiểm thử lại bộ chứng từ cố định trước và sau thay đổi để đảm bảo cải thiện cho một đối tác không làm kết quả của đối tác khác xấu đi.

Cuối cùng, chuẩn bị cách làm thủ công khi mạng hoặc dịch vụ OCR ngừng. Ai đọc bản gốc, ghi vào đâu và nhập lại sau khi phục hồi? Đối chiếu bản nhập tay và kết quả tự động theo mã lô để không tạo dữ liệu ERP trùng. Giữ lý do và người duyệt của ca thủ công trong nhật ký. Đây là điều kiện để quy trình kinh doanh hoạt động liên tục, không phải tính năng riêng của AI.

FAT và SAT phải chứng minh cả quy trình vận hành

FAT kiểm tra thiết kế đã thống nhất trong môi trường của nhà cung cấp hoặc phòng thử; SAT kiểm tra với hệ thống và điều kiện tại địa điểm vận hành. Định nghĩa cụ thể theo hợp đồng từng dự án. Cả hai cần kiểm tra đối chiếu, duyệt, tích hợp và phục hồi lỗi, không chỉ demo OCR.

Trong FAT, thử một cặp chứng từ đúng; sai số lượng hoặc mã hàng; một mặt hàng rải nhiều thùng; thùng hỗn hợp; tên gần giống; chứng từ từ lô khác; Invoice đã sửa; bản quét xấu; mã chưa đăng ký; và thiếu trang. Xác định trước kết quả mong đợi: tự duyệt, cần người xem, hay dừng xử lý. Kiểm tra người dùng có thể quay về đúng vùng bằng chứng trên bản gốc.

Trong SAT, dùng hộp thư hoặc thư mục thật, tên tập tin thực tế, dữ liệu chủ ERP, quyền người dùng, mạng và mốc chốt việc hằng ngày. Ngắt hệ thống đích rồi thử gửi lại mà không trùng. Nộp lại cùng chứng từ để kiểm tra quản lý phiên bản. Xác nhận mọi sửa đổi được lưu và dữ liệu chưa duyệt không trở thành dữ liệu chính thức.

Điều kiện “OCR chính xác 99%” một mình thiếu ý nghĩa nếu không nêu bộ mẫu, trường, công thức tính, trường hợp loại trừ và mức độ nghiêm trọng. Quy định mã hàng có phải trùng tuyệt đối không, tính điểm ghép dòng ra sao, và đếm bỏ sót sai lệch trọng yếu thế nào. Theo dõi lỗi nghiêm trọng riêng khỏi điểm trung bình để các trường dễ không che mất rủi ro.

Câu hỏi thường gặp

Một mô hình OCR có đọc được cả Invoice và Packing List không?

Một nền tảng có thể hỗ trợ cả hai, nhưng cần phân loại chứng từ, định nghĩa trường và bộ thử riêng. Mô hình Invoice dựng sẵn không bảo đảm trích đúng Packing List. Hãy thử trên mẫu thật để quyết định có cần trích xuất tùy chỉnh.

Có thể ghi trực tiếp kết quả OCR vào ERP không?

Về kỹ thuật có thể kết nối API, nhưng trước hết phải chốt điều kiện đối chiếu và phê duyệt. Mã hàng lạ, đơn vị không tương thích hoặc bản chứng từ cũ không được âm thầm trở thành dữ liệu chính thức. Giai đoạn đầu nên dùng vùng đệm và bước kiểm tra của người.

Có thể tự động đối chiếu chứng từ vận tải đến mức nào?

Bài này tập trung Invoice và Packing List. Vận đơn hoặc chứng từ khác được phát hành ở thời điểm và vì mục đích khác. Chỉ thêm khi đã xác định khóa ghép, nguồn chuẩn và bộ phận phụ trách. Hệ thống trình bày sai lệch và chứng cứ; người xử lý quyết định tình huống chưa rõ.

Cần chuẩn bị gì cho RFP OCR chứng từ xuất khẩu?

Chuẩn bị danh mục chứng từ, mẫu đã ẩn dữ liệu nhạy cảm, danh mục trường, ngoại lệ từng gặp, trường ERP, vai trò phê duyệt, sản lượng trung bình và cao điểm. Có cả mẫu dễ và khó, giữ một phần để đánh giá độc lập.

AI-OCR có quyết định hải quan hoặc xuất xứ không?

Phạm vi ở đây là thu nhận và so sánh dữ liệu trên chứng từ. Các quyết định đó cần quy trình, trách nhiệm và bước chuyên môn riêng. Nếu mở rộng hệ thống sang lĩnh vực này, phải thiết kế tiêu chí duyệt riêng.

Kết luận: xác định bản gốc, quy tắc và người duyệt trước

AI-OCR chứng từ xuất khẩu bắt đầu ở việc đọc Invoice và Packing List. Giá trị vận hành nằm ở việc ghép đúng các phiên bản của cùng lô hàng, nối cấp mặt hàng với cấp kiện, giải thích được khác biệt và chỉ chuyển giá trị đã duyệt. Hãy đưa khả năng truy về bản gốc, danh mục trường, màn hình ngoại lệ, kết nối ERP cùng kịch bản FAT/SAT vào RFP trước khi chọn sản phẩm.

TOMAS TECH có thể hỗ trợ nhà máy tại Thái Lan xác định một dự án thử nhỏ dựa trên chứng từ và hệ thống đang dùng. Nếu vẫn đang xác định trường, quy tắc đối chiếu hoặc vai trò phê duyệt, hãy mô tả các chứng từ và khó khăn hiện tại qua trang liên hệ.

Tài liệu tham khảo

• UN/CEFACT: các chuẩn Invoice và Packing List
• WCO Data Model
• WCO: hài hòa dữ liệu chứng từ thương mại
• AWS Textract: đọc Invoice
• Microsoft Document Intelligence: mô hình Invoice
• Microsoft: điểm tin cậy và người kiểm tra
• Google Document AI: đánh giá
• Hải quan Thái Lan: thủ tục xuất khẩu đề cập Invoice và Packing List