Tmpl Uat Sign 002 Uat Sign Off Tracking

1. Tier 1 ? Metadata, Purpose, and Governance

Trường kiểm soát	Giá trị chuẩn
Artifact ID	TMPL-UAT-SIGN-002
Tên tệp được kiểm soát	/03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md
Tiêu đề artifact	Tmpl Uat Sign 002 Uat Sign Off Tracking
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Phân loại artifact	Controlled four-tier template. “Controlled” nghĩa là nội dung, ID, trạng thái, phiên bản và lịch sử thay đổi phải truy vết được.
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục.
Dữ liệu	Chỉ dữ liệu tổng hợp. Tên người, vai trò, giao dịch, ngày, số tiền, lỗi, bằng chứng và quyết định trong Tier 3 là dữ liệu giả lập.
Baseline reference	Chưa có baseline reference tại v0.9.0. IN_REVIEW không có nghĩa BASELINED.
Approval reference	Chưa có approval reference. Metadata, Owner, nội dung mẫu hoặc trạng thái review không tạo phê duyệt ngầm định.
Production boundary	Không phải hồ sơ ký nghiệm thu thực tế, không cấp quyền triển khai production, không xác nhận tuân thủ pháp lý, kế toán, thuế, bảo mật hay vận hành.

Owner giữ toàn vẹn quản trị: đúng Artifact ID, đúng filename, trạng thái, phiên bản, ngày cập nhật và lịch sử thay đổi. Owner không có quyền tự tạo baseline, ghi nhận approval, xác nhận kết quả UAT thực tế, quyết định chấp nhận rủi ro, hay thay thẩm quyền Business Owner, QA Lead, Product Owner, Legal Owner, Accounting Owner, Security Owner hoặc Architect.

Phiên bản	Ngày	Người ghi nhận	Thay đổi	Lý do kiểm soát
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho TMPL-UAT-SIGN-002 ở trạng thái IN_REVIEW; xác lập ranh giới dữ liệu Nova Foods mô phỏng.	Tạo điểm nhận diện có thể truy vết trước khi template được dùng cho học liệu.

Mọi thay đổi sau v0.9.0 phải ghi phiên bản mới, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, mô tả thay đổi và lý do. Không sửa im lặng nội dung đã phát hành để tránh đứt liên kết giữa template, lịch sử thay đổi và bằng chứng review. Nếu thay đổi làm khác Artifact ID, filename, trạng thái, phạm vi dữ liệu mô phỏng hoặc ý nghĩa kiểm soát, phải đối chiếu nguồn canonical trước khi ghi nhận; không dùng tên rút gọn hay filename biến thể thay thế /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md.

Mục đích, điều kiện sử dụng và thẩm quyền

Mục đích. TMPL-UAT-SIGN-002 là mẫu theo dõi ký xác nhận UAT. UAT (User Acceptance Testing — kiểm thử chấp nhận người dùng) kiểm tra hệ thống có đáp ứng kịch bản nghiệp vụ và tiêu chí chấp nhận đã xác định hay không. Mẫu tạo bản ghi kiểm soát cho từng quyết định ký, từ chối ký, ký có điều kiện hoặc cần leo thang. Giá trị mẫu là nối người quyết định, phạm vi kiểm thử, bằng chứng, ngoại lệ và hành động tiếp theo; không thay thế test case, defect log hoặc phê duyệt triển khai.

Nội dung	Quy định áp dụng
Dùng khi	Một phạm vi UAT Nova Foods mô phỏng đã có test basis: yêu cầu, business rule, acceptance criteria, kịch bản UAT và kết quả thực thi. Người có vai trò nghiệp vụ cần ghi nhận quyết định về mức chấp nhận phạm vi đó.
Không dùng khi	Chưa có phạm vi kiểm thử xác định; chưa chạy UAT; bằng chứng chỉ là ý kiến miệng; cần ghi defect kỹ thuật chi tiết; cần phê duyệt production, pháp lý, kế toán, thuế, bảo mật hoặc cấu hình ERP thực tế. Các việc này cần artifact và thẩm quyền riêng.
Đơn vị áp dụng	Nova Foods Trading & Manufacturing là case study giáo dục mô phỏng. Mọi tên người, giao dịch, số liệu, kết quả và bằng chứng trong mẫu phải là dữ liệu tổng hợp.
Trạng thái quyết định	IN_REVIEW nghĩa là bản ghi còn được xem xét. Không được suy diễn thành APPROVED, BASELINED, tuân thủ, sẵn sàng production hoặc đã được người dùng chấp thuận.

Owner và người dùng. Owner mẫu là Principal IT Business Analyst / Technical Curriculum Author. Owner giữ cấu trúc, định danh, phiên bản, liên kết truy vết và lịch sử thay đổi; Owner không được tự ký thay Business Owner, QA, Architect, Legal Owner, Accounting Owner, Security hoặc Compliance. Người lập bản ghi thường là BA hoặc UAT Coordinator. Người tiêu thụ gồm Business Owner, UAT Tester, QA Reviewer, Delivery Lead và nhóm dự án cần đọc quyết định cùng bằng chứng. Người ký chỉ xác nhận trong phạm vi vai trò và phạm vi UAT được ghi rõ, không xác nhận toàn bộ ERP.

Điều kiện đầu vào. Trước khi tạo bản ghi ký xác nhận, phải có: phạm vi UAT duy nhất; phiên bản build hoặc cấu hình mô phỏng được nhận diện; test case và kết quả; defect hoặc exception đang mở; liên kết requirement, business rule hoặc acceptance criteria; danh tính vai trò người quyết định; và bằng chứng truy cập được. Lý do: ký xác nhận là quyết định dựa trên bằng chứng; thiếu một đầu vào làm quyết định không truy vết được về điều đã kiểm thử.

Nhóm đầu vào	Điều phải kiểm tra	Xử lý khi thiếu
Phạm vi	Có module, quy trình, release hoặc kịch bản UAT xác định	Không tạo kết luận ký xác nhận
Bằng chứng	Có kết quả chạy, ngày giờ theo Asia/Ho_Chi_Minh, người thực hiện và tham chiếu evidence	Ghi trạng thái cần bổ sung bằng chứng
Ngoại lệ	Defect, rủi ro hoặc giới hạn đã biết có ID và owner xử lý	Leo thang nếu ngoại lệ ảnh hưởng quyết định chấp nhận
Truy vết	Liên kết dùng ID canonical, không tự tạo ID thay thế	Trả về BA/UAT Coordinator để sửa liên kết

Artifact đầu ra. Bản ghi hoàn chỉnh là đầu vào cho UAT summary, defect triage, release readiness review và decision log của corpus. Bản ghi chỉ truyền đạt quyết định UAT cùng điều kiện và ngoại lệ đã ghi; không tự tạo release approval hay production authorization. Nếu quyết định là ký có điều kiện, downstream artifact phải giữ nguyên điều kiện, owner, hạn xử lý và tiêu chí đóng; không được rút gọn thành “đã ký”.

Thẩm quyền và leo thang. Business Owner quyết định mức chấp nhận nghiệp vụ trong case mô phỏng. QA Reviewer đánh giá đầy đủ bằng chứng kiểm thử, không thay Business Owner quyết định nghiệp vụ. Architect quyết định tác động kiến trúc; Security xử lý rủi ro bảo mật; Legal Owner, Accounting Owner và Compliance xử lý diễn giải thuộc lĩnh vực của họ. BA tổng hợp vấn đề và bảo toàn truy vết, không tự chuyển rủi ro chuyên môn thành quyết định ký. Leo thang ngay khi phạm vi ký mâu thuẫn với yêu cầu hoặc business rule canonical, có defect mức nghiêm trọng chưa được chấp nhận rõ, thiếu bằng chứng, có dữ liệu cá nhân hoặc nghĩa vụ pháp lý, kế toán, an toàn thực phẩm chưa được vai trò có thẩm quyền xác minh, hoặc người ký không có quyền quyết định phạm vi ghi nhận.

Định danh Manifest, Liên kết Canonical và Nghĩa vụ Kiểm soát Thay đổi

Template này có định danh canonical TMPL-UAT-SIGN-002 và tệp được kiểm soát /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md. Giữ nguyên cả ID và tên tệp khi tạo liên kết, kiểm tra chất lượng, ghi nhận bằng chứng hoặc tham chiếu chéo. Lý do: TMPL-UAT-SIGN-002 là khóa truy vết; đổi chuỗi, dịch ID hoặc tạo tên rút gọn sẽ làm đứt liên kết giữa manifest, template và bản ghi UAT.

Hạng mục	Giá trị kiểm soát	Cách dùng
Manifest nguồn chân lý	TEMPLATE_MANIFEST	Kiểm tra template có được đăng ký, đúng phạm vi và đúng đường dẫn trước khi sửa nội dung.
Tệp manifest	/01-curriculum/TEMPLATE_MANIFEST.md	Bản sao hoặc bản xuất không thay thế tệp này.
ID template	TMPL-UAT-SIGN-002	Dùng nguyên dạng trong traceability, review log và change record.
Tệp template	/03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md	Không đổi tên để phản ánh dự án, khách hàng hoặc lần chạy UAT.
Registry ID	TRACEABILITY_ID_REGISTRY	Kiểm tra quy tắc đặt và sử dụng ID truy vết.
Tệp registry	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nguồn kiểm soát cho định danh, không phải nguồn tạo approval.
Manifest chapter	CHAPTER_MANIFEST	Nguồn kiểm soát liên kết chapter của curriculum.
Tệp manifest chapter	/01-curriculum/CHAPTER_MANIFEST.md	Chỉ ghi chapter khi manifest có entry xác nhận; dữ liệu đầu vào hiện có không cung cấp chapter ID riêng cho TMPL-UAT-SIGN-002.
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Chỉ tham chiếu rule đã đăng ký; template không tự tạo rule Nova Foods.
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	Kiểm tra tên trường, ý nghĩa dữ liệu và ranh giới dữ liệu logic khi có liên kết.

Nguồn phương pháp cho nội dung UAT gồm ISTQB CTFL Syllabus v4.0.1, dùng cho thuật ngữ kiểm thử và test basis, tức tập đầu vào làm căn cứ thiết kế hoặc đánh giá kiểm thử. BABOK Guide Version 3 chỉ dùng cho thuật ngữ và thực hành BA. Hai nguồn này không cấp thẩm quyền phê duyệt UAT, không xác nhận cấu hình ERP Nova Foods, không tạo nghĩa vụ pháp lý. URL và phân loại nguồn phải giữ theo /00-research/00_SOURCE_MAP.md; không tự gán số trang, điều khoản hoặc trích dẫn không được xác minh.

Mọi thay đổi ảnh hưởng ID, tên tệp, phạm vi template, liên kết chapter, nguồn, traceability hoặc ý nghĩa trường phải được ghi trong change history của artifact và đối chiếu với TEMPLATE_MANIFEST, CHAPTER_MANIFEST và TRACEABILITY_ID_REGISTRY. Không sửa im lặng, không gọi thay đổi là baseline, approval hoặc production-ready. Nếu manifest, registry và template mâu thuẫn, dừng thay đổi; Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề, giữ nguyên bằng chứng mâu thuẫn và chuyển vai trò có thẩm quyền quyết định.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi ID nghiệp vụ, dữ liệu UAT, người ký, ngày ký, quyết định và bằng chứng trong các Tier sau phải là dữ liệu tổng hợp; không suy diễn thành hồ sơ doanh nghiệp thật, phê duyệt thật hoặc xác nhận tuân thủ.

2. Tier 2 ? Blank Copy-Paste-Ready Template

Cách dùng: Sao chép toàn bộ mẫu này cho từng hồ sơ UAT Sign-off Tracking. UAT (User Acceptance Testing) là kiểm thử chấp nhận người dùng: người dùng nghiệp vụ đánh giá giải pháp theo test basis, tức tập yêu cầu, quy tắc, thiết kế và tiêu chí chấp nhận làm căn cứ kiểm thử. Thay toàn bộ giá trị trong dấu < > bằng dữ liệu hồ sơ. Không coi việc điền mẫu là phê duyệt, baseline hoặc quyền dùng production.

2.1. Nhận diện và kiểm soát hồ sơ

Trường	Giá trị cần điền	Hướng dẫn điền
UAT Sign-off Record ID	<ID hồ sơ UAT sign-off đã đăng ký>	Dùng ID canonical từ TRACEABILITY_ID_REGISTRY; không tự tạo biến thể ID.
Template ID	TMPL-UAT-SIGN-002	Giữ nguyên ID template.
Tên tệp hồ sơ	<tên-tệp-uAT-sign-off-theo-quy-ước>.md	Dùng tên tệp được kiểm soát; không ghi đường dẫn tạm hoặc tệp cá nhân.
Hệ thống/phạm vi	<tên hệ thống hoặc module ERP>	Nêu đúng phạm vi kiểm thử; không ghi phạm vi rộng hơn test basis.
Đợt UAT	<mã và tên đợt UAT>	Phân biệt rõ đợt, sprint, release hoặc hotfix nếu có.
Status	IN_REVIEW	Giữ IN_REVIEW khi chưa có quyết định được ghi nhận bởi vai trò có thẩm quyền.
Phiên bản hồ sơ	<phiên bản, ví dụ v0.9.0>	Tăng phiên bản theo quy tắc kiểm soát thay đổi của artifact.
Ngày cập nhật	<YYYY-MM-DD>	Dùng lịch Gregorian, múi giờ Asia/Ho_Chi_Minh.
Locale và tiền tệ	vi-VN / Asia/Ho_Chi_Minh / VND	Giữ nguyên nếu hồ sơ thuộc corpus Nova Foods.
Phân loại dữ liệu	<PUBLIC_INTERNAL_CONFIDENTIAL_RESTRICTED>	Chọn phân loại đã được dự án quy định; không đưa bí mật vào hồ sơ.
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp	Giữ nguyên với hồ sơ thuộc corpus.

2.2. Mục tiêu, phạm vi và test basis

