sys-analysis-design/ba-output/e-commerce/02-analysis/BACKLOG_CartCheckout_v1.0.md

BACKLOG — 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 (RQ-001…RQ-004) · PROCESS_CartCheckout_v1.0.md v1.0 · Trả lời của người dùng cho OQ-004 và OQ-008 (xem DEC-03, DEC-04 ở 00-index/DECISION_e-commerce.md)
Scope	Module Giỏ hàng & Checkout — RQ-001…RQ-004. Ưu tiên phân rã US cho màn hình Giỏ hàng (FR-05) và Checkout & tách đơn (FR-06), theo đúng chỉ định phạm vi lần chạy này. Tối đa 8 US (giới hạn theo chỉ đạo "tối đa 6–8 US").

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 — 8 US, 2 Epic, 3 Feature	—

---

⚠️ Ngoại lệ gate G1 — xem cảnh báo đầy đủ ở đầu PROCESS_CartCheckout_v1.0.md. Tài liệu này được viết tiếp trong khi BRIEF module chưa qua G1 chính thức, theo xác nhận của người điều phối — xem DEC-02 ở 00-index/DECISION_e-commerce.md. Backlog dưới đây phải rà lại phạm vi và ưu tiên khi PO ký G1 thật.

0. Sơ đồ Use Case — toàn cảnh cho PO

flowchart LR
    GUEST(["👤 Guest"])
    CUS(["👤 Customer"])

    subgraph HT["Phạm vi RQ-001…RQ-004 — Giỏ hàng & Checkout"]
        UC1(["US-001 Thêm sản phẩm đa seller vào giỏ"])
        UC2(["US-002 Xem giỏ hàng nhóm theo seller"])
        UC3(["US-003 Sửa/xoá sản phẩm trong giỏ"])
        UC4(["US-004 Checkout & tách đơn theo seller"])
        UC5(["US-005 Nhập địa chỉ & xem phí ship theo seller"])
        UC6(["US-006 Checkout không cần tài khoản (Guest)"])
        UC7(["US-007 Thanh toán COD"])
        UC8(["US-008 Thanh toán VNPay/Momo"])
    end

    NGOAI1[["Catalog & Tìm kiếm — ngoài phạm vi"]]
    NGOAI2[["VNPay/Momo — ngoài phạm vi (bên thứ 3)"]]
    NGOAI3[["GHN/GHTK — ngoài phạm vi (bên thứ 3)"]]
    NGOAI4[["Khuyến mãi & Loyalty — ngoài phạm vi (điểm tích hợp, OQ-004 đã đóng)"]]

    GUEST --- UC1
    GUEST --- UC2
    GUEST --- UC3
    GUEST --- UC4
    GUEST --- UC5
    GUEST --- UC6
    GUEST --- UC7
    GUEST --- UC8
    CUS --- UC1
    CUS --- UC2
    CUS --- UC3
    CUS --- UC4
    CUS --- UC5
    CUS --- UC7
    CUS --- UC8

    UC1 --- NGOAI1
    UC5 --- NGOAI3
    UC8 --- NGOAI2
    UC4 -.-> NGOAI4

Customer không có US-006 riêng (Guest checkout không áp dụng cho tài khoản đã có). Liên kết nét đứt UC4 -.-> NGOAI4 = điểm tích hợp hiển thị kết quả coupon/điểm thưởng do module khác tính (đã đóng OQ-004, xem DEC-03), module này chỉ gọi API áp dụng và hiển thị.

Actor trong sơ đồ	Vai trò trong RBAC	Số US
Guest	ROLE-01	8
Customer	ROLE-02	7 (không gồm US-006)

Actor khớp RBAC_CartCheckout_v1.0.md §1.

1. Cây phân rã

