Ekspertgruppemøte 6 Overordnet status. Statnett 12.februar 2015

Ekspertgruppemøte 6 Overordnet status Statnett 12.februar 2015

Prosjektstatus - Fremdrift Aktivitet Beslutningsport 1 Kravspesifikasjon Beslutningsport 2 Valg av leverandør År 2013 2014 2015 2016 2017 2018 Måned 9 101112 1 2 3 4 5 6 7 8 9 101112 1 2 3 4 5 6 7 8 9 101112 1 2 3 4 5 6 7 8 9 101112 1 12 3 4 5 6 7 8 9 101112 1 12 3 4 5 6 7 8 9 101112 Beslutningsport 3 Systemimplementasjon og test Datamigrering og markedstest Elhub i drift Beslutningsport 4 og 5 Planlagte bransjerådsmøter NVE Forskriftsarbeid (Elhub/NBS) NVE Forskriftsarbeid (Leverandørsentrisk/En-regning) AMS implementering Elhub versjon 2 12.02.2015 2

Nytt fra prosjektet Viktigste aktiviteter inneværende periode Forhandlinger med 2 gjenstående leverandører avsluttet. Valg av leverandør 16. februar Pilotuttrekk mottatt fra samtlige pilotaktører innen migrering Specification of Migration Files og Nonconformity files v0.9 DRAFT sendt til ekspertgruppen. Tilbakemeldinger mottatt Utvikling av Ediel-portalen igangsatt Dialog med systemleverandører initiert Viktigste aktiviteter i neste periode Signere intensjonsavtale med valgt leverandør. Oppstart av detaljert design med leverandør Forberede BP3-beslutning Publisere test- og migreringsspesifikasjoner på Elhub.no Infobrosjyre om migrering og test; innholdskrav, kvalitetskrav og prosess Specification of Migration Files og Nonconformity files v0.9 på Elhub.no Format for datakvalitetsrapport

Tentativ tidsplan test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Datavask Pilot migrering MIGRERING SYSTEMTILPASNING / TEST Systemutvikling Inkrementell migrering Elhub GO-LIVE 01.10.2016 Systemsertifisering Edielportal Systemgodkjenning og pilottesting elhub Aktørsertifisering Edielportal Aktørgodkjenning elhub

Forslag til aktørmilepæler - test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Formål Kriterier Migrering Kriterier Test Sikre at aktøren har identifisert alle data som skal migreres Gi en tidlig indikasjon på datakvalitet på data som skal migreres Få oversikt over strukturdata i markedet Sikre at aktør har inngått nødvendige avtale med systemleverandører Rapport på spesifisert format er oversendt til Elhub Rapporten er fullstendig i forhold til aktørens målepunkter og kunder Avtale om migrering inngått med systemleverandør Avtale om systemtilpasning og test inngått med systemleverandør

Forslag til aktørmilepæler - test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Formål Kriterier Migrering Kriterier Test Sikre at aktører med lav datakvalitet har oppnådd en bedring Rapport på spesifisert format er oversendt til elhub Datakvalitet vurderes som akseptabel

Forslag til aktørmilepæler - test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Formål Kriterier Migrering Kriterier Test Sikre at aktøren er i stand til å gjøre uttrekk fra egne systemer på spesifisert filformat og oversende disse til DAM Sikre at datakvalitet på migrerte data er akseptabel Hele porteføljen av data for aktøren er bekreftet korrekt mottatt i elhub migreringsverktøy Datakvalitet strukturdata i DAM >= 95,0%

Forslag til aktørmilepæler - test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Formål Kriterier Migrering Kriterier Test Sikre at aktøren har høy datakvalitet på migrerte data Sikre at aktøren har tilpasset sitt forretningssystem til elhub Datakvalitet strukturdata i DAM >= 99,0% Komplette måleverdier Aktør er sertifisert i Ediel-portalen

Forslag til aktørmilepæler - test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Formål Kriterier Migrering Kriterier Test Sikre at datakvalitet på migrerte data er i henhold til kriterier for GO-LIVE Sikre at aktørs forretningssystem er verifisert og klar for GO- LIVE Datakvalitet strukturdata i DAM >= 99,95% Komplette måleverdier Aktør er godkjent i elhub (Market Trial gjennomført)

Instruksjoner til bransjen Delprosjekt for migrering og test

Informasjonspakke til bransjen

I tillegg Overordnet brosjyre (hard copy) Bakgrunn for Elhub-prosjektet Hvordan vil Elhub affektere nett og kraftselskaper Tidsplan Egen brosjyre relatert til testaktiviteter

Elhub Specification of Migration Files Finnes i versjon v0.9 Draft Innspill kommet fra ekspertgruppen Endringer Diskusjonstemaer Informasjonspunkter Innspill fra ekspertgruppen gjennomgås på dagens møte Versjon 0.9 Draft gjøres tilgjengelig på elhub.no i etterkant av møtet Versjon 1.0 publiseres etter konsolidering med systemleverandør

Elhub Specification of Nonconformity Files Finnes i versjon v0.9 Draft Foreløpig ingen innspill kommet fra ekspertgruppen Versjon 0.9 Draft gjøres tilgjengelig på elhub.no i etterkant av møtet Versjon 1.0 publiseres etter konsolidering med systemleverandør

Brosjyre til bransjen angående delprosjekt for migrering Sendes på høring til ekspertgruppen i etterkant av møtet Prosjektet innarbeider innspill fra bransjen Brosjyren publiseres sammen med filformatene på elhub.no Det legges ut nyhetssak på elhub.no med link til dokumentene og det sendes ut mail til ca. 250 migreringsaktører Da er migreringsprosjektet offisielt i gang!

Hensikten med en brosjyre for migrering Gi en lettfattelig oversikt til markedsaktørene over hva de må gjøre i forbindelse med migrering Separere ut alt som har med migrering å gjøre Samle linker til spesifikasjoner som er relevante for migrering

Innholdet i brosjyren Krav til datakvalitet Krav til datamigrering Eksempel på innsending av filer Bruk av eksterne registre Infotorg Tidslinje for migrering VEE standarden Milepæler for migrering og test

Krav til datakvalitet

Krav til datakvalitet Det er en 3-stegs gradering av kravene til kvalitetssikring Må, Bør, Kan Det forutsettes kvalitetssikring mot eksterne registre Folkeregisteret, Brønnøysund Spesifisert i Elhub Specification of Migration Files

Krav til kvalitetssikring

Krav til datamigrering

Prinsipiell teknisk infrastruktur for migrering Front end DAM Kraftleverandør Periodisk kjøring Validation Nettselskap Migr. DB Elhub migr. Elhub DB 05.02.2015 Brosjyre som beskriver nettselskapers og kraftleverandørers krav til datakvalitet og migrering i forbindelse med Elhub

Bruk av eksterne registre

Tidslinje for migrering

Milepæler for migrering og test

Milepæler for migrering og test

Datakvalitetsrapporter knyttet til milepæler i migreringsprosjektet

