Sheet 8 · Use Case Specifications
Đặc tả Use Case
Đặc tả chi tiết các yêu cầu chức năng: vai trò (Role), điều kiện tiên quyết, luồng hoạt động chính/phụ và điểm kiểm soát dữ liệu. Hệ thống gồm 30 Use Cases chia theo 4 nhóm chuẩn (Manage / Workflow & Delivery / Tài chính & Kế toán / Other). Ba Use Case then chốt được đặc tả đầy đủ 6 khối chuẩn theo tiêu chuẩn ISO/IEEE/BMAD.
8
UC Dữ liệu nền & Thiết lập
10
UC Vận hành & Delivery
7
UC Tài chính & Kế toán
5
UC Hệ thống & Bảo mật
1. Danh mục 30 Use Cases toàn hệ thống
1.1. Nhóm Manage — Dữ liệu nền & Cấu hình 8 UC
| ID | Tên Use Case | Vai trò chính | Module liên quan |
|---|---|---|---|
| UC 01 | Xem / tạo / sửa Hồ sơ Đối tác (Contact) & Gắn tag ngành, giải pháp | Sales, Admin | /crm |
| UC 02 | Quản lý Nhà cung cấp (Vendors AP) & Hợp đồng đối tác | Kế toán chi, Admin | /vendors |
| UC 03 | Thiết lập Thông tin Doanh nghiệp & Mẫu hoá đơn | Admin | /settings |
| UC 04 | Quản trị Tài khoản người dùng & Phân quyền Module (RBAC) | Admin | /settings (tab Users) |
| UC 05 | Đấu nối Email per-user qua Google Apps Script Web App | Member, Admin | /mail |
| UC 06 | Quản trị Chatbot Telegram & Whitelist Token | Admin | /bots |
| UC 07 | Quản lý Kho tài liệu dùng chung (Library Boards & Items) | Admin, Member | /library |
| UC 08 | Quản lý Sổ tay Kỹ năng chuẩn hoá (Skills & SOP Versioning) | Admin, Member | /skills |
1.2. Nhóm Workflow & Delivery — Vòng đời Dự án & Công việc 10 UC
| ID | Tên Use Case | Vai trò chính | Module liên quan |
|---|---|---|---|
| UC 09 | Tiếp nhận Lead tự động từ Ingest API / HubSpot Sync | Hệ thống, Sales | /crm |
| UC 10 | Lập Báo giá per-user (Pricing BG-*) & Gửi khách | Sales Lead | /pricing |
| UC 11 | Chốt Deal & Khởi tạo Dự án (dealStage: won → status: planning) | Sales Lead, BOD | /projects |
| UC 12 | Bóc tách WBS Deliverables & Sinh Task tự tăng CTC-* | Project Manager | /tasks |
| UC 13 | Phân công nhân sự & Gắn tag 3 chiều (gp:, nganh:, viec:) | PM, Lead | /tags |
| UC 14 | Thực thi công việc trên Kanban & Chế độ Focus Mode | Developer, Member | /tasks, /focus |
| UC 15 | Ghim Comment toạ độ & Review đa tầng (@mention) | Reviewer, QA | Review Layer |
| UC 16 | Cấu hình Quy trình tự động hoá (React Flow Canvas) | PM, Tech Lead | /workflows |
| UC 17 | Gửi Đề xuất / Yêu cầu phát triển tính năng (Dev Requests) | Mọi nhân sự | /requests |
| UC 18 | Nghiệm thu Deliverable & Đóng dự án (Project Acceptance) | PM, BOD | /projects/[id] |
1.3. Nhóm Finance — Tài chính, Hoá đơn & Dòng tiền 7 UC
| ID | Tên Use Case | Vai trò chính | Module liên quan |
|---|---|---|---|
| UC 19 | Xuất Hoá đơn GTGT (CTC-INV-*) & Quét ảnh OCR | Kế toán doanh thu | /invoices |
| UC 20 | Ghi nhận Giao dịch Thu / Chi thực tế | Kế toán viên | /finance |
| UC 21 | Cấu hình Khoản định kỳ tự sinh hàng tháng (Recurrences) | Kế toán chi phí | /finance |
| UC 22 | Duyệt chi Hợp đồng Nhà cung cấp > 5.000.000đ | Ban Giám đốc (BOD) | /vendors |
| UC 23 | Đối soát công nợ phải thu AR & Cảnh báo hoá đơn quá hạn | Kế toán trưởng | /finance, /invoices |
| UC 24 | Tính hoa hồng dự án & Thuế TNCN (Income Module 2026) | Member, Kế toán | /income |
| UC 25 | Xem Báo cáo Lãi Lỗ (P&L) dự án & Tỷ trọng Doanh thu | Admin, BOD | /dashboard, /reports |
1.4. Nhóm Other — Xác thực, Tìm kiếm & Audit 5 UC
| ID | Tên Use Case | Vai trò chính | Module liên quan |
|---|---|---|---|
| UC 26 | Đăng nhập / Đăng xuất qua Cookie ode_sess | Mọi người dùng | /login |
| UC 27 | Tự đổi mật khẩu tài khoản cá nhân | Mọi người dùng | /account |
| UC 28 | Tìm kiếm toàn cục ⌘K (Không dấu, Phân quyền scope) | Mọi người dùng | /search, ⌘K |
| UC 29 | Xem Nhật ký thay đổi hệ thống (System Log & Revision Diff) | Admin, Member | /system-log |
| UC 30 | Đấu nối Webhook Relay an toàn (Telegram / GWS Whitelist) | Mọi người dùng | /settings (Relay) |
1b. Use Case bổ sung — trợ lý ngoài & các tính năng thêm 03/09/2026
| Mã | Use Case | Tác nhân | Luồng chính |
|---|---|---|---|
| UC-31 | Trợ lý ngoài dựng kỹ năng nháp | Nhân sự qua trợ lý AI (Claude Code / antigravity / bot Telegram) | Người dùng mô tả kỹ năng bằng lời với trợ lý → trợ lý soạn JSON đúng lược đồ → gọi POST /api/agent/action action tao_ky_nang kèm header X-Agent-Key → ERP kiểm khoá, suy ra chủ sở hữu, kiểm phân hệ skills bằng hasModule, cắt bớt trường theo kiểu và độ dài rồi lưu thành kỹ năng trạng thái nháp → trả câu xác nhận kèm mã. Người dùng vào ERP đọc lại và sửa. Ngoại lệ: thiếu phân hệ → 403 kèm missingModule; quá 40 bản/24 giờ → 429; JSON sai → từ chối tử tế, không tạo gì. |
| UC-32 | Trợ lý ngoài dựng quy trình tự động nháp | Như trên | Giống UC-31 với action tao_quy_trinh và phân hệ workflows. Quy trình sinh ra luôn TẮT — nó chạy nền và ghi vào dữ liệu thật nên việc bật thuộc về người, sau khi đọc. |
| UC-33 | Chia sẻ kỹ năng cho đồng nghiệp theo mức | Chủ sở hữu kỹ năng | Mở kỹ năng → khối "Chia sẻ cho đồng nghiệp" → chọn mức cho từng người: Không · Xem · Sửa (mỗi người đúng một mức) → lưu ngay, không đi qua nháp. Người mức Sửa đổi được nội dung nhưng không đổi được chia sẻ, không phát hành, không xoá — server bỏ qua lặng lẽ nếu họ gửi các trường đó lên. |
| UC-34 | Phát hành kỹ năng cho trợ lý của một người | Chủ sở hữu kỹ năng | Khối "Phát hành cho trợ lý của" liệt kê các khoá API kèm tên chủ khoá → tích chọn → ghi vào bot_api_keys.skill_ids qua POST /api/api-keys/by-skill. Ai chưa có khoá hiện tách riêng kèm nhắc cấp khoá. Khác UC-33: chia sẻ cho một người không làm trợ lý của họ biết kỹ năng, và ngược lại. |
| UC-35 | Đổi hình nền bằng ảnh của mình | Mọi nhân sự | Cài đặt → Giao diện → chọn áp dụng cho Cả hai/Ngày/Đêm → bấm "Tải ảnh từ máy" hoặc kéo thả ảnh → POST /api/wallpaper (multipart, ≤8MB) → server lưu tệp mang id chủ ảnh, trả đường dẫn nội bộ → áp ngay. Ảnh chỉ chính chủ xem được, kể cả quản trị cũng không. Giữ 3 tệp gần nhất rồi tự dọn. |
| UC-36 | Sửa một sự kiện thuộc chuỗi lặp | Mọi nhân sự | Mở sự kiện có lịch lặp → sửa giờ/nội dung → hệ thống hỏi phạm vi: chỉ lịch hôm đó · lịch này và các lịch sau · toàn bộ chuỗi. Chọn "này và sau" hoặc "toàn bộ" thì các trường chung áp cho cả nhóm và eventRecurrences đồng bộ theo; ngày thì chỉ đổi đúng lịch đang sửa. |
| UC-37 | Sửa việc ngay trong phiên Tập trung | Mọi nhân sự | Trong màn Tập trung, bấm Tạm dừng → bấm vào đồng hồ, tiêu đề hoặc mô tả để sửa. Rời ô là lưu, Esc huỷ. Chạy tiếp hoặc chuyển việc thì ô đang sửa tự đóng để không ghi nhầm sang việc khác. Đang chạy thì các ô khoá — màn đó là chỗ làm việc, không phải chỗ soạn thảo. |
| UC-38 | Thu hồi toàn bộ phiên đăng nhập | Owner (ERP_OWNERS) | Nghi ngờ rò rỉ → POST /api/me/sessions/revoke-all → server tăng session_ver của mọi tài khoản trong tenant → mọi cookie đang có mất hiệu lực ngay vì chữ ký phiên phủ cả cột đó. |
Đã gỡ: use case "Dựng kỹ năng/quy trình bằng AI ngay trong ERP" không còn — tính năng đó thêm và gỡ trong cùng ngày 03/09/2026 vì nó cho mọi tài khoản đăng nhập chạy lệnh tuỳ ý dưới unix user
erp. Thay bằng UC-31 và UC-32.2. Đặc tả đầy đủ 3 Use Cases mẫu then chốt (6 khối chuẩn)
UC 12 · Bóc tách WBS Deliverables & Sinh Task tự tăng CTC-* Reference Spec
| Mục tiêu (Objective) | Chuyển giao mục tiêu dự án thành các gói sản phẩm bàn giao (Deliverables) và công việc cụ thể (Tasks), sinh mã tự tăng CTC-n duy nhất toàn tenant. |
| Vai trò chính | Project Manager (PM) / Tech Lead |
| Trigger | Dự án được phê duyệt triển khai (status: planning hoặc active) |
| Điều kiện tiên quyết | Dự án đã tồn tại trên hệ thống; người dùng có quyền module tasks và projects. |
| Điều kiện sau khi xong | Danh sách task mới được khởi tạo ở cột todo; bộ đếm taskCounter tăng lên; cập nhật realtime qua SSE cho mọi tab. |
| User Story | CTC-ERP-UC12: "Là PM, tôi muốn bóc tách nhanh công việc cho dự án kèm tiêu chí nghiệm thu để đội ngũ thực thi chính xác." |
Luồng hoạt động (Activity Flow)
- PM mở màn hình Danh sách Công việc (
/tasks) hoặc mở tab Công việc trong chi tiết Dự án (/projects/[id]). - PM bấm nút "Thêm công việc" (hoặc dùng phím tắt
N/ nút nhanh trên đầu cộttodo). - Hệ thống mở Panel / Modal tạo Task: Tự động điền
projectIdvàcontactIdnếu đi từ trang Dự án. - PM nhập các trường thông tin:
- Tiêu đề task (Bắt buộc): Tên sản phẩm bàn giao / deliverable rõ ràng.
- Mô tả & Checklist (Bắt buộc): Tiêu chí nghiệm thu (Definition of Done), checklist các bước con.
- Người phụ trách: Chọn từ danh sách
auth_usersthuộc tenant. - Hạn hoàn thành (Due date) & Độ ưu tiên:
urgent / high / medium / low. - Tag phân loại: Chọn tag
gp:*(giải pháp) vàviec:*(loại lao động).
- PM bấm "Tạo công việc":
- Hệ thống validate tính hợp lệ (tiêu đề không rỗng, due date hợp lệ).
- Hệ thống lấy
taskCounterhiện tại (ví dụ: 76), tăng lên 77 và gánkey: "CTC-77". - Hệ thống ghi bản ghi mới vào blob
tasks[], tăngrevvà phát sinh sự kiện SSEstate_update. - Hiển thị thông báo thành công
SM1("Đã tạo công việc CTC-77 thành công").
Đặc tả giao diện màn hình (Screen Spec)
| # | Thành phần UI | Loại control | Bắt buộc | Mô tả / Ràng buộc |
|---|---|---|---|---|
| 1 | [Tiêu đề công việc] | Text Input | Có (Y) | Tối đa 255 ký tự; không được chỉ chứa khoảng trắng. |
| 2 | [Dự án liên kết] | Select / Autocomplete | Tuỳ chọn | Lọc từ danh sách projects[] đang mở. |
| 3 | [Người phụ trách] | User Select | Tuỳ chọn | Mặc định là người tạo nếu không chọn người khác. |
| 4 | [Hạn hoàn thành] | Date Picker | Tuỳ chọn | Mặc định cuối tuần hiện tại nếu không chọn. |
| 5 | [Độ ưu tiên] | Dropdown / Badge | Có (Y) | Mặc định là medium. |
| 6 | [Checklist con] | Dynamic List | Tuỳ chọn | Mỗi item có checkbox + text, mặc định mảng rỗng []. |
| 7 | "Tạo công việc" | Button Primary | — | Thực thi lưu và đóng form. |
Quy tắc nghiệp vụ (Business Rules)
| Mã BR | Mô tả quy tắc | Hành động khi vi phạm |
|---|---|---|
| BR 1.1 | Tiêu đề task không được để trống hoặc chỉ có khoảng trắng. | Báo lỗi inline IEM3 ("Trường này là bắt buộc"). |
| BR 1.2 | Mã task key phải duy nhất toàn tenant và có định dạng <PREFIX>-<counter> (ví dụ: CTC-77). | Hệ thống tự sinh, không cho phép client tự chỉ định key. |
| BR 1.3 | Khi khởi tạo, mảng subtasks, tags, links bắt buộc phải là mảng rỗng [] (không được undefined/null). | Server-side sanitizer tự ép kiểu mảng rỗng trước khi lưu. |
UC 19 · Xuất Hoá đơn GTGT & Quét OCR Hoá đơn đầu vào Reference Spec
| Mục tiêu (Objective) | Phát hành hoá đơn GTGT bán hàng cho đối tác, quản lý line-items thuế suất, và hỗ trợ quét ảnh OCR hoá đơn đầu vào từ nhà cung cấp. |
| Vai trò chính | Kế toán Doanh thu / Kế toán trưởng |
| Trigger | Đến mốc thanh toán hợp đồng hoặc nhận hoá đơn đầu vào từ Vendor. |
| Điều kiện tiên quyết | Người dùng có quyền module invoices; đối tác đã có hồ sơ Contact trên hệ thống. |
| Điều kiện sau khi xong | Hoá đơn chuyển sang trạng thái sent hoặc paid; ghi nhận vào sổ công nợ AR; tự sinh giao dịch thu nếu mark-paid. |
| User Story | CTC-ERP-UC19: "Là kế toán, tôi muốn xuất hoá đơn có đầy đủ line-items và scan OCR nhanh hoá đơn chi phí để theo dõi công nợ chính xác." |
Luồng hoạt động (Activity Flow)
- Kế toán mở màn hình Báo giá & Hoá đơn (
/invoices). - Chọn "Tạo hoá đơn mới" hoặc chọn "Quét hoá đơn (OCR)".
- Nhánh tạo tay: Nhập khách hàng, mã số thuế, địa chỉ, chọn ngày xuất và hạn thanh toán.
- Nhánh quét OCR: Upload ảnh/PDF hoá đơn → Hệ thống gọi OCR engine bóc tách: Số HĐ, Ngày lập, MST bên bán/mua, Tổng tiền trước thuế, Tiền thuế GTGT, Tổng thanh toán → Tự điền vào form.
- Kế toán chỉnh sửa các dòng hàng hoá/dịch vụ (Line items):
- Nhập Tên hàng hoá/dịch vụ, Đơn vị tính, Số lượng, Đơn giá, Thuế suất (0%, 5%, 8%, 10%).
- Hệ thống tự tính: Thành tiền = Số lượng × Đơn giá; Tiền thuế = Thành tiền × Thuế suất; Tổng cộng.
- Kế toán bấm "Lưu & Phát hành":
- Hệ thống sinh số hoá đơn dạng
CTC-INV-YYYY-NNNN. - Trạng thái hoá đơn chuyển thành
sent(đã gửi cho khách). - Cập nhật số dư công nợ phải thu (AR) của đối tác.
- Hệ thống sinh số hoá đơn dạng
- Khi khách thanh toán: Kế toán bấm nút "Đánh dấu đã thanh toán (Mark Paid)" → Hệ thống tự động sinh 1 bản ghi giao dịch thu (
Transaction type: income) trong sổ tài chính.
Quy tắc nghiệp vụ (Business Rules)
| Mã BR | Mô tả quy tắc | Hành động khi vi phạm |
|---|---|---|
| BR 2.1 | Mã số thuế doanh nghiệp phải đúng định dạng 10 số hoặc 13 số (chi nhánh). | Báo lỗi inline IEM4 ("Mã số thuế không đúng định dạng"). |
| BR 2.2 | Hoá đơn có ít nhất 1 dòng hàng hoá với số lượng > 0 và đơn giá ≥ 0. | Báo lỗi EM1 ("Hoá đơn phải có ít nhất 1 mặt hàng hợp lệ"). |
| BR 2.3 | Hoá đơn quá hạn thanh toán (hôm nay > dueDate và chưa trả đủ) tự động chuyển tag cảnh báo màu đỏ overdue. | Hệ thống tự tính toán và hiển thị trên Dashboard AR. |
UC 11 · Chốt Deal & Khởi tạo Dự án từ Phễu Bán hàng Reference Spec
| Mục tiêu (Objective) | Chuyển đổi cơ hội bán hàng thành công sang dự án thực thi, đồng bộ doanh số và thiết lập hồ sơ dự án chính thức. |
| Vai trò chính | Phòng Sales & Ban Giám đốc (BOD) |
| Trigger | Đối tác ký kết hợp đồng dịch vụ hoặc chuyển khoản tiền cọc đợt 1. |
| Điều kiện tiên quyết | Hồ sơ đối tác đã tồn tại; đã có báo giá hoặc thoả thuận giá trị hợp đồng. |
| Điều kiện sau khi xong | Project được tạo mới với dealStage: won và status: planning; doanh số được ghi nhận vào KPI; gửi thông báo nội bộ. |
| User Story | CTC-ERP-UC11: "Là Sales Lead, tôi muốn chốt deal và chuyển nhanh sang dự án triển khai để không bị gián đoạn khâu bàn giao." |
Luồng hoạt động (Activity Flow)
- Sales mở màn hình Phễu Bán hàng / Dự án (
/projectsở chế độ Phễu Deal). - Kéo thẻ Deal từ cột
negotiationsang cộtwon(hoặc mở form sửa Project và đổidealStage: won). - Hệ thống hiển thị Modal xác nhận Chốt Deal:
- Yêu cầu xác nhận giá trị hợp đồng chính thức (
dealValue). - Chọn ngày bắt đầu dự án và ngày bàn giao dự kiến.
- Đính kèm file hợp đồng đã ký hoặc link tài liệu trên Google Drive.
- Yêu cầu xác nhận giá trị hợp đồng chính thức (
- Sales bấm "Xác nhận Chốt Deal":
- Hệ thống cập nhật
dealStage = 'won', giữ nguyên hoặc chuyểnstatus = 'planning'. - Hệ thống tự động kích hoạt Workflow Relay: gửi tin nhắn chúc mừng chốt deal tới nhóm Telegram công ty qua
/api/me/relay/telegram. - Giá trị hợp đồng được cộng dồn vào tổng giá trị đối tác (Rollup Contract Value) trên màn hình
/crm. - Thông báo tới Ban Giám đốc để thực hiện phân công nhân sự (Pha 4 trong quy trình).
- Hệ thống cập nhật
Quy tắc nghiệp vụ (Business Rules)
| Mã BR | Mô tả quy tắc | Hành động khi vi phạm |
|---|---|---|
| BR 3.1 | Chỉ tài khoản có vai trò admin hoặc Sales phụ trách deal mới được chuyển trạng thái won/lost. | Từ chối thao tác, báo lỗi EM4 ("Bạn không có quyền chốt deal này"). |
| BR 3.2 | Deal chuyển won bắt buộc phải có giá trị hợp đồng dealValue > 0. | Báo lỗi inline IEM5 ("Giá trị hợp đồng phải lớn hơn 0"). |
| BR 3.3 | Tổng giá trị đối tác (Rollup) luôn bằng tổng dealValue của các dự án chưa lost gắn với đối tác đó. | Hệ thống tự tính realtime trên client, không cho sửa tay. |
UC 16 · Thiết kế & Kích hoạt Quy trình Tự động hoá (Workflow Automation Canvas) Reference Spec
| Mục tiêu (Objective) | Xây dựng kịch bản tự động hoá liên phòng ban bằng canvas kéo-thả (Trigger → Filter → Actions), kích hoạt realtime hoặc theo lịch quét định kỳ. |
| Vai trò chính | Quản lý vận hành / Trưởng bộ phận (Workflow Owner) |
| Trigger | Nhân sự muốn tự động hoá chuỗi thao tác lặp lại (ví dụ: Chốt deal tự động tạo task Kickoff và bắn tin Telegram). |
| Điều kiện tiên quyết | Tài khoản có quyền truy cập module workflows; các kênh relay (Telegram/GWS) đã cấu hình nếu sử dụng action đối ngoại. |
| Điều kiện sau khi xong | Workflow được lưu và kích hoạt (is_active = true); engine client-side lắng nghe sự kiện; server snapshot 1 phiên bản mới trong lịch sử 10 bản. |
| User Story | CTC-ERP-UC16: "Là Trưởng dự án, tôi muốn tự vẽ kịch bản tự động hoá để hệ thống tự giao việc cho team và bắn tin cảnh báo khi có sự kiện quan trọng." |
Luồng hoạt động (Activity Flow)
- Mở danh bạ Quy trình (
/workflows): Bấm nút "Tạo quy trình mới" hoặc chọn 1 trong 5 mẫu dựng sẵn (Templates W1-W5). - Chuyển sang Visual Canvas (
/workflows/[id]):- Cấu hình Trigger Node: Chọn loại
status_change(bắt đối tượng Task/Project/Invoice đổi trạng thái) hoặcdaily_scan(quét hạn hoá đơn, việc quá hạn, trạng thái ngâm lâu). - Thêm Condition Node: Kéo dây nối từ Trigger; thiết lập bộ lọc logic (ví dụ:
tags has gp:ctc-ai-transform). - Thêm Action Nodes: Nối các hành động cần thực thi:
- Action 1:
create_taskvới tiêu đề[Kickoff] {name}, hạn sau 3 ngày, gán cho phụ trách dự án. - Action 2:
send_telegramvới nội dung🎉 Dự án {name} đã chốt! Team chuẩn bị kickoff..
- Action 1:
- Cấu hình Trigger Node: Chọn loại
- Kiểm thử & Lưu quy trình:
- Bấm nút "Chạy thử (Test Run)" để kiểm tra luồng logic và cấu trúc biến thay thế.
- Bật toggle "Kích hoạt (Active)" và bấm "Lưu quy trình".
- Hệ thống lưu cấu trúc toạ độ Graph
WorkflowGraphDeflên server và chuyển đổi sang cấu trúc phẳngWorkflowDefcho Engine chạy.
- Engine thực thi & Chống lặp 3 lớp:
- Khi sự kiện thoả mãn, Engine kiểm tra Fired Key per-user trong
user_data(Lớp 1). - Engine kiểm tra tag ẩn
wf:<id>:<key>trong store trước khi tạo task (Lớp 2). - Engine thực thi hành động và gửi bản ghi log lên server qua
POST /api/workflow-runs.
- Khi sự kiện thoả mãn, Engine kiểm tra Fired Key per-user trong
Quy tắc nghiệp vụ (Business Rules)
| Mã BR | Mô tả quy tắc | Hành động khi vi phạm |
|---|---|---|
| BR 4.1 | Một quy trình bắt buộc phải có đúng 1 Trigger Node hợp lệ trước khi cho phép bật Active. | Báo lỗi inline IEM6 ("Quy trình phải có ít nhất 1 sự kiện kích hoạt"). |
| BR 4.2 | Mỗi mốc sự kiện trong ngày của 1 đối tượng chỉ được kích hoạt Action đúng 1 lần (Idempotency). | Engine tự chặn ở Lớp 1 Fired-key, không bắn lặp. |
| BR 4.3 | Người được chia sẻ (Viewer) chỉ có quyền Xem và Nhân bản (Clone), không được sửa Canvas gốc. | Ẩn các nút chỉnh sửa/lưu trên giao diện đối với Viewer. |
UC 08 · Biên soạn Sổ tay Kỹ năng (SOP) & Yêu cầu Phát hành Phiên bản mới Reference Spec
| Mục tiêu (Objective) | Chuẩn hoá tri thức vận hành (Sales, Tech, Content, Ops, Finance) thành Sổ tay SOP chi tiết và quản trị phê duyệt phát hành phiên bản chính thức. |
| Vai trò chính | Chuyên viên nghiệp vụ (Tác giả) & Ban Giám đốc / Dev Lead (Phê duyệt) |
| Trigger | Doanh nghiệp có quy trình mới cần chuẩn hoá hoặc nâng cấp cẩm nang thực thi. |
| Điều kiện tiên quyết | Tài khoản có quyền truy cập module skills và requests. |
| Điều kiện sau khi xong | SOP được phê duyệt, lưu snapshot phiên bản vX.Y (tối đa 20 bản), và phát hành công khai (published = true) cho toàn công ty. |
| User Story | CTC-ERP-UC08: "Là nhân sự chuyên môn, tôi muốn số hoá quy trình làm việc chuẩn thành cẩm nang Kỹ năng để đồng nghiệp cùng tuân thủ nhất quán." |
Luồng hoạt động (Activity Flow)
- Tác giả mở module Kỹ năng (
/skills):- Bấm nút "Tạo kỹ năng mới" hoặc "Nhập từ file Markdown (.md)".
- Nếu nhập Markdown, hệ thống tự động bóc tách: H1 thành Tên kỹ năng, Text mở đầu thành Tóm tắt (Summary), H2 thành Các bước thực hiện (Steps), Checkbox
- [ ]thành Checklist nghiệm thu, Link thành Tài nguyên (Resources). - Tác giả rà soát và lưu kỹ năng ở trạng thái
status = 'draft'(Bản nháp cá nhân).
- Gửi Yêu cầu Phát hành (
/requests):- Tác giả chuyển sang trang
/requests, bấm "Gửi yêu cầu mới". - Chọn loại
kind: 'skill', tiêu đề "Đề xuất phát hành SOP Bóc tách Deliverables v1.2", liên kếttargetIdtới kỹ năng vừa soạn. - Yêu cầu được khởi tạo ở trạng thái
status: 'new'.
- Tác giả chuyển sang trang
- Admin / BOD Tiếp nhận & Thẩm định:
- Admin mở yêu cầu, xem trước nội dung kỹ năng, chuyển trạng thái sang
reviewing(khoá quyền sửa của tác giả). - Admin đóng góp ý kiến qua trường
reviewNote(hỗ trợ @mention tác giả).
- Admin mở yêu cầu, xem trước nội dung kỹ năng, chuyển trạng thái sang
- Phê duyệt & Phát hành Chính thức:
- Admin bấm "Phê duyệt & Phát hành", nhập số hiệu phiên bản
releasedVersion = 'v1.2'. - Hệ thống tự động bật cờ
published = true, chuyểnstatus = 'active'của Kỹ năng. - Server tự động snapshot toàn bộ nội dung
defvào lịch sửversions[](lưu 20 phiên bản). - Trạng thái yêu cầu chuyển thành
released; thông báo chúc mừng được gửi tới tác giả.
- Admin bấm "Phê duyệt & Phát hành", nhập số hiệu phiên bản
Quy tắc nghiệp vụ (Business Rules)
| Mã BR | Mô tả quy tắc | Hành động khi vi phạm |
|---|---|---|
| BR 5.1 | Kỹ năng chỉ được phát hành toàn công ty (published=true) khi có sự phê duyệt của Admin qua Dev Request. | Thành viên không thể tự ý bật cờ published cho kỹ năng chưa duyệt. |
| BR 5.2 | Mỗi khi nội dung def của Kỹ năng thay đổi, server bắt buộc phải lưu lại 1 phiên bản snapshot có timestamp. | Hệ thống tự động lưu vào versions[] (giữ tối đa 20 bản gần nhất). |
| BR 5.3 | Người gửi chỉ được phép sửa nội dung yêu cầu phát triển khi yêu cầu còn ở trạng thái new. | Từ chối thao tác sửa khi yêu cầu đã chuyển sang reviewing hoặc approved. |