Gå til innhold

Basisdata-synk

Basisdata-synk styrer hvordan ePortal henter og holder oppdatert grunndata fra eksterne kilder — typisk et regnskapssystem (PowerOffice Go, Visma, NXT, Trimble) eller en CRM-løsning. Innstillingene definerer hva som synkes, hvor ofte, hvilken vei dataene flyter, og hva som skal skje ved konflikt.

Tilgang

Hvem Hva trengs
Rolle som kan endre Administrator
Modul som kreves Portalinnstillinger (Settings) — moduleID 99
Effekt på hvem Alle moduler som leser kunde-, leverandør-, prosjekt- eller artikkelregisteret

Selve koblingen til det eksterne systemet (URL, API-nøkkel, autentisering) konfigureres under integrasjonsoppsett — disse innstillingene tar bare stilling til hvordan dataflyt etter etablert kobling skal håndteres.

Innstillinger

Innstilling Betydning Standard Konsekvens Tilgang
Aktiv synk Hovedbryter som skrur all basisdata-synk på eller av Av Når av: ingen data hentes eller skrives mot eksternt system Administrator
Synk-retning Innkommende (les), utgående (skriv) eller toveis Innkommende Bestemmer hvilken side som regnes som "sannhet" Administrator
Entitetsutvalg Hvilke registre som synkes (kunder, leverandører, prosjekt, artikler, ansatte) Tom Selektivt valg reduserer datavolum og risiko Administrator
Synk-frekvens Hvor ofte planlagt synk kjøres Hver time Hyppigere = ferskere data, men mer last på ekstern API Administrator
Initiell historisk synk Antall år tilbake første kjøring henter 2 år Bestemmer hvor mye eksisterende data som kommer inn ved oppstart Administrator
Konfliktshåndtering Hva som skjer når samme post er endret begge steder Ekstern vinner Bestemmer hvilken endring som overlever ved kollisjon Administrator
Sletteflyt Om sletting i ekstern kilde også skal slette i ePortal Marker som inaktiv Hard sletting er irreversibel — mykere alternativ anbefales Administrator
Feilrespons Hva som skjer ved synk-feil (stopp / fortsett / varsel) Fortsett + varsel Påvirker hvor synlig en feil blir for administrator Administrator

Detaljert beskrivelse per innstilling

Aktiv synk

Betydning. Hovedbryter for hele synkmekanikken. Sett til av når du midlertidig vil stoppe all dataflyt — typisk under feilsøking, ved migrering eller når eksternt system er nede.

Gyldige verdier. Av eller på.

Standardverdi. Av. Nye tenants leveres med synk slått av — administrator må aktivere når koblingen er testet.

Når trer endringen i kraft. Umiddelbart. Pågående kjøring fullføres, ingen nye startes.

Påvirker historiske data. Nei. Allerede synket data forblir uendret.

Konsekvens for andre moduler.

  • Kunde-/leverandør-/prosjektmoduler — viser data som var siste status før av.
  • Fakturering — fortsetter med eksisterende kunder; nye kunder i ekstern kilde kommer ikke inn.
  • Rapportering — risiko for "frosne" tall hvis synk er av lenge.

Avhengigheter. Krever at integrasjonskoblingen er konfigurert under integrasjonsoppsett.

Hvem kan endre. Administrator.

Synk-retning

Betydning. Bestemmer hvilken vei data flyter mellom ePortal og det eksterne systemet.

Gyldige verdier.

  • Innkommende — ePortal leser fra ekstern kilde; ePortal-endringer skrives ikke tilbake.
  • Utgående — ePortal skriver til ekstern kilde; eksterne endringer leses ikke inn.
  • Toveis — endringer går begge veier (krever god konfliktshåndtering).

Standardverdi. Innkommende. Tryggeste utgangspunkt — regnskapssystemet beholder rollen som "master".

Når trer endringen i kraft. Neste planlagte synk.

Påvirker historiske data. Endring fra Innkommende til Utgående eller Toveis aktiverer ikke retroaktiv skriving — kun nye endringer fra endringstidspunktet sendes ut.

Konsekvens for andre moduler.

  • Datakvalitet — toveis krever omforent definisjon av masterdata; ellers oppstår sirkulær overskriving.
  • Tilgangskontroll — utgående/toveis krever at API-nøkkelen mot ekstern kilde har skrivetilgang.
  • Audit — toveis logg vokser raskere; vurder oppbevaringspolicy.