Trường	Giá trị cần điền	Hướng dẫn điền
Mục tiêu UAT	<mục tiêu nghiệp vụ có thể kiểm tra>	Viết kết quả cần xác nhận, không viết hoạt động mơ hồ.
Quy trình nghiệp vụ	<tên quy trình đầu-cuối>	Nêu điểm bắt đầu và điểm kết thúc quy trình.
Trong phạm vi	<danh sách chức năng, dữ liệu, vai trò, tích hợp được kiểm thử>	Mỗi mục phải có liên kết tới test case hoặc requirement.
Ngoài phạm vi	<danh sách chức năng, dữ liệu, vai trò, tích hợp không kiểm thử>	Nêu lý do loại trừ và owner quyết định khi có.
Môi trường UAT	<tên hoặc ID môi trường>	Nêu môi trường dùng để thực thi; không ghi thông tin truy cập bí mật.
Test basis	<ID requirement, business rule, acceptance criteria, thiết kế hoặc backlog item>	Mỗi ID phải tồn tại trong artifact canonical liên quan.
Nguồn quy tắc nghiệp vụ	<ID từ CANONICAL_BUSINESS_RULES hoặc Verification required>	Không tự tuyên bố quy tắc pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu.
Nguồn dữ liệu	<mô tả dữ liệu tổng hợp và ID bộ dữ liệu>	Xác nhận không dùng dữ liệu cá nhân hoặc dữ liệu production thật.
Giả định	<giả định kiểm thử>	Nêu bằng chứng hoặc lý do khiến giả định cần thiết.
Phụ thuộc	<hệ thống, đội ngũ, dữ liệu, quyền hoặc lịch trình phụ thuộc>	Nêu tác động nếu phụ thuộc không sẵn sàng.

2.3. Tổng hợp thực thi và quyết định

Chỉ số	Giá trị cần điền	Hướng dẫn điền
Tổng số test case kế hoạch	<số nguyên không âm>	Đếm test case thuộc phạm vi UAT.
Passed	<số nguyên không âm>	Test case có kết quả đạt theo tiêu chí chấp nhận.
Failed	<số nguyên không âm>	Test case không đạt; phải có defect hoặc exception liên kết.
Blocked	<số nguyên không âm>	Test case không thể chạy; nêu nguyên nhân trong exception.
Not Run	<số nguyên không âm>	Test case chưa chạy tại thời điểm báo cáo.
Tổng số defect mở	<số nguyên không âm>	Chỉ đếm defect liên quan phạm vi UAT.
Defect mức nghiêm trọng cao còn mở	<số nguyên không âm>	Dùng thang severity do dự án xác định.
Kết luận thực thi	<PASS_FAIL_CONDITIONAL_PASS_NOT_READY>	Chọn theo bằng chứng test case, defect và exception; không thay quyết định sign-off.
Đề xuất quyết định	<SIGN_OFF_APPROVE_WITH_EXCEPTIONS_REJECT_DEFER>	Đây là đề xuất của người lập, không phải phê duyệt.
Lý do đề xuất	<lý do liên kết chỉ số, defect, exception và tiêu chí>	Nêu cầu nối: bằng chứng nào dẫn tới đề xuất nào.

2.4. Theo dõi test case và bằng chứng

Test Case ID	Mô tả kịch bản	Test Basis ID	Người thực thi	Ngày giờ thực thi	Kết quả	Evidence ID/URL	Defect/Exception ID	Nhận xét
<ID test case canonical>	<mục tiêu và dữ liệu đầu vào tổng hợp>	<ID nguồn yêu cầu hoặc rule>	<vai trò hoặc tên dữ liệu tổng hợp>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>	<PASSED_FAILED_BLOCKED_NOT_RUN>	<ID bằng chứng hoặc URL kho kiểm soát>	<ID defect, exception hoặc N/A>	<kết quả quan sát và liên kết tiêu chí>
<ID test case canonical>	<mục tiêu và dữ liệu đầu vào tổng hợp>	<ID nguồn yêu cầu hoặc rule>	<vai trò hoặc tên dữ liệu tổng hợp>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>	<PASSED_FAILED_BLOCKED_NOT_RUN>	<ID bằng chứng hoặc URL kho kiểm soát>	<ID defect, exception hoặc N/A>	<kết quả quan sát và liên kết tiêu chí>
<ID test case canonical>	<mục tiêu và dữ liệu đầu vào tổng hợp>	<ID nguồn yêu cầu hoặc rule>	<vai trò hoặc tên dữ liệu tổng hợp>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>	<PASSED_FAILED_BLOCKED_NOT_RUN>	<ID bằng chứng hoặc URL kho kiểm soát>	<ID defect, exception hoặc N/A>	<kết quả quan sát và liên kết tiêu chí>

2.5. Đăng ký exception và rủi ro còn lại

Exception ID	Điều kiện kích hoạt	Mô tả	Bằng chứng	Tác động nghiệp vụ	Quyết định xử lý	Owner xử lý	Hạn xử lý	Trạng thái
<ID exception canonical>	<điều kiện khiến UAT không thể kết luận đầy đủ>	<mô tả sự kiện hoặc khoảng trống>	<Evidence ID hoặc liên kết kho kiểm soát>	<tác động định lượng hoặc định tính>	<ACCEPT_DEFER_FIX_RETEST_ESCALATE>	<vai trò có trách nhiệm>	<YYYY-MM-DD hoặc N/A>	<OPEN_MONITORING_CLOSED>
<ID exception canonical>	<điều kiện khiến UAT không thể kết luận đầy đủ>	<mô tả sự kiện hoặc khoảng trống>	<Evidence ID hoặc liên kết kho kiểm soát>	<tác động định lượng hoặc định tính>	<ACCEPT_DEFER_FIX_RETEST_ESCALATE>	<vai trò có trách nhiệm>	<YYYY-MM-DD hoặc N/A>	<OPEN_MONITORING_CLOSED>

2.6. Ma trận truy vết và quyết định sign-off

Traceability Link ID	Nguồn	ID nguồn	Đích	ID đích	Bằng chứng cầu nối	Trạng thái liên kết
<ID liên kết canonical>	<requirement_rule_acceptance-criteria>	<ID canonical>	<test-case_defect_exception_sign-off-record>	<ID canonical>	<Evidence ID hoặc diễn giải kiểm chứng>	<VALID_GAP_CONFLICT>
<ID liên kết canonical>	<requirement_rule_acceptance-criteria>	<ID canonical>	<test-case_defect_exception_sign-off-record>	<ID canonical>	<Evidence ID hoặc diễn giải kiểm chứng>	<VALID_GAP_CONFLICT>

Vai trò quyết định	Người được đề cử	Quyết định	Phạm vi quyết định	Căn cứ quyết định	Ngày giờ ghi nhận	Sign-off reference
<Business Owner hoặc vai trò có thẩm quyền>	<họ tên dữ liệu tổng hợp hoặc chức danh>	<APPROVE_APPROVE_WITH_EXCEPTIONS_REJECT_DEFER_PENDING>	<phạm vi chức năng hoặc release>	<ID test summary, exception, defect và evidence>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A>	<ID chữ ký điện tử, biên bản hoặc N/A>
<QA Owner hoặc vai trò có thẩm quyền>	<họ tên dữ liệu tổng hợp hoặc chức danh>	<APPROVE_APPROVE_WITH_EXCEPTIONS_REJECT_DEFER_PENDING>	<phạm vi chất lượng được xác nhận>	<ID test summary, exception, defect và evidence>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A>	<ID chữ ký điện tử, biên bản hoặc N/A>
<Technical Owner hoặc vai trò có thẩm quyền>	<họ tên dữ liệu tổng hợp hoặc chức danh>	<APPROVE_APPROVE_WITH_EXCEPTIONS_REJECT_DEFER_PENDING>	<phạm vi kỹ thuật được xác nhận>	<ID test summary, exception, defect và evidence>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A>	<ID chữ ký điện tử, biên bản hoặc N/A>

2.7. Lịch sử phiên bản và review

Phiên bản	Ngày giờ	Người cập nhật	Loại thay đổi	Mô tả thay đổi	Lý do và bằng chứng	Review reference
<vX.Y.Z>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>	<vai trò hoặc tên dữ liệu tổng hợp>	<CREATE_UPDATE_CORRECTION>	<trường hoặc nội dung thay đổi>	<ID issue, evidence hoặc yêu cầu thay đổi>	<ID review hoặc N/A>
<vX.Y.Z>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>	<vai trò hoặc tên dữ liệu tổng hợp>	<CREATE_UPDATE_CORRECTION>	<trường hoặc nội dung thay đổi>	<ID issue, evidence hoặc yêu cầu thay đổi>	<ID review hoặc N/A>

Review ID	Reviewer	Vai trò	Phạm vi review	Kết quả	Nhận xét có thể hành động	Ngày giờ
<ID review canonical>	<họ tên dữ liệu tổng hợp hoặc chức danh>	<BA_QA_Business_Owner_Technical_Owner>	<mục hoặc bảng được review>	<ACCEPT_REWORK_ESCALATE>	<vấn đề, bằng chứng, owner và hành động>	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh>

2.8. Tham chiếu bí mật an toàn

Loại bí mật	Tham chiếu an toàn	Mục đích	Owner quyền truy cập	Xác nhận không lộ bí mật
<API key_password_token_certificate hoặc N/A>	<vault://tên-kho/đường-dẫn-tham-chiếu hoặc N/A>	<mục đích kiểm thử>	<vai trò được cấp quyền>	<Không ghi giá trị bí mật, mã OTP, token, mật khẩu hoặc khóa riêng vào hồ sơ>

Xác nhận hoàn tất hồ sơ: <Người lập ghi tên dữ liệu tổng hợp, vai trò, ngày giờ; xác nhận hồ sơ phản ánh bằng chứng hiện có và không tạo approval ngầm định.>

Sổ theo dõi ký xác nhận UAT trống

Bản mẫu này ghi nhận UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng): người đại diện nghiệp vụ xác nhận kết quả kiểm thử có đáp ứng tiêu chí chấp nhận hay không. Dùng cho Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp. Mỗi dòng là một đối tượng kiểm soát riêng; không gộp nhiều quyết định vào một dòng.

Trường kiểm soát	Giá trị điền
UAT Sign-off ID	<ID ký xác nhận duy nhất, ví dụ UAT-SO-YYYY-NNN; không tái dùng>
Tên phạm vi UAT	<tên quy trình, chức năng hoặc bản phát hành được kiểm thử>
Artifact ID liên quan	<ID artifact canonical, giữ nguyên định dạng registry>
Tệp kiểm soát	<đường dẫn tệp canonical, ví dụ /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md>
Tổ chức/case study	<Nova Foods Trading & Manufacturing — mô phỏng giáo dục>
Loại dữ liệu	<Dữ liệu tổng hợp>
Status tài liệu	<IN_REVIEW | APPROVED | REJECTED | SUPERSEDED>
Version	<vX.Y.Z>
Ngày ghi nhận	<YYYY-MM-DD>
Thời điểm ghi nhận	<YYYY-MM-DDTHH:MM:SS+07:00>
Múi giờ	<Asia/Ho_Chi_Minh>
Locale và tiền tệ	<vi-VN; VND>
Owner hồ sơ	<họ tên hoặc vai trò chịu trách nhiệm duy trì hồ sơ>
Môi trường UAT	<tên môi trường mô phỏng; URL không chứa bí mật>
Phạm vi trong	<liệt kê chức năng, quy trình, dữ liệu, tích hợp thuộc UAT>
Phạm vi ngoài	<liệt kê rõ chức năng, dữ liệu, tích hợp không được quyết định tại hồ sơ này>
Kết luận tổng	<PENDING | ACCEPTED | ACCEPTED_WITH_CONDITIONS | REJECTED | ESCALATED>
Lý do kết luận	<liên kết bằng chứng và tiêu chí; không ghi ý kiến không có chứng cứ>
Điều kiện hiệu lực	<điều kiện phải hoàn tất trước khi kết luận được dùng; ghi Không áp dụng nếu không có>
Quyền hạn kết luận	<vai trò được phép xác nhận nghiệp vụ; không suy diễn thành phê duyệt production, pháp lý, kế toán hoặc bảo mật>

ID quyết định	Câu hỏi quyết định	Giá trị được phép	Giá trị điền	Bằng chứng bắt buộc	Quy tắc quyết định
<DEC-UAT-NNN>	<Tất cả test case trong phạm vi đã chạy?>	YES, NO, NOT_APPLICABLE	<giá trị>	<ID test execution hoặc evidence>	YES chỉ khi mọi test case bắt buộc có trạng thái PASSED hoặc ngoại lệ đã được chấp nhận có truy vết.
<DEC-UAT-NNN>	<Có defect chặn quy trình nghiệp vụ?>	YES, NO, UNKNOWN	<giá trị>	<ID defect, mức độ, retest evidence>	YES yêu cầu kết luận tổng REJECTED hoặc ESCALATED, trừ khi người có thẩm quyền ghi điều kiện chấp nhận.
<DEC-UAT-NNN>	<Tiêu chí chấp nhận đã được đối chiếu?>	YES, NO, PARTIAL	<giá trị>	<ID requirement, acceptance criteria, test result>	PARTIAL không được dùng cho ACCEPTED không điều kiện.
<DEC-UAT-NNN>	<Có rủi ro pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật cần xác minh?>	YES, NO, UNKNOWN	<giá trị>	<ID issue hoặc nguồn chính thức>	YES hoặc UNKNOWN yêu cầu ESCALATED; BA không tự kết luận chuyên môn thay vai trò có thẩm quyền.
<DEC-UAT-NNN>	<Có thể ký xác nhận theo phạm vi?>	YES, NO, CONDITIONAL	<giá trị>	<tổng hợp ID quyết định, exception, evidence>	YES yêu cầu không còn blocker trong phạm vi; CONDITIONAL yêu cầu từng điều kiện có owner và hạn xử lý.

ID ngoại lệ	Loại ngoại lệ	Mô tả tác động	Severity	Quyết định xử lý	Owner xử lý	Hạn xử lý	Bằng chứng đóng	Trạng thái
<EXC-UAT-NNN>	<DEFECT | DATA | INTEGRATION | ACCESS | PERFORMANCE | SECURITY | COMPLIANCE | OTHER>	<quy trình, người dùng, dữ liệu bị ảnh hưởng>	<BLOCKER | HIGH | MEDIUM | LOW>	<FIX_BEFORE_SIGN_OFF | ACCEPT_WITH_CONDITION | ESCALATE | REJECT_SCOPE>	<vai trò hoặc tên tổng hợp>	<YYYY-MM-DD hoặc NOT_APPLICABLE>	<ID retest, issue, hoặc evidence>	<OPEN | ACCEPTED_RISK | RESOLVED | ESCALATED>

ID bằng chứng	Loại bằng chứng	Vị trí/tham chiếu	Hash hoặc phiên bản	Người tạo	Ngày tạo	Phân loại truy cập	Quy tắc an toàn
<EVD-UAT-NNN>	<TEST_RESULT | SCREENSHOT | EXPORT | API_RESPONSE | DEFECT_RECORD | MEETING_RECORD | OTHER>	<URL nội bộ mô phỏng, đường dẫn tệp, hoặc ID artifact; không chứa secret>	<SHA-256, version, hoặc NOT_APPLICABLE>	<vai trò hoặc tên tổng hợp>	<YYYY-MM-DD>	<PUBLIC_INTERNAL | CONFIDENTIAL | RESTRICTED>	<chỉ tham chiếu secret bằng secret://<vault>/<path>#<key>; không ghi mật khẩu, token, API key, cookie, dữ liệu cá nhân thô>

ID traceability	Loại nguồn	ID/đường dẫn nguồn	Phiên bản nguồn	Mối liên kết	Kết quả đối chiếu	Người đối chiếu	Ngày đối chiếu
<TRC-UAT-NNN>	<REQUIREMENT | BUSINESS_RULE | DATA_DICTIONARY | TEST_CASE | DEFECT | EVIDENCE | SOURCE>	<ID canonical hoặc đường dẫn canonical>	<vX.Y.Z hoặc trạng thái nguồn>	<VERIFIES | DERIVES_FROM | BLOCKED_BY | EXCEPTION_TO | EVIDENCES>	<MATCHED | PARTIAL | NOT_MATCHED | PENDING>	<vai trò hoặc tên tổng hợp>	<YYYY-MM-DD>

Version	Ngày	Loại thay đổi	Mô tả thay đổi	Người ghi nhận	Lý do	Ảnh hưởng đến kết luận	Tham chiếu evidence
<vX.Y.Z>	<YYYY-MM-DD>	<CREATE | UPDATE | CORRECTION | SUPERSEDE>	<mô tả thay đổi cụ thể>	<vai trò hoặc tên tổng hợp>	<lý do có thể kiểm tra>	<NONE | REQUIRES_REVIEW | INVALIDATES_SIGN_OFF>	<EVD-UAT-NNN hoặc NOT_APPLICABLE>

ID review/sign-off	Loại hoạt động	Vai trò bắt buộc	Người thực hiện	Phạm vi xem xét hoặc ký	Kết quả	Ngày	Chữ ký điện tử/tham chiếu	Điều kiện hoặc từ chối
<REV-UAT-NNN>	<PREPARE | REVIEW | QA_REVIEW | BUSINESS_SIGN_OFF | ESCALATION_REVIEW>	<BA | QA | Business Owner | Product Owner | Security | Legal | Accounting | Other>	<tên tổng hợp hoặc chức danh>	<ID quyết định, exception, evidence được xem xét>	<PENDING | REVIEWED | SIGNED | REJECTED | ESCALATED>	<YYYY-MM-DD>	<ID hệ thống ký hoặc NOT_APPLICABLE>	<điều kiện cụ thể hoặc Không áp dụng>

ACCEPTED chỉ xác nhận phạm vi UAT đã ghi. Không xác nhận baseline, triển khai production, tuân thủ pháp lý, quyết định kế toán, an toàn thực phẩm hoặc bảo mật. Mọi kết luận phải nối được từ quyết định đến evidence và traceability; thiếu một liên kết thì giữ PENDING hoặc ESCALATED.

Hướng dẫn trường, giá trị hợp lệ, kiểm tra và điều kiện điền

Tier 2 là mẫu trống dùng để ghi nhận theo dõi UAT sign-off, trong đó UAT sign-off là xác nhận kết quả User Acceptance Testing, tức kiểm thử chấp nhận bởi người dùng đại diện. Mỗi dấu <...> phải được thay bằng dữ liệu cụ thể trước khi chuyển sang Tier 3. Không dùng giá trị mơ hồ như N/A nếu trường có điều kiện áp dụng; ghi rõ lý do và liên kết bằng chứng.

Nhóm trường	Placeholder bắt buộc	Hướng dẫn điền	Giá trị hợp lệ	Quy tắc kiểm tra
Định danh hồ sơ	<UAT sign-off record ID>	Dùng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY.	Chuỗi ID canonical đã tồn tại.	Không tự tạo tiền tố, không sửa chữ hoa, không dùng lại ID của hồ sơ khác.
Phạm vi kiểm thử	<module or business process name>	Nêu module ERP hoặc quy trình nghiệp vụ được kiểm thử.	Tên đúng theo artifact nguồn đã liên kết.	Phải khớp tên trong test scope hoặc requirement source; không suy diễn phạm vi mới.
Bản phát hành	<release version>	Ghi version build, package hoặc môi trường được kiểm thử.	Version có định dạng dự án, ví dụ <vX.Y.Z> nếu dự án quy định.	Không ghi “latest”, “current” hoặc ngày thay cho version.
Môi trường	<UAT environment identifier>	Chỉ môi trường thực hiện kiểm thử.	<UAT>, <SIT>, <training> chỉ khi artifact nguồn cho phép.	Sign-off UAT chỉ hợp lệ nếu môi trường là UAT; môi trường khác phải ghi ngoại lệ.
Kỳ kiểm thử	<test execution start datetime> và <test execution end datetime>	Ghi thời điểm theo Asia/Ho_Chi_Minh.	ISO 8601 có lệch giờ, ví dụ <YYYY-MM-DDThh:mm:ss+07:00>.	Thời điểm kết thúc không trước thời điểm bắt đầu.
Người xác nhận	<business role>, <reviewer name or approved role reference>	Ghi vai trò nghiệp vụ và người hoặc tham chiếu vai trò thực hiện review.	Vai trò có trong RACI hoặc nguồn phân công.	Không ghi rằng người dùng đã phê duyệt nếu chưa có bằng chứng sign-off.
Trạng thái	<sign-off status>	Chọn trạng thái hiện tại của hồ sơ.	DRAFT, IN_REVIEW, APPROVED, REJECTED, CONDITIONALLY_APPROVED, WITHDRAWN.	Với corpus hiện hành, không tự gán APPROVED hoặc BASELINED; trạng thái artifact là IN_REVIEW.
Quyết định	<sign-off decision>	Ghi kết luận cho phạm vi đã nêu, không thay thế quyết định release production.	ACCEPT, ACCEPT_WITH_CONDITIONS, REJECT, NO_DECISION.	ACCEPT yêu cầu mọi tiêu chí bắt buộc đạt và không còn defect chặn. NO_DECISION yêu cầu nêu lý do.
Defect	<open defect ID>	Ghi ID defect canonical cho từng lỗi còn mở.	ID đã tồn tại trong defect log hoặc <none> khi không có lỗi mở.	Không dùng <none> nếu bảng bằng chứng có lỗi chưa đóng.
Mức nghiêm trọng	<defect severity>	Phân loại tác động lỗi theo quy ước dự án.	BLOCKER, CRITICAL, MAJOR, MINOR, TRIVIAL.	BLOCKER hoặc CRITICAL mở không cho phép ACCEPT; cần REJECT hoặc NO_DECISION, trừ khi thẩm quyền phù hợp ghi quyết định ngoại lệ có bằng chứng.
Điều kiện chấp nhận	<acceptance condition>	Nêu điều kiện đo được cần hoàn tất sau sign-off có điều kiện.	Câu điều kiện có chủ thể, hành động, hạn hoàn tất, bằng chứng.	Chỉ bắt buộc khi quyết định là ACCEPT_WITH_CONDITIONS. Không dùng khi ACCEPT không điều kiện.
Ngoại lệ	<exception ID and rationale>	Ghi ngoại lệ, lý do, rủi ro, owner xử lý và hạn xử lý.	ID ngoại lệ đã đăng ký hoặc <no exception>.	Mỗi ngoại lệ phải liên kết requirement, test case hoặc defect bị ảnh hưởng. Không biến ngoại lệ thành chấp thuận rủi ro ngầm định.
Bằng chứng	<evidence ID>, <evidence location>, <evidence capture datetime>	Liên kết ảnh chụp, log, test execution result hoặc biên bản review.	ID và đường dẫn kiểm soát được; thời gian theo Asia/Ho_Chi_Minh.	Bằng chứng phải đọc được với người có quyền; không chèn secret, dữ liệu cá nhân thật hoặc dữ liệu production.
Truy vết	<requirement ID>, <business rule ID>, <test case ID>, <defect ID>	Ghi liên kết nguồn đến kết quả kiểm thử.	Chỉ ID canonical từ artifact nguồn.	Mỗi quyết định phải có ít nhất một liên kết test case và một liên kết requirement hoặc business rule, trừ khi phạm vi chỉ là vận hành tài liệu và có lý do ghi rõ.
Version hồ sơ	<document version> và <change summary>	Ghi version tài liệu và thay đổi có ảnh hưởng nội dung.	Version theo quy ước corpus; mô tả thay đổi kiểm chứng được.	Không sửa im lặng. Version mới không tự tạo baseline hay approval.
Review	<review status>, <reviewer role>, <review datetime>, <review finding>	Ghi từng kết quả review, kể cả không có phát hiện.	NOT_STARTED, IN_REVIEW, CHANGES_REQUESTED, COMPLETED.	COMPLETED chỉ nghĩa review hoàn tất; không đồng nghĩa sign-off hoặc approval.

Điều kiện điền theo quyết định. Nếu <sign-off decision> là ACCEPT, trường <open defect ID> phải là <none> hoặc chỉ chứa lỗi đã được đánh giá không ảnh hưởng phạm vi, kèm bằng chứng và thẩm quyền phù hợp. Nếu là ACCEPT_WITH_CONDITIONS, phải điền <acceptance condition>, <condition owner role>, <target completion datetime>, <residual risk> và <follow-up evidence ID>. Nếu là REJECT, phải điền ít nhất một defect hoặc tiêu chí thất bại, tác động nghiệp vụ và hành động quay lại kiểm thử. Nếu là NO_DECISION, phải điền nguyên nhân thiếu quyết định, người cần quyết định theo vai trò và dữ liệu còn thiếu. Nếu không có ngoại lệ, ghi đúng <no exception>; không để ô trống.

Tham chiếu bí mật an toàn. Không ghi mật khẩu, API key, access token, cookie phiên, chuỗi kết nối, mã OTP, dữ liệu nhận dạng cá nhân hoặc dữ liệu production trong hồ sơ, ảnh chụp hay log. Khi bằng chứng cần chứng minh quyền truy cập hoặc tích hợp, dùng mẫu <secret reference: vault-path-or-secret-ID; access controlled; secret value not recorded>. Ví dụ này chỉ mô tả dạng tham chiếu, không phải secret thật. Bằng chứng phải che giá trị bí mật và chỉ nêu vị trí kho bí mật, owner quyền truy cập, mục đích kiểm tra và thời điểm kiểm tra. Yêu cầu này giảm nguy cơ lộ thông tin; bằng chứng là nguyên tắc bảo mật của corpus và nguồn OWASP chỉ dùng làm good practice, không phải xác nhận tuân thủ.

Ranh giới Nova Foods. Mọi trường Tier 2 chỉ là cấu trúc tái sử dụng cho Nova Foods Trading & Manufacturing mô phỏng giáo dục, dùng dữ liệu tổng hợp. Trường liên quan pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc phải ghi <Verification required: authorized role and official source> khi chưa được xác minh từ nguồn chính thức và vai trò có thẩm quyền.

3. Tier 3 ? Fully Completed Nova Foods Case: Core Record

Case Nova Foods Trading & Manufacturing là mô phỏng giáo dục; toàn bộ người, giao dịch, ID, ngày và số tiền dưới đây là dữ liệu tổng hợp. UAT (User Acceptance Testing — kiểm thử chấp nhận người dùng) kiểm tra người dùng nghiệp vụ có thể hoàn tất mục tiêu công việc. Sign-off là ghi nhận quyết định chấp nhận, chấp nhận có điều kiện, từ chối hoặc chưa quyết định; không phải phê duyệt triển khai production.

