Webhook từ CRM sang ERP cần được nghiệm thu khi có lỗi và gửi lại. Mục tiêu: không mất tác vụ đã nhận, không tạo đơn trùng, không để dữ liệu cũ ghi đè.

Phân biệt mã sự kiện và mã nghiệp vụ

Mã sự kiện nhận diện một thay đổi; mã nghiệp vụ nhận diện đơn hàng hoặc khách hàng. Một đơn có nhiều cập nhật hợp lệ. Kiểm tra quy tắc định danh bên gửi; khóa chống trùng cần phân biệt nguồn và tài khoản. Không chặn mọi cập nhật chỉ vì cùng mã đơn.

Lưu yêu cầu trước khi xác nhận

Xác minh chữ ký theo tài liệu nhà cung cấp, giữ nguyên nội dung yêu cầu khi cần. Kiểm tra thời hạn chữ ký nếu giao thức hỗ trợ. Từ chối yêu cầu sai chữ ký.

Lưu khóa sự kiện, nội dung và trạng thái chờ trong cùng giao dịch, với ràng buộc duy nhất tại cơ sở dữ liệu. Bảng tiếp nhận lưu bền vững có thể làm hàng đợi cho tiến trình nền. Chỉ trả xác nhận ACK bằng HTTP 2xx sau khi giao dịch hoàn tất. Ghi thất bại thì không ACK. Lưu trong bộ nhớ không đủ.

Các ca kiểm thử giả định

Chạy trong môi trường thử. Các mã và kết quả mong đợi là giả định, không phải kết quả khách hàng.

1. Gửi trùng đồng thời: gửi E101 ba lần cho đơn O42. Đạt khi chỉ nhận một tác vụ và tạo một đơn ERP. Thử E102 cho cùng thao tác tạo O42: vẫn một đơn.
2. Ngắt tại điểm tiếp nhận: cho giao dịch ghi hàng đợi thất bại, rồi thử lại khi kết nối phục hồi. Khởi động lại tiến trình sau ACK. Đạt khi tác vụ đã nhận còn tồn tại và được xử lý.
3. ERP lưu xong rồi lỗi: dừng tiến trình trước khi ghi trạng thái hoàn tất. Khi chạy lại, dùng cùng khóa thao tác chống trùng được ERP hỗ trợ hoặc mã tham chiếu mà ERP bắt buộc không trùng. Đối soát mã ERP; nếu chưa rõ kết quả, chuyển người phụ trách kiểm tra trước khi tạo lại.
4. Sai thứ tự: gửi phiên bản 8 trước 7 của O42. Đạt khi điều kiện phiên bản được kiểm tra nguyên tử lúc ghi: 7 không đè 8; 9 vẫn cập nhật được. Nếu nguồn không có phiên bản tin cậy, lấy trạng thái hiện hành hoặc chuyển đối soát.
5. Lỗi và giả mạo: thử ERP trả 429/503; gửi dữ liệu sai, chữ ký sai. Lỗi tạm thời được thử lại với khoảng chờ tăng dần, độ lệch ngẫu nhiên và giới hạn; tôn trọng Retry-After khi có. Lỗi nghiệp vụ không tự sửa được chuyển hàng chờ lỗi, có cảnh báo và người xử lý.

Bằng chứng nghiệm thu

Lưu mã sự kiện, mã nghiệp vụ, số lần thử, trạng thái, mã ERP, kết quả đối soát; che dữ liệu nhạy cảm. Thử phát lại sau sửa lỗi. Với đầu vào tài liệu, xem thêm kiểm thử AI đọc báo giá PDF.

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

HTTP 200 nghĩa là ERP đã cập nhật?

Không. ACK xác nhận tác vụ đã lưu bền vững; cần theo dõi kết quả xử lý.

Có bảo đảm xử lý đúng một lần không?

Không thể hứa chung. Khả năng chống trùng phụ thuộc cơ chế ERP, thời hạn lưu khóa và quy tắc phát lại.

Liên hệ Việt Nis – IT On Cloud hoặc gọi 0888 728 730 để trao đổi tiêu chí.

Một lượt sao lưu báo thành công chưa chứng minh nhân viên có thể làm việc lại. SME cần kiểm thử khôi phục dữ liệu với tiêu chí rõ: mở đúng nội dung, dùng đúng quyền và hoàn thành nghiệp vụ. Bài chiến lược sao lưu 3-2-1 trình bày cách bố trí bản sao; bài này tập trung nghiệm thu bản phục hồi.

