Tmpl Wf 001 Workflow Map Bpmn

Trường kiểm soát	Giá trị
Artifact ID	TMPL-WF-001
Tên tệp được kiểm soát	/03-templates/TMPL-WF-001-workflow-map-bpmn.md
Tiêu đề artifact	Tmpl Wf 001 Workflow Map Bpmn
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Phân loại artifact	Controlled four-tier template: mẫu có kiểm soát gồm bốn tầng nội dung học và áp dụng.
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.
Baseline reference	Chưa có baseline reference tại v0.9.0.
Approval reference	Chưa có approval reference tại v0.9.0.
Nguồn ký pháp BPMN	OMG BPMN 2.0.2: https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/
Phân loại nguồn BPMN	Nguồn chuẩn quy phạm cho ký pháp BPMN thực tế. Không dùng PlantUML activity diagram, flowchart, UML activity diagram hoặc sơ đồ tự vẽ để tuyên bố là BPMN.
Ranh giới nguồn BA	BABOK Guide Version 3 dùng cho thuật ngữ và thực hành BA: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Ngày truy cập nguồn	2026-08-07 cho mọi URL ghi trong metadata này.

IN_REVIEW nghĩa là artifact đang được xem xét có kiểm soát. Trạng thái này cho phép ghi nhận thay đổi có truy vết, không nghĩa là APPROVED, BASELINED, production-ready, compliant, hoặc đã được người dùng chấp thuận. Bằng chứng là metadata không có baseline reference và approval reference; vì vậy không được suy diễn phê duyệt từ Owner, version, ngày cập nhật, hoặc sự tồn tại của tệp.

Owner duy trì đúng TMPL-WF-001, tên tệp, status, version, lịch sử thay đổi và ranh giới nguồn. Owner không có quyền tự xác nhận quy trình Nova Foods, phê duyệt BPMN, thiết lập baseline, diễn giải pháp luật, quyết định kế toán, xác nhận bảo mật, hoặc cho phép triển khai production. Mọi kết luận thuộc Business Owner, Process Owner, Architect, Security, Legal, Accounting, Compliance hoặc QA phải giữ đúng vai trò thẩm quyền.

Version	Ngày	Người ghi nhận	Thay đổi	Trạng thái kiểm soát
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho /03-templates/TMPL-WF-001-workflow-map-bpmn.md; thiết lập ranh giới mô phỏng, nguồn BPMN và trạng thái xem xét.	IN_REVIEW; chưa baseline; chưa có approval reference.

Ranh giới dữ liệu áp dụng tuyệt đối: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi tên người, tổ chức, mã quy trình, vai trò, thời điểm, số lượng, giá trị VND, dữ liệu đơn hàng, tồn kho, sản xuất, chất lượng, tài chính và ngoại lệ xuất hiện trong artifact phải là dữ liệu tổng hợp. Dữ liệu này minh họa cách lập workflow map, không chứng minh ERP thật, cấu hình thật, quy trình vận hành thật, nghĩa vụ pháp lý, tuân thủ, hay quyết định của doanh nghiệp có thật.

1. Tier 1 ? Metadata, Purpose, and Governance

Metadata quản trị	Giá trị
Định danh canonical	TMPL-WF-001
Tên tệp canonical	/03-templates/TMPL-WF-001-workflow-map-bpmn.md
Phiên bản	v0.9.0
Trạng thái	IN_REVIEW
Ngày kiểm soát	2026-08-07
Ngôn ngữ	vi-VN
Múi giờ	Asia/Ho_Chi_Minh
Đơn vị tiền tệ mô phỏng	VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Ranh giới dữ liệu	Case study giáo dục mô phỏng; dữ liệu tổng hợp, không phải dữ liệu production.

Phiên bản v0.9.0 kiểm soát nội dung artifact này khi đang IN_REVIEW. Owner phải tăng hoặc cập nhật version trong change history khi thay đổi ảnh hưởng cấu trúc template, định danh, traceability, cách dùng BPMN, chapter mapping hoặc ranh giới nguồn. IN_REVIEW không phải BASELINED hay APPROVED; version không tạo approval, xác nhận quy trình thật hoặc quyền dùng cho production.

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

Template Workflow Map BPMN dùng để mô tả luồng công việc liên phòng ban bằng BPMN (Business Process Model and Notation, ký pháp mô hình hóa quy trình nghiệp vụ). Mục tiêu là biến mô tả nghiệp vụ thành bản đồ kiểm tra được: ai thực hiện, việc bắt đầu và kết thúc ở đâu, quyết định nào đổi nhánh, dữ liệu hay chứng từ nào đi qua, và ngoại lệ nào phải xử lý. BPMN chỉ dùng khi ký pháp thực tế tuân theo BPMN 2.0.2 của OMG; sơ đồ activity tự vẽ không được gọi là BPMN. Lý do: tên gọi sai làm người đọc suy luận sai về gateway, event, message flow và trách nhiệm.

Nội dung	Quy định áp dụng
Khi dùng	Có quy trình Nova Foods mô phỏng chạy qua từ hai vai trò, có điểm quyết định, ngoại lệ, handoff, hệ thống hoặc bằng chứng cần truy vết. Ví dụ: nhận đơn bán hàng, phê duyệt mua hàng, tiếp nhận nguyên liệu, xử lý khiếu nại.
Khi không dùng	Không dùng cho một business rule độc lập, cấu trúc trường dữ liệu, mockup màn hình, API contract, test case chi tiết, thiết kế kỹ thuật, hướng dẫn thao tác một bước hoặc quyết định pháp lý/kế toán. Dùng artifact chuyên biệt vì BPMN không thay thế rule catalog, data dictionary, API specification hay legal review.
Owner	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc template, tính nhất quán ID, version, traceability và ranh giới mô phỏng. Owner không được tự xác nhận quy trình là đúng cho vận hành Nova Foods thực, không baseline, không ghi nhận approval, không quyết định kiến trúc, pháp lý, kế toán, thuế, bảo mật hay production.
Người dùng	Business Analyst soạn và phân tích; Business Owner kiểm tra ý nghĩa nghiệp vụ; SME vận hành kiểm tra bước thực hiện; Solution Architect kiểm tra điểm tích hợp; QA dùng làm test basis cấp quy trình; Security, Legal, Accounting hoặc Compliance xem xét phần thuộc thẩm quyền. Việc xem không tạo approval.
Điều kiện đầu vào	Phải có phạm vi quy trình, trigger, kết quả mong đợi, vai trò/lane, nguồn sự thật của business rule, dữ liệu hoặc chứng từ liên quan, ngoại lệ biết được và ID canonical đã đăng ký. Thiếu một đầu vào làm sơ đồ dễ biến giả định thành fact; ghi Project assumption hoặc Verification required, rồi escalation.
Artifact đầu ra	Workflow map BPMN đã kiểm soát; liên kết tới requirement, business rule, data element, exception, acceptance criteria, test scenario và decision log khi các artifact đó tồn tại. Template không tự tạo hay thay thế các artifact kia.

Nova Foods Trading & Manufacturing là case study giáo dục mô phỏng; toàn bộ tên quy trình, vai trò, dữ liệu, số tiền VND, hệ thống và tình huống chỉ là dữ liệu tổng hợp. Không dùng template này để chứng minh cấu hình ERP, tuân thủ pháp luật, năng lực truy xuất thực phẩm, quyết định kế toán, hoặc quy trình production. Khi luồng chạm dữ liệu cá nhân, hóa đơn/chứng từ, kế toán, thuế, an toàn thực phẩm hay bảo mật, nội dung phải giữ nhãn Verification required; lý do là nguồn corpus chỉ cung cấp ranh giới tham chiếu, không thay thế xác minh hiện hành bởi chủ sở hữu chuyên môn.

Thẩm quyền và escalation	Quy tắc
BA/Owner được làm	Ghi nhận luồng, giả định, câu hỏi, liên kết traceability, xung đột và version.
Business Owner hoặc SME vận hành	Xác nhận mục tiêu nghiệp vụ, vai trò, thứ tự công việc, ngoại lệ vận hành và tiêu chí kết quả của quy trình mô phỏng.
Solution Architect	Xem xét system boundary, tích hợp, message flow, quyền hệ thống và tính khả thi kỹ thuật.
QA	Xem xét khả năng kiểm thử của nhánh, ngoại lệ, điều kiện kết thúc và bằng chứng đầu ra.
Legal, Accounting, Security, Compliance	Xem xét nội dung có hàm ý pháp lý, kế toán, bảo mật, dữ liệu cá nhân, hóa đơn hoặc an toàn thực phẩm.
Bắt buộc escalation	Escalation khi thiếu Business Owner/SME cho bước quyết định; rule không có nguồn canonical; hai artifact mâu thuẫn; BPMN yêu cầu chọn kiến trúc; hoặc nội dung có thể bị hiểu là nghĩa vụ pháp lý, kế toán hay production. BA đóng gói vấn đề, giữ ID và bằng chứng; không tự chọn thay vai trò có thẩm quyền.

Liên kết Manifest, Định danh Canonical, Chapter, Nguồn và Kiểm soát Thay đổi

TMPL-WF-001 là định danh canonical của template này; tên tệp canonical là /03-templates/TMPL-WF-001-workflow-map-bpmn.md. Cơ sở: mã và đường dẫn được nêu trong yêu cầu micro-batch. Không đổi mã, đổi viết hoa/thường, dịch mã, hoặc tạo mã thay thế; liên kết khác phải giữ nguyên cả hai giá trị để truy vết không đứt.

Hạng mục liên kết	Giá trị canonical	Cơ sở và quy tắc dùng
Manifest template	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md là nguồn kiểm soát danh mục template. Template phải tuân thủ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND, và ranh giới dữ liệu tổng hợp.
Manifest chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md là nguồn kiểm soát 26 handbook chapter. Chỉ liên kết chapter đã đăng ký trong manifest; không tự gán số chapter vì đầu vào hiện tại không cung cấp entry chapter cho TMPL-WF-001.
Registry định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md kiểm soát ID truy vết. ID mới cho quy trình, yêu cầu, rule, dữ liệu, test hoặc bằng chứng chỉ dùng khi registry đã đăng ký.
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md là nguồn canonical cho business rule. Workflow map tham chiếu rule ID đã có; không biến quyết định trong sơ đồ thành rule canonical mới.
Dữ liệu logic	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn canonical cho khái niệm dữ liệu. Tên dữ liệu trên BPMN phải truy vết về dictionary; không suy diễn schema ERP hoặc field production.
Bản đồ nguồn	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md phân loại nguồn và ranh giới dùng nguồn. Nguồn không nằm trong phạm vi đã xác minh không được nâng thành căn cứ chuẩn mực.

BPMN, viết tắt của Business Process Model and Notation — ký pháp mô hình hóa quy trình nghiệp vụ — dùng nguồn chuẩn OMG BPMN 2.0.2: https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/. Nguồn này chỉ xác thực ký pháp BPMN. Nó không xác thực quy trình, vai trò, rule, cấu hình ERP, kiểm soát pháp lý, hay vận hành của Nova Foods.

Loại nguồn	Nguồn	Phân loại dùng trong template
Chuẩn ký pháp	OMG BPMN 2.0.2	Nguồn chuẩn cho event, activity, gateway, pool, lane, sequence flow và message flow. Không gọi PlantUML activity diagram là BPMN.
Kiến thức BA	BABOK Guide Version 3	Nguồn tham khảo thuật ngữ và thực hành BA: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/. Không bịa số trang hoặc điều khoản.
Yêu cầu hệ thống	ISO/IEC/IEEE 29148:2018	Nguồn tham khảo trạng thái và khái niệm requirements: https://www.iso.org/standard/72089.html. Điều khoản chính xác cần kiểm tra văn bản được cấp phép.
Pháp lý Việt Nam	Nguồn chính thức trong 00_SOURCE_MAP	Chỉ dùng làm bối cảnh cần xác minh. Mọi diễn giải về dữ liệu cá nhân, kế toán, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc phải gắn Verification required và chuyển đúng Legal, Accounting, Compliance hoặc domain owner.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục. Mọi pool, lane, vai trò, đơn hàng, số tiền VND, dữ liệu, ngoại lệ và liên kết trong Tier 3 là dữ liệu tổng hợp. Suy luận kiểm soát: TEMPLATE_MANIFEST và các artifact upstream đều giới hạn case study là simulated educational case study; vì vậy không được trình bày sơ đồ như bằng chứng quy trình thật, cấu hình ERP thật, tuân thủ, baseline hoặc phê duyệt.

Thay đổi ảnh hưởng TMPL-WF-001, đường dẫn, version, traceability link, cách dùng BPMN, chapter mapping, hoặc ranh giới nguồn phải ghi vào change history của artifact và kiểm tra lại liên kết với TEMPLATE_MANIFEST, CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, và 00_SOURCE_MAP. IN_REVIEW không phải BASELINED hay APPROVED. Owner chỉ duy trì quản trị và truy vết; không tự phê duyệt nội dung, xác nhận rule Nova Foods, diễn giải pháp lý, quyết định kế toán, hoặc cho phép production.

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

Dùng Tier 2 để tạo bản đồ workflow BPMN (Business Process Model and Notation, ký pháp mô hình hóa quy trình nghiệp vụ) mới. Thay toàn bộ nội dung trong dấu ngoặc nhọn bằng dữ liệu của phạm vi đang phân tích. Không dùng Tier 2 làm bằng chứng quy trình thật, quyết định vận hành, baseline, phê duyệt, diễn giải pháp lý hoặc cấu hình production. Nếu chưa có nguồn, ghi <chưa có nguồn; cần xác minh bởi <vai trò có thẩm quyền>>, không suy đoán.

2.1. Thông tin kiểm soát workflow

Trường	Giá trị cần điền	Hướng dẫn điền và kiểm tra
Workflow Map ID	<ID workflow theo registry canonical, ví dụ WF-...>	Bắt buộc. Dùng đúng ID đã đăng ký trong TRACEABILITY_ID_REGISTRY; không tự tạo ID gần giống.
Tên workflow	<động từ + đối tượng + phạm vi, ví dụ Xử lý đơn hàng bán hàng nội địa>	Bắt buộc. Tên mô tả một luồng đầu-cuối, không phải tên màn hình hay tên phòng ban.
Artifact ID	TMPL-WF-001	Giữ nguyên. Không đổi thành ID workflow.
Tên tệp	/03-templates/TMPL-WF-001-workflow-map-bpmn.md	Giữ nguyên đường dẫn canonical.
Status	IN_REVIEW	Chỉ dùng giá trị DRAFT, IN_REVIEW, BASELINED, RETIRED khi governance corpus cho phép. Hiện tại giữ IN_REVIEW.
Version	v0.9.0	Dùng định dạng v<major>.<minor>.<patch>. Không tăng version khi chưa ghi thay đổi kiểm soát.
Ngày cập nhật	2026-08-07	Dùng YYYY-MM-DD, theo Asia/Ho_Chi_Minh.
Locale và tiền tệ	vi-VN / Asia-Ho_Chi_Minh / VND	Giữ bối cảnh Việt Nam. Số tiền mẫu phải là dữ liệu tổng hợp.
Owner soạn thảo	<vai trò chịu trách nhiệm duy trì artifact>	Ghi vai trò, không ghi tên cá nhân hoặc thông tin cá nhân không cần thiết. Owner không đồng nghĩa người phê duyệt.
Mục tiêu nghiệp vụ	<kết quả nghiệp vụ có thể quan sát hoặc đo lường>	Bắt buộc. Nêu kết quả cần đạt, không nêu giải pháp trước.
Điểm bắt đầu	<sự kiện nghiệp vụ kích hoạt workflow>	Bắt buộc. Phải là sự kiện BPMN Start Event, ví dụ nhận yêu cầu hợp lệ.
Điểm kết thúc	<kết quả cuối cùng hoặc trạng thái kết thúc>	Bắt buộc. Nêu mọi kết cục hợp lệ, gồm thành công và kết thúc bị hủy nếu có.
Phạm vi bao gồm	<hoạt động, vai trò, hệ thống, kênh thuộc workflow>	Liệt kê ranh giới trong phạm vi.
Ngoài phạm vi	<hoạt động liên quan nhưng không được mô hình hóa>	Bắt buộc. Ngăn người đọc suy diễn workflow bao phủ toàn bộ ERP.
Giả định	<giả định có nguồn hoặc nhãn Verification required>	Mỗi giả định nêu lý do và nguồn hoặc vai trò cần xác minh.
Phân loại case	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp	Giữ nguyên khi dùng case Nova Foods.

