The credit note, the only correction path for a finalized invoice

Featurekamo-shared-library
Shipped
August 27, 2026 at 11:21 PM UTC
Author
Kamo
Commit
a09323e

B3: Kamo owns everything before finalize() and the provider owns everything after, and every provider on the roadmap treats a finalized invoice as immutable. So an invoice that was wrong is never edited and never deleted — a credit note is raised against it and the pair is what a set of accounts and an auditor both read. Nothing here writes to the invoice. Its own number series, from DocumentType.CREDIT_NOTE and its own counter row. A credit note that consumed an invoice number would leave a gap in the invoice series that nobody can explain years later. There is no DRAFT state: a credit note is raised as a completed act, so it is numbered and stamped in the same transaction that creates it. Figures are POSITIVE — a credit note for 50 credits 50. The sign lives in what the document is, not in its numbers; storing it negative means every reader has to know which convention this table follows, and the first one that does not makes an invoice total go up when a customer is refunded. sumCreditedForInvoice COALESCEs to zero: a null arriving where a number was expected is how a cap silently becomes no cap. Observed failures, verbatim. RED (before the entities existed), from CommerceInvoiceServiceTest: **************** cannot find symbol **************** cannot find symbol (CommerceCreditNote, CommerceCreditNoteRepository) GREEN: Tests run: 81, Failures: 0, Errors: 0, Skipped: 0 in InvoicingService, plus SharedLibBeanSafetyTest 3/3 green in an isolated export — the new package carries no stereotype at all.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing