Overordnet tidsplan test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 DATAVASK OG MIGRERING M1 01.07.15 Grunnleggende datavask Uttrekk grunndata M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 Kontinuerlig datavask og datavedlikehold M6 15.01.17 SYSTEMTILPASNING / TEST AVHENGIGHETER Pilot migrering DAMv1.1 levert 01.09.2015 Systemtilpasning Systemsertifisering Edielportal MGA pr målepunkt definert Jan 2015 Edielportal (inkl B2B) klar Jan 2015 DAM v2 levert 15.12.2015 Elhub klar for Vendor Trial 01.05.2016 Inkrementell migrering Systemgodkj. Elhub NBS Go-Live 03.10.2016 Aktørsert. Edielportal Elhub klar for Market Trial 01.09.2016 Aktørgodkjenning Elhub Elhub in production 01.02.2017 Elhub GO-LIVE 20.02.2017
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status Sikre at aktøren har korrekt identifisert alle data som skal migreres Gi en tidlig indikasjon på datakvalitet på data som skal migreres Få totaloversikt over strukturdata i markedet Sikre at aktør har lagt nødvendige planer for migrering og test Statnetts datakvalitetsundersøkelse er besvart Aktør har utarbeidet overordnet plan for datavask og migrering Aktør har spesifisert krav til endringer i sine ITsystemer Aktør har utarbeidet overordnet plan for systemtilpasning og test
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status Sikre at aktør har bedret sin datakvalitet Sikre at aktør er i stand til å gjøre uttrekk fra egne systemer på spesifisert filformat og oversende disse til DAM Etablere infrastruktur for migrering Få indikasjon på omfang av inkonsistens på porteføljenivå Aktør har oversendt målepunkt-, kontrakt- og kundefiler for hele porteføljen til Elhub DAM Grunnleggende datavask er gjennomført Alle målepunkter er unike med GSRN/EAN (Ingen duplikater) Org. nummer er innhentet for alle bedriftskunder Støtte for innhenting av fødselsnr er implementert i aktørs ITsystem
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status Sikre at datakvalitet på migrerte grunndata/strukturdata er på akseptabelt nivå Sikre at systemtilpasning pågår i henhold til plan Aktør har oversendt målepunkt-, kontrakt- og kundefiler for hele porteføljen til Elhub DAM, med gjeldende data frem til 01.02.2016 eller senere Datakvalitetskrav for M3 oppfylt Aktørs system skal være sertifisert i Edielportalen Fødselsnr innhentet
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status Sikre at datakvalitet på migrerte data er høy Sikre at aktøren har tilpasset sitt forretningssystem til elhub Aktør har oversendt målepunkt-, kontrakt-, kunde- og måleverdifiler for hele porteføljen til Elhub DAM, med gjeldende data frem til 01.06.2016 eller senere. Historikk på måleverdier fra 01.05.2016 Datakvalitetskrav for M4 oppfylt Aktørs system skal være godkjent i Elhub
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status Sikre at datakvalitet på migrerte data er høy Sikre at aktøren har tilpasset sitt forretningssystem til elhub Aktør har oversendt målepunkt-, kontrakt-, kunde- og måleverdifiler for hele porteføljen til Elhub DAM, med gjeldende data frem til 01.09.2016 eller senere Datakvalitetskrav for M5 oppfylt Aktør er sertifisert i Edielportalen Aktør har inngått brukeravtale med Elhub Kraftleverandør har implementert prosess for kvalitetssikring og vedlikehold av fødselsnr
Aktørmilepæler - test og migrering 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 M1 01.07.15 M2 01.11.15 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 Formål Akseptansekriterier Anbefalt status 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 Aktør har oversendt målepunkt-, kontrakt-, kundeog måleverdifiler for hele porteføljen til Elhub DAM, med gjeldende data frem til 01.01.2017 eller senere Datakvalitetskrav for M6 oppfylt Aktør er godkjent i Elhub (Market Trial gjennomført)
Datakvalitetskrav for data migrert til DAM Nettselskaper kritikalitetsnivå 1 Nettselskaper kritikalitetsnivå 2 Kraftleverandører kritikalitetsnivå 1 Kraftleverandører kritikalitetsnivå 2 M3 01.03.16 M4 01.07.16 M5 01.11.16 M6 15.01.17 95% 99% 99,9% 99,98% Ingen 95% 98% 99,0% 95% 99% 99,9% 99,98% Ingen 95% 98% 99,0%
Click to edit Master title style Aktørtesting Ekspertgruppemøte 15.oktober 2015
Agenda Plan for gjennomføring av aktørtesting Testmiljø og testdata Hvilke systemer skal sertifiseres? Sjekkliste for aktører Demo av Edielportalen
Milepælplan for aktørtesting 5/10 2015 1/3 2016 1/7 2016 1/11 2016 15/1 2017 Edielportalen er klar for pilotering Alle systemer er sertifisert Alle systemer er godkjent i Elhub Alle aktører er sertifisert Alle aktører er godkjent i Elhub Systemsertifisering Edielportalen Aktørsertifisering Elhub Testmiljø Leverandørtest Elhub Pre-prodmiljø Aktørgodkjenning
Systemsertifisering i Edielportalen Hensikt: Teste at systemene støtter tekniske krav til utveksling i EMIF inkl. krav til komprimering, signering og kryptering Teste at systemene kan sende/motta alle relevante Elhub-meldinger (i henhold til rolle) Teste at systemene støtter alle relevante prosesskomponenter Deltakere: Systemleverandører Edielportalen Gjennomføring: Systemleverandører gjennomfører selvbetjente tester og sertifisering med support fra Elhub test-team
Leverandørtest i Elhub Hensikt: Teste at systemene kan utveksle meldinger med Elhub ihht. tekniske krav i EMIF Teste at systemene kan utføre alle relevante prosesser (BRS) mot Elhub Deltakere: Systemleverandører Elhub Gjennomføring: Elhub test-team planlegger og administrerer testen som gjennomføres av systemleverandører Både selvbetjente, individuelle tester og ende-til-ende tester som kan involvere flere systemer
Aktørsertifisering i Edielportalen Hensikt: Teste at aktørenes systemer kan kommunisere med Edielportalen Teste at aktørene kan prosessere utvalgte, viktige markedsprosesser/brs er i henhold til sin rolle Deltakere: Markedsaktører Edielportalen Forutsetning: Systemet/versjonen som brukes av aktøren er sertifisert i Edielportalen Aktørene må enten ha et testsystem eller legge inn testdata i produksjonssystemet og kjøre testen fra produksjonssystemet Gjennomføring: Markedsaktørene gjennomfører selvbetjente tester med support fra Elhub testteam og egne systemleverandører
Aktørgodkjenning i Elhub Hensikt: Verifisere at markedsaktører kan kommunisere med Elhubs testsystem og klarer å sende og hente meldinger Deltakere: Markedsaktører Elhub Forutsetning: Aktørene må enten ha et testsystem eller legge inn testdata i sitt produksjonssystem og kjøre testen fra produksjonssystemet Gjennomføring: Elhub test-team planlegger og følger opp tester som gjennomføres av markedsaktører Vil omfatte queries og enkelte prosesser.
Test- og sertifiseringsløp EDIELPORTALEN Systemsertifisering Verifisering av at aktørens IT system støtter Elhubs spesifikasjoner, for alle relevante roller Omfang: Alle relevante meldinger Alle relevante prosesskomponenter Teknisk grensesnitt Aktørsertifisering Verifisering av aktørens installasjon og aktørens forståelse for de viktigste prosessene ihht aktuell rolle Omfang: Viktigste prosesser Teknisk grensesnitt ELHUB TESTMILJØ Systemgodkjenning Verifisering av at aktørens system kan kommunisere med Elhub og at prosessene fungerer i Elhub Omfang: Alle relevante prosesser Teknisk grensesnitt Aktørgodkjenning Verifisering av at aktørens installasjon fungerer mot Elhubs testsystem Omfang: Queries og enkelte prosesser Teknisk grensesnitt
Mulige testoppsett hos aktørene Alternativ 1 Med testmiljø Aktøren har et eget testmiljø der det er mulig å legge inn og manipulere testdata for å teste mot Edielportalen og Elhub. Dette gir mulighet for å kjøre mer omfattende tester som medfører endring i data. Markedsaktør Statnett/Elhub Eksisterende produksjons system Aktørens testsystem for Elhub Edielportalen Elhub testmiljø Produksjons- DB Test-DB
Mulige testoppsett hos aktørene Alternativ 2 Uten testmiljø Aktøren har ikke eget testmiljø og må teste fra en Elhub-installasjon i produksjonsmiljøet. Her må det være mulig å legge testdata inn i produksjonsdatabasen. Markedsaktør Statnett/Elhub Eksisterende produksjons system Aktørens testsystem for Elhub Edielportalen Elhub testmiljø Produksjons- DB
Aktørtest i forhold til Cut-over/Go-live 1/7 2016 1/11 2016 15/1 2017 1/2 2017 8/2 2017 20/2 2017 Edielportalen er klar for aktørsertifisering Alle aktører er sertifisert Alle aktører er godkjent i Elhub Elhub er i produksjon Start frysperiode Elhub Go-live Edielportalen Aktørsertifisering Elhub Pre-prodmiljø Aktørgodkjenning Elhub Prodmiljø Aktørverifisering 3/10 2016: NBS Go-live
Spørsmål til Ekspertgruppen Hvordan vil markedet reagere dersom det kommer et krav om at alle aktører enten har testsystem eller må legge testdata i sitt produksjonssystem? Dersom vi kun kan teste uten testdata legger dette begrensninger på hvilke tester som kan kjøres Hvilke typer av tester kan gjennomføres parallelt med EDIFACTutveksling? Spørringer (sending/mottak uten endring av data) Innsending av måleverdier (kun sending) Leverandørbytter (sending/mottak med endring av data)
Spørsmål til Ekspertgruppen Er det mulig å bruke test mot Edielportalen/Elhub som en opplæring av aktørene? Forutsetter test av utvalgte prosesser og ikke bare en teknisk test Krever høyst sannsynlig at aktørene har et testmiljø Har dere andre innspill til hvordan vi best kan verifisere at aktørene er klare for Elhub 20/2 2017?
BRS-NO-101: Oppstart kraftleveranse - leverandørskifte sd Skift lev erandør Kraftleverandør Elhub Nettselskap Ny kraftleverandør Gammel kraftleverandør Målepunktadministrator Nettilknytningstilbyder 1-oppstart kraftleveranse(leverandørskifte) {etter siste frist for kansellering} Meldingsfrist: - senest tre virkedager før oppstartsdato for ikke-fjernavlest - senest kalenderdagen før oppstartsdato for fjernavlest - tidligst seks virkedager før oppstartsdato for ikke-fjernavlest - tidligst fire kalenderdager før oppstartsdato for fjernavlest 6-oppdater grunndata(leverandørskifte) 11-Opphør kraftleveranse(leverandørskifte) 14-Oppstart i målepunkt(leverandørskifte) {senest 3 virkedager etter skiftedato for ikke fjernavlest} 16-måleverdier(Periodevolum, stand) 7-måleverdier(Periodevolum, stand) 7-måleverdier(Periodevolum, stand) {senest kalenderdagen etter for fjernavlest} 16-Måleverdier(Volumserie) 7-Måleverdier(Volumserie) A (from Roller) (from Roller) (from Roller) (from Roller) Name: Skift leverandør Author: perber Version: 1.0 Created: 11.12.2013 15:51:51 Updated: 13.05.2014 14:14:07
Prosesskomponent 1- Oppstart kraftleveranse
BRS-NO-312_ Oversendelse av måleverdier for profilavregnede målepunkt
Integrasjonslag Alternative systemoppsett Markedsaktør Allianse/ Tjenesteleverandør Statnett EDIsystem Sentralsystem KIS Innsamling Alt. 3 Alt. 2 Alt. 1 Edielportalen/ Elhub
Sjekkliste for aktører Gjennomgang av revidert versjon Ligger ute på Elhub.no Nettsiden vil bli oppdatert fortløpende med mer informasjon om aktørtestingen
Utvikling Edielportalen Systemsertifisering (TGT) Første versjon ble lansert 5.oktober 2015 med enkelt teknisk grensesnitt og utvalgte prosesskomponenter Prosesskomponent / og meldinger Melding Nye meldinger lanseres fortløpende med ambisjon om ferdigstilling i løpet av 2015 Neste utgivelse 9.november vil også omfatte endringer på test-casene som ble lagt ut 5.oktober Plan for neste utgivelse vil bli lagt ut på elhub.no. 11 End of supply to Balance Supplier 8 NotifyEndOfSupply 13 Start in metering point from Grid Access Provider 1 RequestStartOfSupplyRequest 2 ConfirmStartOfSupply 3 RejectStartOfSupply 14 Start in metering point to Grid Access Provider 4 NotifyStartOfSupply 22 End in metering point from Grid Access Provider 5 RequestEndOfSupplyRequest 6 ConfirmEndOfSupply 7 RejectEndOfSupply 23 End in metering point to Grid Access Provider 6 NotifyEndOfSupply
Demo av Edielportalen Demo av løsning for systemsertifisering (TGT) som ble lansert 5.oktober Edielportalen
Click to edit Master title style Elhub Market-driven performance 15.10.2015 trond.stromme@statnett.no
Elhub challenging traffic volumes High volume of incoming files with a large number of incoming meter reads 70.000.000 daily ingoing meter reads (2019) 500.000.000 meter reads distributed on peak day (2017) 180.000 business processes per hour Incoming files up to 52MB Potentially a large proportion of resending Data history of 3-10 years
Elhub Load Model Meter Reads 1 mill. AMS meters 24 mill. meter values/day
Elhub Load Model Meter Reads
Elhub Load Model Our starting point for business processes
Elhub Load Model Time distribution for business processes Assumption: Majority of business process initiation will happen during business hours
Performance Requirements Documentation Time distribution
Assumptions, questions The majority of business processes will be initiated during business hours? Will there be market party initiated batching of processes? Do our volumes on BRS' check out? Elhub will be very reliant on Market Parties' behavior. Feedback loops: Poor, missing data in Meter Readings will trigger BRS-NO-314 Reminders of Metering Values and EAC from Grid Owner.. Which triggers processes at Market Parties' end Which triggers more volumes of meter reads to Elhub Will you use us as the Yellow Pages? Monthly dump of your structure/master data to verify your state (NECS pattern..)
Elhub Ekspertgruppemøte - Forretningsprosesser før og etter go-live 2015.10.15
Oppsummering av noen viktige endringer i Elhub fra dagens markedsprosesser Markedsaktører må legge prosesser/meldinger på vent/kø i eget system for å overholde Elhub sine tidsfrister Opphør kan ikke gjøres bakover i tid Nettselskap vil ikke ha mulighet å avvise prosess fra kraftleverandør. Elhub foretar alle valideringer. Reversering av Elhub-prosesser er automatiske og må gjøres i omvendt kronologisk rekkefølge Meldinger om at grunndata har blitt oppdatert må håndteres av både nettselskap og kraftleverandør 16.10.2015 41
Oppsummering av noen viktige endringer i Elhub fra dagens måleverdiprosesser Det vil være mulig å hente ut timesvolumer på alle profilavregnede målepunkt Kun Elhub kan estimere volumer, nettselskapet skal kun sende avlesninger og omforente stipuleringer. Både nettselskap og kraftleverandør kan estimere periodevolum for fakturering basert på forrige avlesning + estimerte timevolumer fra Elhub. Disse estimeringene skal ikke ende opp som «avlesninger» som sendes Elhub. Tilbaketrekking av måleverdier for profilavregnede målepunkt skal nå ikke inneholde gamle verdier, kun nye erstatningsverdier Måleverdier for timesavregnede målepunkt skal sendes med alle 24 timene samlet i 1 melding mellom midnatt og 07:00. Måleverdier for Plusskunder skal sendes inn på 1 målepunkt med 2 kanaler. 16.10.2015 42
Flere viktige endringer i Elhub fra dagens prosesser? De fleste aggregeringer og beregninger overføres fra nettselskap til Elhub Saldooppgjør og korreksjonsoppgjør kjøres månedlig Korreksjonsoppgjøret gjøres opp finansielt av nettselskapet. Sub-nett under f.eks. fellesmåling slippes inn i Elhub, og de fleste prosessene vil håndteres likt som i andre nettområder Flere ting dere mener er viktige endringer fra dagens prosesser? 16.10.2015 43
Endringer som vurderes ifm. neste versjon av BRS dokumentene Elhub vil automatisk informere nettselskap når BRS-NO-102 Innflytting frem i tid skjer i inaktivt målepunkt. Dette istedenfor at BRS-NO-601 Forespørsel til nettselskap brukes. Mulighet for direkte kansellering fjernes, men prosessen vil indirekte kanselleres hvis målepunktet ikke aktiveres. Aktivering tilbake i tid gjøres gjennom BRS-NO-402 Korrigering i grunndata fra nettselskap. Felt for målepunktstatus blir gjeninnført i BIM for å håndtere dette. BRS-NO-401 Korrigering i grunndata fra kraftleverandør fjernes, da grunndata på sluttbruker ikke har gyldighetsperiode. Strengere valideringer for oppdatering av grunndata; melding får kun inneholde de felter som kan endres i den enkelte prosessen. F.eks. kan melding om å starte BRS- NO-302 Oppdatering av grunndata nettselskap ikke inneholde avregningsform siden dette må endres i BRS-NO-306 Endring i avregningsform. En rekke mindre feil i tekst og validering spesielt. Fortsett med å finne feil! 16.10.2015 44
Endringer i ny 1.4 versjon av BIM «Trimmet» meldinger for måleverdier inn (CollectedData) og ut (NotifyValidatedDataForBillingEnergy) ved å fjerne 2 nivåer (Sequence og Quantity) Lagt til element Stipulert i Måleverdier inn (periodevolum) Lagt til element Kalkulert i Måleverdier ut (intervall volum) Fjernet MeteringPointAcountable i MeteringPoint, men lagt til Code Z01 Unsettled i SettlementMethod Fjernet Balance Responsible Party i markedsprosess meldinger Fjernet mellomnavn i sluttbruker. Utvidet fornavn fra 40 til 80 tegn. + en del mindre feilretting / justering 16.10.2015 45
Hovedpunkter for cut-over plan for markedsprosesser 1. Elhub ønsker at sluttbrukere skal merke så lite som mulig av overgangen til Elhub. Markedsaktører skal kunne fortsette sine forretningsaktiviteter. 2. Hendelser som skjer i frysperioden registreres hos markedsaktøren og sendes til Elhub fra og med oppstartsdag Avveining må gjøres for graden av systemstøtte vs. manuelt arbeid 3. Hendelser som registreres fremover i tid i frysperioden må sendes inn til Elhub som endring bakover i tid etter oppstartsdag 4. Ingen prosesser kan ha en endringsdato etter Elhub go-live i de gamle systemene. Bør legges inn sjekk allerede nå! 5. Gamle prosesser stoppes på ulike tidspunkt for å minimere innvirkning på markedet 6. Opphør av kraftleveranse vil ikke være mulig å gjøre i frysperioden Markedsaktørene bør rydde opp før frysperioden starter 7. Meldinger om utflyttinger som vil skje i frysperioden må sendes i gammelt regime før frysperioden starter. Sluttbruker må varsle om utflytting 14 dager i forvei. 16.10.2015 46
Hovedpunkter for cut-over plan for måleverdiprosesser og beregninger 1. Måleverdier for timesavregnede målepunkt skal ikke sendes inn før etter at de inngår i en rapportering til NBS. Det betyr at siste uke ikke sendes inn før etter oppstart av Elhub. 2. Elhub gjør saldooppgjør tilbake til oppstartdato for NBS 3. Elhub gjør korreksjonsoppgjør tilbake til NBS oppstart for de korreksjonene som sendes inn til Elhub etter oppstart av Elhub. 4. Elhub videreformidler også korrigeringer på måleverdiere opp til 3 år tilbake i tid, men gjør ikke avviksoppgjør lengre tilbake enn NBS oppstartsdato. 16.10.2015 47
Andre spørsmål? 16.10.2015 48
Migreringsprosessen
Prinsipper for migreringsprosessen Kvaliteten på migreringsdata måles ved flere milepæler Ved hver milepæl sendes data i to iterasjoner slik at markedsaktørene får mulighet til å øke sin datakvalitet DAM databasen resettes ved ulike tidspunkter Når kvaliteten er god nok begynner aktørene å laste inn dataene sine inkrementelt (delta) Opplasting av data fra markedsaktørene synkroniseres med migrering av strukturdata inn i Elhub To simuleringer av cut over gjøres i løpet av migreringsprosessen der pilotakørene deltar
Oversikt Migreringsprosess frem mot go-live
Oversikt Migreringsprosess 2016
Oversikt Migreringsprosess 2016
Oversikt Migreringsprosess frem mot go-live
Oversikt Migreringsprosess frem mot go-live
Migreringsprosess - oppsummering 1 full innsending ca 1 måned før hver milepæl Påkrevd for alle aktører Gjør det mulig å øke kvaliteten frem mot milepælen Delta-uttrekk til selve milepæl Milepælene vil måles på kvalitet Krav til milepæl publisert på elhub.no: http://elhub.no/nb/pages/134-datakvalitet-og-krav Flere innsendinger øker kvaliteten på migreringen Alle blir kjent med hvordan migreringen skal gjøres i sine systemer M5 uttrekket vil være det fulle uttrekket som danner utgangspunktet for Elhub Delta-uttrekk vil oppdatere dette fulle uttrekket frem mot go-live Totalt 10 uttrekk i migreringsprosessen fram mot go-live Pluss 3 deltamigreringer av måleverdier
Adressemigrering mm.
Noen temaer Husnummer og husbokstav Kontraktskoder Adresser og håndtering av disse 16.10.2015 Bunntekst 58
Ymse spørsmål så langt Husnummer og husbokstav Ulikt BIM BIM basert på Elhub Information Model (revidert), nær HNR anbefaling Migrering basert på tidlig Elhub, nær matrikkelen Husnummer og -bokstav i migrering blir til husnummer i Elhub Noe varianter av data sendt inn Alt annet enn numerisk blir feil, men ikkje grunnlag for avvisning Justerer krav til numerisk Vil tillate sammensatt felt i husnummer fom neste innsending 16.10.2015 Bunntekst 59
Ymse spørsmål så langt Kontraktskoder Gjeldende bruk Fremtidig bruk Gjeldende bruk Nettselskap sender kontrakter med kode GA Kraftleverandør sender kontrakter med kode BS Leveransepliktig kraftleverandør sender kontrakt med kode LR Leveransepliktig kraftleverandør er normalt nettselskap som i slike tilfeller skal sende inn TO kontrakter en med kode GA og en med kode LR Fremtidig bruk Kanselleringskoder KUN for å «fjerne» feilaktig registrerte kontrakter av aktuelle typer. 16.10.2015 Bunntekst 60
Adresser 16.10.2015 Bunntekst 61
Addresser i migreringsformatet I Målepunktfilen Har ikke post-/kundeadresser Antar (og forventer) at adressene befinner seg i Norge I Kundefilen Har sluttbruker- og fakturaadresser Adresser i utlandet 16.10.2015 Bunntekst 62
Identifiserte tilfeller av adresser - Kunde Avvikende fakturamottaker Ved, v/ Care of, c/o Att: Elhub/BIM avgrensning/definisjon: Mottakers navn på faktura = sluttbruker Fakturamottaker angis som v/<fakturamottaker> Utenlandsadresser 16.10.2015 Bunntekst 63
Addresser i migreringsformatet To alternativer vurdert: Endre filformatet Utvide bruk av feltet: AddressType Anbefalt løsning: Utvide bruk av eksisterende felter Uansett tillegg i logikk for håndtering av adresser Beholder filformatet uendret ingen endring eller formatmessig inkonsistens i markedet 16.10.2015 Bunntekst 64
Addresser i migreringsformatet Tilpasset bruk av eksisterende felter (i Kunde-filen): Benytter feltet AddressType, utvidet med en ny tillatt verdi: OnBehalf 16.10.2015 Bunntekst 65
Addresser i migreringsformatet Logikk: "Normale" adresser, kun èn adressat: Som i dag, merket med EndUser Komplette navn og adresse i same rad Avvikende fakturaadresse: Navn på sluttbruker angitt i felter i rad med AddressType = EndUser Hvis "annen adressat" (v/<navn>) avvikende navn (v/) og adresse i ny rad med samme CustomerReference og AddressType = OnBehalf Hvis avvikende fakturamottaker evt. navn og full adresse i ny rad med same CustomerReference og AddressType = Invoice For navn på rader med AddressType annet enn EndUser benyttes kun feltet FirstName, som er angitt til 80 tegn. Dette feltet blir i slike tilfeller koblet til feltet OnBehalf i BIM. 16.10.2015 Bunntekst 66
Mapping between migration format and BIM (example) EndUser: FirstName LastName On behalf: FirstName StreetName BuildingNumber PostCode* (Lookup) Bente Sluttbruker v/per Post Storgata 15 0161 Oslo BIM: FirstName LastName BIM: onbehalf attentionof careof streetname housenumber citysubdivision postalcode City country metering points master data metered values time series 16.10.2015 Bunntekst 67
EndUser: [FirstName] [LastName] OnBehalf: [FirstName] [LastName] OnBehalf: [StreetName][BuildingNumber][BuildingLetter] OnBehalf: [PostCode]* (Lookup) metering points metered values 16.10.2015 master data Bunntekst time series 68
Et par eksempler fra revidert filbeskrivelse Address example Olav Enduser c/o Kari Locationowner att: Sara Wife Address street 14A 0161 Oslo End user: Olav Enduser v/ Petters Company c/o Kari Locationowner att: Sara Wife Address street 14A 0161 Oslo Invoice recipient: Olav Enduser v/ Olavs Own Company c/o Kari Locationowner att: Sara Wife Address street 14A 0161 Oslo Field encodings AddressType: EndUser StreetName: Address street FirstName: Olav BuildingNumber: 14 LastName: Enduser BuildingLetter: A CareOf: Kari Locationowner PostCode: 0161 Attention: Sara Wife (City is deduced from PostCode to Oslo) Three rows transmitted: First row: AddressType: EndUser FirstName: Olav LastName: Enduser Second row: AddressType: OnBehalfOf StreetName: Address street FirstName: Petters Company BuildingNumber: 14 LastName: <blank> BuildingLetter: A CareOf: Kari Locationowner PostCode: 0161 Attention: Sara Wife (City is deduced from PostCode to Oslo) Third row: AddressType: Invoice StreetName: Address street FirstName: Olavs Own Company BuildingNumber: 14 LastName: BuildingLetter: A CareOf: Kari Locationowner PostCode: 0161 Attention: Sara Wife (City is deduced from PostCode to Oslo) metering points metered values 16.10.2015 master data Bunntekst time series 69
Utenlandsadresser Justering (setting) av feltlengde: PostCode er justert til format string(25), men det legges på ytterligere sjekker avhengig av bruk For målepunkt: tillater kun norske adresser med format num(4) For norske kunder: num(4) Øvrige: string(25), også plass for å legge inn poststed i utlandet (dette har også vært gjort så langt i innsendte migreringsfiler) metering points metered values 16.10.2015 master data Bunntekst time series 70
Status på tilgang til folkeregisteret
Status søknad Søknad fra NVE til Skattedirektoratet innvilget for datavask med ajourhold, online oppslag og program-til-program kommunikasjon for følgende opplysninger: Fødselsnummer/d-nummer Navn EVRY støtter ikke dette produktet og kan ikke utvikle støtte for det før jul. NVE planlegger derfor å sende søknad om utvidet tillatelse for oppslag i folkeregisteret. Søknaden skal gjelde for datavask med ajourhold, online oppslag og program-til-program kommunikasjon for følgende opplysninger: Fødselsnummer/d-nummer Navn Bostedsadresse (unntatt kode 4,5, 6 og 7) Postadresse Postnummer/poststed Bostedskommune Reg.status (bosatt, utvandret, død) Det forventes snarlig svar fra Skattedirektoratet på søknaden
Tjenestebeskrivelse for DSF Finnes tilgjengelig på infotorg.no https://www.infotorg.no/cms/site/0/binary/3097/file?download=true Det blir ikke returnert adresser på kodene 4, 6 og 7. Dette vil også være viktig for selskapene, da de får en «heads up» i forhold til å gi ut adresser på denne med basis i egne registrerte adresser. I returfilen kommer deres inputadresse, samt folkeregistrert adresse påført i tillegg til oppgitt adresse, slik at det ikke er overskriving av oppgitt adresse, men ikke for kodene som nevnt over.
Sperrede adresser ref. M2 I forbindelse med M2 skal målepunkter, kontrakter og personer knyttet til kode 6 og 7 IKKE migreres til Elhub. Elhub kommer med en avklaring i løpet av året vedrørende hvordan kode 6 og 7 generelt skal behandles i Elhub. Dette vil få følger for hva som migreres ved kommende milepæler Markedsaktørene må uansett behandle disse kodene allerede nå.
Prising Aktørene må gjøre daglig ajourhold for kr 65,- pr dag. Totalt blir dette en kost på ca 26 000 kroner i migreringsperioden (antatt 400 dager) pr aktør. I tillegg 2 øre pr oppslag, dvs at en middels aktør med 20 000 kunder må betale 400 kroner per vask, dvs under 10 000 totalt gitt at man vasker månedlig i migreringsperioden. Det kommer også prising for tilleggstjenester som for eksempel FTP-tilkobling. Dette er typisk engangssummer.
Men Det foreligger en stortingsproposisjon hvor bortfall av følgende priser foreslås: Oppslag Ajourhold (selve kjøringen) Og de 65 kr pr dag Dersom forslaget går gjennom vil markedsaktørene fra nyttår kun bli belastet for tilleggstjenestene
Praktisk informasjon Hvert enkelt selskap (juridisk enhet som eier et personregister) må inngå standard avtale om bruk av data fra DSF. Denne vil minimum omfatte: Tilgang til oppslag, enten via web eller integrert i fagsystem Ajourhold ihht krav fra SKD. Frekvens minimum en gang pr mnd Daglig ajourhold av døde, hemmelige adresser, endret Dnr/Fnr EVRY har enerett for distribusjon og påføring av fødselsnummer, og har klargjort egen organisasjon for å kunne levere påføring og senere ajourhold, både for selskapenes person- og bedriftskunder i perioden frem til 15.2.16.
Prosess Inngå avtaler med EVRY og annen leverandør Abonnementsavtale inngås med EVRY Andre produkter kjøpes fra annen databehandler (3.part) 3.part inngår en databehandleravtale med kunden i forhold til DSF Eksportere/ importere fil kunderegister EVRY påfører DSFinfo Retur fil til tredjepart Tredjepart påfører øvrig informasjon Produksjon Tredjepart sender personkunder til EVRY for ajourhold Tredjepart ajourholder øvrig informasjon og leverer til kunden.
Spørsmål Har systemleverandørene støtte for kode 6 og 7 i sine systemer Bør håndteres på en enhetlig måte på tvers av bransjen
Adressesperrer
Adressesperre Adressesperre er et tiltak som kan iverksettes for å beskytte trusselutsatte personer. At en person er trusselutsatt vil si at personen står i fare for å bli utsatt for alvorlig kriminalitet rettet mot liv, helse eller frihet. Det kan typisk være snakk om vitner, informanter og ofre for æresrelatert vold eller vold i nære relasjoner. Kripos er nasjonalt kontaktpunkt for adressesperre, og forvalter og utvikler adressesperre som metode Adressesperre kode 7 innebærer at den trusselutsattes adresse ikke skal utgis til private. Adresseopplysninger er likevel tilgjengelig for alle offentlige myndigheter som har tilgang til opplysninger fra folkeregisteret, eller fra kopiene hos offentlige myndigheter eller en av distributørene av folkeregisteret. Kode 7- adresseopplysninger er gradert FORTROLIG i henhold til beskyttelsesinstruksen. 16.10.2015 Bunntekst 81
Adressesperre En adressesperre kode 6 innebærer at opplysninger om adresse i utgangspunktet ikke skal utgis til noen. Personer med adressesperre kode 6 vil ved overføring av folkeregisterkopiene til distributørene være registrert med en adresse som tilhører Kripos. Den reelle adressen finnes bare i en del av folkeregistersystemet som kun er tilgjengelig for Skattedirektoratet, hvor kun autoriserte personer har tilgang. I tillegg blir personer som får innvilget kode 6 i enkelte tilfeller anbefalt å bytte navn, slik at vedkommende ikke kan identifiseres ved hjelp av dokumenter hvor navn fremkommer, typisk på internett i forbindelse med idrettslag, barnehager, styreverv o.l. Kode 6-adresseopplysninger er gradert STRENGT FORTROLIG i henhold til beskyttelsesinstruksen. Ved innvilgelse av adressesperre kode 6 sperres i dag adresseopplysninger og historiske opplysninger. 16.10.2015 Bunntekst 82
Tilgangsbegrensning: Av hensyn til sikkerheten til trusselutsatte personer er det svært viktig at tilgangen til og muligheten for distribusjon av sperrede opplysninger begrenses. Kripos mener at det må stilles strenge krav til behandling av slike opplysninger, herunder at sperrede adresseopplysninger må underlegges særskilt tilgangsbegrensning. Dette begrunnes med at uvedkommendes tilgang til sperrede adresseopplysninger utgjør et stort skadepotensial. Dersom slike opplysninger kommer på avveie vil det i verste fall kunne medføre at personer med beskyttelsesbehov kan bli utsatt for alvorlig kriminalitet rettet mot liv, helse og frihet. Videre er det på bakgrunn av opplysningenes art og potensielle skadeomfang viktig for Kripos at det kreves uttømmende og utvidet politiattest for samtlige ansatte som har befatning med kode 6- og kode 7-opplysninger. 16.10.2015 Bunntekst 83
Dersom det ved oppslag ikke oppgis noen postadresse til personer med adressesperre kode 6, skal følgende postadresse alltid benyttes; Mottakers navn SOT6 Pb. 8163, dep 0034 Oslo Kripos videresender post til den enkeltes postadresse. Post videresendes KUN i de tilfeller hvor adressesperre er iverksatt av politiet. Private virksomheters håndtering er hjemlet i personopplysningsloven. Det vises spesielt til 13. 16.10.2015 Bunntekst 84
Adressesperrer i Migrering Markedsaktørene mottar adresser, og dermed kode 6/7 Alle personer med adressesperrer fjernes før innsending til Elhub Tilgangskontroll: begrenset antall personer skal ha tilgang til informasjon om adressesperrer: uttømmende og utfyllende politiattest Manuell håndtering, hentes ut av alle systemer Ved behov for reell postadresse eller anleggsadresse denne oppbevares i safe, der kun et fåtall autoriserte ansatte har tilgang Beholde informasjon om de med adressesperre i datasystem: Erstatte/maskere navn, fødselsnummer og adresser 16.10.2015 Bunntekst 85
Personvern og Informasjonssikkerhet ALLE personopplysninger skal beskyttes: Personopplysningsloven og Personopplysningsforskriften (https://lovdata.no/) Styringssystem for Informasjonssikkerhet/ ISMS (ISO/IEC 27001:2013) Internkontrollsystem Personvernombud 16.10.2015 Bunntekst 86