flowchart LR
    RQ001["RQ-001 Giỏ hàng đa seller"]
    RQ002["RQ-002 Tách đơn theo seller"]
    RQ003["RQ-003 Thanh toán VNPay/Momo/COD"]
    RQ004["RQ-004 Guest checkout"]

    E01["EPIC-01 Giỏ hàng & Checkout đa seller"]
    E02["EPIC-02 Thanh toán đa kênh"]

    F01["FEAT-01 Quản lý giỏ hàng đa seller"]
    F02["FEAT-02 Checkout & tách đơn theo seller"]
    F03["FEAT-03 Thanh toán"]

    U01(["US-001"])
    U02(["US-002"])
    U03(["US-003"])
    U04(["US-004"])
    U05(["US-005"])
    U06(["US-006"])
    U07(["US-007"])
    U08(["US-008"])

    RQ001 --> E01
    RQ002 --> E01
    RQ004 --> E01
    RQ003 --> E02

    E01 --> F01
    E01 --> F02
    E02 --> F03

    F01 --> U01
    F01 --> U02
    F01 --> U03
    F02 --> U04
    F02 --> U05
    F02 --> U06
    F03 --> U07
    F03 --> U08

2. Epic

ID	Tên	Giá trị nghiệp vụ	RQ phủ	Feature	Ưu tiên
EPIC-01	Giỏ hàng & Checkout đa seller	Cho phép khách mua từ nhiều seller trong một trải nghiệm thống nhất — điều kiện tiên quyết của mô hình marketplace	RQ-001, RQ-002, RQ-004	FEAT-01, FEAT-02	Must — ưu tiên hàng đầu theo OQ-008 (đã đóng, xem DEC-04)
EPIC-02	Thanh toán đa kênh	Thu tiền qua kênh phổ biến VN mà không lưu thẻ, giảm phạm vi PCI-DSS	RQ-003	FEAT-03	Must, nhưng nội bộ Feature có thứ tự con: COD trước, ví điện tử có thể lùi (xem OQ-008/DEC-04 và §8)

3. Feature

ID	Tên	Epic	Mô tả một câu	US	MoSCoW
FEAT-01	Quản lý giỏ hàng đa seller	EPIC-01	Customer/Guest thêm, xem, sửa, xoá sản phẩm từ nhiều seller trong một giỏ hàng	US-001, US-002, US-003	Must
FEAT-02	Checkout & tách đơn theo seller	EPIC-01	Customer/Guest xác nhận đặt hàng; hệ thống thu địa chỉ, tính phí ship, tách đơn theo seller, hỗ trợ cả Guest	US-004, US-005, US-006	Must
FEAT-03	Thanh toán	EPIC-02	Customer/Guest thanh toán qua COD hoặc VNPay/Momo	US-007, US-008	Must (US-007) — US-008 Must nhưng có thể triển khai sau theo DEC-04

4. User Story

Mẫu — cả ba vế bắt buộc: Là <vai trò cụ thể>, tôi muốn <hành động>, để <giá trị nghiệp vụ>.

US-001 — Thêm sản phẩm từ nhiều seller vào giỏ hàng

Feature	FEAT-01
RQ	RQ-001
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	Không — US nền tảng đầu tiên
BR áp dụng	(chưa có BR ràng buộc số lượng seller/sản phẩm tối đa trong giỏ — xem OQ mới nếu phát sinh ở GĐ3)
Ước lượng sơ bộ	M

Story:

Là Customer hoặc Guest, tôi muốn thêm sản phẩm từ nhiều seller khác nhau vào cùng một giỏ hàng, để tôi có thể mua sắm từ nhiều gian hàng mà không phải đặt hàng riêng lẻ với từng seller.

Phạm vi:

• Trong: thêm CartItem từ bất kỳ seller nào vào Cart hiện có của khách (theo customer_id hoặc session_id nếu Guest)
• Ngoài: kiểm tra tồn kho thời điểm checkout (thuộc US-004), tính giá sau khuyến mãi (thuộc module Khuyến mãi/Loyalty theo OQ-004/DEC-03)

Điều kiện nghiệm thu mức thô:

• Thêm được sản phẩm của seller A rồi seller B vào cùng một giỏ mà không bị lỗi/mất dữ liệu của seller A
• Giỏ hàng của Guest được giữ lại theo phiên (thời hạn cụ thể — GĐ3 xác nhận, tham khảo SAD §5.3.1 đề xuất 7 ngày cho Guest, cần Tech Lead xác nhận có áp dụng đúng con số này không)

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	✅	✅	✅	—

US-002 — Xem giỏ hàng nhóm theo seller

Feature	FEAT-01
RQ	RQ-001
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	US-001 (phải có sản phẩm trong giỏ trước)
BR áp dụng	(chưa có — mục hiển thị thuần tuý)
Ước lượng sơ bộ	M

Story:

Là Customer hoặc Guest, tôi muốn xem giỏ hàng của mình được nhóm hiển thị theo từng seller kèm tổng tiền từng nhóm, để tôi biết rõ mình đang mua gì của ai trước khi quyết định đặt hàng.

Phạm vi:

• Trong: hiển thị màn hình Giỏ hàng (FR-05, ưu tiên của lần chạy này) nhóm CartItem theo seller_id, tổng tiền từng nhóm, tổng tiền toàn giỏ
• Ngoài: phí vận chuyển (chưa biết tới lúc checkout — thuộc US-005), áp dụng coupon/điểm thưởng (module khác, OQ-004/DEC-03)

Điều kiện nghiệm thu mức thô:

• Giỏ hàng có sản phẩm của 3 seller hiển thị đúng 3 nhóm, mỗi nhóm đúng tổng tiền của nhóm đó
• Giỏ hàng rỗng hiển thị trạng thái rỗng rõ ràng (text cụ thể — GĐ3, W5)

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	✅	✅	✅	—

US-003 — Sửa số lượng / xoá sản phẩm trong giỏ hàng

Feature	FEAT-01
RQ	RQ-001
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	US-001
BR áp dụng	(chưa có — ràng buộc số lượng tối thiểu/tối đa mỗi dòng chưa được chốt, xem GĐ3)
Ước lượng sơ bộ	S

Story:

Là Customer hoặc Guest, tôi muốn cập nhật số lượng hoặc xoá sản phẩm khỏi giỏ hàng, để tôi kiểm soát đúng những gì mình sẽ mua trước khi checkout.

Phạm vi:

• Trong: sửa quantity, xoá CartItem khỏi Cart
• Ngoài: cảnh báo hết hàng theo thời gian thực (thuộc US-004 tại thời điểm checkout, không phải tại thời điểm xem/sửa giỏ — trừ khi PO quyết khác, xem OQ-009)

Điều kiện nghiệm thu mức thô:

• Sửa số lượng thành 0 ⇒ hành vi (xoá luôn hay chặn) — chưa chốt, cần OQ ở GĐ3
• Xoá hết sản phẩm của một seller ⇒ nhóm hiển thị theo seller đó biến mất (US-002)

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	✅	✅	E: hành vi khi sửa số lượng về 0 chưa rõ — cần làm rõ ở GĐ3 (AC)

US-004 — Checkout & tự động tách đơn theo seller

Feature	FEAT-02
RQ	RQ-002
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	US-001, US-002, US-005 (cần địa chỉ + phí ship trước khi xác nhận cuối)
BR áp dụng	BR-CART-01 (tách đơn theo seller), BR-CART-02 (giữ tồn kho — chống oversell)
Ước lượng sơ bộ	L

Story:

Là Customer hoặc Guest, tôi muốn xác nhận đặt hàng và để hệ thống tự động tách giỏ hàng đa seller thành các đơn con riêng theo từng seller, để mỗi seller nhận và xử lý đúng phần đơn của mình mà không thấy dữ liệu của seller khác.

Phạm vi:

• Trong: kiểm tra tồn kho, tạo Order (cha) + nhiều OrderSeller (con) + OrderItem
• Ngoài: xử lý đơn sau khi tạo (đóng gói, giao hàng — FR-19/FR-26, ngoài phạm vi module)

Điều kiện nghiệm thu mức thô:

