Skip to content

Giai đoạn 2 — Kế hoạch

Những gì ta xây sau khi MVP Giai đoạn 1 vào UAT. Giai đoạn 2 mở rộng quy mô lên hộ kinh doanh doanh thu 1–3 tỷ VND (thuế TNCN theo % doanh thu, sổ kế toán S2a) và thêm F&B đa kênh, bán lẻ tổng hợp, tạp hoá. Khung thời gian mục tiêu: T6 → T9/2026.

7Epic
3Lý do cốt lõi của GĐ2
T7–T9Cửa sổ build thật
1–3 tỷDải doanh thu (VND)

Đọc cái này trước — bảng kế hoạch đang đi sau code

Một đợt audit code ngày 2026-05-31 cho thấy đội dev đã build phần lớn những gì bảng PO đánh "Giai đoạn 2 / chưa chốt" (KDS, BOM/định mức, lô+HSD, hạ tầng barcode, ghi nhận COGS, schema X/Z report, ca 1-user, tách/gộp). Vì vậy phần lớn Giai đoạn 2 là hoàn thiện + đấu nối + kích hoạt, không phải xây từ đầu. Kế hoạch này gắn nhãn mọi mục:

  • Xong — đã có trong code & chạy được (xác minh, đừng xây lại)
  • Hoàn thiện — schema/service đã có, cần state-machine / UI / đấu nối
  • Làm mới — thực sự chưa có, phải xây

Trước khi planning sprint, đối chiếu bảng PO với code để khỏi trả tiền hai lần cho tính năng đã build.

Ba lý do Giai đoạn 2 tồn tại

Mọi thứ còn lại là việc hoàn thiện. Đây là các năng lực thực sự mới định nghĩa Giai đoạn 2 — không thể cắt:

  1. E1 — Thuế cho dải 1–3 tỷ (sổ S2a + tờ khai 01/CNKD + nộp qua T-VAN). Bộ lấy dữ liệu S2a hiện là stub trả dữ liệu giả; đây là phần làm-mới chủ đạo.
  2. E2 — Business Type: bán lẻ + tạp hoá. Code mặc định và hardcode F&B ở ~40–60% của commerce; các ngành mới cần nhánh thật.
  3. E4 — khách hàng doanh nghiệp có MST. Khách hàng hiện chưa lưu được mã số thuế (MST), nên không xuất được hoá đơn VAT cho công ty — yêu cầu bắt buộc, chặn B2B.

Bản đồ phụ thuộc giữa các epic

Quyết định đã chốt (2026-05-31)

  • Ca làm việc phải đa nhân viên → Giai đoạn 2 land refactor feat/shift-variant-2 (đa nhân viên: shift / shift-assignment / shift-device / shift-report), thay cho PosSession 1-user hiện tại.
  • QR self-order · Chế độ offline · Loyalty/voucher · Webshop → Giai đoạn 3. Chúng thực sự chưa có (xây-từ-đầu) và không bắt buộc cho mục tiêu 1–3 tỷ + bán lẻ/tạp hoá.

Tầng ưu tiên

TầngÝ nghĩaEpic
P2-coreLý do Giai đoạn 2 tồn tại; không thể cắtE1 Thuế · E2 Business Type · E4 CRM
P2-finishGiá trị cao, chủ yếu đấu nối code đã buildE3 POS · E5 Báo cáo · E6 Thu chi
P2-importantGiá trị thật, nhỏ khi E4 đã landE7 Giá

E1 · Thuế cho dải 1–3 tỷ Làm mới · P2-core

Mục tiêu: Phục vụ hộ kinh doanh nộp thuế theo % doanh thu — sổ S2a + tờ khai 01/CNKD, nộp được lên cơ quan thuế. Đây là khối làm-mới lớn nhất của Giai đoạn 2.

MụcNhãnBằng chứng / cần làm
Bộ tính TNCN cho S2aLàm mớis2x-hkd.data-fetcher.service.tsstub dữ liệu giả — thay bằng bộ lấy thật: doanh thu × tỷ lệ thuế theo ngành
Tỷ lệ % thuế theo ngànhLàm mớiĐã có entity pricing/tax chung, nhưng chưa có mapping ngành-của-merchant → tỷ lệ; thêm schema + seed tỷ lệ VN
Tờ khai 01/CNKDLàm mớiChưa có — thiết kế schema tờ khai + bộ dựng XML (TaxDeclarationLevel TIRE_0–3 làm điểm móc)
Nộp qua T-VANHoàn thiệnt-van hiện chỉ query (queryInvoiceMessages, queryTaxInformation); thêm POST submit* + audit
Tái dùng: engine sổXongLedgerDataFetcherService tham số hoá theo loại sổ; S1a chạy được, template S2a (s2a-hkd.typ) đã có
Tái dùng: HĐĐT POSXongPOS_VAT/POS_SALE + chế độ REAL_TIME + phát hành qua BullMQ đã sẵn production

Phụ thuộc: E4 (MST khách doanh nghiệp cần cho hoá đơn VAT công ty). Cung cấp cho: E5 (báo cáo thuế/tuân thủ).

E2 · Business Type — bán lẻ + tạp hoá Làm mới · P2-core

Mục tiêu: Làm nền tảng thực sự đa ngành. Enum đã có nhưng hành vi vẫn mang hình F&B.

MụcNhãnBằng chứng / cần làm
Enum ngànhXongMerchantIndustry = RETAIL/FNB/TICKET/OTHER đã định nghĩa
Gỡ hardcode F&BLàm mớimerchant.industry mặc định FNB; template hoá đơn + ~40–60% commerce giả định F&B — thêm nhánh bán lẻ/tạp hoá
Catalog/kho bán lẻHoàn thiệnVariant đã có; thêm khung bán lẻ (size/màu, "catalog" vs "menu"), đấu luồng barcode (hạ tầng InventoryIdentifier đã có)
Tạp hoá: hiển thị lô/HSDXonglotNumber/expiryDate + Typesense isExpired/isExpiringSoon đã có — đưa lên UI tạp hoá
Hoá đơn/thuế theo ngànhHoàn thiệnMerchantInvoiceProfile.businessType (HOUSEHOLD/BUSINESS) quyết định cách tính thuế; mở rộng mapping cho bán lẻ/tạp hoá

Phụ thuộc: E1 (cách tính thuế theo ngành). Cung cấp cho: E5 (KPI theo ngành).

E3 · POS — ca đa nhân viên + KDS + X/Z Hoàn thiện · P2-finish

Mục tiêu: Hoàn thiện sàn F&B/bán lẻ. Chủ yếu đấu nối code đã build — trừ refactor ca đa nhân viên.

MụcNhãnBằng chứng / cần làm
Ca đa nhân viênHoàn thiệnQUYẾT ĐỊNH: land feat/shift-variant-2 (shift/shift-assignment/shift-device/shift-report, commit cc9baf892, hiện need-review). Ổn định + merge, thay cho PosSession 1-user
KDS / gửi bếpXongkitchen-ticket schema + KitchenTicketService.sendToKitchen + Kitchen.screen.tsx + WS + Kafka→inventory đã build hết
In phiếu KDSHoàn thiệnĐấu sendToKitchenPrinterService (tauri-tcp-printer.helper.ts); định nghĩa định dạng phiếu (2 liên)
X/Z reportHoàn thiệnPosSessionReport (X/Z, đủ field) đã có; xây template in + tự sinh Z khi đóng ca
Tách / chuyển bànXongsale-check split + order-split/order-merge; thêm nút context-menu trên sơ đồ bàn
Gộp bànHoàn thiệnorder-merge chỉ chạy với DRAFT; chốt chính sách cho đơn PROCESSING
Đổi trạng thái đơn thủ côngHoàn thiệnThêm PATCH /sale-orders/:id/status nếu cần đổi giữa chừng (hiện: chỉ checkout/cancel + webhook)

Phụ thuộc: refactor ca ổn định. Cung cấp cho: E5 (X/Z), E6 (đối soát tiền mặt theo ca).

E4 · CRM — khách doanh nghiệp + MST + nhóm + công nợ Làm mới · P2-core

Mục tiêu: Biến hồ sơ liên hệ mỏng của Giai đoạn 1 thành CRM thật, và mở B2B. Cụm "chưa có" lớn nhất.

MụcNhãnBằng chứng / cần làm
Khách doanh nghiệp (có MST)Làm mớiuser-profile chưa có MST/công ty → không xuất được hoá đơn VAT công ty; thêm field + validate MST + liên kết hoá đơn
Nhóm khách hàngLàm mớiChưa có — thêm CustomerGroup + bảng thành viên; nền cho giá theo phân khúc ở E7
Công nợ khách hàngLàm mớiChưa có — thêm sổ/số dư công nợ KH (FinanceVoucher đã có partyType=CUSTOMER để xây trên đó)
Công nợ nhà cung cấpHoàn thiệnMaster NCC đã xong; FinanceVoucher PAYMENT đã tự post khi PO-received — thêm sổ/tổng hợp công nợ + UI
Khách hàng cá nhânXongtên+SĐT+email chạy được (customer.service.ts); thêm địa chỉ

Phụ thuộc: —. Cung cấp cho: E1 (hoá đơn VAT công ty), E7 (giá theo phân khúc).

E5 · Báo cáo — P&L + kho Hoàn thiện · P2-finish

Mục tiêu: Cung cấp các con số mà dải 1–3 tỷ cần.

MụcNhãnBằng chứng / cần làm
Báo cáo doanh thuXongSalesReportService (ngày/SP/danh mục) + UI đã có
Dashboard doanh thu toàn hệ thốngHoàn thiệnĐang làm; hoàn thiện dashboard tổng
P&L (lãi/lỗ)Làm mớiCOGS đã post vào finance (handleInventoryIssuedForSale) nhưng chưa có service P&L — xây Doanh thu − COGS − chi phí
Tồn kho & bán chạyHoàn thiệnUI đang ComingSoon; rank từ getProductSales sẵn có; thêm báo cáo tồn/vòng quay

Phụ thuộc: E2 (KPI theo ngành), E3 (dữ liệu ca), E6 (dữ liệu chi phí), E1 (thuế). Xếp lịch trễ.

E6 · Thu chi sâu Hoàn thiện · P2-finish

Mục tiêu: Hoàn thiện mảng tiền mặt — phiếu chi thủ công + đối soát ca.

MụcNhãnBằng chứng / cần làm
Phiếu thuXongFinanceVoucherTypes.RECEIPT tự tạo khi thanh toán thành công
Phiếu chiHoàn thiệnLoại PAYMENT + tự post khi PO-received đã có; xây form tạo/phát hành/huỷ thủ công (chi phí ngoài PO)
Đối soát tiền mặt theo caHoàn thiệncashDiscrepancy đã tính trong closeSession; tự sinh phiếu ADJUSTMENT (lý do CASH_COUNT) + dashboard

Phụ thuộc: E3 (đa ca). Cung cấp cho: E5 (chi phí cho P&L).

E7 · Giá — campaign + phân khúc Hoàn thiện · P2-important

Mục tiêu: Chuyển từ giá phẳng sang giá theo campaign và phân khúc khách hàng. Engine rule đã mạnh; chỉ thiếu trường ngữ cảnh.

MụcNhãnBằng chứng / cần làm
Engine ruleXongToán tử EQ/NE/GT/IN/CONTAINS… + loại khuyến mãi STANDARD/BUY_GET + effectiveFrom/To
Giá theo thời gian/ngàyXongdayOfWeek, calculatingAt đã có trong PricingContext
Giá theo campaignHoàn thiệnThêm campaignId vào promotion + context (trường thời gian đã dùng được)
Giá theo phân khúc (VIP/member)Hoàn thiệnThêm customerGroupId/customerType vào PricingContext + rule mẫu

Phụ thuộc: E4 (nhóm khách hàng). Cung cấp cho: —.

Hoãn sang Giai đoạn 3 (quyết định 2026-05-31)

Thực sự chưa có (xây-từ-đầu) và không bắt buộc cho mục tiêu 1–3 tỷ + bán lẻ/tạp hoá:

Năng lựcVì sao Giai đoạn 3Trạng thái code
QR self-orderBề mặt mới hướng khách + ánh xạ QR-bànChưa có
Chế độ offlineCần local store + hàng đợi sync + xử lý xung đột trong TauriChỉ có banner UI
Loyalty / voucher / điểmĐiểm chỉ có EARN (chưa REDEEM); chưa có model voucherMột phần/chưa có
WebshopApp riêng, phạm vi lớnChưa có (đã dự kiến)
Device hubĐiều khiển thiết bị tập trung vượt mức thông tin kết nốiChưa có

Trình tự đề xuất (T6 → T9/2026)

Tháng 6 chủ yếu là Giai đoạn 1, không phải Giai đoạn 2

T6 = UAT Giai đoạn 1 + dọn carry-over (cổng MVP). Năng lực build Giai đoạn 2 thật là ~T7–T9 (≈10–11 tuần). Đừng tính nợ Giai đoạn 1 thành Giai đoạn 2.

KhốiTrọng tâmCông việc
T6 (song song)Spec + harvestViết spec E1 thuế + E2 Business-Type · "harvest sprint": kích hoạt các mục đã build rủi ro thấp (in KDS, template X/Z, state machine InventoryTicket) trong khi chạy UAT
T7 — nền tảng3 lý do cốt lõiE1 bộ tính S2a + tỷ lệ thuế theo ngành · E2 nhánh bán lẻ/tạp hoá · E4 MST khách doanh nghiệp
T8 — chiều sâuXây trên nền tảngE1 tờ khai 01/CNKD + nộp T-VAN · E3 land refactor đa ca · E4 công nợ · E6 phiếu chi + đối soát · E7 ngữ cảnh giá
T9 — phân tích + ổn địnhHạ nguồn + ổn địnhE5 báo cáo P&L + kho · tích hợp + UAT cho 1–3 tỷ & bán lẻ/tạp hoá

Lan can định cỡ

Review WK22 cho thấy tỷ lệ hoàn thành sụp khi một cycle cam kết ~100 mục so với mức bền vững ~32 (16 người × 2). Định cỡ mỗi sprint Giai đoạn 2 theo trần đó và giữ carry-over Giai đoạn 1 ngoài con số Giai đoạn 2.

Trang liên quan

Proprietary and Confidential. Unauthorized copying, distribution, or use of this software is strictly prohibited.