Anskaffelse av Gebyrhåndteringssystem

Tønsberg kommune skal anskaffe et gebyrhåndteringssystem som leveres som løpende SaaS (multitenant) med integrasjoner og tilhørende etablering/implementering. Opsjon for håndtering av festeavgifter/leiekontrakter ønskes som del av leveransen. Kontraktsperiode er 8 år fra leveringsdag. Leverandør skal levere implementasjon, opplæring, systemdokumentasjon og drift/vedlikehold i avtaleperioden, samt oppfylle funksjonelle, tekniske og tjenestenivåkrav (SLA) knyttet til tilgjengelighet, responstid og løsningstid.

• Leverandør skal ikke ha restanser på skatter og avgifter (skatteattest for skatt og merverdiavgift ikke eldre enn 6 måneder).

  Dokumentasjon: Skatteattest (RF-1316) for skatt og merverdiavgift; evt. bekreftelse for norske leverandører som ikke er merverdipliktige.

  Kilde: Konkurransegrunnlag pkt. 4.2 (Obligatoriske og ufravikelige krav)
• Leverandør skal ha HMS-system for ivaretakelse av helse, miljø og sikkerhet i henhold til internkontrollforskriften.

  Dokumentasjon: HMS-egenerklæring, jf. vedlegg 5 (jf. tekst).

  Kilde: Konkurransegrunnlag pkt. 4.2 (Obligatoriske og ufravikelige krav)
• Leverandør skal være et lovlig etablert foretak/stiftelse/organisasjon.

  Dokumentasjon: Firmaattest (norske foretak) ikke eldre enn 6 måneder; bekreftelse for registrering i foretaks-/bransjeregister (utenlandske foretak).

  Kilde: Konkurransegrunnlag pkt. 4.2 (Organisatorisk og juridisk stilling)
• Leverandør skal ikke være rettskraftig dømt for deltakelse i kriminell organisasjon eller for korrupsjon/bedrageri/hvitvasking de siste 5 år.

  Dokumentasjon: Vandel-egenerklæring, jf. vedlegg 6.

  Kilde: Konkurransegrunnlag pkt. 4.2 (Organisatorisk og juridisk stilling)
• Leverandør skal ha økonomisk evne til å gjennomføre oppdraget/kontrakten.

  Dokumentasjon: Foretakets 3 siste årsregnskap inkl. styrets årsberetning og revisorerklæring samt nyere opplysninger relevant for regnskapstall; evt. stiftelsesdokument med åpningsbalanse for nystartet selskap; kredittrating kan legges ved.

  Kilde: Konkurransegrunnlag pkt. 4.3 (Økonomisk og finansiell stilling, kapasitet m.v.)
• Leverandør skal sikre at egne og underleverandørers arbeidstakere har tariffmessige lønns- og arbeidsvilkår.

  Dokumentasjon: Egenerklæring om at arbeidstakere er sikret tariffmessige lønns- og arbeidsvilkår, jf. vedlegg 6.

  Kilde: Konkurransegrunnlag pkt. 4.4 (Krav til lønns- og arbeidsvilkår)
• Leverandør må opplyse om erfaring fra tilsvarende leveranser.

  Dokumentasjon: Oversikt over de 3 viktigste leveranser/utførte tjenester siste årene: verdi, tidspunkt, leveransens innhold og navn på offentlig/privat oppdragsgiver.

  Kilde: Konkurransegrunnlag pkt. 4.5 (Tekniske og faglige kvalifikasjoner)
• Leverandør må ha godt og velfungerende kvalitetssikringssystem for ytelsene som skal leveres.

  Dokumentasjon: Kort og oversiktlig beskrivelse av leverandørens systemer for å sikre leveransens kvalitet.

  Kilde: Konkurransegrunnlag pkt. 4.5 (Tekniske og faglige kvalifikasjoner)

• Tilbudet skal leveres elektronisk i Mercell MSS og signeres med digital signatur.Kilde: Konkurransegrunnlag pkt. 2.6-2.7 (Innleveringssted og –form) / Tilbudets utforming og levering
• Tilbudet skal utarbeides i tråd med konkurransedokumentene; det er ikke adgang til å gi tilbud på deler av oppdraget.Kilde: Konkurransegrunnlag pkt. 2.9.1-2.9.2 (Krav til tilbudets utforming / Tilbudet)
• Komplett besvarelse av tildelingskriteriene (jf. at manglende beskrivelser kan medføre avvisning).Kilde: Konkurransegrunnlag pkt. 2.9.2 (Komplett besvarelse av tildelingskriteriene)
• Tilbudet skal inneholde utfylte bilag som er leverandørens ansvar: Bilag 2 (fylles ut av Leverandøren), Bilag 3 (fylles ut), Bilag 4 (fylles ut), Bilag 5 (fylles ut), Bilag 6 (fylles ut), evt. Bilag 7 (hvis aktuelt) og Bilag 9/10 (hvis aktuelt).Kilde: Konkurransegrunnlag pkt. 2.9.1 (Dokumentnavn/ Beskrivelse/ instruks)
• Ved sladding/offentlighet: leverandør skal levere eget sladdet tilbud og egenerklæring om hvilke deler som skal unntas offentlighet, samt begrunnelse.Kilde: Konkurransegrunnlag pkt. 2.8 (Offentlighet)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

12.06.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• SaaS-leveranse med multitenant og alltid tilgjengelig løsning; drift/overvåkning/oppgraderinger/vedlikehold i sin helhet av tilbyder.Kilde: Bilag 1 (Kundens kravspesifikasjon) / TEKNISKE KRAV (SaaS/multitenant)
• Integrasjoner: integrasjon mot matrikkel, samt krav om integrasjon mot sak/arkiv (WebSak Acos), Visma fakturering og Gemini Privat (direkte eller via integrasjonsplattform).Kilde: Bilag 1 (Kundens kravspesifikasjon) / FUNKSJONELLE KRAV og INTEGRASJONSKRAV
• Tilgangsstyring: integrasjon med Microsoft Entra ID (SSO) med SAML/OIDC; støtte SCIM 2.0 for provisjonering/deprovisjonering (Ønskelig/standardisert kravskategori).Kilde: Bilag 1 / ROLLER OG TILGANGSSTYRING
• Vedlikehold: oppdatere systemet slik at det støtter gjeldende lov- og avtaleverk; varsle minst 6 måneder ved større endringer som påvirker omliggende integrasjoner.Kilde: Bilag 1 / VEDLIKEHOLDSKRAV
• Service/vedlikeholdsvinduer og endringshåndtering: planlagt vedlikehold (onsdager i partallsuker mellom 20-24) primært; varsling minst 14 virkedager og 1 uke før vedlikehold med forventet nedetid.Kilde: Bilag 4 (Tjenestenivå med standardiserte kompensasjoner) / VEDLIKEHOLDSVINDUP
• SLA - tilgjengelighet: minst 98,5% (forbedres over årene opp til 99,8%).Kilde: Bilag 4 / AVTALTE TJENESTENIVÅ
• SLA - responstid og løsningstid: Kritisk (A) 60 min respons og 8 timer løsning; Alvorlig (B) <4 timer respons og 2 virkedager løsning; Mindre alvorlig (C) 1 virkedag respons og 2 uker løsning; endring 15 virkedager, endringsønsker 3 virkedager.Kilde: Bilag 4 / RESPONSTID OG INNSATS
• Prisavslag/refusjon ved brudd på avtalt tjenestenivå (tilgjengelighet), samt standardiserte kompensasjoner og mulig multiplisering ved gjentatte avvik (se SLA-beregninger).Kilde: Bilag 4 / BEREGNINGER AV PRISAVSLAG
• Databehandleravtale: tilbyder skal inngå databehandleravtale med kunden; lagrede data skal krypteres i systemet.Kilde: Bilag 1 / KRAV TIL TEKNISK MILJØ
• Feilretting og handlingsplikt: tilbyder har ansvar for å avhjelpe, og kunden kan kreve prisavslag ved mislighold; heving ved vesentlig mislighold.Kilde: SSA-L (generell avtaletekst) + Bilag 4 (kompensasjoner)

