CANONICAL_BUSINESS_RULES.md — Plan for Canonical Rule Catalog

Governance, Scope, and Artifact Header

Metadata quản trị artifact

Trường kiểm soát	Giá trị chuẩn	Diễn giải kiểm soát
Artifact ID	CANONICAL_BUSINESS_RULES	Định danh quản trị duy nhất của catalog quy tắc nghiệp vụ. Khi liên kết từ artifact khác, phải dùng đúng chuỗi này, không dùng tên rút gọn hoặc biến thể dịch thuật.
Đường dẫn tệp được kiểm soát	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Đây là vị trí canonical của artifact trong corpus Nova Foods. Bản sao, bản xuất hoặc nội dung trích dẫn không thay thế tệp được kiểm soát này.
Status	IN_REVIEW	Artifact đang được xem xét có kiểm soát và có thể được cập nhật theo lịch sử thay đổi. Trạng thái này không phải APPROVED, BASELINED, compliant, production-ready hoặc user-approved.
Version	v0.9.0	Phiên bản kế hoạch hiện hành tại ngày ghi nhận metadata. Mọi thay đổi sau đó phải tạo phiên bản và dòng lịch sử mới phù hợp; không được sửa đè ý nghĩa kiểm soát của phiên bản này.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner duy trì định danh, đường dẫn, trạng thái, phiên bản, metadata và lịch sử thay đổi của artifact. Owner không tự xác lập baseline, không ghi nhận approval, không xác nhận quy tắc nghiệp vụ là đúng cho vận hành thực tế và không thay thế thẩm quyền của Business Owner, Legal Owner, Accounting Owner, Security hoặc Architect.
Last updated date	2026-08-07	Ngày cập nhật gần nhất của metadata và lịch sử thay đổi khởi tạo, được diễn giải theo múi giờ quản trị Asia/Ho_Chi_Minh.
Timezone	Asia/Ho_Chi_Minh	Múi giờ chuẩn cho ngày giờ thay đổi, review, evidence và đối chiếu quản trị của artifact.
Locale và tiền tệ bối cảnh	vi-VN; Việt Nam; VND	Nội dung được viết cho bối cảnh Việt Nam. VND chỉ là đơn vị tiền tệ trong case study mô phỏng, không phải xác nhận cấu hình tài chính thực tế.
Case-study reference	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp	Tên Nova Foods xác định bối cảnh học tập của corpus ERP. Không suy diễn tổ chức, khách hàng, giao dịch, lô hàng, cấu hình hoặc dữ liệu thực tế từ artifact này.
Artifact classification	Controlled planning artifact for the canonical business-rule catalog in the Nova Foods ERP corpus	Artifact lập kế hoạch có kiểm soát cho catalog quy tắc nghiệp vụ canonical; không phải baseline, specification triển khai, cấu hình ERP, bằng chứng tuân thủ hoặc tài liệu vận hành production.
Baseline reference	Chưa có baseline reference tại v0.9.0.	Không được gọi nội dung, ID, bảng hoặc metadata trong artifact này là baseline khi chưa có tham chiếu baseline được ghi nhận rõ ràng trong artifact kiểm soát phù hợp.
Approval reference	Chưa có approval reference tại v0.9.0.	Việc Owner duy trì artifact, sự tồn tại của bảng metadata hoặc trạng thái IN_REVIEW không tạo approval ngầm định từ bất kỳ vai trò nghiệp vụ, kỹ thuật, pháp lý, kế toán, chất lượng hay bảo mật nào.

Metadata trên kiểm soát danh tính của /01-curriculum/CANONICAL_BUSINESS_RULES.md tại 2026-08-07. Khi có xung đột giữa bản sao và tệp tại đường dẫn được kiểm soát, tệp này là nguồn quản trị của chính artifact; tuy nhiên, trạng thái hiện hành vẫn chỉ là IN_REVIEW và không cho phép suy diễn rằng bất kỳ quy tắc nào đã được chấp thuận hoặc đưa vào baseline.

Phiên bản	Ngày ghi nhận	Trạng thái	Người ghi nhận	Nội dung thay đổi	Tác động kiểm soát
v0.9.0	2026-08-07	IN_REVIEW	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo lịch sử thay đổi cho /01-curriculum/CANONICAL_BUSINESS_RULES.md trong giai đoạn lập kế hoạch trước khi soạn catalog quy tắc nghiệp vụ canonical.	Xác lập điểm xuất phát có truy vết của artifact; không xác lập baseline, không ghi nhận approval, không xác nhận quy tắc nào hoàn chỉnh, hợp lệ về pháp lý, đúng về kế toán hoặc sẵn sàng áp dụng production.

Mỗi thay đổi sau v0.9.0 phải được ghi bằng một dòng mới, bao gồm đủ phiên bản, ngày ghi nhận, trạng thái thực tế, người ghi nhận, mô tả thay đổi và tác động kiểm soát. Không được xóa, sửa đè hoặc diễn giải lại dòng khởi tạo để tạo ấn tượng rằng đã có phê duyệt. Nếu thay đổi liên quan pháp lý, thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc hoặc bảo mật mà chưa được xác minh bởi nguồn và vai trò có thẩm quyền, lịch sử thay đổi phải duy trì nhãn Verification required hoặc Project assumption trong nội dung liên quan.

Mục đích và ranh giới phạm vi của Danh mục Quy tắc Canonical

/01-curriculum/CANONICAL_BUSINESS_RULES.md là artifact lập kế hoạch có kiểm soát để tập hợp và diễn giải nhất quán các quy tắc nghiệp vụ canonical dự kiến cho case study Nova Foods Trading & Manufacturing. Mục đích của artifact là tạo một điểm tham chiếu học tập chung giữa các miền ERP như bán hàng, mua hàng, tồn kho, lô/hạn dùng, sản xuất, tài chính, phê duyệt, báo cáo, bảo mật và tích hợp. Mỗi quy tắc được soạn trong tài liệu này phải giúp người học phân biệt rõ điều kiện kích hoạt, quyết định nghiệp vụ, kết quả mong đợi, ngoại lệ và nhu cầu truy vết sang artifact liên quan trong corpus Nova Foods.

Nova Foods trong artifact này chỉ là bối cảnh ERP mô phỏng phục vụ giáo dục, áp dụng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND. Tên khách hàng, nhà cung cấp, mặt hàng, lô hàng, kho, chứng từ, giá bán, số tiền, quyền hạn và sự kiện nghiệp vụ được nêu trong các quy tắc chỉ có giá trị minh họa cho việc phân tích nghiệp vụ; chúng không mô tả doanh nghiệp, giao dịch, cấu hình hoặc dữ liệu của một tổ chức thực tế.

Biên phạm vi	Bao gồm trong /01-curriculum/CANONICAL_BUSINESS_RULES.md	Loại trừ khỏi artifact này
Quy tắc nghiệp vụ	Các quy tắc canonical dự kiến điều phối hành vi nghiệp vụ trong scenario Nova Foods ERP và các phụ thuộc giữa miền nghiệp vụ.	Cấu hình ERP thực tế, mã nguồn, thiết kế cơ sở dữ liệu vật lý, quyết định kiến trúc triển khai hoặc hướng dẫn vận hành production.
Giá trị học tập	Diễn giải rule theo hướng có thể phân tích, phản biện, kiểm thử và truy vết trong corpus curriculum.	Cam kết thương mại, điều khoản với đối tác, chính sách nội bộ của doanh nghiệp thực hoặc chỉ dẫn để xử lý giao dịch thật.
Nội dung nhạy cảm theo miền	Ghi nhận ranh giới và điểm cần làm rõ đối với thuế, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc và bảo mật khi các miền này ảnh hưởng rule.	Kết luận pháp lý, tư vấn thuế, phê chuẩn hạch toán, xác nhận tuân thủ, quyết định thu hồi thực phẩm hoặc quyền cho phép sản xuất.
Liên kết corpus	Tham chiếu có kiểm soát tới artifact Nova Foods liên quan, bao gồm /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md khi cần bảo toàn nhận diện và cấu trúc học liệu.	Thay thế registry định danh, manifest chapter, specification giao diện, test evidence, hồ sơ phê duyệt hoặc hồ sơ kiểm soát thay đổi của artifact khác.

Do đó, tài liệu này xác định quy tắc để học và đánh giá phân tích nghiệp vụ trong một ERP mô phỏng, không xác định quy tắc đang có hiệu lực tại bất kỳ doanh nghiệp nào. Một nội dung xuất hiện trong danh mục không tự trở thành yêu cầu triển khai, chính sách vận hành, cấu hình hệ thống, bằng chứng tuân thủ hay căn cứ ra quyết định ngoài phạm vi Nova Foods mô phỏng.

Quy tắc diễn giải nguồn, mức độ tin cậy và hành động bắt buộc

Mỗi phát biểu nghiệp vụ, kiểm soát hoặc yêu cầu được ghi trong catalog phải mang một nhãn diễn giải chính trước khi được dùng làm cơ sở cho thiết kế, kiểm thử hoặc ví dụ Nova Foods. Nhãn xác định nguồn gốc tri thức, giới hạn kết luận và hành động tiếp theo; nhãn không xác nhận rằng nội dung đã được phê duyệt, baseline, hợp pháp, phù hợp production hoặc đúng cho mọi ERP.

Nhãn diễn giải	Định nghĩa áp dụng	Khi được phép sử dụng	Hành động kiểm soát bắt buộc	Ví dụ trong Nova Foods
Project assumption	Giả định có chủ đích để hoàn chỉnh tình huống học tập khi chưa có quyết định hoặc bằng chứng nguồn đủ thẩm quyền.	Chỉ dùng cho chi tiết mô phỏng cần thiết để minh họa luồng ERP, dữ liệu tổng hợp hoặc tình huống kiểm thử.	Nêu rõ giả định, phạm vi tác động và điều kiện cần xem xét lại; không diễn đạt như chính sách thực tế.	Giả định một kho mô phỏng áp dụng kiểm tra hạn dùng trước khi xuất hàng.
Verification required	Nội dung có thể chịu tác động pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, bảo mật hoặc quyết định nghiệp vụ nhưng chưa được xác minh đầy đủ.	Có thể được ghi nhận để chỉ ra khoảng trống và hỗ trợ phân tích, nhưng không làm căn cứ kết luận hay cấu hình.	Chuyển câu hỏi và bằng chứng cần thiết đến vai trò có thẩm quyền; giữ nguyên nhãn cho đến khi có xác minh được ghi nhận.	Thời hạn lưu chứng từ hoặc điều kiện phát hành hóa đơn điện tử cho một luồng bán hàng mô phỏng.
Normative standard	Yêu cầu hoặc ngữ nghĩa được quy định bởi tiêu chuẩn, quy chuẩn hoặc nguồn chính thức có hiệu lực trong đúng phạm vi tham chiếu.	Chỉ dùng khi xác định được nguồn ban hành, phiên bản và phạm vi áp dụng; không suy diễn điều khoản không được kiểm chứng.	Ghi nguồn chính thức và phiên bản; xác minh văn bản được cấp phép nếu cần trích dẫn điều khoản chính xác.	Ngữ nghĩa ký pháp BPMN chỉ được gọi là BPMN khi phù hợp OMG BPMN 2.0.2.
Industry good practice	Thực hành phổ biến, có cơ sở chuyên môn hoặc hướng dẫn từ tổ chức uy tín, nhưng không tự tạo nghĩa vụ pháp lý hay yêu cầu bắt buộc cho Nova Foods.	Dùng để đề xuất cách giảm rủi ro, tăng khả năng kiểm thử hoặc cải thiện chất lượng thiết kế.	Trình bày là khuyến nghị có điều kiện; nêu bối cảnh áp dụng và không chuyển thành quy định bắt buộc nếu chưa có quyết định phù hợp.	Tham chiếu OWASP API Security Top 10 2023 để nhận diện rủi ro API trong bài tập tích hợp.
Project convention	Quy ước nội bộ của corpus nhằm giữ nhất quán cách viết, thuật ngữ, phân loại và liên kết giữa các artifact.	Dùng cho nội dung quản trị học liệu và cách tổ chức tài liệu trong phạm vi Nova Foods ERP corpus.	Áp dụng nhất quán trong các artifact liên quan; nếu xung đột với nguồn chính thức hoặc quyết định có thẩm quyền, phải ghi nhận xung đột thay vì tự ưu tiên.	Dùng cùng một thuật ngữ nghiệp vụ cho một đối tượng mô phỏng trong các tài liệu liên kết.
Author recommendation	Đề xuất chuyên môn của tác giả dựa trên phân tích, nhằm hỗ trợ người học lựa chọn phương án rõ ràng và kiểm thử được.	Dùng khi có nhiều phương án hợp lý nhưng corpus cần nêu cách tiếp cận ưu tiên để minh họa.	Phân biệt với fact, chính sách và quyết định; nêu tiêu chí lập luận hoặc đánh đổi để người đọc có thể đánh giá.	Khuyến nghị tách kiểm tra dữ liệu bắt buộc khỏi kiểm tra điều kiện tín dụng trong ví dụ xử lý đơn hàng.

Quy tắc phân định: nếu phát biểu trả lời câu hỏi “Nova Foods sẽ vận hành như thế nào” nhưng chưa có bằng chứng quyết định nghiệp vụ, phân loại là Project assumption. Nếu phát biểu có thể ảnh hưởng nghĩa vụ hoặc tính phù hợp pháp lý, tài chính, an toàn, bảo mật hay vận hành và chưa được vai trò có thẩm quyền xác minh, phân loại là Verification required. Nếu phát biểu mô tả điều mà một tiêu chuẩn hoặc nguồn chính thức quy định, chỉ dùng Normative standard trong phạm vi nguồn đã kiểm tra. Không được nâng một Industry good practice, Project convention hoặc Author recommendation thành yêu cầu bắt buộc chỉ vì nó xuất hiện trong catalog.

Khi một nội dung có nhiều nguồn gốc, nhãn chính phải phản ánh rủi ro cao nhất đối với việc sử dụng nó. Ví dụ, một đề xuất kiểm soát truy xuất lô hàng có thể tham khảo thực hành ngành, nhưng vẫn phải mang nhãn Verification required nếu bị diễn giải thành nghĩa vụ an toàn thực phẩm hoặc quy trình vận hành thực tế.

Tuyên bố giới hạn thẩm quyền giáo dục

/01-curriculum/CANONICAL_BUSINESS_RULES.md là học liệu lập kế hoạch cho case study Nova Foods Trading & Manufacturing trong corpus ERP mô phỏng; toàn bộ tên tổ chức, tình huống, quy trình, mã định danh và dữ liệu đều là dữ liệu tổng hợp. Nội dung chỉ hỗ trợ học viên và người soạn thảo phân tích, cấu trúc, truy vết và thảo luận quy tắc nghiệp vụ. Nội dung không thay thế tư vấn chuyên môn, quyết định có thẩm quyền hoặc hồ sơ kiểm soát cần thiết cho môi trường thực tế.

Lĩnh vực	Điều tài liệu có thể làm trong phạm vi giáo dục	Điều tài liệu không được tuyên bố hoặc thay thế	Hành động khi nội dung phát sinh
Pháp lý và tuân thủ	Ghi nhận bối cảnh pháp lý từ nguồn chính thức đã nêu và mô tả điểm cần phân tích trong mô phỏng.	Không diễn giải luật có giá trị áp dụng, không tư vấn pháp lý, không xác nhận tuân thủ hoặc miễn trừ nghĩa vụ.	Gắn Verification required khi quy tắc có thể chịu ảnh hưởng của pháp luật; chuyển vấn đề cho Legal/Compliance Owner có thẩm quyền.
Kế toán và tài chính	Minh họa quan hệ giữa giao dịch ERP mô phỏng, chứng từ, kỳ, doanh thu, giá vốn hoặc đối soát bằng VND.	Không xác định chính sách kế toán, bút toán có hiệu lực, báo cáo tài chính hợp lệ hoặc kết luận kiểm toán.	Chuyển nội dung cho Accounting Owner; chỉ dùng kết luận đã được ghi nhận trong artifact kiểm soát phù hợp.
Thuế và hóa đơn	Nêu nhu cầu truy vết dữ liệu mô phỏng liên quan hóa đơn, chứng từ hoặc thuế.	Không xác định thuế suất, thời điểm kê khai, điều kiện khấu trừ, mẫu hóa đơn hoặc nghĩa vụ thuế thực tế.	Giữ nhãn Verification required hoặc Project assumption cho đến khi được vai trò thuế/kế toán có thẩm quyền xác minh.
Sản xuất, an toàn thực phẩm và vận hành	Mô phỏng rule về lô, hạn dùng, tồn kho, BOM hoặc work order để học phân tích ERP.	Không ban hành SOP, tiêu chuẩn chất lượng, lệnh sản xuất, quyết định thu hồi, hướng dẫn an toàn thực phẩm hoặc quyền vận hành nhà máy.	Chuyển cho Business Owner và domain owner phù hợp; không áp dụng trực tiếp cho dây chuyền, kho hoặc hàng hóa thực.
Dữ liệu cá nhân và bảo mật	Dạy cách nhận diện rủi ro, yêu cầu truy vết và điểm cần kiểm soát trong thiết kế mô phỏng.	Không là đánh giá tác động dữ liệu cá nhân, phê duyệt bảo mật, xác nhận an toàn hệ thống hoặc chứng nhận compliance.	Chuyển cho Legal/Compliance Owner và Security Owner theo đúng phạm vi chuyên môn.

Ví dụ, một quy tắc mô phỏng yêu cầu chặn xuất kho khi lô đã quá hạn chỉ là một giả định hoặc rule học tập cho Nova Foods; nó không chứng minh ngưỡng kiểm soát, quy trình chất lượng, trách nhiệm pháp lý hay cấu hình ERP thực tế là đúng. Tương tự, việc tham chiếu Luật Kế toán, quy định hóa đơn hoặc luật bảo vệ dữ liệu cá nhân không biến nội dung trong tài liệu thành diễn giải chính thức của các nguồn đó.

Trạng thái IN_REVIEW và Version v0.9.0 không tạo phê duyệt, baseline, xác nhận người dùng, quyền triển khai production hoặc kết luận tuân thủ. Chỉ quyết định được ghi nhận rõ ràng trong artifact kiểm soát phù hợp, dựa trên nguồn hiện hành và do vai trò có thẩm quyền cho đúng lĩnh vực đưa ra, mới có thể được sử dụng như một quyết định chuyên môn hoặc vận hành.

Quy ước toàn cục về mã quy tắc canonical và kỷ luật đặt tên

Mọi quy tắc nghiệp vụ trong /01-curriculum/CANONICAL_BUSINESS_RULES.md phải sử dụng một Canonical Rule ID duy nhất, ổn định và có thể truy vết. Nguồn kiểm soát định danh là /01-curriculum/TRACEABILITY_ID_REGISTRY.md; tài liệu này không được tự tái sử dụng, đổi nghĩa, xóa hoặc gán lại một ID đã đăng ký. Việc một ID xuất hiện trong tài liệu không xác nhận quy tắc đã được phê duyệt, baseline, kiểm chứng hoặc sẵn sàng áp dụng production.

Thành phần	Quy ước bắt buộc	Ví dụ hợp lệ	Ranh giới kiểm soát
Tiền tố loại	Dùng cố định BR cho business rule.	BR-INV-001	Không dùng REQ, FR, NFR, TC, DEF hoặc mã artifact khác thay cho quy tắc nghiệp vụ.
Mã miền	Dùng mã miền viết hoa, ngắn gọn, phản ánh phạm vi nghiệp vụ chính.	INV, SAL, PRC, MFG, FIN	Một quy tắc chỉ có một miền chính; liên kết liên miền được ghi bằng traceability, không ghép nhiều mã miền vào ID.
Số thứ tự	Dùng ba chữ số, tăng dần trong từng miền.	BR-INV-001, BR-INV-002	Không đổi số thứ tự để phản ánh mức ưu tiên, trạng thái, phiên bản hoặc ngày sửa đổi.
Dấu phân cách	Dùng dấu gạch ngang đơn giữa ba thành phần.	BR-SAL-014	Không dùng khoảng trắng, dấu gạch dưới, dấu chấm, ký tự tiếng Việt có dấu hoặc hậu tố tự do trong ID.
Tính bất biến	ID đã được gán giữ nguyên khi chỉ sửa câu chữ, nguồn, rationale hoặc tiêu chí kiểm thử.	BR-INV-001 giữ nguyên qua lần chỉnh diễn đạt	Nếu thay đổi làm đổi ý nghĩa nghiệp vụ cốt lõi, phải tạo ID mới và liên kết thay thế theo registry.

Mã miền phải ưu tiên phạm vi mà quy tắc trực tiếp điều khiển: SAL cho bán hàng, PRC cho định giá, INV cho tồn kho, MFG cho sản xuất và FIN cho tích hợp tài chính. Ví dụ, quy tắc chặn xuất kho khi số lượng khả dụng không đủ thuộc INV, dù đơn hàng bán là sự kiện khởi phát. Không dùng mã miền để suy diễn chủ sở hữu phê duyệt, mức độ rủi ro, nghĩa vụ pháp lý hoặc cấu hình ERP thực tế.

Tên quy tắc là nhãn đọc được cho con người, không thay thế ID. Tên phải theo cấu trúc [Đối tượng nghiệp vụ] — [động từ kiểm soát] — [điều kiện hoặc kết quả], viết tiếng Việt rõ nghĩa, không viết tắt mơ hồ và không chứa trạng thái quản trị như APPROVED hoặc BASELINED.

Tiêu chí đặt tên	Cách áp dụng
Một nghĩa kiểm soát	Tên phải mô tả một quyết định hoặc ràng buộc có thể diễn giải nhất quán.
Chủ thể rõ ràng	Nêu thực thể như đơn hàng bán, tồn kho khả dụng, lô hàng, phiếu hoàn tiền hoặc lệnh sản xuất.
Động từ có thể kiểm tra	Ưu tiên các động từ như chỉ cho phép, chặn, yêu cầu, tính, ghi nhận, không cho phép.
Không nhồi nhiều quy tắc	Không gộp điều kiện tín dụng, giá bán và tồn kho vào một tên hoặc một ID. Các kiểm soát độc lập cần ID độc lập.
Không khẳng định thẩm quyền ngoài phạm vi	Không đặt tên như “Tuân thủ pháp luật về hóa đơn” nếu chưa có xác minh từ vai trò có thẩm quyền; dùng nhãn nguồn phù hợp ở nội dung quy tắc.

Ví dụ tên hợp lệ: BR-INV-001 — Tồn kho khả dụng — chặn xác nhận xuất khi số lượng không đủ. Ví dụ không hợp lệ: Quy tắc tồn kho 1 vì thiếu điều kiện kiểm soát; BR_INV_001 vì sai cấu trúc ID; BR-SAL-001-APPROVED vì đưa trạng thái quản trị vào định danh.

Schema dòng quy tắc canonical dùng thống nhất trong toàn bộ catalog

Mỗi quy tắc nghiệp vụ trong /01-curriculum/CANONICAL_BUSINESS_RULES.md phải được ghi thành một dòng logic nguyên tử: một điều kiện nghiệp vụ có thể được đọc, truy vết, thẩm tra và liên kết kiểm thử độc lập. Một dòng không được gộp nhiều quyết định không phụ thuộc vào nhau; nếu các quyết định có trigger, ngoại lệ, owner hoặc nguồn khác nhau, chúng phải là các dòng canonical riêng và được liên kết bằng trường liên quan.

Trường bắt buộc	Nội dung phải ghi	Quy tắc kiểm soát
Rule ID	Định danh canonical của quy tắc.	Phải tham chiếu và tuân thủ namespace đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự đổi, tái sử dụng hoặc tạo biến thể không đăng ký.
Domain	Miền nghiệp vụ mà quy tắc thuộc về.	Phản ánh đúng phạm vi section, như Sales, Inventory, Manufacturing hoặc Finance; một quy tắc liên miền vẫn có một domain chủ đạo và ghi liên kết tại trường liên quan.
Rule name	Tên ngắn, duy nhất, định hướng hành vi.	Dùng danh từ nghiệp vụ và hành vi kiểm soát rõ ràng; không dùng tên mơ hồ như “Quy tắc chung”.
Canonical rule statement	Mệnh đề quy tắc đầy đủ theo cấu trúc điều kiện → hành động/quyết định → kết quả.	Phải xác định được hệ thống hoặc vai trò phải làm gì, khi nào và với kết quả nào; không thay thế bằng mô tả quy trình chung.
Applicability and trigger	Đối tượng, giao dịch, trạng thái hoặc sự kiện kích hoạt quy tắc.	Nêu biên áp dụng để tránh diễn giải quy tắc là hiệu lực cho mọi giao dịch Nova Foods.
Inputs and decision criteria	Dữ liệu đầu vào, điều kiện, ngưỡng, thứ tự ưu tiên hoặc tiêu chí quyết định.	Giá trị chưa được xác minh phải mang nhãn phân loại phù hợp, không được trình bày như cấu hình ERP thực tế.
Expected outcome	Kết quả nghiệp vụ, trạng thái, chặn xử lý, cảnh báo hoặc hành động tiếp theo.	Kết quả phải quan sát hoặc kiểm tra được; không dùng kết quả chủ quan như “xử lý hợp lý”.
Exception and boundary	Ngoại lệ được phép, trường hợp không áp dụng, hoặc giới hạn xử lý.	Nếu không có ngoại lệ, ghi rõ Không có ngoại lệ được xác định trong phạm vi mô phỏng; không để trống trường.
Data objects	Đối tượng dữ liệu Nova Foods bị tác động.	Dùng tên nghiệp vụ nhất quán, chẳng hạn đơn bán hàng, khách hàng, lô hàng, tồn kho hoặc lệnh sản xuất; không suy diễn schema kỹ thuật.
Responsible role and escalation	Vai trò chịu trách nhiệm diễn giải nghiệp vụ và vai trò cần escalation khi cần xác minh.	Không gán thẩm quyền pháp lý, kế toán, thuế, an toàn thực phẩm hoặc production cho tài liệu giáo dục.
Source classification	Một trong sáu nhãn: Project assumption, Verification required, Normative standard, Industry good practice, Project convention, Author recommendation.	Chỉ chọn nhãn phản ánh đúng bản chất bằng chứng; một quy tắc có nhiều cơ sở phải ghi từng cơ sở trong trường nguồn và nêu nhãn chủ đạo.
Source and safe-use boundary	Artifact hoặc nguồn chính thức hỗ trợ quy tắc, cùng giới hạn sử dụng của nguồn.	Giữ nguyên tên tệp, URL và phân loại nguồn; không tạo trích dẫn, điều khoản hoặc diễn giải pháp lý chưa được xác minh.
Traceability links	Liên kết tới requirement, process, data, test basis, issue hoặc artifact liên quan khi đã tồn tại.	Chỉ dùng ID canonical đã đăng ký; khi chưa có artifact đích, ghi Chưa có liên kết artifact tại v0.9.0 và giữ trạng thái IN_REVIEW.
Verification method	Cách chứng minh quy tắc, như walkthrough kịch bản, kiểm tra dữ liệu, kiểm thử hộp đen hoặc review chuyên môn.	Phương pháp phải kiểm tra được outcome đã nêu, không phải tuyên bố đã được kiểm thử hay phê duyệt.
Rule status	Trạng thái kiểm soát hiện hành của dòng quy tắc.	Tại phiên bản v0.9.0, mọi dòng phải là IN_REVIEW; trạng thái này không đồng nghĩa APPROVED, BASELINED, compliant hoặc production-ready.

Thứ tự cột khi trình bày bảng quy tắc ở các section tiếp theo phải giữ nguyên theo schema trên. Mọi trường đều bắt buộc có giá trị tường minh. Trường không áp dụng phải nêu lý do phạm vi, thay vì bị bỏ trống; trường cần xác minh phải giữ nhãn Verification required. Schema này chỉ chuẩn hóa cách ghi nhận và truy vết quy tắc trong case study Nova Foods Trading & Manufacturing bằng dữ liệu tổng hợp, không tự xác nhận tính hợp pháp, hạch toán, thuế, an toàn thực phẩm, cấu hình ERP hoặc thẩm quyền vận hành thực tế.

Customer, Credit, Sales, Pricing, Discounts, Promotions, and Refunds

Khuôn ghi nhận bắt buộc cho catalog quy tắc

Mỗi quy tắc được lập kế hoạch trong section này phải là một dòng độc lập của catalog và phải dùng một schema canonical duy nhất được quy định dưới đây. Các section ### Schema dòng quy tắc canonical dùng thống nhất trong toàn bộ catalog và ### Mẫu record bắt buộc phải tham chiếu đúng schema này, không được thêm, bớt, đổi tên, đổi thứ tự hoặc định nghĩa schema cạnh tranh. Định danh đã được cấp, gồm BR-SALES-004, phải được giữ nguyên; không đổi số, tái sử dụng hoặc gán lại ý nghĩa. Catalog chỉ ghi nhận quy tắc thuộc bối cảnh mô phỏng Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND.

Mỗi dòng phải có đủ trường dưới đây, theo đúng thứ tự. Trường không áp dụng phải ghi rõ lý do hoặc giá trị kiểm soát được quy định trong dòng đó; không bỏ trống.

Trường catalog theo thứ tự canonical	Giá trị bắt buộc cho từng dòng	Quy tắc kiểm soát
Rule ID	Mã duy nhất dạng BR-SALES-NNN.	Kiểm tra với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tạo ID trùng hoặc ID không thuộc namespace sales.
Rule statement	Một phát biểu chuẩn tắc, đơn nghĩa, nêu chủ thể, điều kiện và kết quả phải xảy ra.	Không thay thế bằng mô tả màn hình, hướng dẫn thao tác hoặc mục tiêu chung.
Rationale	Lý do nghiệp vụ, kiểm soát rủi ro hoặc nhu cầu truy vết.	Rationale giải thích “vì sao”, không lặp lại nguyên văn statement.
Inputs	Dữ liệu, trạng thái, vai trò, thời điểm và ngưỡng cần đánh giá.	Kiểu dữ liệu tiền tệ phải là số nguyên VND; không dùng số thực hoặc floating-point.
Decision logic	Điều kiện IF/THEN/ELSE, thứ tự ưu tiên, kết quả hợp lệ và kết quả bị chặn.	Các biên so sánh phải tường minh gồm bằng, nhỏ hơn và lớn hơn khi có ngưỡng. Với hoàn tiền, phải ghi đầy đủ 0 < Refund Amount <= Paid Amount.
Exceptions	Ngoại lệ cho phép, điều kiện kích hoạt, người có thẩm quyền và hành động sau ngoại lệ.	Nếu chưa xác định thẩm quyền hoặc có tác động pháp lý, kế toán, thuế, hóa đơn hoặc dữ liệu cá nhân, ghi Escalation required, không cho phép quyết định cục bộ.
Authority	Vai trò sở hữu quyết định nghiệp vụ hoặc chuyên môn đối với quy tắc.	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact, không thay thế thẩm quyền Business Owner, Accounting, Legal, Security hoặc QA Reviewer.
Source classification	Một trong: Project assumption, Verified external source, Verification required, hoặc Derived implementation constraint.	Phân loại phải phản ánh bản chất bằng chứng; không trình bày giả định như nghĩa vụ pháp lý hay quy định đã xác minh.
Source and safe-use boundary	Tên artifact nguồn hoặc URL nguồn đã xác minh, kèm giới hạn sử dụng.	Không tạo điều khoản, trích dẫn hoặc diễn giải pháp luật chưa được xác minh bởi vai trò có thẩm quyền.
Effective date	Ngày hiệu lực theo YYYY-MM-DD, hoặc Not established at v0.9.0.	Không suy diễn ngày production. Mọi ngày được diễn giải theo Asia/Ho_Chi_Minh.
Affected entities/states	Thực thể Nova Foods và trạng thái bị tác động.	Phải phân biệt rõ thay đổi dữ liệu, chuyển trạng thái và hành động bị chặn; không để trường này trống.
Related needs and requirements	ID canonical của need và requirement liên quan.	Chỉ liên kết ID đã đăng ký. Nếu chưa có artifact đích, ghi Chưa có liên kết artifact tại v0.9.0.
Test implications	Điều kiện kiểm thử, dữ liệu đầu vào, expected result, biên và bằng chứng dự kiến.	Phải cho phép kiểm thử hộp đen; nêu rõ kết quả được chấp nhận, bị từ chối hoặc chuyển escalation.
Owner	Vai trò duy trì nội dung và kích hoạt review thay đổi.	Owner không đồng nghĩa người phê duyệt và không tạo approval ngầm định.
Change impact	Tác động dự kiến đến dữ liệu, quy trình, giao diện, tích hợp, báo cáo, đào tạo và test basis.	Nêu artifact cần rà soát; không tuyên bố thay đổi đã được triển khai.
Rule status	IN_REVIEW.	Tại v0.9.0, không dùng APPROVED, BASELINED, compliant hoặc production-ready.

Quy trình ghi nhận bắt buộc là: tác giả tạo record theo đúng 16 trường canonical; Owner kiểm tra tính đầy đủ và tác động; Authority xác minh nội dung thuộc phạm vi của mình; QA Reviewer kiểm tra khả năng truy vết và kiểm thử. Tác giả duy trì artifact, Owner kích hoạt review, Authority quyết định nội dung nghiệp vụ hoặc chuyên môn, QA Reviewer kiểm tra chất lượng. Không actor nào được suy diễn approval từ việc record đã được ghi nhận. Dòng vẫn giữ Rule status là IN_REVIEW cho đến khi có bằng chứng và thẩm quyền phù hợp được ghi nhận ở artifact liên quan.

Điều kiện hoàn chỉnh của một dòng quy tắc

Một dòng chỉ đủ điều kiện đưa vào catalog dự kiến khi có toàn bộ trường bắt buộc, có liên kết truy vết hoặc ghi rõ chưa có liên kết tại v0.9.0, và có phương pháp kiểm chứng tương ứng. Quy tắc liên quan đồng thời giá, hoàn tiền, tín dụng, doanh thu, hóa đơn hoặc dữ liệu khách hàng phải tách rõ phần quyết định nghiệp vụ với phần cần xác minh chuyên môn. Thiếu nguồn, thiếu authority, mâu thuẫn giữa artifact canonical, hoặc không xác định được chủ sở hữu ngoại lệ phải được ghi là Escalation required.

BR-SALES-004 phải xuất hiện như một dòng riêng trong catalog section này, giữ nguyên ID canonical, đầy đủ mọi trường theo khuôn trên và giữ nguyên logic biên số nguyên VND. Với mọi yêu cầu hoàn tiền, điều kiện đủ để tiếp nhận phải được ghi đầy đủ là:

0 < Refund Amount <= Paid Amount

Trong biểu thức này, Refund Amount và Paid Amount đều là số nguyên không âm theo đơn vị VND, được lưu và so sánh bằng kiểu số nguyên hoặc kiểu decimal chính xác; không dùng floating-point, không làm tròn và không cắt phần thập phân. Refund Amount = 0 không phải khoản hoàn tiền hợp lệ; Refund Amount > Paid Amount bị từ chối. Nếu cần kiểm soát số tiền đã hoàn trước đó, Paid Amount phải được hiểu là số tiền đã thanh toán còn đủ điều kiện đối soát theo dữ liệu được Authority xác định; không được tự suy diễn hoặc tự sửa giá trị này.

Danh mục quy tắc khách hàng, trạng thái và hạn mức tín dụng

Phạm vi micro-batch này chỉ xác định các quy tắc quản trị Customer Master và kiểm soát tín dụng trước khi xác nhận giao dịch. Các giá trị, vai trò và ngưỡng dưới đây là dữ liệu tổng hợp cho Nova Foods Trading & Manufacturing, mang nhãn Project assumption; không phải cấu hình ERP thực tế, chính sách tín dụng đã được phê duyệt, hay kết luận pháp lý.

ID quy tắc	Phát biểu quy tắc và logic quyết định	Dữ liệu đầu vào; thực thể/trạng thái bị ảnh hưởng	Ngoại lệ, thẩm quyền và phân loại nguồn	Liên kết truy vết, kiểm thử, Owner và tác động thay đổi
BR-SALES-001	Mỗi khách hàng phải có đúng một Customer ID bất biến sau khi tạo. Bản ghi B2B phải có tên pháp nhân, mã số thuế hoặc mã nhận diện doanh nghiệp được Business Owner xác định; bản ghi B2C phải có tên hiển thị và tối thiểu một kênh liên hệ phục vụ giao dịch. Hệ thống phải phát hiện trùng lặp theo tập khóa đối sánh do Data Steward quản trị; nghi ngờ trùng không được tự động gộp bản ghi.	Customer; trạng thái Draft, Active, Suspended, Inactive; loại khách hàng, tên, mã nhận diện, số điện thoại hoặc email, địa chỉ giao dịch.	Bản ghi trùng, thiếu trường nhận diện hoặc yêu cầu gộp khách hàng phải chuyển Data Steward và Business Owner quyết định. Thu thập hoặc xử lý dữ liệu cá nhân phải được Legal/Privacy Owner xác minh. Nguồn: Project assumption; Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP — Verification required. Hiệu lực dự kiến: 2026-08-07.	NEED-SALES-001, REQ-SALES-001, AC-SALES-001. Tạo hai hồ sơ có cùng khóa đối sánh phải đưa vào hàng chờ rà soát; đổi tên không được đổi Customer ID; gộp chỉ hoàn tất sau quyết định có thẩm quyền. Owner: Sales Operations Manager. Thay đổi khóa đối sánh hoặc trường định danh ảnh hưởng nhập liệu, di trú dữ liệu, phân quyền và test hồi quy.
BR-SALES-002	Chỉ khách hàng ở trạng thái Active mới đủ điều kiện đi vào bước bán hàng tiếp theo. Suspended chặn phát sinh nghĩa vụ bán hàng mới; Inactive giữ lịch sử nhưng không cho tái sử dụng; Draft chỉ cho phép hoàn thiện dữ liệu chủ. Chuyển từ Suspended sang Active phải ghi lý do, người thực hiện và thời điểm theo Asia/Ho_Chi_Minh.	Trạng thái hiện tại, trạng thái đề nghị, lý do chuyển trạng thái, vai trò người yêu cầu. Thực thể: Customer, nhật ký trạng thái.	Nhân viên bán hàng không được tự bỏ qua Suspended. Phục hồi do tranh chấp định danh, dấu hiệu gian lận hoặc yêu cầu liên quan dữ liệu cá nhân phải escalation tới Business Owner, Security Owner hoặc Legal/Privacy Owner theo nguyên nhân. Nguồn: Project assumption; OWASP ASVS 5.0.0 chỉ là tham chiếu thực hành bảo mật.	NEED-SALES-002, REQ-SALES-002, AC-SALES-002. Chỉ Active cho kết quả đủ điều kiện; trạng thái khác bị chặn kèm mã lý do; phục hồi phải có audit trail. Owner: Sales Operations Manager. Thay đổi tập trạng thái ảnh hưởng workflow, báo cáo, quyền thao tác và test trạng thái.
BR-SALES-003	Hạn mức tín dụng chỉ áp dụng cho khách hàng B2B ở trạng thái Active và có phương thức thanh toán tín dụng được Business Owner xác định. AvailableCreditVND = CreditLimitVND - OutstandingReceivableVND - ReservedCreditVND. Mọi giá trị là số nguyên VND; không dùng số thập phân hoặc floating-point. Nếu RequestedCreditVND lớn hơn AvailableCreditVND, yêu cầu phải chuyển Credit Controller xem xét; hệ thống không được tự tăng hạn mức. Khách hàng B2C mặc định có CreditLimitVND = 0.	Loại khách hàng, trạng thái, CreditLimitVND, công nợ phải thu, tín dụng giữ chỗ, giá trị tín dụng yêu cầu. Thực thể: CustomerCreditProfile, Customer; trạng thái tín dụng: Eligible, ReviewRequired, Blocked.	Điều chỉnh hạn mức, miễn kiểm tra tín dụng, xử lý công nợ quá hạn hoặc điều kiện thanh toán đặc biệt phải escalation tới Credit Controller và Business Owner; tác động kế toán phải có Accounting Owner xác minh. Nguồn: Project assumption; Luật Kế toán 88/2015/QH13 — Verification required.	NEED-SALES-003, REQ-SALES-003, AC-SALES-003. Bằng AvailableCreditVND → Eligible; lớn hơn 1 VND → ReviewRequired; B2C luôn có hạn mức bằng 0. Owner: Credit Controller. Thay đổi công thức ảnh hưởng tích hợp tài chính, báo cáo tín dụng, kiểm thử biên và đối soát dữ liệu.

Nguyên tắc escalation: Data Steward, Sales Operations Manager và Credit Controller chỉ thực hiện trong phạm vi quy tắc đã ghi. Yêu cầu thay đổi định danh bất biến, cho phép giao dịch khi khách hàng không Active, thay đổi công thức hạn mức, hoặc diễn giải nghĩa vụ pháp lý, kế toán hay dữ liệu cá nhân phải được ghi nhận như vấn đề cần quyết định bởi Owner có thẩm quyền; không được giải quyết bằng quyết định cục bộ.

Quy tắc tạo, xác nhận, hủy đơn bán và hoàn tiền

Phạm vi micro-batch này áp dụng cho Nova Foods Trading & Manufacturing — mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND. Nội dung thuộc /01-curriculum/CANONICAL_BUSINESS_RULES.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải phê duyệt hoặc baseline.

ID quy tắc	Phát biểu quy tắc và lý do	Inputs	Decision logic và trạng thái bị ảnh hưởng	Ngoại lệ, authority, source classification, effective date	Liên kết và kiểm thử
BR-SALES-005	Chỉ tạo sales order khi có mã khách hàng hợp lệ, ít nhất một dòng hàng, số lượng mỗi dòng là số nguyên dương, tiền tệ là VND, và giá trị dòng được tính lại từ dữ liệu hệ thống. Lý do: giao dịch cần có danh tính, nội dung và giá trị quan sát được trước xử lý tiếp.	CustomerID, CustomerStatus, danh sách dòng hàng, ItemID, Quantity, UnitPriceVND, Currency, thời điểm tạo.	Điều kiện đều đúng → DRAFT; thiếu hoặc sai → từ chối, trả lỗi chỉ rõ trường vi phạm. Không tự chuyển CONFIRMED.	Sales Operations thực hiện trong phạm vi đã định nghĩa. Thay đổi cấu trúc đơn, cho phép số lượng âm hoặc tạo đơn thiếu khách hàng phải escalation tới Business Owner và Solution Architect. Nguồn: Project assumption; hiệu lực dự kiến 2026-08-07.	NEED-SALES-004, REQ-SALES-004, AC-SALES-004. Kiểm thử đơn hợp lệ, không có dòng, số lượng 0, số âm, Currency khác VND và mã hàng không tồn tại.
BR-SALES-006	DRAFT chỉ trở thành CONFIRMED sau khi hệ thống kiểm tra lại khách hàng, dòng hàng, tổng tiền và điều kiện bán hàng đã cấu hình. Lý do: xác nhận là điểm chốt nghiệp vụ, dữ liệu không được thay đổi âm thầm giữa lúc tạo và cam kết đơn.	OrderID, trạng thái, khách hàng, dòng hàng, tổng tiền, kết quả kiểm tra, người yêu cầu, timestamp.	DRAFT + mọi kiểm tra đạt → CONFIRMED; kiểm tra thất bại hoặc đơn ở trạng thái cuối → không chuyển và ghi audit event. Chỉ CONFIRMED được phát hành cho bước giao hàng hoặc xử lý tiếp.	Thay đổi quyền xác nhận, cho phép bỏ qua kiểm tra hoặc tạo cam kết tài chính từ DRAFT phải escalation tới Business Owner, Accounting Owner và Solution Architect. Nguồn: Project assumption; hiệu lực 2026-08-07.	NEED-SALES-005, REQ-SALES-005, AC-SALES-005. Kiểm thử chuyển trạng thái, thao tác lặp, tổng tiền không khớp và audit event có actor, thời điểm, trạng thái trước/sau.
BR-SALES-007	Chỉ hủy đơn khi chưa hoàn tất giao hàng hoặc chưa bị khóa bởi chứng từ liên quan; thao tác phải lưu lý do, người thực hiện và thời điểm. Lý do: hủy tác động tồn kho, giao hàng, doanh thu mô phỏng và đối soát.	OrderID, trạng thái đơn, giao hàng, chứng từ liên quan, CancellationReason, actor, timestamp.	DRAFT hoặc CONFIRMED chưa bị khóa → CANCELLED; đơn đã giao, đã khóa, đã hoàn tiền hoặc đã CANCELLED → từ chối. Không xóa vật lý và không tái sử dụng OrderID.	Hủy có liên quan hóa đơn, kế toán hoặc giao dịch hoàn tất phải escalation tới Accounting Owner và Business Owner. Nghị định 123/2020/NĐ-CP — Verification required. Nguồn workflow: Project assumption; hiệu lực 2026-08-07.	NEED-SALES-006, REQ-SALES-006, AC-SALES-006. Kiểm thử hủy DRAFT, CONFIRMED, đơn đã giao, đơn đã hoàn tiền, thiếu lý do và bảo toàn bản ghi gốc.
BR-SALES-004	Refund Amount phải là số nguyên VND dương và không vượt Paid Amount. Boundary đầy đủ: 0 < Refund Amount <= Paid Amount. Refund Amount = 0 không tạo khoản hoàn; Refund Amount > Paid Amount bị từ chối. Không làm tròn, không dùng số thập phân hoặc floating-point. Nếu có nhiều lần hoàn, Paid Amount là số tiền đã thanh toán còn đủ điều kiện đối soát theo dữ liệu được Authority xác định; hệ thống không được tự suy diễn giá trị này. Lý do: so sánh số nguyên chính xác ngăn sai lệch làm tròn và hoàn vượt số tiền đã thanh toán.	OrderID, trạng thái đơn, RefundAmountVND, PaidAmountVND, số tiền đã hoàn, phương thức hoàn, lý do, actor, timestamp.	Kiểm tra kiểu số nguyên trước so sánh. 0 < RefundAmountVND <= PaidAmountVND → REFUND_REQUESTED; bằng 0, âm, không phải số nguyên, thiếu giá trị hoặc lớn hơn PaidAmountVND → từ chối theo mã lỗi tương ứng. Không tự xác nhận hoàn tiền hoặc ghi nhận kế toán.	Sales Operations tạo yêu cầu; người có thẩm quyền hoàn tiền phải được cấu hình riêng, không suy diễn từ IN_REVIEW. Nguồn: Project assumption cho boundary mô phỏng; kế toán, thuế, chứng từ: Verification required với Accounting Owner. Hiệu lực 2026-08-07.	NEED-SALES-007, REQ-SALES-007, AC-SALES-007. Kiểm thử 0, 1, đúng bằng Paid AmountVND, lớn hơn đúng 1 VND, số thập phân, số âm, không phải số nguyên, hoàn lần hai và tổng hoàn lũy kế vượt số tiền đã thanh toán. Thay đổi boundary ảnh hưởng API, màn hình, đối soát, báo cáo và test biên.

Quy tắc truy vết và escalation: NEED-SALES-004 đến NEED-SALES-007 là nhu cầu mô phỏng về vòng đời đơn bán; REQ-SALES-004 đến REQ-SALES-007 phải mô tả hành vi quan sát được; AC-SALES-004 đến AC-SALES-007 phải liên kết test case và bằng chứng trạng thái. Yêu cầu cho phép sửa đơn sau CONFIRMED, hủy đơn đã gắn chứng từ, hoàn tiền vượt Paid Amount, bỏ qua audit trail, hoặc xác định hiệu lực pháp lý/kế toán phải được escalation tới Business Owner, Accounting Owner, Legal Owner hoặc Solution Architect; không giải quyết bằng quyết định cục bộ.

Danh mục quy tắc về giá bán, chiết khấu, khuyến mại và ngưỡng phê duyệt

Phạm vi micro-batch này lập kế hoạch các quy tắc xác định giá bán và ưu đãi thương mại cho Nova Foods Trading & Manufacturing trong môi trường mô phỏng giáo dục, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, tiền tệ VND. Giá được lưu, so sánh và làm tròn dưới dạng số nguyên VND; không dùng floating-point. Các ngưỡng là Project assumption, chưa phải cấu hình ERP, chính sách thương mại, baseline hoặc phê duyệt.

ID quy tắc	Phát biểu và logic quyết định	Lý do	Đầu vào; thực thể/trạng thái ảnh hưởng	Ngoại lệ và thẩm quyền	Phân loại nguồn; hiệu lực	Need / requirement / acceptance / kiểm thử	Owner; tác động thay đổi
BR-SALES-005	Chọn đơn giá theo thứ tự: giá hợp đồng B2B còn hiệu lực và khớp khách hàng–sản phẩm; bảng giá kênh còn hiệu lực; giá niêm yết. Một nguồn giá cơ sở cho mỗi dòng. Nhiều bản ghi cùng ưu tiên và hiệu lực → PRICE_EXCEPTION.	Ngăn nhân viên chọn giá tùy ý và tạo kết quả không nhất quán.	customer_type, customer_id, sales_channel, product_id, order_date; SalesOrderLine: DRAFT → PRICED hoặc PRICE_EXCEPTION.	Giá thiếu điều khoản, đồng hạng hoặc ngoài bảng → Sales Manager và Business Owner; không tự quyết.	Project assumption; hiệu lực 2026-08-07, cần Business Owner xác minh.	NEED-SALES-005; REQ-SALES-005; AC-SALES-005-01; kiểm thử ba nguồn giá và xung đột đồng hạng.	Sales Operations Owner; ảnh hưởng báo giá, đơn hàng, API định giá, báo cáo biên lợi nhuận và regression test.
BR-SALES-006	Chiết khấu dòng tính trên giá cơ sở. Chỉ cộng một chiết khấu thương mại với một khuyến mại đủ điều kiện. Hai khuyến mại cùng loại không cộng dồn; chọn mức giảm lớn hơn. Giá sau giảm không nhỏ hơn 0 VND.	Ngăn giảm trùng và bảo vệ tính minh bạch giá.	Giá cơ sở, loại chiết khấu, tỷ lệ hoặc số tiền nguyên VND, mã khuyến mại, sản phẩm, số lượng; PRICED → DISCOUNTED hoặc PROMOTION_EXCEPTION.	Tổ hợp ngoài quy tắc hoặc giá âm → Sales Manager; không sửa tay.	Project assumption; hiệu lực 2026-08-07, cần Business Owner xác minh.	NEED-SALES-006; REQ-SALES-006; AC-SALES-006-01; kiểm thử bảng quyết định B2B/B2C và khuyến mại đồng loại.	Sales Operations Owner; ảnh hưởng promotion engine, hóa đơn dự kiến, biên lợi nhuận và test.
BR-SALES-007	Khuyến mại đủ điều kiện khi chương trình ACTIVE, thời điểm đặt hàng nằm trong khoảng hiệu lực bao gồm hai đầu mút, đúng kênh, sản phẩm, ngưỡng số lượng hoặc giá trị, và chưa vượt giới hạn sử dụng. Đánh giá tại thời điểm xác nhận giá.	Làm ưu đãi có thể giải thích và tái lập.	Mã chương trình, trạng thái, thời gian Asia/Ho_Chi_Minh, kênh, sản phẩm, số lượng, giá trị trước giảm, khách hàng; Promotion: ACTIVE.	Thiếu giới hạn, dữ liệu mâu thuẫn hoặc ngoại lệ khách hàng chiến lược → Promotion Owner và Business Owner.	Project assumption; hiệu lực 2026-08-07, cần Business Owner xác minh.	NEED-SALES-007; REQ-SALES-007; AC-SALES-007-01; kiểm thử ngày bắt đầu/kết thúc, ngưỡng, giới hạn và sai kênh.	Promotion Owner; ảnh hưởng cấu hình chương trình, tích hợp POS/e-commerce và test biên.
BR-SALES-008	Giảm giá vượt 10% giá cơ sở dòng hoặc vượt 500.000 VND toàn đơn → DISCOUNT_PENDING_APPROVAL. Vượt cả hai ngưỡng vẫn tạo một yêu cầu, ghi cả hai lý do.	Kiểm soát cả tỷ lệ giảm lớn và số tiền giảm lớn.	Giá cơ sở, tổng giảm, tỷ lệ giảm, số tiền nguyên VND; DRAFT → DISCOUNT_PENDING_APPROVAL → PRICED.	Hạ ngưỡng, miễn phê duyệt hoặc đổi authority → Business Owner và Sales Manager.	Project assumption; hiệu lực 2026-08-07, cần Business Owner xác minh.	NEED-SALES-008; REQ-SALES-008; AC-SALES-008-01; 10% và không quá 500.000 VND không tạo yêu cầu; vượt ngưỡng tạo yêu cầu.	Sales Manager; ảnh hưởng workflow, phân quyền, audit, KPI và test biên.

Ghi chú kiểm soát: Không quy tắc nào trong micro-batch này là căn cứ thuế, hóa đơn, kế toán hoặc quyết định giá thương mại thực tế. Nếu giá sau giảm tác động chứng từ, thuế, doanh thu hoặc chính sách khách hàng thực tế, phải escalation đến Accounting Owner, Legal Owner và Business Owner. Tất cả quy tắc và liên kết trong section giữ trạng thái IN_REVIEW; chưa có quy tắc nào được đánh dấu BASELINED, APPROVED hoặc production-ready.

BR-SALES-004 — Ranh giới phê duyệt hoàn tiền bằng VND nguyên

BR-SALES-004 là quy tắc bắt buộc cho yêu cầu hoàn tiền trong Nova Foods Trading & Manufacturing, thuộc case study mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Phát biểu quy tắc: hệ thống chỉ tiếp nhận yêu cầu hoàn tiền khi thỏa đầy đủ boundary:

0 < Refund Amount <= Paid Amount

Refund Amount là số tiền yêu cầu hoàn; Paid Amount là số tiền đã thanh toán còn đủ điều kiện đối soát theo dữ liệu được Authority xác định. Cả hai phải là số nguyên VND, không phải floating-point, không có phần thập phân, không làm tròn và không cắt phần thập phân. Vì vậy, Refund Amount = 0 bị từ chối; Refund Amount âm bị từ chối; 0 < Refund Amount <= Paid Amount đủ điều kiện tiếp nhận; Refund Amount > Paid Amount bị từ chối. Boundary này kiểm soát điều kiện số tiền được hoàn, không tự cấp quyền phê duyệt hoặc ghi nhận kế toán.

Thuộc tính catalog	Nội dung canonical
Rule ID	BR-SALES-004
Tên quy tắc	Ranh giới phê duyệt hoàn tiền bằng VND nguyên
Lý do	Boundary đầy đủ tạo quyết định đơn nghĩa: khoản hoàn phải dương và không vượt số tiền đã thanh toán. So sánh số nguyên chính xác ngăn sai lệch do floating-point, làm tròn hoặc cắt phần thập phân.
Đầu vào	RefundRequest.refund_amount_vnd, PaidAmountVND, định danh yêu cầu, kênh B2B hoặc B2C, trạng thái yêu cầu, số tiền đã hoàn, phương thức hoàn, lý do, actor, timestamp.
Kiểu dữ liệu tiền	RefundRequest.refund_amount_vnd và PaidAmountVND phải là số nguyên VND hoặc kiểu decimal chính xác được kiểm soát; không dùng floating-point. Giá trị có phần thập phân, thiếu giá trị, không phải số hoặc không thể biểu diễn chính xác bằng VND nguyên là đầu vào không hợp lệ.
Logic quyết định	Nếu 0 < RefundRequest.refund_amount_vnd <= PaidAmountVND, đặt REFUND_PENDING_STANDARD_APPROVAL. Nếu RefundRequest.refund_amount_vnd = 0, đặt REFUND_DATA_INVALID và không tạo khoản hoàn. Nếu giá trị âm, thập phân, thiếu, không phải số nguyên hoặc lớn hơn PaidAmountVND, đặt REFUND_DATA_INVALID và từ chối. Không tự xác nhận hoàn tiền hoặc ghi nhận kế toán.
Điểm biên bắt buộc	PaidAmountVND - 1 VND và PaidAmountVND hợp lệ khi đều dương; PaidAmountVND + 1 VND bị từ chối. 0 VND bị từ chối vì điều kiện bắt buộc là 0 < Refund Amount, không phải 0 <= Refund Amount.
Ngoại lệ	Không có ngoại lệ tại chỗ cho nhân viên bán hàng hoặc người tạo yêu cầu. Thay đổi boundary, miễn kiểm tra, gộp hoặc tách yêu cầu để thay đổi kết quả so sánh phải escalation đến Business Owner và Sales Manager. Nếu hoàn tiền tác động chứng từ, doanh thu, thuế hoặc hạch toán mô phỏng, phải bổ sung Accounting Owner; nội dung đó là Verification required.
Thẩm quyền quyết định	Sales Operations tạo yêu cầu. Sales Manager quyết định trong phạm vi mô phỏng đã được cấp. Business Owner quyết định thay đổi chính sách hoặc boundary. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết, không phê duyệt hoàn tiền.
Phân loại nguồn	Project assumption. Không có nguồn pháp luật, kế toán hoặc chính sách Nova Foods thực tế được suy diễn từ quy tắc này.
Source and safe-use boundary	Nguồn kiểm soát nghiệp vụ là nội dung được quản trị trong /01-curriculum/CANONICAL_BUSINESS_RULES.md và master prompt của artifact. Nội dung chỉ dùng cho mô phỏng giáo dục; không dùng làm căn cứ vận hành production, pháp lý, thuế, hóa đơn hoặc kế toán.
Hiệu lực kế hoạch	2026-08-07, Asia/Ho_Chi_Minh; artifact IN_REVIEW, phiên bản v0.9.0. Hiệu lực kế hoạch không phải approval, baseline hoặc quyền vận hành production.
Thực thể và trạng thái bị ảnh hưởng	RefundRequest: DRAFT → REFUND_PENDING_STANDARD_APPROVAL khi 0 < Refund Amount <= Paid Amount; RefundRequest: DRAFT → REFUND_DATA_INVALID khi Refund Amount <= 0, vượt Paid Amount, không phải số nguyên VND hoặc thiếu/không hợp lệ.
Liên kết nhu cầu và yêu cầu	NEED-SALES-004: kiểm soát tuyến xử lý hoàn tiền theo số tiền đã thanh toán. REQ-SALES-004: ERP phải kiểm tra chính xác boundary 0 < Refund Amount <= Paid Amount bằng số nguyên VND, không dùng floating-point.
Hàm ý kiểm thử	AC-SALES-004-01: Refund Amount = 1 VND và Paid Amount = 1 VND → REFUND_PENDING_STANDARD_APPROVAL. AC-SALES-004-02: Refund Amount = PaidAmountVND → REFUND_PENDING_STANDARD_APPROVAL. AC-SALES-004-03: Refund Amount = PaidAmountVND + 1 VND → REFUND_DATA_INVALID. AC-SALES-004-04: Refund Amount = 0, số âm, số thập phân, floating-point, giá trị trống hoặc không phải số nguyên → REFUND_DATA_INVALID. Kiểm thử API, giao diện và báo cáo phải chứng minh cùng boundary, kiểu dữ liệu và kết quả.
Owner	Sales Manager duy trì quyết định vận hành mô phỏng; Principal IT Business Analyst / Technical Curriculum Author duy trì catalog và traceability. Owner không tạo approval ngầm định.
Tác động khi thay đổi	Thay đổi boundary, toán tử, kiểu dữ liệu hoặc định nghĩa Paid Amount ảnh hưởng workflow, phân quyền, nhật ký phê duyệt, API, giao diện, báo cáo, đối soát, acceptance criteria, test biên và tích hợp nhận trạng thái RefundRequest.

Phân biệt kênh B2B bán sỉ và B2C bán lẻ trong catalog quy tắc

Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. B2B và B2C là thuộc tính phân loại giao dịch có kiểm soát, không phải suy đoán từ tên khách hàng hoặc giá trị đơn hàng. ERP phải đọc customer_channel đã được ghi nhận, không để người dùng tự diễn giải từng đơn.

ID quy tắc	Phát biểu và logic quyết định	Đầu vào; thực thể/trạng thái bị ảnh hưởng	Ngoại lệ, thẩm quyền, nguồn, hiệu lực và owner
BR-SALES-005	Mỗi khách hàng dùng tạo đơn phải có đúng một giá trị B2B hoặc B2C tại thời điểm lưu đơn. Giá trị trống, ngoài tập cho phép hoặc khác kênh đã khóa trên đơn → không chuyển CONFIRMED.	customer_id, customer_channel, sales_order_id, trạng thái đơn; Customer và Sales Order; DRAFT → CONFIRMED.	Không có ngoại lệ tự quyết. Hồ sơ có hai mục đích mua phải được Business Owner quyết định. Nguồn: Project assumption; hiệu lực 2026-08-07, IN_REVIEW. Owner: Sales Operations Owner.
BR-SALES-006	Đơn B2B tham chiếu hồ sơ tổ chức đang hoạt động; đơn B2C tham chiếu hồ sơ cá nhân hoặc giao dịch bán lẻ được cấu hình cho B2C. Hệ thống chỉ kiểm tra phù hợp hồ sơ–kênh, không suy luận tư cách pháp nhân, thuế hoặc điều kiện xuất hóa đơn.	customer_type, customer_status, customer_channel, sales_order_id; Customer và Sales Order; DRAFT, ON_HOLD, CONFIRMED.	Không phù hợp → ON_HOLD; Sales Operations không đổi loại khách hàng để hoàn tất đơn. Escalation tới Business Owner; dữ liệu cá nhân chuyển Legal/Privacy Owner. Nguồn: Project assumption; dữ liệu cá nhân Verification required.
BR-SALES-007	Kênh khóa trên đơn là căn cứ cho giá, chiết khấu, khuyến mại, tín dụng và hoàn tiền. Không đổi customer_channel sau CONFIRMED; nếu nhập sai, hủy theo quy tắc rồi tạo đơn mới.	sales_order_id, customer_channel, trạng thái đơn, lý do thay đổi; Sales Order; chặn sửa kênh sau CONFIRMED.	Không ghi đè cục bộ. Escalation tới Sales Operations Owner; tác động chứng từ, doanh thu, hóa đơn hoặc hoàn tiền cần Accounting Owner đánh giá và giữ Verification required. Nguồn: Project assumption; hiệu lực 2026-08-07, IN_REVIEW.

Liên kết truy vết	Nội dung có thể kiểm tra
NEED-SALES-005 → REQ-SALES-005 → AC-SALES-005	ERP lưu và kiểm tra B2B/B2C; kênh trống hoặc không hợp lệ không được xác nhận đơn.
NEED-SALES-006 → REQ-SALES-006 → AC-SALES-006	Kiểm tra tương thích customer_type với customer_channel; không phù hợp chuyển ON_HOLD và có lý do.
NEED-SALES-007 → REQ-SALES-007 → AC-SALES-007	Kênh bị khóa từ CONFIRMED; thử sửa bị từ chối; tạo đơn mới là đường xử lý được phép.
TC-SALES-005 đến TC-SALES-007	Kiểm thử lớp tương đương B2B, B2C, rỗng và không hợp lệ; trạng thái DRAFT/CONFIRMED; kết quả ON_HOLD; quyền ghi đè.

Các quy tắc này không quy định giá bán, hạn mức tín dụng, chiết khấu, khuyến mại, hủy đơn hay hoàn tiền; chúng chỉ đặt ranh giới phân loại. BR-SALES-004 giữ nguyên boundary 0 < Refund Amount <= Paid Amount, kiểu số nguyên VND và trạng thái IN_REVIEW.

Ma trận truy vết từ quy tắc bán hàng đến nhu cầu, yêu cầu, tiêu chí chấp nhận và kiểm thử

Trong phạm vi Nova Foods mô phỏng, traceability là liên kết kiểm tra được từ quy tắc nghiệp vụ đến nhu cầu, yêu cầu hệ thống, acceptance criterion và bằng chứng kiểm thử. Ma trận không thay thế nội dung quy tắc. Mọi dữ liệu là tổng hợp, đơn vị VND, locale vi-VN, múi giờ Asia/Ho_Chi_Minh.

Rule ID	Nhu cầu	Requirement	Acceptance criterion	Test implication và bằng chứng
BR-CUST-001	Nhận diện khách hàng trước lập giao dịch.	REQ-SALES-001: định danh duy nhất, chặn mã không hợp lệ hoặc trùng.	AC-SALES-001: mã hợp lệ hiển thị đúng hồ sơ; mã không tồn tại hoặc trùng bị từ chối.	Kiểm thử hợp lệ, không tồn tại, trùng; lưu mã, trạng thái và lỗi.
BR-CUST-002	Chỉ khách hàng phù hợp được bán hàng.	REQ-SALES-002: kiểm tra trạng thái lúc tạo và xác nhận.	AC-SALES-002: chỉ khách hàng hoạt động được xác nhận.	Kiểm thử từng trạng thái ở cả hai thời điểm.
BR-CREDIT-001	Bảo vệ hạn mức tín dụng mô phỏng.	REQ-SALES-003: tính tín dụng đã sử dụng, đơn mới và hạn mức còn lại.	AC-SALES-003: trong hạn mức được xác nhận; vượt hạn mức bị chặn hoặc chuyển đúng phê duyệt.	Kiểm thử thấp hơn, bằng và cao hơn; lưu đầu vào, kết quả, trạng thái và actor.
BR-SALES-001 và BR-SALES-002	Vòng đời đơn có kiểm soát.	REQ-SALES-004: chỉ chuyển trạng thái hợp lệ; hủy phải lưu lý do và thời điểm.	AC-SALES-004: chuyển không hợp lệ bị từ chối, dữ liệu gốc không đổi.	Kiểm thử ma trận trạng thái, gửi lại yêu cầu và audit history.
BR-PRICE-001, BR-PROMO-001	Giá và ưu đãi nhất quán B2B/B2C.	REQ-SALES-005: áp dụng đúng giá, chiết khấu và khuyến mại.	AC-SALES-005: hiển thị được thành phần giá và không cộng dồn trái điều kiện.	Kiểm thử kênh, hết hạn, điều kiện thiếu và ưu đãi cạnh tranh.
BR-SALES-004	Hoàn tiền đúng boundary số nguyên VND.	REQ-SALES-006: thực thi chính xác 0 < Refund Amount <= Paid Amount; không dùng floating-point.	AC-SALES-006: Paid Amount - 1 VND và Paid Amount hợp lệ khi dương; Paid Amount + 1 VND, 0, âm hoặc thập phân bị từ chối.	Kiểm thử API, giao diện và báo cáo; lưu giá trị nguyên đầu vào, kiểu dữ liệu, kết quả, mã rule và source classification.

Mỗi liên kết ghi theo chuỗi Rule ID → Need ID → Requirement ID → Acceptance Criterion ID → Test ID. Thiếu nhu cầu, requirement hoặc tiêu chí kiểm thử thì liên kết là Verification required, không tự đánh dấu hoàn tất. Quy tắc ảnh hưởng doanh thu, kế toán, hóa đơn, dữ liệu cá nhân, quyền phê duyệt hoặc hoàn tiền phải được Principal IT Business Analyst / Technical Curriculum Author chuyển tới vai trò chuyên môn phù hợp; test kỹ thuật không thay thế quyết định nghiệp vụ, pháp lý hoặc kế toán. Metadata hiện hành vẫn là IN_REVIEW, v0.9.0, ngày 2026-08-07; chưa phải baseline, approval hoặc bằng chứng người dùng chấp thuận.

Ngoại lệ bắt buộc escalation, không được tự quyết tại điểm bán hoặc bộ phận bán hàng

Escalation là chuyển tình huống vượt thẩm quyền xử lý tại chỗ đến vai trò có thẩm quyền để quyết định và lưu vết. Nhân viên chỉ áp dụng quy tắc khi dữ liệu đầy đủ, kết quả xác định và ngoại lệ đã được cho phép rõ ràng. Nếu thiếu một điều kiện, không được tự sửa khách hàng, giá, khoản giảm, trạng thái đơn hoặc hoàn tiền.

Tình huống	Dấu hiệu	Vai trò nhận escalation	Hành động bị cấm tại chỗ	Bằng chứng tối thiểu	Phân loại nguồn
Không xác minh danh tính hoặc trạng thái khách hàng	Mã pháp nhân khác, thông tin B2C không khớp, yêu cầu gộp/tách hồ sơ	Business Owner; Security khi có dấu hiệu truy cập không phù hợp	Không tạo hồ sơ thay thế, đổi chủ thể hoặc tự hợp nhất	Mã khách hàng, mã đơn, trường không khớp, thời điểm, actor	Project assumption; dữ liệu cá nhân Verification required
Đơn vượt hoặc không xác định được tín dụng B2B	Hạn mức, công nợ hoặc điều khoản thiếu/mâu thuẫn	Business Owner và Accounting	Không tự tăng hạn mức, xóa cảnh báo hoặc xác nhận theo suy đoán	Mã khách hàng, đơn, số dư VND, hạn mức, điều khoản, trạng thái	Project assumption; kế toán Verification required
Tranh chấp giá, chiết khấu, khuyến mại	Hai nguồn giá cùng áp dụng, chương trình thiếu hiệu lực, yêu cầu cộng dồn không rõ	Business Owner; Accounting nếu tác động doanh thu/chứng từ	Không sửa giá, cộng dồn hoặc tạo khuyến mại thủ công	Mã hàng, kênh, nguồn giá, số lượng, thời điểm, chênh lệch VND	Project assumption; chứng từ Verification required
Hủy đơn hoặc hoàn tiền liên quan giao hàng, chứng từ hoặc doanh thu	Trạng thái đơn, thanh toán và chứng từ không đồng nhất	Accounting và Business Owner; Legal khi có tranh chấp	Không đổi trạng thái để làm khớp số, hoàn ngoài luồng hoặc xóa lịch sử	Mã đơn, thanh toán, giao hàng, chứng từ, lý do, số tiền nguyên VND, timestamp	Verification required
Không áp dụng được BR-SALES-004	Thiếu tiền, không phải số nguyên VND, nhiều khoản hoàn cạnh tranh hoặc boundary không xác định	Business Owner và Accounting	Không làm tròn, chia nhỏ giao dịch hoặc chọn kết quả có lợi cho một bên	Mã đơn, Refund Amount, Paid Amount, khoản đã hoàn, trạng thái thanh toán	Project assumption; chứng từ/hạch toán Verification required
Dấu hiệu gian lận, truy cập trái quyền hoặc lộ dữ liệu	Người dùng sửa giá, khách hàng hoặc hoàn tiền ngoài vai trò	Security; Business Owner nếu cần tạm dừng giao dịch	Không cấp thêm quyền, gửi dữ liệu ngoài kênh kiểm soát hoặc xóa log	ID người dùng/vai trò, thời điểm, hành động, đối tượng, log	Verification required

Mọi quy tắc trong section giữ Rule status: IN_REVIEW. Chưa có nội dung nào được đánh dấu BASELINED, APPROVED, compliant hoặc production-ready.

| Verification required; OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 chỉ là tham chiếu thực hành, không phải luật Việt Nam |

Khi phát hiện ngoại lệ, người xử lý tại chỗ phải giữ nguyên dấu vết giao dịch hiện có, ghi nhận sự kiện theo múi giờ Asia/Ho_Chi_Minh, phân loại kênh B2B hoặc B2C, và chuyển gói bằng chứng đến đúng vai trò. Việc “giữ nguyên” không có nghĩa là tự động hủy đơn hoặc từ chối hoàn tiền; đó là biện pháp ngăn một cá nhân tạo quyết định không thể truy vết trước khi người có thẩm quyền đánh giá.

Nếu cùng một ngoại lệ chạm từ hai phạm vi trở lên, chẳng hạn hoàn tiền vừa ảnh hưởng chứng từ vừa có dấu hiệu lộ dữ liệu khách hàng, phải escalation đồng thời đến các vai trò liên quan thay vì chọn một tuyến duy nhất. Cầu nối suy luận là mỗi vai trò sở hữu một loại rủi ro khác nhau: Business Owner quyết định ngoại lệ nghiệp vụ mô phỏng, Accounting đánh giá tác động kế toán hoặc chứng từ, Security đánh giá rủi ro truy cập và dữ liệu, còn Legal xử lý điểm cần diễn giải pháp lý. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì mô tả vấn đề và truy vết trong artifact đang IN_REVIEW, không thay thế kết luận của các vai trò này và không ghi nhận approval ngầm định.

Procurement, Inventory, Lot/Batch, Expiry, and Warehouse Control

Quy ước catalog quy tắc chuẩn cho phạm vi mua hàng và tồn kho

Nova Foods là case study ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; section này lập kế hoạch cấu trúc catalog, không xác nhận cấu hình ERP, quy trình vận hành thực tế, nghĩa vụ pháp lý, hay phê duyệt của bất kỳ vai trò nào. Mọi quy tắc được bổ sung trong section này phải là một bản ghi độc lập theo canonical rule schema (lược đồ quy tắc chuẩn): tập trường bắt buộc giúp người đọc biết quy tắc áp dụng cho ai, khi nào, dữ liệu nào, trạng thái nào và thay đổi sẽ ảnh hưởng đến đâu. Cầu nối suy luận là quy tắc không có phạm vi, điều kiện, kết quả và tác động thay đổi sẽ không thể được rà soát nhất quán hoặc truy vết tới các artifact liên quan.

Trường schema bắt buộc	Nội dung phải ghi	Quy tắc kiểm soát
Rule ID	Định danh quy tắc canonical đã được đăng ký.	Phải tuân theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự đặt lại, tái sử dụng hoặc diễn giải ID là bằng chứng phê duyệt.
Rule title	Tên ngắn, nêu một quyết định hoặc ràng buộc nghiệp vụ có thể quan sát.	Không gộp nhiều quyết định độc lập vào một tên.
Rule statement	Mệnh đề “khi điều kiện xảy ra, hệ thống hoặc vai trò phải/không được thực hiện kết quả xác định”.	Phải phân biệt rõ điều kiện kích hoạt, hành vi bắt buộc và kết quả.
Business rationale	Lý do nghiệp vụ của quy tắc.	Phải nêu cầu nối suy luận giữa rủi ro hoặc mục tiêu và quy tắc; không thay lý do bằng nhận định không có căn cứ.
Source classification	Phân loại nguồn: Verified primary source, Project assumption, hoặc Verification required.	Nội dung pháp lý, kế toán, an toàn thực phẩm và truy xuất nguồn gốc chưa được xác minh phải giữ nhãn phù hợp.
Affected entities	Các thực thể dữ liệu bị tác động, như Supplier, Purchase Order, Receipt, Inventory Item, Lot, Warehouse, Inventory Status.	Mỗi thực thể phải ghi vai trò trong quy tắc: đối tượng kiểm tra, đối tượng cập nhật hoặc đối tượng chỉ đọc.
Affected states	Trạng thái trước và sau của thực thể, nếu quy tắc tạo hoặc chặn chuyển trạng thái.	Phải chỉ rõ thực thể sở hữu trạng thái; không ghi trạng thái rời rạc không có thực thể.
Change impact	Tác động dự kiến khi quy tắc được thêm, sửa hoặc ngừng áp dụng.	Tối thiểu nêu tác động đến dữ liệu, quy trình, quyền thao tác, tích hợp hoặc kiểm thử; chỉ nêu loại tác động có liên quan.
Exception and escalation	Điều kiện không thể xử lý theo quy tắc thông thường và vai trò cần đánh giá.	Không được biến ngoại lệ thành quyền tự quyết của người dùng hoặc người soạn tài liệu.
Traceability references	Liên kết tới artifact, quyết định, giả định hoặc kiểm thử liên quan khi đã tồn tại.	Chỉ dùng đường dẫn, ID và phân loại nguồn canonical; không tạo liên kết ngụ ý tới approval hoặc baseline.

Cú pháp tham chiếu thực thể và trạng thái

Mỗi quy tắc phải ghi tác động theo cấu trúc Thực thể — trạng thái trước → trạng thái sau — kiểu tác động. Ví dụ cấu trúc, không phải quy tắc vận hành đã được xác nhận: Purchase Order — [trạng thái hiện hành được định nghĩa] → [trạng thái đích được định nghĩa] — chặn chuyển trạng thái. Cách ghi này tách ba khái niệm thường bị lẫn: thực thể là bản ghi nghiệp vụ, trạng thái là tình trạng vòng đời của bản ghi, và kiểu tác động là tạo mới, cập nhật, chặn, chỉ đọc hoặc yêu cầu đánh giá. Cầu nối suy luận là cùng một nhãn trạng thái có thể có ý nghĩa khác nhau giữa Receipt và Lot; vì vậy trạng thái chỉ có giá trị kiểm soát khi gắn với thực thể sở hữu nó.

Quy ước phân tích tác động thay đổi

Trường Change impact không được ghi chung chung là “ảnh hưởng tồn kho”. Người soạn phải xác định tác động theo các chiều dưới đây và ghi Không áp dụng khi chiều đó đã được đánh giá nhưng không bị ảnh hưởng.

Chiều tác động	Câu hỏi bắt buộc	Bằng chứng hoặc đầu ra dự kiến
Dữ liệu	Trường, quan hệ, lịch sử hay trạng thái của thực thể nào thay đổi?	Danh sách Affected entities và Affected states.
Quy trình	Bước nghiệp vụ, điểm kiểm soát hoặc bàn giao vai trò nào thay đổi?	Mô tả điều kiện kích hoạt và kết quả trong Rule statement.
Phân quyền	Vai trò nào được thực hiện, bị chặn hoặc chỉ được xem hành động liên quan?	Tham chiếu quyền mô phỏng hoặc nhãn Verification required nếu chưa có quyết định Security.
Tích hợp	Giao diện, thông điệp hoặc hệ thống phụ thuộc nào có thể nhận dữ liệu khác?	Tham chiếu artifact tích hợp hiện có; không suy diễn API hoặc thiết kế kỹ thuật.
Kiểm thử	Kết quả nào cần được quan sát để chứng minh quy tắc hoạt động hoặc bị chặn đúng?	Liên kết test basis hoặc điều kiện kiểm thử khi artifact đó đã tồn tại.

Nguồn phương pháp cho cách tách quy tắc, phạm vi và truy vết là BABOK Guide, IIBA, Version 3, theo ranh giới sử dụng đã xác minh: dùng thuật ngữ và hoạt động BA, không suy diễn số trang hoặc điều khoản. ISO/IEC/IEEE 29148:2018 chỉ được dùng ở mức mô tả chính thức và trạng thái thư mục đã xác minh; mọi diễn giải điều khoản chi tiết cần kiểm tra văn bản được cấp phép. Tại v0.9.0, Status IN_REVIEW, ngày 2026-08-07, mọi bản ghi quy tắc chỉ là nội dung lập kế hoạch có kiểm soát, không phải baseline, không phải approval và không phải xác nhận sẵn sàng production.

Danh mục quy tắc Nhà cung cấp, Đơn mua hàng, Nhận hàng và Chênh lệch

Trong Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp, nhà cung cấp (Supplier) là bên bán hàng hóa hoặc dịch vụ; đơn mua hàng (Purchase Order – PO) là cam kết mua nội bộ gửi nhà cung cấp; phiếu nhận hàng (Goods Receipt – GR) là bằng chứng vận hành rằng kho đã nhận và kiểm tra hàng. Việc tách ba đối tượng này giúp kiểm soát chuỗi quyết định từ điều kiện mua đến hàng thực nhận: nhà cung cấp phải đủ điều kiện trước khi đặt mua, PO phải là căn cứ nhận hàng, và mọi khác biệt giữa PO với GR phải được ghi nhận thay vì tự sửa số liệu. Đây là suy luận nghiệp vụ từ mục tiêu truy vết và kiểm soát thay đổi của corpus; quy định an toàn thực phẩm, pháp lý hoặc tiêu chuẩn đánh giá nhà cung cấp cụ thể giữ nhãn Verification required cho đến khi Business Owner và Legal/Compliance Owner xác minh.

Rule ID	Rule statement	Evidence/reasoning bridge	Affected entities / states	Change impact	Test implications
BR-PROC-001	Hệ thống chỉ cho phép tạo PO cho Supplier có trạng thái QUALIFIED. Supplier ở PENDING_QUALIFICATION, SUSPENDED hoặc DISQUALIFIED phải bị chặn khỏi thao tác phát hành PO mới.	PO tạo nghĩa vụ mua; nếu cho phép mua từ nguồn chưa được đánh giá hoặc đã bị đình chỉ thì không còn điểm kiểm soát trước giao dịch. Tiêu chí để chuyển sang QUALIFIED là Project assumption; tiêu chí liên quan chất lượng, an toàn thực phẩm hoặc pháp luật là Verification required.	Supplier: PENDING_QUALIFICATION, QUALIFIED, SUSPENDED, DISQUALIFIED; Purchase Order: DRAFT.	Đổi trạng thái Supplier sang không đủ điều kiện không tự hủy PO đã phát hành; hệ thống phải đánh dấu PO mở liên quan để người có thẩm quyền đánh giá tiếp.	Kiểm tra tạo PO với từng trạng thái Supplier; xác nhận chỉ QUALIFIED đi tiếp và thông báo chặn nêu rõ Supplier cùng trạng thái gây chặn.
BR-PROC-002	Một PO chỉ được chuyển từ DRAFT sang ISSUED khi có Supplier QUALIFIED, ít nhất một dòng hàng, số lượng đặt lớn hơn 0, đơn vị tính, kho nhận dự kiến và ngày nhận dự kiến. Sau ISSUED, không được sửa Supplier hoặc mã hàng trên dòng PO; thay đổi phải tạo phiên bản PO hoặc PO thay thế theo quyết định quy trình được ghi nhận.	Phiếu nhận hàng cần đối chiếu một căn cứ mua xác định. Nếu các trường định danh chính thay đổi sau phát hành mà không có dấu vết, đối chiếu PO–GR trở nên không tin cậy. Cơ chế phiên bản chi tiết là Project assumption cần Business Owner xác nhận.	Purchase Order: DRAFT, ISSUED, CLOSED, CANCELLED; Supplier; Warehouse; Inventory Item.	Thay đổi cấu trúc PO sau ISSUED ảnh hưởng màn hình mua hàng, lịch sử thay đổi, báo cáo hàng đang chờ nhận và tích hợp nhà cung cấp nếu tồn tại. Không suy diễn API hay thiết kế tích hợp.	Kiểm tra biên: PO không có dòng, số lượng bằng 0, thiếu kho nhận, Supplier bị SUSPENDED; kiểm tra sửa Supplier hoặc mã hàng sau ISSUED bị chặn.
BR-PROC-003	GR phải tham chiếu đúng một PO ở trạng thái ISSUED hoặc PO còn dòng mở; mỗi dòng GR phải tham chiếu một dòng PO và ghi nhận số lượng thực nhận lớn hơn 0, thời điểm nhận theo Asia/Ho_Chi_Minh, kho nhận và người ghi nhận. GR không được tạo từ PO CANCELLED hoặc CLOSED.	GR là sự kiện xác nhận hàng thực nhận, không phải bản sao tùy ý của PO. Tham chiếu dòng PO tạo được quan hệ đối chiếu theo hàng, số lượng và kho nhận.	Purchase Order: ISSUED, CLOSED, CANCELLED; Receipt: DRAFT, POSTED, VOIDED; Warehouse; Inventory Item.	Bổ sung hoặc thay đổi khóa liên kết PO–GR ảnh hưởng dữ liệu lịch sử, báo cáo nhận hàng và kiểm thử đối chiếu; không tự tạo kết luận hạch toán hay nghĩa vụ hóa đơn.	Kiểm tra GR tham chiếu PO hợp lệ, PO đã hủy, PO đã đóng, dòng PO không tồn tại, số lượng nhận bằng 0 và kho nhận không khớp dữ liệu nhập bắt buộc.
BR-PROC-004	Khi số lượng GR khác số lượng còn mở của dòng PO, hoặc hàng thực nhận không khớp mã hàng, hệ thống phải tạo bản ghi Receipt Discrepancy trước khi GR được POSTED. Loại chênh lệch tối thiểu gồm SHORT_RECEIPT, OVER_RECEIPT, ITEM_MISMATCH và DAMAGED_ON_RECEIPT. Không được tự động coi chênh lệch là đã giải quyết.	Số lượng đặt và số lượng thực nhận là hai bằng chứng khác nhau. Ép ghi nhận loại chênh lệch bảo toàn nguyên nhân để xử lý tiếp, thay vì che giấu sai khác bằng việc sửa PO hoặc GR. Ngưỡng chấp nhận nhận dư là Project assumption cần Business Owner quyết định.	Receipt: DRAFT, PENDING_DISCREPANCY_REVIEW, POSTED; Receipt Discrepancy: OPEN, RESOLVED, REJECTED; Purchase Order; Inventory Item.	Thêm loại chênh lệch làm thay đổi biểu mẫu GR, báo cáo mua hàng và dữ liệu cần theo dõi bởi bộ phận mua/kho. Quy tắc này không quyết định cách hạch toán, yêu cầu bồi thường hoặc xử lý pháp lý.	Kiểm tra nhận thiếu, nhận dư, sai mã hàng và hàng hư hỏng; xác nhận mỗi trường hợp sinh đúng loại chênh lệch, không tự chuyển sang RESOLVED, và lưu liên kết PO–GR–Discrepancy.
BR-PROC-005	GR có Receipt Discrepancy ở OPEN chỉ được POSTED khi loại chênh lệch được phép tiếp tục nhận theo quyết định nghiệp vụ đã cấu hình cho kịch bản mô phỏng; nếu chưa có quyết định đó, GR phải giữ PENDING_DISCREPANCY_REVIEW. Với ITEM_MISMATCH, hệ thống phải chặn POSTED cho đến khi có xử lý có truy vết.	Sai mã hàng làm đứt liên kết giữa hàng được mua và hàng được nhận; do đó không thể coi là chênh lệch số lượng thông thường. Việc cho phép nhận thiếu, nhận dư hoặc hàng hư hỏng tiếp tục được xử lý là quyết định vận hành, không được tự suy diễn từ nguồn phương pháp.	Receipt: PENDING_DISCREPANCY_REVIEW, POSTED; Receipt Discrepancy: OPEN, RESOLVED, REJECTED; Purchase Order; Supplier.	Quy tắc tạo điểm kiểm soát cho quy trình kho và mua hàng; thay đổi danh mục chênh lệch được phép tiếp tục sẽ ảnh hưởng kịch bản kiểm thử và báo cáo ngoại lệ.	Kiểm tra ITEM_MISMATCH luôn bị chặn; kiểm tra một loại chênh lệch có cấu hình cho phép và một loại chưa có quyết định để xác nhận trạng thái GR khác nhau.
BR-PROC-006	Một Receipt Discrepancy chỉ được chuyển từ OPEN sang RESOLVED khi lưu người xử lý, thời điểm xử lý, quyết định xử lý và tham chiếu PO/GR liên quan. Không được xóa bản ghi chênh lệch sau khi GR đã POSTED; nếu nhập sai, phải dùng trạng thái REJECTED kèm lý do.	Truy vết cần bảo toàn dấu vết của ngoại lệ và cách đóng ngoại lệ. Xóa bản ghi sau khi đã phát sinh GR sẽ làm mất bằng chứng giải thích cho khác biệt lịch sử.	Receipt Discrepancy: OPEN, RESOLVED, REJECTED; Receipt: POSTED; Purchase Order; Supplier.	Ảnh hưởng nhật ký thay đổi và báo cáo chênh lệch mở/đã xử lý; yêu cầu phân quyền cụ thể là Verification required với Security Owner.	Kiểm tra thiếu người xử lý, thiếu quyết định hoặc thiếu thời điểm thì không thể RESOLVED; kiểm tra xóa chênh lệch liên kết GR POSTED bị chặn và thao tác từ chối giữ lý do.

Các quy tắc trên sử dụng cấu trúc canonical gồm định danh, phát biểu quy tắc, cầu nối bằng chứng/lý do, thực thể và trạng thái ảnh hưởng, tác động thay đổi, cùng hàm ý kiểm thử. Thuật ngữ kiểm thử như điều kiện biên và ngoại lệ được dùng theo phạm vi thuật ngữ của ISTQB CTFL Syllabus v4.0.1; đây là cơ sở thiết kế kiểm thử hộp đen, không phải xác nhận hệ thống Nova Foods mô phỏng đã được kiểm thử. BABOK Guide, IIBA Version 3, được dùng trong ranh giới đã xác minh để tổ chức truy vết quy tắc và tác động thay đổi, không suy diễn điều khoản hoặc trích dẫn không có trong nguồn.

Quy tắc tồn kho: giữ chỗ, phân bổ, chặn âm và điều chỉnh

Nova Foods là bối cảnh ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và đơn vị tiền tệ mô phỏng VND. Các quy tắc dưới đây có trạng thái kế hoạch IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải cấu hình production, không xác nhận phê duyệt và không thay thế quyết định vận hành thực tế. “Giữ chỗ” (reservation) là khóa một lượng hàng khả dụng cho nhu cầu đã được ghi nhận; “phân bổ” (allocation) là gán lượng đã giữ cho một yêu cầu cụ thể; “điều chỉnh tồn kho” (stock adjustment) là giao dịch có kiểm soát làm tăng hoặc giảm số lượng sổ sách để phản ánh chênh lệch đã được xử lý.

Rule ID	Phát biểu quy tắc canonical	Cầu nối bằng chứng và lý do	Thực thể/trạng thái ảnh hưởng	Change impact	Hàm ý kiểm thử
BR-INV-001	Hệ thống chỉ được tạo giữ chỗ khi Inventory Item tại Warehouse có Inventory Status = AVAILABLE và lượng khả dụng đủ lớn hơn hoặc bằng lượng yêu cầu. Lượng khả dụng được tính: tồn thực có thể dùng trừ tổng lượng đã giữ chỗ chưa giải phóng.	Giữ chỗ nhằm tránh hai nhu cầu cùng cam kết một đơn vị hàng. Nếu dùng tồn thực mà không trừ lượng đã giữ, một lượng có thể được hứa cho nhiều yêu cầu; vì vậy phép tính phải tách tồn thực và tồn khả dụng. Đây là Project assumption cần Business Owner xác nhận ngưỡng và nguồn phát sinh nhu cầu.	Inventory Item; Warehouse; Inventory Status: AVAILABLE; Inventory Reservation: CREATED, RELEASED.	Thay đổi công thức lượng khả dụng ảnh hưởng khả năng đáp ứng nhu cầu, màn hình tồn kho và các giao dịch tạo giữ chỗ; cần đánh giá lại dữ liệu giữ chỗ đang mở.	Kiểm tra biên: tồn thực 100, đã giữ 40, yêu cầu 60 được tạo; yêu cầu 61 bị chặn. Kiểm tra ngoại lệ: trạng thái khác AVAILABLE không tạo giữ chỗ dù còn số lượng.
BR-INV-002	Mỗi bản ghi phân bổ phải tham chiếu đúng một Inventory Reservation đang CREATED, một Inventory Item, một Warehouse và số lượng phân bổ lớn hơn 0, không vượt lượng còn lại của giữ chỗ. Không được phân bổ trực tiếp từ số lượng chưa giữ chỗ.	Phân bổ cần một đối tượng nguồn đơn nghĩa để truy vết vì giữ chỗ là cam kết cấp hàng còn phân bổ là việc tiêu thụ cam kết đó. Ràng buộc một nguồn cho phép đối chiếu phần đã dùng và phần còn lại, giảm nguy cơ cấp quá mức.	Inventory Reservation: CREATED, PARTIALLY_ALLOCATED, FULLY_ALLOCATED, RELEASED; Inventory Allocation; Inventory Item; Warehouse.	Thay đổi quan hệ giữ chỗ–phân bổ ảnh hưởng tích hợp giao dịch xuất kho, báo cáo lượng đã cam kết và cơ chế giải phóng lượng chưa dùng.	Kiểm tra phân bổ đúng bằng lượng giữ chỗ chuyển trạng thái thành FULLY_ALLOCATED; phân bổ vượt phần còn lại bị chặn; phân bổ với giữ chỗ RELEASED bị chặn.
BR-INV-003	Một giữ chỗ chưa được phân bổ hết phải được giải phóng khi nhu cầu nguồn bị hủy hoặc hết hiệu lực theo chính sách thời hạn đã được Business Owner xác nhận. Thao tác giải phóng phải lưu thời điểm, tác nhân, lý do và lượng được giải phóng; không được xóa bản ghi giữ chỗ đã phát sinh.	Hàng bị giữ mãi sẽ làm tồn khả dụng thấp giả tạo, còn xóa bản ghi làm mất dấu vết lý do thay đổi cam kết. Vì thế cần chuyển trạng thái và lưu nhật ký thay vì xóa. Thời hạn giữ chỗ chưa có nguồn nghiệp vụ đã xác minh nên là Verification required.	Inventory Reservation: CREATED, PARTIALLY_ALLOCATED, RELEASED; Inventory Item; Warehouse; nhật ký giao dịch tồn kho.	Thay đổi thời hạn hoặc điều kiện giải phóng ảnh hưởng lượng khả dụng, cảnh báo tồn bị giữ lâu và các yêu cầu đang chờ cấp hàng.	Kiểm tra hủy nhu cầu làm lượng chưa phân bổ quay về khả dụng; lượng đã phân bổ không được giải phóng tự động; thiếu lý do hoặc tác nhân thì giao dịch giải phóng bị chặn.
BR-INV-004	Hệ thống phải chặn mọi giao dịch làm số lượng tồn có thể dùng của Inventory Item tại Warehouse nhỏ hơn 0, bao gồm cấp phát, xuất dùng và điều chỉnh giảm. Không được dùng giữ chỗ để vượt qua kiểm soát âm tồn.	Âm tồn tạo ra mâu thuẫn cơ bản: hệ thống ghi đã sử dụng hàng nhiều hơn lượng được ghi nhận là có. Chặn tại thời điểm ghi nhận giao dịch giữ cho số dư có thể đối chiếu; ngoại lệ vận hành, nếu cần mô phỏng, phải được Business Owner và Accounting Owner đánh giá riêng.	Inventory Item; Warehouse; Inventory Status: AVAILABLE; giao dịch xuất/giảm tồn; Inventory Reservation.	Bật hoặc đổi quy tắc chặn âm ảnh hưởng toàn bộ luồng giảm tồn, thông báo lỗi, báo cáo thiếu hàng và dữ liệu giao dịch đang chờ xử lý.	Kiểm tra tồn khả dụng 1, giao dịch giảm 1 thành công và về 0; giao dịch giảm tiếp 1 bị chặn; kiểm tra giữ chỗ 1 không làm tồn thực âm nhưng làm yêu cầu mới bị chặn.
BR-INV-005	Điều chỉnh tồn kho chỉ được tạo với loại tăng hoặc giảm, Inventory Item, Warehouse, số lượng lớn hơn 0, lý do chuẩn hóa và tham chiếu chứng cứ xử lý chênh lệch. Điều chỉnh giảm vẫn phải tuân thủ BR-INV-004; điều chỉnh tăng không được tự động giải phóng hoặc thay đổi các giữ chỗ hiện có.	Điều chỉnh là sửa số sổ sách nên phải phân biệt hướng tăng/giảm và có căn cứ để tái kiểm tra. Việc tự động đổi giữ chỗ khi tăng tồn sẽ pha trộn hai quyết định: ghi nhận chênh lệch và cam kết cấp hàng. Danh mục lý do và quyền thực hiện là Verification required với Business Owner, Accounting Owner và Security Owner.	Inventory Adjustment: DRAFT, POSTED, VOIDED; Inventory Item; Warehouse; Inventory Reservation; Inventory Status.	Thay đổi loại lý do, điều kiện đăng giao dịch hoặc trường chứng cứ ảnh hưởng nhật ký tồn, báo cáo chênh lệch và giao diện nhập điều chỉnh. Tác động hạch toán cụ thể nằm ngoài micro-batch này và cần Accounting Owner xác minh.	Kiểm tra số lượng 0, số âm, thiếu lý do hoặc thiếu chứng cứ đều bị chặn; điều chỉnh giảm vượt tồn khả dụng bị chặn; điều chỉnh tăng 10 không thay đổi lượng của giữ chỗ đã tồn tại.
BR-INV-006	Giao dịch đã POSTED làm thay đổi số dư tồn hoặc trạng thái giữ chỗ không được sửa trực tiếp; sửa sai phải tạo giao dịch đảo hoặc giao dịch điều chỉnh mới có liên kết tới giao dịch gốc và lý do.	Số dư hiện tại phải giải thích được từ chuỗi giao dịch. Sửa đè một giao dịch đã đăng làm mất khả năng đối chiếu trước–sau và che khuất nguyên nhân chênh lệch; do đó cần bản ghi thay thế có liên kết. Cách diễn giải kế toán của giao dịch đảo là Verification required với Accounting Owner.	Inventory Adjustment: POSTED, VOIDED; Inventory Reservation; Inventory Allocation; nhật ký giao dịch tồn kho; Inventory Item; Warehouse.	Thay đổi cơ chế sửa sau đăng ảnh hưởng audit trail mô phỏng, API giao dịch, báo cáo lịch sử và logic tính số dư.	Kiểm tra sửa trực tiếp số lượng của giao dịch POSTED bị chặn; giao dịch đảo phải tham chiếu giao dịch gốc; tổng số dư sau đảo và điều chỉnh thay thế phải khớp kết quả mong đợi.

Nguồn phương pháp cho cấu trúc quy tắc, quan hệ tác động và khả năng kiểm thử là BABOK Guide, IIBA Version 3, cùng ISTQB CTFL Syllabus v4.0.1 trong đúng ranh giới nguồn đã xác minh: chúng hỗ trợ tổ chức yêu cầu và kiểm thử hộp đen, không cung cấp chính sách tồn kho riêng cho Nova Foods. Các quyết định về thời hạn giữ chỗ, danh mục lý do điều chỉnh, thẩm quyền thao tác và diễn giải kế toán vẫn mang nhãn Project assumption hoặc Verification required cho đến khi có xác minh từ vai trò có thẩm quyền.

Quy tắc tạo lô, truy vết lô, kiểm soát hạn dùng, FEFO/FIFO và cách ly/giải phóng trong kho mô phỏng Nova Foods

Trong /01-curriculum/CANONICAL_BUSINESS_RULES.md, micro-batch này chuẩn hóa nhóm quy tắc cho Nova Foods Trading & Manufacturing ở trạng thái mô phỏng giáo dục, dùng dữ liệu tổng hợp בלבד. “Lot/Batch” là lô hoặc mẻ; “traceability” là truy vết; “expiry date” là ngày hết hạn; FEFO là first-expired, first-out tức xuất trước lô có hạn dùng gần nhất; FIFO là first-in, first-out tức nhập trước xuất trước. Cơ sở suy luận là: với hàng thực phẩm, giá trị kiểm soát không chỉ nằm ở số lượng mà còn ở danh tính lô, hạn dùng và trạng thái an toàn, vì vậy mỗi biến động phải giữ được đường đi từ Receipt đến Lot, từ Lot đến Inventory Status, và từ trạng thái quarantine đến release.

Rule ID	Quy tắc chuẩn	Affected entity/state	Change impact	Test implication
BR-INV-LOT-001	Mỗi lần nhập kho hợp lệ phải tạo ít nhất một Lot mới hoặc gắn vào Lot đã tồn tại nếu chứng từ nguồn nêu rõ cùng mã lô nhà cung cấp, cùng hàng hóa, cùng hạn dùng và cùng điều kiện kiểm soát; nếu thiếu một trong các thuộc tính này thì hệ thống phải tạo lô mới để tránh nhập nhầm vào một danh tính truy vết không đủ căn cứ. Lý do: truy vết thực phẩm cần một danh tính lô đơn nghĩa để đối chiếu sự cố, nên không được gộp lô chỉ vì giống mặt hàng.	Receipt, Lot, Inventory Item, Inventory Status	Ảnh hưởng cấu trúc dữ liệu lô, liên kết chứng từ nhập và báo cáo truy vết theo lô.	Kiểm tra trường hợp cùng SKU nhưng khác hạn dùng phải sinh Lot khác; trường hợp thiếu mã lô nguồn phải không gộp tự động.
BR-INV-LOT-002	Mỗi Lot phải mang tối thiểu các thuộc tính: mã lô, mã hàng, ngày sản xuất nếu có, ngày hết hạn nếu có, trạng thái kiểm soát, và tham chiếu nguồn tạo lô. Nếu hạn dùng không được cung cấp thì trạng thái lô phải ở dạng không đủ điều kiện xuất hoặc chờ xác minh, vì không có cơ sở để tính FEFO hay đánh giá an toàn xuất kho.	Lot, Inventory Status	Ảnh hưởng quy tắc dữ liệu master, màn hình nhập kho và logic chọn lô xuất.	Kiểm tra lô thiếu expiry date không được xếp vào danh sách xuất; phải hiển thị trạng thái chờ xác minh hoặc bị chặn xuất.
BR-INV-LOT-003	Truy vết lô phải đi theo chuỗi một-nhiều từ Receipt sang Lot và từ Lot sang các biến động tồn kho, để có thể trả lời hai câu hỏi cơ bản: lô này từ đâu đến và lô này đã đi đâu. Nếu một giao dịch làm mất liên kết này thì giao dịch đó bị xem là không đủ truy vết cho nghiệp vụ thực phẩm. Lý do: khi phát sinh cảnh báo chất lượng, kho phải khoanh vùng đúng lô thay vì truy bằng mô tả hàng hóa chung.	Receipt, Lot, Inventory Item, nhật ký tồn kho	Ảnh hưởng audit trail mô phỏng, báo cáo thu hồi và tra cứu sự cố.	Kiểm tra truy vấn theo một mã lô phải trả về chứng từ nguồn, các lần nhập-xuất liên quan và tồn còn lại.
BR-INV-LOT-004	Quy tắc FEFO là quy tắc ưu tiên dự án mặc định cho hàng có hạn dùng: hệ thống phải đề xuất xuất lô có ngày hết hạn sớm nhất trước, trừ khi một ngoại lệ được ghi nhận rõ trong thiết kế nghiệp vụ và được đánh nhãn Verification required. FIFO chỉ được dùng như quy tắc thay thế khi mặt hàng không có hạn dùng hoặc khi chủ thể nghiệp vụ xác nhận đây là nhóm hàng không bị ràng buộc bởi hạn dùng. Suy luận: với thực phẩm, rủi ro hỏng hóc gắn chặt với hạn dùng hơn ngày nhập, nên FEFO an toàn hơn FIFO.	Lot, Inventory Item, Inventory Status	Ảnh hưởng engine đề xuất xuất hàng, quy tắc phân bổ theo lô và báo cáo chọn lô.	Kiểm tra hai lô cùng hàng nhưng hạn dùng khác nhau: hệ thống phải ưu tiên lô hết hạn sớm hơn; kiểm tra mặt hàng không có hạn dùng thì không được áp FEFO bắt buộc.
BR-INV-LOT-005	Lô phải chuyển sang trạng thái QUARANTINED khi hàng có dấu hiệu chờ kiểm tra chất lượng, sai lệch chứng từ, nghi ngờ nhiễm bẩn, hoặc chưa có quyết định giải phóng. Lô ở trạng thái này không được xuất, không được tiêu thụ và không được dùng để bù trừ thiếu hụt, vì lý do kiểm soát là tách vùng rủi ro khỏi vùng khả dụng. Khi có quyết định giải phóng hợp lệ, trạng thái mới được đổi sang RELEASED và phải giữ lịch sử thay đổi trạng thái.	Lot, Inventory Status, Receipt	Ảnh hưởng logic khóa xuất kho, dashboard chất lượng và nhật ký chuyển trạng thái.	Kiểm tra lô QUARANTINED bị chặn khi tạo xuất kho; kiểm tra chỉ người có thẩm quyền mới đổi sang RELEASED theo luồng mô phỏng.

Tác động thay đổi chung của nhóm quy tắc này là: mọi màn hình nhập kho, xuất kho, tra cứu tồn và báo cáo truy vết trong corpus Nova Foods phải dùng mã lô như một khóa nghiệp vụ bắt buộc khi hàng có hạn dùng; mọi giao dịch không có đủ dữ liệu lô phải bị chặn hoặc đưa vào trạng thái chờ xác minh, không được tự suy diễn thành hợp lệ. Các trạng thái liên quan cần được chuẩn hóa trong Inventory Status thành tối thiểu: AVAILABLE, QUARANTINED, RELEASED, và trạng thái chờ xác minh khi thiếu thuộc tính bắt buộc. Nguồn phương pháp cho cách viết quy tắc và kiểm thử là BABOK Guide và ISTQB CTFL Syllabus v4.0.1; còn cách áp FEFO/FIFO, điều kiện cách ly và tiêu chí giải phóng trong Nova Foods là Project assumption cho đến khi có xác minh từ chủ thể có thẩm quyền.

Quy tắc chuyển kho nhiều kho và hiển thị tồn kho theo kho

Trong bối cảnh Nova Foods là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp, quy tắc này xác định rằng tồn kho không được xem như một con số chung cho toàn công ty nếu mục tiêu là điều hành thực tế theo kho. Lý do từ nguyên lý đầu tiên là mỗi Warehouse (kho) là một điểm kiểm soát vật lý riêng; nếu gộp tất cả số lượng lại mà không tách theo kho, người dùng có thể thấy “còn hàng” trong khi kho đang xử lý đơn thật sự lại hết hàng. Vì vậy, /01-curriculum/CANONICAL_BUSINESS_RULES.md cần quy định rõ trạng thái chuyển kho, phạm vi hiển thị, và thời điểm ghi nhận tăng giảm để tránh đếm trùng hoặc che khuất thiếu hụt.

Rule ID	Quy tắc canonical	Change impact	Affected entity/state	Ghi chú kiểm soát
BR-INV-03-001	Chuyển kho phải được khởi tạo bằng một chứng từ chuyển nội bộ có nguồn kho, đích kho, mặt hàng, số lượng và trạng thái rõ ràng; chứng từ này chỉ hợp lệ khi kho nguồn đủ tồn khả dụng tại thời điểm xác nhận.	Nếu nguồn kho không đủ, hệ thống phải chặn hoặc chỉ cho phép phương án chia tách theo chính sách được phê duyệt riêng; không được tự động tạo số âm.	Warehouse, Inventory Item, Inventory Status, Transfer Document	Điều này ngăn việc một kho “mượn” tồn từ kho khác mà không có dấu vết.
BR-INV-03-002	Khi chứng từ chuyển kho ở trạng thái đã xuất khỏi kho nguồn nhưng chưa nhập vào kho đích, số lượng phải nằm ở trạng thái in transit (đang chuyển) và không được tính là tồn khả dụng để bán, giữ chỗ hay xuất tiếp.	Tác động là bảng cân đối tồn phải tách ba lớp: tồn tại kho nguồn, tồn đang chuyển, tồn tại kho đích.	Inventory Balance, Inventory Status, Warehouse	Đây là cách tránh cộng đôi: đã trừ ở nguồn nhưng chưa được cộng ở đích.
BR-INV-03-003	Tồn kho khả dụng chỉ được hiển thị theo phạm vi kho mà người dùng được cấp quyền; tổng hợp toàn doanh nghiệp chỉ hiển thị cho vai trò có quyền xem đa kho.	Nếu không có quyền phù hợp, giao diện và API chỉ trả về dữ liệu của kho được gán, không trả về tổng tất cả kho.	Warehouse, User Scope, Inventory View	Quy tắc này bảo vệ tính đúng của quyết định vận hành và giảm nhầm lẫn khi đối chiếu.
BR-INV-03-004	Khi nhập kho đích được xác nhận, hệ thống mới tăng tồn khả dụng của kho đích và kết thúc trạng thái in transit; nếu hàng bị từ chối ở đích, phải trả về trạng thái xử lý ngoại lệ theo chứng từ gốc.	Tác động là thời điểm ghi nhận chuyển đổi trạng thái phải nhất quán giữa kho nguồn, kho đích và ledger tồn kho.	Warehouse, Inventory Item, Inventory Status, Transfer Receipt	Không được tăng tồn đích trước khi có xác nhận nhận hàng.

Về kiểm thử, QA cần chứng minh ba biên quan trọng: một là chuyển kho khi kho nguồn vừa đủ số lượng thì hệ thống chặn không cho âm và vẫn cho phép khi đủ; hai là trong khoảng giữa xuất và nhập, số lượng in transit không xuất hiện như tồn khả dụng ở bất kỳ kho nào; ba là người dùng chỉ thấy dữ liệu trong phạm vi kho được cấp quyền, còn tổng đa kho chỉ xuất hiện với vai trò phù hợp. Với trường hợp biên, cần thử chuyển một phần, chuyển toàn bộ, kho nguồn bằng 0, và kho đích nhận chậm để bảo đảm trạng thái không tự nhảy và không sinh số lượng ảo.

Quy tắc Kiểm kê, Xử lý Chênh lệch và Đối soát Tồn kho

Nova Foods là bối cảnh mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Kiểm kê tồn kho là việc đếm thực tế hàng tại vị trí kho rồi so sánh với số lượng hệ thống; chênh lệch là phần khác nhau giữa hai số lượng; đối soát tồn kho là quá trình điều tra, quyết định và lưu bằng chứng để số liệu thực tế, nghiệp vụ và hệ thống có thể được giải thích nhất quán. Các quy tắc dưới đây là Project assumption, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh; không phải hướng dẫn hạch toán, quyết định pháp lý hoặc phê duyệt vận hành.

