J.Garden — Hệ thống Quản lý Dự án Cảnh quan & Xây dựng

Brief story phục vụ prototype và quotation

Tài liệu này là bản phân tích yêu cầu sơ bộ (brief story), phục vụ lập kế hoạch prototype, phân rã feature, và báo giá. Đây không phải PRD chính thức cho production.

Ngày: 2026-06-26

Bảng tổng hợp module & ước lượng sơ bộ

1. Bối cảnh khách hàng

1.1 Về J.Garden

J.Garden (tên đầy đủ: công ty cảnh quan & xây dựng) là doanh nghiệp chuyên thi công cảnh quan (landscape), bảo trì bảo dưỡng (BTBD), và thiết kế vườn tại Việt Nam. Quy mô ~50–80 nhân sự, chia thành 10 phòng/khối chức năng:

1.2 Hiện trạng & Pain point

• Phần mềm hiện tại: VSC-PO (cài trên server thuê ngoài, truy cập qua IP) — không trực quan, không rõ ràng cho BOD/Kế toán.
• Quản lý song song trên Excel + Zalo — thông tin bị trôi, file không naming rõ ràng, BOD/Kế toán không biết yêu cầu vật tư nằm trong hay ngoài phạm vi.
• Đứt gãy thông tin giữa các phòng ban — đặc biệt khâu mua hàng: Ban Chỉ Huy không biết khi nào hàng được mua về.
• Tài liệu đính kèm lộn xộn — người duyệt phải mở từng file đoán nội dung.
• Không có quản lý thầu phụ — thiếu theo dõi tiến độ và thanh toán theo % hoàn thành.
• Không cần migrate dữ liệu cũ — dự án cũ vẫn chạy trên hệ thống cũ; hệ thống mới chỉ cho dự án mới.

1.3 Mong muốn

Một hệ thống đóng khung quy trình chặt chẽ — ép người dùng đi đúng workflow & template, không cho đi tắt, tài liệu phân loại rõ ràng theo danh mục.

2. Phạm vi & ranh giới dữ liệu

2.1 Trong phạm vi (In-scope)

• Quản lý dự án cảnh quan từ nhận BOQ → bóc tách → KHCP → thi công → thanh lý

• 7 loại phiếu đề xuất + phiếu yêu cầu + báo giá mua hàng + ĐNTT (lương & mua hàng)

• Quản lý NCC, vật tư, danh mục vật liệu

• Quản lý nhà thầu phụ (portal báo cáo tiến độ)

• Giao nhận hàng hóa + biên bản xác nhận

• Dashboard tổng quan cho BOD & Kế toán

• Quản lý tổ chức, phòng ban, phân quyền theo role + dự án

• Phần mềm chat nội bộ realtime — thay Zalo, kiểm soát thông tin nội bộ

• Quản lý dự án & công việc trong chat — giao task, set deadline, theo dõi tiến độ trực tiếp từ chat

• Dashboard & tìm kiếm thông minh — tổng quan nhanh, tìm kiếm xuyên suốt hệ thống

• Ứng dụng di động Android & iOS — truy cập hệ thống mọi lúc mọi nơi

• Chatbot AI hỗ trợ chủ doanh nghiệp — trợ lý ảo giải đáp cho BOD

• AI hướng dẫn sử dụng hệ thống — onboarding, hướng dẫn thao tác cho người dùng mới

• Truy vấn dữ liệu bằng ngôn ngữ tự nhiên — BOD hỏi bằng tiếng Việt, hệ thống trả kết quả

2.2 Ngoài phạm vi (Out-of-scope)

• Migration dữ liệu từ hệ thống cũ (khách xác nhận không cần)
• Kế toán tổng hợp / sổ cái (nằm ngoài scope hệ thống quản lý dự án)

2.3 Ranh giới dữ liệu

