/03-templates/TMPL-DATA-002-data-model.md — Tmpl Data 002 Data Model

Trường kiểm soát	Giá trị và Diễn giải
Artifact ID	`TMPL-DATA-002` Đây là định danh (Identifier - ID) duy nhất và không thay đổi của mẫu biểu này trong toàn bộ corpus Nova Foods. Mọi tham chiếu đến mẫu biểu này từ các tài liệu khác phải sử dụng chính xác ID này để đảm bảo truy vết (traceability) tự động.
Tên tệp được kiểm soát	`/03-templates/TMPL-DATA-002-data-model.md` Đây là đường dẫn canonical (chính tắc) của tệp. Mọi bản sao, bản xuất hoặc các phiên bản khác không được coi là nguồn chân lý (source of truth).
Trạng thái (Status)	`IN_REVIEW` Tài liệu đang trong quá trình xem xét có kiểm soát. Trạng thái này không có nghĩa là đã hoàn thiện, đã được phê duyệt (approved), đã được chốt phiên bản nền (baselined) hay sẵn sàng để sử dụng trong dự án thật.
Phiên bản (Version)	`v0.9.0` Phiên bản hiện tại của tài liệu. Mọi thay đổi quan trọng sau khi được chốt phiên bản nền sẽ yêu cầu tăng số phiên bản và ghi lại lịch sử rõ ràng.
Người sở hữu (Owner)	`Principal IT Business Analyst / Technical Curriculum Author` Vai trò chịu trách nhiệm chính về việc duy trì tính toàn vẹn, cấu trúc và siêu dữ liệu (metadata) của mẫu biểu này.
Trách nhiệm của Owner	Owner có trách nhiệm bảo toàn cấu trúc 4 tầng của mẫu biểu, đảm bảo các phần Tier 2, 3, 4 tuân thủ mục đích đã định, và ghi nhận lịch sử thay đổi một cách minh bạch.
Giới hạn thẩm quyền	Vai trò Owner chỉ giới hạn ở việc quản lý tài liệu học liệu. Owner không có thẩm quyền phê duyệt yêu cầu nghiệp vụ, quyết định kiến trúc hệ thống, xác nhận tính tuân thủ pháp lý/kế toán, hay cho phép sử dụng mẫu biểu này cho mục đích sản xuất (production).
Ngày cập nhật gần nhất	`2026-08-07` Lần cuối cùng metadata hoặc nội dung của tài liệu này được cập nhật một cách có kiểm soát.
Lịch sử thay đổi	v0.9.0 (2026-08-07): Khởi tạo mẫu biểu ở trạng thái `IN_REVIEW`. Thiết lập metadata quản trị, cấu trúc 4 tầng, và mục đích sử dụng.
Tham chiếu Baseline	`Chưa có tham chiếu baseline.` Tài liệu này chưa có một phiên bản nền ổn định nào được chính thức công nhận. Không được diễn giải nội dung `IN_REVIEW` là một phiên bản nền.
Tham chiếu Phê duyệt	`Chưa có tham chiếu phê duyệt.` Sự tồn tại của tài liệu này không ngụ ý sự phê duyệt từ bất kỳ bên liên quan nào (stakeholder).
Ranh giới dữ liệu mô phỏng	CHỈ DÀNH CHO MỤC ĐÍCH GIÁO DỤC. Mọi dữ liệu, tên, quy trình và thông tin liên quan đến "Nova Foods" trong tài liệu này đều là giả lập và được tạo ra tổng hợp. Chúng không đại diện cho bất kỳ tổ chức, cá nhân hay dữ liệu vận hành thực tế nào và tuyệt đối không được sử dụng cho mục đích sản xuất.

1. Tier 1 – Metadata, Purpose, and Governance

Mục đích, Phạm vi sử dụng và Quản trị

Mẫu này cung cấp cấu trúc chuẩn hóa để định nghĩa Mô hình Dữ liệu (Data Model). Mô hình Dữ liệu là bản thiết kế trừu tượng mô tả cấu trúc, thuộc tính, quy tắc và mối quan hệ của thực thể dữ liệu trong hệ thống. Mục đích chính: tạo nguồn chân lý (single source of truth) về dữ liệu, làm cầu nối giữa yêu cầu nghiệp vụ và giải pháp kỹ thuật. Business Analyst, Lập trình viên và Kỹ sư kiểm thử dùng cùng mô hình để hiểu thống nhất về dữ liệu, giảm hiểu lầm và lỗi phát triển. Tài liệu tập trung vào mô hình dữ liệu logic (logical data model), mô tả dữ liệu theo góc nhìn nghiệp vụ, không phụ thuộc công nghệ lưu trữ cụ thể.

Bảng Metadata Quản trị

Trường metadata	Giá trị	Quy tắc quản trị và hệ quả
Artifact ID	`TMPL-DATA-002`	Định danh ổn định của template. Mọi tham chiếu phải dùng đúng ID này để giữ truy vết.
Canonical filename	`TMPL-DATA-002-data-model.md`	Tên tệp chính thức. Không đổi tên trong tham chiếu liên artifact.
Canonical path	`/03-templates/TMPL-DATA-002-data-model.md`	Nguồn chân lý duy nhất của template. Bản sao ngoài đường dẫn này không có giá trị quản trị.
status	`IN_REVIEW`	Artifact đang được xem xét. Không được diễn giải là BASELINED, đã phê duyệt, hoặc sẵn sàng phát hành.
updated	Lần cập nhật hiện tại sửa metadata quản trị, bổ sung trường `updated` và `history`, đồng thời giữ trạng thái `IN_REVIEW`.	Owner phải cập nhật trường này khi thay đổi nội dung, metadata, trạng thái hoặc phạm vi template. Không cập nhật làm mất khả năng xác định bản nội dung đang được review.
history	Lịch sử hiện có ghi nhận lần cập nhật hiện tại: bổ sung metadata `updated` và `history` để khắc phục lỗi kiểm tra metadata; trạng thái vẫn là `IN_REVIEW`.	Mỗi thay đổi sau phải ghi actor, thay đổi, lý do, tác động và trạng thái review. Không được xóa lịch sử vì sẽ phá vỡ truy vết quyết định.
Owner	`IT Business Analyst`	Owner duy trì nội dung template, metadata, lịch sử thay đổi và liên kết nguồn.
Authority	`Business Owner`; `Technical Architect`	Business Owner xác nhận logic nghiệp vụ. Technical Architect xác nhận cấu trúc và khả thi kỹ thuật. Hai vai trò có thẩm quyền phê duyệt khác nhau; `IN_REVIEW` chưa thể hiện phê duyệt từ bất kỳ vai trò nào.

Bảng dưới đây quy định các trường hợp sử dụng và không sử dụng mẫu này để đảm bảo nhất quán và tránh trùng lặp với artifact khác trong dự án Nova Foods.

Phạm vi Quy định sử dụng

Nên sử dụng khi

Định nghĩa thực thể dữ liệu mới cho hệ thống ERP, ví dụ: Sản Phẩm, Đơn Mua Hàng.
Bổ sung hoặc sửa đổi thuộc tính (trường dữ liệu) của thực thể hiện có.
Tài liệu hóa quy tắc ràng buộc (constraints), quy tắc xác thực (validation rules) và giá trị mặc định cho từng trường dữ liệu.
Xác định mối quan hệ, ví dụ: một-nhiều, nhiều-nhiều, giữa các thực thể dữ liệu.
Tạo đầu vào cho thiết kế API và lược đồ cơ sở dữ liệu (database schema).

Không sử dụng khi

Mô tả luồng quy trình nghiệp vụ. Dùng mẫu TMPL-BPMN-001-process-model.
Thiết kế giao diện người dùng (UI) hoặc trải nghiệm người dùng (UX). Dùng mẫu wireframe hoặc mock-up.
Định nghĩa danh mục quy tắc nghiệp vụ tổng thể. Tham chiếu CANONICAL_BUSINESS_RULES. Mẫu này chỉ áp dụng quy tắc đó vào thực thể dữ liệu cụ thể.
Viết đặc tả kỹ thuật chi tiết cho lược đồ cơ sở dữ liệu vật lý (physical schema), như kiểu dữ liệu CSDL hoặc chỉ mục (index). Đây là artifact xuôi dòng do Kiến trúc sư hoặc DBA tạo.

Bảng sau xác định vai trò, trách nhiệm và quan hệ của artifact tạo từ mẫu này trong quản trị chung dự án.

Vai trò & Trách nhiệm	Diễn giải và Áp dụng cho Nova Foods
Owner (Chủ sở hữu)	`IT Business Analyst` chịu trách nhiệm điền, duy trì, cập nhật metadata `updated`, duy trì `history`, và bảo đảm mô hình dữ liệu cụ thể phản ánh yêu cầu đã xác minh, ví dụ mô hình dữ liệu module Quản lý Kho.
Consumers (Đối tượng sử dụng)	Technical Architect/Solution Architect: Dùng để thiết kế kiến trúc tổng thể và lược đồ cơ sở dữ liệu vật lý. Software Developer: Dùng để lập trình đối tượng, lớp (class) và logic xử lý dữ liệu. QA Engineer: Dùng làm cơ sở viết kịch bản kiểm thử (test case), nhất là kiểm thử xác thực dữ liệu. Business Stakeholder: Xem xét mô hình để xác nhận mô hình phản ánh nhu cầu nghiệp vụ trước khi người có thẩm quyền phê duyệt.
Prerequisites (Đầu vào bắt buộc)	Yêu cầu nghiệp vụ hoặc yêu cầu người dùng đã được định nghĩa rõ. Quy tắc nghiệp vụ liên quan đã được định danh trong `CANONICAL_BUSINESS_RULES`. Thuật ngữ và định nghĩa dữ liệu cốt lõi đã có trong `CANONICAL_DATA_DICTIONARY`.
Downstream Artifacts (Đầu ra / Artifact phụ thuộc)	Đặc tả API, ví dụ dùng `TMPL-API-001-openapi-spec`. Kịch bản di chuyển dữ liệu (Database Migration Scripts). Kịch bản kiểm thử (Test Cases/Test Scenarios). Tài liệu hướng dẫn người dùng cuối (User Manual).
Authority (Thẩm quyền phê duyệt)	Business Owner: Phê duyệt logic nghiệp vụ, quy tắc và tính đầy đủ thuộc tính. Technical Architect: Phê duyệt cấu trúc, khả thi kỹ thuật và phù hợp kiến trúc chung. Trạng thái `IN_REVIEW` nghĩa là các xác nhận này chưa được ghi nhận là hoàn tất.
Escalation (Leo thang)	Khi yêu cầu nghiệp vụ xung đột với khả thi kỹ thuật, hoặc quyết định vượt thẩm quyền BA, BA phải leo thang lên `Senior IT Business Analyst` hoặc `Project Manager`. Vai trò nhận leo thang tổ chức thảo luận với bên liên quan; outcome phải được ghi vào lịch sử thay đổi hoặc log quyết định của artifact.

Định danh, Nguồn và Quản lý Thay đổi

Template này là artifact được kiểm soát trong corpus Nova Foods. Định danh, nguồn tham chiếu, metadata updated, lịch sử history và quy trình thay đổi phải tuân thủ quy tắc quản trị đã thiết lập. Mục tiêu: giữ nhất quán và khả năng truy vết (traceability) xuyên suốt bộ tài liệu.

Bảng Ánh xạ Định danh và Nguồn Canonical

Bảng này xác định định danh chính thức của template trong hệ thống quản trị curriculum. Tài liệu khác tham chiếu template phải dùng đúng định danh và đường dẫn canonical.

Thuộc tính Quản trị	Giá trị Canonical	Diễn giải và Ràng buộc
Artifact ID	`TMPL-DATA-002`	Định danh duy nhất, ổn định của template. ID được đăng ký và kiểm soát bởi `/01-curriculum/TEMPLATE_MANIFEST.md`.
Đường dẫn Canonical	`/03-templates/TMPL-DATA-002-data-model.md`	Vị trí duy nhất, nguồn chân lý (source of truth) của template. Bản sao hoặc phiên bản khác không có giá trị quản trị.
Nguồn Quản lý	`/01-curriculum/TEMPLATE_MANIFEST.md`	Thay đổi metadata template, gồm phiên bản, trạng thái, owner, `updated` và `history`, phải được phản ánh tại manifest theo quy trình quản lý thay đổi.
Nguồn Định danh	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Định danh trong ví dụ Tier 3, ví dụ `REQ-NF-123`, `UC-NF-045`, `RULE-NF-010`, phải được đăng ký và tuân thủ quy tắc tại registry.
Nguồn Thuật ngữ	`/05-glossary/GLOSS-MASTER.md`	Thuật ngữ chuyên môn phải nhất quán với từ điển thuật ngữ chung của corpus.
Nguồn lịch sử thay đổi	Metadata `history` của artifact và các bảng lịch sử trong template	`history` phải ghi thay đổi đã thực hiện, actor chịu trách nhiệm, lý do, tác động và trạng thái review. Bản ghi không đủ các yếu tố này không đủ bằng chứng truy vết.