2.2. Mô hình BPMN cần vẽ

Dán hình BPMN 2.0.2 đã xuất hoặc liên kết tệp nguồn tại đây:

<đường dẫn tệp BPMN 2.0.2 hoặc URL nội bộ được kiểm soát>

Mô hình phải dùng ký pháp BPMN của OMG BPMN 2.0.2. Không gọi sơ đồ activity của PlantUML, flowchart tự do, bảng bước xử lý hoặc sơ đồ UML là BPMN. Một pool biểu diễn một participant; lane biểu diễn trách nhiệm trong pool. Sequence Flow chỉ nối Flow Node trong cùng pool. Message Flow chỉ biểu diễn thông điệp giữa các participant khác pool.

Thành phần BPMN	Giá trị cần điền	Hướng dẫn điền và kiểm tra
Pool chính	<tên participant chịu workflow>	Bắt buộc. Dùng tên tổ chức hoặc hệ thống ở mức nghiệp vụ.
Pool ngoài	<tên participant ngoài tổ chức hoặc ngoài phạm vi, nếu có>	Chỉ điền khi có trao đổi thông điệp giữa participant độc lập. Nếu không có, ghi <không áp dụng; không có participant ngoài phạm vi>.
Lane	<vai trò hoặc đơn vị chịu trách nhiệm>	Mỗi lane là trách nhiệm, không phải trạng thái hay tên bước.
Start Event	<ID sự kiện> — <tên sự kiện kích hoạt>	Bắt buộc. Tên phải trả lời “điều gì đã xảy ra?”.
Task	<ID hoạt động> — <động từ + đối tượng>	Mỗi task có một chủ thể chịu trách nhiệm và một kết quả rõ. Tránh tên mơ hồ như “Xử lý”.
Gateway	<ID quyết định> — <câu hỏi có thể trả lời rõ>	Gateway độc quyền dùng khi chỉ một nhánh được chọn; gateway song song dùng khi các nhánh cùng chạy. Không dùng gateway để che quy tắc chưa rõ.
Intermediate Event	<ID sự kiện trung gian> — <loại và điều kiện>	Chỉ dùng khi có chờ, nhận, gửi, lỗi, timeout hoặc sự kiện trung gian thực sự.
End Event	<ID kết thúc> — <kết cục>	Bắt buộc. Mỗi đường đi phải đến End Event hoặc được giải thích bằng boundary event hợp lệ.
Sequence Flow	<ID luồng> — <nguồn> — <đích> — <điều kiện nếu có>	Điều kiện chỉ đặt trên luồng ra từ gateway khi cần chọn nhánh.
Message Flow	<ID thông điệp> — <pool gửi> — <pool nhận> — <nội dung>	Không dùng trong cùng một pool.
Data Object hoặc Data Store	<ID dữ liệu> — <tên dữ liệu> — <mục đích>	Chỉ nêu dữ liệu cần hiểu workflow. Không ghi bí mật, token, mật khẩu hoặc dữ liệu cá nhân thật.
Text Annotation	<ghi chú giới hạn, giả định hoặc Verification required>	Dùng để làm rõ mà không biến ghi chú thành quy tắc đã xác nhận.

2.3. Danh mục phần tử để đối chiếu sơ đồ

ID phần tử	Loại BPMN	Tên hiển thị	Pool/Lane	Đầu vào	Đầu ra	Căn cứ hoặc lý do
<EVT-START-...>	<Start Event>	<tên sự kiện>	<pool/lane>	<điều kiện kích hoạt>	<token workflow bắt đầu>	<nguồn, giả định, hoặc Verification required>
<TSK-...>	<Task hoặc Sub-Process>	<động từ + đối tượng>	<pool/lane>	<dữ liệu hoặc trạng thái vào>	<dữ liệu hoặc trạng thái ra>	<nguồn, giả định, hoặc Verification required>
<GWY-...>	<Exclusive Gateway hoặc Parallel Gateway>	<câu hỏi quyết định>	<pool/lane>	<dữ kiện quyết định>	<nhánh được chọn hoặc nhánh song song>	<nguồn, giả định, hoặc Verification required>
<EVT-END-...>	<End Event>	<kết cục>	<pool/lane>	<trạng thái trước kết thúc>	<workflow kết thúc>	<nguồn, giả định, hoặc Verification required>

Mỗi hàng danh mục phải khớp đúng một phần tử trong sơ đồ. Lý do tồn tại của task, gateway hoặc event phải chỉ được từ đầu vào: nguồn đã xác minh, requirement, business rule canonical, hoặc giả định gắn nhãn cần xác minh. Cầu nối suy luận là: <nguồn hoặc quan sát> xác nhận <điều kiện hoặc nhu cầu>; vì vậy mô hình có <phần tử BPMN tương ứng>.

2.4. Quy tắc điền placeholder và dữ liệu an toàn

Dùng placeholder mô tả đủ nghĩa, ví dụ <vai trò kiểm tra tín dụng>, không dùng <x>, <data> hoặc <điền vào đây>. Tier 2 được phép chứa placeholder; Tier 3 phải thay hết placeholder bằng dữ liệu tổng hợp Nova Foods, kể cả mọi hàng, nhánh, đầu vào, đầu ra và liên kết.

Không ghi mật khẩu, API key, access token, chuỗi kết nối DB, khóa riêng, số định danh cá nhân, tài khoản ngân hàng hoặc dữ liệu thật vào sơ đồ hay bảng. Khi workflow cần tham chiếu bí mật, dùng mẫu:

<secret reference: vault://<vault-name>/<secret-name>; owner: <vai trò>; access: <nhóm quyền>; value: không ghi trong artifact>

Mẫu này chỉ tham chiếu vị trí quản lý bí mật; không chứng minh vault tồn tại, quyền đã cấp, hay kiểm soát bảo mật đã được xác nhận.

Sổ kiểm soát, quyết định, ngoại lệ, bằng chứng và truy vết

Dùng phần này để kiểm soát Workflow Map BPMN (Business Process Model and Notation, ký pháp mô hình hóa quy trình nghiệp vụ) trong phạm vi <tên quy trình>. Mỗi dòng là một đối tượng kiểm tra độc lập. Không gộp nhiều quyết định, ngoại lệ hoặc bằng chứng vào một dòng vì sẽ mất khả năng truy vết. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ nhập dữ liệu tổng hợp.

Trường kiểm soát phiên bản	Giá trị điền	Hướng dẫn và quy tắc kiểm tra
Template ID	TMPL-WF-001	Giữ nguyên ID canonical, không đổi tên hoặc tạo biến thể.
Tên workflow	<tên quy trình nghiệp vụ rõ động từ và đối tượng>	Ví dụ cấu trúc: Xử lý đơn bán hàng. Không dùng tên chung như Quy trình ERP.
BPMN diagram ID	<BPMN-diagram-ID theo registry>	Phải khớp TRACEABILITY_ID_REGISTRY; chưa có ID thì ghi <chưa đăng ký ID; cần kiểm tra registry> và không tự tạo ID canonical.
Phiên bản tài liệu	<vX.Y.Z>	Theo semantic version nội bộ dự án. Không ghi v0.9.0 nếu nội dung đã khác phiên bản kiểm soát.
Trạng thái	<DRAFT hoặc IN_REVIEW hoặc BASELINED hoặc RETIRED>	Chỉ chọn một giá trị. IN_REVIEW không phải phê duyệt hay baseline. Chỉ dùng BASELINED khi artifact kiểm soát có baseline reference.
Ngày cập nhật	<YYYY-MM-DD>	Dùng lịch Gregorian, múi giờ Asia/Ho_Chi_Minh.
Owner	<vai trò chịu trách nhiệm duy trì artifact>	Ghi vai trò, không suy ra quyền phê duyệt.
Phạm vi locale	vi-VN / Asia-Ho_Chi_Minh / VND	Giữ đúng locale corpus nếu workflow thuộc Nova Foods mô phỏng.
Phân loại dữ liệu	<PUBLIC hoặc INTERNAL hoặc CONFIDENTIAL hoặc RESTRICTED>	Chọn theo dữ liệu workflow xử lý. Có dữ liệu cá nhân, tài chính, bí mật xác thực hoặc thông tin đối tác thì cần Security/Legal Owner xác minh.
Nguồn sự thật nghiệp vụ	<artifact ID và đường dẫn canonical>	Phải là nguồn đã có trong corpus. Không dùng ghi chú họp không được kiểm soát làm nguồn duy nhất.
Giả định dự án	<mã giả định hoặc không có>	Mỗi giả định phải nêu tác động và owner xác minh; không biến giả định thành business rule.
Điểm cần xác minh	<mã vấn đề hoặc không có>	Bắt buộc khi rule, pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật chưa được nguồn có thẩm quyền xác nhận.

ID quyết định	Gateway BPMN liên quan	Câu hỏi quyết định	Điều kiện đầu vào kiểm tra	Nhánh hợp lệ	Quy tắc chọn nhánh	Owner quyết định	Nguồn/rule truy vết	Điều kiện dừng
<DEC-ID>	<gateway-ID và loại XOR/OR/AND/event-based>	<câu hỏi có thể trả lời rõ>	<dữ liệu, trạng thái, vai trò hoặc sự kiện cần có>	<nhánh 1>; <nhánh 2>	<điều kiện Boolean hoặc tiêu chí nghiệp vụ không chồng lấp>	<Business Owner hoặc vai trò có thẩm quyền>	<BR-ID, FR-ID, source artifact ID hoặc Verification required>	<điều kiện không đủ dữ liệu, mâu thuẫn rule hoặc vượt thẩm quyền>

Quy tắc quyết định: Gateway XOR chỉ có một nhánh đúng cho mỗi token; điều kiện nhánh phải đầy đủ, không chồng lấp. Gateway AND chỉ dùng khi mọi nhánh cần chạy song song. Gateway OR phải nêu rõ tổ hợp nhánh hợp lệ. Nếu điều kiện cần diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu cá nhân, ghi Verification required và chuyển đúng owner; BPMN không được tự biến diễn giải đó thành kết luận bắt buộc.

ID ngoại lệ	Hoạt động/gateway phát hiện	Sự kiện hoặc điều kiện lỗi	Phân loại	Tác động	Xử lý ngay trong BPMN	Vai trò nhận xử lý	Thời hạn/điều kiện tiếp tục	Bằng chứng cần lưu	Liên kết quyết định/rule
<EXC-ID>	<BPMN-element-ID>	<mô tả điều kiện ngoại lệ kiểm chứng được>	<Validation error hoặc Business exception hoặc Technical failure hoặc Security incident hoặc Compliance review>	<không xử lý được, chờ xử lý, cần hoàn tác, cần escalation>	<error boundary event, message event, retry, compensation, manual review hoặc end event>	<vai trò hoặc queue chịu trách nhiệm>	<SLA mô phỏng hoặc tiêu chí khôi phục>	<EVD-ID hoặc loại log/chứng từ tổng hợp>	<DEC-ID; BR-ID; FR-ID hoặc Verification required>

Quy tắc ngoại lệ: Mỗi ngoại lệ phải xác định điểm phát hiện, đường đi BPMN, người nhận và bằng chứng. Không dùng retry cho lỗi nghiệp vụ cần người quyết định. Không ghi bí mật, token, mật khẩu, khóa API, số tài khoản thật hoặc dữ liệu cá nhân thật trong diagram, bảng, log mẫu hay evidence. Tham chiếu bí mật theo mẫu <secret-reference: hệ-thống/kho-bí-mật/tên-bí-mật>; chỉ ghi tên tham chiếu, không ghi giá trị.

ID bằng chứng	Bằng chứng xác nhận điều gì	Loại bằng chứng	Nơi lưu/đường dẫn tham chiếu an toàn	Người tạo	Thời điểm ghi nhận	Phân loại dữ liệu	Quy tắc toàn vẹn	Liên kết BPMN
<EVD-ID>	<sự kiện, quyết định, phê duyệt, lỗi hoặc trạng thái cần chứng minh>	<system log hoặc audit trail hoặc báo cáo hoặc chứng từ tổng hợp hoặc test result hoặc review record>	<artifact-ID/path hoặc secure-reference>	<vai trò hoặc hệ thống>	<YYYY-MM-DDThh:mm:ss+07:00 hoặc quy tắc tạo tự động>	<PUBLIC/INTERNAL/CONFIDENTIAL/RESTRICTED>	<immutable log, checksum, access control, retention rule hoặc Verification required>	<task-ID, event-ID, gateway-ID hoặc data-object-ID>

ID truy vết	Loại liên kết	Nguồn	Đích trong workflow	Lý do liên kết	Bằng chứng suy luận	Trạng thái xác minh
<TRC-ID>	<derives-from hoặc satisfies hoặc constrained-by hoặc verified-by hoặc realizes>	<SRC-ID, BR-ID, FR-ID, NFR-ID, DQ-ID hoặc artifact canonical>	<BPMN-element-ID hoặc DEC-ID hoặc EXC-ID>	<nguồn yêu cầu hoặc giới hạn gì>	<mô tả ngắn: nguồn nêu X, nên phần tử BPMN thực hiện/kiểm soát X>	<Verified hoặc Assumption hoặc Verification required>

Quy tắc truy vết: Liên kết chỉ hợp lệ khi nguồn và đích đều có ID hoặc đường dẫn canonical. Verified chỉ dùng khi nội dung nguồn được kiểm tra trong ranh giới sử dụng cho phép. Assumption cần owner xác minh. Verification required bắt buộc khi nguồn pháp lý chỉ cung cấp thông tin tổng quan, văn bản có thể cần kiểm tra phiên bản hiện hành, hoặc kết luận thuộc thẩm quyền Legal, Accounting, Security, Compliance hay domain owner.

Dòng lịch sử thay đổi	Phiên bản	Ngày giờ	Người ghi nhận	Loại thay đổi	Phần tử BPMN bị ảnh hưởng	Mô tả thay đổi	Lý do và bằng chứng	Tác động traceability	Trạng thái review
<CHG-ID>	<vX.Y.Z>	<YYYY-MM-DDThh:mm:ss+07:00>	<vai trò hoặc định danh người ghi nhận>	<Created hoặc Updated hoặc Corrected hoặc Withdrawn>	<BPMN-element-ID hoặc toàn diagram>	<mô tả trước/sau đủ kiểm tra>	<TRC-ID, EVD-ID hoặc issue-ID>	<TRC-ID cần thêm/sửa/đóng hoặc không có>	<Not reviewed hoặc In review hoặc Review completed>

ID review/sign-off	Loại kiểm tra	Reviewer hoặc vai trò cần sign-off	Phạm vi kiểm tra	Tiêu chí đạt	Kết quả	Ngày giờ	Evidence	Hành động khi không đạt
<REV-ID>	<BA peer review hoặc BPMN notation review hoặc Business validation hoặc Security review hoặc Legal/Compliance review hoặc QA test-basis review>	<vai trò có thẩm quyền>	<diagram-ID, DEC-ID, EXC-ID, EVD-ID hoặc TRC-ID>	<tiêu chí kiểm tra cụ thể, đo được>	<Pending hoặc Pass hoặc Fail hoặc Not applicable>	<YYYY-MM-DDThh:mm:ss+07:00 hoặc chưa ghi nhận>	<EVD-ID hoặc review-record path>	<sửa, escalation, giữ IN_REVIEW hoặc không áp dụng có lý do>

Quy tắc review và sign-off: Pass xác nhận phạm vi review ghi trong dòng đó, không tự động xác nhận toàn workflow. Chỉ ghi sign-off khi có bằng chứng review record và người ký đúng thẩm quyền. Nếu chưa có, dùng Pending; không điền tên người phê duyệt giả định. Fail phải liên kết ít nhất một <issue-ID> hoặc <CHG-ID> và giữ trạng thái artifact phù hợp với governance.

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

