* fix(suppliers): one 10-digit org number key for matching and storage Why the problem occurred: the supplier register was written in three spellings (the form asks for XXXXXX-XXXX, the v1 API and the MCP tool stored whatever the caller sent, the AI extractor emits bare digits) while matchSupplierByIdentity compared raw strings with .eq(). The canonical rule existed three times (normalizeOrgNumber, the MCP fuzzy pass's orgNumberKey, the extractor's toOrg10) and nowhere on the path that decides a match, so every AI-extracted invoice from a hyphen-registered supplier missed the strongest key and fell to exact-name matching. Prod holds 1738 hyphenated rows against 493 bare ones. What was removed or simplified: orgNumberKey (digits only, 10 kept, last 10 of 12, no Luhn) moves into lib/invariants/org-number.ts and replaces the two other copies. The matcher scans the company's suppliers with an org_number and compares keys, the same shape as its vat_number branch, so rows written before the backfill (and self-hosted instances that never run it) match too. CreateSupplierSchema, UpdateSupplierSchema and the staged create_supplier schema store the key; the form renders it through formatOrgNumberDisplay. A backfill migration strips the formatting from existing rows, skipping migration-reset source companies. Why this and not the proposed one: the issue's third layer (CHECK plus a unique index) would fail to create on prod, which holds 94 duplicate (company_id, key) groups across 18 companies, one of them 124 rows under a single placeholder-looking number; that needs a merge decision first and is filed as #2404. Rejecting anything that is not 10 or 12 digits on write was also dropped: 68 prod rows carry foreign registration numbers (DK, DE, NL, FI, GB, IE, US, CZ, IT) in org_number, so Swedish-shaped input is canonicalised and anything else is stored as typed. Luhn stays lenient on suppliers because two rows with the same mistyped number are one supplier and parties is Luhn-strict at promotion already. Fixes #2391 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013yCehdxm8yUubGAmoDFZag * fix(suppliers): key only Swedish-shaped org numbers, search and dedup through the key Skeptic pass on the previous commit. Three refutations, all confirmed: 1. orgNumberKey took the last 10 of any 12 digits and stripped letters. A VAT number typed into the org field (SE556012579001, orgnr + 01) keyed to 6012579001, another company's identity, on every write path and in the backfill; 26 prod rows hold exactly that shape (prefixes 55/52/87). A Belgian BE0123456789 lost its country letters the same way. The key now strips only hyphens and spaces and unprefixes 12 digits only behind 16/18/19/20; everything else is null, stored and compared as typed. The migration carries the same rule. 2. The supplier list search, the v1 ?search= filter and the list column all used the raw stored value, so a user searching 556677-88 after the backfill found nothing. Both searches now compare without separators and the column renders XXXXXX-XXXX. 3. Storage was not canonical on every path: the CSV import and the provider migration orchestrator wrote as typed and keyed their re-sync dedup by the raw value, so a Fortnox re-sync sending 556677-8899 would have duplicated the now-bare row. Both write and key through orgNumberKey. Also: the matcher scans live suppliers only, so a register holding an archived hyphenated row next to its live replacement resolves to the live one instead of whichever id sorts first. Refs #2391 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013yCehdxm8yUubGAmoDFZag * fix(suppliers): review pass: foreign numbers survive display and dedup, stub key canonical CodeRabbit findings on PR #2405, all verified against the code: - The supplier list rendered through formatOrgNumber, which strips letters and would show BE0123456789 as 012345-6789; it now uses formatOrgNumberDisplay, which leaves anything not Swedish-shaped alone. - The CSV import dedup fell back to digits-only, so BE0123456789 and FR0123456789 collided; the fallback is now the value as typed, in both the parse preview and the execute route. - The provider migration's supplier-invoice stub map was keyed by the raw provider value while the stored row was canonical, so 556677-8899 and 5566778899 on two invoices produced two stubs; the key goes through orgMapKey like the other maps. - v1 response examples show the stored 10-digit form; the request example keeps the hyphenated input. Refs #2391 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013yCehdxm8yUubGAmoDFZag * docs(api-skill): regenerate suppliers reference for the canonical org_number example Refs #2391 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013yCehdxm8yUubGAmoDFZag --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
107 lines
4.4 KiB
TypeScript
107 lines
4.4 KiB
TypeScript
/**
|
|
* CreateSupplierParamsSchema: vat_number is optional for every supplier type.
|
|
*
|
|
* The schema used to require a VAT number for supplier_type 'eu_business',
|
|
* citing ML 17 kap 24 §. That section governs what a seller must put on an
|
|
* INVOICE it issues, not what a buyer's supplier register must hold, and an EU
|
|
* supplier below its national registration threshold has no VAT number at all.
|
|
* The rule refused legitimate suppliers on the staged/agent path while
|
|
* components/suppliers/SupplierForm.tsx created the same company through the UI.
|
|
*/
|
|
import { describe, it, expect } from 'vitest'
|
|
import { CreateSupplierParamsSchema } from '../create-supplier'
|
|
import { generateReverseChargeBasisLines } from '@/lib/bookkeeping/vat-entries'
|
|
|
|
describe('CreateSupplierParamsSchema org_number', () => {
|
|
// #2391: the staged path stores the same 10-digit key as the dashboard.
|
|
it('stores the 10-digit key for every accepted spelling', () => {
|
|
for (const typed of ['556677-8899', '5566778899', '165566778899', ' 556677-8899 ']) {
|
|
const parsed = CreateSupplierParamsSchema.parse({ name: 'Testbrand AB', org_number: typed })
|
|
expect(parsed.org_number, typed).toBe('5566778899')
|
|
}
|
|
})
|
|
|
|
it('leaves a 12-digit value that is not a century form as typed', () => {
|
|
// A VAT number (orgnr + 01) passes the shape check but is not an identity
|
|
// the key may rewrite.
|
|
const parsed = CreateSupplierParamsSchema.parse({ name: 'Testbrand AB', org_number: '556677889901' })
|
|
expect(parsed.org_number).toBe('556677889901')
|
|
})
|
|
|
|
it('still rejects a value that is not a Swedish org number', () => {
|
|
expect(() =>
|
|
CreateSupplierParamsSchema.parse({ name: 'Testbrand AB', org_number: 'DK12345678' }),
|
|
).toThrow(/org number/)
|
|
})
|
|
})
|
|
|
|
describe('CreateSupplierParamsSchema vat_number', () => {
|
|
it('accepts an EU business supplier with no VAT number (below its national threshold)', () => {
|
|
const parsed = CreateSupplierParamsSchema.parse({
|
|
name: 'Kleinanbieter GmbH',
|
|
supplier_type: 'eu_business',
|
|
country: 'DE',
|
|
})
|
|
expect(parsed.supplier_type).toBe('eu_business')
|
|
expect(parsed.vat_number).toBeUndefined()
|
|
})
|
|
|
|
it('treats an empty-string VAT number on an EU supplier as unset, not invalid', () => {
|
|
const parsed = CreateSupplierParamsSchema.parse({
|
|
name: 'Kleinanbieter GmbH',
|
|
supplier_type: 'eu_business',
|
|
vat_number: ' ',
|
|
})
|
|
expect(parsed.vat_number).toBeUndefined()
|
|
})
|
|
|
|
it('still accepts an EU business supplier that does have a VAT number', () => {
|
|
const parsed = CreateSupplierParamsSchema.parse({
|
|
name: 'Cloud Hosting GmbH',
|
|
supplier_type: 'eu_business',
|
|
vat_number: 'DE123456789',
|
|
})
|
|
expect(parsed.vat_number).toBe('DE123456789')
|
|
})
|
|
|
|
it('leaves non-EU and Swedish suppliers unaffected', () => {
|
|
expect(
|
|
CreateSupplierParamsSchema.parse({ name: 'US Vendor Inc', supplier_type: 'non_eu_business' }).vat_number,
|
|
).toBeUndefined()
|
|
expect(
|
|
CreateSupplierParamsSchema.parse({ name: 'Svensk Leverantör AB', supplier_type: 'swedish_business' }).vat_number,
|
|
).toBeUndefined()
|
|
})
|
|
|
|
it('still rejects a malformed VAT number when one is supplied', () => {
|
|
expect(() =>
|
|
CreateSupplierParamsSchema.parse({
|
|
name: 'Cloud Hosting GmbH',
|
|
supplier_type: 'eu_business',
|
|
vat_number: 'XX123',
|
|
}),
|
|
).toThrow(/vat_number|country prefix/i)
|
|
})
|
|
})
|
|
|
|
describe('reverse charge does not consume supplier.vat_number', () => {
|
|
/**
|
|
* The decisive question behind making the field optional: omvänd
|
|
* betalningsskyldighet on an EU purchase is selected from supplier_type plus
|
|
* the invoice's reverse_charge flag. A VIES-validated counterparty VAT number
|
|
* is a condition for zero-rating an intra-community SUPPLY (the seller's
|
|
* side), not for a buyer self-assessing on a purchase. If someone ever moves
|
|
* a VAT-number gate into the reverse-charge path, this test breaks.
|
|
*/
|
|
it('books EU service purchase basis lines from supplier_type alone', () => {
|
|
const parsed = CreateSupplierParamsSchema.parse({
|
|
name: 'Kleinanbieter GmbH',
|
|
supplier_type: 'eu_business',
|
|
})
|
|
const lines = generateReverseChargeBasisLines(1000, 0.25, parsed.supplier_type)
|
|
expect(lines.map((l) => l.account_number)).toEqual(['4535', '4598'])
|
|
expect(lines[0].debit_amount).toBe(1000)
|
|
expect(lines[1].credit_amount).toBe(1000)
|
|
})
|
|
})
|