Nghĩa vụ Kiểm soát Thay đổi (Change Control Obligations)

Việc sửa đổi template không được thực hiện tùy tiện. Mọi thay đổi phải theo quy trình kiểm soát để giữ toàn vẹn bộ tài liệu học tập.

Không sửa trực tiếp phiên bản đã Baseline: Khi template được đóng băng tại phiên bản (baselined version), không sửa trực tiếp tệp đó. Thay đổi phải thực hiện trên phiên bản mới, ví dụ từ v1.0.0 lên v1.1.0. Owner phải cập nhật updated và thêm bản ghi đầy đủ vào history. Không ghi lịch sử khiến reviewer không thể đánh giá phạm vi và tác động thay đổi.
Liên kết với nguồn: Khi định nghĩa thuộc tính dữ liệu (data attribute) có nguồn từ tiêu chuẩn, ví dụ ISO 29148, hoặc quy định pháp luật, ví dụ Luật Kế toán 88/2015/QH13, phải trích dẫn nguồn tham chiếu đã được xác minh trong /00-research/00_SOURCE_MAP.md. Không suy diễn hoặc bịa đặt yêu cầu tuân thủ. Nếu nguồn chưa được xác minh, BA không được trình bày nó như ràng buộc bắt buộc.
Đồng bộ với Từ điển Dữ liệu và Quy tắc Nghiệp vụ: Trường dữ liệu trong mô hình phải đồng bộ với /01-curriculum/CANONICAL_DATA_DICTIONARY.md về tên, kiểu dữ liệu và mô tả. Mô hình phải hỗ trợ thực thi quy tắc nghiệp vụ trong /01-curriculum/CANONICAL_BUSINESS_RULES.md. Thiếu nhất quán là lỗi cần khắc phục vì Developer, QA Engineer và Business Stakeholder có thể dùng artifact này làm căn cứ cho các outcome khác nhau.
Phạm vi Thay đổi: Owner chỉ được thay đổi trong phạm vi được phân quyền, chủ yếu cải thiện rõ ràng và khả năng sử dụng template. Thay đổi quyết định kiến trúc, nghiệp vụ, pháp lý hoặc bảo mật phải leo thang đến vai trò có thẩm quyền. BA phải ghi authority nhận quyết định, trade-off đã xem xét, outcome và hậu quả đối với artifact vào history.
Cập nhật Metadata và Lịch sử: Actor thực hiện thay đổi phải cập nhật updated để xác định lần cập nhật hiện hành và bổ sung history để ghi thay đổi, lý do, tác động, trạng thái review. Artifact giữ IN_REVIEW cho đến khi bằng chứng phê duyệt từ Business Owner và Technical Architect được ghi nhận theo quy trình quản trị.

2. Tier 2 – Mẫu trắng sẵn sàng Sao chép-Dán

Phần này cung cấp một mẫu trắng hoàn chỉnh để tài liệu hóa một mô hình dữ liệu logic. Mục đích là để một Business Analyst (BA) sao chép toàn bộ nội dung dưới đây vào một tệp mới, sau đó điền thông tin chi tiết cho một thực thể dữ liệu cụ thể trong dự án ERP của Nova Foods. Mẫu này đảm bảo tính nhất quán, đầy đủ và có khả năng truy vết nguồn gốc.

Metadata Quản trị cho Artifact Dữ liệu

Bảng này dùng để quản trị vòng đời của chính tài liệu mô hình dữ liệu này, sau khi được tạo từ mẫu.

Trường kiểm soát	Giá trị	Hướng dẫn điền
Artifact ID	`DATA-<NNN>-<tên-thực-thể-viết-liền>`	ID duy nhất được đăng ký trong `/01-curriculum/TRACEABILITY_ID_REGISTRY.md`.
Tên Thực thể Chính	`<Tên đầy đủ của thực thể được mô hình hóa>`	Tên nghiệp vụ chính, ví dụ: "Đơn đặt hàng Mua hàng".
Trạng thái	`DRAFT`	Các trạng thái hợp lệ: `DRAFT`, `IN_REVIEW`, `APPROVED`, `DEPRECATED`.
Phiên bản	`v0.1.0`	Bắt đầu với `v0.1.0`. Tăng phiên bản sau mỗi lần có thay đổi quan trọng được phê duyệt.
Owner	`<Tên và vai trò của người chịu trách nhiệm chính>`	Người chịu trách nhiệm cho tính chính xác và đầy đủ của mô hình này.
Ngày tạo	`<YYYY-MM-DD>`	Ngày tạo phiên bản đầu tiên của tài liệu này.
Ngày cập nhật gần nhất	`<YYYY-MM-DD>`	Ngày của lần cập nhật cuối cùng.
Liên kết Baseline	`<ID hoặc liên kết đến baseline nếu có>`	Để trống nếu chưa được baseline.

Mô tả Thực thể (Entity)

Thực thể (Entity) là một khái niệm, đối tượng hoặc sự vật trong thế giới thực mà chúng ta muốn lưu trữ thông tin về nó, ví dụ: Nhà cung cấp, Sản phẩm, Hóa đơn.

Tên Thực thể (Entity Name)	Mô tả & Phạm vi
`<Tên khái niệm nghiệp vụ, viết hoa chữ cái đầu>`	`<Giải thích rõ mục đích và phạm vi của thực thể này trong hệ thống Nova Foods ERP. Thực thể này đại diện cho cái gì? Nó được sử dụng trong quy trình nghiệp vụ nào? Có những giới hạn nào cần lưu ý?>`

Chi tiết các Thuộc tính (Attributes)

Thuộc tính (Attribute) là một đặc điểm hoặc tính chất của một thực thể, mô tả một mẩu thông tin cụ thể mà chúng ta cần lưu trữ. Ví dụ, thực thể Sản phẩm có các thuộc tính như Mã sản phẩm, Tên sản phẩm, Đơn vị tính.

Tên Thuộc tính (Attribute Name)	Định danh Logic (Logical Identifier)	Mô tả Nghiệp vụ	Kiểu Dữ liệu & Ràng buộc	Quan hệ (Cardinality)	Truy vết Nguồn (Traceability)
`<Tên thuộc tính nghiệp vụ>`	`<tên_kỹ_thuật_snake_case>`	`<Mô tả ý nghĩa, mục đích sử dụng và lý do cần thuộc tính này.>`	Kiểu: `<String \\| Integer \\| Decimal \\| Boolean \\| Datetime \\| UUID \\| Enum>` Bắt buộc?: `<Có \\| Không>` Giá trị mặc định: `<Giá trị nếu có>` Ràng buộc khác: `<Ví dụ: Độ dài tối đa 50, phải là giá trị duy nhất (unique), định dạng email, giá trị phải > 0.>`	`<Mô tả mối quan hệ với thực thể khác. Ví dụ: 1-1 với 'Người dùng', N-1 với 'Kho hàng'.>`	`<Liệt kê ID yêu cầu (REQ-XXX), quy tắc nghiệp vụ (BR-XXX) hoặc nguồn pháp lý (ví dụ: Luật Kế toán 88/2015/QH13) sinh ra thuộc tính này.>`
(Ví dụ) Mã Đơn hàng	`purchase_order_code`	Mã định danh duy nhất do hệ thống tạo ra cho mỗi đơn đặt hàng mua hàng, dùng để tham chiếu và tra cứu.	Kiểu: `String` Bắt buộc?: `Có` Giá trị mặc định: `(Không có)` Ràng buộc khác: `Định dạng: PO-YYYY-NNNNNN. Duy nhất (unique). Không thể thay đổi sau khi tạo.`	`(Không áp dụng, đây là khóa chính)`	`REQ-PUR-001`, `BR-PUR-005`
`<Tên thuộc tính 2>`	`<attribute_name_2>`	`<Mô tả ý nghĩa, mục đích sử dụng và lý do cần thuộc tính này.>`	Kiểu: `<String \\| Integer \\| Decimal \\| Boolean \\| Datetime \\| UUID \\| Enum>` Bắt buộc?: `<Có \\| Không>` Giá trị mặc định: `<Giá trị nếu có>` Ràng buộc khác: `<Ví dụ: Chỉ chấp nhận các giá trị từ danh mục 'Đơn vị tính'.>`	`<Ví dụ: N-1 với thực thể 'Nhà cung cấp' (supplier).>`	`<ID yêu cầu, quy tắc, nguồn pháp lý.>`
`<Tên thuộc tính 3>`	`<attribute_name_3>`	`<Mô tả ý nghĩa, mục đích sử dụng và lý do cần thuộc tính này.>`	Kiểu: `<String \\| Integer \\| Decimal \\| Boolean \\| Datetime \\| UUID \\| Enum>` Bắt buộc?: `<Có \\| Không>` Giá trị mặc định: `<Giá trị nếu có>` Ràng buộc khác: `<Mô tả ràng buộc.>`	`<Mô tả mối quan hệ.>`	`<ID yêu cầu, quy tắc, nguồn pháp lý.>`

Lịch sử Review và Phê duyệt

Bảng này ghi lại quá trình xem xét và phê duyệt mô hình dữ liệu bởi các bên liên quan.

Vai trò	Tên người Review/Phê duyệt	Ngày	Kết quả	Ghi chú / Yêu cầu thay đổi
`<Vai trò, ví dụ: Business Owner>`	`<Tên người review>`	`<YYYY-MM-DD>`	`<Chưa review \\| Approved \\| Rejected \\| Approved with comments>`	`<Ghi chú chi tiết, hoặc ID của yêu cầu thay đổi nếu có.>`
`<Vai trò, ví dụ: Technical Architect>`	`<Tên người review>`	`<YYYY-MM-DD>`	`<Chưa review \\| Approved \\| Rejected \\| Approved with comments>`	`<Ghi chú chi tiết, hoặc ID của yêu cầu thay đổi nếu có.>`
`<Vai trò, ví dụ: QA Lead>`	`<Tên người review>`	`<YYYY-MM-DD>`	`<Chưa review \\| Approved \\| Rejected \\| Approved with comments>`	`<Ghi chú chi tiết, hoặc ID của yêu cầu thay đổi nếu có.>`
`<Vai trò, ví dụ: Data Governance>`	`<Tên người review>`	`<YYYY-MM-DD>`	`<Chưa review \\| Approved \\| Rejected \\| Approved with comments>`	`<Ghi chú chi tiết, hoặc ID của yêu cầu thay đổi nếu có.>`

Bảng Quyết định, Bằng chứng và Lịch sử Thay đổi

Các bảng sau đây cung cấp một cấu trúc hoàn chỉnh để ghi lại lịch sử phiên bản, truy vết yêu cầu, các quyết định quan trọng, ngoại lệ, và quy trình xem xét phê duyệt. Đây là một phần không thể thiếu của quản trị tài liệu (document governance), đảm bảo tính minh bạch và khả năng kiểm tra lại. Mỗi mục phải được điền đầy đủ, không bỏ trống hàng.

Lịch sử phiên bản (Version History)

Bảng này theo dõi tất cả các thay đổi được thực hiện trên tài liệu mô hình dữ liệu.

Phiên bản	Ngày (YYYY-MM-DD)	Tác giả	Ghi chú thay đổi
`v0.1.0`	`<Ngày tạo>`	`<Tên tác giả>`	`<Khởi tạo tài liệu với cấu trúc cơ bản.>`
`<Số phiên bản mới>`	`<Ngày cập nhật>`	`<Tên người cập nhật>`	`<Mô tả ngắn gọn, súc tích về nội dung thay đổi trong phiên bản này.>`

Truy vết và Bằng chứng (Traceability and Evidence)

Bảng này liên kết từng thành phần của mô hình dữ liệu với các nguồn gốc của nó, chẳng hạn như yêu cầu nghiệp vụ, quy tắc nghiệp vụ, hoặc văn bản pháp lý. Việc này rất quan trọng để chứng minh rằng mô hình dữ liệu đáp ứng đầy đủ các yêu cầu đã nêu.

