The invoice carries the handover: delivery packs filed, units released when paid

When a delivery note is signed, the scenario finds the invoice by number and attaches the whole pack to it: the delivery note itself, the signatory's ID, each payment proof, the registration document and four photos. Accounts and branches then open one invoice and see every document for the sale.

The unit's VIN from the form is written onto the invoice as its reference. That ties the physical unit to the sale, and it is where the release step later reads the VIN from, so nobody types it twice. The update is skipped for a deleted or voided invoice.

The original request-for-invoice form is attached as well. The delivery note doesn't know which entry that was; a data store keyed by invoice id, written when the invoice was raised, resolves it. Photos are named by the first line item's product code, taken by iterating the lines and keeping only the first, without an aggregator.

Runs are processed one at a time. The invoice lookup and a fresh read of the form entry, which renews its file links, each retry up to three times a minute apart, and a run that still fails is kept for resuming rather than lost. After that, an eleven-way router gives each document its own branch with its own ignore handler, so one bad file never blocks the VIN or the other attachments. A companion scenario runs the same steps, photos included, when a signed note is edited, so documents that arrive later still reach the invoice; it checks each file exists before uploading.

Every fifteen minutes in business hours, the release scenario watches invoices and passes only those with nothing left to pay, which catches full payment whether it arrived in one payment or several. It looks the invoice up in a data store first: the first time, it creates a release form prefilled with invoice number, VIN and customer, records the mapping and emails the invoice and form to the sales and branch mailboxes; after that, it updates the existing form instead of creating a second.