• Giỏ hàng có N seller ⇒ tạo đúng N OrderSeller con (giả định ASM-03 chưa xác minh — OQ-011, phải xác nhận trước khi coi AC này là chốt ở GĐ3)
• Không đủ tồn kho một sản phẩm bất kỳ ⇒ chặn tạo đơn, báo lỗi, giữ nguyên giỏ hàng (BR-CART-02)

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	⚠️	⚠️	E: phụ thuộc OQ-009 (giá/tồn kho thay đổi) và OQ-011 (ASM-03 tách N seller); S: đây là US lõi phức tạp nhất, có thể cần tách thêm ở GĐ3 theo luồng thành công/luồng lỗi (W4); T: điều kiện biên "đủ tồn kho" cần dữ liệu test cụ thể ở GĐ3

US-005 — Nhập địa chỉ & xem phí vận chuyển ước tính theo từng seller

Feature	FEAT-02
RQ	RQ-002, RQ-001 (đóng góp làm rõ chi phí giỏ đa seller — RISK-04)
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	US-002
BR áp dụng	(chưa có BR tính phí ship cụ thể — thuộc tích hợp GHN/GHTK, ASM-02 chưa xác minh)
Ước lượng sơ bộ	L

Story:

Là Customer hoặc Guest, tôi muốn nhập/chọn địa chỉ giao hàng và xem phí vận chuyển ước tính theo từng đơn con seller trước khi xác nhận đặt hàng, để tôi biết chính xác tổng số tiền phải trả và không bị bất ngờ ở bước cuối (giải quyết điểm đau P3/RISK-04 ở PROCESS B3).

Phạm vi:

• Trong: thu thập địa chỉ giao hàng, gọi tích hợp GHN/GHTK để ước tính phí/thời gian giao theo từng seller
• Ngoài: tạo vận đơn thật (chỉ xảy ra sau khi đơn đã confirmed, thuộc FR-26)

Điều kiện nghiệm thu mức thô:

• Địa chỉ ngoài vùng phục vụ của GHN/GHTK cho một seller cụ thể ⇒ hành vi hiển thị — chưa chốt, cần OQ ở GĐ3
• Nếu ASM-02 sai (API không khả dụng thời gian thực) ⇒ phương án dự phòng (ước tính tĩnh) — chưa chốt, chặn bởi xác minh ASM-02 ở GĐ1/RISK

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	✅	⚠️	E/T: phụ thuộc kết quả xác minh ASM-02 (GHN/GHTK) — chưa có, ảnh hưởng trực tiếp cách viết AC ở GĐ3

US-006 — Checkout không cần tạo tài khoản (Guest)

Feature	FEAT-02
RQ	RQ-004
MoSCoW	Must
Vai trò	Guest
Phụ thuộc	US-004, US-005
BR áp dụng	BR-CART-07 (điều kiện tối thiểu cho Guest checkout)
Ước lượng sơ bộ	M

Story:

Là Guest (khách vãng lai), tôi muốn hoàn tất checkout mà không cần tạo tài khoản trước, để tôi không phải dừng lại đăng ký tài khoản khi chỉ muốn mua một lần.

Phạm vi:

• Trong: cho phép hoàn tất toàn bộ luồng US-001…US-005, US-007/US-008 mà không yêu cầu đăng nhập/đăng ký
• Ngoài: chuyển đổi giỏ hàng Guest thành tài khoản Customer sau khi mua (nếu có — thuộc FR-01, ngoài phạm vi module này)

Điều kiện nghiệm thu mức thô:

• Guest hoàn tất được toàn bộ luồng checkout mà không bị chặn bởi bước "đăng nhập bắt buộc"
• Guest phải cung cấp tối thiểu thông tin liên hệ nào (họ tên, SĐT, email?) — chưa chốt, xem BR-CART-07, cần GĐ3 xác nhận danh sách field bắt buộc

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	✅	✅	E: danh sách field bắt buộc tối thiểu cho Guest chưa chốt — xem BR-CART-07, để GĐ3 làm bảng field

US-007 — Thanh toán khi nhận hàng (COD)

