/01-curriculum/CANONICAL_DATA_DICTIONARY.md — Canonical Logical Data Dictionary Plan for Nova Foods

01. Governance, Artifact Identity, and Document Control

Metadata quản trị artifact

Trường kiểm soát	Giá trị chuẩn	Diễn giải áp dụng
Artifact ID	CANONICAL_DATA_DICTIONARY	Định danh quản trị duy nhất của kế hoạch từ điển dữ liệu logic canonical. Artifact khác tham chiếu đến tài liệu này phải giữ nguyên chuỗi ID để tránh nhầm với catalog quy tắc, registry định danh hoặc đặc tả dữ liệu triển khai.
Đường dẫn tệp được kiểm soát	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Đây là vị trí canonical của artifact trong corpus Nova Foods. Bản sao, bản xuất PDF, nội dung trích dẫn hoặc tệp có tên tương tự không thay thế tệp tại đường dẫn này.
Status	IN_REVIEW	IN_REVIEW nghĩa là artifact đang được xem xét có kiểm soát và có thể thay đổi theo truy vết. Trạng thái này không có nghĩa APPROVED, BASELINED, sẵn sàng production, tuân thủ pháp luật, hoặc đã được người dùng chấp thuận.
Version	v0.9.0	Phiên bản kế hoạch hiện hành tại ngày ghi nhận metadata. Số phiên bản này nhận diện trạng thái của artifact, không xác nhận rằng các entity, thuộc tính, kiểu dữ liệu hoặc quy tắc kiểm tra đã hoàn chỉnh.
Owner	Principal IT Business Analyst / Technical Curriculum Author	Owner duy trì tính toàn vẹn của Artifact ID, đường dẫn, trạng thái, phiên bản và metadata quản trị. Owner không tự xác lập baseline, không ghi nhận approval, không quyết định cấu hình ERP, và không thay thế thẩm quyền của Business Owner, Architect, QA Reviewer, Legal Owner, Accounting Owner hoặc Security.
Last updated date	2026-08-07	Ngày cập nhật metadata được diễn giải theo múi giờ quản trị Asia/Ho_Chi_Minh; không suy diễn một thời điểm chính xác trong ngày khi artifact không ghi nhận dấu thời gian.
Timezone	Asia/Ho_Chi_Minh	Múi giờ chuẩn để diễn giải ngày giờ review, thay đổi, bằng chứng và liên kết quản trị của artifact trong corpus.
Locale	vi-VN	Locale nội dung là tiếng Việt Việt Nam. Bối cảnh tiền tệ của case study là VND; điều này chỉ định dạng ngữ cảnh học tập, không xác nhận cấu hình kế toán hoặc tiền tệ 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	Nova Foods là case study ERP mô phỏng. Tên gọi này không chứng minh sự tồn tại của doanh nghiệp, hệ thống, khách hàng, nhà cung cấp, nhân sự, giao dịch, lô hàng hoặc dữ liệu thực tế.
Artifact classification	Controlled planning artifact for the canonical logical data dictionary in the Nova Foods ERP corpus	Đây là artifact lập kế hoạch có kiểm soát cho từ điển dữ liệu logic canonical, trong đó “logical data dictionary” là tài liệu mô tả ý nghĩa nghiệp vụ và quy ước dữ liệu dự kiến, độc lập với thiết kế bảng vật lý hoặc cấu hình phần mềm. Artifact không phải đặc tả triển khai, mô hình cơ sở dữ liệu vật lý, cấu hình ERP, tài liệu vận hành production hay bằng chứng tuân thủ.
Baseline reference	Chưa có baseline reference tại v0.9.0.	Baseline là phiên bản được chốt có kiểm soát làm mốc đánh giá thay đổi. Do chưa có tham chiếu baseline được ghi nhận rõ ràng trong artifact kiểm soát phù hợp, không được gọi bất kỳ metadata, section, entity, thuộc tính hoặc ví dụ nào của tài liệu này là baseline.
Approval reference	Chưa có approval reference tại v0.9.0.	Không có phê duyệt được ghi nhận cho artifact này. Việc Owner duy trì tài liệu, sự hiện diện của metadata, hoặc trạng thái IN_REVIEW không tạo approval ngầm định từ Business Owner, QA Reviewer, Legal Owner, Accounting Owner, Security, Architect hay bất kỳ vai trò nào khác.

Metadata này xác định danh tính quản trị của /01-curriculum/CANONICAL_DATA_DICTIONARY.md tại 2026-08-07. Cơ sở của kết luận kiểm soát là: đường dẫn được kiểm soát xác định nguồn artifact, v0.9.0 xác định phiên bản đang xem xét, còn cả Baseline reference và Approval reference đều chưa tồn tại. Vì vậy, khi bản sao hoặc liên kết bên ngoài dùng trạng thái khác, artifact này vẫn phải được diễn giải là IN_REVIEW; không được suy diễn một quyết định chốt baseline, phê duyệt nội dung hoặc quyền áp dụng cho môi trường thực tế.

Khởi tạo lịch sử thay đổi của artifact lập kế hoạch

Lịch sử thay đổi là bảng ghi nhận theo thứ tự thời gian các lần thay đổi có kiểm soát đối với artifact. Bảng này tạo bằng chứng truy vết về điều gì đã đổi, ai ghi nhận và thay đổi đó có ý nghĩa quản trị nào; bảng không phải là bằng chứng phê duyệt. Vì /01-curriculum/CANONICAL_DATA_DICTIONARY.md đang ở giai đoạn lập kế hoạch, bản ghi đầu tiên chỉ xác định điểm xuất phát để các cập nhật sau có thể được đối chiếu nhất quán.

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 artifact CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md trong giai đoạn lập kế hoạch trước khi xác định catalog entity, thuộc tính hoặc quy tắc dữ liệu canonical.	Thiết lập điểm xuất phát có truy vết cho artifact trong corpus ERP Nova Foods mô phỏng. Bản ghi này không tạo baseline, không ghi nhận approval, không xác nhận mô hình dữ liệu hoàn chỉnh, và không cho phép áp dụng nội dung cho production.

Bản ghi v0.9.0 là bản ghi khởi tạo duy nhất tại ngày 2026-08-07, được diễn giải theo múi giờ Asia/Ho_Chi_Minh. Trạng thái IN_REVIEW nghĩa là artifact đang được xem xét có kiểm soát và có thể thay đổi khi có thông tin hoặc nhận xét phù hợp; trạng thái này không đồng nghĩa với APPROVED, BASELINED, tuân thủ pháp lý, sẵn sàng production hoặc được người dùng chấp thuận.

Mỗi thay đổi phát sinh sau bản ghi khởi tạo phải được thêm bằng một dòng mới, không sửa đè, xóa hoặc đổi nghĩa của dòng v0.9.0. Dòng mới phải có đủ sáu trường trong bảng để người đọc phân biệt được thay đổi nội dung với thay đổi trạng thái quản trị. Nếu thay đổi liên quan dữ liệu cá nhân, kế toán, thuế, hóa đơ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 nguồn chính thức và vai trò có thẩm quyền xác minh, mô tả thay đổi hoặc tác động kiểm soát phải giữ nhãn Verification required hoặc Project assumption. Nova Foods là case study mô phỏng và mọi ví dụ dữ liệu được ghi nhận trong các thay đổi sau chỉ được dùng dữ liệu tổng hợp.

Mục đích và ranh giới phạm vi cho Nova Foods mô phỏng

/01-curriculum/CANONICAL_DATA_DICTIONARY.md được lập để quy hoạch từ điển dữ liệu logic canonical: tài liệu mô tả nhất quán ý nghĩa nghiệp vụ của dữ liệu, tên khái niệm, quan hệ dự kiến và các điểm cần kiểm soát trước khi thiết kế dữ liệu vật lý. “Logic” nghĩa là tập trung vào dữ liệu cần biểu đạt cho nghiệp vụ, không quyết định bảng cơ sở dữ liệu, kiểu cột của một hệ quản trị dữ liệu cụ thể, mã nguồn, API hoặc cấu hình ERP.

Phạm vi chỉ áp dụng cho Nova Foods Trading & Manufacturing, là case study ERP mô phỏng phục vụ học tập. Lý do giới hạn này là mỗi thuật ngữ dữ liệu chỉ có ý nghĩa khi gắn với một ngữ cảnh nghiệp vụ xác định; vì vậy, tên thực thể như sản phẩm, kho, lô hàng, đơn bán, phiếu nhập, lệnh sản xuất hoặc bút toán chỉ được diễn giải theo kịch bản Nova Foods mô phỏng, không được suy rộng thành mô hình chuẩn cho doanh nghiệp khác.

Hạng mục	Trong phạm vi của từ điển dữ liệu logic	Ngoài phạm vi của từ điển dữ liệu logic
Khái niệm dữ liệu	Xác định các khái niệm cần dùng để mô tả nghiệp vụ Nova Foods, ví dụ sản phẩm, nhà cung cấp, khách hàng, kho, lô, hạn dùng và chứng từ mô phỏng.	Khẳng định các khái niệm này phản ánh tổ chức, khách hàng, nhà cung cấp hoặc giao dịch có thật.
Ý nghĩa và quan hệ	Làm rõ một dữ liệu đại diện cho điều gì, thuộc miền nghiệp vụ nào và có quan hệ nghiệp vụ dự kiến với dữ liệu nào khác.	Thiết kế khóa chính, khóa ngoại, chỉ mục, bảng vật lý, phân vùng dữ liệu hoặc cơ chế sao chép dữ liệu.
Kiểm soát học liệu	Chuẩn bị cơ sở để các artifact Nova Foods liên kết thuật ngữ, quy tắc, yêu cầu, kiểm thử và truy vết bằng cách hiểu nhất quán.	Thay thế quyết định của Business Owner, Architect, Accounting, Legal, Security hoặc QA Reviewer.
Bối cảnh Việt Nam	Dùng vi-VN, Asia/Ho_Chi_Minh và VND làm bối cảnh diễn giải mô phỏng khi các nội dung sau cần tham chiếu.	Kết luận về nghĩa vụ pháp lý, thuế, kế toán, hóa đơn, bảo vệ dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc thực tế.

Ranh giới quyết định được áp dụng như sau: một nội dung được đưa vào tài liệu khi nó cần thiết để người học nhận diện và diễn giải dữ liệu trong quy trình ERP mô phỏng của Nova Foods; nội dung đó không được đưa vào chỉ vì phổ biến trong một hệ thống ERP khác. Ví dụ, “lô hàng” có thể thuộc phạm vi vì hỗ trợ diễn giải tồn kho và hạn dùng trong kịch bản Nova Foods; nhưng thuật toán cấp số lô, cấu hình máy quét mã vạch và thời hạn lưu trữ thực tế không thuộc phạm vi ở giai đoạn từ điển logic.

Mọi ví dụ, mã minh họa, giá trị tiền tệ, tên đối tượng và tình huống được sử dụng trong phạm vi này chỉ nhằm giải thích dữ liệu của Nova Foods mô phỏng. Nếu một khái niệm có thể bị hiểu là yêu cầu pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc cấu hình production, nội dung phải được giới hạn là giả định học liệu hoặc gắn nhãn Verification required trước khi được diễn giải sâu hơn.

Cam kết sử dụng dữ liệu tổng hợp

Artifact này chỉ sử dụng dữ liệu tổng hợp (synthetic data), tức dữ liệu được tạo có chủ đích cho mục tiêu học tập và kiểm thử mô phỏng, không được trích xuất, sao chép, suy luận từ hoặc đối chiếu để nhận diện dữ liệu của cá nhân, khách hàng, nhà cung cấp, nhân sự, sản phẩm, lô hàng, kho, chứng từ hoặc giao dịch thực tế. Cơ sở của giới hạn này là Nova Foods Trading & Manufacturing là case study ERP mô phỏng; do đó mọi nội dung dữ liệu trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md phải chỉ minh họa cấu trúc logic cần được định nghĩa, không mô tả hồ sơ vận hành có thật.

Hạng mục dữ liệu	Được phép trong artifact	Không được phép trong artifact	Tiêu chí kiểm tra
Tên tổ chức và đối tác	Tên giả định không đại diện cho tổ chức có thật, ví dụ Nhà cung cấp Mô phỏng Miền Nam 01.	Tên pháp lý, mã số thuế, địa chỉ, số điện thoại hoặc thông tin liên hệ của tổ chức thực tế.	Không có khả năng xác định hoặc liên hệ tới một tổ chức thực tế.
Cá nhân và tài khoản	Vai trò giả định, ví dụ Nhân viên kho mô phỏng, cùng mã định danh học liệu như USR-TRAIN-001.	Họ tên thật, email thật, số điện thoại, số định danh cá nhân, thông tin đăng nhập, quyền truy cập hoặc nhật ký người dùng thực tế.	Không chứa dữ liệu cá nhân hoặc bí mật xác thực.
Hàng hóa, lô và tồn kho	Mã minh họa như SKU-SIM-001, LOT-SIM-20260807-01, số lượng và hạn dùng phục vụ tình huống đào tạo.	Mã hàng, công thức, dữ liệu chất lượng, lịch sản xuất, vị trí kho hoặc số liệu tồn kho của doanh nghiệp thực.	Giá trị chỉ đủ để giải thích thuộc tính, quan hệ hoặc quy tắc dữ liệu dự kiến.
Tài chính và chứng từ	Giá trị VND mô phỏng, số chứng từ giả định và kỳ hạch toán phục vụ minh họa.	Số dư, giá vốn, giá bán, thuế, hóa đơn, bút toán, tài khoản hoặc báo cáo tài chính thực tế.	Không thể dùng để suy ra tình hình tài chính của bất kỳ đơn vị nào.
Tích hợp và kỹ thuật	Mã interface, URL mẫu không định tuyến thực tế và định danh giả lập.	Khóa bí mật, token, endpoint nội bộ, địa chỉ IP, cấu hình production, log hoặc sơ đồ truy cập thực tế.	Không tạo rủi ro truy cập trái phép hay tiết lộ kiến trúc thực.

Quy tắc áp dụng là mọi ví dụ dữ liệu xuất hiện về sau phải được gắn ngữ cảnh mô phỏng, có giá trị nhất quán nội bộ và không được trình bày như bằng chứng về hoạt động của Nova Foods hoặc bất kỳ đơn vị nào. Nếu một giá trị được đề xuất có nguồn từ môi trường thực, tài liệu khách hàng, hệ thống ERP đang vận hành, hồ sơ nhân sự, chứng từ, dữ liệu giao dịch hoặc nguồn không xác định được tính tổng hợp, giá trị đó không được đưa vào artifact này. Việc thay thế bằng dữ liệu tổng hợp phải bảo toàn mục tiêu minh họa về kiểu dữ liệu, định dạng, quan hệ và tình huống nghiệp vụ, nhưng không bảo toàn danh tính hay số liệu thực.

Việc chỉ dùng dữ liệu tổng hợp không tự xác nhận rằng mô hình dữ liệu dự kiến đáp ứng yêu cầu pháp lý, kế toán, thuế, hóa đơn, bảo vệ 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. Khi nội dung học liệu chạm đến các lĩnh vực này mà chưa được nguồn chính thức và vai trò có thẩm quyền xác minh, nội dung liên quan phải được phân loại Project assumption hoặc Verification required; không được biến dữ liệu mô phỏng thành căn cứ cho quyết định vận hành hoặc tuân thủ.

Ngôn ngữ kiểm soát: artifact lập kế hoạch, không phải baseline specification

/01-curriculum/CANONICAL_DATA_DICTIONARY.md là artifact lập kế hoạch có kiểm soát (controlled planning artifact), nghĩa là tài liệu được quản lý để chuẩn bị, cấu trúc hóa và xem xét nội dung sẽ có thể cần phát triển ở các giai đoạn sau. Artifact này không phải baseline specification; baseline là một phiên bản được chốt có kiểm soát làm mốc chính thức để đối chiếu thay đổi. Lý do là trạng thái hiện hành IN_REVIEW chỉ chứng minh nội dung đang được xem xét và có thể thay đổi theo truy vết, không chứng minh nội dung đã ổn định, đầy đủ, được xác nhận chuyên môn hoặc đủ điều kiện sử dụng ngoài corpus học tập.

Hạng mục	Diễn giải được phép tại IN_REVIEW	Diễn giải không được phép
Nội dung kế hoạch	Dùng để định hướng cách xây dựng data dictionary logical cho Nova Foods mô phỏng.	Không được coi là định nghĩa dữ liệu đã chốt cho ERP thực tế.
Cấu trúc, tên gọi, bảng và ví dụ	Là đầu vào học tập có thể được rà soát, sửa đổi và truy vết.	Không được coi là cấu hình hệ thống, hợp đồng interface, thiết kế cơ sở dữ liệu vật lý hoặc yêu cầu triển khai.
Thuật ngữ “canonical”	Chỉ biểu thị ý định tạo điểm tham chiếu nhất quán trong corpus Nova Foods.	Không tự tạo hiệu lực phê duyệt, hiệu lực pháp lý, hiệu lực kế toán hoặc quyền áp dụng production.
Baseline	Chưa tồn tại cho artifact này tại v0.9.0 nếu không có tham chiếu baseline được ghi nhận minh bạch trong artifact kiểm soát phù hợp.	Không được suy diễn baseline từ việc tệp có đường dẫn canonical, có version, có Owner hoặc đang được review.
Approval	Chưa được suy diễn từ việc soạn thảo, review, duy trì metadata hay liên kết sang artifact khác.	Không được gọi là đã được Business Owner, Architect, QA, Legal, Accounting, Security hoặc người dùng phê duyệt khi không có approval reference được ghi nhận.

Người học cần phân biệt giữa quản trị tài liệu và thẩm quyền quyết định. Quản trị tài liệu giúp biết nội dung nào đang được theo dõi, ở phiên bản nào và có thể thay đổi ra sao; nó không thay thế việc chuyên gia xác nhận tính đúng đắn của định nghĩa dữ liệu, quy tắc nghiệp vụ, diễn giải pháp lý, hạch toán, bảo mật hoặc kiến trúc. Vì vậy, Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì tính nhất quán và khả năng truy vết của artifact, không có quyền tự biến nội dung kế hoạch thành baseline hoặc specification có hiệu lực.

Mọi nội dung trong artifact phải được hiểu trong ranh giới Nova Foods là case study ERP mô phỏng phục vụ giáo dục và chỉ sử dụng dữ liệu tổng hợp. Không được dùng tài liệu này làm căn cứ vận hành, cấu hình, chuyển đổi dữ liệu, xử lý giao dịch, chứng minh tuân thủ hoặc ra quyết định cho tổ chức thực tế. Khi một nội dung cần được mô tả như đã baseline hoặc đã phê duyệt, phải có bằng chứng quản trị rõ ràng: phiên bản được chốt, tham chiếu baseline hoặc approval tương ứng, phạm vi quyết định, vai trò có thẩm quyền và liên kết đến artifact kiểm soát ghi nhận quyết định đó. Trước khi các điều kiện này tồn tại, cách diễn đạt bắt buộc là “đề xuất”, “dự kiến”, Project assumption hoặc Verification required tùy theo bản chất và mức độ xác minh của nội dung.

02. Scope, Modeling Rules, Naming Conventions, and Source Policy

Phạm vi miền nghiệp vụ được lập từ điển dữ liệu

Nova Foods Trading & Manufacturing là case study ERP mô phỏng phục vụ giáo dục, chỉ dùng dữ liệu tổng hợp, bối cảnh vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND. Phạm vi của từ điển dữ liệu logic dự kiến bao phủ các miền bên dưới vì một ERP cần mô tả dữ liệu xuyên suốt từ nhận diện đối tác, lập giao dịch thương mại, mua hoặc sản xuất hàng, quản lý tồn và lô, đến ghi nhận tài chính, kiểm soát quyết định và phân tích kết quả. Đây là quyết định phạm vi học liệu IN_REVIEW, không phải xác nhận cấu hình, quy trình hay dữ liệu của một doanh nghiệp thực tế.

Miền nghiệp vụ	Mục tiêu dữ liệu trong case study Nova Foods	Nội dung dữ liệu dự kiến được từ điển hóa	Cầu nối lập luận phạm vi
CRM (Customer Relationship Management — quản lý quan hệ khách hàng)	Nhận diện và quản lý thông tin khách hàng, đầu mối liên hệ và cơ hội thương mại mô phỏng.	Khách hàng, địa chỉ liên hệ, phân khúc, nhân sự liên hệ, cơ hội và nguồn tạo khách hàng tiềm năng.	Bán hàng cần biết bán cho ai và theo bối cảnh thương mại nào; vì vậy CRM là đầu vào dữ liệu cho đơn hàng và phân tích khách hàng.
Bán hàng	Ghi nhận vòng đời thương mại mô phỏng từ yêu cầu mua đến cam kết giao hàng và chứng từ bán hàng dự kiến.	Báo giá, đơn bán hàng, dòng đơn hàng, lịch giao, giao hàng, trả hàng và điều chỉnh bán hàng.	Một giao dịch bán cần liên kết khách hàng, mặt hàng, giá, số lượng và trạng thái thực hiện; các dữ liệu này phải nhất quán để truy vết luồng bán hàng.
Giá (pricing)	Quản lý cách xác định giá bán mô phỏng theo mặt hàng, khách hàng, thời gian và điều kiện kinh doanh.	Bảng giá, dòng giá, điều kiện áp dụng, chiết khấu, khuyến mại và hiệu lực giá.	Đơn bán hàng cần một cơ sở xác định đơn giá; do đó dữ liệu giá phải được tách đủ rõ khỏi dữ liệu đơn hàng để giải thích vì sao một mức giá được dùng.
Mua hàng (procurement)	Quản lý nhu cầu mua, lựa chọn nhà cung cấp và tiếp nhận hàng hóa hoặc dịch vụ mô phỏng.	Nhà cung cấp, yêu cầu mua, đơn mua hàng, dòng đơn mua, lịch nhận, biên nhận và trả hàng mua.	Tồn kho nguyên liệu hoặc hàng mua không thể giải thích chỉ bằng số lượng hiện có; cần dữ liệu nguồn cung và sự kiện nhận hàng để hình thành lịch sử.
Tồn kho	Theo dõi hàng hóa theo kho, vị trí lưu trữ và biến động số lượng mô phỏng.	Kho, vị trí kho, số dư tồn, giao dịch nhập, xuất, chuyển kho, kiểm kê và điều chỉnh tồn.	Bán hàng, mua hàng và sản xuất đều làm thay đổi khả dụng của hàng; vì vậy tồn kho là điểm hội tụ dữ liệu vật lý giữa các miền.
Truy xuất lô/mẻ (lot/batch traceability)	Liên kết hàng hóa với lô hoặc mẻ để hỗ trợ truy vết mô phỏng theo chiều nhận, sản xuất, lưu kho và xuất bán.	Lô/mẻ, ngày sản xuất, ngày hết hạn dự kiến, trạng thái lô, quan hệ lô đầu vào–đầu ra và sự kiện dịch chuyển lô.	Với thực phẩm, một đơn vị hàng có thể cần được phân biệt theo lô thay vì chỉ theo mã mặt hàng; vì vậy dữ liệu lô là lớp nhận diện bổ sung cho tồn kho và sản xuất. Mọi yêu cầu pháp lý hoặc an toàn thực phẩm cụ thể vẫn là Verification required.
Sản xuất	Mô tả việc biến đổi nguyên liệu thành thành phẩm trong kịch bản sản xuất mô phỏng.	Công thức hoặc cấu trúc nguyên vật liệu dự kiến, lệnh sản xuất, tiêu hao, sản lượng hoàn thành, phế phẩm và mẻ sản xuất.	Lô thành phẩm, tồn kho nguyên liệu và chi phí mô phỏng cần có điểm nối giải thích hoạt động biến đổi; miền sản xuất cung cấp điểm nối đó.
Tài chính	Liên kết các sự kiện thương mại và vận hành với thông tin giá trị tiền tệ mô phỏng bằng VND.	Kỳ tài chính, tài khoản, chứng từ kế toán dự kiến, dòng bút toán, công nợ phải thu, công nợ phải trả và đối soát.	Bán, mua, tồn kho và sản xuất có tác động giá trị; phạm vi này cần dữ liệu tài chính để học viên phân tích liên kết nghiệp vụ–kế toán. Cách hạch toán, thuế, hóa đơn và nghĩa vụ pháp lý cụ thể là Verification required.
Phê duyệt	Ghi nhận quyết định kiểm soát mô phỏng đối với các đối tượng cần xét duyệt.	Yêu cầu phê duyệt, bước phê duyệt, người hoặc vai trò xử lý, quyết định, thời điểm xử lý và lý do từ chối.	Một số giao dịch có thể cần kiểm soát trước khi tiếp tục; dữ liệu phê duyệt giúp phân biệt trạng thái nghiệp vụ với bằng chứng ai đã thực hiện quyết định trong kịch bản.
Báo cáo	Cung cấp dữ liệu tổng hợp để theo dõi hoạt động và hỗ trợ phân tích mô phỏng.	Chỉ tiêu, kỳ báo cáo, chiều phân tích, tập dữ liệu báo cáo và liên kết đến dữ liệu nguồn nghiệp vụ.	Báo cáo không tạo sự kiện gốc mà diễn giải dữ liệu từ các miền khác; vì vậy phạm vi tập trung vào khả năng truy nguyên số liệu báo cáo về dữ liệu nguồn tổng hợp.

Ranh giới liên miền được giữ ở mức dữ liệu logic: CRM cung cấp ngữ cảnh khách hàng cho bán hàng; giá cung cấp điều kiện định giá cho giao dịch bán; mua hàng và sản xuất tạo hoặc làm biến động hàng; tồn kho và lô/mẻ phản ánh vị trí cùng khả năng truy vết của hàng; tài chính phản ánh giá trị mô phỏng của sự kiện; phê duyệt lưu bằng chứng quyết định; báo cáo tổng hợp từ dữ liệu nguồn. Sự liên kết này là mô hình học tập dự kiến nhằm tránh mô tả từng miền như các vùng dữ liệu cô lập, không phải tuyên bố về kiến trúc tích hợp hay quy trình vận hành thực tế của Nova Foods.

Ranh giới ngoài phạm vi và các hạn chế minh thị

Phạm vi của data dictionary (từ điển dữ liệu) là mô tả có cấu trúc về dữ liệu logic dự kiến được dùng trong case study ERP Nova Foods Trading & Manufacturing. Vì mục tiêu là học liệu, tài liệu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md chỉ xác định dữ liệu cần được hiểu và liên kết ở mức nghiệp vụ; tài liệu không tự tạo cấu hình hệ thống, quy trình vận hành thực tế hoặc bằng chứng tuân thủ. Nova Foods là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp trong bối cảnh vi-VN, Asia/Ho_Chi_Minh và VND.

Hạng mục ngoài phạm vi	Ranh giới loại trừ cụ thể	Lý do và hệ quả áp dụng
Thiết kế vật lý và triển khai cơ sở dữ liệu	Không quy định hệ quản trị cơ sở dữ liệu, bảng vật lý, kiểu cột của nhà cung cấp, chỉ mục, phân vùng, thủ tục lưu trữ, hiệu năng truy vấn, sao lưu hoặc khôi phục.	Dictionary logic trả lời “dữ liệu nghiệp vụ nào cần tồn tại và liên hệ ra sao”, không trả lời “lưu bằng công nghệ nào”. Quyết định vật lý thuộc phạm vi kiến trúc và triển khai.
Cấu hình ERP hoặc mã nguồn	Không cung cấp cấu hình màn hình, workflow engine, phân quyền cụ thể, mapping API, câu lệnh SQL, mã nguồn, biểu mẫu hóa đơn, template báo cáo hay hướng dẫn triển khai.	Một thuộc tính logic có thể được hiện thực khác nhau giữa các nền tảng ERP; suy ra cấu hình từ dictionary sẽ tạo rủi ro diễn giải sai.
Dữ liệu thực và nhận diện cá nhân	Không chứa khách hàng, nhân viên, nhà cung cấp, địa chỉ, số điện thoại, tài khoản ngân hàng, mã số thuế, số định danh, chứng từ hoặc giao dịch thực.	Mọi ví dụ, nếu xuất hiện ở artifact liên quan, phải là dữ liệu tổng hợp. Không được dùng corpus để suy luận danh tính hay hoạt động của một tổ chức thực.
Quyết định pháp lý, thuế và kế toán	Không diễn giải nghĩa vụ pháp lý, mức thuế, thời hạn lưu trữ bắt buộc, cách lập hóa đơn hợp lệ, bút toán chuẩn, chính sách ghi nhận doanh thu hoặc kết luận tuân thủ.	Các nội dung này cần văn bản hiện hành và xác minh bởi vai trò có thẩm quyền về Legal và Accounting. IN_REVIEW tại v0.9.0 không tạo xác nhận pháp lý, thuế hoặc kế toán.
Quy định an toàn thực phẩm và truy xuất nguồn gốc thực tế	Không xác định ngưỡng chất lượng, tiêu chuẩn kiểm nghiệm, thời hạn sử dụng hợp pháp, điều kiện bảo quản bắt buộc, quy trình thu hồi hoặc mức độ truy xuất đáp ứng quy định thực tế.	Dữ liệu lô, mẻ và hạn dùng trong học liệu chỉ mô tả nhu cầu dữ liệu logic. Mọi tuyên bố về an toàn thực phẩm hoặc truy xuất nguồn gốc phải được xác minh bởi chủ sở hữu miền và vai trò pháp lý phù hợp.
An ninh, quyền riêng tư và vận hành bảo mật	Không xác nhận mô hình kiểm soát truy cập thực tế, mã hóa, quản lý secret, thời gian lưu log, phân loại dữ liệu pháp lý, đánh giá rủi ro hoặc mức an toàn của hệ thống.	Dictionary có thể nêu nhu cầu nhận biết dữ liệu nhạy cảm trong giai đoạn sau, nhưng không thay thế thiết kế và xác minh của Security.
Tích hợp với đối tác và cơ quan bên ngoài	Không cam kết kết nối với ngân hàng, cơ quan thuế, nhà vận chuyển, sàn thương mại điện tử, hệ thống POS, thiết bị sản xuất hoặc bên thứ ba.	Không có endpoint, giao thức, tần suất đồng bộ, quyền truy cập hay SLA nào được suy diễn từ phạm vi dictionary.
Báo cáo quản trị đã được chấp thuận	Không xác định KPI chính thức, công thức tài chính cuối cùng, chỉ tiêu pháp định, báo cáo quản trị bắt buộc hoặc quyền phát hành báo cáo.	Cùng một dữ liệu logic có thể hỗ trợ nhiều cách tính; lựa chọn chỉ tiêu cần quyết định nghiệp vụ và xác minh chuyên môn riêng.

Hạn chế chủ đạo là artifact này đang ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; vì vậy nội dung chỉ là kế hoạch có kiểm soát để học và rà soát. Không được diễn giải tên thực thể, mô tả dữ liệu hoặc ví dụ tổng hợp trong dictionary là baseline, approval, cấu hình production, cam kết tích hợp hoặc xác nhận rằng Nova Foods đáp ứng một yêu cầu bên ngoài.

Khi một yêu cầu mới vượt qua ranh giới trên, tác giả phải không âm thầm đưa nó vào dictionary. Yêu cầu cần được tách thành vấn đề cần quyết định, nêu rõ dữ liệu bị ảnh hưởng, lý do vượt phạm vi, vai trò chuyên môn cần xem xét và trạng thái Verification required hoặc Project assumption khi chưa có xác minh thích hợp. Cách xử lý này giữ cho từ điển dữ liệu là nguồn học liệu logic nhất quán, đồng thời ngăn một giả định mô phỏng bị biến thành kết luận vận hành hoặc tuân thủ.

Quy ước biểu diễn dữ liệu logic và liên kết nghiệp vụ

Từ điển dữ liệu này mô tả mô hình dữ liệu logic: cách nghiệp vụ cần nhận diện và liên kết thông tin, độc lập với bảng vật lý, kiểu cơ sở dữ liệu, API hoặc cấu hình ERP cụ thể. Vì Nova Foods là case study ERP mô phỏng, mọi ví dụ dưới đây chỉ dùng dữ liệu tổng hợp; chúng minh họa cấu trúc cần phân tích, không xác nhận thiết kế production, cấu hình hệ thống hay quyết định vận hành thực tế.

