Update Gl Vat Code

Edit a VAT code's deductible share or its ESTV return box.

Partial update: each field is applied only when its key is present in the body, so an explicit null clears return_box_code while an omitted key leaves it alone. An empty body is a 422, not a silent no-op. Both fields may be sent together; they are applied in one transaction, so a refusal on either leaves the row untouched.

⚠️ return_box_code is NOT a forward-only edit — it re-declares this code's existing postings, including in FILED periods. Only the manual/metadata posting path snapshots the box onto gl_vat_posting; ar_ap (every invoice and credit note), the cash book and expense cards deliberately leave that column NULL even for a code that declares a box, and the return resolves them with coalesce(posting.return_box_code, code.return_box_code) — i.e. against whatever the code says at the moment the return is built. A filed period that carries a filed_snapshot keeps its exported figures — the PDF, CSV and eMWST XML render from the snapshot, not live — but the per-period drift diff will start reporting the difference, and the only thing that names a re-boxing as the cause is the annual Umsatzabstimmung's correction_hint, which annotates and never suppresses. ⚠️ A period filed before snapshots existed has none, so its PDF and CSV render live and DO move (its XML refuses either way). Use this to place a code that resolved no box; do not use it to reclassify a code with filed history unless you intend that restatement.

Refused (422) when the change moves the code to a different storage convention. Some boxes decide not just where the return reports an amount but how gl_vat_posting stores it: Ziff 415/420 keep an input-tax correction as a bare positive magnitude (because 479 = Σ(400,405,410) − Σ(415,420) subtracts it), Ziff 381 stores a Bezugsteuer acquisition with the sign of a purchase rather than a sale, and every other box stores the transaction's own sign. Re-boxing across those lines would split one code's declarations between two conventions, and a credit note that should reduce a figure would increase it. A move within one convention is allowed — 415 ↔ 420 changes nothing about storage. Otherwise: create a new code with the box you want and recode onto it whatever this one has already booked.

⚠️ A permitted move is not a harmless one. The refusal guards the stored sign, nothing else. return_box_code is not a presentational field: every accepted change still re-declares this code's existing postings, moving already-declared turnover or input tax from one ESTV line to another. Treat an allowed re-box as a restatement, not a relabelling.

⚠️ One door to the mixed state is deliberately still open, because closing it was outside the ruling that opened this endpoint: a code can be created with return_box_code="415" or "381" (POST …/gl/vat-codes takes a free, unvalidated, unstripped string) and then invoiced through ar_ap, which stores signed amounts whatever the box says. Reported for the owner; do not assume the state is unreachable.

default_deductibility_percent is the per-code Privatanteil (ZET-234) and decides gl_vat_posting.non_deductible_amount, hence Ziffer 415 Vorsteuerkorrektur. Use it for a mixed business/private expense whose private share is a fixed percentage of the code. It changes no already-posted row — non_deductible_amount is snapshotted at post time, so the new value applies to later postings, and to existing ones only when an accountant re-runs prepare on an open VAT period. It may not be sent as null.

Under an Art. 30 three-pot election the two reductions compose (F2355): the private share comes first and the sector key applies to the business remainder — 1,000 input tax at 80 % here and a 75 % residual key deducts 600 and corrects 400 in Ziffer 415. The key is taken to measure business use only; a key that already nets out private use must not be combined with a share below 100 % here. Neither order (this PATCH, or electing three-pot afterwards) is refused any more.