Feature	FEAT-03
RQ	RQ-003
MoSCoW	Must
Vai trò	Customer, Guest
Phụ thuộc	US-004
BR áp dụng	BR-CART-03 (giới hạn giá trị đơn COD — chưa chốt, OQ-006), BR-CART-04
Ước lượng sơ bộ	M

Story:

Là Customer hoặc Guest, tôi muốn thanh toán đơn hàng bằng hình thức thanh toán khi nhận hàng (COD), để tôi hoàn tất mua sắm mà không cần thanh toán trước qua kênh điện tử.

Ưu tiên triển khai trước US-008 theo xác nhận của PO ở OQ-008 — xem DEC-04 và §8.

Phạm vi:

• Trong: chọn COD làm phương thức thanh toán, tạo Payment gắn với Order
• Ngoài: thu tiền thật lúc giao hàng (thuộc vận hành giao nhận, FR-26)

Điều kiện nghiệm thu mức thô:

• Chọn COD ⇒ đơn được tạo mà không cần chuyển hướng ra ngoài hệ thống
• Đơn giá trị vượt ngưỡng (nếu PO chốt BR-CART-03) ⇒ hành vi chặn/cảnh báo — chưa chốt, OQ-006

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	✅	⚠️	E/T: phụ thuộc OQ-006 (giới hạn COD) và OQ-013 (Payment.status COD ghi nhận thế nào) — chưa có câu trả lời, AC ở GĐ3 chưa viết được đầy đủ nếu hai OQ này còn mở

US-008 — Thanh toán qua VNPay/Momo

Feature	FEAT-03
RQ	RQ-003
MoSCoW	Must (theo BRIEF), nhưng có thể lùi triển khai sau US-007 theo OQ-008/DEC-04
Vai trò	Customer, Guest
Phụ thuộc	US-004
BR áp dụng	BR-CART-04, BR-CART-05 (không lưu thẻ), BR-CART-06 (xác thực webhook — phụ thuộc ASM-01)
Ước lượng sơ bộ	XL

Story:

Là Customer hoặc Guest, tôi muốn thanh toán đơn hàng qua VNPay hoặc Momo mà không phải nhập/lưu thông tin thẻ trên hệ thống sàn, để tôi dùng đúng ví điện tử quen thuộc mà không lộ thông tin thẻ cho sàn.

Phạm vi:

• Trong: khởi tạo giao dịch, chuyển hướng cổng thanh toán, nhận xác nhận qua webhook
• Ngoài: hoàn tiền qua VNPay/Momo (thuộc FR-25 đổi trả/tranh chấp, ngoài phạm vi module này), cơ chế đối soát bù đầy đủ (thuộc thiết kế chi tiết Payment Service ở GĐ3)

Điều kiện nghiệm thu mức thô:

• Thanh toán thành công ⇒ webhook cập nhật Payment.status = success, OrderSeller.status chuyển sang confirmed
• Webhook không tới đúng hạn ⇒ hành vi hiển thị cho khách — chưa chốt, phụ thuộc ASM-01/ OQ-010 và cơ chế đối soát bù (ngoài phạm vi US module này, xem PROCESS B9)

INVEST:

I	N	V	E	S	T	Ghi chú nếu không đạt
✅	✅	✅	⚠️	⚠️	⚠️	E/S/T: đây là US phụ thuộc nhiều nhất vào xác nhận bên ngoài (ASM-01, sandbox VNPay/Momo) — nếu tới GĐ3 vẫn chưa xác minh được, đề xuất tách nhỏ US-008 theo từng cổng thanh toán (VNPay riêng, Momo riêng) để không chặn nhau

---

5. Bảng tổng hợp US