Khái niệm	Diễn giải từ nguyên lý	Cách ghi nhận trong từ điển dữ liệu	Ví dụ mô phỏng Nova Foods
Entity (thực thể)	Một tập hợp đối tượng nghiệp vụ cần được nhận diện riêng vì có thuộc tính, vòng đời hoặc quan hệ cần quản lý.	Mỗi thực thể có một bản ghi riêng với mục đích, chủ thể nghiệp vụ và các liên kết dự kiến.	Customer biểu diễn khách hàng; SalesOrder biểu diễn đơn đặt hàng bán.
Attribute (thuộc tính)	Một đơn vị thông tin mô tả thực thể. Thuộc tính chỉ có ý nghĩa khi giá trị của nó trả lời một câu hỏi nghiệp vụ xác định.	Ghi tên nghiệp vụ, ý nghĩa, kiểu dữ liệu logic, bắt buộc hay không, nguồn giá trị và quy tắc kiểm tra liên quan.	SalesOrder.order_date trả lời đơn được lập vào ngày nào; Customer.tax_identifier là thông tin cần phân loại và xác minh riêng nếu được sử dụng.
Key (khóa)	Một hoặc nhiều thuộc tính dùng để phân biệt duy nhất một bản ghi trong phạm vi thực thể. Khóa ngăn hai bản ghi bị hiểu là cùng một đối tượng chỉ vì có mô tả giống nhau.	Xác định loại khóa, phạm vi duy nhất và lý do nghiệp vụ hoặc kỹ thuật dự kiến. Không suy diễn khóa logic thành số chứng từ hợp pháp.	sales_order_id phân biệt từng SalesOrder, kể cả khi hai đơn cùng khách hàng và cùng ngày.
Foreign key (khóa ngoại)	Thuộc tính giữ giá trị khóa của thực thể khác để tạo liên kết có kiểm soát. Đây là cách biểu đạt rằng một bản ghi phụ thuộc hoặc tham chiếu đến một bản ghi đã được nhận diện.	Chỉ rõ thực thể nguồn, thực thể được tham chiếu, khóa được tham chiếu và hành vi nghiệp vụ khi bản ghi liên quan không tồn tại hoặc không còn hợp lệ.	SalesOrder.customer_id tham chiếu Customer.customer_id; đơn bán không thể được diễn giải là thuộc một khách hàng chưa xác định.
Relationship (quan hệ)	Mối liên hệ nghiệp vụ giữa hai thực thể, diễn tả câu hỏi “bản ghi này liên quan với bản ghi kia như thế nào?”. Quan hệ không chỉ là nối dữ liệu; nó phải có ý nghĩa nghiệp vụ.	Ghi động từ quan hệ, hai đầu quan hệ, tính bắt buộc và cardinality.	SalesOrder được đặt bởi Customer; InventoryLot được lưu tại Warehouse.
Cardinality (lực lượng/bội số quan hệ)	Số lượng tối thiểu và tối đa bản ghi ở một đầu quan hệ có thể gắn với một bản ghi ở đầu kia. Cardinality loại bỏ cách hiểu mơ hồ về một–một, một–nhiều hoặc nhiều–nhiều.	Dùng ký hiệu 0..1, 1, 0..*, 1..*; giải thích điều kiện nghiệp vụ tạo ra giá trị tối thiểu.	Một Customer có thể có 0..* SalesOrder; mỗi SalesOrder phải thuộc đúng 1 Customer nếu quy trình mô phỏng yêu cầu xác định người mua.
Domain code (mã miền giá trị)	Tập giá trị có kiểm soát dùng lại cho một thuộc tính phân loại. Mã miền tách giá trị chuẩn khỏi văn bản tự do, giúp báo cáo và kiểm tra nhất quán.	Ghi mã miền, ý nghĩa từng giá trị, thực thể/thuộc tính sử dụng và chủ thể cần xác nhận giá trị mới.	OrderStatusCode có thể chứa DRAFT, SUBMITTED, CONFIRMED, CANCELLED trong phạm vi mô phỏng.
Lifecycle/state reference (tham chiếu vòng đời/trạng thái)	Tham chiếu đến tập trạng thái và chuyển trạng thái hợp lệ của một thực thể. Trạng thái cho biết bản ghi đang ở đâu trong tiến trình; nó không tự chứng minh đã được phê duyệt, hạch toán hay tuân thủ.	Liên kết thuộc tính trạng thái với domain code hoặc quy tắc nghiệp vụ tương ứng; nêu sự kiện kích hoạt chuyển trạng thái và vai trò cần xác minh khi có tác động chuyên môn.	SalesOrder.order_status_code tham chiếu OrderStatusCode; chuyển từ DRAFT sang SUBMITTED là một sự kiện vòng đời cần có điều kiện nghiệp vụ được mô tả.

Quy tắc phân biệt là: tạo thực thể khi đối tượng cần được nhận diện độc lập, có nhiều thuộc tính hoặc tham gia quan hệ riêng; tạo thuộc tính khi thông tin chỉ mô tả một thực thể và không cần vòng đời độc lập. Ví dụ, ngày đặt hàng là thuộc tính của SalesOrder, trong khi InventoryLot là thực thể vì một lô có thể mang nhận diện, số lượng, vị trí tồn và liên kết truy xuất riêng. Lập luận này dựa trên nhu cầu quản lý độc lập và truy vết quan hệ, không dựa trên việc một hệ thống kỹ thuật có sẵn bảng hay màn hình tương ứng.

Quan hệ nhiều–nhiều không được ghi trực tiếp nếu nghiệp vụ cần lưu thông tin về chính mối liên hệ đó. Khi một SalesOrder có nhiều mặt hàng và một mặt hàng có thể xuất hiện trong nhiều đơn, cần một thực thể liên kết như SalesOrderLine, vì số lượng, đơn giá mô phỏng hoặc trạng thái dòng là thông tin thuộc quan hệ giữa đơn và mặt hàng, không thuộc riêng một trong hai thực thể. Đây là quyết định mô hình hóa logic nhằm bảo toàn ý nghĩa dữ liệu; chi tiết hạch toán, thuế, giá hoặc chứng từ liên quan vẫn cần được xác minh trong artifact và bởi vai trò có thẩm quyền phù hợp.

Mỗi domain code phải phân biệt mã ổn định để xử lý với nhãn hiển thị có thể dịch. Ví dụ, CONFIRMED là mã xử lý mô phỏng, còn “Đã xác nhận” là nhãn tiếng Việt hiển thị cho người dùng. Không được dùng nhãn hiển thị làm căn cứ duy nhất cho tích hợp, báo cáo hoặc kiểm thử, vì nhãn có thể thay đổi theo ngôn ngữ trong khi mã cần giữ ý nghĩa ổn định. Việc bổ sung, xóa hoặc đổi nghĩa một giá trị domain code phải được truy vết như thay đổi có tác động đến dữ liệu, quy tắc và báo cáo.

Thuộc tính trạng thái không được dùng thay cho toàn bộ lịch sử. Nếu nghiệp vụ cần biết ai, khi nào và vì sao đã chuyển trạng thái, mô hình logic phải xem xét thực thể hoặc bản ghi lịch sử trạng thái riêng. Tuy nhiên, việc xác định thời hạn lưu giữ, bằng chứng phê duyệt, khả năng truy xuất lô, nghĩa vụ kế toán, hóa đơn, thuế, dữ liệu cá nhân hoặc an toàn thực phẩm thuộc diện Verification required khi chưa được đối chiếu với nguồn chính thức hiện hành và vai trò Legal Owner, Accounting, Business Owner, Security hoặc chuyên gia chất lượng có thẩm quyền.

Quy ước đặt tên canonical cho entity, khóa và miền tham chiếu

Quy ước này áp dụng cho từ điển dữ liệu logic của Nova Foods Trading & Manufacturing, là case study ERP mô phỏng phục vụ giáo dục và chỉ dùng dữ liệu tổng hợp. Mục tiêu là để một tên dữ liệu biểu đạt nhất quán ý nghĩa nghiệp vụ trước khi được chuyển thành tên bảng, cột, API hoặc cấu hình kỹ thuật. Suy luận áp dụng là: cùng một khái niệm nhưng nhiều tên sẽ làm đứt truy vết giữa CRM, bán hàng, mua hàng, tồn kho và tài chính; vì vậy mỗi khái niệm canonical phải có một tên tiếng Anh kỹ thuật ổn định, còn mô tả tiếng Việt giải thích ý nghĩa cho người học.

Đối tượng đặt tên	Mẫu canonical	Quy tắc bắt buộc	Ví dụ hợp lệ	Ví dụ không dùng và lý do
Entity	PascalCase, danh từ số ít	Tên biểu đạt một loại đối tượng nghiệp vụ riêng biệt; không dùng tiền tố module, hậu tố kỹ thuật hoặc động từ.	Customer, SalesOrder, InventoryLot, ProductionOrder	CRMCustomer vì gắn chặt module; Customers vì số nhiều; CreateOrder vì là hành động.
Attribute	lower_snake_case	Dùng danh từ hoặc cụm mô tả thuộc tính; đơn vị được nêu trong tên chỉ khi cần phân biệt rõ nghĩa.	customer_name, order_date, net_amount_vnd, expiry_date	Name vì không đủ ngữ cảnh; ngayHetHan vì trộn quy ước ngôn ngữ và kiểu chữ.
Primary key	<entity>_id	Một khóa chính (primary key) là thuộc tính nhận diện duy nhất một bản ghi; dùng hậu tố _id và cùng gốc tên entity ở dạng lower_snake_case.	customer_id, sales_order_id, inventory_lot_id	id vì mơ hồ khi trao đổi liên miền; customer_code vì mã nghiệp vụ không mặc định là khóa kỹ thuật.
Foreign key	<referenced_entity>_id	Khóa ngoại (foreign key) là thuộc tính tham chiếu khóa chính của entity khác; tên phải phản ánh entity được tham chiếu, không phản ánh màn hình chứa nó.	SalesOrder.customer_id tham chiếu Customer.customer_id; InventoryLot.item_id tham chiếu Item.item_id	buyer_id nếu thực chất tham chiếu Customer; tên này làm sai ngữ nghĩa quan hệ.
Business code	<business_concept>_code	Mã nghiệp vụ dùng để nhận biết, phân loại hoặc hiển thị cho người dùng; không thay thế khóa chính nếu chưa có quyết định thiết kế được xác minh.	customer_code, item_code, warehouse_code	customer_id cho mã nhìn thấy trên chứng từ, vì nhầm khóa hệ thống với mã nghiệp vụ.
Reference domain	UPPER_SNAKE_CASE	Miền tham chiếu là tập mã kiểm soát dùng lặp lại; tên phải chỉ rõ khái niệm được phân loại và tránh tiền tố công nghệ.	ORDER_STATUS, PAYMENT_TERM, LOT_STATUS, UOM_CODE	status, vì quá rộng; tbl_order_status, vì lộ chi tiết bảng vật lý.
Reference-domain value	UPPER_SNAKE_CASE	Giá trị mã phải ổn định, không dấu, không khoảng trắng; nhãn tiếng Việt được lưu ở cột mô tả riêng.	DRAFT, CONFIRMED, ON_HOLD, EA, KG	Đã xác nhận, vì phụ thuộc ngôn ngữ hiển thị; Confirmed Order, vì có khoảng trắng và lẫn mô tả với mã.

Tên entity được viết bằng tiếng Anh chuyên môn để hỗ trợ liên kết nhất quán với mô hình dữ liệu, API và tài liệu kỹ thuật; tuy nhiên, mỗi entity trong từ điển phải có nhãn và định nghĩa tiếng Việt. Ví dụ, InventoryLot có thể được diễn giải là “Lô tồn kho”, tức tập đơn vị hàng hóa được quản lý theo cùng định danh lô trong bối cảnh mô phỏng. Việc dùng tiếng Anh không suy ra rằng Nova Foods đã chọn một ERP, cơ sở dữ liệu hay kiến trúc triển khai cụ thể.

Nhóm	Quy tắc phân biệt	Ví dụ áp dụng cho Nova Foods mô phỏng
Danh từ nghiệp vụ và chứng từ	Entity phản ánh đối tượng hoặc chứng từ, không phản ánh thao tác người dùng.	SalesOrder, PurchaseOrder, GoodsReceipt, Invoice
Đối tượng hàng hóa và truy vết	Dùng Item cho mặt hàng quản trị chung; dùng InventoryLot cho lô tồn kho; không đồng nhất lô với mặt hàng.	Một Item có thể xuất hiện trong nhiều InventoryLot; vì vậy không đặt entity lô là ItemBatch nếu “batch” chưa được định nghĩa canonical.
Giá trị tiền tệ mô phỏng	Thuộc tính tiền tệ ghi rõ _vnd khi từ điển chỉ mô tả giá trị VND mô phỏng, nhằm ngăn nhầm với số lượng hoặc tỷ lệ.	unit_price_vnd, gross_amount_vnd, tax_amount_vnd
Ngày, thời điểm và tỷ lệ	Dùng _date cho ngày lịch; dùng _at cho thời điểm; dùng _percent cho tỷ lệ phần trăm.	order_date, approved_at, discount_percent
Cờ logic	Dùng tiền tố is_, has_ hoặc requires_ khi giá trị chỉ có ý nghĩa đúng/sai.	is_active, has_expiry_date, requires_approval

Các tên trong bảng là quy ước logical, không phải lệnh tạo cột vật lý. Ví dụ, approved_at chỉ biểu đạt “thời điểm được ghi nhận là đã phê duyệt” trong mô hình logic; nó không tự xác định múi giờ lưu trữ, ai có thẩm quyền phê duyệt hoặc điều kiện phê duyệt. Những nội dung đó cần được định nghĩa tại artifact phù hợp và giữ trạng thái Verification required khi liên quan quyền hạn, dữ liệu cá nhân, kế toán, thuế, an toàn thực phẩm hoặc truy xuất nguồn gốc.

Miền tham chiếu phải được đặt tên theo ý nghĩa được kiểm soát, không theo nơi sử dụng. Chẳng hạn, ORDER_STATUS có thể được dùng tại SalesOrder và PurchaseOrder chỉ khi các giá trị và ý nghĩa trạng thái thực sự giống nhau; nếu trạng thái của hai chứng từ khác nhau, phải tách thành SALES_ORDER_STATUS và PURCHASE_ORDER_STATUS. Lý do là một domain dùng chung chỉ an toàn khi cùng mã dẫn đến cùng cách diễn giải; dùng chung vì tên giống nhau sẽ tạo sai lệch báo cáo và kiểm thử.

Tiêu chí quyết định domain	Dùng một domain chung khi	Tách domain khi
Ý nghĩa mã	Cùng mã có cùng định nghĩa nghiệp vụ và cùng hệ quả mô hình.	Cùng nhãn nhưng khác điều kiện chuyển trạng thái hoặc khác ý nghĩa.
Vòng đời	Các đối tượng dùng cùng tập trạng thái ở cấp logic.	Một chứng từ có trạng thái riêng như CANCELLED nhưng chứng từ kia không được phép có trạng thái đó.
Chủ sở hữu thuật ngữ	Cùng owner nghiệp vụ chịu trách nhiệm diễn giải mã.	Owner hoặc ngữ cảnh nghiệp vụ khác nhau, đặc biệt giữa bán hàng, sản xuất và tài chính.
Báo cáo	Có thể gộp báo cáo mà không cần quy tắc chuyển đổi.	Cần chuyển đổi, ánh xạ hoặc giải thích ngoại lệ trước khi so sánh.

Không được tự tạo biến thể tên chỉ để phù hợp với cách gọi địa phương, giao diện hoặc hệ thống nguồn. Ví dụ, nếu Customer là entity canonical thì các tên như “khách mua”, “đối tác mua hàng” hoặc client phải được ghi là thuật ngữ đồng nghĩa trong mô tả, không trở thành entity mới trừ khi có bằng chứng nghiệp vụ cho thấy đó là các đối tượng khác nhau. Khi một tên có thể liên quan định danh, chứng từ kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất lô, người soạn phải chuyển vấn đề đến vai trò có thẩm quyền theo quy tắc escalation của /01-curriculum/TRACEABILITY_ID_REGISTRY.md; việc chọn tên trong từ điển không thay thế xác minh pháp lý, kế toán, bảo mật hay vận hành.

Chính sách nguồn cho tiêu chuẩn, thực hành tốt, quy ước dự án và khuyến nghị tác giả

Chính sách nguồn xác định một phát biểu trong data dictionary được phép nói đến đâu. Nova Foods Trading & Manufacturing là case study ERP mô phỏng, chỉ dùng dữ liệu tổng hợp; vì vậy, nguồn được dùng để tăng tính nhất quán học tập và khả năng truy vết, không biến nội dung thành nghĩa vụ vận hành, tư vấn chuyên môn hoặc bằng chứng tuân thủ. Mỗi phát biểu có tác động quyết định phải ghi loại nguồn, tham chiếu nguồn hoặc artifact, giới hạn sử dụng và nhãn xác minh nếu cần. Lý do là cùng một nội dung, chẳng hạn cách mô tả trường dữ liệu cá nhân hoặc chứng từ kế toán, có giá trị khác nhau tùy nguồn là luật, chuẩn kỹ thuật, thực hành ngành hay đề xuất biên soạn.

Loại nguồn	Mục đích được phép trong data dictionary	Cách ghi nhận bắt buộc	Không được suy diễn
Tiêu chuẩn/quy định chuẩn tắc (normative standard: tài liệu đặt ra quy tắc chính thức trong phạm vi ban hành)	Dùng thuật ngữ, cấu trúc hoặc yêu cầu khi nội dung được kiểm chứng trực tiếp từ nguồn chính thức. Ví dụ: UML 2.5.1 cho ngữ nghĩa mô hình UML; OpenAPI Specification 3.1.1 cho mô tả HTTP API.	Ghi tên nguồn, tổ chức ban hành, phiên bản hoặc trạng thái đã biết, URL chính thức và giới hạn trích dẫn.	Không tự tạo số điều, số trang, câu chữ nguyên văn, hay kết luận vượt quá phần đã xác minh; không gọi một biểu đồ hoạt động PlantUML là BPMN.
Thực hành tốt ngành (industry good practice: cách làm được cộng đồng chuyên môn sử dụng để giảm rủi ro, không tự là luật)	Dùng để định hướng kiểm soát hoặc câu hỏi xem xét. Ví dụ: OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 hỗ trợ nhận diện nhu cầu bảo mật dữ liệu và API.	Ghi rõ đây là thực hành tốt hoặc nguồn tham khảo kỹ thuật, không phải quy định pháp luật Việt Nam.	Không biến khuyến nghị OWASP thành nghĩa vụ pháp lý, yêu cầu đã phê duyệt, hoặc bằng chứng hệ thống Nova Foods đạt an toàn thông tin.
Quy ước dự án (project convention: quy tắc nhất quán nội bộ của corpus)	Dùng để thống nhất tên artifact, định danh, ngôn ngữ, bối cảnh và nhãn kiểm soát. Ví dụ: tham chiếu đúng /01-curriculum/TRACEABILITY_ID_REGISTRY.md, CANONICAL_BUSINESS_RULES, vi-VN, Asia/Ho_Chi_Minh, VND.	Ghi artifact nguồn, phiên bản v0.9.0, trạng thái IN_REVIEW, ngày 2026-08-07 và phạm vi áp dụng trong corpus.	Không gọi quy ước này là tiêu chuẩn quốc tế, cấu hình ERP thực tế, baseline, approval hoặc quyết định của tổ chức ngoài case study.
Khuyến nghị tác giả (author recommendation: đề xuất có lý do của người biên soạn)	Dùng khi nguồn không quy định chi tiết nhưng cần một lựa chọn minh bạch để người học mô hình hóa nhất quán.	Bắt buộc gắn nhãn Author recommendation, nêu lý do và ranh giới. Ví dụ: “Author recommendation: ưu tiên một tên thuộc tính rõ nghĩa thay vì viết tắt khó hiểu để giảm diễn giải khác nhau.”	Không trình bày như yêu cầu pháp lý, chuẩn bắt buộc, quyết định kiến trúc, hoặc ý kiến đã được Business Owner, Legal, Accounting, Security hay Architect xác nhận.

Quy tắc ưu tiên nguồn: khi các nguồn dẫn đến cách diễn giải khác nhau, nguồn chính thức có thẩm quyền trong đúng lĩnh vực được ưu tiên hơn thực hành tốt; thực hành tốt được ưu tiên hơn khuyến nghị tác giả; quy ước dự án chỉ điều phối tính nhất quán nội bộ và không được ghi đè luật, quy định, chuẩn kỹ thuật hoặc quyết định chuyên môn có thẩm quyền. Cầu nối suy luận là: thẩm quyền ban hành xác định phạm vi ràng buộc, còn mức độ gần với Nova Foods mô phỏng xác định mức hữu ích cho việc biên soạn; hai tiêu chí này không thể thay thế nhau.

Tình huống biên soạn	Phân loại nguồn và cách xử lý
Cần dùng thuật ngữ phân tích nghiệp vụ như yêu cầu, stakeholder hoặc traceability	Có thể tham chiếu BABOK Guide Version 3 theo phần tổng quan và errata chính thức của IIBA. Không ghi số trang hoặc điều khoản khi chưa truy cập văn bản được cấp phép.
Cần diễn giải cách mô tả quan hệ trong sơ đồ	Có thể dùng UML 2.5.1 của OMG làm nguồn chuẩn tắc cho ngữ nghĩa UML. Nếu chỉ dùng bảng Markdown, bảng là quy ước trình bày của artifact chứ không phải sơ đồ UML.
Cần đề xuất kiểm soát bảo mật cho thuộc tính hoặc tích hợp	Tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 như thực hành tốt; ghi rõ đề xuất chỉ là đầu vào xem xét bảo mật.
Nguồn chính thức chưa xác minh chi tiết hoặc cần diễn giải chuyên môn	Ghi Verification required; không thay thế khoảng trống bằng suy đoán. Khi chỉ cần giả định học liệu không mang tính nghĩa vụ, ghi Project assumption và mô tả giới hạn.
Cần chọn cách đặt tên hoặc cách diễn đạt để người học dễ theo dõi	Ghi Author recommendation, nêu tiêu chí rõ nghĩa, nhất quán và khả năng truy vết; không gán đề xuất này cho tiêu chuẩn hay nguồn bên ngoài.

Mọi tham chiếu tới /01-curriculum/TRACEABILITY_ID_REGISTRY.md và /01-curriculum/CANONICAL_BUSINESS_RULES.md phải giữ nguyên đường dẫn và định danh canonical. Hai artifact này đang ở trạng thái IN_REVIEW, phiên bản v0.9.0; do đó chúng là nguồn quy ước và truy vết đang xem xét trong corpus, không phải xác nhận nội dung đã baseline, đã phê duyệt hoặc sẵn sàng áp dụng thực tế.

Xử lý bắt buộc xác minh đối với tuyên bố pháp lý, kế toán, thuế, quyền riêng tư, an toàn thực phẩm và truy xuất nguồn gốc

Nova Foods là case study ERP mô phỏng, chỉ sử dụng dữ liệu tổng hợp; vì vậy, mọi phát biểu có thể bị hiểu là nghĩa vụ áp dụng thực tế phải được phân loại trước khi đưa vào data dictionary. Lý do là một thuộc tính như số hóa đơn, mã số thuế, người liên hệ, hạn sử dụng hoặc mã lô có thể đồng thời mang ý nghĩa nghiệp vụ và tạo tác động pháp lý, kế toán, quyền riêng tư hoặc an toàn thực phẩm. Data dictionary được phép mô tả mục đích dữ liệu và nhu cầu xác minh, nhưng không được tự chuyển mô tả đó thành kết luận tuân thủ, diễn giải luật, quy tắc hạch toán, nghĩa vụ thuế, yêu cầu thu hồi hay yêu cầu vận hành production.

Nhóm tuyên bố	Dấu hiệu kích hoạt nhãn Verification required	Nguồn chính thức được phép đối chiếu	Vai trò phải xác minh	Cách ghi trong data dictionary khi chưa xác minh
Pháp lý và quyền riêng tư	Khẳng định về căn cứ xử lý, quyền của chủ thể dữ liệu, thời hạn lưu, chia sẻ, chuyển dữ liệu hoặc nghĩa vụ thông báo liên quan dữ liệu cá nhân.	Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, truy cập ngày 2026-08-07.	Legal Owner và Security; Business Owner xác nhận mục đích nghiệp vụ.	Ghi Verification required; nêu dữ liệu dự kiến, mục đích mô phỏng và câu hỏi cần xác minh; không ghi “tuân thủ luật” hoặc “được phép xử lý”.
Kế toán	Khẳng định về bút toán, kỳ kế toán, chứng từ, giá vốn, doanh thu, lưu trữ sổ sách hoặc tính hợp lệ của ghi nhận tài chính.	Luật Kế toán 88/2015/QH13, truy cập ngày 2026-08-07.	Accounting Owner; Legal Owner khi nội dung có diễn giải pháp lý.	Ghi Verification required hoặc Project assumption; phân biệt rõ minh họa học liệu với chính sách hạch toán thực tế.
Thuế và hóa đơn	Khẳng định về thuế suất, nghĩa vụ kê khai, điều kiện hóa đơn, thời điểm lập hóa đơn, ký số hoặc xử lý điều chỉnh chứng từ.	Nghị định 123/2020/NĐ-CP, truy cập ngày 2026-08-07; phải kiểm tra sửa đổi còn hiệu lực trước khi áp dụng thực tế.	Accounting Owner và Legal Owner.	Ghi Verification required; không gán thuế suất, không kết luận hóa đơn hợp lệ và không mô tả cấu hình thuế production.
An toàn thực phẩm	Khẳng định về tiêu chuẩn an toàn, điều kiện sản xuất, bảo quản, chất lượng, thu hồi, tiêu hủy hoặc trách nhiệm đối với thực phẩm.	Luật An toàn thực phẩm 55/2010/QH12, truy cập ngày 2026-08-07.	Legal Owner và Food-safety/Production Domain Owner.	Ghi Verification required; mô tả đây là điểm dữ liệu hoặc tình huống mô phỏng, không phải hướng dẫn an toàn thực phẩm.
Truy xuất nguồn gốc	Khẳng định rằng dữ liệu lô, nguyên liệu, thành phẩm, hạn dùng hoặc giao dịch đủ để đáp ứng nghĩa vụ truy xuất, thu hồi hay kiểm tra thực tế.	Luật An toàn thực phẩm 55/2010/QH12 là ngữ cảnh pháp lý ban đầu; yêu cầu đối chiếu quy định hiện hành và quy trình được thẩm quyền xác nhận.	Food-safety/Production Domain Owner, Legal Owner, Architect khi có tích hợp.	Ghi Verification required; không gọi liên kết dữ liệu là “đủ truy xuất” hoặc “đáp ứng thu hồi” khi chưa có bằng chứng xác minh.

Quy tắc nhãn: Verification required áp dụng khi nguồn chính thức, hiệu lực hiện hành, phạm vi áp dụng, hoặc kết luận của vai trò có thẩm quyền chưa được ghi nhận. Project assumption chỉ áp dụng cho giả định học liệu không được trình bày như nghĩa vụ pháp lý hay chuẩn vận hành. Hai nhãn này không thay thế nhau: một giả định về trường dữ liệu có thể vẫn cần Verification required nếu nó tác động đến hóa đơn, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc.

Quy tắc bằng chứng: một tuyên bố chỉ được bỏ nhãn Verification required khi artifact liên quan lưu được: (1) URL nguồn chính thức hoặc tham chiếu kiểm soát tương đương; (2) ngày truy cập hoặc ngày hiệu lực được kiểm tra; (3) nội dung được xác minh ở mức đủ để hỗ trợ tuyên bố, không bịa số điều hoặc câu chữ; (4) vai trò xác minh có thẩm quyền; và (5) phạm vi kết luận, ví dụ chỉ áp dụng cho dữ liệu mô phỏng hay cho một phương án thiết kế. Nếu thiếu một trong năm thành phần, data dictionary phải giữ nhãn xác minh và không được dùng các từ “compliant”, “hợp pháp”, “hợp lệ”, “đủ điều kiện” hoặc “bắt buộc” như kết luận đã chốt.

Quy tắc diễn đạt: thuộc tính có rủi ro xác minh phải tách ba lớp thông tin: mục đích nghiệp vụ mô phỏng, yêu cầu xác minh, và giới hạn kết luận. Ví dụ, CustomerContactPhone có thể được mô tả là dữ liệu liên hệ dự kiến phục vụ tình huống chăm sóc khách hàng mô phỏng; tuy nhiên, không được suy ra căn cứ xử lý, thời hạn lưu hoặc quyền chia sẻ số điện thoại. Tương tự, LotCode có thể hỗ trợ liên kết nguyên liệu, sản xuất và tồn kho trong bài học, nhưng không được tuyên bố tự động đáp ứng yêu cầu truy xuất hoặc thu hồi thực tế.

Mọi vấn đề thuộc từ hai nhóm trở lên phải được chuyển đồng thời đến các vai trò liên quan. Ví dụ, dữ liệu hóa đơn có thể cần Accounting Owner, Legal Owner, Security và Architect cùng xem xét vì nó liên quan chứng từ, thuế, quyền truy cập và tích hợp; tác giả curriculum chỉ ghi nhận câu hỏi, bằng chứng và trạng thái truy vết. Tại v0.9.0, trạng thái corpus là IN_REVIEW; việc có nhãn, nguồn hoặc vai trò được nêu trong tài liệu không tạo approval, baseline, xác nhận tuân thủ hoặc quyền áp dụng cho Nova Foods.

03. Core Master Data Entities and Ownership Model

Dữ liệu chủ (master data) là dữ liệu mô tả đối tượng nghiệp vụ tương đối ổn định, được nhiều giao dịch dùng lại, chẳng hạn khách hàng được tham chiếu bởi đơn bán hàng. Dữ liệu chủ không phải là giao dịch phát sinh như đơn hàng, phiếu nhập hay bút toán. Với Nova Foods Trading & Manufacturing là case study ERP mô phỏng, catalog dưới đây xác định ranh giới nghĩa nghiệp vụ và chủ sở hữu nghiệp vụ (Business Owner): vai trò chịu trách nhiệm quyết định ý nghĩa, điều kiện sử dụng và thay đổi nghiệp vụ của thực thể. Data Steward là vai trò quản trị dữ liệu hằng ngày theo quyết định đó; Steward không tự thay đổi chính sách nghiệp vụ.

