Committing a purchase with the result its retry will receive

Make the invoice balance before creating rows#

A purchase request contains more than a total to save. The service validates its fields, resolves the supporting document and converts amounts into bigint minor units. The calculator then rebuilds discounted lines, invoice components and allocated totals.

A missing document or nonzero allocation variance stops the write before the transaction begins. That gives storage an already-checked calculation to record instead of asking it to persist an invoice whose lines don't add up.

Identify the request and the purchase separately#

Inside BEGIN IMMEDIATE, the wrapper checks the retry key against an operation name and canonical request digest. Matching both returns the saved result. Changing either fails, even if the caller reuses the old key.

A new key doesn't necessarily mean a new purchase. The purchase action separately rejects an existing invoice, and existing product IDs can't silently switch their product or supplier association. Request identity helps replay an operation; it doesn't replace the identities of the records being written.

Give the rows and receipt one outcome#

The header, allocated lines, stock receipts, linked audit event and retry receipt commit together. An exception rolls them all back. Saving the receipt later could leave a purchase with no replay result; saving it first could claim success for a purchase that never committed.

This result confirms a local record, not an update to an external account. External work needs its own readback. The audit actor also comes from the trusted local caller, rather than a hosted authentication system.

The inspected tests cover exact retries, existing invoices sent with new keys, changed requests under used keys and attempts to edit audit rows. They weren't rerun, and no ledger data or external accounts were opened for this note.