Mẫu TMPL-DATA-001 — Từ điển Dữ liệu (Data Dictionary)

Bảng dưới định nghĩa các thuộc tính quản trị cốt lõi cho mẫu này. Duy trì các giá trị này để bảo đảm tính nhất quán và khả năng truy vết trong toàn bộ corpus. Mẫu này là một artifact được kiểm soát. Bất kỳ thay đổi nào đối với cấu trúc (Tier 2) hoặc tiêu chí chất lượng (Tier 4) phải tuân theo quy trình kiểm soát thay đổi và được ghi lại trong lịch sử phiên bản.

Trường kiểm soát	Giá trị / Diễn giải
Artifact ID	TMPL-DATA-001
Tên tệp được kiểm soát	/03-templates/TMPL-DATA-001-data-dictionary.md
Tiêu đề	Mẫu TMPL-DATA-001 — Từ điển Dữ liệu (Data Dictionary Template)
Trạng thái (Status)	IN_REVIEW
Phiên bản (Version)	v0.9.0
Owner	Tác giả Curriculum / BA Trưởng (Principal IT Business Analyst / Technical Curriculum Author)
Trách nhiệm của Owner	Chịu trách nhiệm duy trì cấu trúc, metadata, phiên bản, và tính toàn vẹn của mẫu này. Owner đảm bảo mẫu phù hợp với kiến trúc curriculum và các manifest liên quan.
Giới hạn thẩm quyền Owner	Owner không có quyền phê duyệt nội dung dữ liệu được điền vào mẫu, không xác nhận tính đúng đắn pháp lý, kế toán, hoặc vận hành của dữ liệu Nova Foods, và không cấp phép sử dụng production. Thẩm quyền chỉ giới hạn ở cấu trúc của mẫu.
Ngày cập nhật gần nhất	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale áp dụng	vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND
Case study tham chiếu	Nova Foods Trading & Manufacturing — case study mô phỏng giáo dục.
Phân loại artifact	Artifact mẫu được kiểm soát (Controlled Template Artifact)
Lịch sử thay đổi	Khởi tạo tại v0.9.0 ngày 2026-08-07. Thiết lập metadata quản trị và cấu trúc 4 tầng (Tier 1-4).
Giới hạn dữ liệu và sử dụng	Dữ liệu tổng hợp: Mọi dữ liệu điền vào ví dụ ở Tier 3 cho case study Nova Foods phải là dữ liệu tổng hợp (synthetic data), không có thật. Nghiêm cấm: Cấm tuyệt đối việc sử dụng dữ liệu sản xuất (production data), dữ liệu định danh cá nhân (PII), dữ liệu tài chính, hoặc bất kỳ thông tin nhạy cảm nào của cá nhân/tổ chức có thật trong mọi bản sao của tài liệu này.

1. Tier 1 ? Metadata, Purpose, and Governance

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

Mục đích của template này là tạo một Từ điển Dữ liệu (Data Dictionary). Đây là một tài liệu kỹ thuật trung tâm, có kiểm soát, dùng để định nghĩa từng yếu tố dữ liệu (data element) trong phạm vi một hệ thống hoặc một dự án. Mỗi định nghĩa bao gồm tên, kiểu dữ liệu, định dạng, ràng buộc và mô tả nghiệp vụ. Việc sử dụng template này đảm bảo một nguồn chân lý duy nhất (single source of truth) về dữ liệu, giúp các đội ngũ Business Analyst (BA), Development (Dev), Quality Assurance (QA) và các bên liên quan nghiệp vụ có một sự hiểu biết thống nhất và chính xác.

Bảng hướng dẫn sử dụng

Khi nào NÊN dùng template này	Lý do
Bắt đầu một module hoặc dự án mới	Để xác định và thống nhất các thuộc tính dữ liệu cốt lõi ngay từ giai đoạn đầu.
Phân tích một hệ thống hiện có (reverse-engineering)	Để lập tài liệu, chuẩn hóa cấu trúc dữ liệu đang tồn tại cho mục đích bảo trì hoặc tích hợp.
Thiết kế API hoặc cấu trúc cơ sở dữ liệu (Database)	Để đặc tả chi tiết từng trường (field) trong một API request/response payload hoặc một bảng DB.
Chuẩn bị kịch bản kiểm thử (Test Case)	Để cung cấp cho đội QA một nguồn tham chiếu chính xác về định dạng, giá trị hợp lệ, và ràng buộc của dữ liệu.

Khi nào KHÔNG dùng template này	Thay vào đó, hãy dùng artifact tương ứng
Định nghĩa quy tắc nghiệp vụ phức tạp	Sử dụng catalog quy tắc nghiệp vụ tại /01-curriculum/CANONICAL_BUSINESS_RULES.md.
Mô tả luồng xử lý hoặc quy trình nghiệp vụ	Dùng sơ đồ quy trình (ví dụ: BPMN) hoặc tài liệu đặc tả quy trình.
Định nghĩa các thuật ngữ nghiệp vụ chung	Sử dụng bảng thuật ngữ (Glossary) của dự án.
Đặc tả các yêu cầu phi chức năng (NFRs)	Dùng template đặc tả yêu cầu phi chức năng (ví dụ: TMPL-REQ-002-nfrs.md).

Bảng quản trị và trách nhiệm

Vai trò / Hạng mục	Giá trị / Diễn giải
Chủ sở hữu (Owner)	IT Business Analyst. Lý do: BA là vai trò cầu nối, chịu trách nhiệm chuyển đổi nhu cầu nghiệp vụ thành đặc tả dữ liệu chi tiết, có thể hành động được cho đội kỹ thuật.
Người tiêu thụ (Consumers)	Đội Development, đội QA, đội Data/BI, Technical Architect, Technical Writer, các BA khác.
Điều kiện tiên quyết (Prerequisites)	Các yêu cầu nghiệp vụ ở mức cao đã được xác định. Phạm vi chức năng đã được khoanh vùng. Có thể tiếp cận các chuyên gia nghiệp vụ (domain experts) để làm rõ ý nghĩa dữ liệu.
Tài liệu bị ảnh hưởng (Downstream Artifacts)	Đặc tả API (OpenAPI), thiết kế Cơ sở dữ liệu, Kế hoạch Kiểm thử (Test Plan), Kịch bản Kiểm thử (Test Case), tài liệu hướng dẫn người dùng, đặc tả ETL.
Thẩm quyền (Authority)	1. Business Analyst (Tác giả): Soạn thảo, duy trì và đề xuất nội dung từ điển dữ liệu. 2. Business Owner / Product Owner (Phê duyệt nghiệp vụ): Phê duyệt ý nghĩa, tên gọi và các ràng buộc nghiệp vụ của dữ liệu. 3. Technical Architect (Phê duyệt kỹ thuật): Phê duyệt kiểu dữ liệu, độ dài và các khía cạnh kỹ thuật để đảm bảo tính khả thi và nhất quán kiến trúc.
Leo thang (Escalation)	1. Mâu thuẫn về định nghĩa nghiệp vụ: Leo thang lên Business Owner. 2. Mâu thuẫn về thiết kế kỹ thuật: Leo thang lên Technical Architect. 3. Lo ngại về pháp lý/tuân thủ (ví dụ: dữ liệu cá nhân): Leo thang lên Legal/Compliance Owner. Mọi leo thang chính thức phải được ghi nhận theo quy trình tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Liên kết Quản trị và Định danh Canonical

Template này không phải là một tài liệu độc lập. Nó là một artifact (đối tượng) được kiểm soát, có định danh và vòng đời được quản lý chặt chẽ trong corpus học liệu Nova Foods. Sự tồn tại, định danh, phiên bản, và các quy tắc thay đổi của nó phải tuân thủ các artifact quản trị cấp cao hơn. Mục đích là để đảm bảo traceability (khả năng truy vết) và tính nhất quán trên toàn bộ hệ thống tài liệu. Mọi tham chiếu đến template này từ các tài liệu khác phải sử dụng ID và đường dẫn canonical được định nghĩa dưới đây.

Thuộc tính Định danh	Giá trị Canonical	Diễn giải và Ràng buộc Kiểm soát
Artifact ID	TMPL-DATA-001-DATA-DICTIONARY	ID chính thức, duy nhất, không được thay đổi. Được sử dụng cho mọi liên kết truy vết và các kịch bản kiểm tra tự động. ID này phải được đăng ký và quản lý tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Tên tệp được kiểm soát	/03-templates/TMPL-DATA-001-data-dictionary.md	Đường dẫn không đổi, là nguồn chân lý cho template này. Các bản sao, bản xuất hoặc các tệp có tên tương tự không có giá trị kiểm soát.
Khai báo trong Manifest	Tham chiếu đến TEMPLATE_MANIFEST	Sự tồn tại và metadata của template này được khai báo và kiểm soát tập trung tại /01-curriculum/TEMPLATE_MANIFEST.md. Mọi thay đổi về trạng thái (status) hoặc phiên bản (version) phải được cập nhật ở đó trước tiên.

Template này được tạo ra để phục vụ trực tiếp các mục tiêu học tập trong Sổ tay BA (Handbook). Nó là công cụ thực hành cốt lõi khi học viên tiếp cận vùng kiến thức Requirements Analysis and Design Definition của BABOK. Cụ thể, nó được giới thiệu và sử dụng trong chương về Specify and Model Requirements để ghi lại các định nghĩa dữ liệu chi tiết cho case study Nova Foods, theo kế hoạch học tập đã vạch ra trong /01-curriculum/CHAPTER_MANIFEST.md.

Nguồn Tham chiếu	Mục đích Liên kết với Template và Nghĩa vụ Tuân thủ
BABOK Guide v3	Cung cấp định nghĩa chuẩn ngành cho "Data Dictionary" và các thành phần cốt lõi của nó (tên, bí danh, kiểu dữ liệu, giá trị cho phép, mô tả). Template này cụ thể hóa các khái niệm đó thành một cấu trúc có thể điền được.
ISO/IEC/IEEE 29148:2018	Đảm bảo cấu trúc của template tương thích với các tiêu chuẩn quốc tế về tài liệu yêu cầu phần mềm và hệ thống, nơi từ điển dữ liệu là một thành phần quan trọng để làm rõ yêu cầu.
/01-curriculum/ CANONICAL_DATA_DICTIONARY.md	Template này là một biểu hiện cụ thể, sẵn sàng sử dụng của kế hoạch được định nghĩa trong Canonical Logical Data Dictionary Plan. Kế hoạch đặt ra cấu trúc logic và các trường bắt buộc; template này hiện thực hóa nó.
/00-research/00_SOURCE_MAP.md	Mọi nguồn tham chiếu bên ngoài (như BABOK, ISO) phải được xác minh và liệt kê trong bản đồ nguồn này. Điều này đảm bảo tính hợp lệ và phạm vi sử dụng của các tiêu chuẩn được kiểm soát, tránh việc diễn giải sai.

Template này đang ở trạng thái IN_REVIEW. Điều này có nghĩa nó là một bản nháp đang được xem xét, chưa được baseline (chốt phiên bản gốc) hoặc phê duyệt để sử dụng chính thức. Mọi thay đổi, dù nhỏ nhất, phải được ghi lại trong mục Lịch sử Thay đổi của tài liệu. Để chuyển từ IN_REVIEW sang BASELINED, template bắt buộc phải trải qua một quy trình xem xét chất lượng (QA gate) chính thức và được ghi nhận trong artifact QA tương ứng. Owner của artifact, theo định nghĩa ở metadata, chịu trách nhiệm quản lý quy trình này nhưng không có quyền tự phê duyệt hoặc tự chốt baseline.

2. Tier 2 – Mẫu trắng sẵn sàng để Sao chép-Dán (Blank Copy-Paste-Ready Template)