Thực thể dữ liệu chủ	Định nghĩa nghiệp vụ	Business Owner	Data Steward	Ranh giới và lý do phân quyền
Customer	Hồ sơ tổ chức hoặc cá nhân mua hàng, nhận hàng, thanh toán hoặc được quản lý quan hệ bán hàng trong tình huống mô phỏng.	Sales Owner	Sales Operations hoặc Customer Master Data Steward	Sales Owner quyết định tiêu chí phân đoạn, điều kiện phục vụ và quy tắc dùng khách hàng trong bán hàng; Steward duy trì chất lượng hồ sơ theo quyết định đó. Customer không đại diện cho một đơn bán hàng cụ thể.
Supplier	Hồ sơ tổ chức hoặc cá nhân cung cấp nguyên liệu, hàng hóa, dịch vụ hoặc dịch vụ logistics cho Nova Foods mô phỏng.	Procurement Owner	Procurement Master Data Steward	Procurement Owner quyết định quan hệ nguồn cung và điều kiện sử dụng nhà cung cấp; Steward quản trị hồ sơ. Supplier không phải chứng từ yêu cầu mua, đơn mua hoặc hóa đơn.
Product/SKU	Danh mục mặt hàng mà Nova Foods mô phỏng mua, sản xuất, tồn, bán hoặc quản lý. SKU (Stock Keeping Unit) là đơn vị mã hàng dùng để phân biệt một biến thể hàng hóa có thể được quản lý tồn kho riêng.	Product Owner	Product Master Data Steward	Product Owner quyết định ý nghĩa thương mại và vòng đời danh mục hàng; Steward bảo đảm dữ liệu mô tả nhất quán. SKU không thay thế lô hàng, số lượng tồn hoặc công thức sản xuất.
Warehouse	Địa điểm quản lý tồn kho ở cấp kho, ví dụ kho nguyên liệu hoặc kho thành phẩm trong kịch bản học tập.	Supply Chain Owner	Warehouse Master Data Steward	Supply Chain Owner quyết định phạm vi vận hành và cách phân biệt các kho; Steward duy trì danh mục. Warehouse là cấp địa điểm quản lý, không phải một vị trí chứa hàng cụ thể.
Location/Bin	Vị trí vật lý hoặc logic bên trong warehouse dùng để định vị hàng. Bin là ô, kệ, ngăn hoặc vị trí chứa được định danh để hỗ trợ thao tác kho.	Warehouse Operations Owner	Inventory/Warehouse Data Steward	Warehouse Operations Owner quyết định cấu trúc vị trí phù hợp với vận hành mô phỏng; Steward duy trì sơ đồ vị trí. Location/Bin không tự xác nhận số lượng hàng đang có tại vị trí.
Unit of Measure	Danh mục đơn vị đo dùng nhất quán khi ghi nhận số lượng, khối lượng, thể tích hoặc đơn vị bao gói.	Supply Chain Owner	Master Data Steward	Supply Chain Owner chịu trách nhiệm về ý nghĩa vận hành của đơn vị đo giữa mua, tồn và bán. Thực thể này không tự xác định quy đổi cho từng SKU; quan hệ quy đổi là nội dung mô hình chi tiết cần được xác định riêng.
Price List	Danh mục điều kiện giá có tên, phạm vi áp dụng nghiệp vụ và thời gian hiệu lực dự kiến cho hoạt động bán hoặc mua trong case study.	Commercial Owner đối với giá bán; Procurement Owner đối với giá mua	Pricing Data Steward hoặc Procurement Data Steward	Chủ sở hữu tách theo quyết định thương mại: giá bán thuộc Commercial, giá mua thuộc Procurement. Price List không phải báo giá, đơn hàng hay hóa đơn và không tự là cam kết giá thực tế.
Chart-of-Accounts Reference	Danh mục tham chiếu các tài khoản kế toán dùng để phân loại nghiệp vụ tài chính trong mô hình ERP. Chart of Accounts là hệ thống danh mục tài khoản kế toán.	Accounting Owner	Finance Master Data Steward	Accounting Owner quyết định cách diễn giải và sử dụng tài khoản trong case study; Steward duy trì danh mục theo quyết định đó. Thực thể này không phải bút toán, sổ cái hoặc kết luận về chế độ kế toán thực tế.
Employee/Approver Reference	Hồ sơ tham chiếu người lao động hoặc vai trò có thể được gán để khởi tạo, kiểm tra hoặc phê duyệt hoạt động mô phỏng. Approver là người hoặc vai trò được chỉ định để thực hiện bước phê duyệt.	HR Owner cho hồ sơ nhân sự; Process Owner cho quyền phê duyệt theo quy trình	HR Data Steward; Workflow Administration Steward	HR Owner quản lý ý nghĩa hồ sơ nhân sự; Process Owner quyết định ai hoặc vai trò nào được tham chiếu trong luồng phê duyệt mô phỏng. Thực thể này không phải bằng chứng về quan hệ lao động, thẩm quyền pháp lý hoặc một quyết định đã được phê duyệt.

Quy tắc phân định ownership: một thực thể chỉ có một Business Owner chịu trách nhiệm quyết định chính đối với ý nghĩa nghiệp vụ. Khi một thực thể phục vụ hai miền có quyền quyết định khác nhau, catalog phải tách trách nhiệm theo mục đích sử dụng thay vì gán quyền mơ hồ. Price List là ví dụ: giá bán và giá mua có thể cùng là “giá”, nhưng nguồn quyết định thương mại khác nhau, nên không nên coi là một quyền sở hữu không phân biệt.

Nguyên tắc dữ liệu tổng hợp và an toàn riêng tư: mọi bản ghi minh họa của các thực thể trên tại Nova Foods phải là dữ liệu tổng hợp. Tên người, số điện thoại, địa chỉ, email, mã số, tên tổ chức và thông tin tài chính trong ví dụ học tập không được sao chép từ cá nhân, khách hàng, nhà cung cấp hoặc nhân viên thực tế. Employee/Approver Reference chỉ nên dùng nhân vật mô phỏng và vai trò mô phỏng, vì việc gắn dữ liệu nhận diện với quyền phê duyệt có rủi ro riêng tư và kiểm soát truy cập. Phân loại độ nhạy cảm, thời hạn lưu, hệ thống nguồn, khóa định danh, thuộc tính chi tiết và tập giá trị được phép được xử lý ở các micro-batch chuyên biệt tiếp theo; tại v0.9.0 mọi nội dung vẫn ở trạng thái IN_REVIEW.

Hệ thống nguồn chuẩn cho dữ liệu chủ (System of Record)

System of Record (SoR) là hệ thống hoặc miền dữ liệu duy nhất có thẩm quyền ghi nhận và sửa đổi bản ghi chuẩn của một thực thể. Suy luận này cần thiết vì cùng một khách hàng hoặc SKU có thể xuất hiện trong bán hàng, mua hàng và báo cáo; nếu nhiều nơi cùng được phép sửa bản ghi gốc, các bản sao có thể mâu thuẫn. Trong Nova Foods mô phỏng, SoR dưới đây là Project assumption phục vụ thiết kế học liệu tại trạng thái IN_REVIEW, không phải xác nhận cấu hình ERP thực tế.

Thực thể dữ liệu chủ	SoR logic được chỉ định	Ranh giới quyết định và sử dụng
Khách hàng	NovaERP-MDM — miền Master Data Management (quản trị dữ liệu chủ)	Bản ghi khách hàng chuẩn được tạo và điều chỉnh tại NovaERP-MDM; phân hệ bán hàng chỉ tiêu thụ bản sao được đồng bộ, không trở thành nguồn chuẩn thứ hai.
Nhà cung cấp	NovaERP-MDM	Miền mua hàng và công nợ phải tham chiếu dữ liệu nhà cung cấp từ NovaERP-MDM; dữ liệu nhập tại chứng từ mua không được tự ghi đè dữ liệu chủ.
Sản phẩm/SKU	NovaERP-MDM	NovaERP-MDM là nguồn chuẩn cho danh mục SKU dùng chung cho bán hàng, mua hàng, kho và sản xuất mô phỏng; từng phân hệ chỉ lưu tham chiếu hoặc bản sao phục vụ xử lý.
Kho	NovaERP-MDM	Danh mục kho được quản trị tập trung để tránh một kho vật lý mô phỏng được đặt nhiều mã khác nhau giữa tồn kho và sản xuất.
Vị trí/Bin	NovaERP-WMS — miền Warehouse Management System (quản lý kho)	NovaERP-WMS là nguồn chuẩn vì vị trí/bin thuộc tổ chức vận hành nội bộ của kho; NovaERP-MDM chỉ có thể nhận bản sao tham chiếu nếu cần tra cứu liên miền.
Đơn vị tính	NovaERP-MDM	Danh mục đơn vị tính chuẩn được dùng xuyên suốt các miền nghiệp vụ; không được để từng phân hệ tự duy trì danh mục đơn vị riêng.
Bảng giá	NovaERP-COM — miền Commercial Management (quản lý thương mại)	NovaERP-COM là nguồn chuẩn cho bảng giá mô phỏng vì đây là nơi áp dụng chính sách thương mại; hệ thống bán hàng sử dụng giá đã công bố từ miền này.
Tham chiếu hệ thống tài khoản	NovaERP-FIN — miền Financial Management (quản lý tài chính)	NovaERP-FIN là nguồn chuẩn vì hệ thống tài khoản phục vụ phân loại và báo cáo tài chính; các miền khác chỉ chọn mã tham chiếu, không tự tạo mã tài khoản.
Tham chiếu nhân viên/người phê duyệt	NovaHR-REF — miền HR Reference (tham chiếu nhân sự)	NovaHR-REF là nguồn chuẩn cho danh tính nhân viên và khả năng được tham chiếu trong luồng phê duyệt; ERP chỉ nhận dữ liệu tham chiếu cần thiết, không trở thành nguồn hồ sơ nhân sự.

Quy tắc tích hợp là: mọi yêu cầu tạo, sửa, ngừng sử dụng hoặc hợp nhất bản ghi dữ liệu chủ phải đi tới SoR đã chỉ định; hệ thống nhận dữ liệu chỉ được lưu bản sao đồng bộ có truy vết nguồn. Nếu một bản sao khác SoR, SoR được ưu tiên khi đối soát, trừ khi lỗi đồng bộ hoặc ngoại lệ được ghi nhận để xem xét. Điều này là suy luận từ nguyên tắc một nguồn chuẩn duy nhất: chỉ một điểm có quyền cập nhật mới giúp xác định bản ghi nào cần được khắc phục khi có xung đột.

Các tên hệ thống NovaERP-MDM, NovaERP-WMS, NovaERP-COM, NovaERP-FIN và NovaHR-REF là nhãn miền logic tổng hợp cho case study Nova Foods, không xác nhận sản phẩm phần mềm, kiến trúc tích hợp hoặc môi trường production. Nova Foods là bối cảnh mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp; không nhập tên, thông tin liên hệ, hồ sơ nhân sự hoặc dữ liệu của cá nhân, khách hàng hay nhà cung cấp thực tế vào bất kỳ SoR mô phỏng nào. Mọi thay đổi làm phát sinh quyết định về dữ liệu cá nhân, kế toán hoặc kiến trúc tích hợp phải mang nhãn Verification required và được chuyển đến vai trò có thẩm quyền phù hợp.

Khóa chính và khóa thay thế cho dữ liệu chủ

Khóa chính (primary key, PK) là mã định danh kỹ thuật duy nhất cho một bản ghi; ERP dùng PK để liên kết ổn định giữa các bảng ngay cả khi mã nghiệp vụ hiển thị thay đổi. Khóa thay thế (alternate key, AK) là một giá trị hoặc tổ hợp giá trị có ý nghĩa nghiệp vụ và cũng phải duy nhất; AK hỗ trợ tìm kiếm, nhập liệu, tích hợp và phát hiện trùng lặp. Nova Foods là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; các mẫu mã dưới đây là quy ước mô hình hóa dự kiến, trạng thái IN_REVIEW, không phải cấu hình ERP production.

Thực thể master	Khóa chính canonical	Khóa thay thế được kiểm soát	Quy tắc nhận diện và ranh giới
Khách hàng (Customer)	customer_id	customer_code; khi có định danh bên ngoài, dùng tổ hợp external_source_code + external_customer_reference	customer_id là khóa liên kết nội bộ. customer_code là mã khách hàng nhìn thấy trong nghiệp vụ mô phỏng, ví dụ CUS-SYN-0001. Không dùng tên khách hàng làm AK vì tên có thể trùng hoặc đổi.
Nhà cung cấp (Supplier)	supplier_id	supplier_code; khi có nguồn ngoài, dùng external_source_code + external_supplier_reference	supplier_code, ví dụ SUP-SYN-0001, phải định danh một nhà cung cấp mô phỏng duy nhất. Không dùng tên thương mại làm khóa vì một tên có thể có nhiều cách viết.
Sản phẩm/SKU (Product)	product_id	sku	SKU (stock keeping unit, đơn vị lưu kho) định danh một biến thể hàng hóa có thể mua, bán, sản xuất hoặc tồn kho riêng. Một sku, ví dụ SKU-SYN-001, chỉ ánh xạ đến một product_id; không tái sử dụng SKU cho sản phẩm khác sau khi đã được tham chiếu.
Kho (Warehouse)	warehouse_id	warehouse_code	warehouse_code, ví dụ WH-SYN-HCM-01, định danh một kho logic trong mô phỏng. Mã kho không được suy diễn là địa chỉ, pháp nhân hoặc cơ sở thực tế.
Vị trí/bin (LocationBin)	location_bin_id	Tổ hợp warehouse_id + bin_code	Bin là vị trí chứa hàng chi tiết bên trong kho. bin_code chỉ duy nhất trong phạm vi một warehouse_id, ví dụ cùng mã A-01-01 có thể tồn tại tại hai kho khác nhau nhưng không thể trùng trong cùng kho.
Đơn vị tính (UnitOfMeasure)	uom_id	uom_code	uom_code, ví dụ KG, THUNG, CAI, là mã đơn vị dùng thống nhất trong corpus. Mã này định danh đơn vị logic, không tự xác nhận quy đổi, trọng lượng hay tiêu chuẩn đo lường thực tế.
Bảng giá (PriceList)	price_list_id	Tổ hợp price_list_code + version_no	Một price_list_code, ví dụ PL-SYN-RETAIL, có thể có nhiều phiên bản; vì vậy chỉ tổ hợp với version_no mới là AK. Không dùng tên bảng giá làm khóa vì tên mô tả có thể thay đổi.
Tham chiếu hệ thống tài khoản (ChartOfAccountsReference)	coa_account_id	account_code	account_code, ví dụ 511-SYN, là mã tài khoản trong bối cảnh học liệu. Mã này chỉ là tham chiếu mô hình và không xác nhận hệ thống tài khoản, hạch toán hoặc nghĩa vụ kế toán thực tế; nội dung liên quan cần Verification required bởi vai trò Accounting.
Nhân viên/người phê duyệt (EmployeeApproverReference)	employee_id	employee_code; nếu liên kết danh tính kỹ thuật, dùng identity_subject_id làm AK kỹ thuật riêng	employee_code, ví dụ EMP-SYN-0001, nhận diện nhân sự tổng hợp trong luồng phê duyệt. identity_subject_id không thay thế employee_id: một là định danh danh tính đăng nhập, một là định danh tham chiếu nhân sự nghiệp vụ.

Quy tắc chung là PK phải bất biến sau khi tạo và không mang ý nghĩa nghiệp vụ có thể đổi. AK phải được kiểm tra duy nhất sau khi chuẩn hóa định dạng, gồm loại bỏ khoảng trắng đầu-cuối và áp dụng quy tắc chữ hoa/chữ thường nhất quán cho mã. Một bản ghi ngừng sử dụng vẫn giữ PK và AK lịch sử để bảo toàn liên kết; không được tái gán mã đã từng tham chiếu sang bản ghi mới. Suy luận này dựa trên mục tiêu của master data là tạo điểm neo ổn định cho giao dịch: nếu mã bị tái sử dụng, giao dịch cũ có thể bị diễn giải nhầm là thuộc đối tượng mới.

Dữ liệu ví dụ như CUS-SYN-0001, SUP-SYN-0001, SKU-SYN-001 và EMP-SYN-0001 phải luôn là dữ liệu tổng hợp. Không đưa tên cá nhân thật, số liên hệ thật, mã số thuế thật, định danh đăng nhập thật hoặc mã khách hàng/nhà cung cấp của tổ chức thực vào AK. Việc đánh giá liệu một AK có thể làm lộ dữ liệu cá nhân hoặc dữ liệu định danh ngoài mô phỏng cần nhãn Verification required và được chuyển cho Security cùng Legal Owner theo ranh giới thẩm quyền của corpus.

Thuộc tính nghiệp vụ trọng yếu của các thực thể dữ liệu chủ

Dữ liệu chủ là dữ liệu mô tả đối tượng được dùng lặp lại trong nhiều giao dịch, khác với dữ liệu phát sinh của một đơn hàng hoặc một phiếu nhập riêng lẻ. Vì Nova Foods là case study ERP mô phỏng, các thuộc tính dưới đây được chọn theo lập luận: một giao dịch chỉ có thể được hiểu, đối soát và báo cáo nhất quán nếu thông tin nhận diện nghiệp vụ, điều kiện giao dịch và ngữ cảnh vận hành của đối tượng được lưu một lần tại dữ liệu chủ. Bảng này chỉ xác định thuộc tính trọng yếu và ý nghĩa nghiệp vụ; khóa, ownership, system of record, kiểu dữ liệu, danh mục giá trị, nhạy cảm, lưu giữ và quy tắc kiểm tra được xử lý tại phần chuyên biệt của tài liệu.

Thực thể dữ liệu chủ	Thuộc tính trọng yếu	Ý nghĩa nghiệp vụ
Khách hàng	Tên pháp lý hoặc tên giao dịch; nhóm khách hàng; địa chỉ thanh toán; địa chỉ giao hàng; người liên hệ; kênh bán hàng; điều khoản thanh toán dự kiến; điều kiện giao hàng dự kiến; trạng thái quan hệ thương mại	Phân biệt bên mua, xác định nơi nhận hàng và nơi nhận chứng từ, đồng thời cung cấp ngữ cảnh để bán hàng, giao vận và công nợ mô phỏng diễn giải cùng một khách hàng theo cùng một cách. “Dự kiến” thể hiện đây là thông tin mặc định của dữ liệu chủ, không thay thế điều khoản được ghi nhận trên từng giao dịch.
Nhà cung cấp	Tên pháp lý hoặc tên giao dịch; nhóm nhà cung cấp; địa chỉ giao dịch; người liên hệ; nhóm hàng hoặc dịch vụ cung ứng; điều khoản thanh toán dự kiến; điều kiện giao nhận dự kiến; trạng thái đủ điều kiện giao dịch	Hỗ trợ mua hàng xác định đúng đối tác, phạm vi cung ứng và thông tin liên hệ. Thuộc tính về đủ điều kiện chỉ là nhãn nghiệp vụ mô phỏng để phân biệt khả năng sử dụng nhà cung cấp trong luồng học tập; không phải kết luận pháp lý, chất lượng hay an toàn thực phẩm.
Sản phẩm/SKU	Tên sản phẩm; mô tả thương mại; nhóm sản phẩm; nhãn hàng; dạng hàng hóa; đơn vị tính cơ sở; quy cách đóng gói; điều kiện bảo quản; có theo dõi lô; có theo dõi hạn dùng; trạng thái kinh doanh	SKU (Stock Keeping Unit, đơn vị lưu kho được quản lý riêng) đại diện cho một mặt hàng có thể mua, sản xuất, lưu kho hoặc bán. Các thuộc tính này quyết định cách người học diễn giải hàng hóa: ví dụ, quy cách đóng gói giúp phân biệt một chai lẻ với một thùng chứa nhiều chai, còn cờ theo dõi lô và hạn dùng tạo ngữ cảnh cho truy xuất mô phỏng.
Kho	Tên kho; loại kho; địa chỉ hoặc khu vực vận hành; điều kiện bảo quản tổng quát; đơn vị vận hành; khả năng nhận hàng; khả năng xuất hàng; trạng thái hoạt động	Kho là không gian quản lý tồn kho ở cấp vận hành. Loại kho và khả năng nhận hoặc xuất hàng giúp phân biệt kho nguyên liệu, kho thành phẩm hoặc khu vực không dùng để giao nhận trong mô hình học tập, mà không suy diễn cấu hình kho thực tế.
Vị trí/bin	Tên hiển thị vị trí; kho trực thuộc; khu vực; dãy kệ; tầng hoặc ô chứa; loại vị trí; sức chứa mô phỏng; trạng thái khả dụng	Bin là vị trí lưu trữ chi tiết bên trong kho. Các thành phần vị trí giúp nhân viên mô phỏng biết nơi cất hoặc lấy hàng, còn sức chứa mô phỏng hỗ trợ giải thích vì sao một vị trí có thể không phù hợp để đưa thêm hàng vào.
Đơn vị tính	Tên đơn vị tính; ký hiệu hiển thị; mô tả sử dụng; nhóm đo lường; đơn vị tính cơ sở liên quan; hệ số quy đổi nghiệp vụ	Đơn vị tính chuẩn hóa cách biểu đạt số lượng như cái, chai, thùng hoặc kilôgam. Hệ số quy đổi nghiệp vụ cho phép cùng một sản phẩm được mua theo thùng nhưng quản lý tồn theo chai, với điều kiện quy đổi được xác định rõ trong mô hình dữ liệu.
Bảng giá	Tên bảng giá; loại giá; tiền tệ áp dụng; phạm vi khách hàng hoặc nhóm khách hàng; phạm vi sản phẩm hoặc nhóm sản phẩm; ngày hiệu lực; ngày kết thúc hiệu lực; mức giá; trạng thái áp dụng	Bảng giá là tập hợp điều kiện giá dùng lặp lại thay vì nhập lại giá cho từng giao dịch. Khoảng hiệu lực cho phép mô hình giải thích vì sao cùng một sản phẩm có thể có giá khác nhau theo thời điểm hoặc theo nhóm khách hàng; VND chỉ là tiền tệ của bối cảnh mô phỏng.
Tham chiếu hệ thống tài khoản	Tên tài khoản; loại tài khoản; nhóm tài khoản; cấp tài khoản; tính chất tăng giảm dự kiến; phạm vi sử dụng nghiệp vụ; trạng thái sử dụng	Thực thể này cung cấp từ điển tham chiếu để diễn giải tài khoản trong các ví dụ tích hợp kế toán. Thuộc tính “tính chất tăng giảm dự kiến” và “phạm vi sử dụng” chỉ phục vụ học liệu, không cấu thành hướng dẫn hạch toán, cấu hình sổ cái hoặc kết luận theo Luật Kế toán. Verification required: mọi diễn giải áp dụng thực tế phải được Accounting Owner và vai trò có thẩm quyền xác minh.
Nhân viên	Họ tên hiển thị; đơn vị tổ chức; chức danh; vai trò nghiệp vụ; địa điểm làm việc; thông tin liên hệ công việc; ngày bắt đầu hiệu lực; ngày kết thúc hiệu lực; trạng thái làm việc	Tham chiếu nhân viên giúp gắn hoạt động mô phỏng với người thực hiện, người tạo yêu cầu hoặc người phụ trách vận hành. Khoảng hiệu lực ngăn việc diễn giải một tham chiếu cũ là còn có hiệu lực tại thời điểm giao dịch.
Người phê duyệt	Nhân viên tham chiếu; phạm vi phê duyệt; cấp phê duyệt; đơn vị tổ chức áp dụng; ngưỡng giá trị mô phỏng; người thay thế; thời gian hiệu lực; trạng thái ủy quyền hoặc khả dụng	Người phê duyệt là lớp tham chiếu nghiệp vụ gắn với nhân viên, không phải một bản sao tùy ý của hồ sơ nhân viên. Các thuộc tính này cho phép mô hình mô phỏng tuyến phê duyệt theo phạm vi và thời hạn; ngưỡng giá trị chỉ là giả định học tập, không phải thẩm quyền tài chính thực tế.

Để bảo đảm mô hình riêng tư an toàn, mọi tên người, số liên hệ, địa chỉ, tổ chức và số liệu minh họa được dùng cho Nova Foods phải là dữ liệu tổng hợp. Không được đưa dữ liệu cá nhân, thông tin liên hệ, quan hệ lao động hoặc dữ liệu thương mại của cá nhân, khách hàng hay nhà cung cấp thực vào các thuộc tính ví dụ. Việc mô hình có các thuộc tính liên quan con người là cần thiết để dạy quan hệ ERP; việc sử dụng dữ liệu tổng hợp bảo đảm bài học không biến thành hồ sơ của đối tượng thực.

Phân loại nhạy cảm và lưu giữ dữ liệu cho thực thể dữ liệu chủ

Phân loại nhạy cảm là nhãn cho biết mức độ cần bảo vệ khi truy cập, hiển thị, xuất hoặc chia sẻ dữ liệu. Phân loại lưu giữ là nhãn định hướng thời gian và điều kiện giữ lại dữ liệu trước khi xóa, ẩn danh hóa hoặc chuyển lưu trữ; đây không phải thời hạn pháp lý đã được xác nhận. Nova Foods là case study ERP mô phỏng, chỉ dùng dữ liệu tổng hợp. Vì vậy, bảng dưới đây là mô hình học liệu và không xác lập nghĩa vụ pháp lý, kế toán, lao động, thuế hoặc bảo vệ dữ liệu cá nhân cho một tổ chức thực tế.

Thực thể dữ liệu chủ	Phân loại nhạy cảm	Cơ sở phân loại	Phân loại lưu giữ	Điểm kết thúc lưu giữ mô phỏng	Hành động sau lưu giữ
Khách hàng	CONFIDENTIAL_PERSONAL khi chứa tên người liên hệ, số điện thoại, email hoặc địa chỉ; INTERNAL khi chỉ là mã khách hàng tổng hợp	Dữ liệu liên hệ có thể nhận diện cá nhân, kể cả khi gắn với khách hàng tổ chức	COMMERCIAL_AND_PRIVACY_REVIEW	Quan hệ kinh doanh mô phỏng chấm dứt và các liên kết giao dịch, kế toán, khiếu nại đã được xử lý theo chính sách được xác minh	Xóa hoặc ẩn danh hóa thuộc tính nhận diện; giữ mã kỹ thuật chỉ khi còn cần cho tính toàn vẹn tham chiếu
Nhà cung cấp	CONFIDENTIAL_PERSONAL khi chứa người liên hệ, thông tin thanh toán hoặc định danh cá nhân; INTERNAL cho mã và phân nhóm nhà cung cấp tổng hợp	Thông tin liên hệ và thanh toán có nguy cơ lộ dữ liệu cá nhân hoặc thông tin thương mại	COMMERCIAL_AND_PRIVACY_REVIEW	Quan hệ mua hàng mô phỏng kết thúc và không còn nhu cầu đối chiếu nghiệp vụ	Ẩn danh hóa dữ liệu liên hệ; đánh giá riêng mọi liên kết đến chứng từ kế toán
Sản phẩm/SKU	INTERNAL	Tên hàng, quy cách, nhóm hàng và trạng thái kinh doanh mô phỏng là thông tin nội bộ; không mặc định là dữ liệu cá nhân	PRODUCT_LIFECYCLE	SKU bị ngừng sử dụng và không còn được tham chiếu bởi lịch sử cần bảo toàn	Chuyển sang trạng thái lưu trữ logic; không tái sử dụng mã SKU để tránh sai lệch lịch sử
Kho	INTERNAL	Tên, mã và năng lực kho mô phỏng có giá trị vận hành nội bộ; không công bố rộng rãi nếu có thể tạo rủi ro an ninh vật lý	OPERATING_REFERENCE	Kho mô phỏng ngừng vận hành và không còn liên kết đến tồn kho, lô hoặc chứng từ	Lưu trữ logic; giữ mã kho cho truy vết các bản ghi liên quan
Vị trí/bin	INTERNAL_RESTRICTED	Sơ đồ vị trí có thể làm lộ cách bố trí kho và quy trình kiểm soát hàng hóa	OPERATING_REFERENCE	Vị trí ngừng dùng và số dư tồn kho đã bằng không trong bối cảnh mô phỏng	Khóa sử dụng mới; giữ mã vị trí để diễn giải lịch sử tồn kho
Đơn vị tính	INTERNAL	Danh mục đơn vị tính là dữ liệu tham chiếu nghiệp vụ, không chứa dữ liệu cá nhân	REFERENCE_PERMANENT	Không có điểm kết thúc mặc định vì thay đổi đơn vị tính có thể làm sai diễn giải dữ liệu lịch sử	Không xóa vật lý; đánh dấu không còn hiệu lực nếu cần
Bảng giá	CONFIDENTIAL_COMMERCIAL	Giá bán, điều kiện áp dụng và phân khúc giá mô phỏng thể hiện thông tin thương mại cần hạn chế truy cập	COMMERCIAL_AND_ACCOUNTING_REVIEW	Hết hiệu lực, không còn tranh chấp mô phỏng và các tham chiếu giao dịch liên quan đã được đánh giá	Khóa sửa đổi; lưu trữ phiên bản để giải thích giá đã áp dụng trong lịch sử
Tham chiếu hệ thống tài khoản	CONFIDENTIAL_FINANCIAL	Mã tài khoản và cấu trúc phân loại tài chính có thể tiết lộ mô hình quản trị tài chính, dù không phải số dư hay bút toán	ACCOUNTING_REVIEW	Chỉ được xác định sau khi Accounting và Legal Owner xác minh yêu cầu lưu chứng từ, sổ sách và tham chiếu liên quan	Không xóa hoặc đổi nghĩa mã khi còn giao dịch tham chiếu; Verification required
Nhân viên/người phê duyệt tham chiếu	RESTRICTED_PERSONAL	Có thể chứa họ tên, chức danh, đơn vị, định danh đăng nhập mô phỏng và thẩm quyền phê duyệt	EMPLOYMENT_AND_PRIVACY_REVIEW	Quan hệ vai trò mô phỏng kết thúc và không còn yêu cầu kiểm toán hoặc truy vết quyết định	Vô hiệu hóa quyền; ẩn danh hóa thuộc tính nhận diện khi phù hợp; giữ dấu vết quyết định theo chính sách được xác minh

Các nhãn được áp dụng theo nguyên tắc tối thiểu cần biết: INTERNAL chỉ dành cho người học hoặc vai trò nội bộ được phân công; CONFIDENTIAL_COMMERCIAL hạn chế với vai trò cần phân tích giá hoặc quan hệ thương mại; CONFIDENTIAL_FINANCIAL hạn chế với vai trò có nhu cầu tài chính-kế toán; CONFIDENTIAL_PERSONAL và RESTRICTED_PERSONAL yêu cầu hạn chế hơn vì có khả năng nhận diện cá nhân. Sự khác biệt giữa hai nhãn dữ liệu cá nhân là mức tác động: RESTRICTED_PERSONAL áp dụng khi kết hợp danh tính và quyền phê duyệt có thể tạo rủi ro giả mạo, lạm quyền hoặc suy luận về quan hệ lao động mô phỏng.

Không dùng dữ liệu thật của khách hàng, nhà cung cấp, nhân viên hoặc người phê duyệt trong bất kỳ ví dụ, ảnh chụp màn hình, tệp xuất hay bài tập nào của Nova Foods. Dữ liệu tổng hợp phải dùng tên, địa chỉ email, số điện thoại, mã số và địa chỉ được tạo cho mục đích học tập; không sao chép dữ liệu từ danh bạ, hóa đơn, hợp đồng, hồ sơ nhân sự hoặc hệ thống thực. Nếu một mẫu dữ liệu tổng hợp vẫn có cấu trúc giống dữ liệu cá nhân, mẫu đó vẫn phải nhận nhãn nhạy cảm tương ứng vì rủi ro xuất hiện từ loại thuộc tính và khả năng sử dụng, không chỉ từ việc dữ liệu có phải dữ liệu thật hay không.

Việc xác định thời hạn cụ thể, căn cứ xóa và ngoại lệ lưu giữ cho dữ liệu liên quan kế toán, hóa đơn, lao động, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc là Verification required. Cơ sở của nhãn này là các nguồn chính thức được liệt kê cho Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP, Luật Kế toán, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm yêu cầu diễn giải theo phạm vi áp dụng thực tế; micro-batch này không suy diễn điều khoản, thời hạn hay nghĩa vụ vận hành khi chưa có xác minh của Legal Owner, Accounting Owner, Security và Business Owner có thẩm quyền.

Danh mục giá trị được phép áp dụng cho dữ liệu chủ

Giá trị được phép (permitted values) là tập mã hoặc nhãn được kiểm soát mà người dùng chỉ được chọn trong khi tạo hoặc cập nhật dữ liệu chủ. Cách kiểm soát này ngăn cùng một ý nghĩa bị nhập bằng nhiều biến thể, chẳng hạn Đang hoạt động, Hoạt động và Active. Đối với Nova Foods — bối cảnh ERP mô phỏng chỉ dùng dữ liệu tổng hợp — các tập giá trị dưới đây là Project assumption phục vụ học liệu tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chúng không xác nhận cấu hình ERP thực tế, chính sách vận hành hoặc yêu cầu pháp lý.

