Hopp til innhold

Hvordan integrerer regnskaps- og bokføringsplattformer med Altinn og norske offentlige registre?

Med én integrasjon og mange delegeringer. Plattformen har én legitimasjonskjede og ett klientbibliotek; hvert klientselskap gir hver for seg det registrerte systemet rett til å opptre på sine vegne. Derfra er sløyfen per klient de samme tre kallene: sjekk delegeringen, slå opp selskapets plikter og frister, og send inn gjennom Altinn når tiden kommer. Utviklingsarbeidet skalerer med hvor mange registre du berører. Det operative arbeidet skalerer med kundemassen din.

Plattformen din, beskrevet som én integrasjon og én nøkkel, kobles til Apier, beskrevet som én legitimasjonskjede. Derfra vifter en delt linje ut til tre bokser med klientselskaper, som hver gir sin egen delegering. En merknad under sier: og én til for hver kunde du tar inn.Plattformen dinén integrasjon, én nøkkelApierén legitimasjonskjedeKlientselskapgir sin egen delegeringKlientselskapgir sin egen delegeringKlientselskapgir sin egen delegeringog én til for hver kunde du tar inn
Venstre halvdel bygges én gang. Høyre halvdel gjentas per kunde, og det er derfor delegeringsflyten fortjener like mye produktoppmerksomhet som selve integrasjonen.

Hvordan håndterer jeg hundrevis av klientdelegeringer?

Se delegeringsstatus som noe du leser, ikke noe du lagrer. Fristelsen i stor skala er å mellomlagre et tilkoblet-flagg per klient og stole på det, fordi det føles dyrt å sjekke ved hver handling. Flagget kommer til å være galt. Klienter snevrer inn og trekker tilbake tilgang uten å si fra til programvareleverandøren sin, som regel som en bivirkning av opprydding framfor som en beslutning om deg, og mellomlageret ditt har ingen måte å få vite det på.

Myndighetssjekken er laget for nettopp dette. Den svarer HTTP 200 med en avgjørelse på full, partial eller none for én organisasjon, sammen med hvilke scopes som er aktive, hvilke som mangler, og tiltak skrevet på norsk for å vises til klienten. Fordi en ennå ikke autorisert tilstand er et vanlig svar framfor en feil, kan du forgrene på den i vanlig produktkode i stedet for å tolke feil.

I stor skala er den nyttige utformingen en status per klient som du oppdaterer etter en plan og sjekker på nytt før enhver handling som avhenger av den. Vis tiltakene i ditt eget grensesnitt framfor en generisk melding om at noe er frakoblet: klienten kan som regel ordne det selv på noen minutter hvis du sier hva de skal trykke på, og en supporthenvendelse koster begge parter mer enn det.

Hvordan viser jeg hver klients frister i mitt eget produkt?

Spør fristendepunktet per selskap med en from_date og et horizon_months, én gang per klient etter en plan, og vis det som kommer tilbake. En horisont på tolv måneder oppdatert hver natt er som regel riktig form: det er nok til å drive en kalendervisning og en varslingskø, og det er billig nok til å kjøre over en stor portefølje uten spesialhåndtering.

Les adjusted_from før du viser noe. Er den ikke null, flyttet den lovbestemte datoen seg fordi den falt på en helg eller en norsk helligdag, og å vise begge datoene hindrer samtalen der en regnskapsfører som kan regelen er sikker på at produktet ditt tar feil. Svaret bærer også hvilke organisasjonsformer hver oppføring gjelder for, så det å filtrere til det en gitt klient faktisk skylder er en feltsammenligning framfor logikk du vedlikeholder.

For det bredere bildet av hvordan dette passer en regnskapsplattform spesielt, inkludert hvor arbeidet per klient hører hjemme i en innrulleringsflyt, se bruksområdet for regnskapsprogramvare.

Hva endrer seg når en klients registerdata endrer seg?