Rule ID	Quy tắc chuẩn	Kích hoạt, điều kiện và lý do	Thực thi, ngoại lệ và bằng chứng	Entity/state bị ảnh hưởng	Change impact	Test implication
BR-INV-001	Hệ thống phải tạo một phiên kiểm kê riêng cho từng Warehouse và thời điểm chốt đếm; mỗi dòng đếm phải xác định Inventory Item, đơn vị tính, vị trí, số lượng hệ thống tại thời điểm chốt và số lượng thực đếm.	Kích hoạt khi nhân viên kho mở phiên kiểm kê. Điều kiện chốt số liệu là cần thiết vì giao dịch phát sinh sau khi bắt đầu đếm không được làm thay đổi mốc so sánh; nếu không có mốc, chênh lệch không thể được diễn giải đáng tin cậy.	Phiên chỉ chuyển sang COUNTED khi mọi dòng được đếm hoặc được đánh dấu không tìm thấy với lý do. Bằng chứng tối thiểu gồm mã phiên, người đếm, thời điểm, kho, dòng đếm và kết quả. Không cho phép ghi nhận số lượng âm khi nhập kết quả đếm.	Warehouse: AVAILABLE_FOR_COUNT → COUNT_IN_PROGRESS → COUNTED; Inventory Item: ON_HAND; Inventory Status: AVAILABLE, QUARANTINED phải được đếm tách biệt.	Thay đổi cách chốt thời điểm hoặc trường dòng đếm ảnh hưởng báo cáo chênh lệch, khả năng truy vết thao tác kho và các test case đang tham chiếu BR-INV-001.	Kiểm thử giá trị biên: số thực đếm bằng 0, bằng số hệ thống, lớn hơn số hệ thống. Kiểm thử ngoại lệ: thiếu người đếm, thiếu kho, đơn vị tính không khớp hoặc nhập số âm phải bị từ chối.
BR-INV-002	Hệ thống phải tính chênh lệch theo công thức Số lượng thực đếm − Số lượng hệ thống tại thời điểm chốt; không được tự động sửa tồn kho ngay khi phát hiện chênh lệch.	Kích hoạt khi dòng đếm được hoàn tất. Việc tách “phát hiện” khỏi “điều chỉnh” ngăn số liệu hệ thống bị thay đổi trước khi nguyên nhân được xem xét, ví dụ lỗi đơn vị tính, hàng đặt sai vị trí hoặc giao dịch ghi nhận muộn.	Dòng có chênh lệch khác 0 chuyển VARIANCE_PENDING_REVIEW; dòng bằng 0 chuyển MATCHED. Nhân viên phải chọn một mã nguyên nhân thuộc danh mục được quản trị trước khi đề xuất điều chỉnh. Ví dụ tổng hợp: hệ thống ghi 120 kg, thực đếm 118 kg, chênh lệch là -2 kg; hệ thống lưu phép tính và không tự giảm tồn.	Inventory Item: ON_HAND → COUNT_MATCHED hoặc VARIANCE_PENDING_REVIEW; Warehouse: giữ trạng thái phiên COUNTED; Inventory Status: không tự đổi chỉ vì có chênh lệch.	Bổ sung, xóa hoặc đổi mã nguyên nhân làm thay đổi báo cáo xu hướng sai lệch và logic phân quyền xử lý; cần đánh giá lại mapping dữ liệu lịch sử.	Kiểm thử hộp đen theo phân vùng tương đương: chênh lệch âm, bằng không, dương. Kiểm tra kết quả tính toán với số thập phân hợp lệ theo đơn vị tính và xác nhận không có thay đổi ON_HAND trước bước quyết định.
BR-INV-003	Mọi điều chỉnh tồn kho phát sinh từ kiểm kê phải có liên kết đến một dòng chênh lệch đã được xem xét, người thực hiện, thời điểm và lý do; hệ thống phải lưu trước–sau của số lượng điều chỉnh.	Kích hoạt khi người có quyền xử lý chênh lệch yêu cầu cập nhật tồn. Lý do là điều chỉnh là tác động không thể giải thích chỉ bằng số cuối cùng; cần bằng chứng để tái dựng ai thay đổi gì và vì sao.	Chỉ dòng ở VARIANCE_PENDING_REVIEW mới được chuyển sang ADJUSTMENT_POSTED. Nếu kết quả điều chỉnh làm số lượng khả dụng nhỏ hơn 0, hệ thống phải chặn và giữ dòng ở ADJUSTMENT_REJECTED; không dùng kiểm kê để vượt quy tắc ngăn tồn âm. Bằng chứng gồm mã dòng kiểm kê, số trước điều chỉnh, số điều chỉnh, số sau điều chỉnh, lý do và định danh người thao tác.	Inventory Item: VARIANCE_PENDING_REVIEW → ADJUSTMENT_POSTED hoặc ADJUSTMENT_REJECTED; Warehouse: số lượng ON_HAND; Inventory Status: duy trì trạng thái hiện hữu, không chuyển trạng thái chất lượng do điều chỉnh số lượng.	Đổi quy tắc phân quyền, lý do điều chỉnh hoặc cơ chế lưu audit trail ảnh hưởng kiểm soát nội bộ và khả năng truy vết test evidence. Nội dung có liên quan giá trị hàng tồn hoặc bút toán phải được tách sang phạm vi tài chính và gắn Verification required với Accounting Owner.	Kiểm thử ngoại lệ: điều chỉnh khiến tồn âm, điều chỉnh không có lý do, người không có quyền, hoặc dòng đã ADJUSTMENT_POSTED bị gửi lại lần hai. Kỳ vọng hệ thống chặn thao tác và không thay đổi số lượng.
BR-INV-004	Đối soát tồn kho phải hoàn tất ở cấp Warehouse sau khi tất cả dòng kiểm kê đạt MATCHED, ADJUSTMENT_POSTED hoặc ADJUSTMENT_REJECTED; phiên có dòng bị từ chối không được đóng là đã đối soát.	Kích hoạt khi người phụ trách yêu cầu đóng phiên kiểm kê. Lý do là trạng thái đóng phải phản ánh kết quả có thể giải thích được, không che giấu chênh lệch chưa xử lý.	Hệ thống tạo bản tổng hợp gồm tổng dòng, dòng khớp, dòng chênh lệch, dòng đã điều chỉnh, dòng bị từ chối và danh sách nguyên nhân. Phiên chỉ chuyển RECONCILED khi không còn dòng VARIANCE_PENDING_REVIEW hoặc ADJUSTMENT_REJECTED. Dòng bị từ chối phải được mở phiên xử lý mới, không được sửa đè kết quả cũ.	Warehouse: COUNTED → RECONCILED hoặc giữ COUNT_IN_PROGRESS; Inventory Item: trạng thái kết quả từng dòng; Inventory Status: được hiển thị riêng trong tổng hợp đối soát.	Thay đổi tiêu chí đóng phiên ảnh hưởng dashboard tồn kho, quy trình bàn giao kho và truy vết từ báo cáo đến dòng đếm gốc. Không suy diễn đây là chốt sổ kế toán hay xác nhận tuân thủ.	Kiểm thử điều kiện biên: một kho có đúng một dòng; tất cả dòng khớp; chỉ một dòng chờ xem xét; một dòng bị từ chối. Xác nhận chỉ hai trường hợp đầu đủ điều kiện RECONCILED.

Nguồn phân loại cho các quy tắc là Project assumption của corpus Nova Foods ERP mô phỏng. Cách viết rule có cấu trúc, điều kiện kiểm thử và bằng chứng quan sát được phù hợp mục tiêu quản trị yêu cầu và kiểm thử của BABOK Guide v3 तथा ISTQB CTFL v4.0.1, nhưng không suy diễn điều khoản chi tiết từ các nguồn này. Bất kỳ quyết định nào về ngưỡng chênh lệch, phân quyền phê duyệt thực tế, định giá hàng tồn, bút toán hoặc nghĩa vụ lưu chứng từ phải được gắn Verification required và chuyển đúng vai trò Business Owner, Accounting Owner hoặc Legal Owner.

Danh mục thực thể và trạng thái chịu ảnh hưởng

Nova Foods Trading & Manufacturing là bối cảnh mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Danh mục dưới đây xác định ngôn ngữ dữ liệu chuẩn để các quy tắc mua hàng, kho và truy xuất ở các phần tiếp theo cùng tham chiếu một nghĩa. Thực thể (entity) là đối tượng nghiệp vụ được hệ thống lưu và quản lý; trạng thái (state) là giá trị thể hiện vị trí vòng đời hiện tại của thực thể. Đây là Project assumption, vì nguồn đã cung cấp không xác nhận mô hình dữ liệu hay cấu hình ERP thực tế của Nova Foods.

Thực thể canonical	Mục đích dữ liệu	Khóa nhận diện tối thiểu	Trạng thái canonical được phép tham chiếu trong section này
Supplier	Lưu đối tác cung cấp hàng hóa hoặc dịch vụ.	SupplierID	DRAFT, ACTIVE, SUSPENDED, INACTIVE
Purchase Order	Ghi nhận cam kết mua hàng mô phỏng với nhà cung cấp.	PurchaseOrderID	DRAFT, SUBMITTED, APPROVED, CLOSED, CANCELLED
Receipt	Ghi nhận sự kiện tiếp nhận hàng vào một kho cụ thể.	ReceiptID	DRAFT, POSTED, REVERSED, CANCELLED
Inventory Item	Đại diện mặt hàng được quản lý tồn kho.	ItemID	ACTIVE, INACTIVE
Lot	Đại diện lô hoặc batch (nhóm hàng được nhận/sản xuất cùng dấu vết nhận diện) của một Inventory Item.	LotID và ItemID	PENDING_INSPECTION, AVAILABLE, QUARANTINED, EXPIRED, DEPLETED, CLOSED
Warehouse	Đại diện địa điểm kho logic nơi số lượng tồn được quan sát.	WarehouseID	ACTIVE, INACTIVE
Inventory Status	Phân loại khả năng sử dụng của số lượng tồn tại tổ hợp ItemID–LotID–WarehouseID.	InventoryStatusCode	AVAILABLE, RESERVED, QUARANTINED, BLOCKED

Rule ID	Quy tắc canonical	Cơ sở và cầu nối suy luận	Thực thể/trạng thái chịu ảnh hưởng	Change impact (tác động khi thay đổi)	Phân loại nguồn
BR-INV-001	Mỗi tham chiếu tồn kho phải xác định tối thiểu ItemID, WarehouseID và InventoryStatusCode; khi mặt hàng có quản lý lô, phải có thêm LotID.	Số lượng chỉ có ý nghĩa khi biết hàng nào, ở kho nào và có được phép sử dụng hay không. Nếu thiếu một khóa, cùng một số lượng có thể bị diễn giải nhầm là tồn khả dụng hoặc tồn cách ly.	Inventory Item; Lot; Warehouse; Inventory Status	Thay đổi khóa hoặc mã trạng thái làm ảnh hưởng báo cáo tồn, giao diện tra cứu, tích hợp và mọi quy tắc tham chiếu số lượng.	Project assumption
BR-INV-002	Lot phải thuộc đúng một Inventory Item; một LotID không được dùng để biểu diễn hai mặt hàng khác nhau.	Lô dùng để duy trì dấu vết của một mặt hàng cụ thể. Nếu một mã lô gắn với nhiều hàng, truy vết từ tồn kho về nguồn hàng trở nên đa nghĩa và không thể xác định chính xác đối tượng bị ảnh hưởng.	Lot; Inventory Item; Receipt	Đổi quan hệ Lot–Inventory Item ảnh hưởng dữ liệu lịch sử, truy vết, báo cáo hạn dùng và giao diện nhập liệu.	Project assumption; bối cảnh truy xuất cần Verification required với domain owner và nguồn Luật An toàn thực phẩm đã liệt kê
BR-INV-003	Receipt ở trạng thái POSTED phải tham chiếu một Purchase Order hợp lệ và một Warehouse có trạng thái ACTIVE; Receipt ở DRAFT, REVERSED hoặc CANCELLED không được diễn giải là số dư kho hiện hành.	Phiếu nhận là chứng cứ sự kiện nhận hàng trong mô hình mô phỏng. Tách trạng thái đã ghi nhận khỏi trạng thái nháp, đảo hoặc hủy ngăn việc xem dữ liệu chưa có hiệu lực nghiệp vụ là tồn kho.	Receipt: DRAFT, POSTED, REVERSED, CANCELLED; Purchase Order; Warehouse: ACTIVE	Thay đổi định nghĩa POSTED ảnh hưởng logic số dư, đối soát chứng từ, báo cáo nhận hàng và liên kết mua hàng–kho.	Project assumption
BR-INV-004	Inventory Status là thuộc tính của số lượng tại tổ hợp mặt hàng–lô–kho, không phải trạng thái chung thay thế cho trạng thái của Inventory Item, Lot hoặc Warehouse.	Một mặt hàng có thể khả dụng ở kho này nhưng bị cách ly ở kho khác; một lô cũng có thể hết tại một kho mà vẫn còn tại kho khác. Vì vậy, gán một trạng thái chung cho cả thực thể sẽ làm mất ngữ cảnh địa điểm và số lượng.	Inventory Item; Lot; Warehouse; Inventory Status: AVAILABLE, RESERVED, QUARANTINED, BLOCKED	Thay đổi cấp gán trạng thái ảnh hưởng mô hình dữ liệu, phân quyền thao tác, báo cáo tồn theo kho và các kiểm tra liên hệ thống.	Project assumption
BR-INV-005	Supplier chỉ được dùng làm đối tác tham chiếu của Purchase Order khi ở trạng thái ACTIVE; trạng thái SUSPENDED và INACTIVE phải vẫn được lưu để bảo toàn lịch sử, nhưng không được hiểu là đối tác đang sẵn sàng cho giao dịch mới.	Trạng thái hiện hành quyết định khả năng dùng trong giao dịch mới, còn dữ liệu lịch sử cần giữ liên kết với đối tác đã từng xuất hiện. Hai nhu cầu này khác nhau nên không được xóa hoặc tái sử dụng định danh nhà cung cấp.	Supplier: ACTIVE, SUSPENDED, INACTIVE; Purchase Order	Thay đổi ngữ nghĩa trạng thái nhà cung cấp ảnh hưởng danh sách chọn đối tác, kiểm tra tạo chứng từ và truy vết lịch sử mua hàng.	Project assumption
BR-INV-006	Mọi giá trị trạng thái phải lấy từ danh mục canonical đã nêu; không dùng biến thể tự do như Đang dùng, Còn hàng, Tạm khóa hoặc mã cục bộ không được ánh xạ rõ ràng.	Quy tắc liên file và kiểm thử chỉ đáng tin khi cùng một khái niệm có một mã chuẩn. Biến thể tự do tạo ra nhiều cách hiểu cho cùng trạng thái, làm sai tổng hợp dữ liệu và không thể kiểm tra nhất quán.	Tất cả thực thể và trạng thái trong bảng danh mục	Bổ sung, đổi tên hoặc ngừng dùng mã trạng thái đòi hỏi đánh giá tác động đến dữ liệu lịch sử, API, báo cáo, tài liệu và test basis.	Project assumption; thuật ngữ kiểm thử tham chiếu phạm vi ISTQB CTFL, không suy diễn yêu cầu sản phẩm

Các trạng thái AVAILABLE, RESERVED, QUARANTINED và BLOCKED trong danh mục này chỉ mô tả khả năng sử dụng tồn ở mức dữ liệu; chúng chưa tự xác định quyền phê duyệt, điều kiện chuyển trạng thái, xử lý chênh lệch, nghĩa vụ an toàn thực phẩm hay hiệu lực kế toán. Những diễn giải đó cần được quản lý ở quy tắc nghiệp vụ riêng, với Verification required từ Business Owner, Accounting Owner hoặc domain owner phù hợp trước khi được dùng ngoài mục đích học liệu.

Tác động kiểm thử cho kịch bản kho và truy xuất nguồn gốc

Với Nova Foods là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp, phần kiểm thử cho /01-curriculum/CANONICAL_BUSINESS_RULES.md ở mục này phải chứng minh được hai việc: thứ nhất, rule về kho và truy xuất nguồn gốc có thể quan sát được bằng bằng chứng; thứ hai, các trường hợp biên và ngoại lệ không làm sai lệch trạng thái tồn kho. Theo ISTQB CTFL, cách làm đúng là dùng equivalence partitioning (phân vùng tương đương: gom dữ liệu vào nhóm hợp lệ/không hợp lệ) và boundary value analysis (phân tích giá trị biên: kiểm tại ngưỡng tối đa, tối thiểu, bằng 0, âm, hoặc sát hạn mức) để phát hiện lỗi ở ranh giới thay vì chỉ kiểm dữ liệu “đẹp”. Vì vậy, mọi test case phải chỉ rõ Traceability từ rule đến dữ liệu vào, thao tác, kết quả quan sát, và Evidence (bằng chứng) như log nghiệp vụ, trạng thái chứng từ, số lượng tồn, mã lô, trạng thái kho, và dấu vết chuyển đổi trạng thái; không được dừng ở mô tả cảm tính.

Mã kiểm thử kế hoạch	Kịch bản biên/ngoại lệ cần phủ	Dữ liệu biên tối thiểu	Kết quả mong đợi quan sát được	Thực thể/trạng thái chịu ảnh hưởng
BR-03-TEST-001	Lô hàng cận ngày hết hạn để kiểm tra truy vết và xếp ưu tiên xử lý	Hai lô cùng mặt hàng, một lô còn hạn dài và một lô sát ngưỡng cảnh báo	Hệ thống phải cho phép nhận diện đúng lô, giữ dấu vết lô riêng biệt, và không nhập nhầm sang lô khác	Lot, Inventory Item, Inventory Status
BR-03-TEST-002	Tồn kho bằng 0 và yêu cầu xuất tiếp để kiểm tra ngăn âm kho	Số lượng tồn = 0, phát sinh yêu cầu xuất 1 đơn vị	Giao dịch bị chặn hoặc chuyển sang trạng thái ngoại lệ theo rule đã định; không tạo số âm	Inventory Item, Warehouse, Inventory Status
BR-03-TEST-003	Sai lệch giữa chứng từ nhận hàng và số lượng thực nhận	PO/Receipt có số lượng lệch 1 đơn vị	Hệ thống phải ghi nhận discrepancy (chênh lệch) rõ ràng, không tự động hợp thức hóa chênh lệch	Purchase Order, Receipt, Inventory Item
BR-03-TEST-004	Chuyển kho giữa hai kho có cùng mặt hàng nhưng khác trạng thái sẵn sàng	Một kho có hàng khả dụng, kho còn lại không có hàng	Số liệu tồn phải dịch chuyển đúng kho nguồn/kho đích, không làm mất truy vết lô	Warehouse, Lot, Inventory Status
BR-03-TEST-005	Kiểm đếm phát hiện chênh lệch so với sổ hệ thống	Số kiểm đếm nhỏ hơn hoặc lớn hơn hệ thống 1 đơn vị	Phát sinh variance (chênh lệch kiểm kê) và giữ lịch sử điều chỉnh có truy vết	Inventory Item, Warehouse, Inventory Status

Điểm quyết định kiểm thử là: nếu một rule về kho hoặc truy xuất nguồn gốc không tạo ra được quan sát đúng trên Receipt, Lot, Warehouse hoặc Inventory Status, thì rule đó chưa đủ kiểm thử được và phải bổ sung điều kiện chấp nhận rõ hơn. Ngược lại, nếu test chỉ kiểm “đúng luồng” mà không có dữ liệu biên như số lượng bằng 0, cận hạn dùng, sai lệch nhận hàng, hoặc chuyển kho giữa hai trạng thái khác nhau, thì test chưa đủ mạnh để bắt lỗi ngoại lệ. Do đó, với section này, mỗi test implication phải gắn một hành vi đo được, một biên dữ liệu cụ thể, và một kết quả thất bại dự kiến nếu rule bị sai; đây là cách bảo đảm tính truy vết từ yêu cầu đến kiểm thử cho corpus Nova Foods.

Manufacturing, BOM, Work Orders, and Production Control

Quy ước schema chuẩn cho catalog rule sản xuất

Nova Foods là bối cảnh ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mọi rule được lập trong section này phải là một record độc lập theo cùng schema chuẩn; một rule không được chỉ tồn tại dưới dạng đoạn mô tả, ví dụ minh họa hoặc tiêu đề bảng. Mục tiêu của schema là biến một phát biểu nghiệp vụ thành đối tượng có thể truy vết: biết rule nói gì, áp dụng cho ai hoặc đối tượng nào, dựa trên thẩm quyền nào, và được xem xét hiệu lực từ ngày nào.

Trường schema bắt buộc	Quy tắc ghi nhận	Lý do kiểm soát
Rule ID	Phải dùng ID đã được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự đổi, tái sử dụng hoặc tạo biến thể ID trong prose.	Giữ một nhận diện duy nhất khi liên kết rule với requirement, test và issue.
Rule name	Tên ngắn, nêu một quyết định nghiệp vụ có thể hiểu độc lập.	Giúp người học phân biệt tên rule với diễn giải hoặc test case.
Rule statement	Viết theo cấu trúc: điều kiện kích hoạt → hành vi bắt buộc hoặc bị cấm → kết quả kiểm soát.	Rule phải có hành vi quan sát được, không chỉ ghi mục tiêu chung.
Rule classification	Chỉ nhận một trong ba giá trị: Operational rule, Project assumption, Verification required.	Không được trình bày giả định hoặc nội dung chưa xác minh như quyết định vận hành đã có hiệu lực.
Authority type	Ghi rõ Business authority, Legal authority, Accounting authority, Production authority, hoặc Curriculum governance authority.	“Authority” là nguồn hoặc vai trò có quyền xác định căn cứ của rule, không phải tên người viết tài liệu.
Authority reference	Nêu artifact nguồn, nguồn chính thức đã xác minh, hoặc vai trò cần xác nhận; không tạo trích dẫn, điều khoản hoặc quyết định không có trong nguồn.	Cho phép reviewer kiểm tra đường đi từ rule đến căn cứ.
Authority status	Ghi Verified source boundary, Project assumption, hoặc Verification required.	Phân biệt phạm vi sử dụng an toàn của nguồn với xác nhận nghiệp vụ thực tế.
Effective from	Bắt buộc theo định dạng YYYY-MM-DD, múi giờ Asia/Ho_Chi_Minh.	Xác định ngày bắt đầu được catalog xem xét, không mặc định là ngày vận hành ERP.
Effective to	Bắt buộc theo định dạng YYYY-MM-DD hoặc giá trị No end date recorded.	Ngăn việc suy diễn rằng rule luôn còn hiệu lực khi không có lịch sử thay đổi.
Rule status	Tại micro-batch này là IN_REVIEW.	IN_REVIEW chỉ biểu thị đang xem xét có kiểm soát; không là APPROVED, BASELINED hoặc production-ready.
Affected entities/states	Liệt kê entity và state bằng tên canonical khi đã được registry ghi nhận.	Bảo toàn khả năng truy vết mà không thay thế thiết kế dữ liệu hoặc cấu hình ERP.
Traceability links	Liên kết đến need, requirement, test implication, issue hoặc escalation bằng ID canonical khi các artifact đó tồn tại.	Một rule cần có đường kiểm tra xuôi tới kiểm thử và ngược về căn cứ.
Rationale and evidence bridge	Nêu rõ bằng chứng đầu vào và suy luận dẫn đến rule.	Mọi inference phải cho thấy cầu nối giữa evidence và kết luận, tránh biến suy đoán thành fact.

Mẫu record bắt buộc

Trường	Giá trị mẫu ở mức schema
Rule ID	ID được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Rule name	Tên một quyết định nghiệp vụ sản xuất
Rule statement	Khi điều kiện đã xác định xảy ra, hệ thống hoặc vai trò phải thực hiện hành vi xác định và lưu kết quả kiểm soát xác định.
Rule classification	Operational rule hoặc Project assumption hoặc Verification required
Authority type	Một loại authority trong danh mục schema
Authority reference	Nguồn chính thức, artifact kiểm soát, hoặc vai trò có thẩm quyền cần xác nhận
Authority status	Verified source boundary, Project assumption, hoặc Verification required
Effective from	2026-08-07
Effective to	No end date recorded
Rule status	IN_REVIEW
Affected entities/states	Entity/state canonical đã đăng ký
Traceability links	ID canonical của artifact liên quan khi đã được đăng ký
Rationale and evidence bridge	Evidence đã biết → lý do suy luận → giới hạn của kết luận

Ngày 2026-08-07 trong mẫu chỉ là ngày kiểm soát của corpus tại version v0.9.0, không chứng minh rule có hiệu lực vận hành tại Nova Foods. Cầu nối suy luận là: metadata của các artifact phụ thuộc xác nhận trạng thái IN_REVIEW, không có baseline reference và không có approval reference; vì vậy một rule được ghi trong catalog chỉ có thể được mô tả là đang được xem xét. Nếu business owner hoặc production authority chưa xác nhận ngày vận hành, trường Rule classification phải là Project assumption hoặc Verification required, còn Authority reference phải nêu đúng vai trò cần xác minh.

Phân cấp authority và giới hạn sử dụng nguồn

Loại căn cứ	Có thể hỗ trợ	Không được suy diễn
Curriculum governance authority từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md	ID, trạng thái artifact, version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, phạm vi mô phỏng và giới hạn IN_REVIEW.	Quyết định vận hành nhà máy, approval nghiệp vụ, baseline hoặc quyền triển khai production.
Production authority	Quy tắc vận hành sản xuất khi được business owner hoặc production owner xác nhận trong artifact kiểm soát phù hợp.	Diễn giải pháp lý, an toàn thực phẩm hoặc kế toán khi không có vai trò chuyên môn tương ứng.
Legal authority từ Luật An toàn thực phẩm, nguồn chính thức được cung cấp	Bối cảnh cần xác minh liên quan an toàn thực phẩm, truy xuất nguồn gốc hoặc thu hồi.	Điều khoản chi tiết, nghĩa vụ ERP cụ thể hoặc kết luận tuân thủ nếu chưa được legal owner và domain owner xác minh.
Accounting authority	Các tác động kế toán khi có xác nhận của vai trò kế toán có thẩm quyền.	Tự xác lập hạch toán, thuế, giá vốn hoặc chứng từ từ rule sản xuất.
Verified source boundary	Thuật ngữ và cách tổ chức yêu cầu theo phạm vi nguồn đã xác minh, như BABOK Guide hoặc ISO/IEC/IEEE 29148.	Số trang, điều khoản, trích dẫn chi tiết hoặc yêu cầu không thể kiểm chứng trực tiếp từ phạm vi nguồn được cung cấp.

Một record chỉ được phân loại Operational rule khi authority reference xác định được nguồn quyết định nghiệp vụ hoặc vai trò có thẩm quyền và ngày Effective from không mâu thuẫn với trạng thái record. Nếu rule được suy ra từ cấu trúc học liệu, ví dụ để tạo tình huống cho người học, phải gắn Project assumption. Nếu rule có thể tác động đến an toàn thực phẩm, truy xuất nguồn gốc, kế toán, thuế, pháp lý hoặc vận hành thực tế nhưng chưa có xác minh phù hợp, phải gắn Verification required; không được dùng ngôn ngữ khẳng định rằng Nova Foods đã áp dụng rule đó.

Quy tắc BOM: hiệu lực, phiên bản, thay thế vật tư và phê duyệt

Trong Nova Foods mô phỏng, BOM (Bill of Materials = định mức/cấu trúc nguyên vật liệu của một sản phẩm) phải được quản trị như một đối tượng có lịch sử rõ ràng, vì cùng một thành phẩm có thể đổi công thức, đổi bao bì, hoặc đổi nhà cung cấp mà không được làm mơ hồ phiên bản đang áp dụng. Căn cứ suy luận: nếu BOM không có ngày hiệu lực, phiên bản, và trạng thái phê duyệt tách bạch, hệ thống sẽ không biết dùng cấu phần nào để ghi nhận chi phí, kiểm soát chất lượng, hoặc truy vết lô sau này; vì vậy quy tắc phải ưu tiên tính xác định hơn sự tiện lợi vận hành. Nguồn nền cho cách viết quy tắc này là BABOK v3 và ISO/IEC/IEEE 29148:2018 ở mức nguyên tắc quản trị yêu cầu, cùng bối cảnh mô phỏng giáo dục của Nova Foods; mọi dữ liệu đều là tổng hợp, không phải dữ liệu thật.

Rule ID	Quy tắc canonical	Authority	Effective date	Phạm vi tác động	Lý do và cầu nối suy luận
BR-MFG-BOM-001	Mỗi BOM phải có BOM Code, Version, Status, Effective From, Effective To và Approval Reference; nếu thiếu một trong các trường này thì BOM không được xem là hợp lệ để tham chiếu vận hành.	Business Owner + Master Data Owner	2026-08-07	BOM	BOM là bản mô tả cấu phần; muốn dùng an toàn phải biết “bản nào”, “từ khi nào”, và “ai cho phép”. Thiếu các trường này sẽ làm mất truy vết và tạo rủi ro dùng nhầm công thức.
BR-MFG-BOM-002	Chỉ BOM ở trạng thái Approved mới được coi là BOM hiệu lực; các trạng thái như Draft, Pending Approval, Superseded, Inactive không được dùng làm nguồn chuẩn để lập kế hoạch hay phát hành sản xuất.	Business Owner	2026-08-07	BOM	Phê duyệt là điểm cắt trách nhiệm. Nếu cho phép dùng BOM chưa duyệt, hệ thống sẽ biến bản nháp thành chuẩn vận hành, trái với nguyên tắc kiểm soát thay đổi.
BR-MFG-BOM-003	Khi có BOM mới thay BOM cũ, phiên bản mới phải bắt đầu hiệu lực theo ngày giờ đã ghi, và BOM cũ phải chuyển sang Superseded hoặc Inactive theo quy tắc đóng hiệu lực; hai BOM không được cùng là nguồn chuẩn cho cùng một sản phẩm trong cùng một khoảng thời gian hiệu lực.	Business Owner + Master Data Owner	2026-08-07	BOM, phiên bản BOM	Phiên bản song song cho cùng một thời điểm sẽ làm kết quả phụ thuộc vào lựa chọn ngầm của hệ thống. Quy tắc này cắt bỏ mơ hồ bằng cách chỉ cho phép một nguồn chuẩn hiệu lực tại một thời điểm.
BR-MFG-BOM-004	Mọi thay thế vật tư trong BOM phải được ghi rõ là thay thế chính thức cho một mã vật tư cụ thể, kèm lý do thay thế và phạm vi áp dụng; thay thế chỉ hợp lệ nếu có phê duyệt tương ứng với quyền hạn đã định nghĩa.	Business Owner + QA/QA Owner theo mô hình kiểm soát chất lượng nội bộ	2026-08-07	BOM, vật tư thay thế	Thay thế không chỉ là đổi mã hàng; nó có thể đổi chất lượng, định lượng, hoặc rủi ro an toàn. Vì vậy cần biết thay cái gì, thay vì sao, và ai có quyền chấp thuận.
BR-MFG-BOM-005	Nếu BOM có nhiều phương án thay thế hợp lệ, hệ thống phải xếp hạng ưu tiên theo thứ tự đã cấu hình; nếu không có ưu tiên được cấu hình thì phải dừng ở mức cảnh báo nghiệp vụ và không tự suy diễn phương án chọn.	Business Owner	2026-08-07	BOM, substitution	Khi có nhiều lựa chọn ngang nhau, máy không được tự đoán ý nghĩa nghiệp vụ. Việc chọn phương án là quyết định kinh doanh, không phải quyết định kỹ thuật tự động.
BR-MFG-BOM-006	BOM chỉ được sửa đổi thông qua quy trình quản trị thay đổi; mọi chỉnh sửa trực tiếp trên bản đã duyệt phải tạo phiên bản mới thay vì ghi đè phiên bản cũ.	Master Data Owner	2026-08-07	BOM, lịch sử phiên bản	Ghi đè làm mất dấu vết “trước/sau”, khiến kiểm tra nguyên nhân sai lệch không còn khả thi. Phiên bản mới bảo toàn lịch sử và hỗ trợ truy vết.

Quy tắc phê duyệt và hiệu lực vận hành: Approved chỉ có nghĩa là BOM đã qua kiểm soát nội bộ đúng thẩm quyền trong mô phỏng Nova Foods; nó không đồng nghĩa với phê duyệt pháp lý, phê duyệt sản xuất thực tế, hay xác nhận tuân thủ ngoài phạm vi corpus. Effective From và Effective To phải được hiểu theo múi giờ chuẩn của corpus là Asia/Ho_Chi_Minh; nếu thiếu giờ cụ thể thì chỉ được coi là hiệu lực ở mức ngày, không được tự suy diễn sang giờ đầu ngày hoặc cuối ngày. Đây là điểm quan trọng vì cùng một ngày nhưng khác giờ có thể làm thay đổi BOM nào được xem là hợp lệ tại thời điểm giao dịch.

Giả định cần xác nhận bởi Business Owner: 1) tiêu chí phân biệt Approved và Pending Approval trong môi trường mô phỏng có yêu cầu một hay nhiều cấp duyệt; 2) khi một BOM có thay thế vật tư, có cho phép áp dụng tự động theo ưu tiên hay phải chọn thủ công; 3) nếu một sản phẩm có BOM cho từng thị trường/khách hàng, có coi đó là các BOM khác nhau hay là một BOM có thuộc tính biến thể. Các điểm này chưa thể kết luận từ nguồn seed, nên phải giữ nhãn Verification required cho đến khi chủ nghiệp vụ Nova Foods xác nhận.

Quy tắc phát hành, cấp phát, theo dõi và kết thúc Lệnh sản xuất

Trong Nova Foods là mô phỏng giáo dục dùng dữ liệu tổng hợp, Work Order (lệnh sản xuất) là chỉ thị thực hiện một lượng sản phẩm cụ thể; Material Issue (cấp phát nguyên liệu) là giao dịch ghi nhận nguyên liệu đã rời trạng thái sẵn dùng để phục vụ lệnh; scrap (phế phẩm) là lượng không đạt yêu cầu và không được tính vào sản lượng hoàn thành; rework (tái chế/tái xử lý) là lượng cần xử lý lại theo quyết định nghiệp vụ. Các quy tắc dưới đây là quy tắc vận hành đề xuất, không phải kết luận về quy trình thực tế, an toàn thực phẩm, hạch toán hay phê duyệt của Nova Foods.

