187 lines
19 KiB
Markdown
187 lines
19 KiB
Markdown
# PROCESS — Quy trình AS-IS / TO-BE — Giỏ hàng & Checkout (e-commerce)
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Version** | 1.0 |
|
||
| **Date** | 2026-09-08 |
|
||
| **Author** | BA (qua skill ba-2-analysis) |
|
||
| **Status** | 🟡 Draft |
|
||
| **Approved by** | — |
|
||
| **Profile** | screen · greenfield · standard (xem `00-index/PROFILE_e-commerce.md`) |
|
||
| **Source** | `01-discovery/BRIEF_CartCheckout_v1.0.md` · `01-discovery/RISK_CartCheckout_v1.0.md` · `01-discovery/ELICITATION_CartCheckout_2026-09-08.md` · `e-commerce/docs/sections/06-luong-xu-ly.md` §6.1.1, §6.3.1, §6.4 BR-01/BR-02/BR-15 (chỉ dùng làm tài liệu tham chiếu kỹ thuật, không chép nguyên văn thiết kế) · `e-commerce/docs/sections/05-thiet-ke-du-lieu.md` §5.2.3 (tham chiếu entity) |
|
||
| **Scope** | Module Giỏ hàng & Checkout — RQ-001…RQ-004 (`BRIEF_CartCheckout_v1.0.md`) |
|
||
|
||
## Change Log
|
||
|
||
| Version | Date | Người sửa | Thay đổi | CR |
|
||
|---|---|---|---|---|
|
||
| 1.0 | 2026-09-08 | BA (qua skill ba-2-analysis) | Bản đầu | — |
|
||
|
||
---
|
||
|
||
> ⚠️ **Ngoại lệ gate G1** — `BRIEF_CartCheckout_v1.0.md` tự chấm **chưa đủ điều kiện ký chính
|
||
> thức** (3/6 tiêu chí G1 còn ☐: thiếu tên thật stakeholder, thiếu buổi làm việc trực tiếp,
|
||
> KPI chưa có baseline số — xem mục "Tự chấm" cuối `BRIEF`). Tài liệu này được viết tiếp theo
|
||
> **xác nhận rõ ràng của người điều phối** rằng vẫn muốn chạy GĐ2 trong khi chờ G1 ký chính
|
||
> thức, cho mục đích đánh giá bộ skill BA. Xem `DEC-02` ở `00-index/DECISION_e-commerce.md`.
|
||
> Toàn bộ nội dung dưới đây **phải rà lại** khi G1 được ký thật (đặc biệt phần A3–A5 và B3, vì
|
||
> chúng dựa trên `RISK`/`ASM` chưa được PO xác nhận).
|
||
|
||
## 1. Phạm vi quy trình
|
||
|
||
| | |
|
||
|---|---|
|
||
| **Tên quy trình** | Giỏ hàng đa seller → Checkout → Tách đơn theo seller → Thanh toán |
|
||
| **Điểm bắt đầu** | Customer/Guest có ≥1 sản phẩm trong giỏ hàng và bấm "Đặt hàng" |
|
||
| **Điểm kết thúc** | Đơn hàng cha (`Order`) và các đơn con theo seller (`OrderSeller`) đã được tạo, ở trạng thái `pending_payment` hoặc `confirmed` tuỳ phương thức thanh toán — bàn giao cho module Quản lý đơn hàng (FR-08/FR-19, ngoài phạm vi) |
|
||
| **Tần suất** | Theo mỗi lượt checkout — chưa đo được (greenfield, chưa vận hành) |
|
||
| **Khối lượng** | Chưa đo — quy mô mục tiêu "lớn" theo `BRIEF` §2 (hàng trăm nghìn–hàng triệu user, cao điểm hàng nghìn–chục nghìn concurrent mùa flash sale) |
|
||
| **Vai trò tham gia** | Customer, Guest (không có vai trò nội bộ nào tham gia trực tiếp trong phạm vi RQ-001…RQ-004 — đây là luồng self-service) |
|
||
|
||
---
|
||
|
||
# PHẦN A — AS-IS (hiện trạng)
|
||
|
||
## 0. Vì sao PHẦN A rút gọn còn A3–A5, và vì sao A3–A5 không mô tả "hiện trạng" theo nghĩa thông thường
|
||
|
||
Theo `00-index/PROFILE_e-commerce.md` (`LIFECYCLE = greenfield`) và theo `domain-profiles.md`
|
||
§2, PHẦN A rút gọn còn **A3 (điểm đau) · A4 (đường tắt) · A5 (ngoại lệ)**, bỏ A1/A2/A6. Lý do
|
||
bỏ A1/A2/A6: dự án là marketplace hoàn toàn mới, **không có hệ thống hay quy trình thủ công
|
||
nào đang chạy để vẽ sơ đồ luồng/bảng bước** cho việc "một khách mua từ nhiều seller trong một
|
||
giỏ hàng, hệ thống tự tách đơn" — xác nhận tại `ELICITATION_CartCheckout_2026-09-08.md` F7:
|
||
*"Không có hệ thống cũ (ERP/kho/CRM) cần tích hợp hoặc migrate cho luồng giỏ hàng/checkout —
|
||
dự án hoàn toàn mới."* Không có A1 (sơ đồ) thì cũng không có A2 (bảng bước) tương ứng để điền,
|
||
và A6 (hệ thống/dữ liệu đang dùng) không áp dụng vì chưa có hệ thống nào đang dùng.
|
||
|
||
🔴 Vì không có "hiện trạng" thật, A3–A5 dưới đây **không phải điểm đau/đường tắt/ngoại lệ đã
|
||
quan sát được từ vận hành thật** (không thể có, vì chưa vận hành). Thay vào đó, ba mục này
|
||
tổng hợp lại **rủi ro và giả định đã ghi ở GĐ1** (`RISK_CartCheckout_v1.0.md`,
|
||
`ELICITATION_CartCheckout_2026-09-08.md`) dưới đúng hình thức "spec ẩn" mà A3–A5 được thiết kế
|
||
để bắt: chỗ nào TO-BE dễ bỏ sót nhất nếu không đối chiếu lại. Đây là cách diễn giải hợp lý
|
||
nhất của A3–A5 cho một luồng greenfield — không tự bịa thêm dữ liệu quan sát không có thật.
|
||
|
||
## A3. Điểm đau (rủi ro tương đương — chưa có dữ liệu vận hành thật)
|
||
|
||
| ID | Bước TO-BE liên quan | Vấn đề dự kiến | Tần suất | Hậu quả đo được | → RQ |
|
||
|---|---|---|---|---|---|
|
||
| P1 | B7 (xác nhận đơn COD) | Giỏ hàng đa seller tách thành nhiều đơn COD độc lập; MVP chưa có giới hạn giá trị đơn COD (`ASM-05`, chưa xác minh) → khách có thể chỉ nhận một phần đơn, từ chối phần còn lại | Chưa đo — `RISK-01` đánh giá Khả năng: Cao, Tác động: Cao (🔴) | Seller chịu phí vận chuyển hoàn hàng, tranh chấp seller–sàn hàng loạt ở quy mô lớn | RQ-002, RQ-003 |
|
||
| P2 | B8→D3 (chờ xác nhận thanh toán VNPay/Momo) | Webhook xác nhận thanh toán chưa được xác minh khả thi gần thời gian thực (`ASM-01`) → đơn có thể bị trừ tiền nhưng hệ thống không nhận được xác nhận kịp thời | Chưa đo — `RISK-02` đánh giá Khả năng: Trung bình, Tác động: Cao (🔴) | Đơn kẹt "chờ thanh toán" dù tiền đã được gateway ghi nhận, khiếu nại CSKH, sai lệch đối soát với Kế toán (STK-04) | RQ-003 |
|
||
| P3 | B3 (ước tính phí ship theo từng seller) | Phí vận chuyển tính riêng cho từng đơn con theo seller có thể cao hơn đáng kể so với mua từ một seller | Chưa đo — `RISK-04` đánh giá Khả năng: Trung bình, Tác động: Trung bình (🟠) | Khách bỏ giỏ hàng ở bước checkout, ảnh hưởng trực tiếp `GOAL-01`/`GOAL-02` | RQ-001, RQ-002 |
|
||
|
||
## A4. Đường tắt dự kiến (suy luận — chưa có dữ liệu vận hành thật, đánh dấu rõ là giả định)
|
||
|
||
*Vì chưa vận hành, không thể quan sát "người ta đang lách quy trình thế nào". Bảng dưới là suy
|
||
luận có nguồn (hành vi thị trường tương tự + rủi ro đã ghi ở GĐ1), **không phải quan sát thật**
|
||
— PO/Tech Lead cần xác nhận lại khi có dữ liệu soft-launch.*
|
||
|
||
| # | Ai làm | Làm gì ngoài quy trình (dự đoán) | Vì sao phải làm vậy | Ẩn ý về yêu cầu |
|
||
|---|---|---|---|---|
|
||
| 1 | Customer | Đặt hàng riêng lẻ với từng seller qua kênh khác (mạng xã hội, điện thoại) thay vì dùng giỏ hàng đa seller | Nếu tổng phí ship gộp hiển thị cao hoặc luồng checkout phức tạp, khách có thể quay lại cách mua cũ (nếu seller có kênh riêng) | Cần hiển thị rõ, sớm phí ship theo từng seller trước khi khách cam kết đặt hàng (US-005), không để tới bước cuối mới lộ tổng chi phí thật |
|
||
| 2 | CSKH (ngoài phạm vi module này, nhưng liên đới) | Xác nhận thủ công qua điện thoại/email với khách khi đơn kẹt "chờ thanh toán" quá lâu (do `RISK-02`) | Webhook thanh toán chưa được xác minh đáng tin cậy | Module Thanh toán (GĐ3, có thể ngoài phạm vi US của module này) cần cơ chế đối soát bù tự động, không chỉ dựa vào webhook một lần — ghi nhận là phụ thuộc, xem `IMPACT_CartCheckout_v1.0.md` §1.5 |
|
||
|
||
## A5. Ngoại lệ đã biết trước (từ tài liệu SAD, cần BA/PO xác nhận lại là spec chính thức của module này)
|
||
|
||
🔴 Các dòng dưới đây **tham chiếu** thiết kế kỹ thuật đã có ở
|
||
`e-commerce/docs/sections/06-luong-xu-ly.md` (tài liệu SAD, không phải quyết định BA/PO) — dùng
|
||
làm gợi ý ngoại lệ cần rà, **không** coi là spec đã chốt cho tới khi PO/Tech Lead xác nhận lại
|
||
trong phạm vi BA.
|
||
|
||
| # | Ca ngoại lệ | Tần suất | Cách xử lý tham chiếu (SAD) | Ai xử lý | TO-BE của module này có xử lý? |
|
||
|---|---|---|---|---|---|
|
||
| E1 | Không đủ tồn kho khi checkout (nhiều khách cùng mua sản phẩm sắp hết trong lúc flash sale) | Chưa đo — dự kiến cao trong mùa flash sale (`NFR-02`) | SAD §6.4 BR-02: giữ tồn kho (reserve) khi `POST /checkout`, trả lỗi nếu không đủ, yêu cầu điều chỉnh giỏ hàng | Hệ thống | ✅ Có — US-004 (xem `BR_CartCheckout_v1.0.md` BR-CART-02) |
|
||
| E2 | Giá/tồn kho hiển thị trong giỏ thay đổi giữa lúc thêm giỏ và lúc checkout | Chưa đo (`ASM-06`, chưa xác minh) | SAD chưa mô tả cơ chế khoá giá/tồn kho tạm thời (reservation) cho riêng trường hợp này ở mức UX | Chưa xác định | ☐ Chưa xử lý — xem `OQ-009` |
|
||
| E3 | Không tạo được vận đơn qua GHN (timeout/lỗi) khi tính phí ship lúc checkout | Chưa đo | SAD §6.4 BR-15: fallback GHTK, nếu cả hai lỗi thì Ops xử lý thủ công | Hệ thống/Ops | ➖ Ngoài phạm vi — BR-15 áp dụng ở bước **tạo vận đơn sau khi đơn đã tồn tại** (FR-26), không phải lúc ước tính phí ship trong checkout. Trong phạm vi module này, nếu GHN/GHTK không phản hồi lúc checkout thì chỉ ảnh hưởng tới việc hiển thị phí ước tính (xem `ASM-02`, chưa xác minh) |
|
||
| E4 | Khách chọn thanh toán COD cho đơn giá trị lớn (không có giới hạn ở MVP theo `ASM-05`) | Chưa đo | Không có xử lý nào ở SAD — đây thuần là quyết định nghiệp vụ chưa chốt | PO chưa chỉ định | ☐ Chưa xử lý — xem `OQ-006` (đã mở từ GĐ1, nhắc lại vì chặn `BR-CART-03` ở GĐ2) |
|
||
|
||
---
|
||
|
||
# PHẦN B — TO-BE (đề xuất)
|
||
|
||
## B1. Sơ đồ luồng
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
START(["Customer/Guest có sản phẩm trong giỏ, bấm Đặt hàng"]) --> B1["🆕 B1. Xem giỏ hàng nhóm theo seller · Customer/Guest · US-002"]
|
||
B1 --> B2["🆕 B2. Chọn/nhập địa chỉ giao hàng · Customer/Guest · US-005"]
|
||
B2 --> B3["🆕 B3. Hệ thống ước tính phí ship theo từng seller · Hệ thống · US-005"]
|
||
B3 --> D1{"Đủ tồn kho tất cả item? (BR-CART-02)"}
|
||
D1 -->|Không| B4["🆕 ⚠️ P1' · B4. Báo lỗi, yêu cầu điều chỉnh giỏ hàng · Hệ thống · US-004"]
|
||
B4 --> B1
|
||
D1 -->|Có| B5["🆕 B5. Tách giỏ hàng thành các đơn con theo seller (BR-CART-01) · Hệ thống · US-004"]
|
||
B5 --> B6["🆕 B6. Chọn phương thức thanh toán COD/VNPay/Momo · Customer/Guest · US-007, US-008"]
|
||
B6 --> D2{"Phương thức thanh toán?"}
|
||
D2 -->|COD| B7["🆕 B7. Xác nhận đơn COD · Hệ thống · US-007"]
|
||
D2 -->|VNPay/Momo| B8["🆕 B8. Chuyển hướng cổng thanh toán, chờ xác nhận · Hệ thống + bên ngoài · US-008"]
|
||
B7 --> ENDOK(["Đơn con đã tạo — bàn giao FR-08/FR-19 (ngoài phạm vi)"])
|
||
B8 --> D3{"Thanh toán thành công? (webhook, BR-CART-06)"}
|
||
D3 -->|Có| ENDOK
|
||
D3 -->|"Không / timeout"| B9["⚠️ P2' · B9. Đơn giữ pending_payment — cần cơ chế đối soát bù (ngoài phạm vi US module này)"]
|
||
B9 --> ENDWAIT(["Chờ xử lý bù — xem IMPACT §1.5"])
|
||
```
|
||
|
||
*Đánh dấu `🆕` mọi bước vì không có AS-IS để so sánh (bỏ B4/B5 dạng "bước bị bỏ/bước cũ" —
|
||
xem giải thích ở §0 Phần A). `⚠️ P1'/P2'` tham chiếu điểm đau `P1`/`P2` ở A3.*
|
||
|
||
## B2. Bảng chi tiết từng bước
|
||
|
||
| # | Bước | Loại | Ai làm | Input | Output | Hệ thống | ⏱ Dự kiến | US |
|
||
|---|---|---|---|---|---|---|---|---|
|
||
| B1 | Xem giỏ hàng nhóm theo seller | 🆕 | Customer/Guest | Danh sách `CartItem` trong `Cart` | Giỏ hàng hiển thị nhóm theo `seller_id` kèm tổng tiền từng nhóm | Cart & Order Service (nội bộ) | Đích NFR-01: phản hồi màn hình < 2 giây | US-002 |
|
||
| B2 | Chọn/nhập địa chỉ giao hàng | 🆕 | Customer/Guest | Địa chỉ đã lưu (Customer) hoặc nhập mới (Guest) | Địa chỉ giao hàng gắn với phiên checkout | Identity & Access Service (đọc `customer_address`, nếu có tài khoản) | Chưa ước lượng — phụ thuộc UX GĐ3 | US-005 |
|
||
| B3 | Ước tính phí ship theo từng seller | 🆕 | Hệ thống | Địa chỉ giao hàng + danh sách seller trong giỏ | Phí ship ước tính theo từng đơn con (nếu `ASM-02` đúng) | GHN/GHTK (bên ngoài, `ASM-02` chưa xác minh) | Chưa ước lượng — phụ thuộc SLA API GHN/GHTK | US-005 |
|
||
| B4 | Báo lỗi không đủ tồn kho | 🆕 | Hệ thống | Kết quả kiểm tra `inventory_stock` | Thông báo lỗi, giữ nguyên giỏ hàng để khách điều chỉnh | Catalog & Inventory Service | Tức thời (đồng bộ, trong luồng checkout) | US-004 |
|
||
| B5 | Tách giỏ hàng thành đơn con theo seller | 🆕 | Hệ thống | `Cart` + `CartItem` đã nhóm theo `seller_id` | `Order` (cha) + nhiều `OrderSeller` (con) + `OrderItem` | Cart & Order Service (nội bộ) | Đích NFR-01: hoàn tất checkout < 3 giây (cả B1–B5) | US-004 |
|
||
| B6 | Chọn phương thức thanh toán | 🆕 | Customer/Guest | Danh sách phương thức khả dụng (COD/VNPay/Momo) | Phương thức đã chọn gắn với `Order` | Cart & Order Service | Chưa ước lượng | US-007, US-008 |
|
||
| B7 | Xác nhận đơn COD | 🆕 | Hệ thống | `Order` + phương thức = COD | `OrderSeller.status` chuyển theo `BR-CART-07`/`BR-CART-03` (chờ PO chốt giới hạn COD) | Cart & Order Service | Tức thời | US-007 |
|
||
| B8 | Chuyển hướng cổng thanh toán, chờ xác nhận | 🆕 | Hệ thống + VNPay/Momo | `Order` + phương thức = VNPay/Momo | Redirect URL, sau đó webhook xác nhận | Payment Service + VNPay/Momo (bên ngoài) | Phụ thuộc SLA cổng thanh toán (`ASM-01` chưa xác minh) | US-008 |
|
||
| B9 | Giữ đơn `pending_payment`, chờ đối soát bù | ⚠️ | Hệ thống | Không nhận được webhook đúng hạn | Đơn ở trạng thái chờ, cần cơ chế đối soát bù (ngoài phạm vi thiết kế chi tiết US module này) | Payment Service | Chưa xác định — phụ thuộc `RISK-02` | Ghi nhận, không có US riêng trong module này |
|
||
|
||
**Tổng thời gian dự kiến:** B1→B5 (đến khi tạo đơn) phải đạt < 3 giây theo `NFR-01`; không có
|
||
AS-IS để so sánh (xem §0 Phần A).
|
||
|
||
## B3. Đối chiếu điểm đau → cách xử lý
|
||
|
||
| Điểm đau | Bước TO-BE xử lý | Cách xử lý | Hiệu quả kỳ vọng | Nếu không xử lý: lý do |
|
||
|---|---|---|---|---|
|
||
| P1 (COD bùng đơn một phần, `RISK-01`) | B7 | **Chưa xử lý triệt để** — `BR-CART-03` (giới hạn giá trị đơn COD) đang chờ PO chốt (`OQ-006`, đã mở từ GĐ1). B7 chỉ tạo đơn theo phương thức đã chọn, chưa có bước chặn/giới hạn | Nếu PO chốt giới hạn: giảm rủi ro seller chịu phí hoàn hàng | Nếu PO không chốt giới hạn: rủi ro tồn tại nguyên vẹn trong TO-BE — **đây là khoảng trống đã biết, không phải bỏ sót**, ghi rõ trong `IMPACT` §0 |
|
||
| P2 (webhook trễ, `RISK-02`) | B9 | Ghi nhận trạng thái chờ; cơ chế đối soát bù (reconciliation job) là đề xuất của GĐ1 (`RISK-02`), **thuộc thiết kế chi tiết của module Thanh toán ở GĐ3**, không phải một US của module Giỏ hàng & Checkout (RQ-001…004 không bao gồm vận hành đối soát) | Giảm số đơn kẹt lâu, giảm khiếu nại CSKH | Nếu không xây cơ chế đối soát bù ở GĐ3: đơn có thể kẹt vô thời hạn — ghi nhận là phụ thuộc bắt buộc, xem `IMPACT` §1.5 |
|
||
| P3 (phí ship cao khiến bỏ giỏ, `RISK-04`) | B3 | Hiển thị phí ước tính **sớm** (ngay sau khi nhập địa chỉ, trước khi khách xác nhận thanh toán) để minh bạch hoá — không giải quyết triệt để việc phí cao, chỉ giảm bất ngờ | Giảm tỷ lệ bỏ giỏ do "phí ẩn xuất hiện cuối cùng"; không giảm được tổng phí | Việc giảm phí ship (VD trợ giá) là quyết định thương mại của PO, **ngoài phạm vi BA** — xem `RISK-04` phương án đề xuất |
|
||
|
||
## B4. Bước bị bỏ — ai làm thay
|
||
|
||
*Không có — không có AS-IS Phần A1/A2 để so sánh (giải thích ở §0 Phần A, greenfield không có
|
||
quy trình cũ nào bị thay thế bởi module này).*
|
||
|
||
## B5. Bước mới — ai có thời gian làm
|
||
|
||
| Bước mới | Ai làm | Thêm bao nhiêu thời gian/ngày | Đã hỏi người đó chưa |
|
||
|---|---|---|---|
|
||
| B1–B8 (toàn bộ luồng) | Customer/Guest tự thao tác (self-service qua giao diện); không có vai trò nội bộ nào phải làm thêm việc thủ công trong phạm vi RQ-001…004 | 0 — không phát sinh việc thủ công cho nhân sự nội bộ, vì đây là luồng tự phục vụ hoàn toàn | N/A |
|
||
| B9 (giữ đơn chờ đối soát) | *Nếu* cần CSKH can thiệp thủ công (theo A4 mục 2) | Chưa ước lượng — phụ thuộc tần suất webhook trễ thực tế (chưa đo) | ☐ Chưa hỏi — CSKH (STK ngoài phạm vi stakeholder module này) chưa được phỏng vấn |
|
||
|
||
## B6. Thay đổi với người dùng
|
||
|
||
| Vai trò | Trước | Sau | Cần đào tạo gì | Mức kháng cự dự kiến |
|
||
|---|---|---|---|---|
|
||
| Customer/Guest | Không có trải nghiệm nào (sản phẩm/thị trường hoàn toàn mới) | Trải nghiệm mua từ nhiều seller trong một giỏ, một lần thanh toán | Hướng dẫn UX tại chỗ (onboarding/tooltip) — chi tiết thuộc `WF`/`UICONV` ở GĐ3, ngoài phạm vi tài liệu này | Thấp (không có thói quen cũ để phá vỡ) — nhưng cần đo thật ở soft-launch theo `GOAL-01` |
|
||
|
||
---
|
||
|
||
## 2. Open Questions
|
||
|
||
| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì |
|
||
|---|---|---|---|---|
|
||
| OQ-006 | *(đã mở từ GĐ1, nhắc lại)* Chính sách giới hạn giá trị đơn COD là gì? | PO sàn, Kế toán đối soát | 2026-09-08 | `BR-CART-03`, bước B7 |
|
||
| OQ-009 | Khi giá/tồn kho thay đổi giữa lúc thêm giỏ và lúc checkout (`ASM-06`), hệ thống tự động cập nhật giá mới và thông báo, hay chặn checkout yêu cầu khách xác nhận lại? | PO + Tech Lead | 2026-09-08 | Bước B3/B5, AC của US-004/US-005 ở GĐ3 |
|
||
| OQ-010 | Xác nhận khả thi kỹ thuật `ASM-01` (webhook VNPay/Momo gần thời gian thực) | Tech Lead | 2026-09-08 | Bước B8/D3, `BR-CART-06`, US-008 |
|
||
|
||
## 3. Ngoài phạm vi
|
||
|
||
- Thiết kế màn hình chi tiết (bố cục, field) → GĐ3 `SRS`/`WF`
|
||
- Chi tiết business rule (công thức, ví dụ đúng/sai) → `BR_CartCheckout_v1.0.md`
|
||
- Ma trận phân quyền → `RBAC_CartCheckout_v1.0.md`
|
||
- Luồng sau khi đơn đã tạo (đóng gói, giao hàng, đổi trả, khiếu nại — FR-08, FR-09, FR-19,
|
||
FR-25, FR-26) → module Quản lý đơn hàng, chạy GĐ1/GĐ2 riêng
|
||
- Cơ chế đối soát bù thanh toán (bước B9) → thiết kế chi tiết ở GĐ3 của module Thanh toán,
|
||
không phải một US của module này
|