1. No category

Ekspertgruppemøte 7
Migrering og test
Statnett, Nydalen
19. Mars 2015
Agenda ekspertgruppemøte 19.03.2015
09:30-09:50
Velkommen og introduksjon
• Dagens agenda
• Revidert tidsplan
09:50-10:30
Presentasjon fra leverandør - Accenture
• Prosjektplan
• Overordnet presentasjon av Elhub-løsning
10:30-10:45
10:45-12:00
Pause
Accenture forts
• Presentasjon av migreringsverktøy
• Demo av migreringsverktøy
12:00-13:00
Lunsj
13:00-14:30
Analyse av pilotdata
Datavask-prosess for markedsaktørene
Gjennomgang av kvalitetskrav
Prosess for identifisering av inkonsistens mellom nett og kraft
14:30-14:45
Pause
14:45-15:15
Oppdatert milepælsplan for test og migrering
15:15-15.30
Oppsummering
Milepæler for kraftleverandører og nettselskaper
• For å sikre at alle aktører har jevn progresjon i arbeidet og er
klare for idriftsettelse av Elhub på planlagt dato har Elhubprosjektet utarbeidet en milepælsplan for aktørsertifisering og
datamigrering.
• Aktørene skal rapportere status på hver milepæl til Elhubprosjektet.
• NVE kan fatte vedtak om tvangsmulkt for selskaper som ikke
kan dokumentere fremdrift i henhold til milepælsplanen.
Tidsplan v3.0
• Ny overordnet tidsplan fra NVE. Go-Live mandag 20. februar 2017
• Tydeligere spesifisering av datavask-aktiviteter. Konkretisering av krav til datavask i
milepæler
– Intern datavask eks innhenting av fødselsnr skal være gjennomført innen M2
– Innhenting av fødselsnr skal være gjennomført innen M3
• Ny hovedaktivitet "Uttrekk grunndata"
– Retting av inkonsistens i kundedata på samme målepunkt er en prosess som kan ta lang
tid. Aktørene har begrenset mulighet for selv å rette denne inkonsistens før data migreres
til Elhub og sjekkes der. Gunstig å starte dette så tidlig som mulig
– Det kan ta tid å etablere migreringsgrensesnittet for alle 200+ aktører. Gunstig å starte
dette så tidlig som mulig
– DAM front end planlegges levert innen sommeren 2015
– Systemleverandører antas å være er i stand til å rulle ut funksjonalitet for å hente uttrekk
på migreringsfilformat innen Q2 2015
• Oppdatering av krav i milepæler for systemtilpasning/test
– Krav til systemleverandører legges inn i M2 og M3
– Lagt inn krav til løpende verifikasjon av fødselsnr/orgnr. i M4
– Nytt krav om brukeravtale mellom aktør og Elhub legges inn i M4
Overordnet tidsplan systemtilpasning, test og
migrering
2015
Q1
Q2
2016
Q3
Q4
M2
01.11.15
M1
01.06.15
Q1
Q2
M3
01.03.16
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
2017
Q2
Kontinuerlig datavask og datavedlikehold
Grunnleggende datavask
Uttrekk
grunndata
Pilot migrering
Inkrementell migrering
Elhub GO-LIVE
20.02.2017
MIGRERING
SYSTEMTILPASNING / TEST
Systemgodkj.
Elhub
Systemtilpasning
Systemsertifisering
Edielportal
DAM v0.5 levert
01.06.2015
Edielportal klar for
systemsertifisering
01.08.2015
Aktørsert.
Edielportal
Aktørgodkjenning
Elhub
NBS Go-Live
18.04.2016
DAM v1.0 levert
15.12.2015
Elhub klar for
Vendor Trial
01.04.2016
Elhub klar for
Market Trial
01.09.2016
Aktiviteter - datamigrering
• Grunnleggende datavask. Omfatter intern vask av grunndata som ikke
forutsetter systemoppgradering (dvs innhenting av fødselsnr). Identifiser
alle målepunkter med gyldig GSRN, fjern duplikater. Innhent orgnr for alle
bedriftskunder
• Kontinuerlig datavask og datavedlikehold. Fortsettelse av utestående
intern datavask. Innhenting av fødselsnr og splitt av navn. Korrigering av
inkonsistens mellom nett og kraft
• Uttrekk grunndata. Uttrekk av grunndata på migreringsfilformat. Gir
grunnlag for å kartlegge omfang av inkonsistens mellom nett og kraft
• Pilot migrering. Utvalge pilotaktører går foran og tester ut filformater,
infrastruktur, migreringsprosess osv i praksis
• Inkrementell migrering. Gradvis migrering av data til DAM. Jevnlige
korrigeringer og oppdateringer.
Datavask i fase for grunnleggende datavask
• Pågår frem til ca 1. oktober 2015
• Omfatter datavask som ikke forutsetter
systemoppgradering (les innhenting av
fødselsnr)
– Alle målepunkter skal inn med gyldig GSRN
nummer (EAN)
– Ingen duplikate målepunktID'er
– Alle organisasjonskunder skal ha gyldig
organisasjonsnummer
• Ikke tilgjengelig verktøystøtte fra Elhubprosjektet i denne perioden
• Har dagens EDIEL-utveksling tilgjengelig
som verktøy for utbedring av
inkonsistenser
• Har tilgjengelig NUBIX for oppslag
• Eksterne oppslag mot Enhetsregisteret
og Folkeregisteret
Aktiviteter - systemtilpasning og test
• Systemtilpasning. Markedsaktørens systemleverandør sin tilpasning av
systemet i henhold til gjeldende spesifikasjoner for Elhub. Kan skje i flere
releaser (f.eks. NBS/fødselsnr/database/meldinger/GUI)
• Systemsertifisering Edielportal. Elhub vil videreføre oppsettet med test og
sertifisering i Edielportalen. Markedsaktørens KIS-system må oppnå
Systemsertifisering i Edielportalen for de roller markedsaktøren vil ha i
Elhub, før en markedsaktør kan gjennomføre aktørsertifisering
• Systemgodkjenning Elhub. Full funksjonell ende-til-ende test av en
markedsaktørs IT-system mot Elhub
• Aktørsertifisering Edielportal. Sertifisering i Ediel-portalen av den enkelte
markedsaktør for de roller markedsaktør vil inneha
• Aktørgodkjenning Elhub. Denne testen vil verifisere at aktøren kan utveksle
meldinger med Elhub på korrekt format i henhold til aktuell rolle.
Godkjenning i Elhub forutsetter at markedsaktører har tilpasset sine interne
arbeidsprosesser i forhold til Elhub
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
M1
01.06.15
Formål
2016
Q3
Q4
M2
01.11.15
Q1
Q2
M3
01.03.16
Kriterier Migrering
• Sikre at aktøren har
• Datakvalitetsrapport på
korrekt identifisert alle
spesifisert format er
data som skal migreres
oversendt til Elhub
• Gi en tidlig indikasjon på • Avtale om migrering
datakvalitet på data som
inngått med
skal migreres
systemleverandør eller
• Få oversikt over
plan for egen utvikling
strukturdata i markedet
er lagt
• Sikre at aktør har inngått
nødvendige avtale med
systemleverandører
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
2017
Q2
Kriterier Test
• Avtale om
systemtilpasning og
test inngått med
systemleverandør eller
plan for egen utvikling
er lagt
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Formål
Q4
M2
01.11.15
Q1
Q2
M3
01.03.16
Kriterier Migrering
• Sikre at aktør har bedret • Grunnleggende
sin datakvalitet
datavask gjennomført
• Sikre at aktør er i stand
• Alle målepunkter
til å gjøre uttrekk fra
unike med
egne systemer på
GSRN/EAN (Ingen
spesifisert filformat og
duplikater)
oversende disse til DAM
• Org. nummer for
• Etablere infrastruktur
alle bedriftskunder
for migrering
• Grunndata og
• Få indikasjon på omfang
strukturdata sendt til
av inkonsistens på
Elhub på definert
porteføljenivå
filformat*
* Gradvise frister pr aktør
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
Kriterier Test
• Støtte for innhenting
og vedlikehold av
fødselsnr er
implementert
2017
Q2
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
M1
01.06.15
Formål
2016
Q3
Q4
M2
01.11.15
Q1
Q2
M3
01.03.16
Kriterier Migrering
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
2017
Q2
Kriterier Test
• Sikre at datakvalitet på
• Hele porteføljen av
• Aktørs system skal
migrerte
grunndata og
være sertifisert i
grunndata/strukturdata
strukturdata for
Edielportalen og klar
er på akseptabelt nivå
aktøren er bekreftet
for systemgodkjenning
• Sikre at systemtilpasning
korrekt mottatt i elhub
i Elhub
pågår i henhold til plan
DAM
• Datakvalitet >= 95,0%
(inkl fødselsnr/orgnr og
nettavregningsomåder,
eks måleverdier)
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.11.15
Q1
Q2
M3
01.03.16
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
Formål
Kriterier Migrering
Kriterier Test
• Sikre at datakvalitet på
migrerte data er høy
• Sikre at aktøren har
tilpasset sitt
forretningssystem til
elhub
• Hele porteføljen av
grunndata,
strukturdata og
måleverdier for
aktøren er bekreftet
korrekt mottatt i DAM
• Datakvalitet >= 99,0%,
inkl måleverdier frem
til 01.09
• Aktør er sertifisert i
Ediel-portalen og er
klar for godkjenning i
Elhub
• Aktør har inngått
brukeravtale med
Elhub
2017
Q2
Forslag til aktørmilepæler - test og migrering
2015
Q1
Q2
2016
Q3
M1
01.06.15
Q4
M2
01.11.15
Q1
Q2
M3
01.03.16
Q3
Q4
M4
15.09.16
Q1
M5
15.01.17
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
• Hele porteføljen av
grunndata,
strukturdata og
måleverdier for
aktøren er bekreftet
korrekt mottatt i DAM
• Datakvalitet >=
99,95%, inkl
måleverdier frem til
01.01
• Aktør er godkjent i
Elhub (Market Trial
gjennomført)
2017
Q2
Ekspertgruppemøte 7
Migrering og test
Statnett, Nydalen
19. Mars 2015
Agenda ekspertgruppemøte 19.03.2015
09:30-09:50
Velkommen og introduksjon
• Dagens agenda
• Revidert tidsplan
09:50-10:30
Presentasjon fra leverandør - Accenture
• Prosjektplan
• Overordnet presentasjon av Elhub-løsning
10:30-10:45
10:45-12:00
Pause
Accenture forts
• Presentasjon av migreringsverktøy
• Demo av migreringsverktøy
12:00-13:00
Lunsj
13:00-14:30
Status på pilotaktiviteter
Gjennomgang av kvalitetskrav
Prosess for datavask
• Prosess for korrigering av inkonsistens mellom nett og kraft
• Konkrete eksempler
14:30-14:45
Pause
14:45-15:15
Oppdatert milepælsplan for test og migrering
15:15-15.30
Oppsummering
Tonny Gundersen
• Rolle i Elhub er ansvarlig for teknisk arkitektur
– Er også teknisk ansvarlig fra Accenture sin side for bl.a. DAM og B2B
grensesnitt
• Jobbet 16 år som konsulent i Accenture
• Erfaring fra ulike tekniske roller
– Helsedirektoratet, Telenor, Nordea, SpareBank 1, SpareBank 1 Liv,
Norgesgruppen, Skatteetaten, Statnett, Kongsberggruppen, etc
– Var for eksempel ansvarlig for teknisk arkitektur for Kjernejournal
Prosjektplan Accenture
2015
3
4
5
6
7
2016
8
9
10 11 12
Solution Description
High Level
Design
1
2
3
4
5
6
7
Construction
Prepare Solution
Description
Development - R1
Sprint 1-7
2017
8
9
1
2
3
Acceptance and Completion
Development - R2
Sprint 8-13
UAT
System Vendor
Trials
Sprint 0
10 11 12
Market Trials
Go Live Prep.
PMS1 Solution
Description Approved
Sprint 3
Sprint 2
Sprint 1
Sprint 0.6
Test /UAT
period
Sprint 0.5
Sprint 0.4
Sprint 0.3
Sprint 0.2
Sprint 0.1
Mig. Tool HLD
Mig. Tool Solution
Description
PMS3 Ready for
Acceptance
Prep preprod env
Migration tool v1
PMS2 Migration tool
& Elhub core ready
PMS4
Go-live
4
5
The Best of Breed Solution
Functionality fit
Industry leading
software
High performance
and scalable
Robust and
effective
Flexible
Automated
Secure
Copyright © 2014 Accenture All rights reserved.
User friendly
18
Business Processes Solution
EnergyIP Market
Transaction
Management (MTM)
EnergyIP Meter Data
Management (MDM)
Meter Data Processing Area
1
M2
Manage Metering
Data
2
M4
Aggregation and
Calculations
Supporting
M5
Single-Invoice
Orchestration and Configuration Area
M1
System
Configuration
Oracle Enterprise
Management
(OEM)
Copyright © 2014 Accenture All rights reserved.
M3
Manage Market
Processes
Oracle BPM and
SOA Suite
M6
Reporting and
Monitoring
M7 Web portal, Web
plug-in
M8 Migration
T1 System to
system interfaces
T2 Conceptual
information model
T3 Non-functional
requirements
Oracle BI
19
Basis for Solution: Statnett’s Conceptual
Overview
elhub
operations
WEB portal
market
parties
WEB portal
WEB interface
meter data
responsible
reporting,
monitoring and
statistics
elhub operations,
administration and
functions
market and business process support
(change of supplier, moving, etc. - collection and administration of master data)
metered values and
time series mgmt.
aggregation and
calculation
(collection, verification and distribution)
(metered values, balancing, profiling)
administration of structured data-, and models (e.g. grid areas)
workflow engine and process management (incl. configuration)
security and authentication, audit-trail (incl. privacy – data protection)
capacity, performance and technology
metering points
master data
Storage
elhub-users, roles and access
configuration , grid area model
metered values
time series
EDI interface, B2B
grid
owners
EDI interface, B2B
functions and
services
suppliers
producers
3rd parties
bal. resp.
NECS
NBS
Fokus pr. dags dato er workshops og arbeid delt inn i
funksjonelle og tekniske områder
Prosess/område
Teknologi
M1 System configuration
Oracle/Siemens konfigurasjon
M2 Manage metering data
EnergyIP MDM
M3 Manage Market processes
Oracle BPM / Oracle SOA Suite
M4 Aggregation and Calculation
EnergyIP MTM
M6 Reporting and Monitoring
Oracle BI
M7 Web portal, Web plug-in
HTML5, JavaScripts, CSS3
M8 Migration
Java EE, HTML5, Oracle DB
T1 System to system interfaces
Grensesnitt B2B og grensesnitt internt
T2 Conceptual information model
Oracle DB, fleksibel EnergyIP data modell
T3 Non-functional requirements
Ytelse, sikkerhet, skalerbarhet, infrastruktur, mm
Resultatet av workshops og fokusert arbeid vil resultere i leveransene High Level
Design og Solution Description. Milepæl PMS1.
23.03.2015
21
Eksempel: M3 - Arbeid med markedsprosesser (BRSNO-101 som stjerne-eksempel)
Description
Before the process: The new
supplier sends a request to
initiate a supplier change for a
specified meter.
metering points
master data
•
Upon receiving the request, a
sub-process is initiated and
master data is read
•
The request will then be
validated
•
If one of the validation rules
fail to hold, an exception is
made from the process flow:
A reject message is generated
and returned to the
requesting supplier
metered values
time series
Eksempel: M7 - Web-plugin
Iframe: Web-Plugin into existing web pages
metering points
master data
metered values
time series
T1 - Arbeid med B2B grensesnitt
• Fokus på ebIX formatet
– Vil eksponere web services basert på ebIX
– Basert på Elhub BIM Business Information Model v1.x.pdf
• Sprint 0 for hovedprosjektet går i parallell med første leveranse av DAM
– Utvikler utvalgte markedsprosesser
– Implementasjon i Oracle Service Bus med første versjon av utvalgte B2B grensesnitt
– Etablerer tjenestekatalog med web services, eksponeres til markedsaktørene
– Lager “oppstartspakke” med mockede web services for å kunne distribuere til
markedsaktørene. Dette for å sikre tidlig uttesting i for eksempel Java/.Net.
– Etablerer B2B spesifikasjon som beskriver hvordan integrasjon med Elhub skal
implementeres (wsdl, xsd, sikkerhet, etc.)
• Vil legge ut resultatet av dette arbeidet på elhub.no
– Dato: Senest 1.6
23.03.2015
Bunntekst
24
T1 - Arbeid med B2B grensesnitt – hovedprinsipper
• Krever push inn til Elhub, dvs request/reply
• Markedsaktørene må hente meldinger fra Elhub (pull)
• Garantert leveranse
• Synkron kvittering, asynkron prosessering
• Standardiserte grensesnitt
– Følge Web Services standarder, SOAP, WS-I, WSDL, etc.
• Sikkerhet
• Ytelse
– Komprimering
Agenda ekspertgruppemøte 19.03.2015
09:30-09:50
Velkommen og introduksjon
• Dagens agenda
• Revidert tidsplan
09:50-10:30
Presentasjon fra leverandør - Accenture
• Prosjektplan
• Overordnet presentasjon av Elhub-løsning
10:30-10:45
10:45-12:00
Pause
Accenture forts
• Presentasjon av migreringsverktøy
• Demo av migreringsverktøy
12:00-13:00
Lunsj
13:00-14:30
Status på pilotaktiviteter
Gjennomgang av kvalitetskrav
Prosess for datavask
• Prosess for korrigering av inkonsistens mellom nett og kraft
• Konkrete eksempler
14:30-14:45
Pause
14:45-15:15
Oppdatert milepælsplan for test og migrering
15:15-15.30
Oppsummering
Migreringsverktøy
• Fra spesifikasjon:
– Before Elhub is put into operation, the project will ensure that all
historical master data, structure data and meter data that are currently
in the DSOs and energy suppliers' customer information systems, meter
data management systems or other system, have been checked for
consistency and migrated to the repository in Elhub
• Spesifikasjoner:
– Elhub Specification of Migration Files.pdf
– Elhub Specification of Nonconformity Files.pdf
• Java EE basert løsning
• Lagring av data – Oracle Database
Utvalgte krav
• Ability to accept data on multiple layouts on the same format
from market parties
– This format is a semicolon delimited text file
• The DAM will provide a graphical user interface
• Ability to perform integrity check
• Ability to perform validity check
• Ability to perform consistency check
• Ability to do migration from migration database to Elhub
database
Migreringsverktøyet er drevet av tre steg
Steg 2 Ok/Ikke Ok?
Steg 1 Ok/Ikke Ok?
Steg 1:
Opplastning av rådata
Steg 2:
Videreforedling
Last opp, rapporter
Sjekk - Integritet
Sjekk - Format
Sjekk - Konsistens
Lagre informasjon pr. rad
gitt spesifikasjon
..
xx.sdv
yy.sdv
zz.sdv
…
Contract
MeteringPoint
Customer
..
..
Steg 3:
Lagret i Elhub
..
Migreringsverktøy pr. dags dato – fokusert på
pilotaktører
• Arbeidet med utvikling har startet, foreløpig med fokus på følgende brukerhistorier:
– DAM - Format market parties - Contract
– DAM - Format market parties - Metering Point
– DAM - Format market parties - Customer
– DAM - Interface - Upload market party files
• Arbeidet foregår i tre ukers sprinter
– Smidig metodikk sentralt i arbeidet
• Leveranse 1.6 inkluderer:
– Pålogging (brukernavn/passord) for markedsaktører
– Opplastning av historiske målerdata fra en manuell opplastningsside
– Til diskusjon: Er en manuell opplastningsside tilstrekkelig?
– Ulike formatsjekker i forkant av lagring (spesifisert i spesifikasjon)
– Rapportering på opplastning
– Etablering av sikret infrastruktur hos Basefarm
Samarbeid med pilotaktører
• Før 1.6
– Vi mottar pr. dags dato innsendinger over FTP med krypterte produksjonsdata
– Vi vil i en kontrollert prosess maskere deler av disse produksjonsdataene og
benytte disse i testing av 1.6 leveransen
– Med fokus på rapportering vil vi demonstrere maskerte og redigerte pilotdata i
en utviklings/test-versjon av DAM
– Fortløpende i april sende over eksempel-rapporter og få tilbakemelding på disse
– Gjøre klar uttrekk for pilotperiode
– Etablere og bistå med å teste ut infrastruktur for pilotperiode (sikkerhet,
brannmuråpninger, tilganger, etc)
• Fra 1.6
– Logge seg på første versjon av DAM i en pilotperiode, manuelt laste opp
(u)vaskede produksjonsdata
Demo - Upload market party files
34
35
36
37
38
39
40
Analyse av uttrekksfiler
Delprosjekt for migrering og test
Datagrunnlag (sånn ca)
• 3 forskjellige systemer
• 10 pilotaktører
– 6 Nettselskap
– 4 Kraftleverandører
• 251.000 kundeforhold
• 219.000 kundeforhold - privat
• 32.000 kundeforhold - bedrift
• 249.000 målepunkt
• 494.000 kontrakter
• 253.000 nett-kontrakter
• 241.000 kraft-kontrakter
Kjapp begrepsforklaring
• Kunde
– kunde fra en markedsaktør
– ikke analysert på tvers av kraft og nett
• Kundeforhold
– kunde slått sammen på kontrakt for et målepunkt
– sammenlignet på tvers av kraft og nett
Kunder med feil
• Privatkunder uten fødselsdato: 0,12%
– Kun 9-tall, tom dato e.l.
– Vanskeligere å vaske
– Dette inkluderer ikke fødselsdatoer som ikke er korrekte
• Bedriftskunder uten orgnummer: 3,84%
– 999999999 / 99999999999 / «» e.l.
– Vil bli redusert ved vask mot eksterne register
– Der en part mangler denne, mangler ofte også den andre parten samme
(94,5%)
• Privatkunder med næringskode: 0,81%
– Ola Nordmann – Næringskode 49.392 (Skulle vært XX, XY e.l.)
Kundeforhold med feil
• Kundeforhold med ulikheter på navn: 29%
– Inkluderer alle ulikheter i for-/etter- og firmanavn
• Eks: Ola Nordmann – Ole Nerdmann
– De med kun enkle skrivefeil (majoriteten) vil løses ved vask mot
eksternt register
– Gjelder 73.593 av 252.522 aktive kundeforhold
• Kunder uten noe som helst navn: 0,004%
– Noen tilfeller har CO/PB/ATT
Andre forskjeller i kundeforhold
• Ulik CustomerIdentity (orgnummer, fødselsdato)
– Eks: Ola Nordmann fdato: 160782 – Kari Nordmann fdato: 020154
– 4.373 av 252.522 kundeforhold (1,73%)
– Inkluderer der det er mismatch bedrift/privat, orgnummer er forskjellig,
eller fødselsdato er forskjellig
• Bedrift hos kraft – privat hos nett (eller omvendt)
– Eks: Ola Nordmann – Storo Blikkenslager AS
– 1.508 av 252.522 (0,60%)
• Likt etternavn, forskjellig fornavn (Hr/Fru problematikk)
– Eks: Ola Nordmann – Kari Nordmann (inkl lik fdato)
– 2.739 av 219.291 kundeforhold privat (1,25%)
– Inkluderer også mismatch med mellomnavn, grove skrivefeil i fornavn
Andre ulikheter i kundeforhold
• Ulik næringskode på bedriftskunder
– Eks: 47.532 vs 27.510
– 3.729 av 31.723 (13,05%)
• Samboere med fullt navn på begge parter på ene siden av
kontrakten
– Eks: FirstName kraft: «Kari Nordmann Ola Nordmann», First/Last nett:
«Kari»/«Nordmann», Adresse nett: «Ole Nordmann Storveien»
– På andre siden av kontrakten er adressefeltet benyttet som
kompletterende navnefelt for part som mangler i navn
– Lite problem, men vil muligens komplisere vask noe
Oppsummering av forskjeller
• Hvis man trekker fra hr/fru, priv/bedrift osv kan man anta
– Verdt å merke seg at dataene vi har analysert primært er kundeforhold
fra ulike selskaper – dvs. IKKE vertikalintegrerte porteføljer
– Av 73.593 er 64.973 trivielle skrivefeil der det er forskjell mellom nett og
kraft som vil løses med vask
– Det betyr at man sitter igjen med 8.620 (3%) feil av varierende
alvorlighetsgrad som det er uklart om umiddelbart løses ved vask
– Ekstrapolert er dette 84.000 på landsbasis… (2.800.000 målepunkter)
En ting til - manglende kontrakter
• Vil kunne resultere i mye manuell jobb for opprydding
– Analyser basert på komplette porteføljer (så vidt vi vet)
– Inneholder også målepunkter med åpne prosesser
– Noe usikre tall – er mest sannsynlig lavere
• Kontrakter fra nett som ikke har motpart hos kraft
– 1.157 av 252.522 (0,46%)
• Kontrakter fra kraft som ikke har motpart hos nett
– 1.822 av 252.522 (0,72%)
Andre observasjoner
• Aktiverte kundeforhold pr måned
– Indikasjon på hvor mange åpne prosesser vi kan forvente ved go-live
– Noe usikkerhet knyttet til tallene, uvisst hvor komplette uttrekkene er
bakover/fremover i tid
– Store svingninger måned til måned – fjernet de mest avvikende
– 3.398 av 252.522 (1,35%)
• Aktiveringer denne uken
– 343 aktiverte denne uken
– Ekstrapolert vil dette bli ca 3500 på landsbasis uken før go-live
Inkonsistens mellom nett og
kraft
Delprosjekt for migrering og test
Innstramming i ny forskrift
• Én og samme sluttbruker
for nett og kraft på ett og
samme målepunkt
• Sluttbrukeren skal være
en person eller juridisk
person
• Sluttbrukeren skal være
identifisert enten ved
fødselsnummer eller
organisasjonsnummer
Inkonsistens i kundedata fra nett og kraft
Kontrakt
Kunde
Målepunkt
Kunde
Kontrakt
Måleverdier
Kraftleverandør
Nettselskap
•
•
•
Inkonsistens mellom kraft og nett må rettes
før Go-Live
Dersom fortsatt inkonsistens ved Go-Live vil
Elhub velge data fra Nett
Inkonsistens defineres som feil for
kraftleverandør
Hovedproblem
• Data mangler eller er inkonsistente hos nett
eller kraft
– Mangler org. Nummer
– Org. Nummer ikke konsistent med bedriftsnavn
– Mangler fødselsdato
– Mangler fødselsnummer
• Kunde er ikke identisk for nett og kraft
– Herr/fru
– Privat/bedrift
– Ulik næringskode
– Helt forskjellig kunde
– Mangler kunde hos nett eller kraft
Tilbakemelding fra pilotaktører og ekspertgruppe
• Prosjektet har mottatt mye data fra pilotaktørene
– Har avdekket en rekke problemstillinger
• Prosjektet har også motta noen forslag fra pilotaktører og
andre i forhold til hvordan utbedre inkonsistenser
• Vanskelig å få aktørene til å kommunisere seg imellom
– Tilhører forskjellige konstellasjoner
– Forskjellige typer av markedsaktører
• Kan vi komme fram til generiske beskrivelser for å utbedre
inkonsistenser?
Datavask og utbedring av inkonsistens
• Først kommer fasen for grunnleggende datavask
– Jobber internt først
– Best mulig datagrunnlag før sammenstilling i Elhub DAM mellom nett og
kraft
• Kontinuerlig vedlikehold og datavask kommer utover i 2016
– Utbedring av inkonsistens mellom nett og kraft
Datavask i fase for grunnleggende datavask
• Pågår frem til 1. oktober 2015
– Alle målepunkter skal inn med gyldig
GSRN nummer (EAN)
– Ingen duplikate målepunktIDer
– Alle organisasjonskunder skal ha
gyldig organisasjonsnummer
• Ikke tilgjengelig verktøystøtte fra
Elhub-prosjektet i denne perioden
• Har dagens EDIEL-utveksling
tilgjengelig som verktøy for
utbedring av inkonsistenser
• Har tilgjengelig NUBIX for oppslag
• Eksterne oppslag mot
Enhetsregisteret og Folkeregisteret
Bedriftskunder uten reelt org. nummer
• Søke i Enhetsregisteret
• Manuelt søk eller eller programmatisk
integrasjon mot Brønnøysund
• Ta manuelt kontakt med de som ikke
er registrert
– Enten registrerer de seg
– Eller, abonnement omregistreres på
privatperson
• Hva med ambassader?
– Skal ha org. nummer
?
Bedriftskunder med feil navn
• Org.nummer og bedriftsnavn stemmer ikke overens
• Hva er riktig?
– Org. Nummer er mer entydig enn bedriftsnavn
– Bedriftsnavn er det som står på fakturaen
• Bruke navn som fasit?
• Bruke organisasjonsnummer som fasit?
• Kontakte kunde?
Bedriftskunder med feil næringskode
• Feil næringskode – en bedrift kan ha flere næringskoder
– Hvor viktig?
– Hvor viktig er det for kraft? Nett bruker den til KILE rapportering
• Nett må i verste fall ta kontakt med kunde
• Droppe krav om næringskode fra kraft?
Næringskode på privatperson
• Privatkunder med næringskode
• Skulle det vært registrert som bedrift?
• Finnes det noen grunn til å bruke næringskode på person?
• Fjern den!
Andre momenter
• Felter kan være misbrukt
• For eksempel adressefeltet kan være brukt til
navneinformasjon
• Kan løses ved å vaske adressefelt mot Posten
Vedlikehold og kontinuerlig datavask
Hente inn fødselsnummer for privatkunder
• Hente fødselsnummer fra Folkeregisteret
– Må ha én-til-én treff
• Må i verste fall kontakte kunden
– Spesielt hvis man mangler fødselsdato
Privatkunder uten navn eller fødselsnummer
• Kraft
– Søke i NUBIX
• Nett
– Kan ha CO/PB/ATT
– Kontakte kraft
– Oppsøke målepunkt
Skrivefeil i navn for bedrift/privat
• En del inkonsistens mellom nett og kraft skyldes rett og slett
skrivefeil hos den ene eller begge parter
• Løses ved vask mot eksternt register
– Folkereigsteret
– Enhetsregisteret
Herr og fru
• Navn med store skrivefeil vil også kunne havne i denne
kategorien
• Hvordan entydig identifisere herr og fru
– Samme etternavn
– Sjekke i Folkeregisteret
• Her er det to forskjellige juridiske kontrakter
• Kan være registrert på samme fødselsdato
– Eieren av fødselsdato er den reelle kunden
– Kraft endrer eller kjører anleggsovertakelse uten kundekontakt
• Hvis forskjellig fødselsdato
– Kraft endrer hos seg
• Oppsigelse sendes til den som ikke lenger er kunde, med
forklaring på prosessen som er gjennomført
Privat versus bedrift
• Privat og bedrift antas å være samme faktiske
sluttbruker
• Mest sannsynlig privat som er riktig
• Komplisert fordi det foreligger avtalemessige bindinger i
begge retninger
• Kraft kan være bedrift og nett privat, eller vice versa
• Kan løses uten kundekontakt
– Hvis privat hos kraft: Kraft kjører anleggsovertakelse med
privat
– Hvis bedrift hos kraft: Kraft endrer til privat
• Evt. kraft tar kontakt med kunde og retter opp
• Det sendes oppsigelse til den som ikke lenger antas å
være kunde
?
Forskjellige kunder på kraft og nett
• Forskjellig kunder på kraft og nett uten at de tilhører noen av
de overnevnte kategorier
• Kraft må ta kontakt med kunde?
• Kjører anleggsovertakelse via dagens meldingsutveksling
Arbeid fremover i forhold til datavask-prosess
• Prosjektet jobber videre med innspill fra ekspertgruppen
• Ekspertgruppen jobber med tilbakemeldinger på de forslag som
er fremmet av prosjektet (hjemmelekse)
• De som eventuelt er interessert i å være med i en
arbeidsgruppe for datavask gir beskjed
• Prosjektet vurderer eventuelt å opprette en arbeidsgruppe og
hvem som skal delta i denne
Opprette egen arbeidsgruppe
• Dele konfidenselle data fra
pilotene
• Jobbe i mindre gruppe
• Møtes mer frekvent
• Utarbeide retningslinjer til
bransjen for hvordan utbedre
inkonsistenser
Mandat
• Presentere status på neste
ekspertgruppemøte
• Kategorisere de ulike typene av datafeil og
inkonsistenser
• Generelle anbefalinger til hvordan
markedsaktørene kan løse feil:
– Feil i egne data før DAM er lansert
– Feil som blir påpekt av DAM
• Målet er å beskrive en prosess som blir
billigst mulig for markedsaktørene, men som
samtidig ivaretar sluttbrukernes interesser
Filformat, kvalitetskrav og
korreksjonsprosess
Delprosjekt for migrering og test
Noen kommende justeringer i filformat
• Nye felter: MeteringPoint
– Prioritet (verdi: P, A, B, C, D)
– Start av periode for forventet mottatt avlesning (datetime)
• Justerte formater/enumerasjoner:
– EndReason (Contract)
• Etablert enumerasjon (blir også inkludert i BIM)
• Z41 (death), Z42 (move), Z44 (default), Z45 (change)
– SettlementConstant
• Endret format fra decimal(10,8) til decimal(20,8) – må håndtere større tall
– MeterDigits
• Skal selvfølgelig være decimal(4,1)
• Endringer blir inkludert i v1.0
– Versjon (foreløpig) 0.95 er oppdatert på Confluence
– Innhold foreløpig avklart med leverandør, forventer ikke ytterligere felter
Kvalitetskrav
Overordnede datakvalitetskrav
QA-kategori
Beskrivelse
FEILNIVÅ
TYPISK INFORMASJON
MÅ
Data som er nødvendige
for at Elhub skal virke.
MÅ kvalitetssikres.
KRITISK
•
•
•
•
•
BØR
Data som skal sendes til
ALVORLIG
Elhub som ikke er
driftskritiske, men er viktige
for markedet.
BØR kvalitetssikres.
• Målepunktadresse
KAN
Data som skal sendes til
Elhub som ikke er
driftskritiske, men vil bli
viktige for markedet.
KAN kvalitetssikres
• Kundeadresse
• Kontaktinfo
MINDRE
VIKTIG
Målepunktinformasjon
Måleverdier
Kundeidentifikasjon
Avgiftsinformasjon
Relasjoner
Nærmere om kvalitetssikring av felter og data
• Tidligere presentert og sendt ut tabeller detaljerer krav til felter
i de enkelte filene fra forskjellige aktører
• Tabellene inngår i bransjeinstruksjoner, og beriker filformatet
• Kan være noe uforståelige…
• …derfor en liten forklaring på feltenes innhold…
Felter og data - en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
ValidTo
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk Må
Obligatorisk Må
Avhengig
i/r
i/r
Begge aktører
Kraftleverandør
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Må
i/r
Kraftleverandør
CustomerReferenceEndUser Obligatorisk Må
i/r
Kraftleverandør
CustomerReferenceInvoice
Valgfri
Nei
Ingen konsistenskontroller
GridAccessProvider
Obligatorisk Må
i/r
Kraftleverandør
BalanceSupplierUsed
Valgfri
i/r
Ingen konsistenskontroller
BalanceResponsibleParty
Obligatorisk Må
Ja
Kraftleverandør
Kan
i/r
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Kunde mangler i kundefil. Tbm.
samme.
Kunde mangler i kundefil. Tbm.
samme.
MP ikke hos GAP, dvs. feil
GAP(MP). Tbm. BS.
Inkonsistent BS og BS fra
filnavn/innsender. Tbm. BS
(valgfri)
Ikke gyldig BRP - kan sjekkes?
Må feltet være med i filen?
Obligatorisk = Ja, Avhengig = kanskje,
Valgfri = kun hvis data foreligger
Felter og data - en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
ValidTo
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk Må
Obligatorisk Må
Avhengig
i/r
i/r
Begge aktører
Kraftleverandør
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Må
i/r
Kraftleverandør
CustomerReferenceEndUser Obligatorisk Må
i/r
Kraftleverandør
CustomerReferenceInvoice
Valgfri
Nei
Ingen konsistenskontroller
GridAccessProvider
Obligatorisk Må
i/r
Kraftleverandør
BalanceSupplierUsed
Valgfri
i/r
Ingen konsistenskontroller
BalanceResponsibleParty
Obligatorisk Må
Ja
Kraftleverandør
Kan
i/r
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Kunde mangler i kundefil. Tbm.
samme.
Kunde mangler i kundefil. Tbm.
samme.
MP ikke hos GAP, dvs. feil
GAP(MP). Tbm. BS.
Inkonsistent BS og BS fra
filnavn/innsender. Tbm. BS
(valgfri)
Ikke gyldig BRP - kan sjekkes?
Hva skal gjøres med data før sending?
Må = Skal kvalitetssikres og være korrekt,
Bør/kan = anbefales kvalitetssikret
i/r = kvalitetssikring antas ikke relevant
Felter og data - en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
ValidTo
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk Må
Obligatorisk Må
Avhengig
i/r
i/r
Begge aktører
Kraftleverandør
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Må
i/r
Kraftleverandør
CustomerReferenceEndUser Obligatorisk Må
i/r
Kraftleverandør
CustomerReferenceInvoice
Valgfri
Nei
Ingen konsistenskontroller
GridAccessProvider
Obligatorisk Må
i/r
Kraftleverandør
BalanceSupplierUsed
Valgfri
i/r
Ingen konsistenskontroller
BalanceResponsibleParty
Obligatorisk Må
Ja
Kraftleverandør
Kan
i/r
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Kunde mangler i kundefil. Tbm.
samme.
Kunde mangler i kundefil. Tbm.
samme.
MP ikke hos GAP, dvs. feil
GAP(MP). Tbm. BS.
Inkonsistent BS og BS fra
filnavn/innsender. Tbm. BS
(valgfri)
Ikke gyldig BRP - kan sjekkes?
Skal endringer i feltet generere ytterligere rader?
i/r = feltet inngår som identifiserende element i raden, og skal derfor IKKE generere nye rader
Nei = kun siste data er relevant, tidligere verdier av feltet skal ikke sendes (som egne rader)
Ja = endringer i data skal sendes i form av nye rader i filen. Sammenfallende endringer (samme dag) sendes
som samme endring.
Felter og data - en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
ValidTo
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk Må
Obligatorisk Må
Avhengig
i/r
i/r
Begge aktører
Kraftleverandør
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Må
i/r
Kraftleverandør
CustomerReferenceEndUser Obligatorisk Må
i/r
Kraftleverandør
CustomerReferenceInvoice
Valgfri
Nei
Ingen konsistenskontroller
GridAccessProvider
Obligatorisk Må
i/r
Kraftleverandør
BalanceSupplierUsed
Valgfri
i/r
Ingen konsistenskontroller
BalanceResponsibleParty
Obligatorisk Må
Ja
Kraftleverandør
Kan
i/r
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Kunde mangler i kundefil. Tbm.
samme.
Kunde mangler i kundefil. Tbm.
samme.
MP ikke hos GAP, dvs. feil
GAP(MP). Tbm. BS.
Inkonsistent BS og BS fra
filnavn/innsender. Tbm. BS
(valgfri)
Ikke gyldig BRP - kan sjekkes?
Hvis feil oppdages i feltet, hvilken aktør (hvis noen) skal motta rapport?
Begge aktører = feilen er av såpass viktighet at begge aktører må forholde seg til denne, og mottar derfor rapport.
Kraftleverandør/Nettselskap = Den aktuelle aktøren er ansvarlig for å korrigere data, og mottar derfor rapporten.
Ingen konsistenskontroller = Feltet kan være underlagt andre sjekker (format, mm.) som meldes den enkelte aktør, men
Det foreligger ingen konsistenskontroller på feltet, dvs. ingen sjekker på tvers av aktører.
Felter og data - en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
ValidTo
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk Må
Obligatorisk Må
Avhengig
i/r
i/r
Begge aktører
Kraftleverandør
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Må
i/r
Kraftleverandør
CustomerReferenceEndUser Obligatorisk Må
i/r
Kraftleverandør
CustomerReferenceInvoice
Valgfri
Nei
Ingen konsistenskontroller
GridAccessProvider
Obligatorisk Må
i/r
Kraftleverandør
BalanceSupplierUsed
Valgfri
i/r
Ingen konsistenskontroller
BalanceResponsibleParty
Obligatorisk Må
Ja
Kraftleverandør
Kan
i/r
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Kunde mangler i kundefil. Tbm.
samme.
Kunde mangler i kundefil. Tbm.
samme.
MP ikke hos GAP, dvs. feil
GAP(MP). Tbm. BS.
Inkonsistent BS og BS fra
filnavn/innsender. Tbm. BS
(valgfri)
Ikke gyldig BRP - kan sjekkes?
Dette er en forslagsvis kolonne for å angi hvilke typer feil som forventes, hvordan dette kan forekomme, og hvilke
aksjoner som Elhub migrering vil foreta seg (typisk tilbakemelding).
Foreløpig er dette kun en intern kolonne, spørsmålet er om den kan ha verdi for markedet også?
Felter og data – en forklaring
Eksempel: De første feltene i kontraktsfilen
Fil
Felt
Contract MeteringPointUsed
ValidFrom
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk
Obligatorisk
Må
Må
i/r
i/r
Begge aktører
Kraftleverandør
Mulig feil, grunn og aksjon
MP mangler fra GAP. Enten feil
i MP eller feil fra GAP. Tbm. til
begge.
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm. til BS,
evt. begge BS hvis lev.skifte.
Merk at det er forskjellige tabeller med varianter for begge typer markedsaktører…
Fil
Felt
Contract MeteringPointUsed
ValidFrom
Påkrevde felter nettselskap
Påkrevd
QA-krav
Historikk Tilbakemelding til…
Obligatorisk
Obligatorisk
Må
Må
i/r
i/r
Mulig feil, grunn og aksjon
Nettselskap
MP mangler fra GAP(MP). Feil i
MP-fil. Tbm. til GAP.
Begge aktører
Feil med overlapp eller gap i
tidsperiode mellom
eierskap/historikk. Tbm.
avhengig av felt - hvis endret
BS, tbm. til alle (tre parter)
Definisjon av feil i migrerte data
jfr. definisjon av rapporterte feil og statistikk
• Feil i migrerte data aggregeres og rapporteres på
målepunktnivå – et målepunkt er enten korrekt eller feil
• Et målepunkt defineres som feil dersom
– Målepunktet mangler (dvs at målepunktet eksisterer i virkeligheten men
data om målepunktet er ikke migrert til Elhub)
ELLER
– Et obligatorisk felt tilknyttet målepunktet mangler
ELLER
– Et tilknyttet felt har en KRITISK feil (dvs QA-krav = MÅ)
Mulig kvalitetssikring som aktørene skal
gjennomføre
QA-kategori
INFORMASJON
MULIG KVALTETSSIKRING
MÅ
Målepunktinformasjon
Sjekk at målepunkt-ID har gyldig GSRN-nr
Fjern duplikater
Måleverdier
Sjekk at parameter "antatt årsforbruk" er
rimelig
Kundeidentifikasjon person
Sjekk navn og fødselsnr mot
Folkeregisteret
Splitt navn til fornavn/etternavn
Kundeidentifikasjon bedrift
Sjekk navn og organisasjonsnr mot
Brønnøysund
Avgiftsinformasjon
Sjekk om satser er riktige i forhold til type
forbruk på målepunkt
Relasjoner
Sjekk av kunderelasjon på målepunkt
mellom kraftleverandør og nettselskap
BØR
Målepunktadresse
Sjekk mot Matrikkelen
KAN
Kundeadresse
Sjekk mot kunden
Kontaktinfo
Sjekk mot kunden
Korreksjon av inkonsistens mellom nett og kraft
- Bakgrunn
• Noe statistikk
– Antall GLN i bruk i markedet i dag: ca. 390
– Antall netteiere registrert (EDIEL-portal og balanseavregning): 171
– Antall kraftleverandører registrert: 220
– Antall balanseansvarlige registrert: 68
– Antall netteiere i bruk (balanseavregningen): 145
– Antall balanseansvarlige i bruk (balanseavregningen): 45
– Antatt antall porteføljer å behandle: ca. 5000 (mellom 4600 og 5200)
Korreksjon av inkonsistens mellom nett og kraft
- behandling
• Håndtering av tilbakemeldinger
– Må rapporteres per portefølje (kommersielt sensitiv informasjon)
• Per kombinasjon av kraftselskap og nettselskap
– Målepunkter mellom porteføljer
• Leverandørskifter betyr at et målepunkt skifter fra en til en annen portefølje
• Konsistens må sjekkes og rapporteres på tvers av disse (konsistens mellom tidsintervaller)
• Korreksjoner forventes verifisert og gjennomført på en av tre måter:
– Endring i egne systemer (kun) – normalt for kraftleverandør
– Endring sendt via eksisterende EDIEL-infrastruktur til annen part
– Endring krever kontakt med sluttbruker før korreksjon
… detaljer rundt dette er grunnlag for videre arbeid
Migreringsfiler og felter
Informasjon om Kontrakt fra Nettselskap
Fil
Contract
23.02.2015
Felt
MeteringPointUsed
ValidFrom
ValidTo
CustomerReferenceEndUser
CustomerReferenceInvoice
GridAccessProvider
BalanceSupplierUsed
BalanceResponsibleParty
NACE_Code
ElCertificateShare
EnovaFeeShare
EnovaFeeType
ElFeeShare
ValueAddedTaxShare
EndReason
Channel1
Description1
Value1
Channel2
Description2
Value2
Channel3
Description3
Value3
Channel4
Description4
Value4
Påkrevde felter nettselskap
Påkrevd
QA-krav
Obligatorisk
Må
Obligatorisk
Må
Avhengig
Må
Obligatorisk
Må
Valgfri
Kan
Obligatorisk
Må
Valgfri
i/r
Obligatorisk
Må
Obligatorisk
Må
Obligatorisk
Må
Obligatorisk
Må
Obligatorisk
Må
Obligatorisk
Må
Obligatorisk
Må
Avhengig
Må
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Valgfri
Kan
Historikk
i/r
i/r
i/r
i/r
Nei
i/r
i/r
Ja
Ja
Ja
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Nei
Brosjyre som beskriver nettselskapers og
kraftleverandørers krav til datakvalitet og –
migrering i forbindelse med Elhub
Tilbakemelding til…
Nettselskap
Nettselskap
Nettselskap
Nettselskap
Ingen konsistenskontroller
Nettselskap
Ingen konsistenskontroller
Nettselskap
Nettselskap
Nettselskap
Nettselskap
Nettselskap
Nettselskap
Begge aktører
Nettselskap
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Migreringsfiler og felter
Informasjon om Kontrakt fra Kraftleverandør
Fil
Contract
23.02.2015
Felt
MeteringPointUsed
ValidFrom
ValidTo
CustomerReferenceEndUser
CustomerReferenceInvoice
GridAccessProvider
BalanceSupplierUsed
BalanceResponsibleParty
NACE_Code
ElCertificateShare
EnovaFeeShare
EnovaFeeType
ElFeeShare
ValueAddedTaxShare
EndReason
Channel1
Description1
Value1
Channel2
Description2
Value2
Channel3
Description3
Value3
Channel4
Description4
Value4
Påkrevde felter kraftleverandører
Påkrevd
QA-krav
Historikk
Obligatorisk Må
i/r
Obligatorisk Må
i/r
Avhengig
Må
i/r
Obligatorisk Må
i/r
Valgfri
Kan
Nei
Valgfri
i/r
i/r
Obligatorisk Må
i/r
Obligatorisk Må
Ja
Obligatorisk Må
Ja
Valgfri
Må
Ja
Valgfri
Må
Nei
Valgfri
Må
Nei
Valgfri
Må
Nei
Obligatorisk Må
Nei
Avhengig
Må
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Valgfri
Kan
Nei
Brosjyre som beskriver nettselskapers og
kraftleverandørers krav til datakvalitet og –
migrering i forbindelse med Elhub
Tilbakemelding til…
Begge aktører
Kraftleverandør
Kraftleverandør
Kraftleverandør
Ingen konsistenskontroller
Ingen konsistenskontroller
Kraftleverandør
Kraftleverandør
Kraftleverandør
Kraftleverandør
Kraftleverandør
Kraftleverandør
Kraftleverandør
Begge aktører
Kraftleverandør
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller
Ingen konsistenskontroller