# Cash Refund → Register Shift Foundation v34

## Purpose

v34 adds controlled cash refunds against an existing captured cash payment.

This foundation does not yet model the complete Sales Return document.
It establishes the cash/accounting side of refund handling.

## Rules

Refund source payment must be:
- `method_type = cash`
- `status = captured`

Target register must have an open shift.

Cumulative cash refunds for one payment cannot exceed the original captured amount.

Refund amount also cannot exceed the current shift expected cash or violate the cash
account non-negative balance rule.

## Effects

Every refund atomically creates:

1. `cash.sale_cash_refunds`
2. negative immutable `cash.movements` entry (`shift_cash_out`)
3. immutable `cash.shift_entries` entry (`refund_cash`)
4. decrease in shift expected cash
5. decrease in cashbox balance
6. audit event

## Idempotency

Refund commands use tenant-scoped idempotency keys.

Retrying the same command returns the original refund and does not affect balances twice.

## API

POST /api/v1/cash/sale-payments/{paymentId}/refund-from-shift

Payload:
- register_id
- amount
- idempotency_key
- reason
- metadata (optional)

## Permission

- cash.shift.refund

## Important boundary

v34 controls the financial cash side only.

A later Sales Returns module should invoke this same public application contract after
the return/refund business rules have been approved.

## Next

v35:
- transactional outbox / automatic cash payment posting
- payment-capture → cash-shift orchestration
- cash refund orchestration from future Sales Returns