ID quy tắc	Quy tắc chuẩn và tiêu chí quyết định	Thực thể/trạng thái bị ảnh hưởng	Authority và phân loại nguồn	Ngày hiệu lực
BR-MFG-001	Hệ thống chỉ cho phép chuyển Work Order từ DRAFT sang RELEASED khi lệnh có mã sản phẩm, số lượng kế hoạch lớn hơn 0, đơn vị tính, kho sản xuất và phiên bản BOM được tham chiếu. Cầu nối suy luận: thiếu một trong các dữ liệu này thì nhân sự xưởng không có đối tượng, lượng, nơi thực hiện hoặc định mức để kiểm soát sản xuất; vì vậy phát hành lệnh sẽ tạo giao dịch không thể kiểm tra đầy đủ.	Work Order: DRAFT → RELEASED; Production Status	Project assumption; cần Business Owner và Production Owner xác nhận quy trình phát hành thực tế.	Đề xuất áp dụng cho catalog từ 2026-08-07, Asia/Ho_Chi_Minh; trạng thái artifact IN_REVIEW.
BR-MFG-002	Material Issue chỉ được tạo cho Work Order ở trạng thái RELEASED hoặc IN_PROGRESS. Mỗi dòng cấp phát phải ghi mã nguyên liệu, số lượng, đơn vị tính, kho nguồn, thời điểm và người thực hiện. Hệ thống từ chối số lượng cấp phát bằng hoặc nhỏ hơn 0. Cầu nối suy luận: trạng thái hợp lệ xác định lệnh đã được phép thực hiện; các trường bắt buộc tạo bằng chứng để đối chiếu lượng đã dùng với lượng sản xuất.	Material Issue; Work Order: RELEASED, IN_PROGRESS	Project assumption; cần Business Owner và Production Owner xác nhận quyền cấp phát, đơn vị tính và chứng từ vận hành.	Đề xuất áp dụng từ 2026-08-07, Asia/Ho_Chi_Minh; IN_REVIEW.
BR-MFG-003	Khi Material Issue đầu tiên được ghi nhận hợp lệ, hệ thống chuyển Work Order từ RELEASED sang IN_PROGRESS; nếu đã ở IN_PROGRESS thì giữ nguyên trạng thái. Không tự động chuyển trạng thái khi người dùng chỉ mở hoặc xem lệnh. Cầu nối suy luận: cấp phát là sự kiện vận hành có thể quan sát cho thấy nguyên liệu đã được đưa vào thực hiện, trong khi thao tác xem không chứng minh sản xuất đã bắt đầu.	Work Order: RELEASED → IN_PROGRESS; Material Issue	Project assumption; cần Production Owner xác nhận có cho phép bắt đầu sản xuất mà chưa cấp phát trên hệ thống hay không.	Đề xuất áp dụng từ 2026-08-07, Asia/Ho_Chi_Minh; IN_REVIEW.
BR-MFG-004	Báo cáo tiến độ sản xuất phải ghi nhận riêng ba lượng: lượng hoàn thành đạt yêu cầu, lượng scrap và lượng rework; mỗi lượng không âm và dùng cùng đơn vị tính của Work Order hoặc có quy đổi được kiểm soát. Tổng lượng báo cáo lũy kế không được làm số lượng còn phải xử lý của lệnh trở thành âm. Cầu nối suy luận: tách ba lượng ngăn việc tính phế phẩm hoặc hàng cần tái xử lý thành thành phẩm đạt yêu cầu, đồng thời cho phép kiểm tra chênh lệch theo từng kết quả sản xuất.	Production Order; Production Status: IN_PROGRESS; Scrap record; Rework record	Project assumption; cần Business Owner, Production Owner và QA Reviewer xác nhận định nghĩa “đạt yêu cầu”, ngưỡng chênh lệch và bằng chứng kiểm tra.	Đề xuất áp dụng từ 2026-08-07, Asia/Ho_Chi_Minh; IN_REVIEW.
BR-MFG-005	Work Order chỉ được chuyển sang COMPLETED khi lượng hoàn thành đạt yêu cầu đã được ghi nhận, mọi lượng scrap và rework phát sinh đã được phân loại, và phép đối chiếu số lượng kế hoạch với các kết quả thực tế không còn chênh lệch chưa giải trình. Công thức kiểm tra đề xuất là: Số lượng kế hoạch = lượng hoàn thành đạt yêu cầu + scrap + rework còn mở + chênh lệch được ghi nhận. Cầu nối suy luận: hoàn tất lệnh là điểm khóa kết quả sản xuất; nếu chênh lệch chưa được nhận diện thì số liệu thành phẩm và hao hụt không đủ cơ sở để kiểm tra.	Work Order: IN_PROGRESS → COMPLETED; Production Order; Scrap record; Rework record	Project assumption; cần Business Owner, Production Owner và Accounting Owner xác nhận cách xử lý chênh lệch và thời điểm khóa lệnh.	Đề xuất áp dụng từ 2026-08-07, Asia/Ho_Chi_Minh; IN_REVIEW.
BR-MFG-006	Scrap phải được ghi nhận bằng lý do chuẩn hóa và không được tự động cộng vào lượng hoàn thành. Rework phải giữ liên kết tới Work Order gốc, lượng cần tái xử lý và trạng thái OPEN hoặc CLOSED; Work Order gốc không được hoàn tất nếu rework vẫn OPEN, trừ khi có bản ghi ngoại lệ nêu rõ người quyết định, lý do và thời điểm. Cầu nối suy luận: scrap là kết quả không đạt, còn rework là nghĩa vụ xử lý tiếp; gộp hoặc bỏ qua hai kết quả này làm mất khả năng giải thích số lượng thực tế.	Scrap record; Rework record: OPEN, CLOSED; Work Order: IN_PROGRESS, COMPLETED	Project assumption; cần Business Owner và Production Owner xác nhận danh mục lý do, quyền đóng rework và cơ chế ngoại lệ.	Đề xuất áp dụng từ 2026-08-07, Asia/Ho_Chi_Minh; IN_REVIEW.

Nhu cầu/requirement liên quan	Hàm ý kiểm thử có thể quan sát	Phân loại
Ghi nhận chuyển trạng thái Work Order có kiểm soát.	Kiểm thử giá trị biên: lệnh thiếu mã sản phẩm, số lượng bằng 0, hoặc thiếu kho sản xuất phải không chuyển được sang RELEASED; lệnh đủ dữ liệu phải chuyển được.	Nhu cầu hệ thống đề xuất; Project assumption.
Ghi nhận Material Issue và tiến độ theo lượng không âm.	Kiểm thử hộp đen: số lượng cấp phát hoặc báo cáo tiến độ âm, bằng 0 khi không được phép, hoặc vượt lượng còn phải xử lý phải bị từ chối kèm lý do có thể đọc được.	Nhu cầu hệ thống đề xuất; thuật ngữ kiểm thử tham chiếu ISTQB CTFL Syllabus v4.0.1.
Đối chiếu kết quả hoàn thành, scrap và rework trước khi hoàn tất.	Kiểm thử quyết định: Work Order có rework OPEN hoặc chênh lệch chưa giải trình không thể thành COMPLETED; sau khi đóng rework hoặc ghi nhận ngoại lệ hợp lệ, hệ thống đánh giá lại điều kiện hoàn tất.	Nhu cầu hệ thống đề xuất; Project assumption.

Các ngưỡng hao hụt, danh mục lý do scrap, quyền phê duyệt ngoại lệ, cách xác định “đạt yêu cầu”, và tác động kế toán của việc hoàn tất lệnh đều là Verification required. Lý do là nguồn seed chỉ xác nhận Luật Kế toán và Luật An toàn thực phẩm là nguồn chính thức ở mức bối cảnh, không cung cấp trong micro-batch này điều khoản đã được đối chiếu để suy ra cấu hình ERP hoặc quy trình sản xuất cụ thể.

Ràng buộc lập kế hoạch sản xuất theo tồn kho khả dụng và ưu tiên nhu cầu

Trong Nova Foods — mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp — lập kế hoạch sản xuất là việc quyết định sản xuất mặt hàng nào, với số lượng nào và vào thời điểm nào để đáp ứng nhu cầu đã ghi nhận. “Tồn kho khả dụng” là lượng nguyên vật liệu hệ thống có thể cấp cho kế hoạch sau khi trừ lượng đã được giữ chỗ cho nhu cầu có ưu tiên cao hơn; vì vậy không được đồng nhất số dư sổ kho với lượng có thể sử dụng ngay. “Ưu tiên nhu cầu” là thứ tự phục vụ giữa các nguồn cầu, ví dụ nhu cầu giao đơn hàng đã cam kết trước nhu cầu bổ sung tồn kho mục tiêu. Cầu nối suy luận là: nếu lập kế hoạch chỉ dùng số dư sổ kho mà không trừ lượng đã giữ chỗ, cùng một lượng nguyên vật liệu có thể bị hứa cho hai nhu cầu, làm kế hoạch không khả thi.

Trường schema canonical	BR-MFG-PLAN-001
Rule ID	BR-MFG-PLAN-001
Tên quy tắc	Chỉ đề xuất lệnh sản xuất khi vật tư khả dụng đáp ứng nhu cầu ròng
Loại	Quy tắc vận hành
Quy tắc	Hệ thống phải tính nhu cầu ròng cho từng mặt hàng cần sản xuất bằng nhu cầu ưu tiên chưa được đáp ứng trừ lượng thành phẩm khả dụng đã được phân bổ hợp lệ. Số lượng sản xuất đề xuất chỉ được tạo khi toàn bộ nguyên vật liệu cần thiết có lượng khả dụng đủ cho số lượng đề xuất đó.
Bằng chứng và cầu nối suy luận	Nhu cầu đã ưu tiên xác định lượng cần đáp ứng; tồn kho thành phẩm đã phân bổ xác định phần nhu cầu còn lại; tồn kho nguyên vật liệu khả dụng xác định năng lực thực hiện. Ba dữ liệu này là đầu vào tối thiểu để tránh đề xuất vượt khả năng cấp vật tư.
Authority	Business Owner chịu trách nhiệm xác nhận định nghĩa “nhu cầu đã cam kết”, nguyên tắc phân bổ và ngưỡng cho phép lập kế hoạch một phần.
Effective date	2026-08-07, hiệu lực dự kiến trong catalog IN_REVIEW; cần Business Owner xác nhận trước khi dùng làm quy tắc vận hành mô phỏng.
Affected entities/states	Production Planning Proposal, Demand Priority, Inventory Availability, Material Reservation, Production Status
Traceability cần tạo	Need về khả năng nhìn thấy nhu cầu ròng; requirement về phép tính tồn kho khả dụng; test case kiểm tra thiếu một nguyên vật liệu làm đề xuất không thể chuyển sang trạng thái sẵn sàng phát hành.

Trường schema canonical	BR-MFG-PLAN-002
Rule ID	BR-MFG-PLAN-002
Tên quy tắc	Thứ tự ưu tiên nhu cầu quyết định thứ tự giữ chỗ vật tư
Loại	Quy tắc vận hành
Quy tắc	Khi nhiều nhu cầu cạnh tranh cùng một nguyên vật liệu khan hiếm, hệ thống phải giữ chỗ theo thứ tự ưu tiên đã được cấu hình cho kịch bản Nova Foods. Nhu cầu có ưu tiên thấp hơn chỉ nhận lượng còn lại sau khi nhu cầu ưu tiên cao hơn đã được tính phân bổ. Hệ thống không được tự động gộp hoặc đảo thứ tự hai nhu cầu có cùng mức ưu tiên mà không có tiêu chí phân giải đã xác định.
Bằng chứng và cầu nối suy luận	Vật tư khan hiếm là ràng buộc chung; nếu không có thứ tự giữ chỗ nhất quán, kết quả kế hoạch phụ thuộc vào thời điểm người dùng thao tác thay vì mục tiêu phục vụ nhu cầu. Vì vậy, ưu tiên phải được áp dụng trước khi xác định lượng có thể cấp.
Authority	Business Owner xác nhận các mức ưu tiên và tiêu chí phân giải khi bằng nhau; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết quy tắc trong artifact.
Effective date	2026-08-07, hiệu lực dự kiến trong catalog IN_REVIEW; không là quyết định ưu tiên thực tế của doanh nghiệp.
Affected entities/states	Demand Priority, Production Planning Proposal, Inventory Availability, Material Reservation
Traceability cần tạo	Requirement về trường mức ưu tiên và tiêu chí sắp xếp; acceptance criterion chứng minh nhu cầu ưu tiên cao nhận vật tư trước; test case cạnh tranh một nguyên vật liệu giữa hai nhu cầu.

Trường schema canonical	BR-MFG-PLAN-003
Rule ID	BR-MFG-PLAN-003
Tên quy tắc	Chặn phát hành kế hoạch khi chênh lệch giữa nhu cầu và năng lực vật tư chưa được xử lý
Loại	Quy tắc vận hành
Quy tắc	Nếu lượng nguyên vật liệu khả dụng không đủ cho số lượng sản xuất đề xuất, kế hoạch phải được đánh dấu ngoại lệ thiếu vật tư và không được xem là khả thi để phát hành. Người lập kế hoạch có thể giảm số lượng đề xuất xuống mức vật tư hỗ trợ được hoặc chuyển nhu cầu chưa đáp ứng sang trạng thái chờ quyết định, nhưng không được coi thiếu vật tư là đã được giải quyết chỉ bằng việc tạo đề xuất.
Bằng chứng và cầu nối suy luận	Đề xuất sản xuất không làm tăng tồn kho nguyên vật liệu. Khi đầu vào thiếu, trạng thái khả thi sẽ sai nếu vẫn cho phép phát hành như không có ngoại lệ. Việc đánh dấu ngoại lệ tạo điểm kiểm soát để phân biệt kế hoạch có thể thực hiện với kế hoạch còn rủi ro.
Authority	Business Owner xác nhận vai trò được phép quyết định giảm sản lượng, hoãn nhu cầu hoặc yêu cầu bổ sung vật tư trong mô phỏng.
Effective date	2026-08-07, hiệu lực dự kiến trong catalog IN_REVIEW; cần xác nhận trước khi dùng trong bài tập hoặc thiết kế hệ thống.
Affected entities/states	Production Planning Proposal, Inventory Availability, Demand Priority, Production Status
Traceability cần tạo	Requirement về trạng thái ngoại lệ thiếu vật tư; test case xác nhận kế hoạch bị chặn khi thiếu vật tư và được tính lại sau khi thay đổi số lượng đề xuất.

Ví dụ tổng hợp: nhu cầu A có ưu tiên 1, cần 100 đơn vị thành phẩm; nhu cầu B có ưu tiên 2, cần 80 đơn vị. Sau khi trừ thành phẩm đã phân bổ, hệ thống xác định A còn cần 70 đơn vị và B còn cần 80 đơn vị. Nếu nguyên vật liệu khả dụng chỉ hỗ trợ sản xuất 100 đơn vị, BR-MFG-PLAN-002 yêu cầu giữ chỗ trước cho A với 70 đơn vị; B chỉ có thể nhận 30 đơn vị. Theo BR-MFG-PLAN-003, 50 đơn vị còn thiếu của B phải hiển thị là ngoại lệ, không được biểu diễn là kế hoạch khả thi.

Nội dung cần Business Owner xác nhận	Phân loại	Lý do chưa thể nâng thành quy tắc vận hành đã xác nhận
Thứ tự cụ thể giữa đơn hàng khách đã cam kết, nhu cầu bổ sung tồn kho và kế hoạch khuyến mại	Project assumption	Source seed không cung cấp chính sách ưu tiên của Nova Foods; thứ tự này ảnh hưởng trực tiếp đến dịch vụ khách hàng và sử dụng vật tư.
Có cho phép sản xuất một phần khi nguyên vật liệu thiếu hay không	Project assumption	Đây là lựa chọn vận hành phụ thuộc khả năng chia lô sản xuất và chính sách phục vụ nhu cầu của Business Owner.
Tiêu chí phân giải khi hai nhu cầu cùng mức ưu tiên, chẳng hạn ngày cần hàng hay thời điểm tạo nhu cầu	Verification required	Cần một tiêu chí đơn nghĩa để kết quả lập kế hoạch có thể lặp lại và kiểm thử được.

Gán lô thành phẩm, đối soát sản lượng và xử lý chênh lệch

Trong Nova Foods mô phỏng, lô thành phẩm (Finished Goods Lot) là nhóm đơn vị thành phẩm được ghi nhận cùng định danh để liên kết với một Work Order (lệnh sản xuất), thời điểm hoàn thành và số lượng thực tế. Đối soát sản lượng (produced quantity reconciliation) là kiểm tra có thể truy vết giữa tổng lượng đã báo cáo từ sản xuất, lượng được gán vào các lô thành phẩm, lượng phế phẩm và lượng chuyển rework (làm lại). Các quy tắc dưới đây dùng dữ liệu tổng hợp, không thay thế quyết định an toàn thực phẩm, chất lượng hoặc truy xuất nguồn gốc thực tế.

Canonical Rule ID	Quy tắc nghiệp vụ	Thực thể/trạng thái ảnh hưởng	Authority và phân loại nguồn	Ngày hiệu lực
BR-MFG-LOT-001	Khi Production Status chuyển sang COMPLETED, hệ thống phải gán toàn bộ số lượng thành phẩm đạt yêu cầu vào ít nhất một Finished Goods Lot. Mỗi lô phải liên kết duy nhất với Work Order nguồn, mã thành phẩm, đơn vị tính, số lượng, thời điểm ghi nhận theo Asia/Ho_Chi_Minh và trạng thái lô. Một lô không được đồng thời liên kết với hai Work Order.	Work Order; Production Order; Finished Goods Lot; Production Status COMPLETED	Quy tắc vận hành Nova Foods mô phỏng — Project assumption; cần Business Owner xác nhận. Bối cảnh truy xuất lô tham chiếu Luật An toàn thực phẩm, nhưng cách áp dụng chi tiết là Verification required.	2026-08-07
BR-MFG-LOT-002	Tổng số lượng của các Finished Goods Lot thuộc cùng một Work Order phải bằng số lượng thành phẩm đạt yêu cầu đã được báo cáo hoàn thành. Nếu sản xuất báo cáo 980 kg đạt yêu cầu thì tổng lượng các lô thành phẩm của Work Order đó phải là 980 kg; không được đóng Work Order khi chỉ gán 970 kg hoặc gán vượt 980 kg.	Work Order; Finished Goods Lot; Production Status IN_PROGRESS, COMPLETED	Quy tắc vận hành Nova Foods mô phỏng — Project assumption; cần Business Owner và QA Reviewer xác nhận tiêu chí đối soát.	2026-08-07
BR-MFG-REC-001	Trước khi chuyển Work Order sang COMPLETED, hệ thống phải đối soát theo đơn vị tính chuẩn: Sản lượng đã báo cáo = Thành phẩm đạt yêu cầu đã gán lô + Phế phẩm đã ghi nhận + Sản lượng chuyển rework. Mỗi thành phần phải có bản ghi nguồn và không được dùng cùng một lượng cho hai thành phần. Quy tắc này bảo đảm mọi lượng đã sản xuất đều có trạng thái giải trình được, không khẳng định công thức yield hay định mức sản xuất.	Work Order; Production Order; Material Issue; Finished Goods Lot; Production Status IN_PROGRESS, COMPLETED	Quy tắc vận hành Nova Foods mô phỏng — Project assumption; cần Business Owner xác nhận mô hình đo lường và đơn vị quy đổi.	2026-08-07
BR-MFG-REC-002	Khi có lượng chuyển rework, hệ thống phải tạo liên kết truy vết từ Work Order nguồn đến bản ghi rework và giữ nguyên lượng, đơn vị tính, thời điểm, lý do và trạng thái xử lý. Lượng rework chưa hoàn tất vẫn được tính là lượng đã giải trình cho Work Order nguồn, nhưng không được cộng vào Finished Goods Lot cho đến khi có báo cáo hoàn thành riêng.	Work Order; Production Order; Finished Goods Lot; Production Status IN_PROGRESS; bản ghi rework	Quy tắc vận hành Nova Foods mô phỏng — Project assumption; cần Business Owner xác nhận vòng đời rework.	2026-08-07
BR-MFG-ESC-001	Hệ thống phải chặn chuyển trạng thái COMPLETED và tạo discrepancy record (bản ghi chênh lệch) khi tổng lượng đối soát không bằng lượng đã báo cáo, khi lô thành phẩm thiếu liên kết Work Order, khi số lượng lô âm hoặc bằng không, hoặc khi một lô được liên kết với nhiều Work Order. Bản ghi chênh lệch phải lưu Work Order, loại chênh lệch, lượng chênh, đơn vị tính, người ghi nhận, thời điểm và trạng thái OPEN.	Work Order; Finished Goods Lot; Production Status IN_PROGRESS; Discrepancy Record OPEN	Quy tắc vận hành Nova Foods mô phỏng — Project assumption; cần Business Owner và QA Reviewer xác nhận quyền xử lý ngoại lệ.	2026-08-07

Cầu nối suy luận cho BR-MFG-LOT-001 và BR-MFG-LOT-002 là: nếu thành phẩm hoàn thành không có lô hoặc lượng lô không khớp lượng đạt yêu cầu, người học không thể trả lời thành phẩm nào phát sinh từ Work Order nào; vì vậy liên kết một-nhiều từ Work Order đến Finished Goods Lot và kiểm tra tổng lượng là điều kiện tối thiểu để tạo truy vết nội bộ trong mô phỏng.

Cầu nối suy luận cho BR-MFG-REC-001 là: một lượng đã báo cáo chỉ có giá trị kiểm soát khi được phân loại thành đạt yêu cầu, phế phẩm hoặc rework; do đó phép đối soát ngăn cùng một lượng bị bỏ sót hoặc ghi nhận trùng. Mọi ngưỡng dung sai sản lượng, cách quy đổi đơn vị và quyền cho phép đóng lệnh khi có chênh lệch là Verification required, vì chưa có quyết định Business Owner được ghi nhận.

Liên kết cần/requirement/test	Nội dung kiểm chứng dự kiến
Need NEED-MFG-LOT-001	Người vận hành cần xem được Work Order nguồn, mã lô, số lượng lô và trạng thái chênh lệch để xác định lượng thành phẩm đã được giải trình.
Requirement REQ-MFG-LOT-001	Hệ thống phải từ chối hoàn thành Work Order khi tổng số lượng Finished Goods Lot không bằng lượng thành phẩm đạt yêu cầu đã báo cáo.
Requirement REQ-MFG-REC-001	Hệ thống phải lưu discrepancy record OPEN khi phép đối soát sản lượng không cân bằng và không tự xóa bản ghi này.
Test TC-MFG-LOT-001	Với Work Order báo cáo 980 kg đạt yêu cầu và hai lô 600 kg, 380 kg, kết quả mong đợi là cho phép hoàn thành nếu các thành phần đối soát khác hợp lệ.
Test TC-MFG-ESC-001	Với Work Order báo cáo 980 kg đạt yêu cầu nhưng chỉ gán một lô 970 kg, kết quả mong đợi là chặn COMPLETED và tạo discrepancy record có lượng chênh 10 kg.

Mô hình thực thể và trạng thái chuẩn cho dữ liệu sản xuất

Trong Nova Foods là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, thực thể (entity) là đối tượng dữ liệu cần được ERP nhận diện riêng; trạng thái (state) là giá trị cho biết đối tượng đang ở giai đoạn nào và hành động nào còn được phép. Việc tách thực thể khỏi trạng thái giúp người mới không nhầm “Lệnh sản xuất” là một hồ sơ với “Đang thực hiện” là tình trạng của hồ sơ đó. Các quy tắc dưới đây dùng cấu trúc chuẩn: mã quy tắc, phát biểu có thể kiểm tra, thực thể/trạng thái tác động, thẩm quyền, ngày hiệu lực và căn cứ.

Mã quy tắc	Phát biểu quy tắc có thể kiểm tra	Thực thể và trạng thái tác động	Thẩm quyền và phân loại nguồn	Hiệu lực
BR-MFG-ENTITY-001	Mỗi BOM (Bill of Materials, định mức nguyên vật liệu) phải có định danh riêng, mã thành phẩm áp dụng, phiên bản và trạng thái DRAFT, PENDING_APPROVAL, APPROVED, SUPERSEDED hoặc RETIRED. Một BOM không được đồng thời mang hai trạng thái.	BOM; BOM Status	Project assumption — cần Business Owner xác nhận tập trạng thái và ý nghĩa vận hành.	2026-08-07; IN_REVIEW
BR-MFG-ENTITY-002	Work Order (lệnh công việc tại công đoạn) và Production Order (lệnh sản xuất quản lý việc tạo thành phẩm) là hai thực thể phân biệt. Work Order phải tham chiếu đúng một Production Order; một Production Order có thể chưa có Work Order hoặc có một hay nhiều Work Order theo tuyến sản xuất được xác nhận.	Work Order; Production Order; quan hệ tham chiếu	Project assumption — cần Business Owner và Architect xác nhận có cần tách hai thực thể trong ERP mô phỏng hay dùng một thực thể duy nhất.	2026-08-07; IN_REVIEW
BR-MFG-ENTITY-003	Production Order phải dùng một trạng thái duy nhất trong tập PLANNED, RELEASED, IN_PROGRESS, COMPLETED, CLOSED, CANCELLED. Hệ thống phải lưu thời điểm chuyển trạng thái theo Asia/Ho_Chi_Minh, người hoặc vai trò thực hiện và lý do khi chuyển sang CANCELLED.	Production Order; Production Status	Project assumption — cần Business Owner xác nhận tên trạng thái, người có quyền đổi trạng thái và ngoại lệ vận hành.	2026-08-07; IN_REVIEW
BR-MFG-ENTITY-004	Material Issue (phiếu xuất nguyên liệu cho sản xuất) là bằng chứng dữ liệu riêng, không phải chỉ là một trường số lượng trên lệnh. Mỗi phiếu phải liên kết với một Production Order, một kho nguồn, ít nhất một dòng nguyên liệu và lô nguồn khi nguyên liệu được quản lý theo lô.	Material Issue; Production Order; lô nguyên liệu	Project assumption — cần Business Owner xác nhận mức chi tiết phiếu xuất; ngữ cảnh truy xuất thực phẩm thuộc Verification required theo Luật An toàn thực phẩm 55/2010/QH12.	2026-08-07; IN_REVIEW
BR-MFG-ENTITY-005	Finished Goods Lot (lô thành phẩm) phải có mã lô riêng, mã thành phẩm, số lượng tạo ra, đơn vị tính, ngày tạo và tham chiếu Production Order đã tạo lô. Một mã lô thành phẩm không được được gán cho hai lệnh sản xuất khác nhau.	Finished Goods Lot; Production Order; Production Status	Verification required — Business Owner và Food-safety/quality owner cần xác nhận quy tắc mã lô, mức truy xuất và thời điểm tạo lô.	2026-08-07; IN_REVIEW
BR-MFG-ENTITY-006	Khi Production Order ở COMPLETED, tổng số lượng thành phẩm được ghi nhận qua các Finished Goods Lot, cộng số lượng phế phẩm và số lượng đang chờ xử lý sai lệch, phải đối chiếu được với số lượng đầu ra thực tế của lệnh. Nếu không đối chiếu được, trạng thái phải là DISCREPANCY_REVIEW, không được chuyển trực tiếp sang CLOSED.	Production Order; Finished Goods Lot; Production Status	Project assumption — cần Business Owner xác nhận công thức đối chiếu, ngưỡng sai lệch và vai trò xử lý; không phải kết luận kế toán hay an toàn thực phẩm.	2026-08-07; IN_REVIEW

Thực thể	Khóa nhận diện tối thiểu trong phạm vi học liệu	Trạng thái hoặc quan hệ bắt buộc	Ranh giới diễn giải
BOM	Mã BOM, mã thành phẩm, phiên bản	Một BOM Status; tham chiếu bởi Production Order khi được dùng	Bảng này chỉ định nghĩa dữ liệu và trạng thái, chưa quyết định điều kiện phê duyệt, hiệu lực hay thay thế BOM.
Production Order	Mã lệnh sản xuất, mã thành phẩm, số lượng kế hoạch	Một Production Status; có thể liên kết nhiều Work Order, Material Issue, Finished Goods Lot	Không suy diễn lịch sản xuất, năng lực máy hoặc thứ tự ưu tiên nhu cầu.
Work Order	Mã lệnh công việc, mã Production Order, công đoạn	Trạng thái công việc phải được thiết kế nhất quán với Production Status	Không tự xác định tuyến công đoạn hay tiêu chuẩn thời gian.
Material Issue	Mã phiếu, mã lệnh sản xuất, kho nguồn, dòng nguyên liệu	Tham chiếu lô nguồn khi có quản lý lô	Không tự quy định định mức xuất, phương pháp xuất kho hoặc quyền phê duyệt.
Finished Goods Lot	Mã lô, mã thành phẩm, mã lệnh sản xuất	Được tạo từ một Production Order; số lượng tham gia đối chiếu hoàn thành	Không tự xác nhận quy tắc hạn dùng, nhãn hàng hóa hoặc yêu cầu truy xuất pháp lý.

Cầu nối bằng chứng và kiểm thử: Quy tắc BR-MFG-ENTITY-002 được lập vì Work Order và Production Order có mục đích quản lý khác nhau; do đó kiểm thử phải tạo một Production Order tổng hợp với hai Work Order và xác minh mỗi lệnh công việc tham chiếu đúng lệnh sản xuất. Quy tắc BR-MFG-ENTITY-006 được lập vì hoàn thành sản xuất chỉ đáng tin khi đầu ra, phế phẩm và sai lệch được phân biệt; do đó test case phải thử một trường hợp tổng số không khớp và kỳ vọng trạng thái DISCREPANCY_REVIEW, không phải CLOSED. Đây là tiêu chí kiểm thử chức năng theo cách hiểu kiểm thử hộp đen (black-box testing: kiểm tra đầu vào và kết quả quan sát được), phù hợp phạm vi thuật ngữ của ISTQB CTFL Syllabus v4.0.1, không phải bằng chứng phê duyệt vận hành.

Nhu cầu liên quan, yêu cầu và hàm ý kiểm thử cho kịch bản sản xuất

Trong Nova Foods là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp, nhu cầu nghiệp vụ là vấn đề cần được giải quyết; yêu cầu là phát biểu có thể kiểm tra về năng lực hệ thống; còn hàm ý kiểm thử xác định bằng chứng phải quan sát để chứng minh yêu cầu. Cầu nối suy luận là: nếu một bước sản xuất làm thay đổi nguyên liệu, sản lượng, phế phẩm hoặc lô thành phẩm, người học và người vận hành mô phỏng cần thấy được trạng thái, số lượng và liên kết chứng từ tương ứng; vì vậy yêu cầu phải truy vết được tới quy tắc sản xuất canonical và có tiêu chí kiểm thử quan sát được.

Nhu cầu liên quan	Yêu cầu cần được liên kết trong catalog	Bằng chứng kiểm thử tối thiểu	Phạm vi và ranh giới
Lập kế hoạch sản xuất dựa trên khả năng đáp ứng vật tư và mức ưu tiên nhu cầu.	Requirement phải xác định đầu vào nhu cầu, số lượng khả dụng, đơn vị tính, trạng thái tồn kho được phép dùng và thứ tự ưu tiên được áp dụng cho Production Order.	Test case dùng dữ liệu tổng hợp với hai nhu cầu cạnh tranh cùng một nguyên liệu; kết quả hiển thị nhu cầu được ưu tiên, lượng khả dụng và lý do không thể cấp đủ cho nhu cầu còn lại.	Không suy diễn thuật toán tối ưu kế hoạch, năng lực máy móc hoặc lịch ca khi chưa có quyết định Business Owner.
Sử dụng đúng BOM (Bill of Materials, định mức nguyên vật liệu) khi tạo và thực hiện Work Order.	Requirement phải liên kết BOM version, ngày hiệu lực, trạng thái phê duyệt và lượng nguyên liệu định mức với Work Order cụ thể.	Test case xác nhận Work Order ngày 2026-08-07 chỉ nhận BOM hợp lệ tại ngày đó; BOM hết hiệu lực hoặc chưa được phê duyệt không được chọn.	Đây là yêu cầu kiểm tra quan hệ dữ liệu; không tự đặt công thức định mức thực tế.
Ghi nhận cấp phát vật tư và tiến độ sản xuất có kiểm soát.	Requirement phải yêu cầu Material Issue tham chiếu Work Order, nguyên liệu, lô nguyên liệu, số lượng và trạng thái ghi nhận; tiến độ phải phân biệt sản lượng đang sản xuất, hoàn thành, phế phẩm và tái chế.	Test case tạo một Material Issue hợp lệ và một bản ghi thiếu Work Order; bản ghi hợp lệ có liên kết đầy đủ, bản ghi thiếu liên kết bị chặn hoặc được đánh dấu lỗi theo quy tắc canonical liên quan.	Không bao gồm thiết kế màn hình, giao diện quét mã vạch hoặc quyền chi tiết của từng vai trò.
Đối soát sản lượng đầu ra với vật tư đã dùng và tổn thất.	Requirement phải cho phép đối chiếu giữa planned quantity, issued quantity, completed quantity, scrap quantity và rework quantity theo cùng Work Order hoặc Production Order.	Test case với dữ liệu tổng hợp: kế hoạch 100 kg, hoàn thành 92 kg, phế phẩm 5 kg, tái chế 3 kg; kết quả phải giữ từng đại lượng riêng và hiển thị chênh lệch cần xử lý nếu tổng hợp không phù hợp quy tắc đã liên kết.	Không xác định ngưỡng hao hụt chấp nhận được vì đây là tham số nghiệp vụ cần Business Owner xác nhận.
Bảo đảm thành phẩm hoàn thành có nhận diện lô để phục vụ truy vết.	Requirement phải liên kết Finished Goods Lot với Production Order hoặc Work Order, sản phẩm, lượng hoàn thành và thời điểm hoàn thành theo Asia/Ho_Chi_Minh.	Test case hoàn thành sản xuất bằng dữ liệu tổng hợp và kiểm tra lô thành phẩm có thể truy ngược tới Work Order, BOM version và Material Issue liên quan.	Bối cảnh truy xuất thực phẩm liên quan Luật An toàn thực phẩm là Verification required; học liệu không tuyên bố đáp ứng nghĩa vụ pháp lý hay an toàn thực phẩm thực tế.
Xử lý chênh lệch và ngoại lệ sản xuất minh bạch.	Requirement phải xác định điều kiện tạo discrepancy, tức chênh lệch giữa số liệu dự kiến và số liệu ghi nhận, cùng trạng thái chờ xử lý hoặc cơ chế escalation.	Test case nhập số lượng hoàn thành vượt giới hạn mà quy tắc canonical cho phép; hệ thống phải không tự hoàn tất Work Order và phải tạo bằng chứng về chênh lệch để người có thẩm quyền xử lý.	Không gán sẵn người phê duyệt, mức dung sai hoặc thời hạn xử lý khi chưa có quyết định nghiệp vụ được ghi nhận.

Mỗi requirement của nhóm này phải liên kết tối thiểu tới: quy tắc canonical áp dụng, thực thể bị ảnh hưởng (BOM, Work Order, Production Order, Material Issue, Finished Goods Lot, Production Status), điều kiện tiền đề, kết quả mong đợi, ngoại lệ và test case. Cấu trúc này phù hợp nguyên tắc đặc tả yêu cầu có thể kiểm tra của ISO/IEC/IEEE 29148:2018 ở mức sử dụng an toàn theo abstract chính thức; không viện dẫn điều khoản của văn bản có bản quyền chưa được kiểm chứng.

Thành phần schema liên kết	Giá trị kiểm soát cho mục này
Authority	ISO/IEC/IEEE 29148:2018 dùng cho định hướng chất lượng requirement; ISTQB CTFL Syllabus v4.0.1 dùng cho thuật ngữ và thiết kế kiểm thử ở mức nền tảng.
Source classification	Nguồn chuẩn/chuyên môn bên ngoài; không phải quy định vận hành riêng của Nova Foods.
Effective date	2026-08-07 cho phạm vi artifact mô phỏng đang IN_REVIEW; không phải ngày hiệu lực vận hành hoặc production.
Traceability bắt buộc	Canonical rule → related need → requirement → acceptance criterion → test case → test evidence.
Dữ liệu kiểm thử	Chỉ dùng mã, lô, sản phẩm, số lượng và tình huống tổng hợp; không dùng dữ liệu khách hàng, nhà cung cấp, nhân sự hoặc giao dịch thực tế.
Trạng thái quản trị	IN_REVIEW, v0.9.0; không tạo baseline, approval, xác nhận Business Owner hoặc xác nhận sẵn sàng triển khai.

Quy tắc vận hành là điều kiện bắt buộc đã được ghi trong canonical rule catalog, ví dụ điều kiện để một Work Order chuyển trạng thái hoặc điều kiện ghi nhận Material Issue. Project assumption là giả định phục vụ thiết kế học liệu nhưng chưa có Business Owner xác nhận, ví dụ ngưỡng hao hụt, cách ưu tiên đơn hàng khi cùng mức ưu tiên, tỷ lệ tái chế được phép và vai trò có quyền giải quyết discrepancy. Cầu nối suy luận là các tham số này quyết định kết quả nghiệp vụ và kết quả kiểm thử; do chưa có nguồn xác nhận trong seed, chúng phải được gắn Project assumption và chuyển Business Owner xác nhận, không được biến thành quy tắc vận hành chỉ vì đã xuất hiện trong test case.

Phân loại quy tắc vận hành và giả định cần xác nhận của Business Owner

Trong Nova Foods Trading & Manufacturing là tình huống mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, quy tắc vận hành (operational rule) là mệnh đề mà ERP phải kiểm soát hoặc thực thi khi đã có chủ sở hữu nghiệp vụ xác nhận. Giả định cần xác nhận (assumption requiring business-owner confirmation) là cách hiểu tạm thời để lập kế hoạch học liệu khi chưa có quyết định nghiệp vụ có thẩm quyền; giả định không được cấu hình, kiểm thử chấp nhận như một quy tắc đã có hiệu lực, hoặc diễn giải là quyết định của Nova Foods.

Mỗi bản ghi trong catalog quy tắc sản xuất phải dùng cùng schema canonical sau để tránh biến giả định thành quy tắc hiệu lực chỉ vì được ghi trong tài liệu: Rule ID, Phân loại, Mệnh đề, Đối tượng/trạng thái bị ảnh hưởng, Điều kiện áp dụng, Kết quả hoặc hành động hệ thống, Ngoại lệ, Evidence/reasoning bridge, Nguồn và phân loại nguồn, Authority, Effective date, Trạng thái xác nhận, Needs/Requirements liên quan, Hàm ý kiểm thử, Escalation owner. Trường Authority phải nêu vai trò sở hữu quyết định, không ghi tên cá nhân; trường Effective date phải là ngày hiệu lực được xác nhận theo Asia/Ho_Chi_Minh, hoặc ghi rõ Chưa có hiệu lực — chờ xác nhận Business Owner khi bản ghi là giả định.