Avhengigheter. Utgående og toveis krever at ekstern API støtter skriving for valgte entiteter.

Hvem kan endre. Administrator.

Entitetsutvalg

Betydning. Hvilke registre som faktisk synkes. Selektivt utvalg reduserer både datavolum, risiko og kompleksitet.

Gyldige verdier. En eller flere av:

  • Kunder — kunderegister (debitorer)
  • Leverandører — leverandørregister (kreditorer)
  • Prosjekt — prosjektregister
  • Artikler/varer — vareregister
  • Ansatte — ansattregister (krever særlig forsiktighet — overlapper med ePortal-bruker)

Standardverdi. Tom — administrator må aktivt velge.

Når trer endringen i kraft. Neste planlagte synk inkluderer kun valgte entiteter.

Påvirker historiske data. Avvelging av en entitet stopper videre synk, men sletter ikke allerede synket data.

Konsekvens for andre moduler.

  • Hver entitet påvirker den tilsvarende modulen direkte (f.eks. Kunder → CRM + Fakturering).
  • Ansatte-synk — kan kollidere med manuelt vedlikeholdte ePortal-brukere; les avhengighetene før aktivering.

Avhengigheter. Hver entitet må støttes av ekstern API.

Hvem kan endre. Administrator.

Synk-frekvens

Betydning. Hvor ofte planlagt synk kjøres. Lavere frekvens sparer API-kall mot ekstern kilde; høyere frekvens gir ferskere data.

Gyldige verdier.

  • Hvert 15. min — sjelden anbefalt, kun ved kritiske use cases
  • Hver time
  • Hver 4. time
  • Daglig (nattlig)
  • Manuell — kun ved knappetrykk

Standardverdi. Hver time.

Når trer endringen i kraft. Neste planlagte kjøring.

Påvirker historiske data. Nei.

Konsekvens for andre moduler.

  • API-rate limits — hyppige kjøringer kan overskride leverandørens grenser og blokkere all annen integrasjon mot samme konto.
  • Cache-friskhet — for sjeldne kjøringer gir utdaterte data i moduler som ikke har lokal endring-logikk.

Avhengigheter. Krever at bakgrunnstjenesten kjører kontinuerlig.

Hvem kan endre. Administrator.

Initiell historisk synk

Betydning. Hvor langt tilbake i tid første kjøring henter eksisterende data. Senere kjøringer henter kun endringer siden forrige vellykkede kjøring.

Gyldige verdier. 0 (kun nye fremover), 1 år, 2 år, 5 år, alt.

Standardverdi. 2 år.

Når trer endringen i kraft. Første kjøring etter aktivering.

Påvirker historiske data. Stor initiell synk kan ta timer og belaste ekstern API betraktelig. Planlegg utenom kontortid.

Konsekvens for andre moduler.

  • Database-størrelse — full historikk øker volumet vesentlig.
  • Rapporter — full historikk gir bedre tidsserier, men kan inkludere foreldede / inaktive poster.

Avhengigheter. Krever at ekstern API tillater å hente eldre data uten ytterligere konfigurasjon.

Hvem kan endre. Administrator.

Konfliktshåndtering

Betydning. Hva som skjer når samme post er endret på begge sider siden forrige synk — typisk relevant ved toveis synk.

Gyldige verdier.

  • Ekstern vinner — eksterne endringer overskriver lokale.
  • Lokal vinner — lokale endringer overskriver eksterne.
  • Sist oppdatert vinner — basert på tidsstempel.
  • Pause til manuell beslutning — konflikten flagges og må løses i UI.

Standardverdi. Ekstern vinner. Regnskapssystemet er master.

Når trer endringen i kraft. Neste kjøring der konflikt oppdages.

Påvirker historiske data. Nei. Allerede løste konflikter er endelige.

Konsekvens for andre moduler.

  • Datakvalitet — feil valg gir tap av endringer brukere har gjort i godt minne.
  • Audit-logg — "pause til manuell" gir best sporbarhet; "sist oppdatert vinner" mister informasjon ved klokke-skjev.

Avhengigheter. "Sist oppdatert vinner" krever pålitelig tidsstempel fra ekstern API.

Hvem kan endre. Administrator.

Sletteflyt

Betydning. Hvordan sletting i ekstern kilde reflekteres i ePortal.

Gyldige verdier.

  • Ignorer — sletting i ekstern kilde ignoreres; poster blir værende i ePortal.
  • Marker som inaktiv — poster settes som inaktive men beholdes med all historikk.
  • Hard slett — poster slettes også i ePortal (irreversibelt).