• I mottatt tekst finnes detaljer om funksjonelle krav (Bilag 1) og tjenestenivå (Bilag 4), men av konkrete innleveringskrav utover Mercell/ signering og sladdet tilbud er det lite strukturert tekst om hvilke eksakte skjemaer/vedlegg som må leveres i tillegg til bilag 2-6. (Konkurransegrunnlag oppgir bilag som skal fylles ut, men mangler eksplisitt liste over hvilke kvalifikasjonsdokumenter som skal vedlegges i Mercell.)
• I prisskjema-Excel er prisfelter oppført med 0 (f.eks. etableringskostnader og årlig tjeneste). Teksten sier ikke hvordan dette skal tolkes (gjelder det eksempel/utkast, eller at tilbudssummer faktisk skal være 0 i teksten).
• Tidsplanen for etablering (Bilag 3) er gitt som kundens ønske og milepæler med konkrete datoer, men leverandørens oppgaver/innhold i risikohåndtering og test/migreringsleveranser er beskrevet som at leverandør skal fylle ut felter. Mangler konkrete krav til hva leverandør må spesifisere utover at tabellene skal fylles ut.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I Bilag 4 – SLA beskrives definisjoner for nedetid og at terskel for “utilgjengelig” fastsettes basert på gjennomsnittlig transaksjonstid (f.eks. pålogging) i de første 3 månedene. Kan dere presisere nøyaktig hvilke måleparametere og terskler som skal brukes (hvilke transaksjoner, hvordan X-sannsynliggjøres, og hvilken metrikkerapport kommunen skal få tilgang til)?

   Hvorfor det er verdt å spørre: Dette påvirker hvordan nedetid måles og dermed om SLA og prisavslag kan kreves på korrekt grunnlag fra oppstart.

   Kilde: Bilag 4 – Innledning / definisjoner av Nedetid og “utilgjengelig”

2. Bilag 4 angir responstid og løsningstid for A/B/C-feil (f.eks. Umiddelbart/senest 60 min og løsningstid 8 timer/2 virkedager/2 uker). Kan dere bekrefte hvordan responstid/løsningstid måles i praksis når en hendelse behandles med midlertidig løsning (midlertidig løsning kategoriseres som B-feil): teller “løsningstid” til midlertidig løsning er iverksatt, eller først når endelig løsning er levert?

   Hvorfor det er verdt å spørre: Uklart målegrunnlag kan gi tvist om hvorvidt leveransen anses oppfylt eller utløser prisavslag.

   Kilde: Bilag 4 – Responstid og innsats / definisjoner av Løsningstid og Midlertidig løsning

3. I Bilag 4 fremgår at tilgjengelighet skal beregnes som (Servicetid – Nedetid - Vedlikeholdstid) * 100 / (Servicetid – Vedlikeholdstid), med krav til 98,5% eller bedre i årsplanen. Kan dere opplyse om hvordan dere håndterer og dokumenterer vedlikeholdstid for planlagte vedlikeholdsvinduer som varierer (inkl. nødvedlikehold) – og om vedlikehold som skjer utenfor vindu medfører at det likevel blir “nedetid” etter SLA-reglene?

   Hvorfor det er verdt å spørre: Vedlikeholdshåndteringen påvirker SLA-tellingen direkte; det bør være entydig før tilbud/prising og gjennomføring.

   Kilde: Bilag 4 – Avtalt tjenestenivå / beregning av tilgjengelighet og vedlikehold

4. Bilag 4 beskriver standardisert refusjon, men utdraget viser ikke selve tabellene/formlene for “Beregninger av prisavslag” og hvordan refusjon beregnes per hendelse vs. per måleperiode. Kan dere oversende/tydeliggjøre hvilke kvalitetsparametere som gir prisavslag og hvordan prisavslag beregnes (inkl. satser/formel og hva som inngår i beregningsgrunnlaget)?

   Hvorfor det er verdt å spørre: Leverandøren må kunne prise riktig risiko, og kommunen må ha et tydelig kravgrunnlag for mislighold/kompensasjon.

   Kilde: Bilag 4 – 5 Beregninger av prisavslag (utdrag mangler detaljer); samt 3 Avtalte tjenestenivå