Thực thể dữ liệu chủ	Trường áp dụng	Giá trị được phép	Quy tắc sử dụng và biên quyết định
Khách hàng	customer_type	DOANH_NGHIEP, BAN_LE, NOI_BO	Chọn DOANH_NGHIEP khi bên mua mô phỏng là tổ chức; BAN_LE khi là người mua cá nhân mô phỏng; NOI_BO chỉ cho tình huống luân chuyển nội bộ trong học liệu. Không dùng giá trị này để suy ra nghĩa vụ thuế hoặc tư cách pháp nhân.
Khách hàng	status	ACTIVE, INACTIVE, BLOCKED	ACTIVE cho phép được tham chiếu trong tình huống mô phỏng; INACTIVE ngừng dùng cho giao dịch mới nhưng vẫn giữ giá trị lịch sử; BLOCKED biểu thị chặn sử dụng do tình huống kiểm soát mô phỏng. Lý do chặn cụ thể thuộc quy tắc nghiệp vụ, không được suy diễn tại đây.
Nhà cung cấp	supplier_type	NGUYEN_LIEU, BAO_BI, DICH_VU, THIET_BI	Mỗi nhà cung cấp có một loại chính trong phạm vi học liệu để đơn giản hóa phân tích. Nếu một đối tác cung cấp nhiều loại, cần mô hình hóa quan hệ năng lực cung ứng ở phạm vi được xác định riêng, không tự thêm giá trị tự do.
Nhà cung cấp	status	ACTIVE, INACTIVE, BLOCKED	Nghĩa của từng trạng thái giống tập giá trị của khách hàng để giảm sai khác ngữ nghĩa giữa các miền mua và bán.
Sản phẩm/SKU	product_type	NGUYEN_LIEU, BAO_BI, THANH_PHAM, HANG_HOA, DICH_VU	NGUYEN_LIEU và BAO_BI phục vụ ngữ cảnh sản xuất mô phỏng; THANH_PHAM là đầu ra sản xuất; HANG_HOA là hàng mua để bán; DICH_VU không đại diện cho vật phẩm tồn kho. Việc một loại có được theo dõi tồn kho hay không là quyết định mô hình hoặc cấu hình ở phạm vi khác.
Sản phẩm/SKU	product_status	DRAFT, ACTIVE, INACTIVE, DISCONTINUED	DRAFT chỉ dùng khi dữ liệu minh họa chưa đủ để sử dụng trong kịch bản; ACTIVE dùng được; INACTIVE tạm ngừng dùng; DISCONTINUED ngừng cung cấp trong kịch bản mới. Không coi các trạng thái này là trạng thái phê duyệt sản phẩm thực tế.
Kho	warehouse_type	NGUYEN_LIEU, THANH_PHAM, PHAN_PHOI, CACH_LY	Phân loại phản ánh mục đích logistics mô phỏng. CACH_LY chỉ mô tả khu vực tách biệt trong kịch bản chất lượng; không phải kết luận về yêu cầu an toàn thực phẩm. Verification required nếu được dùng để suy diễn quy trình pháp lý hoặc chất lượng thực tế.
Vị trí/bin	location_type	RECEIVING, STORAGE, PICKING, STAGING, QUARANTINE, DISPATCH	Mỗi vị trí/bin phải có đúng một loại để hỗ trợ cách đọc luồng hàng thống nhất. QUARANTINE là nhãn mô phỏng cho hàng chờ xử lý; điều kiện chuyển vào hoặc ra vị trí này thuộc quy tắc nghiệp vụ riêng.
Đơn vị tính	uom_category	COUNT, WEIGHT, VOLUME, LENGTH, TIME	COUNT dành cho đơn vị đếm như EA; WEIGHT cho KG, G; VOLUME cho L, ML; LENGTH cho M, CM; TIME cho DAY, HOUR. Không chuyển đổi tự động giữa hai nhóm khác nhau nếu chưa có quy tắc chuyển đổi được xác định.
Đơn vị tính	uom_code	EA, BOX, PACK, KG, G, L, ML, M, CM, DAY, HOUR	Mã viết hoa là giá trị lưu trữ canonical; giao diện vi-VN có thể hiển thị diễn giải tiếng Việt như “cái”, “ki-lô-gam”, “lít”, nhưng không được tạo mã lưu trữ mới từ nhãn hiển thị.
Bảng giá	price_list_type	SALES, PURCHASE	SALES áp dụng cho giá bán mô phỏng; PURCHASE áp dụng cho giá mua mô phỏng. Giá trị tiền tệ trong case study dùng VND; điều này không xác nhận cấu hình tài chính thực tế.
Bảng giá	price_scope	STANDARD, CUSTOMER_SPECIFIC, SUPPLIER_SPECIFIC	STANDARD là giá dùng chung trong kịch bản; hai giá trị còn lại chỉ ra giá gắn với một đối tác mô phỏng xác định. Không sử dụng CUSTOMER_SPECIFIC cho nhà cung cấp hoặc ngược lại.
Tham chiếu hệ thống tài khoản	account_class	ASSET, LIABILITY, EQUITY, REVENUE, EXPENSE	Tập giá trị là phân nhóm học tập ở mức cao để liên kết ngữ nghĩa ERP. Việc ánh xạ tài khoản, hạch toán, thuế, hóa đơn hoặc kỳ kế toán là Verification required với vai trò Accounting và nguồn pháp lý hiện hành.
Nhân viên/người phê duyệt tham chiếu	reference_role	REQUESTER, MANAGER_APPROVER, FINANCE_APPROVER, WAREHOUSE_APPROVER, SYSTEM_ADMINISTRATOR	Giá trị phản ánh vai trò tham chiếu trong kịch bản, không phải quyền truy cập hệ thống. Một cá nhân tổng hợp có thể mang nhiều vai trò tham chiếu nếu kịch bản yêu cầu; việc phân quyền thực tế thuộc phạm vi bảo mật và kiến trúc.
Nhân viên/người phê duyệt tham chiếu	employment_status	ACTIVE, INACTIVE	ACTIVE cho phép được chọn làm người yêu cầu hoặc người phê duyệt trong kịch bản; INACTIVE không được chọn cho tình huống mới. Không lưu hoặc suy diễn hồ sơ nhân sự thực tế.

Mọi giá trị ngoài bảng phải bị từ chối tại điểm nhập hoặc được ghi nhận như một yêu cầu thay đổi có truy vết trước khi bổ sung vào danh mục. Lý do là mã tự do làm mất khả năng nhóm dữ liệu và gây mơ hồ khi báo cáo, tích hợp hoặc kiểm thử. Ví dụ, nếu người dùng nhập Kho lạnh thay vì chọn một warehouse_type đã có, hệ thống học liệu cần giữ tên mô tả đó ở nơi được thiết kế riêng, còn trường phân loại vẫn phải chọn một mã hợp lệ như NGUYEN_LIEU hoặc THANH_PHAM.

Tên khách hàng, nhà cung cấp, nhân viên và người phê duyệt dùng trong ví dụ hoặc dữ liệu nạp thử phải là dữ liệu tổng hợp, không tái sử dụng tên, số điện thoại, địa chỉ, mã số thuế, email hoặc định danh của cá nhân, tổ chức thực. Giá trị được phép không phải bằng chứng về sự tồn tại của đối tác, nhân sự hay hoạt động của Nova Foods; chúng chỉ chuẩn hóa cách biểu diễn dữ liệu trong corpus mô phỏng.

Nguyên tắc sử dụng dữ liệu tổng hợp và mô hình hóa an toàn quyền riêng tư

Nova Foods Trading & Manufacturing là case study ERP mô phỏng giáo dục, vì vậy mọi giá trị minh họa trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md phải là dữ liệu tổng hợp: dữ liệu được tạo ra cho mục đích học tập, không được sao chép, suy ngược hoặc ghép nối từ cá nhân, doanh nghiệp hay giao dịch có thật. Lý do là dữ liệu chủ trong ERP có thể chứa dữ liệu cá nhân hoặc thông tin thương mại nhạy cảm; một tên có vẻ giả vẫn gây rủi ro nếu kết hợp với số điện thoại, địa chỉ, mã số thuế, lịch sử mua hàng hoặc thông tin thanh toán có thật.

Tình huống mô hình hóa	Cách dùng an toàn trong Nova Foods	Ranh giới không được vượt qua
Tên khách hàng, nhà cung cấp hoặc nhân viên	Dùng tên hư cấu rõ ràng, ví dụ Khách hàng Minh An Mô phỏng, Nhà cung cấp Hạt Việt Tổng hợp, Nguyễn An Học liệu.	Không dùng tên, chức danh và đơn vị thật theo cách có thể nhận diện một người hoặc tổ chức thực.
Thông tin liên hệ	Dùng chuỗi minh họa như contact@example.test, 0900 000 000, địa chỉ Phường Mô Phỏng, TP. Hồ Chí Minh.	Không đưa email, số điện thoại, địa chỉ, tài khoản mạng xã hội hoặc mã định danh thật vào ví dụ, ảnh chụp, tệp đính kèm hoặc dữ liệu kiểm thử.
Mã định danh nghiệp vụ	Dùng mã tổng hợp theo quy ước của corpus khi quy ước đó đã được đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Không tái sử dụng mã khách hàng, mã nhà cung cấp, mã nhân viên, mã kho hoặc mã số thuế từ nguồn thực tế.
Giá, số dư, doanh số và công nợ	Dùng số liệu được tạo riêng cho bài học, biểu diễn bằng VND trong bối cảnh mô phỏng.	Không sao chép báo giá, sổ cái, hóa đơn, sao kê hoặc dữ liệu thương mại thực, kể cả khi đã xóa tên hiển thị.
Dữ liệu người phê duyệt	Chỉ mô hình hóa vai trò, ví dụ Quản lý mua hàng mô phỏng; khi cần ví dụ cá nhân, dùng nhân vật tổng hợp.	Không ghi chữ ký, mã nhân sự, lịch sử phê duyệt, quyền truy cập hoặc mẫu hành vi của nhân sự thực.

Khử nhận dạng là loại bỏ hoặc biến đổi thông tin để không còn có thể nhận diện chủ thể dữ liệu một cách hợp lý; giả danh hóa là thay giá trị nhận diện bằng mã thay thế nhưng vẫn có thể khôi phục khi tồn tại khóa liên kết. Trong corpus này, dữ liệu tổng hợp được ưu tiên hơn giả danh hóa vì không cần giữ khóa liên kết với dữ liệu nguồn. Do đó, không được tạo bảng ánh xạ giữa tên giả và người thật, không nhập bản trích xuất production để “làm sạch”, và không dùng công cụ sinh dữ liệu dựa trực tiếp trên tập dữ liệu thật.

Quyết định thiết kế an toàn	Áp dụng cho tài liệu học liệu	Lý do và bằng chứng suy luận
Tách cấu trúc khỏi giá trị thực	Có thể mô tả trường như email, số điện thoại, địa chỉ giao hàng, tài khoản thanh toán, nhưng chỉ điền giá trị tổng hợp.	Cấu trúc dữ liệu cần thiết để học mô hình ERP; giá trị thật không cần thiết để chứng minh quan hệ dữ liệu.
Giảm thiểu dữ liệu	Chỉ mô hình hóa thuộc tính cần để giải thích nghiệp vụ của bài học.	Thuộc tính không phục vụ mục tiêu học tập làm tăng bề mặt lộ lọt mà không tăng giá trị phân tích.
Không dùng dữ liệu nhạy cảm để minh họa	Không tạo ví dụ về giấy tờ định danh, dữ liệu sức khỏe, sinh trắc học, thông tin tài khoản thanh toán đầy đủ hoặc hồ sơ nhân sự chi tiết.	Các loại dữ liệu này có rủi ro cao hơn; bài học về master data không cần giá trị chi tiết để giải thích mô hình logic.
Gắn nhãn nguồn dữ liệu	Mọi bảng ví dụ phải được hiểu là synthetic data only trong bối cảnh Nova Foods mô phỏng.	Nhãn giúp người đọc không nhầm dữ liệu học liệu với dữ liệu vận hành, bằng chứng giao dịch hoặc dữ liệu có thể tái sử dụng cho production.
Kiểm soát tệp và bản sao	Không đính kèm tệp xuất ERP, bảng tính nhân sự, danh bạ đối tác hoặc ảnh chụp màn hình có dữ liệu thật vào corpus.	Một ví dụ trong Markdown vẫn có thể bị sao chép rộng rãi; kiểm soát giá trị đầu vào an toàn hơn xử lý sau khi đã phát tán.

Các yêu cầu về dữ liệu cá nhân trong Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý cần tham chiếu khi hệ thống thực tế xử lý dữ liệu cá nhân. Việc diễn giải nghĩa vụ cụ thể, thời hạn lưu giữ, căn cứ xử lý hoặc biện pháp tuân thủ cho production được gắn nhãn Verification required và phải do Legal Owner cùng Security xác minh. Nội dung hiện tại chỉ đặt ranh giới an toàn cho học liệu IN_REVIEW phiên bản v0.9.0 ngày 2026-08-07, không phải xác nhận tuân thủ pháp lý, cấu hình ERP hoặc quyền sử dụng dữ liệu thực.

04. Transactional, Traceability, and Accounting-Integration Entities

Trong Nova Foods mô phỏng, transactional entity (thực thể giao dịch) là đối tượng dữ liệu ghi lại một hành động nghiệp vụ đã, đang hoặc sẽ xảy ra; còn system of record (nguồn ghi nhận chuẩn) là hệ thống hoặc phân hệ chịu trách nhiệm giữ bản ghi chính thức của thực thể đó. Bảng dưới đây chỉ dùng synthetic data only và giúp người học nhìn từ gốc: thực thể nào khởi tạo nhu cầu, thực thể nào xác nhận thực hiện, thực thể nào làm bằng chứng truy vết. Cách đọc là: một thực thể phải có 1 nơi ghi nhận chuẩn rõ ràng, 1 nhóm sở hữu nghiệp vụ chịu trách nhiệm, và 1 vòng đời đủ ngắn để không lẫn với master data ở section 3 hoặc các quy tắc kiểm soát ở section sau.

Mã tham chiếu ổn định	Thực thể giao dịch	Mục đích nghiệp vụ	System of record	Chủ sở hữu nghiệp vụ	Vòng đời điển hình	Vai trò đối với truy vết
TX-SO	Sales Order (đơn bán hàng)	Ghi yêu cầu mua của khách và là điểm khởi phát cam kết cung ứng; reasoning: nếu không có đơn bán hàng thì không có căn cứ chuẩn để tạo giao hàng, hóa đơn và theo dõi thực hiện.	Sales / Order Management	Bán hàng, CSKH	Draft → Confirmed → Fulfilled / Cancelled	Neo toàn bộ chuỗi từ đơn đến giao hàng, sản xuất, hóa đơn.
TX-SOL	Sales Order Line (dòng đơn bán hàng)	Ghi từng mặt hàng, số lượng, giá, kho giao và điều kiện riêng; reasoning: một đơn có thể nhiều dòng, nên dòng là đơn vị tối thiểu để đối chiếu tồn kho và giao hàng.	Sales / Order Management	Bán hàng	Open → Allocated → Shipped / Closed	Bảo đảm truy vết theo từng mặt hàng, không chỉ theo đầu đơn.
TX-DEL	Delivery / Picking / Shipping artifacts (chứng từ giao hàng, phiếu soạn hàng, xác nhận gửi hàng)	Ghi bước thực thi kho và vận chuyển; reasoning: đơn hàng là cam kết, còn bộ chứng từ giao/soạn/gửi là bằng chứng rằng hàng đã rời kho hoặc sẵn sàng rời kho.	Warehouse / Logistics	Kho, vận hành giao nhận	Created → Picked → Packed → Dispatched → Delivered	Là mắt xích giữa đơn bán và tồn kho thực tế.
TX-PO	Purchase Order (đơn mua hàng)	Ghi nhu cầu mua từ nhà cung cấp; reasoning: mua hàng cần một cam kết đặt hàng có kiểm soát để đối chiếu với nhận hàng và công nợ.	Procurement	Mua hàng	Draft → Approved → Sent → Partially received / Closed / Cancelled	Là đầu mối truy vết chiều mua vào.
TX-GR	Goods Receipt (phiếu nhập kho / ghi nhận nhận hàng)	Ghi hàng thực nhận từ nhà cung cấp hoặc từ xưởng; reasoning: chỉ khi có phiếu nhập kho mới xác nhận số lượng đã vào kho, không dựa vào PO.	Warehouse / Inventory	Kho	Open → Received → Posted → Adjusted / Reversed	Là bằng chứng nhận hàng để nối PO với tồn kho và lô.
TX-IM	Inventory Stock Movement (biến động tồn kho)	Ghi mọi tăng giảm, chuyển kho, xuất dùng, điều chỉnh; reasoning: tồn kho logic phải được cộng trừ từ từng biến động thay vì chỉ nhìn số dư cuối kỳ.	Inventory Control	Quản lý tồn kho	Created → Posted → Reconciled / Reversed	Là sổ vết chuẩn để giải thích vì sao số lượng thay đổi.
TX-LB	Lot / Batch (lô / mẻ)	Ghi đơn vị truy xuất nguồn gốc theo lô sản xuất, ngày sản xuất, hạn dùng; reasoning: thực phẩm cần truy vết theo lô để phục vụ thu hồi, kiểm tra chất lượng và hạn dùng.	Quality / Warehouse / Manufacturing	Chất lượng, sản xuất, kho	Assigned → Released → Consumed / Shipped / Quarantined / Recalled	Là khóa truy vết ngược và xuôi cho recall và expiry.
TX-POORD	Production Order (lệnh sản xuất)	Ghi yêu cầu tạo thành phẩm; reasoning: khi nhu cầu bán hoặc kế hoạch tồn kho cần sản xuất, lệnh sản xuất là lệnh điều hành trung tâm.	Manufacturing Execution / Planning	Sản xuất	Planned → Released → In process → Completed / Closed	Nối nhu cầu bán với tiêu hao nguyên liệu và tạo lô thành phẩm.
TX-WO	Work Order (lệnh công việc)	Ghi một tác vụ cụ thể trong sản xuất hoặc bảo trì; reasoning: một production order có thể tách thành nhiều việc nhỏ, nên work order là mức thực thi chi tiết hơn.	Manufacturing / Maintenance	Sản xuất, bảo trì	Created → Assigned → Executed → Confirmed / Cancelled	Cung cấp chi tiết hoạt động để giải thích tiến độ và công sức.
TX-BOMREF	BOM Reference (tham chiếu BOM, bill of materials = định mức nguyên vật liệu)	Ghi cấu trúc nguyên liệu, bán thành phẩm, tỷ lệ tiêu hao; reasoning: sản xuất chỉ có thể giải thích hao hụt và nhu cầu nguyên liệu khi có tham chiếu BOM chuẩn.	Engineering / Planning	Kỹ thuật công nghệ, kế hoạch	Draft → Effective → Superseded / Obsolete	Là căn cứ để suy ra nguyên liệu nào đã tạo ra lô thành phẩm nào.
TX-INV	Invoice (hóa đơn / chứng từ bán hàng)	Ghi nghĩa vụ thanh toán của khách; reasoning: hàng đã giao chưa đủ để ghi nhận doanh thu hóa đơn, nên invoice phải tách khỏi delivery nhưng liên kết chặt với đơn và giao hàng.	Finance / AR (Accounts Receivable = công nợ phải thu)	Kế toán bán hàng	Issued → Posted → Partially paid → Paid / Cancelled / Adjusted	Là đầu mối nối đơn, giao hàng và công nợ khách hàng.
TX-PAY	Payment (thanh toán)	Ghi tiền đã thu hoặc đã chi; reasoning: invoice thể hiện phải thu, còn payment thể hiện dòng tiền thực tế và trạng thái tất toán.	Finance / Treasury / AR	Kế toán, quỹ	Initiated → Cleared → Matched → Settled / Reversed	Khóa đối chiếu giữa hóa đơn và dòng tiền.
TX-CRAPP	Credit Approval (phê duyệt tín dụng)	Ghi quyết định cho phép bán chịu, giới hạn công nợ hoặc điều kiện nợ; reasoning: nếu không có phê duyệt tín dụng thì hệ thống không có căn cứ kiểm soát rủi ro công nợ.	Credit Control / Finance	Tín dụng, tài chính	Requested → Reviewed → Approved / Rejected → Expired	Điều kiện trước khi mở rộng bán hàng theo hạn mức.
TX-DISCAPP	Discount Approval (phê duyệt chiết khấu)	Ghi quyết định cho phép giảm giá vượt ngưỡng chuẩn; reasoning: chiết khấu là ngoại lệ ảnh hưởng doanh thu nên cần phê duyệt riêng thay vì cho nhập tự do.	Sales Governance / Finance	Bán hàng, tài chính	Requested → Approved / Rejected → Expired	Giải thích vì sao giá thực tế khác giá niêm yết.
TX-DEFCHG	Defect / Change References (tham chiếu lỗi / thay đổi)	Ghi tham chiếu đến lỗi chất lượng, thay đổi quy trình, thay thế lô hoặc xử lý ngoại lệ; reasoning: khi có lỗi hoặc thay đổi, cần một mã tham chiếu để nối sự kiện với hành động khắc phục.	Quality / Change Control	Chất lượng, cải tiến quy trình	Raised → Investigating → Actioned → Closed	Giữ dấu vết cho truy hồi lỗi, điều tra nguyên nhân và hành động sửa chữa.

Quy tắc chọn thực thể trong catalog này là: nếu bản ghi mô tả cam kết với bên ngoài, đặt nó ở nhóm bán/mua/tín dụng; nếu bản ghi mô tả thực thi vật lý, đặt nó ở giao nhận, tồn kho hoặc sản xuất; nếu bản ghi mô tả bằng chứng tài chính, đặt nó ở hóa đơn hoặc thanh toán; nếu bản ghi mô tả truy xuất chất lượng, đặt nó ở lô, lỗi hoặc thay đổi. Nova Foods ở đây là bối cảnh mô phỏng giáo dục, nên mọi mã như TX-SO, TX-PO, TX-LB chỉ là mã quản trị chuẩn để học tập và đối chiếu, không phải xác nhận cấu hình ERP production.

Nguồn ghi nhận chuẩn, quyền sở hữu và ý nghĩa vòng đời của thực thể giao dịch

System of record (SoR, hệ thống ghi nhận chuẩn) là nơi lưu bản ghi có thẩm quyền vận hành cho một thực thể: người dùng và hệ thống tích hợp phải tra cứu hoặc cập nhật bản ghi đó theo quyền được cấp, thay vì dùng tệp xuất, email hoặc bảng tính cá nhân làm nguồn quyết định. Owner (chủ sở hữu) là vai trò chịu trách nhiệm làm rõ ý nghĩa nghiệp vụ, quy tắc sử dụng và ngoại lệ của thực thể; Owner không mặc nhiên là người phê duyệt, không thay vai trò Kế toán, Pháp lý, An toàn thực phẩm, Kiến trúc hoặc Bảo mật. Cách phân định này cần thiết vì một giao dịch chỉ có thể truy vết đáng tin cậy khi biết bản ghi gốc nằm ở đâu, ai giải thích được nghiệp vụ và bản ghi cần tồn tại tại giai đoạn nào của vòng đời ERP.

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, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ mô phỏng VND. Bảng dưới đây là kế hoạch logical data dictionary đang IN_REVIEW, version v0.9.0, ngày 2026-08-07; không xác lập cấu hình ERP production, baseline hoặc phê duyệt. Việc dùng các vai trò Owner được suy ra từ chức năng nghiệp vụ trực tiếp của thực thể: thực thể khởi tạo cam kết bán thuộc Bán hàng, thực thể ghi nhận vật chất thuộc Kho/Sản xuất, và thực thể phản ánh chứng từ tài chính thuộc Tài chính–Kế toán. Các suy luận có tác động pháp lý, thuế, hóa đơn, kế toán hoặc an toàn thực phẩm vẫn mang nhãn Verification required.

Thực thể giao dịch	SoR dự kiến và nhãn phân loại nguồn	Owner nghiệp vụ dự kiến	Ý nghĩa trong vòng đời
Sales Order (đơn bán hàng)	ERP Nova Foods; Operational transaction source	Sales Operations Manager	Là cam kết bán được ghi nhận sau khi tiếp nhận nhu cầu khách hàng; là điểm bắt đầu vận hành của chuỗi thực hiện đơn, nhưng không tự xác nhận giao hàng hoặc thu tiền.
Sales Order Line (dòng đơn bán hàng)	ERP Nova Foods; Operational transaction source	Sales Operations Manager	Phân rã từng hàng hóa/dịch vụ cần thực hiện trong đơn; vòng đời dòng có thể khác đơn tổng khi giao từng phần, thay thế hoặc hủy từng phần.
Pick Artifact (phiếu lấy hàng)	ERP Nova Foods hoặc ứng dụng kho tích hợp được xác nhận; Warehouse execution source	Warehouse Manager	Ghi nhận yêu cầu và kết quả lấy hàng tại kho; có ý nghĩa khi đơn đã chuyển sang thực hiện vật lý, không thay thế chứng từ giao hàng.
Delivery Artifact (phiếu giao hàng)	ERP Nova Foods; Fulfilment execution source	Logistics Manager	Ghi nhận việc chuẩn bị bàn giao hàng cho vận chuyển; là mốc kiểm soát thực hiện giao nhận, không phải hóa đơn.
Shipment Artifact (lệnh/chứng từ xuất vận chuyển)	ERP Nova Foods hoặc hệ thống vận tải tích hợp được xác nhận; Logistics execution source	Logistics Manager	Theo dõi hàng rời điểm kiểm soát của Nova Foods và trạng thái vận chuyển; bằng chứng giao thành công cần được quản trị riêng theo quy trình logistics.
Purchase Order (đơn mua hàng)	ERP Nova Foods; Operational transaction source	Procurement Manager	Là cam kết mua sau quyết định mua hàng; duy trì đến khi hoàn tất, đóng hoặc hủy theo quy trình mua hàng mô phỏng.
Goods Receipt (phiếu nhận hàng)	ERP Nova Foods hoặc ứng dụng kho tích hợp được xác nhận; Warehouse receiving source	Warehouse Manager	Ghi nhận thời điểm và kết quả hàng được tiếp nhận vào kiểm soát kho; khác với xác nhận thanh toán cho nhà cung cấp.
Inventory Stock Movement (biến động tồn kho)	ERP Nova Foods; Inventory ledger source	Inventory Control Manager	Là bản ghi vận hành giải thích tăng, giảm, chuyển hoặc điều chỉnh số lượng tồn; phải tồn tại xuyên suốt từ khi phát sinh hoạt động kho đến khi khóa kỳ nghiệp vụ theo thiết kế được xác minh.
Lot/Batch (lô/mẻ)	ERP Nova Foods; Traceability source	Quality Manager	Là đơn vị nhận diện truy xuất của hàng hóa theo lô hoặc mẻ; có ý nghĩa từ lúc lô được nhận hoặc tạo ra đến khi được tiêu thụ hết, hủy, thu hồi hoặc lưu trữ theo chính sách được xác minh.
Production Order (lệnh sản xuất)	ERP Nova Foods; Manufacturing planning source	Production Planning Manager	Đại diện cho nhu cầu sản xuất được lập kế hoạch và phát hành để thực hiện; vòng đời kết thúc khi được hoàn tất, đóng hoặc hủy theo quyền hạn nghiệp vụ.
Work Order (phiếu công việc)	ERP Nova Foods hoặc hệ thống thực thi sản xuất tích hợp được xác nhận; Manufacturing execution source	Production Manager	Giao việc thực tế cho công đoạn, máy hoặc nhóm sản xuất; được dùng khi cần theo dõi thực hiện chi tiết hơn lệnh sản xuất.
BOM Reference (tham chiếu định mức nguyên vật liệu)	ERP Nova Foods; Controlled master-data reference	Product/Process Owner	Là tham chiếu phiên bản định mức được chọn tại thời điểm lập hoặc thực hiện sản xuất; bản thân tham chiếu không phải giao dịch xuất dùng vật tư và không được thay cho hồ sơ kỹ thuật đã được kiểm soát.
Invoice (hóa đơn/chứng từ lập hóa đơn)	Mô-đun tài chính–kế toán ERP Nova Foods hoặc hệ thống hóa đơn tích hợp được xác nhận; Financial document source	Accounting Owner	Ghi nhận chứng từ yêu cầu thanh toán hoặc nghĩa vụ phải trả/phải thu theo thiết kế nghiệp vụ. Verification required: cách lập, điều chỉnh, lưu và sử dụng hóa đơn phải được Accounting Owner và Legal Owner đối chiếu quy định hiện hành.
Payment (thanh toán)	Mô-đun tài chính–kế toán ERP Nova Foods hoặc tích hợp ngân hàng được xác nhận; Financial settlement source	Treasury/Accounting Owner	Ghi nhận trạng thái thực hiện thanh toán hoặc nhận tiền; vòng đời bao gồm khởi tạo, xác nhận kết quả và đối soát, không suy diễn rằng một lệnh thanh toán luôn đồng nghĩa tiền đã được quyết toán.
Credit Approval (phê duyệt tín dụng)	ERP Nova Foods hoặc công cụ phê duyệt tích hợp được xác nhận; Controlled approval source	Credit Manager	Cung cấp quyết định kiểm soát rủi ro tín dụng trước hoặc trong quá trình thực hiện đơn bán; hết hiệu lực, thay thế hoặc thu hồi phải được lưu theo cơ chế phê duyệt được xác minh.
Discount Approval (phê duyệt chiết khấu)	ERP Nova Foods hoặc công cụ phê duyệt tích hợp được xác nhận; Controlled approval source	Sales Manager	Ghi nhận quyết định cho phép áp dụng mức chiết khấu ngoài điều kiện thông thường; là bằng chứng kiểm soát thương mại, không phải bản ghi doanh thu hay thanh toán.
Defect Reference (tham chiếu lỗi)	Hệ thống quản lý chất lượng hoặc issue tracker tích hợp được xác nhận; Quality issue source	Quality Manager	Liên kết một lỗi chất lượng hoặc sai lệch được phát hiện với hoạt động xử lý; được duy trì cho đến khi xử lý, đóng hoặc mở lại theo quy trình chất lượng mô phỏng.
Change Reference (tham chiếu thay đổi)	Hệ thống quản lý thay đổi hoặc issue tracker tích hợp được xác nhận; Change-control source	Change Owner được chỉ định theo phạm vi thay đổi	Lưu quyết định và lịch sử thay đổi ảnh hưởng đến quy trình, dữ liệu, sản phẩm hoặc cấu hình học liệu; không được dùng để ngầm xác nhận thay đổi đã được triển khai production.

Quy tắc ranh giới nguồn: tệp xuất báo cáo, email, bản in, ảnh chụp màn hình và bảng tính dùng để phân tích chỉ được xem là Derived reference hoặc bằng chứng hỗ trợ; chúng không thay thế SoR dự kiến trong bảng. Nếu một giao dịch được tạo ở hệ thống tích hợp, Architect phải xác nhận hệ thống nào giữ bản ghi gốc, hệ thống nào chỉ sao chép, và cơ chế định danh liên hệ với /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Lý do là cùng một nội dung hiển thị ở hai nơi không đủ để xác định nơi có quyền sửa, nơi lưu lịch sử và nơi phải được dùng khi có sai lệch.

Quy tắc ownership: khi một thực thể ảnh hưởng đồng thời đến vận hành, chất lượng và tài chính, Owner nghiệp vụ trong bảng chỉ chịu trách nhiệm về nghĩa nghiệp vụ chính; vấn đề liên quan hạch toán, hóa đơn, thuế hoặc chứng từ phải escalation đến Accounting Owner và, khi áp dụng, Legal Owner. Các tình huống liên quan lô, hạn dùng, lỗi chất lượng hoặc thu hồi phải escalation đến Quality Manager, Business Owner và Legal Owner vì Luật An toàn thực phẩm được nêu trong nguồn seed chỉ cung cấp bối cảnh, không đủ để suy ra yêu cầu vận hành chi tiết.