• Dữ liệu tách biệt theo dự án — mỗi dự án có BOQ, KHCP, contracts, đề xuất riêng
• BOD có quyền xem tất cả dự án
• Kế toán xem tất cả giao dịch tài chính
• CHT/Site Manager chỉ thấy dự án được assign
• NCC/Thầu phụ chỉ thấy phần liên quan đến mình (portal riêng)

3. Vai trò & phân quyền

Mặc định / suy luận: Permission matrix chi tiết sẽ cần chốt với khách. Prototype dùng role-based gating theo bảng trên.

4. Quy trình tổng quan — Từ Dự án đến Thanh toán

flowchart TD
    A["Nhận BOQ + Bản vẽ từ Chủ đầu tư"] --> B["QS bóc tách & soát xét khối lượng"]
    B --> C["Kế toán kiểm tra"]
    C --> D["BOD duyệt BOQ"]
    D --> E["Giao Ban Chỉ Huy (BCH)"]
    E --> F["BCH lập Kế Hoạch Chi Phí (KHCP)"]
    F --> G["Kế toán duyệt KHCP"]
    G --> H["BOD duyệt KHCP"]
    H --> I["Dự án chuyển Đang hoạt động"]

    I --> J["BCH tạo các Đề xuất & Yêu cầu"]

    J --> J1["Đề xuất Thầu phụ"]
    J --> J2["Đề xuất Vật tư / Thiết bị / Nhân công"]
    J --> J3["Đề xuất Hồ sơ Pháp lý"]
    J --> J4["Yêu cầu Mua hàng"]

    J4 --> K["Kế toán duyệt → Chuyển Phòng Mua Hàng"]
    K --> L["NV Mua Hàng lập Báo giá"]
    L --> M["TP Mua Hàng duyệt → BOD duyệt"]
    M --> N["Mua hàng & Giao nhận"]
    N --> O["BCH xác nhận nhận hàng"]

    J1 --> P["Kế toán duyệt → BOD duyệt"]
    J2 --> P
    J3 --> Q["Kế toán → KTT → BOD → HR xác nhận"]

    P --> R["Đề nghị Thanh toán (ĐNTT)"]
    Q --> R
    O --> R
    R --> S["Chain duyệt ĐNTT → Giải ngân"]

5. Module chi tiết

5.1 BOQ — Bóc tách Khối lượng (Bill of Quantities)

Bối cảnh

Khi nhận bản vẽ và BOQ từ Chủ đầu tư (CĐT), đội QS sẽ bóc tách chi tiết khối lượng công việc thành cây phân cấp nhiều tầng (section → sub-section → item). Đây là xương sống của toàn bộ hệ thống — KHCP, đề xuất vật tư, báo giá đều tham chiếu về BOQ.

Workflow chính

1. Nhập BOQ — tạo mới hoặc AI import từ file Excel/PDF
2. Bóc tách (Breakdown) — chia nhỏ khối lượng theo khu vực (Khu A, B, C…) thành cây N tầng
3. QS soát xét — kiểm tra đơn giá, khối lượng, tổng tiền
4. Kế toán kiểm tra — xác nhận ngân sách phù hợp
5. BOD duyệt — chốt BOQ chính thức
6. Theo dõi thực tế — cập nhật "khối lượng thực tế" vs "kế hoạch" trong quá trình thi công; nếu vượt → tạo phụ lục hợp đồng trình BOD duyệt

stateDiagram-v2
    [*] --> breakdown: Tạo BOQ / AI Import
    breakdown --> qs_review: BCH gửi QS soát xét
    qs_review --> finance_review: QS duyệt → Kế toán
    finance_review --> bod_approval: Kế toán duyệt → BOD
    bod_approval --> approved: BOD duyệt
    approved --> [*]

    note right of approved
        BOQ approved → Tạo KHCP
        Revision nếu KL thay đổi
    end note

Đã rõ / đã ghi nhận

