Write Invoice

The write body for a draft invoice — create and full replace alike.

A replace, not a patch: the editor holds the whole document, and a merge is how a line the user deleted survives the save. Only a draft is writable — once an invoice has been handed to SdI its content is frozen by law, which the store enforces in SQL rather than here.

The line cap (AP-099) is declared here rather than on _InvoiceFields, for the same reason the normalisers are: this is the only shape that reaches the table, and a read model that refused a stored row would turn an oversized write we once accepted into an invoice its owner can no longer open. InvoiceRead therefore keeps the format's own 9999 bound.

One stored invoice as the API returns it (payload decrypted).

number is NULL until the issue transaction assigns it, so a draft is exactly the row whose status is draft and whose number is unset. total_amount is the imponibile the store computed from the lines, and bollo_applied the builder's verdict on it — both stored plaintext because the live estimate aggregates them in SQL.

credit_note_of is what makes a TD04 legible on its own (AP-090): set, this row is a nota di credito and names the invoice it corrects; NULL on every ordinary document. It is the store's field and never a client's — a credit note is opened through its own route, not by writing this on a draft.

client_label is the same kind of field for an imported row (AP-095): a pre-signup invoice names its customer as the text the user's own export carried, because there is no client record behind it and inventing one would put a half-filled customer — no address, no identifier — in the picker that issues real documents. It is NULL on every invoice that has a client_id.