Dùng bảng này khi điền Tier 2. Mỗi placeholder góc nhọn phải được thay bằng dữ liệu cụ thể trước khi chuyển nội dung sang Tier 3. Nova Foods là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp. Lý do: workflow map là bản đồ quy trình, nên mỗi trường phải cho biết ai làm gì, khi nào, theo điều kiện nào và bằng chứng nào xác nhận kết quả.

Trường template	Cách điền	Giá trị hợp lệ hoặc mẫu placeholder	Quy tắc kiểm tra
<workflow_id_canonical>	Điền ID workflow đã đăng ký, không tự tạo biến thể.	<ID workflow canonical từ TRACEABILITY_ID_REGISTRY>	Phải khớp nguyên dạng ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
<workflow_name_vi>	Ghi tên quy trình bằng động từ và đối tượng.	<Động từ + đối tượng nghiệp vụ, ví dụ: Xử lý yêu cầu mua hàng>	Không dùng tên mơ hồ như Quy trình mới hoặc Xử lý dữ liệu.
<business_trigger>	Ghi sự kiện bắt đầu có thể quan sát.	<Sự kiện nghiệp vụ khởi phát>	Phải là sự kiện, không phải giải pháp kỹ thuật hoặc vai trò.
<start_event_type>	Chọn loại start event BPMN. BPMN là Business Process Model and Notation, chuẩn ký pháp mô hình quy trình.	None; Message; Timer; Conditional; Signal; Error	Chỉ chọn một loại cho mỗi start event. Dùng Timer khi khởi phát theo lịch; dùng Message khi nhận thông điệp.
<participant_or_pool>	Ghi tổ chức hoặc hệ thống tham gia.	<Tên đơn vị hoặc hệ thống mô phỏng>	Một pool đại diện một participant. Không đặt vai trò cá nhân làm pool nếu chỉ là bộ phận nội bộ.
<lane_role>	Ghi vai trò chịu trách nhiệm, không ghi tên người.	<Vai trò nghiệp vụ hoặc vai trò hệ thống>	Vai trò phải thực hiện tối thiểu một activity hoặc nhận một event.
<activity_id>	Điền ID hoạt động đã đăng ký.	<ID activity canonical>	Không tái sử dụng ID cho activity khác.
<activity_name>	Ghi động từ chủ động và đối tượng xử lý.	<Động từ + đối tượng>	Phải phân biệt rõ với event: activity tạo hành động; event biểu thị việc đã xảy ra.
<activity_type>	Chọn loại BPMN phù hợp.	User Task; Service Task; Manual Task; Business Rule Task; Send Task; Receive Task; Sub-Process	User Task cần người dùng thao tác hệ thống; Service Task cần dịch vụ tự động; không gọi sơ đồ activity thông thường là BPMN.
<input_data_object>	Ghi dữ liệu đầu vào cần cho activity.	<Tên dữ liệu logic hoặc chứng từ mô phỏng>	Phải có nguồn tạo hoặc nguồn nhận rõ trong workflow.
<output_data_object>	Ghi dữ liệu tạo, cập nhật hoặc phát hành.	<Tên dữ liệu logic hoặc chứng từ mô phỏng>	Phải nêu trạng thái đầu ra nếu activity thay đổi trạng thái.
<gateway_id>	Điền ID gateway canonical.	<ID gateway canonical>	Một gateway phải có ít nhất hai luồng ra hoặc hai luồng vào theo mục đích mô hình.
<gateway_type>	Chọn loại quyết định BPMN.	Exclusive; Inclusive; Parallel; Event-Based	Exclusive khi chỉ một nhánh đúng; Inclusive khi có thể nhiều nhánh đúng; Parallel khi mọi nhánh cùng chạy.
<decision_question>	Viết câu hỏi có thể trả lời bằng dữ liệu.	<Câu hỏi quyết định nghiệp vụ>	Không dùng câu hỏi chủ quan như Có hợp lý không?; phải xác định được tiêu chí đánh giá.
<outgoing_condition>	Ghi điều kiện từng nhánh ra.	<Biểu thức điều kiện nghiệp vụ có nguồn dữ liệu>; Default	Với Exclusive, các điều kiện không được cùng đúng trừ nhánh Default.
<business_rule_reference>	Liên kết quy tắc, không chép lại quy tắc không có nguồn.	<ID rule từ CANONICAL_BUSINESS_RULES>; Verification required	Nếu chưa có rule canonical, ghi Verification required và nêu owner cần xác minh.
<exception_id>	Điền ID ngoại lệ canonical.	<ID exception canonical>	Mỗi ngoại lệ phải gắn activity, event hoặc gateway kích hoạt.
<exception_trigger>	Ghi lỗi hoặc điều kiện bất thường quan sát được.	<Lỗi hệ thống, dữ liệu thiếu, quá hạn hoặc từ chối>	Không dùng Lỗi khác; phải mô tả điều kiện phát hiện.
<exception_handling>	Ghi xử lý, vai trò nhận việc và điểm kết thúc.	<Hành động khắc phục + vai trò + kết quả>	Phải bảo toàn dữ liệu hoặc ghi rõ dữ liệu không được tạo/cập nhật khi thất bại.
<end_event_type>	Chọn loại end event BPMN.	None; Message; Error; Escalation; Terminate	Terminate chỉ dùng khi mọi luồng trong phạm vi phải dừng.
<evidence_id>	Điền ID bằng chứng canonical.	<ID evidence canonical>	Phải liên kết activity, quyết định hoặc ngoại lệ cần chứng minh.
<evidence_type>	Chọn loại bằng chứng.	System log; Audit trail; Document; API response; Report; Notification; Test result	Không ghi dữ liệu bí mật vào bằng chứng. Chỉ tham chiếu vị trí lưu và quyền truy cập.
<evidence_retention_or_verification_note>	Ghi ghi chú kiểm tra hoặc nhãn xác minh.	<Cách kiểm tra bằng chứng>; Verification required	Yêu cầu lưu giữ theo pháp lý, kế toán, an toàn thực phẩm hoặc dữ liệu cá nhân phải giữ nhãn Verification required khi chưa được owner có thẩm quyền xác minh.
<source_classification>	Phân loại nguồn cho nhận định hoặc rule.	Verified primary source; Project assumption; Verification required; Internal controlled artifact	Không nâng Project assumption thành yêu cầu bắt buộc.
<source_reference>	Ghi ID artifact canonical hoặc URL nguồn chính thức.	/01-curriculum/CANONICAL_BUSINESS_RULES.md; https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/	Không bịa số trang, điều khoản hoặc trích dẫn.
<secret_reference>	Chỉ tham chiếu bí mật, không ghi secret.	<secret-manager://environment/path#key>; <vault-reference-approved-by-security>	Cấm điền mật khẩu, API key, access token, private key, chuỗi kết nối DB hoặc dữ liệu cá nhân thật.
<version>	Ghi phiên bản template hoặc workflow.	<vX.Y.Z theo kiểm soát phiên bản>	Không dùng version để ngụ ý baseline hoặc approval.
<status>	Ghi trạng thái kiểm soát.	DRAFT; IN_REVIEW; BASELINED; RETIRED	Với corpus hiện hành, dùng IN_REVIEW; chỉ dùng BASELINED khi có baseline reference được ghi nhận.
<reviewer_role>	Ghi vai trò review cần thiết.	Business Owner; Solution Architect; QA Lead; Security Owner; Legal Owner; Accounting Owner	Chỉ chọn vai trò theo nội dung. Việc ghi tên vai trò không chứng minh review đã diễn ra.
<review_outcome>	Ghi kết quả review có kiểm soát.	Pending; Accepted with comments; Changes requested; Escalated	Không dùng Approved nếu không có approval reference hợp lệ.
<sign_off_reference>	Ghi tham chiếu phê duyệt nếu tồn tại.	<ID approval record>; Không có approval reference	Không để trống. Không suy ra phê duyệt từ email, họp, tên reviewer hoặc trạng thái IN_REVIEW.

Phần điều kiện. Chỉ điền <gateway_type>, <decision_question>, <outgoing_condition> và <business_rule_reference> khi quy trình có rẽ nhánh. Nếu không có quyết định, ghi Không áp dụng — không có rẽ nhánh trong phạm vi workflow; không tạo gateway để trang trí.

Phần ngoại lệ. Chỉ điền <exception_id> và các trường xử lý khi có lỗi, từ chối, timeout, dữ liệu không hợp lệ hoặc escalation trong phạm vi. Nếu không có ngoại lệ được mô hình hóa, ghi Không áp dụng — ngoại lệ ngoài phạm vi workflow; lý do phải nêu tại <scope_boundary> của template.

Phần tích hợp và bí mật. Chỉ điền <secret_reference> khi activity gọi API, DB, hàng đợi thông điệp hoặc dịch vụ cần thông tin xác thực. Mẫu an toàn: <secret-manager://nonprod/nova-foods-erp/procurement-api#client-secret>. Giá trị này chỉ chỉ vị trí tham chiếu mô phỏng; không xác nhận tồn tại vault, quyền truy cập hay cấu hình Nova Foods thực tế.

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

Case mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, không phải quy trình vận hành thực tế. Workflow map này mô tả luồng xử lý yêu cầu mua nguyên liệu bột mì cho kế hoạch sản xuất. BPMN (Business Process Model and Notation) là ký pháp mô hình hóa quy trình nghiệp vụ; sơ đồ dùng pool để biểu diễn tổ chức tham gia, lane để phân vai, event cho sự kiện, task cho công việc và gateway cho điểm quyết định.

Trường	Giá trị
Workflow ID	WF-PROC-001
Tên workflow	Xét duyệt yêu cầu mua bột mì cho lệnh sản xuất
Artifact ID	TMPL-WF-001
Tệp kiểm soát	/03-templates/TMPL-WF-001-workflow-map-bpmn.md
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày mô phỏng	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN, VND
Phạm vi bắt đầu	Kế hoạch sản xuất xác định thiếu bột mì mã RM-FLOUR-001 cho lệnh MO-20260810-014
Phạm vi kết thúc	ERP tạo đơn mua PO-20260807-0031 ở trạng thái APPROVED_FOR_SEND hoặc đóng yêu cầu mua ở trạng thái REJECTED
Ngoài phạm vi	Gửi đơn mua cho nhà cung cấp, nhận hàng, kiểm nghiệm, nhập kho, hóa đơn, thanh toán và hạch toán
Chủ sở hữu nghiệp vụ mô phỏng	Trần Minh Quân, Procurement Manager
Thẩm quyền quyết định mô phỏng	Lê Thu Hà, Finance Manager, quyết định yêu cầu có tổng giá trị từ 50.000.000 VND đến 200.000.000 VND
Phân loại nguồn	SIMULATED_PROJECT_ASSUMPTION; dữ liệu Nova Foods tổng hợp
Cơ sở ký pháp	NORMATIVE_STANDARD: OMG BPMN 2.0.2, https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/
Trạng thái phê duyệt	Không có approval reference; IN_REVIEW không là phê duyệt

Bối cảnh, sự kiện và nhu cầu

Ngày 2026-08-07, kế hoạch sản xuất mô phỏng kiểm tra lệnh MO-20260810-014 cho sản phẩm bánh quy yến mạch FG-COOKIE-OAT-250. Lệnh cần 3.000 kg bột mì RM-FLOUR-001; tồn khả dụng là 1.100 kg; mức thiếu là 1.900 kg. Bộ phận Kế hoạch tạo yêu cầu mua PR-20260807-0042 cho 2.000 kg để đủ lượng thiếu và mức làm tròn đóng bao 25 kg.

Hành vi hiện tại trong case mô phỏng: người mua có thể tạo đơn mua từ yêu cầu đã được kiểm tra tồn kho nhưng chưa qua kiểm tra ngân sách. Nhu cầu nền: ngăn cam kết mua vượt ngân sách tháng và vẫn bảo đảm nguyên liệu đến trước ngày sản xuất. Suy luận: giá trị dự kiến 136.000.000 VND vượt ngưỡng kiểm soát 50.000.000 VND; vì vậy yêu cầu cần Finance Manager quyết định trước khi ERP tạo đơn mua.

Dữ liệu nghiệp vụ	Giá trị mô phỏng	Phân loại nguồn
Yêu cầu mua	PR-20260807-0042	SIMULATED_TRANSACTION
Lệnh sản xuất	MO-20260810-014	SIMULATED_TRANSACTION
Mã nguyên liệu	RM-FLOUR-001	SIMULATED_MASTER_DATA
Mô tả	Bột mì đa dụng bao 25 kg	SIMULATED_MASTER_DATA
Số lượng yêu cầu	2.000 kg	SIMULATED_TRANSACTION
Đơn giá dự kiến	68.000 VND/kg	SIMULATED_QUOTATION_ASSUMPTION
Tổng giá trị dự kiến	136.000.000 VND	SIMULATED_CALCULATION
Ngày cần hàng	2026-08-09	SIMULATED_TRANSACTION
Nhà cung cấp đề xuất	SUP-00017 — Công ty TNHH Nguyên liệu An Phú	SIMULATED_MASTER_DATA
Ngân sách mua nguyên liệu tháng 08/2026 còn lại	180.000.000 VND	SIMULATED_BUDGET_DATA
Mã cost center	CC-PROD-01	SIMULATED_MASTER_DATA

BPMN core record

BPMN ID	Loại BPMN	Pool / lane	Tên phần tử	Đầu vào	Đầu ra	Trạng thái sau xử lý
EVT-PR-001	Start Event	Nova Foods ERP / Kế hoạch sản xuất	Phát hiện thiếu nguyên liệu	MO-20260810-014, tồn khả dụng 1.100 kg	Nhu cầu mua 2.000 kg	SHORTAGE_IDENTIFIED
TSK-PR-001	User Task	Nova Foods ERP / Kế hoạch sản xuất	Tạo yêu cầu mua	Nhu cầu mua, ngày cần hàng, cost center	PR-20260807-0042	SUBMITTED
TSK-PR-002	Service Task	Nova Foods ERP / ERP	Kiểm tra dữ liệu yêu cầu	Yêu cầu mua đã gửi	Kết quả kiểm tra dữ liệu	VALIDATED hoặc DATA_INVALID
GW-PR-001	Exclusive Gateway	Nova Foods ERP / ERP	Dữ liệu yêu cầu hợp lệ?	Kết quả kiểm tra dữ liệu	Nhánh hợp lệ hoặc từ chối dữ liệu	Không áp dụng
TSK-PR-003	User Task	Nova Foods ERP / Procurement Officer	Bổ sung hoặc sửa yêu cầu	Lỗi dữ liệu từ ERP	Yêu cầu mua đã sửa	SUBMITTED
TSK-PR-004	Service Task	Nova Foods ERP / ERP	Kiểm tra ngân sách	Yêu cầu hợp lệ, ngân sách còn lại	Kết quả ngân sách	BUDGET_CHECKED
GW-PR-002	Exclusive Gateway	Nova Foods ERP / ERP	Ngân sách đủ và giá trị có cần duyệt tài chính?	Tổng giá trị, ngân sách, ngưỡng duyệt	Nhánh duyệt tài chính hoặc từ chối ngân sách	Không áp dụng
TSK-PR-005	User Task	Nova Foods ERP / Finance Manager	Quyết định yêu cầu mua	Yêu cầu, kết quả ngân sách, lý do mua	Quyết định APPROVE hoặc REJECT	PENDING_FINANCE_DECISION
GW-PR-003	Exclusive Gateway	Nova Foods ERP / Finance Manager	Finance Manager chấp thuận?	Quyết định tài chính	Nhánh tạo đơn mua hoặc đóng yêu cầu	Không áp dụng
TSK-PR-006	Service Task	Nova Foods ERP / ERP	Tạo đơn mua	Quyết định APPROVE, nhà cung cấp đề xuất	PO-20260807-0031	APPROVED_FOR_SEND
EVT-PR-002	End Event	Nova Foods ERP / ERP	Đơn mua sẵn sàng gửi	PO-20260807-0031	Thông báo cho Procurement Officer	APPROVED_FOR_SEND
EVT-PR-003	End Event	Nova Foods ERP / ERP	Yêu cầu mua bị từ chối	Lý do từ chối	Thông báo cho Kế hoạch sản xuất	REJECTED