ID Mục dữ liệu: Định danh duy nhất cho trường hoặc thực thể dữ liệu (ví dụ: Supplier.TaxCode).
Loại Liên kết: Kiểu quan hệ, ví dụ: Satisfies (Đáp ứng), DerivedFrom (Bắt nguồn từ), VerifiedBy (Xác minh bởi).
ID Tham chiếu: ID của artifact nguồn, phải tồn tại trong các registry của dự án (ví dụ: REQ-NF-015, BR-NF-TAX-001, SRC-LEGAL-VN-123).

ID Mục dữ liệu	Loại Liên kết	ID Tham chiếu	Ghi chú
`<TênBảng.TênTrường>`	`<Satisfies / DerivedFrom / VerifiedBy>`	`<ID từ TRACEABILITY_ID_REGISTRY>`	`<Lý do cụ thể cho liên kết này, ví dụ: "Trường này đáp ứng yêu cầu lưu trữ mã số thuế theo Luật Kế toán".>`
`<TênBảngKhác.TênTrườngKhác>`	`<Satisfies / DerivedFrom / VerifiedBy>`	`<ID-tham-chiếu-khác>`	`<Mô tả lý do liên kết.`

Bảng ghi nhận Quyết định và Ngoại lệ (Decision and Exception Log)

Ghi lại các quyết định thiết kế quan trọng hoặc các trường hợp ngoại lệ được phê duyệt đi ngược lại quy tắc chung.

ID Quyết định/Ngoại lệ	Ngày (YYYY-MM-DD)	Chủ đề	Nội dung Quyết định/Ngoại lệ	Lý do (Rationale)	Người quyết định	Trạng thái
`<DEC-DM-XXX / EXC-DM-XXX>`	`<Ngày quyết định>`	`<Mô tả ngắn về vấn đề>`	`<Mô tả chi tiết quyết định đã được đưa ra hoặc ngoại lệ được chấp thuận.>`	`<Giải thích tại sao quyết định này là tối ưu, bao gồm các phương án đã bị loại bỏ.>`	`<Tên và vai trò của người có thẩm quyền.>`	`<Proposed / Approved / Rejected>`

Bảng theo dõi Xem xét và Phê duyệt (Review and Sign-off Log)

Ghi lại bằng chứng chính thức về việc các bên liên quan có thẩm quyền đã xem xét và phê duyệt mô hình dữ liệu.

Vai trò	Tên người xem xét/phê duyệt	Ngày (YYYY-MM-DD)	Kết quả	Ghi chú / Điều kiện phê duyệt
`<Vai trò có thẩm quyền (VD: Business Owner)>`	`<Tên đầy đủ>`	`<Ngày xem xét>`	`<Approved / Approved with Conditions / Changes Requested / Rejected>`	`<Ghi chú chi tiết phản hồi, hoặc các điều kiện phải được đáp ứng để phê duyệt có hiệu lực.>`
`<Vai trò có thẩm quyền (VD: Technical Architect)>`	`<Tên đầy đủ>`	`<Ngày xem xét>`	`<Approved / Approved with Conditions / Changes Requested / Rejected>`	`<Nếu có yêu cầu thay đổi, mô tả rõ ràng tại đây.>`
`<Vai trò có thẩm quyền (VD: Legal / Compliance)>`	`<Tên đầy đủ>`	`<Ngày xem xét>`	`<Approved / Approved with Conditions / Changes Requested / Rejected>`	`<Ghi rõ các điểm cần lưu ý về pháp lý hoặc tuân thủ.>`

Hướng dẫn điền trường, quy tắc và giá trị cho phép

Phần này cung cấp hướng dẫn chi tiết để điền vào biểu mẫu mô hình dữ liệu. Việc tuân thủ các quy tắc này đảm bảo tính nhất quán, rõ ràng và toàn vẹn của dữ liệu trên toàn bộ hệ thống Nova Foods. Mỗi trường phải được định nghĩa theo cấu trúc và quy tắc xác thực (validation rules) được chỉ định.

Cấu trúc bảng định nghĩa trường dữ liệu

Sử dụng bảng sau để định nghĩa từng thuộc tính (field) trong một thực thể dữ liệu (data entity).

Cột	Hướng dẫn điền
Tên trường logic (Logical Field Name)	Tên nghiệp vụ của trường, dễ hiểu cho người đọc. Dùng tiếng Anh, theo quy tắc `PascalCase`. Ví dụ: `CustomerFirstName`.
Định danh (Identifier)	Mã định danh duy nhất của trường trong từ điển dữ liệu chính tắc (canonical data dictionary). Ví dụ: `CUST-001`.
Kiểu dữ liệu (Data Type)	Kiểu dữ liệu logic. Ví dụ: `String`, `Integer`, `Decimal(18,2)`, `Boolean`, `Date`, `Timestamp`, `UUID`, `JSONB`.
Định dạng / Quy tắc xác thực	Quy tắc cụ thể trường phải tuân theo. Ví dụ: `YYYY-MM-DD`, `chuỗi 10 chữ số`, `phải là email hợp lệ`, `> 0`.
Bắt buộc? (Required?)	`Yes` nếu trường không được để trống (NOT NULL). `No` nếu có thể để trống (NULLABLE). Ghi rõ điều kiện nếu là bắt buộc có điều kiện.
Mô tả nghiệp vụ	Giải thích ý nghĩa và mục đích của trường trong bối cảnh nghiệp vụ Nova Foods.
Ví dụ	Một ví dụ về giá trị hợp lệ. Ví dụ: `2026-10-20` cho trường `Date`.
Ghi chú	Các thông tin bổ sung, giả định hoặc phụ thuộc khác.

Quy tắc xác thực và giá trị cho phép phổ biến

Bảng dưới đây liệt kê các quy tắc xác thực (validation rules) và bộ giá trị được phép tiêu chuẩn. Phải ưu tiên sử dụng các quy tắc này để đảm bảo tính đồng bộ.

Loại quy tắc	Tên quy tắc	Mô tả chi tiết và ví dụ
Định danh	`ID-FORMAT-NF`	Các định danh do Nova Foods tạo phải theo mẫu `NF-[PREFIX]-[VALUE]`. Ví dụ: `NF-PO-202600101` cho đơn mua hàng.
Định danh	`UUIDv4`	Đối với các định danh kỹ thuật, sử dụng UUID phiên bản 4. Ví dụ: `f47ac10b-58cc-4372-a567-0e02b2c3d479`.
Ngày giờ	`ISO-8601-DATE`	Ngày phải theo định dạng `YYYY-MM-DD`. Ví dụ: `2026-08-07`.
Ngày giờ	`ISO-8601-TIMESTAMP`	Dấu thời gian phải theo định dạng `YYYY-MM-DDTHH:mm:ss.sssZ` (UTC). Ví dụ: `2026-08-07T14:30:00.000Z`.
Phiên bản	`SEMVER`	Phiên bản phần mềm hoặc tài liệu phải tuân thủ Semantic Versioning. Ví dụ: `v1.2.0`.
Phân loại	`DATA-CLASSIFICATION`	Phân loại dữ liệu. Giá trị cho phép: `Public`, `Internal`, `Confidential`, `Restricted`.
Trạng thái	`STATUS-LIFECYCLE`	Trạng thái của một đối tượng (ví dụ: đơn hàng, tài liệu). Giá trị phải được định nghĩa riêng cho từng quy trình. Ví dụ cho đơn hàng: `Pending`, `Confirmed`, `Shipped`, `Delivered`, `Cancelled`.
Tiền tệ	`CURRENCY-CODE`	Mã tiền tệ theo ISO 4217. Trong bối cảnh Việt Nam, mặc định là `VND`.

Các mục có điều kiện

Một số phần trong biểu mẫu chỉ cần điền khi có điều kiện cụ thể. * Thông tin dữ liệu cá nhân (PII): Nếu trường Contains PII được chọn là Yes, bạn phải hoàn thành mục PII Details. Mục này yêu cầu mô tả loại dữ liệu cá nhân, mục đích thu thập, và tham chiếu đến quy định của Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15). * Trường mã hóa: Nếu trường Is Encrypted được chọn là Yes, bạn phải điền mục Encryption Details, chỉ rõ thuật toán mã hóa được kiến trúc sư hệ thống phê duyệt.

Mẫu tham chiếu bí mật an toàn (Safe Secret-Reference)

Không bao giờ ghi trực tiếp các thông tin nhạy cảm như mật khẩu, API key, hoặc chuỗi kết nối (connection string) vào tài liệu này. Thay vào đó, hãy sử dụng một chuỗi tham chiếu an toàn. Hệ thống sẽ dùng tham chiếu này để lấy giá trị thật từ một kho lưu trữ an toàn (ví dụ: HashiCorp Vault, Azure Key Vault) tại thời điểm chạy (runtime).

Quy tắc: Sử dụng định dạng {{VAULT:path/to/secret}}. * Ví dụ đúng: {{VAULT:nova-foods/prod/erp-database-password}} * Ví dụ sai: P@ssw0rd123!

Lý do: Việc này ngăn chặn rò rỉ thông tin nhạy cảm khi tài liệu được lưu trữ trong hệ thống quản lý phiên bản (như Git) hoặc được chia sẻ qua email/chat. Đây là một thực hành tốt theo tiêu chuẩn an ninh ứng dụng như OWASP ASVS.

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

Bối cảnh: Phòng Mua hàng Nova Foods tạo Đơn Mua Hàng (Purchase Order). Đặt bao bì sản phẩm. Tài liệu này mô hình hóa PurchaseOrder và PurchaseOrderItem.

3.1. Thực thể chính: Đơn Mua Hàng (`PurchaseOrder`)

Bảng định nghĩa trường dữ liệu PurchaseOrder. Dùng cho ERP Nova Foods.

ID Yếu tố Dữ liệu	Tên Nghiệp vụ	Tên Kỹ thuật (`camelCase`)	Kiểu Dữ liệu	Định dạng / Quy tắc	Mô tả	Ví dụ	Nguồn chân lý	Chứa PII	Mã hóa
`DE-PO-001`	Mã Đơn Mua Hàng	`purchaseOrderId`	STRING	`PO-YYYY-MM-NNNNN`	ID duy nhất. Không đổi.	`PO-2026-08-00123`	ERP System	No	No
`DE-PO-002`	Mã Nhà Cung Cấp	`supplierId`	STRING	`NCC-NNN`	Khóa ngoại. Trỏ tới `Supplier` đã duyệt.	`NCC-008`	ERP System	No	No
`DE-PO-003`	Ngày Đặt Hàng	`orderDate`	DATETIME	ISO 8601 (`YYYY-MM-DDTHH:mm:ssZ`)	Thời điểm tạo. Dùng UTC.	`2026-08-07T10:30:00Z`	ERP System	No	No
`DE-PO-004`	Mã Nhân viên Yêu cầu	`requesterId`	STRING	`NV-NNNN`	Khóa ngoại. Trỏ tới `Employee` tạo yêu cầu.	`NV-0451`	ERP System	No	No
`DE-PO-005`	Tổng Tiền (chưa VAT)	`totalAmount`	NUMBER	`Decimal(18, 2)`	Tổng giá trị các mục. Tự động tính. Đơn vị VND.	`137500000.00`	ERP System	No	No
`DE-PO-006`	Trạng thái Đơn hàng	`status`	ENUM	Xem Bảng 3.2	Trạng thái quy trình. Kiểm soát hành động.	`PENDING_APPROVAL`	ERP System	No	No
`DE-PO-007`	Ghi chú	`notes`	STRING	`TEXT`, max 1000 chars	Ghi chú nội bộ. NCC không thấy.	`Hàng cần gấp cho lô sản xuất tháng 9.`	ERP System	No	No

3.2. Bảng kê Trạng thái Đơn Mua Hàng (`PurchaseOrderStatus`)

Trường status dùng ENUM. Giúp nhất quán. Kiểm soát quy trình.

Giá trị Kỹ thuật	Tên Nghiệp vụ	Mô tả
`PENDING_APPROVAL`	Chờ duyệt	Đã tạo. Cần quản lý duyệt.
`APPROVED`	Đã duyệt	Đã duyệt. Sẵn sàng gửi NCC.
`REJECTED`	Bị từ chối	Bị quản lý từ chối.
`ORDERED`	Đã đặt hàng	Đã gửi NCC.
`CONFIRMED`	NCC đã xác nhận	NCC xác nhận thực hiện.
`SHIPPED`	Đã giao hàng	NCC đã giao hàng.
`RECEIVED`	Đã nhận hàng	Nova Foods đã nhận hàng, kiểm tra chất lượng.
`CANCELLED`	Đã hủy	Đơn hàng bị hủy.

