* perf(bundle): drop the BAS chart and the Node crypto polyfill from the shared client baseline
Two chunks rode along in the first-load JS of almost every dashboard route:
the full BAS 2026 chart (315 KB uncompressed, in 81 route manifests) and
the browser polyfill for Node's crypto/vm/Buffer (327 KB, in 26 routes
incl. login and register). Neither was needed on first paint; both got
there through static imports of helpers that happen to live next to code
that needs the data or the builtin.
Node polyfill (4 pure splits, behaviour unchanged, re-exported from the
original modules for server callers):
- lib/auth/bankid-flags.ts: isBankIdEnabled (login, register, security
settings imported it from bankid.ts, which imports crypto).
- lib/import/bank-file/formats.ts: the format registry + detection (the
import history imported getFormat from parser.ts, which hashes).
- lib/salary/personnummer-format.ts: parsing/validation/formatting (the
employee forms reached the encrypting personnummer.ts via tax-column).
- lib/auth/api-key-scopes.ts: scope catalogue, groups, tool map, helpers
(the API key panel imported STAGING_SCOPES from the key generator).
BAS chart:
- lib/bookkeeping/bas-lazy.ts + use-bas-reference.ts: the chart becomes a
dynamic import, fetched once per session after first paint; components
that show BAS names/descriptions call useBasReference() and re-render
when it lands. Until then (and on the server) only the hardcoded
account-descriptions answer, so SSR and hydration agree.
- lib/bookkeeping/bas-labels.ts: class/group labels out of bas-reference.ts
(account-descriptions needed a label and paid for the whole chart).
- lib/bookkeeping/bas-account-numbers.ts (generated, ~11 KB) +
scripts/generate-bas-account-numbers.ts (--check) + parity test:
isStandardBASAccountNumber for AddAccountDialog/ChartOfAccountsManager.
- lib/bookkeeping/account-classifier-{heuristic,client}.ts: the BAS-aligned
heuristic shared by the server classifier and a client variant that uses
the lazy chart.
- lib/bookkeeping/invoice-accounts.ts: INVOICE_FX_RATE_MISSING,
InvoiceFxRateMissingError, getRevenueAccount, getOutputVatAccount out of
invoice-entries.ts, whose engine import pulled account-backfill and the
chart into SendInvoiceDialog/PaymentBookingDialog.
- CorrectOpeningBalanceDialog re-seeds names when the chart lands;
OpeningBalanceRowEditor builds its Fuse indexes lazily; the
ChartOfAccountsManager BAS-katalog tab awaits the chunk.
Tooling:
- scripts/perf/client-import-closure.mjs: static import closure of every
'use client' module with the shortest chain to a target (file or bare
specifier); found every path above without a build.
- scripts/checks/client-node-builtin.mjs wired into check:guards: a client
module reaching a Node builtin is a hard failure (0 today).
Left as is: invoices/[id], its credit page and SendInvoiceDialog still
reach the chart through lib/invoices/issue-credit-note -> invoice-entries
-> engine -> account-backfill; splitting the engine is out of scope here.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(perf): unambiguous import-edge regex in the closure walker (CodeQL js/redos)
One quantifier per span: a greedy [^'"]* up to the specifier quote, which it
cannot cross, so a run of whitespace has a single parse. Same edges as
before (multi-line named imports, re-exports, side-effect imports; type-only
imports still skipped).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Jakob Wennberg <311770904+jakobwennberg-oss@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
91 lines
3.3 KiB
TypeScript
91 lines
3.3 KiB
TypeScript
/**
|
|
* Pure invoice booking constants and account resolvers.
|
|
*
|
|
* Split from invoice-entries.ts (whose generators import the bookkeeping
|
|
* engine, and through it the account backfill and the full BAS chart) so
|
|
* the client-side proposal helpers can import them without that closure.
|
|
*/
|
|
|
|
import type { EntityType, VatTreatment } from '@/types'
|
|
|
|
/**
|
|
* Stable code for the "foreign-currency customer invoice without a rate"
|
|
* refusal. Registered in lib/errors/structured-errors.ts so REST routes, the
|
|
* MCP server and getErrorMessage() all translate it the same way.
|
|
*
|
|
* Sales-side twin of SI_FX_RATE_MISSING (supplier-invoice-entries.ts).
|
|
*/
|
|
export const INVOICE_FX_RATE_MISSING = 'INVOICE_FX_RATE_MISSING' as const
|
|
|
|
/**
|
|
* Raised when an invoice booking path is asked to translate a foreign-currency
|
|
* amount that has no usable exchange rate.
|
|
*
|
|
* The generators below derive every FX leg from the per-item amounts, and items
|
|
* carry no `*_sek` column: `exchange_rate` is the only SEK source they have. The
|
|
* old per-file fallback returned the RAW foreign amount, and because the 1510
|
|
* debit is derived from the sum of the credits on the FX branch, every leg was
|
|
* scaled by the same wrong factor: the verifikation still balanced, no DB
|
|
* trigger fired and nothing errored. A 1 000 EUR sale posted 1 000 kr to 3001
|
|
* and 250 kr to 2611 instead of 11 500 kr and 2 875 kr at 11,50 SEK/EUR,
|
|
* understating ruta 05 and ruta 10 of the momsdeklaration by the same amount:
|
|
* an oriktig uppgift exposed to skattetillägg under SFL 49 kap 4 §.
|
|
*
|
|
* Refusing instead of guessing follows the `match_batch_allocate` RPC
|
|
* (BATCH_FX_RATE_MISSING) and `toSekOrThrow()` in supplier-invoice-entries.ts.
|
|
*
|
|
* The same refusal covers the header-level fallbacks (no-items bookings and
|
|
* the payment entry) via `headerToSekOrThrow` below: those paths DO honour a
|
|
* populated `*_sek` column, so only rows with no SEK source at all refuse.
|
|
*/
|
|
export class InvoiceFxRateMissingError extends Error {
|
|
readonly code = INVOICE_FX_RATE_MISSING
|
|
constructor(public readonly currency: string) {
|
|
super(
|
|
`Invoice is in ${currency} but has no exchange rate on file; refusing to post it as if 1 ${currency} = 1 SEK.`
|
|
)
|
|
this.name = 'InvoiceFxRateMissingError'
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Get the appropriate revenue account based on VAT treatment
|
|
*
|
|
* For 'exempt': AB uses 3004 (Försäljning inom Sverige, momsfri),
|
|
* EF uses 3100 (Momsfria intäkter, mapped to R2 in NE engine).
|
|
*/
|
|
export function getRevenueAccount(vatTreatment: VatTreatment, entityType: EntityType = 'enskild_firma'): string {
|
|
switch (vatTreatment) {
|
|
case 'standard_25':
|
|
return '3001' // Försäljning 25%
|
|
case 'reduced_12':
|
|
return '3002' // Försäljning 12%
|
|
case 'reduced_6':
|
|
return '3003' // Försäljning 6%
|
|
case 'reverse_charge':
|
|
return '3308' // Försäljning tjänst EU
|
|
case 'export':
|
|
return '3305' // Försäljning tjänst Export
|
|
case 'exempt':
|
|
return entityType === 'aktiebolag' ? '3004' : '3100'
|
|
default:
|
|
return '3001'
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Get the output VAT account based on VAT treatment
|
|
*/
|
|
export function getOutputVatAccount(vatTreatment: VatTreatment): string {
|
|
switch (vatTreatment) {
|
|
case 'standard_25':
|
|
return '2611'
|
|
case 'reduced_12':
|
|
return '2621'
|
|
case 'reduced_6':
|
|
return '2631'
|
|
default:
|
|
return '2611'
|
|
}
|
|
}
|