Formål Få oversikt over grunndata og strukturdata som skal migreres til Elhub Initiell oversikt over datakompleksitet og datakvalitet hos aktørene i forkant av migrering til Elhub Oppfølging av migreringsaktørene i forhold til progresjon

To rapporter fra henholdsvis kraftleverandører og nettselskaper

Når og hvordan To rapporter knyttet til aktørmilepæler for delprosjekt for migrering og test M1 1. juni 2015 M2 1. november 2016 Rapporten blir gjennomført med Questback som også ble benyttet i spørreundersøkelsen før jul Andre rapporten blir utformet på bakgrunn av responsen på første rapport Forslag til format er utarbeidet av prosjektet og blir sendt til høring i ekspertgruppen i etterkant av møtet

Målepunkt

Antall og type Antall målepunkter av forskjellig type Produksjon Forbruk Utveksling Antall målepunkter av ulik avregningsmetode Profilavregnet Timesavregnet Antall målepunkter med/uten GSRN ID Sammenligning mellom kraft og nett

Omfang av spesielle avtaler Antall målepunkter med spesielle avtaler: Konsesjonskraft Frikraft Erstatningskraft Fastleveranseavtale Sammenligning mellom kraft og nett

Datakvalitet på målepunktadresse (kun nett) Postadresse Matrikkeladresse XY-koordinater

Strukturdata Oversikt over avregningsområder Oversikt over regionalnett Oversikt over fellesmåling Antall områder Hvor vidt man kan bytte kraftleverandør

Bruk av tjenesteleverandører (kun nett) Benyttes tjensteleverandører til innsamling av måledata Antall produksjonsmålepunkt som samles inn og kvalitetssikres av andre Antall forbruksmålepunkt som samles inn og kvalitetssikres av andre

Kunde

Datakvalitet på kundedata Antall kunder totalt (K) 1: Antall organisasjonskunder (O) 1: Antall personkunder (P) 1: Antall personkunder uten gyldig og reell fødselsdato: Antall organisasjonskunder uten organisasjonsnummer (OX) 2 : Antall organisasjonskunder med gyldig organisasjonsnummer (ON) 2 : Antall utenlandske personkunder (PU) 3 : 1) K = O + P 2) OX <= O 3) OX + ON = O 4) PU <= P 40

Aktørenes bruk av Infotorg for vask mot Folkeregisteret (DSF)

EVRY og DSF Gjennom avtale med Skattedirektoratet (Skd) er EVRY enedistributør av DSF Det kreves tillatelse for å få tilgang til DSF, for eksempel i forbindelse med vask og vedlikehold. Tillatelse må innhentes hos registereier (Skattedirektoratet) før det kan etableres tilgang til en tjeneste hos DSF.

Tjenester fra EVRY relatert til DSF Vask og vedlikehold av data mot DSF (Filematcth DSF) Relevant for markedsaktørene i migreringsprosjektet Sanntidsintegrasjon mot DSF (online skjermbaserte oppslag, online integrerte oppslag, datauttrekk) Ikke relevant for kraftaktørene i migreringen, men relevant for aktørene for pågående vasking etter Elhub go-live

Filematch DSF Vask er løsning for identifisering og oppdatering av persondata fra DSF i brukerens system. Vedlikehold er løsning for å vedlikeholde identifiserte personobjekter i brukerens system etter hvert som data om objektene endres i DSF. Hva er gevinsten: Finne kundenes fødselsnummer Finne dubletter av kunder Detektere kunder som «ikke eksisterer» Holde personregisteret oppdatert til enhver tid Detektere døde kunder Automatisere oppdatering av egne persondata

Prinsippskisse vask og vedlikehold

Data som sendes inn til EVRY Feltnavn Startpos Type/lengde Beskrivelse KUNDE-NR 1 A/8 Kundens kunde-identifikasjon hos EVRY, normalt kundenummeret. AVDELINGSNR 9 A/6 Avdeling hvis dette er aktuelt EGEN-ID 15 A/16 Unik ID i kundens egen portefølje til bruk for tilbakematch når data mottas i retur fra vask. FODSELSDATO 31 A/6 Hvis man har fødselsdato registrert legges denne her på forman DDMMÅÅ PERSONNR 37 A/5 Hvis man har personnummer registrert legges dette her. NAVN 42 A/50 FORNAVN 92 A/50 ADRESSE 142 A/30 HUSNR 172 N/4 Personens navn. Hvis etternavn, fornavn og mellomnavn er sammensatt i ett og samme felt legges dette her, ellers bare etternavn. Personens fornavn og eventuelle mellomnavn. Fornavn legges først. Personens adresse. Hvis gatenavn, husnr. og bokstav er sammensatt i ett og samme felt legges dette her, ellers bare gatenavn. Hvis adressen er delt i gatenavn, husnr og bokstav som egne felter legges husnr her. POSTNR 176 N/4 Postnummer der personen er bosatt. SYSTEM-DATA 180 A/21 Fylles ut etter nærmere avtale. Ellers blank.

Identifikasjon av person Det må være likhet på enten Fødselsnr og navn (fornavn og etternavn), eller Fødselsdato og navn (fornavn og etternavn), eller Navn (fornavn og etternavn), adresse og postnr Folkeregistrert adresse kan brukes til positiv identifikasjon, men avvikende adresse betyr ikke feil kunde ettersom det ikke er 1-1 mellom sluttbrukeradresse og folkeregistrert adresse Trenger aktørene folkeregistrert adresse?

Priser for vask og vedlikehold Vask og vedlikehold (ajourhold) av kunde-, klient-, eller medlemsregister med opplysninger fra folkeregisteret. - - Maskinell oppdatering (pr vask/vedlikehold) av register. Pris for første 1.000 personer Pr. oppdrag kr 175,00 Maskinell oppdatering (pr vask/vedlikehold) av register. Pris for neste 1.000 personer Pr. 1.000 personer kr 2,00 Månedlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for første 1.000 personer Pr. oppdrag kr 175,00 Månedlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for neste 1.000 personer Pr. 1.000 personer kr 2,00 Ukentlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for første 1.000 personer Pr. oppdrag kr 75,00 Ukentlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for neste 1.000 personer Pr. 1.000 personer kr 1,50 Daglig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for første 1.000 personer Pr. oppdrag kr 25,00 Daglig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask for neste 1.000 personer Pr. 1.000 personer kr 1,00 Fortløpende oppdatering av utgåtte fnr/dnr og sperret adresse Pr. oppdrag kr 65,00

Kommersielt Priseeksempel 100.000 kunder Kr 175,- + kr 2,- * 99 = kr 373,- Virker som en tjeneste som treffer bransjens behov godt Aktørene kan selv gå mot EVRY, eller via en tredjepart (f.eks. en spesialist på datavask som i tillegg kan koble mot andre registre som f.eks. Matrikkelen og brreg)

Elhub-prosjektet sin rolle Elhub-prosjektet kommer ikke til å være involvert i aktørenes tekniske integrasjon mot DSF Elhub-prosjektet ønsker å være en fasilitator i prosessen for at tilstrekkelige hjemler gis til aktørene gjennom forskrifter og søknadsprosesser NVE har avtalt møte med Skattedirektoratet. Vi avventer tilbakemelding.