3.3. Thực thể phụ: Mục hàng trong Đơn Mua Hàng (`PurchaseOrderItem`)

Mỗi đơn hàng có nhiều mục hàng. Bảng này mô hình hóa một mục.

ID Yếu tố Dữ liệu	Tên Nghiệp vụ	Tên Kỹ thuật (`camelCase`)	Kiểu Dữ liệu	Định dạng / Quy tắc	Mô tả	Ví dụ	Nguồn chân lý
`DE-POI-001`	ID Mục hàng	`purchaseOrderItemId`	UUID	UUID v4	ID duy nhất cho mỗi dòng.	`a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d`	ERP System
`DE-POI-002`	Mã Đơn Mua Hàng	`purchaseOrderId`	STRING	`PO-YYYY-MM-NNNNN`	Khóa ngoại. Liên kết về `PurchaseOrder`.	`PO-2026-08-00123`	ERP System
`DE-POI-003`	Mã Sản phẩm/Vật tư	`productId`	STRING	`PROD-VT-NNNNN`	ID vật tư được mua.	`PROD-VT-0025A`	ERP System
`DE-POI-004`	Số lượng	`quantity`	NUMBER	`Integer`, > 0	Số lượng cần mua.	`5000`	ERP System
`DE-POI-005`	Đơn giá	`unitPrice`	NUMBER	`Decimal(18, 2)`	Giá mỗi đơn vị. Đơn vị VND.	`15000.00`	ERP System
`DE-POI-006`	Thành tiền	`lineTotal`	NUMBER	`Decimal(18, 2)`	`quantity` * `unitPrice`. Tự động tính.	`75000000.00`	ERP System

3.4. Ví dụ Payload Dữ liệu (`JSON`)

Ví dụ payload PurchaseOrder hoàn chỉnh. Dùng cho API tạo đơn hàng.

{
  "purchaseOrderId": "PO-2026-08-00123",
  "supplierId": "NCC-008",
  "orderDate": "2026-08-07T10:30:00Z",
  "requesterId": "NV-0451",
  "status": "PENDING_APPROVAL",
  "totalAmount": 137500000.00,
  "currency": "VND",
  "notes": "Hàng cần gấp cho lô sản xuất tháng 9. Yêu cầu chứng nhận an toàn thực phẩm.",
  "items": [
    {
      "purchaseOrderItemId": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
      "productId": "PROD-VT-0025A",
      "productName": "Thùng carton 5 lớp (60x40x40cm)",
      "quantity": 5000,
      "unitPrice": 15000.00,
      "lineTotal": 75000000.00
    },
    {
      "purchaseOrderItemId": "f0e9d8c7-b6a5-4f3e-2d1c-0b9a8f7e6d5c",
      "productId": "PROD-VT-0108B",
      "productName": "Túi hút chân không PA/PE (20x30cm)",
      "quantity": 25000,
      "unitPrice": 2500.00,
      "lineTotal": 62500000.00
    }
  ]
}

Ví dụ hoàn chỉnh: Mô hình Dữ liệu cho 'Đơn Mua Hàng' (Purchase Order)

Đây là mô hình dữ liệu logic cho thực thể PurchaseOrder (Đơn Mua Hàng) trong hệ thống ERP của Nova Foods. Mô hình này bao gồm các trường chính, thực thể liên quan, vòng đời trạng thái, quy tắc nghiệp vụ và một ví dụ payload JSON.

1. Cấu trúc Thực thể (Entity Structure)

Hai thực thể chính là PurchaseOrder (đầu mục đơn hàng) và PurchaseOrderItem (dòng chi tiết sản phẩm).

Bảng 1: Thực thể PurchaseOrder Tham chiếu từ điển dữ liệu: CDD-ENTITY-004

Tên trường logic	Kiểu dữ liệu	Diễn giải & Ví dụ	Ràng buộc & Quy tắc
`po_id`	`UUID`	Khóa chính duy nhất của đơn hàng. Ví dụ: `a1b2c3d4-e5f6-7890-1234-567890abcdef`	`PRIMARY KEY`, `NOT NULL`
`supplier_id`	`UUID`	Khóa ngoại tham chiếu đến nhà cung cấp trong `Supplier`. Ví dụ: `s-987-xyz`	`FOREIGN KEY`, `NOT NULL`
`order_date`	`TIMESTAMPTZ`	Ngày và giờ tạo đơn hàng. Ví dụ: `2026-10-20T10:00:00+07:00`	`NOT NULL`
`created_by_user_id`	`UUID`	Khóa ngoại tham chiếu đến người dùng tạo đơn trong `User`.	`FOREIGN KEY`, `NOT NULL`
`status`	`ENUM`	Trạng thái hiện tại của đơn hàng. Xem Vòng đời Trạng thái bên dưới.	`NOT NULL`, phải thuộc tập (`DRAFT`, `SUBMITTED`, `APPROVED`, `REJECTED`, `FULFILLED`, `CLOSED`)
`total_value`	`DECIMAL(18, 2)`	Tổng giá trị đơn hàng, tự động tính từ các dòng chi tiết.	`NOT NULL`, `VALUE >= 0`
`currency`	`VARCHAR(3)`	Mã tiền tệ theo ISO 4217.	`NOT NULL`, `DEFAULT 'VND'`

Bảng 2: Thực thể PurchaseOrderItem Tham chiếu từ điển dữ liệu: CDD-ENTITY-005

Tên trường logic	Kiểu dữ liệu	Diễn giải & Ví dụ	Ràng buộc & Quy tắc
`po_item_id`	`UUID`	Khóa chính duy nhất của dòng chi tiết.	`PRIMARY KEY`, `NOT NULL`
`po_id`	`UUID`	Khóa ngoại tham chiếu đến `PurchaseOrder` cha.	`FOREIGN KEY`, `NOT NULL`, `ON DELETE CASCADE`
`product_id`	`UUID`	Khóa ngoại tham chiếu đến sản phẩm trong `Product`.	`FOREIGN KEY`, `NOT NULL`
`quantity`	`DECIMAL(10, 3)`	Số lượng sản phẩm đặt mua.	`NOT NULL`, `VALUE > 0`
`unit_price`	`DECIMAL(18, 2)`	Đơn giá của sản phẩm tại thời điểm đặt hàng.	`NOT NULL`, `VALUE >= 0`
`line_total`	`DECIMAL(18, 2)`	Tổng giá trị của dòng (`quantity` * `unit_price`).	`NOT NULL`, `VALUE >= 0`

2. Vòng đời Trạng thái (Status Lifecycle) cho PurchaseOrder

Vòng đời xác định các trạng thái và các quy tắc chuyển đổi hợp lệ.

Trạng thái	Diễn giải	Chuyển tiếp hợp lệ từ	Điều kiện & Hành động
`DRAFT`	Bản nháp, có thể sửa đổi tự do.	(Trạng thái khởi tạo)	Người dùng tạo đơn hàng.
`SUBMITTED`	Đã gửi đi để chờ phê duyệt.	`DRAFT`, `REJECTED`	Người dùng nhấn "Gửi duyệt". Đơn hàng bị khóa, không thể sửa.
`APPROVED`	Đã được cấp có thẩm quyền phê duyệt.	`SUBMITTED`	Người quản lý có quyền duyệt chấp thuận. Kích hoạt quy trình mua hàng.
`REJECTED`	Bị từ chối.	`SUBMITTED`	Người quản lý từ chối, yêu cầu ghi rõ lý do. Đơn hàng được mở khóa để sửa và gửi lại.
`FULFILLED`	Nhà cung cấp đã giao đủ hàng.	`APPROVED`	Bộ phận kho xác nhận đã nhận đủ hàng hóa theo đơn.
`CLOSED`	Đã hoàn tất thanh toán và đóng.	`FULFILLED`	Kế toán xác nhận đã hoàn tất thanh toán cho nhà cung cấp. Trạng thái cuối cùng.

3. Quy tắc nghiệp vụ liên quan (Associated Business Rules)

Các quy tắc này được đăng ký tại CANONICAL_BUSINESS_RULES.

ID Quy tắc	Nội dung quy tắc	Nguồn/Thẩm quyền
`BR-PO-001`	Một đơn mua hàng có `total_value` > 500,000,000 VND phải được phê duyệt bởi Trưởng phòng Mua hàng (role: `purchasing_manager`).	Nova Foods Procurement Policy v2.1
`BR-PO-002`	Không được phép chỉnh sửa hoặc xóa `PurchaseOrderItem` sau khi `PurchaseOrder` cha chuyển sang trạng thái `APPROVED`.	System Integrity Constraint
`BR-PO-003`	Trường `total_value` của `PurchaseOrder` phải bằng tổng của tất cả các trường `line_total` trong các `PurchaseOrderItem` liên quan.	Data Integrity Rule
`BR-PO-004`	Khi một `PurchaseOrder` bị `REJECTED`, người từ chối bắt buộc phải cung cấp lý do trong trường `rejection_reason`.	Process Compliance Rule

4. Ví dụ Payload Dữ liệu (Sample Data Payload)

Ví dụ về một đối tượng PurchaseOrder dưới dạng JSON, thể hiện cấu trúc dữ liệu hoàn chỉnh.

{
  "po_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "supplier_id": "s-f48e-dalat-farm",
  "order_date": "2026-10-20T10:05:12+07:00",
  "created_by_user_id": "u-nv-a-0113-ha.le",
  "status": "SUBMITTED",
  "total_value": 75500000.00,
  "currency": "VND",
  "items": [
    {
      "po_item_id": "i-1111-2222-3333-4444",
      "product_id": "prod-coffee-arabica-g1",
      "quantity": 500.0,
      "unit_price": 125000.00,
      "line_total": 62500000.00
    },
    {
      "po_item_id": "i-5555-6666-7777-8888",
      "product_id": "prod-packaging-bags-5kg",
      "quantity": 1000.0,
      "unit_price": 13000.00,
      "line_total": 13000000.00
    }
  ]
}

Bối cảnh, Phân tích Phương án và Quyết định Mô hình hóa

Hiện trạng: Nova Foods quản lý lô hàng tồn kho (inventory lot) bằng Excel. Dữ liệu phân mảnh, nhập liệu thủ công dễ sai sót. Không thể truy xuất nguồn gốc sản phẩm theo thời gian thực để thu hồi hoặc báo cáo. Việc này tạo rủi ro không tuân thủ Luật An toàn thực phẩm (55/2010/QH12).

Nhu cầu cốt lõi: Cần một thực thể dữ liệu (data entity) trung tâm trong hệ thống ERP để ghi nhận thông tin lô hàng. Dữ liệu phải nhất quán, tin cậy và cho phép truy vết hai chiều (từ nhà cung cấp tới khách hàng và ngược lại) một cách nhanh chóng.

Bảng phân tích các phương án cho định danh lô (Lot Identifier):

Phương án	Mô tả	Ưu điểm	Nhược điểm
A: Chuỗi tự do	Người dùng tự nhập một chuỗi văn bản để định danh lô. Ví dụ: `nhomuhalan_200826`.	Linh hoạt tối đa cho người nhập liệu. Không cần thay đổi quy trình hiện tại nhiều.	Rủi ro trùng lặp mã rất cao. Không có cấu trúc, khó phân tích tự động. Không thể dùng làm khóa chính (`primary key`) tin cậy.
B: Mã ghép	Hệ thống tự động tạo mã lô theo cấu trúc định sẵn. Ví dụ: `[Mã Sản Phẩm]-[YYMMDD]-[Số Thứ Tự]`.	Có cấu trúc, người đọc có thể hiểu được. Dễ dàng nhận diện thông tin cơ bản từ mã.	Cứng nhắc. Khó thay đổi định dạng trong tương lai. Có thể quá dài, ảnh hưởng hiệu năng database khi làm khóa.
C: Khóa thay thế	Hệ thống tạo một định danh duy nhất không mang ngữ nghĩa (`surrogate key`), ví dụ như UUID. Các thông tin khác như ngày sản xuất, mã sản phẩm được lưu ở các trường riêng.	Đảm bảo duy nhất tuyệt đối. Hiệu năng truy vấn và join bảng tốt nhất. Rất linh hoạt để mở rộng mô hình dữ liệu.	Mã định danh không có ý nghĩa với người dùng. Luôn cần truy vấn thêm để xem thông tin chi tiết.

Bảng tiêu chí quyết định:

ID Tiêu chí	Tên Tiêu chí	Mức độ Ưu tiên	Diễn giải
`DC-LOT-01`	Đảm bảo tính duy nhất	Bắt buộc	Định danh lô không được phép trùng lặp trong toàn bộ vòng đời dữ liệu của hệ thống.
`DC-LOT-02`	Hỗ trợ truy vết	Bắt buộc	Phải liên kết được với phiếu nhập kho, lệnh sản xuất, và phiếu xuất kho một cách tường minh.
`DC-LOT-03`	Hiệu năng hệ thống	Cao	Tối ưu hóa tốc độ truy vấn trên bảng lô, đặc biệt cho các báo cáo thu hồi sản phẩm quy mô lớn.
`DC-LOT-04`	Tính linh hoạt	Cao	Mô hình phải dễ dàng mở rộng để thêm thuộc tính mới cho lô hàng mà không cần thay đổi định danh.

Quyết định và Thẩm quyền:

Quyết định được đề xuất: Lựa chọn Phương án C - Dùng Khóa thay thế (Surrogate Key).
Lý do: Phương án C đáp ứng toàn bộ các tiêu chí bắt buộc và ưu tiên cao. Việc sử dụng surrogate key làm khóa chính là một thông lệ tốt nhất (best practice) trong thiết kế CSDL cho ERP, giúp tách biệt định danh kỹ thuật khỏi logic nghiệp vụ. Điều này đảm bảo tính toàn vẹn dữ liệu, hiệu năng cao và khả năng bảo trì hệ thống trong dài hạn.
Thẩm quyền quyết định: Trưởng bộ phận Chuỗi cung ứng (Head of Supply Chain), sau khi tham vấn và nhận đồng thuận từ Kiến trúc sư Giải pháp (Solution Architect).
Hậu quả nếu quyết định sai: Chọn phương án không đảm bảo tính duy nhất và khả năng liên kết (A hoặc B) sẽ dẫn đến việc hệ thống không thể thực hiện truy xuất nguồn gốc đáng tin cậy. Khi xảy ra sự cố an toàn thực phẩm, Nova Foods có nguy cơ đối mặt với chế tài pháp lý, tổn thất tài chính do thu hồi chậm/sai, và khủng hoảng uy tín thương hiệu.

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

Phần này chi tiết hóa bằng chứng, các giả định, và các mục quản trị cho mô hình dữ liệu Lô hàng (Lot) được định nghĩa ở phần trước. Mục đích là đảm bảo tính toàn vẹn, khả năng truy vết, và nhận diện rõ các điểm cần xác minh hoặc leo thang.

Bằng chứng, Ngoại lệ và Luồng tiêu cực

Bảng này ghi lại các kịch bản lỗi và luồng xử lý không mong muốn để đảm bảo hệ thống vững chắc.

ID	Tình huống	Hành vi Hệ thống Mong đợi	Liên kết Traceability
`EX-LOT-001`	Người dùng tạo Lô mới với `ExternalLotCode` đã tồn tại cho cùng một `ProductID` và `SupplierID`.	Hệ thống từ chối lưu. Hiển thị lỗi rõ ràng: "Mã lô nhà cung cấp đã tồn tại cho sản phẩm này."	`BR-LOT-001`, `REQ-TRACE-002`, `AC-LOT-002`
`EX-LOT-002`	Người dùng nhập `ExpiryDate` (ngày hết hạn) có giá trị trước hoặc bằng `ProductionDate` (ngày sản xuất).	Hệ thống từ chối lưu tại giao diện và API. Hiển thị lỗi: "Ngày hết hạn phải sau ngày sản xuất."	`BR-GEN-015`, `AC-LOT-004`
`EX-LOT-003`	Một hệ thống bên ngoài gọi API để tạo Lô nhưng `GoodsReceiptID` (ID phiếu nhập) được cung cấp không tồn tại.	API trả về mã lỗi HTTP `400 Bad Request`. Nội dung lỗi (`error payload`) chỉ rõ trường `GoodsReceiptID` không hợp lệ.	`API-SPEC-005`, `DATA-DEF-018`
`EX-LOT-004`	Người dùng cố gắng xóa một bản ghi Lô đã được liên kết với một Phiếu xuất kho (`Delivery Note`).	Hệ thống ngăn chặn việc xóa. Ràng buộc khóa ngoại (`foreign key constraint`) ở CSDL sẽ thất bại. Giao diện hiển thị thông báo: "Không thể xóa Lô đã xuất kho."	`BR-DATA-004` (Data Integrity), `REQ-AUDIT-005`

Các giả định và Mục cần xác minh

Đây là các giả định được đưa ra trong quá trình phân tích và các mục yêu cầu xác nhận từ các vai trò có thẩm quyền để giảm thiểu rủi ro.

Bảng Giả định (Assumptions)

ID	Giả định	Tác động nếu sai	Hành động giảm thiểu
`ASM-LOT-001`	Cách diễn giải yêu cầu truy vết từ `Luật An toàn thực phẩm (55/2010/QH12)` trong các quy tắc nghiệp vụ là đầy đủ và chính xác.	Mô hình dữ liệu có thể thiếu trường bắt buộc, dẫn đến không tuân thủ pháp lý và phải thiết kế lại.	Tạo mục `VFY-LOT-001` để Legal Owner xác minh chính thức.
`ASM-LOT-002`	Hiệu năng truy vấn cho báo cáo thu hồi sản phẩm quy mô lớn là chấp nhận được với thiết kế index tiêu chuẩn trên khóa thay thế (`surrogate key`).	Thời gian phản ứng sự cố có thể bị chậm do báo cáo chạy quá lâu, gây thiệt hại tài chính và uy tín.	Lên lịch `performance test` trên môi trường UAT với dữ liệu mô phỏng 10 triệu bản ghi Lô trước khi phê duyệt triển khai.

Bảng Cần xác minh (Verification-Required)

ID	Mục cần xác minh	Lý do	Vai trò xác minh
`VFY-LOT-001`	Toàn bộ định nghĩa dữ liệu Lô (định dạng, trường bắt buộc, liên kết) có tuân thủ đầy đủ và cập nhật nhất của `Luật An toàn thực phẩm` không?	BA không có thẩm quyền diễn giải pháp luật. Cần xác nhận từ chuyên gia để đảm bảo tuân thủ, tránh rủi ro pháp lý.	Legal Owner, Head of Quality Control
`VFY-LOT-002`	Thời gian lưu trữ tối thiểu cho dữ liệu lô hàng (kể cả sau khi hết hạn) có đáp ứng yêu cầu của `Luật Kế toán (88/2015/QH13)` không?	Dữ liệu lô hàng là chứng từ gốc cho việc tính giá vốn và kiểm kê tài sản, thuộc phạm vi quản lý của Kế toán.	Chief Accountant

Hồ sơ Leo thang

Các vấn đề vượt quá thẩm quyền của nhóm dự án hoặc cần quyết định chiến lược từ cấp quản lý cao hơn được ghi nhận tại đây.

ID	Vấn đề	Tác động	Vai trò cần quyết định	Trạng thái
`ESC-DATA-001`	Hệ thống quản lý kho cũ (`INV-SYS-002`) dùng khóa tổng hợp (`composite key`) để định danh lô. Quyết định dùng khóa thay thế (`surrogate key`) trong ERP mới tạo ra xung đột kỹ thuật khi đồng bộ dữ liệu.	Tích hợp dữ liệu có thể thất bại, hoặc đòi hỏi logic trung gian phức tạp và tốn kém, làm tăng rủi ro lỗi và chi phí bảo trì.	Solution Architect, Head of IT	`OPEN - Awaiting Decision`

Ma trận Truy vết và Liên kết Bằng chứng

Truy vết (Traceability) là khả năng theo dõi và liên kết các yêu cầu trong suốt vòng đời phát triển sản phẩm, từ khởi tạo đến triển khai và xác minh. Đối với Business Analyst (BA), đây là công cụ cốt lõi để đảm bảo rằng mọi tính năng được xây dựng, mọi dòng code được viết đều phục vụ một nhu cầu nghiệp vụ cụ thể và đã được xác minh. Ma trận Truy vết Yêu cầu (Requirements Traceability Matrix - RTM) là một tài liệu trực quan hóa các mối liên kết này, từ nhu cầu ban đầu (Need) đến yêu cầu (Requirement), quy tắc nghiệp vụ (Business Rule), tiêu chí chấp nhận (Acceptance Criteria), thiết kế kỹ thuật (Data/API), và cuối cùng là kiểm thử (Test Case). Điều này giúp ngăn chặn 'scope creep' (phình phạm vi không kiểm soát), đảm bảo chất lượng và cung cấp bằng chứng cho việc kiểm toán hoặc tuân thủ quy định.

Ma trận dưới đây thể hiện truy vết hai chiều (bidirectional traceability) cho kịch bản quản lý lô hàng của Nova Foods.

ID Tham chiếu	ID Yêu cầu (REQ)	Quy tắc (BR)	Tiêu chí chấp nhận (AC)	Dữ liệu/API (DATA)	Kiểm thử (TC)	Nguồn (Source)
`TRC-MAP-001`	`REQ-TRC-001` - Hệ thống phải ghi nhận và truy xuất được nguồn gốc mọi lô sản phẩm.	`BR-INV-001` - Mã lô (`lot_id`) phải là duy nhất trong toàn hệ thống.	`AC-LOT-001` - Hệ thống phải từ chối tạo mới một lô hàng nếu `lot_id` được cung cấp đã tồn tại.	`DATA-LOT-001` (Thực thể `lô_hàng`) `DATA-FLD-101` (Trường `lot_id`)	`TC-LOT-002` - Xác minh hệ thống báo lỗi khi tạo lô có `lot_id` trùng lặp.	`Luật An toàn thực phẩm (55/2010/QH12)`
`TRC-MAP-002`	`REQ-TRC-001` - Hệ thống phải ghi nhận và truy xuất được nguồn gốc mọi lô sản phẩm.	`BR-INV-003` - Hạn sử dụng của một lô hàng phải lớn hơn ngày sản xuất.	`AC-LOT-003` - Hệ thống phải từ chối lưu thông tin lô hàng nếu `hạn_sử_dụng` nhỏ hơn hoặc bằng `ngày_sản_xuất`.	`DATA-LOT-001` (Thực thể `lô_hàng`) `DATA-FLD-103` (`ngày_sản_xuất`) `DATA-FLD-104` (`hạn_sử_dụng`)	`TC-LOT-004` - Xác minh hệ thống báo lỗi khi nhập `hạn_sử_dụng` không hợp lệ so với `ngày_sản_xuất`.	`Luật An toàn thực phẩm (55/2010/QH12)`

Bảng trên minh họa cách một yêu cầu cấp cao như REQ-TRC-001 (cần truy xuất nguồn gốc) được hiện thực hóa. Dòng TRC-MAP-001 cho thấy yêu cầu này dẫn đến quy tắc nghiệp vụ BR-INV-001 (mã lô phải duy nhất). Để làm cho quy tắc này có thể kiểm chứng được, chúng ta định nghĩa tiêu chí chấp nhận cụ thể AC-LOT-001. Về mặt kỹ thuật, nó được triển khai thông qua trường lot_id trong thực thể dữ liệu lô_hàng. Cuối cùng, đội kiểm thử (QA) sẽ viết trường hợp kiểm thử TC-LOT-002 để xác minh rằng hệ thống thực sự từ chối mã lô trùng lặp. Toàn bộ chuỗi liên kết này bắt nguồn từ một nghĩa vụ pháp lý trong Luật An toàn thực phẩm, đảm bảo rằng yêu cầu kỹ thuật không chỉ là một quyết định tùy ý mà là một đòi hỏi có cơ sở. Việc duy trì ma trận này đảm bảo không có yêu cầu nào bị "bỏ rơi" và mọi tính năng đều có lý do tồn tại rõ ràng, có thể kiểm chứng.

Bằng chứng: Bảng Quyết định, Dữ liệu Kiểm thử và Payload API

Để cung cấp bằng chứng cụ thể và có thể kiểm chứng cho quy tắc nghiệp vụ và tiêu chí chấp nhận đã nêu, chúng ta sử dụng các kỹ thuật trực quan hóa và đặc tả dữ liệu. Các artifact này không chỉ làm rõ logic cho đội ngũ phát triển mà còn là cơ sở để đội kiểm thử (QA) tạo kịch bản kiểm thử.

