Nghiệm thu hệ thống POS: 8 nhóm kiểm thử trước mở bán

Nghiệm thu hệ thống POS cần kiểm tra được một vòng bán hàng hoàn chỉnh từ chọn hàng tới thu tiền, in phiếu, thay đổi tồn và báo cáo. Việc mở được màn hình phần mềm hoặc in được một tờ giấy chưa chứng minh toàn bộ hệ thống sẵn sàng. Bài viết đưa ra tám nhóm kiểm thử để chủ cửa hàng cùng đơn vị triển khai thống nhất kết quả mong đợi, ghi lỗi và bàn giao. Các tính năng chỉ được đưa vào phạm vi nghiệm thu khi đã xác nhận có trong gói và cấu hình thực tế.

1. Chuẩn bị phạm vi nghiệm thu hệ thống POS

Liệt kê số quầy, chi nhánh, tài khoản, thiết bị và kết nối thuộc đợt bàn giao. Ghi phiên bản phần mềm, model máy, hệ điều hành và vai trò người tham gia. Chốt chức năng nào phải thử, chức năng nào chưa triển khai và ai có quyền chấp nhận. Một danh sách rõ giúp tránh hiểu rằng mọi khả năng thường thấy của POS đều đã được mua hoặc cấu hình.

Mỗi kịch bản nên có dữ liệu đầu vào, thao tác, kết quả mong đợi, kết quả thực tế và chứng cứ. Dùng dữ liệu thử hoặc môi trường được phép để không làm phát sinh đơn, tồn hay tiền thật ngoài kế hoạch. Nếu cần thử giao dịch thực, phải có quy trình và người có thẩm quyền xử lý; không tự dùng tiền khách hoặc tạo đơn giả trên ca đang kinh doanh.

Chuẩn bị danh sách lỗi với mức ảnh hưởng. Lỗi không thu được tiền, sai giá hoặc sai tồn cần được ưu tiên hơn lỗi trình bày không cản trở vận hành. Tiêu chí mở bán nên được thống nhất trước, không đợi tới cuối buổi mới quyết định lỗi nào có thể chấp nhận.

2. Kiểm tra danh mục, biến thể và giá bán

Chọn mẫu hàng có mã dài, số 0 đầu chuỗi, nhiều biến thể và nhiều đơn vị nếu cửa hàng sử dụng. Quét hoặc tìm hàng rồi so tên, quy cách và giá. Thử trường hợp tên gần giống để xem nhân viên có phân biệt được. Không chỉ kiểm một sản phẩm dễ nhất vì nó không phản ánh những dữ liệu thường gây nhầm trong vận hành.

Với chương trình giảm giá, mô tả rõ điều kiện áp dụng, thời gian, nhóm khách hoặc số lượng theo chính sách được duyệt. Kiểm kết quả trước và sau ngưỡng áp dụng. Nếu chưa triển khai tính năng tương ứng, ghi ngoài phạm vi thay vì tạo thao tác thủ công không có người chịu trách nhiệm. Thử cả tình huống người dùng không có quyền tự sửa giá.

Xem cách đối chiếu giá kệ và POS để nối kiểm thử dữ liệu với nhãn tại cửa hàng. Một bảng giá trên phần mềm đúng nhưng nhãn kệ còn cũ vẫn có thể làm khách hiểu nhầm khi mở bán.

3. Kiểm tra thanh toán và quỹ tiền mặt

Thử từng phương thức thanh toán thuộc phạm vi đã cấu hình. Với mỗi đơn, kiểm tổng tiền, phần giảm giá, số khách đưa và tiền trả lại nếu có. Tách xác nhận đã ghi nhận phương thức trên POS với xác nhận tiền thật từ nhà cung cấp thanh toán. Nếu hệ thống chỉ ghi nhận thủ công, cần ghi rõ giới hạn đó để nhân viên không hiểu rằng nó tự xác minh giao dịch.

Kiểm tra quỹ mở ca, các lần cấp thêm hoặc rút bớt theo chức năng thực tế. Với ca thử, số tiền kỳ vọng cuối ca phải có cách tính lại được. Thử một ngoại lệ được hỗ trợ như hủy trước thanh toán hoặc hoàn theo quy trình, rồi xem báo cáo phản ánh ra sao. Không thử thao tác tài chính vượt quyền của người đang thực hiện.

Đối chiếu thêm quy trình kiểm tra tiền mặt, chuyển khoản và ví. Lưu chứng cứ đã ẩn dữ liệu nhạy cảm, đủ để biết mã đơn, phương thức và kết quả mà không phát tán thông tin khách hoặc tài khoản.

4. Kiểm tra máy in và đường đi của từng loại phiếu

In mẫu có tên hàng dài, ký tự tiếng Việt, nhiều dòng và thông tin cần quét nếu có. Kiểm tên máy đích, khổ giấy, chiều in và số bản. Nếu có phiếu bếp hoặc tem đồ uống, xác nhận từng bộ phận nhận đúng phần cần làm. Không coi việc một máy in biên lai chạy được là bằng chứng toàn bộ máy bếp đã cấu hình đúng.

Thử tình huống hết giấy hoặc mất kết nối theo cách an toàn và được người triển khai hướng dẫn. Quan sát lệnh đang chờ, thông báo lỗi và thao tác khôi phục. Sau khi kết nối lại, kiểm có tự in lệnh cũ hay không. Nhân viên cần biết cách in lại từ đơn gốc mà không tạo thêm giao dịch hoặc yêu cầu chế biến trùng.

Có thể tham khảo hướng dẫn kiểm tra kết nối máy in khi phù hợp cấu hình. Thông số cuộn và cách xử lý đầu in phải theo đúng model. Không dùng vật tư gần giống chỉ để buổi nghiệm thu ra được giấy rồi bỏ qua ảnh hưởng khi chạy thật.

5. Kiểm tra tồn kho, đổi trả và điều chuyển

Ghi số tồn trước kịch bản, bán lượng xác định rồi đối chiếu số sau. Với hàng có biến thể hoặc nhiều đơn vị, kiểm tra đúng bản ghi bị tác động. Nếu bán combo có định mức, chỉ thử phần đã được cấu hình và duyệt; đối chiếu nguyên liệu theo quy tắc thực tế. Tránh suy ra khả năng quản lý kho từ tên gói phần mềm.

Thử đổi trả hoặc hủy theo các trạng thái được hỗ trợ và kiểm tra lại tiền, tồn, lịch sử. Nếu có chuyển chi nhánh, xác định thời điểm trừ kho gửi, trạng thái đang đi và thời điểm tăng kho nhận. Một giao dịch có số tổng đúng vẫn có thể ghi sai địa điểm. Ghi riêng chênh lệch dữ liệu với chênh lệch kiểm đếm vật lý.

Ví dụ, ban đầu kho thử có 10 đơn vị, bán 2 thì còn 8 theo quy tắc đã xác nhận. Nếu trả hợp lệ 1 đơn vị được nhập lại, kết quả kỳ vọng là 9. Đây là ví dụ kiểm tra số học, không áp dụng tự động cho hàng hỏng, hàng không nhập lại hoặc quy trình có cấu hình khác.

6. Kiểm tra quyền tài khoản và khả năng tra cứu

Đăng nhập bằng từng vai trò thật sự sẽ dùng: thu ngân, quản lý ca, kho và chủ cửa hàng nếu có. Thử thao tác được phép và thao tác cần bị hạn chế như đổi giá, hủy đơn hoặc xuất báo cáo. Kiểm cả việc người dùng có nhìn thấy dữ liệu ngoài phạm vi chi nhánh hay không. Không nghiệm thu toàn bộ bằng một tài khoản quản trị rồi cho rằng phân quyền đã hoạt động.

Tài khoản bàn giao cần có người sở hữu rõ và được quản lý theo quy trình của đơn vị. Nhật ký hoặc dấu vết thao tác, nếu được hỗ trợ, phải giúp tìm người thực hiện và thời điểm. Nếu không có tính năng, ghi nhận giới hạn và chọn biện pháp kiểm soát bổ sung phù hợp, không quảng cáo rằng mọi thay đổi đều tự được lưu.

Xem cách tổ chức phân quyền nhân viên để chuẩn bị bảng vai trò. Với dữ liệu khách, chỉ cấp quyền cần cho công việc; bản sao nghiệm thu không nên chứa nhiều thông tin cá nhân hơn mức cần thiết.

7. Kiểm tra mất mạng, khôi phục và đồng bộ

Trước khi thử mất mạng, hỏi rõ hệ thống hỗ trợ nghiệp vụ nào khi offline. Có thể một số màn hình vẫn mở nhưng không lưu được đơn hoặc không xác nhận thanh toán. Chỉ mô phỏng theo hướng dẫn trong môi trường phù hợp, tránh ngắt mạng dùng chung làm ảnh hưởng hệ thống đang vận hành. Ghi chính xác thời điểm mất và phục hồi kết nối.