Trường	Giá trị hoàn chỉnh
UAT Sign-off ID	UATSO-NF-2026-0087
Tên hồ sơ	Theo dõi sign-off UAT cho đối soát ba bên hóa đơn mua nguyên liệu
Artifact ID	TMPL-UAT-SIGN-002
Tệp được kiểm soát	/03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md
Trạng thái hồ sơ	IN_REVIEW
Phiên bản hồ sơ	v0.9.0
Ngày lập	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN, VND
Đơn vị nghiệp vụ mô phỏng	Nova Foods Trading & Manufacturing
Phân hệ ERP mô phỏng	Procurement, Inventory, Accounts Payable
Môi trường kiểm thử	UAT-NF-SIM-01
Phạm vi phát hành kiểm thử	REL-NF-ERP-0.9.0-UAT-02
Chức năng kiểm thử	Đối soát ba bên giữa đơn mua hàng, biên nhận hàng và hóa đơn nhà cung cấp trước khi tạo đề nghị thanh toán
Nhu cầu nghiệp vụ	Ngăn tạo đề nghị thanh toán khi số lượng nhận hoặc đơn giá hóa đơn vượt dữ liệu đã được đặt mua và nhận kho.
Bằng chứng cho nhu cầu	Giao dịch mô phỏng PO-NF-260731-0142 có số lượng đặt 500 kg, biên nhận GRN-NF-260801-0096 xác nhận 480 kg, nhưng hóa đơn INV-SYN-VAT-260805-118 ghi 500 kg. Chênh 20 kg tạo nguy cơ thanh toán vượt hàng đã nhận.
Suy luận kiểm thử	Vì quy trình chỉ an toàn khi ERP chặn hoặc đưa vào ngoại lệ phần chênh lệch, UAT phải xác minh trạng thái hóa đơn không được chuyển sang sẵn sàng thanh toán khi chênh lệch chưa xử lý.
Người lập hồ sơ	Lê Minh Anh — Senior Business Analyst, nhân sự mô phỏng
Người thực hiện UAT	Trần Quốc Bảo — Purchasing Supervisor, nhân sự mô phỏng
Người xác nhận kết quả nghiệp vụ	Phạm Thu Hà — Accounts Payable Lead, nhân sự mô phỏng
Vai trò có thẩm quyền quyết định sign-off	Finance Process Owner, vai trò mô phỏng; chưa có quyết định được ghi nhận
Người giữ quyền cấu hình kỹ thuật	Nguyễn Gia Huy — ERP Functional Consultant, nhân sự mô phỏng
Phân loại nguồn chính	SIMULATED_PROJECT_ARTIFACT
Nguồn quyết định nghiệp vụ	PROJECT_ASSUMPTION — quy tắc chặn thanh toán vượt hàng nhận là giả định học liệu, không phải quy định vận hành thật
Nguồn thuật ngữ kiểm thử	PRIMARY_STANDARD_REFERENCE — ISTQB CTFL Syllabus v4.0.1, dùng cho thuật ngữ UAT và kiểm thử; không suy diễn yêu cầu ERP cụ thể
Nguồn pháp lý hoặc kế toán	VERIFICATION_REQUIRED — mọi diễn giải về hóa đơn, chứng từ, kế toán và thuế cần Accounting Owner hoặc Legal Owner xác minh từ nguồn chính thức trước khi dùng ngoài học liệu

Dữ liệu giao dịch UAT mô phỏng

Loại dữ liệu	ID	Ngày	Giá trị	Trạng thái trước UAT
Nhà cung cấp	SUP-NF-00418 — Công ty TNHH Nguyên liệu An Phú	2026-07-30	Không áp dụng	Đang hoạt động trong dữ liệu mô phỏng
Mã nguyên liệu	RM-COCO-POWDER-25KG — Bột cacao 25 kg	2026-07-31	500 kg	Được phép mua trong dữ liệu mô phỏng
Đơn mua hàng	PO-NF-260731-0142	2026-07-31	500 kg × 186.000 VND = 93.000.000 VND	APPROVED trong dữ liệu mô phỏng
Biên nhận hàng	GRN-NF-260801-0096	2026-08-01	480 kg × 186.000 VND = 89.280.000 VND	POSTED trong dữ liệu mô phỏng
Hóa đơn nhà cung cấp	INV-SYN-VAT-260805-118	2026-08-05	500 kg × 186.000 VND = 93.000.000 VND	PENDING_MATCH trong dữ liệu mô phỏng
Chênh lệch số lượng	VAR-NF-260805-0031	2026-08-05	20 kg = 3.720.000 VND	OPEN trong dữ liệu mô phỏng
Đề nghị thanh toán	PAYREQ-NF-260805-0074	2026-08-05	93.000.000 VND	BLOCKED trong dữ liệu mô phỏng

Kết quả core record

Hạng mục	Kết quả ghi nhận
Điều kiện khởi tạo	Người dùng nhập hóa đơn INV-SYN-VAT-260805-118 với 500 kg và liên kết hóa đơn tới PO-NF-260731-0142.
Hành vi hệ thống quan sát	ERP mô phỏng đối chiếu 500 kg trên hóa đơn với 480 kg trên biên nhận, tạo VAR-NF-260805-0031 trị giá 3.720.000 VND, đặt hóa đơn PENDING_MATCH và đề nghị thanh toán BLOCKED.
Kết quả UAT	PASS cho kiểm tra chặn đề nghị thanh toán khi hóa đơn vượt số lượng đã nhận.
Quyết định sign-off hiện tại	NO_DECISION
Lý do chưa có quyết định	Finance Process Owner mô phỏng chưa ghi nhận quyết định sign-off trong hồ sơ IN_REVIEW; kết quả PASS của một kịch bản không thay thế quyết định có thẩm quyền.
Tác động nếu kết luận sai	Nếu ghi nhận nhầm là chấp nhận toàn bộ, ERP có thể được hiểu là đủ điều kiện dùng ngoài phạm vi mô phỏng dù chưa có quyết định nghiệp vụ, kiểm thử đầy đủ và xác minh kế toán.
Ranh giới sử dụng	Chỉ dùng làm ví dụ học liệu về theo dõi UAT. Không dùng làm bằng chứng tuân thủ, phê duyệt thanh toán, xác nhận hóa đơn hoặc cho phép triển khai production.

Hồ sơ UAT hoàn chỉnh — Nova Foods mô phỏng

Trường	Giá trị hoàn chỉnh
Template ID	TMPL-UAT-SIGN-002
Tên tệp	/03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md
Trạng thái hồ sơ	IN_REVIEW
Phiên bản	v0.9.0
Ngày lập	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Tổ chức	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Phân loại dữ liệu	Dữ liệu tổng hợp, không dùng cho vận hành hoặc production
UAT Record ID	NF-UAT-2026-0087
Phạm vi kiểm thử chấp nhận người dùng	Luồng tạo đơn bán hàng, kiểm tra hạn mức công nợ, xuất kho và tạo phiếu giao hàng cho khách hàng doanh nghiệp
Mục tiêu	Xác nhận người dùng nghiệp vụ có thể hoàn tất luồng bán hàng chuẩn trong ERP với dữ liệu, quyền và quy tắc mô phỏng đã xác định.
UAT	User Acceptance Testing, kiểm thử chấp nhận người dùng. Đây là hoạt động người dùng nghiệp vụ kiểm tra hệ thống có đáp ứng nhu cầu làm việc hay không, không thay thế kiểm thử kỹ thuật.
Môi trường	UAT-NOVA-ERP-01
Bản dựng kiểm thử	ERP-NF-0.9.0-uat.12
Kho kiểm thử	KHO-HCM-01 — Kho Thành phẩm Hồ Chí Minh, mô phỏng
Kỳ kiểm thử	2026-08-05 08:30 đến 2026-08-07 16:30

Vai trò	Họ tên mô phỏng	Mã người dùng	Trách nhiệm trong UAT	Trạng thái tham gia
Sales Executive	Nguyễn Minh An	NF.UAT.SALES.01	Tạo và xác nhận đơn bán hàng	Đã thực hiện
Credit Controller	Trần Thu Hà	NF.UAT.CREDIT.01	Kiểm tra hạn mức công nợ và quyết định giữ hoặc cho phép đơn	Đã thực hiện
Warehouse Supervisor	Lê Quốc Bình	NF.UAT.WH.01	Xác nhận phân bổ tồn kho, xuất kho và phiếu giao hàng	Đã thực hiện
UAT Coordinator	Phạm Gia Huy	NF.UAT.COORD.01	Ghi nhận kết quả, đối chiếu phạm vi và điều phối xử lý lỗi	Đã thực hiện
Business Owner	Võ Thanh Mai	NF.UAT.BO.01	Có thẩm quyền quyết định chấp nhận, chấp nhận có điều kiện hoặc từ chối	Chưa ra quyết định

Sự kiện nghiệp vụ mô phỏng: khách hàng KH-DOANHNGHIEP-018 đặt 240 thùng sản phẩm SP-NF-TRA-DAO-500ML, đơn giá 168.000 VND mỗi thùng, chưa gồm VAT. Giá trị hàng hóa là 40.320.000 VND. VAT 8% là 3.225.600 VND theo giả định dự án phục vụ kiểm thử; không phải kết luận thuế. Tổng thanh toán là 43.545.600 VND. Hạn mức công nợ mô phỏng của khách hàng là 50.000.000 VND, dư nợ mở đầu là 12.500.000 VND. Tổng phơi nhiễm sau đơn là 56.045.600 VND, vượt hạn mức 6.045.600 VND.

Đối tượng	ID	Dữ liệu đầy đủ	Trạng thái xử lý
Đơn bán hàng	SO-UAT-20260805-0187	240 thùng SP-NF-TRA-DAO-500ML; 40.320.000 VND trước VAT; 43.545.600 VND sau VAT	ON_HOLD_CREDIT
Phiếu kiểm tra tín dụng	CR-UAT-20260805-0041	Hạn mức 50.000.000 VND; phơi nhiễm 56.045.600 VND; vượt 6.045.600 VND	REJECTED
Yêu cầu xuất kho	WR-UAT-20260805-0093	Kho KHO-HCM-01; yêu cầu 240 thùng	BLOCKED
Phiếu giao hàng	DN-UAT-20260805-0068	Không được tạo vì đơn bị giữ tín dụng	NOT_CREATED
Lỗi UAT	DEF-UAT-2026-014	Màn hình Sales hiển thị nút “Tạo phiếu giao hàng” khi đơn ở trạng thái ON_HOLD_CREDIT	OPEN
Lỗi UAT	DEF-UAT-2026-015	API tạo phiếu giao hàng trả 201 Created cho đơn vượt hạn mức khi gọi trực tiếp bằng quyền kho	OPEN

Quy tắc	Giá trị áp dụng	Lý do và hệ quả nếu sai	Phân loại nguồn
BR-UAT-001	Khi tổng phơi nhiễm lớn hơn hạn mức công nợ, hệ thống phải đặt đơn ở ON_HOLD_CREDIT.	Bằng chứng số học: 56.045.600 VND lớn hơn 50.000.000 VND. Nếu sai, đơn vượt kiểm soát tín dụng có thể được xuất kho.	Giả định dự án mô phỏng
BR-UAT-002	Đơn ON_HOLD_CREDIT không được tạo yêu cầu xuất kho hoặc phiếu giao hàng.	Nhu cầu nền: trạng thái tín dụng phải chặn cả giao diện và API, vì chỉ chặn giao diện không ngăn được tích hợp hoặc thao tác kỹ thuật. Nếu sai, kiểm soát nghiệp vụ bị vượt qua.	Giả định dự án mô phỏng; tham chiếu nhận thức OWASP API Security Top 10 2023, không phải yêu cầu pháp lý
BR-UAT-003	Chỉ NF.UAT.CREDIT.01 được đổi đơn từ ON_HOLD_CREDIT sang RELEASED_CREDIT.	Vai trò Credit Controller chịu trách nhiệm đánh giá ngoại lệ tín dụng mô phỏng. Nếu sai, Sales hoặc Kho có thể tự bỏ chặn đơn.	Giả định dự án mô phỏng
BR-UAT-004	Giá trị tiền lưu và hiển thị bằng VND, không có phần lẻ.	Locale corpus là vi-VN, tiền tệ mô phỏng là VND. Nếu sai, tổng tiền và đối chiếu UAT có thể không nhất quán.	Quy ước corpus Nova Foods mô phỏng

Lựa chọn đánh giá	Nội dung	Tiêu chí quyết định	Kết quả
Phương án A	Chấp nhận UAT dù còn DEF-UAT-014 và DEF-UAT-015	Chỉ phù hợp khi lỗi không làm sai quy tắc nghiệp vụ trọng yếu hoặc có kiểm soát bù được xác nhận.	Không chọn. Hai lỗi đều cho phép tiến đến giao hàng trái BR-UAT-002.
Phương án B	Chấp nhận có điều kiện, chặn phát hành bằng quy trình thủ công	Cần bằng chứng quy trình thủ công chặn được cả giao diện và API trong mọi ca sử dụng.	Không chọn. Không có kiểm soát bù được ghi nhận; hồ sơ IN_REVIEW không chứng minh kiểm soát đó tồn tại.
Phương án C	Chưa chấp nhận; sửa lỗi, kiểm thử lại hai đường giao diện và API	Phù hợp khi lỗi phá vỡ kiểm soát tín dụng và có thể gây xuất kho sai.	Khuyến nghị.

Tiêu chí UAT	Kết quả	Cơ sở kết luận
Sales tạo đơn đúng sản phẩm, số lượng, đơn giá và tổng tiền	Đạt	SO-UAT-20260805-0187 lưu 240 thùng, 40.320.000 VND trước VAT và 43.545.600 VND sau VAT.
Hệ thống phát hiện vượt hạn mức	Đạt	CR-UAT-20260805-0041 tính vượt 6.045.600 VND và đặt trạng thái ON_HOLD_CREDIT.
Giao diện chặn tạo phiếu giao hàng cho đơn bị giữ tín dụng	Không đạt	DEF-UAT-2026-014 ghi nhận nút tạo phiếu vẫn hiển thị và thao tác được đến bước xác nhận.
API chặn tạo phiếu giao hàng cho đơn bị giữ tín dụng	Không đạt	DEF-UAT-2026-015 ghi nhận API trả 201 Created, trái BR-UAT-002.
Phân quyền bỏ chặn tín dụng đúng vai trò	Chưa xác nhận	Không thể chạy ca bỏ chặn hợp lệ trước khi sửa cơ chế chặn giao hàng. Trạng thái này là kết quả kiểm thử, không phải khoảng trống tài liệu.

Quyết định UAT hiện hành	Giá trị
Khuyến nghị UAT Coordinator	NOT_READY_FOR_SIGN_OFF
Cơ sở khuyến nghị	Hai lỗi mở phá vỡ quy tắc chặn giao hàng khi đơn vượt hạn mức công nợ.
Thẩm quyền quyết định cuối	Business Owner NF.UAT.BO.01, sau khi nhận kết quả kiểm thử lại và đánh giá rủi ro nghiệp vụ.
Trạng thái sign-off	PENDING_DECISION
Phê duyệt người dùng	Chưa có. IN_REVIEW không phải phê duyệt, baseline hoặc cho phép triển khai production.
Điều kiện đóng hồ sơ	Sửa DEF-UAT-2026-014 và DEF-UAT-2026-015; kiểm thử lại giao diện và API với cùng đơn SO-UAT-20260805-0187; cả hai ca phải chặn tạo DN-UAT-20260805-0068.
Hệ quả nếu ký sai	Hàng có thể được giao cho khách hàng vượt hạn mức công nợ mô phỏng; báo cáo công nợ và kiểm soát xuất kho có thể phản ánh sai trạng thái nghiệp vụ.

Tình huống Nova Foods mô phỏng: quyết định ký xác nhận UAT lô nhập kho

Nova Foods Trading & Manufacturing là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. Bản ghi UAT này kiểm tra luồng nhận hàng mua nguyên liệu cho giao dịch GRN-NF-20260805-0147: 1.250 kg bột mì MF-01, đơn giá mô phỏng 18.400 VND/kg, giá trị hàng 23.000.000 VND. Phạm vi kiểm thử: ERP ghi nhận phiếu nhập kho, cập nhật tồn kho kho WH-HCM-RM01, và tạo dữ liệu chờ đối soát hóa đơn mua. Không xác nhận hạch toán, thuế, hóa đơn điện tử, hay tuân thủ pháp lý.

Trường lõi	Giá trị đã điền
UAT Sign-off ID	UAT-SIGN-NF-20260807-003
Artifact	TMPL-UAT-SIGN-002
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày đánh giá	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Người thực hiện UAT	Nguyễn Minh An, UAT Tester mô phỏng, Procurement Operations
Người đề xuất quyết định	Trần Hải Yến, Senior BA mô phỏng
Thẩm quyền quyết định sign-off	Lê Quốc Bảo, Business Owner mô phỏng, Supply Chain
Quyết định hiện tại	Chưa ký xác nhận; chờ Business Owner mô phỏng quyết định
Phân loại nguồn	PROJECT_ASSUMPTION cho quy trình nghiệp vụ mô phỏng; SYNTHETIC_TEST_DATA cho actor, giao dịch và giá trị VND

Sự kiện thực tế ghi nhận: người kiểm thử tạo phiếu nhận hàng từ PO mô phỏng PO-NF-20260803-0088, nhập số lượng nhận 1.250 kg, rồi xác nhận nhận hàng lúc 2026-08-05 14:32:18. ERP tạo GRN-NF-20260805-0147, tăng tồn khả dụng MF-01 từ 8.400 kg lên 9.650 kg, và gắn trạng thái PENDING_INVOICE_MATCH. Kết quả này khớp dữ liệu nhập và phép tính 8.400 + 1.250 = 9.650 kg.

Hành vi hiện tại: ERP cho phép xác nhận nhận hàng khi số lượng nhận không vượt số lượng chưa nhận trên PO. Với PO này, số lượng đặt là 1.500 kg, đã nhận trước đó 250 kg, nên số lượng còn được nhận là 1.250 kg. ERP chặn thử nghiệm nhập 1.251 kg và trả lỗi Received quantity exceeds remaining PO quantity. Cầu nối suy luận: số lượng còn lại bằng 1.500 - 250 = 1.250 kg; vì 1.251 lớn hơn 1.250, chặn giao dịch bảo vệ tính nhất quán giữa PO và GRN.

Nhu cầu nền: Kho cần tăng tồn ngay sau khi hàng được nhận để kế hoạch sản xuất thấy đúng lượng nguyên liệu khả dụng. Procurement cần không cho nhận vượt PO để tránh ghi nhận hàng chưa được đặt mua hoặc nhập trùng. Finance cần trạng thái chờ đối soát thay vì tự động kết luận hóa đơn hợp lệ; đây là ranh giới nghiệp vụ mô phỏng, không phải diễn giải kế toán hay thuế.

Phương án	Mô tả	Tiêu chí đánh giá	Kết quả
O1	Cho nhận vượt PO không cần quyền đặc biệt	Nhanh thao tác, nhưng rủi ro tồn kho và chi phí sai	Loại
O2	Chặn mọi số lượng vượt PO còn lại	Đúng số lượng PO, kiểm soát đơn giản, truy vết rõ	Khuyến nghị
O3	Cho vượt PO khi có phê duyệt ngoại lệ	Linh hoạt vận hành, nhưng cần quy tắc quyền và bằng chứng riêng	Không thuộc phạm vi ca UAT này

Quy tắc quyết định: chọn O2 khi cùng thỏa ba điều kiện: số lượng GRN không vượt PO còn lại; tồn kho sau nhận bằng tồn trước nhận cộng số lượng GRN; trạng thái sau nhận là PENDING_INVOICE_MATCH. Ca kiểm thử đạt đủ ba điều kiện. Khuyến nghị của Senior BA mô phỏng: Business Owner mô phỏng ký xác nhận có điều kiện cho phạm vi nhận hàng chuẩn theo O2. Business Owner mô phỏng quyết định cuối cùng; Senior BA không có thẩm quyền tự ghi nhận approval.

Hậu quả nếu quyết định sai: chọn O1 có thể làm tồn MF-01 cao hơn hàng thực nhận, gây sai tín hiệu lập kế hoạch sản xuất và đối soát mua hàng. Ký xác nhận khi chưa kiểm tra trạng thái PENDING_INVOICE_MATCH có thể khiến nhóm sau hiểu nhầm GRN đã hoàn tất đối soát hóa đơn. Chọn O3 mà chưa có quy tắc quyền, luồng ngoại lệ và kiểm thử riêng tạo khoảng trống kiểm soát; cần tách thành yêu cầu mới, không gộp vào sign-off này.

4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability

4.1 Ngoại lệ, đường đi âm và bằng chứng UAT

Ca Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Phạm vi là nhận hàng theo PO khi lựa chọn O2: hệ thống chặn số lượng nhận vượt số lượng PO còn lại và đặt GRN hợp lệ ở trạng thái PENDING_INVOICE_MATCH. “Đường đi âm” là thao tác cố ý dùng dữ liệu không hợp lệ để chứng minh kiểm soát chặn đúng, không phải lỗi vận hành thực.

ID	Loại	Tình huống và dữ liệu tổng hợp	Kết quả mong đợi	Bằng chứng tham chiếu	Trạng thái ghi nhận
EXC-UAT-001	Ngoại lệ số lượng	PO PO-NF-202608-001 còn 100 kg nguyên liệu RM-SUGAR-001; người dùng nhập GRN 101 kg	Hệ thống không tạo GRN; hiển thị lỗi Received quantity exceeds remaining PO quantity; tồn kho MF-01 giữ nguyên 500 kg	EVD-UAT-001: ảnh chụp lỗi; EVD-UAT-002: xuất tồn kho trước và sau thao tác	PASS
EXC-UAT-002	Đường đi âm dữ liệu bắt buộc	Người dùng để trống mã lô nhà cung cấp khi nhận 80 kg RM-SUGAR-001	Hệ thống không lưu GRN vì mất dữ liệu truy vết lô; không thay đổi tồn kho	EVD-UAT-003: ảnh chụp kiểm tra trường bắt buộc; EVD-UAT-004: nhật ký thao tác UAT	PASS
EXC-UAT-003	Đường đi âm định danh PO	Người dùng nhập PO PO-NF-202608-999, không có trong tập dữ liệu UAT	Hệ thống không cho tạo GRN; không tạo bản ghi nhận hàng hoặc biến động kho	EVD-UAT-005: ảnh chụp thông báo không tìm thấy PO; EVD-UAT-006: truy vấn danh sách GRN UAT	PASS
EXC-UAT-004	Trạng thái không đúng	Người dùng cố chuyển GRN GRN-NF-202608-001 từ PENDING_INVOICE_MATCH sang trạng thái hoàn tất đối soát hóa đơn trong ca nhận hàng	Chức năng nhận hàng không tự xác nhận hóa đơn; GRN giữ PENDING_INVOICE_MATCH	EVD-UAT-007: ảnh chụp trạng thái; EVD-UAT-008: nhật ký sự kiện trạng thái	PASS
EXC-UAT-005	Rủi ro quyền hạn	Người dùng UAT vai trò Warehouse Receiver thử thao tác sửa số lượng GRN đã ghi nhận 80 kg thành 90 kg	Cần xác minh quyền sửa sau ghi nhận và cơ chế lưu vết trước khi kết luận đạt hoặc không đạt	EVD-UAT-009: ảnh chụp quyền; EVD-UAT-010: nhật ký thay đổi nếu hệ thống cho phép thao tác	VERIFY_REQUIRED

4.2 Giả định và mục cần xác minh

ID	Loại	Nội dung	Cầu nối bằng chứng và lập luận	Owner xác minh	Trạng thái
ASM-UAT-001	Giả định dự án	Warehouse Receiver được phép tạo GRN cho PO đã phát hành	Ca UAT cần một vai trò thao tác để kiểm tra quy tắc số lượng; chưa có ma trận quyền canonical được baseline	Business Owner mô phỏng và Security Owner mô phỏng	OPEN
ASM-UAT-002	Giả định dự án	Tồn đầu MF-01 của RM-SUGAR-001 là 500 kg và GRN hợp lệ 80 kg làm tồn thành 580 kg	Dữ liệu này tạo phép kiểm độc lập: 500 + 80 = 580; chỉ là dữ liệu UAT tổng hợp, không phải tồn kho thực	QA Reviewer mô phỏng	OPEN
VR-UAT-001	Verification required	Quy tắc lưu vết lô nhà cung cấp có bắt buộc với mọi nguyên liệu hay chỉ nhóm nguyên liệu cần truy xuất	EXC-UAT-002 chứng minh kiểm tra trường, nhưng nguồn đầu vào chưa xác nhận phạm vi áp dụng theo loại hàng	Food Safety Owner mô phỏng và Business Owner mô phỏng	OPEN
VR-UAT-002	Verification required	Trạng thái PENDING_INVOICE_MATCH có đủ cho đối soát mua hàng hay cần trạng thái trung gian khác	EXC-UAT-004 chỉ xác nhận ca UAT không tự kết luận hóa đơn hợp lệ; không diễn giải kế toán, thuế hoặc cấu hình production	Accounting Owner mô phỏng	OPEN
VR-UAT-003	Verification required	Quyền sửa GRN sau ghi nhận, lịch sử sửa và phân quyền phê duyệt ngoại lệ	EXC-UAT-005 chưa có ma trận quyền, quy tắc ngoại lệ hoặc bằng chứng thiết kế được xác nhận	Security Owner mô phỏng, Architect mô phỏng, Business Owner mô phỏng	OPEN

4.3 Hồ sơ escalation

Escalation ID	Kích hoạt	Ảnh hưởng	Hồ sơ gửi escalation	Người nhận	Quyết định cần có	Trạng thái
ESC-UAT-001	VR-UAT-001 chưa xác minh phạm vi bắt buộc mã lô	Có thể chặn nhận hàng không cần thiết hoặc thiếu truy vết cho nguyên liệu cần kiểm soát	EXC-UAT-002, EVD-UAT-003, ASM-UAT-001	Food Safety Owner mô phỏng, Business Owner mô phỏng	Xác định phạm vi nguyên liệu phải lưu mã lô và nguồn quyết định	OPEN
ESC-UAT-002	VR-UAT-002 chưa xác minh ý nghĩa trạng thái đối soát	Người đọc có thể hiểu sai GRN đã hoàn tất nghĩa vụ hóa đơn	EXC-UAT-004, EVD-UAT-007, EVD-UAT-008	Accounting Owner mô phỏng	Xác nhận hoặc sửa tên, ý nghĩa và chuyển trạng thái của PENDING_INVOICE_MATCH	OPEN
ESC-UAT-003	VR-UAT-003 chưa xác minh quyền sửa GRN	Rủi ro thay đổi số lượng đã nhận mà thiếu kiểm soát hoặc nhật ký	EXC-UAT-005, EVD-UAT-009, EVD-UAT-010	Security Owner mô phỏng, Architect mô phỏng	Xác định quyền sửa, điều kiện sửa, nhật ký và luồng ngoại lệ	OPEN

Giới hạn sign-off: các dòng PASS chỉ ghi nhận kết quả của dữ liệu UAT tổng hợp trong ca mô phỏng. OPEN và VERIFY_REQUIRED chặn mọi diễn giải rằng quy tắc, quyền, trạng thái, kế toán, pháp lý hoặc vận hành production đã được xác nhận.

Ma trận truy vết đầu cuối cho hồ sơ UAT Nova Foods mô phỏng

Truy vết đầu cuối nối nhu cầu với kết quả kiểm thử để biết mỗi kiểm tra phục vụ lý do nào. NEED là nhu cầu; REQ là yêu cầu; BR là quy tắc nghiệp vụ; AC là tiêu chí chấp nhận; DATA/API là dữ liệu hoặc giao diện lập trình ứng dụng; TC là ca kiểm thử; DEF là lỗi; CR là yêu cầu thay đổi. Chuỗi dưới đây là liên kết học liệu cho Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, không phải baseline hay phê duyệt.