• Cây phân cấp tự tham chiếu (parent_id), N tầng (prototype mặc định 8)
• Tổng tiền roll up từ lá lên: total = quantity × unit_rate, section total = sum of children
• Có markup (%) trên tổng trực tiếp phí
• Trạng thái duyệt: breakdown → qs_review → finance_review → bod_approval → approved
• Revision: original → drawing (khi có thay đổi so sánh khối lượng)
• AI import: nhập từ Excel/PDF → mock phân tích → tạo cây BOQ tự động
• BOQ gắn với dự án cụ thể

Mặc định / suy luận triển khai

• Ordinal format: "01.02.0010" (path-based numbering)
• Sort order riêng biệt với ordinal (3 concern: ordinal, sort_order, parent_id)
• Giá trị tiền tệ: VND, số nguyên (không float)
• BOQ approved có thể link sang Budget/KHCP

Cần xác nhận

• Max nesting depth cho phép? (prototype dùng 8)
• Có cần quản lý phiên bản (snapshot) BOQ khi revision không?
• Quy trình "phụ lục hợp đồng" khi khối lượng thực tế vượt kế hoạch — flow duyệt thế nào?
• BOQ có gắn với nhiều dự án hay 1:1?

Cần chú ý khi prototype/test

• Performance cây lớn (>500 position) — cần virtual scroll
• Rollup tính toán client-side phải chính xác khi edit inline
• AI import chỉ là mock — cần demo convincing nhưng không phải AI thật

5.2 Kế hoạch Chi phí (KHCP)

Bối cảnh

Sau khi BOQ được duyệt, Ban Chỉ Huy (BCH) lập Kế hoạch Chi phí (KHCP) — break-down khối lượng công việc từ BOQ thành các hạng mục chi phí cụ thể theo khu vực thi công. KHCP là cơ sở để tạo đề xuất và yêu cầu mua hàng.

Workflow chính

1. BCH tạo KHCP từ BOQ đã duyệt
2. Break-down hạng mục theo khu vực (Khu A, Khu C…)
3. Gắn bản vẽ, tài liệu, tiến độ thi công
4. Kế toán duyệt
5. BOD duyệt
6. KHCP approved → cơ sở cho các đề xuất

flowchart TD
    A["BOQ đã duyệt"] --> B["BCH lập KHCP"]
    B --> C["Break-down theo khu vực"]
    C --> D["Đính kèm: Bản vẽ + Tiến độ + Tài liệu"]
    D --> E["Gửi Kế toán duyệt"]
    E --> F["BOD duyệt"]
    F --> G["KHCP approved"]
    G --> H["Cơ sở tạo Đề xuất & Yêu cầu"]

Đã rõ / đã ghi nhận

• KHCP bao gồm: Thầu phụ, Vật tư, Nhân công, Softscape
• Đính kèm bắt buộc: Bản vẽ, Tiến độ thi công, Tài liệu liên quan
• Người lập: Chỉ Huy Trưởng
• Chain duyệt: Kế toán → BOD

Mặc định / suy luận triển khai

• KHCP gắn 1:1 với BOQ (hoặc một phần BOQ)
• Có thể có nhiều KHCP cho cùng dự án (theo giai đoạn)
• KHCP approved gắn budget tương ứng trong hệ thống tài chính

Cần xác nhận

• KHCP có cần revision/amendment khi chi phí phát sinh?
• Mối quan hệ KHCP ↔ BOQ ↔ Budget chi tiết thế nào?
• Break-down theo khu vực hay theo hạng mục công việc?

5.3 Hệ thống Phiếu Đề xuất (7 loại voucher type)

Bối cảnh

J.Garden có 7 loại phiếu đề xuất khác nhau, mỗi loại có chain duyệt riêng. Đây là core business logic — mỗi loại phiếu có người lập, tài liệu đính kèm bắt buộc, và chuỗi phê duyệt đa phòng ban khác nhau.

Bảng tổng hợp 7 loại voucher

Ngoài ra còn ĐNTT Lương (dntt_luong) với chain 6 bước — xem mục 5.6.

Chain duyệt chi tiết

flowchart LR
    subgraph "KHCP / Thầu phụ / Vật tư / CP ngoài KH"
        A1["Chỉ Huy Trưởng lập"] --> B1["Kế toán duyệt"]
        B1 --> C1["BOD phê duyệt"]
    end

    subgraph "Hồ sơ Pháp lý"
        A2["QA/QC lập"] --> B2["Kế toán duyệt"]
        B2 --> C2["KTT soát xét"]
        C2 --> D2["BOD phê duyệt"]
        D2 --> E2["HR xác nhận hồ sơ"]
    end

    subgraph "Yêu cầu Mua hàng"
        A3["CHT lập"] --> B3["Kế toán duyệt"]
        B3 --> C3["Chuyển Phòng Mua Hàng"]
    end

    subgraph "Báo giá Mua hàng"
        A4["NV Mua Hàng lập"] --> B4["TP Mua Hàng duyệt"]
        B4 --> C4["BOD phê duyệt"]
    end

Đã rõ / đã ghi nhận

• Mỗi loại voucher có chain duyệt cố định (static data, không có workflow engine động)
• Chain step gồm: step_key, role, dept, flag handoff (chuyển phòng ban)
• Voucher không có voucher_type → fallback legacy chain (Kế toán → KTT → Owner)
• Trạng thái: Draft → In_Review → Approved / Rejected
• Reject ở bất kỳ bước nào → terminal, ghi reason
• Approve ở bước cuối → Approved
• Tài liệu đính kèm bắt buộc theo từng loại voucher (xem bảng bên dưới)

Tài liệu đính kèm bắt buộc theo loại

Mặc định / suy luận triển khai

• Tài liệu đính kèm chia thành danh mục cụ thể (không upload chung) — yêu cầu quan trọng từ khách
• Mỗi field upload gắn nhãn rõ: "Bản vẽ", "Tiến độ", "KHCP đã duyệt"…
• Hệ thống reject upload nếu thiếu danh mục bắt buộc

Cần xác nhận

• Form mẫu phiếu đề xuất (khách nói "cần lấy form mẫu") — đã có chưa?
• Đề xuất nhân công và đề xuất thiết bị/cơ giới có tách voucher type riêng hay gộp vào dx_vattu?
• Yêu cầu vật tư vượt BOQ → tạo yêu cầu thay đổi riêng, flow duyệt thế nào?

Cần chú ý khi prototype/test

• 7 loại voucher × nhiều trạng thái = ma trận test lớn
• Chain duyệt khác nhau → cần test từng chain riêng
• Persona switcher phải cover đủ role để demo approve từng bước

5.4 Yêu cầu Mua hàng & Handoff Phòng Mua Hàng

Bối cảnh

Khi BCH cần vật tư/thiết bị/thầu phụ, họ tạo phiếu yêu cầu. Sau khi Kế toán duyệt, phiếu được chuyển sang Phòng Mua Hàng (handoff) — đây là điểm đứt gãy thông tin lớn nhất hiện tại mà hệ thống mới cần giải quyết.

Workflow

flowchart TD
    A["CHT lập Yêu cầu mua hàng"] --> B["Kế toán duyệt"]
    B --> C["Handoff → Phòng Mua Hàng"]
    C --> D["NV Mua Hàng nhận yêu cầu"]
    D --> E["Liên hệ NCC, lập Báo giá"]
    E --> F["TP Mua Hàng duyệt Báo giá"]
    F --> G["BOD duyệt"]
    G --> H["Đặt hàng"]
    H --> I["Giao hàng → Công trường"]
    I --> J["BCH xác nhận nhận hàng"]
    J --> K["Cập nhật trạng thái → BCH biết hàng đã về"]

Đã rõ / đã ghi nhận