Hvordan komme i gang med vask og vedlikehold selv? Informasjon fra EVRY sine Infotorg sider

Historikk på migrerte data Behov: Elhub trenger alle grunndata og strukturdata for å bli nav for alle markedsprosser og måleverdier fra oktober 2016 Elhub trenger migrerte data for å støtte saldooppgjør tilbake i tid til 1. februar 2016 (tentativ dato for overgang til nettavregningsområder) Elhub trenger måleverdier fra 1. januar 2016 for å kunne støtte elcert rapportering fra 2017. Løsning: All data som krever historikk pluss måleverdier migreres fra 1. januar 2016 Man trenger ikke historikk på hver enkelt måleverdi, men måleverdihistorien med siste versjon av hver verdi skal migreres Typisk informasjon som krever historikk er: knytning mellom målepunkt og aktører, dvs. kraftleverandør, balanseansvarlig, nettselskap og sluttbruker Målepunktinformasjon som avregningsmetode, avlesningsmetode, status Typisk informasjon som ikke krever historikk: Måleverdiinformasjon som kvantitet, kvalitet, valideringskode, estimeringskode, registreringsdato, startdato, tildato, kategori Nettavregningsområder Alt man ikke skal ha historikk på migreres kun siste status før go-live

Måleravlesning i forbindelse med migrering Uke før Jan 2016 Feb 2016 go-live 1/10 2016 Måleverdier etc tilgj. Strukturdata tilgj. Frys av marked Elhub go-live For rapportering av Elcert fra 2017 NBS Go-live Avlesninger profilavregnede Alle målepunkter leses av etter overgang til nettområder men før Elhub go-live Periodevolumet fordeles før/etter skjæringsdato feb med påfølgende saldooppgjør frem til feb. 2016. Resten gjøres opp av Elhub etter golive

VEE og migrering Pålegg om bruk av Statnetts standard for VEE kommer i ny forskrift 301 Standarden gjelder fra Elhub go-live Markedsaktørene oppfordres til å implementere VEE standarden samtidig med AMS Mao. migrerte timesverdier til Elhub behøver ikke følge VEE standarden, men kan gjøre det.

Krav til datakvalitet for data som skal migreres

Masterdata en agenda Vurderinger på felt-nivå i migreringsfilene Krav og forventning til kvalitetssikring Hva skjer ved feil og på hvilke nivåer Hvilken aktør blir informert om feil på hvilket nivå Forventning til korreksjon av feil data Hva skjer dersom feil ikke korrigeres Rapportering av funn og valg av autoritativ kilde

Mottak av data fra kraft og nett Elhub Kraftleverandør Kunde Relasjon til målepunkt Syntakskontroll Integritetskontroll Konsistenskontroll Målepunkt Måleverdier Kunde Relasjoner Nettselskaper database database Sluttbruker Målepunkt

Recap: Informasjonsmodell for migrering class Migration conceptual information model Name: Migration conceptual information model Author: perber Version: 1.0 Created: 03.12.2014 16:05:22 Updated: 05.12.2014 13:52:55 Balance Supply Contract Balance Supply Customer Metering Point Elhub inv oice recipient Elhub address register Elhub End-user 0..* 0..* Metering Values Grid Access Contract Grid Access Customer

Vurdering av felter i migreringsfilene Påkrevde felter: Mandatory, Conditional, Optional Valideringsregler tilknyttet felter, hver med feilnivå og kritikalitet Feilnivå: Syntaks, Integritet, Konsistens Kritikalitet: Kritisk, Alvorlig, Mindre viktig Fra disse graderingene stiller Elhub krav til gjennomført kvalitetssikring per felt: Må, Bør, Kan(, samt ikke relevant)

Vurdering av felter i migreringsfilene - ref. formatbeskrivelse for migreringsfiler Hvert felt er identifisert med en rekke egenskaper, bl.a.: Navn (norsk og engelsk) Krav til kvalitetssikring per felt: Må, Bør, Kan Påkrevde felter: Mandatory, Conditional, Optional Krav til representasjon av historikk for feltet Datatype og format for feltet Valideringsregler er tilknyttet felter, hver med feilnivå og kritikalitet

Detaljert - Krav til uttrekk av felter Angitt krav til uttrekk: Mandatory, Conditional, Optional Mandatory (Obligatorisk) Skal fylles ut uansett. Hvis informasjon mangler, må den fremskaffes eller konstrueres. Conditional (Avhengig) Skal fylles ut dersom i hvert fall en av følgende: Feltets innhold eksisterer i kildesystemet Feltet/ene som innholdet er avhengig av er fylt ut fra kildesystemet Optional (Valgfri) Skal fylles ut dersom feltets innhold eksisterer i kildesystemet Merk spesielt: Definisjonen innebærer at feltet ikke skal konstrueres dersom data mangler. Men dersom informasjonen er tilgjengelig, SKAL denne sendes inn. Begrepet Valgfri/Optional er derfor KUN knyttet til den tekniske filbeskrivelsen, og må ikke feiltolkes ift. kravet om å sende inn eksisterende data i feltet. Dette gjelder også for felter som er angitt som Conditional og der avhengigheten er Optional.

Feilnivå En rekke felter er tilknyttet en eller flere valideringsregler Hver valideringsregel har et feilnivå og en kritikalitet Feilnivå er en av: Syntaks, Integritet, Konsistens Syntaks Sjekk at feltet er korrekt utfylt ift. verdier og formater/utforming Integritet Sjekk at feltet er korrekt i forhold til andre felter i samme fil og/eller i filer fra samme markedsaktør/rolle Konsistens Sjekk at felter er korrekt i forhold til felter i filer fra andre markedsaktører og roller

Kritikalitet Kritikalitet er en av: Kritisk, Alvorlig, Mindre viktig Kritisk Feltets korrekthet påvirker direkte Elhubs funksjon etter go-live Feltets innhold må være korrekt senest fra go-live Feil inngår i rapportering av fremdrift til NVE Alvorlig Feltets korrekthet påvirker markedets funksjon etter go-live Feltets innhold bør være korrekt senest fra go-live Manglende forbedring av feil over tid rapporteres til NVE Mindre viktig Feltets korrekthet kan påvirke fremtidige Elhub-funksjoner Feltets innhold bør korrigeres men kan også korrigeres etter go-live

Detaljert Representasjon av historikk Migreringsfiler vil ofte omfatte informasjon over en periode Eks.: Endringer i data for målepunkt i perioden 01.01.2015 01.06.2015 Avhengig av krav til feltet skal da enten alle endringer sendes med, eller kun siste verdi for perioden Dette angis gjennom parameteren "historikk" for feltet Angitt krav til historikk: Yes, No Historikk = Yes Historikk for feltet skal følge med, dvs. dersom feltets innhold har endret seg over perioden, skal hver nye verdi angis på en ny rad Dersom flere felter endrer seg på samme tid, skal alle endringene samles i så få rader som mulig, dvs. hvis eksempelvis tre felter er endret på samme tid, skal det sendes to rader: En med opprinnelige verdier, og en rad med endrede verdier for alle felter. Oppløsningen på tid ift. historikk skal settes til en dag, dvs. hvis de samme tre endringer er gjennomført på tre forskjellige tidspunkter på samme dag, skal disse fremdeles kun utgjøre én endring. Endringstidspunktet settes til tidspunktet av den siste endringen. Historikk = No Kun siste (gjeldende) verdi skal sendes dersom det har skjedd endringer i perioden som det tas uttrekk fra.

Kvalitetssikring

Kvalitetssikring som enkeltaktører bør gjøre selv forut for migreringen Gjennomgang og komplettering av egne data Manglende opplysninger på (eldre) anlegg Inndeling av navn/etternavn (og mellomnavn) Kommunikasjonsinformasjon på sluttbrukere Start innsamling av fødselsnummer Datavask mot enhets- og det sentrale folkeregister (DSF) Krav om vask ifm. datamigrering til Elhub, samt løpende sjekk ved oppstart av nye markedsprosesser som leverandørbytte, osv. Organisasjoner skal fremover registreres med et enhetsnummer Sammenstille med porteføljeoversikter / Nubix-uttrekk Sammenfallende sluttbrukere mellom kraft og nett 05.02.2015 Brosjyre som beskriver nettselskapers og kraftleverandørers krav til datakvalitet og migrering i forbindelse med Elhub

Kvalitetssikring: Betydning av graderingene ("nice-to-have" versus "must-have") Data som er nødvendige for at Elhub skal virke MÅ være kvalitetssikret før overføring til Elhub Data som skal sendes til Elhub som ikke er driftskritiske, men er viktige for markedet, BØR være kvalitetssikret før overføring til Elhub Data som skal sendes til Elhub som ikke er driftskritiske, men vil bli viktige for markedet *, KAN være kvalitetssikret før overføring til Elhub *) Ref. leverandørsentrisk modell

Hva skal kvalitetssikres av markedsaktørene? Markedsaktør MÅ BØR KAN Nett Målepunktinformasjon Måleverdier Kundeidentifikasjon Relasjoner Avgiftsinformasjon Kraft Kundeidentifikasjon Relasjoner Målepunktadresse Kundeadresse Kundeadresse Avgiftsinformasjon

QA på Migreringsdata og tilhørende entiteter Avgifter Målepunkt adresse Kontrakt Kunde Navn og info Kundeadresse Målepunkt Alt.: Fullintegrerte kundereferanser Kontrakt Kunde Navn og info Kundeadresse Måleverdier Avgifter QA-krav Må Bør Kan Markedsaktør Kraftleverandør Nettselskap

Rapportering og håndtering av feil

Tilbakemelding på feil nivå og kritikalitet En rekke felter er tilknyttet en eller flere valideringsregler Hver valideringsregel har et feilnivå og en kritikalitet En valideringsregel vil kunne utløses av minst en markedsaktør Rapport på og forventet korreksjon av en regel utføres av en (evt. annen) markedsaktør, jfr. tabell Feilnivå Kritikalitet Utløsende part Avviksfil til 1 - Syntaks Enhver Enhver Samme 2 - Integritet Enhver Enhver Samme 3 - Konsistens 1 - Kritisk Enhver Begge 3 - Konsistens 2 - Alvorlig Enhver Kraftleverandør 3 - Konsistens 3 - Mindre viktig Enhver Kraftleverandør

To raske eksempler - Oversikt for nettselskap Oversikt for kraftleverandør Felter per fil som er enten Mandatory eller Conditional Alle feilnivåer og kritikaliteter, men Konsistens/Kritisk merket spesielt Markert felter med QA_krav = Må

Fil Metering Point Påkrevd kvalitetssikring av felter (rødt = inngår i kritisk konsistenskontroll) Påkrevd felter nettselskap Felt MeteringPointID ValidFrom ValidTo SettlementMethodType MeteringMethodType MeteringPointLoadLimit MeteringPointInstalledEffect ReportingFrequency MeteringPointSubType SettlementConstant MeterDigits MeteringGridAreaUsed OutAreaUsed MeteringPointType MeteringPointStatus MeterIdentification MeteringPointAccountable GardsNr BruksNr SeksjonsNr FesteNr BuildingNumber PostCode MunicipalityCode Påkrevd felter nettselskap QAkrav Fil Felt QAkrav Må Customer CustomerReference Må Må AddressType Må Må ValidFrom Må Må ValidTo Må Må CustomerIdentity Må Bør CustomerIdentityType Må Må Nationality Må Kan FirstName Må Må LastName Må Kan CompanyName Må Kan BuildingNumber Kan Må StreetName Kan Må PostCode Kan Må CountryCode Kan Må Contract MeteringPointUsed Må Kan ValidFrom Må Ikke rel. ValidTo Må Bør CustomerReferenceEndUser Må Bør GridAccessProvider Må Bør BalanceSupplierUsed Må Bør BalanceResponsibleParty Må Bør NACE_Code Må Bør ElCertificateShare Må Bør EnovaFeeShare Må EnovaFeeType Må ElFeeShare Må ValueAddedTaxShare Må EndReason Må Påkrevd felter nettselskap Fil Felt QAkrav Formula ResultMeteringPoint Kan ValidFrom Kan ValidTo Kan FormulaItemNumber Kan FormulaNumberOfItems Kan FormulaItemIdentification Kan MeteringPointReferenced Kan ArithmeticOperation Kan Metering MeteringPointUsed Må Value TimeSeriesType Må ProductType Må UnitType Må StartDate Må EndDate Må QuantityQuality Må RegistrationDateTime Må Quantity Må ValidationCode Må EstimationCode Må VolumeCategoryCode Må ExpectedAnnualConsumption Må MeterReadingOriginType Må

Påkrevd kvalitetssikring av felter (rødt = inngår i kritisk konsistenskontroll) Påkrevd felter kraftleverandører Fil Felt QA-krav Contract MeteringPointUsed Må ValidFrom Må ValidTo Må CustomerReferenceEndUser Må GridAccessProvider Må BalanceSupplierUsed Må BalanceResponsibleParty Må NACE_Code Kan EndReason Må Customer CustomerReference Må AddressType Må ValidFrom Må ValidTo Må CustomerIdentity Må CustomerIdentityType Må Nationality Må FirstName Må LastName Må CompanyName Må StreetName Kan PostCode Kan CountryCode Kan

Totale oversikter foreligger også

Et lite eksempel på innsending av filer Case Vertikalintegrert aktør med hhv.: Kun kraftkunder: 5 000 Kun nettkunder: 10 000 Kunder av både kraft og nett (vertikalintegrerte): 20 000 Hvilke filer skal da sendes inn? Hvilket innhold skal være i de respektive filene?

QA på Migreringsdata og tilhørende entiteter 25.000 kraftkontrakter 30.000 målepunkter Målepunkt adresse Avgifter Kontrakt Kunde Navn og info 5.000 kraftkunder Alt.: 20.000 integrerte kunder Kundeadresse Kundeadresse Målepunkt Alt.: Vertikalintegrerte kundereferanser Kontrakt Kunde Navn og info Måleverdier Avgifter 10.000 nettkunder 20.000 integrerte kunder Case. Aktør med: - 5.000 rene kraftkunder (kun kraftkunder) - 10.000 rene nettkunder (kun nettkunder) - 20.000 vertikalintegrerte kunder (kraft og nett) 30.000 nettkontrakter

Ved ikke mulig korreksjon av feil (residualfeil ved go-live) Alt er selvfølgelig korrekt ved go-live men for sikkerhets skyld

Kilde til informasjon i migrering - Behov for entydige regler for valg og håndtering av autoritativ kilde for informasjon forut for Elhub go-live, dvs. gjennom migreringen Regler må defineres på egnet nivå Datasett og aktør Absolutt behov for korrekthet i forhold til mindre viktige data Kritikalitet for Elhub nå, markedet og fremtidige behov Utlede konklusjon fra vurdering av argumenter og kritikalitet

Argumenter fra diskusjon Nettseskap som autoritativ kilde Via Nubix er Nettselskapene i prinsippet master i dag Uenighet om kvalitet på data: Siden nett er monopol og gjerne representere lengre kontinuitet for kunder, kan datakvaliteten her være mer korrekte. Som aktør i et sterkt konkurranseutsatt marked kan kraftselskapenes insentiv for økt datakvalitet oppleves som underordnet i forhold til å skaffe flere kunder raskere. I deres migreringer har Energinet.dk kun fokusert på data fra nettselskaper Kraftselskap som autoritativ kilde Kraft har den juridisk mest bindende kontrakten, der navnet som er registrert ikke uten videre kan endres uten også å endre kontrakten. Kraftselskapet har i mange tilfeller hatt siste kontakt med kunden, og kan derfor ha mest oppdatert informasjon. Etter go-live vil kraftleverandørene få ansvaret for kundedata i Elhub, og ved go-live må disse data være samstemte med Elhub. Elhub kan kun få begrenset kontroll på kraftselskapets korreksjoner i forkant dersom nettselskap er master. Signaler antyder en varierende praksis og grad av vask mot Nubix fra kraftleverandørene.

Håndtering av inkonsistente data (etter sammenstilling i informasjonsmodellen) Omfang: Avvik på relaterte kundedata Kundeadresser og kontaktinformasjon Informasjon er IKKE kritisk for verken Elhub eller markedsprosesser Informasjon benyttes i aktørenes egne (separate) systemer Uendret selv etter Elhub go-live, frem til neste/ny markedsprosess kjøres Vil være avvikende i markedet frem til utrulling av en-regningsmodell Modell i samsvar med dagens regime, dvs. master=nett Nubix forespør nettselskap om informasjon uavhengig av kraftlev. data Bruk av nettselskapets data vil gi konsistent svar på Nubix-forespørsel, også via Elhub (gjennom BRS-NO-611) etter go-live

QA på Migreringsdata og tilhørende entiteter Avgifter Målepunkt adresse Kontrakt Kunde Navn og info Kundeadresse Målepunkt Alt.: Fullintegrerte kundereferanser? Kontrakt Kunde Navn og info Kundeadresse Måleverdier Avgifter Entydige datareferanser (ingen avvik) Retning for å overskrive data ved avvik QA-krav Må Bør Kan Markedsaktør Kraftleverandør Nettselskap

Hva med inkonsistens på kritisk felter? Nettselskapet er autoritativ kilde for migreringen Konsekvenser og konflikthåndtering Avvikende sluttbruker på målepunkt: De-facto master (på sikt) = Nett Sluttbruker for nett registreres på målepunktet Fakturering fra hver part som i dag (frem til en-regning) Ved oppdatering av masterdata fra kraft: Melding avvist grunnet avvikende sluttbruker: Må registrere eierskifte. Ved leverandørbytte: Sluttbruker hos ny kraftlev. må samsvare med nett Ved ut-/innflytting: Ny sluttbruker registreres likt hos kraft og nett

Hva med inkonsistens på kritisk felter? Nettselskapet er autoritativ kilde for migreringen Konsekvenser og konflikthåndtering Avvikende kundeinformasjon: Master = Nett Nettselskapets adressedata registreres på kunden Fakturering fra hver part som i dag (frem til en-regning) Ved oppdatering av masterdata fra kraft: Data oppdateres til nett

Hva med inkonsistens på kritisk felter? Nettselskapet er autoritativ kilde for migreringen Konsekvenser og konflikthåndtering Avvikende tidsperioder for kunderelasjoner: Master = Majoritet Dersom avvik gjelder move-out/move-in (eierskifte) = nett er master Start- og sluttdato for kraftkontrakt = start- og sluttdato for nettleiekontrakt Dersom avvik gjelder leverandørskifte = ny kraftlev. er master Sluttdato for gammel kontrakt = Startdato for ny kontrakt

Hva med inkonsistens på kritisk felter? Nettselskapet er autoritativ kilde for migreringen Konsekvenser og konflikthåndtering Avvikende avgifter: Master = Nett

Konsesjonskraft, frikraft, erstatningskraft, Konsesjonskraft Frikraft Erstatningskraft Andre begreper og (sær-)ordninger vi må vurdere? Fastleveransekontrakter? Andre tilfeller?

Konsesjonskraft, frikraft, erstatningskraft, En overordnet føring er at særtilfeller håndteres bilateralt og dermed utenfor Elhub - så langt som mulig Funksjonen til Elhub skal dermed rendyrkes så langt som mulig, og skal kun omfatte informasjon som treffer flere aktører og/eller noen av de beregningsområdene som Elhub vil overta

Konsesjonskraft Basis Kompensasjon til kommuner og fylkeskommuner i følge vassdragskonsesjonen. Resulterer i et volum per år med konsesjonskraft Påvirkning på Elhub og migrering Har nettselskap og/eller (sluttbrukers) kraftleverandør en rolle i forhold til denne formen for avtaler som berører Elhub? Rapporteres måleverdier fra Nett knyttet til denne typen kontrakter, og i så fall til hvem/hvilke(n) parter? Har dette noen konsekvens for rapportering til Balanseavregningen for måledata eller er det kun finansielle løsninger? Hvilken rolle har konsesjonæren i kraftmarkedet? Hvem/hvilken rolle "holder oversikt" over avtalene og håndterer disse i dag, og hvilke avtaler foreligger og med hvilke parter? Hvordan håndtere i migreringen? Hvis det er behov for informasjon i Elhub er dette for å dele informasjonen med en annen Markedsaktør eller fordi Elhub har behov for dette for å utføre sine prosesser korrekt? Påvirker dette Elhub?

Erstatningskraft Basis Kompensasjon til andre kraftverk for bortfall av egen produksjon ved nye utbygginger. Bilateral avtale mellom produsenter? Resulterer i et volum per år med erstatningskraft Påvirkning på Elhub og migrering Ingen? Hvordan håndtere i migreringen? Treffer ikke sluttbrukermarkedet, og trenger derfor ikke håndtering i Elhub?

