Kontoplan behavior
Documented against app commit ed7d6935. The same text lives in docs/agent/kontoplan.md in the app repo.
Kontoplan
Section titled “Kontoplan”The chart of accounts for the active company. Posting lines store kontoplan_id. A number such as 4200 is looked up again per year, so the same number can be a different row next year.
Middleware: auth.check, module:kontoplan, account. The list is not year-scoped by middleware. Year is chosen on the row and when generating a year.
Screens
Section titled “Screens”| Path | View | What it is |
|---|---|---|
GET /kontoplans | resources/views/pages/kontoplans/index.blade.php | The chart. Create and edit are modals. |
GET /kontoplans/import and POST /kontoplans/import | resources/views/pages/imports/kontoplans/index.blade.php | CSV preview. |
List regions: number, name, type, momskode, year, and the generate-year action. Import regions: file, preview, save.
Off-screen
Section titled “Off-screen”POST /kontoplans (KontoplanController@store) inserts one row for the company: number, name, type, class, and optional momskode. POST /kontoplans/update changes those fields. Existing bogføring lines keep the old kontoplan_id. Renaming a row changes the label the lists show. Changing the number does not rewrite posted lines.
POST /kontoplans/generate (addAndSetYear) copies the chart into another year. Posting and faktura-scan resolve a modkonto number against the year of the invoice date. Generating the year is what makes that lookup succeed.
POST /kontoplans/import/save (Imports\KontoplanController@save) writes the previewed CSV rows. GET/POST /kontoplans/import only parses and shows them. Import does not create bogføringer.
Commented helpers getKontoplansByYear, getExistingYears, and checkKontoplanYear are not called. Do not build a new screen on them. The live lookup is the company’s active kontoplan set for the selected year, built in CoreController and KontoplanService::getKontoplanMap.
Momskoder linked from a konto are docs/agent/rules.md. The momskode’s own konto numbers are how BogforingTransactionService finds the type 3 and type 4 lines.