• Handoff là bước đặc biệt (handoff: true trong chain) — chuyển ownership sang phòng ban khác
• Pain-point chính: BCH không biết khi nào hàng được mua → cần liên kết trạng thái real-time
• Sau handoff, Phòng Mua Hàng tạo Báo giá (voucher type bg_muahang)

Mặc định / suy luận triển khai

• Yêu cầu gắn với KHCP đã duyệt (reference)
• Trạng thái yêu cầu tracking end-to-end: Tạo → Duyệt → Handoff → Mua → Giao → Nhận
• BCH có dashboard theo dõi trạng thái yêu cầu đã gửi

Cần xác nhận

• Sau handoff, phiếu yêu cầu có liên kết ngược với báo giá mua hàng không?
• Khi hàng về, biên bản giao nhận là tài liệu riêng hay gắn vào phiếu yêu cầu?

5.5 Báo giá Mua hàng & Quản lý NCC

Bối cảnh

Phòng Mua Hàng nhận yêu cầu từ BCH, liên hệ NCC lấy báo giá, so sánh ít nhất 3 NCC, và trình duyệt.

Workflow

1. NV Mua Hàng nhận yêu cầu từ handoff
2. Liên hệ NCC, nhập báo giá (line items: vật tư, SL, đơn giá, thành tiền)
3. So sánh báo giá từ nhiều NCC
4. TP Mua Hàng duyệt báo giá tốt nhất
5. BOD phê duyệt
6. Đặt hàng → Giao nhận

Đã rõ / đã ghi nhận

• Báo giá gồm: danh sách line items (material, quantity, unit_price, total)
• NCC: tên, MST, liên hệ, điều khoản thanh toán, category
• Trạng thái báo giá: Draft → In_Review → Approved / Rejected
• So sánh báo giá từ nhiều NCC (ít nhất 3) là yêu cầu business
• Vật tư phân loại theo category: Cây, Đèn, Hoa, Đất, Thảm Cỏ…

Mặc định / suy luận triển khai

• Danh mục vật tư (Materials catalog) quản lý tập trung, dùng chung cho tất cả báo giá
• NCC có trạng thái active/inactive, không xóa cứng

Cần xác nhận

• So sánh báo giá hiển thị dạng bảng so sánh hay chỉ attach file?
• Quy trình chọn NCC — tiêu chí nào?

5.6 Đề nghị Thanh toán (ĐNTT)

Bối cảnh

Có 2 nhánh ĐNTT chính:

• ĐNTT Mua hàng — thanh toán cho NCC sau khi giao nhận
• ĐNTT Lương — thanh toán lương hàng tháng, chain dài nhất (6 bước)

Chain ĐNTT Lương (chi tiết nhất)

flowchart TD
    A["NV Nhân sự (C&B) lập ĐNTT Lương"] --> B["Phụ trách C&B duyệt"]
    B --> C["Kế toán kiểm tra"]
    C --> D["Kế toán Trưởng soát xét"]
    D --> E["BOD phê duyệt"]
    E --> F["Kế toán thanh toán lập UNC"]
    F --> G["Kế toán Trưởng giải ngân"]

Tài liệu ĐNTT Lương

• ĐNTT được duyệt
• Danh sách chuyển lương
• Bảng chấm công
• Bảng theo dõi nhân công
• Danh sách nhận lương

Tài liệu ĐNTT Mua hàng

• Hợp đồng (nếu có)
• KHCP đã duyệt
• Quy trình duyệt: Đề xuất → Yêu cầu → Báo giá (đều đã duyệt)
• Biên bản giao nhận hàng hóa
• Tài liệu liên quan khác

Đã rõ / đã ghi nhận

• ĐNTT Lương chain 6 bước: C&B → Kế toán → KTT → BOD → KT thanh toán → KTT giải ngân
• ĐNTT Mua hàng yêu cầu biên bản giao nhận → cần có module giao nhận
• Sau giải ngân → ghi nhận Transaction (immutable)

Mặc định / suy luận triển khai

• Transaction (lệnh đi tiền): immutable, pessimistic locking, deduct budget
• Partial payment hỗ trợ cho hợp đồng theo đợt thanh toán

Cần xác nhận

• ĐNTT Mua hàng chain duyệt cụ thể? (tài liệu ghi: Kế toán → Kế toán viên → KTT — cần rõ hơn)
• ĐNTT có gắn với hợp đồng cụ thể hay chỉ tham chiếu?

5.7 Quản lý Nhà thầu phụ

Bối cảnh

Với hạng mục không chuyên, J.Garden thuê thầu phụ thi công. Cần module riêng để thầu phụ:

• Được assign công việc
• Báo cáo tiến độ hàng ngày (hình ảnh, % hoàn thành)
• Gửi yêu cầu thanh toán theo % hoàn thành

Workflow

flowchart TD
    A["Đề xuất Thầu phụ được duyệt"] --> B["Ký hợp đồng thầu phụ"]
    B --> C["Assign công việc cho thầu phụ"]
    C --> D["Thầu phụ báo cáo tiến độ hàng ngày"]
    D --> E["BCH xác nhận tiến độ"]
    E --> F{"Hoàn thành đợt?"}
    F -->|Có| G["Thầu phụ gửi YC thanh toán"]
    G --> H["Kế toán duyệt → BOD duyệt"]
    H --> I["Giải ngân"]
    F -->|Chưa| D

Đã rõ / đã ghi nhận

• Thầu phụ báo cáo tiến độ (ví dụ: hoàn thành 50%) kèm hình ảnh
• Thanh toán theo % hoàn thành hoặc theo đợt hợp đồng
• Cần portal riêng cho thầu phụ (hoặc app view hạn chế quyền)

Cần xác nhận

• Portal thầu phụ là web app riêng hay cùng hệ thống với role hạn chế?
• Biên bản nghiệm thu giữa BCH và thầu phụ — flow như thế nào?
• Theo dõi công nợ thầu phụ (đã trả / còn nợ)?

Cần chú ý khi prototype/test

• Prototype hiện có seed 5 dự án với mock subcontractor — cần show mục Quản lý Thầu phụ trên nav

5.8 Giao nhận Hàng hóa

Bối cảnh

Khi hàng về công trường, BCH phải xác nhận nhận hàng kèm chứng từ. Đây là bước bắt buộc trước khi lập ĐNTT Mua hàng — giải quyết pain-point "BCH không biết hàng đã về chưa".

Workflow

1. Phòng Mua Hàng xác nhận đã đặt hàng
2. NCC giao hàng → Công trường
3. BCH kiểm tra, lập Biên bản giao nhận
4. Upload chứng từ: phiếu giao hàng, hình ảnh thực tế
5. Xác nhận nhận hàng → cập nhật trạng thái yêu cầu
6. Biên bản giao nhận → đính kèm vào ĐNTT

Đã rõ / đã ghi nhận

• Biên bản giao nhận hàng hóa là bắt buộc cho ĐNTT Mua hàng
• BCH xác nhận kèm chứng từ (phiếu giao hàng, hình ảnh)

Cần xác nhận

• Giao nhận một phần (partial delivery) — xử lý thế nào?
• Từ chối nhận hàng (hàng lỗi, sai spec) — flow?
• Biên bản giao nhận có template mẫu không?

5.9 Quản lý Dự án (Project Lifecycle)

Bối cảnh

Dự án cảnh quan có lifecycle từ nhận thầu đến thanh lý, gắn chặt với BOQ, KHCP, và các đề xuất.

Lifecycle

stateDiagram-v2
    [*] --> pitching: Nhận yêu cầu từ CĐT
    pitching --> planning: BOQ + Bản vẽ nhập hệ thống
    planning --> active: BOD duyệt → Giao BCH
    active --> on_hold: Tạm dừng
    on_hold --> active: Tiếp tục
    active --> completed: Hoàn thành thi công
    completed --> liquidated: Thanh lý tài chính
    pitching --> failed: Không trúng thầu
    failed --> liquidated: Thanh lý
    liquidated --> [*]