Frikraft Basis Kompensasjon til grunneier for bortfall av andre rettigheter. Bilateral avtale mellom utbygger/kraftprodusent og grunneier/sluttbruker. Omfatter en avtalefestet kostnadsfri kraftleveranse angitt som en effekt og beregnet som et volum per år. Variasjoner i utregning og måling. Omfatter (normalt) ikke El-sertifikatavgift eller forbruksavgift, som må dekkes av sluttbrukeren selv. Forhindrer denne type avtale normalt skifte av kraftleverandør på målepunktet?

Frikraft Påvirkning på Elhub og migrering Måleverdier Hvilke måleverdier rapporteres fra Nett til hvem/hvilke(n) parter? Sluttbruker får tilgang til totalvolumer via Elhub. Annen deling kan gjøres av kraftleverandør. Har avtalen noen konsekvens for rapportering til Balanseavregningen for måledata eller er det kun finansielle løsninger? I hvilken grad er det installert overforbruksmålere ift. "vanlige" målere? I de tilfeller der overforbruksmålere er installert er disse registrert som samme eller forskjellige målepunkt? Roller i markedet Hvem/hvilken rolle "holder oversikt" over avtalene og håndterer disse i dag Har nettselskap og/eller (sluttbrukers) kraftleverandør en rolle i forhold til denne formen for avtaler som berører Elhub? Hvilken rolle har konsesjonæren i kraftmarkedet Hvilke avtaler foreligger og med hvilke parter?

Frikraft Hvordan håndtere i migreringen? Vi kommer tilbake med forslag til håndtering basert på tilbakemeldinger.

Fastleveransekontrakter I hvilket omfang benyttes disse i markedet i dag? Hvilke aktører håndterer slike avtaler? Hvordan håndteres slike avtaler i dag?

Endringer i format for migreringsfiler

Endringer i filformat Endringer Diskusjonstemaer Informasjonspunkter

Endringer (1 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon Contract - ValueAddedTaxShare Customer - CompanyName Customer - CustomerIdentity Confluence QA-ansvar MVA for kraft og nett, derfor begge Required. Setter QA grid owner = Required Confluence IntegritetsbegrensningFeil i dokumentet. Skal være: M if FirstName == NA Confluence Påkrevd Beskrevet inkonsistent med BIM: Feltet endres til Mandatory også for Conditional for privatpersoner. privatpersoner, men med tillatte Conditional i denne sammenhengen variasjoner på format. gjelder ikke hvorvidt feltet er Mandatory, men er knyttet til hvilke formater som kan tillates. Dette kan misforstås. Generelt Intern QA Skrivefeil adress -> address MeteringPoint - BuildingNumber MeteringPoint - MeterDigits Confluence Begrepsavklaring BuildingNumber kommer fra både HNR og ebix, og er sånt sett noe i motstrid til Matrikkelens "Husnummer". Dette også relatert til splitt av BuildingNumber og BUildingLetter. Merk samtidig at Matrikkelen også opererer med "bokstav" som mulig felt i en adresse, og at disse dermed er skilt fra hverandre. Confluence Formatdefinisjon Vi bør fastsette format på dette feltet, hvorvidt vi skal ha desimaler, og i så fall hvor mange. 1. Følger HNR med BuildingNumber for "husnummer". 2. For samsvar med notasjon i HNR (feltet eksisterer imidlertid ikke der) benyttes BuildingLetter for "bokstav". Forslag: dec(4.1) Dvs. totalt 4 tegn inkl. komma, og ett desimal (iht C-notasjon). Dette for angivelse av antall tegn som dermed er oppad begrenset til 99.9 = 89 hovedtall og 9 desimaler.

Endringer (2 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon MeteringPoint - MeteringMethodType MeteringPoint - MeteringPointLoadLimi t MeteringPoint - MeteringPointStatus MeteringPoint - MeteringPointType MeteringPoint - MunicipalityCode MeteringValue - EstimationCode Intern QA Endre enumerasjon Endre alternativer til: E13 Automated E14 Manual read E16 Not read E24 Calculated Må dobbeltsjekkes med Erik. Må stemme overens med ebix, BIM (og kanskje HNR). Her ble det introdusert noen feil i forbindelse med oversettelsen. Confluence Manglende rad i tabell Setter inn Dependencies med beskrivelse. Confluence Manglende rad i tabell Setter inn Format med beskrivelse. Confluence Manglende rad i tabell Setter inn Format med beskrivelse. Confluence Integritetsbegrensning Conditional. M if (StreetCode!= NA or Gnr!= NA) Mandatory if either Gnr or StreetCode is set. Gjennomgang Inkonsistent med BIM og VEE E001 Actual volume and history based E002 Actual volume and MGA profile based E003 Total volume and history based E004 Volume based on expected annual consumption and MGA profile E005 Power failure. Estimated volume is set to 0. Enumerasjon oppdateres med fullstendig liste over koder og tilhørende beskrivelser.

Endringer (3 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon MeteringValue - EstimationCode MeteringValue - ValidationCode MigreringsteamPåkrevd Confluence Inkonsistent med BIM og VEE XXX - BuildingNumber Confluence Avvikende format mellom målepunkt og kunde-filene XXX - FloorIdentification Confluence Mangler spesifikasjon av formatlengde Dette feltet (og ValidationCode) er ikke egentlig påkrevd i migreringen. Disse feltene er påkrevd etter Elhub go-live, og skal fylles inn i migrering hvis de korrekte (eller tilsvarende) verdier foreligger. Ellers kan feltene tillates å være blanke. V001 Power failure V002 Missing interval values V003 Register errors V004 Time stamp V011 Positive numerical value V012 Active versus reactive energy V013 Volumes versus meter reading Kundefilen angir text(10) som format, mens målepunktfilen angir num(10). Forslag: Endre forutsetningene for Conditional på begge feltene. Enumerasjon oppdateres med fullstendig liste over koder og tilhørende beskrivelser, inkl. korrigere eksempel (som har en "0" for mye). Forslag: Num(5) Dette skal være en numerisk verdi uansett (bokstav er eget felt), og denne verdien angir høyeste gatenummer til 99999. Antar dette vil være tilstrekkelig, også for internasjonale adresser? Forslag: string(10) Muliggjør alternative beskrivelser på etasjer, inkl. "KJELLER", "LOFT", "H01", "U01", "K01", "L01", osv.

Endringer (4 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon XXX - StreetName Confluence Forslag til revidert lengde XXX- RoomIdentification XXX-CareOF og XXX_Attention Confluence Mangler spesifikasjon av formatlengde Foreslått endret til 80 tegn. Forslag: string(150) Kartverkets API-beskrivelser angir kun "string" og ikke lengde. Samtidig oppgir Kartverket en "kortversjon" av alle gater som har større lengde enn 22 tegn. Sinde vi opererer med fulle navn, kan det derfor være hensiktsmessig å sette denne til en grense som er godt over det lengste mulige navnet. Et forslag kan da være 150 tegn. Forslag: string(10) Tilrettelegger dermed for alternativer som eksempelvis "HØYRE", "VENSTRE", "01", "02", Confluence Prefiks eller ikke? Beskrivelsen er utydelig, må presiseres hva som skal være med. EDIEL-dokumentasjon angir verkeneller, så dette er opp til migreringsløpet og Elhub å fastsette. I og med at feltene har klart definerte formål, synes et prefiks å være både unødvendig, forstyrrende og kilde til feil. osv. Anbefaler at navn fylles inn UTEN prefiks. Vil i så fall oppdatere feltbeskrivelsene til å gjenspeile dette.

Diskusjonstemaer (1 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon Contract - NACE_Code Confluence Endre format? For entiteter som ikke har NACE er det iht EDIEL etablert en to-tegns enumerasjon (XX, XY, etc.) og det samlede utfallsrom av formatalternativer er forsøkt beskrevet i Confluence som avhengigheter. Avhengig av tbm. i ekspertgruppemøtet. Et spørsmål er imidlertid relatert til hvorvidt bedrifter kan knyttes til hovedgrupper av NACE-koder - i så fall er det grunnlag for å endre forutsetningene for bruk av format for dette feltet til å være inntil 6 tegn langt. Hvilket format på NACE vil gi korrekt utfallsrom? Forslag: string(2) string(6) Er det tilstrekkelig å angi string(6) NB! dette er kun lengdebegrensning

Diskusjonstemaer (2 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon Customer - CustomerIdentityType Confluence Nødvendig felt? Feltet angir type identitet for utenlandske kunder, i form av fritekst. Er dette en hensiktsmessig form på dette feltet, og er feltet i det hele tatt nødvendig? 1. Feltet kunne vært vurdert fjernet dersom CustomerIdentity også angir type identitet - eksempelvis: Pass- 123456789. Dette krever at type identitet skrives likt av alle alltid. 2. Feltet kan settes som enumerasjon slik at valgene alltid er entydige. Siden utfallsrommet av dette feltet ikke er klart, må dette i så fall være en enumerasjon som det tillates lagt inn nye verdier i (fra Elhubs side). Anbefaler alternativ 2 med følgende innledende liste over enumerasjoner: 1. passnummer 2. nasjonalt identitetsnummer 3. førerkortnummer 4. fødselsdato 5. Annen identifikator Logikken må her være en prioritert rekkefølge på identetstypene ut fra listen over. Det betyr eksempelvis at dersom et passnummer foreligger, skal ikke fødselsdato oppgis. I utvidet forslag: 1. fødsels-/d-nummer 2. passnummer 3. nasjonalt identitetsnummer Utvidet forslag: 4. førerkortnummer Sette feltet til Mandatory, og fylles ut 5. fødselsdato også for norske sluttbrukere for å angi type identitet som foreligger. 6. Annen identifikator 7. Standard/kunstig identifikator (eks. standard dato e.l.) 8. Ingen identifikator

Diskusjonstemaer (3 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon Customer - xxxname Confluence Feltlengde Det er benyttet forskjellige feltlengder i forskjellige dokumenter og definisjoner, samt forskjellig antall felter på navn. Dette må harmoniseres med en klar begrunnelse, og vurderes overført til BIM der relevant, evt beskrives hvorfor ikke. Dette omfatter feltene: FirstName, LastName, MiddleName, CompanyName. Forslag: 1. FirstName - string(80), dvs. 2 x 40 tegn, omfatter for- og mellomnavn. 2. LastName - string (40), omfatter kun (hele) etternavnet. 3. CompanyName - string(80), som i dag, ingen endring. Format og beskrivelse i dokumentet oppdateres for å gjenspeile dette. MeteringValue - ExpectedAnnualConsu mption Folkeregisteret omfatter tre navn på personer, og en normal feltlengde per navn er ofte 35 tegn. Gjennomgang Konsistens med BIM For profilavregnede målepunkt skal feltet sendes inn sammen med avlesninger (siden en avlesning krever oppdatert årsforbruk). På hvilken måte er migreringsfilene inkonsistent med BIM? Dette feltet heter i BIM ABIE::AnnualPeriodEstimatedMetrics.Total og er heltall. På hvilken måte er dermed migreringsfilene inkonsistent med BIM? Navnet i BIM er satt til "Estimated annual consumption".

Diskusjonstemaer (4 av 4) Kapittel Kilde Navn på endring Beskrivelse av endring Konklusjon MeteringValue - MeterReadingOriginTy pe MeteringValue - TimeSeriesType Gjennomgang Konsistens med BIM Confluence Integritetsbegrensnin g På hvilken måte er migreringsfilene inkonsistent med BIM? Det benyttes samme koder med samme betydning, selv om enumerasjonen i BIM heter "Meter read reason code" i feltet "Reason for meter reading". Feltet er Mandatory. Verdien er enten E17 (forbruk) eller E18 (produksjon), og angir energiretningen for måleverdien. Kommentar påpeker at det er avhengighet knyttet til dette feltet - hvilken? (skal ikke være noen i migreringsfilene) På hvilken måte er migreringsfilene inkonsistent med BIM? Kommentar påpeker at det er avhengighet knyttet til dette feltet - hvilken? (skal ikke være noen slik avhengighet i migreringsfilene)

Informasjonspunkter (1 av 2) Kapittel Kilde Navn på endring Contract - ElCertificateShare (og andre tilsvarende decimal-felter) Beskrivelse av endring Confluence Formatdefinisjon Et spenn av formater er angitt: num(1) til num(10,8). Dette er den relle andelen (altså ikke i %), og omfatter følgende verdier: 1 = 100% 0,03 = 3% 0,000001 = 0,0001 % 9,99999999 = 999,999999% Konklusjon Merk num(10,8) betyr 8 desimaler, komma, og ett signifikant tall foran - totalt 10 tegn. Det antas at dette gir tilstrekkelig presisjon for angivelse av egnede andeler i dette og tilsvarende felter. Customer - Confluence Mangler spesifikasjon Feltet er en enumerasjon, og AddressType av formatlengde lengden er derfor ikke relevant. Eksempelfiler Confluence Spørsmål Eksempelfiler oppdatert? Eksempelfiler vil representeres på ny måte - som (nedlastbare) vedlegg i Confluence, og ikke som tekst. Kommentarer til dette? MeteringPoint - Intern QA Endre navn Endre navn til Tas til følge MeteringMethodType MeteringPoint - ReportingFrequency Intern QA Oppløsning for avlesninger MeterReadingCharacteristics Eksempel endret fra 8760 til 365. Beskrivelse oppdateres.

Informasjonspunkter (1 av 2) Kapittel Kilde Navn på endring MeteringValue - RegistrationVersionNu mber Beskrivelse av endring Confluence Spørsmål Dette feltet er tatt med som et valgfritt felt, men ellers på linje med Validation- og EstimationCode. Hensikten er at nettselskap skal kunne angi en versjon (hvis ønskelig), noe som vil kunne forenkle referanse til denne verdien senere, eksempelvis ved tilbaketrekking av verdier. Konklusjon MeteringValue - VolumeCategoryCode Gjennomgang Spørsmål Det er således opp til nettselskap å angi hvorvidt dette feltet skal benyttes. I migreringssammenheng er det nødvendig å få informasjon om hvordan en verdi er oppstått. Dette er informasjon som Elhub vil utlede etter go-live, og er således ikke nødvendig etter det tidspunktet. Feltet må fylles ut og sendes inn som angitt i filformatet, men er ikke relevant for BIM eller Elhub informasjonsmodell.

Analyse av uttrekksfiler

Datagrunnlag 9 pilotaktører 3 Nettselskap 6 Kraftleverandører Ca 90.000 unike kunder Ca 78.000 unike målepunkt Ca 146.000 kontrakter 17.02.2015 Bunntekst 110

Kodesett Windows 1252 vs UTF-8 17.02.2015 Bunntekst 111

Tall 17.02.2015 Bunntekst 112

Datoformat 3 systemer, 4 formater 17.02.2015 Bunntekst 113

Duplisering av data 17.02.2015 Bunntekst 114

Observasjoner rundt konsistens på tvers av nett/kraft Organisasjoner uten organisasjonsnummer. Pågående dialog med NVE på hvordan dette skal håndteres 260 tilfeller av 135.879 kunder = 0,2 % feilprosent Estimert 5600 tilfeller av 2.800.000 målepunkt på nasjonal basis. Kundeforhold på et målepunkt hvor det er en privatkunde på en av kontraktene, mens det er bedriftskunde på den andre. Eksempelvis en privatperson som sitter som kunde på nett mens et selskap sitter som kunde på kraft. 340 tilfeller av 73.000 kundeforhold = 0,47% Estimert 13160 tilfeller av 2.800.000 målepunkt på nasjonal basis. 17.02.2015 Bunntekst 115

Observasjoner rundt konsistens på tvers av nett/kraft fortsetter Privatkunder uten fødselsdato 60 av 135.879 kunder = 0,04% 1120 tilfeller på 2.800.000 målepunkt på nasjonal basis. Kundeforhold uten noen form for kommunikasjonskanal annet enn postadresse. (NB! Utrulling AMS) 792 av 54891 kundeforhold = 1,44% 40320 tilfeller på 2.800.000 målepunkt på nasjonal basis. 17.02.2015 Bunntekst 116

Observasjoner rundt konsistens på tvers av nett/kraft fortsetter Kundeforhold med personer med likt etternavn, men med ulikt fornavn. (herr og fru problematikken) 1380 av 54891 kundeforhold = 2,5% 70.000 tilfeller av 2.800.000 målepunkt på nasjonal basis. 17.02.2015 Bunntekst 117

Ekspertgruppemøte Statnett 12.februar 2015

Test Begrepsavklaring Sjekkliste for aktører Ressursbehov piloter

Begrepsavklaring Markedsaktør Kraftleverandør eller Nettselskap Allianse Samarbeid mellom markedsaktører for å etablere fellestjenester og foreta anskaffelser (f.eks. Soria) Tjenesteleverandør Leverandør av tjenester til markedsaktører eller allianser (f.eks. Valider og MAIK) Systemleverandør Leverandør av system som skal utveksle informasjon med og godkjennes mot Elhub (f.eks. Enoro, CGI og Tieto) EDI-leverandør Leverandør av EDI-system som skal kommunisere med Elhub (f.eks. Compello) Tredjepart Aktør som kun henter/mottar informasjon fra Elhub Rolle En aktør vil kommunisere med Elhub i kraft av en rolle, f.eks. Måleverdiansvarlig eller Nettilknytningstilbyder.

Begrepsavklaring Systemsertifisering i Edielportalen Test og sertifisering av system som skal utveksle informasjon med Elhub. Tilsvarer dagens TGT, Teknisk godkjenningstest. Aktørsertifisering i Edielportalen Test og sertifisering av markedsaktører som skal utveksle informasjon med Elhub. Tilsvarer dagens AGT, Aktørgodkjenningstest. Leverandørtest (Vendor trial) Test av systemer mot Elhub. Forutsetter test av alle typer prosesser som skal støttes av systemet. Gjennomføres parallelt med Elhub Systemtest. Markedstest (Market trial) Godkjenning av aktører i Elhub. Forutsetter utveksling av et sett av meldinger mellom markedsaktører og Elhub. Gjennomføres parallelt med Elhub Akseptansetest.

Tentativ tidsplan test og migrering 2015 2016 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 M1 01.06.15 M2 01.10.15 M3 01.02.16 M4 01.05.16 M5 15.09.16 Datavask Pilot migrering MIGRERING SYSTEMTILPASNING / TEST Systemutvikling Inkrementell migrering Elhub GO-LIVE 01.10.2016 Systemsertifisering Edielportal Systemgodkjenning og pilottesting elhub Aktørsertifisering Edielportal Aktørgodkjenning elhub

Sjekkliste for test (1) Sjekkpunkt Dato Ansvarlig Elhub-spesifikasjoner er ferdigstilt og publisert Elhub Utviklings- og testprosjektet er planlagt Markedsaktør Krav til systemendringer er spesifisert Markedsaktør Krav til endringer i prosess og organisasjon er Markedsaktør spesifisert Løsningsbeskrivelse og arkitektur er etablert Markedsaktør Avtale om utvikling og test er inngått med Markedsaktør systemleverandør Edielportalen er under utvikling og klar for initiell test Elhub Brukermanual for Systemsertifisering er utarbeidet Elhub M1 Alle markedsaktører har inngått avtale med systemleverandør om systemtilpasning og test 01.06.15

Sjekkliste for test (2) Sjekkpunkt Dato Ansvarlig Systemet er klargjort for Systemsertifisering Systemleverandør Systemsertifisering i Edielportalen er gjennomført Systemleverandør Testplan for Leverandørtest (Vendor trial) er Elhub utarbeidet Elhub er klargjort for Leverandørtest Elhub Systemet er klargjort for Leverandørtest Systemleverandør Leverandørtest er gjennomført Systemleverandør Sertifisert system er installert hos markedsaktør Markedsaktør Aktørsertifisering i Edielportalen er gjennomført Markedsaktør M4 Alle markedsaktører er sertifisert i Edielportalen 01.05.16

Sjekkliste for test (3) Sjekkpunkt Dato Ansvarlig Testplan for Markedstest (Market trial) er Elhub utarbeidet Interne arbeidsprosesser er tilpasset Elhub Intern opplæring er gjennomført Markedstest er gjennomført med godkjent resultat Ny VEE prosess er implementert M5 Alle markedsaktører er godkjent i Elhub 15.09.16 Markedsaktør Markedsaktør Markedsaktør Markedsaktør

Pilot-aktiviteter 1/7 2015 1/1 2016 M4: 1/5 2016 M5: 15/9 2016 Edielportalen ferdig utviklet Alle systemer er sertifisert Alle aktører er sertifisert Alle aktører godkjent i Elhub Systemsertifisering Edielportalen Aktørsertifisering Pilot 1 - Testing Edielportalen Elhub Testmiljø Leverandørtest Pilot 2 - Delta i systemtest Elhub Systemtest Elhub Elhub Pre-prodmiljø Markedstest Pilot 3 og 4 - Delta i akseptansetest og pilotering av Elhub Akseptansetest og pilotering Elhub