Loại	ID canonical	Nội dung đã hoàn tất cho ca UAT	Nguồn hoặc căn cứ liên kết	Liên kết xuôi	Liên kết ngược	Trạng thái truy vết
NEED	NEED-NF-INV-001	Nhân viên kho cần ghi nhận nhận hàng theo lô để đối chiếu số lượng đơn mua và hỗ trợ truy xuất lô nguyên liệu mô phỏng.	Bối cảnh case study Nova Foods; Luật An toàn thực phẩm dùng cho ngữ cảnh truy xuất, cần xác minh chủ sở hữu miền và pháp lý trước dùng thực tế.	REQ-NF-GR-001	Không có cấp trước trong phạm vi hồ sơ.	Đủ liên kết; chưa baseline.
REQ	REQ-NF-GR-001	ERP phải cho phép tạo phiếu nhận hàng GRN-NF-20260807-001 từ đơn mua PO-NF-20260805-014, gồm mã hàng, mã lô, số lượng nhận và trạng thái kiểm tra chất lượng.	Suy ra từ NEED-NF-INV-001: cần đối chiếu nhận hàng theo lô nên phải lưu giao dịch nhận và dữ liệu lô.	BR-NF-GR-001, AC-NF-GR-001, DATA-NF-GR-001, TC-NF-UAT-001	NEED-NF-INV-001	Đủ liên kết; chưa baseline.
BR	BR-NF-GR-001	Chỉ cho phép xác nhận nhận hàng khi tổng số lượng nhận của từng dòng đơn mua không vượt số lượng còn mở trên đơn mua; đơn vị tính phải khớp đơn mua.	Suy ra từ REQ-NF-GR-001: đối chiếu số lượng chỉ có ý nghĩa khi chặn nhận vượt và tránh đổi đơn vị tính không kiểm soát. Đây là giả định dự án mô phỏng.	AC-NF-GR-001, TC-NF-UAT-001, TC-NF-UAT-002	REQ-NF-GR-001	Đủ liên kết; cần Business Owner xác minh quy tắc trước dùng thực tế.
AC	AC-NF-GR-001	Khi nhập RM-COCO-001, lô LOT-COCO-260807-A, 500 kg, hệ thống lưu phiếu nhận thành công và cập nhật số lượng đã nhận của PO-NF-20260805-014 từ 0 kg thành 500 kg.	Điều kiện quan sát được để chứng minh REQ-NF-GR-001 và BR-NF-GR-001.	TC-NF-UAT-001	REQ-NF-GR-001, BR-NF-GR-001	Đủ liên kết; chưa baseline.
AC	AC-NF-GR-002	Khi nhập 1.001 kg cho dòng đơn mua còn mở 1.000 kg, hệ thống không xác nhận phiếu nhận, không cập nhật tồn kho, hiển thị lỗi Số lượng nhận vượt số lượng còn mở.	Điều kiện quan sát được để kiểm tra đường âm của BR-NF-GR-001.	TC-NF-UAT-002, DEF-NF-UAT-001	BR-NF-GR-001	Đủ liên kết; chưa baseline.
DATA	DATA-NF-GR-001	Payload nhận hàng tổng hợp: goodsReceiptNo=GRN-NF-20260807-001; purchaseOrderNo=PO-NF-20260805-014; itemCode=RM-COCO-001; lotNo=LOT-COCO-260807-A; receivedQuantity=500; uom=kg; qualityStatus=PendingInspection; currency=VND.	Trường dữ liệu tối thiểu để thực hiện REQ-NF-GR-001; tên trường là mô hình logic học liệu, không xác nhận API hay cấu hình ERP.	TC-NF-UAT-001, TC-NF-UAT-002	REQ-NF-GR-001	Đủ liên kết; Architect và Data Owner cần xác minh nếu chuyển thành đặc tả triển khai.
API	API-NF-GR-001	POST /api/v1/goods-receipts nhận payload DATA-NF-GR-001; phản hồi thành công mô phỏng là HTTP 201; phản hồi nhận vượt mô phỏng là HTTP 422.	API là phương án kiểm tra tích hợp cho dữ liệu của REQ-NF-GR-001; không có tài liệu API baseline trong corpus.	TC-NF-UAT-001, TC-NF-UAT-002	DATA-NF-GR-001	Liên kết học liệu; cần Architect xác minh hợp đồng API.
TC	TC-NF-UAT-001	Tạo nhận hàng hợp lệ: gửi 500 kg cho PO-NF-20260805-014; kỳ vọng HTTP 201, phiếu GRN-NF-20260807-001 tồn tại, số lượng đã nhận là 500 kg, tồn kho lô tăng 500 kg.	Kiểm tra trực tiếp AC-NF-GR-001 bằng DATA-NF-GR-001 và API-NF-GR-001.	Không có lỗi hoặc CR được ghi nhận trong ca mô phỏng.	AC-NF-GR-001, DATA-NF-GR-001, API-NF-GR-001	Pass mô phỏng; không phải bằng chứng UAT thực tế.
TC	TC-NF-UAT-002	Tạo nhận hàng vượt: gửi 1.001 kg khi số lượng còn mở là 1.000 kg; kỳ vọng HTTP 422, không tạo phiếu, tồn kho không đổi.	Kiểm tra đường âm của AC-NF-GR-002 và BR-NF-GR-001.	DEF-NF-UAT-001	AC-NF-GR-002, DATA-NF-GR-001, API-NF-GR-001	Fail mô phỏng; lỗi được ghi nhận dưới đây.
DEF	DEF-NF-UAT-001	Kết quả thực thi mô phỏng của TC-NF-UAT-002: API trả HTTP 201, tạo GRN-NF-20260807-002, tăng tồn kho 1.001 kg. Sai khác với kỳ vọng chặn nhận vượt.	So sánh kết quả quan sát với AC-NF-GR-002: điều kiện “không xác nhận” không đạt nên cần bản ghi lỗi.	CR-NF-GR-001	TC-NF-UAT-002, AC-NF-GR-002, BR-NF-GR-001	Open; không có quyết định khắc phục hay phê duyệt đóng lỗi.
CR	CR-NF-GR-001	Đề nghị sửa kiểm tra số lượng còn mở trước khi lưu phiếu nhận; sau sửa phải chạy lại TC-NF-UAT-001 và TC-NF-UAT-002.	DEF-NF-UAT-001 chứng minh quy tắc chưa được thực thi đúng trong mô phỏng.	TC-NF-UAT-001, TC-NF-UAT-002 khi có bản sửa được kiểm soát.	DEF-NF-UAT-001	Open; cần Business Owner, Architect và QA xác minh tác động.

Chuỗi kiểm soát	Kết luận
Chuỗi dương	NEED-NF-INV-001 → REQ-NF-GR-001 → BR-NF-GR-001 → AC-NF-GR-001 → DATA-NF-GR-001/API-NF-GR-001 → TC-NF-UAT-001
Chuỗi âm và xử lý sai khác	REQ-NF-GR-001 → BR-NF-GR-001 → AC-NF-GR-002 → TC-NF-UAT-002 → DEF-NF-UAT-001 → CR-NF-GR-001
Ranh giới baseline	Không ID nào trong bảng có baseline reference hoặc approval reference. Pass mô phỏng chỉ mô tả kết quả tình huống học liệu, không xác nhận hệ thống ERP, quy tắc Nova Foods hay quyền đưa vào production.

Bảng quyết định ký xác nhận UAT cho đợt kiểm thử xuất kho Nova Foods

Nova Foods là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Ký xác nhận UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) chỉ ghi nhận kết quả kiểm thử của phạm vi đang xét; không tạo baseline, phê duyệt người dùng, quyết định production, hay xác nhận tuân thủ pháp lý.

Quyết định dựa trên nguyên tắc đầu vào trước: chỉ có thể đánh giá ký xác nhận khi tồn tại bằng chứng chạy test, kết quả được ghi nhận, và lỗi còn mở được phân loại. Nếu thiếu một đầu vào, trạng thái phải giữ IN_REVIEW vì chưa đủ căn cứ kết luận.

Điều kiện quyết định	Dữ liệu tổng hợp đã ghi nhận	Kết quả ký xác nhận cần ghi	Lý do
Bằng chứng test tồn tại	Có 12 ảnh chụp màn hình, 12 nhật ký kết quả và 1 tệp xuất kết quả cho luồng tạo phiếu xuất kho bán hàng	Đủ điều kiện xem xét	Bằng chứng cho phép đối chiếu thao tác, dữ liệu đầu vào và kết quả thực tế mô phỏng.
Kịch bản mức ưu tiên cao hoàn tất	4 trên 4 kịch bản mức cao đạt kết quả PASS	Đủ điều kiện xem xét	Luồng tạo, duyệt, xuất kho và in phiếu phải có kết quả trước khi đánh giá phạm vi.
Kịch bản mức ưu tiên trung bình hoàn tất	8 trên 8 kịch bản mức trung bình đạt kết quả PASS	Đủ điều kiện xem xét	Các kiểm tra số lượng, đơn vị tính, kho xuất và thông báo lỗi đã có bằng chứng kết quả.
Lỗi chặn còn mở	0 lỗi mức Blocker còn mở	Không chặn ký xác nhận	Lỗi chặn làm người dùng không thể hoàn thành luồng nghiệp vụ đã kiểm thử.
Lỗi nghiêm trọng còn mở	0 lỗi mức Critical còn mở	Không chặn ký xác nhận	Lỗi nghiêm trọng có thể làm sai kết quả nghiệp vụ trọng yếu trong phạm vi UAT.
Lỗi mức cao còn mở	1 lỗi mức High còn mở: thông báo tồn kho âm hiển thị không dấu tiếng Việt	Ký xác nhận có điều kiện	Luồng từ chối xuất kho vẫn hoạt động; lỗi hiển thị cần được theo dõi trước khi dùng ngoài môi trường mô phỏng.
Phạm vi test bị thay đổi sau khi chạy	Không có thay đổi phạm vi được ghi nhận	Đủ điều kiện xem xét	Kết quả test còn khớp phạm vi đã thực hiện.
Người có thẩm quyền xác nhận	Chưa có bằng chứng xác nhận từ Business Owner hoặc UAT Lead	Giữ IN_REVIEW	Template không được suy diễn approval từ kết quả PASS hoặc từ việc hoàn tất bảng.

Bộ dữ liệu test tổng hợp	Giá trị
Khách hàng	KH-MP-20260807-01 — Siêu thị Minh Phát Mô Phỏng
Đơn bán hàng	SO-MP-20260807-01
Kho xuất	KHO-HCM-TP-01 — Kho Thành phẩm Hồ Chí Minh Mô Phỏng
Mặt hàng	TP-NF-CHILI-500G — Tương ớt Nova 500g Mô Phỏng
Số lượng đặt	120 chai
Tồn khả dụng trước xuất	150 chai
Số lượng xuất hợp lệ	120 chai
Tồn khả dụng sau xuất kỳ vọng	30 chai
Số lượng xuất âm kiểm tra đường âm	151 chai
Kết quả kỳ vọng đường âm	Hệ thống từ chối xác nhận xuất; không tạo phiếu xuất kho; hiển thị thông báo còn tồn kho không đủ
Giá trị đơn mô phỏng	4.800.000 VND
Thời điểm chạy test	2026-08-07 14:30:00 Asia/Ho_Chi_Minh

Kết luận quyết định cho bộ dữ liệu này: kết quả chức năng đạt, nhưng trạng thái hồ sơ ký xác nhận giữ IN_REVIEW vì chưa có xác nhận từ vai trò có thẩm quyền và còn một lỗi High về hiển thị tiếng Việt. Bảng này là bằng chứng quyết định mô phỏng, không thay thế hồ sơ defect, change request, hoặc phê duyệt chính thức.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng kiểm soát chất lượng trước baseline: Senior Business Analyst rà soát xem hồ sơ UAT có đủ để đưa vào quyết định tiếp theo hay phải sửa, dừng, hoặc chuyển đúng người có thẩm quyền. Cổng này không tạo APPROVED, BASELINED, xác nhận tuân thủ, hay quyền dùng production. Áp dụng cho Nova Foods Trading & Manufacturing mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

ID kiểm tra	Hạng mục và câu hỏi kiểm tra	PASS	FAIL	STOP	Escalation
QG-UAT-001	Tính đầy đủ: hồ sơ có đủ ID UAT, phạm vi, test case, dữ liệu test, kết quả thực tế, bằng chứng, defect, quyết định và trạng thái không?	Mọi trường bắt buộc có giá trị cụ thể; không có placeholder; từng kết quả có bằng chứng định danh được.	Thiếu một trường nhưng còn xác định được phạm vi và người bổ sung.	Thiếu test case, kết quả, bằng chứng, hoặc quyết định khiến không thể biết điều gì đã được kiểm tra.	UAT Lead bổ sung hồ sơ; Business Owner làm rõ phạm vi nếu thiếu quyết định nghiệp vụ.
QG-UAT-002	Tính nhất quán: ID, tên nghiệp vụ, số lượng, tiền tệ VND, thời điểm Asia/Ho_Chi_Minh, trạng thái và kết quả có khớp giữa các bảng không?	Không có mâu thuẫn giữa core record, evidence và traceability.	Sai khác trình bày không đổi nghĩa, như lỗi chính tả không làm đổi ID hay giá trị.	Cùng một test có hai kết quả khác nhau, hoặc số liệu làm đổi kết luận.	UAT Lead và test executor đối chiếu log; Senior BA giữ IN_REVIEW đến khi có bản ghi thống nhất.
QG-UAT-003	Khả năng kiểm thử: mỗi yêu cầu có điều kiện đầu vào, bước chạy, kết quả kỳ vọng và kết quả thực tế đo được không?	Có thể chạy lại độc lập và phân biệt rõ PASS, FAIL, BLOCKED.	Bước chạy chưa rõ nhưng log và dữ liệu đủ để viết lại chính xác.	Kết quả dùng nhận xét chủ quan như “hoạt động tốt”, không có tiêu chí kiểm chứng.	QA Lead hoặc UAT Lead chuẩn hóa test case; không dùng kết quả đó để ký xác nhận.
QG-UAT-004	Truy vết: mỗi test và defect có liên kết đến requirement, business rule, dữ liệu và bằng chứng nguồn không?	Liên kết dùng canonical ID nguyên dạng từ TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY khi áp dụng.	Có liên kết nhưng sai định dạng hoặc thiếu mô tả quan hệ.	Không xác định được test đang chứng minh requirement hoặc rule nào.	Principal IT Business Analyst / Technical Curriculum Author sửa liên kết quản trị; Business Owner làm rõ rule nếu nguồn mâu thuẫn.
QG-UAT-005	Thẩm quyền nguồn: nguồn tạo yêu cầu, rule, tiêu chí UAT và quyết định có đúng loại nguồn không?	Nguồn được phân loại rõ; giả định dự án và Verification required được gắn nhãn.	Nguồn hợp lệ nhưng chưa ghi rõ phiên bản hoặc ngày truy cập.	Nội dung pháp lý, kế toán, bảo mật, thuế hoặc an toàn thực phẩm bị diễn đạt là bắt buộc khi chưa có xác minh chủ sở hữu chuyên môn.	Legal Owner, Accounting Owner, Security Owner, Compliance Owner hoặc domain owner xác minh; Senior BA không tự diễn giải.
QG-UAT-006	Ownership: người chạy test, người ghi nhận, người xử lý defect và người có quyền xác nhận có được nêu rõ không?	Mỗi hành động có một vai trò chịu trách nhiệm; giới hạn thẩm quyền rõ.	Có tên vai trò nhưng thiếu thời điểm hoặc trách nhiệm xử lý.	Gán quyền ký xác nhận cho người không có thẩm quyền, hoặc không xác định được người chịu trách nhiệm defect.	UAT Lead và Business Owner phân công lại; không suy diễn approval từ việc hoàn tất test.
QG-UAT-007	Bảo mật và riêng tư: bằng chứng không lộ dữ liệu cá nhân, bí mật truy cập, token, mật khẩu, dữ liệu khách hàng thật hoặc dữ liệu production không?	Chỉ dùng dữ liệu tổng hợp; dữ liệu nhạy cảm được loại bỏ hoặc che theo quy tắc được xác minh.	Có dữ liệu cần che nhưng chưa được phát hành ngoài nhóm review.	Có mật khẩu, token, dữ liệu cá nhân thật, dữ liệu production, hoặc bằng chứng không thể chia sẻ an toàn.	Security Owner và Privacy/Legal Owner đánh giá; dừng phân phối artifact đến khi xử lý.
QG-UAT-008	Ranh giới pháp lý, kế toán, thuế và an toàn thực phẩm: hồ sơ có tránh biến mô phỏng thành kết luận chuyên môn bắt buộc không?	Nội dung chỉ ghi requirement đã được nguồn có thẩm quyền xác minh, hoặc gắn Verification required hay giả định dự án.	Cần bổ sung nhãn ranh giới hoặc nguồn chính thức.	Kết luận “tuân thủ”, hạch toán, thuế, hóa đơn, truy xuất hoặc thu hồi được khẳng định không có xác nhận chuyên môn.	Legal Owner, Accounting Owner và food-safety domain owner quyết định; Senior BA chỉ bảo toàn traceability.
QG-UAT-009	Tác động thay đổi: thay đổi requirement, rule, dữ liệu, môi trường hoặc phạm vi sau khi chạy test có được ghi nhận không?	Không có thay đổi, hoặc thay đổi có impact assessment: test bị ảnh hưởng, kết quả cần chạy lại, owner và trạng thái.	Thay đổi nhỏ chưa ảnh hưởng logic nhưng cần ghi log.	Thay đổi làm kết quả cũ không còn chứng minh đúng phạm vi; không có đánh giá tác động.	Business Owner, UAT Lead, QA Lead và Architect đánh giá; chạy lại test bị ảnh hưởng trước quyết định tiếp theo.
QG-UAT-010	Quyết định chất lượng: trạng thái cuối có phản ánh đúng defect, blocker, rủi ro và thiếu bằng chứng không?	IN_REVIEW được giữ khi chưa có xác nhận có thẩm quyền; mọi điều kiện còn mở được ghi rõ.	Kết luận có thể sửa bằng cách làm rõ ngôn ngữ trạng thái.	Ghi APPROVED, BASELINED, “sẵn sàng production” hoặc tương đương khi không có tham chiếu quyết định hợp lệ.	Senior BA xóa kết luận vượt thẩm quyền; Business Owner hoặc vai trò được ủy quyền ghi quyết định riêng nếu có.