Chốt phạm vi và người chịu trách nhiệm

Chọn một quy trình, chẳng hạn lập báo giá từ bảng giá và hồ sơ sản phẩm. Giao IT thực hiện, người phụ trách nghiệp vụ xác nhận và chỉ định người thay thế. Ghi danh sách tệp, phiên bản, quyền truy cập, phụ thuộc và tiêu chí đạt trước khi thử.

RPO là mức mất dữ liệu tối đa chấp nhận được, tính theo thời gian. RTO là thời gian gián đoạn tối đa chấp nhận được trước khi dịch vụ được khôi phục. Đây là mục tiêu theo nhu cầu doanh nghiệp, không phải bảo đảm của phần mềm sao lưu.

Thực hiện trong môi trường cách ly

1. Chuẩn bị: dùng thư mục, máy ảo hoặc tài khoản thử riêng. Chặn đồng bộ ngược, gửi email và kết nối ghi vào hệ thống thật. Tuyệt đối không xóa hoặc ghi đè dữ liệu gốc để tạo sự cố.
2. Khôi phục: chọn điểm phục hồi đã xác định; kiểm tra quyền thực hiện và khả năng truy cập khóa giải mã. Tính thời gian từ mốc sự cố giả định, gồm cả chờ và xử lý lỗi.
3. Đối chiếu: mở tệp, kiểm tra nội dung và phiên bản cần dùng; đối chiếu số dòng, tổng tiền hoặc mã kiểm tra toàn vẹn đã lưu nếu phù hợp. Tên tệp giống nhau chưa đủ.
4. Thử quyền: tài khoản được phép phải mở hoặc sửa được theo vai trò; tài khoản ngoài phạm vi phải bị từ chối. Kiểm tra cả chủ sở hữu và liên kết chia sẻ.
5. Thử nghiệp vụ: xác minh công thức, tệp liên kết, ứng dụng và cơ sở dữ liệu phụ thuộc trong môi trường thử. Chỉ dừng đồng hồ khi người phụ trách nghiệp vụ xác nhận công việc mẫu hoàn tất.

Tình huống giả định và cách kết luận

Giả định sự cố lúc 10:00, RPO 30 phút, RTO 90 phút. Bản sao chứa dữ liệu đến 09:40; đội thử hoàn tất báo giá mẫu lúc 11:05. Khoảng dữ liệu có nguy cơ mất là 20 phút, thời gian phục hồi đo được là 65 phút.

Hai chỉ tiêu thời gian đạt trong tình huống này. Tuy nhiên, bảng giá sai phiên bản hoặc tài khoản ngoài nhóm vẫn truy cập được thì chưa nghiệm thu. Đây là ví dụ minh họa, không phải kết quả khách hàng.

Lưu bằng chứng để lần sau làm lại được

Biên bản cần mã bản sao, phạm vi, mốc giờ, kết quả từng phép thử, người xác nhận và lỗi cần sửa. Lên lịch thử lại sau thay đổi quan trọng. Kết quả chỉ phản ánh phạm vi và điều kiện đã kiểm tra.

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

Chỉ mở được một tệp đã đủ chưa?

Chưa. Cần kiểm tra đúng phiên bản, quyền và quy trình sử dụng đã chọn.

Nếu bản khôi phục thiếu dữ liệu thì sao?

Đánh dấu chưa đạt, giữ nguyên dữ liệu gốc và bằng chứng; điều chỉnh cấu hình rồi thử lại.

Cần xây dựng tiêu chí phù hợp? Liên hệ Việt Nis – IT On Cloud hoặc gọi 0888 728 730.

AI đọc được một báo giá PDF chưa có nghĩa dữ liệu đã sẵn sàng nhập vào ERP. Trước khi kết nối tự động, doanh nghiệp cần đối chiếu các trường quan trọng, thử những tài liệu khó và xác định trường hợp bắt buộc có người duyệt. Mục tiêu là tránh đưa một sai sót nhỏ của tài liệu thành một giao dịch sai trong hệ thống.

Bắt đầu bằng bộ mẫu có đáp án đã kiểm tra

Chọn báo giá của nhiều nhà cung cấp: PDF có lớp chữ, bản scan, bảng nhiều trang và bản sửa đổi. Nhân sự nghiệp vụ xác nhận dữ liệu đúng từ tài liệu gốc, sau đó mới so sánh với kết quả AI. Không dùng chính đầu ra AI làm đáp án để tự chấm.