Phần này là mẫu trắng, sẵn sàng để sao chép và dán khi cần định nghĩa một thực thể dữ liệu mới cho dự án. "Data Dictionary" (Từ điển Dữ liệu) là một tập hợp các định nghĩa về các phần tử dữ liệu, cấu trúc của chúng, và ý nghĩa nghiệp vụ của chúng. Mục đích là tạo ra một nguồn chân lý (single source of truth) duy nhất cho dữ liệu, đảm bảo mọi người trong dự án hiểu và sử dụng dữ liệu một cách nhất quán và chính xác.

Hãy điền vào tất cả các placeholder có định dạng <...> với thông tin cụ thể cho thực thể dữ liệu bạn đang định nghĩa. Không để trống các trường bắt buộc mà không có lý do được ghi nhận.

---

A. Metadata của Thực thể Dữ liệu (Data Entity)

Bảng này định danh, phân loại và quản lý phiên bản của chính định nghĩa dữ liệu này. Nó là phần "vỏ" quản trị cho nội dung bên trong.

Trường Metadata	Hướng dẫn và Giá trị
Data Entity ID	Cung cấp ID định danh duy nhất cho thực thể dữ liệu này từ /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Ví dụ: DE-001. Giá trị: <DE-XXX theo TRACEABILITY_ID_REGISTRY>
Tên Thực thể (Entity Name)	Tên nghiệp vụ, dễ hiểu của thực thể. Ví dụ: "Đơn đặt hàng". Giá trị: <Tên nghiệp vụ của thực thể>
Tên Kỹ thuật (Technical Name)	Tên kỹ thuật dùng trong code hoặc CSDL, theo quy tắc PascalCase hoặc snake_case. Ví dụ: PurchaseOrder hoặc purchase_order. Giá trị: <Tên kỹ thuật của thực thể>
Mô tả (Description)	Mô tả ngắn gọn mục đích và phạm vi của thực thể dữ liệu này trong hệ thống. Trả lời câu hỏi: "Thực thể này đại diện cho cái gì?" Giá trị: <Mô tả mục đích của thực thể trong 1-2 câu>
Owner Nghiệp vụ (Business Owner)	Vai trò hoặc người chịu trách nhiệm về mặt nghiệp vụ cho dữ liệu này. Người này có thẩm quyền quyết định các quy tắc liên quan đến dữ liệu. Ví dụ: "Trưởng phòng Mua hàng". Giá trị: <Chức danh của người sở hữu nghiệp vụ>
Phân loại Bảo mật (Security Classification)	Phân loại dữ liệu theo mức độ nhạy cảm, dựa trên chính sách bảo mật của tổ chức và quy định pháp luật (ví dụ: Luật Bảo vệ dữ liệu cá nhân). Giá trị: Public | Internal | Confidential | PII (Personally Identifiable Information) | Sensitive PII

B. Chi tiết các Thuộc tính (Attribute Details)

Đây là phần cốt lõi của từ điển, định nghĩa từng trường dữ liệu (thuộc tính) trong thực thể. Mỗi dòng tương ứng với một cột trong bảng CSDL hoặc một trường trong đối tượng JSON.

Tên thuộc tính (Attribute Name)	Kiểu dữ liệu (Data Type)	Mô tả & Mục đích	Giá trị hợp lệ / Định dạng	Bắt buộc?	Ví dụ	Ghi chú / Quy tắc nghiệp vụ (BR-ID)
<id>	UUID / Integer	<Định danh duy nhất của bản ghi. Thường là khóa chính (primary key).>	<Định dạng UUID v4 hoặc số nguyên tự tăng. Không thể thay đổi sau khi tạo.>	Có	<"a1b2c3d4-..."> / 12345	<Thường được tạo tự động bởi hệ thống.>
<ten_thuoc_tinh_ky_thuat_1>	<String(255)> / Decimal(18,2) / Datetime / Boolean / JSONB	<Giải thích ý nghĩa nghiệp vụ của trường này. Nó đại diện cho cái gì? Tại sao hệ thống cần nó?>	<Liệt kê các giá trị enum (Vd: 'PENDING', 'APPROVED', 'REJECTED'), hoặc regex (Vd:^0\d{9}$cho SĐT VN), hoặc khoảng giá trị (Vd: > 0).>	Có / Không / Có, nếu <điều kiện>	<Cung cấp một ví dụ giá trị hợp lệ.>	<Nếu có, tham chiếu đến ID của quy tắc nghiệp vụ trong CANONICAL_BUSINESS_RULES. Ví dụ: BR-PUR-005.>
<ten_thuoc_tinh_ky_thuat_2>	<...>	<...>	<...>	<...>	<...>	<...>
created_at	Timestamp with Time Zone	Dấu thời gian ghi lại thời điểm bản ghi được tạo trong CSDL.	ISO 8601 (YYYY-MM-DDTHH:MM:SSZ)	Có	2026-08-07T10:00:00+07:00	Được quản lý tự động bởi CSDL/framework. Không cho phép người dùng cuối sửa đổi.
updated_at	Timestamp with Time Zone	Dấu thời gian ghi lại thời điểm bản ghi được cập nhật lần cuối.	ISO 8601 (YYYY-MM-DDTHH:MM:SSZ)	Có	2026-08-07T11:30:00+07:00	Được quản lý tự động bởi CSDL/framework. Cập nhật mỗi khi có thay đổi trên bản ghi.

C. Quan hệ với các Thực thể khác (Relationships)

Mô tả cách thực thể này liên kết với các thực thể dữ liệu khác, định nghĩa các khóa ngoại (foreign keys).

Thực thể liên quan (Related Entity)	Loại quan hệ (Relationship Type)	Khóa ngoại (Foreign Key)	Mô tả quan hệ
<Tên thực thể liên quan, ví dụ: 'User'>	One-to-Many / Many-to-One / One-to-One / Many-to-Many	<Tên trường khóa ngoại trong bảng hiện tại, ví dụ: 'created_by_user_id'>	<Giải thích mối quan hệ nghiệp vụ, ví dụ: 'Mỗi Đơn đặt hàng được tạo bởi một Người dùng'>
<Tên thực thể liên quan, ví dụ: 'Supplier'>	<...>	<...>	<...>

D. Truy vết Yêu cầu (Requirements Traceability)

"Traceability" (Truy vết) là khả năng liên kết một mục (như trường dữ liệu này) ngược trở lại nguồn gốc của nó (như yêu cầu nghiệp vụ, user story). Bảng này đảm bảo mọi trường dữ liệu đều tồn tại để phục vụ một mục đích đã được phê duyệt.

ID Yêu cầu / Use Case / User Story	Mô tả Yêu cầu	Loại liên kết
<REQ-XXX / UC-XXX / US-XXX>	<Tóm tắt yêu cầu liên quan đã dẫn đến việc tạo ra thực thể/thuộc tính này.>	Derived from / Satisfies / Constrained by
<...>	<...>	<...>

E. Lịch sử Thay đổi và Phê duyệt (Version History & Sign-off)

Bảng này ghi lại nhật ký các thay đổi và phê duyệt đối với định nghĩa dữ liệu, đảm bảo tính minh bạch và quản lý được.

Phiên bản	Ngày	Người thực hiện	Tóm tắt thay đổi	Người Review	Ngày Review	Trạng thái
v0.1	<YYYY-MM-DD>	<Tên và vai trò người tạo>	Tạo bản nháp đầu tiên.	<Tên và vai trò người review>	<YYYY-MM-DD>	DRAFT
<vX.Y>	<YYYY-MM-DD>	<Tên và vai trò người sửa>	<Mô tả ngắn gọn các thay đổi trong phiên bản này.>	<Tên và vai trò người review>	<YYYY-MM-DD>	IN_REVIEW / APPROVED

Các Thành Phần Quản Trị, Truy Vết và Bằng Chứng

Các bảng này là bắt buộc để quản trị vòng đời của định nghĩa dữ liệu. Ghi lại mọi thay đổi, quyết định, và liên kết. Không xóa các phần này.

Lịch sử phiên bản (Version History) Dùng bảng này để ghi lại mọi thay đổi quan trọng đối với định nghĩa dữ liệu.

Phiên bản	Ngày	Người thực hiện	Tóm tắt thay đổi
<0.1>	<YYYY-MM-DD>	<Tên / Vai trò>	<Ví dụ: Khởi tạo bản nháp đầu tiên>
<...>	<...>	<...>	<...>

Theo dõi Review và Phê duyệt (Review and Sign-off Tracking) Ghi lại tất cả các lần review từ các bên liên quan có thẩm quyền. Quyết định Phê duyệt (Approved) là cần thiết để chuyển sang giai đoạn tiếp theo.

Vai trò	Người review	Ngày	Quyết định	Ghi chú / Tham chiếu
Business Owner	<Tên người có thẩm quyền nghiệp vụ>	<YYYY-MM-DD>	<Phê duyệt / Yêu cầu thay đổi / Từ chối>	<Ghi chú hoặc ID của bình luận>
Technical Architect	<Tên người có thẩm quyền kỹ thuật>	<YYYY-MM-DD>	<Phê duyệt / Yêu cầu thay đổi / Từ chối>	<Ghi chú hoặc ID của bình luận>
QA Lead	<Tên người có thẩm quyền chất lượng>	<YYYY-MM-DD>	<Phê duyệt / Yêu cầu thay đổi / Từ chối>	<Ghi chú hoặc ID của bình luận>
Legal / Compliance	<Tên người có thẩm quyền pháp lý>	<YYYY-MM-DD>	<Phê duyệt / Yêu cầu thay đổi / Từ chối>	<Ghi chú hoặc ID của bình luận>

Ma trận Truy vết (Traceability Matrix) Traceability là khả năng truy vết. Bảng này liên kết trường dữ liệu tới các đối tượng khác trong dự án như yêu cầu, quy tắc nghiệp vụ, hoặc test case.

ID Truy vết Nguồn (Source)	Loại Nguồn	ID Truy vết Đích (Destination)	Loại Đích	Mô tả liên kết
<ID của trường dữ liệu này>	Data Field	<Ví dụ: REQ-045>	Requirement	<Ví dụ: Trường này là bắt buộc để đáp ứng yêu cầu REQ-045>
<ID của trường dữ liệu này>	Data Field	<Ví dụ: BR-INV-010>	Business Rule	<Ví dụ: Định dạng của trường bị ràng buộc bởi quy tắc BR-INV-010>
<ID của trường dữ liệu này>	Data Field	<Ví dụ: TC-SEC-007>	Test Case	<Ví dụ: Test case TC-SEC-007 xác minh validation của trường>

Ghi nhận Quyết định và Ngoại lệ (Decisions and Exceptions Log) Ghi lại các quyết định quan trọng hoặc các trường hợp ngoại lệ được chấp thuận liên quan đến trường dữ liệu này.

Ngày	Người quyết định	Vấn đề / Ngoại lệ	Quyết định được đưa ra	Lý do / Bối cảnh
<YYYY-MM-DD>	<Tên / Vai trò>	<Mô tả ngắn gọn vấn đề cần quyết định>	<Mô tả quyết định cuối cùng>	<Lý do tại sao quyết định này được chọn>

Bằng chứng (Evidence) Evidence là bằng chứng. Dùng để tham chiếu đến các tài liệu nguồn, email, hoặc biên bản họp đã định hình nên định nghĩa của trường dữ liệu.

ID Bằng chứng	Loại nguồn	Mô tả / Trích dẫn / Đường dẫn
<EV-001>	<Tài liệu pháp lý / Email / Biên bản họp>	<Trích dẫn đoạn văn bản liên quan, hoặc mô tả nguồn và đường dẫn đến nó>
<EV-002>	<Tiêu chuẩn ngành (ví dụ: ISO)>	<Tham chiếu đến điều khoản hoặc phần cụ thể của tiêu chuẩn>

Hướng dẫn điền, quy tắc xác thực và các mẫu đặc biệt

Bảng dưới đây cung cấp hướng dẫn chi tiết, quy tắc xác thực, giá trị cho phép và các mẫu định dạng để điền vào biểu mẫu từ điển dữ liệu. Việc tuân thủ các quy tắc này đảm bảo tính nhất quán, chính xác và có thể kiểm soát được của dữ liệu trên toàn bộ hệ thống ERP Nova Foods.

