PRD: Ca Đa nhân viên
| Module | Bán hàng | PRD ID | PRD-SHF-001 |
| Trạng thái | Sẵn sàng dev | FEAT | SHF · BANA-1426 |
| Epic | BANA-1321 | Plane | BANA-1557 |
| Ngày | 2026-07-17 | Phiên bản | v0.2 |
| Gói | @nx/sale | URD | SHF |
| Surface | Sale · POS | ||
| Phụ trách | Việt Võ · Phát Nguyễn | ||
TL;DR
- ✅ Ca bán hàng đúng nghĩa đã có sẵn ở backend: mở/đóng ca trên thiết bị, nhiều nhân viên ghi danh tự động vào cùng một ca, đối soát tiền mặt (thực đếm vs kỳ vọng, có ngưỡng dung sai), và báo cáo X (giữa ca) / Z (đóng ca).
- ✅ Mỗi kênh bán chấp nhận nhiều ca mở song song; mỗi thiết bị/nhân viên chỉ ở đúng một ca tại một thời điểm; mở ca mới không bao giờ bị ca trước chặn.
- 🔶 Doanh thu theo từng nhân viên và theo kỳ (gộp nhiều ca) chưa dựng - báo cáo hiện gộp theo két/thiết bị và theo từng ca riêng lẻ.
- 🚧 Ghi chú bắt buộc khi chênh lệch tiền mặt khác 0 (URD-SHF-008, mức Must) chưa được backend enforce - trường ghi chú hiện là tùy chọn ở mọi lượt đối soát.
- 🚧 POS vẫn chạy phiên 1 người cũ - phần còn lại của increment này là nối FE sang hệ ca mới và kiểm chứng end-to-end; PRD này đóng vai trò spec để viết test case.
1. Bối cảnh & Vấn đề
Phase 1 chỉ có phiên POS một người (API PosSession v1 - đã bị gỡ hoàn toàn khỏi backend). Thực tế merchant cần ca chung nhiều người (thu ngân + phục vụ chia sẻ một két) với trách nhiệm rõ ràng từng người, đối soát tiền mặt ngay tại quầy, và báo cáo bàn giao ca in được.
Hệ ca (Shift v2) đã xây xong đầy đủ ở backend: ca theo kênh bán, ghi danh đa hình (thiết bị + nhân viên), két tiền theo thiết bị, biến động tiền mặt (mỗi khoản sinh một phiếu kế toán), và sinh báo cáo X/Z - toàn bộ là logic hoàn chỉnh, không phải schema rỗng. Vấn đề còn lại thuần túy là: POS chưa gọi tới hệ ca mới (vẫn chạy mô hình phiên cũ), và chưa có tài liệu nào mô tả đủ chi tiết để viết test case đối chiếu khi nối FE. Tài liệu này lấp cả hai khoảng trống đó.
2. Mục tiêu & Loại trừ
Mục tiêu
- Mở/đóng ca trên thiết bị, ca sống sót qua khởi động lại (URD-SHF-001).
- Nhiều nhân viên (không chỉ nhiều thiết bị) cùng tham gia một ca, ghi danh tự động (URD-SHF-002).
- Báo cáo X giữa ca (lặp lại được) và báo cáo Z khi đóng/đối soát (URD-SHF-003).
- Đối soát tiền mặt khi đóng két: thực đếm vs kỳ vọng, ghi nhận chênh lệch (URD-SHF-004).
- Đơn bán trong ca gắn đúng nhân viên thao tác qua bản ghi hiện diện (URD-SHF-005).
- Biến động tiền mặt trong két: thu/chi/nộp két, mỗi khoản post một phiếu kế toán (URD-SHF-006).
- Chủ xem doanh thu theo ca (URD-SHF-007 - chỉ phần "theo ca"; xem 🔶 ở FR-007).
- Đóng két với chênh lệch khác 0 yêu cầu ghi chú lý do (URD-SHF-008).
- Quỹ đầu ca không tự sửa được tại POS sau khi mở két (URD-SHF-009).
Loại trừ
- Cờ quyền theo thành viên trong ca (vd quyền refund/void riêng cho từng người) - theo dõi dưới Permissions, không thuộc PRD này.
- Chấm công / lương theo giờ làm.
- Doanh thu theo kỳ (gộp nhiều ca theo khoảng ngày) và theo từng nhân viên - chưa có endpoint tổng hợp; xem 🔶 ở FR-007, không phải non-goal vĩnh viễn mà là phần chưa tới lượt của cùng URD-SHF-007.
- Chi tiết cấu trúc JSON của báo cáo X/Z, phân rã theo phương thức thanh toán/danh mục, và quyền đọc báo cáo - thuộc PRD báo cáo ca (X/Z); PRD này chỉ mô tả các sự kiện phía sale sinh ra dữ liệu cho báo cáo đó, không định nghĩa lại cấu trúc báo cáo.
- Bước xác thực PIN khi truy cập báo cáo - thuộc PRD báo cáo ca (X/Z), không thuộc PRD này.
3. Thước đo thành công
| Thước đo | Mục tiêu |
|---|---|
| POS chạy hệ ca mới | Thay hẳn phiên 1 người cũ, không regression trên luồng bán hàng |
| Báo cáo Z | Công thức tiền kỳ vọng kiểm chứng đúng với một ngày bán thật tại merchant pilot |
| Đối soát chênh lệch có ghi chú | 🚧 100% lượt đối soát có chênh lệch ≠ 0 kèm ghi chú lý do - phụ thuộc việc bắt buộc ghi chú được thêm vào FE hoặc backend (xem FR-008) |
| Ghi danh nhân viên đúng người | 0 trường hợp hiện diện/bàn giao gắn sai nhân viên tại merchant pilot (đòi hỏi mỗi người đăng nhập tài khoản riêng) |
4. Persona & Tình huống
| Persona | Mục tiêu trong tính năng này |
|---|---|
| Thu ngân | Mở/đóng ca, đếm két, xử lý hộp thoại lệch tiền, in phiếu bàn giao |
| Phục vụ | Ghi danh tự động khi bán hàng trên thiết bị dùng chung, không cần thao tác riêng |
| Chủ / Quản lý | Đọc báo cáo X/Z theo ca; điều chỉnh quỹ đầu ca hoặc kết quả đối soát của một két khi cần (có lịch sử) |
Tình huống chính: quán có 1 két dùng chung cho 2 thiết bị (quầy thu ngân + máy phục vụ cầm tay). Thu ngân mở ca, nhập quỹ đầu ca cho két; máy phục vụ tham gia ca đang mở. Trong ca, cả hai máy bán hàng - nhân viên nào đăng nhập máy nào được tự động ghi danh vào ca của máy đó. Cuối ngày, thu ngân đóng ca (khóa bán hàng toàn bộ), đếm tiền mặt trong két, hệ thống báo tiền kỳ vọng và chênh lệch; nếu lệch vượt ngưỡng, thu ngân đếm lại hoặc xác nhận chấp nhận. Đối soát xong, ca chốt và in được phiếu bàn giao Z.
5. User Stories
- Là thu ngân, tôi mở ca với quỹ đầu ca, đồng nghiệp tham gia và bán hàng mà không cần tôi thao tác gì thêm, và khi đóng ca tôi đếm két và thấy ngay chênh lệch.
- Là phục vụ, tôi đăng nhập tài khoản của mình trên máy bán hàng dùng chung và bắt đầu bán ngay - không cần biết ai đã mở ca hay gọi API ghi danh nào.
- Là thu ngân, khi số tiền đếm được lệch quá ngưỡng cho phép so với kỳ vọng, tôi được yêu cầu đếm lại hoặc xác nhận rõ ràng là tôi biết và chấp nhận khoản lệch đó trước khi đóng ca xong.
- Là chủ, tôi đọc báo cáo Z của từng ca đã đóng và biết chắc con số đó không đổi (đã khóa).
- Là chủ, khi phát hiện quỹ đầu ca nhập sai sau khi ca đã đóng, tôi điều chỉnh lại được và vẫn xem lại được số cũ/số mới.
- Là thu ngân, khi tôi đóng ca mà quán có nhiều két, tôi đối soát lần lượt từng két và chỉ khi két cuối cùng xong thì ca mới thật sự chốt.
6. Yêu cầu chức năng
| # | Yêu cầu | Trạng thái | URD ref |
|---|---|---|---|
FR-001 | Mở/đóng ca trên thiết bị. • Thiết bị đầu tiên tạo ca mới cho một kênh bán; thiết bị sau tham gia ca đang mở của kênh đó. Một kênh bán chấp nhận nhiều ca mở song song; mỗi thiết bị chỉ ở đúng một ca mở tại một thời điểm. • Máy có bật két tiền bắt buộc nhập quỹ đầu ca trước khi bán được; máy không có két bỏ qua bước này. • Đóng ca do bất kỳ thiết bị nào trong ca thực hiện, khóa bán hàng cho toàn bộ ca (mọi thiết bị/nhân viên trong ca, không chỉ máy bấm đóng). • Vòng đời: Đang mở → Đã đóng (chờ đối soát) → Đã đối soát (khi két cuối cùng đối soát xong; ca không có két nào chốt thẳng ngay khi đóng). • Mở ca mới không bao giờ bị ca trước chặn: đơn dở dang trên thiết bị được chuyển sang ca mới, đơn đã hoàn tất giữ nguyên gắn ca cũ; ca trước không cần đối soát trước khi mở ca mới. Toàn vẹn tiền chỉ kiểm ở từng két lúc mở (xem FR-004). • Trạng thái ca sống sót qua khởi động lại ứng dụng. | ✅ | URD-SHF-001 |
FR-002 | Ghi danh đa nhân viên (tự động). • Ngoài thiết bị, hệ thống ghi danh riêng từng nhân viên vào ca - không cần FE gọi hành động ghi danh nào: nhân viên mở/tham gia ca được ghi danh ngay lúc đó; nhân viên khác đăng nhập một thiết bị đang trong ca và bán hàng lần đầu được tự động ghi danh (ghi danh trễ). • Nhân viên chuyển sang thao tác ở thiết bị thuộc ca khác tự động rời ca cũ và vào ca mới - hiện diện luôn đi theo nơi thao tác gần nhất. • Khi ca chốt "Đã đối soát", mọi nhân viên còn đang hiện diện được tự động rời ca. • Danh tính nhân viên lấy từ tài khoản đăng nhập trên thiết bị - mỗi nhân viên phải đăng nhập bằng tài khoản của chính mình, không dùng chung tài khoản, để dữ liệu hiện diện/bàn giao đúng người. • Theo dõi hiện diện là best-effort: lỗi ghi danh nhân viên không bao giờ chặn giao dịch bán. • Mỗi thiết bị/nhân viên chỉ giữ tối đa một ghi danh đang hoạt động tại một thời điểm. | ✅ | URD-SHF-002 |
FR-003 | Báo cáo X (giữa ca) và Z (đóng ca). • Báo cáo X: snapshot trực tiếp của ca đang mở, gọi lại bao nhiêu lần tùy ý, không làm thay đổi ca. • Báo cáo Z được chốt khi đối soát một két xong: mỗi két sinh một báo cáo Z cho mỗi thiết bị gắn vào két đó (không phải một Z gộp duy nhất) - nếu nhiều thiết bị dùng chung một két, mỗi Z mang phần tiền két giống nhau (đánh dấu "tiền dùng chung") cộng doanh số riêng của thiết bị đó. • Thiết bị không có két được cắt Z ngay khi ca đóng - không cần chờ đối soát vì không có tiền phải đếm. • Khi két cuối cùng của ca đối soát xong (hoặc ca không có két nào), ca chốt và sinh thêm một báo cáo Z tổng hợp toàn ca (tiền két = 0 vì đã tính ở các Z theo thiết bị; doanh số là của cả ca) - vẫn là nguồn sự thật về tiền, cộng dồn các két vật lý. • Cả X và Z có thể lưu thành một mốc (snapshot) xem lại được sau này. • Chi tiết cấu trúc dữ liệu báo cáo, phân rã theo phương thức thanh toán/danh mục, và quyền đọc thuộc PRD báo cáo ca (X/Z) - FR này chỉ mô tả sự kiện phía ca sinh ra báo cáo. | ✅ | URD-SHF-003 |
FR-004 | Đối soát tiền mặt khi đóng két. • Thu ngân nhập số tiền mặt đếm thực tế (bắt buộc), có thể kèm số tiền phi tiền mặt đếm được cho các phương thức Chuyển khoản / QR / POS di động. • Tiền kỳ vọng = quỹ đầu ca + doanh thu tiền mặt − hoàn tiền mặt + thu két − chi két; chênh lệch = thực đếm − kỳ vọng. • Nếu merchant bật "đếm mù" (blind count, mặc định bật), thu ngân không thấy số tiền kỳ vọng trước khi nhập số đếm - chỉ thấy sau khi đối soát xong. • Nếu |chênh lệch| vượt ngưỡng dung sai do merchant cấu hình (mặc định 0) → hệ thống từ chối, buộc thu ngân đếm lại hoặc xác nhận rõ ràng là đã biết và chấp nhận khoản lệch trước khi tiếp tục. • Mỗi thiết bị có két đối soát riêng (không phải cả ca đối soát một lần cho toàn bộ két); lúc đối soát, thu ngân chọn thiết bị đó rời ca hoặc để nó mang sang ca kế tiếp (vẫn phải nhập quỹ đầu ca mới cho ca kế). • Toàn vẹn tiền kiểm ở mức từng két lúc mở két (không phải lúc mở ca): một két còn ca trước đã đóng nhưng chưa đối soát bị từ chối mở tới khi được đối soát xong. • Chủ/quản lý (không cần thiết bị) có thể điều chỉnh kết quả đối soát của một két sau đó; mỗi lần điều chỉnh lưu thành một phiên bản, xem lại được toàn bộ lịch sử. | ✅ | URD-SHF-004 |
FR-005 | Gắn đơn theo nhân viên thao tác. • Đơn bán gắn theo ca của thiết bị mở/đóng đơn đó: một đơn mở dở trên ca A rồi thanh toán xong khi thiết bị đã chuyển sang ca B thì doanh thu tính cho ca B (đã hỗ trợ sẵn), không phải ca A. • Nhân viên thao tác (tạo đơn / thanh toán) được suy ra qua bản ghi hiện diện (check-in) của ca tại thời điểm thao tác (xem FR-002), không phải một field "nhân viên bán" gắn trực tiếp trên từng đơn. • 🔶 Một phần: doanh thu chi tiết theo từng nhân viên cụ thể chưa dựng - báo cáo hiện chỉ gộp theo két/thiết bị, chưa tách theo người thao tác (xem FR-007). | 🔶 | URD-SHF-005 |
FR-006 | Biến động tiền mặt trong két. • Ba loại biến động, ghi theo từng két: Thu tiền vào két (pay-in), Chi tiền ra khỏi két (pay-out), Rút tiền cất/nộp về (safe-drop) - đều bắt buộc nhập số tiền, có thể kèm lý do tùy chọn. • Mỗi biến động post một phiếu kế toán tương ứng (phiếu thu/phiếu chi) vào tài khoản tài chính của merchant - không chỉ là log nội bộ. • Biến động chỉ thực hiện được khi két đang mở; sau khi ca đóng, két không nhận thêm biến động. | ✅ | URD-SHF-006 |
FR-007 | Doanh thu theo ca và theo kỳ. • Doanh thu theo từng ca: ✅ có sẵn qua báo cáo X/Z và bundle báo cáo ca (toàn ca + từng thiết bị), cộng danh sách ca lọc được theo kênh bán/khoảng thời gian mở-đóng. • 🚧 Doanh thu theo kỳ (gộp nhiều ca trong một khoảng ngày, vd "doanh thu tuần này") và theo từng nhân viên - chưa dựng; hiện chưa có báo cáo tổng hợp nào cộng dồn nhiều ca hoặc tách theo người thao tác. Đây là phần việc còn lại của URD-SHF-007, không phải toàn bộ URD-SHF-007. | 🔶 | URD-SHF-007 |
FR-008 | Ghi chú khi chênh lệch tiền mặt khác 0. • Khi đối soát một két phát sinh chênh lệch (thực đếm ≠ kỳ vọng), thu ngân nhập ghi chú lý do trước khi hoàn tất đối soát két đó. • 🚧 Forward-spec: trường ghi chú hiện là tùy chọn ở mọi lượt đối soát (kể cả khi có chênh lệch) - việc bắt buộc nhập ghi chú khi chênh lệch ≠ 0 là phần việc cần thêm trong increment này (ở FE khi đóng ca, hoặc validate ở backend) để khớp URD-SHF-008 (mức Must). | 🚧 | URD-SHF-008 |
FR-009 | Khóa / điều chỉnh quỹ đầu ca. • Quỹ đầu ca khóa với thao tác tại POS: không có luồng cho thu ngân tự sửa số quỹ đã nhập sau khi mở két. • 🔶 Không phải khóa tuyệt đối: chủ/quản lý điều chỉnh được quỹ đầu ca của một két đã mở qua một hành động riêng ở back-office (không cần thiết bị) - mỗi lần sửa lưu lại lịch sử (số cũ → số mới) xem lại được. | 🔶 | URD-SHF-009 |
6.1 Tiêu chí nghiệm thu
- Máy 1 mở ca cho kênh bán X, nhập quỹ đầu ca 500.000đ cho két của máy 1 → ca chuyển "Đang mở"; máy 2 tham gia cùng ca, nhập quỹ đầu ca riêng cho két của máy 2 → cả hai máy cùng thuộc một ca. (FR-001)
- Nhân viên A đăng nhập máy 1 và mở ca → nhân viên A được ghi danh ngay. Nhân viên B đăng nhập máy 2 (đã ở trong ca) và tạo đơn bán đầu tiên → nhân viên B được tự động ghi danh vào ca tại thời điểm đó, không cần thao tác ghi danh riêng. (FR-002)
- Trong lúc ca đang mở, gọi báo cáo X nhiều lần liên tiếp → mỗi lần trả về snapshot mới nhất, không có lần nào làm thay đổi trạng thái ca hay tạo bản ghi Z. (FR-003)
- Một két dùng chung cho máy 1 và máy 2, đối soát két đó → hệ thống trả về hai báo cáo Z (một cho máy 1, một cho máy 2), phần tiền két giống hệt nhau giữa hai báo cáo, phần doanh số khác nhau theo từng máy. (FR-003)
- Đóng ca có 2 két → đối soát xong két 1 chưa làm ca chốt; chỉ khi đối soát xong két 2 (két cuối cùng) ca mới chuyển "Đã đối soát" và sinh thêm một báo cáo Z tổng hợp toàn ca. (FR-001, FR-003)
- Thu ngân đóng ca, đếm được số tiền lệch 15.000đ so với kỳ vọng trong khi ngưỡng dung sai của merchant là 10.000đ → hệ thống từ chối hoàn tất, yêu cầu đếm lại hoặc xác nhận chấp nhận chênh lệch; xác nhận chấp nhận xong mới đối soát thành công. (FR-004)
- Merchant bật "đếm mù" → màn hình đối soát của thu ngân không hiển thị số tiền kỳ vọng trước khi nhập số đếm thực tế. (FR-004)
- Một máy còn két ở trạng thái "Đã đóng - chưa đối soát" từ ca trước → mở két đó cho ca mới bị từ chối cho tới khi đối soát xong két đó; trong khi đó, việc mở ca mới trên kênh bán vẫn thực hiện được bình thường, không bị chặn bởi két chưa đối soát. (FR-001, FR-004)
- Chủ mở lại một két đã đối soát 2 ngày trước và điều chỉnh lại quỹ đầu ca → số liệu mới được ghi nhận, lịch sử vẫn còn nguyên bản ghi số cũ để đối chiếu. (FR-009)
- 🚧 Thu ngân đối soát một két có chênh lệch ≠ 0 và không nhập ghi chú → hiện tại hệ thống vẫn cho hoàn tất (không chặn); sau khi bổ sung validate theo FR-008, hành vi kỳ vọng là hệ thống buộc nhập ghi chú trước khi hoàn tất. (FR-008)
- 🚧 Chủ xem báo cáo doanh thu theo tuần gộp nhiều ca, hoặc theo một nhân viên cụ thể → hiện chưa có màn hình/báo cáo này; chỉ xem được doanh thu của từng ca riêng lẻ. (FR-007)
7. Yêu cầu phi chức năng
| Khía cạnh | Yêu cầu |
|---|---|
| Tính bền vững | Trạng thái ca sống sót khi app khởi động lại; không mất ghi danh/két đang mở |
| Chặn bán ngoài ca | Không bán được ngoài ca đang mở, khi merchant bật quản lý ca (enableShiftManagement, mặc định tắt) |
| Bật/tắt giữa ca | Tắt quản lý ca giữa chừng chỉ chặn mở ca mới; ca đang mở vẫn vận hành trọn vòng (bán hàng, thu/chi két, đóng, đối soát, báo cáo X/Z) - không bao giờ làm kẹt ca đang mở |
| Tenancy | Mọi ca, ghi danh, két, biến động giới hạn theo đúng merchant + kênh bán; không lẫn dữ liệu giữa các merchant |
| Độ chính xác tiền | Tiền mặt và các khoản tiền theo dõi với độ chính xác 4 chữ số thập phân |
| Idempotency báo cáo | Lưu một mốc (snapshot) báo cáo trùng với mốc gần nhất - không tạo bản ghi trùng lặp |
| Best-effort ghi danh | Lỗi ghi danh/theo dõi hiện diện nhân viên không bao giờ chặn giao dịch bán |
8. UX & Luồng
Một ca với hai thiết bị, hai két
Màn hình bàn giao ca (đóng từ báo cáo X)
9. Dữ liệu & Miền nghiệp vụ
| Khái niệm | Vai trò |
|---|---|
| Ca | Phiên bán hàng theo kênh bán, có vòng đời Đang mở → Đã đóng → Đã đối soát; một kênh bán có thể có nhiều ca mở song song |
| Ghi danh | Đa hình - đại diện cho một thiết bị hoặc một nhân viên trong ca; mỗi thiết bị/nhân viên chỉ giữ một ghi danh đang hoạt động tại một thời điểm |
| Két | Gắn với ghi danh của thiết bị có bật két tiền; mang quỹ đầu ca, tiền kỳ vọng, tiền thực đếm, chênh lệch |
| Sự kiện ghi danh | Nhật ký từng hành động: thiết bị vào/rời ca, nhân viên vào/rời ca, mở két, thu/chi/nộp két, đối soát |
| Báo cáo ca (X/Z) | Snapshot giữa ca (X) hoặc đóng ca đã khóa (Z); một Z cho mỗi thiết bị gắn két, cộng một Z tổng hợp toàn ca - chi tiết cấu trúc thuộc PRD báo cáo ca (X/Z) |
| Đơn bán | Gắn vào ca qua ghi danh mở đơn / ghi danh đóng đơn (thanh toán); doanh thu tính cho ca đóng đơn |
Chỉ mang tính khái niệm - chi tiết đầy đủ và bất biến nằm trong domain model của sale và tài liệu Ca làm việc (Shift v2).
10. Phụ thuộc & Giả định
Phụ thuộc vào
| Phụ thuộc | Vì sao |
|---|---|
| Cơ chế xác định nhân viên thao tác qua đăng nhập thiết bị (BANA-1140, đang chạy) | Ghi danh tự động (FR-002) và gắn đơn theo nhân viên (FR-005) cần biết ai đang thao tác trên thiết bị nào |
| Tài khoản tài chính của merchant | Biến động két (FR-006) post phiếu thu/chi vào tài khoản tài chính |
| Cấu hình két tiền theo thiết bị | Chỉ thiết bị bật két mới yêu cầu quỹ đầu ca và tham gia đối soát |
| PRD báo cáo ca (X/Z) | Sở hữu cấu trúc dữ liệu và quyền đọc của báo cáo X/Z mà FR-003 sinh ra |
Giả định
- Mỗi nhân viên đăng nhập bằng tài khoản riêng trên thiết bị dùng chung - không dùng chung tài khoản - để dữ liệu hiện diện/bàn giao đúng người (FR-002).
- Merchant chọn được chính sách két phù hợp (dùng chung một két cho nhiều máy, hay mỗi máy một két riêng) trước khi bật quản lý ca; PRD này hỗ trợ cả hai mô hình nhưng không áp đặt mặc định (xem Rủi ro §11).
- Giá trị mặc định của chính sách ca (
enableBlindCount = bật,discrepancyTolerance = 0) phù hợp cho merchant pilot ban đầu; điều chỉnh nếu vận hành thực tế cho thấy khác.
11. Rủi ro & Câu hỏi mở
| Rủi ro / câu hỏi | Giảm thiểu / trạng thái |
|---|---|
| Cutover: merchant đang giữa ca khi rollout | Định nghĩa đường nâng cấp - đóng phiên PosSession v1 cũ trước khi merchant chuyển sang hệ ca mới; API cũ đã gỡ nên không thể chạy song song |
| Biến thể chính sách két (dùng chung vs theo từng thiết bị) | Chốt mặc định v1 trước khi launch pilot - ảnh hưởng trực tiếp tới UX màn đối soát nhiều két |
| Ghi chú bắt buộc khi lệch tiền (FR-008, URD-SHF-008 mức Must) chưa được enforce | Quyết định enforce ở FE (validate trước khi gửi) hay backend (schema bắt buộc có điều kiện) trước khi coi increment hoàn tất |
| Ngưỡng dung sai mặc định (0đ) có thể quá chặt cho vận hành thực tế | Theo dõi tỉ lệ ca yêu cầu "xác nhận chấp nhận chênh lệch" tại pilot; điều chỉnh nếu tỉ lệ bất thường cao |
12. Kế hoạch phát hành & Tiêu chí
| Khía cạnh | Kế hoạch |
|---|---|
| Giai đoạn | P2 (T7, WK27-31) - SHF trong URD feature catalog |
| Rollout | Migrate FE khỏi phiên cũ + kiểm chứng end-to-end tại merchant pilot trước khi mở rộng |
| Migration | Đóng mọi phiên PosSession v1 đang mở trước khi merchant chuyển sang hệ ca mới; không có dữ liệu ca cũ để migrate (khái niệm mới) |
| Tiêu chí ra mắt | AC-SHF-01 (URD) pass tại merchant pilot: một ca trọn vẹn với hai nhân viên, báo cáo Z đúng công thức tiền kỳ vọng; phiên cũ ngừng dùng hoàn toàn |
| Giám sát | Tỉ lệ ca yêu cầu xác nhận chấp nhận chênh lệch, số ca "kẹt" ở trạng thái Đã đóng-chưa đối soát quá lâu, lỗi ghi danh nhân viên (best-effort nhưng cần theo dõi tần suất) |
13. FAQ
- Có xây lại backend không? Không - đã xây xong đầy đủ; đây là nối FE + kiểm chứng, và PRD này là tham chiếu để viết test case.
- Ghi chú khi lệch tiền có bắt buộc không? Theo URD là bắt buộc (Must), nhưng backend hiện để trường này tùy chọn - xem FR-008, cần chốt enforce ở đâu trước khi launch.
- Quỹ đầu ca có sửa được sau khi mở két không? Không sửa được tại POS, nhưng chủ/quản lý sửa được qua back-office với lịch sử đầy đủ - xem FR-009.
- Một két có nhiều thiết bị cùng dùng thì báo cáo Z ra sao? Mỗi thiết bị gắn két đó nhận một báo cáo Z riêng (phần tiền két giống nhau, phần doanh số riêng) - xem FR-003.
- Xem được doanh thu theo tuần hoặc theo một nhân viên cụ thể không? Chưa - hiện chỉ xem được doanh thu theo từng ca riêng lẻ; xem 🔶 ở FR-007.
Tham chiếu
- URD:
SHF- Ca Đa nhân viên (URD-SHF-001…009) - PRD liên quan: PRD báo cáo ca (X/Z)
- Lộ trình: Giai đoạn 2 - Theo tháng
- Developer: Ca làm việc (Shift v2) · domain model
- Epic BANA-1321