Avinor AS - T-193041 - Strømforvaltningsavtale

Avtalen gjelder strømforvaltning for Avinor i 3 år fra oppstart 1. april 2027, med opsjon for forlengelse. Leverandøren skal ha samlet tilsyn og forestå all handel med elektrisk energi for Avinors portefølje, håndtere/viderefakturere nettleiefakturaer, samt levere analyser og rapportering (markedsrapport og forbruks-/kostnadsrapporter) og tilby administrasjonsverktøy/webportal. Volumet er ca. 220 GWh/år historisk, ca. 500 abonnement.

• Leverandøren må ha omsetningskonsesjon (ettersom oppdragsgiver ikke er clearingkunde på Nord Pool, og leverandøren skal handle i eget navn på Nord Pool).

  Dokumentasjon: Mangler i utdraget; kravet fremgår som forutsetning for leverandøren.

  Kilde: Vedlegg A1 – Kravspesifikasjon ("Leverandøren må dermed ha omsetningskonsesjon")
• Leverandøren skal stille en kontaktperson (KAM/SPOC) med nødvendige kvalifikasjoner og erfaring, og utskifting skal varsles og skriftlig godkjennes av Oppdragsgiver.

  Dokumentasjon: Ikke spesifisert hvilken dokumentasjon som skal leveres.

  Kilde: Vedlegg A1 – Kravspesifikasjon ("Som minimum skal Leverandøren stille følgende ressurs tilgjengelig")
• NSMs grunnprinsipper for IKT-sikkerhet skal ligge til grunn hos leverandør; leverandøren må kunne gjennomføre nødvendige tilpasninger i eksisterende system for informasjonssikkerhet innen kontraktsstart (kostnader belastes ikke Avinor).

  Dokumentasjon: Ikke spesifisert dokumentasjonskrav i utdraget.

  Kilde: Vedlegg A1 – Kravspesifikasjon ("NSMs grunnprinsipper for IKT-sikkerhet...")

• Tilbudet skal besvare evalueringskravene i vedlegg B.Kilde: Vedlegg A1 – Kravspesifikasjon ("Evalueringskrav... svares ut i vedlegg B")
• Leverandøren skal beskrive tilbudt administrasjonsverktøy/webportal, inkludert krav til SSO, datalagring i Norge, sporbarhet av kontotilganger, rapportuttak og eksport til Excel, samt historisk datagrunnlag og graf-/tabellpresentasjon.Kilde: Vedlegg A1 – Kravspesifikasjon ("Administrasjonsverktøy/Webportal" )
• Leverandøren bes beskrive hvilke tjenester som kan leveres innenfor håndtering av fleksibilitetsmarkedet, erfaringer og muligheter for Avinor i dette markedet.Kilde: Vedlegg A1 – Kravspesifikasjon ("Fleksibilitetsmarked")
• Kravspesifikasjon: Alle krav anses bekreftet oppfylt ved tilbudsinngivelse dersom ikke avvik listes opp i «Skjema for avvik».Kilde: Vedlegg A1 – Kravspesifikasjon (innledning)

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

22.06.2026

Språk

norsk, English

Elektronisk katalog

Tillatt

