Feature: Print cash tendered amount and change on receipts #770

Status

Planned receipt-projection follow-on after the queued inventory scopes. The completed product-ledger baseline is #280 / PR #775; supplies and recipe planning are #768 and #769. This issue records a focused print fix only and does not authorize payment redesign.

Problem or motivation

When a customer pays more cash than the bill total, the payment flow already stores the applied amount separately from tendered_amount and change_amount, but normal receipt projections discard those optional fields. A 150 bill paid with 200 can therefore print cash 150 without showing cash received 200 or change 50.

Current behavior

Payment calculation, settlement, and the POS payment UI already handle cash overpayment and display change. The shared print document and backend/frontend print normalizers currently preserve only the payment method and applied amount. Existing payment-integrity work is tracked in #214 and is closed; this issue is the remaining print projection gap.

Desired outcome

Supported normal receipts show the persisted cash tendered amount and a localized positive change row while preserving applied payment amounts, payment order, legacy output, currency formatting, and non-cash behavior.

Proposed technical approach

• Extend the shared semantic payment snapshot with optional tendered and change values.
• Preserve the existing persisted fields through both backend and frontend normalizers; do not derive values for legacy records that lack them.
• Render cash tendered (falling back to applied cash when optional tendered data is absent) and a separate change row only when the persisted change is positive.
• Apply the semantic rule consistently to backend classic/compact, browser, WebUSB, raster, and merchant-template projections that use the shared document; assess the separate raw country-pack path explicitly.
• Reuse existing currency, minor-unit, locale, bilingual, RTL, and print-label flows. No payment settlement or database migration redesign is needed.

Alternatives considered

• Recomputing change from bill total and printed payments risks fabricating values for legacy or partially populated records; persisted payment fields are authoritative.
• Changing payment settlement would expand the closed Split-tender: card/upi lines silently capped to remaining balance, corrupting reconciliation and receipts #214 concern and is not needed for this projection defect.
• Tax-bill diagnostic output remains separate unless maintainers explicitly include it in the supported normal-receipt acceptance surface.

Area

Printing / ESC-POS

Acceptance criteria

• A 150 bill paid with cash 200 prints applied total 150, cash received/tendered 200, and localized change 50 on every supported normal receipt path.
• Exact cash payment prints no change row.
• Partial and split payments preserve applied amounts and order; only cash may expose tendered/change values.
• Legacy records without optional fields retain current output and never show derived/fake change.
• Formatting follows existing tenant currency, locale, minor-unit, zero-decimal, bilingual, and RTL behavior.
• Regression coverage proves normalizer preservation and print parity for backend classic/compact, browser/WebUSB, raster, and legacy no-change output.

Explicit exclusions

No payment settlement changes, refund redesign, database migration, supplier or inventory coupling, recipe/BOM behavior, cash-drawer accounting, tax-bill diagnostic expansion, or ERP work.

Dependencies and sequencing

The cash-drawer foundation is already delivered in PR #772. The product ledger is complete in #280; #768 and #769 are the preceding planning slots. These links define sequencing only and do not make inventory implementation a prerequisite of the print code or authorize any of those deliveries.

Review request

@itsbkm, please review the supported receipt surface and the bounded projection approach, share your thoughts, and let us know whether you are willing to take over or collaborate.

Additional context

The issue originated from the JUM-XZVN receipt report. The smallest fix is at the print-model boundary because the payment data is already stored correctly.