Đã rõ / đã ghi nhận

• Dự án gắn: BOQ, KHCP, Contracts, Đề xuất, NCC, Thầu phụ
• Mỗi dự án có: mã dự án, tên, khách hàng, địa điểm, giá trị HĐ, manager, trạng thái
• Prototype đã có 5 dự án seed (Thảo Điền, Long Hải, Aqua City, Sala, Landmark 81)

Mặc định / suy luận triển khai

• Dự án pitching chỉ hiển thị cho BOD, KTT, CHT assign
• Dự án gắn 1:1 với Budget

5.10 Tổ chức & Phân quyền

Bối cảnh

10 phòng/khối, 6+ role hệ thống, phân quyền theo role + dự án assign.

Đã rõ / đã ghi nhận

• Cây phòng ban: BOD → 9 phòng/khối trực thuộc
• Tổng ~50–80 nhân sự (danh sách chi tiết đã có trong sơ đồ tổ chức)
• Role gắn với phòng ban (Site_Manager thuộc Khối CT-DA, Purchasing thuộc Phòng Mua Hàng…)
• Prototype đã có 13 persona demo cover đủ role

Mặc định / suy luận triển khai

• Phân quyền 2 tầng: org-level (BOD, KT, HR…) + project-level (CHT, QS assign vào dự án)
• Permission matrix theo RBAC model

5.11 Dashboard & Báo cáo

Cần xác nhận

• KPI dashboard cho BOD: những chỉ số nào? (tổng chi phí, budget vs actual, tiến độ dự án, công nợ NCC…)
• Dashboard cho Kế toán: tổng hợp phiếu đang chờ duyệt, tình hình giải ngân
• Dashboard cho CHT: trạng thái yêu cầu đã gửi, tiến độ mua hàng
• Báo cáo xuất Excel/PDF?

5.12 Chat nội bộ & Quản lý công việc

Bối cảnh

Thay thế Zalo cho toàn bộ giao tiếp nội bộ — kiểm soát thông tin, tránh trôi file, gắn chặt với dự án và công việc.

Tính năng chính

• Phần mềm chat nội bộ realtime — nhắn tin 1:1, nhóm theo dự án/phòng ban, gửi file có phân loại
• Quản lý dự án & công việc trong chat — giao task trực tiếp từ cuộc chat, set deadline, notify, theo dõi tiến độ
• Dashboard & tìm kiếm thông minh — tổng quan nhanh các task, tin nhắn, tài liệu; tìm kiếm xuyên suốt hệ thống

Đã rõ / đã ghi nhận

• Mục đích chính: kiểm soát thông tin, tránh mất file trên Zalo
• Chat gắn context dự án — tin nhắn, file, task thuộc về dự án cụ thể
• Tạo nhóm chat theo dự án, phòng ban

Cần xác nhận

• Có cần voice/video call không hay chỉ text + file?
• Retention policy cho tin nhắn và file?
• Tích hợp notification với hệ thống duyệt phiếu (duyệt xong → thông báo trong chat)?

5.13 Ứng dụng di động (Android & iOS)

Bối cảnh

BOD và quản lý cần truy cập hệ thống mọi lúc mọi nơi — đặc biệt duyệt phiếu, xem reports, chat với nhân viên.

Tính năng chính

• Chat — realtime, đồng bộ với web
• Quản lý task — giao việc, set deadline, notify, theo dõi tiến độ
• Xem reports dự án — dashboard, tiến độ, chi phí
• Duyệt phiếu — approve/reject nhanh từ mobile notification
• Cross-platform: Android + iOS

Mặc định / suy luận triển khai

• Dùng framework cross-platform (React Native / Flutter) để giảm effort maintain
• Ưu tiên flow duyệt + chat + dashboard trước, các tính năng khác phase sau