5. I Bilag 4 står det at nedetid ikke er tid som skyldes “kommunikasjonslinje (internett kommunikasjon ut fra kunde) eller feil i egen infrastruktur”. Hvordan avgrenser dere ansvarsdeling når integrasjoner mot WebSak/Gemini/Visma eller IAM (Entra ID) feiler: skal feil i tredjeparts-/kommunekomponenter regnes som kundens ansvar, og hvilke bevis/diagnosegrunnlag kreves for at leverandøren kan avvise SLA-ansvar?

   Hvorfor det er verdt å spørre: Integrasjonsavhengigheter kan gi komplekse ansvarsforhold; det bør avklares for å redusere risiko for SLA-tvist.

   Kilde: Bilag 4 – Definisjoner av Nedetid (hva nedetid ikke er) samt integrasjonskrav i Bilag 1

6. I Bilag 1 under “Funksjonelle krav – Gebyrhåndtering” etterspørres bl.a. “automatiske justeringer av fakturagrunnlag ved endring i fagsystemene” (V K). Kan dere presisere hvilke konkrete kilder/hendelser som skal trigge justering (f.eks. matrikkelendring, ferdigattest, vannmåleroppgjør, Gemini/WebSak-tilknytning), og hvilke responstider/kalendervinduer som skal gjelde for at justeringen skal være tilgjengelig i gebyrsystemet?

   Hvorfor det er verdt å spørre: For å gi presise leveranse- og integrasjonsbeskrivelser må kommunen konkretisere hvilke hendelser som inngår og forventet “freshness”.

   Kilde: Bilag 1 – Krav V K “Systemet skal kunne gjøre automatisk justering av fakturagrunnlag ved endring i fagsystemene, og presentere full historikk…”

7. Bilag 1 beskriver at systemet skal støtte fakturering av ulike gebyrtyper og deler opp årsgebyr i 4 eller 12 terminer, samt forskudd (a-konto) basert på forrige års forbruk etter vannmåleroppgjør. Kan dere angi hvilke opplysningsfelter og datagrunnlag kommunen legger til grunn for terminfordeling og a-konto (f.eks. hvor “forrige års forbruk” hentes fra), og om det er krav til re-kalkulering/backfill når kildedata korrigeres?

   Hvorfor det er verdt å spørre: Dette er nødvendig for å estimere integrasjonsarbeid, testomfang og operasjonell risiko, samt riktig prising av migrering/handtering av endringer.

   Kilde: Bilag 1 – Funksjonelle krav (terminfordeling og a-konto)

8. Konkurransegrunnlaget sier at “Kravevaluering”/tildeling ikke er spesifikt vektet utover kategori- og kravtypebeskrivelse (ingen prosentvekt i utdraget). Kan dere bekrefte hvordan tilbud vurderes og rangeres: hvilke krav som faktisk gir utslag i score, og om det finnes en samlet evalueringsmodell (f.eks. sum score fra komplekse krav) som kan legges til grunn?

   Hvorfor det er verdt å spørre: Utydelig tildelingslogikk gjør det vanskelig å vite hvilke deler av tilbudet som bør prioriteres og beskrives mest grundig.

   Kilde: Bilag 1 – Kravtype og evaluering

9. Bilag 1/SSA-L Bilag 3: milepæler og garantitid fremgår kun delvis i utdraget og kan endres i fellesskap. Kan dere bekrefte endelige datoer og hva som er “fast” vs. “forhandlingsbart” i etableringsfasen (inkl. om akseptansetest/produksjonssetting er betinget av bestemte leveranser fra leverandør, f.eks. løsningsdesign-godkjenning)?

   Hvorfor det er verdt å spørre: Tydelighet om tidslinje og hvilke avhengigheter som er kritiske reduserer leveranserisiko og mulig kostnadsavvik.

   Kilde: Bilag 1 – Organisering og gjennomføring (SSA-L Bilag 3)