Quan hệ giữa thực thể giao dịch và dữ liệu chủ

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu chủ (master data) là dữ liệu nhận diện tương đối ổn định, như khách hàng, nhà cung cấp, sản phẩm, kho, vị trí kho, đơn vị tính, điều khoản thanh toán và công thức/BOM. Thực thể giao dịch (transactional entity) ghi nhận một sự kiện vận hành cụ thể, như đặt bán, nhận hàng hoặc xuất kho. Quan hệ logic phải lưu khóa tham chiếu đến dữ liệu chủ thay vì chép tự do tên hay mã mô tả; lý do là một mã chủ chuẩn tạo điểm đối chiếu thống nhất khi cùng một sản phẩm hoặc đối tác xuất hiện trong nhiều chứng từ. Mã định danh canonical áp dụng theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; tài liệu này không tự tạo hoặc thay thế ID đã đăng ký.

Thực thể giao dịch	Dữ liệu chủ được tham chiếu	Ý nghĩa quan hệ và biên kiểm soát
Sales Order và Sales Order Line	Khách hàng, địa chỉ giao nhận, sản phẩm, đơn vị tính, bảng giá, điều khoản thanh toán	Đơn bán xác định bên mua; dòng đơn xác định hàng hóa hoặc dịch vụ được yêu cầu. Tên khách hàng và mô tả sản phẩm hiển thị có thể là ảnh chụp nghiệp vụ tại thời điểm lập chứng từ, nhưng khóa tham chiếu vẫn phải trỏ về bản ghi chủ để tránh biến mô tả thành nguồn dữ liệu chính.
Pick Artifact, Delivery Artifact và Shipment Artifact	Kho, vị trí kho, sản phẩm, đơn vị vận chuyển, địa chỉ giao nhận	Chứng từ lấy hàng, giao hàng và xuất gửi dùng dữ liệu chủ để xác định nơi xuất, hàng cần xử lý và đích giao. Không dùng tên kho hoặc tên sản phẩm nhập tự do làm liên kết chính, vì cách này làm suy yếu khả năng đối chiếu khi tên được chuẩn hóa lại.
Purchase Order	Nhà cung cấp, sản phẩm, đơn vị tính, địa điểm nhận, điều khoản mua	Đơn mua liên kết nhà cung cấp và các mặt hàng dự kiến mua. Điều khoản hiển thị trên chứng từ là dữ liệu giao dịch; bản ghi chủ là nguồn để chọn giá trị mặc định, không được coi là tự động ghi đè mọi thỏa thuận đã ghi nhận trên đơn mua.
Goods Receipt	Nhà cung cấp, sản phẩm, kho, vị trí kho, đơn vị tính	Phiếu nhận hàng xác định hàng nào được nhận từ nhà cung cấp nào và được đưa vào đâu. Quan hệ này là nền tảng để đối chiếu thực thể nhận hàng với đối tác, mặt hàng và địa điểm đã chuẩn hóa.
Inventory Stock Movement	Sản phẩm, kho nguồn, kho đích, vị trí kho nguồn, vị trí kho đích, đơn vị tính, mã lý do biến động	Biến động tồn kho tham chiếu các bản ghi chủ để diễn giải hàng, nơi chốn và nguyên nhân theo danh mục kiểm soát. Mã lý do là dữ liệu chủ riêng nhằm ngăn các diễn giải tự do khác nhau cho cùng một loại biến động.
Lot/Batch	Sản phẩm, đơn vị tính, quy tắc hạn dùng của sản phẩm, trạng thái chất lượng danh mục	Lô/batch gắn với đúng một định nghĩa sản phẩm để không dùng một mã lô cho nhiều hàng hóa khác nhau. Thuộc tính ngày sản xuất, ngày hết hạn và thông tin chất lượng là dữ liệu của lô; quy tắc tính hoặc kiểm tra các thuộc tính này cần được xác minh riêng với chủ sở hữu nghiệp vụ và an toàn thực phẩm.
Production Order và Work Order	Sản phẩm đầu ra, kho hoặc vị trí thực hiện, tuyến/quy trình sản xuất, nguồn lực sản xuất, đơn vị tính	Lệnh sản xuất xác định sản phẩm cần tạo; lệnh công việc xác định phần việc thực thi. Các tham chiếu chủ bảo đảm cùng thuật ngữ sản phẩm, nơi sản xuất và nguồn lực được dùng nhất quán giữa kế hoạch và ghi nhận vận hành.
BOM Reference	Sản phẩm thành phẩm, BOM/công thức, phiên bản BOM, sản phẩm thành phần, đơn vị tính	BOM (Bill of Materials, danh mục nguyên vật liệu/công thức) là dữ liệu chủ có phiên bản; thực thể tham chiếu BOM trên lệnh sản xuất phải chỉ ra bản BOM đã được chọn cho giao dịch đó. Việc này phân biệt công thức chuẩn đang được quản trị với công thức được sử dụng trong một lần sản xuất cụ thể.
Invoice	Khách hàng hoặc nhà cung cấp, địa chỉ, điều khoản thanh toán, tiền tệ mô phỏng VND, mã hàng hóa/dịch vụ	Hóa đơn tham chiếu đối tác và dữ liệu chủ liên quan để xác định bên được lập chứng từ và đối tượng tính tiền. Các yêu cầu pháp lý, thuế và hóa đơn điện tử là Verification required với Legal Owner và Accounting Owner; bảng này chỉ xác định quan hệ dữ liệu học liệu.
Payment	Khách hàng hoặc nhà cung cấp, phương thức thanh toán, tài khoản thanh toán, tiền tệ mô phỏng VND	Thanh toán liên kết đối tác và phương thức/tài khoản từ dữ liệu chủ, giúp phân biệt thông tin định danh ổn định với số tiền, ngày và tham chiếu của lần thanh toán cụ thể.
Credit Approval và Discount Approval	Khách hàng, chính sách tín dụng, chính sách chiết khấu, vai trò/phạm vi thẩm quyền	Yêu cầu phê duyệt tham chiếu khách hàng và chính sách chủ được áp dụng. Giá trị quyết định, người thực hiện và thời điểm quyết định thuộc giao dịch phê duyệt, không được ghi đè ngược vào hồ sơ chủ chỉ vì một yêu cầu đơn lẻ.
Defect Reference và Change Reference	Sản phẩm, lô/batch khi áp dụng, loại lỗi, loại thay đổi, nguyên nhân danh mục	Tham chiếu lỗi hoặc thay đổi dùng danh mục chủ để phân loại nhất quán đối tượng và nguyên nhân. Nội dung mô tả sự cố hoặc đề xuất thay đổi vẫn là dữ liệu giao dịch có ngữ cảnh, không được suy diễn là thuộc tính chuẩn của sản phẩm.

Quy tắc thiết kế là: một tham chiếu từ giao dịch đến dữ liệu chủ phải nêu rõ vai trò nghiệp vụ của nó, ví dụ customer, supplier, orderedProduct, receivingWarehouse hoặc productionBOM, thay vì chỉ dùng một trường mã chung không rõ nghĩa. Lập luận là cùng một loại bản ghi chủ có thể tham gia nhiều vai trò khác nhau; một nhà kho có thể là nơi nhận, nơi xuất hoặc nơi thực hiện sản xuất. Tên vai trò rõ ràng giúp BA, kiến trúc sư và QA kiểm tra đúng ý nghĩa liên kết mà không suy đoán từ tên cột.

Dữ liệu chủ không được xóa vật lý khi đã có giao dịch tham chiếu trong case study; thay vào đó, thay đổi tình trạng sử dụng hoặc tạo phiên bản mới theo chính sách quản trị sẽ cần được định nghĩa tại artifact phù hợp. Đây là Project assumption cho mục đích bảo toàn liên kết lịch sử trong học liệu Nova Foods. Quyết định thực tế về lưu giữ, chỉnh sửa và hiệu lực dữ liệu cần Business Owner, Architect, Accounting Owner hoặc Legal Owner xác minh khi có tác động tương ứng.

Quy tắc lực lượng liên kết cho chuỗi truy vết Đơn hàng đến Lô, Giao hàng, Hóa đơn và Phiếu thu

Trong Nova Foods Trading & Manufacturing mô phỏng, lực lượng liên kết (cardinality) trả lời hai câu hỏi cơ bản: một bản ghi ở thực thể A có thể liên kết với bao nhiêu bản ghi ở thực thể B, và liên kết đó có bắt buộc hay không. Quy tắc này cần được xác định trước khi thiết kế dữ liệu vì một đơn bán hàng có thể giao nhiều đợt, mỗi đợt có thể xuất từ nhiều lô, và một khoản thanh toán có thể thanh toán cho nhiều hóa đơn. Nếu chỉ lưu một mã lô hoặc một mã giao hàng trực tiếp trên đơn hàng, hệ thống sẽ mất khả năng giải thích chính xác mặt hàng nào, số lượng nào đã đi qua lô nào và đã được lập hóa đơn, thu tiền đến đâu.

Liên kết chuỗi bán hàng	Lực lượng liên kết chuẩn	Quy tắc dữ liệu và lý do
Đơn bán hàng → Dòng đơn bán hàng	1 : 1..n	Một đơn bán hàng phải có ít nhất một dòng hàng; một dòng đơn chỉ thuộc một đơn. Lý do: đơn là phần đầu chứng từ, còn dòng là nơi xác định mặt hàng, số lượng và điều kiện thực hiện cụ thể.
Dòng đơn bán hàng → Phân bổ lô xuất	1 : 0..n	Một dòng đơn có thể chưa được phân bổ lô khi chưa giao, hoặc được phân bổ từ nhiều lô. Một phân bổ lô xuất chỉ tham chiếu một dòng đơn. Lý do: một mặt hàng có thể được đáp ứng bằng nhiều lô còn tồn, đặc biệt khi cần ưu tiên hạn dùng gần.
Lô/batch → Phân bổ lô xuất	1 : 0..n	Một lô có thể chưa được xuất hoặc được xuất cho nhiều dòng đơn, nhiều chuyến giao khác nhau. Mỗi phân bổ phải chỉ đến đúng một lô. Không được suy luận lô từ mã mặt hàng vì cùng một mặt hàng có thể có nhiều lô với ngày sản xuất, hạn dùng hoặc trạng thái chất lượng khác nhau.
Dòng đơn bán hàng → Dòng giao hàng/xuất hàng	1 : 0..n	Một dòng đơn có thể được giao một phần hoặc giao nhiều đợt; một dòng giao hàng chỉ thực hiện cho một dòng đơn. Tổng số lượng giao hợp lệ không được vượt số lượng đã xác nhận của dòng đơn, trừ khi có quy trình điều chỉnh được kiểm soát.
Chứng từ giao hàng → Dòng giao hàng/xuất hàng	1 : 1..n	Một chứng từ giao hàng phải có ít nhất một dòng giao; một dòng giao thuộc một chứng từ giao hàng. Chứng từ giao hàng là bằng chứng vận hành cho một lần thực hiện giao, không thay thế đơn bán hàng.
Dòng giao hàng/xuất hàng → Phân bổ lô xuất	1 : 1..n khi mặt hàng thuộc diện quản lý lô; 1 : 0..n khi không quản lý lô theo chính sách đã xác minh	Với mặt hàng quản lý lô, mọi số lượng xuất trên dòng giao phải được phủ kín bởi một hoặc nhiều phân bổ lô. Tổng số lượng phân bổ lô phải bằng số lượng thực xuất của dòng giao. Đây là cầu nối bắt buộc để truy ngược từ giao hàng về lô. Việc mặt hàng nào bắt buộc quản lý lô là Project assumption cho đến khi Business Owner và Quality Owner xác minh.
Chứng từ giao hàng → Hóa đơn	1 : 0..n	Một lần giao có thể chưa lập hóa đơn, có thể được lập hóa đơn một lần, hoặc được tách thành nhiều hóa đơn khi có yêu cầu nghiệp vụ được kiểm soát. Một hóa đơn có thể gộp nhiều lần giao của cùng đối tác theo chính sách lập hóa đơn được xác minh.
Hóa đơn → Dòng hóa đơn	1 : 1..n	Một hóa đơn phải có ít nhất một dòng hóa đơn; mỗi dòng hóa đơn chỉ thuộc một hóa đơn. Dòng hóa đơn cần liên kết về dòng giao hoặc dòng đơn theo phương pháp lập hóa đơn đã chọn để không mất dấu nguồn số lượng.
Dòng giao hàng/xuất hàng → Dòng hóa đơn	1 : 0..n	Một dòng giao có thể chưa được lập hóa đơn hoặc được phân bổ vào nhiều dòng hóa đơn nếu nghiệp vụ cho phép tách hóa đơn. Một dòng hóa đơn có thể tham chiếu nhiều dòng giao chỉ khi có bảng liên kết phân bổ; không được dùng một trường khóa đơn lẻ vì sẽ làm sai quan hệ nhiều-nhiều.
Hóa đơn → Phân bổ phiếu thu	1 : 0..n	Một hóa đơn có thể chưa thu tiền, được thu một phần hoặc được thanh toán bằng nhiều phiếu thu. Mỗi phân bổ phiếu thu áp vào đúng một hóa đơn và ghi nhận số tiền phân bổ bằng VND trong dữ liệu tổng hợp.
Phiếu thu → Phân bổ phiếu thu	1 : 1..n	Một phiếu thu phải có ít nhất một phân bổ hóa đơn; một phiếu thu có thể thanh toán nhiều hóa đơn. Tổng tiền phân bổ không được vượt tổng tiền phiếu thu, trừ khoản chênh lệch được xử lý bằng cơ chế được Accounting Owner xác minh.

Phân biệt thuật ngữ: “phiếu thu” trong chuỗi này là chứng từ ghi nhận tiền khách hàng thanh toán cho hóa đơn; không phải “phiếu nhập hàng” (goods receipt) của quy trình mua hàng. Việc tách nghĩa này cần thiết vì cùng từ “receipt” trong tiếng Anh có thể chỉ hai chứng từ khác nhau. Chuỗi bán hàng chuẩn được biểu diễn ở mức logic là: Đơn bán hàng → Dòng đơn → Dòng giao/xuất → Phân bổ lô → Dòng hóa đơn → Phân bổ phiếu thu. Chứng từ giao hàng, hóa đơn và phiếu thu lần lượt đóng vai trò đầu chứng từ bao bọc các dòng hoặc phân bổ tương ứng.

Quy tắc kiểm soát truy vết	Điều kiện phải thỏa	Bằng chứng suy luận
Truy ngược từ khách hàng đến lô	Từ một dòng hóa đơn phải lần được về một hoặc nhiều dòng giao, rồi đến các phân bổ lô và mã lô cụ thể.	Hóa đơn chỉ nói số tiền và hàng hóa được tính; phân bổ lô mới xác định lô thực tế đã xuất. Vì vậy không thể dùng quan hệ Hóa đơn → Lô trực tiếp để thay thế các liên kết giao hàng.
Truy xuôi từ lô đến khách hàng	Từ một lô phải lần được mọi phân bổ lô xuất, dòng giao, đơn bán hàng, hóa đơn liên quan và trạng thái thu tiền tương ứng.	Một lô có thể được chia cho nhiều khách hàng và nhiều đợt giao; quan hệ 1 : 0..n từ lô đến phân bổ lô bảo toàn đầy đủ các đích đến.
Kiểm soát số lượng	Với từng dòng giao quản lý lô, tổng số lượng phân bổ theo lô phải bằng số lượng thực xuất; với từng lô, tổng xuất không được vượt số lượng khả dụng theo trạng thái tồn.	Không có phép đối chiếu tổng này, một dòng giao có thể được ghi xuất nhưng không xác định đủ lô, hoặc cùng số lượng lô bị phân bổ vượt mức.
Bảo toàn lịch sử	Sau khi chứng từ giao, hóa đơn hoặc phiếu thu được ghi nhận, các liên kết nguồn không được bị thay thế âm thầm; sửa sai phải tạo bản ghi điều chỉnh hoặc hủy có tham chiếu tới bản ghi gốc.	Truy vết phục vụ kiểm tra cần biết không chỉ trạng thái hiện tại mà còn cách dữ liệu đã thay đổi. Xóa liên kết gốc làm đứt chuỗi bằng chứng.
Thu hồi lô	Một sự kiện thu hồi phải có khả năng chọn mã lô làm điểm bắt đầu và liệt kê các dòng giao, khách hàng, hóa đơn liên quan theo phạm vi thời gian và số lượng đã xuất.	Thu hồi bắt đầu từ lô bị ảnh hưởng, trong khi khách hàng nhận hàng được xác định qua phân bổ lô và giao hàng; do đó quan hệ nhiều-đợt và nhiều-khách hàng phải được giữ nguyên.

Ví dụ dữ liệu tổng hợp: một dòng đơn cho sản phẩm mô phỏng có số lượng 120 đơn vị có thể được giao thành hai chứng từ giao hàng. Đợt giao thứ nhất xuất 70 đơn vị từ một lô; đợt thứ hai xuất 50 đơn vị gồm 20 đơn vị từ lô trước và 30 đơn vị từ lô khác. Khi đó, dòng đơn có hai dòng giao và ba phân bổ lô. Nếu hai đợt được gộp vào một hóa đơn, hóa đơn vẫn phải giữ liên kết đến cả hai dòng giao; nếu khách hàng thanh toán làm hai lần, hóa đơn có hai phân bổ phiếu thu. Cấu trúc này giải thích được đồng thời số lượng, lô, giao nhận, số tiền phải thu và tiền đã thu mà không ép các quan hệ nhiều-nhiều vào một trường dữ liệu.

Các quy tắc trên là thiết kế logic cho corpus Nova Foods mô phỏng, chỉ dùng dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN và múi giờ Asia/Ho_Chi_Minh. Cách lập hóa đơn, thời điểm ghi nhận kế toán, chứng từ thu tiền và yêu cầu pháp lý về truy xuất hoặc thu hồi là Verification required với Accounting Owner, Legal Owner và Quality Owner; nội dung này không xác nhận cấu hình ERP thực tế, nghĩa vụ pháp lý hoặc phê duyệt vận hành.

Điểm chạm tích hợp kế toán và nhãn phân loại nguồn chứng từ

Điểm chạm tích hợp kế toán là thời điểm một sự kiện vận hành tạo, điều chỉnh, đảo hoặc đối soát dữ liệu cần được chuyển sang phân hệ tài chính-kế toán. Sự kiện vận hành không tự động là bút toán: ví dụ, đơn bán hàng thể hiện cam kết thương mại, còn hóa đơn hoặc sự kiện ghi nhận được Accounting Owner xác nhận mới có thể là căn cứ tạo dữ liệu kế toán. Sự tách biệt này cần thiết vì Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp và không được suy diễn cấu hình hạch toán, thuế hoặc nghĩa vụ pháp lý thực tế.

Nhãn phân loại nguồn	Ý nghĩa sử dụng trong từ điển dữ liệu	Ví dụ điểm chạm	Quy tắc kiểm soát
OPERATIONAL_SOURCE	Bản ghi phát sinh từ quy trình vận hành và là nguồn đầu vào cho đánh giá kế toán.	Sales order, purchase order, picking, shipment, goods receipt, work order.	Không được tự gán trạng thái “đã hạch toán” chỉ vì bản ghi vận hành đã hoàn tất.
ACCOUNTING_SOURCE	Chứng từ hoặc sự kiện do miền kế toán-tài chính quản lý, dùng làm nguồn cho công nợ, sổ cái hoặc đối soát.	Invoice, payment, credit note, accounting journal reference.	Mã tài khoản, kỳ kế toán, thuế và quy tắc ghi nhận là Verification required bởi Accounting Owner và Legal Owner khi phù hợp.
INTEGRATION_DERIVED	Bản ghi hoặc thông điệp được hệ thống tạo từ dữ liệu nguồn theo quy tắc tích hợp đã xác định.	Accounting posting request từ invoice; inventory valuation request từ stock movement.	Phải giữ khóa tham chiếu về bản ghi nguồn, thời điểm tạo, trạng thái xử lý và lý do lỗi hoặc đảo giao dịch.
EXTERNAL_EVIDENCE	Tài liệu hoặc phản hồi đến từ bên ngoài ranh giới ERP mô phỏng.	Xác nhận thanh toán từ cổng thanh toán mô phỏng; số tham chiếu hóa đơn điện tử mô phỏng.	Không coi dữ liệu bên ngoài là đúng tuyệt đối; cần trạng thái đối soát và bằng chứng nguồn.
CONTROL_DECISION	Quyết định phê duyệt hoặc từ chối làm thay đổi khả năng tiếp tục xử lý tài chính, nhưng không tự là chứng từ kế toán.	Credit approval, discount approval.	Quyết định phải được liên kết đến đối tượng được kiểm soát, người hoặc vai trò quyết định, thời điểm và kết quả quyết định.
CORRECTION_REFERENCE	Tham chiếu điều chỉnh để giải thích tác động lên dữ liệu tài chính hoặc chứng từ nguồn.	Defect reference, change reference, reversal reference.	Không được xóa liên kết đến giao dịch gốc; điều chỉnh phải bảo toàn đường dẫn kiểm toán.

Artifact giao dịch	Điểm chạm kế toán dự kiến	Nhãn nguồn chính	Dữ liệu tối thiểu cần truyền hoặc liên kết	Ranh giới quyết định
Sales order	Cung cấp cơ sở thương mại cho kiểm tra hạn mức tín dụng, giá, chiết khấu và công nợ dự kiến.	OPERATIONAL_SOURCE	Số đơn, khách hàng, tiền tệ VND, tổng tiền, điều khoản thanh toán, tham chiếu phê duyệt.	Không ghi nhận doanh thu chỉ từ sales order.
Credit approval	Cho phép hoặc chặn tiếp tục xử lý đơn có rủi ro tín dụng theo chính sách mô phỏng.	CONTROL_DECISION	Đối tượng áp dụng, hạn mức được xét, kết quả, thời điểm, lý do.	Ngưỡng tín dụng là Project assumption cho đến khi Business Owner và Accounting Owner xác nhận.
Discount approval	Xác nhận ngoại lệ hoặc mức giảm giá dùng khi lập hóa đơn.	CONTROL_DECISION	Đơn hoặc dòng áp dụng, loại giảm giá, giá trị, kết quả phê duyệt.	Không tự suy diễn cách hạch toán giảm giá, thuế hoặc doanh thu thuần.
Delivery, pick hoặc shipment artifact	Cung cấp bằng chứng vận hành cho thời điểm cần xem xét giá vốn, tồn kho hoặc điều kiện lập hóa đơn.	OPERATIONAL_SOURCE	Số chứng từ, kho, hàng hóa, số lượng, thời điểm hoàn tất, tham chiếu đơn bán.	Điều kiện ghi nhận giá vốn và doanh thu cần Accounting Owner xác nhận.
Inventory stock movement	Kích hoạt yêu cầu xác định ảnh hưởng giá trị tồn kho khi nhập, xuất, chuyển, điều chỉnh hoặc đảo.	OPERATIONAL_SOURCE	Loại dịch chuyển, kho nguồn/đích, hàng hóa, số lượng, đơn vị tính, chi phí hoặc tham chiếu định giá.	Phương pháp định giá tồn kho là Verification required; không được tự chọn FIFO, bình quân hay phương pháp khác.
Purchase order	Cung cấp cam kết mua và dữ liệu đối chiếu dự kiến với nhận hàng, hóa đơn mua.	OPERATIONAL_SOURCE	Nhà cung cấp, hàng hóa, số lượng, đơn giá dự kiến, tiền tệ, điều khoản thanh toán.	Không tạo công nợ phải trả chỉ từ purchase order.
Goods receipt	Cung cấp sự kiện nhận hàng cho kiểm soát tồn kho, chênh lệch mua hàng và đối chiếu ba bên nếu được thiết kế.	OPERATIONAL_SOURCE	Số nhận hàng, nhà cung cấp, hàng hóa, số lượng nhận, thời điểm nhận, tham chiếu purchase order.	Quy tắc đối chiếu purchase order, goods receipt và invoice là Project assumption trước xác nhận chuyên môn.
Production order hoặc work order	Cung cấp tiêu hao, hoàn thành và chênh lệch vận hành để đánh giá giá trị sản xuất dở dang hoặc thành phẩm.	OPERATIONAL_SOURCE	Lệnh, hàng hóa đầu vào/đầu ra, số lượng, thời điểm, tham chiếu BOM.	Cách phân bổ chi phí sản xuất là Verification required bởi Accounting Owner.
Invoice	Là điểm chạm chính để tạo dữ liệu phải thu hoặc phải trả theo luồng bán hoặc mua.	ACCOUNTING_SOURCE	Số hóa đơn, bên đối tác, ngày chứng từ, tiền tệ VND, dòng tiền hàng, tham chiếu đơn/nhận hàng/giao hàng.	Yêu cầu hóa đơn, thuế, số hóa đơn và lưu trữ chứng từ phải được Legal Owner và Accounting Owner xác minh theo nguồn pháp lý hiện hành.
Payment	Ghi nhận hoặc đối soát việc thu tiền, chi tiền, hoàn tiền hoặc bù trừ mô phỏng.	ACCOUNTING_SOURCE hoặc EXTERNAL_EVIDENCE	Số tham chiếu thanh toán, bên thanh toán, số tiền, ngày giá trị, phương thức, liên kết invoice.	Phản hồi từ kênh thanh toán là bằng chứng đối soát, không thay thế quyết định kế toán được thẩm quyền xác nhận.
Defect hoặc change reference	Gắn nguyên nhân và phạm vi của điều chỉnh, hủy, phát hành lại hoặc đảo dữ liệu tích hợp.	CORRECTION_REFERENCE	Mã tham chiếu, đối tượng gốc, loại tác động, thời điểm, lý do, liên kết giao dịch thay thế hoặc đảo.	Không được sửa đè số liệu nguồn mà không lưu dấu vết thay đổi.

Quy tắc tích hợp bắt buộc là mỗi bản ghi INTEGRATION_DERIVED phải giữ ít nhất một tham chiếu đến nguồn OPERATIONAL_SOURCE hoặc ACCOUNTING_SOURCE, cùng trạng thái truyền nhận, thời điểm theo Asia/Ho_Chi_Minh, mã lỗi nếu thất bại và tham chiếu bản ghi điều chỉnh nếu có. Lý do là dữ liệu kế toán chỉ kiểm toán và đối soát được khi người xem lần ngược từ kết quả tích hợp về sự kiện nguồn mà không cần suy đoán.

Các nhãn trên là quy ước dữ liệu của học liệu Nova Foods tại trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chúng không xác lập sơ đồ tài khoản, quy tắc thuế, bút toán kép, thời điểm ghi nhận doanh thu, cấu hình hóa đơn hoặc sự tuân thủ pháp luật. Các quyết định thuộc các phạm vi đó phải mang nhãn Verification required cho đến khi được xem xét bởi Accounting Owner, Legal Owner và các vai trò có thẩm quyền trong artifact kiểm soát phù hợp.

Hỗ trợ truy xuất lô, hạn dùng, thu hồi và dấu vết kiểm toán

Trong Nova Foods Trading & Manufacturing mô phỏng, chỉ sử dụng dữ liệu tổng hợp, truy xuất nguồn gốc là khả năng lần ngược và lần xuôi một đơn vị hàng từ sự kiện nghiệp vụ đến lô hàng cụ thể. Lần ngược trả lời “lô đã giao cho ai, qua chứng từ nào”; lần xuôi trả lời “đơn hàng hoặc nguyên liệu nào đã tạo ra lô này”. Cần tách Lot/Batch (lô/mẻ có chung đặc tính kiểm soát) khỏi số chứng từ, vì một chứng từ có thể xử lý nhiều lô và một lô có thể xuất hiện trên nhiều lần giao. Lý do là số chứng từ chỉ định danh một sự kiện, còn mã lô là khóa nghiệp vụ nối các sự kiện vật lý xuyên suốt vòng đời.

Nhu cầu sử dụng	Dữ liệu truy xuất tối thiểu cần bảo toàn	Quan hệ logic cần chứng minh	Giá trị kiểm soát
Kiểm soát lô/batch	Mã lô, mã mặt hàng, ngày tạo hoặc nhận lô, trạng thái chất lượng, kho/vị trí tại thời điểm phát sinh	Mỗi dòng nhận, sản xuất, điều chuyển hoặc xuất kho phải ghi lô thực tế và số lượng theo lô.	Ngăn việc chỉ biết tổng tồn kho nhưng không xác định được tồn kho thuộc lô nào.
Kiểm soát hạn dùng	Ngày sản xuất khi áp dụng, ngày hết hạn, đơn vị tính thời gian, thời điểm ghi nhận theo Asia/Ho_Chi_Minh	Hạn dùng thuộc lô, không thuộc riêng chứng từ bán hàng; dòng xuất phải tham chiếu lô có hạn dùng xác định.	Cho phép đánh giá hàng còn hiệu lực theo lô thay vì suy đoán từ ngày lập đơn.
Khoanh vùng thu hồi	Mã/sự kiện thu hồi, lý do, lô bị ảnh hưởng, phạm vi kho/khách nhận, thời điểm phong tỏa và kết quả xử lý	Một sự kiện thu hồi có thể ảnh hưởng nhiều lô; một lô có thể được liên kết với nhiều dòng giao hoặc tồn kho còn lại.	Tạo danh sách đối tượng cần cách ly, liên hệ hoặc kiểm tra mà không mở rộng sai phạm vi.
Kiểm toán thay đổi	Ai thực hiện, vai trò, thời điểm, hành động, giá trị trước/sau, lý do và tham chiếu giao dịch	Mọi thay đổi có tác động đến mã lô, hạn dùng, số lượng theo lô hoặc trạng thái thu hồi phải có bản ghi dấu vết không bị thay thế bởi giá trị hiện hành.	Giúp tái dựng diễn biến quyết định và phát hiện thay đổi không có căn cứ.

Quy tắc chuỗi truy xuất tối thiểu: một lô phải được nối với ít nhất một sự kiện nguồn hợp lệ: nhận hàng, hoàn tất sản xuất hoặc điều chỉnh tồn có lý do. Từ lô, hệ thống phải lần xuôi được đến các lần xuất, giao hoặc tiêu thụ nội bộ có sử dụng lô đó; từ một lần giao hoặc tiêu thụ, hệ thống phải lần ngược được đến lô đã cấp phát. Đây là quy tắc mô hình logic cho học liệu, vì nếu chỉ lưu mã lô ở trạng thái tồn cuối kỳ thì không thể chứng minh lô đã đi qua giao dịch nào.

Điểm kiểm soát	Quy tắc áp dụng cho dữ liệu mô phỏng	Cầu nối lý do/evidence	Phân loại nguồn
Gán lô khi nhập hoặc tạo	Không cho phép ghi nhận số lượng có kiểm soát theo lô mà thiếu mã lô; ngoại lệ chỉ có thể tồn tại khi loại mặt hàng được mô hình hóa là không quản lý lô.	Số lượng không gắn lô không thể được khoanh vùng khi phát hiện vấn đề chất lượng.	Project assumption
Xuất hàng theo lô	Dòng xuất phải ghi số lượng theo từng lô thực cấp phát; không suy diễn lô từ tồn kho tổng.	Một đơn hàng có thể được cấp từ nhiều lô, do đó mã lô ở cấp đầu chứng từ không đủ chứng cứ.	Project assumption
Hạn dùng	Ngày hết hạn phải là một giá trị xác định của lô khi mặt hàng yêu cầu kiểm soát hạn dùng; việc sửa ngày này phải để lại giá trị trước/sau và lý do.	Hạn dùng ảnh hưởng trực tiếp đến quyết định có thể xuất, cách ly hoặc thu hồi; thay đổi không có dấu vết làm mất khả năng giải trình.	Project assumption
Phong tỏa phục vụ thu hồi	Khi lô nằm trong phạm vi thu hồi, trạng thái kiểm soát phải ngăn lô đó được chọn cho giao dịch phát sinh mới cho đến khi có quyết định xử lý được ghi nhận.	Thu hồi chỉ có ý nghĩa nếu hệ thống ngăn luồng phân phối tiếp diễn đối với lô đã được nhận diện.	Project assumption; Verification required với chủ sở hữu an toàn thực phẩm và pháp lý
Dấu vết kiểm toán	Bản ghi audit phải được tạo khi tạo, sửa, hủy hiệu lực hoặc thay đổi trạng thái của dữ liệu lô, hạn dùng và thu hồi; không được ghi đè lịch sử bằng bản ghi hiện hành.	Giá trị hiện hành chỉ trả lời “đang là gì”, còn audit trail trả lời “đã thay đổi thế nào, khi nào và bởi ai”.	Project assumption; yêu cầu lưu giữ cụ thể là Verification required

