* fix(inbox): match suppliers on VAT number, not just org-nr and name
An extracted document auto-links to a supplier by org_number, then by an
exact (case-insensitive) name match. The extractor deliberately leaves
orgNumber null unless the document carries a real Swedish
organisationsnummer, so for every foreign supplier the name was the only
key left: "ADOBE SYSTEMS SOFTWARE IRELAND LTD" prints nothing but a
momsregistreringsnummer (IE6364992H), which the suppliers table already
stores in vat_number and which no code path looked at.
Adds vat_number as a match key between org_number and name, and collapses
the five inlined copies of the lookup into lib/suppliers/match-supplier.ts:
- invoice-inbox upload (sync and deferred worker)
- invoice-inbox PUT /items/:id/extracted-data
- MCP createDocumentInboxItem (org-nr only until now: gains VAT and name)
- MCP gnubok_set_inbox_extracted_data
- MCP gnubok_create_supplier_invoice_from_inbox, which additionally read
supplierExt.organizationNumber, a key the extraction schema never
writes, so its org-nr lookup could not fire at all
VAT numbers are compared on a canonical key (uppercased alphanumerics), so
formatting variants match and a prefix-less "556012579001" still matches
"SE556012579001"; two different country prefixes never do.
Also escapes LIKE metacharacters in the name lookup, so a supplier named
"100 % Solutions" is no longer a wildcard pattern.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(inbox): re-run the supplier match when the extraction is re-run
"Tolka om" (POST /items/:id/retry-extraction) rewrote extracted_data and
left matched_supplier_id untouched. It is the one affordance a user
reaches for precisely when auto-linking failed, and it could not produce
a link no matter how many times they pressed it: the match ran once, at
first extraction, and never again. An item that arrived before its
supplier existed stayed unlinked forever.
The retry now runs the same shared matcher the other extraction paths
use. Only a positive match is written, unlike those paths which also
write null: a supplier the user picked by hand must survive a retry that
finds nothing, which is the likelier case on a document that already
failed to match once.
Stacked on fix/supplier-match-vat-number for matchSupplierId(); merge
that one first.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(inbox): write the retry-extraction update as two literal payloads
The conditional spread for matched_supplier_id was one more dynamic
payload than the phantom-column guard's ceiling allows (380 > 379), and
a spread is exactly the shape that guard cannot check. Two inline
literal update calls keep every written column checkable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