ID	Tên	Feature	RQ	MoSCoW	Ước lượng	Phụ thuộc	INVEST	Trạng thái
US-001	Thêm sản phẩm đa seller vào giỏ	FEAT-01	RQ-001	Must	M	—	✅	Draft
US-002	Xem giỏ hàng nhóm theo seller	FEAT-01	RQ-001	Must	M	US-001	✅	Draft
US-003	Sửa/xoá sản phẩm trong giỏ	FEAT-01	RQ-001	Must	S	US-001	⚠️	Draft
US-004	Checkout & tách đơn theo seller	FEAT-02	RQ-002	Must	L	US-001, US-002, US-005	⚠️	Draft
US-005	Địa chỉ & phí ship theo seller	FEAT-02	RQ-002, RQ-001	Must	L	US-002	⚠️	Draft
US-006	Checkout không cần tài khoản (Guest)	FEAT-02	RQ-004	Must	M	US-004, US-005	⚠️	Draft
US-007	Thanh toán COD	FEAT-03	RQ-003	Must	M	US-004	⚠️	Draft
US-008	Thanh toán VNPay/Momo	FEAT-03	RQ-003	Must	XL	US-004	⚠️	Draft

6. Đối chiếu ngược RQ → US (bảng bắt buộc)

RQ	Phát biểu ngắn	MoSCoW	US phủ	Trạng thái
RQ-001	Giỏ hàng đa seller, một lần checkout	Must	US-001, US-002, US-003, US-005	✅ Đã phủ
RQ-002	Tự động tách đơn theo seller	Must	US-004, US-005	✅ Đã phủ
RQ-003	Thanh toán VNPay/Momo/COD, không lưu thẻ	Must	US-007, US-008	✅ Đã phủ
RQ-004	Guest checkout không cần tài khoản	Must	US-006	✅ Đã phủ

Kết luận: 4/4 RQ của module này đã được phủ bởi ≥1 US — không có RQ bị bỏ quên.

7. US không truy về RQ nào (nghi ngờ scope creep)

US	Từ đâu ra	Đề xuất	PO quyết
(không có)	—	—	—

Kết luận: cả 8 US đều truy về được một RQ cụ thể — không phát hiện scope creep trong lần phân rã này.

8. Đề xuất thứ tự thực hiện

BA đề xuất theo trả lời của PO ở OQ-008 (xem DEC-04): giữ RQ-001/RQ-002 (giỏ hàng đa seller, tách đơn) trước; RQ-003 phần ví điện tử (VNPay/Momo) có thể lùi sau COD nếu thiếu thời gian. PO chốt thứ tự cuối cùng.

Đợt	US	Lý do xếp trước	Kết quả demo được
1	US-001, US-002, US-003	Nền tảng giỏ hàng — mọi US sau đều phụ thuộc	Thêm/xem/sửa giỏ hàng đa seller
2	US-004, US-005, US-006	Lõi giao dịch — tách đơn theo seller (RQ-002, ưu tiên theo OQ-008), gồm cả luồng Guest	Checkout hoàn tất, tạo được Order/OrderSeller, hỗ trợ cả Guest và Customer
3	US-007	COD không phụ thuộc tích hợp bên thứ ba phức tạp (VNPay/Momo) — làm trước theo DEC-04	Đặt hàng thanh toán COD đầu-cuối
4	US-008	Phụ thuộc xác minh ASM-01 + sandbox VNPay/Momo (RISK §3 phụ thuộc bên ngoài) — có thể lùi theo DEC-04 nếu ASM-01 chưa xác minh kịp	Đặt hàng thanh toán qua ví điện tử đầu-cuối

9. Open Questions

ID	Câu hỏi	Hỏi ai	Từ ngày	Chặn US nào
OQ-006	(đã mở từ GĐ1) Giới hạn giá trị đơn COD là gì?	PO, Kế toán đối soát	2026-09-08	US-007
OQ-009	Giá/tồn kho thay đổi giữa lúc thêm giỏ và checkout — tự động cập nhật hay chặn xác nhận lại?	PO + Tech Lead	2026-09-08	US-003, US-004
OQ-010	Xác nhận khả thi ASM-01 (webhook VNPay/Momo)	Tech Lead	2026-09-08	US-008
OQ-011	Xác nhận ASM-03 — giỏ N seller luôn tách đúng N đơn, không gộp	PO	2026-09-08	US-004
OQ-013	Với COD, Payment.status ghi "success" ngay khi xác nhận đơn hay giữ "pending" tới khi thực thu tiền?	Kế toán đối soát, PO	2026-09-08	US-007