Quy tắc quyết định: PASS nghĩa là hạng mục đủ bằng chứng trong phạm vi review. FAIL nghĩa là có khoảng trống sửa được, hồ sơ giữ IN_REVIEW. STOP nghĩa là khoảng trống làm sai, không thể kiểm chứng, không an toàn, hoặc vượt thẩm quyền; dừng baseline và dừng dùng kết quả làm căn cứ ký xác nhận. Escalation là chuyển gói vấn đề gồm ID, bằng chứng, tác động, câu hỏi quyết định và owner tới vai trò có thẩm quyền; không phải chuyển trách nhiệm kết luận cho Senior BA.

Ma trận kiểm soát chất lượng Senior BA cho hồ sơ Nova Foods

Tính đầy đủ nghĩa là mỗi trường cần quyết định đều có giá trị, không chỉ có tiêu đề. Kiểm tra hồ sơ Tier 3 của Nova Foods mô phỏng: mục tiêu UAT, phạm vi, kịch bản, dữ liệu tổng hợp, kết quả mong đợi, kết quả thực tế, ngoại lệ, người sở hữu và liên kết nguồn phải cùng hiện diện. Một dòng “đạt” không đủ nếu thiếu bằng chứng test hoặc thiếu người chịu trách nhiệm xử lý sai lệch.

Khía cạnh	Câu hỏi kiểm tra	Bằng chứng tối thiểu	Ranh giới quyết định
Completeness — tính đầy đủ	Mọi trường, hàng và ngoại lệ có dữ liệu cụ thể không?	Hồ sơ Tier 3 điền đủ; không dùng placeholder; dữ liệu Nova Foods là tổng hợp	Thiếu trường làm thay đổi cách hiểu nghiệp vụ: không dùng làm test basis
Consistency — tính nhất quán	Tên quy trình, ID, trạng thái, ngày, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND có khớp nhau không?	Đối chiếu với TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	ID hoặc rule mâu thuẫn: giữ nguồn canonical, không tự đổi
Testability — khả năng kiểm thử	Yêu cầu có đầu vào, bước thực hiện, kết quả mong đợi và tiêu chí quan sát được không?	Kịch bản UAT có dữ liệu tổng hợp, điều kiện pass/fail và bằng chứng kết quả	Câu như “hệ thống phải thân thiện” chưa test được; cần tiêu chí đo được
Traceability — truy vết	Mỗi kết quả UAT truy ngược được đến requirement, rule, dữ liệu và nguồn không?	Liên kết ID nguyên dạng, tên tệp canonical, phân loại nguồn	Không suy diễn liên kết từ tên giống nhau
Source authority — thẩm quyền nguồn	Nguồn nào là nguồn chính, nguồn nào chỉ tham khảo?	URL chính thức hoặc artifact canonical; ngày truy cập 2026-08-07	Bản sao, trao đổi miệng, ảnh chụp không thay nguồn canonical
Ownership — quyền sở hữu	Ai cung cấp nghiệp vụ, ai kiểm thử, ai xử lý lỗi, ai có thẩm quyền chuyên môn?	Vai trò ghi rõ, không gán quyền phê duyệt ngầm	Principal IT Business Analyst / Technical Curriculum Author chỉ quản trị artifact
Security/privacy/legal/accounting	Dữ liệu, quyền truy cập, nghĩa vụ pháp lý, kế toán có vượt phạm vi BA không?	Phân loại dữ liệu; nhãn Verification required hoặc project assumption khi chưa xác minh	Legal Owner, Accounting Owner, Security Owner xác nhận nội dung thuộc thẩm quyền họ
Change impact — ảnh hưởng thay đổi	Sửa rule, dữ liệu hoặc kịch bản ảnh hưởng requirement, test, tích hợp hay báo cáo nào?	Danh sách artifact/ID bị ảnh hưởng và lý do liên kết	Không sửa im lặng nội dung đã được kiểm soát

Áp dụng cho ví dụ Nova Foods mô phỏng: nguồn quản trị của hồ sơ phải giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07; trạng thái này chứng minh nội dung đang xem xét, không chứng minh baseline hay approval. Liên kết quản trị dùng nguyên dạng /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Lý do: ba artifact này là nguồn canonical đã nêu cho ID, quy tắc và dữ liệu logic; template không tự trở thành nguồn chân lý thay thế.

Ranh giới dữ liệu: chỉ ghi dữ liệu tổng hợp Nova Foods; không ghi dữ liệu cá nhân thật, số tài khoản thật, thông tin nhà cung cấp thật hoặc chứng từ thật. Yêu cầu bắt nguồn từ Luật Bảo vệ dữ liệu cá nhân, Luật Kế toán, quy định hóa đơn/chứng từ hoặc Luật An toàn thực phẩm phải ghi Verification required cho Legal Owner, Accounting Owner hoặc domain owner xác minh. Nguồn pháp lý trong corpus chỉ định hướng học liệu; không phải kết luận tuân thủ hay diễn giải pháp lý.

Ranh giới thay đổi: nếu sửa một business rule, Senior BA phải kiểm tra requirement liên quan, dữ liệu test, expected result, lỗi đã ghi nhận và liên kết traceability. Ví dụ, đổi cách tính tổng tiền bằng VND có thể đổi kết quả mong đợi của UAT và báo cáo kế toán; BA ghi ảnh hưởng nhưng không tự quyết định cách hạch toán.

Áp dụng Quality Gate cho Nova Foods mô phỏng

Nova Foods Trading & Manufacturing là case học liệu mô phỏng, chỉ dùng dữ liệu tổng hợp. Senior BA đối chiếu bản ghi hoàn chỉnh tại mục 3 và bằng chứng tại mục 4 của /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md với nguồn kiểm soát. “Pass” nghĩa là đủ bằng chứng để tiếp tục review; không nghĩa là được phê duyệt. “Stop” nghĩa là không được baseline hoặc dùng làm quyết định production cho đến khi vai trò có thẩm quyền xử lý.

Điểm kiểm	Bằng chứng kiểm tra	Kết quả	Phát hiện và cầu nối suy luận	Hành động
Đủ trường sign-off	Mục 3 có phạm vi UAT, kết quả, ngoại lệ, quyết định, owner, ngày và trạng thái	PASS có điều kiện	Bản ghi có cấu trúc theo mục đích theo dõi UAT. Tuy nhiên IN_REVIEW tại v0.9.0 chỉ xác nhận đang xem xét, không xác nhận sign-off. Bằng chứng: metadata corpus trong TEMPLATE_MANIFEST.	Giữ trạng thái IN_REVIEW. Không đổi thành APPROVED hoặc BASELINED.
Nhất quán nhận dạng	Tên tệp, template ID, trạng thái, version, ngày, locale	PASS	Tên tệp canonical là /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md; trạng thái IN_REVIEW; version v0.9.0; ngày 2026-08-07; locale vi-VN; múi giờ Asia/Ho_Chi_Minh; tiền tệ mô phỏng VND. Các giá trị khớp contract hiện hành.	Không tạo tên tệp, version hoặc trạng thái thay thế.
Tính kiểm thử được	Mỗi kết quả UAT liên kết test basis, dữ liệu tổng hợp, kết quả mong đợi và kết quả thực tế	PASS có điều kiện	Mục 3 và 4 là vị trí ghi core record, evidence và traceability. Kiểm thử chỉ đáng tin khi test case phân biệt kết quả mong đợi với kết quả thực tế; đây là nguyên tắc thuật ngữ testing tham chiếu ISTQB CTFL v4.0.1.	QA reviewer xác nhận thực thi test case trước khi quyết định UAT.
Traceability	Liên kết từ sign-off đến nguồn, requirement, rule, test evidence và ngoại lệ	PASS có điều kiện	Liên kết quản trị phải giữ ID canonical của TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY. Các artifact này đều IN_REVIEW, nên liên kết chứng minh đường truy vết, không chứng minh rule đã được xác nhận vận hành.	Dừng baseline nếu bất kỳ liên kết nào trỏ tới bản sao, ID dịch thuật hoặc nguồn không canonical.
Thẩm quyền nguồn	Phân biệt nguồn học liệu, chuẩn, pháp luật và quyết định nghiệp vụ	FAIL — ESCALATE	00_SOURCE_MAP cho phép dùng BABOK, ISTQB, OWASP và nguồn pháp luật trong ranh giới đã nêu. Nguồn này không trao quyền diễn giải pháp lý, kế toán, thuế hoặc food-safety cho Senior BA. Vì sign-off có thể bị hiểu là chấp thuận vận hành, BA không được tự đóng kết luận các miền này.	Escalate Legal Owner, Accounting Owner và Business Owner nếu quyết định UAT chạm dữ liệu cá nhân, hóa đơn/chứng từ, hạch toán hoặc truy xuất thực phẩm.
Ownership	Owner, người thực thi UAT, người xử lý lỗi và người quyết định được tách vai trò	PASS có điều kiện	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact và traceability. Bằng chứng: giới hạn thẩm quyền trong TEMPLATE_MANIFEST, CHAPTER_MANIFEST và CANONICAL_BUSINESS_RULES. Do đó Owner template không thể thay Business Owner, QA, Architect, Legal hoặc Accounting sign-off.	Ghi rõ vai trò có thẩm quyền trong bản ghi; không ghi nhận approval khi chưa có tham chiếu approval kiểm soát.
Bảo mật và riêng tư	Dữ liệu UAT không chứa dữ liệu cá nhân thật; quyền truy cập và che giấu dữ liệu được kiểm tra	PASS có điều kiện	Contract yêu cầu synthetic data only. Đây giảm rủi ro lộ dữ liệu thật, nhưng không tự chứng minh tuân thủ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP. Nguồn pháp luật yêu cầu Legal Owner xác minh yêu cầu hệ thống suy ra.	STOP nếu evidence chứa dữ liệu cá nhân thật, bí mật sản xuất thật hoặc thông tin truy cập thật.
Biên kế toán, pháp lý, thực phẩm	Không suy diễn quy tắc ERP từ nguồn học liệu	FAIL — ESCALATE	Luật Kế toán, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm là nguồn bối cảnh. Seed quy định diễn giải phải do Accounting Owner, Legal Owner và domain owner xác minh. Bản ghi UAT không có thẩm quyền thay kết luận đó.	Gắn Verification required cho mọi kết luận pháp lý, kế toán, hóa đơn, thuế, truy xuất hoặc thu hồi.
Tác động thay đổi	Ngoại lệ UAT có impact đến requirement, rule, data, API, quyền hoặc báo cáo	PASS có điều kiện	Mọi thay đổi sau baseline phải qua kiểm soát thay đổi; hiện chưa có baseline reference. Vì vậy không được gọi sửa đổi là “change sau baseline”, nhưng vẫn phải phân tích tác động trước khi đóng review.	Escalate Architect khi tác động API, tích hợp, phân quyền hoặc cấu trúc dữ liệu; escalate Business Owner khi đổi quy trình hoặc acceptance criterion.

Kết luận review: STOP — AUTHORITY VERIFICATION REQUIRED. Bản ghi Nova Foods mô phỏng có thể tiếp tục hoàn thiện traceability và bằng chứng UAT. Không có approval reference, baseline reference, legal sign-off, accounting sign-off, security sign-off hay production authorization tại v0.9.0 ngày 2026-08-07.

6. Cross-File Checks, Open Issues, and Escalation

