fix(vat): drop personnummer century so enskild firma VAT number is SE+12 not SE+14 (#796)
* fix(vat): drop personnummer century so enskild firma VAT number is SE+12 not SE+14
Onboarding derived the VAT number as SE${orgNumber}01. For an enskild firma the
org number is a 12-digit personnummer, producing SE + 14 digits, which fails the
^SE\d{12}$ validation — the pre-filled value is re-submitted on save and the tax
settings page becomes unsavable.
New shared helper lib/vat/vat-number.ts (normalize/validate/derive, reusing
normalizeOrgNumber to drop the century + Luhn-validate). UpdateSettingsSchema,
the onboarding wizard, the onboarding upsert in lib/company/actions.ts, and the
arcim-migration provider import all route through it. Backfill migration repairs
existing SE+14 rows to SE+12 (idempotent, scoped to ^SE\d{14}$ only).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* chore(arcim): warn when a provider VAT number is dropped as malformed
The provider VAT guard silently discarded a value that doesn't normalise to a
valid SE+12 momsregistreringsnummer. Emit a structured warn (provider +
company, no raw value — it can embed a personnummer) so consistently-bad
provider data is observable rather than invisible. Addresses the OWASP V16
logging finding on the arcim VAT-normalisation change in this PR.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
9278221616
commit
5bacda4839
@@ -22,6 +22,7 @@ import type { MigrationProgress, MigrationResults, SkipReasons } from '../types'
|
||||
import type { ProviderName } from '@/lib/providers/types'
|
||||
import type { CustomerDto, SupplierDto, SalesInvoiceDto, SupplierInvoiceDto, PartyDto } from '@/lib/providers/dto'
|
||||
import { resolveConsent } from '@/lib/providers/resolve-consent'
|
||||
import { normalizeVatNumber, isValidSwedishVatNumber } from '@/lib/vat/vat-number'
|
||||
import {
|
||||
fetchCompanyInfoDirect,
|
||||
fetchCustomersDirect,
|
||||
@@ -109,8 +110,22 @@ export async function executeMigration(options: MigrationOptions): Promise<Migra
|
||||
if (!existing?.company_name && mapped.company_name) updates.company_name = mapped.company_name
|
||||
if (!existing?.org_number && mapped.org_number) updates.org_number = mapped.org_number
|
||||
if (!existing?.vat_number && mapped.vat_number) {
|
||||
updates.vat_number = mapped.vat_number
|
||||
updates.vat_registered = true
|
||||
// Normalise provider input; only persist a structurally valid
|
||||
// SE+12 momsregistreringsnummer so a malformed value from an
|
||||
// external API can't enter company_settings unchecked.
|
||||
const normalizedVat = normalizeVatNumber(mapped.vat_number)
|
||||
if (isValidSwedishVatNumber(normalizedVat)) {
|
||||
updates.vat_number = normalizedVat
|
||||
updates.vat_registered = true
|
||||
} else {
|
||||
// Observability: a provider sent a VAT number we can't normalise
|
||||
// to a valid SE+12 momsregistreringsnummer. We drop it (above),
|
||||
// but surface the anomaly so consistently-bad provider data is
|
||||
// visible. Don't log the raw value — it can embed a personnummer.
|
||||
console.warn(
|
||||
`[migration] Dropped malformed VAT number from ${provider} for company ${companyId} (normalized length ${normalizedVat.length})`,
|
||||
)
|
||||
}
|
||||
}
|
||||
if (mapped.fiscal_year_start_month !== 1) {
|
||||
updates.fiscal_year_start_month = mapped.fiscal_year_start_month
|
||||
|
||||
Reference in New Issue
Block a user