Fix/07 27 (#1271)
* fix(enable-banking): keep bank account mappings across reconnects and surface dead sessions A PSD2 reconnect silently moved the user's ledger mapping. Account identity came from the provider's account uid, which does not survive a re-authorization at every ASPSP, and a fresh connect to an already-connected bank mints a new bank_connections row regardless. Both paths looked like "an account we have never seen", so the allocator handed out the next free 19xx slot and a 1930/1940/1941 mapping came back as 1942-1946 on every consent renewal, roughly quarterly per connection. Match on the IBAN instead. resolvePsd2LedgerAccount() finds the existing cash_accounts row by normalized IBAN before allocating, and upsertFromPsd2 promotes that row in place rather than inserting a second one, so it keeps its id and its linked transactions and is re-pointed at the connection that just authorized. The previous holder's connection status is deliberately ignored: one IBAN is one physical account, and the old row often still reads 'active' because the bank killed the session without telling us. The allocator also stopped treating a 19xx number as free just because no cash_accounts row holds it. A chart imported from SIE carries the company's real bank accounts by name with no PSD2 row behind them, which is how a SEK company account got proposed as an unrelated brokerage account. Overflow now skips chart-occupied numbers, falling back only when nothing unnamed is left. Dead connections kept rendering as "Aktiv": status only ever changed when a transaction fetch failed, so a session killed bank-side stayed healthy-looking with a stale last_synced_at while the user read old balances as current. Add probeSessionHealth() and run it in the daily cron over every connection that run did not prove alive, including the ones the loop skips silently (capability gate, all accounts deselected) and the ones parked in pending_selection that the cron never looked at. It acts only on a definite dead answer; anything ambiguous leaves the row alone, since a wrong flip costs a full BankID re-authorization. The all-accounts-deselected branch is reclassified 'synced' to 'skipped' for the same reason: it never contacts the bank, so it must not count as proof of life. The settings row warns when an active connection has not synced in three days or has never synced. Which company a connection belongs to was invisible. Everything was already scoped to ctx.companyId, so there was no cross-tenant leak, but a bank authorized while the wrong company was active looked identical to the right one. Name the company on the connect surface and in the account picker, and say where the connection went when the callback lands under a different active company. Warn (bypassably) before authorizing a bank where the same user already holds live connections in other companies: several ASPSPs allow one active AIS session per login, so the new authorization can kill the others. The history start date already defaulted to the fiscal-year start; the card above it recommended a mid-year date and contradicted the selected option. It now states the fact and offers the shortcut without presenting it as advice. Not addressed: sharing one PSD2 session across companies. company_id is the tenancy anchor on bank_connections and cash_accounts hangs off (company_id, bank_connection_id), so that needs the session to become its own entity. See DECISIONS.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): show the posted line description in the voucher preview The "Verifikation som bokförs" preview built its expense debit lines with description set to the raw account number, so the BESKRIVNING column showed "5615" or "6990" where the posted verifikat actually says "Leverantörsfaktura 123, ACME AB". A hardcoded 11-entry ACCOUNT_LABELS map masked this for 2440/2641/26xx, which is why the column read as a mix of friendly labels and bare account numbers, neither of which was the posted text. The preview now renders exactly the line_description the engine writes: the shared invoice-level text on expense lines and 2440, "Ingående moms {rate}% {desc}" on 2641, and the reverse-charge pair taken straight from generateReverseChargeLines instead of being re-derived locally. buildSupplierDescription moves into its own dependency-free module so the client-side preview can call it without pulling the journal engine (and its Supabase server client) into the browser bundle. The account name stays reachable on the AccountNumber hover card. Picked option A from the issue, keeping the fixed invoice-level description rather than propagating each item's own text: the customer-invoice side already writes invoice-level descriptions, so per-item text would create an inconsistency between the two invoice sides rather than remove one, and it would need an aggregation-collision policy in the journal engine. Rationale recorded in DECISIONS.md. Refs #1258 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(bookkeeping): restore the copy icon on verifikat rows The row-language rewrite in #1123 reused the copy icon's slot for the new expand toggle, removing the zero-click copy affordance from the bookkeeping list without mentioning it. The leftover orphaned copy_voucher_tooltip key in both message files is what identifies it as collateral rather than a product decision. Restore a copy icon in the row's right-edge action cell, reusing that key for aria-label and title. stopPropagation keeps the click off the row's expand toggle. The icon is hover-revealed on md+ and always visible below it: #1123 collapsed the desktop table and the mobile card into one responsive table, so hover-only would leave touch users with nothing. Copy is no longer gated on posted. The copy_from handler and the GET journal-entries route never looked at status, so copying a draft already worked end-to-end and only the detail-page button hid it; the two list surfaces were already ungated. Both list affordances now respect canWrite, which previously dropped read-only users into a dialog they could not submit. The repo does not render components in tests, which is why #1123 removed this silently. Pin the source shape instead, the same way the copy-invoice query is pinned. Closes #1266 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(transactions): revalidate stale invoice match pointers before offering a match potential_invoice_id / potential_supplier_invoice_id are written once, at bank import, and never revisited. When one of several identical recurring invoices was settled by a different transaction, every other transaction kept pointing at the now fully paid invoice. The match dialog then measured the bank amount against a 0 kr remaining balance and reported a "Beloppen skiljer sig ... fakturan blir delbetald" partial payment, and the worklist offered the same dead suggestion as a one-click confirm row. Worse, the manual escape hatch was hidden exactly when it was needed: TransactionInboxCard only shows "Matcha mot leverantörsfaktura" when no suggestion exists, so a stale pointer left the user with no way at all to reach the correct invoice. Fixed by revalidating at read time rather than by clearing sibling pointers on settle. Invoices are settled through many paths (both match routes, mark-paid, MCP, bank reconciliation, SIE import), so write-time cleanup leaks the moment one is missed, while the candidate lookup covers every route into the list. The shared accept-lists in lib/invoices/matchable-statuses.ts mirror the CAS guards the match routes already enforce. - listSuggestedMatches and the transactions page candidate fetch filter on status + remaining_amount, so a settled candidate yields no suggestion and the manual picker reappears on its own. - InvoiceMatchDialog blocks a settled target with a distinct message and a disabled confirm. Not advisory: both routes reject it outright with MATCH_INVOICE_ALREADY_PAID / MATCH_SI_ALREADY_PAID, so no override could succeed. - The supplier detail card now shows remaining_amount like the customer branch, instead of total. On a partially paid invoice it used to print "1 250 kr" directly beside "Differens: 1 250 kr". - match-supplier-invoice clears potential_supplier_invoice_id on the transaction it just matched, mirroring the customer route. No bookkeeping was ever at risk: both routes already refused a settled target before creating a voucher. The damage was confined to a misleading dialog and a dead end. createQueuedMockSupabase gains passive call recording (calls / findCall / findCalls) because the proxy swallowed filter and update arguments, which made the new assertions inexpressible. Refs #1259, #1260 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(webhooks): dispatch on emit instead of waiting for the next cron tick (#1256) * feat(webhooks): dispatch on emit instead of waiting for the next cron tick The webhook dispatcher ran only on a per-minute cron, so the floor on delivery latency was up to 60 seconds plus the request. An external consumer that wanted to react as a transaction landed had only one alternative: polling /api/events, which the 100 rpm per-key limit makes expensive and which still cannot beat the tick interval. Schedules one dispatch cycle as soon as deliveries are enqueued. The cron is unchanged and remains the retry and sweep path; this only moves the first attempt forward. Wired into the event-bus fanout plus the two routes that enqueue a delivery directly: the :test verb, whose entire purpose is telling someone whether their receiver works, and the manual delivery retry. Three properties are load-bearing and covered by tests. The kick is never awaited, because eventBus.emit is awaited at ~99 call sites including journal_entry.committed and each delivery can burn a 10 s receiver timeout. It coalesces per function instance, so a bulk booking that emits once per row does not schedule one claim round trip per row. It claims 5 rows rather than the cron's 50, because it runs on the tail of a user-facing request. Double delivery is not a risk: claim_due_webhook_deliveries already claims FOR UPDATE SKIP LOCKED and flips rows to in_flight in the same statement, so a kick racing the cron sees disjoint rows. Does not close #1201, which asks for a realtime stream for API consumers. This is the cheap half. Refs #1201 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(webhooks): stop claiming the kick makes double delivery impossible Adversarial review of the previous commit caught an overstatement in its own comments. SKIP LOCKED keeps a kick and the cron from claiming the same row at the same moment, but claim_due_webhook_deliveries autocommits before any POST is issued, so from then on ownership is only status='in_flight' and a later cycle's recoverStuckInFlight sweep can re-arm a row still queued behind an earlier cycle's serial loop. Delivery is at-least-once, which is what the public docs already tell receivers ("the same delivery id may arrive more than once ... idempotency is on you"). The comments contradicted that. No behaviour change. The kick does not create this window: the cron claims 50 rows serially against the same 20 s stuck threshold, which is wider than what a batch of 5 can open. Refs #1201 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(bokslut): add bokslut-flow depreciation (78xx) back to the bolagsskatt base (#1253) * fix(bokslut): add bokslut-flow depreciation (78xx) back to the bolagsskatt base sumPostedYearEndDispositions reconstructs resultat fore skatt for the tax calculation, because generateIncomeStatement excludes every source_type='year_end' entry. It summed class 88 and 7533 but not 78xx, so planenlig avskrivning posted by the bokslut flow (lib/bokslut/assets/depreciation-engine.ts) was dropped from the income statement and never added back. The bolagsskatt base and the periodiseringsfond 25 % cap were therefore computed on an overstated result: tax too high by roughly 20.6 % of the depreciation. Also exclude the period's final bokslutsverifikation from the fetch. It carries source_type='year_end' as well and reverses every P&L account, 78xx/88xx/7533 included (verified against production closing entries), so once the year is closed it would cancel the add-back this function exists to produce. That hazard already applied to 88xx and 7533; the fix closes it for all three rather than widening it. Scope is deliberately the tax base only. Making the standalone resultatrakning show bokslut entries is a separate, larger change: the same exclusion is duplicated in the kpi_report_aggregates RPC, it moves displayed profit for every company that ran the bokslut flow, and it means removing the add-back at four call sites. Refs #1051 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(bokslut): scope the closing-entry lookup to the company and fail loudly Review (CodeRabbit + the compliance swarm, ASVS V8.2.1) flagged the new fiscal_periods read in sumPostedYearEndDispositions on two counts, both fair. It filtered only on the period id while every sibling query in the same function carries the tenant scope. Primary key or not, service-role paths have no RLS to fall back on and the repo's rule is to filter company_id explicitly, so it now does. It also discarded the query error. That mattered more than it looks: a failed read fell through to closingEntryId = null, which silently re-admits the closing verifikat's 78xx/88xx reversals and understates the tax base, i.e. exactly the failure this lookup was added to prevent. It now throws, and the surrounding catch turns it into the existing 'Failed to read posted dispositions' error. A wrong bolagsskatt is worse than a loud failure. Two regression tests: the lookup carries both eq filters, and a lookup failure propagates instead of degrading to a wrong number. Refs #1051 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(storage): drop the client-side DELETE policy on the documents bucket (#1254) * fix(storage): drop the client-side DELETE policy on the documents bucket 20240101000024 documents this bucket as WORM: "No UPDATE or DELETE policies". That described the repo, not production. Production carries a users_delete_own_documents policy that exists in no migration file: FOR DELETE TO authenticated USING (bucket_id = 'documents' AND (storage.foldername(name))[2] = auth.uid()::text) Under it, the uploading user can delete the storage bytes of any document they uploaded under the legacy documents/{userId}/... layout, using nothing but their normal browser token. That includes documents linked to a posted verifikat, which are rakenskapsinformation under the BFL 7 kap 2 § seven-year retention duty. deleteDocument()'s linked-check and the block_document_deletion() trigger both guard the document_attachments ROW, not the object: the row survives, still pointing at a file that is gone. Reproduced against a local replay of the full migration stream: with the policy present the uploader's own DELETE removes the object; with it dropped the same statement matches zero rows. Company-scoped keys were never exposed (their second path segment is the company id, not auth.uid()), so this only ever reached the legacy layout, which is where most documents still live. Safe because every in-app remove() on this bucket already runs on the service role, covered by service_role_all_documents. Deliberately narrow: users_read_own_documents and users_upload_own_documents stay. The Phase B backfill from 20260726092000 has not run, so dropping the legacy SELECT policy now would make existing documents unreadable. That is Phase C. The pg-real test asserts no DELETE and no UPDATE policy over the bucket under ANY name: the hole arrived under a name this repo never used, so pinning a name would not have caught it. Refs #1208 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(storage): make the WORM ratchet see FOR ALL and WITH CHECK policies Review caught two blind spots in the ratchet, both fair. It matched only polcmd 'd' and 'w', but polcmd '*' (FOR ALL) grants DELETE and UPDATE just as effectively, and FOR ALL is the shape the one legitimate policy on this table already uses, so a hostile one would look unremarkable in the catalogue. It also read only polqual, so an UPDATE policy carrying its bucket restriction in WITH CHECK was invisible. Both assertions now run through one helper that covers d/w/*, concatenates USING and WITH CHECK, and filters by grantee so service_role_all_documents (how the application does its authorized deletes) is excluded while every client-reachable role is not. A policy granted to PUBLIC has an empty polroles, which is the most permissive case there is, so it is treated as client-reachable rather than as "no roles". Matching on the substring rather than the exact `bucket_id = 'documents'` shape pg_get_expr emits today: a policy written as bucket_id::text or with the comparison reversed would slip past a stricter match, and for a WORM ratchet a false alarm is cheap while a silent hole is not. Adds a probe case that creates a FOR ALL policy and asserts the helper sees it, so the main assertion cannot pass vacuously. That case earned its keep immediately: it caught that node-postgres hands back a raw string for a name[] column, so the role filter needed rolname::text to work at all. Verified against a local replay of the full migration stream: red with the original prod FOR DELETE policy present, red with a FOR ALL probe, green without either. Full pg-real suite 933 passed. Refs #1208 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(storage): catch a destructive policy that names no bucket at all Adversarial review of the previous commit found the ratchet still failed open, and reproduced it: a policy with no bucket_id predicate covers EVERY bucket, documents included, so gating on the bucket name discarded exactly the widest hole. The concrete shape is Supabase's own stock "Enable delete for users based on user_id" template, USING (auth.uid() = owner), which is the single most likely form of a future dashboard edit. A destructive policy is now in scope unless it provably cannot reach this bucket, i.e. only a bucket_id predicate naming some other bucket exempts it. The behavioural assertions had the matching blind spot: fixtures were seeded without an owner, so an owner-based policy matched NULL and the DELETE reported 0 rows for the wrong reason. Objects now carry an owner the way storage-api stamps them in production, so those tests fail loudly instead of passing by accident. Two probes pin both directions: a bucketless policy must be reported (and is shown to really permit the delete), and a policy scoped to another bucket must not be, so the ratchet cannot start crying wolf on receipts or sie-files and get switched off. Verified against a local replay of the full migration stream: red with the stock bucketless template installed, green without it. Full pg-real suite 935 passed. Refs #1208 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(kontoplan): make a deactivated account reachable again (#1262) is_active=false read as "does not exist" on every read path but as "exists" on the (company_id, account_number) unique constraint, so a deactivated account vanished from the kontoplan with no way back and re-creating it answered "Kontonummer X finns redan i din kontoplan." The write side was already correct: POST /accounts/activate has a toReactivate branch and PUT /accounts/[number] accepts is_active:true. Both were simply unreachable, so this opens routes to them rather than relaxing the read filters, which are load-bearing for AccountsNotInChartError. - Kontoplan gets a "Visa inaktiva" filter; inactive rows carry an "Inaktiv" chip and the existing per-row switch reactivates them in one click. - Deactivating an account that has posted lines now warns first, using the usage count already loaded for the Verifikat column. - POST /accounts distinguishes the two collisions and returns the new ACCOUNT_EXISTS_INACTIVE code; AddAccountDialog offers "Aktivera kontot istallet" rather than a dead-end 409. The stored account is left exactly as it was; values typed into the failed create form are not applied. - bas-lookup consults the company's own chart before the static BAS reference, so a deactivated custom account reads as known and "Aktivera och bokfor" is no longer disabled for it. New in_chart / is_active fields let callers tell "will be added" from "will be revived". - BAS-katalog stops showing "Aktiverat" for an account the company holds but has deactivated; it falls through to a relabelled Aktivera button, and the per-class counts follow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): flag foreign 0 % lines with reverse charge switched off (#1255) * fix(supplier-invoices): flag foreign 0 % lines with reverse charge switched off A foreign supplier charging no Swedish VAT is normally omvand skattskyldighet. With the reverse-charge switch off, createSupplierInvoiceRegistrationEntry emits neither the 26x4 output leg nor the 44xx/45xx basis lines, so ruta 20-24, 30-32 and 48 all stay empty and the momsdeklaration takes a shape Skatteverket rejects. For a fully deductible purchase the net moms att betala is unchanged, which is exactly why this goes unnoticed. The form already auto-ticks reverse charge for eu_business but not for non_eu_business, so that path slips through silently. Adds a pure helper plus a non-blocking banner cloned from the existing rc_account_warning block. Deliberately silent for swedish_business, where 0 % is a genuine exemption that belongs in no ruta at all, and phrased as a question rather than an assertion: a non-EU goods purchase cleared at customs is legitimately 0 % without reverse charge, and pushing that user into ticking the switch would manufacture a new wrong verifikat. Does not add the exempt/import/other picker the issue proposes: supplier_invoices.vat_treatment is metadata that no booking or ruta mapping reads, and the codebase cannot book import VAT at all, so an import option would imply ruta 50/60 were handled when they are not. Refs #1042 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(supplier-invoices): name the local-VAT case in the foreign 0 % hint Review flagged that the most common foreign document a Swedish small company sees is an invoice carrying the supplier's OWN local VAT, booked at 0 % Swedish VAT with reverse charge correctly off. The banner fires there, and the previous copy only offered "momsfri av annat skal, till exempel en varuimport" as the way out, which does not describe that invoice at all: it is not VAT-free, it carries foreign VAT. Names both legitimate cases explicitly and says 0 % is correct in them, so the hint cannot read as an instruction to tick reverse charge on a purchase where that would produce a wrong verifikat. Title also narrowed to "utan svensk moms" for the same reason. Refs #1042 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(sandbox): call the sandbox assistant Assistenten, not Anna (#1244) A named persona earns its name once someone has been through onboarding and chosen it: it is their assistant and they named it. Nobody in the sandbox chose anything, so a first name reads as a character the product invented and implies a relationship the visitor never opted into. Both halves move together, which is the point. profile_summary is the agent's own self-description inside the system prompt, so leaving it as "Du är Anna" would have the header say one thing while the assistant introduces itself as another in its first sentence. Nothing else in the stack checks that pairing, so a test now does. Scope: this changes the seed, so new sandbox companies get the new name. The 483 sandbox profiles already seeded keep 'Anna' (the seeder returns early once a profile exists, and its caller only runs while verified_at is null). Backfilling those is a production write on demo data and is being raised separately rather than smuggled into a code change. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> * feat(reports): show the last posted voucher per series in report headers Adds a "Senaste bokforda verifikat: A 214, B 37" line to the balans- and resultatrapport, so a printed or exported report answers which vouchers are actually in it rather than only which dates it spans (#1267). Reads MAX(voucher_number) over posted entries, never voucher_sequences.last_number. The sequence counter is an allocation high-water mark that drifts from the books in both directions: next_voucher_number burns a number when the follow-up insert fails, delete_last_voucher decrements by one instead of resetting to the new MAX, and pre-RPC SIE imports left it behind. Since the point of the line is avstamning, an allocated number would send a reconciler chasing a gap that does not exist, so the label says plainly that the number is the posted one. Scoped to the report own date range, so a Q1 report printed in November says something true about Q1. The balansrapport keeps the fiscal-year start as its lower bound because it accumulates. Skipped on a dimension-filtered resultatrapport: that report already discloses it is partial, and an unfiltered voucher range beside a filtered result invites the wrong conclusion. Populated in both engines, so the JSON, PDF and XLSX routes all inherit it without signature changes. Best-effort: a header nicety never breaks a report. The pure formatter lives in its own module so the client view does not pull the Supabase query path into the browser bundle. No new i18n keys; both report views and the PDF template are hard-coded Swedish per the "stays Swedish" report surfaces in .claude/rules/i18n.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(customers): stop rendering personnummer ciphertext, make unreadable rows editable, add a reveal path (#1263) customers.personal_number holds AES-256-GCM ciphertext (20260726110000). Three defects compounded into one broken surface for private customers. The list queried Supabase from the browser with select('*') and rendered the raw value, 76-82 chars of hex, into the nowrap identifier cell. It now reads GET /api/customers, which already masks every row, so the ciphertext never leaves the server. Searching by personnummer works again: the client filter had been matching against ciphertext and could never hit. A row whose value cannot be decrypted renders as the placeholder '********-????'. None of the three mask checks recognised it, each having its own '-1234'-only copy, so such a customer could not be edited in ANY field: name and address edits 400'd on a personnummer the user had no way to correct. All three now share one pattern from the new crypto-free lib/customers/mask-personal-number.ts, which the client form can import. Typing a fresh personnummer overwrites the unreadable value, which is the only repair possible: the rejected writes failed whole INSERTs, so there is nothing to backfill. The value was write-only by construction. GET /api/customers/{id}/personal-number is the deliberate drill-in, mirroring the employee convention, gated on the write role because .compliance/ropa.yaml listed no_full_value_read_endpoint as a safeguard for this column; that entry is rewritten rather than left stale, and reveals log actor and customer id but never the value. Also: arcim-migration wrote the identity number as plaintext, which aborts any import containing a Privatperson with 23514 since the constraint flip; and the customer embeds on /api/invoices shipped ciphertext to the browser on every invoice read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat: enhance ruta 05 handling for dynamic revenue accounts - Introduced `fetchDynamicRuta05Accounts` to fetch company-specific revenue accounts marked with a VAT rate, addressing issue #1261. - Updated VAT declaration logic to include these dynamic accounts in ruta 05 calculations, ensuring accurate reporting for user-added accounts. - Modified `ACCOUNT_RUTA` to include account 3000 for completeness in ruta 05. - Enhanced tests to validate the inclusion of user-added revenue accounts in ruta 05 and ensure correct VAT calculations. - Seeded default VAT rates for BAS revenue accounts to ensure proper classification in the VAT declaration. * fix: enhance data handling and masking in customer and invoice APIs * fix(vat): resolve the 3000 gruppkonto's rate for the ruta 05 base split 3000 "Forsaljning inom Sverige" is mapped to ruta05 by ACCOUNT_RUTA, so a balance on it is filed in the right box already. What was missing is the rate split: unlike 3001/3002/3003 the account number carries no sats, and fetchDynamicRuta05Accounts skipped it because it is in ACCOUNT_TO_BOX. A company posting to the gruppkonto therefore got a ruta 05 total that breakdown.invoices.base25/12/6 did not add up to. Surface those rates separately as staticRateByAccount: rate-only on purpose, because the static map already sums the account and adding it to the dynamic account list would double the filed figure. A test pins that single-count property. Also add 3000 to the MCP server's RUTA_05_ACCOUNTS, which is the display list behind report.rutor.ruta05: without it a 3000 balance appeared in the filed projection but not in the report the agent reads back. The comment claiming SALES_OUTPUT_VAT_SHORTFALL reads base25/12/6 was wrong and is corrected. That check derives its expected base from the output-VAT rutor (ruta10/0.25 + ruta11/0.12 + ruta12/0.06); nothing reads the per-rate bases, which are reporting metadata. So the incomplete split never affected a filed return or a warning, only the breakdown. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Jakob Wennberg <149234542+jakobwennberg@users.noreply.github.com>
This commit is contained in:
Mattsson
co-authored by
Claude Opus 5
Jakob Wennberg
Claude Opus 5
Jakob Wennberg
parent
151ef51cc5
commit
65c6d4c178
@@ -9,18 +9,28 @@ vi.mock('../imbalance-diagnosis', () => ({
|
||||
buildImbalanceDiagnosis: vi.fn(),
|
||||
}))
|
||||
|
||||
// Mocked rather than fed through the queued Supabase stub: the queue resolves
|
||||
// in strict call order, so an extra real query inside the engine would shift
|
||||
// every enqueued response in this file.
|
||||
vi.mock('../latest-vouchers', () => ({
|
||||
getLatestPostedVouchers: vi.fn(),
|
||||
}))
|
||||
|
||||
import { generateBalansrapport } from '../balansrapport'
|
||||
import { generateTrialBalance } from '../trial-balance'
|
||||
import { findUntransferredResults, buildImbalanceDiagnosis } from '../imbalance-diagnosis'
|
||||
import { getLatestPostedVouchers } from '../latest-vouchers'
|
||||
import { createQueuedMockSupabase } from '@/tests/helpers'
|
||||
import type { TrialBalanceRow } from '@/types'
|
||||
|
||||
const mockTrialBalance = vi.mocked(generateTrialBalance)
|
||||
const mockFindUntransferred = vi.mocked(findUntransferredResults)
|
||||
const mockBuildDiagnosis = vi.mocked(buildImbalanceDiagnosis)
|
||||
const mockLatestVouchers = vi.mocked(getLatestPostedVouchers)
|
||||
|
||||
beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
mockLatestVouchers.mockResolvedValue([])
|
||||
})
|
||||
|
||||
function makeRow(overrides: Partial<TrialBalanceRow>): TrialBalanceRow {
|
||||
@@ -410,4 +420,77 @@ describe('generateBalansrapport', () => {
|
||||
expect(report.beraknat_resultat).toBe(0)
|
||||
expect(report.is_balanced).toBe(true)
|
||||
})
|
||||
|
||||
describe('latest_vouchers header line', () => {
|
||||
function enqueuePeriod(q: ReturnType<typeof createQueuedMockSupabase>) {
|
||||
q.enqueue({
|
||||
data: { period_start: '2026-01-01', period_end: '2026-12-31' },
|
||||
error: null,
|
||||
})
|
||||
mockTrialBalance.mockResolvedValueOnce(tb([]))
|
||||
}
|
||||
|
||||
it('carries the last posted voucher per series', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockResolvedValueOnce([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateBalansrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect(report.latest_vouchers).toEqual([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
})
|
||||
|
||||
it('omits the field entirely when the period has no vouchers', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockResolvedValueOnce([])
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateBalansrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect('latest_vouchers' in report).toBe(false)
|
||||
})
|
||||
|
||||
it('still returns the report when the lookup fails', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockRejectedValueOnce(new Error('boom'))
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateBalansrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect(report.latest_vouchers).toBeUndefined()
|
||||
expect(report.is_balanced).toBe(true)
|
||||
})
|
||||
|
||||
it('bounds the window at the as-of date with no lower bound (accumulating report)', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
|
||||
await generateBalansrapport(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ fromDate: '2026-02-01', toDate: '2026-03-31' }
|
||||
)
|
||||
|
||||
// fromDate narrows the report's own period label, but a balansrapport
|
||||
// accumulates from the fiscal-year start, so the voucher window must not
|
||||
// inherit that lower bound.
|
||||
expect(mockLatestVouchers).toHaveBeenCalledWith(
|
||||
expect.anything(),
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-03-31' }
|
||||
)
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
@@ -0,0 +1,187 @@
|
||||
import { describe, it, expect, vi, beforeEach } from 'vitest'
|
||||
import { getLatestPostedVouchers } from '../latest-vouchers'
|
||||
import { formatLatestVouchers, LATEST_VOUCHERS_LABEL } from '../latest-vouchers-format'
|
||||
import { createQueuedMockSupabase } from '@/tests/helpers'
|
||||
|
||||
beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
})
|
||||
|
||||
interface Row {
|
||||
id: string
|
||||
voucher_series: string | null
|
||||
voucher_number: number
|
||||
}
|
||||
|
||||
function row(id: string, series: string | null, number: number): Row {
|
||||
return { id, voucher_series: series, voucher_number: number }
|
||||
}
|
||||
|
||||
describe('getLatestPostedVouchers', () => {
|
||||
it('returns the highest number per series, sorted by series', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({
|
||||
data: [
|
||||
row('e1', 'B', 12),
|
||||
row('e2', 'A', 214),
|
||||
row('e3', 'A', 7),
|
||||
row('e4', 'B', 37),
|
||||
row('e5', 'A', 100),
|
||||
],
|
||||
error: null,
|
||||
})
|
||||
|
||||
const result = await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
|
||||
expect(result).toEqual([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
})
|
||||
|
||||
it('returns an empty array when the window holds no posted vouchers', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [], error: null })
|
||||
|
||||
const result = await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
|
||||
expect(result).toEqual([])
|
||||
})
|
||||
|
||||
it('excludes drafts and cancelled entries, which is what voucher_number > 0 buys', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [row('e1', 'A', 5)], error: null })
|
||||
|
||||
await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
|
||||
// Drafts and cancelled entries both carry voucher_number = 0.
|
||||
expect(q.findCall('journal_entries', 'gt')).toEqual(['voucher_number', 0])
|
||||
// Reversed entries keep their number and their slot in the series, so they
|
||||
// count: excluding them would report a gap that is not there.
|
||||
const statusFilter = q.findCall('journal_entries', 'in')
|
||||
expect(statusFilter?.[0]).toBe('status')
|
||||
expect(statusFilter?.[1]).toEqual(['posted', 'reversed'])
|
||||
})
|
||||
|
||||
it('bounds the window by toDate only when no fromDate is given (balansrapport)', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [row('e1', 'A', 5)], error: null })
|
||||
|
||||
await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-03-31' }
|
||||
)
|
||||
|
||||
expect(q.findCall('journal_entries', 'lte')).toEqual(['entry_date', '2026-03-31'])
|
||||
// The fiscal period filter is the lower bound; no explicit gte.
|
||||
expect(q.findCall('journal_entries', 'gte')).toBeUndefined()
|
||||
expect(q.findCall('journal_entries', 'eq')).toEqual(['company_id', 'company-1'])
|
||||
})
|
||||
|
||||
it('bounds both ends when fromDate is given (resultatrapport)', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [row('e1', 'A', 5)], error: null })
|
||||
|
||||
await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ fromDate: '2026-01-01', toDate: '2026-03-31' }
|
||||
)
|
||||
|
||||
expect(q.findCall('journal_entries', 'gte')).toEqual(['entry_date', '2026-01-01'])
|
||||
expect(q.findCall('journal_entries', 'lte')).toEqual(['entry_date', '2026-03-31'])
|
||||
})
|
||||
|
||||
it('orders on the primary key so paging cannot skip or duplicate rows', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [row('e1', 'A', 5)], error: null })
|
||||
|
||||
await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
|
||||
expect(q.findCall('journal_entries', 'order')).toEqual(['id', { ascending: true }])
|
||||
})
|
||||
|
||||
it('falls back to series A for entries with a null voucher_series', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: [row('e1', null, 9), row('e2', 'A', 4)], error: null })
|
||||
|
||||
const result = await getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
|
||||
expect(result).toEqual([{ series: 'A', last_number: 9 }])
|
||||
})
|
||||
|
||||
it('propagates a query error so the caller can decide (engines swallow it)', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
q.enqueue({ data: null, error: { message: 'boom' } })
|
||||
|
||||
await expect(
|
||||
getLatestPostedVouchers(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ toDate: '2026-12-31' }
|
||||
)
|
||||
).rejects.toThrow('boom')
|
||||
})
|
||||
})
|
||||
|
||||
describe('formatLatestVouchers', () => {
|
||||
it('joins series and number with a comma', () => {
|
||||
expect(
|
||||
formatLatestVouchers([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
).toBe('A 214, B 37')
|
||||
})
|
||||
|
||||
it('returns null for an empty list so surfaces drop the line entirely', () => {
|
||||
expect(formatLatestVouchers([])).toBeNull()
|
||||
})
|
||||
|
||||
it('returns null for undefined', () => {
|
||||
expect(formatLatestVouchers(undefined)).toBeNull()
|
||||
})
|
||||
|
||||
it('names the number as posted, not allocated', () => {
|
||||
// The distinction is the whole point: an allocated number can sit ahead of
|
||||
// the books, and a reconciler told the wrong one chases a phantom gap.
|
||||
expect(LATEST_VOUCHERS_LABEL).toBe('Senaste bokförda verifikat')
|
||||
})
|
||||
})
|
||||
@@ -0,0 +1,121 @@
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { renderToBuffer } from '@react-pdf/renderer'
|
||||
import { BalansrapportPDF, ResultatrapportPDF } from '../operational-report-pdf-template'
|
||||
import type { BalansrapportReport, CompanySettings, ResultatrapportReport } from '@/types'
|
||||
|
||||
// Real @react-pdf/renderer layout is CPU-heavy; under a fully parallel
|
||||
// test run these can exceed the 5s default on a saturated machine.
|
||||
const RENDER_TIMEOUT = 30_000
|
||||
|
||||
function fakeCompany(): CompanySettings {
|
||||
return {
|
||||
company_name: 'Testbolaget AB',
|
||||
org_number: '5566778899',
|
||||
vat_number: 'SE556677889901',
|
||||
entity_type: 'aktiebolag',
|
||||
} as unknown as CompanySettings
|
||||
}
|
||||
|
||||
function balansrapport(overrides: Partial<BalansrapportReport> = {}): BalansrapportReport {
|
||||
return {
|
||||
groups: [
|
||||
{
|
||||
class: 1,
|
||||
class_label: '1 Tillgångar',
|
||||
rows: [
|
||||
{ account_number: '1930', account_name: 'Företagskonto', ib: 50000, ub: 75000, period_change: 25000 },
|
||||
],
|
||||
subtotal_ib: 50000,
|
||||
subtotal_ub: 75000,
|
||||
},
|
||||
],
|
||||
total_assets_ub: 75000,
|
||||
total_equity_liabilities_ub: -75000,
|
||||
beraknat_resultat: 0,
|
||||
is_balanced: true,
|
||||
period: { start: '2026-01-01', end: '2026-12-31' },
|
||||
...overrides,
|
||||
}
|
||||
}
|
||||
|
||||
function resultatrapport(overrides: Partial<ResultatrapportReport> = {}): ResultatrapportReport {
|
||||
return {
|
||||
groups: [
|
||||
{
|
||||
class: 3,
|
||||
class_label: '3 Rörelsens inkomster/intäkter',
|
||||
rows: [
|
||||
{ account_number: '3001', account_name: 'Försäljning 25%', current_period: 100000, prior_period: 80000 },
|
||||
],
|
||||
subtotal_current: 100000,
|
||||
subtotal_prior: 80000,
|
||||
},
|
||||
],
|
||||
net_result_current: 100000,
|
||||
net_result_prior: 80000,
|
||||
period: { start: '2026-01-01', end: '2026-12-31' },
|
||||
prior_period: { start: '2025-01-01', end: '2025-12-31' },
|
||||
...overrides,
|
||||
}
|
||||
}
|
||||
|
||||
describe('operational report PDFs', () => {
|
||||
it(
|
||||
'renders the balansrapport with the latest-voucher header line',
|
||||
async () => {
|
||||
const buffer = await renderToBuffer(
|
||||
BalansrapportPDF({
|
||||
report: balansrapport({
|
||||
latest_vouchers: [
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
],
|
||||
}),
|
||||
company: fakeCompany(),
|
||||
generatedAt: '2026-07-28T10:00:00.000Z',
|
||||
})
|
||||
)
|
||||
|
||||
expect(buffer).toBeInstanceOf(Buffer)
|
||||
expect(buffer.slice(0, 5).toString()).toBe('%PDF-')
|
||||
expect(buffer.length).toBeGreaterThan(1000)
|
||||
},
|
||||
RENDER_TIMEOUT
|
||||
)
|
||||
|
||||
it(
|
||||
'renders the balansrapport without the line when no vouchers exist',
|
||||
async () => {
|
||||
const buffer = await renderToBuffer(
|
||||
BalansrapportPDF({
|
||||
report: balansrapport(),
|
||||
company: fakeCompany(),
|
||||
generatedAt: '2026-07-28T10:00:00.000Z',
|
||||
})
|
||||
)
|
||||
|
||||
expect(buffer.slice(0, 5).toString()).toBe('%PDF-')
|
||||
},
|
||||
RENDER_TIMEOUT
|
||||
)
|
||||
|
||||
it(
|
||||
'renders the resultatrapport with both the voucher line and a filter note',
|
||||
async () => {
|
||||
const buffer = await renderToBuffer(
|
||||
ResultatrapportPDF({
|
||||
report: resultatrapport({
|
||||
latest_vouchers: [{ series: 'A', last_number: 88 }],
|
||||
}),
|
||||
company: fakeCompany(),
|
||||
generatedAt: '2026-07-28T10:00:00.000Z',
|
||||
filterNote: 'Filtrerad (dimension 6: P001), ej fullständig rapport',
|
||||
})
|
||||
)
|
||||
|
||||
expect(buffer.slice(0, 5).toString()).toBe('%PDF-')
|
||||
expect(buffer.length).toBeGreaterThan(1000)
|
||||
},
|
||||
RENDER_TIMEOUT
|
||||
)
|
||||
})
|
||||
@@ -4,15 +4,25 @@ vi.mock('../trial-balance', () => ({
|
||||
generateTrialBalance: vi.fn(),
|
||||
}))
|
||||
|
||||
// Mocked rather than fed through the queued Supabase stub: the queue resolves
|
||||
// in strict call order, so an extra real query inside the engine would shift
|
||||
// every enqueued response in this file.
|
||||
vi.mock('../latest-vouchers', () => ({
|
||||
getLatestPostedVouchers: vi.fn(),
|
||||
}))
|
||||
|
||||
import { generateResultatrapport, shiftDateOneYearBack } from '../resultatrapport'
|
||||
import { generateTrialBalance } from '../trial-balance'
|
||||
import { getLatestPostedVouchers } from '../latest-vouchers'
|
||||
import { createQueuedMockSupabase } from '@/tests/helpers'
|
||||
import type { TrialBalanceRow } from '@/types'
|
||||
|
||||
const mockTrialBalance = vi.mocked(generateTrialBalance)
|
||||
const mockLatestVouchers = vi.mocked(getLatestPostedVouchers)
|
||||
|
||||
beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
mockLatestVouchers.mockResolvedValue([])
|
||||
})
|
||||
|
||||
function makeRow(overrides: Partial<TrialBalanceRow>): TrialBalanceRow {
|
||||
@@ -450,6 +460,94 @@ describe('generateResultatrapport', () => {
|
||||
expect(report.groups[0].rows[0].current_period).toBe(40000)
|
||||
expect(report.net_result_current).toBe(40000)
|
||||
})
|
||||
|
||||
describe('latest_vouchers header line', () => {
|
||||
function enqueuePeriod(q: ReturnType<typeof createQueuedMockSupabase>) {
|
||||
q.enqueue({
|
||||
data: { period_start: '2026-01-01', period_end: '2026-12-31', previous_period_id: null },
|
||||
error: null,
|
||||
})
|
||||
mockTrialBalance.mockResolvedValueOnce(tb([]))
|
||||
}
|
||||
|
||||
it('carries the last posted voucher per series', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockResolvedValueOnce([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateResultatrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect(report.latest_vouchers).toEqual([
|
||||
{ series: 'A', last_number: 214 },
|
||||
{ series: 'B', last_number: 37 },
|
||||
])
|
||||
})
|
||||
|
||||
it('omits the field entirely when the period has no vouchers', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockResolvedValueOnce([])
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateResultatrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect('latest_vouchers' in report).toBe(false)
|
||||
})
|
||||
|
||||
it('still returns the report when the lookup fails', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
mockLatestVouchers.mockRejectedValueOnce(new Error('boom'))
|
||||
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
const report = await generateResultatrapport(q.supabase as any, 'company-1', 'period-1')
|
||||
|
||||
expect(report.latest_vouchers).toBeUndefined()
|
||||
expect(report.net_result_current).toBe(0)
|
||||
})
|
||||
|
||||
it('scopes the window to the reported date range', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
|
||||
await generateResultatrapport(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ fromDate: '2026-01-01', toDate: '2026-03-31' }
|
||||
)
|
||||
|
||||
expect(mockLatestVouchers).toHaveBeenCalledWith(
|
||||
expect.anything(),
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ fromDate: '2026-01-01', toDate: '2026-03-31' }
|
||||
)
|
||||
})
|
||||
|
||||
it('skips the lookup entirely on a dimension-filtered report', async () => {
|
||||
const q = createQueuedMockSupabase()
|
||||
enqueuePeriod(q)
|
||||
|
||||
const report = await generateResultatrapport(
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
q.supabase as any,
|
||||
'company-1',
|
||||
'period-1',
|
||||
{ dimensions: { '6': 'P001' } }
|
||||
)
|
||||
|
||||
// The report already discloses that it is partial; an unfiltered voucher
|
||||
// range next to a filtered result would invite the wrong conclusion.
|
||||
expect(mockLatestVouchers).not.toHaveBeenCalled()
|
||||
expect(report.latest_vouchers).toBeUndefined()
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
describe('shiftDateOneYearBack', () => {
|
||||
|
||||
@@ -7,6 +7,15 @@ import { describe, it, expect, vi, beforeEach } from 'vitest'
|
||||
let resultIdx: number
|
||||
let results: Array<{ data?: unknown; error?: unknown }>
|
||||
|
||||
/**
|
||||
* The company's own class 3 accounts carrying a "Standard moms", as
|
||||
* fetchDynamicRuta05Accounts reads them. Answered off a table-routed builder
|
||||
* rather than the sequential queue: every calculateVatDeclaration test would
|
||||
* otherwise have to seed one, and a missing seed would silently hand the chart
|
||||
* query the ledger result.
|
||||
*/
|
||||
let chartAccounts: Array<{ account_number: string; default_vat_rate: number | null }>
|
||||
|
||||
function makeBuilder() {
|
||||
const b: Record<string, unknown> = {}
|
||||
for (const m of ['select', 'eq', 'neq', 'in', 'gte', 'lte', 'lt', 'or', 'not', 'order', 'range', 'limit']) {
|
||||
@@ -18,9 +27,31 @@ function makeBuilder() {
|
||||
return b
|
||||
}
|
||||
|
||||
/**
|
||||
* chart_of_accounts builder. Applies the same filters the real query relies on
|
||||
* (account_class = 3, default_vat_rate in the taxable sats) so a fixture can
|
||||
* assert that a rate-less or non-revenue konto never reaches ruta 05.
|
||||
*/
|
||||
function makeChartBuilder() {
|
||||
const b: Record<string, unknown> = {}
|
||||
for (const m of ['select', 'eq', 'in', 'not', 'order', 'range']) {
|
||||
b[m] = vi.fn().mockReturnValue(b)
|
||||
}
|
||||
b.then = (resolve: (v: unknown) => void) =>
|
||||
resolve({
|
||||
data: chartAccounts.filter(
|
||||
(a) => a.default_vat_rate != null && [0.25, 0.12, 0.06].includes(a.default_vat_rate)
|
||||
),
|
||||
error: null,
|
||||
})
|
||||
return b
|
||||
}
|
||||
|
||||
function makeClient() {
|
||||
return {
|
||||
from: vi.fn().mockImplementation(() => makeBuilder()),
|
||||
from: vi.fn().mockImplementation((table: string) =>
|
||||
table === 'chart_of_accounts' ? makeChartBuilder() : makeBuilder()
|
||||
),
|
||||
rpc: vi.fn().mockImplementation(async () => results[resultIdx++] ?? { data: null, error: null }),
|
||||
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
||||
} as any
|
||||
@@ -76,6 +107,7 @@ beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
resultIdx = 0
|
||||
results = []
|
||||
chartAccounts = []
|
||||
supabase = makeClient()
|
||||
})
|
||||
|
||||
@@ -896,6 +928,220 @@ describe('calculateVatDeclaration: parent/summary accounts', () => {
|
||||
})
|
||||
})
|
||||
|
||||
// ============================================================
|
||||
// #1261: the company's OWN revenue accounts reach ruta 05.
|
||||
//
|
||||
// ACCOUNT_RUTA maps 3000-3003 only, and Accounted's BAS chart ships no
|
||||
// varugrupp accounts at all, so a company selling on 3013 had that revenue
|
||||
// dropped from the declaration entirely: the map's keys ARE the account filter
|
||||
// sent to the aggregation RPC. Membership now comes from the konto's own
|
||||
// "Standard moms" (chart_of_accounts.default_vat_rate).
|
||||
// ============================================================
|
||||
|
||||
describe('calculateVatDeclaration: company-specific ruta 05 accounts', () => {
|
||||
it('includes a user-added revenue account carrying a moms-sats', async () => {
|
||||
chartAccounts = [{ account_number: '3013', default_vat_rate: 0.06 }]
|
||||
seedLedger([
|
||||
{ account_number: '3013', debit_amount: 0, credit_amount: 8000 },
|
||||
{ account_number: '2631', debit_amount: 0, credit_amount: 480 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(8000)
|
||||
expect(result.rutor.ruta12).toBe(480)
|
||||
})
|
||||
|
||||
it('books the account into the base bucket of its own sats', async () => {
|
||||
// Without this the ruta 05 total would have no matching base25/12/6, and
|
||||
// the proportional SALES_OUTPUT_VAT_SHORTFALL check reads an unaccounted
|
||||
// base as missing utgående moms.
|
||||
chartAccounts = [
|
||||
{ account_number: '3011', default_vat_rate: 0.25 },
|
||||
{ account_number: '3013', default_vat_rate: 0.06 },
|
||||
]
|
||||
seedLedger([
|
||||
{ account_number: '3011', debit_amount: 0, credit_amount: 4000 },
|
||||
{ account_number: '3013', debit_amount: 0, credit_amount: 1000 },
|
||||
{ account_number: '3001', debit_amount: 0, credit_amount: 2000 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(7000)
|
||||
expect(result.breakdown.invoices.base25).toBe(6000) // 3001 + 3011
|
||||
expect(result.breakdown.invoices.base6).toBe(1000) // 3013
|
||||
expect(result.breakdown.invoices.base12).toBe(0)
|
||||
})
|
||||
|
||||
it('counts a 3000 gruppkonto balance in ruta 05 exactly once', async () => {
|
||||
// 3000 is already summed into ruta 05 by the static map. Surfacing its
|
||||
// "Standard moms" must not also add it to the dynamic account list, which
|
||||
// would double the filed figure.
|
||||
chartAccounts = [{ account_number: '3000', default_vat_rate: 0.25 }]
|
||||
seedLedger([
|
||||
{ account_number: '3000', debit_amount: 0, credit_amount: 5000 },
|
||||
{ account_number: '2611', debit_amount: 0, credit_amount: 1250 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(5000)
|
||||
expect(result.rutor.ruta10).toBe(1250)
|
||||
})
|
||||
|
||||
it('books a rated 3000 into its base bucket so the split adds up to ruta 05', async () => {
|
||||
chartAccounts = [{ account_number: '3000', default_vat_rate: 0.25 }]
|
||||
seedLedger([
|
||||
{ account_number: '3000', debit_amount: 0, credit_amount: 5000 },
|
||||
{ account_number: '3001', debit_amount: 0, credit_amount: 2000 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(7000)
|
||||
expect(result.breakdown.invoices.base25).toBe(7000) // 3001 + 3000
|
||||
expect(result.breakdown.invoices.base12).toBe(0)
|
||||
expect(result.breakdown.invoices.base6).toBe(0)
|
||||
})
|
||||
|
||||
it('leaves 3000 in ruta 05 with no base bucket when no sats is set', async () => {
|
||||
// The filed figure is unaffected: only the breakdown is incomplete, and
|
||||
// the checks derive their expected base from the output-VAT rutor.
|
||||
chartAccounts = []
|
||||
seedLedger([{ account_number: '3000', debit_amount: 0, credit_amount: 5000 }])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(5000)
|
||||
expect(result.breakdown.invoices.base25).toBe(0)
|
||||
})
|
||||
|
||||
it('nets a credit note booked as a debit on the account', async () => {
|
||||
chartAccounts = [{ account_number: '3013', default_vat_rate: 0.06 }]
|
||||
seedLedger([
|
||||
{ account_number: '3013', debit_amount: 0, credit_amount: 8000 },
|
||||
{ account_number: '3013', debit_amount: 1000, credit_amount: 0 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(7000)
|
||||
expect(result.breakdown.invoices.base6).toBe(7000)
|
||||
})
|
||||
|
||||
it('does not double-count an account the static map already owns', async () => {
|
||||
// The BAS backfill sets 3001 = 25 %, so it comes back from the chart query
|
||||
// too. Counting it in both projections would double ruta 05.
|
||||
chartAccounts = [{ account_number: '3001', default_vat_rate: 0.25 }]
|
||||
seedLedger([
|
||||
{ account_number: '3001', debit_amount: 0, credit_amount: 10000 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(10000)
|
||||
expect(result.breakdown.invoices.base25).toBe(10000)
|
||||
})
|
||||
|
||||
it('leaves accounts that belong to another ruta out of ruta 05', async () => {
|
||||
// VMB (3211) is ruta 07 and 3231 is ruta 41. Neither is mappable yet, so
|
||||
// they stay out of the declaration: filing an amount in the wrong box is
|
||||
// worse than omitting it.
|
||||
chartAccounts = [
|
||||
{ account_number: '3211', default_vat_rate: 0.25 },
|
||||
{ account_number: '3231', default_vat_rate: 0.25 },
|
||||
]
|
||||
seedLedger([
|
||||
{ account_number: '3211', debit_amount: 0, credit_amount: 5000 },
|
||||
{ account_number: '3231', debit_amount: 0, credit_amount: 3000 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(0)
|
||||
})
|
||||
|
||||
it('keeps an account the ACCOUNT_TO_BOX mirror already maps in its own ruta', async () => {
|
||||
// 3108 is momsfri EU-leverans (ruta 35). A user who sets a sats on it must
|
||||
// not move it to ruta 05.
|
||||
chartAccounts = [{ account_number: '3108', default_vat_rate: 0.25 }]
|
||||
seedLedger([{ account_number: '3108', debit_amount: 0, credit_amount: 4000 }])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta35).toBe(4000)
|
||||
expect(result.rutor.ruta05).toBe(0)
|
||||
})
|
||||
|
||||
it('routes momspliktig EU-försäljning (3106) to ruta 05', async () => {
|
||||
// 3106 carries Swedish moms (buyer not VAT-registered), so it is ordinary
|
||||
// momspliktig försäljning. Neither ACCOUNT_RUTA nor the mirror maps it; the
|
||||
// MCP report has widened ruta 05 with it by hand for the same reason.
|
||||
chartAccounts = [{ account_number: '3106', default_vat_rate: 0.25 }]
|
||||
seedLedger([
|
||||
{ account_number: '3106', debit_amount: 0, credit_amount: 2000 },
|
||||
{ account_number: '2611', debit_amount: 0, credit_amount: 500 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(2000)
|
||||
expect(result.breakdown.invoices.base25).toBe(2000)
|
||||
})
|
||||
|
||||
it('ignores revenue accounts with no sats or an explicit 0 %', async () => {
|
||||
// "Ingen standard" and "Ingen moms" both mean the konto is not declared
|
||||
// momspliktig: momsfri revenue belongs in ruta 42, not 05.
|
||||
chartAccounts = [
|
||||
{ account_number: '3013', default_vat_rate: null },
|
||||
{ account_number: '3014', default_vat_rate: 0 },
|
||||
]
|
||||
seedLedger([
|
||||
{ account_number: '3013', debit_amount: 0, credit_amount: 8000 },
|
||||
{ account_number: '3014', debit_amount: 0, credit_amount: 2000 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
expect(result.rutor.ruta05).toBe(0)
|
||||
})
|
||||
|
||||
it('adds the accounts to p_accounts but never to p_ruta_accounts', async () => {
|
||||
// p_ruta_accounts is the settlement SHAPE detector inside the RPC: an entry
|
||||
// touching it plus 2650/1650 is classified a momsredovisning and dropped
|
||||
// from the totals. A plain sale booked 1930 / 3013 / 2650 would then vanish
|
||||
// from its own declaration. This is invisible to an outcome assertion, so
|
||||
// assert the RPC arguments directly.
|
||||
chartAccounts = [{ account_number: '3013', default_vat_rate: 0.06 }]
|
||||
seedLedger([{ account_number: '3013', debit_amount: 0, credit_amount: 8000 }])
|
||||
|
||||
await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
|
||||
const [, args] = supabase.rpc.mock.calls[0]
|
||||
expect(args.p_accounts).toContain('3013')
|
||||
expect(args.p_ruta_accounts).not.toContain('3013')
|
||||
expect(args.p_ruta_accounts).toContain('3001') // static list still intact
|
||||
})
|
||||
|
||||
it('clears the blocking OUTPUT_VAT_WITHOUT_SALES finding (#1261)', async () => {
|
||||
// The reported symptom was not just an understated ruta 05: with ruta05 = 0
|
||||
// and output VAT on 2611, runVatDeclarationChecks failed the declaration
|
||||
// with a blocking ERROR and the user could not file at all.
|
||||
chartAccounts = [{ account_number: '3013', default_vat_rate: 0.06 }]
|
||||
seedLedger([
|
||||
{ account_number: '3013', debit_amount: 0, credit_amount: 8000 },
|
||||
{ account_number: '2631', debit_amount: 0, credit_amount: 480 },
|
||||
])
|
||||
|
||||
const result = await calculateVatDeclaration(supabase, 'company-1', 'monthly', 2024, 1)
|
||||
const findings = runVatDeclarationChecks(result.rutor)
|
||||
|
||||
expect(findings.map((f) => f.code)).not.toContain('OUTPUT_VAT_WITHOUT_SALES')
|
||||
expect(findings.map((f) => f.code)).not.toContain('SALES_OUTPUT_VAT_SHORTFALL')
|
||||
})
|
||||
})
|
||||
|
||||
describe('calculateVatDeclaration: annual VAT spans the räkenskapsår', () => {
|
||||
it('uses the fiscal period bounds for yearly when a fiscalPeriodId is given', async () => {
|
||||
// Förlängt räkenskapsår (extended first year, 18 months): annual VAT
|
||||
@@ -977,9 +1223,10 @@ describe('calculateVatDeclaration: annual VAT spans the räkenskapsår', () => {
|
||||
|
||||
expect(result.period.start).toBe('2026-03-01')
|
||||
expect(result.period.end).toBe('2026-03-31')
|
||||
// The räkenskapsår path is yearly-only: monthly makes no table query at
|
||||
// all, just the single totals RPC.
|
||||
expect(supabase.from).not.toHaveBeenCalled()
|
||||
// The räkenskapsår path is yearly-only: monthly never touches
|
||||
// fiscal_periods. (chart_of_accounts is read on every period type, for the
|
||||
// company's own ruta 05 accounts.)
|
||||
expect(supabase.from).not.toHaveBeenCalledWith('fiscal_periods')
|
||||
expect(supabase.rpc).toHaveBeenCalledTimes(1)
|
||||
})
|
||||
})
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { generateTrialBalance } from './trial-balance'
|
||||
import { findUntransferredResults, buildImbalanceDiagnosis } from './imbalance-diagnosis'
|
||||
import { getLatestPostedVouchers } from './latest-vouchers'
|
||||
import type {
|
||||
BalanceImbalanceDiagnosis,
|
||||
BalansrapportReport,
|
||||
BalansrapportRow,
|
||||
BalansrapportGroup,
|
||||
LatestVoucherPerSeries,
|
||||
} from '@/types'
|
||||
|
||||
const CLASS_LABELS: Record<number, string> = {
|
||||
@@ -115,6 +117,19 @@ export async function generateBalansrapport(
|
||||
}
|
||||
}
|
||||
|
||||
// Reconciliation aid for the header: which vouchers are actually in here.
|
||||
// The balansrapport accumulates from the fiscal year start, so the window has
|
||||
// no lower bound beyond fiscal_period_id even when the user narrows fromDate.
|
||||
// Best-effort: a header nicety never breaks the report.
|
||||
let latestVouchers: LatestVoucherPerSeries[] = []
|
||||
try {
|
||||
latestVouchers = await getLatestPostedVouchers(supabase, companyId, fiscalPeriodId, {
|
||||
toDate: effectiveToDate,
|
||||
})
|
||||
} catch {
|
||||
// Best-effort header line only.
|
||||
}
|
||||
|
||||
return {
|
||||
groups,
|
||||
total_assets_ub: totalAssetsUb,
|
||||
@@ -123,6 +138,7 @@ export async function generateBalansrapport(
|
||||
is_balanced: trialBalance.isBalanced,
|
||||
period: { start: effectiveFromDate, end: effectiveToDate },
|
||||
...(imbalanceDiagnosis ? { imbalance_diagnosis: imbalanceDiagnosis } : {}),
|
||||
...(latestVouchers.length > 0 ? { latest_vouchers: latestVouchers } : {}),
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
import type { LatestVoucherPerSeries } from '@/types'
|
||||
|
||||
/**
|
||||
* Rendering half of the "senaste bokförda verifikat" header line (#1267).
|
||||
*
|
||||
* Kept dependency-free and separate from `latest-vouchers.ts` so the client
|
||||
* report views can import it without dragging the Supabase query path (and
|
||||
* through it the logger and observability sink) into the browser bundle.
|
||||
*/
|
||||
|
||||
/**
|
||||
* Swedish-only report surface (see .claude/rules/i18n.md).
|
||||
*
|
||||
* The wording is load-bearing: this is the last POSTED number, not the last
|
||||
* number the sequence counter handed out. A reconciler who assumes the other
|
||||
* one chases a gap that is not there.
|
||||
*/
|
||||
export const LATEST_VOUCHERS_LABEL = 'Senaste bokförda verifikat'
|
||||
|
||||
/**
|
||||
* Renders the header value, e.g. "A 214, B 37".
|
||||
*
|
||||
* Returns null when there is nothing to show, so every surface drops the line
|
||||
* entirely rather than printing an empty label.
|
||||
*/
|
||||
export function formatLatestVouchers(entries: LatestVoucherPerSeries[] | undefined): string | null {
|
||||
if (!entries || entries.length === 0) return null
|
||||
return entries.map((e) => `${e.series} ${e.last_number}`).join(', ')
|
||||
}
|
||||
@@ -0,0 +1,78 @@
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { fetchAllRows } from '@/lib/supabase/fetch-all'
|
||||
import type { LatestVoucherPerSeries } from '@/types'
|
||||
|
||||
/**
|
||||
* Statuses that count as "bokförd" for the purposes of this line.
|
||||
*
|
||||
* `reversed` is included deliberately: a stornerad verifikat keeps its number
|
||||
* and still occupies its slot in the series, so leaving it out would report a
|
||||
* gap that does not exist. Drafts and cancelled entries carry
|
||||
* `voucher_number = 0` and are excluded by the `> 0` filter instead.
|
||||
*/
|
||||
const POSTED_STATUSES = ['posted', 'reversed'] as const
|
||||
|
||||
interface VoucherRow {
|
||||
id: string
|
||||
voucher_series: string | null
|
||||
voucher_number: number
|
||||
}
|
||||
|
||||
/**
|
||||
* Highest POSTED voucher number per series within a reported window.
|
||||
*
|
||||
* Reads `journal_entries`, never `voucher_sequences`. The sequence table holds
|
||||
* an allocation high-water mark that drifts from reality in both directions:
|
||||
* `next_voucher_number` burns a number when the follow-up insert fails,
|
||||
* `delete_last_voucher` decrements blindly by one rather than resetting to the
|
||||
* new MAX, and pre-RPC SIE imports left it behind. Since the whole point of
|
||||
* this figure is reconciliation, only a number the user can actually look up in
|
||||
* the books is worth printing.
|
||||
*
|
||||
* The window is bounded below by `fiscalPeriodId` alone when `fromDate` is
|
||||
* omitted, which is what an accumulating report (balansrapport) wants.
|
||||
*/
|
||||
export async function getLatestPostedVouchers(
|
||||
supabase: SupabaseClient,
|
||||
companyId: string,
|
||||
fiscalPeriodId: string,
|
||||
window: { fromDate?: string; toDate: string }
|
||||
): Promise<LatestVoucherPerSeries[]> {
|
||||
const rows = await fetchAllRows<VoucherRow>(
|
||||
({ from, to }) => {
|
||||
let query = supabase
|
||||
.from('journal_entries')
|
||||
.select('id, voucher_series, voucher_number')
|
||||
.eq('company_id', companyId)
|
||||
.eq('fiscal_period_id', fiscalPeriodId)
|
||||
.in('status', POSTED_STATUSES)
|
||||
.gt('voucher_number', 0)
|
||||
.lte('entry_date', window.toDate)
|
||||
|
||||
if (window.fromDate) {
|
||||
query = query.gte('entry_date', window.fromDate)
|
||||
}
|
||||
|
||||
// Order on the PK: paging is only stable with a unique total order.
|
||||
return query.order('id', { ascending: true }).range(from, to)
|
||||
},
|
||||
{ dedupeBy: (r) => r.id }
|
||||
)
|
||||
|
||||
const maxBySeries = new Map<string, number>()
|
||||
for (const row of rows) {
|
||||
const series = row.voucher_series || 'A'
|
||||
const current = maxBySeries.get(series) ?? 0
|
||||
if (row.voucher_number > current) {
|
||||
maxBySeries.set(series, row.voucher_number)
|
||||
}
|
||||
}
|
||||
|
||||
return [...maxBySeries.entries()]
|
||||
.map(([series, last_number]) => ({ series, last_number }))
|
||||
.sort((a, b) => a.series.localeCompare(b.series, 'sv'))
|
||||
}
|
||||
|
||||
// Re-exported for convenience on server surfaces; the canonical home is the
|
||||
// dependency-free format module, which client components import directly.
|
||||
export { formatLatestVouchers, LATEST_VOUCHERS_LABEL } from './latest-vouchers-format'
|
||||
@@ -7,9 +7,11 @@ import {
|
||||
} from '@react-pdf/renderer'
|
||||
import type {
|
||||
CompanySettings,
|
||||
LatestVoucherPerSeries,
|
||||
ResultatrapportReport,
|
||||
BalansrapportReport,
|
||||
} from '@/types'
|
||||
import { formatLatestVouchers, LATEST_VOUCHERS_LABEL } from './latest-vouchers'
|
||||
|
||||
// Operational reports (Resultatrapport / Balansrapport) are löpande
|
||||
// bookkeeping documents, not draft årsredovisning per ÅRL 2:7 §, so this
|
||||
@@ -254,13 +256,16 @@ interface CommonHeaderProps {
|
||||
period: { start: string; end: string }
|
||||
/** Partial-view disclosure (dimension-filtered exports, BFNAR 2013:2). */
|
||||
filterNote?: string
|
||||
/** Highest posted voucher per series in the window. Reconciliation aid (#1267). */
|
||||
latestVouchers?: LatestVoucherPerSeries[]
|
||||
}
|
||||
|
||||
function HeaderBlock({ title, company, period, filterNote }: CommonHeaderProps) {
|
||||
function HeaderBlock({ title, company, period, filterNote, latestVouchers }: CommonHeaderProps) {
|
||||
const companyDisplayName = company.company_name || ''
|
||||
const periodLabel = period.start && period.end
|
||||
? `${formatDateSv(period.start)}: ${formatDateSv(period.end)}`
|
||||
: ''
|
||||
const vouchersLabel = formatLatestVouchers(latestVouchers)
|
||||
return (
|
||||
<View style={styles.header} fixed>
|
||||
<View style={styles.titleBlock}>
|
||||
@@ -271,6 +276,9 @@ function HeaderBlock({ title, company, period, filterNote }: CommonHeaderProps)
|
||||
{periodLabel && (
|
||||
<Text style={styles.period}>Period: {periodLabel}</Text>
|
||||
)}
|
||||
{vouchersLabel && (
|
||||
<Text style={styles.period}>{LATEST_VOUCHERS_LABEL}: {vouchersLabel}</Text>
|
||||
)}
|
||||
{filterNote && (
|
||||
<Text style={styles.period}>{filterNote}</Text>
|
||||
)}
|
||||
@@ -322,7 +330,13 @@ export function ResultatrapportPDF({ report, company, generatedAt, filterNote }:
|
||||
return (
|
||||
<Document>
|
||||
<Page size="A4" style={styles.page}>
|
||||
<HeaderBlock title="Resultatrapport" company={company} period={report.period} filterNote={filterNote} />
|
||||
<HeaderBlock
|
||||
title="Resultatrapport"
|
||||
company={company}
|
||||
period={report.period}
|
||||
filterNote={filterNote}
|
||||
latestVouchers={report.latest_vouchers}
|
||||
/>
|
||||
|
||||
<View style={styles.tableHeader}>
|
||||
<Text style={[styles.tableHeaderText, styles.colAccount]}>Konto</Text>
|
||||
@@ -391,7 +405,12 @@ export function BalansrapportPDF({ report, company, generatedAt }: Balansrapport
|
||||
return (
|
||||
<Document>
|
||||
<Page size="A4" style={styles.page}>
|
||||
<HeaderBlock title="Balansrapport" company={company} period={report.period} />
|
||||
<HeaderBlock
|
||||
title="Balansrapport"
|
||||
company={company}
|
||||
period={report.period}
|
||||
latestVouchers={report.latest_vouchers}
|
||||
/>
|
||||
|
||||
<View style={styles.tableHeader}>
|
||||
<Text style={[styles.tableHeaderText, styles.colAccount]}>Konto</Text>
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { generateTrialBalance } from './trial-balance'
|
||||
import { getLatestPostedVouchers } from './latest-vouchers'
|
||||
import type {
|
||||
LatestVoucherPerSeries,
|
||||
ResultatrapportReport,
|
||||
ResultatrapportRow,
|
||||
ResultatrapportGroup,
|
||||
@@ -157,12 +159,31 @@ export async function generateResultatrapport(
|
||||
const netResultCurrent = sumNet(currentRows)
|
||||
const netResultPrior = sumNet(priorRows)
|
||||
|
||||
// Reconciliation aid for the header: which vouchers are actually in here.
|
||||
// Scoped to the reported window, so a Q1 report says something true about Q1.
|
||||
// Dimension filter: skipped entirely. The report already discloses that it is
|
||||
// partial, and an unfiltered voucher range next to a filtered result invites
|
||||
// exactly the wrong conclusion during avstämning.
|
||||
// Best-effort: a header nicety never breaks the report.
|
||||
let latestVouchers: LatestVoucherPerSeries[] = []
|
||||
if (!options?.dimensions) {
|
||||
try {
|
||||
latestVouchers = await getLatestPostedVouchers(supabase, companyId, fiscalPeriodId, {
|
||||
fromDate: effectiveFromDate,
|
||||
toDate: effectiveToDate,
|
||||
})
|
||||
} catch {
|
||||
// Best-effort header line only.
|
||||
}
|
||||
}
|
||||
|
||||
return {
|
||||
groups,
|
||||
net_result_current: round2(netResultCurrent),
|
||||
net_result_prior: round2(netResultPrior),
|
||||
period: { start: effectiveFromDate, end: effectiveToDate },
|
||||
prior_period: priorPeriodInfo,
|
||||
...(latestVouchers.length > 0 ? { latest_vouchers: latestVouchers } : {}),
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -5,6 +5,7 @@ import type {
|
||||
VatPeriodType,
|
||||
} from '@/types'
|
||||
import type { VatCheckAccountTotals } from './vat-declaration-checks'
|
||||
import { fetchDynamicRuta05Accounts } from './vat-revenue-accounts'
|
||||
|
||||
/**
|
||||
* Calculate VAT declaration (Momsdeklaration) for a given period.
|
||||
@@ -33,7 +34,10 @@ import type { VatCheckAccountTotals } from './vat-declaration-checks'
|
||||
* Reverse charge output (2614/2624/2634) → ruta 30/31/32 (credit)
|
||||
* Import VAT (2615/2625/2635) → ruta 60/61/62 (credit)
|
||||
* Input VAT (2640-2649) → ruta 48 (debit), incl. parent 2640
|
||||
* Domestic taxable sales (3001-3003) → ruta 05 (credit)
|
||||
* Domestic taxable sales (3000-3003) → ruta 05 (credit)
|
||||
* The company's OWN class 3 accounts marked with a moms-sats join ruta 05 on
|
||||
* top of this fixed list: see fetchDynamicRuta05Accounts (#1261). This map
|
||||
* only covers the accounts Accounted itself seeds.
|
||||
* Uttag (3401-3403) → ruta 06 (credit)
|
||||
* EU goods (3108) → ruta 35; EU services (3308) → ruta 39 (credit)
|
||||
* Export (3105/3305) → ruta 36/40; Exempt (3004/3100/3404/3994/3980) → ruta 42 (credit)
|
||||
@@ -85,6 +89,7 @@ export const ACCOUNT_RUTA: Record<string, { box: keyof VatDeclarationRutor; side
|
||||
'2625': { box: 'ruta61', side: 'credit' }, // Import 12%
|
||||
'2635': { box: 'ruta62', side: 'credit' }, // Import 6%
|
||||
// Revenue: domestic taxable sales → ruta 05
|
||||
'3000': { box: 'ruta05', side: 'credit' }, // Försäljning inom Sverige (summary/parent)
|
||||
'3001': { box: 'ruta05', side: 'credit' },
|
||||
'3002': { box: 'ruta05', side: 'credit' },
|
||||
'3003': { box: 'ruta05', side: 'credit' },
|
||||
@@ -345,18 +350,28 @@ export async function fetchVatAccountTotals(
|
||||
supabase: SupabaseClient,
|
||||
companyId: string,
|
||||
start: string,
|
||||
end: string
|
||||
end: string,
|
||||
dynamicRuta05Accounts: string[] = []
|
||||
): Promise<VatAccountTotals> {
|
||||
// Aggregation, settlement-shape detection, and source_type counts all
|
||||
// happen in one SQL pass (get_vat_declaration_totals). The previous
|
||||
// implementation paged every entry + line for the period through PostgREST
|
||||
// and reduced in JS: dozens of round trips for a busy quarter. The account
|
||||
// lists are parameters so ACCOUNT_RUTA stays the single source of truth.
|
||||
//
|
||||
// The company's own ruta 05 accounts join p_accounts (they must be summed)
|
||||
// but deliberately NOT p_ruta_accounts. That second list is the settlement
|
||||
// SHAPE detector: an entry with a line on it plus a line on 2650/1650 is
|
||||
// classified a momsredovisning and dropped from the totals entirely. A plain
|
||||
// sale booked 1930 / 3013 / 2650 (a company clearing moms straight off the
|
||||
// revenue voucher) would then vanish from its own declaration. The fixed
|
||||
// ACCOUNT_RUTA list is what defines settlement shape; user accounts widen
|
||||
// what is measured, never what counts as a momsredovisning.
|
||||
const { data, error } = await supabase.rpc('get_vat_declaration_totals', {
|
||||
p_company_id: companyId,
|
||||
p_start: start,
|
||||
p_end: end,
|
||||
p_accounts: [...VAT_ACCOUNTS, ...VAT_SETTLEMENT_NET_ACCOUNTS],
|
||||
p_accounts: [...VAT_ACCOUNTS, ...VAT_SETTLEMENT_NET_ACCOUNTS, ...dynamicRuta05Accounts],
|
||||
p_ruta_accounts: VAT_ACCOUNTS,
|
||||
p_net_accounts: VAT_SETTLEMENT_NET_ACCOUNTS,
|
||||
})
|
||||
@@ -382,10 +397,16 @@ export async function fetchVatAccountTotals(
|
||||
|
||||
/**
|
||||
* Map aggregated per-account totals to the momsdeklaration boxes, including
|
||||
* the recomputed ruta 49 net (FK009). Pure projection over ACCOUNT_RUTA.
|
||||
* the recomputed ruta 49 net (FK009). Pure projection over ACCOUNT_RUTA plus
|
||||
* the company's own ruta 05 accounts (fetchDynamicRuta05Accounts).
|
||||
*
|
||||
* `dynamicRuta05Accounts` is optional so callers that only need the 26xx boxes
|
||||
* keep working untouched: ruta 05 is a beskattningsunderlag, not moms, so it
|
||||
* never reaches ruta 49 and the settlement proposal nets the same either way.
|
||||
*/
|
||||
export function rutorFromTotals(
|
||||
totals: Map<string, { debit: number; credit: number }>
|
||||
totals: Map<string, { debit: number; credit: number }>,
|
||||
dynamicRuta05Accounts: string[] = []
|
||||
): VatDeclarationRutor {
|
||||
const rutor: VatDeclarationRutor = {
|
||||
ruta05: 0, ruta06: 0, ruta07: 0, ruta08: 0,
|
||||
@@ -407,6 +428,14 @@ export function rutorFromTotals(
|
||||
rutor[mapping.box] = round(rutor[mapping.box] + balance)
|
||||
}
|
||||
|
||||
// The company's own momspliktiga intäktskonton. Always credit-side: these are
|
||||
// revenue accounts by construction (account_class 3).
|
||||
for (const account of dynamicRuta05Accounts) {
|
||||
const t = totals.get(account)
|
||||
if (!t) continue
|
||||
rutor.ruta05 = round(rutor.ruta05 + (t.credit - t.debit))
|
||||
}
|
||||
|
||||
// FK009: summaMoms = (10 + 11 + 12 + 30 + 31 + 32 + 60 + 61 + 62) - 48
|
||||
rutor.ruta49 = round(
|
||||
rutor.ruta10 + rutor.ruta11 + rutor.ruta12 +
|
||||
@@ -484,23 +513,59 @@ export async function calculateVatDeclaration(
|
||||
supabase, companyId, periodType, year, period, options.fiscalPeriodId
|
||||
)
|
||||
|
||||
// Which of the company's OWN class 3 accounts count as momspliktig
|
||||
// försäljning. Resolved from their "Standard moms" rather than a fixed BAS
|
||||
// list, because Accounted seeds no varugrupp accounts: every 3011/3013-style
|
||||
// konto is user-added and would otherwise never be fetched at all (#1261).
|
||||
const dynamicRuta05 = await fetchDynamicRuta05Accounts(supabase, companyId)
|
||||
|
||||
// Fetch and aggregate posted VAT-account activity for the period. The same
|
||||
// RPC round trip carries the per-source_type entry counts for the metadata.
|
||||
const { totals, sourceTypeCounts } = await fetchVatAccountTotals(supabase, companyId, start, end)
|
||||
const { totals, sourceTypeCounts } = await fetchVatAccountTotals(
|
||||
supabase, companyId, start, end, dynamicRuta05.accounts
|
||||
)
|
||||
|
||||
// Map account balances to momsdeklaration boxes
|
||||
const rutor = rutorFromTotals(totals)
|
||||
const rutor = rutorFromTotals(totals, dynamicRuta05.accounts)
|
||||
|
||||
// Compute per-rate base amounts from individual revenue accounts
|
||||
// Compute per-rate base amounts from individual revenue accounts. The
|
||||
// company's own accounts carry their rate on the konto itself, so they land
|
||||
// in the same three buckets: without that, a 3013 company would show a
|
||||
// ruta 05 base that none of base25/12/6 accounts for.
|
||||
//
|
||||
// These three are REPORTING metadata (breakdown.invoices), not check inputs:
|
||||
// vat-declaration-checks.ts derives its expected base from the output-VAT
|
||||
// rutor (ruta10/0.25 + ruta11/0.12 + ruta12/0.06) and never reads base25/12/6.
|
||||
// So an incomplete split understates nothing that gets filed; it only makes
|
||||
// the breakdown fail to add up to ruta 05.
|
||||
const revenueByRate = {
|
||||
base25: 0, // 3001
|
||||
base12: 0, // 3002
|
||||
base6: 0, // 3003
|
||||
}
|
||||
const RATE_BUCKET = { 0.25: 'base25', 0.12: 'base12', 0.06: 'base6' } as const
|
||||
for (const [account, rate] of [['3001', 'base25'], ['3002', 'base12'], ['3003', 'base6']] as const) {
|
||||
const t = totals.get(account)
|
||||
if (t) revenueByRate[rate] = round(t.credit - t.debit)
|
||||
}
|
||||
for (const [account, rate] of dynamicRuta05.rateByAccount) {
|
||||
const t = totals.get(account)
|
||||
if (!t) continue
|
||||
const bucket = RATE_BUCKET[rate as keyof typeof RATE_BUCKET]
|
||||
if (!bucket) continue
|
||||
revenueByRate[bucket] = round(revenueByRate[bucket] + (t.credit - t.debit))
|
||||
}
|
||||
// Accounts the static map ALREADY sums into ruta 05 (3000, the 30xx
|
||||
// gruppkonto) but whose rate only exists as the konto's "Standard moms".
|
||||
// Rate-only on purpose: their balance is in ruta 05 either way, so adding
|
||||
// them to dynamicRuta05.accounts would double the filed figure.
|
||||
for (const [account, rate] of dynamicRuta05.staticRateByAccount) {
|
||||
const t = totals.get(account)
|
||||
if (!t) continue
|
||||
const bucket = RATE_BUCKET[rate as keyof typeof RATE_BUCKET]
|
||||
if (!bucket) continue
|
||||
revenueByRate[bucket] = round(revenueByRate[bucket] + (t.credit - t.debit))
|
||||
}
|
||||
|
||||
// Entry counts by source type for metadata: aggregated by the RPC in the
|
||||
// same round trip as the totals (SQL GROUP BY, so a busy VAT period can
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
import type { SupabaseClient } from '@supabase/supabase-js'
|
||||
import { fetchAllRows } from '@/lib/supabase/fetch-all'
|
||||
import { ACCOUNT_TO_BOX } from '@/lib/vat/moms-box-mapping'
|
||||
|
||||
/**
|
||||
* Resolve which of a company's OWN revenue accounts belong in ruta 05
|
||||
* (momspliktig försäljning som inte ingår i någon annan ruta).
|
||||
*
|
||||
* ACCOUNT_RUTA is a fixed BAS whitelist and ruta 05 is literally 3001/3002/3003
|
||||
* there. That is only correct for a company that never touched its kontoplan:
|
||||
* the shipped BAS reference (lib/bookkeeping/bas-data/class-3-revenue.ts) has
|
||||
* no varugrupp accounts at all, so every 3011/3013/3041-style konto is added by
|
||||
* the user. Their revenue was not merely mapped to the wrong ruta, it was never
|
||||
* fetched from the ledger: ACCOUNT_RUTA's keys ARE the account filter passed to
|
||||
* get_vat_declaration_totals. Ruta 05 came out short and, because
|
||||
* runVatDeclarationChecks compares rutor 05-08 against 10-12, a perfectly
|
||||
* correct declaration got a blocking OUTPUT_VAT_WITHOUT_SALES error (#1261).
|
||||
*
|
||||
* The per-account "Standard moms" (chart_of_accounts.default_vat_rate) is the
|
||||
* resolver: a class 3 konto the user marked 25/12/6 % is by definition domestic
|
||||
* taxable sales, which is exactly what ruta 05 collects. The account dialogs
|
||||
* say so, since the field now carries declaration weight and not just line
|
||||
* prefill.
|
||||
*/
|
||||
|
||||
/**
|
||||
* Class 3 accounts that carry a moms-sats but belong in a DIFFERENT ruta, so
|
||||
* "has a rate" must not be read as "ruta 05". Per the SKV 4700 mapping in
|
||||
* .claude/skills/swedish-vat/references/vat-compliance-reference.md §7:
|
||||
*
|
||||
* 3211/3212/3220 → ruta 07 (vinstmarginalbeskattning)
|
||||
* 3231/3232/3233 → ruta 41 (försäljning där köparen är betalningsskyldig)
|
||||
* 3913 → ruta 08 (hyresinkomster, frivillig skattskyldighet)
|
||||
*
|
||||
* Rutor 07, 08 and 41 are not mappable yet (see the note in
|
||||
* vat-declaration-checks.ts). Until they are, these accounts stay out of the
|
||||
* declaration entirely: that understates one ruta, whereas sweeping them into
|
||||
* ruta 05 would file the amount in the wrong box.
|
||||
*/
|
||||
export const RUTA_05_EXCLUDED_ACCOUNTS = new Set([
|
||||
'3211', '3212', '3220',
|
||||
'3231', '3232', '3233',
|
||||
'3913',
|
||||
])
|
||||
|
||||
/** VAT rates that mark a konto as momspliktig försäljning. 0 and NULL do not. */
|
||||
const TAXABLE_RATES = [0.25, 0.12, 0.06]
|
||||
|
||||
/**
|
||||
* Ruta 05 accounts that ACCOUNT_TO_BOX already sums, but whose per-rate bucket
|
||||
* cannot be inferred from the account number.
|
||||
*
|
||||
* 3000 "Försäljning inom Sverige" is the BAS gruppkonto for the 30xx range. A
|
||||
* BAS-conformant company posts to 3001/3002/3003 and never to 3000, but a
|
||||
* company that does post to it has genuine domestic taxable sales, so ruta 05
|
||||
* stays the right box and the filed figure is already correct. What is missing
|
||||
* is only the rate split: unlike 3001/3002/3003 the number carries no sats, so
|
||||
* `breakdown.invoices.base25/12/6` would not add up to ruta 05.
|
||||
*
|
||||
* These accounts therefore contribute a RATE ONLY. Adding them to `accounts`
|
||||
* would double-count them, since ACCOUNT_TO_BOX already puts them in the sum.
|
||||
*/
|
||||
const RUTA_05_STATIC_RATE_ACCOUNTS = new Set(['3000'])
|
||||
|
||||
export interface DynamicRuta05Accounts {
|
||||
/** Accounts to add to the ledger fetch and to the ruta 05 sum. */
|
||||
accounts: string[]
|
||||
/** account_number → 0.25 | 0.12 | 0.06, for the per-rate base breakdown. */
|
||||
rateByAccount: Map<string, number>
|
||||
/**
|
||||
* Rates for accounts ALREADY counted in ruta 05 by the static map. Feeds the
|
||||
* base breakdown only, never the sum. Empty unless the user set a
|
||||
* "Standard moms" on one of RUTA_05_STATIC_RATE_ACCOUNTS.
|
||||
*/
|
||||
staticRateByAccount: Map<string, number>
|
||||
}
|
||||
|
||||
const EMPTY: DynamicRuta05Accounts = {
|
||||
accounts: [],
|
||||
rateByAccount: new Map(),
|
||||
staticRateByAccount: new Map(),
|
||||
}
|
||||
|
||||
/**
|
||||
* Fetch the company-specific ruta 05 accounts.
|
||||
*
|
||||
* Excluded:
|
||||
* - every account in ACCOUNT_TO_BOX. This covers all of ACCOUNT_RUTA (the
|
||||
* alignment test in lib/vat/__tests__/moms-box-mapping.test.ts fails if the
|
||||
* mirror ever stops being a superset) and additionally the accounts only
|
||||
* the mirror maps (3106, 3109, 3521, 3522). Filtering on the superset alone
|
||||
* keeps this module off vat-declaration.ts, which imports it.
|
||||
*
|
||||
* This exclusion is what makes the BAS backfill safe: it sets 3001 = 25 %,
|
||||
* and without it 3001 would be counted once by ACCOUNT_RUTA and once here,
|
||||
* doubling ruta 05.
|
||||
* - RUTA_05_EXCLUDED_ACCOUNTS above.
|
||||
*
|
||||
* The company_id filter is explicit rather than left to RLS:
|
||||
* calculateVatDeclaration is also reached from /api/v1/* on a service client,
|
||||
* which has no RLS.
|
||||
*/
|
||||
export async function fetchDynamicRuta05Accounts(
|
||||
supabase: SupabaseClient,
|
||||
companyId: string
|
||||
): Promise<DynamicRuta05Accounts> {
|
||||
const rows = await fetchAllRows<{ account_number: string; default_vat_rate: number | string | null }>(
|
||||
({ from, to }) =>
|
||||
supabase
|
||||
.from('chart_of_accounts')
|
||||
.select('account_number, default_vat_rate')
|
||||
.eq('company_id', companyId)
|
||||
.eq('account_class', 3)
|
||||
// Deactivated accounts only. is_active is nullable (boolean DEFAULT
|
||||
// true, never made NOT NULL) and the accounts API treats only an
|
||||
// explicit false as deactivated, so `eq(true)` would silently drop a
|
||||
// NULL-flagged konto: the same kind of quiet omission this whole fix
|
||||
// exists to remove.
|
||||
.not('is_active', 'is', false)
|
||||
.in('default_vat_rate', TAXABLE_RATES)
|
||||
.order('account_number', { ascending: true })
|
||||
.range(from, to)
|
||||
)
|
||||
|
||||
if (rows.length === 0) return EMPTY
|
||||
|
||||
const accounts: string[] = []
|
||||
const rateByAccount = new Map<string, number>()
|
||||
const staticRateByAccount = new Map<string, number>()
|
||||
for (const row of rows) {
|
||||
const account = row.account_number
|
||||
const rate = Number(row.default_vat_rate)
|
||||
if (!TAXABLE_RATES.includes(rate)) continue
|
||||
|
||||
// Checked before the ACCOUNT_TO_BOX skip: these accounts ARE in that map,
|
||||
// which is precisely why they need the rate surfaced separately.
|
||||
if (RUTA_05_STATIC_RATE_ACCOUNTS.has(account)) {
|
||||
staticRateByAccount.set(account, rate)
|
||||
continue
|
||||
}
|
||||
|
||||
if (ACCOUNT_TO_BOX[account]) continue
|
||||
if (RUTA_05_EXCLUDED_ACCOUNTS.has(account)) continue
|
||||
|
||||
accounts.push(account)
|
||||
rateByAccount.set(account, rate)
|
||||
}
|
||||
|
||||
return { accounts, rateByAccount, staticRateByAccount }
|
||||
}
|
||||
Reference in New Issue
Block a user