Đầu tiên, chúng ta dùng một Bảng Quyết định (Decision Table). Đây là một kỹ thuật trong phân tích nghiệp vụ (Business Analysis) giúp trình bày các quy tắc phức tạp một cách có cấu trúc, dựa trên các điều kiện (conditions) và hành động (actions) tương ứng. Bảng này trực tiếp diễn giải Quy tắc Nghiệp vụ BR-PROC-001.

Bảng Quyết định cho BR-PROC-001: Yêu cầu Tối thiểu một Dòng hàng

	Quy tắc 1	Quy tắc 2
Điều kiện (Conditions)
`purchaseOrder.lineItems.length > 0`	Y	N
Hành động (Actions)
Tạo hoặc cập nhật Đơn Mua Hàng thành công	X	-
Trả về lỗi `PO_REQUIRES_LINE_ITEMS`	-	X

Diễn giải: Quy tắc 1 (Rule 1) cho thấy nếu điều kiện "số lượng dòng hàng lớn hơn 0" là đúng (Y - Yes), hệ thống sẽ thực thi hành động "Tạo hoặc cập nhật Đơn Mua Hàng". Ngược lại, Quy tắc 2 (Rule 2) cho thấy nếu điều kiện là sai (N - No), hệ thống sẽ thực thi hành động "Trả về lỗi".

Tiếp theo, chúng ta định nghĩa các trường hợp kiểm thử (test cases) cụ thể để xác minh Tiêu chí Chấp nhận AC-PROC-001-01. Dữ liệu kiểm thử này là cơ sở để đội QA đảm bảo chức năng hoạt động đúng như mong đợi trong cả trường hợp thành công (happy path) và thất bại (negative path).

Dữ liệu Kiểm thử cho AC-PROC-001-01

Test Case ID	Mô tả	Dữ liệu đầu vào (Tóm tắt)	Kết quả mong đợi
`TC-PROC-001-01`	Happy Path: Tạo Đơn Mua Hàng hợp lệ với hai dòng hàng.	Một đối tượng `PurchaseOrder` chứa một mảng `lineItems` có 2 phần tử.	Hệ thống tạo thành công Đơn Mua Hàng và trả về mã `201 Created` cùng với ID của đơn hàng mới.
`TC-PROC-001-02`	Negative Path: Cố gắng tạo Đơn Mua Hàng với một mảng dòng hàng rỗng.	Một đối tượng `PurchaseOrder` chứa một mảng `lineItems` rỗng (`[]`).	Hệ thống từ chối yêu cầu, trả về mã lỗi `400 Bad Request` và một thông báo lỗi chứa mã `PO_REQUIRES_LINE_ITEMS`.

Cuối cùng, để làm rõ cấu trúc dữ liệu DATA-DEF-001 cho các lập trình viên API, chúng ta cung cấp ví dụ về payload. Payload là khối dữ liệu thực tế được gửi đi trong một yêu cầu API. Dưới đây là hai ví dụ JSON, một cho trường hợp hợp lệ (TC-PROC-001-01) và một cho trường hợp không hợp lệ (TC-PROC-001-02).

Ví dụ Payload API (JSON) cho việc tạo Đơn Mua Hàng

Payload hợp lệ (tương ứng TC-PROC-001-01):

{
  "supplierId": "NCC-2026-00123",
  "orderDate": "2026-10-20",
  "currency": "VND",
  "notes": "Yêu cầu giao hàng trước ngày 2026-11-01. Dữ liệu mô phỏng cho Nova Foods.",
  "lineItems": [
    {
      "productId": "SP-TRUNG-001",
      "productName": "Trứng gà tươi VietGAP (Vỉ 10)",
      "quantity": 200,
      "unitPrice": 30000
    },
    {
      "productId": "SP-SUA-005",
      "productName": "Sữa tươi tiệt trùng NovaMilk (Lốc 4x180ml)",
      "quantity": 150,
      "unitPrice": 32000
    }
  ]
}

Payload không hợp lệ (tương ứng TC-PROC-001-02):

{
  "supplierId": "NCC-2026-00124",
  "orderDate": "2026-10-21",
  "currency": "VND",
  "notes": "Dữ liệu mô phỏng không hợp lệ cho Nova Foods.",
  "lineItems": []
}

5. Tier 4 – Cổng Chất lượng của BA Cấp cao (Senior BA Quality Gate)

Mục này định nghĩa Cổng Chất lượng (Quality Gate), một chốt chặn kiểm tra chính thức do BA cấp cao (Senior BA) thực hiện. Mục đích là để xác minh chất lượng và sự hoàn chỉnh của mô hình dữ liệu trước khi nó được công nhận là baseline (phiên bản nền tảng, chính thức để các bên khác dựa vào). Việc này ngăn chặn các lỗi nghiêm trọng lan truyền đến các giai đoạn sau như thiết kế kỹ thuật, kiểm thử và triển khai.

Bảng dưới đây là danh sách kiểm tra (checklist) tiêu chuẩn. Mỗi hạng mục phải được đánh giá là PASS (Đạt). Một kết quả FAIL (Không đạt) đòi hỏi phải sửa chữa. Một kết quả STOP (Dừng) chỉ ra một lỗi nghiêm trọng, yêu cầu dừng mọi công việc liên quan đến tài liệu này để xử lý và leo thang (escalation) – tức báo cáo lên vai trò có thẩm quyền để giải quyết.

Bảng 5.1: Danh sách kiểm tra chất lượng mô hình dữ liệu

Hạng mục kiểm tra	Tiêu chí đánh giá để đạt (`PASS`)	Hành động khi `FAIL` / `STOP`
Tính Toàn vẹn (Completeness)	Tất cả các mục trong template Tier 2 đã được điền đầy đủ. Không có ghi chú `TBD`, `TODO` hoặc placeholder. Mọi thực thể dữ liệu cần thiết cho quy trình nghiệp vụ (ví dụ: `PurchaseOrder`) đều có mặt.	FAIL: Bổ sung thông tin còn thiếu. STOP: Dừng lại nếu thiếu một thực thể dữ liệu lõi (ví dụ: Đơn Mua Hàng không có thông tin Nhà Cung Cấp).
Tính Nhất quán (Consistency)	Thuật ngữ và định danh (ID) tuân thủ `CANONICAL_DATA_DICTIONARY` và `GLOSSARY`. Kiểu dữ liệu (`Data Type`) của một trường nhất quán ở mọi nơi nó xuất hiện. Định dạng ID theo đúng quy ước (ví dụ: `supplierId` luôn là `NCC-YYYY-NNNNN`).	FAIL: Chỉnh sửa thuật ngữ, định dạng hoặc kiểu dữ liệu cho khớp với nguồn chuẩn.
Khả năng Kiểm thử (Testability)	Mỗi quy tắc (rule) hoặc ràng buộc (constraint) phải cụ thể để có thể viết được một ca kiểm thử (test case) với kết quả rõ ràng. Ví dụ: "Số lượng phải lớn hơn 0" là có thể kiểm thử; "Số lượng phải hợp lý" thì không.	FAIL: Viết lại các quy tắc mơ hồ. STOP: Dừng lại nếu một quy tắc nghiệp vụ quan trọng không thể kiểm thử được.
Khả năng Truy vết (Traceability)	Mỗi trường dữ liệu, quy tắc, và ví dụ phải có liên kết truy vết rõ ràng về nguồn gốc của nó (ví dụ: `DATA-DEF-001` truy vết đến yêu cầu `BIZ-REQ-XXX`). Mọi định danh mới phải được đăng ký trong `TRACEABILITY_ID_REGISTRY`.	FAIL: Bổ sung các liên kết truy vết còn thiếu. STOP: Dừng lại nếu một yêu cầu có tác động lớn (pháp lý, tài chính) không có nguồn gốc rõ ràng.
Thẩm quyền Nguồn (Source Authority)	Nguồn được trích dẫn phải có thẩm quyền phù hợp. Yêu cầu pháp lý phải trích dẫn văn bản luật (`Luật`, `Nghị định`), không phải một bài blog. Quy tắc nghiệp vụ phải đến từ quyết định của Business Owner, không phải giả định của nhóm dự án.	FAIL: Tìm và trích dẫn nguồn có thẩm quyền đúng. STOP & LEO THANG: Dừng và leo thang ngay lập tức cho chủ sở hữu nghiệp vụ/pháp lý nếu một yêu cầu dựa trên nguồn không hợp lệ.
Quyền Sở hữu (Ownership)	Mỗi thực thể dữ liệu chính (ví dụ: `Customer`, `Product`) phải có một Chủ sở hữu nghiệp vụ (Business Owner) được xác định rõ ràng. Mỗi ràng buộc pháp lý, tài chính, bảo mật phải có một vai trò sở hữu (Owner role) được chỉ định.	FAIL: Xác định và ghi lại Owner. LEO THANG: Leo thang cho Quản lý Dự án (Project Manager) nếu quyền sở hữu không rõ ràng hoặc có tranh chấp.
Ranh giới Bảo mật, Pháp lý, Kế toán (Security, Privacy, Legal, Accounting Boundaries)	Dữ liệu nhạy cảm, đặc biệt là Thông tin nhận dạng cá nhân (PII - Personally Identifiable Information), phải được đánh dấu. Mọi trường dữ liệu phát sinh từ quy tắc pháp lý hoặc kế toán phải được gắn nhãn `Verification Required` (Yêu cầu xác minh) tới đúng vai trò (Legal, Accounting).	FAIL: Bổ sung phân loại và nhãn cho dữ liệu. STOP & LEO THANG: Dừng và leo thang ngay cho vai trò Security/Legal nếu PII không được nhận diện, hoặc một quy tắc pháp lý/kế toán được trình bày như một sự thật đã được xác nhận mà không có nhãn yêu cầu xác minh.
Tác động Thay đổi (Change Impact)	Tài liệu phải xác định được các hệ thống, quy trình, hoặc phòng ban khác bị ảnh hưởng bởi mô hình dữ liệu này. Ví dụ, thay đổi cấu trúc `PurchaseOrder` sẽ ảnh hưởng đến `API Nhà Cung Cấp`, `Hệ thống Kho`, và `Quy trình Kế toán Phải trả`.	FAIL: Phân tích và ghi lại các phụ thuộc và tác động. LEO THANG: Leo thang cho Kiến trúc sư (Architect) hoặc Quản lý Dự án nếu tác động lớn và chưa được đánh giá đầy đủ.

Tiêu chí Đánh giá Chất lượng của Senior BA

Bảng dưới đây định nghĩa các tiêu chí chất lượng cốt lõi mà một Senior Business Analyst (BA) sử dụng để xem xét và đánh giá mô hình dữ liệu trước khi đề xuất baseline. Mỗi tiêu chí được diễn giải rõ ràng, kèm theo ví dụ áp dụng cụ thể cho case study mô phỏng của Nova Foods. Đây là một cổng kiểm soát chất lượng nội bộ, không phải là một phê duyệt chính thức từ phía nghiệp vụ hay pháp lý.

Hạng mục Chất lượng	Tiêu chí đánh giá chính	Diễn giải và ví dụ (Case study Nova Foods)	Nguồn tham chiếu / Công cụ
1. Tính đầy đủ (Completeness)	Mọi thuộc tính dữ liệu bắt buộc trong Tier 2 template đã được điền đầy đủ và có chủ đích trong ví dụ Tier 3 chưa? Có tồn tại giá trị `null` hoặc trống ở những nơi không được phép không?	Ví dụ: Trong thực thể `SalesOrderLine`, thuộc tính `product_id`, `quantity`, và `unit_price` phải luôn có giá trị. Nếu một dòng hàng mẫu của Nova Foods thiếu `product_id`, mô hình không đạt tiêu chí đầy đủ. Việc này đảm bảo tính toàn vẹn dữ liệu cơ bản.	So sánh trực tiếp giữa `Tier 2 - Blank Copy-Paste-Ready Template` và `Tier 3 - Fully Completed Nova Foods Case`.
2. Tính nhất quán (Consistency)	Thuật ngữ, định dạng dữ liệu, và quy tắc nghiệp vụ có được áp dụng đồng nhất trong toàn bộ mô hình và có khớp với các tài liệu chuẩn của dự án không?	Ví dụ: Thuật ngữ `Đơn vị tính` phải nhất quán sử dụng `unit_of_measure` làm định danh kỹ thuật. Nếu mô hình này dùng `uom` trong khi `/01-curriculum/CANONICAL_DATA_DICTIONARY.md` định nghĩa là `unit_of_measure`, nó đã vi phạm tính nhất quán. Tương tự, định dạng ngày tháng phải tuân thủ `YYYY-MM-DD` trên mọi thực thể.	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`, `/01-curriculum/CANONICAL_BUSINESS_RULES.md`
3. Tính kiểm thử được (Testability)	Mỗi quy tắc ràng buộc (constraint) hoặc quy tắc nghiệp vụ (business rule) liên quan đến dữ liệu có được mô tả một cách rõ ràng, đơn nghĩa, và có thể kiểm chứng được bằng một kịch bản pass/fail cụ thể không?	Ví dụ: Một quy tắc "Giá trị đơn hàng hợp lệ" là không thể kiểm thử. Một quy tắc "Tổng giá trị `order_total` phải bằng tổng của (`quantity` * `unit_price`) trên tất cả các `SalesOrderLine` liên quan" là có thể kiểm thử. Quy tắc phải tránh các từ ngữ chủ quan như "hợp lý", "phù hợp", "tốt".	ISTQB CTFL Syllabus v4.0.1 (định nghĩa về testability)
4. Khả năng truy vết (Traceability)	Mỗi thực thể và thuộc tính dữ liệu có liên kết rõ ràng đến một yêu cầu nghiệp vụ, quy tắc, hoặc nguồn gốc pháp lý cụ thể không? Có thuộc tính nào "mồ côi" (orphan) không rõ lý do tồn tại không?	Ví dụ: Thuộc tính `batch_code` trên thực thể `InventoryLot` phải có một `traceability_id` tham chiếu đến yêu cầu truy xuất nguồn gốc thực phẩm (ví dụ: `REQ-NF-FS-001`), vốn bắt nguồn từ Luật An toàn thực phẩm (`Luật 55/2010/QH12`).	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`
5. Thẩm quyền nguồn (Source Authority) & Quyền sở hữu (Ownership)	Nguồn gốc và chủ sở hữu (owner) của từng nhóm dữ liệu có được xác định rõ ràng và hợp lý không? Dữ liệu pháp lý/kế toán có đến từ vai trò có thẩm quyền tương ứng không?	Ví dụ: Thuộc tính `vat_rate` (thuế suất GTGT) phải có Owner là "Accounting Owner" và nguồn tham chiếu là "Nghị định 123/2020/NĐ-CP" hoặc văn bản thuế liên quan, chứ không phải do BA hay Developer tự định nghĩa.	Nhãn "Ownership" và "Source" trong mô hình dữ liệu, đối chiếu với `/00-research/00_SOURCE_MAP.md`.
6. Ranh giới Bảo mật, Pháp lý, Kế toán	Các thuộc tính chứa dữ liệu nhạy cảm (PII), dữ liệu tài chính, hoặc dữ liệu cần tuân thủ quy định đặc biệt đã được đánh dấu và phân loại đúng cách chưa?	Ví dụ: Bất kỳ thuộc tính nào chứa thông tin cá nhân của khách hàng (ví dụ: `customer_phone`, `customer_address`) phải được đánh dấu phân loại là `PII` (Personally Identifiable Information) và có ghi chú tham chiếu đến `Luật 91/2025/QH15` (Luật Bảo vệ dữ liệu cá nhân). Tương tự, dữ liệu hóa đơn phải tuân thủ `Luật Kế toán 88/2015/QH13`.	OWASP API Security Top 10 (ví dụ: `API3:2023 - Broken Object Property Level Authorization`), các văn bản luật liên quan (`Luật 91/2025/QH15`, `Luật 88/2015/QH13`).
7. Tác động thay đổi (Change Impact)	Việc thay đổi một thuộc tính (ví dụ: kiểu dữ liệu, độ dài, quy tắc ràng buộc) có được phân tích về tác động lên các hệ thống, quy trình, hoặc dữ liệu hiện có không?	Ví dụ: Nếu đề xuất thay đổi kiểu dữ liệu của `product_sku` từ `VARCHAR(50)` sang `INT`, phần đánh giá phải trả lời được các câu hỏi: Điều này ảnh hưởng gì đến các tích hợp API với nhà cung cấp? Dữ liệu SKU cũ sẽ được di chuyển (migrate) như thế nào? Giao diện người dùng có bị ảnh hưởng không?	Phân tích phụ thuộc (Dependency analysis) và kỹ thuật phân tích tác động (Impact analysis) được mô tả trong BABOK Guide.

Áp dụng Checklist vào Case Study Nova Foods (Chưa có phê duyệt)

Bảng dưới đây ghi lại kết quả áp dụng checklist chất lượng cho ví dụ Nova Foods đã hoàn thiện trong Tier 3. Các ghi nhận này dùng để cải thiện tài liệu trước khi baseline, không cấu thành phê duyệt.

Mã hạng mục	Hạng mục kiểm tra	Kết quả	Ghi nhận & Bằng chứng	Hành động đề xuất
`QG-DATA-01`	Tính hoàn chỉnh (Completeness)	`PASS`	Mọi trường dữ liệu trong các bảng ví dụ của Tier 3 (ví dụ `Supplier Master Data`) đều được điền giá trị cụ thể. Không có placeholder như `<chưa xác định>` hay `TBD`.	Không cần hành động.
`QG-DATA-02`	Tính nhất quán (Consistency)	`NEEDS_CLARIFICATION`	Trường `DateCreated` có múi giờ `UTC`, nhưng `LastModifiedDate` lại không có thông tin múi giờ. Có rủi ro khi so sánh hoặc sắp xếp các bản ghi trên các hệ thống khác nhau.	Thống nhất tất cả các trường kiểu `datetime` phải theo chuẩn ISO 8601 với thông tin múi giờ đầy đủ (ví dụ: `2026-08-07T10:00:00Z`). Cập nhật `LastModifiedDate`.
`QG-DATA-03`	Tính khả kiểm (Testability)	`PASS`	Các quy tắc nghiệp vụ liên quan đến mô hình dữ liệu (ví dụ `BR-INV-001: Mã nhà cung cấp phải bắt đầu bằng 'NVFSUP-'`) được định nghĩa rõ ràng. Dựa vào đây có thể viết được các ca kiểm thử (test case) cụ thể.	Không cần hành động. Chuyển cho đội QA để làm cơ sở viết test case.
`QG-DATA-04`	Khả năng truy vết (Traceability)	`PASS`	Mỗi trường dữ liệu có tham chiếu rõ ràng đến định danh trong `Canonical Data Dictionary` (ví dụ `CDD-SUP-005` cho `SupplierName`). Các quy tắc nghiệp vụ cũng có ID riêng, liên kết tới `CANONICAL_BUSINESS_RULES`.	Không cần hành động. Duy trì tính toàn vẹn của các ID này.
`QG-DATA-05`	Nguồn xác thực & chủ sở hữu (Source Authority & Ownership)	`NEEDS_CLARIFICATION`	Đã xác định Chủ sở hữu dữ liệu (Data Owner) là "Phòng Mua hàng". Tuy nhiên, chưa xác định rõ vai trò cụ thể nào trong phòng ban đó có thẩm quyền phê duyệt thay đổi dữ liệu hoặc định nghĩa quy tắc mới.	Làm rõ vai trò chịu trách nhiệm cuối cùng (ví dụ: "Trưởng phòng Mua hàng") cho việc phê duyệt thay đổi dữ liệu gốc của nhà cung cấp.
`QG-DATA-06`	Bảo mật, riêng tư, pháp lý (Security, Privacy, Legal)	`NEEDS_VERIFICATION`	Trường `BankAccountNumber` và `TaxCode` được xác định là dữ liệu nhạy cảm. Mô hình chưa nêu rõ yêu cầu che giấu (masking) hoặc mã hóa khi lưu trữ và hiển thị. Cần đối chiếu với `Luật Bảo vệ dữ liệu cá nhân` (91/2025/QH15) và `Nghị định 356/2025/NĐ-CP`.	Gắn nhãn `Verification Required: Legal, Security`. Chuyển cho Chủ sở hữu pháp lý và Chủ sở hữu bảo mật để xác nhận yêu cầu tuân thủ.
`QG-DATA-07`	Tác động thay đổi (Change Impact)	`NEEDS_CLARIFICATION`	Phân tích tác động còn sơ sài. Ví dụ: Việc thay đổi trạng thái nhà cung cấp `SupplierStatus` từ `ACTIVE` thành `INACTIVE` sẽ ảnh hưởng thế nào đến các đơn đặt hàng (Purchase Order) đang mở hoặc các khoản phải trả chưa thanh toán? Mô hình chưa làm rõ luồng xử lý cho các trường hợp này.	Bổ sung một mục phân tích tác động thay đổi cho các trường dữ liệu quan trọng, mô tả rõ các hệ thống hoặc quy trình bị ảnh hưởng.

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

6.1. Bảng kiểm tra đối chiếu chéo (Cross-File Consistency Check)

Đây là bước kiểm soát chất lượng bắt buộc trước khi chuyển giao một artifact. Mục đích là để đảm bảo artifact hiện tại, TMPL-DATA-002-data-model.md, không mâu thuẫn với các nguồn chân lý (sources of truth) hoặc các tài liệu quản trị khác đã được thiết lập trong corpus của dự án Nova Foods. Mọi mâu thuẫn được phát hiện phải được ghi lại, nêu rõ Owner có thẩm quyền, tác động và hành động xử lý.

Bảng dưới đây ghi lại kết quả kiểm tra tính nhất quán của artifact này (phiên bản v0.9.0, trạng thái IN_REVIEW) tại ngày 2026-08-07.