Quy tắc và điều kiện quyết định

Rule ID	Quy tắc	Bằng chứng và cầu nối suy luận	Kết quả áp dụng cho PR-20260807-0042	Phân loại nguồn
BR-PROC-001	Số lượng yêu cầu phải lớn hơn 0, là bội số 25 kg, có mã nguyên liệu, ngày cần hàng và cost center.	Bột mì mô phỏng đóng bao 25 kg; thiếu 1.900 kg; số lượng 2.000 kg là bội số 25 kg.	Hợp lệ.	SIMULATED_PROJECT_ASSUMPTION
BR-PROC-002	ERP từ chối ngân sách khi tổng giá trị dự kiến lớn hơn ngân sách còn lại.	136.000.000 VND nhỏ hơn 180.000.000 VND.	Ngân sách đủ.	SIMULATED_PROJECT_ASSUMPTION
BR-PROC-003	Finance Manager quyết định yêu cầu từ 50.000.000 VND đến 200.000.000 VND.	136.000.000 VND nằm trong khoảng kiểm soát.	Chuyển TSK-PR-005.	SIMULATED_PROJECT_ASSUMPTION
BR-PROC-004	ERP chỉ tạo đơn mua khi quyết định tài chính là APPROVE.	Đơn mua là cam kết mua mô phỏng; kiểm soát trước tạo đơn giảm rủi ro mua sai ngân sách.	Tạo PO-20260807-0031 nếu quyết định là APPROVE.	SIMULATED_PROJECT_ASSUMPTION

Điều kiện gateway GW-PR-001: chọn nhánh hợp lệ khi đủ năm trường bắt buộc: mã nguyên liệu, số lượng, đơn vị tính, ngày cần hàng, cost center. Nếu thiếu bất kỳ trường nào, chuyển TSK-PR-003; hệ quả nếu bỏ kiểm tra là ERP có thể tạo yêu cầu không thể phân bổ chi phí hoặc không thể mua đúng vật tư.

Điều kiện gateway GW-PR-002: chọn nhánh PENDING_FINANCE_DECISION khi ngân sách đủ và tổng giá trị từ 50.000.000 VND. Chọn nhánh REJECTED khi ngân sách không đủ. Case này có ngân sách đủ nên đi tới Finance Manager. Phương án bỏ qua duyệt tài chính nhanh hơn nhưng không được chọn vì giá trị 136.000.000 VND vượt ngưỡng mô phỏng.

Điều kiện gateway GW-PR-003: quyết định APPROVE tạo đơn mua; quyết định REJECT kết thúc yêu cầu với lý do FINANCE_REJECTED_BUDGET_PRIORITY. Hệ quả nếu diễn giải sai quyết định là ERP có thể tạo đơn mua không có quyết định kiểm soát tương ứng.

Payload mô phỏng giữa các bước

Payload ID	Bước gửi	Bước nhận	Nội dung đầy đủ	Phân loại nguồn
PAY-PR-001	TSK-PR-001	TSK-PR-002	{"purchaseRequestId":"PR-20260807-0042","productionOrderId":"MO-20260810-014","materialCode":"RM-FLOUR-001","quantityKg":2000,"unitPriceVnd":68000,"estimatedAmountVnd":136000000,"needByDate":"2026-08-09","costCenter":"CC-PROD-01","supplierId":"SUP-00017","status":"SUBMITTED"}	SIMULATED_TRANSACTION
PAY-PR-002	TSK-PR-004	TSK-PR-005	{"purchaseRequestId":"PR-20260807-0042","estimatedAmountVnd":136000000,"remainingBudgetVnd":180000000,"budgetSufficient":true,"approvalThresholdVnd":50000000,"decisionRequired":"FINANCE_MANAGER"}	SIMULATED_CALCULATION
PAY-PR-003	TSK-PR-005	TSK-PR-006	{"purchaseRequestId":"PR-20260807-0042","decision":"APPROVE","decisionReason":"Ngân sách còn đủ và nguyên liệu cần trước ngày sản xuất","decidedBy":"USR-FIN-004","decidedAt":"2026-08-07T14:20:00+07:00"}	SIMULATED_DECISION
PAY-PO-001	TSK-PR-006	EVT-PR-002	{"purchaseOrderId":"PO-20260807-0031","purchaseRequestId":"PR-20260807-0042","supplierId":"SUP-00017","materialCode":"RM-FLOUR-001","quantityKg":2000,"totalAmountVnd":136000000,"status":"APPROVED_FOR_SEND"}	SIMULATED_TRANSACTION

Hồ sơ lõi hoàn chỉnh — Luồng mua nguyên liệu Bao PP cho lệnh sản xuất NF-PO-20260807-001

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ tên người, giao dịch, số tiền, ngày và dữ liệu dưới đây là dữ liệu tổng hợp. BPMN (Business Process Model and Notation) là ký pháp mô hình hóa quy trình nghiệp vụ; bản đồ này mô tả thứ tự công việc, vai trò, quyết định, dữ liệu vào-ra và trạng thái.

Trường lõi	Giá trị hoàn chỉnh
Workflow ID	WF-NF-PROC-001
Workflow name	Mua Bao PP phục vụ lệnh sản xuất
Artifact	/03-templates/TMPL-WF-001-workflow-map-bpmn.md
Template ID	TMPL-WF-001
Status	IN_REVIEW
Version	v0.9.0
Ngày ghi nhận	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN; VND
Phạm vi	Yêu cầu mua, phê duyệt, lập đơn mua, nhận hàng và xử lý sai lệch Bao PP
Điểm bắt đầu	Kế hoạch sản xuất xác nhận thiếu Bao PP cho lệnh MO-NF-20260810-014
Điểm kết thúc thành công	Phiếu nhận hàng GRN-NF-20260809-003 được ghi nhận, tồn kho khả dụng tăng
Điểm kết thúc ngoại lệ	Yêu cầu mua bị từ chối hoặc hàng nhận sai lệch chuyển xử lý
Chủ sở hữu quy trình mô phỏng	Trần Minh Quân — Procurement Lead
Nguồn phân loại	SYNTHETIC_CASE_FACT; PROJECT_ASSUMPTION; không phải bằng chứng vận hành thực tế

Lane BPMN	Actor mô phỏng	Trách nhiệm
Production Planning	Nguyễn Thu Hà — Production Planner	Phát hiện thiếu vật tư, tạo yêu cầu mua
Procurement	Lê Quốc Bảo — Buyer	Kiểm tra nhà cung cấp, lập đơn mua
Finance Control	Phạm Ngọc Linh — Finance Controller	Duyệt hoặc từ chối giá trị mua vượt ngưỡng giả định
Supplier	Công ty Bao bì An Phát — mô phỏng	Xác nhận đơn, giao Bao PP
Warehouse	Võ Thành Nam — Warehouse Receiver	Nhận hàng, kiểm đếm, lập phiếu nhận
Quality Control	Đỗ Mỹ Duyên — QC Inspector	Kiểm tra chất lượng bao bì khi có sai lệch

Dữ liệu giao dịch	Giá trị
Lệnh sản xuất	MO-NF-20260810-014
Sản phẩm thành phẩm	Nước mắm Nova Premium 500 ml
Mã vật tư	RM-PKG-PP-001
Tên vật tư	Bao PP 25 kg, trắng, in logo Nova Foods
Tồn kho khả dụng trước yêu cầu	1.200 bao
Nhu cầu lệnh sản xuất	5.000 bao
Số lượng thiếu	3.800 bao
Yêu cầu mua	PR-NF-20260807-021
Số lượng yêu cầu mua	4.000 bao
Nhà cung cấp mô phỏng	SUP-NF-014 — Công ty Bao bì An Phát
Đơn giá chưa thuế	8.500 VND/bao
Thành tiền chưa thuế	34.000.000 VND
Thuế suất dùng trong case	10%; PROJECT_ASSUMPTION, cần Accounting Owner xác minh trước production
Tiền thuế mô phỏng	3.400.000 VND
Tổng giá trị đơn mua	37.400.000 VND
Đơn mua	PO-NF-20260807-018
Ngày giao cam kết	2026-08-09
Số lượng nhận thực tế	3.950 bao
Phiếu nhận hàng	GRN-NF-20260809-003
Số lượng sai lệch	50 bao thiếu so với đơn mua
Biên bản sai lệch	NCR-NF-20260809-002

Thứ tự BPMN	Loại phần tử	Lane	ID	Nội dung hoàn chỉnh	Trạng thái sau bước
1	Start Event	Production Planning	EVT-NF-001	Lệnh MO-NF-20260810-014 cần 5.000 Bao PP, tồn kho khả dụng chỉ 1.200 bao.	SHORTAGE_IDENTIFIED
2	User Task	Production Planning	TASK-NF-001	Nguyễn Thu Hà tạo PR-NF-20260807-021 cho 4.000 Bao PP, cần trước 2026-08-09.	PR_SUBMITTED
3	Service Task	Procurement	TASK-NF-002	ERP kiểm tra mã RM-PKG-PP-001, nhà cung cấp SUP-NF-014, đơn giá 8.500 VND/bao và tổng tiền 37.400.000 VND.	PR_VALIDATED
4	Exclusive Gateway	Finance Control	GW-NF-001	Kiểm tra tổng giá trị đơn mua có lớn hơn 30.000.000 VND không. Dữ kiện: 37.400.000 VND lớn hơn 30.000.000 VND.	PENDING_FINANCE_REVIEW
5	User Task	Finance Control	TASK-NF-003	Phạm Ngọc Linh xem xét giá, số lượng thiếu, ngày cần hàng và ngân sách mô phỏng BUD-NF-2026-OPS-03.	FINANCE_APPROVED
6	User Task	Procurement	TASK-NF-004	Lê Quốc Bảo phát hành PO-NF-20260807-018 cho SUP-NF-014, số lượng 4.000 bao, tổng tiền 37.400.000 VND.	PO_ISSUED
7	Message Catch Event	Supplier	EVT-NF-002	Nhà cung cấp gửi xác nhận giao 4.000 Bao PP ngày 2026-08-09.	DELIVERY_CONFIRMED
8	User Task	Warehouse	TASK-NF-005	Võ Thành Nam kiểm đếm giao nhận: 3.950 bao, thiếu 50 bao.	RECEIVING_RECORDED
9	Exclusive Gateway	Warehouse	GW-NF-002	So sánh số nhận 3.950 bao với số đơn mua 4.000 bao. Kết quả không khớp.	RECEIPT_VARIANCE
10	User Task	Quality Control	TASK-NF-006	Đỗ Mỹ Duyên kiểm tra 3.950 bao nhận thực tế; 3.950 bao đạt ngoại quan theo tiêu chí mô phỏng, 50 bao thiếu chưa được giao.	QC_ACCEPTED_WITH_SHORTAGE
11	User Task	Warehouse	TASK-NF-007	Lập GRN-NF-20260809-003 cho 3.950 bao và NCR-NF-20260809-002 cho thiếu 50 bao.	GRN_POSTED_NCR_OPEN
12	End Event	Procurement	EVT-NF-003	Buyer yêu cầu nhà cung cấp giao bù 50 bao; nhận hàng 3.950 bao được ghi nhận, sai lệch còn mở.	PARTIALLY_COMPLETED

Quy tắc	Điều kiện và xử lý	Cơ sở suy luận	Phân loại nguồn
BR-NF-PROC-001	Không tạo đơn mua khi số lượng yêu cầu mua nhỏ hơn hoặc bằng 0. PR-NF-20260807-021 có 4.000 bao nên hợp lệ.	Số lượng bằng 0 không thể tạo nhu cầu nhận hàng hay giá trị mua có nghĩa.	PROJECT_ASSUMPTION
BR-NF-PROC-002	Tổng đơn mua lớn hơn 30.000.000 VND phải qua Finance Control trước khi phát hành PO. PO-NF-20260807-018 là 37.400.000 VND nên đi qua TASK-NF-003.	Giá trị vượt ngưỡng mô phỏng làm tăng rủi ro cam kết chi phí; cần tách người lập và người kiểm soát.	PROJECT_ASSUMPTION
BR-NF-PROC-003	Chỉ ghi nhận tồn kho bằng số lượng nhận thực tế đã QC chấp nhận. GRN-NF-20260809-003 ghi 3.950 bao, không ghi 4.000 bao.	Ghi 4.000 bao khi chỉ nhận 3.950 bao làm tồn kho cao hơn thực tế 50 bao.	SYNTHETIC_CASE_FACT
BR-NF-PROC-004	Sai lệch số lượng khác 0 phải tạo NCR và giữ trạng thái đơn mua mở phần sai lệch. 50 bao thiếu tạo NCR-NF-20260809-002.	Chênh lệch chưa được xử lý không thể bị che bằng việc đóng toàn bộ đơn mua.	PROJECT_ASSUMPTION

Quyết định	Phương án	Tiêu chí	Kết quả trong case	Thẩm quyền quyết định mô phỏng	Hậu quả nếu sai
DEC-NF-001	Phát hành PO; từ chối PR	Mã vật tư hợp lệ, số lượng dương, nhu cầu gắn lệnh sản xuất, đủ kiểm soát giá trị	Phát hành PO-NF-20260807-018	Finance Controller cho ngưỡng giá trị; Procurement Lead phát hành PO	Thiếu bao bì có thể chậm lệnh sản xuất; mua sai có thể tạo chi phí không cần thiết
DEC-NF-002	Nhận đủ; nhận một phần và mở NCR; từ chối toàn bộ	Số lượng thực nhận, kết quả QC, khả năng dùng hàng nhận	Nhận 3.950 bao, mở NCR cho 50 bao thiếu	Warehouse Receiver ghi nhận; QC Inspector xác nhận chất lượng	Ghi sai số lượng làm sai tồn kho và sai cơ sở đối chiếu nhà cung cấp

Payload dữ liệu PR-NF-20260807-021	Giá trị
requestId	PR-NF-20260807-021
requestDate	2026-08-07
requesterId	EMP-NF-PP-006
productionOrderId	MO-NF-20260810-014
materialId	RM-PKG-PP-001
requestedQuantity	4000
unitOfMeasure	BAO
requiredDate	2026-08-09
currency	VND
sourceClassification	SYNTHETIC_CASE_FACT

Payload dữ liệu GRN-NF-20260809-003	Giá trị
goodsReceiptId	GRN-NF-20260809-003
purchaseOrderId	PO-NF-20260807-018
materialId	RM-PKG-PP-001
orderedQuantity	4000
receivedQuantity	3950
acceptedQuantity	3950
rejectedQuantity	0
varianceQuantity	50
nonConformanceId	NCR-NF-20260809-002
receiptStatus	POSTED_WITH_OPEN_VARIANCE
sourceClassification	SYNTHETIC_CASE_FACT

Bối cảnh, nhu cầu và quyết định luồng xử lý đơn mua nguyên liệu mô phỏng

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ tên người, giao dịch, mã và số tiền dưới đây là dữ liệu tổng hợp. BPMN (Business Process Model and Notation) là ký pháp chuẩn để mô tả luồng công việc bằng sự kiện, hoạt động, cổng quyết định và trách nhiệm. Bản đồ này mô tả luồng từ yêu cầu mua nguyên liệu đến xác nhận nhận hàng cho giao dịch PR-NF-20260805-017, không phải cấu hình ERP thực tế hay chỉ dẫn vận hành production.

Trường	Giá trị hoàn chỉnh
Workflow ID	WF-NF-P2P-001
Tên luồng	Mua bột cacao nguyên liệu có kiểm soát ngân sách
Phiên bản workflow	v0.9.0
Status	IN_REVIEW
Ngày ghi nhận	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Đơn vị tiền tệ	VND
Điểm bắt đầu	Nhân viên kế hoạch tạo yêu cầu mua đã có nhu cầu sản xuất
Điểm kết thúc thành công	Kho xác nhận nhận đủ hàng, ERP ghi nhận biên bản nhận hàng
Điểm kết thúc ngoại lệ	Yêu cầu bị từ chối, trả về bổ sung, hoặc lô hàng bị cách ly chờ xử lý
Chủ quy trình mô phỏng	Trần Minh Khoa — Procurement Manager
Quyền quyết định nghiệp vụ mô phỏng	Lê Thu Hà — Supply Chain Director
Nguồn phân loại	SRC-PROJECT-ASSUMPTION-001 — giả định dự án cho học liệu; không phải quy định vận hành đã phê duyệt
Liên kết quy tắc	CANONICAL_BUSINESS_RULES — trạng thái IN_REVIEW; không suy diễn thành rule production
Liên kết dữ liệu	CANONICAL_DATA_DICTIONARY — trạng thái IN_REVIEW; không phải schema triển khai

