cadrumo.application.aggregation.invoice_kind module¶
One authority for the bank-direction to invoice-issuance mapping.
Every ledger surface that needs to know whether a bank movement represents an
invoice the taxpayer issued or one they received asks this module, so the
answer is decided once. Three private copies of the mapping previously lived in
iva_ledger,
evidence_advisory and
_ledger_evidence_gate, byte-identical and
independently maintained.
Home¶
This lives in the application layer rather than beside
InvoiceKind, deliberately. The mapping joins a
TransactionDirection to an
InvoiceKind, and domain.iva imports nothing from domain.transactions
today. Placing it there would mint a new cross-domain edge to host a function
whose only callers are in application — the same reasoning that keeps
InvoiceKind itself in domain.iva. _business_proportion is the
established precedent for a one-decision application module shared across the
aggregation surfaces.
- invoice_kind_for_direction(direction)[source]¶
Map a bank movement’s direction onto the invoice-issuance axis.
INCOMINGmoney is treated as a sale the taxpayer issued (output IVA);OUTGOINGmoney as a purchase they received (input IVA).- Parameters:
direction (
TransactionDirection|None) – The bank movement’s direction, orNonewhen the caller could not resolve one from a persisted evidence row.- Return type:
- Returns:
The corresponding
InvoiceKind, orNonefor any direction that is not an IVA settlement flow —INTERNAL_TRANSFERand the unresolved case — so the caller can reject the row rather than guess at a treatment for it.Note the deliberate limit in the module docstring: the refund of a purchase is an
INCOMINGmovement and resolves toISSUEDhere.