• Varighet: 3 år fra oppstart 1. april 2027, med opsjon for Oppdragsgiver til forlengelse inntil 2+2+1 år.Kilde: Avtaledokument – Strømforvaltningsavtale for Avinor ("Avtalens varighet")
• Leverandøren skal forvalte porteføljen og ha samlet tilsyn, inkludert forestå all handel med elektrisk energi i avtaleperioden (fysisk handel på vegne av Oppdragsgiver), samt håndtering/viderefakturering av nettleiefakturaer.Kilde: Vedlegg A1 – Kravspesifikasjon ("Porteføljeforvaltning" )
• Levering av all strøm skal skje til spotpris for gjeldende prisområde i NOK satt på Nord Pool.Kilde: Vedlegg A1 – Kravspesifikasjon ("All leveranse av strøm...")
• Arbeidsoppgaver: porteføljeforvaltning; formidle markedsanalyser på forespørsel; faglig innlegg (inntil 4 timer, 1 gang pr år) og opplæring web (4 timer i året) – inkludert i pris.Kilde: Vedlegg A1 – Kravspesifikasjon ("Forvaltning, rådgivning og analyser")
• Gjenvinningskraft og opprinnelsesgarantier er opsjoner: kan etter Avinors valg kreves tilbud/skriftlig avtale.Kilde: Vedlegg A1 – Kravspesifikasjon ("Gjenvinningskraft (opsjon)", "Opprinnelsesgarantier (opsjon)")
• Rapportering: markedsrapport månedlig minimum (primo inneværende måned) og forbruks-/kostnadsrapport med minimum spesifisert innhold (kWh og nett-/kraftkostnader per målepunkt-ID per måned, nettleieelementer, inkludering av nye målere, mulighet for tilpasning og Excel-eksport, samt web-uttak/gruppering).Kilde: Vedlegg A1 – Kravspesifikasjon ("Rapportering")
• Sanksjon: manglende levering av korrekte rapporter/filer kan medføre dagmulkt 1 500 kr eks. mva utover overskredet frist; Avinor fakturerer dagmulk.Kilde: Vedlegg A1 – Kravspesifikasjon ("Manglende levering av rapporter/filer...")
• Sikkerhet: det skal ikke utveksles skjermingsverdig informasjon mellom partene; leverandør plikter å følge sikkerhetslov mv. hvis tjenesteyter får tilgang til skjermingsverdig informasjon/objekt/infrastruktur.Kilde: Vedlegg A1 – Kravspesifikasjon ("Generelle sikkerhetskrav")
• Begrenset tilgang til Avinors energidata/lokasjoner/målenummer/målepunkts-ID/forbruk (kun personell med tjenstlig behov); Avinor skal kunne få informasjon om alle personer hos leverandøren med tilgang; Avinors anlegg/måleteknologi skal ikke kartlegges.Kilde: Vedlegg A1 – Kravspesifikasjon ("Konkrete sikkerhetskrav")
• Honorar/prismodell: påslag (NOK) pr kWh fysisk levert; påslag skal inkludere handels- og ubalansekostnader; offentlige avgifter betales av Oppdragsgiver (korrigeres ved endringer).Kilde: Vedlegg A1 – Kravspesifikasjon ("Honorar og oppgjørsmodell" )
• Oppgjør/etterskuddsbetaling: Avinor betaler etterskuddsvis hver måned til leverandør basert på faktisk forbruk; opsjon for Avinor til å ta ut finansierings- og kredittkostnader (alternativ B).Kilde: Vedlegg A1 – Kravspesifikasjon ("Oppgjørsmodell – Etterskuddsbetaling")
• Prisregulering: påslag fast i første 3 år; deretter regulering for hver opsjonsperiode med SSB tabell 14702; skriftlig varsel og utregning; første regulering tidligst 1. april 2030.Kilde: Vedlegg A1 – Kravspesifikasjon ("Prisregulering")
• Betalingsfrist: 30 dagers betalingsfrist fra mottatt godkjent faktura hos Oppdragsgiver; Oppdragsgiver kan redusere antall dager som opsjon.Kilde: Vedlegg A1 – Kravspesifikasjon ("Betalingsfrist")
• Gjennomfakturering: separat faktura for kraft og nettleie, per selskap; ingen fakturagebyr; elektronisk faktura EHF Billing 3.0 til angitte elektroniske fakturaadresser.Kilde: Vedlegg A1 – Kravspesifikasjon ("Elektronisk faktura", "Krav til fakturaene")
• Fakturaformat/opplysninger: spesifiserte opplysninger inkl. kontraktsnummer, kontaktperson, måleperioder, kWh, påslag, offentlige avgifter, unik KID per faktura; nettleiefaktura skal ligge som vedlegg; mulighet for flere konteringsdimensjoner per målepunkt-ID.Kilde: Vedlegg A1 – Kravspesifikasjon ("Krav til fakturaene")
• Kostnadsunderlag: Innen 4. virkedager skal leverandør sende filer (REST-API/annet) som angir kraftforbruk per måler og nettleie per måler; filtype CSV semikolonseparert; feltskjema/struktur og linjetekstkrav (målernummer og anleggsadresse).Kilde: Vedlegg A1 – Kravspesifikasjon ("Krav til kostnadsunderlag" og "Krav til filtype")
• Møter: oppstartsmøte før oppstart på hovedkontoret i Oslo; halvårlige oppfølgingsmøter ved behov.Kilde: Vedlegg A1 – Kravspesifikasjon ("Møter/ reisekostnader")