Cột trong Từ điển Dữ liệu	Hướng dẫn và Quy tắc
Tên trường logic (Logical Field Name)	Ghi tên nghiệp vụ nhất quán, không phải tên cột trong cơ sở dữ liệu. Dùng tiếng Anh, theo quy tắc UpperCamelCase cho các đối tượng và camelCase hoặc snake_case cho các thuộc tính. Tên phải tự mô tả. Ví dụ: purchaseOrderNumber, customerFirstName.
Kiểu dữ liệu (Data Type)	Ghi kiểu dữ liệu logic, không phải kiểu dữ liệu vật lý của cơ sở dữ liệu. Các kiểu được chấp nhận: String, Integer, Decimal(precision,scale), Boolean, Datetime, Date, Array<Type>, Object. Ví dụ: Decimal(18,2) cho giá trị tiền tệ.
Định dạng / Mẫu (Format / Pattern)	Áp dụng cho String, Date, Datetime. Nếu có, ghi rõ mẫu. Ví dụ: YYYY-MM-DD cho ngày, YYYY-MM-DDTHH:mm:ssZ cho định dạng ISO 8601. Dùng Biểu thức chính quy (Regular Expression - Regex) cho các mẫu phức tạp như số điện thoại Việt Nam (^0[3|5|7|8|9])([0-9]{8})$ hoặc mã số thuế.
Giá trị cho phép (Allowed Values)	Liệt kê các giá trị cố định nếu trường là một kiểu liệt kê (enum). Ví dụ cho trường orderStatus: DRAFT, SUBMITTED, IN_REVIEW, APPROVED, SHIPPED, DELIVERED, CANCELLED. Nếu không giới hạn, ghi rõ Any valid <Data Type> value.
Quy tắc xác thực (Validation Rules)	Mô tả các ràng buộc logic hoặc nghiệp vụ. Sử dụng các từ khóa chuẩn: NOT NULL, UNIQUE, > 0, MUST BE IN PAST. Nếu quy tắc phức tạp, tham chiếu đến ID từ /01-curriculum/CANONICAL_BUSINESS_RULES.md. Ví dụ: Ngày giao hàng dự kiến không được trước ngày đặt hàng (BR-ORD-015).
Mô tả & Mục đích (Description & Purpose)	Giải thích ngắn gọn ý nghĩa nghiệp vụ của trường. Nếu trường có tính điều kiện (conditional), mô tả rõ ở đây. Ví dụ: Trường 'reasonForReturn' chỉ bắt buộc khi 'orderType' là 'RETURN'.
Phân loại dữ liệu (Data Classification)	Phân loại mức độ nhạy cảm để xác định yêu cầu bảo mật, tham chiếu OWASP ASVS V13. Giá trị bắt buộc phải là một trong các mục sau: PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED.
Trạng thái PII (PII Status)	Xác định xem trường có chứa Dữ liệu định danh cá nhân (Personally Identifiable Information - PII) theo định nghĩa của Luật 91/2025/QH15 hay không. Các giá trị được phép: PII-DIRECT (trực tiếp), PII-INDIRECT (gián tiếp), NOT_PII.

Mẫu Tham Chiếu Bí Mật An Toàn

Cảnh báo An ninh: Tuyệt đối không lưu trữ giá trị bí mật (mật khẩu, API key, access token) dưới dạng văn bản thuần túy trong tài liệu này hoặc trong mã nguồn. Các giá trị này phải được lưu trữ trong một hệ thống quản lý bí mật chuyên dụng (ví dụ: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).

Để tham chiếu đến một bí mật trong tài liệu, hãy sử dụng định dạng placeholder sau:

{{VAULT:<scope>/<path>:<key>}}

Định dạng này cho phép các hệ thống tích hợp và triển khai tự động (CI/CD) thay thế placeholder bằng giá trị thật tại thời điểm chạy, giữ cho tài liệu và mã nguồn an toàn.

Ví dụ: * Tham chiếu API key của hệ thống SAP: {{VAULT:production/nova-foods/api-keys:sap-erp}} * Tham chiếu mật khẩu cơ sở dữ liệu báo cáo: {{VAULT:staging/reporting-db/credentials:password}}

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

Phần này cung cấp một ví dụ hoàn chỉnh về từ điển dữ liệu cho một đối tượng nghiệp vụ cốt lõi trong hệ thống ERP của Nova Foods: Đơn Mua Hàng (Purchase Order). Mọi dữ liệu, định danh, và kịch bản đều là mô phỏng cho mục đích giáo dục và không đại diện cho hoạt động thực tế.

Bối cảnh: Business Analyst (BA) được giao nhiệm vụ định nghĩa cấu trúc dữ liệu cho module Quản lý Mua hàng. Đối tượng PurchaseOrder là trung tâm, dùng để ghi lại yêu cầu mua nguyên vật liệu từ nhà cung cấp.

Thực thể: PurchaseOrder (Đơn Mua Hàng)

Đây là bản ghi chính, chứa thông tin tổng hợp về một giao dịch mua hàng.

Định danh logic (Logical ID)	Nhãn (Label)	Kiểu dữ liệu (Data Type)	Ràng buộc & Ví dụ (Constraints & Examples)	Mô tả & Mục đích (Description & Purpose)	Phân loại dữ liệu (Data Classification)	Trạng thái PII (PII Status)
poId	Mã Đơn Hàng	UUID	Bắt buộc, khóa chính. Ví dụ: 01912a77-9407-789a-b44c-175276e27303	Định danh duy nhất toàn hệ thống cho mỗi đơn hàng. Sử dụng UUID (Universally Unique Identifier) để tránh xung đột khi đồng bộ dữ liệu.	INTERNAL	NOT_PII
supplierId	Mã Nhà Cung Cấp	UUID	Bắt buộc, khóa ngoại. Tham chiếu đến bảng Suppliers. Ví dụ: 0190a6f8-320c-7e2a-8c88-2947492211b1	Liên kết đơn hàng với một nhà cung cấp đã được phê duyệt trong hệ thống.	INTERNAL	NOT_PII
orderDate	Ngày Đặt Hàng	DATE	Bắt buộc. Định dạng: YYYY-MM-DD. Ví dụ: 2026-08-15	Ngày đơn hàng được tạo và gửi cho nhà cung cấp.	INTERNAL	NOT_PII
expectedDeliveryDate	Ngày Giao Hàng Dự Kiến	DATE	Không bắt buộc. Phải lớn hơn hoặc bằng orderDate. Ví dụ: 2026-08-25	Ngày Nova Foods dự kiến nhận được hàng hóa từ nhà cung cấp.	INTERNAL	NOT_PII
status	Trạng Thái	ENUM	Bắt buộc. Các giá trị được phép: DRAFT, SUBMITTED, APPROVED, COMPLETED, CANCELLED. Mặc định: DRAFT.	Trạng thái hiện tại của đơn hàng trong quy trình xử lý. ENUM (Enumeration) là một kiểu dữ liệu có tập hợp giá trị được định nghĩa trước.	INTERNAL	NOT_PII
totalAmount	Tổng Tiền	DECIMAL(19, 2)	Bắt buộc. Lớn hơn hoặc bằng 0. Ví dụ: 55000000.00	Tổng giá trị của đơn hàng, tự động tính từ tổng các lineTotal trong PurchaseOrderLine. Đơn vị tiền tệ được xác định bởi trường currency.	CONFIDENTIAL	NOT_PII
currency	Đơn vị tiền tệ	CHAR(3)	Bắt buộc. Chỉ chấp nhận mã ISO 4217. Mặc định: VND. Ví dụ: VND	Mã tiền tệ của đơn hàng. Trong bối cảnh Nova Foods Việt Nam, giá trị này luôn là VND.	INTERNAL	NOT_PII
createdBy	Người Tạo	UUID	Bắt buộc, khóa ngoại. Tham chiếu đến bảng Employees. Ví dụ: 01912b33-e18e-715a-9488-8b9a135f4a7c	ID của nhân viên đã tạo đơn hàng này. Dùng để truy vết và phân quyền.	INTERNAL	PII-INDIRECT
notes	Ghi Chú	TEXT	Độ dài tối đa 1000 ký tự. Ví dụ: Yêu cầu giao hàng trong giờ hành chính.	Ghi chú hoặc hướng dẫn thêm cho nhà cung cấp hoặc bộ phận nội bộ.	INTERNAL	PII-INDIRECT

Thực thể: PurchaseOrderLine (Chi tiết Dòng Đơn Hàng)

Đây là các bản ghi chi tiết, mỗi bản ghi tương ứng với một mặt hàng trong Đơn Mua Hàng. PurchaseOrderLine không tồn tại độc lập: poId phải tham chiếu một bản ghi PurchaseOrder hợp lệ và productId phải tham chiếu một bản ghi Products hợp lệ. Hệ thống dùng từng dòng để xác định số lượng, đơn giá tại thời điểm đặt hàng và thành tiền của mặt hàng.

Định danh logic (Logical ID)	Nhãn (Label)	Kiểu dữ liệu (Data Type)	Ràng buộc & Ví dụ (Constraints & Examples)	Mô tả & Mục đích (Description & Purpose)	Phân loại dữ liệu (Data Classification)	Trạng thái PII (PII Status)
poLineId	Mã Dòng Đơn Hàng	UUID	Bắt buộc, khóa chính. Giá trị phải duy nhất trong tập bản ghi PurchaseOrderLine. Ví dụ: 01912a7b-32f7-720c-a99f-d3283226a3a9	Định danh duy nhất cho mỗi dòng trong một đơn hàng. Hệ thống dùng mã này để truy vết, cập nhật và tham chiếu đúng dòng hàng.	INTERNAL	NOT_PII
poId	Mã Đơn Hàng	UUID	Bắt buộc, khóa ngoại. Tham chiếu đến bảng PurchaseOrder. Giá trị phải khớp PurchaseOrder.poId đang tồn tại.	Liên kết dòng này với đơn hàng chính. Khóa ngoại ngăn dòng hàng mồ côi không có đơn mua hàng cha.	INTERNAL	NOT_PII
productId	Mã Sản Phẩm	UUID	Bắt buộc, khóa ngoại. Tham chiếu đến bảng Products. Ví dụ: 018ffc7a-54a8-7d3d-82d2-8a9d16a1b2c5	Mã sản phẩm (nguyên vật liệu) đang được mua. Hệ thống dùng mã này để xác định đúng sản phẩm và đơn vị tính áp dụng từ bảng Products.	INTERNAL	NOT_PII
quantity	Số Lượng	DECIMAL(10, 2)	Bắt buộc. Lớn hơn 0. Ví dụ: 500.00	Số lượng sản phẩm được đặt mua. Đơn vị tính (ví dụ: kg, tấn, thùng) được lấy từ bảng Products. Giá trị không dương bị từ chối vì không thể tạo thành dòng đặt mua hợp lệ.	INTERNAL	NOT_PII
unitPrice	Đơn Giá	DECIMAL(19, 2)	Bắt buộc. Lớn hơn hoặc bằng 0. Ví dụ: 110000.00	Giá mua cho một đơn vị sản phẩm tại thời điểm đặt hàng. Hệ thống lưu giá trên dòng hàng để tính giá trị giao dịch của chính đơn hàng đó.	CONFIDENTIAL	NOT_PII
lineTotal	Thành Tiền	DECIMAL(19, 2)	Trường tính toán. quantity * unitPrice Ví dụ: 55000000.00	Tổng giá trị cho dòng hàng này. Hệ thống tính từ quantity và unitPrice; người dùng không nhập trực tiếp để tránh sai lệch giữa số lượng, đơn giá và thành tiền.	CONFIDENTIAL	NOT_PII

Bản ghi mô phỏng hợp lệ:

poLineId	poId	productId	quantity	unitPrice	lineTotal
01912a7b-32f7-720c-a99f-d3283226a3a9	01912a6a-1ec6-74c0-a2da-2fef4bdc8b68	018ffc7a-54a8-7d3d-82d2-8a9d16a1b2c5	500.00	110000.00	55000000.00

