Gå til innhold

Initialisere bankkonto

Før en bankkonto kan avstemmes må den initialiseres: du oppgir hvilken dato kontoen er avstemt til og med, og bank- og regnskapssaldoen slik de er per den datoen. Uten dette har ikke bankavstemmingen noe utgangspunkt å måle differansen mot — importen vet ikke hvor det ordinære vinduet begynner, og arbeidsbenken vet ikke hva "i balanse" betyr.

Tilgang

Hvem Hva trengs
Modul Bankavstemming (moduleId: 42)
Rutevakt ActivateService + ModuleGuard på /bank-reconciliation/accounts (bank-reconciliation-routing.module.ts:23)
Tilleggsrettighet wv_BankAccountAccess styrer hvilke bankkontoer en bruker ser i kontolisten
Endepunkt POST /api/BankReconciliation/InitializeAccount (BankReconciliationController.cs:265-266)

Hva "avstemt til og med" betyr

Feltet ReconciliationStartDate på wv_BankAccount styrer hvor det ordinære avstemmingsvinduet begynner. Betydningen er entydig fastsatt (eierbeslutning 2026-08-03, Jarle Ljosnes — "konvensjon B" i BRQ-32-planen):

  • Datoen du skriver inn ER avstemt. Den regnes ikke som en "startdato" for noe nytt — den er den siste dagen som allerede er ferdig avstemt.
  • Åpningssaldoen er saldoen PÅ denne datoen — ikke dagen før. Både OpeningBankBalance og OpeningLedgerBalance skal være saldoen ved dagens slutt på cutoff-datoen (BankReconciliationRepository.cs:393-417, OpeningBalanceDate settes direkte lik ReconciliationStartDate på linje 395).
  • Det ordinære vinduet åpner dagen ETTER cutoff. Import, matching, arbeidsflatens datofelt og saldoberegningen krever alle en dato strengt etter cutoff for at en rad skal telle som "ny" — men håndhevet av ulike mekanismer per overflate, ikke én delt hjelper: importens post-fetch-dropfiltre bruker ReconciliationWindow.IsInsideWindow (ReconciliationWindow.cs:27-34), matching/lister/saldoberegning avgjøres SQL-side av ReconciliationBalanceSql.InWindow/InBalance (ReconciliationBalanceSql.cs:291-300), og arbeidsflatens datofelt (Fra-dato og ERP-import-modalens minimumsdato) regnes ut i ren TypeScript i frontend uten noen delt hjelper (bank-reconciliation-workspace.component.ts:486-1045). En rad datert nøyaktig PÅ cutoff-datoen regnes IKKE som ny — den er allerede dekket av åpningssaldoen.

Feltnavn i skjemaet: Feltet heter "Avstemt til og med" i grensesnittet (no.json, nøkkel BankReconciliation.startDate), per eierbeslutningen 2026-08-03 og BRQ-32-planen §7. Åpningssaldofeltene heter tilsvarende "Banksaldo per avstemt-dato" (openingBankBalance) og "Regnskapssaldo per avstemt-dato" (openingLedgerBalance).

Eksempel: skal du avstemme april

Skal du starte avstemming av april måned, skriver du 31.03 i datofeltet — ikke 01.04.

    1. mars er den siste dagen som regnes som ferdig avstemt fra før.
  • Åpningssaldoen du oppgir er bank- og regnskapssaldoen slik den var ved utgangen av 31. mars.
  • April sine transaksjoner (fra og med 01.04) faller innenfor det ordinære avstemmingsvinduet, og importeres/matches som normalt.

Tommelfingerregel: datoen du skriver inn er alltid den siste dagen i forrige periode, ikke den første dagen i perioden du skal avstemme.

Slik initialiserer du en konto

  1. Gå til Bankavstemming → Kontoer (/bank-reconciliation/accounts).
  2. Finn kontoen og klikk Initialiser (eller Endre initialisering for en konto som allerede er initialisert).
  3. Fyll ut Avstemt til og med — bank-account-list.component.html:519.
  4. Klikk Hent saldi for å hente bank- og regnskapssaldo automatisk fra ERP-integrasjonen per den valgte datoen, eller fyll dem inn manuelt i Banksaldo per avstemt-dato / Regnskapssaldo per avstemt-dato.
  5. Har kontoen utestående poster per cutoff-datoen (og tidligere) som ennå ikke er avstemt (f.eks. en sjekk som ikke er inkassert): legg dem til under Åpneposter — se kontrakten under. En åpnepost kan dateres helt fram til og med cutoff-datoen, ikke bare strengt før den.
  6. Lagre. InitializeAccountAsync skriver ReconciliationStartDate, OpeningBankBalance, OpeningLedgerBalance og OpeningBalanceDate i én transaksjon, og erstatter tidligere lagrede åpneposter for kontoen (unngår duplikater ved re-initialisering).

Åpningspost-kontrakten

En åpnepost er en post som er utestående per cutoff-datoen — den ligger allerede i den ene siden sin saldo (bank eller regnskap), men er ikke matchet mot en motpost på den andre siden ennå. Typisk eksempel: en utbetaling bokført i regnskapet i mars, men som banken ikke har trukket ennå.

Sammenheng Åpnepost Hvorfor
Saldosummer (InBalance) Ekskludert Den lagrede åpningssaldoen dekker den allerede — å summe raden i tillegg ville dobbeltelle den
Lister, matching, auto-match-kandidater (InWindow) Inkludert Hele poenget med en åpnepost er at den skal kunne matches mot en motpost etter cutoff
Umatchet-antall, bro-visningens utestående poster Inkludert En umatchet åpnepost er nettopp det bro-visningen finnes for å vise
Fullførings-stempling Inkludert Ellers kan en matchet åpnepost aldri lukkes sammen med resten av perioden

Håndhevet av to enkeltrad-hjelpere med identisk logikk på SQL- og C#-siden: InWindow/InBalance (ReconciliationBalanceSql.cs:282-300) og ReconciliationWindow.IsInsideWindow (ReconciliationWindow.cs:27-34) — en åpnepost (SourceSystem = 'OpeningBalance') er aldri "innenfor vinduet" for saldosummen, uansett dato.

Re-initialisering av eksisterende kontoer

BRQ-32 rettet en tvetydighet i hvordan ReconciliationStartDate/OpeningBalanceDate ble tolket på tvers av import, lister og bro-beregningen (se docs/releasenotes/NEXT_RELEASE.md og datamodell-endringsloggen). Kontoer som ble initialisert før denne rettelsen kan ha data eller åpneposter satt under den gamle, tvetydige tolkningen. Administrator bør reinitialisere eksisterende kontoer (sette feltet «avstemt til og med» på nytt, samme dato som før) etter denne utrullingen, slik at åpningssaldoer og -datoer reflekterer den korrigerte konvensjonen konsekvent.

Relaterte sider