10. Ngoài phạm vi

• Ước lượng story point chính thức → team dev ở buổi grooming
• Thiết kế màn hình, field spec chi tiết → GĐ3 SRS
• Áp dụng coupon/điểm thưởng (FR-13/FR-14) → module Khuyến mãi & Loyalty (điểm tích hợp đã xác nhận qua OQ-004/DEC-03)
• Xử lý đơn sau khi tạo (đóng gói, giao hàng, đổi trả, khiếu nại) → module Quản lý đơn hàng
• Cơ chế đối soát bù thanh toán → thiết kế chi tiết Payment Service ở GĐ3, không phải US của module này

---

11. Tự chấm Gate G2 (chấm ở mức RIGOR = standard — áp đúng checklist workflow.md §2, không bớt/thêm)

#	Tiêu chí	☐/✅	Ghi chú
1	PROCESS có AS-IS và TO-BE, mỗi bước ghi ai làm, input/output, điều kiện rẽ nhánh	✅ (có lưu ý)	AS-IS rút gọn đúng theo greenfield (A3–A5 thay vì A1/A2/A6, giải thích rõ lý do ở PROCESS §0); TO-BE (B1–B6) đầy đủ
2	BACKLOG phân rã tới US-nnn, mỗi US có value statement và ước lượng sơ bộ	✅	8 US, đủ ba vế Là/muốn/để, có ước lượng S/M/L/XL
3	Mỗi RQ-nnn của G1 map được về ≥1 US-nnn	✅	4/4 RQ đã phủ — xem §6
4	BR-nnn đã chốt, không mâu thuẫn nhau	☐	BR_CartCheckout_v1.0.md đã liệt kê đủ rule nhưng 3 rule quan trọng chưa chốt được giá trị (BR-CART-03 giới hạn COD, BR-CART-01 phụ thuộc xác minh ASM-03, BR-CART-06 phụ thuộc xác minh ASM-01) — đây là khoảng trống thật, đã ghi OQ, không tự chốt thay PO/Tech Lead
5	RBAC có ma trận vai trò × hành động; hành động phê duyệt/chốt sổ có bảng SoD	✅ (có lưu ý)	Ma trận Guest/Customer đầy đủ; không có hành động phê duyệt nội bộ nào trong phạm vi RQ-001…004 (tách đơn/thanh toán do hệ thống tự động, không có bước người duyệt) — đã ghi rõ lý do thay vì bỏ trống bảng SoD, xem RBAC §3
6	IMPACT nêu module/dữ liệu/tích hợp bị ảnh hưởng và cách xử lý dữ liệu cũ	✅ (rút gọn theo greenfield)	Theo PROFILE §"Hệ quả đã áp dụng": IMPACT rút gọn chỉ trọng tâm trục tích hợp (1.5); các trục khác ghi N/A kèm lý do (greenfield, module đầu tiên, không dữ liệu cũ)
7	Tech Lead xác nhận khả thi kỹ thuật và nêu ràng buộc	☐	Chưa có — không có Tech Lead thật tham gia lần chạy này (đúng như cảnh báo G1 chưa ký); các giả định kỹ thuật (ASM-01, ASM-02, ASM-06) vẫn ở trạng thái "chưa xác minh"
8	ba-traceability báo coverage RQ→US ≥ 100%	☐	Chưa chạy ba-traceability trong lần này — khuyến nghị chạy trước khi trình G2, theo đúng nhắc nhở cuối SKILL.md

Kết luận tự chấm: G2 chưa đủ điều kiện ký chính thức — 4/8 tiêu chí còn ☐, chủ yếu vì thiếu xác nhận thật từ Tech Lead (đúng hệ quả của việc G1 cũng chưa ký thật, xem ngoại lệ gate ở đầu tài liệu) và chưa chạy ba-traceability. Đây là kết quả tự chấm, không phải kết luận gate — PO + Tech Lead phải xem lại trước khi ký.