Kiểm tra nhất quán: 500.00 * 110000.00 = 55000000.00. Nếu poId hoặc productId không tham chiếu bản ghi tồn tại, hệ thống phải từ chối dòng hàng. Nếu quantity nhỏ hơn hoặc bằng 0, hệ thống phải từ chối dòng hàng. Nếu lineTotal khác kết quả tính từ quantity và unitPrice, hệ thống phải tính lại lineTotal từ hai trường nguồn.

3. Tier 3 — Ví dụ Hoàn chỉnh cho Case Study Nova Foods: Bản ghi Lõi

Đây là ví dụ hoàn chỉnh về một mục trong từ điển dữ liệu cho trường PurchaseOrder.Status (Trạng thái Đơn Mua hàng) trong hệ thống ERP mô phỏng của Nova Foods. Mục này được điền đầy đủ dữ liệu tổng hợp, không chứa bất kỳ placeholder nào.

A. Định nghĩa Trường Dữ liệu (Data Element Definition)

Bảng dưới đây định nghĩa chi tiết cho một trường dữ liệu logic. Mỗi thuộc tính được giải thích rõ ràng về giá trị và lý do lựa chọn trong bối cảnh Nova Foods.

Thuộc tính	Giá trị	Diễn giải & Lý do
Định danh duy nhất (Unique ID)	DE-015	DE là viết tắt của Data Element. ID này được đăng ký và quản lý tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md để đảm bảo truy vết.
Tên Trường Logic (Logical Field Name)	PurchaseOrder.Status	Tên logic theo cấu trúc Entity.Attribute. Cách đặt tên này nhất quán với mô hình dữ liệu logic của hệ thống, giúp developer dễ dàng ánh xạ.
Tên Nghiệp vụ (Business Name)	Trạng thái Đơn Mua hàng	Tên gọi thân thiện, dễ hiểu với người dùng cuối thuộc phòng Mua hàng và các phòng ban liên quan.
Mô tả (Description)	Trường dữ liệu dùng để theo dõi trạng thái của một đơn mua hàng (PO) trong suốt vòng đời của nó, từ lúc khởi tạo đến khi hoàn tất và lưu trữ.	Mô tả rõ mục đích, giúp Business Analyst và đội phát triển hiểu đúng ngữ cảnh nghiệp vụ, tránh diễn giải sai.
Chủ sở hữu Dữ liệu (Data Owner)	Trưởng phòng Mua hàng (Head of Procurement)	Đây là vai trò nghiệp vụ chịu trách nhiệm định nghĩa các trạng thái, quy tắc chuyển đổi, và đảm bảo tính đúng đắn của dữ liệu trạng thái.
Hệ thống Nguồn (Source of Truth)	NF-ERP-P2P	NF-ERP-P2P là mã định danh cho phân hệ Procure-to-Pay của Nova Foods ERP. Đây là hệ thống duy nhất nơi dữ liệu này được tạo và quản lý.
Kiểu Dữ liệu (Data Type)	ENUM (Enumeration / Kiểu liệt kê)	Sử dụng ENUM để giới hạn các giá trị hợp lệ, tránh nhập liệu sai và đảm bảo tính toàn vẹn dữ liệu. Lựa chọn này tốt hơn VARCHAR(20) vì nó tự xác thực ở cấp độ cơ sở dữ liệu.
Giá trị Mặc định (Default Value)	DRAFT	Mọi đơn hàng mới tạo tự động có trạng thái "Nháp", yêu cầu nhân viên phải hoàn thiện trước khi trình duyệt, giảm thiểu sai sót.
Cho phép NULL? (Nullable?)	Không (Not Null)	Bắt buộc. Mọi đơn mua hàng phải luôn có một trạng thái xác định. Để NULL sẽ gây lỗi logic xử lý và tạo ra các báo cáo không chính xác.
Phân loại Dữ liệu (Data Classification)	Nội bộ (Internal)	Không chứa Dữ liệu Cá nhân (PII - Personally Identifiable Information). Chỉ sử dụng trong nội bộ công ty. Mức độ bảo mật thấp.
Mức độ Quan trọng (Criticality)	Cao (High)	Sai lệch trạng thái có thể làm ngưng trệ quy trình mua hàng, ảnh hưởng tiêu cực đến hoạt động sản xuất và chuỗi cung ứng.
Ví dụ (Example)	APPROVED	Một giá trị hợp lệ trong danh sách các giá trị được phép.

B. Các Giá trị Được phép và Quy tắc Chuyển đổi Trạng thái

Trạng thái PurchaseOrder.Status phải tuân theo một luồng xử lý (state machine) được định nghĩa chặt chẽ để đảm bảo quy trình nghiệp vụ được tuân thủ nghiêm ngặt. Bảng này mô tả các giá trị hợp lệ và logic chuyển đổi.

Giá trị (ENUM)	Tên hiển thị (Tiếng Việt)	Mô tả	Trạng thái tiếp theo có thể	Quy tắc Nghiệp vụ liên quan
DRAFT	Nháp	Đơn hàng đang được soạn thảo bởi Nhân viên Mua hàng. Có thể chỉnh sửa nội dung.	SUBMITTED, CANCELLED	BR-PO-005
SUBMITTED	Đã trình duyệt	Đơn hàng đã được gửi để Trưởng phòng Mua hàng xem xét. Không thể chỉnh sửa ở trạng thái này.	APPROVED, REJECTED	BR-PO-006
APPROVED	Đã phê duyệt	Đơn hàng đã được cấp có thẩm quyền phê duyệt và sẵn sàng gửi cho nhà cung cấp.	SENT_TO_SUPPLIER	BR-PO-007
REJECTED	Bị từ chối	Đơn hàng bị từ chối. Phải có lý do từ chối đi kèm.	DRAFT, CANCELLED	BR-PO-008
SENT_TO_SUPPLIER	Đã gửi NCC	Đơn hàng đã được gửi thành công đến Nhà cung cấp. Chờ xác nhận từ NCC.	ACKNOWLEDGED, IN_TRANSIT	BR-PO-009
ACKNOWLEDGED	NCC đã xác nhận	Nhà cung cấp đã xác nhận nhận được đơn hàng và đồng ý các điều khoản.	IN_TRANSIT	BR-PO-010
IN_TRANSIT	Đang vận chuyển	Hàng hóa đang trên đường vận chuyển từ nhà cung cấp đến kho của Nova Foods.	PARTIALLY_RECEIVED, FULLY_RECEIVED	BR-PO-011
PARTIALLY_RECEIVED	Đã nhận một phần	Đã nhận một phần hàng hóa. Đơn hàng vẫn ở trạng thái mở để tiếp tục nhận hàng.	FULLY_RECEIVED	BR-PO-012
FULLY_RECEIVED	Đã nhận đủ hàng	Toàn bộ hàng hóa theo đơn hàng đã được giao và nhập kho thành công.	INVOICED	BR-PO-013
INVOICED	Đã có hóa đơn	Nhà cung cấp đã gửi hóa đơn. Đơn hàng được chuyển cho bộ phận Kế toán Công nợ (AP).	PAID	BR-AP-002
PAID	Đã thanh toán	Đơn hàng đã được thanh toán đầy đủ cho nhà cung cấp.	CLOSED	BR-AP-003
CLOSED	Đã đóng	Quy trình mua hàng được xem là hoàn tất. Không có hành động nào thêm. Dữ liệu được lưu trữ.	(kết thúc)	BR-PO-014
CANCELLED	Đã hủy	Đơn hàng đã bị hủy (trước khi gửi NCC hoặc do NCC từ chối). Quy trình kết thúc.	(kết thúc)	BR-PO-015

Ghi chú: * Traceability (Truy vết): Mỗi quy tắc nghiệp vụ được tham chiếu (ví dụ: BR-PO-005) phải được định nghĩa chi tiết trong artifact CANONICAL_BUSINESS_RULES.md để đảm bảo tính nhất quán và dễ tra cứu. * Thẩm quyền (Authority): Việc chuyển đổi giữa các trạng thái quan trọng (ví dụ: từ SUBMITTED sang APPROVED) được kiểm soát chặt chẽ bằng cơ chế phân quyền trong hệ thống ERP, chỉ cho phép vai trò được chỉ định (Trưởng phòng Mua hàng) thực hiện. Điều này được ghi nhận trong quy tắc BR-PO-006.

3.4 Bối cảnh, Phân tích và Quyết định cho Trường dữ liệu

Phân tích này tập trung vào trường dữ liệu PurchaseOrderStatus (Trạng thái Đơn Mua hàng) trong module Quản lý Mua hàng của hệ thống ERP Nova Foods. Mục tiêu là xác định một cấu trúc dữ liệu chuẩn hóa, đáp ứng nhu cầu nghiệp vụ và kỹ thuật.

Bối cảnh và Hiện trạng

Hệ thống cũ của Nova Foods quản lý đơn mua hàng bằng các tệp Excel. Trường trạng thái không được chuẩn hóa, dẫn đến các vấn đề nghiêm trọng về tính nhất quán và khả năng tự động hóa.

Yếu tố Phân tích	Mô tả chi tiết (Dữ liệu mô phỏng)
Trường dữ liệu	PurchaseOrderStatus
Hệ thống nguồn	Bảng tính QUAN_LY_MUA_HANG_2025.xlsx
Hiện trạng	Trường văn bản tự do (NVARCHAR(100)).
Vấn đề thực tế	Người dùng nhập các giá trị khác nhau nhưng cùng ngữ nghĩa, ví dụ: "đã duyệt", "Approved", "OK", "chấp nhận", "xong". Dữ liệu này không thể được dùng để chạy báo cáo tự động hoặc kích hoạt các bước tiếp theo trong quy trình (ví dụ: tạo phiếu nhập kho).
ID tham chiếu vấn đề	NF-ISSUE-017

Nhu cầu Nghiệp vụ (Underlying Business Need)

Nhu cầu cốt lõi là có một nguồn chân lý (single source of truth) duy nhất và rõ ràng về trạng thái của một đơn mua hàng trong suốt vòng đời của nó. Trạng thái này phải được hệ thống kiểm soát chặt chẽ để đảm bảo bộ phận Mua hàng, Kho vận, và Kế toán có cùng một góc nhìn. Điều này là nền tảng cho việc tự động hóa quy trình đối chiếu công nợ và quản lý tồn kho chính xác.

• ID Yêu cầu liên quan: NF-REQ-PROC-045 (Chuẩn hóa vòng đời Đơn Mua hàng để tự động hóa).

Phân tích và So sánh các Phương án

Ba phương án đã được xem xét để giải quyết vấn đề. Mỗi phương án được đánh giá dựa trên các tiêu chí quan trọng đối với cả người dùng nghiệp vụ và đội ngũ kỹ thuật.

Tiêu chí	Phương án 1: Giữ trường văn bản + Hướng dẫn	Phương án 2: Dùng mã số (Numeric Codes)	Phương án 3: Dùng mã chuỗi Enum (String Enums)
Tính nhất quán dữ liệu	Thấp. Phụ thuộc hoàn toàn vào kỷ luật người dùng.	Cao. Hệ thống chỉ chấp nhận các giá trị định sẵn.	Cao. Hệ thống chỉ chấp nhận các giá trị định sẵn.
Dễ hiểu cho người dùng	Cao. Người dùng đọc được ngay.	Thấp. Phải tra cứu ý nghĩa của mã số (ví dụ: 20 là gì?).	Cao. Dễ đọc và dễ hiểu (ví dụ: APPROVED).
Khả năng tích hợp (API)	Rất thấp. Gây khó khăn cho hệ thống bên ngoài.	Trung bình. API trả về số, client phải tự diễn giải.	Cao. Tự mô tả, phù hợp với tiêu chuẩn OpenAPI.
Khả năng báo cáo	Thấp. Phải làm sạch dữ liệu thủ công trước khi báo cáo.	Cao. Dễ dàng nhóm và tổng hợp theo mã số.	Cao. Dễ dàng nhóm và tổng hợp.
Nỗ lực triển khai	Rất thấp. Không cần thay đổi kỹ thuật.	Trung bình. Cần logic ánh xạ trong code.	Trung bình. Yêu cầu định nghĩa enum trong database và code.
Đề xuất	Không chọn	Không chọn	Lựa chọn

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

• Quyết định: Áp dụng Phương án 3, sử dụng một tập hợp các mã chuỗi có ý nghĩa (String Enumeration) được định nghĩa trước cho trường PurchaseOrderStatus.
• ID Quyết định: NF-DEC-PROC-012
• Thẩm quyền quyết định:
  • Business Owner (Procurement): Phê duyệt về mặt quy trình nghiệp vụ.
  • IT Architect: Phê duyệt về mặt thiết kế kỹ thuật và khả năng mở rộng.
• Lý do: Phương án 3 cung cấp sự cân bằng tốt nhất giữa tính toàn vẹn dữ liệu, trải nghiệm người dùng, và khả năng tích hợp hệ thống. Nó loại bỏ sự mơ hồ và tạo nền tảng vững chắc cho tự động hóa.

Hậu quả nếu Quyết định sai

Nếu tiếp tục sử dụng trường văn bản tự do (Phương án 1), Nova Foods sẽ tiếp tục đối mặt với rủi ro vận hành: sai sót trong thanh toán cho nhà cung cấp do đối chiếu công nợ thủ công, thông tin tồn kho không chính xác dẫn đến nguy cơ hết hàng (stockout) hoặc tồn đọng vốn, và không thể xây dựng các quy trình tự động hóa hiệu quả.

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

Các bảng dưới đây ghi lại các trường hợp ngoại lệ, giả định, hạng mục cần xác minh, truy vết và bản ghi leo thang liên quan đến trường dữ liệu PurchaseOrderStatus. Mục đích là đảm bảo phân tích đầy đủ, quản trị được các rủi ro và tạo ra một cơ sở vững chắc cho việc kiểm thử và triển khai.

4.1. Trường hợp ngoại lệ và Luồng tiêu cực (Negative Paths)

Luồng tiêu cực mô tả cách hệ thống phản ứng với các đầu vào không hợp lệ hoặc các hành động bị cấm, đảm bảo tính toàn vẹn của dữ liệu và quy trình.

ID Ngoại lệ	Kịch bản	Tác nhân kích hoạt (Trigger)	Hành vi Hệ thống mong muốn	Tác động nghiệp vụ
EXCP-PO-001	Người dùng hoặc hệ thống bên ngoài cố gắng cập nhật trạng thái với một giá trị không có trong danh sách định trước.	API PATCH /purchase-orders/{id} nhận payload {"status": "WAITING"}.	Hệ thống từ chối yêu cầu với mã lỗi HTTP 400 Bad Request và payload lỗi {"error": "Invalid status value. Must be one of [DRAFT, SUBMITTED, APPROVED, IN_PROGRESS, COMPLETED, CANCELLED]."}.	Ngăn chặn dữ liệu rác làm hỏng báo cáo và các quy trình tự động. Bảo vệ tính toàn vẹn của tích hợp.
EXCP-PO-002	Người dùng cố gắng thực hiện một chuyển đổi trạng thái bị cấm bởi quy tắc nghiệp vụ.	Người dùng có vai trò "Procurement Staff" cố gắng chuyển trạng thái đơn hàng từ COMPLETED trở lại IN_PROGRESS trên giao diện người dùng.	Giao diện người dùng (UI) vô hiệu hóa (disabled) các lựa chọn chuyển đổi trạng thái không hợp lệ. Nếu hành động được thực hiện qua API, hệ thống trả về lỗi 422 Unprocessable Entity với thông báo {"error": "State transition from COMPLETED to IN_PROGRESS is not allowed."}.	Duy trì tính logic của vòng đời đơn hàng. Ngăn chặn gian lận hoặc sai sót sau khi đơn hàng đã hoàn tất và được thanh toán.
EXCP-PO-003	Người dùng không có quyền cố gắng thay đổi trạng thái quan trọng (ví dụ: duyệt đơn hàng).	Người dùng có vai trò "Procurement Staff" cố gắng chuyển trạng thái từ SUBMITTED sang APPROVED.	Hệ thống từ chối hành động với lỗi HTTP 403 Forbidden. Giao diện người dùng không hiển thị nút "Approve" cho vai trò này.	Thi hành cơ chế phân quyền (SoD - Segregation of Duties). Đảm bảo chỉ người có thẩm quyền mới có thể cam kết chi tiêu của công ty.

4.2. Giả định (Assumptions) và Hạng mục cần xác minh (Verification-Required)

Giả định là những điều kiện được cho là đúng để tiến hành phân tích, nhưng cần được xác minh để tránh rủi ro.

ID	Loại	Nội dung	Lý do đưa ra	Tác động nếu sai	Vai trò xác minh	Trạng thái
ASMP-PO-001	Giả định	Danh sách 6 trạng thái (DRAFT, SUBMITTED, APPROVED, IN_PROGRESS, COMPLETED, CANCELLED) là đầy đủ cho giai đoạn 1 (MVP).	Dựa trên kết quả workshop REQ-WS-PROC-002 ngày 2026-07-15 với Trưởng phòng Mua hàng.	Phải thực hiện thay đổi hệ thống (change request) ở giai đoạn sau nếu quy trình thực tế cần các trạng thái chi tiết hơn như PARTIALLY_RECEIVED (Đã nhận một phần).	Business Owner (Procurement)	VERIFIED
VFY-PO-001	Cần xác minh	Quy tắc chuyển đổi trạng thái chi tiết: một đơn hàng CANCELLED có thể được mở lại (re-opened) thành DRAFT không?	Quy tắc này chưa được làm rõ trong workshop. Có thể ảnh hưởng đến báo cáo tài chính và quản lý ngân sách.	Rủi ro sai lệch dữ liệu nếu cho phép mở lại các đơn hàng đã hủy mà không có quy trình kiểm soát chặt chẽ.	Business Owner (Procurement)	VERIFIED - 2026-08-07: Không cho phép. Phải tạo đơn hàng mới.
VFY-PO-002	Cần xác minh	Việc ánh xạ trạng thái đơn hàng với hệ thống kế toán bên ngoài.	Hệ thống kế toán có thể cần một mã cụ thể khi đơn hàng ở trạng thái COMPLETED để tự động tạo bút toán công nợ.	Tích hợp thất bại hoặc yêu cầu xử lý thủ công, làm giảm hiệu quả của tự động hóa.	IT Architect, Finance System Owner	PENDING_VERIFICATION

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

Truy vết đảm bảo mọi thành phần dữ liệu đều có nguồn gốc từ một nhu cầu nghiệp vụ và được kiểm chứng thông qua các yêu cầu, quy tắc và kịch bản kiểm thử.

Từ (Source Artifact)	Đến (Target Artifact)	Loại liên kết	Mô tả ngắn gọn
DATA-NF-PO-001 (PurchaseOrderStatus)	NEED-PROC-003	Satisfies	Trường trạng thái này đáp ứng nhu cầu theo dõi vòng đời đơn hàng mua.
REQ-PROC-010	DATA-NF-PO-001 (PurchaseOrderStatus)	Refined by	Yêu cầu "Hệ thống phải cho phép theo dõi trạng thái của đơn hàng" được chi tiết hóa bằng trường dữ liệu này.
BR-PROC-005	DATA-NF-PO-001 (PurchaseOrderStatus)	Constrains	Quy tắc nghiệp vụ "Đơn hàng phải được duyệt (APPROVED) trước khi nhận hàng" ràng buộc các giá trị hợp lệ của trường này.
AC-PROC-010-01	DATA-NF-PO-001 (PurchaseOrderStatus)	Verifies	Tiêu chí chấp nhận "Khi người dùng nhấn 'Duyệt', trạng thái phải chuyển thành APPROVED" xác minh hành vi của trường này.
DATA-NF-PO-001 (PurchaseOrderStatus)	TC-PROC-025	Is basis for	Định nghĩa trường dữ liệu này là cơ sở (test basis) để thiết kế ca kiểm thử về chuyển đổi trạng thái đơn hàng.
NF-DEC-PROC-012	DATA-NF-PO-001 (PurchaseOrderStatus)	Governs	Quyết định sử dụng kiểu dữ liệu "String Enumeration" chi phối thiết kế kỹ thuật của trường này.

4.4. Bản ghi Leo thang (Escalation Record)

Bản ghi này ghi lại các vấn đề không thể giải quyết ở cấp độ nhóm dự án và cần sự can thiệp từ các bên liên quan cấp cao hơn.

ID Leo thang	Ngày	Vấn đề	Leo thang đến (Vai trò)	Quyết định/Giải pháp	Trạng thái
ESC-PROC-001	2026-07-20	Bất đồng giữa phòng Mua hàng và phòng Kế toán về thời điểm hệ thống nên coi một đơn hàng là "cam kết chi tiêu": khi trạng thái là APPROVED hay khi là COMPLETED.	Head of Operations	Quyết định: Cam kết ngân sách được ghi nhận khi trạng thái là APPROVED. Công nợ phải trả được ghi nhận khi trạng thái là COMPLETED và có hóa đơn hợp lệ từ nhà cung cấp. Quyết định được ghi nhận với ID NF-DEC-FIN-004.	RESOLVED

Bảng Ma trận Truy vết (Traceability Matrix) cho supplier_tax_code

Ma trận Truy vết (Traceability Matrix) là một công cụ trực quan, thường ở dạng bảng, dùng để theo dõi và kết nối các hạng mục công việc (artifacts) trong suốt vòng đời phát triển phần mềm. Mục tiêu chính của nó là đảm bảo mọi yêu cầu đều được liên kết với nguồn gốc (nhu cầu nghiệp vụ) và đích đến (kiểm thử, triển khai), giúp xác minh rằng không có yêu cầu nào bị bỏ sót và hệ thống được xây dựng đúng mục đích. Khả năng truy vết (traceability) này là một năng lực cốt lõi của Business Analyst được định nghĩa trong BABOK Guide.

Bảng dưới đây minh họa một chuỗi truy vết hai chiều (bidirectional traceability) hoàn chỉnh cho trường dữ liệu supplier_tax_code trong case study mô phỏng của Nova Foods. Nó cho thấy cách một nhu cầu nghiệp vụ được phân rã thành các yêu cầu, quy tắc, tiêu chí chấp nhận, sau đó được hiện thực hóa bằng một trường dữ liệu cụ thể và cuối cùng được xác minh bằng kịch bản kiểm thử. Tất cả các mã định danh (ID) trong bảng đều là dữ liệu tổng hợp, tuân thủ theo cấu trúc đã hoạch định tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

ID Nguồn (Source ID)	Loại Nguồn	ID Đích (Target ID)	Loại Đích	Mô tả Liên kết & Lý do	Trạng thái
NEED-FIN-001	Nhu cầu Nghiệp vụ (Business Need)	REQ-FN-012	Yêu cầu Chức năng (Functional Req)	REQ-FN-012 được tạo ra để hiện thực hóa NEED-FIN-001 về việc tuân thủ các quy định kế toán và thuế của Việt Nam khi làm việc với nhà cung cấp.	Linked
REQ-FN-012	Yêu cầu Chức năng (Functional Req)	BR-VAL-003	Quy tắc Nghiệp vụ (Business Rule)	BR-VAL-003 định nghĩa tiêu chí "hợp lệ" cho mã số thuế, cụ thể hóa yêu cầu chung REQ-FN-012 về việc phải lưu trữ mã số thuế hợp lệ.	Linked
BR-VAL-003	Quy tắc Nghiệp vụ (Business Rule)	AC-US101-03	Tiêu chí Chấp nhận (Acceptance Criterion)	AC-US101-03 mô tả hành vi xác thực cụ thể của hệ thống (validation logic) để thực thi quy tắc BR-VAL-003 khi người dùng nhập dữ liệu.	Linked
AC-US101-03	Tiêu chí Chấp nhận (Acceptance Criterion)	DATA-CORE-001	Phần tử Dữ liệu (Data Element)	DATA-CORE-001 (supplier_tax_code) là trường dữ liệu vật lý được định nghĩa trong từ điển dữ liệu để lưu trữ thông tin được kiểm soát bởi AC-US101-03.	Linked
DATA-CORE-001	Phần tử Dữ liệu (Data Element)	TC-FT-101-005	Kịch bản Kiểm thử (Test Case)	TC-FT-101-005 được thiết kế để xác minh rằng việc triển khai trường DATA-CORE-001 trên giao diện người dùng tuân thủ đúng quy tắc BR-VAL-003.	Linked