Sự thật quan sát được trong case mô phỏng. Ngày 2026-08-05, kế hoạch sản xuất mã MPS-NF-202608-02 cần 2.000 kg bột cacao cho đợt sản xuất tháng 2026-08. Tồn kho khả dụng ghi nhận trong kịch bản là 650 kg; mức tồn an toàn giả định là 300 kg. Khoảng thiếu là 1.650 kg, tính bằng 2.000 - 650 + 300. Nhân viên kế hoạch Nguyễn Quang Huy tạo PR-NF-20260805-017 với số lượng đề nghị 1.700 kg, đơn giá dự kiến 98.000 VND/kg, giá trị trước thuế 166.600.000 VND. Số lượng 1.700 kg lớn hơn khoảng thiếu 50 kg, nhằm giảm nguy cơ thiếu nguyên liệu trong phạm vi giả định dự án.

Dữ liệu giao dịch	Giá trị mô phỏng	Bằng chứng hoặc cầu nối suy luận
Mã yêu cầu mua	PR-NF-20260805-017	Bản ghi yêu cầu mua mô phỏng
Mặt hàng	Bột cacao alkalized 10–12%	Dòng vật tư RM-COCOA-ALK-001 trong case mô phỏng
Số lượng yêu cầu	1.700 kg	Khoảng thiếu 1.650 kg cộng đệm 50 kg
Đơn giá dự kiến	98.000 VND/kg	Báo giá mô phỏng QT-NF-20260804-031
Giá trị trước thuế	166.600.000 VND	1.700 × 98.000 VND
Nhà cung cấp dự kiến	Công ty TNHH Nguyên liệu Đông Nam	Nhà cung cấp mô phỏng SUP-NF-014
Ngày cần hàng	2026-08-12	Mốc đầu vào giả định của MPS-NF-202608-02
Địa điểm nhận	Kho nguyên liệu Bình Dương	Địa điểm mô phỏng WH-NF-BD-01

Hành vi hiện tại cần thay đổi. Trong tình huống mô phỏng, nhân viên kế hoạch gửi yêu cầu mua qua email; Procurement nhập lại dữ liệu vào ERP; Finance kiểm tra ngân sách trong bảng tính riêng; kho nhận hàng dựa vào bản in PO. Cùng một giá trị 1.700 kg bị nhập ở nhiều nơi. Cầu nối suy luận là: nhập lặp tạo khả năng khác số lượng, giá và ngày giao; nếu PO ghi 1.700 kg nhưng kho nhận theo email cũ 1.500 kg, ERP có thể ghi nhận sai tồn kho và Finance có thể thanh toán sai căn cứ.

Nhu cầu nền tảng. Luồng cần một nguồn dữ liệu nghiệp vụ xuyên suốt từ PR đến PO và biên bản nhận hàng. Nguồn dữ liệu chung giúp từng vai trò thấy cùng mã giao dịch, số lượng, giá trị, trạng thái và quyết định. Nhu cầu không phải “tự động hóa mọi bước”; nhu cầu là chặn cam kết mua khi thiếu dữ liệu, vượt ngân sách giả định, hoặc nhận hàng không khớp PO.

Phương án	Mô tả	Tiêu chí đánh giá	Kết quả đánh giá mô phỏng
OPT-WF-001-A	Giữ email, bảng tính và PO bản in	Tốc độ ban đầu, truy vết, kiểm soát dữ liệu lặp	Nhanh khi tạo yêu cầu nhưng truy vết yếu, dữ liệu lặp cao
OPT-WF-001-B	ERP ghi PR, phê duyệt, PO và nhận hàng; email chỉ báo thông báo	Một nguồn dữ liệu, kiểm soát trạng thái, khả năng kiểm tra	Đạt cả ba tiêu chí, giảm nhập lại
OPT-WF-001-C	ERP tự tạo PO ngay khi có PR	Tốc độ, kiểm soát ngân sách, kiểm soát nhà cung cấp	Nhanh nhưng bỏ qua kiểm tra giá, ngân sách và quyền phê duyệt

Tiêu chí quyết định. Phương án được chọn phải: có PR chứa mã vật tư, số lượng, ngày cần hàng và lý do nhu cầu; chỉ tạo PO sau kiểm tra ngân sách mô phỏng và chọn nhà cung cấp; chặn nhận hàng vượt PO; lưu trạng thái có thể truy vết. Các tiêu chí này xuất phát từ lỗi nhập lặp và nguy cơ cam kết mua sai đã nêu, không phải trích dẫn hay diễn giải quy định pháp luật.

Khuyến nghị và thẩm quyền quyết định. Khuyến nghị OPT-WF-001-B: ERP là nguồn ghi nhận chính; email chỉ phát thông báo có liên kết tới bản ghi ERP. Principal IT Business Analyst / Technical Curriculum Author ghi nhận phân tích và traceability, không có quyền chọn phương án cho vận hành thật. Trong case mô phỏng, Trần Minh Khoa đề xuất luồng; Lê Thu Hà là Decision Authority cho quyết định nghiệp vụ mô phỏng. Quyết định này vẫn IN_REVIEW, không phải approval, baseline hay quyền triển khai production.

Quyết định	Quy tắc xử lý mô phỏng	Hậu quả nếu quyết định sai
Kiểm tra dữ liệu PR	Không chuyển sang Procurement nếu thiếu mã vật tư, số lượng, ngày cần hàng hoặc lý do mua	Procurement có thể mua sai vật tư hoặc giao sau ngày sản xuất cần
Kiểm tra ngân sách	Không tạo PO nếu giá trị 166.600.000 VND vượt ngân sách còn lại giả định 150.000.000 VND	Cam kết mua vượt ngân sách mô phỏng, làm sai dự báo chi phí
So khớp nhận hàng	Kho chỉ xác nhận nhận đủ khi số lượng thực nhận bằng hoặc thấp hơn 1.700 kg và có PO PO-NF-20260806-044	Tồn kho hoặc nghĩa vụ thanh toán có thể bị ghi cao hơn hàng thực nhận
Cách ly ngoại lệ chất lượng	Lô nhận có lỗi bao bì hoặc sai chỉ tiêu kiểm tra mô phỏng phải ở trạng thái QUARANTINED	Nguyên liệu không đạt có thể bị cấp cho sản xuất, gây sai chất lượng thành phẩm

Ranh giới nguồn và xác minh. Kiểm soát ngân sách, kiểm tra chất lượng, hồ sơ nhận hàng và trạng thái cách ly trong bảng là giả định dự án SRC-PROJECT-ASSUMPTION-001. Các chi tiết liên quan kế toán, hóa đơn, an toàn thực phẩm và truy xuất nguồn gốc cần Verification required bởi Accounting Owner, Legal Owner và Food Safety Owner trước khi dùng ngoài học liệu. BPMN 2.0.2 của OMG là nguồn chuẩn cho ký pháp BPMN; bản đồ này dùng ký pháp để học phân tích luồng, không tuyên bố tuân thủ pháp lý hay cấu hình ERP thực tế.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã, người, số lượng và chứng từ dưới đây là dữ liệu tổng hợp. Ngoại lệ là kết quả lệch khỏi đường xử lý chuẩn; đường âm (negative path) là luồng hệ thống từ chối hoặc chặn giao dịch để ngăn dữ liệu sai đi tiếp. Bằng chứng phải chỉ rõ vật chứng kiểm tra được, không thay bằng nhận định miệng.

ID ngoại lệ	Điểm phát sinh	Điều kiện mô phỏng	Xử lý bắt buộc trong luồng	Trạng thái kết quả	Bằng chứng cần lưu
EXC-NF-PR-001	Procurement kiểm tra PR	PR thiếu ngày cần hàng	Chặn tạo PO; trả PR cho Requester bổ sung ngày cần hàng	RETURNED_TO_REQUESTER	PR PR-NF-20260805-017; nhật ký kiểm tra EV-NF-20260806-001; trường requiredDate rỗng
EXC-NF-PO-001	Procurement kiểm tra ngân sách	Giá trị PO 166.600.000 VND lớn hơn ngân sách còn lại giả định 150.000.000 VND	Không phát hành PO; tạo yêu cầu quyết định vượt ngân sách mô phỏng	PENDING_BUDGET_DECISION	PO nháp PO-NF-20260806-044; ảnh chụp ngân sách mô phỏng EV-NF-20260806-002; chênh lệch 16.600.000 VND
EXC-NF-GR-001	Kho nhận hàng	Số lượng thực nhận 1.650 kg thấp hơn số lượng PO 1.700 kg	Ghi nhận số lượng thực nhận; không xác nhận nhận đủ; thông báo Procurement xử lý phần thiếu 50 kg	PARTIALLY_RECEIVED	Phiếu nhận mô phỏng GR-NF-20260807-012; PO PO-NF-20260806-044; biên bản chênh lệch EV-NF-20260807-003
EXC-NF-QA-001	QA kiểm tra lô nhận	Bao bì rách tại 3 trên 34 bao, lô chưa đạt tiêu chí kiểm tra mô phỏng	Đặt lô vào khu cách ly; chặn cấp phát sản xuất; mở hồ sơ chất lượng	QUARANTINED	Lô LOT-NF-RM-20260807-031; phiếu kiểm tra QC-NF-20260807-009; ảnh mô phỏng EV-NF-20260807-004
EXC-NF-SEC-001	Người dùng thao tác nhận hàng	Tài khoản Kho cố sửa đơn giá PO	Từ chối lưu; ghi nhật ký truy cập; không đổi dữ liệu PO	ACCESS_DENIED	Nhật ký bảo mật mô phỏng EV-NF-20260807-005; user wh.nf01; quyền thiếu PO_PRICE_UPDATE

ID đường âm	Bước bị chặn	Dữ liệu đầu vào tổng hợp	Phản hồi mong đợi	Lý do kiểm soát
NEG-NF-001	Tạo PO từ PR	materialCode="", quantityKg=1700, requiredDate="2026-08-12"	Hiển thị lỗi “Mã vật tư là bắt buộc”; không tạo PO	Mã vật tư là khóa nhận diện hàng cần mua; thiếu mã làm Procurement không xác định được đối tượng mua
NEG-NF-002	Phê duyệt PO	poAmountVnd=166600000, remainingBudgetVnd=150000000	Không cho chuyển APPROVED; chuyển PENDING_BUDGET_DECISION	Ngăn cam kết mua vượt ngưỡng ngân sách giả định trước khi có quyết định đúng thẩm quyền
NEG-NF-003	Xác nhận nhận đủ	orderedQuantityKg=1700, receivedQuantityKg=1750	Từ chối xác nhận; yêu cầu lập biên bản nhận vượt	Nhận vượt PO có thể làm sai tồn kho và nghĩa vụ thanh toán mô phỏng
NEG-NF-004	Cấp phát lô cho sản xuất	lotStatus="QUARANTINED"	Từ chối cấp phát; giữ lô tại khu cách ly	Trạng thái cách ly ngăn nguyên liệu có dấu hiệu lỗi đi vào sản xuất

ID bằng chứng	Loại bằng chứng	Tham chiếu nguồn	Phân loại nguồn	Cầu nối suy luận
EV-NF-20260806-001	Nhật ký kiểm tra PR mô phỏng	PR-NF-20260805-017	SRC-PROJECT-ASSUMPTION-001	PR thiếu trường đầu vào thiết yếu; vì không thể xác định thời điểm cần hàng, luồng trả về Requester
EV-NF-20260806-002	Bản ghi ngân sách mô phỏng	PO nháp PO-NF-20260806-044	SRC-PROJECT-ASSUMPTION-001	166.600.000 VND lớn hơn 150.000.000 VND; vì chênh 16.600.000 VND, không được phát hành PO theo giả định case
EV-NF-20260807-004	Phiếu QA và ảnh bao bì mô phỏng	LOT-NF-RM-20260807-031	SRC-PROJECT-ASSUMPTION-001	Có 3 bao rách; vì tình trạng lô chưa được xác nhận đạt, hệ thống đặt QUARANTINED
EV-NF-20260807-005	Nhật ký phân quyền mô phỏng	user wh.nf01	OWASP ASVS 5.0.0; SRC-PROJECT-ASSUMPTION-001	Vai trò Kho không có quyền PO_PRICE_UPDATE; vì phân quyền ngăn sửa dữ liệu ngoài trách nhiệm, thao tác bị từ chối

ID giả định	Giả định dự án mô phỏng	Tác động nếu sai	Verification required	Vai trò escalation
ASM-NF-001	Ngưỡng ngân sách còn lại cho PO này là 150.000.000 VND	Luồng chặn hoặc cho phép PO có thể sai	Xác minh quy tắc ngân sách, thẩm quyền vượt ngân sách và cách ghi nhận cam kết	Business Owner; Accounting Owner
ASM-NF-002	Lô có bao bì rách phải cách ly trước khi cấp phát	Có thể cách ly quá mức hoặc bỏ lọt rủi ro chất lượng	Xác minh tiêu chí chất lượng, lấy mẫu và xử lý lô không đạt	Food Safety Owner; QA Owner; Legal Owner
ASM-NF-003	Kho không được sửa đơn giá PO	Ma trận quyền có thể khác thiết kế ERP thực tế	Xác minh mô hình phân quyền và yêu cầu audit log	Security Owner; Solution Architect
ASM-NF-004	Nhận vượt 1.700 kg phải chặn xác nhận nhận đủ	Quy tắc dung sai nhận hàng có thể khác hợp đồng hoặc vận hành thực	Xác minh dung sai số lượng, xử lý hàng vượt và ảnh hưởng kế toán	Procurement Owner; Accounting Owner

ID escalation	Điều kiện mở escalation	Người lập gói vấn đề	Người nhận quyết định	Nội dung phải quyết định	Trạng thái
ESC-NF-20260806-001	PO vượt ngân sách giả định 16.600.000 VND	Trần Minh Khoa, BA mô phỏng	Lê Thu Hà, Decision Authority mô phỏng; Accounting Owner	Cho phép, từ chối, hoặc điều chỉnh số lượng/đơn giá PO nháp PO-NF-20260806-044	OPEN_VERIFICATION_REQUIRED
ESC-NF-20260807-002	Lô LOT-NF-RM-20260807-031 có 3 bao rách	Trần Minh Khoa, BA mô phỏng	QA Owner; Food Safety Owner; Legal Owner	Tiêu chí chấp nhận, tái kiểm, trả hàng hoặc hủy lô	OPEN_VERIFICATION_REQUIRED
ESC-NF-20260807-003	Cần xác định dung sai nhận vượt 50 kg	Trần Minh Khoa, BA mô phỏng	Procurement Owner; Accounting Owner	Có chấp nhận số lượng vượt, sửa PO, hay lập chứng từ riêng	OPEN_VERIFICATION_REQUIRED

Không escalation nào là phê duyệt, baseline, diễn giải pháp lý, quyết định kế toán hoặc quyền triển khai production. SRC-PROJECT-ASSUMPTION-001 chỉ hỗ trợ tình huống học liệu. Chi tiết hóa đơn, kế toán, an toàn thực phẩm, truy xuất nguồn gốc và dữ liệu cá nhân cần xác minh nguồn chính thức hiện hành bởi đúng chủ thể có thẩm quyền trước mọi sử dụng ngoài case mô phỏng.

Ma trận truy vết đầu-cuối cho luồng duyệt yêu cầu mua nguyên liệu

