[Help wanted] Partial refund / residual value: published-fare proration vs invented arithmetic

[telivity-otaip]

Who this is for

TMC refund specialists and airline revenue accounting people who calculate partially flown residuals. If you've used "published fare for flown city pair, else carrier proration" — please document it here before someone codes original - flown = residual.

Why this hardens the system

Agents 5.1 / 5.2 / 6.1 touch residual value and partial refunds. The constitution explicitly forbids:

• residual = original − change fee
• partial refund = original − "used portion" without saying how used portion is priced
• ignoring separate tax proration

Files:

• packages/agents/settlement/src/refund-processing/
• packages/agents/exchange/src/change-management/
• packages/agents/exchange/src/exchange-reissue/
• CLAUDE.md Agents 5.1 / 5.2 / 6.1

What we need

1. KB algorithm outline used in your market:
   • when published fares exist for flown sectors
   • when carrier-specific proration applies
   • tax handling on partials
   • conjunction all-or-none interactions (6.1 already rejects partial conjunction — confirm exceptions if any)
2. Worked examples with made-up amounts (not live tickets).
3. Proposed interfaces so agents fail closed when proration method is unspecified.

Acceptance criteria

• KB rejects simple subtraction as the general rule
• Clear decision tree: published fare vs proration vs DOMAIN_QUESTION
• Worked examples for one-ways and round-trips partially flown
• Tests asserting fail-closed / explicit method required
• No invented TPM tables — call out data dependency

Search keywords

help wanted · partial refund · residual value · proration · Cat 33 · reissue · TMC · revenue accounting

How to contribute

Start with a comment describing your shop's decision tree. KB PR before engine math changes.