POSTKontrollér journal uden bogføring

Formål og præcis afgrænsning

Brug operationen før en planlagt bogføring for at opdage ugyldige input og ikke-tilladte referencer. Den kontrollerer det normaliserede journalinput, det aktuelle scope og de valgte kontoreferencer. Resultatet har altid posted: false.

Forberedelse reserverer ikke et bilagsnummer, låser ikke perioden og tildeler ikke et bogføringsmandat. Kundens adgang eller regnskabsperiode kan ændre sig efter kontrollen. Et senere POST /journal gennemfører derfor sine egne aktuelle kontroller; et tidligere gyldigt prepare-svar kan ikke bruges som en adgangsbillet.

Før kaldet

Vælg den eksplicit konfigurerede installation. HOURS_BASE er enten dens /api/partner/sandbox/v1 eller /api/partner/v1. Basisadressen vises i App Console for appen. Et sandboxtoken begynder med hsk_; et produktions-access-token begynder med hat_. De er ikke indbyrdes udskiftelige og er ikke Supabase-login-tokens.

Produktion kræver en godkendt apprevision, en kundegrant og de relevante scopes. Kundegrantet er givet af organisationsejeren med tofaktor (aal2), gælder de valgte konti og varer højst 90 dage. Endelig journalbogføring kræver et særskilt mandat. Sandbox kræver en klargjort appgeneration i et separat projekt. En gyldig tokenform alene er ikke adgang.

Input og grænser

Linjefelter

Hver linje har præcis én af debit_minor og credit_minor større end 0. Ukendte felter afvises. Hele body er højst 256 KiB, datoer skal være gyldige kalenderdatoer, og beløb er heltal i hele øre, højst 99 999 999 999 999 pr. linje. Valgfrie null-værdier og defaults normaliseres af serverens inputmodel. Organisation, aktør, intern kilde og bankkobling bestemmes ikke af payloaden.

Eksempel

Gem følgende syntetiske input som input.json. UUID'er erstattes med referencer fra den konkrete sandbox eller kundeautorisation; de må ikke genbruges mellem miljøer.

{
  "posting_date": "2026-09-30",
  "currency": "DKK",
  "description": "Syntetisk prøve",
  "lines": [
    {
      "account_id": "00000000-0000-4000-8000-000000000001",
      "debit_minor": 12500
    },
    {
      "account_id": "00000000-0000-4000-8000-000000000002",
      "credit_minor": 12500
    }
  ]
}

curl --silent --show-error --fail-with-body \
  --request POST "$HOURS_BASE/journal/prepare" \
  --header "Authorization: Bearer $HOURS_TOKEN" \
  --header "Content-Type: application/json" \
  --data-binary @input.json

Succes og output

Forvent HTTP 200 ved succes:

{
  "valid": true,
  "posted": false,
  "checked": [
    "input",
    "grant",
    "references"
  ],
  "not_checked": [
    "commit_time_period_locks",
    "accounting_transaction"
  ]
}

Svaret skal fortolkes som den beskrevne projektion. Det giver ikke ekstra rettigheder eller en komplet kopi af den interne model. Bevar især forskellen på lokal inputkontrol, kvittering og aktuel regnskabstilstand.

Fejl og genforsøg

Manglende eller forkert miljøtoken afvises. Manglende scope, tilbagekaldt grant eller ændret apprevision stopper kaldet. Input, der afvises før regnskabskernen (invalid_input, invalid_amount, journal_unbalanced og reference_not_allowed), gemmer ingen kvittering. Reference- og domænefejl skal afklares i stedet for at blive omskrevet til tilfældige gyldige værdier.

Ved midlertidig transportfejl kan det samme læse- eller prepare-kald forsøges igen under aktuel adgang. Et rettighedsstop er ikke et tomt datasæt. Et prepare-resultat reserverer ikke en fremtidig commit.

Hvad et grønt svar ikke betyder

Forbereder du et input med en aktiv konto og derefter lukker perioden, før det endelige skrivekald gennemføres, afvises det endelige kald stadig af regnskabskernen. Det viser forskellen mellem en vejledende kontrol og en transaktion på det tidspunkt, hvor data faktisk bogføres.

En balanceret postering med et fremmed konto-id er heller ikke gyldig. Balance alene er ikke gyldighed: regnskabet skal tilhøre den rigtige organisation, og kontiene skal ligge inden for det tilladte sæt. Fejlsvaret udleverer ikke den fremmede kontos navn eller ejerskab.

Der gemmes ikke en operationskvittering for prepare på samme måde som for et endeligt skrivekald. Klienten må derfor ikke vente på en operation.completed-webhook eller kalde kvitteringsopslaget med et opdigtet operations-ID efter en forberedelse.

Test din integration

Test korrekt kontekst, manglende scope, forkert miljø og fremmede referencer. Kontrollér eksplicit, at svaret har posted: false.

Se rettigheder, fejl og idempotens.