12. Quy tắc viết W1–W13

W1	W2	W3	W4	W5	W6	W7	W8	W9	W10	W11	W12	W13
✅	✅ (có lưu ý)	N/A (chưa có field/con số cụ thể — thuộc GĐ3)	N/A (GĐ2 chưa viết AC Given/When/Then chi tiết)	N/A (chưa có text hiển thị — GĐ3)	✅ (xem BR §3)	N/A (chưa có bảng field — GĐ3)	✅	✅	✅	N/A (chưa có wireframe ở GĐ2)	✅	✅

Ghi chú W2: quét nhanh|mượt|thân thiện|v\.v|phù hợp|tương ứng|nên |có thể trên 5 file GĐ2 (PROCESS, BACKLOG, BR, RBAC, IMPACT) — 27 dòng khớp trước khi soát, đã rà từng dòng:

• Hai dòng ban đầu dùng "nhanh" trong vế để của US-006/US-008 đã được sửa lại (không còn "mua nhanh"/"thanh toán nhanh") để không mô tả giá trị bằng tính từ mơ hồ — thay bằng mô tả hành vi cụ thể hơn (không phải dừng lại đăng ký; dùng đúng ví điện tử quen thuộc mà không lộ thông tin thẻ). Grep lại sau khi sửa: 0 kết quả cho riêng từ khoá nhanh trong toàn bộ 5 file.
• Các dòng còn lại (25 dòng) đều thuộc hai nhóm: (a) trích dẫn/diễn giải rủi ro theo đúng công thức chuẩn của RISK GĐ1 ("có thể xảy ra…"), hoặc (b) mô tả điều mà PO có thể cân nhắc như một tuỳ chọn thương mại/kỹ thuật chưa chốt (VD trợ giá phí ship ở PROCESS B3, thứ tự triển khai US-008 "có thể lùi" theo DEC-04) — đây là ngôn ngữ mô tả tuỳ chọn có nguồn (RISK, DEC-04), không phải một phát biểu RQ/AC né tránh quyết định bằng từ mơ hồ.
• Không có dòng nào dùng các từ này để thay thế cho một con số/quyết định còn thiếu — mọi chỗ thiếu số đều có OQ riêng (xem §9, §13). Đã quét TBD|TODO|\?\?\? — 0 kết quả ngoài chính dòng giải thích quy tắc này.

13. OQ mở tổng hợp của lần chạy GĐ2 này

ID	Câu hỏi	Hỏi ai	Chặn gì	Nguồn
OQ-006	(GĐ1, nhắc lại) Giới hạn giá trị đơn COD	PO, Kế toán đối soát	BR-CART-03, US-007	RISK_CartCheckout_v1.0.md
OQ-009	Giá/tồn kho đổi giữa thêm giỏ và checkout — tự động cập nhật hay chặn?	PO + Tech Lead	US-003, US-004	PROCESS A5 (E2)
OQ-010	Xác nhận khả thi ASM-01 (webhook VNPay/Momo)	Tech Lead	BR-CART-06, US-008	PROCESS A3 (P2)
OQ-011	Xác nhận ASM-03 — luôn tách đúng N đơn theo N seller	PO	BR-CART-01, US-004	RISK_CartCheckout_v1.0.md ASM-03
OQ-012	Guest có giới hạn giá trị đơn hoặc cần OTP xác thực cho đơn giá trị cao?	PO, Bảo mật	RBAC §4, RISK-01 phương án (b)	RBAC_CartCheckout_v1.0.md
OQ-013	Payment.status của COD ghi "success" ngay hay giữ "pending" tới khi thực thu?	Kế toán đối soát, PO	US-007, BR_CartCheckout §3	BR_CartCheckout_v1.0.md

Đã đồng bộ vào 00-index/OQ_e-commerce.md — xem sổ toàn dự án để theo dõi trạng thái đóng/mở.