Nova Foods là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Truy vết đầu-cuối nối nhu cầu nghiệp vụ với yêu cầu, quy tắc, tiêu chí chấp nhận, dữ liệu/API và kiểm thử. Mục tiêu: khi một điểm thay đổi hoặc lỗi xuất hiện, BA xác định được tác động và bằng chứng kiểm tra. Các ID là liên kết đang IN_REVIEW tại v0.9.0, không phải baseline hay phê duyệt.

Chuỗi	ID	Phân loại nguồn	Nội dung đầy đủ	Liên kết xuôi	Bằng chứng liên kết và lý do
Need	NEED-NF-PO-001	Nhu cầu case mô phỏng	Bộ phận Mua hàng cần chặn phát hành đơn mua khi yêu cầu mua nguyên liệu chưa được cấp thẩm quyền duyệt.	REQ-NF-PO-001	Nhu cầu nêu kết quả cần đạt: không phát hành PO chưa duyệt. Yêu cầu hệ thống phải kiểm soát trạng thái trước thao tác phát hành.
Requirement	REQ-NF-PO-001	Yêu cầu chức năng case mô phỏng	ERP phải chỉ cho phép người dùng có vai trò Purchasing Officer phát hành PO khi purchaseRequisition.status = APPROVED.	BR-NF-PO-001, AC-NF-PO-001, DATA-NF-PR-001, API-NF-PO-001, TC-NF-PO-001, TC-NF-PO-002	Cụm “chỉ cho phép” cần quy tắc quyết định; điều kiện trạng thái cần trường dữ liệu; thao tác phát hành cần hợp đồng API; hai nhánh cho phép và từ chối cần test riêng.
Business Rule	BR-NF-PO-001	Quy tắc nghiệp vụ case mô phỏng	PO chỉ được chuyển sang RELEASED nếu yêu cầu mua tham chiếu có trạng thái chính xác là APPROVED. Trạng thái DRAFT, SUBMITTED, REJECTED, CANCELLED đều không hợp lệ.	AC-NF-PO-001, AC-NF-PO-002, TC-NF-PO-001, TC-NF-PO-002	Quy tắc chuyển điều kiện nghiệp vụ thành tập trạng thái kiểm tra được. Không suy diễn ngưỡng tiền, phân quyền duyệt, thuế hoặc quy định pháp lý.
Acceptance Criteria	AC-NF-PO-001	Tiêu chí chấp nhận case mô phỏng	Given PR-NF-20260807-001 có trạng thái APPROVED; when Purchasing Officer phát hành PO-NF-20260807-001; then ERP lưu RELEASED và trả mã PO.	TC-NF-PO-001	Đây là đường dương: điều kiện hợp lệ theo BR-NF-PO-001 phải tạo kết quả phát hành.
Acceptance Criteria	AC-NF-PO-002	Tiêu chí chấp nhận case mô phỏng	Given PR-NF-20260807-002 có trạng thái SUBMITTED; when Purchasing Officer phát hành PO-NF-20260807-002; then ERP từ chối, giữ PO ở DRAFT, trả lỗi PR_STATUS_NOT_APPROVED.	TC-NF-PO-002, DEF-NF-PO-001	Đây là đường âm: SUBMITTED thuộc tập trạng thái bị chặn của BR-NF-PO-001. DEF-NF-PO-001 chỉ dùng nếu thực thi sai tiêu chí này.
Data	DATA-NF-PR-001	Liên kết tới /01-curriculum/CANONICAL_DATA_DICTIONARY.md; nội dung case mô phỏng	Thực thể logic PurchaseRequisition: purchaseRequisitionId, status, requestDate, requestingDepartmentCode. Giá trị kiểm thử: PR-NF-20260807-001/APPROVED và PR-NF-20260807-002/SUBMITTED.	API-NF-PO-001, TC-NF-PO-001, TC-NF-PO-002	status là dữ liệu quyết định trực tiếp theo REQ-NF-PO-001. Từ điển dữ liệu đang IN_REVIEW; không khẳng định schema triển khai.
API	API-NF-PO-001	Hợp đồng API case mô phỏng; tham chiếu thuật ngữ OAS 3.1.1	POST /api/v1/purchase-orders/{purchaseOrderId}/release; đầu vào gồm purchaseOrderId và purchaseRequisitionId; thành công 200; yêu cầu mua chưa duyệt trả 409 với code: PR_STATUS_NOT_APPROVED.	TC-NF-PO-001, TC-NF-PO-002	Endpoint biểu diễn thao tác “phát hành” trong REQ-NF-PO-001. HTTP 409 tách xung đột trạng thái nghiệp vụ khỏi lỗi xác thực hoặc lỗi máy chủ.
Test Case	TC-NF-PO-001	Kiểm thử chức năng case mô phỏng	Gọi API phát hành cho PO-NF-20260807-001 tham chiếu PR-NF-20260807-001. Kỳ vọng HTTP 200, purchaseOrderStatus: RELEASED.	AC-NF-PO-001	Xác minh nhánh hợp lệ từ dữ liệu nguồn đến kết quả lưu.
Test Case	TC-NF-PO-002	Kiểm thử biên âm case mô phỏng	Gọi API phát hành cho PO-NF-20260807-002 tham chiếu PR-NF-20260807-002. Kỳ vọng HTTP 409, code: PR_STATUS_NOT_APPROVED, PO vẫn DRAFT.	AC-NF-PO-002	Xác minh hệ thống không đổi trạng thái PO khi điều kiện quy tắc không đạt.
Defect	DEF-NF-PO-001	Chỉ kích hoạt khi test thất bại; chưa có bản ghi defect	Không có defect được ghi nhận tại dữ liệu mô phỏng hiện có. Nếu TC-NF-PO-002 nhận HTTP 200 hoặc PO thành RELEASED, tạo defect với liên kết REQ-NF-PO-001, BR-NF-PO-001, AC-NF-PO-002.	Không áp dụng khi test đạt	Không tạo defect giả. Defect là bằng chứng lỗi thực thi, không phải thành phần bắt buộc của mọi chuỗi truy vết.
Change Request	CR-NF-PO-001	Chỉ kích hoạt khi thay đổi phạm vi; chưa có yêu cầu thay đổi	Không có change request được ghi nhận. Nếu thêm trạng thái PENDING_REVIEW hoặc đổi điều kiện phát hành, tạo CR liên kết các ID bị tác động trước khi sửa yêu cầu hoặc test.	Không áp dụng khi phạm vi không đổi	Không tạo CR giả. CR cần thay đổi được ghi nhận, không dùng để hợp thức hóa suy diễn mới.

Kiểm tra đủ chuỗi: NEED-NF-PO-001 liên kết tới REQ-NF-PO-001; yêu cầu liên kết tới quy tắc, tiêu chí, dữ liệu, API và test; mỗi tiêu chí có ít nhất một test; nhánh lỗi liên kết điều kiện tạo defect nhưng không khai báo defect không tồn tại. Nguồn chuẩn chỉ hỗ trợ thuật ngữ BPMN, BA, API và kiểm thử; nội dung nghiệp vụ Nova Foods vẫn là mô phỏng, cần Business Owner, Architect và QA xác minh trước mọi baseline hoặc sử dụng production.

4.1. Sơ đồ BPMN 2.0.2, bảng quyết định và dữ liệu kiểm thử mô phỏng

BPMN (Business Process Model and Notation) là ký pháp chuẩn để biểu diễn luồng công việc. Sơ đồ dưới mô tả case mô phỏng Nova Foods: nhân viên Kinh doanh tạo đơn bán hàng, ERP kiểm tra hạn mức tín dụng mô phỏng, rồi phát hành đơn sang Kho hoặc trả đơn về Kinh doanh để chỉnh sửa. Mọi mã và dữ liệu là tổng hợp, không phải cấu hình ERP thật.

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
  id="Definitions_NF_SO_CreditCheck"
  targetNamespace="https://novafods.example.vn/bpmn">

  <bpmn:process id="Process_NF_SO_CreditCheck" name="Nova Foods - Kiểm tra tín dụng đơn bán hàng" isExecutable="false">
    <bpmn:startEvent id="StartEvent_CreateSO" name="Nhận yêu cầu tạo đơn">
      <bpmn:outgoing>Flow_Start_Create</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:userTask id="Task_CreateSO" name="Tạo đơn bán hàng">
      <bpmn:incoming>Flow_Start_Create</bpmn:incoming>
      <bpmn:outgoing>Flow_Create_Check</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:serviceTask id="Task_CheckCredit" name="ERP kiểm tra hạn mức tín dụng">
      <bpmn:incoming>Flow_Create_Check</bpmn:incoming>
      <bpmn:outgoing>Flow_Check_Gateway</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:exclusiveGateway id="Gateway_CreditAvailable" name="Hạn mức còn đủ?">
      <bpmn:incoming>Flow_Check_Gateway</bpmn:incoming>
      <bpmn:outgoing>Flow_CreditYes_Release</bpmn:outgoing>
      <bpmn:outgoing>Flow_CreditNo_Return</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:serviceTask id="Task_ReleaseSO" name="Phát hành đơn cho Kho">
      <bpmn:incoming>Flow_CreditYes_Release</bpmn:incoming>
      <bpmn:outgoing>Flow_Release_End</bpmn:outgoing>
    </bpmn:serviceTask>

    <bpmn:endEvent id="EndEvent_Released" name="Đơn đã phát hành">
      <bpmn:incoming>Flow_Release_End</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:userTask id="Task_ReturnSO" name="Trả đơn cho Kinh doanh chỉnh sửa">
      <bpmn:incoming>Flow_CreditNo_Return</bpmn:incoming>
      <bpmn:outgoing>Flow_Return_End</bpmn:outgoing>
    </bpmn:userTask>

    <bpmn:endEvent id="EndEvent_Returned" name="Đơn cần chỉnh sửa">
      <bpmn:incoming>Flow_Return_End</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="Flow_Start_Create" sourceRef="StartEvent_CreateSO" targetRef="Task_CreateSO"/>
    <bpmn:sequenceFlow id="Flow_Create_Check" sourceRef="Task_CreateSO" targetRef="Task_CheckCredit"/>
    <bpmn:sequenceFlow id="Flow_Check_Gateway" sourceRef="Task_CheckCredit" targetRef="Gateway_CreditAvailable"/>
    <bpmn:sequenceFlow id="Flow_CreditYes_Release" name="Có" sourceRef="Gateway_CreditAvailable" targetRef="Task_ReleaseSO">
      <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><![CDATA[creditAvailableVnd >= orderTotalVnd]]></bpmn:conditionExpression>
    </bpmn:sequenceFlow>
    <bpmn:sequenceFlow id="Flow_CreditNo_Return" name="Không" sourceRef="Gateway_CreditAvailable" targetRef="Task_ReturnSO">
      <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><![CDATA[creditAvailableVnd < orderTotalVnd]]></bpmn:conditionExpression>
    </bpmn:sequenceFlow>
    <bpmn:sequenceFlow id="Flow_Release_End" sourceRef="Task_ReleaseSO" targetRef="EndEvent_Released"/>
    <bpmn:sequenceFlow id="Flow_Return_End" sourceRef="Task_ReturnSO" targetRef="EndEvent_Returned"/>
  </bpmn:process>
</bpmn:definitions>

Quyết định tại Gateway_CreditAvailable dùng so sánh số học VND. Lý do: ERP cần một điều kiện xác định để chọn đúng một nhánh; tổng đơn bằng hạn mức còn lại vẫn được phát hành vì số dư đủ thanh toán giá trị đơn.

Quy tắc quyết định	creditAvailableVnd	orderTotalVnd	Kết quả gateway	Bước kế tiếp
DEC-NF-SO-001	15000000	12500000	Có	Task_ReleaseSO
DEC-NF-SO-002	12500000	12500000	Có	Task_ReleaseSO
DEC-NF-SO-003	12499999	12500000	Không	Task_ReturnSO

Payload đầu vào tổng hợp cho Task_CheckCredit:

{
  "salesOrderId": "SO-NF-260807-001",
  "customerId": "CUS-NF-00128",
  "orderDate": "2026-08-07",
  "currencyCode": "VND",
  "orderTotalVnd": 12500000,
  "creditLimitVnd": 50000000,
  "creditUsedVnd": 35000000,
  "creditAvailableVnd": 15000000,
  "requestedByUserId": "USR-NF-SALES-014"
}

TC ID	Dữ liệu kiểm thử tổng hợp	Kết quả mong đợi
TC-NF-SO-001	SO-NF-260807-001; hạn mức còn lại 15000000; tổng đơn 12500000	Đi qua Flow_CreditYes_Release; kết thúc EndEvent_Released.
TC-NF-SO-002	SO-NF-260807-002; hạn mức còn lại 12500000; tổng đơn 12500000	Đi qua Flow_CreditYes_Release; kiểm tra điều kiện bằng cho phép phát hành.
TC-NF-SO-003	SO-NF-260807-003; hạn mức còn lại 12499999; tổng đơn 12500000	Đi qua Flow_CreditNo_Return; kết thúc EndEvent_Returned.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng kiểm soát trước baseline: Senior Business Analyst (BA cấp cao) kiểm tra workflow map có đủ để review, xây test và truy vết hay chưa. Cổng này không tạo phê duyệt, không tạo baseline, không xác nhận tuân thủ pháp lý, kế toán hoặc production. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Kết quả	Nghĩa	Hành động
PASS	Bằng chứng đủ, nhất quán, đúng boundary thẩm quyền.	Ghi kết quả review; giữ trạng thái IN_REVIEW.
FAIL	Có lỗi xác định, nhưng phạm vi và cách sửa rõ.	Ghi finding; sửa artifact và review lại mục lỗi.
STOP	Thiếu nguồn chân lý, mâu thuẫn trọng yếu, hoặc vượt thẩm quyền BA.	Dừng pre-baseline review; không gọi artifact là baseline-ready.
ESCALATE	Cần quyết định từ owner chuyên môn khác.	Lập gói vấn đề, giữ traceability, chuyển đúng vai trò có thẩm quyền.

