23 lines
1.6 KiB
Markdown
23 lines
1.6 KiB
Markdown
# F-190 — Reporting updates from POS sales and returns
|
|
|
|
Fix reporting capture and refresh so POS sales payments returns pending and completed states update reports.
|
|
|
|
## Scope
|
|
- POS sales (POST /pos/sales) already emit `reporting_payment_lines` rows on payment — these are verified to capture correctly.
|
|
- POS returns (POST /pos/sales/:id/returns) already emit `reporting_payment_lines` with status=`refund`/`partial_refund` — these are verified to capture correctly.
|
|
- PENDING-payment sales (F-188) when they transition to COMPLETED must emit a payment line to `reporting_payment_lines` so the report shows the sale.
|
|
- Orders in `PARTIALLY_REFUNDED` and `REFUNDED` must reflect the updated totals in `reporting_payment_lines`.
|
|
- A refresh mechanism for `reporting_payment_lines` for a given order_id exists (for correction scenarios) — or a clear note that manual correction is required.
|
|
- Any gaps in `expected_cash_cents` calculation for returns are verified and fixed.
|
|
|
|
## Out of scope
|
|
- Ecommerce or admin order refunds.
|
|
- Automatic reconciliation of discrepancies (manual correction only).
|
|
|
|
## Acceptance
|
|
1. A PENDING sale that transitions to COMPLETED emits exactly one `reporting_payment_lines` row with the correct amount and status.
|
|
2. A fully-returned sale shows a `refund` payment line in reporting with negative amount.
|
|
3. A partially-returned sale shows a `partial_refund` payment line in reporting with the partial amount.
|
|
4. Reporting summary totals match the sum of `reporting_payment_lines` for the date range.
|
|
5. `verify.sh` green, typecheck green, all tests pass.
|