Có thể bắt đầu bằng 20 tài liệu cho một vòng thử nhỏ. Đây là đề xuất triển khai, không phải cỡ mẫu đủ để chứng minh độ chính xác của toàn bộ hệ thống. Chưa có đủ dạng tài liệu thì cần bổ sung mẫu trước khi kết luận.

Sáu nhóm lỗi nên đưa vào bộ kiểm thử

1. Nhầm đơn vị: thùng, hộp, chiếc hoặc giờ công. Ví dụ giả định, giá 120.000 đồng/hộp 12 chiếc không được tự hiểu thành 120.000 đồng/chiếc. Quy đổi chỉ khi có quy tắc nghiệp vụ được duyệt.
2. Nhầm tiền tệ và dấu số: không suy ra VND hay USD từ vị trí nhà cung cấp. Kiểm tra ký hiệu, dấu phân cách và trường tiền tệ riêng.
3. Mất hoặc lệch dòng hàng: thử bảng sang trang, tiêu đề lặp và một mô tả kéo dài nhiều dòng. Đếm dòng so với tài liệu gốc, không chỉ kiểm tra tổng tiền.
4. Thiếu thông tin: ô trống phải được đánh dấu cần xác minh, không tự điền điều kiện thanh toán hoặc thời hạn báo giá.
5. Nhầm phiên bản hoặc nhập trùng: cùng số báo giá có thể có bản cập nhật. Lưu dấu nhận diện tài liệu và quy tắc xử lý bản mới trước khi tạo giao dịch.
6. Sai phép đối chiếu: kiểm tra số lượng, đơn giá, chiết khấu và tổng thể hiện trong tài liệu. Chênh lệch cần người phụ trách xác nhận; không tự sửa để ép các con số khớp nhau.

Điểm tin cậy cao vẫn cần kiểm tra nghiệp vụ

Theo tài liệu đánh giá Document AI của Google Cloud, precision, recall và ngưỡng confidence phản ánh những khía cạnh khác nhau của kết quả trích xuất. Điểm confidence không phải giấy bảo đảm rằng một giao dịch cụ thể đúng. Cần xem kết quả theo từng trường và mức ảnh hưởng của sai sót.

Với trường có thể làm sai số tiền hoặc nhà cung cấp, thử nghiệm ban đầu nên chuyển kết quả sang hàng đợi duyệt. Chỉ cho phép bước tự động sau khi đã thống nhất tiêu chí chấp nhận, cách ghi nhận lỗi và cách dừng luồng khi dữ liệu không hợp lệ.

Lưu gì để sửa lỗi và chạy lại có kiểm soát?

• Tài liệu nguồn và phiên bản bộ trích xuất.
• Giá trị AI đọc được, giá trị người duyệt xác nhận và lý do sửa.
• Kết quả kiểm tra nghiệp vụ, người phê duyệt và mã giao dịch đích.
• Trạng thái xử lý lại để tránh tạo thêm giao dịch khi một yêu cầu được gửi lần nữa.

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

Có nên nối thẳng AI vào ERP ngay từ đầu?

Nên bắt đầu với bước nhập nháp hoặc môi trường thử, có người duyệt. Không dùng một bản demo đọc đúng vài tài liệu làm căn cứ bỏ toàn bộ kiểm soát.

Có thể dùng báo giá thật để thử không?

Chỉ dùng dữ liệu được phép xử lý trên công cụ đã được doanh nghiệp chấp thuận. Giảm hoặc che thông tin không cần cho bài kiểm thử; giới hạn người truy cập bộ mẫu.

Muốn thử AI đọc chứng từ theo một quy trình cụ thể? Xem bài checklist bàn giao dữ liệu Google Drive, tìm hiểu dịch vụ của Việt Nis hoặc gửi yêu cầu tư vấn. Trước tiên chỉ cần mô tả dạng tài liệu, số lượng dự kiến và hệ thống nhận dữ liệu; không gửi hồ sơ nhạy cảm qua biểu mẫu công khai. Hotline 0888 728 730.

Để bàn giao Google Drive khi nhân viên nghỉ việc, doanh nghiệp cần kiểm kê tài liệu, xác định quyền sở hữu và kiểm tra quyền truy cập của người tiếp nhận trước khi kết thúc tài khoản. Shared drives (bộ nhớ dùng chung) giúp tổ chức quản lý tài liệu của đội ngũ; một thư mục được chia sẻ trong My Drive không tự trở thành Shared drive.

Vì sao thư mục đã chia sẻ vẫn cần bàn giao?

Theo hướng dẫn Google, tài liệu trong Shared drives thuộc tổ chức và vẫn tồn tại khi thành viên rời đi. My Drive có cơ chế sở hữu khác. Vì vậy, hãy kiểm tra nơi lưu thực tế của từng tài liệu thay vì chỉ nhìn danh sách người được chia sẻ.

Ví dụ giả định: một nhân viên kinh doanh lưu báo giá trong My Drive và gửi liên kết cho cả phòng. Người quản lý nhìn thấy thư mục nhưng chưa có nghĩa toàn bộ hồ sơ đã thuộc bộ nhớ chung của công ty.

Checklist bàn giao gồm năm bước

1. Kiểm kê theo nghiệp vụ. Lập danh sách báo giá, hợp đồng, bảng theo dõi và tài liệu dự án. Ghi URL, người sở hữu, nơi lưu và người tiếp nhận. Bao gồm biểu mẫu, tệp đính kèm và liên kết mà đồng nghiệp đang sử dụng.
2. Phân loại quyền sở hữu. Tách tài liệu của tổ chức, tài liệu bên ngoài và dữ liệu cá nhân. Với tệp thuộc khách hàng hoặc đối tác, cần thống nhất quyền truy cập với chủ sở hữu; không coi mọi tệp nhân viên nhìn thấy là tài sản có thể chuyển.
3. Chọn cách bàn giao phù hợp. Đưa tài liệu đội ngũ vào Shared drive khi gói dịch vụ, quyền và loại tệp cho phép; các trường hợp khác cần quản trị viên đánh giá cách chuyển quyền hoặc lưu trữ. Kiểm thử một nhóm nhỏ trước khi di chuyển nhiều tệp.
4. Kiểm thử bằng tài khoản tiếp nhận. Mở liên kết từ hồ sơ cũ; thử đọc, chỉnh sửa hoặc tải xuống đúng phạm vi cần thiết. Kiểm tra riêng người dùng ngoài công ty. Một danh sách quyền đẹp chưa chứng minh công việc tiếp tục được.
5. Xác nhận và thu hồi quyền. Người phụ trách nghiệp vụ ký nhận danh mục. IT xử lý tài khoản, nhóm và quyền chia sẻ theo quy trình nghỉ việc, đồng thời lưu biên bản và các ngoại lệ chưa giải quyết.

Chọn quyền đủ dùng, tránh cấp Manager cho mọi người

Google phân biệt Manager, Content manager, Contributor, Commenter và Viewer. Quyền phù hợp tùy việc người dùng cần thực hiện; đối chiếu bảng quyền Shared drives trước khi cấp. Người chỉ cần đọc tài liệu không cần quyền quản lý thành viên.

Biên bản cần ghi gì?

• URL tài liệu và vị trí lưu sau bàn giao.
• Người tiếp nhận, quyền cần có và kết quả kiểm thử.
• Ngoại lệ: tệp bên ngoài, liên kết lỗi hoặc dữ liệu chưa phân loại.
• Ngày xác nhận và người chịu trách nhiệm xử lý phần còn lại.

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

Chỉ chia sẻ thư mục My Drive đã đủ chưa?

Chưa. Chia sẻ quyền truy cập không đồng nghĩa thay đổi quyền sở hữu. Cần kiểm tra từng nhóm tài liệu và xác nhận người tiếp nhận làm việc được.

Shared drives có thay thế sao lưu không?

Không nên coi bộ nhớ dùng chung là toàn bộ kế hoạch phục hồi. Doanh nghiệp vẫn cần chính sách lưu giữ, sao lưu và kiểm thử khôi phục phù hợp với dữ liệu quan trọng.

Nên bắt đầu từ đâu?

Chọn một phòng ban, lập danh mục và chạy thử quy trình trước đợt thay đổi nhân sự tiếp theo. Theo dõi số liên kết lỗi và số tài liệu chưa có người tiếp nhận để biết phần nào còn thiếu.

Cần rà soát cấu trúc Drive của công ty? Xem dịch vụ Google Workspace của Việt Nis hoặc gửi yêu cầu tư vấn kèm số người dùng, nơi lưu hiện tại và thời điểm dự kiến bàn giao. Gọi 0888 728 730.