Giao diện
PHÂN TÍCH NGHIỆP VỤ (Version 2 - SRS CHI TIẾT)
Flow 1: QUẢN LÝ ĐƠN HÀNG
1.1 Use Cases
UC-001: Tạo Đơn Hàng Mới
Actor: Nhân viên kinh doanh
Điều kiện tiên quyết: User đã đăng nhập với quyền SALES hoặc cao hơn
Luồng chính:
- User truy cập trang "Tạo Đơn Hàng"
- Hệ thống hiển thị form tạo đơn hàng
- User tìm kiếm khách hàng theo tên/SĐT/MST
- IF khách hàng đã tồn tại THEN
- Chọn khách hàng từ danh sách ELSE
- User nhấn "Thêm Khách Hàng Mới"
- Điền form thông tin khách (xem UC-002)
- User thêm sản phẩm vào đơn (có thể nhiều sản phẩm)
- For each sản phẩm:
- Chọn loại: In ấn / Biển quảng cáo
- Nhập thông số kỹ thuật
- Upload file thiết kế (optional)
- Hệ thống tự động tính giá dự kiến
- User nhập ngày cần giao hàng
- User nhập địa chỉ giao hàng
- User chọn hành động:
- "Lưu nháp" → Lưu trạng thái DRAFT
- "Tạo báo giá" → Chuyển UC-003
- "Xác nhận ngay" → Nếu khách đã đồng ý qua điện thoại
Luồng thay thế:
- 3a. Không tìm thấy khách hàng → Tạo mới
- 7a. Giá tính ra âm/vô lý → Hiển thị warning, yêu cầu kiểm tra lại
- 10a. User thoát giữa chừng → Hiển thị confirm "Bạn có muốn lưu nháp?"
Post-condition:
- Đơn hàng được tạo trong DB với trạng thái phù hợp
- Mã đơn hàng được generate tự động:
DH-YYYYMMDD-XXX - Activity log ghi lại user tạo đơn
Validation Rules:
VR-001: Khách hàng phải được chọn (required)
VR-002: Phải có ít nhất 1 sản phẩm
VR-003: Mỗi sản phẩm phải có số lượng > 0
VR-004: Ngày giao hàng >= Ngày hiện tại + 2 ngày (minimum lead time)
VR-005: Tổng tiền đơn hàng >= 100,000 VNĐ
VR-006: File thiết kế (nếu có) phải là PDF/AI/PSD, max 50MBUC-002: Tạo Khách Hàng Mới (Sub-flow)
Actor: Nhân viên kinh doanh
Trigger: Từ UC-001 hoặc từ menu Khách Hàng
Luồng chính:
- Hệ thống hiển thị form "Thêm Khách Hàng"
- User nhập thông tin:
- Tên công ty/cá nhân (required)
- Mã số thuế (optional)
- Số điện thoại (required)
- Email (optional)
- Địa chỉ (required)
- Người liên hệ (optional)
- Phân loại: Mới/Thường/VIP (default: Mới)
- Hạn mức công nợ (default: 0)
- Hệ thống validate dữ liệu nhập
- IF validation pass THEN
- Lưu vào DB
- Generate mã KH:
KH001, KH002... - Hiển thị thông báo thành công
- Return khách hàng vừa tạo về UC-001 ELSE
- Hiển thị lỗi validation
- User sửa lại
- End
Validation Rules:
VR-010: Tên khách hàng: 3-200 ký tự
VR-011: SĐT: 10-11 số, regex: ^(0[3|5|7|8|9])[0-9]{8,9}$
VR-012: Email (nếu có): Định dạng email hợp lệ
VR-013: MST (nếu có): 10-14 ký tự số
VR-014: SĐT không được trùng với KH đã tồn tại
VR-015: Hạn mức công nợ >= 0Business Rules:
BR-001: Khách hàng mới mặc định không có hạn mức công nợ
BR-002: Chỉ Manager/Admin mới set được hạn mức công nợ > 0
BR-003: Khách VIP được phê duyệt bởi Giám đốcUC-003: Tạo và Gửi Báo Giá
Actor: Nhân viên kinh doanh
Điều kiện tiên quyết: Đơn hàng ở trạng thái DRAFT
Luồng chính:
- User chọn đơn hàng cần báo giá
- Nhấn nút "Tạo Báo Giá"
- Hệ thống kiểm tra:
- Đơn hàng có đủ thông tin chưa?
- Giá đã được tính chưa?
- Hệ thống hiển thị preview báo giá (format chuẩn)
- User có thể:
- Chỉnh sửa giá thủ công (nếu có quyền)
- Thêm ghi chú, điều khoản
- Chỉnh sửa thời gian giao hàng
- User chọn cách gửi:
- Email: Nhập email, hệ thống gửi tự động
- In PDF: Tải về máy hoặc in trực tiếp
- Cả hai
- Hệ thống:
- Generate file PDF báo giá
- Lưu vào storage:
/uploads/quotations/BG-XXXXXXX.pdf - Gửi email (nếu chọn)
- Cập nhật trạng thái đơn → QUOTED
- Log activity
- Hiển thị thông báo "Đã gửi báo giá thành công"
Sequence Diagram:
mermaid
sequenceDiagram
participant U as User (Sales)
participant UI as Web UI
participant BE as Backend API
participant PDF as PDF Generator
participant Email as Email Service
participant DB as Database
U->>UI: Nhấn "Tạo Báo Giá"
UI->>BE: POST /orders/{id}/quote
BE->>DB: Lấy thông tin đơn hàng
DB-->>BE: order_data
BE->>PDF: Generate PDF (template + data)
PDF-->>BE: quotation.pdf
BE->>DB: Lưu path file PDF
BE->>Email: Gửi email + attach PDF
Email-->>BE: Email sent
BE->>DB: Cập nhật status = QUOTED
BE-->>UI: Response {success, pdf_url}
UI-->>U: Hiển thị "Đã gửi báo giá"Validation Rules:
VR-020: Email khách hàng phải hợp lệ (nếu gửi qua email)
VR-021: Giá mỗi sản phẩm > 0
VR-022: Tổng giá đơn >= 100,000 VNĐ
VR-023: Thời gian giao hàng >= Ngày hiện tại + 2 ngàyBusiness Rules:
BR-010: Báo giá có hiệu lực 7 ngày (có thể cấu hình)
BR-011: Sau 7 ngày, nếu khách chưa phản hồi → Nhắc nhở qua email tự động
BR-012: Nhân viên Sales chỉ được giảm giá max 10%, > 10% cần Manager duyệt
BR-013: Email báo giá tự động CC cho ManagerUC-004: Xác Nhận Đơn Hàng
Actor: Nhân viên kinh doanh
Điều kiện tiên quyết:
- Đơn hàng ở trạng thái QUOTED
- Khách hàng đã đồng ý (qua email/điện thoại)
Luồng chính:
- User vào danh sách đơn hàng, lọc status = QUOTED
- Tìm đơn hàng cần xác nhận
- Nhấn "Xác Nhận Đơn"
- Hệ thống hiển thị popup xác nhận:
- Thông tin đơn hàng (review)
- Form nhập thông tin thanh toán:
- % Đặt cọc: [____] % (default 50%)
- Phương thức: [Tiền mặt/Chuyển khoản/Thẻ]
- Ngày hẹn thanh toán cọc: [____]
- IF khách hàng có công nợ quá hạn THEN
- Hiển thị warning: "KH đang nợ XX VNĐ quá hạn"
- Yêu cầu xác nhận từ Manager
- User nhấn "Xác Nhận"
- Hệ thống:
- Cập nhật status đơn → CONFIRMED
- Tạo payment record (tiền cọc expected)
- IF đặt cọc > 0% THEN
- Tạo invoice/receipt cho tiền cọc
- Trigger tạo Production Order (UC-101)
- Gửi email xác nhận đơn hàng cho khách
- Gửi thông báo cho bộ phận sản xuất
- Hiển thị "Đơn hàng đã được xác nhận"
Data Flow Diagram:
┌─────────────┐
│ Khách │ (đồng ý báo giá)
│ Hàng │─────────────────┐
└─────────────┘ │
▼
┌───────────────┐
│ Nhân viên │
│ Kinh doanh │
└───────┬───────┘
│ (xác nhận đơn)
▼
┌─────────────────────────────────────────┐
│ HỆ THỐNG │
│ 1. Cập nhật status → CONFIRMED │
│ 2. Tạo Payment Record │
│ 3. Tạo Production Order │
│ 4. Gửi email cho khách │
│ 5. Notify bộ phận sản xuất │
└─────┬───────────────────┬───────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────────┐
│ Database │ │ Email Service │
│ (orders, │ │ (send confirm) │
│ payments, │ └─────────────────┘
│ prod_ord) │
└─────────────┘Validation Rules:
VR-030: % Đặt cọc: 0-100
VR-031: Ngày hẹn thanh toán cọc <= Ngày bắt đầu SX
VR-032: IF khách có nợ quá hạn > hạn mức → Yêu cầu Manager approvalBusiness Rules:
BR-020: Khách mới: Bắt buộc cọc >= 50%
BR-021: Khách thường: Cọc >= 30%
BR-022: Khách VIP: Có thể không cọc (debt payment)
BR-023: Đơn hàng > 100 triệu: Bắt buộc cọc >= 50% dù khách VIP
BR-024: Sau khi confirm, không thể sửa thông tin sản phẩm, chỉ sửa được ngày giao1.2 State Machine - Trạng Thái Đơn Hàng
mermaid
stateDiagram-v2
[*] --> DRAFT: Tạo đơn mới
DRAFT --> QUOTED: Gửi báo giá
DRAFT --> CANCELLED: Khách từ chối
QUOTED --> CONFIRMED: Khách đồng ý
QUOTED --> DRAFT: Chỉnh sửa lại
QUOTED --> CANCELLED: Khách từ chối
CONFIRMED --> IN_PRODUCTION: Bắt đầu SX
CONFIRMED --> CANCELLED: Hủy đơn (có phí)
IN_PRODUCTION --> COMPLETED: Hoàn thành SX
IN_PRODUCTION --> CANCELLED: Lỗi nghiêm trọng
COMPLETED --> DELIVERED: Giao hàng
DELIVERED --> ACCEPTED: Nghiệm thu OK
DELIVERED --> IN_PRODUCTION: Lỗi, làm lại
ACCEPTED --> [*]: Hoàn tất
CANCELLED --> [*]: Kết thúc
note right of DRAFT
- Có thể sửa mọi thứ
- Chưa tính vào doanh số
end note
note right of CONFIRMED
- Đã lock thông tin SP
- Đã tạo lệnh SX
- Đã tính vào doanh số dự kiến
end note
note right of ACCEPTED
- Đã nghiệm thu
- Chờ thanh toán còn lại
end noteQuy tắc chuyển trạng thái:
- Chỉ được chuyển theo flow đã định
- Một số chuyển đổi cần approval (VD: CONFIRMED → CANCELLED)
- Mỗi lần chuyển đổi phải ghi log chi tiết (user, timestamp, reason)
Flow 2: QUẢN LÝ SẢN XUẤT
2.1 Use Cases
UC-101: Tạo Lệnh Sản Xuất (Production Order)
Actor: Hệ thống (tự động) hoặc Trưởng sản xuất
Trigger: Đơn hàng chuyển sang trạng thái CONFIRMED
Luồng chính:
- System nhận event "Order Confirmed"
- For each order_item trong đơn hàng: a. Tạo 1 production_order b. Generate mã LSX:
LSX-YYYYMMDD-XXXc. Tính toán các công đoạn cần thiết dựa trên loại SP:- Nếu in ấn → Thiết kế, Xuất kẽm, In, Gia công...
- Nếu biển QC → Khảo sát, Thiết kế 3D, Gia công khung, In hiflex, Lắp ráp... d. Tạo production_steps cho từng công đoạn e. Tính toán nguyên vật liệu cần thiết f. Ước tính thời gian hoàn thành
- Gán priority dựa trên ngày cần giao:
- Càng sớm → Priority càng cao (1=Gấp, 3=Thường, 5=Không gấp)
- Thông báo cho Trưởng sản xuất
- Log activity
Business Rules:
BR-100: Lead time tối thiểu:
- In offset số lượng lớn: 5-7 ngày
- In kỹ thuật số nhỏ: 2-3 ngày
- Biển quảng cáo: 7-14 ngày (tùy quy mô)
BR-101: Nếu ngày giao < lead time → Tự động đánh priority = 1 (Gấp)
BR-102: Không được nhận quá 10 lệnh SX gấp cùng lúc → WarningUC-102: Phân Công Công Việc
Actor: Trưởng sản xuất
Điều kiện tiên quyết: Production order đã được tạo, status = PENDING
Luồng chính:
- Trưởng SX vào danh sách lệnh SX
- Lọc theo status = PENDING, sắp xếp theo priority
- Chọn 1 lệnh SX
- Xem chi tiết:
- Sản phẩm
- Số lượng
- Thông số kỹ thuật
- Ngày cần hoàn thành
- Các công đoạn
- Phân công:
- Chọn thợ chính cho lệnh SX (assigned_to)
- For each công đoạn:
- Chọn người thực hiện
- Chọn máy móc/thiết bị (nếu cần)
- Điều chỉnh thời gian dự kiến (nếu cần)
- Chọn ngày bắt đầu
- Lưu phân công
- Hệ thống:
- Cập nhật assigned_to
- Gửi thông báo cho các thợ được phân công
- Cập nhật status lệnh SX → DESIGN (công đoạn đầu)
Validation Rules:
VR-100: Mỗi công đoạn phải có người thực hiện
VR-101: Ngày bắt đầu >= Ngày hiện tại
VR-102: Tổng thời gian các công đoạn + ngày bắt đầu <= Ngày cần giao
VR-103: Không được phân công quá 5 việc cho 1 người cùng lúcUC-103: Cập Nhật Tiến Độ Công Đoạn
Actor: Nhân viên sản xuất
Điều kiện tiên quyết:
- Production step đã được assign cho user
- Status = PENDING hoặc IN_PROGRESS
Luồng chính:
Thợ vào trang "Công Việc Của Tôi"
Hệ thống hiển thị danh sách công đoạn được giao
Chọn 1 công đoạn
IF status = PENDING THEN a. Nhấn "Bắt Đầu" b. Hệ thống:
- Cập nhật status → IN_PROGRESS
- Ghi start_time = now()
- Log activity
ELSE IF status = IN_PROGRESS THEN a. Nhập số lượng đã làm được: [] b. Nhập số lượng lỗi (nếu có): [] c. Ghi chú vấn đề gặp phải (optional) d. Nhấn "Cập Nhật Tiến Độ" e. Hệ thống:
- Lưu progress
- Tính % hoàn thành
- IF có lỗi nhiều → Thông báo cho Trưởng SX
Khi hoàn thành: a. Nhập số lượng đầu ra thực tế b. Nhập số lượng phế phẩm c. Upload ảnh sản phẩm (optional) d. Nhấn "Hoàn Thành" e. Hệ thống validate:
- IF quantity_output < quantity_input THEN
- Yêu cầu giải thích lý do
- IF quantity_defect > 10% THEN
- Warning, yêu cầu Trưởng SX xác nhận f. IF validation OK THEN
- Cập nhật status → COMPLETED
- Ghi end_time = now()
- Tính duration_minutes
- Chuyển công đoạn tiếp theo sang IN_PROGRESS (nếu có)
- Thông báo cho người thực hiện công đoạn tiếp
- IF đây là công đoạn cuối THEN
- Cập nhật production_order.status → COMPLETED
- Trigger UC-104 (QC)
- IF quantity_output < quantity_input THEN
Sequence Diagram:
mermaid
sequenceDiagram
participant Worker as Thợ
participant UI as Web UI
participant API as Backend
participant DB as Database
participant Notif as Notification Service
Worker->>UI: Nhấn "Bắt Đầu"
UI->>API: PATCH /production-steps/{id}/start
API->>DB: UPDATE status=IN_PROGRESS, start_time=NOW()
DB-->>API: OK
API-->>UI: Success
UI-->>Worker: "Đã bắt đầu công đoạn"
Note over Worker: Làm việc...
Worker->>UI: Nhập tiến độ + Nhấn "Hoàn Thành"
UI->>API: PATCH /production-steps/{id}/complete
API->>API: Validate output quantity
alt Validation Failed
API-->>UI: Error {message}
UI-->>Worker: Hiển thị lỗi
else Validation OK
API->>DB: UPDATE status=COMPLETED, end_time=NOW(), quantity_output=X
API->>DB: SELECT next_step
alt Có công đoạn tiếp theo
API->>DB: UPDATE next_step.status=IN_PROGRESS
API->>Notif: Gửi thông báo cho thợ tiếp
else Đây là công đoạn cuối
API->>DB: UPDATE production_order.status=COMPLETED
API->>Notif: Thông báo QC
end
DB-->>API: OK
API-->>UI: Success
UI-->>Worker: "Hoàn thành công đoạn"
endValidation Rules:
VR-110: quantity_output > 0
VR-111: quantity_output <= quantity_input + 5% (sai số cho phép)
VR-112: quantity_defect >= 0
VR-113: quantity_defect <= quantity_input
VR-114: Không được hoàn thành nếu chưa bắt đầuBusiness Rules:
BR-110: Tỷ lệ phế phẩm cho phép:
- In offset: <= 5%
- In kỹ thuật số: <= 3%
- Gia công: <= 2%
BR-111: Nếu phế phẩm > ngưỡng → Tự động tạo lệnh SX bổ sung
BR-112: Thời gian mỗi công đoạn không được vượt quá dự kiến >20%
BR-113: Nếu delay → Thông báo tự động cho kinh doanh để báo kháchUC-104: Kiểm Tra Chất Lượng (QC)
Actor: Nhân viên QC
Điều kiện tiên quyết: Production order status = COMPLETED
Luồng chính:
QC vào danh sách "Chờ Kiểm Tra"
Chọn lệnh SX cần kiểm tra
Hệ thống hiển thị:
- Thông tin sản phẩm
- Mẫu thiết kế (để so sánh)
- Yêu cầu kỹ thuật
- Checklist QC (dựa vào loại sản phẩm)
QC thực hiện kiểm tra và tick checklist:
□ Màu sắc chuẩn so với mẫu (sai lệch <= 5%) □ Kích thước chính xác (sai số <= 2mm) □ Không có vệt mực, vệt bẩn □ Cán màng (nếu có) đều, không bọt khí □ Bế (nếu có) đúng đường, góc cạnh sắc □ Đóng gáy (nếu có) chắc chắn, thẳng hàng □ Số lượng đạt yêu cầu (>= order quantity) □ Đóng gói cẩn thận, dán nhãn đầy đủQC đếm số lượng thực tế
IF tất cả checklist OK AND số lượng đủ THEN a. Chọn "Đạt Chất Lượng" b. Nhập vị trí kho thành phẩm: [____] c. Upload ảnh sản phẩm (sample) d. Nhấn "Xác Nhận QC Đạt" e. Hệ thống:
- Cập nhật production_order → QC_PASSED
- Tạo phiếu nhập kho thành phẩm (UC-201)
- Cập nhật order.status → COMPLETED
- Thông báo cho kinh doanh "Đơn đã sẵn sàng giao"
ELSE a. Chọn "Không Đạt Chất Lượng" b. Tick vào các lỗi gặp phải c. Nhập mô tả chi tiết lỗi d. Upload ảnh lỗi e. Chọn hành động:
- "Sửa chữa được" → Trả về công đoạn gia công
- "Phải làm lại" → Tạo lệnh SX mới f. Hệ thống:
- Cập nhật production_order → FAILED
- Tạo QC report
- Thông báo Trưởng SX
- IF "Làm lại" → Tạo lệnh SX mới, trừ vào KPI thợ
Validation Rules:
VR-120: Phải tick ít nhất 5/8 checklist items
VR-121: Vị trí kho phải hợp lệ (tồn tại trong hệ thống)
VR-122: Nếu "Không đạt" phải có mô tả lỗi (min 20 ký tự)Business Rules:
BR-120: QC phải được thực hiện bởi người khác với người sản xuất
BR-121: Sản phẩm không đạt:
- Lỗi < 5%: Sửa chữa
- Lỗi >= 5%: Làm lại toàn bộ
BR-122: Làm lại do lỗi sản xuất → Không tính thêm tiền khách, trừ KPI
BR-123: Làm lại do khách đổi ý → Tính phí 30-50% giá trị đơnKết thúc Flow 2: Quản Lý Sản Xuất
💡 Lưu ý: Tài liệu này là phần 1 của bộ SRS. Vui lòng xem tiếp các phần sau: