1. No category

Ekspertgruppemøte 6
Overordnet status
Statnett
12.februar 2015
Prosjektstatus - Fremdrift
År
Aktivitet
Måned
2013
2014
2015
2016
2017
2018
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 1
Kravspesifikasjon
Beslutningsport 2
Valg av leverandør
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
Q1
Q2
2016
Q3
Q4
M2
01.10.15
M1
01.06.15
Q1
M3
01.02.16
Q2
M4
01.05.16
Q3
Q4
M5
15.09.16
Datavask
Pilot migrering
Inkrementell migrering
MIGRERING
SYSTEMTILPASNING / TEST
Systemutvikling
Systemsertifisering
Edielportal
Systemgodkjenning
og pilottesting elhub
Aktørsertifisering
Edielportal
Aktørgodkjenning
elhub
Elhub
GO-LIVE
01.10.2016
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
Q3
M1
01.06.15
Formål
2016
Q4
M2
01.10.15
Q1
M3
01.02.16
Kriterier Migrering
• Sikre at aktøren har
• Rapport på spesifisert
identifisert alle data
format er oversendt til
som skal migreres
Elhub
• Gi en tidlig indikasjon på • Rapporten er fullstendig
datakvalitet på data som
i forhold til aktørens
skal migreres
målepunkter og kunder
• Få oversikt over
• Avtale om migrering
strukturdata i markedet
inngått med
• Sikre at aktør har inngått
systemleverandør
nødvendige avtale med
systemleverandører
Q2
M4
01.05.16
Q3
M5
15.09.16
Kriterier Test
• Avtale om
systemtilpasning og
test inngått med
systemleverandør
Q4
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.10.15
Q1
M3
01.02.16
Formål
Kriterier Migrering
• Sikre at aktører med lav
datakvalitet har
oppnådd en bedring
• Rapport på spesifisert
format er oversendt til
elhub
• Datakvalitet vurderes
som akseptabel
Q2
M4
01.05.16
Kriterier Test
Q3
M5
15.09.16
Q4
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.10.15
Q1
M3
01.02.16
Formål
Kriterier Migrering
• 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%
Q2
M4
01.05.16
Kriterier Test
Q3
M5
15.09.16
Q4
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.10.15
Q1
M3
01.02.16
Q2
M4
01.05.16
Q3
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
Q4
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.10.15
Q1
M3
01.02.16
Q2
M4
01.05.16
Q3
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 GOLIVE
• Datakvalitet
strukturdata i DAM >=
99,95%
• Komplette måleverdier
• Aktør er godkjent i
elhub (Market Trial
gjennomført)
Q4
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
DAM
Front
end
Kraftleverandør Periodisk kjøring
Validation
Nettselskap
05.02.2015
Migr.
DB
Elhub
migr.
Brosjyre som beskriver nettselskapers og
kraftleverandørers krav til datakvalitet og –
migrering i forbindelse med Elhub
Elhub
DB
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)
2)
3)
4)
K=O+P
OX <= O
OX + ON = O
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
EGEN-ID
15
A/16
FODSELSDATO
31
A/6
Avdeling hvis dette er aktuelt
Unik ID i kundens egen portefølje til bruk for tilbakematch når
data mottas i retur fra vask.
Hvis man har fødselsdato registrert legges denne her på forman
DDMMÅÅ
PERSONNR
37
A/5
NAVN
42
A/50
FORNAVN
92
A/50
ADRESSE
142
A/30
HUSNR
172
N/4
POSTNR
SYSTEM-DATA
176
180
N/4
A/21
Hvis man har personnummer registrert legges dette her.
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.
Postnummer der personen er bosatt.
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
Maskinell oppdatering (pr vask/vedlikehold) av register. Pris for neste
1.000 personer
Månedlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr
vask for første 1.000 personer
Månedlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr
vask for neste 1.000 personer
Ukentlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask
for første 1.000 personer
Ukentlig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask
for neste 1.000 personer
Daglig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask
for første 1.000 personer
Daglig maskinell oppdatering (vask/vedlikehold) av register. Pris pr vask
for neste 1.000 personer
Fortløpende oppdatering av utgåtte fnr/dnr og sperret adresse
-
-
Pr. oppdrag
kr
175,00
Pr. 1.000 personer
kr
2,00
Pr. oppdrag
kr
175,00
Pr. 1.000 personer
kr
2,00
Pr. oppdrag
kr
75,00
Pr. 1.000 personer
kr
1,50
Pr. oppdrag
kr
25,00
Pr. 1.000 personer
kr
1,00
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
Jan 2016
Feb 2016
Måleverdier
etc tilgj.
Strukturdata tilgj.
Uke før
go-live
Frys av
marked
Avlesninger
profilavregnede
NBS Go-live
For rapportering
av Elcert fra
2017
1/10 2016
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
Alle målepunkter leses av etter
overgang til nettområder men før
Elhub go-live
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:
Author:
Version:
Created:
Updated:
Migration conceptual information model
perber
1.0
03.12.2014 16:05:22
05.12.2014 13:52:55
Balance Supply
Contract
Metering Point
Balance Supply
Customer
Elhub inv oice
recipient
Elhub address
register
0..*
Metering Values
Grid Access
Contract
Elhub End-user
0..*
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
• Målepunktadresse
• Kundeadresse
Kraft
• Kundeidentifikasjon
• Relasjoner
• Kundeadresse
• Avgiftsinformasjon
QA på Migreringsdata og tilhørende entiteter
Avgifter
Målepunkt
adresse
Kontrakt
Kundeadresse
Alt.: Fullintegrerte
kundereferanser
Målepunkt
Kontrakt
Måleverdier
Kunde
Navn og info
Kunde
Navn og info
Kundeadresse
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å
Påkrevd kvalitetssikring av felter
(rødt = inngår i kritisk konsistenskontroll)
Påkrevd felter nettselskap
QAFil
Felt
krav
Fil
MeteringPointID
Må
Customer
Metering
ValidFrom
Må
Point
ValidTo
Må
SettlementMethodType
Må
MeteringMethodType
Må
MeteringPointLoadLimit
Bør
MeteringPointInstalledEffect Må
ReportingFrequency
Kan
MeteringPointSubType
Må
SettlementConstant
Kan
MeterDigits
Kan
MeteringGridAreaUsed
Må
OutAreaUsed
Må
MeteringPointType
Må
MeteringPointStatus
Må
Contract
MeterIdentification
Kan
MeteringPointAccountable Ikke rel.
GardsNr
Bør
BruksNr
Bør
SeksjonsNr
Bør
FesteNr
Bør
BuildingNumber
Bør
PostCode
Bør
MunicipalityCode
Bør
Påkrevd felter nettselskap
Påkrevd felter nettselskap
QAFil
Felt
Felt
krav
ResultMeteringPoint
CustomerReference
Må
Formula
ValidFrom
AddressType
Må
ValidTo
ValidFrom
Må
FormulaItemNumber
ValidTo
Må
FormulaNumberOfItems
CustomerIdentity
Må
FormulaItemIdentification
CustomerIdentityType
Må
MeteringPointReferenced
Nationality
Må
ArithmeticOperation
FirstName
Må
LastName
Må
Metering MeteringPointUsed
TimeSeriesType
CompanyName
Må
Value
ProductType
BuildingNumber
Kan
UnitType
StreetName
Kan
StartDate
PostCode
Kan
EndDate
CountryCode
Kan
QuantityQuality
MeteringPointUsed
Må
RegistrationDateTime
ValidFrom
Må
Quantity
ValidTo
Må
ValidationCode
CustomerReferenceEndUser Må
EstimationCode
GridAccessProvider
Må
VolumeCategoryCode
BalanceSupplierUsed
Må
ExpectedAnnualConsumption
BalanceResponsibleParty
Må
MeterReadingOriginType
NACE_Code
Må
ElCertificateShare
Må
EnovaFeeShare
Må
EnovaFeeType
Må
ElFeeShare
Må
ValueAddedTaxShare
Må
EndReason
Må
QAkrav
Kan
Kan
Kan
Kan
Kan
Kan
Kan
Kan
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Påkrevd kvalitetssikring av felter
(rødt = inngår i kritisk konsistenskontroll)
Fil
Contract
Customer
Påkrevd felter kraftleverandører
Felt
MeteringPointUsed
ValidFrom
ValidTo
CustomerReferenceEndUser
GridAccessProvider
BalanceSupplierUsed
BalanceResponsibleParty
NACE_Code
EndReason
CustomerReference
AddressType
ValidFrom
ValidTo
CustomerIdentity
CustomerIdentityType
Nationality
FirstName
LastName
CompanyName
StreetName
PostCode
CountryCode
QA-krav
Må
Må
Må
Må
Må
Må
Må
Kan
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Må
Kan
Kan
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
Avgifter
5.000 kraftkunder
Alt.: 20.000 integrerte kunder
30.000 målepunkter
Målepunkt
adresse
Kontrakt
Kunde
Navn og info
Kundeadresse
Alt.: Vertikalintegrerte
kundereferanser
Målepunkt
Kontrakt
Kunde
Navn og info
Kundeadresse
10.000 nettkunder
20.000 integrerte kunder
Måleverdier
Avgifter
30.000 nettkontrakter
Case. Aktør med:
- 5.000 rene kraftkunder (kun kraftkunder)
- 10.000 rene nettkunder (kun nettkunder)
- 20.000 vertikalintegrerte kunder (kraft og nett)
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
Kraftselskap som autoritativ kilde
• Via Nubix er Nettselskapene i
prinsippet master i dag
• 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.
• 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
•
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
Kundeadresse
Alt.: Fullintegrerte
kundereferanser
Målepunkt
Kontrakt
Måleverdier
Kunde
Navn og info
Kunde
Navn og info
?
Kundeadresse
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
Contract ValueAddedTaxShare
Customer CompanyName
Customer CustomerIdentity
Confluence
QA-ansvar
Beskrivelse av endring
Confluence
MVA for kraft og nett, derfor begge
Required.
IntegritetsbegrensningFeil i dokumentet.
Confluence
Påkrevd
Generelt
MeteringPoint BuildingNumber
Intern QA
Confluence
Skrivefeil
Begrepsavklaring
MeteringPoint MeterDigits
Confluence
Formatdefinisjon
Konklusjon
Setter QA grid owner = Required
Skal være:
M if FirstName == NA
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.
adress -> address
BuildingNumber kommer fra både
1. Følger HNR med BuildingNumber
HNR og ebIX, og er sånt sett noe i
for "husnummer".
motstrid til Matrikkelens
2. For samsvar med notasjon i HNR
"Husnummer". Dette også relatert til (feltet eksisterer imidlertid ikke der)
splitt av BuildingNumber og
benyttes BuildingLetter for
BUildingLetter. Merk samtidig at
"bokstav".
Matrikkelen også opererer med
"bokstav" som mulig felt i en adresse,
og at disse dermed er skilt fra
hverandre.
Vi bør fastsette format på dette
Forslag: dec(4.1)
feltet, hvorvidt vi skal ha desimaler, Dvs. totalt 4 tegn inkl. komma, og
og i så fall hvor mange.
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
Navn på endring
Beskrivelse av endring
Konklusjon
MeteringPoint Intern QA
MeteringMethodType
Endre enumerasjon
Endre alternativer til:
E13 Automated
E14 Manual read
E16 Not read
E24 Calculated
MeteringPoint Confluence
MeteringPointLoadLimi
t
MeteringPoint Confluence
MeteringPointStatus
MeteringPoint Confluence
MeteringPointType
MeteringPoint Confluence
MunicipalityCode
Manglende rad i tabell
Må dobbeltsjekkes med Erik. Må
stemme overens med ebIX, BIM (og
kanskje HNR). Her ble det
introdusert noen feil i forbindelse
med oversettelsen.
Setter inn Dependencies med
beskrivelse.
MeteringValue EstimationCode
Kilde
Manglende rad i tabell
Setter inn Format med beskrivelse.
Manglende rad i tabell
Setter inn Format med beskrivelse.
Integritetsbegrensning
Conditional.
M if (StreetCode != NA or Gnr != NA)
Mandatory if either Gnr or
StreetCode is set.
Enumerasjon oppdateres med
fullstendig liste over koder og
tilhørende beskrivelser.
Gjennomgang Inkonsistent med BIM • E001 Actual volume and history
og VEE
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.
Endringer (3 av 4)
Kapittel
Kilde
MeteringValue EstimationCode
MigreringsteamPåkrevd
MeteringValue ValidationCode
Confluence
XXX - BuildingNumber Confluence
XXX FloorIdentification
Confluence
Navn på endring
Beskrivelse av endring
Konklusjon
Dette feltet (og ValidationCode) er Forslag: Endre forutsetningene for
ikke egentlig påkrevd i migreringen. Conditional på begge feltene.
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.
Inkonsistent med BIM • V001 Power failure
Enumerasjon oppdateres med
og VEE
• V002 Missing interval values
fullstendig liste over koder og
• V003 Register errors
tilhørende beskrivelser, inkl.
• V004 Time stamp
korrigere eksempel (som har en "0"
• V011 Positive numerical value
for mye).
• V012 Active versus reactive energy
• V013 Volumes versus meter
reading
Avvikende format
Kundefilen angir text(10) som format, Forslag: Num(5)
mellom målepunkt og mens målepunktfilen angir num(10). Dette skal være en numerisk verdi
kunde-filene
uansett (bokstav er eget felt), og
denne verdien angir høyeste
gatenummer til 99999. Antar dette
vil være tilstrekkelig, også for
internasjonale adresser?
Mangler spesifikasjon
Forslag: string(10)
av formatlengde
Muliggjør alternative beskrivelser på
etasjer, inkl. "KJELLER", "LOFT",
"H01", "U01", "K01", "L01", osv.
Endringer (4 av 4)
Kapittel
Kilde
Navn på endring
XXX - StreetName
Confluence
Forslag til revidert
lengde
XXXRoomIdentification
Confluence
XXX-CareOF og
XXX_Attention
Confluence
Beskrivelse av endring
Konklusjon
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.
Mangler spesifikasjon
Forslag: string(10)
av formatlengde
Tilrettelegger dermed for
alternativer som eksempelvis
"HØYRE", "VENSTRE", "01", "02",
osv.
Prefiks eller ikke?
Beskrivelsen er utydelig, må
Anbefaler at navn fylles inn UTEN
presiseres hva som skal være med. prefiks.
EDIEL-dokumentasjon angir verkeneller, så dette er opp til
Vil i så fall oppdatere
migreringsløpet og Elhub å fastsette. feltbeskrivelsene til å gjenspeile
I og med at feltene har klart definerte dette.
formål, synes et prefiks å være både
unødvendig, forstyrrende og kilde til
feil.
Diskusjonstemaer (1 av 4)
Kapittel
Kilde
Contract - NACE_Code Confluence
Navn på endring
Beskrivelse av endring
Konklusjon
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
Customer Confluence
CustomerIdentityType
Navn på endring
Beskrivelse av endring
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?
Konklusjon
Anbefaler alternativ 2 med følgende
innledende liste over
enumerasjoner:
1. passnummer
2. nasjonalt identitetsnummer
3. førerkortnummer
1. Feltet kunne vært vurdert fjernet 4. fødselsdato
dersom CustomerIdentity også angir 5. Annen identifikator
type identitet - eksempelvis: Pass123456789. Dette krever at type
Logikken må her være en prioritert
identitet skrives likt av alle alltid.
rekkefølge på identetstypene ut fra
2. Feltet kan settes som
listen over. Det betyr eksempelvis at
enumerasjon slik at valgene alltid er dersom et passnummer foreligger,
entydige. Siden utfallsrommet av
skal ikke fødselsdato oppgis.
dette feltet ikke er klart, må dette i
så fall være en enumerasjon som det I utvidet forslag:
tillates lagt inn nye verdier i (fra
1. fødsels-/D-nummer
Elhubs side).
2. passnummer
3. nasjonalt identitetsnummer
Utvidet forslag:
4. førerkortnummer
Sette feltet til Mandatory, og fylles ut5. fødselsdato
også for norske sluttbrukere for å
6. Annen identifikator
angi type identitet som foreligger. 7. Standard/kunstig identifikator
(eks. standard dato e.l.)
8. Ingen identifikator
Diskusjonstemaer (3 av 4)
Kapittel
Kilde
Navn på endring
Beskrivelse av endring
Customer - xxxName
Confluence
Feltlengde
Det er benyttet forskjellige
feltlengder i forskjellige
dokumenter og definisjoner, samt
forskjellig antall felter på navn.
Konklusjon
Forslag:
1. FirstName - string(80), dvs. 2 x 40
tegn, omfatter for- og mellomnavn.
2. LastName - string (40), omfatter
kun (hele) etternavnet.
Dette må harmoniseres med en klar 3. CompanyName - string(80), som i
begrunnelse, og vurderes overført til dag, ingen endring.
BIM der relevant, evt beskrives
hvorfor ikke.
Format og beskrivelse i dokumentet
Dette omfatter feltene: FirstName, oppdateres for å gjenspeile dette.
LastName, MiddleName,
CompanyName.
Folkeregisteret omfatter tre navn på
personer, og en normal feltlengde
per navn er ofte 35 tegn.
MeteringValue Gjennomgang Konsistens med BIM For profilavregnede målepunkt skal På hvilken måte er migreringsfilene
ExpectedAnnualConsu
feltet sendes inn sammen med
inkonsistent med BIM?
mption
avlesninger (siden en avlesning
krever oppdatert årsforbruk).
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
MeteringValue Gjennomgang Konsistens med BIM På hvilken måte er migreringsfilene
MeterReadingOriginTy
inkonsistent med BIM?
pe
Det benyttes samme koder med
samme betydning, selv om
enumerasjonen i BIM heter "Meter
read reason code" i feltet "Reason
for meter reading".
MeteringValue Confluence
Integritetsbegrensnin Feltet er Mandatory.
TimeSeriesType
g
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)
Konklusjon
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
Contract Confluence
ElCertificateShare (og
andre tilsvarende
decimal-felter)
Customer AddressType
Eksempelfiler
Confluence
Confluence
MeteringPoint Intern QA
MeteringMethodType
MeteringPoint Intern QA
ReportingFrequency
Navn på
endring
Beskrivelse av endring
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.
Mangler spesifikasjon Feltet er en enumerasjon, og
av formatlengde
lengden er derfor ikke relevant.
Spørsmål
Eksempelfiler oppdatert?
Eksempelfiler vil representeres på
ny måte - som (nedlastbare)
vedlegg i Confluence, og ikke som
tekst. Kommentarer til dette?
Endre navn
Endre navn til
Tas til følge
MeterReadingCharacteristics
Oppløsning for
Eksempel endret fra 8760 til 365. Beskrivelse oppdateres.
avlesninger
Informasjonspunkter (1 av 2)
Kapittel
Kilde
MeteringValue Confluence
RegistrationVersionNu
mber
Navn på
endring
Beskrivelse av endring
Spørsmål
Dette feltet er tatt med som et
valgfritt felt, men ellers på linje med
Validation- og EstimationCode.
Konklusjon
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.
MeteringValue Gjennomgang Spørsmål
VolumeCategoryCode
Det er således opp til nettselskap å
angi hvorvidt dette feltet skal
benyttes.
I migreringssammenheng er det
Feltet må fylles ut og sendes inn
nødvendig å få informasjon om
som angitt i filformatet, men er ikke
hvordan en verdi er oppstått. Dette relevant for BIM eller Elhub
er informasjon som Elhub vil utlede informasjonsmodell.
etter go-live, og er således ikke
nødvendig etter det tidspunktet.
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
Q1
Q2
2016
Q3
Q4
M2
01.10.15
M1
01.06.15
Q1
M3
01.02.16
Q2
M4
01.05.16
Q3
Q4
M5
15.09.16
Datavask
Pilot migrering
Inkrementell migrering
MIGRERING
SYSTEMTILPASNING / TEST
Systemutvikling
Systemsertifisering
Edielportal
Systemgodkjenning
og pilottesting elhub
Aktørsertifisering
Edielportal
Aktørgodkjenning
elhub
Elhub
GO-LIVE
01.10.2016
Sjekkliste for test (1)
Sjekkpunkt
Dato
Elhub-spesifikasjoner er ferdigstilt og publisert
Utviklings- og testprosjektet er planlagt
Krav til systemendringer er spesifisert
Krav til endringer i prosess og organisasjon er
spesifisert
Løsningsbeskrivelse og arkitektur er etablert
Avtale om utvikling og test er inngått med
systemleverandør
Edielportalen er under utvikling og klar for initiell test
Brukermanual for Systemsertifisering er utarbeidet
M1 Alle markedsaktører har inngått avtale med
01.06.15
systemleverandør om systemtilpasning og test
Ansvarlig
Elhub
Markedsaktør
Markedsaktør
Markedsaktør
Markedsaktør
Markedsaktør
Elhub
Elhub
Sjekkliste for test (2)
Sjekkpunkt
Systemet er klargjort for Systemsertifisering
Systemsertifisering i Edielportalen er gjennomført
Testplan for Leverandørtest (Vendor trial) er
utarbeidet
Elhub er klargjort for Leverandørtest
Systemet er klargjort for Leverandørtest
Leverandørtest er gjennomført
Sertifisert system er installert hos markedsaktør
Aktørsertifisering i Edielportalen er gjennomført
M4 Alle markedsaktører er sertifisert i
Edielportalen
Dato
Ansvarlig
Systemleverandør
Systemleverandør
Elhub
Elhub
Systemleverandør
Systemleverandør
Markedsaktør
Markedsaktør
01.05.16
Sjekkliste for test (3)
Sjekkpunkt
Testplan for Markedstest (Market trial) er
utarbeidet
Interne arbeidsprosesser er tilpasset Elhub
Dato
Ansvarlig
Elhub
Markedsaktør
Intern opplæring er gjennomført
Markedsaktør
Markedstest er gjennomført med godkjent resultat
Markedsaktør
Ny VEE prosess er implementert
Markedsaktør
M5 Alle markedsaktører er godkjent i Elhub
15.09.16
Pilot-aktiviteter
1/1 2016
1/7 2015
M4: 1/5 2016
Alle systemer
er sertifisert
Edielportalen
ferdig utviklet
Systemsertifisering
Alle aktører
er sertifisert
M5: 15/9 2016
Alle aktører
godkjent i Elhub
Edielportalen
Aktørsertifisering
Pilot 1 Testing Edielportalen
Pilot 2 Delta i systemtest
Elhub
Elhub Testmiljø
Leverandørtest
Systemtest Elhub
Pilot 3 og 4 - Delta i
akseptansetest og pilotering av Elhub
Elhub Pre-prodmiljø
Markedstest
Akseptansetest og
pilotering Elhub
Krav til pilotaktører
• Må ha utført nødvendige systemtilpasninger
• Må ha et miljø som er satt opp for test og kan
kommunisere med Elhub
• Må ha gjort klart testsystemet med nødvendige
testdata
• Må delta i planlegging av tester
• Må gjennomføre tester i henhold til plan
• Må delta i statusmøter og rapportere testresultater til
Elhub
Ressursbehov Pilot 1
• Pilottest Edielportalen - Q3 2015 og Q1 2016
– Delta i utprøving av ny versjon av Edielportalen som skal brukes for
sertifisering mot Elhub
– Fase 1 er systemsertifisering og Fase 2 er aktørsertifisering
• Deltakere Fase 1: Systemleverandører
• Deltakere Fase 2: Markedsaktører
• Antatt ressursbehov pr. pilotaktør:
5 dagsverk i løpet av 1 måned
Ressursbehov Pilot 2
• Systemtest Elhub – Q1 2016
– Delta i funksjonelle tester av Elhub (markedsprosesser, GUI mm.). Vil
være samfallende med leverandørtest.
• Deltakere: Systemleverandører og Markedsaktører
• Antatt ressursbehov pr. pilotaktør:
Systemleverandører: 5-15 dagsverk i løpet av 3 måneder
(Usikkert hvor mye av piloten som er ekstraarbeid ut over den
testen som systemleverandører uansett må gjennomføre)
Markedsaktører: 5 dagsverk i løpet av 3 måneder
Ressursbehov Pilot 3
• Akseptansetest Elhub – Q3 2016
– Delta i funksjonelle tester av Elhub som del av Akseptanse av løsningen
(markedsprosesser, GUI mm.).
• Deltakere: Markedsaktører
• Antatt ressursbehov pr. pilotaktør :
12 dagsverk i løpet av 3 måneder
Ressursbehov Pilot 4
• Pilot Elhub – Q3 2016
– Delta i pilotering av Elhub som forberedelse til produksjonssetting av
løsningen
• Deltakere: Markedsaktører
• Antatt ressursbehov pr. pilotaktør:
6 dagsverk i løpet av 3 måneder
Deltakere Pilot 1
• Pilottest Edielportalen - Q3 2015
– Delta i utprøving av ny versjon av Edielportalen som skal brukes for
sertifisering mot Elhub. Fase 1 er systemsertifisering.
• Antatt ressursbehov: 5 dagsverk i løpet av 1 måned
• Trenger dekning for alle roller og prosesskomponenter
• Mulige deltakere
– Enoro, CGI, Tieto/Hafslund
– Powell/Valider
– Brady, Sonlinc
– Andre systemleverandører