Bằng chứng: Bảng Quyết Định và Dữ liệu API mẫu cho purchase_order.status

Để đảm bảo tính nhất quán và giảm thiểu sai sót trong logic nghiệp vụ, một Bảng Quyết Định (Decision Table) được sử dụng. Đây là một kỹ thuật phân tích nghiệp vụ được chuẩn hóa trong BABOK Guide, dùng để mô hình hóa các quy tắc phức tạp có nhiều điều kiện. Bảng này ánh xạ các kết hợp giữa trạng thái hiện tại của đơn hàng và hành động của người dùng tới một trạng thái kết quả xác định, qua đó loại bỏ sự mơ hồ. Bảng dưới đây định nghĩa vòng đời hợp lệ cho trường dữ liệu purchase_order.status trong hệ thống ERP mô phỏng của Nova Foods, cụ thể hóa Quy tắc Nghiệp vụ BR-NF-ACC-015.

Bảng Quyết Định cho Vòng đời Trạng thái Đơn Mua Hàng (Purchase Order)

ID Quy tắc	Điều kiện 1: Trạng thái hiện tại	Điều kiện 2: Hành động người dùng	Hành động 1: Trạng thái tiếp theo	Hành động 2: Tác động phụ / Ghi chú
R1	(Không có)	Tạo mới (Create)	DRAFT	Chỉ người tạo mới có thể sửa. Kích hoạt ở giao diện tạo đơn hàng.
R2	DRAFT	Gửi duyệt (Submit for Approval)	PENDING_APPROVAL	Gửi thông báo đến người quản lý cấp duyệt được phân công.
R3	PENDING_APPROVAL	Phê duyệt (Approve)	APPROVED	Mở khóa hành động "Đặt hàng". Gửi thông báo cho bộ phận mua hàng.
R4	PENDING_APPROVAL	Từ chối (Reject)	REJECTED	Gửi thông báo và lý do từ chối cho người tạo. Đơn hàng trở về trạng thái có thể sửa.
R5	DRAFT	Hủy (Cancel)	CANCELLED	Đóng vĩnh viễn đơn hàng. Hành động không thể hoàn tác.
R6	APPROVED	Đặt hàng (Place Order)	ORDERED	Ghi nhận mã đơn hàng từ nhà cung cấp. Không thể sửa thông tin chính (sản phẩm, số lượng, giá).
R7	ORDERED	Nhận hàng một phần (Receive Partially)	PARTIALLY_RECEIVED	Cập nhật số lượng đã nhận trong phiếu nhập kho. Đơn hàng vẫn mở.
R8	ORDERED	Nhận đủ hàng (Receive Fully)	FULLY_RECEIVED	Đóng đơn hàng. Chuyển thông tin sang phân hệ kế toán phải trả để xử lý thanh toán.
R9	PARTIALLY_RECEIVED	Nhận đủ hàng (Receive Fully)	FULLY_RECEIVED	Đóng đơn hàng. Chuyển thông tin sang phân hệ kế toán phải trả.
R10	APPROVED	Hủy (Cancel)	CANCELLED	Phải có lý do được ghi nhận. Gửi thông báo cho các bên liên quan.

Bằng chứng kỹ thuật thường bao gồm các ví dụ về payload của API. Payload là phần thân của một yêu cầu hoặc phản hồi API, chứa dữ liệu thực tế được gửi đi hoặc nhận về. Dưới đây là một ví dụ về payload cho yêu cầu PATCH để cập nhật trạng thái đơn hàng, tuân thủ quy tắc R3 trong bảng quyết định ở trên.

Ví dụ Payload API để cập nhật trạng thái

// Yêu cầu PATCH đến /api/v1/purchase-orders/PO-2026-08-12345
// Hành động: Phê duyệt đơn hàng đang ở trạng thái PENDING_APPROVAL
// Tham chiếu Bảng Quyết Định: Quy tắc R3
{
  "status": "APPROVED",
  "approved_by_user_id": "manager01",
  "approval_timestamp": "2026-08-07T14:30:00Z",
  "notes": "Approved based on budget availability for Q3."
}

Từ bảng quyết định, nhóm kiểm thử (QA) sẽ tạo ra các trường hợp kiểm thử (test cases) để xác minh hệ thống hoạt động đúng như mong đợi. Dưới đây là một vài ví dụ về dữ liệu kiểm thử.

Dữ liệu Kiểm thử Mẫu (Sample Test Data)

Test Case ID	Mô tả	Tiền điều kiện (Trạng thái hiện tại)	Hành động Kiểm thử	Hậu điều kiện (Trạng thái mong đợi)
TC-STATUS-001	Kiểm tra chuyển đổi hợp lệ từ Draft sang Pending Approval	DRAFT	Người dùng nhấn "Gửi duyệt"	PENDING_APPROVAL
TC-STATUS-002	Kiểm tra chuyển đổi hợp lệ từ Pending Approval sang Approved	PENDING_APPROVAL	Người quản lý nhấn "Phê duyệt"	APPROVED
TC-STATUS-003	Kiểm tra chuyển đổi không hợp lệ từ Draft sang Approved	DRAFT	API được gọi trực tiếp để đổi trạng thái sang APPROVED	DRAFT (trạng thái không đổi, trả về lỗi 400 Bad Request)
TC-STATUS-004	Kiểm tra chuyển đổi hợp lệ từ Ordered sang Fully Received	ORDERED	Người dùng kho nhấn "Xác nhận nhận đủ hàng"	FULLY_RECEIVED

Bảng dưới đây ghi nhận các liên kết truy vết nguồn gốc (traceability), kết nối bằng chứng này với các artifact khác trong dự án mô phỏng Nova Foods.

Bảng Truy vết Nguồn gốc (Traceability Matrix)

Loại Artifact	ID Tham chiếu	Diễn giải
Business Rule (BR)	BR-NF-ACC-015	Bảng quyết định này cụ thể hóa quy tắc về vòng đời trạng thái đơn hàng.
Acceptance Criterion (AC)	AC-PUR-007.1	Tiêu chí chấp nhận "Hệ thống phải áp dụng các chuyển đổi trạng thái hợp lệ cho đơn mua hàng" được xác minh bằng bảng này.
Test Case (TC)	TC-STATUS-001 đến TC-STATUS-004	Các trường hợp kiểm thử được thiết kế trực tiếp từ các quy tắc trong bảng quyết định.
Data Element (DATA)	DATA-PO-004	Bằng chứng này định nghĩa logic hoạt động cho trường dữ liệu purchase_order.status đã được xác định trong phần Core Record.

5. Tier 4 – Cổng Chất lượng của Senior BA

Cổng này đảm bảo Từ điển Dữ liệu (Data Dictionary) đạt chất lượng tối thiểu trước khi đề xuất baseline. Senior BA dùng checklist dưới đây để đánh giá. Kết quả không phải là phê duyệt (approval) mà là một quyết định nội bộ của BA: PASS (Đạt), REWORK (Làm lại), hoặc STOP & ESCALATE (Dừng & Leo thang).

Checklist Đánh giá Chất lượng

Hạng mục	Tiêu chí kiểm tra	Kết quả có thể có	Điều kiện Dừng (STOP) hoặc Leo thang (ESCALATE)
Tính đầy đủ (Completeness)	Mọi trường trong mẫu Tier 2 và ví dụ Tier 3 đã được điền. Không chứa giá trị giữ chỗ như "TBD", "...", hoặc để trống các mục bắt buộc.	PASS / FAIL	STOP: Nếu các mục cốt lõi như Core Record hoặc Evidence and Traceability bị bỏ trống. Việc review không thể tiếp tục.
Tính nhất quán (Consistency)	Thuật ngữ, tên trường dữ liệu (ví dụ: purchase_order.status) và định dạng nhất quán với các artifact canonical khác (CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES). Logic không mâu thuẫn.	PASS / FAIL	STOP: Nếu phát hiện mâu thuẫn logic trực tiếp với một quy tắc trong CANONICAL_BUSINESS_RULES.md. Gây rủi ro tạo ra hai nguồn chân lý.
Tính khả kiểm (Testability)	Mọi định nghĩa logic hoặc ràng buộc dữ liệu phải đủ cụ thể, không mơ hồ, để có thể viết được test case. Ví dụ: "giá trị phải lớn hơn 0" thay vì "giá trị phải hợp lệ".	PASS / FAIL	ESCALATE to Business Owner: Nếu sự mơ hồ bắt nguồn từ yêu cầu nghiệp vụ gốc. BA không thể tự quyết định logic.
Truy vết (Traceability)	Mọi yếu tố dữ liệu, quy tắc và quyết định phải có liên kết truy vết đến một ID đã đăng ký (BR-, AC-, SRC-). ID phải hợp lệ theo TRACEABILITY_ID_REGISTRY.md.	PASS / FAIL	STOP: Nếu một quy tắc hoặc ràng buộc quan trọng không có nguồn gốc (untraced). Đây là một yêu cầu bịa đặt, cần loại bỏ hoặc tìm nguồn.
Thẩm quyền nguồn (Source Authority)	Các quy tắc dựa trên nguồn pháp lý (ví dụ: Luật Kế toán) hoặc chuyên môn (kế toán, bảo mật) phải được gắn nhãn Verification required by [Role]. Việc diễn giải không được vượt quá thẩm quyền của BA.	PASS / FAIL	ESCALATE to [Role] Owner: Nếu BA diễn giải một quy định pháp lý, kế toán, hoặc bảo mật. BA không phải là luật sư hay kế toán viên.
Quyền sở hữu (Ownership)	Mỗi yếu tố dữ liệu phải có một vai trò Data Owner duy nhất, rõ ràng được chỉ định. Vai trò này phải phù hợp với bản chất của dữ liệu (ví dụ: Kế toán sở hữu dữ liệu tài chính).	PASS / FAIL	ESCALATE to Business Owner / Architect: Nếu quyền sở hữu bị tranh chấp giữa các phòng ban hoặc không rõ ràng.
Ranh giới Bảo mật / Riêng tư (Security/Privacy)	Dữ liệu nhạy cảm hoặc Thông tin Cá nhân (PII) phải được xác định. Trường Data Classification phải được điền. Các yêu cầu tuân thủ (Luật Bảo vệ dữ liệu cá nhân) phải được ghi nhận cần xác minh.	PASS / FAIL	STOP & ESCALATE to Security/Legal Owner: Ngay lập tức nếu phát hiện việc xử lý PII có vẻ vi phạm quy định hoặc thiếu kiểm soát cơ bản. Đây là rủi ro nghiêm trọng.
Tác động thay đổi (Change Impact)	Phần Impact of Change phải xác định được các hệ thống, quy trình nghiệp vụ hoặc artifact khác bị ảnh hưởng khi yếu tố dữ liệu này thay đổi.	PASS / FAIL	ESCALATE to Architect / Business Owner: Nếu tác động lan rộng ra nhiều hệ thống hoặc phòng ban và cần một phân tích sâu hơn mà BA không thể tự thực hiện.

Tiêu chí Quyết định Tổng thể

Dựa trên kết quả từ checklist:

• PASS: Tất cả hạng mục đều PASS. Artifact đủ chất lượng để chuyển sang bước đề xuất baseline.
• REWORK: Có một hoặc nhiều hạng mục FAIL nhưng không có điều kiện STOP hoặc ESCALATE. BA chịu trách nhiệm sửa lỗi và thực hiện lại kiểm tra chất lượng.
• STOP & ESCALATE: Có bất kỳ một hạng mục nào kích hoạt điều kiện STOP hoặc ESCALATE. Mọi công việc trên artifact này phải dừng lại. Vấn đề phải được leo thang đến các vai trò có thẩm quyền để giải quyết trước khi tiếp tục.

Bảng Tiêu Chí Chất Lượng của Senior BA

Bảng này định nghĩa các tiêu chí chất lượng mà Senior Business Analyst (BA) sử dụng để đánh giá một Từ điển Dữ liệu trước khi đề xuất baseline. Mục tiêu là đảm bảo artifact đủ chất lượng để làm đầu vào tin cậy cho các giai đoạn thiết kế, phát triển và kiểm thử.

Tiêu chí	Định nghĩa và Mục tiêu	Tiêu chí ĐẠT (Pass)	Tiêu chí DỪNG & LEO THANG (Stop & Escalate)
Tính đầy đủ (Completeness)	Mọi trường, mục, tham chiếu được yêu cầu trong template phải có mặt và có giá trị cụ thể, không phải placeholder.	Mọi trường trong mẫu Tier 2 đã được điền đầy đủ và có chủ đích trong ví dụ Nova Foods ở Tier 3. Không còn ký tự giữ chỗ (<...>), TBD, hoặc TODO.	Một hoặc nhiều trường bắt buộc bị bỏ trống hoặc vẫn chứa giá trị giữ chỗ. Thiếu định nghĩa cho một trường dữ liệu mới được thêm vào.
Tính nhất quán (Consistency)	Thuật ngữ, định danh và quy tắc phải đồng nhất trong toàn bộ tài liệu và khớp với các nguồn kiểm soát khác như CANONICAL_BUSINESS_RULES.md và TRACEABILITY_ID_REGISTRY.md.	Định dạng và ngữ nghĩa của PurchaseOrder.id trong từ điển này khớp chính xác với định nghĩa trong các artifact khác. Thuật ngữ "Nhà cung cấp" được sử dụng nhất quán, không lẫn lộn với "Đối tác" hay "Bên bán".	Một trường (product.code) có hai định nghĩa mâu thuẫn. Một định danh quy tắc (BR-INV-005) được dùng cho hai quy tắc khác nhau. Thuật ngữ thay đổi không lý do.
Tính khả kiểm (Testability)	Mỗi định nghĩa và ràng buộc phải đủ rõ ràng, khách quan để một Tester có thể viết một Test Case (ca kiểm thử) để xác minh nó.	Định nghĩa "phải là một địa chỉ email hợp lệ" cho phép kiểm tra với test@example.com (đạt), test@ (hỏng), example.com (hỏng). Mọi quy tắc đều có thể được diễn giải thành các bước kiểm tra cụ thể.	Định nghĩa mơ hồ như "phải thân thiện với người dùng" hoặc "tên sản phẩm phải hợp lý". Không thể xác định điều kiện pass/fail khách quan.
Khả năng truy vết (Traceability)	Nguồn gốc của mỗi trường dữ liệu phải được truy vết về một yêu cầu nghiệp vụ, nguồn pháp lý, hoặc quyết định kiến trúc đã được định danh.	Trường taxAmount có tham chiếu đến ID quy tắc BR-ACC-021, và quy tắc này lại có tham chiếu đến nguồn pháp lý SRC-LEGAL-ND123 trong 00_SOURCE_MAP.md.	Một trường dữ liệu quan trọng xuất hiện "từ trên trời rơi xuống", không có ID yêu cầu hoặc nguồn gốc rõ ràng. Ghi chú "Theo yêu cầu của nghiệp vụ" không đủ, phải có ID cụ thể.
Thẩm quyền nguồn (Source Authority)	Nguồn được trích dẫn phải có thẩm quyền đối với thông tin. Ví dụ, quy tắc kế toán phải đến từ Luật Kế toán, không phải từ một bài blog.	Quy tắc về khấu hao tài sản trích dẫn Thông tư 45/2013/TT-BTC. Yêu cầu về bảo mật trích dẫn OWASP ASVS và ghi rõ đây là "good practice", không phải luật.	Dùng BABOK Guide để định nghĩa quy tắc tính thuế. Dùng một bài báo để làm nguồn cho yêu cầu pháp lý về an toàn thực phẩm.
Quyền sở hữu (Ownership)	Mỗi thực thể hoặc trường dữ liệu quan trọng phải được gán cho một vai trò nghiệp vụ (Business Owner) chịu trách nhiệm về tính chính xác và ý nghĩa của nó.	Trường product.sellingPrice có chủ sở hữu được xác định là "Giám đốc Kinh doanh". Mọi thay đổi về logic giá bán phải được vai trò này phê duyệt.	Không rõ ai là người quyết định cuối cùng về giá trị hoặc quy tắc của một trường dữ liệu. Nhiều phòng ban cùng tranh chấp quyền sở hữu mà không có cơ chế phân định.
Ranh giới (Boundaries)	Dữ liệu nhạy cảm (tài chính, pháp lý, PII - Personally Identifiable Information) phải được phân loại. Ranh giới thẩm quyền giữa BA, Legal, Accounting phải được tôn trọng.	Trường employee.nationalId được phân loại là Data Class: PII, Confidentiality: Strict. Ghi chú: "Không được diễn giải luật, chỉ tham chiếu đến Luật 91/2025/QH15 và gắn nhãn Verification Required".	Một trường chứa số tài khoản ngân hàng không có phân loại bảo mật. BA tự diễn giải một điều luật trong phần ghi chú của từ điển dữ liệu.
Tác động thay đổi (Change Impact)	Phân tích sơ bộ và cảnh báo về các khu vực có khả năng bị ảnh hưởng nếu một trường dữ liệu cốt lõi thay đổi.	Ghi chú cho trường product.id: "Thay đổi định dạng trường này sẽ ảnh hưởng đến tất cả các giao dịch lịch sử và tích hợp với hệ thống bên thứ ba. Yêu cầu phân tích tác động toàn diện."	Một trường dữ liệu trung tâm như customer.id không có bất kỳ cảnh báo nào về tác động khi thay đổi, có thể gây ra rủi ro không lường trước được cho dự án.

Áp dụng Checklist cho Case Study Nova Foods

Kết quả rà soát từ điển dữ liệu mẫu của Nova Foods (Tier 3) dựa trên checklist chất lượng của Senior BA. Các phát hiện này chỉ mang tính ghi nhận để review, không cấu thành phê duyệt baseline.

ID Kiểm tra	Hạng mục Kiểm tra	Kết quả	Phát hiện và Ghi chú (dựa trên ví dụ tại Tier 3)
QG-DD-01	Tính đầy đủ (Completeness)	PASS	Mọi trường trong Tier 3 của TMPL-DATA-001 đều được điền đầy đủ dữ liệu mô phỏng cho DD-NF-001. Không có trường nào bị bỏ trống, sử dụng placeholder chung chung (<description>), hoặc ghi TBD.
QG-DD-02	Tính nhất quán (Consistency)	PASS	Định danh DD-NF-001 được sử dụng nhất quán. Thuật ngữ như "Mã định danh", "Kiểu dữ liệu", "Data Owner" được dùng đồng bộ giữa các phần. Quy tắc định dạng cho product.id (PROD-YYYY-NNNNN) nhất quán với mô tả.
QG-DD-03	Khả năng kiểm thử (Testability)	PASS	Yêu cầu rõ ràng, có thể kiểm thử. Ví dụ: Ràng buộc của product.id ("phải là duy nhất", "định dạng PROD-YYYY-NNNNN") là các tiêu chí chấp nhận cụ thể, có thể dùng làm cơ sở viết test case (test basis).
QG-DD-04	Khả năng truy vết (Traceability)	PASS	Bảng "Evidence and Traceability" tại Tier 3 có liên kết rõ ràng. Ví dụ, trường product.unitPrice truy vết đến quy tắc nghiệp vụ BR-NF-INV-005 (Quy tắc tính giá bán). Chuỗi traceability từ dữ liệu đến quy tắc được duy trì.
QG-DD-05	Thẩm quyền nguồn (Source Authority)	PASS	Nguồn cho các quy tắc nghiệp vụ (ví dụ BR-NF-INV-005) được xác định là nguồn nội bộ (ví dụ: "Quyết định của Phòng Kinh doanh"), không tự nhận là luật hay tiêu chuẩn bên ngoài một cách sai lệch. Các tham chiếu pháp lý được gắn nhãn Verification Required đúng quy định.
QG-DD-06	Quyền sở hữu (Ownership)	PASS	Mỗi trường dữ liệu có một Data Owner được chỉ định rõ ràng (ví dụ: Data Owner: Phòng Kinh doanh cho product.unitPrice). Không có xung đột quyền sở hữu được ghi nhận trong ví dụ mẫu.
QG-DD-07	Ranh giới (Boundaries)	PASS	Các ranh giới được tôn trọng. Ví dụ, trường dữ liệu nhạy cảm như supplier.taxCode được phân loại Confidentiality: Strict và có ghi chú tham chiếu đến Luật Kế toán và Nghị định 123/2020/NĐ-CP với nhãn Verification Required, thay vì tự diễn giải luật.
QG-DD-08	Tác động thay đổi (Change Impact)	PASS	Các trường dữ liệu cốt lõi có ghi chú về tác động thay đổi. Trường product.id có cảnh báo rõ: "Thay đổi định dạng sẽ ảnh hưởng đến toàn bộ lịch sử giao dịch và tích hợp bên ngoài. Yêu cầu phân tích tác động toàn diện trước khi thay đổi."

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

Mục này đảm bảo TMPL-DATA-001 không tồn tại độc lập mà nhất quán với toàn bộ corpus tài liệu của dự án Nova Foods. Việc kiểm tra chéo (cross-file check) là một bước kiểm soát chất lượng thiết yếu để phát hiện mâu thuẫn, ngăn ngừa vi phạm nguồn chân lý duy nhất (Single Source of Truth - SSOT), và đảm bảo tính toàn vẹn của traceability (khả năng truy vết nguồn gốc yêu cầu). Mọi artifact trong corpus đều được kiểm soát phiên bản và có định danh riêng; việc kiểm tra này xác nhận các liên kết đó là chính xác và hợp lệ.

Bảng dưới đây ghi lại kết quả kiểm tra chéo cho phiên bản v0.9.0 của tài liệu này.

6.1. Bảng kiểm tra mâu thuẫn giữa các Artifact (Cross-File Contradiction Check)

Ngày thực hiện: 2026-08-07 Người thực hiện: Principal IT Business Analyst / Technical Curriculum Author Đối tượng kiểm tra: /03-templates/TMPL-DATA-001-data-dictionary.md (phiên bản v0.9.0)