Dấu vết kiểm toán (audit trail) là tập bản ghi lịch sử phục vụ đối chiếu, không phải màn hình lịch sử tự do. Bản ghi tối thiểu phải chứa định danh đối tượng bị tác động, loại đối tượng, hành động, dấu thời gian Asia/Ho_Chi_Minh, tác nhân hoặc định danh dịch vụ, vai trò tại thời điểm thao tác, trường thay đổi, giá trị trước, giá trị sau, lý do và tham chiếu sự kiện liên quan. Đối với thao tác hệ thống tự động, tác nhân phải thể hiện tài khoản hoặc dịch vụ kỹ thuật thay vì gán sai cho người dùng; điều này phân biệt hành động tự động với quyết định của con người.

Phạm vi thu hồi trong case study phải được tính từ bằng chứng lô, không được tính chỉ từ tên mặt hàng. Ví dụ dữ liệu tổng hợp: nếu một lô thành phẩm bị đánh dấu cần đánh giá, danh sách tác động phải gồm lượng còn trong kho, các giao dịch đã cấp phát từ đúng lô đó và các đối tượng nhận tương ứng; các lô khác cùng mặt hàng không tự động thuộc phạm vi chỉ vì có cùng tên sản phẩm. Cách giới hạn này dựa trên quan hệ lô–sự kiện đã ghi nhận, nên giảm nguy cơ thu hồi quá rộng hoặc bỏ sót giao dịch có liên quan.

Luật An toàn thực phẩm 55/2010/QH12 được ghi nhận trong nguồn hạt giống như bối cảnh pháp lý cho truy xuất và thu hồi. Tuy nhiên, tiêu chí pháp lý, thời hạn lưu hồ sơ, nghĩa vụ thông báo, điều kiện thu hồi và thẩm quyền quyết định cụ thể cho Nova Foods đều là Verification required bởi chủ sở hữu an toàn thực phẩm và pháp lý. Nội dung này thuộc artifact học liệu đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải cấu hình ERP thực tế, bằng chứng tuân thủ, baseline hoặc xác nhận phê duyệt.

05. Attribute Standards: Data Types, Units, Precision, Nullability, Values, and Sensitivity

Mục tiêu của mẫu mô tả thuộc tính là tách rõ ý nghĩa nghiệp vụ và ý nghĩa kỹ thuật để cùng một trường dữ liệu được hiểu giống nhau trong ERD, API, SQL, kiểm thử và rà soát chất lượng. Với Nova Foods là bối cảnh mô phỏng, chỉ dùng dữ liệu tổng hợp, mỗi thuộc tính phải được mô tả theo cùng một khung để tránh tình trạng tên trường giống nhau nhưng cách dùng khác nhau giữa mua hàng, kho, sản xuất, bán hàng, kế toán và truy vết. Vì vậy, mẫu chuẩn phải luôn ghi đủ các trường kiểm soát dưới đây; thiếu một trường sẽ làm giảm khả năng đối chiếu và khiến quy tắc dữ liệu không còn đơn nghĩa.

Trường trong mẫu thuộc tính	Ý nghĩa bắt buộc	Quy tắc ghi nhận cho Nova Foods
Business definition	Định nghĩa nghiệp vụ, tức thuộc tính đại diện cho điều gì trong vận hành.	Phải mô tả bằng ngôn ngữ nghiệp vụ, không dùng biệt ngữ kỹ thuật. Ví dụ phải nêu “ngày giao hàng dự kiến” thay vì chỉ nói “date field”.
Technical meaning	Ý nghĩa kỹ thuật, tức thuộc tính được hệ thống lưu và xử lý như thế nào.	Phải nêu rõ đây là khóa, chỉ số, mô tả, trạng thái hay tham chiếu. Nếu là giá trị tính toán thì phải ghi rõ nguồn tính, không được mô tả mơ hồ.
Data type	Kiểu dữ liệu, tức dạng lưu trữ logic của giá trị.	Phải chỉ ra kiểu đủ để người đọc hiểu cách xử lý, như số, chuỗi, ngày giờ, cờ logic, mã, định danh hoặc tham chiếu.
Length/scale	Độ dài hoặc số chữ số có thể lưu.	Phải nêu giới hạn hữu ích cho thiết kế và kiểm soát dữ liệu. Với chuỗi là độ dài, với số là phần nguyên/phần thập phân.
Unit	Đơn vị đo lường áp dụng cho giá trị.	Chỉ ghi khi giá trị có đo lường. Nếu không có đơn vị thì phải ghi “không áp dụng” để tránh suy diễn ngầm.
Precision	Độ chính xác nghiệp vụ cần giữ.	Phải mô tả mức chi tiết cần bảo toàn, ví dụ giữ đến 2 chữ số thập phân hay đến ngày, để tránh mất ý nghĩa khi tổng hợp hoặc nhập liệu.
Minimum increment	Bước thay đổi nhỏ nhất được phép.	Phải xác định khi giá trị có thể tăng theo bậc, giúp tránh nhập giá trị lệch chuẩn so với nghiệp vụ.
Nullability	Khả năng cho phép rỗng, tức thuộc tính có được phép không có giá trị hay không.	Phải ghi rõ “cho phép rỗng” hoặc “không cho phép rỗng”. Không được để người đọc tự đoán vì khác biệt này ảnh hưởng trực tiếp đến bắt buộc nhập liệu và kiểm tra hợp lệ.
Default behavior	Hành vi mặc định khi không cung cấp giá trị.	Phải mô tả giá trị khởi tạo, quy tắc tự sinh, hoặc điều kiện không tự điền. Nếu không có mặc định thì phải ghi rõ là do người nhập hoặc hệ thống nguồn quyết định sau.
Permitted values	Tập giá trị được phép, tức danh sách giá trị hợp lệ hoặc miền hợp lệ.	Phải nêu rõ nếu là danh mục cố định, cờ đúng/sai, trạng thái hay mã chuẩn. Nếu giá trị mở rộng được thì phải chỉ ra nguyên tắc mở rộng, không viết mơ hồ “tùy chọn”.
Sensitivity	Mức nhạy cảm của dữ liệu, tức mức cần hạn chế xem, sao chép hoặc phát tán.	Phải ghi mức phù hợp với corpus mô phỏng của Nova Foods, để người đọc biết thuộc tính nào không nên dùng đại trà trong ví dụ hoặc báo cáo rộng.
Retention classification	Phân loại lưu giữ, tức nhóm quy tắc lưu trữ và hủy theo vòng đời dữ liệu.	Phải ghi nhãn lưu giữ ở mức tài liệu kế hoạch, để phân biệt dữ liệu dùng tạm, dữ liệu lưu theo nghiệp vụ, và dữ liệu cần kiểm soát dài hơn. Nếu chưa có thẩm quyền xác minh thì phải ghi là giả định dự án hoặc Verification required.

Từ nguyên tắc trên, mỗi thuộc tính trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md phải được mô tả theo cùng một thứ tự để người học có thể đọc từ trái sang phải: nghiệp vụ nói gì, hệ thống lưu gì, giá trị được phép là gì, và dữ liệu đó nhạy đến mức nào. Cách sắp xếp này có lý do rõ ràng: nếu chỉ ghi kiểu dữ liệu mà không có định nghĩa nghiệp vụ thì người dùng dễ hiểu sai; nếu chỉ ghi nghiệp vụ mà không có độ dài, độ chính xác và nullability thì thiết kế triển khai và kiểm thử sẽ thiếu căn cứ. Vì Nova Foods là dữ liệu tổng hợp mô phỏng, các trường sensitivity và retention classification phải được ghi để phục vụ kiểm soát học liệu, nhưng không được diễn giải thành cam kết tuân thủ production khi chưa có xác minh từ chủ sở hữu phù hợp.

Để giữ tính nhất quán, mọi đặc tả thuộc tính nên dùng một câu ngắn cho mỗi trường kiểm soát và không trộn nhiều ý vào một ô. Ví dụ, nếu thuộc tính vừa có ý nghĩa nghiệp vụ vừa là giá trị tham chiếu, thì business definition mô tả “đại diện cho đối tượng nào trong quy trình”, còn technical meaning mô tả “tham chiếu đến bản ghi nào trong mô hình dữ liệu”. Việc tách đôi này giúp tránh một lỗi thường gặp: cùng một thuộc tính bị dùng như mô tả ở biểu mẫu, nhưng lại bị hiểu như mã định danh trong tích hợp. Với corpus Nova Foods, yêu cầu này đặc biệt quan trọng vì cùng một thực thể có thể xuất hiện ở nhiều miền như đơn hàng, kho, lô, sản xuất và tài chính, nên mẫu thuộc tính phải đóng vai trò chuẩn hóa ngữ nghĩa trước khi bàn đến quy tắc triển khai chi tiết.

Quy tắc chọn kiểu thuộc tính theo bản chất dữ liệu

Thuộc tính (attribute) là một mẩu dữ liệu mô tả một thực thể hoặc giao dịch, ví dụ số lượng nhận hàng, ngày hết hạn hoặc mã sản phẩm. Quy tắc chọn kiểu phải dựa trên ý nghĩa nghiệp vụ trước, rồi mới đến cách lưu kỹ thuật: cùng là chuỗi ký tự nhưng product_code là mã nghiệp vụ, còn supplier_id là định danh nội bộ; vì vậy chúng không được áp dụng cùng quy tắc quản trị. Nova Foods là bối cảnh ERP mô phỏng, chỉ sử dụng dữ liệu tổng hợp; các ví dụ dưới đây không mô tả cấu hình hay dữ liệu thực tế.

Nhóm thuộc tính	Quy tắc canonical	Ví dụ theo miền Nova Foods mô phỏng	Ranh giới quyết định
Số (numeric)	Dùng số khi giá trị có ý nghĩa đo lường, tính toán, so sánh hoặc tổng hợp. Số lượng, khối lượng, tỷ lệ và tiền phải được phân biệt theo đơn vị và độ chính xác phù hợp, không lưu dưới dạng văn bản như "1.000 kg" hoặc "250000 VND". Giá trị tiền tệ mô phỏng dùng VND; không suy diễn đây là quy tắc kế toán thực tế.	received_quantity = 125.50; unit_price = 24500; vat_rate = 0.08; inventory_on_hand = 840.	Không dùng kiểu số cho mã có số 0 ở đầu, như lot_code = "000125", vì phép chuyển số sẽ làm mất ý nghĩa nhận diện. Diễn giải thuế, tiền tệ, hạch toán và làm tròn là Verification required từ Accounting và Legal Owner khi chuyển sang yêu cầu vận hành.
Ngày và thời điểm (date/time)	Dùng ngày khi chỉ cần lịch, như ngày sản xuất; dùng thời điểm khi cần xác định một sự kiện theo giờ, phút, giây, như lúc xác nhận xuất kho. Thời điểm phải gắn rõ múi giờ chuẩn Asia/Ho_Chi_Minh trong bối cảnh corpus để tránh hai hệ thống hiểu khác nhau về cùng một khoảnh khắc.	manufactured_date = 2026-07-15; expiry_date = 2026-12-15; goods_received_at = 2026-08-07T09:15:00+07:00.	Không thay ngày bằng thời điểm 00:00:00 nếu nghiệp vụ chỉ biết ngày; việc thêm giờ giả tạo tạo ra độ chính xác không có bằng chứng. Không dùng chuỗi diễn đạt tự do như "chiều mai" hoặc "15/7" làm giá trị lưu trữ canonical.
Văn bản (text)	Dùng văn bản cho nội dung do con người đọc và có thể chứa chữ Việt, dấu, khoảng trắng hoặc câu mô tả. Nội dung được lưu theo Unicode; ý nghĩa nghiệp vụ không được phụ thuộc vào việc người dùng viết hoa, viết thường, có dấu hoặc không dấu, trừ khi trường đó là mã được quản trị riêng.	product_name = "Nước ép cam 1 lít"; warehouse_note = "Kiện ngoài bị móp, đã ghi nhận khi nhận hàng".	Văn bản mô tả không là khóa liên kết, không dùng để suy luận trạng thái hoặc quyền hạn. Không nhét nhiều dữ liệu có cấu trúc vào một trường ghi chú, ví dụ không lưu "LOT-01; 25 kg; kho A" thay cho các thuộc tính riêng.
Liệt kê hữu hạn (enum)	Enum là tập giá trị đóng do hệ thống kiểm soát, mỗi giá trị biểu thị một trạng thái hoặc lựa chọn có ý nghĩa xác định. Giá trị enum phải ổn định, máy đọc được và không lấy trực tiếp từ nhãn hiển thị tiếng Việt.	inventory_movement_type = RECEIPT; production_order_status = RELEASED; quality_result = PASS.	Chỉ dùng enum khi tập lựa chọn nhỏ và thay đổi cần kiểm soát. Nếu danh sách có chủ sở hữu nghiệp vụ, có hiệu lực theo thời gian hoặc được bổ sung thường xuyên, dùng thực thể danh mục tham chiếu thay vì tiếp tục thêm enum trong mã nguồn.
Đúng/sai (boolean)	Boolean chỉ dùng khi thực sự chỉ có hai trạng thái loại trừ nhau: true hoặc false. Tên thuộc tính phải đọc được như một mệnh đề có/không, ví dụ is_active, is_quarantined, has_allergen_declaration.	is_batch_traceable = true; is_credit_hold = false.	Không dùng boolean cho tình huống có trạng thái “chưa biết”, “không áp dụng” hoặc “đang chờ”. Khi có từ ba khả năng trở lên, cần enum hoặc thuộc tính trạng thái khác để không làm mất nghĩa nghiệp vụ.
Mã nghiệp vụ (code)	Code là chuỗi ngắn, có cấu trúc và dễ nhận biết bởi người dùng hoặc đối tác trong phạm vi nghiệp vụ. Mã phải được lưu như văn bản để bảo toàn số 0 đầu, chữ cái, dấu gạch nối và phân biệt định dạng.	product_code = "NF-JUICE-001"; warehouse_code = "HCM-DC-01"; uom_code = "KG".	Mã không tự là định danh bất biến. Nếu mã có thể đổi do đổi tên sản phẩm, tái tổ chức kho hoặc thay quy ước, quan hệ nội bộ phải dựa trên định danh ổn định thay vì dựa trực tiếp vào code. Quy tắc cấp mã cụ thể thuộc nguồn nghiệp vụ được kiểm soát, không được tự suy diễn từ ví dụ.
Định danh (identifier)	Identifier là giá trị nhận diện duy nhất cho một bản ghi hoặc đối tượng trong phạm vi xác định. Định danh kỹ thuật dùng để liên kết dữ liệu phải ổn định trong suốt vòng đời bản ghi, không mang ý nghĩa nghiệp vụ có thể thay đổi và không tái sử dụng cho đối tượng khác.	product_id, purchase_order_id, inventory_lot_id, sales_order_id.	Tên, family và phạm vi canonical của định danh phải tuân theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Registry đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; việc tham chiếu registry không biến bất kỳ ID nào thành baseline hoặc xác nhận sẵn sàng production.
Tham chiếu (reference)	Reference là thuộc tính chứa định danh của bản ghi khác để diễn đạt quan hệ, ví dụ một dòng nhận hàng thuộc một đơn mua hàng. Reference phải chỉ tới đúng loại thực thể đích và không được dùng tên hiển thị, mã mô tả hoặc ghi chú thay thế cho định danh đích.	purchase_order_line.purchase_order_id → purchase_order.purchase_order_id; inventory_lot.product_id → product.product_id; sales_order.customer_id → customer.customer_id.	Reference không được tạo liên kết đa nghĩa, như một trường source_id có thể trỏ tùy ý đến đơn mua hàng, lệnh sản xuất hoặc phiếu điều chỉnh mà không kèm loại nguồn rõ ràng. Quan hệ đa nguồn cần được mô hình hóa minh bạch trong ERD, thay vì che giấu trong một chuỗi ký tự.

Quy tắc lựa chọn nhanh là: nếu dữ liệu cần tính toán thì chọn số; nếu mô tả lịch hoặc sự kiện thì chọn ngày hoặc thời điểm; nếu người dùng cần đọc nội dung tự do thì chọn văn bản; nếu chỉ được chọn từ tập đóng thì chọn enum; nếu chỉ có đúng hai khả năng thì chọn boolean; nếu cần con người nhận biết theo quy ước thì chọn code; nếu cần nhận diện ổn định thì chọn identifier; và nếu cần nối tới bản ghi khác thì chọn reference. Suy luận này bảo vệ ERD khỏi việc dùng một trường văn bản cho nhiều chức năng, đồng thời giúp các nhóm phân tích, kiến trúc và kiểm thử diễn giải cùng một thuộc tính theo một nghĩa.

Ý nghĩa nghiệp vụ, điều kiện phát sinh và ngoại lệ của từng thuộc tính phải được đối chiếu với /01-curriculum/CANONICAL_BUSINESS_RULES.md khi catalog quy tắc có nội dung phù hợp. Artifact đó cũng đang IN_REVIEW, v0.9.0, nên liên kết chỉ phục vụ truy vết học liệu; không thay thế xác minh của Business Owner, Architect, Accounting, Legal, Security hoặc QA Reviewer.

Mẫu kiểm tra tại thuộc tính và ràng buộc định dạng

Kiểm tra tại thuộc tính (attribute-level validation) là điều kiện đánh giá một giá trị đơn trước khi hệ thống lưu, truyền hoặc dùng giá trị đó trong xử lý tiếp theo. Ràng buộc định dạng (format constraint) xác định cách biểu diễn có thể chấp nhận được, ví dụ chuỗi mã phải dùng chữ in hoa và dấu gạch nối. Hai loại kiểm tra này ngăn dữ liệu sai ngay tại điểm nhập hoặc điểm nhận API, nhưng không thay thế quy tắc nghiệp vụ liên thuộc tính, liên bản ghi hoặc theo trạng thái. Cơ sở suy luận là một thuộc tính có thể kiểm tra độc lập về sự hiện diện, ký tự, độ dài và miền giá trị; ngược lại, điều kiện như “ngày hết hạn phải sau ngày sản xuất” cần so sánh nhiều thuộc tính nên phải được truy vết sang /01-curriculum/CANONICAL_BUSINESS_RULES.md, không ghi giả thành kiểm tra đơn thuộc tính.

Mã mẫu	Mẫu kiểm tra thuộc tính	Ràng buộc định dạng/đánh giá	Ví dụ dữ liệu tổng hợp Nova Foods	Kết quả khi không đạt
AVP-REQ	Bắt buộc có giá trị	Không chấp nhận null, chuỗi rỗng hoặc chuỗi chỉ gồm khoảng trắng sau khi chuẩn hóa nhập liệu.	item_name = "Bánh gạo Nova 180 g"	Từ chối lưu và chỉ rõ trường cần bổ sung.
AVP-LEN	Độ dài	Đo số ký tự sau khi cắt khoảng trắng đầu/cuối; không tự cắt bớt phần vượt giới hạn vì có thể làm đổi nghĩa.	warehouse_code = "KHO-HCM-01"	Từ chối nếu vượt giới hạn đã công bố cho thuộc tính.
AVP-CHAR	Bộ ký tự cho mã	Chỉ chấp nhận A–Z, 0–9 và -; không có khoảng trắng, ký tự tiếng Việt có dấu hoặc ký tự điều khiển.	supplier_code = "NCC-000128"	Từ chối với NCC 000128 hoặc ncc-000128 nếu chuẩn yêu cầu in hoa.
AVP-PATTERN	Biểu thức mẫu	Dùng biểu thức chính quy (regular expression, quy tắc khớp khuôn dạng chuỗi) được neo từ đầu đến cuối chuỗi để không chấp nhận phần thừa.	lot_code = "LOT-260807-001" khớp ^LOT-[0-9]{6}-[0-9]{3}$	Từ chối LOT-260807-1 vì thiếu hai chữ số thứ tự.
AVP-RANGE	Miền số	Giá trị phải nằm trong cận dưới và cận trên được định nghĩa; cận có thể bao gồm hoặc loại trừ và phải ghi rõ.	received_quantity = 125	Từ chối giá trị âm khi số lượng nhận không cho phép âm.
AVP-STEP	Bước tăng tối thiểu	Giá trị phải là bội số của bước tăng đã công bố; kiểm tra theo giá trị số, không theo chuỗi hiển thị.	weight_kg = 12.375, bước 0.001	Từ chối 12.3755 nếu chỉ nhận đến từng 0.001 kg.
AVP-DATEFMT	Định dạng ngày	Payload chỉ dùng ngày lịch YYYY-MM-DD, gồm đủ năm-tháng-ngày và là ngày tồn tại trong lịch.	expiry_date = "2026-12-31"	Từ chối "31/12/2026" và "2026-02-30".
AVP-DATETIMEFMT	Định dạng thời điểm	Payload dùng ISO 8601 có lệch múi giờ rõ ràng; thời điểm thuộc bối cảnh quản trị Nova Foods được quy chiếu Asia/Ho_Chi_Minh.	"2026-08-07T14:30:00+07:00"	Từ chối thời điểm không có phần lệch múi giờ khi giao diện hoặc tích hợp cần phân biệt thời điểm tuyệt đối.
AVP-ENUM	Tập giá trị đóng	Chỉ nhận đúng một giá trị canonical đã công bố, phân biệt chữ hoa/thường nếu quy ước thuộc tính yêu cầu.	storage_condition = "AMBIENT"	Từ chối "Nhiệt độ thường" nếu đây chỉ là nhãn hiển thị, không phải giá trị canonical.
AVP-BOOL	Giá trị logic	Chỉ nhận true hoặc false trong payload; không suy diễn từ "Có", "Không", 1, 0 hay chuỗi rỗng.	is_batch_tracked = true	Từ chối biểu diễn mơ hồ để tránh thay đổi ý nghĩa qua tích hợp.
AVP-REF	Tham chiếu tồn tại	Giá trị phải khớp định dạng mã đích và tham chiếu đến bản ghi đích còn hợp lệ theo ngữ cảnh xử lý.	product_id = "PRD-000042"	Từ chối nếu mã đúng khuôn dạng nhưng không tìm thấy sản phẩm tổng hợp tương ứng.
AVP-NORM	Chuẩn hóa trước kiểm tra	Chỉ chuẩn hóa những thao tác không làm mất nghĩa đã được quy định, như cắt khoảng trắng đầu/cuối của tên; không tự đổi mã, số lô hoặc số chứng từ.	" Kho Thành Phẩm " thành "Kho Thành Phẩm"	Ghi nhận giá trị chuẩn hóa; từ chối nếu sau chuẩn hóa vẫn vi phạm mẫu.

Quy tắc thiết kế là mỗi thuộc tính phải nêu rõ điểm kiểm tra, cách chuẩn hóa, mẫu hợp lệ, ví dụ biên và thông báo lỗi nghiệp vụ. Ví dụ, lot_code có thể kiểm tra khuôn dạng ^LOT-[0-9]{6}-[0-9]{3}$, nhưng khuôn dạng này chỉ chứng minh chuỗi có cấu trúc LOT-ngày-số thứ tự; nó không chứng minh lô thực sự được tạo, thuộc đúng sản phẩm hay được phép xuất kho. Bằng chứng là các kết luận sau cần truy vấn bản ghi khác hoặc xét trạng thái quy trình, nên phải được mô hình hóa thành quy tắc có truy vết thay vì mở rộng quá mức kiểm tra định dạng.

Thông báo lỗi phải chỉ ra trường, quy tắc bị vi phạm và cách sửa mà không tiết lộ dữ liệu nhạy cảm hoặc chi tiết nội bộ không cần thiết. Mẫu thông báo phù hợp là: lot_code phải có dạng LOT-YYMMDD-NNN, ví dụ LOT-260807-001. Mẫu này giúp người dùng sửa dữ liệu tổng hợp ngay từ lần nhập đầu tiên; đồng thời, nó không tiết lộ danh sách lô đang tồn tại, thông tin nhà cung cấp hay dữ liệu cá nhân. Yêu cầu hạn chế tiết lộ này là thực hành bảo vệ đầu vào và API phù hợp để xem xét theo OWASP ASVS 5.0.0 तथा OWASP API Security Top 10 2023; hai nguồn này là hướng dẫn bảo mật ngành, không phải căn cứ pháp lý Việt Nam.

Miền Nova Foods mô phỏng	Thuộc tính minh họa	Kiểm tra tại thuộc tính áp dụng	Ranh giới không được suy diễn
Danh mục sản phẩm	product_code	AVP-REQ, AVP-CHAR, AVP-PATTERN; ví dụ PRD-000042.	Không suy diễn mã là duy nhất nếu chưa có ràng buộc định danh được xác định ở artifact phù hợp.
Kho và tồn kho	warehouse_code	AVP-REQ, AVP-CHAR, AVP-LEN; ví dụ KHO-HCM-01.	Không suy diễn kho đang hoạt động hoặc người nhập có quyền dùng kho.
Lô và hạn dùng	lot_code, expiry_date	AVP-PATTERN cho lô; AVP-DATEFMT cho hạn dùng.	Không suy diễn hạn dùng hợp lệ so với ngày sản xuất; đó là kiểm tra liên thuộc tính.
Mua hàng	received_quantity	AVP-RANGE, AVP-STEP; không nhận số âm, áp dụng bước đo đã được định nghĩa.	Không suy diễn số nhận không vượt số đặt; đó là kiểm tra liên chứng từ.
Bán hàng	customer_reference	AVP-LEN, kiểm tra ký tự được phép theo quy ước đã công bố.	Không biến chuỗi tham chiếu thành định danh khách hàng hoặc chứng từ pháp lý.
Sản xuất	planned_output_qty	AVP-RANGE, AVP-STEP; ví dụ lượng theo kg phải tuân thủ độ chia đã quy định.	Không suy diễn đủ nguyên liệu, năng lực máy hoặc tính khả thi kế hoạch.
Tích hợp	external_reference	AVP-REQ, AVP-LEN, AVP-CHAR hoặc AVP-PATTERN theo hợp đồng giao diện được kiểm soát.	Không chấp nhận dữ liệu ngoài chỉ vì đúng khuôn dạng; vẫn cần kiểm tra nguồn gửi và tham chiếu.

Các ví dụ trên chỉ là dữ liệu tổng hợp cho Nova Foods Trading & Manufacturing mô phỏng, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và bối cảnh tiền tệ VND. Chúng là chuẩn soạn thảo đang IN_REVIEW tại v0.9.0, ngày 2026-08-07; không phải cấu hình ERP production, xác nhận tuân thủ, baseline hoặc phê duyệt. Khi một ràng buộc định dạng liên quan số chứng từ, hóa đơn, dữ liệu cá nhân, truy xuất thực phẩm hoặc thời hạn lưu giữ, phải gắn nhãn Verification required và chuyển câu hỏi cho vai trò Legal, Accounting, Security hoặc Business Owner phù hợp, vì các nguồn pháp lý trong corpus chỉ cho phép sử dụng trong ranh giới đã nêu.

Trường kiểm soát chuẩn cho bản ghi Nova Foods

Trường kiểm soát (control field) là thuộc tính không mô tả trực tiếp hàng hóa, khách hàng hay giao dịch, mà ghi nhận ai tạo/sửa, bản ghi đang ở trạng thái nào, phiên bản nào đang có hiệu lực và bằng chứng nào giải thích thay đổi. Nova Foods Trading & Manufacturing là case study ERP mô phỏng, chỉ dùng dữ liệu tổng hợp; vì vậy các ví dụ dưới đây là cấu trúc học liệu, không phải cấu hình production, bằng chứng tuân thủ, baseline hay phê duyệt.

Tên thuộc tính canonical	Ý nghĩa nghiệp vụ	Ý nghĩa kỹ thuật và cách dùng	Ví dụ dữ liệu tổng hợp
created_at	Thời điểm bản ghi lần đầu được tạo.	Hệ thống ghi một lần khi tạo; không được thay đổi bởi thao tác cập nhật nghiệp vụ. Thời điểm phải được diễn giải theo Asia/Ho_Chi_Minh khi hiển thị cho người dùng Việt Nam.	2026-08-07T09:15:00+07:00
updated_at	Thời điểm gần nhất bản ghi được thay đổi có lưu vết.	Hệ thống cập nhật khi dữ liệu bản ghi thực sự thay đổi; không dùng thay cho thời điểm phê duyệt hoặc thời điểm hiệu lực.	2026-08-07T14:30:00+07:00
created_by	Chủ thể khởi tạo bản ghi.	Lưu định danh tài khoản hoặc định danh tác nhân hệ thống đã tạo bản ghi; không lưu tên hiển thị làm khóa truy vết vì tên có thể thay đổi.	user_demo_procurement_01
updated_by	Chủ thể thực hiện thay đổi gần nhất.	Tham chiếu đến tài khoản hoặc tác nhân tích hợp gây ra lần cập nhật gần nhất; phải phân biệt tác nhân người dùng với tác nhân tự động.	svc_demo_inventory_sync
status	Nhãn tình trạng nghiệp vụ hoặc quản trị hiện tại của bản ghi.	Chỉ được lưu giá trị thuộc danh sách trạng thái đã được xác định cho đúng loại entity. status của artifact và status của dữ liệu nghiệp vụ không được suy diễn là cùng một khái niệm.	IN_REVIEW
effective_from	Thời điểm bắt đầu áp dụng nội dung của bản ghi phiên bản.	Dùng cho dữ liệu có hiệu lực theo thời gian, như giá mô phỏng, định mức hoặc chính sách nội bộ mô phỏng; không phải lúc tạo bản ghi.	2026-08-08T00:00:00+07:00
effective_to	Thời điểm kết thúc áp dụng nội dung của bản ghi phiên bản.	Dùng cùng effective_from để xác định khoảng hiệu lực; giá trị trống chỉ biểu thị chưa xác định thời điểm kết thúc trong dữ liệu mô phỏng, không phải xóa bỏ kiểm soát.	null
version	Số hoặc nhãn phiên bản của nội dung được quản trị thay đổi.	Tăng khi thay đổi có ý nghĩa cần phân biệt với bản trước; không dùng updated_at thay cho phiên bản vì hai lần cập nhật khác nhau có thể cần cùng hoặc khác phiên bản theo chính sách entity.	v0.9.0
audit_reference	Tham chiếu đến bằng chứng hoặc artifact giải thích nguồn gốc, thay đổi hay quyết định cần xem xét.	Lưu định danh và đường dẫn canonical có kiểm soát, không sao chép toàn bộ nội dung audit vào trường này.	TRACEABILITY_ID_REGISTRY; /01-curriculum/TRACEABILITY_ID_REGISTRY.md

created_at, updated_at, created_by và updated_by tạo thành dấu vết nguồn gốc tối thiểu của bản ghi. Lý do là câu hỏi “bản ghi xuất hiện khi nào, do ai tạo và lần sửa gần nhất do ai thực hiện?” cần được trả lời bằng dữ liệu có cấu trúc, thay vì suy đoán từ tên tệp, nội dung mô tả hoặc ngày xuất tài liệu. Các trường này chỉ ghi nhận sự kiện dữ liệu; chúng không chứng minh người tạo có quyền hợp lệ, nội dung đúng nghiệp vụ, hoặc thay đổi đã được phê duyệt.

status phải phản ánh đúng phạm vi đối tượng được quản trị. Ví dụ, IN_REVIEW của /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md xác định artifact đang được xem xét có kiểm soát tại phiên bản v0.9.0, ngày 2026-08-07; nó không tương đương APPROVED, BASELINED, compliant, production-ready hoặc user-approved. Khi áp dụng cho entity nghiệp vụ mô phỏng, trường status phải tham chiếu danh sách trạng thái dành riêng cho entity đó, không tái sử dụng ngầm định trạng thái artifact.