6.1 Kiểm tra nhất quán liên tệp

Kiểm tra liên tệp là đối chiếu một bản ghi UAT với nguồn kiểm soát khác để phát hiện mâu thuẫn về định danh, trạng thái, quy tắc, dữ liệu, phạm vi hoặc thẩm quyền. Bản ghi này áp dụng cho Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không phải dữ liệu ERP, khách hàng, nhân sự hoặc vận hành thật.

Điểm đối chiếu	Nguồn canonical phải kiểm tra	Kết quả tại v0.9.0 ngày 2026-08-07	Cầu nối bằng chứng và kết luận
Danh mục template và tên tệp	/01-curriculum/TEMPLATE_MANIFEST.md	PASS có điều kiện	Template đang soạn có tên tệp /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md. TEMPLATE_MANIFEST là nguồn kiểm soát danh mục template; không có dữ liệu trích đủ trong lô này để xác nhận dòng đăng ký chi tiết của TMPL-UAT-SIGN-002. Không được đổi ID, tên tệp hoặc suy diễn trạng thái đăng ký.
Trạng thái, phiên bản, ngày và locale	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	PASS	Các artifact nguồn đều ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, bối cảnh Việt Nam và VND. Vì metadata cùng giá trị, bản theo dõi sign-off không được ghi APPROVED, BASELINED, production-ready hoặc user-approved.
Định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	PASS có điều kiện	Registry là nguồn duy nhất cho ID traceability. Bản ghi UAT chỉ được tham chiếu ID đã đăng ký nguyên dạng; không tự tạo biến thể ID, dịch ID hoặc dùng ID làm bằng chứng phê duyệt. Dữ liệu dependency không cung cấp dòng registry của từng ID UAT, nên chỉ xác nhận được ranh giới kiểm soát.
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	PASS có điều kiện	CANONICAL_BUSINESS_RULES là catalog quy tắc nghiệp vụ canonical. UAT sign-off kiểm tra kết quả thực thi so với quy tắc đã được liên kết; template không được tự tạo quy tắc Nova Foods. Catalog cũng xác định IN_REVIEW không phải xác nhận quy tắc đúng cho vận hành thực tế.
Định nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	PASS có điều kiện	CANONICAL_DATA_DICTIONARY là nguồn cho tên trường, ý nghĩa logic và liên kết dữ liệu. Evidence UAT phải dùng định danh dữ liệu canonical khi có; không đổi tên trường để làm kết quả test trông phù hợp. Lô nguồn không cung cấp trường dữ liệu cụ thể để đối chiếu giá trị từng trường.
Chapter liên quan	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md, /01-curriculum/CHAPTER_MANIFEST.md	PASS	Curriculum architecture yêu cầu chuỗi requirement, acceptance criteria, traceability và test basis rõ. UAT sign-off là đầu ra kiểm soát, không thay requirement, acceptance criterion hay test basis. Mâu thuẫn chuỗi học phải dừng ở mức kế hoạch, không biến thành quy tắc ERP.
Nguồn chuẩn và pháp lý	/00-research/00_SOURCE_MAP.md	PASS có điều kiện	Source map phân loại BABOK, ISTQB, ISO/IEC/IEEE 29148, OWASP, WCAG và nguồn pháp lý Việt Nam theo ranh giới sử dụng. Bản UAT chỉ dùng chúng làm ngữ cảnh học liệu. Không được kết luận tuân thủ pháp lý, kế toán, hóa đơn, thuế, bảo mật, an toàn thực phẩm hoặc truy xuất từ kết quả UAT mô phỏng.
Consumer hạ nguồn	/04-cheatsheets/, /05-glossary/, /06-qa/	PASS có điều kiện	Consumer hạ nguồn là artifact sử dụng thuật ngữ, checklist hoặc kiểm tra chất lượng từ template. Chúng phải giữ nguyên TMPL-UAT-SIGN-002, trạng thái IN_REVIEW, nguồn canonical và nhãn dữ liệu tổng hợp. Không consumer nào được nâng kết quả review thành approval hoặc production authorization.

Quy tắc phát hiện mâu thuẫn: coi là mâu thuẫn khi cùng một ID có hai ý nghĩa, cùng một trường có hai định nghĩa canonical, trạng thái khác IN_REVIEW, version khác v0.9.0, hoặc evidence UAT kết luận vượt thẩm quyền Business Owner, Architect, QA, Legal Owner, Accounting Owner, Security hoặc Compliance. Lý do: manifest kiểm soát cấu trúc, registry kiểm soát ID, rule catalog kiểm soát quy tắc, data dictionary kiểm soát dữ liệu; template không được thay nguồn chân lý này.

Quy tắc xử lý trong bản ghi: khi phát hiện mâu thuẫn, giữ nguyên bằng chứng đã ghi, liên kết tới artifact canonical nêu trên và đánh dấu kết quả kiểm tra là không thể dùng làm sign-off. Không sửa im lặng ID, tên tệp, quy tắc, dữ liệu hoặc trạng thái để tạo kết quả đạt. IN_REVIEW vẫn là trạng thái duy nhất của artifact này tại v0.9.0; không có baseline reference, approval reference hoặc quyền triển khai production.

Sổ vấn đề mở, giả định và mục cần xác minh

Sổ này áp dụng cho TMPL-UAT-SIGN-002 trong /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md. UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) chỉ có thể ghi nhận quyết định khi có bằng chứng kiểm thử và người có thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi tên, vai trò và dữ liệu dưới đây là tổng hợp. Trạng thái toàn bộ mục là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh.

Loại	ID theo dõi	ID/tệp bị ảnh hưởng	Bằng chứng và cầu nối suy luận	Owner xử lý	Tác động	Hành động kế tiếp
Vấn đề mở	OI-UAT-001	TMPL-UAT-SIGN-002; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Template là artifact dự kiến, còn registry là kế hoạch ID; nguồn cung cấp không ghi nhận mã bản ghi UAT Nova Foods đã đăng ký. Vì vậy không được tạo hoặc gọi một ID phiên UAT là canonical.	Principal IT Business Analyst / Technical Curriculum Author	Không thể coi bản ghi ký xác nhận mô phỏng là bằng chứng truy vết chính thức.	Gửi yêu cầu đăng ký ID cho registry; chỉ dùng ID được registry ghi nhận ở phiên bản sau.
Vấn đề mở	OI-UAT-002	TMPL-UAT-SIGN-002; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Hai catalog đều có trạng thái IN_REVIEW; nguồn không cung cấp quy tắc, trường dữ liệu, giá trị trạng thái hay tiêu chí chấp nhận Nova Foods đã xác minh. Vì vậy nội dung Tier 3 không được biến thành quy tắc ERP thật.	Business Owner mô phỏng, phối hợp Principal IT Business Analyst / Technical Curriculum Author	Kết quả UAT có thể kiểm thử sai test basis, tức tập yêu cầu và quy tắc làm căn cứ kiểm thử.	Xác định test basis được gắn ID canonical; tách rõ giả định học liệu khỏi rule cần thẩm quyền nghiệp vụ.
Giả định dự án	ASM-UAT-001	TMPL-UAT-SIGN-002; CHAPTER_MANIFEST; TEMPLATE_MANIFEST	Manifest mô tả corpus là học liệu kiểm soát và Nova Foods là dữ liệu tổng hợp. Suy ra chữ ký, tên người kiểm thử và quyết định trong template chỉ là dữ liệu mô phỏng.	Principal IT Business Analyst / Technical Curriculum Author	Không có giá trị phê duyệt, baseline, pháp lý, kế toán hoặc production.	Giữ nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” tại mọi bản ghi hoàn chỉnh và bản xuất.
Giả định dự án	ASM-UAT-002	TMPL-UAT-SIGN-002; 01_CURRICULUM_ARCHITECTURE	Curriculum architecture yêu cầu chuỗi requirement, acceptance criteria, traceability và test basis. Suy ra sign-off chỉ ghi nhận mức độ đạt theo bằng chứng liên kết, không tự thay thế test case hay quyết định phát hành.	QA Reviewer mô phỏng	Tránh diễn giải sign-off là xác nhận chất lượng toàn hệ thống.	Mỗi quyết định UAT phải liên kết requirement, acceptance criterion, kết quả test và lỗi mở nếu có.
Cần xác minh	VR-UAT-001	TMPL-UAT-SIGN-002; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Nguồn không có nội dung rule và dictionary hoàn chỉnh. Bất kỳ trường liên quan hóa đơn, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc đều có thể vượt thẩm quyền BA.	Legal Owner, Accounting Owner, Compliance Owner, Business Owner	Nguy cơ gọi giả định là nghĩa vụ pháp lý hoặc nghiệp vụ bắt buộc.	Xác minh với chủ sở hữu chuyên môn; ghi nguồn chính thức, phạm vi áp dụng và kết luận vào artifact canonical trước khi dùng làm tiêu chí UAT.
Cần xác minh	VR-UAT-002	TMPL-UAT-SIGN-002; TRACEABILITY_ID_REGISTRY; CHAPTER_MANIFEST	Registry nêu IN_REVIEW không phải APPROVED hay BASELINED; manifest cũng không có approval reference. Vì vậy authority ký UAT, điều kiện chấp nhận có điều kiện và cơ chế escalation chưa được xác nhận.	Business Owner, QA Reviewer, Principal IT Business Analyst / Technical Curriculum Author	Không được ghi “đã phê duyệt”, “đã baseline”, “sẵn sàng production” hoặc suy ra quyền phát hành.	Xác minh ma trận thẩm quyền và ghi reference kiểm soát nếu được cấp bởi vai trò có quyền; trước thời điểm đó giữ quyết định là IN_REVIEW.

Không mục nào trong sổ này được tự đóng bởi Owner tài liệu. Đóng mục cần bằng chứng được liên kết, người xử lý đúng thẩm quyền, ngày ghi nhận theo Asia/Ho_Chi_Minh, và cập nhật có truy vết trong artifact canonical liên quan.

6.3 Bàn giao cuối và quy tắc lan truyền thay đổi

Bàn giao có kiểm soát là chuyển hồ sơ UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) cho vai trò nhận xử lý mà không biến kết quả kiểm thử thành phê duyệt. Vì /03-templates/TMPL-UAT-SIGN-002_uat-sign-off-tracking.md có Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, mọi bản ghi Nova Foods Trading & Manufacturing chỉ là mô phỏng giáo dục dùng dữ liệu tổng hợp. Không được ghi APPROVED, BASELINED, production-ready, compliant hoặc user-approved khi chưa có tham chiếu quyết định được ghi nhận tại artifact kiểm soát.

Điểm bàn giao	Gói phải chuyển	Người nhận phù hợp	Giới hạn thẩm quyền
Hồ sơ sign-off UAT	Core record, evidence, traceability link, trạng thái test, ngoại lệ và lịch sử thay đổi của TMPL-UAT-SIGN-002	Principal IT Business Analyst / Technical Curriculum Author	Duy trì traceability và điều phối review; không tự phê duyệt UAT hoặc baseline
Quyết định chấp nhận nghiệp vụ	Kết quả UAT, tác động quy trình, ngoại lệ nghiệp vụ mô phỏng	Business Owner	Chỉ Business Owner có thể kết luận chấp nhận nghiệp vụ; kết luận phải được ghi riêng, không suy ra từ template
Lỗi, rủi ro kỹ thuật, tích hợp	Bằng chứng tái hiện, môi trường mô phỏng, ảnh hưởng downstream	QA Reviewer, Technical Architect hoặc đội kỹ thuật phù hợp	Không biến lỗi thành thay đổi rule hay thiết kế khi chưa qua artifact canonical
Nội dung pháp lý, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm	ID bị ảnh hưởng, nguồn chính thức, giả định dự án và câu hỏi cần xác minh	Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner phù hợp	Không diễn giải luật, xác nhận tuân thủ hoặc quyết định vận hành thực tế

Quy tắc lan truyền thay đổi: thay đổi chỉ bắt đầu từ nguồn chân lý phù hợp. Thay đổi định danh, đường dẫn, trạng thái hoặc version phải được cập nhật trước tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md hoặc manifest liên quan; thay đổi quy tắc nghiệp vụ phải bắt đầu tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; thay đổi định nghĩa dữ liệu phải bắt đầu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md. TMPL-UAT-SIGN-002 chỉ phản ánh thay đổi đã được liên kết truy vết, không tự tạo rule, trường dữ liệu, ID hoặc quyết định mới.

Loại thay đổi	Tác động bắt buộc	Thứ tự lan truyền	Điều kiện giữ IN_REVIEW
Sửa ID hoặc tên tệp	Link traceability, manifest, template liên quan, consumer downstream	Registry/manifest → artifact bị ảnh hưởng → evidence UAT → consumer	Chưa có baseline reference và approval reference
Sửa business rule	Test case, expected result, exception, sign-off record	CANONICAL_BUSINESS_RULES → requirement/template liên quan → UAT evidence	Business Owner chưa ghi quyết định có thẩm quyền
Sửa data definition	Payload, mapping, validation, dữ liệu kiểm thử tổng hợp	CANONICAL_DATA_DICTIONARY → interface/template liên quan → UAT evidence	Architect, Security hoặc data owner chưa xác nhận phần thuộc thẩm quyền
Sửa nghĩa vụ pháp lý hoặc kế toán	Rule, acceptance criterion, nhãn Verification required	Nguồn chính thức và owner chuyên môn → canonical artifact → UAT record	Chưa có xác minh từ Legal Owner hoặc Accounting Owner

Mỗi thay đổi phải giữ ID cũ làm tham chiếu lịch sử khi thay thế, ghi lý do, phạm vi ảnh hưởng, owner xử lý, ngày theo Asia/Ho_Chi_Minh, và liên kết artifact nguồn. Không sửa im lặng evidence hoặc kết quả UAT. Khi một thay đổi ảnh hưởng đồng thời business rule, data definition và quyết định chuyên môn, Principal IT Business Analyst / Technical Curriculum Author lập gói escalation; các owner chuyên môn quyết định trong ranh giới của họ. Handoff hoàn tất nghĩa là gói đã được chuyển đủ và truy vết được, không nghĩa là đã phê duyệt, đã baseline, hay được phép dùng production.