Standardverdi. Marker som inaktiv.

Når trer endringen i kraft. Neste kjøring som oppdager sletting.

Påvirker historiske data. Hard slett vil prosessere historiske slettinger ved neste full-synk — vurder nøye.

Konsekvens for andre moduler.

  • Fakturering — historiske fakturaer mot slettet kunde må fortsatt vises; hard slett bryter dette.
  • Rapporter — referanseintegritet kan brytes; bruk "Marker som inaktiv" i de fleste tilfeller.

Avhengigheter. Krever at ekstern API rapporterer sletting (ikke alle gjør det).

Hvem kan endre. Administrator.

Feilrespons

Betydning. Hva som skjer når en synk-kjøring feiler — helt eller delvis.

Gyldige verdier.

  • Stopp — kjøringen avbrytes ved første feil; ingen flere poster prosesseres før manuell intervensjon.
  • Fortsett + varsel — kjøringen fortsetter, men administrator varsles via e-post + i varslingslogg.
  • Stille fortsett — ingen varsling; kun logging i synk-historikk.

Standardverdi. Fortsett + varsel.

Når trer endringen i kraft. Neste kjøring.

Påvirker historiske data. Nei.

Konsekvens for andre moduler.

  • Driftssikkerhet — "Stille fortsett" gjør feil usynlige før de er kritiske.
  • Administrator-varsling — "Fortsett + varsel" kan generere mye støy ved sporadiske feil; juster tærskel om mulig.

Avhengigheter. Varsling forutsetter at varslingssystemet er konfigurert.

Hvem kan endre. Administrator.

Slik aktiverer du basisdata-synk

  1. Sørg for at integrasjonskoblingen er testet og fungerer (separat oppsett).
  2. Åpne Innstillinger → Grunndata → Basisdata-synk.
  3. Velg Entitetsutvalg — start med kun Kunder og Prosjekt for å begrense omfang.
  4. Sett Synk-retning til Innkommende for første aktivering.
  5. Sett Initiell historisk synk til ønsket periode.
  6. La Synk-frekvens stå på Hver time.
  7. Skru på Aktiv synk og klikk Lagre.
  8. Følg første kjøring i synk-historikken — verifiser antall importerte poster mot ekstern kilde.

Vanlige problemer

Første synk tar veldig lang tid

Stor Initiell historisk synk + mange entiteter = mange API-kall. Sjekk synk-historikken for progresjon; avbryt og reduser scope hvis det stopper.

Kunder dukker ikke opp i ePortal

Sjekk: (1) Kunder er valgt i Entitetsutvalg, (2) feilrespons-loggen viser ikke autorisasjonsfeil, (3) eksterne kunder har gyldige obligatoriske felt — manglende felt kan gi avvist post.

Endringer i ePortal kommer ikke tilbake til regnskapssystemet

Synk-retning står på Innkommende. Endre til Utgående eller Toveis (med konfliktshåndtering forstått).

Inaktiv kunde-post dukker opp igjen ved neste synk

Kilden har posten som aktiv. Slett eller deaktiver i kilden, eller bytt Sletteflyt til Ignorer og håndter inaktivering manuelt i ePortal.

Synk-feil gjentar seg uten å bli rapportert

Feilrespons står på Stille fortsett. Bytt til Fortsett + varsel for å få e-postvarsel ved feil.

Datavolumet stiger raskt etter aktivering

Forventet ved Initiell historisk synk over 1 år. Sjekk database-vekst etter første uke; vurder kortere historikk hvis volumet er kritisk.

Konsekvensanalyse før endring

Før du aktiverer eller endrer basisdata-synk, vurder:

  • [ ] Er integrasjonskoblingen testet? Synk uten gyldig kobling feiler umiddelbart.
  • [ ] Hvor mange poster forventer du å importere? Sjekk i ekstern kilde først.
  • [ ] Er det pågående manuelt vedlikehold av samme register? Synk kan overskrive lokale endringer.
  • [ ] Trenger du toveis-synk? Begynn med Innkommende og oppgrader senere — toveis er vanskeligere å reversere.
  • [ ] Er fakturering eller andre kritiske flyter avhengige av disse dataene? Aktiver utenom kontortid.
  • [ ] Hvem skal varsles ved feil? Verifiser e-postoppsett før aktivering.

Relaterte sider