ID kiểm tra	Nhóm	Câu hỏi kiểm tra và bằng chứng tối thiểu	PASS	FAIL	STOP / Escalation
QG-WF-001	Tính đầy đủ	Workflow có trigger, điểm bắt đầu, tác vụ, gateway, luồng điều kiện, ngoại lệ, điểm kết thúc, lane/owner và đầu ra không? Bằng chứng: sơ đồ BPMN cùng bảng quyết định.	Mỗi đường đi từ start đến end có ý nghĩa nghiệp vụ và owner.	Thiếu nhãn gateway, thiếu end event, hoặc một nhánh không có kết quả.	STOP nếu không xác định được phạm vi quy trình hoặc trigger. Escalate Business Owner.
QG-WF-002	BPMN và tính nhất quán	Ký pháp BPMN 2.0.2 có dùng đúng loại phần tử không? BPMN là Business Process Model and Notation, chuẩn mô hình hóa quy trình nghiệp vụ.	XML BPMN, sơ đồ, tên task và sequence flow cùng biểu đạt một luồng.	Gateway ghi điều kiện khác bảng quyết định; flow trỏ sai task.	STOP nếu sơ đồ không phải BPMN nhưng bị gọi là BPMN. Sửa artifact trước review tiếp.
QG-WF-003	Nhất quán dữ liệu	ID, ngày, tiền tệ, số tiền, customer và trạng thái có khớp giữa payload, gateway, test case và workflow không?	Cùng salesOrderId, customerId, VND, số học và điều kiện trên mọi artifact liên quan.	Ví dụ creditAvailableVnd khác giá trị dùng trong test.	STOP nếu không xác định được nguồn canonical của dữ liệu. Escalate Data Owner hoặc Architect.
QG-WF-004	Tính kiểm thử	Mỗi quyết định có dữ liệu đầu vào, điều kiện, kết quả mong đợi và test case dương/biên/âm không?	Test case chứng minh mọi nhánh, gồm trường hợp bằng ngưỡng.	Có mô tả “kiểm tra hạn mức” nhưng không có toán tử hay expected result.	STOP nếu không thể tạo expected result khách quan. Escalate Business Owner.
QG-WF-005	Truy vết	Mỗi task, gateway, rule, payload và test case có ID ổn định, liên kết được tới nguồn hoặc giả định không?	Liên kết dùng ID canonical như DEC-NF-SO-001, TC-NF-SO-001; không đổi tên tùy ý.	Test case không chỉ rõ rule hoặc flow cần chứng minh.	STOP nếu ID chưa đăng ký hoặc hai đối tượng dùng cùng ID. Escalate Principal IT Business Analyst / Technical Curriculum Author.
QG-WF-006	Thẩm quyền nguồn	Nguồn được phân loại đúng: chuẩn, luật, project assumption hoặc Verification required?	BPMN tham chiếu OMG BPMN 2.0.2; nội dung pháp lý giữ nhãn cần xác minh khi chưa có owner kết luận.	Good practice bị viết thành nghĩa vụ pháp luật; giả định bị viết thành quy định Nova Foods.	STOP nếu nguồn không rõ hoặc mâu thuẫn. Escalate Legal Owner, Accounting Owner, Security Owner hoặc domain owner tùy chủ đề.
QG-WF-007	Ownership	Mỗi tác vụ và quyết định có role chịu trách nhiệm; role không bị gán quyền vượt phạm vi không?	Sales, Credit Control, ERP System hoặc role mô phỏng được nêu rõ; người khởi tạo không tự phê duyệt vượt quyền.	Task có tên chung chung như “xử lý đơn” mà không có owner.	ESCALATE nếu phân quyền cần quyết định vận hành thực tế. Business Owner và Security Owner quyết định.
QG-WF-008	Bảo mật và riêng tư	Payload có dữ liệu cá nhân, thông tin tín dụng, định danh truy cập hoặc dữ liệu nhạy cảm không? Nếu có, mục đích dùng, quyền truy cập và che giấu khi hiển thị đã rõ chưa?	Chỉ dùng dữ liệu tổng hợp; requestedByUserId được coi là định danh cần kiểm soát; không đưa bí mật, mật khẩu, token vào tài liệu.	Payload chứa thông tin thật, token, số tài khoản, địa chỉ cá nhân không cần thiết.	STOP khi có dữ liệu thật hoặc yêu cầu xử lý dữ liệu cá nhân chưa được Legal/Security xác minh. Escalate Legal Owner và Security Owner.
QG-WF-009	Pháp lý, kế toán, hóa đơn	Workflow có tạo nghĩa vụ pháp lý, hạch toán, thuế, hóa đơn hoặc lưu trữ chứng từ không?	Nội dung chỉ mô tả workflow mô phỏng; mọi diễn giải ngoài nguồn verified mang nhãn Verification required hoặc project assumption.	Khẳng định điều kiện tín dụng là nghĩa vụ luật, hoặc khẳng định bút toán/hóa đơn mà không có Accounting Owner.	STOP nếu workflow được dùng để kết luận pháp lý, thuế, kế toán hoặc hóa đơn. Escalate Legal Owner và Accounting Owner.
QG-WF-010	An toàn thực phẩm và truy xuất	Workflow có quyết định liên quan lô hàng, recall, hạn dùng hoặc truy xuất thực phẩm không?	Nếu ngoài phạm vi sales order credit check, boundary ghi rõ không bao gồm.	Tự thêm bước truy xuất/lệnh thu hồi không có nguồn và owner.	ESCALATE Food Safety/Operations Owner và Legal Owner khi phạm vi chạm truy xuất hoặc recall.
QG-WF-011	Ảnh hưởng thay đổi	Thay đổi rule, ngưỡng, owner, payload hay flow có danh sách artifact/test bị ảnh hưởng không?	Có xác định impact tối thiểu: BPMN, bảng quyết định, payload, test case, traceability link.	Đổi điều kiện gateway nhưng giữ test cũ.	STOP nếu thay đổi phá traceability hoặc không xác định được phạm vi ảnh hưởng. Escalate Architect, QA Lead hoặc Business Owner theo loại thay đổi.
QG-WF-012	Trạng thái quản trị	Artifact có giữ đúng IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND và tính chất synthetic không?	Metadata và nội dung không mâu thuẫn controlled corpus.	Gọi tài liệu là approved, baselined, compliant hoặc production-ready.	STOP nếu có claim approval/baseline không có tham chiếu kiểm soát. Escalate Owner quản trị artifact.

Quy tắc quyết định: một STOP chặn kết luận pre-baseline review cho toàn workflow map. Một FAIL không tự thành PASS khi chưa có bằng chứng sửa tương ứng. Một ESCALATE giữ nguyên nhãn IN_REVIEW; Senior BA chỉ ghi vấn đề, bằng chứng, ảnh hưởng và role nhận escalation, không thay vai trò chuyên môn để tự kết luận.

5.1 Checklist chất lượng: đầy đủ, nhất quán và ranh giới kiểm soát

Quality gate là cổng rà soát trước baseline: kiểm tra artifact đủ đầu vào để review, không tự xác nhận phê duyệt, tuân thủ, hiệu lực pháp lý hoặc khả năng dùng production. Áp dụng cho /03-templates/TMPL-WF-001-workflow-map-bpmn.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Hạng mục	Câu hỏi kiểm tra và cầu nối bằng chứng	Đạt	Không đạt	Dừng hoặc chuyển cấp
Đầy đủ	Core Record phải có phạm vi quy trình, điểm bắt đầu/kết thúc, tác nhân, bước xử lý, cổng quyết định, ngoại lệ, đầu vào/đầu ra và liên kết evidence. Lý do: thiếu một thành phần làm người đọc không dựng lại được luồng nghiệp vụ.	Mỗi thành phần có nội dung Nova Foods cụ thể, không có placeholder Tier 2 trong Tier 3.	Thiếu bước, quyết định, ngoại lệ hoặc đầu ra.	STOP nếu thiếu thành phần làm đổi kết quả quy trình hoặc che giấu ngoại lệ.
Nhất quán	Tên vai trò, tên dữ liệu, kết quả quyết định, đơn vị tiền tệ VND, locale vi-VN và múi giờ Asia/Ho_Chi_Minh phải khớp giữa Core Record và Evidence. Lý do: một đối tượng có hai nghĩa tạo lỗi build, test và vận hành.	Một tên, một nghĩa, một kết quả cho cùng ngữ cảnh.	Cùng vai trò hoặc dữ liệu có tên/kết quả khác nhau.	Chuyển Principal IT Business Analyst / Technical Curriculum Author xử lý liên kết; STOP nếu mâu thuẫn với artifact canonical.
Khả năng kiểm thử	Mỗi quyết định và ngoại lệ phải quan sát được qua dữ liệu vào, điều kiện, kết quả mong đợi. Testability là khả năng tạo kiểm thử lặp lại từ mô tả. Lý do: câu “hệ thống xử lý đúng” không cho QA biết dữ liệu nào chứng minh đúng.	Có điều kiện, dữ liệu tổng hợp, kết quả và trạng thái mong đợi.	Chỉ có mô tả chung, không có điều kiện kiểm tra.	Chuyển QA reviewer nếu acceptance condition hoặc test basis chưa xác định.
Truy vết	Mỗi bước quan trọng phải nối về nguồn, quy tắc, dữ liệu hoặc giả định trong Evidence and Traceability. Traceability là khả năng lần từ luồng đến căn cứ và lần ngược lại.	Liên kết giữ nguyên ID canonical và đường dẫn nguồn.	Liên kết thiếu, đổi ID, đổi filename hoặc trỏ nguồn không kiểm soát.	STOP nếu không xác định được nguồn của quyết định ảnh hưởng tài chính, dữ liệu cá nhân hoặc an toàn thực phẩm.
Thẩm quyền nguồn	Phân biệt nguồn chuẩn, nguồn pháp luật, giả định dự án và nội dung mô phỏng. BABOK Guide dùng cho thuật ngữ BA; BPMN 2.0.2 dùng cho ký pháp BPMN; pháp luật Việt Nam không tự biến thành yêu cầu hệ thống nếu chưa có Legal Owner xác minh.	Nguồn dùng đúng safe use boundary; nội dung chưa xác minh gắn Verification required hoặc project assumption.	Gán diễn giải pháp lý, kế toán hoặc kỹ thuật là kết luận đã xác nhận.	Chuyển Legal Owner, Accounting Owner, Security hoặc domain owner theo loại nguồn; STOP nếu claim nghĩa vụ bắt buộc không có thẩm quyền.
Ownership	Mỗi lane, bước phê duyệt và xử lý ngoại lệ phải có vai trò chịu trách nhiệm. Ownership là trách nhiệm quyết định hoặc thực hiện, không phải tên người.	Vai trò thực hiện và vai trò quyết định phân biệt rõ.	“Hệ thống”, “người dùng” hoặc nhóm chung chung chịu trách nhiệm quyết định.	Chuyển Business Owner khi chưa rõ quyền quyết định; chuyển Architect khi chưa rõ ranh giới hệ thống.
Bảo mật và riêng tư	Xác định dữ liệu cá nhân, quyền xem/sửa, điểm truyền dữ liệu và log cần bảo vệ. Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn pháp lý cần Legal Owner xác minh khi rút thành requirement. OWASP ASVS 5.0.0 là good practice, không phải luật Việt Nam.	Luồng nêu loại dữ liệu, vai trò truy cập và ranh giới xác minh.	Đưa dữ liệu cá nhân vào luồng không nêu kiểm soát hoặc gọi good practice là nghĩa vụ pháp lý.	Chuyển Security và Legal Owner; STOP nếu luồng cho phép truy cập dữ liệu cá nhân không có ranh giới quyền.
Pháp lý, kế toán, hóa đơn và an toàn thực phẩm	Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm 55/2010/QH12 chỉ định bối cảnh cần xác minh, không là rule ERP tự suy diễn.	Mọi yêu cầu dẫn xuất giữ nhãn Verification required và owner chuyên môn.	Ghi nhận thuế, hóa đơn, lưu trữ kế toán, truy xuất hoặc thu hồi là rule đã chốt.	Chuyển Accounting Owner, Legal Owner và food-safety domain owner; STOP nếu quyết định làm thay đổi ghi nhận tài chính hoặc nghĩa vụ pháp lý.
Tác động thay đổi	So sánh thay đổi với workflow, Evidence, nguồn canonical và artifact phụ thuộc. Lý do: sửa một cổng quyết định có thể đổi test, dữ liệu, quyền truy cập và trách nhiệm.	Nêu thành phần bị ảnh hưởng, lý do, owner rà soát và liên kết cần cập nhật.	Chỉ sửa sơ đồ, không kiểm tra evidence, test basis hoặc nguồn liên quan.	STOP nếu thay đổi ảnh hưởng ranh giới pháp lý, kế toán, bảo mật hoặc source authority chưa được review.

Áp dụng sơ bộ cho Nova Foods mô phỏng: giữ kết quả IN_REVIEW. Bằng chứng quản trị xác nhận corpus dùng dữ liệu tổng hợp, chưa baseline và chưa có approval reference tại v0.9.0. Vì dependencies chỉ cung cấp metadata và source boundary, mọi rule cụ thể về dữ liệu cá nhân, hạch toán, hóa đơn, truy xuất thực phẩm hoặc quyền vận hành phải giữ Verification required cho đến khi owner có thẩm quyền xác minh.

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

Case Nova Foods Trading & Manufacturing là học liệu mô phỏng, chỉ dùng dữ liệu tổng hợp. Kết quả dưới đây là ghi nhận review trước baseline cho /03-templates/TMPL-WF-001-workflow-map-bpmn.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. PASS nghĩa là đủ bằng chứng trong artifact; FAIL nghĩa là có thiếu hoặc mâu thuẫn; STOP nghĩa là không được baseline phần bị ảnh hưởng; ESCALATE nghĩa là chuyển đúng owner thẩm quyền, không tự suy diễn.

ID kiểm tra	Kết quả	Bằng chứng và cầu nối suy luận	Finding ghi nhận	Hành động trước baseline
QG-WF-001 Hoàn chỉnh	FAIL	Tier 3 phải điền đủ luồng, quyết định, ngoại lệ và liên kết truy vết. Quy tắc này bảo đảm người đọc có thể lần từ bước BPMN về nguồn.	Không có bằng chứng trong dependency rằng mọi bước, gateway, ngoại lệ của case đã liên kết tới CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY.	Bổ sung liên kết canonical cho từng rule và dữ liệu; dừng baseline phần thiếu liên kết.
QG-WF-002 Nhất quán	PASS có điều kiện	Metadata corpus thống nhất: IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; Nova Foods là mô phỏng.	Không phát hiện xung đột metadata trong nguồn dependency đã cung cấp. Kết quả không xác nhận nội dung BPMN đã đúng.	Giữ nguyên metadata khi đối chiếu toàn bộ diagram và bảng Tier 3.
QG-WF-003 Khả năng kiểm thử	FAIL	Một workflow kiểm thử được khi mỗi luồng có đầu vào, điều kiện quyết định, đầu ra mong đợi và ngoại lệ quan sát được. ISTQB CTFL là nguồn thuật ngữ kiểm thử.	Dependency không chứng minh case hoàn chỉnh có test condition cho từng nhánh gateway, gồm nhánh từ chối và lỗi tích hợp.	Lập test basis gắn từng luồng; STOP nếu gateway không có tiêu chí quan sát được.
QG-WF-004 Truy vết	FAIL	TRACEABILITY_ID_REGISTRY là nguồn canonical cho ID; artifact không được tự tạo ID hoặc dùng biến thể.	Chưa có bằng chứng rằng mọi ID trong workflow đã được đăng ký và giữ nguyên dạng canonical.	Đối chiếu từng ID với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; ESCALATE khi ID thiếu, trùng hoặc mâu thuẫn.
QG-WF-005 Thẩm quyền nguồn	PASS có điều kiện	OMG BPMN 2.0.2 là nguồn chuẩn cho ký pháp BPMN. Nguồn pháp lý, kế toán và an toàn thực phẩm chỉ cho bối cảnh, không tự tạo nghĩa vụ ERP.	Không được gọi PlantUML activity diagram là BPMN; không được biến giả định Nova Foods thành điều khoản pháp lý.	STOP nếu diagram không dùng ký pháp BPMN hoặc nếu nguồn không có phân loại rõ.
QG-WF-006 Ownership	FAIL	Owner corpus chỉ quản trị artifact, không có quyền quyết định vận hành, pháp lý, kế toán, bảo mật hay baseline.	Vai trò chịu trách nhiệm cho quyết định nghiệp vụ, ngoại lệ tài chính và xác nhận xử lý dữ liệu cá nhân chưa có bằng chứng được ghi trong case.	ESCALATE Business Owner, Accounting Owner, Legal/Compliance Owner, Security Owner và Architect theo phạm vi quyết định.
QG-WF-007 Bảo mật, riêng tư, pháp lý, kế toán	STOP	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP là nguồn chính thức nhưng cần owner thẩm quyền xác minh yêu cầu áp dụng.	Không có bằng chứng xác minh rằng dữ liệu, chứng từ, phân quyền và lưu vết trong case đáp ứng nghĩa vụ thực tế. Case mô phỏng không chứng minh tuân thủ.	Không baseline các bước chạm dữ liệu cá nhân, hóa đơn, bút toán hoặc lưu trữ chứng từ trước khi có review chuyên môn được ghi nhận.
QG-WF-008 Ảnh hưởng thay đổi	FAIL	Đổi workflow có thể đổi rule, dữ liệu, test basis, phân quyền và tài liệu liên quan; vì vậy phải xác định impact trước baseline.	Chưa có bằng chứng impact analysis liên kết từ workflow tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và test artifact.	Lập impact record theo ID; STOP khi thay đổi làm đứt traceability hoặc đổi boundary thẩm quyền.

Kết luận review: Không có approval, baseline, compliance sign-off hoặc xác nhận sẵn sàng production. QG-WF-007 đặt trạng thái STOP; chỉ gỡ dừng sau khi bằng chứng và xác minh owner thẩm quyền được ghi trong artifact kiểm soát.

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

6.1 Ma trận kiểm tra mâu thuẫn liên tệp