Tiêu chí quyết định	Quy tắc vận hành	Giả định cần xác nhận Business Owner
Cơ sở áp dụng	Có quyết định nghiệp vụ được ghi nhận trong artifact kiểm soát phù hợp.	Chỉ có nhu cầu lập kế hoạch, ví dụ học tập, hoặc suy luận từ bối cảnh chưa được xác nhận.
Authority	Business Owner của sản xuất, hoặc vai trò được Business Owner chỉ định rõ bằng bằng chứng quản trị.	Business Owner — xác nhận bắt buộc; Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận và truy vết.
Effective date	Ngày có thể xác định và phù hợp với quyết định được ghi nhận.	Chưa có hiệu lực — chờ xác nhận Business Owner; không thay bằng ngày soạn tài liệu 2026-08-07.
Cách dùng trong ERP mô phỏng	Có thể làm test basis, acceptance criterion và nội dung cấu hình mô phỏng sau khi được xác nhận.	Chỉ dùng để nêu câu hỏi, phạm vi lựa chọn và test khám phá; không được dùng làm expected result bắt buộc.
Khi có mâu thuẫn	Ưu tiên bản ghi còn hiệu lực có authority rõ ràng; xung đột phải escalation.	Không tự chọn một phương án; giữ các phương án và câu hỏi quyết định đơn nghĩa để Business Owner quyết định.

Các nội dung sau phải được ghi là giả định cần xác nhận, không được viết như quy tắc vận hành, vì source seed chỉ cung cấp bối cảnh BA và nguồn pháp lý cấp cao chứ không cung cấp quyết định quy trình riêng của Nova Foods. Cầu nối lập luận là: một hành vi có thể hợp lý về mặt vận hành không chứng minh rằng Nova Foods mô phỏng đã chọn hành vi đó; do đó thiếu bằng chứng quyết định nghiệp vụ dẫn đến phân loại giả định.

Chủ đề sản xuất	Giả định phải xác nhận	Bằng chứng/lập luận phân loại	Authority và ngày hiệu lực	Câu hỏi quyết định cho Business Owner	Tác động nếu chưa xác nhận
Ưu tiên nhu cầu	Đơn hàng khách hàng được ưu tiên hơn kế hoạch bổ sung tồn kho khi cùng tranh chấp nguyên liệu.	Mức ưu tiên phản ánh mục tiêu dịch vụ và doanh thu của doanh nghiệp, không suy ra được chỉ từ tồn kho hoặc cấu trúc Work Order.	Business Owner — xác nhận bắt buộc; Chưa có hiệu lực — chờ xác nhận Business Owner.	Khi nguyên liệu thiếu, thứ tự ưu tiên giữa đơn hàng khách hàng, tồn kho an toàn và kế hoạch dự báo là gì?	Không thể xác định quy tắc phân bổ nguyên liệu hoặc expected result của kịch bản thiếu hàng.
Thay thế nguyên liệu	Nguyên liệu thay thế trong BOM chỉ được issue sau khi có xác nhận của vai trò sản xuất.	Việc thay thế có thể ảnh hưởng chất lượng, công thức, chi phí và truy xuất; Luật An toàn thực phẩm là bối cảnh pháp lý, không xác nhận cơ chế phê duyệt ERP của Nova Foods.	Business Owner — xác nhận bắt buộc; Chưa có hiệu lực — chờ xác nhận Business Owner; nhãn Verification required cho tác động an toàn thực phẩm.	Ai được phép chấp nhận thay thế, và quyết định đó áp dụng cho từng Work Order hay cho phiên bản BOM?	Không được thiết kế tự động thay thế hoặc coi nguyên liệu thay thế là hợp lệ.
Sai lệch sản lượng	Sai lệch giữa lượng hoàn thành, lượng phế phẩm và lượng nguyên liệu issue vượt một ngưỡng phần trăm sẽ chặn completion.	Ngưỡng, người nhận cảnh báo và việc chặn hay chỉ cảnh báo là lựa chọn kiểm soát vận hành; chưa có số liệu Nova Foods được xác nhận.	Business Owner — xác nhận bắt buộc; Chưa có hiệu lực — chờ xác nhận Business Owner.	Ngưỡng sai lệch là bao nhiêu theo từng nhóm sản phẩm, và hệ thống phải chặn hay cho phép hoàn tất kèm escalation?	Không gán số phần trăm giả định vào rule hoặc test pass/fail.
Rework	Hàng cần tái chế được tạo Work Order riêng thay vì quay lại Work Order gốc.	Cách quản lý rework quyết định truy vết chi phí, lô hàng và trạng thái sản xuất; không có nguồn xác nhận lựa chọn của Nova Foods.	Business Owner — xác nhận bắt buộc; Chưa có hiệu lực — chờ xác nhận Business Owner.	Rework phải tách Work Order, dùng mã trạng thái riêng, hay được ghi nhận trong Work Order ban đầu?	Không xác định được mô hình trạng thái và chuỗi truy vết cho Finished Goods Lot.
Gán lô thành phẩm	Một Work Order chỉ được tạo một Finished Goods Lot.	Quan hệ một-một hay một-nhiều phụ thuộc vào cách đóng gói, ca sản xuất và yêu cầu truy xuất thực tế của mô hình nghiệp vụ.	Business Owner — xác nhận bắt buộc; Chưa có hiệu lực — chờ xác nhận Business Owner; nhãn Verification required cho yêu cầu truy xuất/an toàn thực phẩm.	Một Work Order có thể sinh nhiều lô thành phẩm theo ca, ngày, dây chuyền hoặc điều kiện nào?	Không thể chốt quan hệ dữ liệu và kịch bản đối soát lô.

Một bản ghi chỉ được đổi từ Assumption requiring business-owner confirmation sang Operational rule khi có đủ chuỗi bằng chứng: câu hỏi quyết định có một đáp án rõ ràng; authority là Business Owner hoặc người được ủy quyền có thể xác định; effective date được ghi nhận; tác động tới BOM, Work Order, Material Issue, Finished Goods Lot hoặc Production Status được nêu; và QA Reviewer có thể tạo kiểm thử quan sát được. Việc sửa phân loại phải giữ nguyên Rule ID, bổ sung lịch sử thay đổi, liên kết evidence quyết định và không xóa giả định ban đầu, nhằm bảo toàn traceability trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.

Nguồn phương pháp cho việc tách giả định khỏi yêu cầu/quy tắc là BABOK Guide, IIBA, Version 3, dùng trong ranh giới thuật ngữ và thực hành phân tích nghiệp vụ; đây không phải nguồn xác nhận quy trình sản xuất của Nova Foods. Mọi nội dung liên quan chất lượng thực phẩm, truy xuất nguồn gốc hoặc nghĩa vụ pháp lý phải giữ nhãn Verification required và được escalation đến Business Owner cùng vai trò pháp lý hoặc chuyên môn an toàn thực phẩm phù hợp; trạng thái corpus tại 2026-08-07 vẫn là IN_REVIEW, v0.9.0, không có baseline hoặc approval được suy diễn.

Finance Integration, Approvals, Reporting, Security, and Integration Rules

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ sử dụng dữ liệu tổng hợp bằng VND, locale vi-VN, múi giờ Asia/Ho_Chi_Minh. Tại ngày 2026-08-07, /01-curriculum/CANONICAL_BUSINESS_RULES.md có trạng thái IN_REVIEW, phiên bản v0.9.0; vì vậy catalog dưới đây là cấu trúc kiểm soát để soạn và review quy tắc, không phải baseline, phê duyệt, cấu hình ERP thực tế, kết luận kế toán/pháp lý hay xác nhận sẵn sàng production.

Quy tắc quản trị schema bắt buộc

Mọi quy tắc được tạo trong phần này phải dùng đầy đủ schema canonical dưới đây. Schema là tập trường bắt buộc và ý nghĩa cố định của từng trường; nó giúp người đọc, QA Reviewer và các artifact liên quan hiểu cùng một quy tắc theo cùng một cấu trúc. Cơ sở suy luận là một quy tắc không có định danh, nguồn hoặc tác động thay đổi thì không thể liên kết đơn nghĩa tới quyết định, kiểm thử và thay đổi downstream; do đó các trường này là điều kiện tối thiểu để bảo toàn traceability.

Trường schema canonical	Nội dung bắt buộc	Quy tắc kiểm soát
Rule ID	Định danh duy nhất, ổn định của quy tắc theo family ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Không tái sử dụng ID, không đổi ID chỉ vì sửa câu chữ; thay đổi nội dung giữ nguyên ID và ghi lịch sử thay đổi.
Rule title	Tiêu đề ngắn, diễn đạt một quyết định hoặc ràng buộc nghiệp vụ.	Không gộp nhiều quyết định độc lập vào một tiêu đề.
Rule statement	Mệnh đề điều kiện–hành động–kết quả có thể quan sát.	Phải nêu rõ điều kiện kích hoạt, hành vi bắt buộc/cấm và kết quả mong đợi; tránh từ mơ hồ như “phù hợp” hoặc “kịp thời” nếu không có tiêu chí đo được.
Business rationale	Lý do nghiệp vụ cho quy tắc.	Phân biệt lý do với chính quy tắc để người review đánh giá được tác động khi lý do thay đổi.
Affected entities and states	Thực thể và trạng thái chịu ảnh hưởng.	Chỉ nêu thực thể/trạng thái được xác định bởi quy tắc; không suy diễn mô hình dữ liệu hoặc trạng thái chưa được xác nhận.
Source classification	Phân loại nguồn của nội dung quy tắc.	Bắt buộc chọn đúng một phân loại chính và ghi nguồn hoặc căn cứ cụ thể.
Source reference and evidence bridge	URL nguồn chính thức, artifact nội bộ được kiểm soát, hoặc mô tả giả định; kèm cầu nối lý luận từ bằng chứng đến quy tắc.	Không tạo số trang, điều khoản, trích dẫn hoặc nội dung nguồn không được cung cấp.
Owner and decision authority	Vai trò sở hữu quy tắc và vai trò có thẩm quyền xác minh/quyết định.	Owner quản lý nội dung không đồng nghĩa với quyền tự phê duyệt vấn đề pháp lý, kế toán, bảo mật hoặc kiến trúc.
Acceptance evidence	Kết quả quan sát được để QA Reviewer kiểm tra quy tắc.	Evidence phải cho phép phân biệt đạt/không đạt mà không cần suy đoán ý định người thực hiện.
Exceptions and escalation	Ngoại lệ được phép, điều kiện escalation và vai trò nhận escalation.	Nếu chưa có ngoại lệ được xác nhận, ghi rõ “Không xác định ngoại lệ trong phạm vi quy tắc này”; không tự tạo quyền ngoại lệ.
Change impact	Tác động khi quy tắc được thêm, sửa, vô hiệu hóa hoặc thay đổi phân loại nguồn.	Phải nêu artifact, dữ liệu, kiểm thử, đào tạo hoặc vai trò cần review lại, cùng mức tác động.
Status and version trace	Trạng thái quy tắc, phiên bản artifact và ngày hiệu lực nếu đã được xác định hợp lệ.	Trong corpus hiện tại, không diễn giải IN_REVIEW thành APPROVED, BASELINED hoặc có hiệu lực vận hành.

Phân loại nguồn bắt buộc

Source classification phải phản ánh mức độ bằng chứng thực tế, không phản ánh mức độ mong muốn của người soạn. Cầu nối lý luận là: nguồn có thẩm quyền và mức xác minh khác nhau tạo ra rủi ro quyết định khác nhau; vì vậy cùng một câu quy tắc phải được gắn nhãn khác nhau nếu cơ sở của nó thay đổi.

Giá trị Source classification	Khi được dùng	Cách ghi cầu nối bằng chứng	Giới hạn diễn giải
Verified primary source	Quy tắc chỉ diễn đạt trong ranh giới an toàn của nguồn chính thức đã xác minh.	Nêu issuer, tên nguồn, phiên bản/trạng thái, URL và lý do nội dung nguồn hỗ trợ quy tắc.	Không suy diễn điều khoản chi tiết nếu chưa kiểm tra văn bản được cấp phép hoặc văn bản đầy đủ.
Official legal source — Verification required	Quy tắc có liên hệ luật, hóa đơn, kế toán, dữ liệu cá nhân hoặc nghĩa vụ quản lý tại Việt Nam.	Nêu văn bản chính thức và ghi rõ phần diễn giải hệ thống cần Legal Owner hoặc Accounting xác minh.	Không trình bày nội dung như tư vấn pháp lý, kết luận tuân thủ hoặc cấu hình bắt buộc cho production.
Project assumption	Chưa có nguồn xác nhận hoặc quyết định có thẩm quyền, nhưng cần giả định minh bạch để tiếp tục thiết kế học liệu.	Nêu giả định, lý do cần giả định và câu hỏi quyết định cần gửi đúng owner.	Không được chuyển thành operational rule chỉ vì đã được ghi trong catalog.
Derived internal rule	Quy tắc được suy ra từ artifact Nova Foods đã kiểm soát, không phải từ nguồn bên ngoài.	Liên kết artifact nguồn, ID liên quan và chuỗi lý luận từ nội dung nguồn đến quy tắc.	Nếu artifact nguồn cũng là giả định hoặc IN_REVIEW, quy tắc kế thừa giới hạn đó.

Chuẩn ghi nhận tác động thay đổi

Change impact phải trả lời câu hỏi: “Nếu quy tắc này đổi, điều gì có thể không còn đúng hoặc phải được kiểm tra lại?” Việc yêu cầu trường này dựa trên nguyên tắc traceability: thay đổi một quyết định mà không xác định đối tượng chịu ảnh hưởng sẽ khiến kiểm thử và tài liệu downstream có nguy cơ dùng phiên bản logic cũ.

Mức tác động	Tiêu chí ghi nhận	Nội dung tối thiểu phải nêu
Low	Chỉ làm rõ diễn đạt, không đổi điều kiện, hành động, kết quả, nguồn hoặc evidence.	Rule ID, lý do sửa, artifact cần đọc lại và xác nhận rằng acceptance evidence không đổi.
Medium	Đổi điều kiện, kết quả, ngoại lệ, owner hoặc evidence của một quy tắc.	Thực thể/trạng thái liên quan, test basis cần cập nhật, vai trò review và rủi ro của dữ liệu hoặc tài liệu cũ.
High	Đổi phân loại nguồn; liên quan pháp lý, kế toán, dữ liệu cá nhân, bảo mật; hoặc ảnh hưởng nhiều artifact/domain.	Nguồn thay đổi, phạm vi artifact bị ảnh hưởng, vai trò escalation, điều kiện dừng sử dụng diễn giải cũ và evidence cần xác minh lại.

Một quy tắc chỉ được coi là bản ghi catalog hoàn chỉnh khi tất cả trường schema có giá trị cụ thể, Source classification có cầu nối bằng chứng, và Change impact xác định được phạm vi review lại. Bản ghi thiếu một trong ba yếu tố Rule ID, Source classification hoặc Change impact là bản ghi chưa đủ điều kiện đưa vào catalog canonical; nó phải được giữ ngoài danh mục quy tắc cho đến khi được bổ sung có truy vết.

Kế hoạch quy tắc tích hợp tài chính: hóa đơn, phải thu, kích hoạt hạch toán và ranh giới đối soát

Nova Foods là bối cảnh ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp bằng VND, locale vi-VN và thời gian Asia/Ho_Chi_Minh. Mỗi quy tắc dưới đây dùng schema quy tắc canonical: ID, quy tắc, thực thể/trạng thái ảnh hưởng, điều kiện kích hoạt, kết quả bắt buộc, phân loại nguồn, cầu nối bằng chứng–lý luận, tác động thay đổi và điểm xác minh. “Hạch toán” là việc tạo bản ghi kế toán từ sự kiện nghiệp vụ; “khoản phải thu” (Receivable) là số tiền khách hàng còn phải thanh toán theo hóa đơn; “đối soát” là so sánh có kiểm soát giữa các số liệu để phát hiện và xử lý chênh lệch.

ID quy tắc	Quy tắc canonical	Thực thể/trạng thái ảnh hưởng	Điều kiện kích hoạt và kết quả bắt buộc	Phân loại nguồn và cầu nối bằng chứng–lý luận	Tác động thay đổi
BR-INV-001	Hệ thống chỉ được tạo Invoice từ giao dịch bán hàng có căn cứ nghiệp vụ mô phỏng hợp lệ; một hóa đơn phải tham chiếu duy nhất giao dịch nguồn và khách hàng chịu trách nhiệm thanh toán.	Invoice: Draft, Issued, Cancelled; Receivable	Khi giao dịch nguồn đạt điều kiện lập hóa đơn do Business Owner và Accounting xác nhận, tạo Invoice ở Draft, lưu mã giao dịch nguồn, mã khách hàng, tiền tệ VND, tổng tiền và thời điểm tạo. Khi hóa đơn được phát hành theo quy trình được xác minh, tạo hoặc cập nhật một Receivable tương ứng.	Verification required — pháp lý/kế toán/hóa đơn. Nghị định 123/2020/NĐ-CP là nguồn chính thức về hóa đơn, chứng từ; seed không cung cấp điều khoản để suy ra điều kiện phát hành cụ thể. Cầu nối: vì hóa đơn và chứng từ có hệ quả pháp lý/kế toán, điều kiện phát hành không được tự đặt thành quy định production.	Thay đổi khóa liên kết hóa đơn–giao dịch, trạng thái hoặc trường tiền tệ ảnh hưởng dữ liệu lịch sử, báo cáo công nợ và thiết kế bút toán; cần Accounting đánh giá.
BR-AR-001	Mỗi Receivable phải phản ánh số dư còn thu của đúng một Invoice; số dư được tính từ tổng giá trị hóa đơn trừ các khoản thanh toán hoặc điều chỉnh đã được ghi nhận hợp lệ trong mô hình mô phỏng.	Invoice, Receivable: Open, Partially Settled, Settled, Cancelled	Khi Invoice chuyển sang Issued, khởi tạo Receivable có số dư bằng tổng giá trị phải thu. Khi ghi nhận thanh toán hoặc điều chỉnh hợp lệ, giảm số dư; nếu số dư bằng 0 VND, chuyển Receivable sang Settled. Không cho số dư âm nếu không có loại điều chỉnh được Accounting xác định rõ.	Project assumption — mô hình nghiệp vụ học liệu; Verification required — diễn giải kế toán. Luật Kế toán 88/2015/QH13 là nguồn chính thức nhưng việc xác định cách ghi nhận và điều chỉnh thực tế thuộc thẩm quyền Accounting. Cầu nối: quan hệ một hóa đơn–một khoản phải thu giúp người học kiểm tra được nguồn gốc số dư; đây không phải kết luận về cấu hình sổ cái thực tế.	Thay đổi công thức số dư hoặc quy tắc điều chỉnh ảnh hưởng công nợ, tuổi nợ và đối soát; yêu cầu đánh giá hồi tố dữ liệu mô phỏng.
BR-FIN-001	Kích hoạt hạch toán chỉ được xảy ra từ sự kiện nghiệp vụ đã đạt trạng thái xác định; việc lưu bản nháp hoặc chỉnh sửa dữ liệu chưa phát hành không phải là kích hoạt hạch toán.	Invoice, Receivable, bản ghi hạch toán mô phỏng	Khi Invoice chuyển từ Draft sang Issued, hệ thống tạo yêu cầu ghi nhận tài chính mô phỏng gắn với ID hóa đơn. Khi Invoice ở Draft hoặc bị Cancelled trước khi phát hành, không tạo yêu cầu hạch toán. Việc đảo hoặc điều chỉnh sau phát hành phải có tham chiếu đến chứng từ nguồn, không được xóa dấu vết bản ghi trước đó.	Project assumption — nguyên tắc kiểm soát học liệu; Verification required — kế toán. Cầu nối: tách trạng thái chuẩn bị khỏi sự kiện phát hành ngăn bản nháp làm sai số liệu tài chính; tuy nhiên thời điểm ghi nhận doanh thu, thuế và bút toán thực tế phải do Accounting xác minh theo nguồn hiện hành.	Thay đổi trạng thái kích hoạt ảnh hưởng tính đúng kỳ báo cáo, số dư phải thu và dữ liệu đối soát; cần kiểm thử chuyển trạng thái và Accounting review.
BR-FIN-002	Một lần chuyển trạng thái hợp lệ của cùng Invoice chỉ được tạo tối đa một bản ghi hạch toán mô phỏng cho cùng loại sự kiện và cùng mã tham chiếu nghiệp vụ.	Invoice, Receivable, bản ghi hạch toán mô phỏng	Khi xử lý sự kiện Issued, hệ thống kiểm tra tổ hợp Invoice ID và loại sự kiện hạch toán. Nếu tổ hợp đã tồn tại, giữ nguyên bản ghi đã tạo và đánh dấu sự kiện lặp để kiểm tra, thay vì cộng thêm số tiền phải thu.	Project assumption — kiểm soát toàn vẹn dữ liệu. Cầu nối: một hóa đơn phát hành lặp lại về mặt kỹ thuật không làm phát sinh khoản nợ mới về mặt nghiệp vụ; khóa kiểm tra ngăn ghi nhận trùng trong dữ liệu mô phỏng.	Thay đổi khóa chống trùng ảnh hưởng dữ liệu tích hợp lịch sử và khả năng phát hiện chênh lệch; cần kiểm tra dữ liệu trùng trước khi áp dụng.
BR-REC-001	Đối soát phải phân biệt rõ ba biên số liệu: biên chứng từ bán hàng, biên phải thu và biên ghi nhận tài chính mô phỏng; không được coi các tổng số bằng nhau là bằng chứng đủ nếu thiếu khóa tham chiếu từng giao dịch.	Invoice, Receivable, bản ghi hạch toán mô phỏng, kết quả đối soát	Theo chu kỳ do Accounting xác định, đối chiếu từng Invoice ID đã Issued với Receivable và bản ghi hạch toán mô phỏng tương ứng. Kết quả phải phân loại: khớp hoàn toàn, thiếu ở phải thu, thiếu ở ghi nhận tài chính, khác số tiền, hoặc khác trạng thái. Chênh lệch không tự được sửa bằng cách thay đổi tổng số; phải giữ mã tham chiếu và nguyên nhân điều tra.	Project assumption — thiết kế kiểm soát học liệu; Verification required — kế toán. Cầu nối: tổng hợp có thể che khuất một hóa đơn bị thiếu và một hóa đơn bị ghi trùng có giá trị bằng nhau; đối chiếu theo khóa giao dịch mới xác định được nguồn chênh lệch.	Thay đổi mức độ đối soát từ tổng hợp sang từng chứng từ tăng nhu cầu lưu dữ liệu tham chiếu, nhưng giảm rủi ro sai lệch không truy được nguồn.
BR-REC-002	Ranh giới đối soát của corpus chỉ bao gồm dữ liệu ERP mô phỏng: giao dịch nguồn, Invoice, Receivable và bản ghi hạch toán mô phỏng; không khẳng định đối soát với ngân hàng, cơ quan thuế, nhà cung cấp hóa đơn điện tử hoặc sổ sách thực tế.	Invoice, Receivable, kết quả đối soát	Báo cáo đối soát phải ghi rõ phạm vi dữ liệu đã so sánh, thời điểm chốt dữ liệu theo Asia/Ho_Chi_Minh, số lượng bản ghi, tổng VND và danh sách chênh lệch theo ID. Dữ liệu ngoài ranh giới chỉ được đưa vào sau khi có nguồn, quyền sở hữu dữ liệu và xác minh chuyên môn phù hợp.	Verification required — pháp lý/kế toán/hóa đơn; Project assumption — phạm vi mô phỏng. Cầu nối: các nguồn chính thức được cung cấp xác nhận tồn tại khung pháp lý liên quan, nhưng không cung cấp đủ điều khoản hoặc bằng chứng kết nối hệ thống để xác nhận đối soát bên ngoài.	Mở rộng biên đối soát sang nguồn ngoài ERP sẽ tạo tác động đến ownership dữ liệu, bằng chứng kế toán và nghĩa vụ pháp lý; cần escalation tới Accounting và Legal Owner.

Ví dụ dữ liệu tổng hợp: Invoice INV-SIM-20260807-001 có tổng giá trị 12.500.000 VND được chuyển từ Draft sang Issued. Theo BR-INV-001 và BR-AR-001, hệ thống tạo Receivable liên kết có số dư ban đầu 12.500.000 VND; theo BR-FIN-001, đây là sự kiện đủ điều kiện tạo ghi nhận tài chính mô phỏng. Nếu cùng sự kiện được gửi lại, BR-FIN-002 yêu cầu nhận diện tổ hợp hóa đơn và loại sự kiện đã tồn tại để không tăng số dư lần hai. Khi đối soát, BR-REC-001 kiểm tra ba bản ghi theo cùng ID thay vì chỉ so tổng tiền; mọi diễn giải về thuế, doanh thu, chứng từ điện tử hoặc bút toán thực tế vẫn giữ nhãn Verification required và phải được Accounting hoặc Legal Owner xác minh.

Quy tắc phê duyệt ngoại lệ cho tín dụng, chiết khấu, mua hàng và sản xuất

Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy mọi quy tắc dưới đây chỉ là kế hoạch chuẩn hóa cho corpus /01-curriculum/CANONICAL_BUSINESS_RULES.md, không phải approval thực tế hay cam kết vận hành. Từ nguyên lý kiểm soát nghiệp vụ, một “ngoại lệ” chỉ được chấp nhận khi có người có thẩm quyền đúng vai trò ký duyệt trước khi chứng từ đi tiếp; nếu không, hệ thống phải giữ trạng thái PENDING_APPROVAL hoặc tương đương và không cho ghi nhận hậu quả kế toán hay vận hành. “Approval” là phê duyệt có truy vết; “override” là cho phép vượt ngưỡng chuẩn một cách có kiểm soát. Các quy tắc dưới đây bám vào nguyên tắc đó và phân tách rõ quyền quyết định, lý do, và tác động thay đổi.

Canonical Rule ID	Quy tắc chuẩn hóa	Đối tượng/trạng thái bị ảnh hưởng	Nguồn phân loại	Change impact
BR-APP-CR-001	Yêu cầu phê duyệt khi người dùng muốn credit override (vượt hạn mức tín dụng): nếu giá trị đơn bán vượt hạn mức khách hàng đã cấu hình hoặc vượt ngưỡng rủi ro tạm chấp nhận, hệ thống phải tạo Approval trước khi cho phép tiếp tục xử lý đơn. Lý do: hạn mức tín dụng là hàng rào kiểm soát rủi ro công nợ; nếu vượt ngưỡng mà không duyệt thì rủi ro chuyển thẳng sang Receivable.	Approval, User Role, Credit Limit, Sales Order, Receivable	Project assumption cho ngưỡng nghiệp vụ; Sourced về nguyên tắc kiểm soát công nợ và ghi nhận kế toán theo Luật Kế toán cần xác minh bởi Accounting Owner	Ảnh hưởng trung bình đến luồng bán hàng và công nợ; thay đổi phải tăng kiểm soát truy vết, thêm lý do duyệt, và khóa ghi nhận khi chưa duyệt
BR-APP-DS-002	Yêu cầu phê duyệt khi người dùng muốn discount override (vượt mức chiết khấu): nếu chiết khấu thực tế cao hơn khung cho phép theo khách hàng, chương trình bán hàng, hoặc vai trò người dùng, hệ thống phải tạo Approval trước khi giá cuối cùng được chốt. Lý do: chiết khấu làm giảm doanh thu mô phỏng và ảnh hưởng bút toán; vì vậy phải có kiểm soát quyền lực rõ ràng để tránh giảm giá tùy tiện.	Approval, User Role, Sales Order, Invoice	Sourced từ nguyên tắc hóa đơn/chứng từ theo Nghị định 123/2020/NĐ-CP; Verification required bởi Accounting Owner trước khi dùng trong cấu hình thật	Ảnh hưởng cao đến doanh thu, hóa đơn và báo cáo; thay đổi phải ghi rõ mức vượt ngưỡng, người duyệt, thời điểm duyệt, và không cho tự động ghi đè nếu chưa có approval
BR-APP-PR-003	Yêu cầu phê duyệt cho procurement exception (ngoại lệ mua hàng): nếu đơn mua, nhà cung cấp, giá mua, điều kiện giao hàng, hoặc số lượng vượt quy trình mua đã chuẩn hóa thì phải có Approval trước khi phát hành hoặc xác nhận tiếp. Lý do: ngoại lệ mua hàng có thể làm lệch ngân sách và điều kiện kiểm soát nhà cung cấp; không duyệt thì không được coi là hợp lệ về quy trình.	Approval, Procurement Request, Purchase Order, User Role	Project assumption; nếu gắn với nghĩa vụ kế toán/hóa đơn thì phần diễn giải kế toán phải được Verification required	Ảnh hưởng trung bình đến ngân sách và lịch nhập hàng; thay đổi phải giữ vết người đề nghị, người duyệt, lý do ngoại lệ, và mức chênh lệch so với chuẩn
BR-APP-PP-004	Yêu cầu phê duyệt cho production exception (ngoại lệ sản xuất): nếu lệnh sản xuất, công thức, định mức, thay thế nguyên liệu, hoặc thời điểm chạy vượt kế hoạch chuẩn thì phải có Approval trước khi phát hành lệnh hoặc cho phép sản xuất tiếp. Lý do: ngoại lệ sản xuất có thể làm thay đổi tiêu hao, chất lượng và truy vết lô; nếu chưa duyệt thì trạng thái phải giữ ở mức chờ xử lý.	Approval, Production Order, BOM, User Role	Project assumption; phần nào liên quan an toàn thực phẩm hoặc truy xuất nguồn gốc phải gắn Verification required theo chủ sở hữu nghiệp vụ và pháp lý	Ảnh hưởng cao đến chất lượng và truy vết; thay đổi phải ghi lý do kỹ thuật, tác động đến định mức, và không cho phép phát hành lệnh khi còn treo phê duyệt

Quy tắc chung cho cả bốn nhóm ngoại lệ là: người tạo yêu cầu không được tự duyệt yêu cầu của chính mình nếu vai trò đó đồng thời là người đề xuất và người ghi nhận hậu quả; đây là nguyên tắc phân tách nhiệm vụ để giảm gian lận và sai sót. Nếu một ngoại lệ chạm đồng thời đến bán hàng, kế toán, mua hàng hoặc sản xuất, hồ sơ phải ghi một Approval duy nhất có tham chiếu đến đối tượng gốc, lý do duyệt bằng ngôn ngữ nghiệp vụ ngắn gọn, và mức vượt chuẩn cụ thể để người đọc zero-entry vẫn hiểu được “vượt cái gì, ai cho phép, và vì sao được phép”. Các nội dung có liên quan Luật Kế toán hoặc Nghị định hóa đơn đều phải giữ nhãn Sourced cho căn cứ văn bản, còn cách áp dụng vào Nova Foods mô phỏng phải ghi Verification required trước khi đưa sang thiết kế thực thi.

Quy tắc báo cáo vận hành, dashboard điều hành, độ mới dữ liệu và thẩm quyền báo cáo

Nova Foods Trading & Manufacturing là bối cảnh mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp bằng VND. Trong phạm vi này, dashboard là màn hình tổng hợp chỉ số để theo dõi nhanh; báo cáo vận hành là báo cáo phục vụ xử lý công việc hằng ngày; báo cáo điều hành là báo cáo tổng hợp phục vụ quyết định quản trị. “Độ mới dữ liệu” (data freshness) là thời điểm dữ liệu được làm mới so với thời điểm người dùng xem báo cáo. Các quy tắc dưới đây dùng schema canonical gồm: ID, phát biểu quy tắc, kích hoạt, đối tượng/trạng thái, nguồn và phân loại nguồn, kiểm tra được, tác động thay đổi.

Rule ID	Phát biểu quy tắc canonical	Kích hoạt và ranh giới quyết định	Đối tượng/trạng thái ảnh hưởng	Phân loại nguồn và cầu nối lập luận	Kiểm tra được	Tác động thay đổi
BR-RPT-001	Mỗi Report phải hiển thị rõ tên báo cáo, kỳ dữ liệu, thời điểm làm mới gần nhất theo Asia/Ho_Chi_Minh, đơn vị tiền tệ VND khi có giá trị tiền, và trạng thái dữ liệu CURRENT, STALE hoặc FAILED.	Kích hoạt khi người dùng mở, xuất hoặc lên lịch nhận báo cáo. CURRENT chỉ được dùng khi lần làm mới hoàn tất; STALE dùng khi dữ liệu cũ hơn ngưỡng đã công bố; FAILED dùng khi lần làm mới gần nhất không hoàn tất.	Report, Dashboard, Report Dataset	Project assumption. Cầu nối: người đọc không thể đánh giá tính phù hợp của con số nếu không biết dữ liệu thuộc kỳ nào và được cập nhật lúc nào; vì vậy metadata phải đi cùng kết quả báo cáo.	Mở một báo cáo dữ liệu tổng hợp và xác nhận đủ năm trường hiển thị; mô phỏng lỗi làm mới để xác nhận trạng thái chuyển thành FAILED.	Ảnh hưởng trung bình đến giao diện, mô hình dữ liệu và kiểm thử báo cáo; thay đổi ngưỡng freshness phải rà soát tất cả dashboard dùng chung dataset.
BR-RPT-002	Dashboard vận hành phải ưu tiên chỉ số có thể hành động trong ngày, gồm số lượng chứng từ chờ xử lý, đơn hàng quá hạn xử lý, tồn kho dưới mức cảnh báo và ngoại lệ cần xử lý; dashboard không được tự diễn giải nguyên nhân hoặc tự tạo quyết định nghiệp vụ.	Kích hoạt khi vai trò vận hành truy cập dashboard. Ranh giới là dashboard chỉ hiển thị và dẫn tới danh sách nguồn; người dùng phải mở đối tượng gốc trước khi xử lý.	Dashboard, Report, Sales Order, Inventory Item, Exception	Project assumption; thuật ngữ và cách tổ chức yêu cầu được tham chiếu ở mức phương pháp từ BABOK Guide, IIBA, Version 3. Cầu nối: chỉ số vận hành có giá trị khi dẫn người dùng đến công việc cụ thể, không thay thế phán đoán nghiệp vụ.	Với mỗi KPI tổng hợp, kiểm tra có liên kết đến danh sách đối tượng nguồn và số lượng danh sách khớp số KPI trong dữ liệu tổng hợp.	Ảnh hưởng cao đến phạm vi chỉ số, truy vấn dữ liệu và acceptance criteria; thêm KPI mới cần xác định nguồn dữ liệu, chủ sở hữu và hành động tiếp theo.
BR-RPT-003	Dashboard điều hành phải phân biệt chỉ số sơ bộ với chỉ số đã đối soát. Chỉ số doanh thu, công nợ hoặc số liệu kế toán chỉ được gắn nhãn RECONCILED khi quy trình đối soát đã hoàn tất theo phạm vi kỳ báo cáo; nếu chưa hoàn tất phải gắn PRELIMINARY.	Kích hoạt khi tạo hoặc xem báo cáo điều hành có số liệu tài chính. Ranh giới: nhãn RECONCILED xác nhận trạng thái dữ liệu trong hệ thống mô phỏng, không xác nhận báo cáo tài chính hợp pháp, quyết toán thuế hoặc tuân thủ kế toán thực tế.	Executive Dashboard, Report, Invoice, Receivable, Reconciliation Status	Verification required đối với mọi diễn giải kế toán; nguồn pháp lý tham chiếu: Luật Kế toán 88/2015/QH13. Cầu nối: luật là nguồn chính thức nhưng seed không cung cấp điều khoản để suy luận tiêu chí đối soát cụ thể; Accounting Owner phải xác minh trước khi thiết kế thực thi.	Tạo dữ liệu tổng hợp có một Invoice chưa đối soát và xác nhận báo cáo hiển thị PRELIMINARY; sau khi hoàn tất đối soát mô phỏng, xác nhận nhãn đổi thành RECONCILED.	Ảnh hưởng cao đến báo cáo tài chính, định nghĩa KPI và quy trình chốt kỳ; thay đổi phải được Accounting Owner xác minh và truy vết.
BR-RPT-004	Mỗi Report phải có một report authority (thẩm quyền báo cáo) được ghi nhận: vai trò chịu trách nhiệm về định nghĩa chỉ số, kỳ báo cáo, nguồn dữ liệu và mục đích sử dụng. Người xem báo cáo không trở thành chủ sở hữu số liệu chỉ vì có thể xem hoặc xuất báo cáo.	Kích hoạt khi tạo báo cáo mới, sửa công thức KPI, đổi nguồn dữ liệu hoặc đổi lịch làm mới. Ranh giới: report authority chịu trách nhiệm nghiệp vụ về định nghĩa; không tự thay thế thẩm quyền pháp lý, kế toán hoặc phê duyệt quản trị.	Report, Dashboard, User Role, Report Definition	Project assumption. Cầu nối: khi số liệu thay đổi mà không có vai trò chịu trách nhiệm, người dùng không có đầu mối để làm rõ ý nghĩa, nên định nghĩa và owner phải được lưu cùng báo cáo.	Kiểm tra mỗi báo cáo có trường authority, mục đích, danh sách KPI và nguồn dữ liệu; thử sửa KPI khi chưa có authority để xác nhận yêu cầu bị từ chối ở mức quy trình.	Ảnh hưởng trung bình đến quản trị danh mục báo cáo và quy trình thay đổi; thay authority phải cập nhật traceability và thông báo cho các dashboard phụ thuộc.
BR-RPT-005	Báo cáo xuất ra phải mang mã Report ID, thời điểm xuất, kỳ dữ liệu, trạng thái freshness và nhãn dữ liệu mô phỏng. Tệp xuất không được được coi là nguồn chuẩn mới; nguồn chuẩn vẫn là Report trong hệ thống tại thời điểm có ghi metadata.	Kích hoạt khi người dùng xuất PDF, bảng tính hoặc bản in từ Report. Ranh giới: tệp xuất là ảnh chụp dữ liệu tại thời điểm xuất, không tự cập nhật khi dữ liệu nguồn thay đổi.	Report, Report Export, Audit Log	Project assumption. Cầu nối: bản xuất có thể được chia sẻ sau khi dashboard đã đổi dữ liệu; metadata xuất giúp phân biệt kết quả cũ với kết quả hiện hành và tránh hiểu nhầm về tính cập nhật.	Xuất một báo cáo dữ liệu tổng hợp, thay đổi dữ liệu nguồn, rồi xác nhận tệp đã xuất vẫn giữ thời điểm và trạng thái ban đầu trong khi báo cáo trực tuyến hiển thị lần làm mới mới.	Ảnh hưởng trung bình đến mẫu xuất báo cáo, lưu vết và kiểm thử hồi quy; mọi thay đổi định dạng phải bảo toàn năm metadata bắt buộc.