Pliktsettet deres kan endre seg med det, og det er den delen som lurer plattformer. Et selskap som registrerer seg for merverdiavgift får merverdiavgiftsrapportering fra det tidspunktet. Et bytte av organisasjonsform endrer hvilke årlige innsendinger som gjelder. Et selskap som går under avvikling endrer hva som forventes av det. Ingenting av dette kommer som en melding fra klienten; det kommer som en forskjell i registeret som produktet ditt ikke har noen grunn til å legge merke til.

Følg derfor endringsarkivet framfor å evaluere alt på en timer. Det returnerer oppdagede endringer filtrerbart på kilde, enhet og dato, og hver rad bærer feltstien som flyttet seg sammen med verdiene før og etter, slik at du kan evaluere de navngitte klientene på nytt og la resten være. På Professional-nivået kan de samme endringene leveres som signerte webhooks hvis polling passer dårlig for arkitekturen din.

Én vane er verdt å bygge inn fra starten. Lagre regelversjonen og korrelasjons-IDen fra enhver evaluering du viser en klient. Når noen om åtte måneder spør hvorfor plattformen sa at en frist var på en bestemt dato, gjør de to feltene svaret om fra en rekonstruksjon til et oppslag.

Gjør det første kallet

Sandkassekallet viser fristformen per klient før du har tatt inn noen. TypeScript-utdraget er myndighetssjekken per klient, skrevet som den grenen den bør være framfor som en feilsti.

# Nøkkelløs sandkasse: formen per klient, før noen er tatt inn.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/deadlines
// Myndighetssjekk per klient. Alltid HTTP 200.
async function clientState(orgNumber: string) {
  const res = await fetch(
    `https://www.apier.no/api/v1/auth/permissions/${orgNumber}`,
    { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
  );

  const { data } = await res.json();
  // "full" | "partial" | "none". En produkttilstand, ikke en feil.
  return { status: data.status, fixSteps: data.fix_steps };
}

Ofte stilte spørsmål

Trenger jeg én integrasjon per klientselskap?
Nei. Du bygger én integrasjon og har én legitimasjonskjede. Det som gjentas per klient er delegeringen: hvert selskap gir det registrerte systemet ditt tilgang til å opptre på sine vegne. Utviklingsarbeidet er dermed avgrenset av hvor mange registre du berører, mens det operative arbeidet skalerer med kundemassen din.
Hvordan følger jeg delegeringsstatus for hundrevis av klienter?
Spør framfor å lagre. GET /api/v1/auth/permissions/{org} svarer HTTP 200 med en avgjørelse på full, partial eller none for én organisasjon, pluss hvilke scopes som mangler og norske fix_steps du kan sette rett foran klienten. Å lagre et tilkoblet-flagg i din egen database er en påstand om fortiden, og den blir gal første gang en klient rydder i tilgangslisten sin.
Kan jeg se hvilke av mine egne principals som har myndighet?
Ja. Fullmakt-endepunktet svarer, for én kundeorganisasjon, hvilke av dine egne agent-principals som akkurat nå har delegert myndighet, hvilke scopes som er aktive og hvilke som mangler i forhold til nivået ditt. Det er lesesiden av forespørselsflyten, og det er riktig kall å gjøre før en agent forsøker en handling framfor etter at den feiler.
Hvordan viser jeg hver klients frister i mitt eget grensesnitt?
Spør fristendepunktet per selskap med en fra-dato og en horisont i måneder, én gang per klient etter en plan, og vis resultatet. Les adjusted_from før du viser en dato: er den ikke null, flyttet den lovbestemte datoen seg for en helg eller en helligdag, og å vise begge hindrer supporthenvendelsen der en klient er sikker på at datoen din er gal.
Hva skjer når en klients registerdata endrer seg?
Pliktsettet deres kan endre seg med det. Et selskap som registrerer seg for merverdiavgift får merverdiavgiftsrapportering; et bytte av organisasjonsform endrer hva som gjelder. Poll endringsarkivet for kildene og enhetene du bryr deg om, eller abonner på webhook-leveranser på Professional-nivået, og evaluer klientene det nevner på nytt framfor å gå gjennom hele porteføljen på en timer.