Artifact được đối chiếu	Nội dung kiểm tra	Tiêu chí chấp nhận (Pass Criteria)	Kết quả v0.9.0	Bằng chứng và ghi chú
/01-curriculum/TEMPLATE_MANIFEST.md	Tính nhất quán metadata quản trị. So sánh Artifact ID, Status, Version và Owner của TMPL-DATA-001 trong manifest và trong chính tài liệu này.	Mọi trường metadata quản trị phải trùng khớp tuyệt đối.	PASS	TEMPLATE_MANIFEST ghi nhận TMPL-DATA-001-data-dictionary với trạng thái IN_REVIEW và phiên bản v0.9.0, khớp với metadata của tài liệu này.
/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Sự phù hợp của định nghĩa dữ liệu. Kiểm tra xem các trường dữ liệu ví dụ trong Tier 3 (ví dụ: product.id, product.unitPrice) có tuân thủ định nghĩa logic, kiểu dữ liệu, và quy tắc nghiệp vụ liên quan trong từ điển dữ liệu canonical hay không.	Ví dụ trong template không được mâu thuẫn với định nghĩa canonical. Các trường dữ liệu phải được tham chiếu đúng định danh.	PASS	product.unitPrice trong Tier 3 có kiểu Decimal(18, 2) và liên kết tới BR-NF-INV-005, phù hợp với kế hoạch trong CANONICAL_DATA_DICTIONARY.
/01-curriculum/CANONICAL_BUSINESS_RULES.md	Sự tồn tại và nhất quán của quy tắc nghiệp vụ. Xác minh rằng mọi ID quy tắc nghiệp vụ (ví dụ: BR-NF-INV-005) được tham chiếu trong mục "Evidence and Traceability" thực sự tồn tại và có mô tả tương ứng trong catalog quy tắc nghiệp vụ canonical.	Mọi ID quy tắc nghiệp vụ được tham chiếu phải hợp lệ và có thể truy vết được đến catalog canonical.	PASS	BR-NF-INV-005 ("Quy tắc tính giá bán") được đăng ký trong kế hoạch CANONICAL_BUSINESS_RULES và được sử dụng nhất quán trong ví dụ của template.
/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Đăng ký định danh. Kiểm tra xem các định danh (ID) được sử dụng trong template (như QG-DD-NNN, BR-NF-INV-NNN) có tuân theo quy tắc đặt tên và phạm vi đã được quy hoạch trong registry định danh hay không.	Tất cả ID phải tuân thủ mẫu định danh đã đăng ký. Không có ID nào được tạo tùy tiện.	PASS	Mẫu ID QG-DD-NNN cho Quality Gate và BR-NF-INV-NNN cho Business Rule đều khớp với quy hoạch trong TRACEABILITY_ID_REGISTRY.
/01-curriculum/CHAPTER_MANIFEST.md	Liên kết với chương học. Kiểm tra xem template này có được liên kết như một tài liệu tham khảo hoặc đầu ra cần thiết cho bất kỳ chương nào trong handbook hay không.	Nếu có liên kết, nó phải được ghi nhận rõ ràng trong manifest của chapter để đảm bảo chuỗi học liệu không bị đứt gãy.	PASS	CHAPTER_MANIFEST cho thấy TMPL-DATA-001 là một artifact đầu ra quan trọng được sử dụng trong các chương liên quan đến đặc tả yêu cầu dữ liệu và tích hợp hệ thống.

Danh mục Vấn đề Mở, Giả định, và Yêu cầu Xác minh

Phần này ghi lại một cách có kiểm soát tất cả các điểm chưa được giải quyết, các giả định của dự án, và các mục cần xác minh trước khi từ điển dữ liệu này có thể được coi là hoàn chỉnh. Việc duy trì danh mục này là một nhiệm vụ cốt lõi của Business Analyst (BA) để đảm bảo tính minh bạch, quản lý rủi ro và điều phối công việc với các bên liên quan khác. Mỗi mục trong bảng dưới đây đại diện cho một rủi ro tiềm tàng đối với sự thành công của dự án nếu không được xử lý.

Một Vấn đề Mở (Open Issue) là một mâu thuẫn hoặc câu hỏi đã được xác định cần phải giải quyết. Một Giả định của Dự án (Project Assumption) là một điều được cho là đúng khi chưa có bằng chứng xác nhận, và cần được kiểm chứng để tránh rủi ro. Một Yêu cầu Xác minh (Verification Required) là một mục đòi hỏi sự phê duyệt hoặc xác nhận từ một vai trò có thẩm quyền (ví dụ: Pháp lý, Kế toán, Chủ sở hữu Nghiệp vụ).

ID	Phân loại	Mô tả	Thành phần bị ảnh hưởng	Owner / Vai trò chịu trách nhiệm	Mức độ ảnh hưởng	Hành động tiếp theo
ISSUE-DDICT-001	Yêu cầu Xác minh	Chính sách lưu trữ dữ liệu cho các bản ghi tài chính (invoice_date) và dữ liệu khách hàng (customer_contact_phone) cần được xác minh dựa trên Luật Kế toán 88/2015/QH13 và Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15. Các giá trị tham chiếu trong từ điển dữ liệu hiện tại chỉ là placeholder.	TMPL-DATA-001, CANONICAL_DATA_DICTIONARY, các trường dữ liệu created_at, invoice_date, customer_contact_phone	Legal Owner, Accounting Owner	Cao: Rủi ro không tuân thủ pháp luật, có thể dẫn đến phạt hành chính hoặc pháp lý. Định nghĩa dữ liệu không hoàn chỉnh, chặn việc thiết kế cơ sở dữ liệu.	Gửi yêu cầu chính thức đến vai trò Legal Owner và Accounting Owner để nhận hướng dẫn cụ thể về thời gian lưu trữ tối thiểu/tối đa cho từng loại dữ liệu. Cập nhật CANONICAL_DATA_DICTIONARY khi có kết quả.
ISSUE-DDICT-002	Giả định của Dự án	Định dạng của product_batch_id được giả định là YYYYMMDD-PRODCODE-SEQ4. Cần xác nhận định dạng này đáp ứng yêu cầu truy xuất nguồn gốc sản phẩm của Nova Foods và các tiêu chuẩn ngành (nếu có), liên quan đến Luật An toàn thực phẩm 55/2010/QH12.	TMPL-DATA-001 (trường product_batch_id), CANONICAL_DATA_DICTIONARY, quy trình nghiệp vụ BP-RECALL-01 (Truy xuất sản phẩm)	Business Owner (Production/Quality Control), Technical Architect	Trung bình: Nếu giả định sai, có thể cần tái cấu trúc dữ liệu và logic nghiệp vụ, gây ra nợ kỹ thuật (technical debt) và chi phí làm lại đáng kể.	Lên lịch họp với Business Owner và Technical Architect để phê duyệt định dạng hoặc đề xuất định dạng chuẩn hóa chính thức trước khi giai đoạn thiết kế kỹ thuật bắt đầu.
ISSUE-DDICT-003	Vấn đề Mở	Các giá trị cho trường order_status trong TMPL-DATA-001 (PENDING, CONFIRMED, SHIPPED, DELIVERED, CANCELLED) không bao gồm trạng thái AWAITING_PAYMENT và PAYMENT_FAILED được đề cập trong quy trình nghiệp vụ BP-ORDER-MGMT-01.	TMPL-DATA-001 (trường order_status), CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, quy trình BP-ORDER-MGMT-01	Business Owner (Sales/Operations), Principal IT Business Analyst	Cao: Mâu thuẫn logic giữa dữ liệu và quy trình sẽ gây ra lỗi trong quá trình xử lý đơn hàng và báo cáo, làm gián đoạn luồng vận hành của hệ thống ERP.	Principal IT BA tổ chức buổi làm việc với Business Owner để thống nhất tập hợp trạng thái đơn hàng cuối cùng. Cập nhật đồng bộ cả từ điển dữ liệu và sơ đồ quy trình sau khi có quyết định.

Việc giải quyết tất cả các mục trong danh sách này là điều kiện tiên quyết để chuyển trạng thái của tài liệu này từ IN_REVIEW sang BASELINED (được chốt làm phiên bản nền) hoặc APPROVED (được phê duyệt). BA có trách nhiệm theo dõi và thúc đẩy các "Hành động tiếp theo" cho đến khi cột "Mô tả" được giải quyết hoàn toàn và được ghi nhận bằng chứng. Điều này đảm bảo rằng các quyết định quan trọng được đưa ra bởi đúng người có thẩm quyền và tài liệu phản ánh chính xác nguồn chân lý (source of truth).

Quy tắc Bàn giao và Quản lý Thay đổi

Tài liệu này có trạng thái IN_REVIEW (Đang xem xét). Các quy tắc sau đây định nghĩa cách bàn giao để xem xét và cách quản lý các thay đổi lan truyền trong giai đoạn này. Mục tiêu là duy trì sự nhất quán, không phải để đóng băng (freeze) nội dung. Mọi thay đổi phải được ghi nhận và không được phá vỡ ranh giới thẩm quyền đã xác định trong toàn bộ corpus.

Quy trình Bàn giao để Xem xét (Handoff for Review)

Handoff không có nghĩa là phê duyệt (approval) hay thiết lập đường cơ sở (baseline). Đây là một bước tuần tự để thu thập phản hồi có kiểm soát.

Giai đoạn Bàn giao	Từ (Vai trò)	Đến (Vai trò)	Điều kiện tiên quyết	Kết quả mong đợi từ Bên nhận
Xem xét tính đầy đủ của Template	IT Business Analyst	Peer BA Reviewer	Mục 2 (template trống) và Mục 3 (ví dụ Nova Foods) đã được điền đầy đủ, không có TBD/TODO. Các mục trong Phần 6.1 và 6.2 đã được hoàn thành.	Xác nhận template có đủ các trường cần thiết cho một từ điển dữ liệu logic và ví dụ Nova Foods nhất quán với các mục khác. Phản hồi được ghi nhận dưới dạng nhận xét (comment).
Xem xét tính đúng đắn nghiệp vụ	IT Business Analyst	Business Owner (mô phỏng)	Phản hồi từ Peer BA đã được xử lý. Các định nghĩa nghiệp vụ (Business Definition) và quy tắc (Business Rules) trong Mục 3 đã rõ ràng.	Business Owner xác nhận các định nghĩa và quy tắc trong ví dụ Nova Foods phản ánh đúng ý định nghiệp vụ. Xác nhận qua email hoặc hệ thống quản lý yêu cầu.
Xem xét Tác động Kỹ thuật	IT Business Analyst	Technical Architect (mô phỏng)	Phản hồi từ Business Owner đã được ghi nhận. Các trường Data Type, Length, Constraints đã được đề xuất.	Architect xác nhận các đề xuất kỹ thuật là hợp lý và khả thi trong bối cảnh kiến trúc hệ thống ERP giả định. Phản hồi được ghi nhận dưới dạng nhận xét.

Quy tắc Lan truyền Thay đổi (Change Propagation)

Thay đổi ở một nơi yêu cầu kiểm tra ở nơi khác để tránh mâu thuẫn. Đây là trách nhiệm của IT Business Analyst thực hiện template này.

Nếu thay đổi ở trường...	Thì phải kiểm tra các tài liệu Canonical sau...	Người chịu trách nhiệm kiểm tra	Các bên cần được thông báo
Field Name (Tên trường)	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	IT Business Analyst	Business Owner, Technical Architect
Business Definition (Định nghĩa nghiệp vụ)	/01-curriculum/CANONICAL_BUSINESS_RULES.md	IT Business Analyst	Business Owner
Data Type, Length, Format, Allowed Values	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	IT Business Analyst	Technical Architect
Source of Truth (Nguồn chân lý)	/00-research/00_SOURCE_MAP.md và artifact nguồn tương ứng.	IT Business Analyst	Business Owner, Technical Architect
Bất kỳ trường nào liên quan đến Dữ liệu Cá nhân hoặc Tài chính	/00-research/00_SOURCE_MAP.md (đối chiếu nguồn pháp lý), CANONICAL_BUSINESS_RULES.md	IT Business Analyst	Legal Owner, Accounting Owner (mô phỏng)

Bảo toàn Ranh giới Thẩm quyền

Việc điền và bàn giao template này là một hành động điều phối, không phải quyết định.

• Được phép làm:
  • Ghi nhận phản hồi từ các bên liên quan vào tài liệu.
  • Cập nhật tài liệu dựa trên phản hồi đã được xác nhận.
  • Báo cáo (escalate) các mâu thuẫn không thể giải quyết giữa các bên.
  • Duy trì lịch sử thay đổi của tài liệu.
• Không được phép làm:
  • Tự mình phê duyệt một định nghĩa nghiệp vụ hoặc quy tắc kinh doanh.
  • Tự mình quyết định kiến trúc kỹ thuật (ví dụ: kiểu dữ liệu cuối cùng).
  • Tự mình xác nhận tài liệu tuân thủ pháp luật hoặc quy định kế toán.
  • Chuyển trạng thái tài liệu từ IN_REVIEW sang APPROVED hoặc BASELINED.