Ví dụ diễn giải: dashboard vận hành hiển thị “12 đơn hàng chờ xử lý” là chỉ số để nhân viên mở danh sách 12 đơn hàng tổng hợp và xử lý từng đơn; nó không có nghĩa hệ thống đã kết luận đơn hàng nào phải được ưu tiên. Dashboard điều hành hiển thị “Doanh thu tháng 07/2026 — PRELIMINARY” cho biết số liệu còn sơ bộ trong mô phỏng, không phải khẳng định về báo cáo tài chính hoặc nghĩa vụ kế toán thực tế. Mọi thay đổi định nghĩa KPI tài chính, kỳ chốt hoặc tiêu chí RECONCILED phải được gắn Verification required, có tham chiếu đến BR-RPT-003, và chuyển đến Accounting Owner để xác minh theo nguồn chính thức phù hợp.

Danh mục quy tắc bảo mật: truy cập, phân tách nhiệm vụ, nhật ký và dữ liệu nhạy cảm

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Các quy tắc dưới đây được lập cho /01-curriculum/CANONICAL_BUSINESS_RULES.md, trạng thái IN_REVIEW, phiên bản 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. Mỗi quy tắc dùng cùng một schema canonical: Rule ID để truy vết ổn định; quy tắc và tiêu chí quyết định để xác định hành vi; đối tượng/trạng thái ảnh hưởng; phân loại nguồn và cầu nối suy luận; bằng chứng kiểm tra; và change impact (tác động khi thay đổi). IN_REVIEW không xác nhận thiết kế đã được phê duyệt, tuân thủ pháp luật hoặc sẵn sàng production.

Rule ID	Quy tắc và tiêu chí quyết định	Đối tượng/trạng thái ảnh hưởng	Phân loại nguồn và cầu nối suy luận	Bằng chứng kiểm tra tối thiểu	Change impact
BR-SEC-001	ERP phải áp dụng RBAC (Role-Based Access Control — kiểm soát truy cập theo vai trò): một User Role chỉ được cấp thao tác đọc, tạo, sửa, duyệt hoặc hủy trên đúng đối tượng cần cho nhiệm vụ mô phỏng. Khi người dùng không có quyền được cấp rõ ràng, hệ thống phải từ chối thao tác và không làm thay đổi trạng thái đối tượng.	User Role, Invoice, Receivable, Approval, Report, Audit Log; trạng thái thao tác Denied hoặc Permitted.	Sourced — OWASP ASVS 5.0.0; Project assumption. OWASP ASVS là chuẩn kiểm chứng thực hành bảo mật, không phải luật Việt Nam. Suy luận: quyền tối thiểu giới hạn hậu quả khi tài khoản bị dùng sai; phạm vi quyền cụ thể của Nova Foods chưa có nguồn nghiệp vụ nên là giả định dự án.	Ma trận vai trò–quyền; một kiểm thử truy cập được phép; một kiểm thử truy cập bị từ chối; bản ghi Audit Log cho lần từ chối.	Thay đổi vai trò, quyền, đối tượng hoặc trạng thái được bảo vệ phải đánh giá lại ma trận quyền, test truy cập, tài liệu đào tạo và traceability tới các rule liên quan.
BR-SEC-002	Một người dùng không được đồng thời có tập quyền có thể tự tạo và tự hoàn tất cùng một quyết định có ảnh hưởng tài chính hoặc kiểm soát. Đây là segregation of duties (SoD), tức phân tách nhiệm vụ để một cá nhân không tự khởi tạo, tự phê duyệt và tự che giấu cùng một giao dịch. Nếu tổ hợp quyền vi phạm ma trận SoD, yêu cầu cấp quyền phải bị chặn hoặc chuyển thành ngoại lệ có lý do, người phê duyệt độc lập và thời hạn hiệu lực xác định.	User Role, Approval, Invoice, Receivable, Audit Log; trạng thái yêu cầu quyền Blocked, Exception Pending, Granted.	Project assumption; Verification required — accounting/security owner. Suy luận: phân tách người khởi tạo với người hoàn tất giảm rủi ro sai sót hoặc lạm dụng không được phát hiện. Việc xác định tổ hợp quyền nào có tác động kế toán thực tế cần Accounting Owner và Security Owner xác minh; không suy diễn từ Luật Kế toán.	Ma trận xung đột SoD; kiểm thử cấp hai quyền xung đột bị chặn; hồ sơ ngoại lệ có người quyết định độc lập, thời hạn và log.	Mọi thay đổi luồng công việc, vai trò tài chính hoặc quyền Approval phải rà soát lại xung đột SoD, ngoại lệ đang hiệu lực và ca kiểm thử hồi quy.
BR-SEC-003	Mỗi hành động tạo, sửa, hủy, cấp hoặc thu hồi quyền, thay đổi trạng thái, và truy cập bị từ chối trên đối tượng kiểm soát phải sinh Audit Log không thể bị người thực hiện nghiệp vụ sửa trực tiếp. Bản ghi tối thiểu gồm mã sự kiện, thời điểm theo Asia/Ho_Chi_Minh, định danh người hoặc vai trò thực hiện, đối tượng bị tác động, giá trị trạng thái trước/sau khi phù hợp, kết quả và mã lý do.	Audit Log, User Role, Invoice, Receivable, Approval, Report; trạng thái Created, Updated, Cancelled, Denied, Role Changed.	Sourced — OWASP ASVS 5.0.0; Project assumption. Cầu nối: khả năng điều tra đòi hỏi bằng chứng ai làm gì, khi nào và kết quả ra sao; tập trường log cụ thể là giả định thiết kế học liệu, chưa phải cấu hình kỹ thuật.	Mẫu log dùng dữ liệu tổng hợp; kiểm thử một thay đổi trạng thái và một lần bị từ chối đều tạo log; kiểm thử người dùng nghiệp vụ không sửa trực tiếp log.	Thay đổi trường log, quyền xem log, danh mục sự kiện hoặc cơ chế lưu giữ phải được Security Owner và QA Reviewer đánh giá vì có thể làm mất khả năng truy vết hoặc làm lộ dữ liệu.
BR-SEC-004	Dữ liệu định danh cá nhân và dữ liệu có thể liên kết đến một cá nhân trong dữ liệu tổng hợp phải được phân loại là Sensitive hoặc Restricted trước khi hiển thị, xuất hoặc dùng trong báo cáo. User Role không có nhu cầu công việc đã được xác định chỉ được thấy dữ liệu che một phần hoặc không thấy dữ liệu; không dùng dữ liệu người thật, số định danh thật, tài khoản thật hoặc thông tin liên hệ thật trong corpus Nova Foods.	Report, User Role, Audit Log, Invoice, Receivable; trạng thái dữ liệu Masked, Restricted, Access Denied.	Verification required — Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP; Project assumption. Nguồn pháp lý được xác định nhưng yêu cầu hệ thống suy ra từ nguồn phải do Legal Owner xác minh. Suy luận tạm thời: phân loại và che dữ liệu giảm việc tiếp cận vượt nhu cầu; danh mục trường nhạy cảm cụ thể chưa được xác nhận pháp lý.	Danh mục phân loại dữ liệu; ví dụ báo cáo tổng hợp hiển thị dữ liệu đã che; kiểm thử vai trò không đủ quyền không xem được giá trị gốc; xác nhận mọi ví dụ là dữ liệu tổng hợp.	Bổ sung trường dữ liệu, chức năng xuất, báo cáo hoặc đối tượng người dùng mới phải phân loại lại dữ liệu và rà soát Legal Owner, Security Owner, quyền truy cập và log.
BR-SEC-005	Việc cấp, thay đổi, tạm ngừng và thu hồi User Role phải có yêu cầu truy vết được, nêu rõ người dùng, vai trò, phạm vi đối tượng, lý do, người quyết định có thẩm quyền trong mô phỏng và thời điểm hiệu lực. Quyền tạm thời phải có ngày hết hạn; khi đến hạn, quyền phải bị thu hồi hoặc chuyển về trạng thái chờ quyết định mới, không tự gia hạn.	User Role, Approval, Audit Log; trạng thái quyền Requested, Active, Suspended, Expired, Revoked.	Project assumption; Sourced — OWASP ASVS 5.0.0. Cầu nối: vòng đời quyền có bằng chứng và thời hạn giúp kiểm soát quyền dư thừa; vai trò phê duyệt cụ thể của Nova Foods là giả định vì chưa có mô hình tổ chức được xác minh.	Hồ sơ yêu cầu quyền mẫu; kiểm thử quyền tạm thời hết hạn; log cấp và thu hồi quyền; kiểm thử tài khoản đã thu hồi bị từ chối.	Thay đổi chính sách vòng đời tài khoản hoặc ma trận vai trò phải đánh giá tác động tới SoD, log, dữ liệu nhạy cảm, kịch bản kiểm thử và hướng dẫn vận hành mô phỏng.

Các nội dung pháp lý về dữ liệu cá nhân chỉ được gắn nhãn Verification required; chúng không phải kết luận tuân thủ, diễn giải pháp lý hoặc xác nhận của Legal Owner. Mọi thay đổi làm lộ cấu trúc quyền, định danh người dùng, dữ liệu nhạy cảm hoặc nội dung Audit Log phải được chuyển tới vai trò Security theo cơ chế escalation của /01-curriculum/TRACEABILITY_ID_REGISTRY.md; nếu đồng thời ảnh hưởng ghi nhận tài chính, phải chuyển thêm Accounting Owner.

Quy tắc tích hợp API, bàn giao sự kiện, xử lý lỗi, retry, idempotency và ranh giới sở hữu dữ liệu

Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; vì vậy, các quy tắc tích hợp dưới đây được viết từ nguyên tắc kiểm soát luồng dữ liệu trước khi nói tới kỹ thuật triển khai. Điểm gốc là: một hệ thống chỉ được phát tán dữ liệu khi nó là nguồn có thẩm quyền cho dữ liệu đó, còn hệ thống nhận chỉ được dùng dữ liệu như đầu vào tiêu thụ hoặc đồng bộ, không tự ý đổi ngược dữ liệu gốc. Thuật ngữ API (giao diện lập trình ứng dụng) ở đây được hiểu là hợp đồng trao đổi dữ liệu giữa hệ thống; event handoff (bàn giao sự kiện) là việc phát tín hiệu rằng một thay đổi đã hoàn tất ở hệ thống nguồn để hệ thống khác xử lý tiếp; idempotency (tính lặp an toàn) là dù gửi lại cùng một yêu cầu nhiều lần thì kết quả nghiệp vụ vẫn không bị nhân đôi.

Rule ID	Quy tắc canonical cho /01-curriculum/CANONICAL_BUSINESS_RULES.md	Source classification	Change impact
BR-INT-001	Mọi API của Nova Foods phải có hợp đồng rõ ràng về tài nguyên, phương thức, trường dữ liệu, mã lỗi và phiên bản schema; khi API chạm tới Invoice hoặc Receivable, payload phải ghi rõ hệ thống nguồn nào là source of truth (nguồn dữ liệu chuẩn) để tránh đồng bộ chéo mơ hồ. Cơ sở là OpenAPI 3.1.1 cho cách mô tả API, còn nội dung nghiệp vụ cụ thể của từng trường là Project assumption cho corpus này cho tới khi có xác minh từ owner phù hợp.	Sourced: OpenAPI; Project assumption cho nghiệp vụ nội bộ	Cao, vì đổi hợp đồng API có thể làm hỏng tích hợp và downstream mapping
BR-INT-002	Chỉ phát sinh sự kiện sau khi trạng thái ở hệ thống nguồn đã commit xong; ví dụ một Integration Message chỉ được phát đi khi thay đổi nghiệp vụ đã được ghi nhận hoàn tất ở nguồn. Lý do là nếu phát sự kiện trước khi commit, hệ thống nhận có thể thấy dữ liệu chưa tồn tại hoặc chưa nhất quán. Đây là nguyên tắc tích hợp dựa trên suy luận nghiệp vụ, dùng cho thiết kế bàn giao sự kiện, không phải phán quyết pháp lý hay kế toán.	Project assumption	Cao, vì sai thứ tự commit/sự kiện gây lệch trạng thái giữa các hệ thống
BR-INT-003	Khi hệ thống đích nhận lỗi tạm thời như timeout, mất kết nối hoặc dịch vụ bận, luồng tích hợp phải retry (thử lại) có giới hạn, có khoảng chờ tăng dần, và phải ghi nhận trạng thái xử lý của Integration Message; khi lỗi là lỗi dữ liệu hoặc lỗi hợp đồng, phải dừng retry tự động và chuyển sang hàng chờ xử lý ngoại lệ. Cách phân loại lỗi này xuất phát từ nguyên tắc kiểm soát rủi ro tích hợp; chi tiết ngưỡng số lần thử là Project assumption cho Nova Foods cho tới khi kiến trúc hệ thống xác nhận.	Project assumption; tham chiếu tốt với OpenAPI cho mã lỗi	Trung bình đến cao, vì thay đổi chính sách retry ảnh hưởng tải hệ thống và thời gian xử lý
BR-INT-004	Các yêu cầu có thể gửi lặp, như tạo chứng từ hoặc nhận event trùng, phải dùng khóa idempotency hoặc khóa nghiệp vụ tự nhiên để cùng một thao tác chỉ tạo ra một kết quả duy nhất; nếu hệ thống đã xử lý rồi, lần gửi sau phải trả về cùng kết quả xử lý thay vì tạo bản ghi mới. Quy tắc này bảo vệ Invoice, Receivable và các bản ghi trung gian khỏi bị nhân đôi khi mạng lỗi hoặc consumer nhận lại message.	Project assumption	Cao, vì lỗi idempotency có thể tạo hóa đơn hoặc công nợ trùng
BR-INT-005	Ranh giới sở hữu dữ liệu phải rõ theo miền nghiệp vụ: hệ thống nguồn giữ quyền sửa dữ liệu gốc của miền mình, hệ thống nhận chỉ được đọc, chuyển đổi hoặc lưu bản sao phục vụ tích hợp, không được đổi ngược trường gốc nếu chưa có giao thức quay lại nguồn. Ví dụ, dữ liệu bán hàng tạo công nợ là đầu vào cho kế toán tích hợp, nhưng việc xác nhận logic hạch toán cụ thể là Verification required và phải do vai trò kế toán có thẩm quyền xác minh; corpus này không tự suy diễn bút toán thực tế.	Verification required cho phần kế toán; Project assumption cho ranh giới sở hữu	Cao, vì nhầm owner dữ liệu sẽ tạo xung đột giữa hệ thống nguồn và hệ thống tiêu thụ

Quy tắc vận hành bổ sung cho micro-batch này là: mỗi Integration Message phải có định danh duy nhất để truy vết, và mọi trạng thái xử lý như pending, processed, failed, retrying phải được hiểu là trạng thái kỹ thuật của tích hợp chứ không phải trạng thái phê duyệt nghiệp vụ. Nếu một tích hợp đụng tới dữ liệu kế toán, hóa đơn, công nợ hoặc dữ liệu cá nhân, phần mô tả trong /01-curriculum/CANONICAL_BUSINESS_RULES.md phải gắn nhãn đúng là Sourced, Verification required, hoặc Project assumption; không được ngầm coi là đã được luật, kế toán hay chủ sở hữu dữ liệu xác nhận chỉ vì nó xuất hiện trong plan.

Danh mục thực thể và trạng thái chịu tác động

Nova Foods là bối cảnh ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp bằng VND. Bảng dưới xác định các thực thể (entity, đối tượng dữ liệu mà hệ thống quản lý) và trạng thái (state, điều kiện vòng đời có ý nghĩa nghiệp vụ) phải được dùng nhất quán khi soạn các quy tắc tại phần này. Đây là phạm vi lập kế hoạch của /01-curriculum/CANONICAL_BUSINESS_RULES.md, trạng thái artifact là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải cấu hình ERP, baseline hay xác nhận phê duyệt.

Thực thể chịu tác động	Mục đích và trạng thái chuẩn cần mô hình hóa	Bằng chứng/lý do xác định	Phân loại nguồn	Change impact (tác động khi thay đổi)
Invoice (Hóa đơn)	Đại diện chứng từ bán hàng cần theo dõi tối thiểu qua Draft, Issued, Cancelled, Reconciled. Draft chưa là căn cứ ghi nhận; Issued là bản đã được phát hành theo luồng mô phỏng; Cancelled giữ dấu vết thay vì xóa; Reconciled cho biết đã được đối chiếu trong phạm vi đã xác định.	Mục yêu cầu nêu rõ invoicing, posting trigger và reconciliation boundary nên hóa đơn phải có trạng thái phân biệt trước/sau phát hành và đối soát.	Verification required đối với mọi diễn giải về hóa đơn, thời điểm lập, hủy, điều chỉnh và lưu trữ; nguồn tham chiếu là Nghị định 123/2020/NĐ-CP, cần kiểm tra sửa đổi hiện hành bởi Legal Owner/Accounting.	Thay đổi trạng thái hoặc ý nghĩa Invoice ảnh hưởng quy tắc tài chính, báo cáo doanh thu, thông điệp tích hợp, nhật ký kiểm toán và kiểm thử đối soát.
Receivable (Khoản phải thu)	Theo dõi nghĩa vụ thu tiền mô phỏng với Open, Partially Settled, Settled, Disputed, Written Off. Open còn số dư; Partially Settled đã thu một phần; Settled có số dư bằng không; Disputed đang bị tranh chấp; Written Off là trạng thái nghiệp vụ mô phỏng, không tự suy ra bút toán hợp lệ.	Yêu cầu có receivables và reconciliation boundaries; các trạng thái này tách số dư còn thu, tranh chấp và xử lý ngoại lệ để báo cáo không gộp sai.	Project assumption cho mô hình trạng thái. Verification required cho xóa nợ, dự phòng, hạch toán và thời hạn lưu giữ theo Luật Kế toán 88/2015/QH13 và quyết định của Accounting Owner.	Ảnh hưởng quy tắc công nợ, hạn mức tín dụng, dashboard tài chính, đối soát thanh toán và dữ liệu phát sang hệ thống kế toán.
Approval (Yêu cầu phê duyệt)	Quản lý quyết định ngoại lệ qua Pending, Approved, Rejected, Expired, Cancelled. Mỗi yêu cầu phải liên kết một đối tượng đích, ví dụ hóa đơn, đơn mua hoặc lệnh sản xuất, nhưng không được dùng trạng thái phê duyệt để thay thế trạng thái của đối tượng đích.	Yêu cầu section liệt kê approval và các nhóm ngoại lệ; tách hai vòng đời tránh suy luận sai rằng một yêu cầu được duyệt làm chứng từ tự động hoàn tất.	Project assumption; thẩm quyền, ngưỡng và người duyệt chưa được xác nhận là quyết định nghiệp vụ.	Ảnh hưởng phân quyền, segregation of duties (phân tách nhiệm vụ để một người không tự tạo và tự phê duyệt cùng ngoại lệ), Audit Log và các điều kiện chuyển trạng thái liên quan.
Report (Báo cáo)	Quản lý sản phẩm thông tin qua Defined, Published, Superseded, Retired. Defined có định nghĩa chỉ tiêu; Published được phát hành cho người có quyền; Superseded bị thay bởi phiên bản mới nhưng cần truy vết; Retired không còn được dùng làm nguồn báo cáo hiện hành.	Yêu cầu có operational/executive dashboard, data freshness và report authority; báo cáo cần vòng đời riêng để phân biệt chỉ tiêu đang dùng với chỉ tiêu cũ.	Project assumption cho trạng thái và thẩm quyền báo cáo; không phải xác nhận chỉ tiêu tài chính chính thức.	Ảnh hưởng danh mục KPI, quyền xem, metadata về độ mới dữ liệu, liên kết dashboard và bằng chứng kiểm toán.
User Role (Vai trò người dùng)	Biểu diễn tập quyền theo Defined, Active, Suspended, Retired. Vai trò không phải người dùng cá nhân; một người dùng có thể được gán hoặc thu hồi nhiều vai trò theo quy tắc truy cập.	Yêu cầu nêu access control và segregation of duties; tách role khỏi user giúp đánh giá quyền theo chức năng thay vì theo tên cá nhân.	Project assumption. OWASP ASVS 5.0.0 là nguồn thực hành bảo mật tham khảo, không phải luật Việt Nam hay bằng chứng tuân thủ.	Ảnh hưởng quyền thao tác thực thể, phạm vi dữ liệu hiển thị, phê duyệt, API authorization và Audit Log.
Integration Message (Thông điệp tích hợp)	Theo dõi đơn vị bàn giao dữ liệu giữa hệ thống qua Created, Accepted, Processing, Succeeded, Failed, Dead Letter. Dead Letter là hàng chờ tách biệt cho thông điệp thất bại cần xử lý có kiểm soát, không được xem là đã thành công.	Yêu cầu chỉ rõ API, event handoff, failure handling, retry và idempotency; trạng thái thông điệp là bằng chứng vận hành để phân biệt lỗi giao nhận với lỗi dữ liệu nghiệp vụ.	Project assumption; OpenAPI Specification 3.1.1 chỉ là nguồn chuẩn mô tả HTTP API, không tự quyết định kiến trúc tích hợp Nova Foods.	Ảnh hưởng đối soát liên hệ thống, cơ chế xử lý lỗi, nhật ký kỹ thuật, quyền truy cập dữ liệu truyền đi và kiểm thử tính không xử lý trùng.
Audit Log (Nhật ký kiểm toán)	Lưu dấu vết sự kiện với Recorded, Protected, Archived, Retention Disposition. Recorded ghi nhận sự kiện; Protected hạn chế sửa đổi/xóa trái phép; Archived chuyển sang lưu trữ; Retention Disposition chỉ được thực hiện theo chính sách đã được xác minh.	Yêu cầu auditability và sensitive-data handling đòi hỏi một thực thể độc lập cho bằng chứng ai làm gì, khi nào, trên đối tượng nào và kết quả ra sao.	Verification required cho thời hạn lưu, quyền truy cập, xóa/ẩn dữ liệu và mọi nghĩa vụ dữ liệu cá nhân; tham chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, cần Legal Owner/Security Owner xác minh.	Ảnh hưởng khả năng điều tra sự cố, kiểm tra phân tách nhiệm vụ, truy vết thay đổi, chi phí lưu trữ và rủi ro lộ dữ liệu nhạy cảm.

Quy tắc liên kết thực thể: mọi quy tắc canonical được soạn sau danh mục này phải nêu rõ Affected entities/states bằng đúng tên thực thể và trạng thái trong bảng, kèm quan hệ chuyển đổi nếu có. Ví dụ, một quyết định trên Approval: Approved có thể là điều kiện để xử lý tiếp một Receivable: Open, nhưng không được tự động đổi Receivable thành Settled; lý do là “được phê duyệt” và “đã thu đủ tiền” là hai sự kiện có bằng chứng khác nhau. Nếu cần thêm trạng thái, tác giả phải ghi nguồn, chủ sở hữu quyết định, tác động đến liên kết hiện có và nhãn Project assumption hoặc Verification required phù hợp, thay vì diễn giải trạng thái mới như quy định đã được chấp thuận.

Phân loại nguồn và nhãn xác minh cho nội dung pháp lý, kế toán và dữ liệu cá nhân

Nova Foods là bối cảnh ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp bằng VND, locale vi-VN và múi giờ Asia/Ho_Chi_Minh. Vì quy tắc pháp lý, kế toán và quyền riêng tư có thể tạo nghĩa vụ ngoài phạm vi học liệu, mỗi phát biểu thuộc ba lĩnh vực này phải mang một nhãn trạng thái tri thức: Sourced, Verification required hoặc Project assumption. Nhãn cho biết mức độ chứng cứ của phát biểu, không phải trạng thái tuân thủ, phê duyệt hay sẵn sàng production. Tại v0.9.0, Status IN_REVIEW, không nhãn nào được diễn giải là xác nhận của Legal Owner, Accounting Owner hoặc Privacy Owner.

Trường của schema quy tắc canonical	Cách ghi bắt buộc cho nội dung nhạy cảm
Rule ID	Mã duy nhất, ổn định trong catalog; không tái sử dụng mã khi nội dung thay đổi bản chất.
Rule statement	Nêu điều hệ thống hoặc artifact phải làm trong phạm vi mô phỏng; không khẳng định đây là nghĩa vụ pháp lý thực tế nếu chưa được xác minh.
Source classification	Ghi chính xác một trong ba giá trị: Sourced, Verification required, Project assumption.
Source reference	Với Sourced, nêu tên nguồn chính thức, cơ quan ban hành, URL và ngày truy cập 2026-08-07; không bịa số điều, khoản hoặc diễn giải vượt quá văn bản đã kiểm chứng.
Evidence/reasoning bridge	Nêu cầu nối từ nguồn đến quy tắc: nguồn nói về lĩnh vực nào, phần nào là suy luận thiết kế, và vì sao cần hoặc chưa thể áp dụng cho Nova Foods.
Authorized verifier	Chỉ định Legal Owner cho pháp lý/quyền riêng tư, Accounting Owner cho kế toán/hóa đơn; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì truy vết.
Change impact	Nêu artifact, dữ liệu, quy trình học liệu hoặc test basis phải xem xét lại khi nhãn, nguồn hoặc diễn giải thay đổi.

Rule ID	Quy tắc canonical	Phân loại nguồn và cầu nối chứng cứ	Đối tượng bị ảnh hưởng	Change impact
BR-FIN-051	Mọi quy tắc liên quan ghi nhận kế toán, số dư phải thu, hóa đơn hoặc chứng từ phải ghi rõ nhãn nguồn trước khi được dùng làm cơ sở thiết kế hoặc kiểm thử trong corpus.	Sourced — Luật Kế toán, Quốc hội, Luật 88/2015/QH13, và Nghị định 123/2020/NĐ-CP về hóa đơn, chứng từ, Chính phủ, là nguồn pháp lý chính thức. Cầu nối: nguồn xác lập lĩnh vực điều chỉnh; việc chuyển thành trường dữ liệu, luồng ERP hoặc bút toán Nova Foods vẫn cần Accounting Owner xác minh.	Invoice, Receivable, Report, Audit Log	Thay đổi nguồn hoặc diễn giải yêu cầu rà soát quy tắc tài chính liên quan, ví dụ dữ liệu tổng hợp trên Invoice và báo cáo mô phỏng bằng VND.
BR-FIN-052	Phát biểu nêu nghĩa vụ pháp lý, thời hạn lưu trữ, thuế, cách hạch toán, giá trị pháp lý của hóa đơn hoặc điều kiện tuân thủ phải mang nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh trên văn bản hiện hành.	Verification required — nguồn seed xác nhận Luật Kế toán và Nghị định 123/2020/NĐ-CP tồn tại, đồng thời nêu cần kiểm tra sửa đổi sau này trước khi dùng production. Cầu nối: chưa có văn bản xác minh theo tình huống Nova Foods, nên không đủ chứng cứ để biến thành yêu cầu bắt buộc.	Invoice, Receivable, Approval, Report	Không được dùng phát biểu này làm acceptance criterion hoặc kết luận compliance; khi được xác minh, cập nhật nhãn, nguồn và các liên kết rule-to-test.
BR-FIN-053	Mọi nội dung về dữ liệu cá nhân, quyền của chủ thể dữ liệu, đồng ý, chia sẻ, lưu giữ hoặc xử lý dữ liệu phải ghi nhãn riêng biệt, kể cả khi dữ liệu trong ví dụ là tổng hợp.	Sourced — Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn chính thức, hiệu lực từ 2026-01-01. Cầu nối: nguồn xác lập phạm vi pháp lý cần được xem xét; corpus chưa xác định dữ liệu, mục đích xử lý và vai trò pháp lý thực tế nên không suy ra cấu hình tuân thủ.	User Role, Audit Log, Integration Message, Report	Mọi thay đổi làm ví dụ tổng hợp có thể chứa định danh cá nhân phải kích hoạt rà soát phân loại dữ liệu và tham chiếu Legal Owner/Privacy Owner.
BR-FIN-054	Chi tiết thiết kế chỉ phục vụ học liệu, chưa được nguồn chính thức hoặc chủ sở hữu chuyên môn xác minh, phải mang nhãn Project assumption và mô tả ranh giới mô phỏng.	Project assumption — Nova Foods là case study giáo dục, chỉ sử dụng dữ liệu tổng hợp theo metadata của corpus. Cầu nối: đây là giả định phạm vi học liệu, không phải suy luận rằng một hệ thống thực tế được miễn nghĩa vụ pháp lý, kế toán hay quyền riêng tư.	Invoice, Receivable, Approval, Report, User Role, Integration Message, Audit Log	Nếu case study mở rộng sang dữ liệu thực, tích hợp thực hoặc vận hành production, giả định này không còn đủ; toàn bộ nội dung nhạy cảm phải được phân loại lại.

Tiêu chí chọn nhãn: dùng Sourced chỉ khi phát biểu giới hạn đúng điều có thể quy về nguồn chính thức đã liệt kê; dùng Verification required khi phát biểu đòi hỏi diễn giải pháp lý, kế toán hoặc quyền riêng tư theo tình huống cụ thể; dùng Project assumption khi phát biểu là lựa chọn mô phỏng của Nova Foods và không được trình bày như nghĩa vụ bên ngoài. Khi một quy tắc vừa dựa vào nguồn vừa chứa lựa chọn thiết kế, phần mô tả nguồn phải tách hai lớp: phần được dẫn nguồn là Sourced, còn phần lựa chọn thiết kế là Project assumption hoặc Verification required theo mức chứng cứ.

Traceability, Cross-File Checks, Self-Review, Open Issues, and Escalation Needs

Đối chiếu liên tệp với các artifact quản trị

Đối chiếu liên tệp (cross-file check) là việc so sánh cùng một thông tin quản trị giữa các tệp được kiểm soát để phát hiện sai khác trước khi thông tin đó được sử dụng làm đầu vào cho curriculum. Cách làm này cần thiết vì một quy tắc nghiệp vụ chỉ truy vết được khi định danh, phạm vi và nơi sử dụng của nó không mâu thuẫn giữa catalog quy tắc, registry định danh, manifest chapter và các artifact curriculum được tạo trong tương lai.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ, liên kết và dữ liệu đối chiếu chỉ dùng dữ liệu tổng hợp. Việc một liên kết vượt qua đối chiếu chỉ xác nhận tính nhất quán quản trị giữa artifact, không xác nhận tính đúng nghiệp vụ, hiệu lực pháp lý, tuân thủ, cấu hình ERP hay khả năng áp dụng production.

Đối tượng đối chiếu	Artifact nguồn kiểm soát	Trường phải so sánh	Quy tắc kiểm tra cụ thể	Bằng chứng và cầu nối suy luận
Định danh quy tắc nghiệp vụ	/01-curriculum/TRACEABILITY_ID_REGISTRY.md với Artifact ID TRACEABILITY_ID_REGISTRY	Rule ID, family/prefix, trạng thái đăng ký ID, quan hệ thay thế hoặc ngừng dùng nếu có	Mỗi Rule ID được catalog sử dụng phải khớp nguyên dạng với ID đã được registry quản trị; không tự đổi prefix, số thứ tự, cách viết hoa, dấu gạch nối hoặc tái sử dụng ID đã có nghĩa khác.	Registry được xác định là nguồn chuẩn duy nhất cho quản trị định danh. Vì vậy catalog chỉ được tham chiếu ID đã kiểm tra, thay vì tạo một biến thể ID cục bộ làm đứt quan hệ truy vết.
Danh tính artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md	Artifact ID, đường dẫn tệp, Status, Version, ngày, múi giờ, locale, bối cảnh Nova Foods	Tham chiếu đến hai artifact phải giữ nguyên TRACEABILITY_ID_REGISTRY, CHAPTER_MANIFEST, đường dẫn canonical, IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN và VND.	Metadata của cả hai artifact xác định rõ danh tính quản trị tại thời điểm kiểm soát. Sai khác metadata làm người đọc có thể đối chiếu nhầm phiên bản hoặc nhầm nguồn, nên phải được ghi nhận là sai lệch liên tệp.
Phạm vi chapter nhận quy tắc	/01-curriculum/CHAPTER_MANIFEST.md với Artifact ID CHAPTER_MANIFEST	Chapter filename, chapter index, phạm vi chapter, dependency dự kiến	Một quy tắc chỉ được liên kết tới chapter filename nằm trong tập 26 handbook chapter được manifest quản trị, từ 00-foundations.md đến 25-ai-assisted-ba-workflow.md; không tự tạo filename ngoài tập này.	Manifest quy định chính xác biên 26 tệp. Vì catalog dùng chapter như điểm đến của traceability, liên kết tới tệp ngoài biên sẽ không có căn cứ quản trị trong corpus.
Liên kết tới artifact curriculum tương lai	Catalog quy tắc và các artifact curriculum được tạo sau này trong phạm vi manifest	Rule ID, filename đích, loại artifact, mục đích sử dụng, trạng thái liên kết	Artifact tương lai muốn tham chiếu quy tắc phải dùng Rule ID canonical từ registry và filename canonical từ manifest. Nếu artifact chưa tồn tại, liên kết chỉ được ghi là quan hệ dự kiến, không được trình bày như bằng chứng artifact đã hoàn thành.	Registry quản trị ID, còn manifest quản trị tập filename. Khi cả hai điều kiện cùng đúng, liên kết dự kiến có thể được truy vết mà không suy diễn rằng nội dung chapter hay test artifact đã tồn tại.
Phân loại nguồn của quy tắc	Catalog quy tắc, nguồn gốc được ghi trong artifact curriculum tương lai và verified primary-source seed	Sourced, Verification required, Project assumption, URL hoặc tham chiếu nguồn đã được phép dùng	Nhãn phân loại nguồn phải được giữ nguyên khi quy tắc được trích dẫn sang artifact khác. Một artifact không được nâng Verification required hoặc Project assumption thành kết luận đã xác minh chỉ vì Rule ID đã được đăng ký.	ID xác nhận danh tính, không xác nhận tính đúng của nội dung. Do đó, nhãn nguồn phải đi cùng quy tắc để người học phân biệt được sự kiện có nguồn, điểm cần xác minh và giả định mô phỏng.