Cần xác nhận

• Offline support cần ở mức nào? (xem data đã cache hay cần edit offline?)
• Push notification cho những event nào? (duyệt phiếu, chat, task deadline…)

5.14 AI Chatbot & Truy vấn thông minh

Bối cảnh

Hỗ trợ BOD tra cứu dữ liệu bằng ngôn ngữ tự nhiên, và hướng dẫn người dùng mới sử dụng hệ thống.

Tính năng chính

• Chatbot AI hỗ trợ chủ doanh nghiệp — BOD hỏi: "tổng chi phí dự án Thảo Điền tháng này?", chatbot trả kết quả
• AI hướng dẫn sử dụng hệ thống — onboarding tự động, hướng dẫn thao tác theo ngữ cảnh
• Truy vấn dữ liệu bằng ngôn ngữ tự nhiên — hỏi bằng tiếng Việt, hệ thống chuyển thành query và trả kết quả

Mặc định / suy luận triển khai

• RAG (Retrieval-Augmented Generation) trên dữ liệu hệ thống
• Chatbot chỉ có quyền đọc — không thay đổi dữ liệu qua chat
• LLM backend: có thể dùng API (OpenAI, Claude, Gemini) hoặc model on-prem tùy yêu cầu bảo mật

Cần xác nhận

• Phạm vi dữ liệu chatbot được truy vấn? (tài chính, nhân sự, dự án…)
• Yêu cầu bảo mật — data có được gửi ra API bên ngoài không?
• Chatbot có hỗ trợ tạo báo cáo/biểu đồ từ câu hỏi không?

6. Nguyên tắc tài chính

• Tiền tệ: VND, số nguyên (int64), không float
• Transaction immutable — không sửa, không xóa
• Pessimistic locking khi deduct budget
• Audit log mọi thay đổi trạng thái tài chính
• Over-budget control (allow_over_budget flag)
• Idempotency key cho mutating endpoints

7. Giả định & câu hỏi mở

Giả định chính

1. Hệ thống single-tenant cho J.Garden, không multi-tenant
2. Không migrate dữ liệu cũ — dự án mới chạy trên hệ thống mới
3. Tiền tệ chỉ VND, không multi-currency
4. Auth qua Keycloak/OIDC
5. Prototype demo ungated (mock data + persona switcher)

Câu hỏi mở cần chốt với khách

1. Form mẫu phiếu đề xuất — đã có template sẵn chưa? Cần lấy từ khách.
2. Đề xuất nhân công vs đề xuất thiết bị/cơ giới — tách riêng voucher type hay gộp vào dx_vattu?
3. Phụ lục hợp đồng khi khối lượng vượt BOQ — flow duyệt chi tiết?
4. ĐNTT Mua hàng chain duyệt — tài liệu ghi KT → KT viên → KTT nhưng cần rõ hơn.
5. Portal thầu phụ — web app riêng hay view hạn chế trong hệ thống chính?
6. Giao nhận hàng hóa — partial delivery, từ chối nhận hàng flow?
7. Dashboard KPI — chỉ số cụ thể cho BOD, KT, CHT?
8. BOQ revision/snapshot — cần quản lý phiên bản hay chỉ override?
9. Yêu cầu vật tư vượt kế hoạch BOQ — flow yêu cầu thay đổi → chờ BOD duyệt?
10. So sánh báo giá NCC — UI bảng so sánh hay chỉ attach file báo giá?

Bước tiếp theo cho prototype

1. Chốt câu hỏi mở với khách (đặc biệt #1, #4, #5)
2. Chuẩn bị kịch bản demo: (a) Flow BOQ bóc tách, (b) Flow duyệt đề xuất đa phòng ban
3. Hoàn thiện mock data cho kịch bản demo
4. Bổ sung module Giao nhận + Thầu phụ vào prototype
5. Prototype Chat/Mobile/AI modules