Kiểm tra liên tệp nhằm bảo đảm TMPL-WF-001 không tự tạo nguồn chân lý mới. Nguồn chân lý là artifact được chỉ định giữ giá trị chuẩn cho một loại thông tin. Workflow map chỉ mô tả luồng công việc và liên kết đến rule, dữ liệu, ID, nguồn; không tự quyết định quy tắc nghiệp vụ, cấu trúc dữ liệu, nghĩa vụ pháp lý hay cấu hình ERP. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Điểm kiểm tra	Artifact hoặc consumer đối chiếu	Bằng chứng đối chiếu	Kết quả tại IN_REVIEW v0.9.0	Quy tắc xử lý mâu thuẫn
Danh tính template	/01-curriculum/TEMPLATE_MANIFEST.md; TEMPLATE_MANIFEST	Template manifest là nguồn quản trị danh mục template; tệp đang kiểm tra là /03-templates/TMPL-WF-001-workflow-map-bpmn.md.	Không được đổi TMPL-WF-001, tên tệp, IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh hoặc VND trong workflow map.	Dừng cập nhật nội dung nếu manifest ghi ID, đường dẫn hoặc metadata khác. Sửa tại artifact có thẩm quyền quản trị, không sửa im lặng bản sao.
ID và traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md; TRACEABILITY_ID_REGISTRY	Registry là nguồn canonical cho định danh và liên kết truy vết. Workflow map cần tham chiếu ID đã đăng ký, không tự đặt biến thể ID.	Mọi ID xuất hiện trong sơ đồ, bảng bước, exception, rule hoặc dữ liệu phải giữ nguyên chuỗi canonical. TMPL-WF-001 là ID artifact, không phải ID quy trình nghiệp vụ.	Không dùng ID chưa đăng ký như bằng chứng hoàn chỉnh. Không đổi tiền tố, số thứ tự hoặc ý nghĩa ID chỉ để khớp sơ đồ.
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md; CANONICAL_BUSINESS_RULES	Catalog quy tắc nghiệp vụ là nguồn chân lý cho điều kiện, quyết định, ngoại lệ và ràng buộc nghiệp vụ. BPMN chỉ biểu diễn nơi rule được áp dụng.	Không có cơ sở để workflow map tuyên bố một gateway, ngưỡng tiền, phê duyệt, thời hạn hay ngoại lệ là rule Nova Foods đã xác nhận.	Khi nhãn gateway khác rule canonical, rule canonical không bị ghi đè. Giữ liên kết rule và chuyển nội dung mâu thuẫn về catalog để kiểm soát.
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; CANONICAL_DATA_DICTIONARY	Data dictionary là nguồn chân lý cho tên dữ liệu, định nghĩa, kiểu logic, owner, phân loại và quan hệ dữ liệu.	Workflow map chỉ được gọi dữ liệu theo tên canonical đã có. Không suy ra field, bảng vật lý, API payload hoặc quyền truy cập từ một data object BPMN.	Nếu tên dữ liệu trong workflow khác dictionary, không hợp nhất bằng dịch tự do. Giữ tên canonical và sửa nhãn workflow hoặc dictionary qua kiểm soát thay đổi.
Cấu trúc học liệu	/01-curriculum/CHAPTER_MANIFEST.md; CHAPTER_MANIFEST; /01-curriculum/01_CURRICULUM_ARCHITECTURE.md; 01_CURRICULUM_ARCHITECTURE	Manifest chapter và curriculum architecture kiểm soát chuỗi học, dependency và ranh giới artifact.	TMPL-WF-001 là template bốn tier, không thay chapter, requirement specification, data model, test basis hay kiến trúc giải pháp.	Dừng khi template tạo mâu thuẫn chuỗi học, trùng nguồn chân lý hoặc biến ví dụ mô phỏng thành yêu cầu triển khai.
Ký pháp BPMN	BPMN 2.0.2, OMG	OMG BPMN 2.0.2 là nguồn chuẩn cho ký pháp BPMN. PlantUML activity diagram không được gọi là BPMN.	Chỉ mô tả là BPMN khi sơ đồ dùng đúng ngữ nghĩa BPMN; nếu dùng biểu diễn chữ hoặc activity diagram, phải gắn nhãn đúng loại biểu diễn.	Không đổi tên loại sơ đồ để tạo cảm giác tuân thủ. Điều chỉnh ký pháp hoặc hạ nhãn mô tả về loại sơ đồ thực tế.
Consumer hạ nguồn	Requirement, acceptance criteria, test basis, test case, backlog, API specification, data mapping và QA review	Consumer dùng workflow để hiểu trình tự, actor, decision point, exception và traceability; không được dùng nó làm bằng chứng approval hoặc compliance.	Workflow map hiện chỉ là đầu vào xem xét. Không đủ căn cứ tạo test pass, API contract, quyền production, bút toán, hóa đơn hoặc kết luận tuân thủ.	Consumer phải truy ngược tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, registry và nguồn có thẩm quyền trước khi dùng thông tin làm tiêu chí kiểm thử hay thiết kế.
Pháp lý, kế toán, riêng tư, an toàn thực phẩm	00_SOURCE_MAP; 00_SOURCE_MAP	Seed nguồn xác định Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 là nguồn chính thức, nhưng diễn giải áp dụng cần owner chuyên môn.	Không có workflow step nào được coi là nghĩa vụ pháp lý, kế toán, thuế, bảo vệ dữ liệu cá nhân hoặc truy xuất thực phẩm đã xác minh.	Giữ nhãn Verification required tại nội dung chạm phạm vi này; không chuyển nhãn thành kết luận tuân thủ dựa trên sơ đồ.

6.2 Tiêu chí kết luận kiểm tra

Một liên kết được xem là nhất quán khi năm yếu tố cùng khớp: ID giữ nguyên theo TRACEABILITY_ID_REGISTRY; đường dẫn và loại artifact khớp manifest; rule liên kết tồn tại trong CANONICAL_BUSINESS_RULES; dữ liệu liên kết tồn tại trong CANONICAL_DATA_DICTIONARY; consumer không diễn giải trạng thái IN_REVIEW thành baseline, approval, compliance hoặc production readiness. Thiếu một yếu tố thì liên kết chưa đủ điều kiện làm bằng chứng kiểm soát.

Không có mâu thuẫn được phép giải quyết bằng cách sửa nội dung nguồn canonical từ workflow map. Lý do: workflow map là artifact trình bày luồng, còn manifest, registry, rule catalog và data dictionary giữ thẩm quyền riêng. Khi hai artifact diễn đạt khác nhau, giữ nguyên bằng chứng gốc, ghi rõ điểm lệch theo ID và dùng artifact có thẩm quyền cho loại thông tin đó làm chuẩn đối chiếu.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. IN_REVIEW nghĩa là đang xem xét có kiểm soát, không phải đã phê duyệt, đã baseline, tuân thủ hay sẵn sàng production. Bảng này ghi toàn bộ điểm chưa thể kết luận trong phạm vi TMPL-WF-001; không biến khoảng trống thành quy tắc ERP.

Loại	Mã ảnh hưởng	Nội dung, bằng chứng và lập luận	Owner có thẩm quyền	Tác động	Hành động kế tiếp
Vấn đề mở	TMPL-WF-001, TEMPLATE_MANIFEST	Chưa có trích đoạn manifest xác nhận entry, phạm vi workflow cụ thể, dependency và downstream consumer của TMPL-WF-001. Vì manifest là nguồn danh mục canonical, template không tự suy ra quy trình được phép mô hình hóa.	Principal IT Business Analyst / Technical Curriculum Author	Có thể sai phạm vi, sai liên kết tệp hoặc tạo workflow không nằm trong kế hoạch corpus.	Đối chiếu entry TMPL-WF-001 tại /01-curriculum/TEMPLATE_MANIFEST.md; ghi nhận kết quả review có truy vết trước khi dùng template cho case hoàn chỉnh.
Vấn đề mở	TMPL-WF-001, TRACEABILITY_ID_REGISTRY	Chưa có workflow ID, process ID, event ID, gateway ID, rule ID hoặc data ID đã được cung cấp cho workflow Nova Foods. Registry là nguồn duy nhất quản lý định danh; tự đặt ID sẽ phá traceability.	Principal IT Business Analyst / Technical Curriculum Author; escalation nếu ID chạm Business, Architect, Security, Legal hoặc Accounting	Không thể liên kết ổn định BPMN, rule, dữ liệu, yêu cầu, test case và thay đổi.	Kiểm tra /01-curriculum/TRACEABILITY_ID_REGISTRY.md; chỉ dùng ID đã đăng ký. Nếu thiếu namespace, lập gói escalation, không tạo ID thay thế trong template.
Mục cần xác minh	TMPL-WF-001, CANONICAL_BUSINESS_RULES	Chưa có quy tắc canonical đã xác minh cho điều kiện gateway, phân quyền phê duyệt, ngưỡng tiền VND, ngoại lệ, hủy, hoàn tác hoặc thời hạn xử lý. BPMN 2.0.2 chuẩn hóa ký pháp, không xác nhận quy tắc nghiệp vụ Nova Foods.	Business Owner; Accounting Owner cho tiền và hạch toán; Legal Owner khi có nghĩa vụ pháp lý	Gateway có thể diễn đạt sai quyết định nghiệp vụ hoặc ngầm tạo nghĩa vụ tài chính, pháp lý.	Map từng điều kiện workflow tới ID đã có trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; giữ nhãn Verification required cho rule chưa có owner xác minh.
Mục cần xác minh	TMPL-WF-001, CANONICAL_DATA_DICTIONARY	Chưa có định nghĩa dữ liệu canonical cho đối tượng, trường bắt buộc, trạng thái, nguồn dữ liệu, chủ sở hữu dữ liệu và phân loại dữ liệu xuất hiện trên BPMN. Sơ đồ chỉ được ghi tên dữ liệu khi dictionary xác nhận nghĩa logic.	Data Owner; Security Owner nếu dữ liệu có phân loại hoặc quyền truy cập	Có thể nhầm dữ liệu logic với bảng ERP, lộ dữ liệu hoặc tạo trạng thái không nhất quán.	Đối chiếu /01-curriculum/CANONICAL_DATA_DICTIONARY.md; không ghi schema, API payload hay trường dữ liệu chưa có định nghĩa canonical.
Giả định dự án	TMPL-WF-001, CHAPTER_MANIFEST, 01_CURRICULUM_ARCHITECTURE	Giả định template phục vụ học BPMN và traceability trong corpus 26 chapter, không mô tả cấu hình ERP thực. Bằng chứng: manifest và architecture định vị corpus là controlled planning artifact, Nova Foods là mô phỏng.	Principal IT Business Analyst / Technical Curriculum Author	Learner có thể nhầm sơ đồ hoàn chỉnh với chỉ dẫn vận hành.	Giữ nhãn mô phỏng, dữ liệu tổng hợp và IN_REVIEW trên mọi bản dùng template; sửa giả định nếu manifest cấp phạm vi khác.
Mục cần xác minh	TMPL-WF-001, SRC-READY-010, SRC-READY-011	Bất kỳ lane, nhiệm vụ hay dữ liệu nào chạm hóa đơn, kế toán, thuế, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc cần xác minh chuyên môn. Nguồn seed nêu rõ luật và chuẩn không tự tạo requirement triển khai.	Legal Owner, Accounting Owner, Compliance Owner, Food-safety Domain Owner, Security Owner tùy nội dung	Rủi ro diễn đạt học liệu như nghĩa vụ pháp lý hoặc xác nhận tuân thủ.	Gắn Verification required, nguồn chính thức phù hợp và owner; không chuyển thành mandatory rule, control hoặc sign-off trong TMPL-WF-001.

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

Bàn giao có kiểm soát nghĩa là chuyển artifact cùng bằng chứng để vai trò nhận kiểm tra, không phải xác nhận nội dung đúng hay được phê duyệt. Lý do: IN_REVIEW tại v0.9.0 chỉ cho phép review có truy vết; không phải BASELINED, APPROVED, sẵn sàng production, tuân thủ pháp lý hoặc được người dùng chấp thuận. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, theo vi-VN, Asia/Ho_Chi_Minh, VND.

Mục bàn giao	Giá trị phải giữ nguyên	Bằng chứng và giới hạn
Artifact nhận bàn giao	/03-templates/TMPL-WF-001-workflow-map-bpmn.md	Giữ filename, TMPL-WF-001, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Không đổi tên hoặc tạo ID thay thế.
Nguồn định danh	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry là nguồn kiểm soát ID. Template chỉ tham chiếu ID đã có, không tự cấp ID mới.
Nguồn quy tắc	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Workflow chỉ biểu diễn quy tắc đã được liên kết; không biến diễn giải sơ đồ thành quy tắc canonical.
Nguồn dữ liệu	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên dữ liệu, nghĩa logic và phân loại dữ liệu phải theo từ điển; BPMN không quyết định cấu trúc DB hay API.
Nguồn cấu trúc template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Manifest kiểm soát vị trí và phạm vi template dự kiến; không là bằng chứng phê duyệt workflow.
Chuẩn ký pháp	BPMN 2.0.2 của OMG	Chỉ gọi sơ đồ là BPMN khi ký pháp phù hợp nguồn OMG. PlantUML activity diagram không phải BPMN.

Quy tắc lan truyền thay đổi: thay đổi chỉ bắt đầu từ artifact nguồn có thẩm quyền với loại thông tin đó. Nếu đổi ID, kiểm tra TRACEABILITY_ID_REGISTRY trước; nếu đổi business rule, kiểm tra CANONICAL_BUSINESS_RULES; nếu đổi trường dữ liệu hoặc nghĩa dữ liệu, kiểm tra CANONICAL_DATA_DICTIONARY; nếu đổi filename, phạm vi hoặc quan hệ template, kiểm tra TEMPLATE_MANIFEST. Lý do: một khái niệm có nhiều nguồn chân lý sẽ làm đứt traceability, nghĩa là khả năng lần ngược từ sơ đồ đến nguồn kiểm soát.

Loại thay đổi phát hiện	Phạm vi lan truyền tối thiểu	Hành động bắt buộc
Đổi hoặc hủy ID liên kết	TMPL-WF-001, artifact tham chiếu ID, TRACEABILITY_ID_REGISTRY	Dừng dùng ID cũ trong nội dung mới; ghi nhận quan hệ ID cũ và ID thay thế tại nguồn registry; rà soát mọi liên kết trước khi bàn giao lại.
Đổi rule ảnh hưởng gateway, task hoặc exception	TMPL-WF-001, CANONICAL_BUSINESS_RULES, chapter hoặc template dùng cùng rule	Cập nhật flow, điều kiện quyết định, exception và traceability cùng một đợt review; không sửa riêng sơ đồ để tạo rule mới.
Đổi nghĩa dữ liệu workflow nhận, tạo, đọc hoặc cập nhật	TMPL-WF-001, CANONICAL_DATA_DICTIONARY, consumer dữ liệu liên quan	So khớp tên, nghĩa, nguồn và phân loại dữ liệu; chuyển Security, Legal, Accounting hoặc Business Owner khi thay đổi thuộc thẩm quyền họ.
Đổi ký pháp BPMN hoặc cách diễn đạt chuẩn	TMPL-WF-001 và tài liệu hướng dẫn liên quan	Đối chiếu BPMN 2.0.2; không suy diễn compliance hoặc cấu hình ERP từ ký pháp.
Đổi nội dung có tác động pháp lý, kế toán, thuế, riêng tư, an toàn thực phẩm hoặc production	Artifact bị ảnh hưởng và owner chuyên môn	Giữ nhãn Verification required hoặc Project assumption; Principal IT Business Analyst / Technical Curriculum Author lập gói truy vết, không tự kết luận chuyên môn.

Gói bàn giao phải nêu: artifact nguồn, artifact nhận tác động, ID liên quan, lý do thay đổi, bằng chứng nguồn, trạng thái kiểm tra liên kết và owner xử lý. Không được sửa im lặng, sửa đè lịch sử, gắn APPROVED, gắn BASELINED, hoặc diễn đạt Nova Foods đã vận hành quy trình này. Principal IT Business Analyst / Technical Curriculum Author giữ vai trò điều phối và bảo toàn traceability; Business Owner quyết định nghiệp vụ, Architect quyết định kiến trúc, QA xác nhận kiểm thử, Legal/Compliance diễn giải nghĩa vụ pháp lý, Accounting Owner quyết định kế toán và thuế.