Cặp effective_from và effective_to giải quyết khác biệt giữa thời điểm lưu và thời điểm có hiệu lực. Chẳng hạn, một bảng giá bán mô phỏng có thể được tạo ngày 2026-08-07 nhưng chỉ áp dụng từ ngày 2026-08-08; khi đó created_at trả lời lịch sử nhập liệu, còn effective_from trả lời thời điểm nghiệp vụ bắt đầu sử dụng. Nếu bản ghi không có bản chất hiệu lực theo thời gian, không được thêm hai trường này chỉ để tạo cảm giác đầy đủ.

version phải được dùng khi cần phân biệt các nội dung kế tiếp của cùng một đối tượng logic, ví dụ phiên bản định mức sản xuất mô phỏng, cấu hình chất lượng mô phỏng hoặc artifact curriculum. Nhãn v0.9.0 trong corpus hiện tại là phiên bản đang IN_REVIEW; bằng chứng từ metadata của hai artifact nguồn cho thấy chưa có baseline reference và chưa có approval reference. Vì vậy, version là thông tin nhận diện thay đổi, không phải bằng chứng rằng phiên bản đó đã được chấp thuận.

audit_reference phải ưu tiên liên kết đến nguồn có kiểm soát thay vì văn bản tự do. Với quy tắc nghiệp vụ, tham chiếu canonical là CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; với quản trị định danh và quan hệ truy vết, tham chiếu canonical là TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Cách tách tham chiếu khỏi nội dung vận hành giúp người học lần lại nguồn, phiên bản và trạng thái của bằng chứng mà không biến một trường dữ liệu thành kho lưu trữ tài liệu.

Miền Nova Foods mô phỏng	Trường kiểm soát nên áp dụng	Lý do nghiệp vụ
Danh mục hàng hóa, đơn vị tính, khách hàng, nhà cung cấp	created_at, updated_at, created_by, updated_by, status, version, audit_reference	Master data cần biết nguồn tạo, lần sửa gần nhất và nội dung phiên bản nào đang được dùng trong mô phỏng.
Giá bán, định mức nguyên liệu, quy tắc phân bổ mô phỏng	Toàn bộ trường trên, bổ sung effective_from, effective_to	Nội dung có thể được nhập trước ngày áp dụng và cần phân biệt các khoảng hiệu lực.
Đơn bán hàng, phiếu nhập kho, lệnh sản xuất, điều chuyển kho mô phỏng	created_at, updated_at, created_by, updated_by, status, audit_reference	Giao dịch cần truy nguyên người hoặc tác nhân tạo/sửa và liên kết tới bằng chứng liên quan.
Lô hàng, hạn dùng, truy xuất nguồn gốc mô phỏng	created_at, updated_at, created_by, updated_by, status, audit_reference	Dữ liệu lô cần khả năng giải thích lịch sử ghi nhận và liên kết nguồn truy vết; chi tiết an toàn thực phẩm cần Verification required từ domain owner và legal owner trước khi dùng thực tế.
Chứng từ kế toán và đối soát VND mô phỏng	created_at, updated_at, created_by, updated_by, status, version, audit_reference	Cần phân biệt lịch sử xử lý và phiên bản dữ liệu; mọi diễn giải về kế toán, hóa đơn, thuế hoặc thời hạn lưu giữ thực tế vẫn là Verification required bởi Accounting và Legal Owner.

Hồ sơ kiểu SQL được hỗ trợ và biểu diễn payload API

Để ERD (Entity Relationship Diagram, sơ đồ quan hệ thực thể), SQL và API cùng diễn giải một thuộc tính theo một cách, dictionary phải ghi đồng thời kiểu logic, kiểu lưu trữ SQL chuẩn dự kiến và biểu diễn JSON (JavaScript Object Notation, định dạng trao đổi dữ liệu). Lý do là SQL phân biệt kiểu cột và khả năng tính toán trong cơ sở dữ liệu, còn JSON chỉ có các kiểu số, chuỗi, boolean, mảng, đối tượng và null; vì vậy một giá trị NUMERIC(19,0) trong SQL vẫn có thể cần truyền là chuỗi trong API để tránh mất chính xác ở client JavaScript.

Nhóm giá trị logic	Kiểu SQL hỗ trợ trong dictionary	Biểu diễn API JSON/OpenAPI 3.1.1	Quy ước Nova Foods mô phỏng	Ví dụ dữ liệu tổng hợp
Mã định danh kỹ thuật duy nhất	UUID khi DBMS hỗ trợ; nếu không, CHAR(36)	type: string, format: uuid khi áp dụng	API giữ nguyên định danh dưới dạng chuỗi; không chuyển UUID thành số. Architect xác nhận kiểu vật lý theo DBMS được chọn.	"inventory_lot_id": "4b6ea315-29b6-43e8-9625-f24c3f2f74ba"
Mã nghiệp vụ có cấu trúc	VARCHAR(n) hoặc CHAR(n) chỉ khi độ dài cố định	type: string	Không dùng kiểu số cho mã vì số 0 đầu, dấu gạch nối và chữ cái là phần nhận diện, không phải giá trị để tính toán.	"item_code": "TP-NUOC-001"
Văn bản ngắn	VARCHAR(n)	type: string, maxLength: n	Dùng cho tên hàng, tên kho mô phỏng, ghi chú ngắn; n là giới hạn ký tự đã được xác định ở định nghĩa thuộc tính.	"warehouse_name": "Kho Thành phẩm Bình An"
Văn bản dài	TEXT	type: string	Dùng khi giới hạn VARCHAR không phù hợp; API không giả định kích thước payload được chấp nhận ngoài hợp đồng endpoint.	"note": "Lô dữ liệu tổng hợp phục vụ đào tạo."
Số nguyên đếm được	SMALLINT, INTEGER hoặc BIGINT theo miền giá trị	type: integer	Dùng cho số lượng kiện, thứ tự dòng, số ngày. Chọn kiểu nhỏ nhất vẫn bao phủ miền giá trị dự kiến để giảm chi phí lưu trữ nhưng không làm tràn số.	"line_number": 2
Số thập phân chính xác	NUMERIC(p,s) hoặc DECIMAL(p,s)	type: string, pattern phù hợp với định dạng thập phân canonical	Dùng cho khối lượng, đơn giá, tỷ lệ và số tiền VND. Chuỗi API tránh sai lệch dấu phẩy động; dấu thập phân API luôn là ..	"net_weight_kg": "25.500"
Số tiền VND mô phỏng	NUMERIC(19,0)	type: string, ví dụ "125000"	Không dùng FLOAT, REAL hoặc DOUBLE PRECISION cho tiền vì các kiểu xấp xỉ có thể gây sai khác khi cộng, so sánh và đối soát. Cấu hình hạch toán thực tế là Verification required bởi Accounting và Architect.	"line_amount_vnd": "125000"
Tỷ lệ hoặc phần trăm	NUMERIC(p,s)	type: string	Lưu giá trị tỷ lệ theo dạng thập phân, ví dụ 0.0500 nghĩa là 5%; tên thuộc tính phải thể hiện rõ là rate, không dùng hậu tố %.	"discount_rate": "0.0500"
Cờ đúng/sai	BOOLEAN	type: boolean	Chỉ dùng khi thực sự có hai trạng thái nghiệp vụ. Không mã hóa boolean bằng "Y", "N", 0 hoặc 1 trong payload mới.	"is_quarantine": true
Ngày nghiệp vụ không có giờ	DATE	type: string, format: date	Dùng cho ngày hết hạn, ngày sản xuất, ngày nhận hàng khi giờ không tạo ý nghĩa nghiệp vụ. Không thêm T00:00:00 vì sẽ tạo ngộ nhận về thời điểm.	"expiry_date": "2026-12-31"
Thời điểm có múi giờ	TIMESTAMP WITH TIME ZONE hoặc kiểu tương đương DBMS	type: string, format: date-time	Dùng cho sự kiện có thứ tự thời gian như tạo phiếu hoặc ghi nhận quét lô. Payload phải có offset, ví dụ +07:00; Asia/Ho_Chi_Minh là múi giờ quản trị corpus.	"received_at": "2026-08-07T14:30:00+07:00"
Danh mục giá trị đóng	VARCHAR(n) kèm bảng tham chiếu hoặc CHECK theo quyết định kiến trúc	type: string, enum khi tập giá trị đã được kiểm soát	Không dùng enum vật lý của DBMS làm mặc định vì thay đổi tập mã có thể phức tạp khi triển khai; Architect quyết định ngoại lệ theo DBMS.	"uom_code": "KG"
Quan hệ đến bản ghi khác	Kiểu trùng chính xác với khóa được tham chiếu, ví dụ UUID hoặc VARCHAR(n)	type: string với mô tả tham chiếu	API gửi giá trị khóa, không nhúng toàn bộ đối tượng liên quan trừ khi hợp đồng endpoint quy định response mở rộng.	"supplier_id": "a72811cc-1546-4825-a58e-793559bff4ac"
Dữ liệu có cấu trúc linh hoạt	JSON hoặc JSONB chỉ khi không thể mô hình hóa ổn định bằng cột quan hệ	type: object hoặc type: array	Không dùng JSON để né thiết kế dữ liệu lõi như lô, tồn kho, đơn hàng hoặc bút toán. Mọi thuộc tính cần tìm kiếm, đối soát hoặc ràng buộc thường xuyên phải là cột hoặc quan hệ rõ ràng.	"source_metadata": {"import_channel":"training-seed"}

Quy tắc chọn kiểu: chọn DATE khi câu hỏi nghiệp vụ chỉ là “ngày nào”; chọn thời điểm có múi giờ khi cần trả lời “xảy ra lúc nào và theo thứ tự nào”. Chọn NUMERIC/DECIMAL khi giá trị phải chính xác qua phép cộng, trừ, nhân, chia; không chọn kiểu số thực xấp xỉ cho giá, tiền, khối lượng tính phí hoặc tỷ lệ ảnh hưởng chứng từ. Chọn VARCHAR thay vì CHAR cho mã có độ dài thay đổi, vì CHAR có thể tạo khoảng trắng đệm và làm phát sinh khác biệt khi so sánh giữa DBMS hoặc API.

Quy ước payload API: hợp đồng API sử dụng JSON với tên trường snake_case trùng tên thuộc tính canonical trong dictionary, ví dụ expiry_date, unit_price_vnd và inventory_lot_id. API biểu diễn ngày theo YYYY-MM-DD, thời điểm theo ISO 8601/RFC 3339 có offset, UUID và mã nghiệp vụ dưới dạng chuỗi. Decimal và tiền truyền dưới dạng chuỗi decimal canonical, không có dấu phân tách hàng nghìn, không có ký hiệu VND, và không dùng dấu phẩy làm dấu thập phân; đơn vị và tiền tệ được xác định bằng trường hoặc ngữ cảnh nghiệp vụ riêng.

Nguồn kỹ thuật cho mô tả HTTP API và schema là OpenAPI Specification 3.1.1 của OpenAPI Initiative, thuộc nhóm nguồn chuẩn tắc cho mô tả API theo source seed đã xác minh ngày 2026-08-07. OpenAPI mô tả payload và schema nhưng không quyết định DBMS hay kiểu SQL vật lý; do đó ánh xạ UUID, JSONB, TIMESTAMP WITH TIME ZONE và chiến lược decimal phải được Architect xác nhận trước khi trở thành quyết định triển khai. Nova Foods là ERP mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; hướng dẫn này ở trạng thái IN_REVIEW, phiên bản v0.9.0, không phải cấu hình production hay xác nhận tuân thủ.

Ánh xạ mẫu thuộc tính phổ biến theo miền nghiệp vụ Nova Foods

Trong Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp, một mẫu thuộc tính là nhóm trường có cùng ý nghĩa quản trị xuất hiện lặp lại giữa nhiều miền nghiệp vụ. Ánh xạ theo mẫu giúp cùng một khái niệm được biểu diễn nhất quán trong ERD (sơ đồ quan hệ thực thể), API (giao diện lập trình ứng dụng), cơ sở dữ liệu và kịch bản kiểm thử. Cơ sở suy luận là: nếu hai miền đều cần nhận diện cùng một đối tượng, đo cùng một đại lượng hoặc ghi nhận cùng một sự kiện, chúng cần dùng mẫu thuộc tính tương thích; nếu ý nghĩa nghiệp vụ khác nhau, không được ép dùng chung chỉ vì tên trường giống nhau.

Mẫu thuộc tính canonical	Miền Nova Foods áp dụng	Ví dụ dữ liệu tổng hợp	Ý nghĩa liên miền và ranh giới quyết định
Định danh nghiệp vụ	Danh mục hàng hóa, khách hàng, nhà cung cấp, kho, đơn mua, đơn bán, lệnh sản xuất	item_code: "NF-RM-001", warehouse_code: "KHO-HCM-01"	Mã hỗ trợ con người nhận biết đối tượng trong chứng từ và báo cáo. Mã hàng không được mặc định là mã lô, vì hàng hóa là danh mục ổn định còn lô là đơn vị truy xuất phát sinh theo lần nhận hoặc sản xuất.
Định danh hệ thống	Tất cả miền có bản ghi cần liên kết	item_id, sales_order_id, inventory_transaction_id	Khóa hệ thống phục vụ liên kết kỹ thuật giữa thực thể. Suy luận này xuất phát từ việc mã nghiệp vụ có thể cần thay đổi quy ước hiển thị, trong khi quan hệ dữ liệu cần duy trì ổn định. Quy tắc đặt tên và namespace phải đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không tự tạo quy ước ID thay thế.
Tham chiếu quan hệ	Mua hàng, bán hàng, tồn kho, sản xuất, kế toán tích hợp	Đơn bán tham chiếu khách hàng; dòng nhập kho tham chiếu hàng hóa, kho và lô	Thuộc tính tham chiếu diễn đạt “bản ghi này thuộc về hoặc liên quan đến bản ghi nào”. Ví dụ, giao dịch tồn kho cần tham chiếu hàng hóa và kho để trả lời đồng thời “mặt hàng gì” và “ở đâu”; chỉ có mã hàng sẽ không đủ xác định tồn tại kho.
Số lượng và đơn vị đo	Mua hàng, bán hàng, tồn kho, sản xuất, kiểm kê	quantity: 125.5, uom_code: "KG"	Số lượng phải đi cùng đơn vị đo vì 125.5 không tự cho biết là kilôgam, thùng hay chai. Miền sản xuất có thể dùng số lượng nguyên liệu và thành phẩm; miền tồn kho dùng cùng mẫu để đối chiếu nhập, xuất và số dư. Quy đổi đơn vị là quyết định nghiệp vụ và kỹ thuật cần được quản trị riêng, không suy diễn từ tên đơn vị.
Giá trị tiền tệ và tiền tệ	Báo giá, đơn bán, đơn mua, hóa đơn mô phỏng, bút toán tích hợp	unit_price: 18500, line_amount: 1850000, currency_code: "VND"	Giá trị tiền phải tách giá đơn vị, số lượng và thành tiền để có thể giải thích phép tính. VND là tiền tệ bối cảnh của case study, không xác nhận cấu hình tài chính thực tế. Diễn giải thuế, hóa đơn, doanh thu, giá vốn hoặc lưu trữ chứng từ là Verification required với Accounting và Legal Owner, đối chiếu nguồn pháp lý chính thức phù hợp.
Lô, hạn dùng và nguồn gốc	Nhập hàng, tồn kho, sản xuất, kiểm soát chất lượng, thu hồi mô phỏng	lot_code: "LOT-260801-A", expiry_date: "2027-02-01"	Mẫu này cho phép phân biệt các đơn vị cùng mã hàng nhưng khác lần nhận, ngày sản xuất hoặc hạn dùng. Bằng chứng là truy xuất hàng thực phẩm không thể chỉ dựa vào mã hàng chung khi cần khoanh vùng một lô cụ thể. Logic truy xuất và thu hồi chỉ là ngữ cảnh học liệu; yêu cầu pháp lý hoặc an toàn thực phẩm thực tế cần Business Owner và Legal Owner xác minh.
Thời điểm nghiệp vụ	Đơn hàng, nhận hàng, giao hàng, sản xuất, kiểm kê, kế toán tích hợp	order_date: "2026-08-07", received_at: "2026-08-07T14:30:00+07:00"	Ngày nghiệp vụ trả lời “sự kiện có hiệu lực khi nào”; thời điểm có múi giờ trả lời “sự kiện được ghi nhận chính xác lúc nào”. Với corpus này, mốc thời gian quản trị dùng Asia/Ho_Chi_Minh; không được suy luận rằng mọi thời điểm vận hành tương lai đều đã được chốt theo cấu hình production.
Trạng thái quy trình	Đơn mua, đơn bán, lệnh sản xuất, phiếu kho, đối soát	status: "DRAFT" hoặc status: "POSTED"	Trạng thái biểu thị vị trí của bản ghi trong vòng đời nghiệp vụ, không phải mô tả tự do. Ví dụ, đơn bán và phiếu kho đều có trạng thái nhưng tập giá trị có thể khác vì chúng đại diện các quy trình khác nhau. Danh sách trạng thái, chuyển trạng thái và ngoại lệ phải liên kết với /01-curriculum/CANONICAL_BUSINESS_RULES.md khi quy tắc được soạn và xem xét; artifact này hiện IN_REVIEW, v0.9.0, không phải baseline hay xác nhận vận hành.
Chủ thể và trách nhiệm	Bán hàng, mua hàng, phê duyệt, kho, sản xuất	customer_id, supplier_id, assigned_employee_id, approver_reference	Mẫu chủ thể xác định ai hoặc tổ chức nào tham gia giao dịch. Không dùng tên tự do làm liên kết chính vì tên có thể trùng hoặc đổi. Thuộc tính gắn với người dùng hoặc nhân sự có thể liên quan dữ liệu cá nhân; phân loại và biện pháp bảo vệ cụ thể là Verification required với Security và Legal Owner.
Địa điểm và năng lực vận hành	Kho, giao nhận, sản xuất, tồn kho	warehouse_id, bin_code: "A-01-02", production_line_code: "LINE-01"	Địa điểm trả lời nơi hàng hóa được lưu, xử lý hoặc giao nhận; năng lực vận hành trả lời nơi hoạt động được thực hiện. Mã kho không thay thế địa chỉ giao hàng, vì một địa chỉ phục vụ liên lạc còn kho là đối tượng kiểm soát tồn kho.
Tham chiếu chứng từ và đối soát	Mua hàng, bán hàng, kho, kế toán tích hợp	purchase_order_reference, delivery_note_reference, accounting_document_reference	Mẫu tham chiếu nối chuỗi bằng chứng giữa giao dịch nguồn và giao dịch nhận kết quả. Nó hỗ trợ điều tra chênh lệch giữa đơn hàng, giao nhận, tồn kho và ghi nhận tài chính mô phỏng. Không suy diễn rằng một tham chiếu chứng từ tự chứng minh tính hợp pháp, hạch toán đúng hoặc đã phát hành hóa đơn.
Phân loại và thuộc tính thương mại	Danh mục hàng hóa, bán hàng, mua hàng, báo cáo	item_category_code: "NGUYEN_LIEU", brand_code: "NOVA", sales_channel_code: "B2B"	Mẫu phân loại phục vụ lọc, tổng hợp và áp dụng chính sách theo nhóm. Chỉ dùng mã từ danh mục kiểm soát thay vì văn bản tự do khi giá trị ảnh hưởng báo cáo hoặc quy tắc. Nếu một phân loại tác động giá, thuế, hạch toán hoặc quyền bán, cần escalation tới Business Owner, Accounting hoặc Legal Owner theo tác động thực tế.

Quy tắc áp dụng là ưu tiên tái sử dụng mẫu khi ý nghĩa, chủ sở hữu và vòng đời dữ liệu tương đương; tạo mẫu chuyên biệt khi khác biệt làm thay đổi cách hiểu hoặc kết quả kiểm thử. Ví dụ, lot_code có thể xuất hiện trong nhận hàng, sản xuất và xuất kho để bảo toàn truy xuất; ngược lại, customer_id không được dùng thay cho supplier_id dù cả hai đều là đối tác, vì vai trò thương mại, nghĩa vụ quy trình và quan hệ chứng từ khác nhau. Mọi ví dụ trong bảng chỉ minh họa dữ liệu tổng hợp của Nova Foods mô phỏng, không đại diện dữ liệu, cấu hình hoặc quyết định của một doanh nghiệp thực tế.

06. Validation Rules, Lifecycle/State References, Quality Checks, and Review Controls

06.1. Quy tắc kiểm tra logic cho định danh, quan hệ và miền giá trị

Các quy tắc dưới đây áp dụng cho mô hình dữ liệu logic của Nova Foods Trading & Manufacturing là case study ERP mô phỏng, chỉ 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. Validation rule (quy tắc kiểm tra hợp lệ) là điều kiện mà một giá trị hoặc quan hệ dữ liệu phải thỏa mãn để được xem là nhất quán về mặt logic. Quy tắc này kiểm tra cấu trúc và ý nghĩa dữ liệu dự kiến, không xác nhận cấu hình ERP, hiệu lực pháp lý, cách hạch toán thực tế hoặc sự chấp thuận của bất kỳ vai trò nào.

Mã quy tắc	Phạm vi kiểm tra	Quy tắc logic bắt buộc	Ví dụ dữ liệu tổng hợp hợp lệ	Ví dụ bị từ chối	Cơ sở và kết quả khi vi phạm
DD-VAL-001	Định danh chính	Mỗi thực thể có khóa chính phải dùng một giá trị duy nhất, ổn định trong phạm vi thực thể và không được tái sử dụng cho bản ghi khác.	item_id = "ITEM-NF-0001"	Hai bản ghi cùng item_id = "ITEM-NF-0001"	Khóa chính là điểm neo để các quan hệ tham chiếu đúng một bản ghi; trùng khóa làm hệ thống không phân biệt được hai đối tượng. Từ chối bản ghi trùng.
DD-VAL-002	Hình thức định danh	ID nghiệp vụ phải theo mẫu chữ hoa, số và dấu gạch nối; không chứa khoảng trắng đầu/cuối, ký tự điều khiển hoặc giá trị chỉ gồm khoảng trắng.	supplier_id = "SUP-NF-0102"	supplier_id = " sup nf 0102 "	Mẫu nhất quán giúp con người và hệ thống đối chiếu cùng một đối tượng mà không phụ thuộc cách gõ. Từ chối giá trị sai mẫu; không tự sửa im lặng vì có thể che giấu lỗi nguồn.
DD-VAL-003	Khóa ngoại	Mỗi khóa ngoại, ví dụ customer_id, supplier_id, item_id hoặc warehouse_id, phải tham chiếu đến một khóa chính đang tồn tại của thực thể đích phù hợp vai trò.	Dòng bán hàng có customer_id = "CUS-NF-0021" và khách hàng này tồn tại.	Dòng bán hàng có customer_id = "SUP-NF-0102" hoặc một ID không tồn tại.	Referential integrity (toàn vẹn tham chiếu) bảo đảm giao dịch không trỏ đến đối tượng không có thật trong mô hình. Từ chối hoặc đưa vào luồng xử lý lỗi có kiểm soát; không tự tạo đối tượng đích.
DD-VAL-004	Tương thích vai trò quan hệ	Một định danh chỉ được dùng tại trường mang đúng vai trò nghiệp vụ. customer_id chỉ tham chiếu Khách hàng; supplier_id chỉ tham chiếu Nhà cung cấp; lot_code chỉ tham chiếu Lô hàng.	purchase_order.supplier_id = "SUP-NF-0102"	purchase_order.customer_id = "CUS-NF-0021" được dùng thay cho supplier_id	Tên trường thể hiện ngữ nghĩa quan hệ; hai đối tượng đều là đối tác nhưng có trách nhiệm quy trình khác nhau. Từ chối sai vai trò để tránh báo cáo và truy vết sai.
DD-VAL-005	Lực lượng quan hệ	Cardinality (lực lượng quan hệ) phải khớp mô tả logic: một dòng giao dịch tham chiếu đúng một mặt hàng; một mặt hàng có thể xuất hiện trong không hoặc nhiều dòng giao dịch; một dòng truy xuất lô tham chiếu tối đa một lot_code khi mặt hàng được quản lý theo lô.	Một dòng nhận hàng có một item_id và một lot_code.	Một trường item_id chứa chuỗi "ITEM-NF-0001, ITEM-NF-0002"	Quan hệ một-nhiều phải được biểu diễn bằng nhiều bản ghi con, không gộp nhiều đối tượng vào một trường. Từ chối giá trị đa đối tượng trong trường đơn trị.
DD-VAL-006	Giá trị được phép	Trường phân loại có ảnh hưởng đến xử lý, lọc hoặc báo cáo phải nhận giá trị từ tập được kiểm soát, thay vì văn bản tự do.	sales_channel_code = "B2B"	sales_channel_code = "bán sỉ tùy chọn"	Permitted values (giá trị được phép) giảm biến thể cách viết làm sai tổng hợp. Từ chối giá trị ngoài tập kiểm soát, bao gồm khác biệt chữ hoa/chữ thường nếu miền mã quy định phân biệt.
DD-VAL-007	Mã miền	Domain code (mã miền) là mã ngắn đại diện cho một tập giá trị có ý nghĩa xác định. Mã phải dùng nguyên dạng canonical và có mô tả nghiệp vụ tương ứng; không dùng số thứ tự hoặc nhãn hiển thị thay mã.	item_category_code = "NGUYEN_LIEU"	item_category_code = "1" hoặc "Nguyên liệu" khi trường yêu cầu mã	Mã miền hỗ trợ tích hợp và báo cáo nhất quán, còn nhãn có thể thay đổi theo ngôn ngữ hoặc giao diện. Từ chối mã không thuộc miền đã công bố trong từ điển.
DD-VAL-008	Nullability	Nullability (khả năng để trống) phải tuân theo ý nghĩa trường: khóa chính, khóa ngoại bắt buộc và thuộc tính quyết định nhận dạng không được null; thuộc tính tùy chọn chỉ được null khi việc thiếu giá trị không làm mất nghĩa giao dịch.	item_id có giá trị; brand_code có thể null nếu mặt hàng không áp dụng nhãn hiệu trong case study.	sales_order_line.item_id = null	Không thể xác định đối tượng giao dịch nếu thiếu khóa bắt buộc; ngược lại, ép điền dữ liệu không áp dụng sẽ tạo dữ liệu giả. Từ chối thiếu trường bắt buộc; giữ null có chủ đích cho trường tùy chọn.
DD-VAL-009	Phân biệt null, rỗng và giá trị mặc định	null nghĩa là chưa có hoặc không áp dụng theo định nghĩa trường; chuỗi rỗng "" không được dùng thay null; giá trị mặc định chỉ được dùng khi đã có nghĩa nghiệp vụ rõ ràng trong dictionary.	brand_code = null cho mặt hàng không gắn nhãn hiệu.	brand_code = "" hoặc tự gán "KHONG_CO" khi chưa định nghĩa mã này	Ba trạng thái tạo ba ý nghĩa khác nhau trong truy vấn và tích hợp. Chuẩn hóa cách biểu đạt giúp tránh đếm sai dữ liệu thiếu. Từ chối chuỗi rỗng và giá trị mặc định không được định nghĩa.
DD-VAL-010	Tham chiếu chứng từ	Trường tham chiếu như purchase_order_reference, delivery_note_reference và accounting_document_reference phải theo định dạng được định nghĩa cho loại chứng từ và không được dùng như bằng chứng tự động về tính hợp pháp hoặc hạch toán đúng.	purchase_order_reference = "PO-NF-2026-0008"	Một trường chứa đồng thời "PO-NF-2026-0008 / ghi chú gọi điện"	Tham chiếu chứng từ có chức năng nối dữ liệu, không thay thế đánh giá pháp lý hoặc kế toán. Từ chối giá trị trộn mã với ghi chú tự do; ghi chú phải thuộc trường mô tả phù hợp.

Quy ước quyết định áp dụng

Một trường được xác định là bắt buộc khi thiếu trường đó làm bản ghi không thể nhận diện, không thể đặt đúng quan hệ, hoặc không thể diễn giải giao dịch theo một nghĩa duy nhất. Ví dụ, dòng giao dịch cần item_id vì nếu không có mặt hàng thì số lượng và đơn vị tính không còn đối tượng để diễn giải. Ngược lại, một trường được xác định là tùy chọn khi nó chỉ bổ sung ngữ cảnh và việc không có giá trị vẫn không làm thay đổi nhận dạng hay quan hệ cốt lõi; ví dụ brand_code chỉ có thể để trống khi ngữ nghĩa của danh mục mặt hàng cho phép không áp dụng nhãn hiệu.

Danh sách mã miền phải tách rõ code là giá trị lưu trữ canonical và display_name là nhãn hiển thị cho người dùng. Chẳng hạn, item_category_code = "NGUYEN_LIEU" là mã; nhãn tiếng Việt có thể là “Nguyên liệu”. Sự tách biệt này cần thiết vì mã được dùng trong quan hệ, lọc và trao đổi dữ liệu, còn nhãn có thể được trình bày khác nhau mà không được làm đổi nghĩa dữ liệu. Không được suy diễn rằng các mã ví dụ là danh mục đã chốt, đã baseline hoặc được phê duyệt.

Các quy tắc về ID phải bảo toàn ranh giới quản trị của /01-curriculum/TRACEABILITY_ID_REGISTRY.md: ID hợp lệ về hình thức chỉ xác nhận tính nhất quán định danh trong corpus, không tự xác nhận nội dung nghiệp vụ, thẩm quyền quyết định hoặc khả năng triển khai. Tương tự, quy tắc kiểm tra dữ liệu không thay thế quy tắc nghiệp vụ được quản trị tại /01-curriculum/CANONICAL_BUSINESS_RULES.md; validation rule xác định dữ liệu có thể được chấp nhận về cấu trúc và quan hệ, còn quyết định nghiệp vụ về ngoại lệ hoặc tác động vận hành vẫn thuộc phạm vi quy tắc nghiệp vụ và vai trò có thẩm quyền.

Tham chiếu vòng đời và trạng thái cho thực thể có hành vi quy trình

Vòng đời (lifecycle) là chuỗi trạng thái có kiểm soát mà một bản ghi được phép đi qua từ khi được tạo đến khi kết thúc. Trạng thái (state/status) mô tả vị thế nghiệp vụ hiện tại của bản ghi tại một thời điểm; trạng thái không phải là ghi chú tự do, không thay thế ngày hiệu lực, người thực hiện hay chứng từ liên quan. Cách tách này cần thiết vì cùng một đơn hàng có thể mang trạng thái CONFIRMED nhưng vẫn cần các thuộc tính riêng để lưu thời điểm xác nhận và người xác nhận. Các tham chiếu dưới đây là kế hoạch logic cho Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp, trạng thái artifact hiện hành là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chúng không là cấu hình ERP, baseline hay xác nhận vận hành thực tế.