Thử các tình huống đã được hỗ trợ như đơn nháp, đơn chờ đồng bộ hoặc lần gửi lệnh bị gián đoạn. Sau khôi phục, đếm đơn, đối chiếu tiền và tồn để phát hiện trùng hoặc mất. Nếu phần mềm không hỗ trợ bán offline, nghiệm thu quy trình dự phòng thủ công được duyệt và bước nhập lại có kiểm soát, không biến giới hạn thành lời hứa tính năng.

Đối chiếu quy trình bán hàng khi mất mạng. Khi nhận đơn từ website, kiểm mã tham chiếu giữa hai hệ thống. Có thể phối hợp 8SEO để xử lý màn hình và luồng dữ liệu web, nhưng chỉ ghi đã đồng bộ sau khi thử và đối chiếu thành công.

8. Chốt báo cáo và bàn giao theo lỗi thực tế

Đọc báo cáo ca thử và tự cộng lại một số đơn để kiểm tổng theo phương thức, hủy, hoàn và các điều chỉnh. So sánh số trên báo cáo với dữ liệu kịch bản, không chỉ chụp màn hình tổng quan. Tài liệu quản lý đơn của WooCommerce là ví dụ về cách xem trạng thái và chi tiết trên một nền tảng; báo cáo POS phải được kiểm theo hệ thống thực tế.

Biên bản bàn giao cần có số kịch bản đạt, lỗi còn mở, mức ảnh hưởng, người xử lý và điều kiện kiểm lại. Phân biệt đã hướng dẫn người dùng với đã sửa lỗi. Nếu lỗi nghiêm trọng còn tồn tại, nêu rõ chức năng chưa sẵn sàng thay vì ký hoàn tất chung cho mọi phần. Chứng cứ cần đủ để lần kiểm sau lặp lại được.

Cuối buổi, thu ngân thử độc lập một vòng công việc bằng tài khoản của mình. Lưu đầu mối hỗ trợ, cấu hình được duyệt và hướng dẫn ngắn cho sự cố thường gặp. Liên hệ 8POS với phạm vi triển khai và kết quả mong đợi để chuẩn bị kịch bản trước lắp đặt; một lần nghiệm thu rõ giúp cả cửa hàng và đơn vị triển khai cùng biết hệ thống đã làm được gì.

Nếu đang cân nhắc phần mềm quán ăn miễn phí, chỉ thử các chức năng thực có và ghi rõ giới hạn. Với máy POS cầm tay dưới 2 triệu hoặc cấu hình cho quán ăn nhỏ, đối chiếu đúng phiên bản được báo giá và môi trường ứng dụng trước khi chọn.

Khi có kết nối phần mềm bán hàng và kế toán, người phụ trách hai hệ thống cần cùng xác nhận mã tham chiếu và số liệu. Với bảng chi phí phần mềm, gắn từng khoản với phạm vi được cung cấp thay vì suy ra mọi tính năng đều nằm trong một gói.

Các tính năng chăm sóc khách hàng bằng AI và ứng dụng AI trong bán hàng cần thêm kịch bản về dữ liệu, quyền truy cập và cách kiểm tra kết quả. Một ví dụ trình diễn đúng không thay cho bằng chứng hệ thống hoạt động ổn định trên dữ liệu phù hợp của cửa hàng.

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

Mở phần mềm và in được bill đã đủ nghiệm thu chưa?

Chưa. Cần kiểm giá, tiền, tồn, quyền, báo cáo và các kết nối thuộc phạm vi triển khai. Một thao tác thành công chỉ xác nhận một phần.

Có cần thử bằng tài khoản thu ngân không?

Có. Tài khoản quản trị có quyền khác nên không phản ánh đúng trải nghiệm và giới hạn của người vận hành.

Mọi POS đều cần thử bán offline giống nhau không?

Không. Xác nhận khả năng của phiên bản trước; nếu không hỗ trợ, kiểm quy trình dự phòng thay vì mặc định phần mềm vẫn lưu đơn.

Lỗi nhỏ có được bàn giao không?

Theo tiêu chí đã thống nhất. Ghi rõ mức ảnh hưởng, chức năng liên quan và cách kiểm lại; không ghi hoàn tất những phần chưa được chấp nhận.

Nên lưu gì sau nghiệm thu?

Lưu phạm vi, cấu hình, kịch bản, kết quả, lỗi còn mở và người xác nhận. Tài liệu phải giúp lặp lại phép thử khi kiểm tra hoặc mở rộng.