PRD: Order & Payment History at POS
| Module | Sale | PRD ID | PRD-SLD-001 |
| Status | Ready to dev | FEAT | SLD |
| Epic | BANA-1326 | Plane | BANA-1749 |
| Date | 2026-06-26 | Version | v1.0 |
| Packages | @nx/sale | URD | SLD |
| Surface | Sale · POS | ||
| Owner | Phát Nguyễn | ||
TL;DR
A dedicated tab embedded in the Sale (POS) page that lets cashiers and managers review order and payment history without leaving the POS workflow - filter by time, staff, and payment method; search by order ID or customer; view order details and payment info; and reprint thermal receipts.
1. Context & Problem
Today, when a cashier or floor manager at a POS terminal needs to look up a recent order or verify payment details (e.g., "Did the customer's payment go through? Which order was it?"), they must switch to the client admin dashboard - effectively leaving the POS workflow entirely.
This disrupts the selling experience, especially during peak hours, and slows down the ability to handle on-the-spot customer inquiries. We need an order and payment history screen embedded directly in the Sale (POS) page so cashiers and managers can look up transactions without interrupting the selling flow.
Implementation status: this is a planned feature - it is not yet built. The sections below describe the target design.
2. Goals & Non-Goals
Goals
- In-POS Order History: Display the list of orders created at the POS, accessible directly from a tab within the Sale page - no redirect to the client admin required.
- Filters: Filter by date/time range, payment method, order status, and salesperson.
- Quick Search: Search by order ID or customer name/phone.
- Summary Panel: Show total order count, total revenue, and total collected at the top of the list based on active filters.
- Order Detail Drawer: Click any order row to open a drawer with full order details and payment information.
- Thermal Receipt Reprint: Allow reprinting the thermal receipt from the order detail drawer.
- Permission-Based Access Control: The feature requires the
SaleCheck.historypermission. The Order History tab is only visible to users granted this permission. Access is enforced at the API level - there is no role-based logic in the frontend.
Non-Goals
- Sales Analytics Charts / Reporting: Visual trend charts belong in the Reports module; this screen is for real-time operational lookup at the POS counter.
- Direct Refund or Order Editing: Refunds and edits go through their dedicated workflows; this screen is read-only.
- Item-Level Sold Products Report: Detailed product-level revenue reconciliation belongs in the client admin (see the Reports module).
3. Success Metrics
| Metric | Target / Success Signal |
|---|---|
| Data Accuracy | Order list and payment details shown match 100% with actual shift transaction data. |
| Lookup Speed | Users can find and view the detail of any order in under 10 seconds from opening the tab. |
4. Personas & Scenarios
Personas
Cashier: Needs to look up a recently created order or verify a payment status at the POS counter without leaving the selling flow.
Operator / Merchant Manager: Wants to review the order list for the current shift to verify or handle a customer complaint on the spot.
Key Scenarios
Core scenario: A cashier just created an order but the thermal receipt printer failed. The customer asks for the total. The cashier opens the Order History tab directly in the Sale (POS) page, finds the order by time, views the payment details, and informs the customer - all without navigating away from the POS screen.
5. User Stories
As a Cashier, I want to view the list of orders I created during my shift directly in the Sale (POS) page, so that I can look up transactions and answer customers without leaving the POS workflow.
As a Cashier, I want to view the full details of any order including payment information, so that I can resolve customer complaints on the spot at the counter.
As a Cashier, I want to filter the order list by time, staff, and payment method, so that I can quickly check the shift's POS sales activity.
6. Functional Requirements
| # | Requirement | URD Ref | Priority |
|---|---|---|---|
| FR-1 | Display a list of orders created at the POS, accessible directly from a tab within the Sale page without redirecting to the client admin. Default view shows the current shift; includes COMPLETED, PARTIAL, and DRAFT orders. | URD-SLD-001 | Must |
| FR-2 | Display a summary row per order: Order ID, Created Time, Customer, Total Amount, Payment Method, Order Status, Payment Status, and Created By. | URD-SLD-002 | Must |
| FR-3 | Filter the list by: Date/Time Range, Payment Method, Order Status, and Salesperson. | URD-SLD-003 | Must |
| FR-4 | Search orders by Order ID, or Customer Name/Phone number. | URD-SLD-004 | Must |
| FR-5 | Show a summary panel at the top based on active filters: Total orders, Total revenue, Total collected. | URD-SLD-005 | Should |
| FR-6 | Click any order row to open a Drawer showing full order details and complete payment information. | URD-SLD-006 | Must |
| FR-7 | Allow reprinting the thermal receipt for the selected order from the detail drawer. | URD-SLD-007 | Should |
7. Non-Functional Requirements
- List load speed: The order list for the current shift must appear in under 2 seconds - users are standing at the counter and cannot wait.
- Drawer open speed: The order detail drawer must fully render in under 1 second after clicking.
- Real-time data: Orders just created must appear immediately when the user opens the tab or refreshes - no lag behind the actual shift state.
8. UX & Flows
User Flow
- The user opens the Order History tab within the Sale (POS) page.
- A list of orders appears in summary form - each row shows key info: order ID, time, customer, total amount, payment method, and status.
- The user can filter or search to narrow the list.
- Clicking any order opens a detail drawer with the full order and payment information.
- From the drawer, the user can reprint the thermal receipt or close it to return to the list.
9. Data & Domain
Related entities
| Entity | Role |
|---|---|
SaleOrder | Primary entity - each row in the list corresponds to one order. Provides Order ID, Created Time, Status, Total Amount, and links to Customer and Salesperson. |
Payment | Payment records for an order - Method, Amount, Time, and Status. One order may have multiple Payment records (partial payments). |
SaleOrderItem | Used in the detail Drawer only - lists the products ordered. Not shown in the list view. |
Entity Relationships
[SaleOrder] ──(1:N)──> [Payment]
│
└──(1:N)──> [SaleOrderItem] (Detail View only)10. Dependencies & Assumptions
Dependencies
- Sale/Order Module: Provides
SaleOrder,SaleOrderItem, andPaymentdata. - User/Auth Module: Authenticates the session token and supplies
Salespersoninformation for display and filtering. - Printer Service: The local thermal printer service must be available to support receipt reprinting from the detail drawer.
Assumptions
- Each paid order has at least one
Paymentrecord; unpaid orders have aPENDINGstatus or no payment record. - The Sale (POS) page maintains its own login session, independent of the client admin session.
11. Risks & Open Questions
Risks
- Performance with long shifts or high order volume: A long shift or a high-volume merchant can produce hundreds of orders - slow load times degrade the at-counter experience.
- Mitigation: Apply server-side pagination (default 20 rows/page); index
created_atandmerchant_idfields.
- Mitigation: Apply server-side pagination (default 20 rows/page); index
- Unstable printer connection: The thermal receipt reprint feature depends on a local printer connection; if the printer is offline the feature cannot be used.
- Mitigation: Show a clear error message when the printer is unavailable. Receipt reprint is a Should requirement - the order list and detail view work independently.
Open Questions
- Should fully refunded orders appear in the list?
- An order that was COMPLETED but later fully refunded - should it still show here?
- Status: Needs confirmation from the business team.
12. Rollout Plan & Criteria
Rollout Plan
- Week 1 (API & UI Development): Build the order list API and render the list view in the Sale page using mock data.
- Week 2 (Integration & Testing): Integrate with the live API, implement the detail drawer with payment info, and test filtering and search.
- Week 3 (Pilot & Release): Deploy to pilot merchants for feedback, validate printer reprint flow, and release globally.
Release Criteria
- Order list renders correctly and matches actual shift data.
- Detail drawer opens with correct order and payment information.
- Filtering, searching, and pagination work as expected.
- Must pass Acceptance Criteria AC-SLD-01 and AC-SLD-02 in the URD.
13. FAQ
Q: Why not just use the order list on the client admin dashboard instead of building this in the Sale page? A: The client admin dashboard requires the user to leave the POS workflow, authenticate into a different interface, and navigate through multiple steps - not suitable for quick, on-the-spot lookups at the cashier counter. This feature is embedded directly in the Sale (POS) page so cashiers and managers can check order and payment history without interrupting their selling flow.
Q: Do DRAFT orders appear in the list? A: Yes. This feature is for real-time operational lookup at the POS counter, so DRAFT orders are included so cashiers can track in-progress orders. This is different from revenue reports, which only count COMPLETED or PARTIAL orders.