• Utdraget inneholder ikke vekting og detaljerte tildelingskriterier (ligger i vedlegg B).
• Det er uklart hva som kreves av dokumentasjon for kvalifikasjonskrav (omsetningskonsesjon, SPOC-kvalifikasjoner, sikkerhet/IKT) fordi dokumenterte krav til dokumentasjon ikke fremgår i utdraget.
• Vedlegg A2 (federasjon) er stort sett tekniske krav; det fremgår ikke i utdraget hvordan disse inngår i kontrakten for strømforvaltningsavtalen (omfang/tilknytning til selve tilbudet utover at det listes som vedlegg F/ADFS i avtaledokumentet).
• Krav til rapporterings- og filleveransefrister er angitt (innen 4. virkedager), men sanksjonsregime for filleveranser utover rapporteringsdagmulk er ikke fullstendig beskrevet i utdraget.

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 vedlegg F – ADFS – «Avinor Federation Guidelines», kapittel 4.4.1 (ADFS Preferred Primary Solution) fremgår det at webapplikasjonen skal bruke et unikt FQDN/host-header dedikert for Avinor, og at «dedicated FQDN can’t be used by any other customers». Kan oppdragsgiver bekrefte hvordan dette skal håndteres i denne konkrete anskaffelsen for leverandørens eksisterende multi-tenant URL-er (f.eks. om det tilbys egen Avinor-dedikerte URL, reverse proxy/host-routing, eller om det er aksept for alternativ URL «kun hvis preferred URL ikke kan brukes»)?

   Hvorfor det er verdt å spørre: Dette påvirker både arkitektur, kost/innsats og risiko (integrasjon, drift, godkjenning). Leverandøren må vite hva som er akseptert i anskaffelsen.

   Kilde: Vedlegg F – ADFS – «4.4.1 ADFS Preferred Primary Solution»

2. Vedlegg F – ADFS – «4.3.1 Conditional Access» sier at Avinor krever at det skal være mulig å definere dedikert Conditional Access-policy for «the particular app», og at apper som kun støtter «All Cloud Apps» ikke er tillatt. Kan oppdragsgiver presisere hva som skal leveres/konfigureres av leverandør (og hva som gjøres av Avinor), og hvordan leverandørens «application registration» forventes å understøtte dette i praksis?

   Hvorfor det er verdt å spørre: Kravet kan slå ut på omfanget av konfigurasjon og tilpasninger; leverandøren må prise riktig om det krever endringer i leverandørens løsning.

   Kilde: Vedlegg F – ADFS – «4.3.1 Conditional Access»

3. Vedlegg F – ADFS – «4.6.2.1 Schema» og generelt om SCIM fremgår at SCIM Discovery/Schema-endepunkt er «Required». For denne anskaffelsen: Skal leverandøren levere en SCIM-implementasjon (inkl. Schema-endepunkt) som del av leveransen, eller er dette kun relevante føringer for eventuelle integrasjoner leverandøren velger? Oppdragsgiver bes bekrefte hvilken integrasjonsmetode som er valgt/forventet for kontrakten (SCIM/REST eller SOAP), og hvilke SCIM-endepunkter som skal være tilgjengelige.

   Hvorfor det er verdt å spørre: Selve valg av integrasjonsmetode (SCIM vs SOAP) og hvilke endepunkter som inngår, bestemmer utvikling/implementasjonskost og testregime.

   Kilde: Vedlegg F – ADFS – «4.6 Provisioning of identities» samt «4.6.2.1 Schema»

4. Vedlegg F – ADFS – «4.6.2 Preferred Primary Solution of Identities Provisioning» beskriver SCIM operasjoner som «Required» (CREATE/READ/REPLACE/DELETE/SEARCH) og Bulk som «Optional». I denne anskaffelsen: Skal leverandør levere Bulk-API for SCIM («Bulk Operation»), eller er dette kun opsjonelt/valgfritt? Hvis det er valgfritt: hva er terskelen for når oppdragsgiver vil kreve Bulk i ettertid?

   Hvorfor det er verdt å spørre: Bulk påvirker arbeidsmengde og modenhet i integrasjonen; leverandøren må vite om dette er en kostdrivende del av leveransen.

   Kilde: Vedlegg F – ADFS – «4.6.2.3 User Operations» (Bulk Optional)

5. Vedlegg F – ADFS – «4.4.1 ADFS Preferred Primary Solution» inneholder URL-regler og eksempler, bl.a. at «https://applikasjonsnavn.avinor.no» er «Preferred configuration, shall be selected» og at andre varianter kan være «Allowed only if preferred URL can’t be used». Kan oppdragsgiver angi hvilke konkrete scenarioer som i denne anskaffelsen kan gjøre at «preferred URL can’t be used», og hvem som dokumenterer/avgjør dette?

   Hvorfor det er verdt å spørre: Uklare unntak kan skape kontraktsrisiko og forsinkelser ved oppstart; leverandøren må vite beslutningsgrunnlag og akseptkriterier.

   Kilde: Vedlegg F – ADFS – «4.4.1 ADFS Preferred Primary Solution» (tabell over URL-konfigurasjoner)

6. Vedlegg F – ADFS – «4.3.2.1 Auth Code Flow» og «4.3.2.2 Implicit Grant Flow» angir at Avinor krever Auth Code Flow og ikke støtter implicit grant. For denne kontrakten: Hvilken apptype gjelder (web, SPA, server-basert app, native iOS/Android, API)? Kan oppdragsgiver bekrefte hvilken OAuth/OIDC-flow som er forventet for leverandørens grensesnitt(e), slik at leverandøren kan implementere korrekt (inkl. PKCE og bruk av MSAL)?

   Hvorfor det er verdt å spørre: Flow-valget påvirker implementasjon, sikkerhet og løsningens kost; leverandøren må vite hvilke deler som faktisk skal støttes.

   Kilde: Vedlegg F – ADFS – «4.3.2 App registrations and authentications flows» (Auth Code vs Implicit)

7. Vedlegg F – ADFS – «4.3.4 Azure AD B2B Guest Users» sier at applikasjonen må støtte UPN-formatet for B2B guest users (jonny.good_domain.com#EXT#domain.onmicrosoft.com) og at det kreves synkronisering av guest users via SCIM. I denne anskaffelsen: Er støtte for B2B guest users en del av leveransen, og i så fall hvilken rolle har leverandørens system (mottaker av gjesteidentiteter vs forvalter av gjesteobjekter)?

   Hvorfor det er verdt å spørre: B2B-krav kan kreve ekstra SCIM/atributt- og mappingsarbeid; leverandøren må vite omfanget.

   Kilde: Vedlegg F – ADFS – «4.3.4 Azure AD B2B Guest Users»

8. Vedlegg F – ADFS – «4.7 Usage of Authorization Claim» beskriver at Avinor kan regulere tilgang basert på claims som IsManaged/IsCompliant/IsRegisteredUser (Intune/Workplace Join) og at leverandøren «shall describe» hvordan applikasjonen kan bruke claims til å styre funksjonalitet. For denne anskaffelsen: Hvilke konkrete funksjoner/brukerreiser forventer oppdragsgiver at leverandøren skal styre basert på disse claims (f.eks. offline tilgang, signering/betaling, eller andre use cases)?

   Hvorfor det er verdt å spørre: Utydelige use cases gjør det vanskelig å prise riktig og kan gi avvik ved akseptansetest.

   Kilde: Vedlegg F – ADFS – «4.7 Usage of Authorization Claim»

9. Vedlegg F – ADFS – «5.1.2 OpenIDConnect Security Requirements» og «5.1.3 id_token»/«5.1.4 access_token» sier at applikasjonen må validere token signatur og bl.a. nonce/aud/iss/iat/exp, samt sørge for «no access»-side ved manglende autorisasjon. Kan oppdragsgiver spesifisere hvilke test-/akseptkriterier som forventes dokumentert eller verifisert i denne anskaffelsen (f.eks. krav til hvilke påstander som skal valideres og hvordan dette skal testes i lab/prod)?

   Hvorfor det er verdt å spørre: Leverandøren trenger å vite hva som kreves for dokumentasjon og verifikasjon for å kunne levere sikkert og kosteffektivt.

   Kilde: Vedlegg F – ADFS – «5.1.2 OpenIDConnect Security Requirements» samt «5.1.3 id_token» og «5.1.4 access_token»