Artifact tham chiếu (Reference Artifact)	Nội dung kiểm tra (Check Point)	Kết quả (Result)	Ghi chú / Hành động cần thực hiện (Notes / Required Action)
`/01-curriculum/TEMPLATE_MANIFEST.md`	Tính nhất quán Metadata. Metadata của artifact này (ID, phiên bản, trạng thái, owner) có khớp với bản ghi trong manifest template không.	`PASS`	Metadata (`ID: TMPL-DATA-002`, `Version: v0.9.0`, `Status: IN_REVIEW`) khớp hoàn toàn với bản ghi trong manifest.
`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Tuân thủ định danh. Các định danh dữ liệu (ví dụ: `DATA-SUP-001`) và định danh quy tắc (`BR-SUP-xxx`) có tuân thủ quy tắc đặt tên và không xung đột với registry không.	`PASS`	Tất cả các định danh được sử dụng trong mô hình dữ liệu này đều tuân thủ mẫu `DATA-{domain}-{nnn}` và `BR-{domain}-{nnn}` đã được quy hoạch trong `TRACEABILITY_ID_REGISTRY`.
`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Tính nhất quán định nghĩa dữ liệu. Định nghĩa các trường dữ liệu (kiểu dữ liệu, độ dài, ràng buộc, danh sách giá trị cho phép) trong mô hình này có mâu thuẫn với Từ điển Dữ liệu Canonical không.	`ACTION_REQUIRED`	Phát hiện mâu thuẫn: Trường `DATA-SUP-004` (`SupplierStatus`) trong mô hình này chỉ có các giá trị `('ACTIVE', 'INACTIVE')`. Trong khi đó, Từ điển Dữ liệu Canonical yêu cầu phải có thêm giá trị `'PENDING_VERIFICATION'` để xử lý các nhà cung cấp đang trong quá trình thẩm định. Hành động: Người soạn thảo cập nhật trường `SupplierStatus` trong mô hình dữ liệu này để bao gồm giá trị `'PENDING_VERIFICATION'`, sau đó đối chiếu lại với Canonical Data Dictionary. Không cập nhật sẽ làm mô hình không biểu diễn được trạng thái thẩm định và tạo sai lệch cho quy trình mua hàng xuôi dòng.
`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Tính hợp lệ của tham chiếu quy tắc. Các tham chiếu đến quy tắc nghiệp vụ (Business Rule) có trỏ đúng đến catalog canonical và sử dụng đúng định danh không.	`PASS`	Các liên kết đến quy tắc nghiệp vụ như `BR-SUP-001` và `BR-SUP-002` là hợp lệ và khớp với kế hoạch trong catalog quy tắc.
`/00-research/00_SOURCE_MAP.md`	Liên kết nguồn xác minh. Các trường dữ liệu nhạy cảm (PII, tài chính) có được đánh dấu cần xác minh theo nguồn pháp lý (`Luật 91/2025/QH15`, `Nghị định 123/2020/NĐ-CP`, v.v.) được liệt kê trong bản đồ nguồn không.	`NEEDS_VERIFICATION`	Các trường `BankAccountNumber` (`DATA-SUP-010`) và `TaxCode` (`DATA-SUP-009`) đã được xác định là dữ liệu nhạy cảm, nhưng yêu cầu cụ thể về che giấu (masking), mã hóa khi lưu trữ và hiển thị chưa được xác nhận bởi Chủ sở hữu Pháp lý và Bảo mật. Trạng thái này được kế thừa từ quality gate `QG-DATA-06`. Không suy diễn biện pháp bảo vệ khi chưa có xác nhận của Owner có thẩm quyền.
Downstream Consumers (ví dụ: Purchase Order, Accounts Payable)	Phân tích tác động. Tác động của các trường dữ liệu và trạng thái trong mô hình Nhà cung cấp lên các quy trình/module xuôi dòng đã được phân tích chưa.	`INCOMPLETE`	Phân tích tác động thay đổi chưa hoàn tất (tham chiếu `QG-DATA-07`). Ví dụ, chưa làm rõ quy trình xử lý khi `SupplierStatus` chuyển thành `INACTIVE` đối với các đơn hàng đang mở. Hành động: Business Analyst thực hiện phân tích với Owner của Purchase Order và Accounts Payable khi các mô hình dữ liệu module liên quan, ví dụ `TMPL-DATA-005-purchase-order`, được định nghĩa. Không làm rõ sẽ tạo rủi ro đơn hàng mở tiếp tục xử lý với nhà cung cấp không hoạt động.

Danh sách các vấn đề mở, giả định và hạng mục cần xác minh

Bảng này ghi nhận các điểm cần làm rõ trước khi baseline mô hình dữ liệu. Mục đích là kiểm soát rủi ro do suy diễn yêu cầu và chuyển giao trách nhiệm xác minh cho đúng vai trò có thẩm quyền. Mỗi hạng mục phải được giải quyết, có kết quả và bằng chứng ghi nhận trước khi TMPL-DATA-002 có thể chuyển sang trạng thái BASELINED.

ID Vấn đề	Hạng mục	Loại	ID bị ảnh hưởng	Owner xác minh	Mức độ ảnh hưởng	Hành động tiếp theo
`ISSUE-TMPL-002-01`	Mức thuế suất GTGT (VAT) cho sản phẩm Nova Foods chưa được xác định.	Cần xác minh	`DATA-NVF-115` (order.vat_rate), `RULE-NVF-TAX-01` (Quy tắc tính thuế GTGT)	Accounting Owner	Cao. Sai sót ảnh hưởng đến toàn bộ báo cáo tài chính, hóa đơn điện tử và tuân thủ thuế.	BA yêu cầu Accounting Owner cung cấp văn bản xác nhận mức thuế GTGT áp dụng cho các nhóm sản phẩm chính, tham chiếu `Luật Kế toán` và các nghị định liên quan.
`ISSUE-TMPL-002-02`	Phân loại các trường dữ liệu là Thông tin định danh cá nhân (PII - Personally Identifiable Information).	Cần xác minh	`DATA-NVF-011` (customer.full_name), `DATA-NVF-012` (customer.phone_number), `DATA-NVF-013` (customer.email), `DATA-NVF-035` (delivery_address.full_address)	Legal Owner	Cao. Phân loại sai dẫn đến vi phạm `Luật Bảo vệ dữ liệu cá nhân`, có thể gây rủi ro pháp lý và ảnh hưởng đến thiết kế bảo mật hệ thống.	BA lập danh sách các trường dữ liệu nghi ngờ là PII và gửi cho Legal Owner để xác nhận phân loại chính thức.
`ISSUE-TMPL-002-03`	Giả định hệ thống sẽ tích hợp với nhà cung cấp hóa đơn điện tử V-Invoice.	Giả định dự án	`DATA-NVF-118` (invoice.provider_signature), `IF-NVF-003` (Giao diện tích hợp hóa đơn)	Technical Architect, Business Owner	Trung bình. Giả định sai có thể yêu cầu làm lại (rework) phần tích hợp, gây trễ tiến độ và tăng chi phí nếu nhà cung cấp khác có API không tương thích.	BA yêu cầu Technical Architect đánh giá tính khả thi kỹ thuật và Business Owner xác nhận lựa chọn nhà cung cấp phù hợp với ngân sách và quy trình vận hành.
`ISSUE-TMPL-002-04`	Yêu cầu về định dạng của mã truy xuất nguồn gốc lô sản phẩm chưa rõ ràng.	Cần xác minh	`DATA-NVF-202` (product_lot.traceability_id)	Domain Owner (Production), Legal Owner	Cao. Định dạng mã không tuân thủ có thể vi phạm `Luật An toàn thực phẩm` và gây khó khăn khi cần thu hồi sản phẩm.	BA tổ chức buổi làm việc với Domain Owner và Legal Owner để định nghĩa cấu trúc và quy tắc tạo mã truy xuất nguồn gốc, đảm bảo đáp ứng yêu cầu pháp lý và vận hành.
`ISSUE-TMPL-002-05`	Thời gian lưu trữ dữ liệu đơn hàng của khách hàng chưa được quyết định.	Cần xác minh	`DATA-NVF-101` (order), `DATA-NVF-110` (invoice)	Legal Owner, Accounting Owner	Trung bình. Lưu trữ quá ngắn có thể vi phạm quy định kế toán; lưu trữ quá dài có thể vi phạm luật bảo vệ dữ liệu cá nhân và tốn chi phí hạ tầng.	BA yêu cầu Legal Owner và Accounting Owner cung cấp chính sách lưu trữ dữ liệu tối thiểu và tối đa cho các chứng từ kế toán và dữ liệu khách hàng.

Tài liệu giữ trạng thái IN_REVIEW cho đến khi tất cả hạng mục trong bảng trên được đóng với bằng chứng xác nhận từ Owner tương ứng. Business Analyst theo dõi, ghi nhận trạng thái và lan truyền thay đổi; không tự quyết định nội dung chuyên môn thuộc thẩm quyền Owner khác.

Quy tắc Bàn giao, Quản lý Thay đổi và Phân định Thẩm quyền

Mục này xác định quy trình bàn giao có kiểm soát cho mô hình dữ liệu này khi nó ở trạng thái IN_REVIEW. "Bàn giao" (Handoff) là hành động chuyển giao artifact đã hoàn thiện cho người chịu trách nhiệm tiếp theo để xem xét. Nó không phải phê duyệt. "Lan truyền thay đổi" (Change Propagation) đảm bảo thay đổi trong tài liệu này được cập nhật nhất quán đến tài liệu phụ thuộc. Các quy tắc này bảo toàn ranh giới thẩm quyền, ngăn người soạn thảo đưa ra quyết định ngoài vai trò.

Bảng 6.4: Danh mục kiểm tra điều kiện bàn giao

Trước khi bàn giao tài liệu này để review, người soạn thảo phải xác nhận tất cả các mục dưới đây đã hoàn tất. Việc bàn giao chỉ được thực hiện khi tất cả các mục đều ở trạng thái Đã hoàn thành. Điều kiện này ngăn artifact chứa dữ liệu chưa xác định hoặc thiếu trách nhiệm xử lý được chuyển sang bước review.

Mã kiểm tra	Nội dung kiểm tra	Trạng thái yêu cầu	Ghi chú & Người thực hiện
HNDF-CHK-01	Tất cả các mục trong Tier 3 (Mục 3 và 4) đã được điền đầy đủ bằng dữ liệu mô phỏng của Nova Foods.	Đã hoàn thành	Không để trống trường hoặc dùng giá trị giữ chỗ. Nếu một trường không áp dụng, người soạn thảo ghi rõ lý do, phạm vi không áp dụng và liên kết đến hạng mục Open Issues tương ứng. (Người soạn thảo)
HNDF-CHK-02	Mục 5 (Senior BA Quality Gate) đã được người soạn thảo tự kiểm tra và ghi nhận kết quả.	Đã hoàn thành	Đây là bước tự rà soát chất lượng của người soạn thảo trước khi chuyển cho người khác. (Người soạn thảo)
HNDF-CHK-03	Mục 6.1 (Kiểm tra chéo) đã được thực hiện và mọi mâu thuẫn đã được ghi nhận.	Đã hoàn thành	Mọi mâu thuẫn với các artifact canonical phải được ghi vào Bảng 6.2 (Open Issues), kèm Owner, tác động và hành động xử lý. (Người soạn thảo)
HNDF-CHK-04	Mục 6.2 (Vấn đề mở) đã liệt kê đầy đủ tất cả các giả định, điểm cần xác minh, và các mâu thuẫn đã phát hiện.	Đã hoàn thành	Mỗi vấn đề phải có ID, người chịu trách nhiệm (owner) được đề xuất, mức độ ảnh hưởng và hành động tiếp theo. (Người soạn thảo)

Bảng 6.5: Ma trận lan truyền thay đổi

Bất kỳ thay đổi nào đối với các thành phần dữ liệu hoặc quy tắc trong tài liệu này đều phải được lan truyền đến các artifact canonical tương ứng. Người soạn thảo chịu trách nhiệm khởi tạo yêu cầu thay đổi, không tự ý cập nhật các artifact đó.

Nguồn thay đổi trong `TMPL-DATA-002`	Artifact bị ảnh hưởng (Nguồn chân lý)	Hành động lan truyền bắt buộc	Vai trò thực hiện
Định nghĩa một trường dữ liệu logic mới hoặc đã sửa đổi (ví dụ: `FIELD-CUST-001`).	`/01-curriculum/CANONICAL_DATA_DICTIONARY.md`	Gửi yêu cầu cập nhật đến Owner của Từ điển Dữ liệu Canonical, đính kèm lý do, định nghĩa đề xuất và tác động đến consumer.	Người soạn thảo
Một quy tắc nghiệp vụ mới hoặc đã sửa đổi (ví dụ: `BR-INV-005`).	`/01-curriculum/CANONICAL_BUSINESS_RULES.md`	Gửi yêu cầu cập nhật đến Owner của Danh mục Quy tắc Nghiệp vụ Canonical, nêu rõ nguồn gốc, logic quy tắc và hậu quả nếu không áp dụng.	Người soạn thảo
Sử dụng một định danh traceability mới (ví dụ: `REQ-PUR-015`).	`/01-curriculum/TRACEABILITY_ID_REGISTRY.md`	Gửi yêu cầu đăng ký định danh mới đến Owner của Sổ đăng ký ID, đảm bảo ID tuân thủ quy tắc đặt tên.	Người soạn thảo
Một thay đổi có thể ảnh hưởng đến cấu trúc hoặc nội dung của các template hoặc chapter khác.	`/01-curriculum/TEMPLATE_MANIFEST.md` `/01-curriculum/CHAPTER_MANIFEST.md`	Thông báo cho `Principal IT Business Analyst / Technical Curriculum Author` về phụ thuộc tiềm ẩn để đánh giá tác động, quyết định cập nhật và ghi nhận kết quả.	Người soạn thảo

Bảng 6.6: Phân định ranh giới thẩm quyền

Người soạn thảo template này có vai trò đề xuất và tài liệu hóa, không có thẩm quyền phê duyệt. Bảng này làm rõ ranh giới đó.

Hành động	Người soạn thảo có được phép thực hiện?	Thẩm quyền & Quy trình đúng
Phê duyệt (approve) một quy tắc nghiệp vụ cho Nova Foods.	Không	Quy tắc nghiệp vụ phải được `Business Owner` (Chủ sở hữu nghiệp vụ) phê duyệt. Người soạn thảo chỉ ghi lại quy tắc và bằng chứng phê duyệt.
Phê duyệt một định nghĩa dữ liệu canonical.	Không	Định nghĩa dữ liệu phải được `Data Architect` hoặc `Data Governance Owner` phê duyệt. Đề xuất được ghi trong template này để review.
Thay đổi trạng thái tài liệu từ `IN_REVIEW` sang `APPROVED` hoặc `BASELINED`.	Không	Chỉ người có thẩm quyền, ví dụ `Project Manager` hoặc `Curriculum Owner`, mới có thể thay đổi trạng thái sau quy trình review và phê duyệt chính thức có bằng chứng ghi nhận.
Quyết định kiến trúc kỹ thuật hoặc lựa chọn công nghệ.	Không	Thuộc thẩm quyền của `Technical Architect` hoặc `Solution Architect`. Mô hình dữ liệu này là logic, không phải vật lý hay kỹ thuật.

Việc hoàn thành và bàn giao tài liệu này chỉ xác nhận người soạn thảo đã hoàn thành phần việc theo mẫu và đã ghi nhận các điểm cần xác minh. Tài liệu vẫn ở trạng thái IN_REVIEW cho đến khi có phê duyệt chính thức được ghi nhận trong metadata quản trị ở Mục 1.