Trình tự đối chiếu bắt buộc cho từng liên kết quy tắc

Bước	Thao tác	Điều kiện đạt	Xử lý khi sai khác
1	Đọc Rule ID và phạm vi rule từ catalog dự kiến.	ID có một dạng văn bản rõ ràng, không bị cắt ngắn hoặc đổi định dạng.	Không tạo liên kết liên tệp cho đến khi dạng ID được đối chiếu với registry.
2	Tra ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	ID, family/prefix và ý nghĩa quản trị không mâu thuẫn với registry.	Giữ nguyên sai khác như một điểm cần phân giải; không tự sửa registry hoặc catalog theo suy đoán.
3	Tra filename chapter hoặc artifact đích trong /01-curriculum/CHAPTER_MANIFEST.md.	Filename thuộc tập 26 chapter được kiểm soát hoặc là artifact curriculum có quan hệ được manifest cho phép.	Loại bỏ liên kết ngoài phạm vi khỏi bản đối chiếu; không tạo tệp mới để hợp thức hóa liên kết.
4	So sánh metadata ngữ cảnh.	Tham chiếu vẫn nhất quán với IN_REVIEW, v0.9.0, 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND và bối cảnh Nova Foods mô phỏng.	Gắn sai khác là lỗi quản trị phiên bản hoặc ngữ cảnh, không diễn giải thành thay đổi nội dung nghiệp vụ.
5	Kiểm tra nhãn nguồn đi kèm quy tắc khi nó xuất hiện ở artifact tương lai.	Nhãn Sourced, Verification required hoặc Project assumption được bảo toàn đúng theo bằng chứng đã ghi.	Không cho phép artifact đích làm mạnh hơn mức chứng cứ của artifact nguồn.

Ranh giới kiểm soát: TRACEABILITY_ID_REGISTRY quản trị định danh; CHAPTER_MANIFEST quản trị danh mục và tên tệp chapter; catalog quy tắc nghiệp vụ quản trị nội dung quy tắc và liên kết dự kiến. Không artifact nào trong ba loại này tự thay thế phạm vi của artifact khác. Sự tách biệt này bảo đảm một Rule ID hợp lệ không bị hiểu nhầm là một yêu cầu đã xác minh, một filename hợp lệ không bị hiểu nhầm là nội dung chapter đã tồn tại, và một liên kết dự kiến không bị hiểu nhầm là bằng chứng triển khai.

Danh sách tự rà soát tính toàn vẹn của từng quy tắc canonical

Tự rà soát (self-review) là bước người soạn tự kiểm tra nội dung trước khi chuyển catalog sang vòng xem xét; bước này phát hiện lỗi cấu trúc và phạm vi, không thay thế xác minh chuyên môn hay phê duyệt. Áp dụng cho catalog quy tắc nghiệp vụ của Nova Foods Trading & Manufacturing, là bối cảnh mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp, theo vi-VN, Asia/Ho_Chi_Minh và VND.

Điểm kiểm tra	Tiêu chí đạt bắt buộc	Cách phát hiện lỗi	Xử lý khi không đạt
Đủ trường định danh	Mỗi quy tắc có một ID canonical, tên ngắn, mô tả quy tắc và vị trí section sở hữu. ID phải được ghi nguyên dạng, không tự đổi tiền tố, số thứ tự hoặc kiểu chữ.	Lọc các dòng thiếu một trong bốn trường; đối chiếu tên với nội dung để phát hiện tên không phản ánh quy tắc.	Giữ quy tắc ở trạng thái chưa hoàn tất; không tạo ID thay thế tùy ý.
Đủ logic nghiệp vụ	Mỗi quy tắc nêu rõ điều kiện kích hoạt, đối tượng áp dụng, hành vi hoặc kết quả bắt buộc, và ngoại lệ nếu ngoại lệ tồn tại. “Nếu có điều kiện X thì hệ thống/người dùng phải thực hiện Y” là cấu trúc tối thiểu để kiểm tra được.	Đánh dấu câu chỉ nêu mong muốn chung như “quản lý tốt tồn kho” vì không có điều kiện và kết quả xác định.	Viết lại thành phát biểu đơn nghĩa; tách thành nhiều quy tắc nếu có nhiều điều kiện độc lập.
Đủ căn cứ nguồn	Mỗi quy tắc ghi nguồn, phân loại nguồn và ranh giới diễn giải. Nội dung chưa được xác minh phải giữ đúng nhãn Verification required hoặc Project assumption; không được chuyển nhãn chỉ vì câu văn đã hoàn chỉnh.	Kiểm tra dòng không có nguồn, không có nhãn, hoặc suy diễn chi tiết pháp lý, kế toán, thuế, bảo mật, dữ liệu cá nhân hay an toàn thực phẩm vượt quá nguồn.	Giữ nhãn hiện có và nêu rõ giới hạn; không biến giả định thành sự kiện.
Đủ trách nhiệm và biên áp dụng	Mỗi quy tắc xác định vai trò hoặc thành phần chịu tác động, thời điểm áp dụng và giới hạn không áp dụng. Điều này ngăn một quy tắc bán hàng bị hiểu nhầm là quy tắc kho hoặc tài chính.	Tìm các câu dùng chủ ngữ mơ hồ như “bộ phận liên quan” hoặc phạm vi bao trùm nhiều quy trình không phân biệt.	Chỉ rõ vai trò, đối tượng và biên quy trình; tách quy tắc khi trách nhiệm khác nhau.
Duy nhất ID	Một ID chỉ đại diện cho một quy tắc có một ý nghĩa ổn định. Không dùng lại ID cho biến thể, ví dụ minh họa, ngoại lệ hoặc quy tắc đã viết lại.	Sắp xếp theo ID để tìm trùng hoàn toàn; so sánh các ID gần giống có thể gây nhầm như khác ký tự hoặc số thứ tự.	Giữ ID đã được ghi nhận cho đúng một ý nghĩa; chuyển nội dung còn lại thành quy tắc riêng với định danh được quản trị.
Không chồng lấn section	Mỗi quy tắc có đúng một section sở hữu theo chủ đề quyết định chính. Section khác chỉ được tham chiếu khi chịu ảnh hưởng, không sao chép toàn bộ quy tắc.	So sánh điều kiện, kết quả và đối tượng của các quy tắc giữa section; hai quy tắc cùng bắt buộc một quyết định trong cùng ngữ cảnh là dấu hiệu chồng lấn.	Chọn section sở hữu theo nơi quyết định nghiệp vụ phát sinh; để lại tham chiếu ngắn tại section bị ảnh hưởng.
Không mâu thuẫn nội bộ	Điều kiện giống nhau không được dẫn tới hai kết quả trái ngược; ngoại lệ không được phủ định quy tắc chính mà không nêu điều kiện ưu tiên.	Đặt các quy tắc cùng đối tượng và cùng sự kiện cạnh nhau, sau đó kiểm tra kết quả bắt buộc.	Làm rõ thứ tự ưu tiên hoặc điều kiện phân nhánh; không tự chọn chính sách nghiệp vụ khi thiếu căn cứ.

Nguyên tắc phân biệt chồng lấn là: hai quy tắc được xem là trùng về nội dung khi chúng có cùng đối tượng, cùng điều kiện kích hoạt và cùng kết quả phải thực hiện, dù diễn đạt bằng từ khác nhau. Hai quy tắc không trùng khi một quy tắc quyết định chính sách và quy tắc kia chỉ xác định cách áp dụng chính sách đó trong một trạng thái khác, với điều kiện và kết quả được phân biệt rõ.

Ví dụ mô phỏng: quy tắc “không cho xuất kho lô đã hết hạn” thuộc phạm vi kiểm soát kho và hạn dùng; một câu ở phạm vi bán hàng chỉ nên tham chiếu hạn chế này khi đơn hàng yêu cầu giữ hàng. Không được sao chép lại quy tắc xuất kho dưới một ID khác, vì việc sao chép tạo hai nguồn diễn giải có thể lệch nhau khi sửa đổi.

Kết quả tự rà soát chỉ được ghi là Pass, Needs correction hoặc Verification required cho từng dòng quy tắc. Tại v0.9.0, trạng thái corpus là IN_REVIEW; kết quả Pass chỉ xác nhận rằng dòng đã qua kiểm tra cấu trúc theo danh sách này, không xác lập baseline, không ngụ ý approval và không xác nhận quy tắc sẵn sàng áp dụng thực tế.

Kiểm tra độ bao phủ tối thiểu từ Quy tắc Nghiệp vụ đến Nhu cầu, Yêu cầu, Trạng thái và Kiểm thử

Mỗi quy tắc nghiệp vụ (business rule) trong catalog hoàn chỉnh phải có chuỗi truy vết tối thiểu gồm: ít nhất một nhu cầu (need), một yêu cầu (requirement), một thực thể hoặc trạng thái bị ảnh hưởng, và một hàm ý kiểm thử (test implication). Nhu cầu giải thích vấn đề hoặc kết quả nghiệp vụ cần đạt; yêu cầu mô tả hành vi, ràng buộc hoặc thông tin hệ thống phải đáp ứng; thực thể/trạng thái xác định đối tượng ERP chịu tác động; hàm ý kiểm thử xác định điều gì phải quan sát được để kiểm tra quy tắc. Chuỗi này cần thiết vì một câu quy tắc có thể đúng về mặt diễn đạt nhưng không thể thiết kế, vận hành hoặc kiểm tra nếu không chỉ ra mục đích, điểm tác động và kết quả mong đợi.

Thành phần bắt buộc	Nội dung phải ghi cho mỗi business rule	Tiêu chí đạt	Lý do kiểm tra
Business Rule ID	Một ID canonical đã được đăng ký theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID xuất hiện đúng nguyên dạng, thuộc đúng family và không được dùng lại cho quy tắc khác	ID là khóa liên kết; thiếu hoặc sai ID làm quan hệ truy vết không xác định được đối tượng cần kiểm tra
Need	ID và mô tả ngắn của nhu cầu nghiệp vụ mà quy tắc phục vụ	Có ít nhất một need nêu rõ kết quả cần bảo vệ hoặc vấn đề cần kiểm soát	Quy tắc không liên kết need có nguy cơ là chi tiết kỹ thuật hoặc giả định không có mục tiêu nghiệp vụ
Requirement	ID yêu cầu liên quan và loại quan hệ: thực thi, ràng buộc, tính toán, kiểm soát hoặc ngoại lệ	Có ít nhất một requirement diễn đạt được hành vi hay điều kiện có thể xác minh	Need cho biết “vì sao”; requirement cho biết hệ thống hoặc quy trình “phải làm gì”
Affected entity/state	Tên thực thể, thuộc tính quan trọng, trạng thái trước và trạng thái sau nếu có chuyển trạng thái	Có tối thiểu một thực thể hoặc một trạng thái xác định; nếu rule không đổi trạng thái, phải ghi rõ đây là rule kiểm soát dữ liệu hoặc tính toán	ERP xử lý dữ liệu và vòng đời đối tượng; không xác định điểm tác động thì không đánh giá được phạm vi thực thi
Test implication	Điều kiện kiểm thử dự kiến, dữ liệu tổng hợp, hành động, kết quả quan sát được và trường hợp biên hoặc ngoại lệ nếu rule có điều kiện	Có ít nhất một kết quả mong đợi có thể quan sát hoặc đối chiếu	Theo tư duy kiểm thử hộp đen của ISTQB CTFL, quy tắc cần tạo được điều kiện và kết quả kiểm tra, không chỉ là diễn giải chủ quan
Evidence/reasoning bridge	Liên kết từ nguồn hoặc giả định đến cách diễn giải rule, sau đó đến need, requirement, entity/state và test implication	Không nhảy trực tiếp từ nguồn sang test mà thiếu giải thích rule áp dụng như thế nào	Cầu nối lập luận giúp reviewer phân biệt nội dung được nguồn hỗ trợ với suy luận dự án

Việc kiểm tra được thực hiện theo hướng xuôi và ngược. Hướng xuôi bắt đầu từ Business Rule ID, lần lượt xác nhận có liên kết đến need, requirement, entity/state và test implication. Hướng ngược bắt đầu từ một requirement hoặc điều kiện kiểm thử, xác nhận nó quy về ít nhất một business rule đã đăng ký, thay vì tạo ra hành vi không có căn cứ nghiệp vụ. Hai hướng phải cho cùng kết quả về ID và phạm vi; nếu khác nhau, bản ghi chưa đạt vì liên kết có thể bị thiếu, nhầm ID hoặc diễn giải không nhất quán.

Quy tắc quyết định	Cách áp dụng trong catalog
Một rule có thể phục vụ nhiều need hoặc requirement	Được phép ghi nhiều liên kết, nhưng từng liên kết phải nêu loại quan hệ và lý do; không gom các liên kết khác mục đích vào một mô tả mơ hồ
Một requirement có thể thực thi nhiều rule	Được phép khi requirement là điểm kiểm soát chung, nhưng phải chỉ ra rule nào áp dụng cho điều kiện nào để tránh suy diễn mọi rule đều luôn có hiệu lực
Một rule không có trạng thái chuyển tiếp	Vẫn đạt nếu xác định được thực thể và thuộc tính bị kiểm soát, chẳng hạn giá trị, ngày hiệu lực, quyền xử lý hoặc điều kiện hợp lệ
Một rule không tạo được test implication quan sát được	Chưa đạt coverage; phải làm rõ outcome, điều kiện đầu vào hoặc evidence dự kiến trước khi coi rule là có thể kiểm tra
Rule dựa trên pháp lý, kế toán, thuế, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật	Liên kết phải giữ phân loại nguồn và nhãn Verification required hoặc Project assumption khi chưa có xác minh phù hợp; không suy diễn rằng liên kết traceability đã xác nhận hiệu lực chuyên môn

Bảng coverage của catalog phải coi một hàng business rule là hoàn chỉnh chỉ khi tất cả năm cột liên kết bắt buộc đều có giá trị xác định: Business Rule ID, Need ID, Requirement ID, Affected Entity/State, và Test Implication. “Nhiều hơn một” không thay thế cho “ít nhất một”: ví dụ, nhiều requirement nhưng không có entity/state vẫn không xác định được nơi quy tắc tác động; nhiều test case dự kiến nhưng không có need vẫn không chứng minh được giá trị nghiệp vụ. Mọi scenario Nova Foods Trading & Manufacturing dùng để diễn giải các liên kết này là mô phỏng giáo dục và chỉ sử dụng dữ liệu tổng hợp bằng bối cảnh vi-VN, Asia/Ho_Chi_Minh và VND.

Kế hoạch phân tích tác động và lan truyền khi cập nhật quy tắc canonical

Phân tích tác động thay đổi (change-impact analysis) là việc xác định có kiểm soát mọi nội dung phải được xem xét hoặc cập nhật khi một quy tắc nghiệp vụ canonical thay đổi. Cơ sở của kế hoạch này là một quy tắc không đứng độc lập: quy tắc có thể ảnh hưởng đến nhu cầu nghiệp vụ, yêu cầu, thực thể ERP, trạng thái xử lý, kịch bản Nova Foods mô phỏng, tiêu chí chấp nhận và học liệu dự kiến. Vì vậy, thay đổi chỉ được ghi là “cục bộ” khi bằng chứng truy vết cho thấy không có liên kết đi ra ngoài chính bản ghi quy tắc; không được kết luận theo cảm tính.

Bước kiểm soát	Thực hiện bắt buộc	Bằng chứng hoặc đầu ra cần ghi nhận	Ranh giới thẩm quyền
1. Đăng ký yêu cầu thay đổi	Ghi nhận ID quy tắc canonical, loại thay đổi, lý do, nguồn kích hoạt, ngày theo Asia/Ho_Chi_Minh và người ghi nhận.	Mã thay đổi, ID quy tắc, mô tả trước và sau thay đổi, phân loại Verified source, Project assumption hoặc Verification required.	Principal IT Business Analyst / Technical Curriculum Author quản trị hồ sơ, không tự xác nhận hiệu lực chuyên môn.
2. Phân loại mức tác động	Xác định thay đổi thuộc ngữ nghĩa nghiệp vụ, điều kiện kích hoạt, ngoại lệ, dữ liệu, trạng thái, vai trò, tích hợp, kiểm thử hay thuật ngữ. Một thay đổi có nhiều loại phải được đánh dấu đủ các loại.	Danh sách loại tác động và lập luận nối từ trường quy tắc bị đổi đến thành phần bị ảnh hưởng.	Không diễn giải pháp lý, kế toán, bảo mật hoặc kiến trúc ngoài nguồn và thẩm quyền phù hợp.
3. Lập bản đồ lan truyền	Theo các liên kết đã ghi từ quy tắc đến need, requirement, entity, state, test implication và artifact curriculum tương lai.	Danh sách artifact, ID liên quan, loại liên kết, hành động cần thực hiện và trạng thái xử lý tác động.	Chỉ dùng đường dẫn canonical và ID đã được registry quản trị.
4. Quyết định xử lý	Mỗi mục bị ảnh hưởng phải được gán một hành động: Cập nhật, Xác minh lại, Ngừng sử dụng liên kết, hoặc Không tác động kèm lý do.	Quyết định từng mục, lý do có thể kiểm tra và người chịu trách nhiệm thực hiện.	Không tác động phải có bằng chứng; không được dùng để bỏ qua tác động chưa phân tích.
5. Ghi nhận phiên bản	Tạo bản ghi thay đổi mới, bảo toàn lịch sử phiên bản trước và liên kết tới các cập nhật lan truyền.	Version, ngày, trạng thái thực tế, phạm vi ảnh hưởng và liên kết thay đổi.	IN_REVIEW tại v0.9.0 không tạo baseline, approval hoặc quyền dùng production.

Ma trận lan truyền dưới đây quy định phạm vi tối thiểu phải xem xét. TRACEABILITY_ID_REGISTRY là nguồn chuẩn duy nhất cho quản trị định danh; /01-curriculum/CHAPTER_MANIFEST.md là nguồn kiểm soát danh mục và tên tệp chapter. Hai artifact này xác định nhận diện và cấu trúc, không tự xác nhận nội dung quy tắc là đúng hoặc đã được phê duyệt.

Thành phần bị thay đổi trong quy tắc	Tác động cần phân tích	Đối tượng nhận lan truyền	Hành động tối thiểu
ID quy tắc hoặc family ID	Nguy cơ đứt liên kết, trùng namespace, hoặc tham chiếu nhầm quy tắc khác.	TRACEABILITY_ID_REGISTRY, bảng truy vết, requirement, test artifact và học liệu tương lai.	Không đổi ID chỉ để diễn đạt lại; nếu bắt buộc đổi, giữ liên kết từ ID cũ sang ID mới và cập nhật toàn bộ tham chiếu.
Điều kiện kích hoạt hoặc điều kiện chặn	Thay đổi thời điểm quy tắc được áp dụng và kết quả mong đợi.	Need, requirement, entity/state, acceptance criterion, kịch bản và test case tương lai.	Cập nhật điều kiện đầu vào, điều kiện biên, ngoại lệ và expected result tương ứng.
Thực thể, trường dữ liệu hoặc trạng thái	Có thể thay đổi dữ liệu bắt buộc, chuyển trạng thái hoặc quyền xử lý.	Mô hình dữ liệu, state model, giao diện, API hoặc tài liệu kiến trúc tương lai.	Đánh dấu Verification required nếu tác động cần xác minh kiến trúc, bảo mật, pháp lý hoặc vận hành.
Nguồn, giả định hoặc mức độ xác minh	Có thể làm thay đổi độ tin cậy và cách diễn giải của quy tắc.	Canonical rule catalog, ghi chú học liệu, requirement và test basis tương lai.	Giữ nguyên phân loại nguồn; không nâng Project assumption thành quy định xác thực nếu chưa có nguồn và vai trò có thẩm quyền.
Thuật ngữ Nova Foods mô phỏng	Có thể gây lệch nghĩa giữa các chapter và kịch bản học tập.	CHAPTER_MANIFEST, chapter tương lai và glossary tương lai nếu được lập.	Đồng bộ cách gọi, nhưng không tạo thêm định nghĩa vận hành thực tế cho Nova Foods.

Ví dụ mô phỏng: nếu quy tắc BR-INV-001 được thay đổi ở điều kiện chặn của trạng thái tồn kho, người thực hiện không chỉ sửa câu chữ của quy tắc. Lý do là điều kiện chặn quyết định khi giao dịch được phép tiếp tục; do đó cần truy ngược các requirement mô tả hành vi, entity/state biểu diễn tồn kho, kịch bản Nova Foods dùng dữ liệu tổng hợp và test implication kiểm tra kết quả bị chặn hoặc được phép. Nếu phát hiện quy tắc này ảnh hưởng đến định giá, hóa đơn, bút toán, dữ liệu cá nhân, truy xuất nguồn gốc thực phẩm hoặc quyền truy cập, thay đổi phải giữ nhãn Verification required cho đến khi nguồn chính thức và vai trò chuyên môn phù hợp xác minh diễn giải.

Quy tắc lan truyền cốt lõi là: một cập nhật canonical chỉ được coi là đã xử lý về mặt quản trị khi từng liên kết bị ảnh hưởng có hành động và bằng chứng tương ứng; việc sửa một artifact đích không thay thế việc đánh giá các artifact đích khác. Mọi ví dụ, kịch bản và giá trị tiền tệ VND trong kế hoạch này thuộc Nova Foods Trading & Manufacturing mô phỏng giáo dục và chỉ sử dụng dữ liệu tổng hợp.

Danh mục vấn đề mở về xác minh nguồn, khoảng trống thẩm quyền và giả định

Vấn đề mở là điểm mà bằng chứng hiện có chưa đủ để ghi một quy tắc nghiệp vụ canonical như một kết luận xác thực. Danh mục này chỉ áp dụng cho Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, sử dụng dữ liệu tổng hợp; vì vậy, một giả định giúp minh họa học tập không được diễn giải thành chính sách vận hành thực tế, nghĩa vụ pháp lý hoặc cấu hình ERP thực tế.

Mỗi vấn đề mở phải được ghi cùng quy tắc liên quan khi catalog được hoàn thiện. Cầu nối suy luận là: nguồn chính thức chỉ xác nhận phạm vi hoặc trạng thái pháp lý/tiêu chuẩn ở mức đã kiểm chứng; nếu chưa có văn bản đầy đủ, diễn giải của chủ thể có thẩm quyền, hoặc quyết định nghiệp vụ mô phỏng được ghi nhận, BA không có căn cứ để chuyển nội dung đó thành quy tắc bắt buộc. Khi đó nội dung phải giữ nhãn Verification required hoặc Project assumption.

Open Issue ID	Loại vấn đề	Nội dung chưa thể kết luận	Bằng chứng và cầu nối suy luận	Nhãn bắt buộc trong catalog	Điều kiện đóng vấn đề
OI-CBR-001	Xác minh nguồn pháp lý	Diễn giải chi tiết nghĩa vụ bảo vệ dữ liệu cá nhân trong các quy tắc khách hàng, nhân sự, phân quyền hoặc nhật ký truy cập.	Đã có nguồn chính thức cho Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, nhưng seed không chứa toàn văn điều khoản hoặc kết luận áp dụng cho tình huống Nova Foods mô phỏng. Vì thiếu cầu nối từ văn bản hiện hành đến yêu cầu hệ thống cụ thể, không được suy ra nghĩa vụ chi tiết.	Verification required	Có diễn giải bằng văn bản từ vai trò pháp lý có thẩm quyền, nêu rõ phạm vi áp dụng cho nội dung học liệu.
OI-CBR-002	Khoảng trống thẩm quyền kế toán	Quy tắc về thời điểm ghi nhận doanh thu, giá vốn, bút toán, khóa kỳ, thuế hoặc xử lý hóa đơn.	Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP là nguồn chính thức được nêu, nhưng seed quy định rõ rằng diễn giải kế toán và kiểm tra sửa đổi sau này cần vai trò được ủy quyền. BA không có thẩm quyền biến ví dụ dòng tiền VND thành kết luận hạch toán.	Verification required	Có quyết định diễn giải phạm vi học liệu từ Accounting Owner và, khi cần, xác minh pháp lý.
OI-CBR-003	Xác minh nguồn an toàn thực phẩm	Điều kiện pháp lý cụ thể cho truy xuất nguồn gốc, thu hồi, quản lý lô/batch và hạn dùng.	Luật An toàn thực phẩm 55/2010/QH12 cung cấp bối cảnh nguồn chính thức, nhưng seed yêu cầu xác minh bởi domain owner và Legal. Vì chưa có bằng chứng về yêu cầu áp dụng chi tiết, catalog chỉ có thể nêu quy tắc mô phỏng nếu được gắn nhãn phù hợp.	Verification required	Có xác minh nguồn hiện hành và diễn giải của Legal cùng Business Owner phụ trách nghiệp vụ chất lượng/an toàn thực phẩm.
OI-CBR-004	Giả định nghiệp vụ	Chính sách mô phỏng về ngưỡng tín dụng, mức chiết khấu, quyền duyệt hoàn tiền, quy tắc phân bổ tồn kho hoặc ưu tiên xuất hàng.	Không có nguồn Nova Foods thực tế vì Nova Foods là mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp. Do đó mọi con số, ngưỡng và thứ tự ưu tiên chỉ là lựa chọn thiết kế tình huống học tập, không phải fact nghiệp vụ.	Project assumption	Business Owner xác nhận lựa chọn mô phỏng, phạm vi sử dụng học liệu và ngoại lệ được phép minh họa.
OI-CBR-005	Khoảng trống thẩm quyền bảo mật	Mức phân quyền, thời hạn lưu log, bảo vệ API, phân loại dữ liệu và cách che giấu dữ liệu nhạy cảm trong ví dụ ERP.	OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là chuẩn thực hành/nguyên tắc nhận biết rủi ro, không phải luật Việt Nam hoặc quyết định kiến trúc Nova Foods. Vì vậy không thể tự suy ra cấu hình kiểm soát cụ thể.	Verification required	Security Owner xác định kiểm soát phù hợp cho corpus; Architect xác nhận khả năng áp dụng nếu nội dung chạm đến thiết kế kỹ thuật.
OI-CBR-006	Xác minh chuẩn chuyên môn có giới hạn truy cập	Trích dẫn chính xác điều khoản từ BABOK Guide hoặc ISO/IEC/IEEE 29148.	Seed chỉ cho phép sử dụng overview, errata, abstract và bibliographic status; toàn văn có thể yêu cầu quyền truy cập. Suy ra rằng không được gán số trang, điều khoản, câu chữ hoặc nghĩa chi tiết chưa kiểm chứng trực tiếp.	Verification required	Có quyền truy cập nguồn được cấp phép và bản đối chiếu chỉ rõ nội dung được dùng trong học liệu.
OI-CBR-007	Giả định kỹ thuật	Cơ chế tích hợp, định dạng API, mã lỗi, đồng bộ dữ liệu và ownership của hệ thống ngoài ERP.	OpenAPI Specification 3.1.1 chỉ chuẩn hóa cách mô tả HTTP API; nó không cung cấp interface thực tế của Nova Foods. Không có hợp đồng tích hợp hoặc quyết định kiến trúc trong nguồn đầu vào, nên không được trình bày endpoint hay hành vi kỹ thuật như sự thật.	Project assumption	Architect xác định ranh giới kỹ thuật mô phỏng và artifact interface phù hợp.
OI-CBR-008	Xác minh kiểm thử	Bằng chứng kiểm thử chứng minh quy tắc có thể quan sát và đánh giá được.	ISTQB CTFL v4.0.1 cung cấp thuật ngữ kiểm thử và kỹ thuật hộp đen, nhưng không tự tạo acceptance criterion cho từng quy tắc Nova Foods. Nếu quy tắc chưa có kết quả mong đợi đo được, tính kiểm thử vẫn chưa được chứng minh.	Verification required	QA Reviewer xác nhận điều kiện kiểm thử, dữ liệu tổng hợp, kết quả mong đợi và evidence dự kiến.

Quy tắc xử lý: Verification required không được viết lại thành kết luận chắc chắn chỉ vì nguồn có tên chính thức; Project assumption không được đổi thành chính sách Nova Foods chỉ vì ví dụ được lặp lại ở nhiều artifact. Khi điều kiện đóng chưa có bằng chứng phù hợp, vấn đề mở phải giữ nguyên ID, nhãn và lý do để tránh làm mất dấu rủi ro thẩm quyền trong quá trình phát triển catalog.

Ngưỡng Escalation Khi Quy Tắc Vượt Thẩm Quyền BA

Escalation (chuyển vấn đề để vai trò có thẩm quyền quyết định hoặc xác minh) là bắt buộc khi Business Analyst (BA) chỉ có thể mô tả quy tắc, nhưng không có quyền xác nhận tính hợp pháp, cách hạch toán, mức kiểm soát bảo mật, quyết định vận hành, tính khả thi kiến trúc hoặc khả năng kiểm thử. Cơ sở là /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md đều xác định Owner chỉ quản trị artifact ở trạng thái IN_REVIEW, không thay thế thẩm quyền chuyên môn. Vì vậy, BA phải giữ nguyên nhãn Verification required hoặc Project assumption cho nội dung chưa có kết luận từ đúng vai trò.

Vai trò nhận escalation	Điều kiện kích hoạt cụ thể	Cầu nối bằng chứng và lý do	Gói thông tin BA phải chuyển
Legal	Quy tắc được diễn giải từ pháp luật về dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, hóa đơn hoặc nghĩa vụ khác.	Các nguồn Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 là nguồn pháp lý chính thức, nhưng seed chỉ cho phép sử dụng trong ranh giới đã xác minh; BA không được suy diễn điều khoản chi tiết.	Quy tắc dự kiến, nguồn chính thức, ngày truy cập 2026-08-07, tình huống Nova Foods mô phỏng, diễn giải đang dùng, câu hỏi pháp lý đơn nghĩa và nhãn Verification required.
Accounting	Quy tắc tác động bút toán, doanh thu, giá vốn, thuế, kỳ kế toán, đối soát, chứng từ hoặc hóa đơn bằng VND.	Luật Kế toán là nguồn pháp lý, đồng thời seed quy định diễn giải kế toán cần vai trò được ủy quyền; do đó BA không thể tự xác nhận cách hạch toán ERP.	Luồng nghiệp vụ mô phỏng, sự kiện kích hoạt, chứng từ dự kiến, giá trị dữ liệu tổng hợp, giả định hiện tại, tác động nếu chọn từng phương án và câu hỏi cần xác nhận.
Security	Quy tắc quy định quyền truy cập, dữ liệu cá nhân, API, nhật ký, secret, phân quyền hoặc bảo vệ dữ liệu.	OWASP ASVS 5.0.0 và OWASP API Security Top 10:2023 là chuẩn thực hành an ninh, không phải luật Việt Nam; yêu cầu pháp lý về dữ liệu cá nhân vẫn cần Legal xác minh. BA cần Security xác định kiểm soát kỹ thuật phù hợp.	Loại dữ liệu, actor, quyền dự kiến, điểm truy cập, rủi ro, tham chiếu nguồn, tác động học liệu và yêu cầu không đưa dữ liệu thực vào Nova Foods mô phỏng.
Business Owner	Quy tắc chọn chính sách bán hàng, ngoại lệ đơn hàng, ưu tiên giao hàng, xử lý hàng hết hạn, mức chấp nhận rủi ro vận hành hoặc mục tiêu nghiệp vụ.	BA có thể phân tích lựa chọn và tác động, nhưng Business Owner sở hữu quyết định nghiệp vụ. Không có owner xác nhận thì quy tắc chỉ là giả định học tập.	Scenario Nova Foods, các phương án, tác động tới người dùng và quy trình, giả định, tiêu chí quyết định, câu hỏi lựa chọn một nghĩa.
Architect	Quy tắc buộc chọn kiến trúc, ranh giới dịch vụ, mô hình dữ liệu, tích hợp ERP, giao thức API, hiệu năng hoặc tính sẵn sàng.	OpenAPI Specification 3.1.1 mô tả HTTP API, nhưng không tự quyết định kiến trúc Nova Foods; BA không được biến mô tả nghiệp vụ thành quyết định kỹ thuật.	Quy tắc nghiệp vụ, entity hoặc state bị ảnh hưởng, interface dự kiến, phụ thuộc, rủi ro kỹ thuật, phương án và điểm cần kiến trúc xác nhận.
QA Reviewer	Quy tắc không có kết quả quan sát được, điều kiện biên, xử lý lỗi hoặc bằng chứng kiểm thử; hoặc mâu thuẫn giữa kết quả kỳ vọng và ngoại lệ.	ISTQB CTFL v4.0.1 là nguồn thuật ngữ kiểm thử; BA viết test basis nhưng QA xác định khả năng kiểm thử và evidence phù hợp.	Quy tắc, tiền điều kiện, dữ liệu tổng hợp, kết quả kỳ vọng, ngoại lệ, tiêu chí pass/fail và lý do chưa thể kiểm thử.

BA phải escalation đồng thời đến tất cả vai trò liên quan khi một quy tắc có nhiều bản chất, ví dụ quy tắc lưu dữ liệu hóa đơn có thể cần Accounting, Legal, Security và Architect. BA được phép ghi nhận vấn đề, phân tích tác động và điều phối câu hỏi; BA không được tự đóng vấn đề bằng kết luận thay cho chuyên gia. Mọi kết luận nhận được trong giai đoạn này chỉ là đầu vào để xem xét tiếp theo, không tạo baseline, approval hay quyền triển khai cho Nova Foods.

Tuyên bố ranh giới trước soạn thảo, baseline và phê duyệt

Tại thời điểm 2026-08-07 theo múi giờ Asia/Ho_Chi_Minh, đầu ra lập kế hoạch của CANONICAL_BUSINESS_RULES.md chỉ xác định cách chuẩn bị cho Danh mục Quy tắc Nghiệp vụ Chuẩn của Nova Foods Trading & Manufacturing, là case study mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp. Không phần nào trong sáu phần của tài liệu này được phép chuyển sang trạng thái soạn thảo nội dung quy tắc, bao gồm việc viết rule statement, điều kiện áp dụng, ngoại lệ, quyết định nghiệp vụ hoặc ví dụ vận hành. Cơ sở cho ranh giới này là các artifact nguồn /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CHAPTER_MANIFEST.md đều mang trạng thái IN_REVIEW, phiên bản v0.9.0, đồng thời ghi rõ đây là planning artifact trước drafting; vì vậy, kế hoạch không phải là nội dung catalog đã được xác minh.

Hạng mục	Diễn giải bắt buộc trong micro-batch lập kế hoạch	Diễn giải bị cấm
Trạng thái	IN_REVIEW nghĩa là nội dung kế hoạch đang được xem xét có kiểm soát và có thể thay đổi theo truy vết.	Không được diễn giải là APPROVED, BASELINED, compliant, production-ready hoặc user-approved.
Soạn thảo section	Sáu section chỉ được xác định tiêu đề, mục đích và biên nội dung để chuẩn bị cho giai đoạn sau.	Không được tạo nội dung quy tắc nghiệp vụ chính thức cho bất kỳ section nào.
Baseline	Không có baseline reference cho CANONICAL_BUSINESS_RULES.md tại v0.9.0. Baseline là phiên bản được chốt có kiểm soát để làm mốc đối chiếu thay đổi.	Không được gọi cấu trúc, bảng kế hoạch, tên section, ID dự kiến hoặc ví dụ mô phỏng là baseline.
Approval	Không có approval reference được ghi nhận. Approval là quyết định chấp thuận được ghi nhận rõ bởi vai trò có thẩm quyền đối với đúng phạm vi.	Không được suy ra phê duyệt từ việc tài liệu tồn tại, được cập nhật, có Owner, có metadata hoặc có trạng thái IN_REVIEW.
Thẩm quyền Owner	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì tính nhất quán quản trị của artifact.	Owner không được thay Legal, Accounting, Security, Business Owner, Architect hoặc QA xác nhận nội dung hay cấp phép sử dụng.

Quy tắc quyết định là: chỉ sau khi có nội dung được soạn ở giai đoạn phù hợp, được xem xét theo nguồn và thẩm quyền tương ứng, và có tham chiếu baseline hoặc approval được ghi nhận minh bạch trong artifact kiểm soát, mới được dùng các thuật ngữ “đã baseline” hoặc “đã phê duyệt”. Cho đến trước điều kiện đó, mọi nội dung Nova Foods vẫn là kế hoạch học liệu mô phỏng, không phải quy định vận hành ERP, cam kết pháp lý, diễn giải kế toán, xác nhận bảo mật hay chỉ dẫn triển khai thực tế.