Nhóm thực thể logic dự kiến	Mục đích của trạng thái	Chuỗi trạng thái dự kiến	Điểm kết thúc và diễn giải
Đơn bán hàng	Phân biệt bản nháp, cam kết xử lý, hoàn tất giao hàng và hủy nghiệp vụ.	DRAFT → CONFIRMED → FULFILLED; hoặc DRAFT/CONFIRMED → CANCELLED	FULFILLED kết thúc trách nhiệm thực hiện đơn theo phạm vi bán hàng; CANCELLED giữ lịch sử nhưng không cho tiếp tục thực hiện.
Đơn mua hàng	Phân biệt đề nghị mua đang soạn, đơn đã xác nhận với nhà cung cấp, đã nhận đủ và bị hủy.	DRAFT → CONFIRMED → RECEIVED; hoặc DRAFT/CONFIRMED → CANCELLED	RECEIVED chỉ biểu thị quá trình nhận theo đơn đã hoàn tất trong mô hình học liệu; không tự xác nhận nghĩa vụ thanh toán hoặc hạch toán.
Phiếu nhận hàng	Theo dõi việc tiếp nhận hàng vật lý vào kiểm tra, chấp nhận hoặc từ chối.	DRAFT → PENDING_INSPECTION → ACCEPTED; hoặc PENDING_INSPECTION → REJECTED	ACCEPTED cho phép hàng được tham chiếu bởi nghiệp vụ tồn kho theo thiết kế sau này; REJECTED yêu cầu giữ lý do từ chối.
Lô tồn kho	Phân biệt lô có thể sử dụng, bị cách ly chất lượng, đã hết hoặc không còn hiệu lực sử dụng.	AVAILABLE ↔ QUARANTINED; AVAILABLE/QUARANTINED → EXHAUSTED hoặc EXPIRED	QUARANTINED là trạng thái hạn chế sử dụng, không đồng nghĩa với lô bị hủy; tiêu chí chất lượng và xử lý hết hạn là Verification required với Business Owner, Legal Owner và QA.
Lệnh sản xuất	Theo dõi kế hoạch sản xuất từ soạn thảo đến phát hành, thực hiện, hoàn tất hoặc hủy.	DRAFT → RELEASED → IN_PROGRESS → COMPLETED; hoặc DRAFT/RELEASED → CANCELLED	COMPLETED kết thúc lệnh sản xuất về mặt luồng nghiệp vụ mô phỏng; quy tắc tiêu hao, thành phẩm và giá thành cần được xác minh riêng với Accounting và Business Owner.
Chứng từ giao hàng	Theo dõi chuẩn bị, giao thực tế, xác nhận giao và hủy giao.	DRAFT → READY_TO_SHIP → SHIPPED → DELIVERED; hoặc DRAFT/READY_TO_SHIP → CANCELLED	DELIVERED chỉ cho biết giao nhận được ghi nhận trong case study; không tự xác nhận doanh thu, hóa đơn hoặc bằng chứng pháp lý.
Hóa đơn mô phỏng	Phân biệt hóa đơn đang lập, đã phát hành trong mô hình và bị vô hiệu theo quy trình được xác minh.	DRAFT → ISSUED; hoặc DRAFT → CANCELLED; ISSUED → VOIDED	Mọi chuyển đổi liên quan ISSUED hoặc VOIDED là Verification required với Accounting và Legal Owner do có liên hệ đến quy định hóa đơn, chứng từ.

Mỗi thực thể có trạng thái phải có tối thiểu bốn thuộc tính logic đi kèm: status_code, status_changed_at, status_changed_by và status_change_reason khi chuyển sang CANCELLED, REJECTED, QUARANTINED, EXPIRED hoặc VOIDED. Lý do là mã trạng thái chỉ trả lời “đang ở đâu”, còn thời điểm, chủ thể và nguyên nhân trả lời “ai đã thay đổi, khi nào và vì sao”; thiếu ba thông tin sau sẽ làm mất khả năng giải thích luồng nghiệp vụ mô phỏng.

Quy tắc chuyển trạng thái được diễn giải theo hướng tiến có kiểm soát: một bản ghi không được quay từ trạng thái kết thúc như COMPLETED, FULFILLED, RECEIVED, DELIVERED, EXHAUSTED, EXPIRED hoặc VOIDED về trạng thái đang xử lý chỉ bằng sửa trực tiếp mã trạng thái. Nếu nghiệp vụ cần điều chỉnh sau điểm kết thúc, thiết kế sau này phải xác định một bản ghi điều chỉnh hoặc quy trình ngoại lệ có liên kết đến bản ghi gốc. Đây là suy luận kiểm soát vì việc sửa ngược sẽ xóa dấu vết về quyết định trước đó; tuy nhiên, cơ chế điều chỉnh cụ thể vẫn là Project assumption cho đến khi Business Owner, Accounting, Architect và QA xác minh.

IN_REVIEW chỉ là trạng thái quản trị của artifact /01-curriculum/CANONICAL_DATA_DICTIONARY.md, không phải trạng thái nghiệp vụ dùng cho đơn hàng, lô hàng, lệnh sản xuất hay hóa đơn. Tương tự, không được dùng các trạng thái lifecycle dự kiến trong bảng này để suy diễn rằng /01-curriculum/TRACEABILITY_ID_REGISTRY.md hoặc /01-curriculum/CANONICAL_BUSINESS_RULES.md đã được phê duyệt; hai artifact nguồn vẫn có trạng thái IN_REVIEW, phiên bản v0.9.0, và chưa có baseline reference hoặc approval reference tại ngày 2026-08-07.

Kiểm tra chất lượng dữ liệu từ điển và xác minh nguồn

Kiểm tra chất lượng (quality check) là hoạt động đối chiếu có bằng chứng để phát hiện nội dung thiếu, mâu thuẫn, trùng lặp hoặc không xác định được nguồn gốc trước khi một thuộc tính được dùng làm đầu vào cho thiết kế tiếp theo. Áp dụng cho từ điển dữ liệu logical của Nova Foods Trading & Manufacturing, là case study ERP mô phỏng chỉ dùng dữ liệu tổng hợp; kết quả kiểm tra tại IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07 chỉ ghi nhận tình trạng rà soát, không phải baseline, phê duyệt, xác nhận tuân thủ hoặc sẵn sàng production.

Nhóm chất lượng	Điều kiện đạt có thể kiểm tra	Bằng chứng phải lưu trong dòng thuộc tính hoặc ghi chú kiểm tra	Xử lý khi không đạt
Đầy đủ (completeness)	Mỗi entity và attribute trong phạm vi phải có tên canonical, định nghĩa nghiệp vụ, kiểu dữ liệu logical, nullability, nguồn hoặc nhãn giả định/xác minh cần thiết. Thuộc tính có mã phải nêu miền mã hoặc nguồn quản trị mã.	Dòng từ điển hoàn chỉnh; tham chiếu nguồn; nhãn Project assumption hoặc Verification required nếu chưa đủ căn cứ.	Không suy đoán giá trị thiếu. Gắn nhãn phù hợp và lập câu hỏi cho vai trò có thẩm quyền.
Nhất quán (consistency)	Cùng một khái niệm phải dùng một tên, định nghĩa, kiểu dữ liệu, đơn vị và cách diễn giải thống nhất trong toàn bộ từ điển. Ví dụ, VND chỉ được diễn giải là tiền tệ mô phỏng của case study, không phải xác nhận cấu hình tài chính thực tế.	So sánh các dòng có cùng thuật ngữ, tên viết tắt, mã trạng thái hoặc đơn vị đo; ghi nhận vị trí mâu thuẫn.	Chọn cách diễn giải có nguồn hoặc rationale rõ hơn; nếu chưa phân xử được thì giữ Verification required, không tự hợp nhất nghĩa.
Duy nhất (uniqueness)	Mỗi tên entity, tên attribute trong cùng entity và định nghĩa nghiệp vụ phải phân biệt được. Hai dòng chỉ khác viết hoa, dấu tiếng Việt, gạch dưới hoặc tên viết tắt nhưng cùng nghĩa được xem là nguy cơ trùng.	Kết quả dò trùng theo tên canonical, tên thay thế và mô tả; lý do giữ riêng nếu hai khái niệm gần giống nhưng khác nghĩa.	Hợp nhất bản ghi trùng khi có cùng nghĩa; đổi tên hoặc làm rõ phạm vi khi khác nghĩa. Không tạo mã định danh mới chỉ để che giấu trùng lặp.
Truy vết (traceability)	Mỗi quyết định về thuộc tính phải lần được về một nguồn: nhu cầu nghiệp vụ mô phỏng, quy tắc nghiệp vụ, nguồn chuẩn, hoặc giả định được đánh dấu. Liên kết truy vết phải chỉ rõ đối tượng được chứng minh, không chỉ ghi tên tài liệu chung chung.	Tên artifact hoặc URL nguồn, ngày truy cập 2026-08-07, ngữ cảnh áp dụng, và giới hạn diễn giải.	Đánh dấu thiếu truy vết; không trình bày quyết định như sự thật đã xác nhận.
Xác minh nguồn (source verification)	Nguồn được phân loại đúng là nguồn chính thức, nguồn chuẩn nghề nghiệp, hay nguồn nội bộ lập kế hoạch. Nội dung chỉ được khẳng định trong giới hạn đã kiểm chứng; không suy diễn điều khoản, trang, nghĩa vụ pháp lý hoặc cấu hình ERP từ phần tóm tắt.	URL chính thức, tổ chức ban hành, phiên bản/trạng thái đã biết và “safe use boundary” tương ứng.	Hạ mức khẳng định thành Project assumption hoặc Verification required; chuyển câu hỏi đến chủ thể có thẩm quyền khi liên quan pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật.

Việc kiểm tra đầy đủ phải bắt đầu từ một câu hỏi nền tảng: người đọc có thể hiểu và sử dụng thuộc tính mà không phải đoán ý nghĩa hay không. Vì vậy, một dòng chỉ có tên như ExpiryDate nhưng không nêu đây là ngày hạn dùng của đối tượng nào, định dạng ngày giờ nào, có được để trống không và căn cứ nào dẫn đến thuộc tính này thì chưa đạt đầy đủ. Nếu thông tin về hạn dùng xuất phát từ bối cảnh truy xuất thực phẩm nhưng chưa có quyết định nghiệp vụ mô phỏng chi tiết, dòng phải ghi rõ giới hạn đó là Verification required; không được biến bối cảnh pháp luật về an toàn thực phẩm thành yêu cầu hệ thống đã được xác nhận.

Việc kiểm tra nhất quán phải phân biệt giữa khác tên và khác nghĩa. Chẳng hạn, “lô hàng” có thể được dùng để chỉ lô tồn kho, lô sản xuất hoặc chuyến giao hàng; ba cách dùng này không được coi là đồng nghĩa chỉ vì cùng chứa từ “lô”. Rationale là mỗi khái niệm có thể có vòng đời, chủ sở hữu và dữ liệu liên kết khác nhau. Người rà soát phải yêu cầu định nghĩa phân biệt đối tượng, thay vì đổi tên theo cảm tính hoặc gộp dữ liệu để làm bảng ngắn hơn.

Việc kiểm tra duy nhất không đồng nghĩa bắt buộc mọi giá trị dữ liệu đều duy nhất trong thực tế. Trong từ điển logical, mục tiêu là bảo đảm mỗi khái niệm được mô tả một lần theo phạm vi xác định và mỗi thuộc tính trong một entity có một vai trò không mơ hồ. Ví dụ, ProductCode và ProductName có thể cùng xuất hiện vì một trường là mã nhận diện còn trường kia là tên hiển thị; tuy nhiên, hai trường cùng được định nghĩa là “mã sản phẩm duy nhất” là lỗi trùng ý nghĩa cần phân tích lại.

Việc kiểm tra truy vết phải bảo toàn cầu nối lý do: “thuộc tính này tồn tại vì nguồn nào hoặc giả định nào”. Với nguồn chuẩn nghề nghiệp, có thể dùng BABOK Guide Version 3 cho thuật ngữ và hoạt động BA, hoặc ISTQB CTFL Syllabus v4.0.1 cho thuật ngữ kiểm thử, nhưng không được tạo số trang hay điều khoản không có bằng chứng. Với nguồn pháp luật Việt Nam như Luật Kế toán, Luật Bảo vệ dữ liệu cá nhân, Nghị định hướng dẫn bảo vệ dữ liệu cá nhân, Nghị định về hóa đơn chứng từ và Luật An toàn thực phẩm, từ điển chỉ ghi bối cảnh và nhu cầu xác minh; diễn giải nghĩa vụ, thời hạn lưu trữ, thuế hoặc điều kiện tuân thủ phải chờ xác nhận của vai trò được ủy quyền.

Người soạn tự đánh giá một dòng thuộc tính là đạt kiểm tra chất lượng khi có thể trả lời bằng bằng chứng cho năm câu hỏi: thuộc tính có thiếu thông tin thiết yếu không; có mâu thuẫn với cách gọi hoặc định nghĩa đang dùng không; có trùng khái niệm với dòng khác không; quyết định ghi nhận có truy ngược được nguồn không; và nguồn đó có đúng thẩm quyền cùng giới hạn sử dụng không. Nếu bất kỳ câu trả lời nào là “không xác định”, trạng thái kiểm tra phải phản ánh đúng sự không chắc chắn thay vì dùng ngôn ngữ khẳng định.

Kế hoạch đối chiếu liên-artifact và xác nhận liên kết hạ nguồn

Đối chiếu liên-artifact (cross-file check, kiểm tra có hệ thống giữa các tệp) được lập kế hoạch để bảo đảm một entity, thuộc tính, quy tắc hoặc liên kết truy vết trong từ điển này không mang ý nghĩa khác nhau khi xuất hiện ở artifact Nova Foods khác. Lý do là một định nghĩa chỉ hữu ích cho thiết kế và kiểm thử khi định danh, nguồn tham chiếu và phạm vi của nó được nối nhất quán. Các kiểm tra dưới đây chỉ áp dụng cho corpus Nova Foods Trading & Manufacturing mô phỏng giáo dục, sử dụng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ bối cảnh VND; chúng không xác nhận cấu hình ERP thực tế, tuân thủ hay khả năng đưa vào production.

Mã kiểm tra kế hoạch	Artifact đối chiếu	Đối tượng đối chiếu	Quy tắc kiểm tra và cầu nối lý do	Kết quả cần ghi nhận khi thực hiện
XFC-DD-001	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID của entity, attribute, business rule, requirement, interface hoặc test liên kết từ từ điển	Mỗi ID được tham chiếu phải giữ nguyên chuỗi canonical đã đăng ký, đúng family và không dùng biến thể viết tắt. Cầu nối: registry được xác định là nguồn chuẩn duy nhất cho quản trị định danh; vì vậy một ID lệch ký tự có thể tạo hai đối tượng truy vết giả.	Danh sách ID khớp, ID chưa đăng ký, ID trùng hoặc ID dùng sai family; mỗi sai lệch phải liên kết về đúng dòng registry hoặc được ghi là vấn đề cần xử lý.
XFC-DD-002	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Thuộc tính được ràng buộc bởi quy tắc nghiệp vụ, điều kiện, ngoại lệ và kết quả	Mỗi tham chiếu quy tắc phải dùng đúng Business Rule ID; định nghĩa trường dữ liệu không được tự biến thành quy tắc mới. Cầu nối: catalog quy tắc là nơi quản trị điều kiện và quyết định nghiệp vụ, còn từ điển chỉ mô tả cấu trúc dữ liệu hỗ trợ quy tắc đó.	Ma trận Data Dictionary ID–Business Rule ID, xác định liên kết một-một, một-nhiều hoặc chưa xác định; mâu thuẫn về tên, điều kiện hoặc phạm vi phải được nêu rõ.
XFC-DD-003	CHAPTER_MANIFEST	Artifact ID, đường dẫn canonical, thứ tự chapter, trạng thái, phiên bản và liên kết phụ thuộc của tài liệu	Giá trị quản trị của tài liệu này phải khớp entry tương ứng trong manifest. Cầu nối: manifest điều phối danh mục artifact; nếu đường dẫn hoặc phiên bản khác nhau, người đọc có thể kiểm tra nhầm bản sao không được kiểm soát.	Bản ghi đối chiếu metadata, nêu rõ khớp hoặc sai khác theo từng trường; trạng thái phải tiếp tục là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.
XFC-DD-004	Template/library artifacts được CHAPTER_MANIFEST hoặc manifest template/library canonical tham chiếu	Cấu trúc bảng, nhãn cột, quy ước datatype, khóa, nullability và traceability field	Chỉ tái sử dụng mẫu hoặc thư viện có định danh và đường dẫn canonical được manifest công bố; không coi bản sao cục bộ là nguồn chuẩn. Cầu nối: template giúp nhất quán cách biểu diễn, nhưng không có thẩm quyền thay đổi nghĩa nghiệp vụ hoặc quyết định kiến trúc.	Danh mục template/library đã đối chiếu, version được tham chiếu và các cột cần điều chỉnh; khác biệt về cấu trúc phải được giữ như chênh lệch có truy vết, không âm thầm chuẩn hóa.
XFC-DD-005	ERD sẽ được xây dựng ở giai đoạn sau	Entity, primary key, foreign key, quan hệ và cardinality	Mỗi entity và khóa trong ERD phải có định nghĩa tương ứng trong từ điển; quan hệ ERD không được tạo thuộc tính hoặc khóa vô danh. Cầu nối: ERD biểu diễn cấu trúc và quan hệ logic, nên phải kiểm chứng được ngược về nghĩa dữ liệu canonical.	Ma trận Entity/Attribute ID–ERD element ID; phát hiện entity thiếu định nghĩa, thuộc tính không có trong ERD, hoặc cardinality mâu thuẫn.
XFC-DD-006	API specification sẽ được xây dựng ở giai đoạn sau, áp dụng OpenAPI Specification OAS 3.1.1 khi API dùng OpenAPI	Request/response field, schema, enum, format, required field và error payload	Mỗi field API phải ánh xạ đến attribute canonical hoặc được giải thích là field kỹ thuật; enum API không được mở rộng domain code mà không có liên kết nguồn. Cầu nối: API là hợp đồng trao đổi dữ liệu, do đó sai khác tên hoặc kiểu dữ liệu có thể làm mất ý nghĩa dữ liệu giữa hệ thống.	Bảng mapping API field–Attribute ID, chênh lệch kiểu dữ liệu, required/nullability và domain code; việc dùng OAS chỉ là chuẩn mô tả API, không tự xác nhận kiến trúc hay bảo mật.
XFC-DD-007	Test artifacts sẽ được xây dựng ở giai đoạn sau	Test basis, test case, test data tổng hợp, expected result và evidence	Mỗi kiểm tra dữ liệu quan trọng phải truy ngược được đến attribute, rule hoặc quan hệ canonical; test case phải phân biệt dữ liệu hợp lệ và không hợp lệ. Cầu nối: theo thuật ngữ kiểm thử của ISTQB CTFL, test basis là cơ sở để thiết kế kiểm thử; không có liên kết này thì kết quả pass/fail không chứng minh được điều gì trong từ điển.	Mapping Test Case ID–Data Dictionary ID–Business Rule ID, nêu điều kiện đầu vào và kết quả mong đợi bằng dữ liệu tổng hợp; QA Reviewer xác nhận khả năng kiểm thử khi artifact tồn tại.

Việc đối chiếu được thực hiện theo chiều nguồn quản trị → từ điển → artifact hạ nguồn và chiều ngược lại. Ví dụ, một domain code xuất hiện trong API phải lần lượt truy về attribute trong từ điển, Business Rule ID nếu code chịu ràng buộc nghiệp vụ, rồi đến ID canonical trong TRACEABILITY_ID_REGISTRY. Nếu chuỗi này đứt ở bất kỳ điểm nào, kết luận hợp lệ chỉ là “liên kết chưa chứng minh được”, không phải suy đoán rằng phần tử đó đúng hoặc đã được chấp thuận.

Tại thời điểm kế hoạch v0.9.0, các kiểm tra XFC-DD-005 đến XFC-DD-007 là kiểm tra dự kiến vì ERD, API specification và test artifacts chưa được cung cấp trong phạm vi micro-batch này. Tương tự, mọi kết quả đối chiếu với TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CHAPTER_MANIFEST và template/library artifacts phải bảo toàn phân loại nguồn của từng artifact và không được diễn giải trạng thái IN_REVIEW thành APPROVED, BASELINED, production-ready hoặc đã được người dùng chấp thuận.

06.5. Checklist tự rà soát của BA về chất lượng và tuân thủ quản trị

Checklist này được Principal IT Business Analyst / Technical Curriculum Author thực hiện trước khi chuyển nội dung dictionary sang vòng xem xét tiếp theo. Tự rà soát là hoạt động BA đối chiếu nội dung đã soạn với các quy ước đã công bố để phát hiện sai lệch sớm; đây không phải phê duyệt, không thiết lập baseline và không thay thế xác minh của Business Owner, Accounting, Legal, Security, Architect hoặc QA. Phạm vi áp dụng là /01-curriculum/CANONICAL_DATA_DICTIONARY.md, 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; Nova Foods là case study mô phỏng giáo dục và chỉ dùng dữ liệu tổng hợp.

Mã kiểm	Câu hỏi tự rà soát bắt buộc	Tiêu chí đạt	Hành động khi chưa đạt
BA-SR-01	Tiêu đề, cấu trúc và nội dung có nằm đúng section được giao không?	Nội dung chỉ giải quyết mục tiêu của section; không lẫn yêu cầu thiết kế, cấu hình ERP, quyết định vận hành hoặc nội dung thuộc artifact khác.	Tách hoặc chuyển phần lạc phạm vi về artifact/section phù hợp; ghi nhận phụ thuộc thay vì tự suy diễn.
BA-SR-02	Mỗi entity, attribute, relationship hoặc rule được nhắc đến có dùng đúng tên canonical và đúng chữ hoa/thường khi ID yêu cầu không?	Không có tên dịch tự do, viết tắt không định nghĩa hoặc ID biến thể; tham chiếu registry dùng nguyên dạng TRACEABILITY_ID_REGISTRY.	Sửa về tên canonical; nếu chưa có định danh canonical, ghi Verification required thay vì tự tạo ID có vẻ chính thức.
BA-SR-03	Mỗi khẳng định có phân biệt rõ giữa dữ kiện nguồn, suy luận BA và giả định dự án không?	Dữ kiện nêu nguồn; suy luận có cầu nối lý do; nội dung chưa xác minh được gắn Project assumption hoặc Verification required.	Bổ sung nguồn hoặc lý do; hạ mức khẳng định khi chưa có bằng chứng phù hợp.
BA-SR-04	Thuật ngữ tiếng Anh chuyên môn có được giải thích bằng tiếng Việt ở lần xuất hiện đầu tiên không?	Các thuật ngữ như canonical (chuẩn dùng thống nhất), traceability (truy vết liên kết) hoặc baseline (phiên bản mốc được chốt có kiểm soát) được diễn giải trước khi sử dụng độc lập.	Viết lại câu đầu tiên chứa thuật ngữ để người học chưa có nền tảng vẫn hiểu đúng.
BA-SR-05	Các bảng có đủ tiêu đề cột, đơn vị diễn giải và điều kiện áp dụng để đọc độc lập không?	Mỗi dòng có ý nghĩa hoàn chỉnh, không dựa vào ô trống, ký hiệu mơ hồ hoặc dữ liệu bị lược bỏ.	Bổ sung ngữ cảnh cần thiết hoặc loại bỏ dòng chưa đủ thông tin kiểm soát.
BA-SR-06	Nội dung có tránh biến dữ liệu tổng hợp thành dữ liệu thực, cam kết kinh doanh hoặc bằng chứng tuân thủ không?	Mọi ví dụ về Nova Foods được hiểu là mô phỏng; không chứa dữ liệu cá nhân thực, giao dịch thực, thông tin bí mật hoặc tuyên bố production-ready.	Thay bằng dữ liệu tổng hợp rõ ràng; xóa kết luận vượt quá phạm vi học liệu.
BA-SR-07	Các nội dung có yếu tố pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, an toàn thực phẩm hoặc bảo mật có được giữ đúng ranh giới thẩm quyền không?	BA chỉ mô tả nhu cầu và nhãn cần xác minh; không diễn giải luật, xác nhận nghĩa vụ, phương pháp hạch toán hoặc biện pháp bảo mật là bắt buộc cho thực tế.	Gắn Verification required và chuẩn bị câu hỏi đơn nghĩa cho vai trò có thẩm quyền.
BA-SR-08	Nội dung có nhất quán với trạng thái quản trị hiện hành không?	Mọi tham chiếu giữ IN_REVIEW, v0.9.0, ngày 2026-08-07; không dùng từ ngữ hàm ý đã được phê duyệt, đã baseline hoặc đã chấp nhận.	Thay ngôn ngữ khẳng định bằng mô tả trạng thái xem xét có kiểm soát.
BA-SR-09	Các ví dụ và tiêu chí có thể được người đọc kiểm tra bằng artifact hoặc bằng chứng được nêu không?	Mỗi kết luận quan trọng chỉ ra đối tượng đối chiếu, điều kiện đánh giá và kết quả mong đợi; không dùng nhận định chủ quan như “hợp lý” mà không có tiêu chí.	Bổ sung tiêu chí quan sát được hoặc chuyển nội dung thành câu hỏi cần xác minh.
BA-SR-10	Ngôn ngữ có rõ ràng, đơn nghĩa và phù hợp locale vi-VN không?	Câu mô tả một trách nhiệm hoặc một quyết định; tiền tệ, ngày giờ và bối cảnh Việt Nam không bị suy diễn thành cấu hình thực tế.	Chia câu quá tải, định nghĩa lại thuật ngữ mơ hồ và giữ VND là tiền tệ mô phỏng.

BA ghi nhận kết quả checklist bằng trạng thái Đạt, Chưa đạt hoặc Không áp dụng có lý do cho từng mã kiểm. Không áp dụng có lý do chỉ hợp lệ khi nêu rõ nội dung nào không xuất hiện trong micro-batch và vì sao; trạng thái này không được dùng để bỏ qua một kiểm tra có liên quan. Nếu có bất kỳ mục Chưa đạt nào ảnh hưởng đến định danh canonical, nguồn, thẩm quyền chuyên môn, trạng thái quản trị hoặc ranh giới dữ liệu tổng hợp, nội dung phải được sửa hoặc gắn nhãn xác minh trước khi BA chuyển sang hoạt động rà soát tiếp theo.

Danh mục vấn đề mở, giả định, xác minh bắt buộc và tuyến escalation

Phần này quản trị các điểm chưa đủ căn cứ để biến thành quyết định dữ liệu của Nova Foods Trading & Manufacturing, là case study ERP mô phỏng chỉ dùng dữ liệu tổng hợp. Vấn đề mở là câu hỏi có tác động nhưng chưa có kết luận từ vai trò có thẩm quyền. Giả định dự án là cách diễn giải tạm thời để tiếp tục thiết kế học liệu, không phải quy định vận hành. Verification required là nhãn bắt buộc khi nội dung cần đối chiếu nguồn chính thức hoặc xác nhận chuyên môn trước khi được dùng làm yêu cầu. Các nhãn này không phải approval, baseline hoặc xác nhận tuân thủ vì /01-curriculum/CANONICAL_DATA_DICTIONARY.md đang ở trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Nhóm cần làm rõ	Nhãn hiện tại	Căn cứ và cầu nối suy luận	Quyết định hoặc bằng chứng cần có	Vai trò escalation chính	Tác động nếu chưa xác minh
Trường định danh khách hàng, người liên hệ, nhân viên hoặc tài khoản người dùng có phải dữ liệu cá nhân và cần hạn chế hiển thị hay không	Verification required	Các trường này có thể liên hệ đến cá nhân; Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý được nhận diện, nhưng artifact học liệu không tự diễn giải nghĩa vụ cụ thể.	Phân loại dữ liệu, mục đích sử dụng mô phỏng, đối tượng được xem, thời hạn lưu và nguyên tắc che dữ liệu trong tài liệu.	Legal, Security	Không được gắn nhãn tuân thủ pháp luật, không xác định mức nhạy cảm cuối cùng và không mô tả quyền truy cập như quyết định production.
Mã số thuế, hóa đơn, chứng từ kế toán, kỳ kế toán, thuế, doanh thu và giá vốn trong từ điển dữ liệu	Verification required	Các khái niệm này liên quan Luật Kế toán 88/2015/QH13 và Nghị định 123/2020/NĐ-CP; nguồn seed nêu rõ việc diễn giải kế toán, thuế và hóa đơn cần vai trò được ủy quyền.	Phạm vi mô phỏng của từng trường, quy tắc diễn giải chứng từ và xác nhận rằng số tiền dùng VND chỉ là dữ liệu tổng hợp.	Accounting, Legal	Không được suy diễn sơ đồ hạch toán, nghĩa vụ thuế, mẫu hóa đơn hợp lệ hoặc yêu cầu lưu trữ thực tế.
Dữ liệu lô hàng, hạn dùng, nguyên liệu, thành phẩm, thu hồi và truy xuất nguồn gốc	Project assumption kết hợp Verification required	Nova Foods có ngữ cảnh thực phẩm nên các thuộc tính này có ý nghĩa nghiệp vụ; Luật An toàn thực phẩm 55/2010/QH12 chỉ cung cấp bối cảnh nguồn, chưa đủ để tự xác định thời hạn lưu, mức truy vết hoặc quy trình thu hồi.	Business Owner xác nhận kịch bản mô phỏng; Legal xác nhận phần nào cần kiểm chứng pháp lý; QA xác định bằng chứng có thể kiểm thử cho kịch bản được chọn.	Business Owner, Legal, QA	Chỉ được dùng mô tả “dự kiến” trong học liệu; không gọi mô hình lô/hạn dùng là đáp ứng nghĩa vụ an toàn thực phẩm.
Mối liên hệ giữa mã nghiệp vụ, khóa dữ liệu, mã API và mã tích hợp	Vấn đề mở	/01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn quản trị định danh canonical, nhưng registry đang IN_REVIEW và không tự quyết định namespace kỹ thuật hay thiết kế giao diện.	Architect xác nhận ranh giới giữa business identifier, technical key và API identifier; đối chiếu tên artifact, family ID và đường dẫn canonical.	Architect, Security	Không được coi mã nghiệp vụ là khóa kỹ thuật, không công bố endpoint hoặc cấu trúc tích hợp, và không tạo mapping kỹ thuật chưa được xác nhận.
Danh mục giá trị cho trạng thái nghiệp vụ, loại chứng từ, loại kho, đơn vị tính và lý do ngoại lệ	Vấn đề mở	Giá trị miền dữ liệu thể hiện lựa chọn vận hành; /01-curriculum/CANONICAL_BUSINESS_RULES.md là nguồn catalog quy tắc dự kiến nhưng hiện chỉ có trạng thái IN_REVIEW.	Business Owner xác nhận ý nghĩa nghiệp vụ; Architect đánh giá ảnh hưởng tích hợp; QA xác nhận các giá trị có thể quan sát và kiểm thử.	Business Owner, Architect, QA	Không được diễn giải danh mục dự kiến thành master data đã chốt hoặc cấu hình ERP được phép dùng.
Trường quyền truy cập, nhật ký thao tác, token, mật khẩu, secret hoặc thông tin xác thực	Verification required	OWASP ASVS 5.0.0 và OWASP API Security Top 10 năm 2023 là nguồn thực hành bảo mật, không phải luật Việt Nam; đồng thời các trường này có nguy cơ làm lộ thông tin kiểm soát.	Security xác nhận phân loại, nguyên tắc không ghi secret vào dictionary, mức chi tiết được phép mô tả và cách tham chiếu an toàn.	Security, Architect	Không ghi giá trị mẫu giống secret, không mô tả cơ chế xác thực như thiết kế đã quyết định, và không công bố chi tiết có thể làm tăng rủi ro.
Mức chính xác tiền tệ, quy tắc làm tròn, tỷ giá, thời điểm ghi nhận và liên kết sổ cái	Project assumption kết hợp Verification required	VND là tiền tệ bối cảnh mô phỏng; mọi quy tắc ảnh hưởng số tiền có thể dẫn đến diễn giải kế toán hoặc thuế nếu không có xác nhận chuyên môn.	Accounting xác nhận phạm vi minh họa, cách ghi nhận số tiền tổng hợp và các giới hạn không được suy ra thành cấu hình tài chính.	Accounting	Không dùng ví dụ số tiền để khẳng định phương pháp hạch toán, làm tròn hoặc nghĩa vụ báo cáo thực tế.

BA chịu trách nhiệm lập gói escalation với câu hỏi đơn nghĩa, artifact bị ảnh hưởng, nhãn hiện tại, giả định đang dùng, dữ liệu tổng hợp minh họa và hậu quả nếu chưa quyết định. BA không được tự đóng vấn đề bằng nhận định thay cho Accounting, Legal, Security, Architect, QA hoặc Business Owner. Khi một điểm đồng thời liên quan pháp lý, kế toán, bảo mật hoặc kiến trúc, phải escalation đồng thời đến tất cả vai trò liên quan để tránh một kết luận cục bộ làm sai phạm vi dữ liệu.

Kết quả phản hồi phải được ghi nhận có truy vết về artifact nguồn, ngày theo Asia/Ho_Chi_Minh, vai trò cung cấp kết luận và phạm vi áp dụng cho case study. Cho đến khi có bằng chứng phù hợp trong artifact được kiểm soát, mọi nội dung trên vẫn giữ nhãn Project assumption, Verification required hoặc vấn đề mở; không được đổi thành APPROVED, BASELINED, production-ready hoặc đã được người dùng chấp thuận.