DataHub Migrering - Strategi og plan for datamigrering i forbindelse med idriftsættelse af DataHub

Transkript

1 Typografidefinition: Indholdsfortegnelse 1 Typografidefinition: Indholdsfortegnelse 2: Indrykning: Venstre: 1 cm, Hængende: 1 cm, Tabulatorer: 1 cm, Venstre DataHub Migrering - Strategi og plan for datamigrering i forbindelse med idriftsættelse af DataHub Udarbejdet af DataHub Ekspertgruppen Migrering Denne rapport udvikles løbende på basis af input fra møder i Ekspertgruppen Migrering DATE JGR NAME DATE Slettet: 14 Slettet: 6 NAME REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED Slettet: 1 Energinet.dk DOC. NO. Slettet: 1 Slettet: yy Dok , Sag /28

2 1.... Baggrund for notat Begrundelse for migrering Arbejdsmetode Datamængder Saldoafregning Andelstalsberegning Stamdata for målepunkter Måledata Oversigt over krav til migrering af måledata Migreringsstart for skabelonafregnet forbrug Korrektioner af måledata efter idriftsættelse af DataHub Forretningsprocesser ved idriftsættelse af DataHub Migreringsmetode Overordnet beskrivelse Elleverandørenes opgave Datafiler til migrering Tidsplan for migrering Migreringsfaser Milepæle Detaljeret tidsplan ved go-live Nødplaner Migreringsfiler Generelle regler Headerlinje (HDR) Datalinje (DATA) Footerlinje (FTR) Eksempel: ALL_CONNECTION Eksempel: MASTERDATA Eksempel: METERDATA Eksempel: Konvention for filnavne...21 Appendix A - Krav til måledata...22 Forskriftskrav...22 Saldoafregning...22 Appendix B - Fejlmeldinger ved migrering...23 Slettet: 1. Baggrund for notat Begrundelse for datamigrering Arbejdsmetode 3 2. Datamængder 4 3. Saldoafregning Afstemning af Saldoafregning ved migreringen 7 4. Andelstalsberegning 7 5. Stamdata for målepunkter 7 6. Måledata Forskriftskrav Korrektioner af måledata efter idriftsættelse af DataHub 9 7. Forretningsprocesser ved idriftsættelse af DataHub Migreringsmetode Overordnet beskrivelse Elleverandørenes opgave Datafiler til migrering Tidsplan for migrering Migreringsfaser Milepæle Detaljeret tidsplan ved go-live Nødplaner Migreringsfiler Generelle regler Headerlinje (HDR) Datalinje (DATA) Footerlinje (FTR) Eksempel: ALL_CONNECTION Eksempel: MASTERDATA Eksempel: METERDATA Eksempel: Konvention for filnavne 20 : Indrykning: Første linje: 0 cm Dok , Sag /28

3 Dokumenthistorik Første version offentliggjort på DataHub portal Opdateret efter migreringsmøde : - Afsnit 6 omskrevet, tilføjet forklarende figur, forskriftshenvisninger flyttet til appendix A - Appendix B tilføjet med fejlkoder ved migrering - Bemærk, at beskrivelser for go-live perioden (delta migrering) afventer en endelig afklaring, og er ikke ajourført Ændret procedure for brugeroprettelse (kap.9): ENDK udsender brugerinformationen Slettet: : Skrifttype: 10 pkt, Fed : Ikke Store bogstaver : Ikke Store bogstaver tabel : Punktopstilling 1. Baggrund for notat I forbindelse med DataHub projektet, er en af de mere komplekse opgaver at få migreret data sikkert og præcist fra alle netvirksomheder, da dette er en forudsætning for idriftsættelse af DataHub og de nye markedsprocesser. Slettet: Baggrund for notat : Punktopstilling : Overskrift 1 Denne rapport beskriver den strategi og plan der skal være grundlaget for en succesfuld datamigrering. 1.1 Begrundelse for migrering Ved idriftsættelse af DataHub skal DataHub som minimum have stamdata for alle aktive målepunkter, herunder aktuel disponent, elleverandør og balanceansvarlig. Slettet: <#> <#>Begrundelse for datamigrering : Overskrift 2 Da DataHub overtager opgaven med Saldoafregning, betyder dette at det ikke er tilstrækkelig med aktuelle stamdata på målepunkter, der er også visse historiske stamdata for målepunkter der skal migreres. Måledata skal også migreres i DataHub, igen af hensyn til Saldoafregningsopgaven, men måledata er også nødvendige for at kunne tilbyde historiske data til elleverandører i forbindelse med tilbudsgivningen. Der skal udelukkende migreres data fra netvirksomheder og målepunkter som Energinet.dk er ansvarlige for. 1.2 Arbejdsmetode Der er i DataHub projektet etableret en ekspertgruppe med fokus på datamigrerings-opgaven, og arbejdsopgaverne for gruppen er defineret i kommissoriet: - Identificere og beskrive migreringsopgaver - behov, omfang og kompleksitet - Beskrive mulige løsningsmodeller for migrering af stamdata, måledata og processer. - Fastlægge en detaljeret migreringsplan og udarbejde alternative nødplaner - Fastlægge en plan for overflytning af Saldoafregning - Gennemføre migreringstest med netvirksomheder (og elleverandører) - Afklare spørgsmål i forbindelse med migreringsprocessen Ekspertgruppen har deltagere fra netvirksomheder, it-leverandører og Energinet.dk. Dok , Sag /28

4 Migreringsopgaven er kompleks, og der er mange deltagere i løsningen af opgaven, så for at minimere risiko ved implementeringen af migreringen er der i arbejdsgruppen enighed om, at der ved valg af løsningsmuligheder skal fokuseres på enkle løsninger, frem for forkromede 120% løsninger. Dok , Sag /28

5 2. Datamængder Der skal migreres data fra 77 netvirksomheder (antal pr ), med et samlet antal målepunkter på ca. 3.2 mio. Nedenstående tabel viser antal målepunkter (MP) pr. netvirksomhed for de 25 største netvirksomheder. Tabellen er sorteret efter faldende antal målepunkter, og den viser at disse 25 største netvirksomheder dækker mere end 90% af alle målepunkter der skal migreres. x1000 MP Pct. MP Akk. pct. Netvirksomhed 908,6 28,0 28,0 791 Dong Energy Eldistribution A/S 365,5 11,3 39,3 740 SEAS-NVE A.m.b.a. 260,3 8,0 47,4 344 SYD ENERGI Net A/S 210,2 6,5 53,9 151 NRGi A.m.b.a. 150,2 4,6 58,5 131 EnergiMidt Net A/S 133,0 4,1 62,6 244 TRE-FOR 85,6 2,6 65,2 543 Energi Fyn 75,9 2,3 67,6 044 HEF Net A/S 74,5 2,3 69,9 543 Energi Fyn City 62,6 1,9 71,8 052 AKE Forsyning A/S 59,5 1,8 73,7 751 Frederiksberg Elnet A/S 57,6 1,8 75,4 232 Østjysk Net A/S 51,5 1,6 77,0 031 ENV NET A/S 50,9 1,6 78,6 149 ELRO Net A/S 43,8 1,4 79,9 331 Thy-Mors Energi El-Net ( ) 43,7 1,3 81,3 023 Nyfors 43,2 1,3 82,6 353 EnergiMidt Net Vest A/S 41,4 1,3 83,9 152 Energi Randers net A/S 39,5 1,2 85,1 046 ESV 31,2 1,0 86,1 533 SEF Net A/S, c/o Sydfyns Elforsyning 29,4 0,9 87,0 347 NOE A.m.b.a. 28,2 0,9 87,9 911 Østkraft Net 26,6 0,8 88,7 348 RAH Net A/S 25,2 0,8 89,5 860 SK Elnet A/S 23,4 0,7 90,2 145 GE Net A/S Datakilde: Dansk Elforsyning Statistik 2009 Dok , Sag /28

6 Nedenstående diagram illustrerer på samme måde fordelingen af antal målepunkter mellem netvirksomhederne. I migreringsprocessen skal der i processen tages højde for forskellen mellem de datamængder der skal migreres fra netvirksomhederne, og der skal tilbydes forskellige metoder for migreringen (f.eks. upload af data via FTP server, mail-løsning eller fysisk flytning (DVD)). Dok , Sag /28

7 3. Saldoafregning Saldoafregningen vedrører kun skabelonafregnede forbrugsmålepunkter. Saldoafregningen overtages af DataHub pr , og fra dette tidspunkt afregnes efter nye regler beskrevet i Pseudo-forskrift H2. Saldoafregningen der udføres for 2011 skal ske efter eksisterende regler, og udføres derfor af netvirksomhederne i hele Saldoafregningen skal i 2012 udføres af netvirksomhederne med samme frekvens som i 2011, afhængig af om kunderne i netområdet aflæses rullende (et antal kunder aflæses hver måned eller hvert kvartal) eller om alle kunder aflæses en gang årligt samtidig i hele netområdet. Overflytning af saldoafregningsopgaven fra netvirksomhederne til Energinet.dk er en større konverteringopgave som ikke vil blive behandlet i dette notat. Overflytningen vil ske efter idriftsættelsen af DataHub fra fjerde kvartal 2012 til primo Slettet: NDK Migreringen skal sikre, at stamdata og måledata er til rådighed, således at grundlaget for afvikling af Saldoafregningen for januar 2012 er til stede i Datahub. Nedenstående illustrerer forløbet for saldoafregningerne fra Ny Saldoafregning Netvirksomhed Aflæsning Aflæsning Periode: Afregn: Aflæsning Aflæsning Periode: Afregn: Aflæsning Aflæsning Periode: Afregn: Aflæsning Aflæsning Periode: Afregn: DataHub Periodeforbrug Periodeforbrug påbaggrund af Periodeforbrug påbaggrund af aflæsning 2012-mm påbaggrund af aflæsning aflæsning Periode: Afregn: Periodeforbrug påbaggrund af aflæsning Periode: Afregn: Saldoafregningen udføres udfra den aflæsning der dækker overgangstidpunktet ( ). I 2011 gennemfører netvirksomhederne saldoafregningen for månederne i 2010 uden ændringer i forhold til tidligere. Dok , Sag /28

8 I 2012 gennemfører netvirksomhederne saldoafregningerne for alle måneder i Den sidste saldoafregning netvirksomhederne gennemfører, er for december 2011, som tidligst kan gennemføres i december 2012 (når sidste aflæsning er modtaget). Den første saldoafregning DataHub udfører med de nye regler, er for januar Denne afregning kan tidligst ske i januar 2013, da de sidste aflæsninger for januar 2012 vil være indeholdt i forbruget opgjort på baggrund af aflæsningen januar For at DataHub kan periodisere forbrug for alle målepunkter for januar skal der i Data- Hub findes forbrug aflæst "henover" januar DataHub indeholder ikke måleaflæsninger men forbrug - så de forbrug der er indsendt i løbet af 2012, vil alle dække januar Af hensyn til Saldoafregningen, skal DataHub altså have et forbrug der indeholder januar 2012 for alle målepunkter. Til brug for Saldoafregningen skal alle stamdata for målepunkter være komplette for hele 2012, herunder leverandørskifte og flytninger. Specielt for netvirksomheder der anvender justeret residual til saldoafregningen, skal der migreres det justerede residualforbrug der er anvendt i saldoafregningen i 2011, således at DataHub kan periodisere de periodiserede aflæsninger hen over årsskiftet 2011/2012. Denne migrering vil ske efterfølgende, og er ikke en del af den almindelige migreringsprocedure. 4. Andelstalsberegning Netvirksomhederne beregner og udsender andelstal for i september 2012 for sidste gang. Beregning og udsendelse af andelstal for sker i DataHub i oktober DataHub skal til Saldoafregningen bruge andelstallene pr. leverandør for januar oktober Disse andelstal migreres manuelt af Energinet.dk. Slettet: <#>Afstemning af Saldoafregning ved migreringen På baggrund af de indsendte forbrug kan DataHub danne et periodiseret forbrug for hvert målepunkt for hver måned herunder december dette periodiserede forbrug pr. målepunkt skal stemme med det periodiserede forbrug som netvirksomheden har beregnet for Slettet: september Slettet: NDK. Dok , Sag /28

9 5. Stamdata for målepunkter Der skal migreres stamdata for alle målepunkter der er aktive pr , og der skal migreres stamdata hørende til alle migrerede måledata. Slettet: 2 Målepunkt Migreres af Stamdata for målepunkt migreres (minimum) fra Timeafregnet forbrugsmålepunkt Skabelonafregnet forbrugsmålepunkt Netvirksomhed Udvekslingsmålepunkt Netvirksomhed Produktionsmålepunkt ENDK Målepunkter vedr. nettoafregnede produktionsanlæg Tekniske målepunkter (f.eks. udveksling 60/150 kv, reaktive målere) Netvirksomhed Fra starttidspunktet for den afregningsrelevante aflæsning der dækker forbruget oktober ENDK ENDK beskrives i særskilt notat fra ENDK Slettet: perioden Slettet: over perioden for måledata for hvert målepunkt For oplysningerne vedr. disponenten (navn og evt. fødselsdato) på forbrugsmålepunkter gælder specielt, at det kun er oplysningen om den aktuelle (og evt. fremtidige) disponent der er relevant. Måledata (forbrugsopgørelse) i forbindelse med den sidst effektuerede flytning på målepunktet skal migreres (hvis denne flytning er sket efter ), og ligeledes skal stamdata migreres hvis der i forbindelse med tidligere flytninger er sket et leverandørskifte. Det er ikke et krav at migrere alle flytninger (disponenter på målepunkterne), men af hensyn til fuldstændighed i data anbefales det at migrere alle flytninger og leverandørskifte der er sket på hvert målepunkt. Stamdata for målepunkter der skal migreres, baseres på "Pseudo-forskift I - Stamdata" Slettet: en Slettet: n Slettet: r Slettet: tilladt Slettet: det Slettet: er ikke et krav Slettet:. I regnearket "DataHub - Migrering filbeskrivelse" (der kan findes på DataHub hjemmesiden) kan der findes en nærmere beskrivelse af de enkelte felter der migreres, og den validering der foretages ved migreringen. Specielt skal hver netvirksomhed være opmærksom på at oprette forbrugsmålepunktet "Nettab", og heri specificere forventet årsforbrug. Dok , Sag /28

10 6. Måledata Slettet: I det nedenstående skal "Fra dato" forstås som 6.1 Oversigt over krav til migrering af måledata "Fra og med dato". Måling Migreres af Måledata migreres fra og med Timeafregnet forbrug Netvirksomhed Af hensyn til at kunne gennemføre saldoafregningen Skabelonafregnet forbrug Netvirksomhed Aflæsningen som dækker forbruget for oktober 2011 Udvekslingsmåling (kvarters- eller timemålt) Produktionsmålinger (kvarters- eller timemålt) Målinger vedr. nettoafregnede produktionsanlæg Tekniske målinger (udveksling 60/150 kv, reaktive målinger) Netvirksomhed ENDK ENDK ENDK skal kendes for alle skabelonafregnede målepunkter der er tilsluttet pr Der skal som minimum migreres forbruget for én aflæsningsperiode for disse målepunkter beskrives i særskilt notat fra ENDK fra januar 2012, skal der migreres måledata tilbage i tid fra før januar : Overskrift 2 Slettet: F Slettet: Slettet: 2 1 Bemærk, at evt. timemålinger for skabelonafregnede målepunkter ikke migreres, da disse ikke er relevante for saldoafregningen. 6.2 Migreringsstart for skabelonafregnet forbrug Der kan ikke gives en eksakt dato for hvornår data skal migreres fra, idet dette afhænger af aflæsningsperioden for hvert skabelonafregnet målepunkt. : Overskrift 2 Slettet: Vedr. skabelonafregnet forbrug: Nedenstående figur illustrerer (med grøn farve) hvilke forbrugsmålinger der skal migreres for skabelonafregnede målepunkter: 2010 Jul Aug Sep Okt Nov Dec 2011 Jan Feb Mar Apr Maj Jun Jul Aug Sep Okt Nov Dec 2012 Jan Feb Mar Apr Maj Jun Jul Aug Sep Okt Nov Dec Slettet: Måledata fra Månedsaflæst: Kvartalsaflæst: Årsaflæst Apr: Årsaflæst Dec: Årsaflæst Sep: Data migreres ikke Data skal migreres Princippet er, at perioden for forbruget skal dække oktober dog er der krav om at der som minimum skal migreres én aflæsningsperiode, hvilket betyder at "Årsaflæst Sep" skal migreres for perioden Slettet: Nedenstående tabel viser eksempel på sammenhængen mellem aflæsninger og startdato for migrering af måledata: Måle-punkt... [1] Dok , Sag /28

11 Starttidspunktet for stamdata for målepunktet, skal være mindre end eller lig med starttidspunktet for måledata for målepunktet. 6.3 Korrektioner af måledata efter idriftsættelse af DataHub Eventuelle korrektioner af de måledata der er migreret, skal følge processerne beskrevet i pseudo-forskrift D1 - korrektionerne indmeldes til DataHub via de beskrevne forretningsprocesser. Korrektioner for måledata der ikke er migreret, håndteres af netvirksomhederne. Det er netvirksomhedernes opgave at formidle korrektioner til den/de berørte elleverandør(er). Hvis der til DataHub'en indsendes korrektioner til måledata for en periode der ikke er migreret data for, vil disse måledata blive afvist af DataHub. 7. Forretningsprocesser ved idriftsættelse af DataHub Ved idriftsættelsen af DataHub, vil alle eksisterende markedsprocesser blive stoppet fra et givet tidspunkt medio september 2012 (dato specificere nærmere i detailplanlægningen). Alle leverandørskifte processer der sker i det eksisterende regime primo september 2012 vil vedrøre leverandørskifte til datoen Efter idriftsættelse af DataHub kan evt. udestående leverandørskifte pr (ventende fra medio september) nemt gennemføres, da fristen for leverandørskifte med de nye regler nu er 10 arbejdsdage. Samme metode anvendes for indmelding af flytninger, således at alle flytteprocesser i det gamle regime stoppes medio september. Slettet: <#>Forskriftskrav I pseudo-forskrift H1 (afsnit 3.5) er der flg. krav til timeafregnede målepunkter: "For timeafregnede kunder kan historiske timedata hentes, så længe kunden har været registreret på målepunktet, dog højst 1 år" Dette krav er opfyldt af ovenstående krav til migrering. I psudo-forskrift H1 (afsnit 3.5) er der flg. krav til skabelonafregnede målepunkter: "For skabelonafregnede målepunkter kan kundens registrerede skabelonafregnede forbrug for de seneste 3 år samt det forventede årsforbrug hentes i Data- Hub'en." "1 Alene forbrug fra 1. januar 2011 og frem vil være tilgængelig i DataHub'en" Med fodnotens bemærkning, opfyldes kravet fra pseudo-forskrift H1. I Psudo-forskrift D1 (afsnit 5.1.1) er følgende krav: "Netvirksomheden skal mindst en gang månedligt lave en kontrol af, om de måledata for skabelonafregnede målepunkter, der ligger i DataHub'en indtil 3 år tilbage, er identiske med dem, der ligger i netvirksomhedens database." Da måledata ved idriftsættelsen af DataHub ikke er tilgængelige 3 år tilbage, vil dette krav kun være gældende for de migrerede data - indtil data efterhånden opbygges i DataHub. Denne tolkning af kravet er konfirmeret i Ekspertpanelet. : Punktopstilling : Skrifttype: Kursiv Dok , Sag /28

12 8. Migreringsmetode 8.1 Overordnet beskrivelse Netvirksomhederne danner udtræk af stamdata og måledata fra egne systemer. Udtrækkene sker til tre simple csv-filer, der indlæses i Migreringssystemet hos Energinet.dk. Data vil her blive valideret, og hvis data opfylder valideringskriterierne, læses data ind i migreringssystemet. Netvirksomhederne kan løbende danne rapporter der viser status på indlæsningerne - hvor mange er ok, hvor mange er fejlet - og hvorfor er de fejlet. Netvirksomhederne kan selv styre migreringsprocessen via web-interface, og migreringen kan udføres successivt. Elleverandørene kan løbende i processen udtrække en rapport (csv-fil) der viser stamdata for de målepunkter elleverandøren er registreret som leverandør på. Denne rapport skal elleverandøren anvende til validering af de migrerede data. Hvis elleverandøren finder uoverensstemmelser i data, udredes dette bilateralt mellem elleverandøren og netvirksomheden i migreringsforløbet. Gridoperators ENDK Create extract Import Validate Reporting Clearing Errors Systemmæssigt vil Migreringssystemet være en del af DataHub løsningen, med egne funktioner og egne skærmbilleder (web). Systemet vil kun være aktivt i migreringsperioden, og vil blive lukket ved go-live af DataHub. Dok , Sag /28

13 Som udgangspunkt afleveres datafilerne fra netvirksomhederne til Migreringssystemet via SFTP. 8.2 Elleverandørenes opgave Elleverandørene skal i migreringssystemet udtrække rapport (csv-fil) der viser alle stamdata for alle de målepunkter, der er tilknyttet den pågældende elleverandør, Elleverandørene skal kontrollere at stamdata for målepunkterne er i overensstemmelse med elleverandørens oplysninger. Ved evt. uoverensstemmelse skal elleverandøren udrede dette bilateralt med netvirksomheden. 8.3 Datafiler til migrering Der vil være tre typer filer der migreres i nedenstående rækkefølge: 1. Målepunkter (ALL_CONNECTION). Indeholder kun én kolonne med alle GSRN numre på målepunkter, der skal migreres. Anvendes til validering af efterfølgende indlæste stamdata og til opgørelse af status (hvor mange målepunkter mangler at blive migreret). 2. Stamdata for målepunkter (MASTERDATA). Indeholder alle stamdata for målepunkter, herunder også ændringer i stamdata over tid, f.eks. leverandørskifte. 3. Måledata (METERDATA). Indeholder måledata for perioder (skabelonafregnede målepunkter), eller på time-/kvartersbasis. Herudover findes en speciel filtype (), som kan anvendes hvis netvirksomheden ønsker at slette evt. migrerede data. Filen indeholder én kolonne med de GSRN numre der ønskes slettet, og alle måledata og stamdata for de pågældende målepunkter slettes i migreringssystemet. Filerne indlæses uafhængigt af hinanden og filerne kan deles i mindre filer, der indeholder dele af netvirksomhedens data. Rækkefølgen af indlæsningen for et målepunkt skal følge den angivne (målepunkter -> stamdata for målepunkter -> måledata), og data skal migreres i kronologisk orden. Slettet:. Dok , Sag /28

14 Filerne kan indlæses flere gange. Hvis der er ændringer i data i forhold til sidste indlæsning, vil disse ændringer blive migreret. I afsnit 11 beskrives det præcise format for de fire filtyper, og regler for navngivningen af filerne. 9. Tidsplan for migrering 9.1 Migreringsfaser Migreringen foregår i to hovedfaser: TestMigrering Oktober Marts 2012 Netvirksomhederne skal her blive fortrolige med migreringsproceduren, og her teste migreringen af så mange data som muligt, således at evt. fejl i data allerede opdages i denne fase. Det er muligt at slette allerede migrerede data, for at teste migreringsprocessen så meget som muligt. DriftsMigrering April September 2012 Efter afsluttet TestMigrering slettes alle data i migreringssystemet, og data der migreres i Driftsmigreringsfasen, migreres med henblik på endelig overflytning af data til DataHub. Indtil juni 2012 er det muligt at slette migrerede data. Migreringen er mere detaljeret planlagt i følgende faser: Fase Periode Netvirksomheder Energinet.dk Forberedelse Nu - Start TestMigrering TestMigrering Start Driftsmigrering DriftsMigrering Flytning til Data- Hub Klargøre egne applikationer til udtræk af data i migreringsfiler. Datavask af egne data. Brugeroplysninger udsendes fra ENDK til it-leverandører og aktører Migrering af data - opfølgning på evt. afviste data Teste migreringssystem. Konfigurering af system. Oprette brugere i migreringssystemet. Rettigheder til SFTP Alle migrerede data i Migreringssystemet slettes DeltaMigrering Migrering af data til Data- Hub - opfølgning på evt. afviste data. Indlæsning af "deltaload" - dvs. ændrede/nye data fra Go-Live Migreringssystemet lukkes. Ændringer/nye data anven- Migreringssystemet lukkes Data flyttes fra migreringssystemet til Data- Hub. Flytning af "delta-load" fra migreringssystem til DataHub 1 Slettet: til Slettet: 15 Dok , Sag /28

15 der standard forretningsprocesser. 9.2 Milepæle Energinet.dk følger op på nedenstående milepæle baseret på statusrapporter fra migreringssystemet, og vil følge tæt op på netvirksomheder der ikke overholder specificerede milepæle. Dato Ansvarlig Milepæl TestMigrering ENDK Migreringssytem færdigkonfigureret og alle brugere fra netvirksomheder er oprettet. ENDK har udsendt brugeroplysninger til alle itleverandører og aktører Alle it-leverandører - Alle it-leverandører har afprøvet indlæsning af migreringsfiler dannet fra eget system Alle netvirksomheder - Alle netvirksomheder har indlæst ALL_CONNECTION (alle målepunkter) (intet krav om fuldstændighed) - Alle netvirksomheder har indlæst MASTERDATA og migreret stamdata med succes (intet krav om antal) - Alle netvirksomheder har indlæst METERDATA og migreret måledata med succes (intet krav om antal) Alle netvirksomheder - Alle netvirksomheder har indlæst ALL_CONNECTION med alle målepunkter - Alle netvirksomheder har indlæst MASTERDATA og migreret stamdata med succes for 80% af alle målepunkter angivet i ALL_CONNECTION - Alle netvirksomheder har indlæst METERDATA og migreret måledata med succes for 50% af de timeafregnede målepunkter og 50% af de skabelonafregnede målepunkter angivet i ALL_CONNECTION (intet krav om antal målinger) Elleverandører Alle elleverandører har lavet rapport udtræk af stamdata for egne målepunkter DriftMigrering Netvirksomheder - Alle netvirksomheder har indlæst ALL_CONNECTION med alle målepunkter - Alle netvirksomheder har indlæst MASTERDATA og migreret stamdata med succes for 90% af alle målepunkter angivet i ALL_CONNECTION - Alle netvirksomheder har indlæst METERDATA og migreret måledata med succes for 50% af de timeafregnede målepunkter og 50% af de skabelonafregnede målepunkter angivet i ALL_CONNECTION (intet krav om antal målinger) Elleverandører Alle elleverandører har lavet rapport udtræk af stamdata for egne målepunkter og verificeret disse Netvirksomheder - Alle netvirksomheder har indlæst ALL_CONNECTION med alle målepunkter - Alle netvirksomheder har indlæst MASTERDATA og Slettet: Slettet: 1 Slettet: [2] Dok , Sag /28

16 migreret stamdata med succes for 95% af alle målepunkter angivet i ALL_CONNECTION - Alle netvirksomheder har indlæst METERDATA og migreret måledata med succes for 90% af de timeafregnede målepunkter og 90% af de skabelonafregnede målepunkter angivet i ALL_CONNECTION (intet krav om antal målinger) 9.3 Detaljeret tidsplan ved go-live Nedenstående illustrerer den detaljerede tidsplan omkring go-live tidspunktet. Den endelige detailplanlægning sker medio Fredag Sidste processer med gl. regler Lørdag Søndag Mandag Tirsdag Onsdag Torsdag Fredag Lørdag Søndag Mandag Start Tirsdag Onsdag Torsdag Fredag 10. Nødplaner Her beskrives senere nødplaner i forbindelse med go-live. Dok , Sag /28

17 11. Migreringsfiler 11.1 Generelle regler - Tegnsæt i alle migreringsfiler er UTF-8. - Skilletegn mellem felterne er tegnet " " (Unicode 007C). - Alle linjer i filen afsluttes med linjeskift <LF> (Unicode 000A) - Data i filen må ikke indeholde linjeskift <LF> - Decimaltal angives med "." som decimalseparator, og uden tusindeadskillelse, f.eks Datoformat i filerne er: YYYY-MM-DD (eks.: ) - Tidsformat i filerne er: YYYY-MM-DDTHH:MMZ (eks.: T11:00Z) - Tidsstempel på måledata skal angives i UTC+0 : Punktopstilling Det generelle filformat ser således ud: HDR MASTERDATA T15:43Z 327 Testkørsel med ny version<lf> DATA <LF> DATA <LF> DATA <LF> DATA <LF> FTR <LF> Første linje i filen er en headerlinje (HDR) der beskriver filindholdet, herefter følger datalinjerne (DATA) der er afhængige af filtypen, og filen afsluttes med en footer-linje (FTR) der indeholder antal records i filen og evt. definerede checksummer for data Headerlinje (HDR) Headerlinjen er ens for de tre filtyper. Hvis én af feltvalideringerne fejler i headerlinjen, afvises hele filen. Felt nr. Beskrivelse Opt/ Man Validering 1 Recordnavn: HDR M Skal være "HDR" HDR 2 Migreringsfiltype, én af typerne: - ALL_CONNECTION - MASTERDATA - METERDATA - 2 DEF nummer på netvirksomhed (med evt. foranstillet nul) 3 Tidspunkt for dannet dataudtræk 4 Migreringsnummer - anvendes til intern styring af migreringsproces i netvirksomheden. Nummeret anvendes til reference i rapporteringen fra mi- M M M M En af de tre lovlige filtyper DE nummer skal findes i migreringssystemet Tidspunkt skal overholde format og være valid Migreringsnr. skal være entydigt for hver fil for hver netvirksomhed Eksempel MASTERDATA T15:43Z 327 Dok , Sag /28

18 greringsprocessen og skal derfor være entydigt pr. netvirksomhed. 5 Frit tekstfelt. Kan anvendes frit af netvirksomheden. Teksten migreres ikke, men er kun tiltænkt som intern hjælp for netvirksomheden. O - Testkørsel med ny version Eksempel på de fire filtyper: HDR ALL_CONNECTION T15:43Z 044 Testkørsel med ny version<lf> : Dansk HDR MASTERDATA T09:43Z upload af målepunkter<lf> HDR METERDATA T09:45Z 255 Måledata<LF> HDR T11:43Z 042 Slet testmålepunkter<lf> 11.3 Datalinje (DATA) Feltbeskrivelserne for datalinjen er individuel for de tre filtyper - se efterfølgende afsnit 2,3 og 4 - og er beskrevet detaljeret i regnearket "Migration - DataFields" Felt nr. Beskrivelse Opt/ Man Validering 1 Recordnavn: DATA M Skal være "DATA" 2 Aftagenummer (GSRN) for målepunktet X Eksempel: Data er afhængige af filtypen DATA <LF> M Valideres som gyldig GSRN Eksempel DATA Hvis én af valideringerne fejler i datalinjen, afvises alle linjer i filen der vedrører det pågældende aftagenummer (GSRN) Footerlinje (FTR) Hvis én af valideringerne fejler i footerlinjen, afvises hele filen. Felt nr. Beskrivelse Opt/ Man Validering 1 Recordnavn: FTR M Skal være "FTR" FTR 2 Antal linjer i filen (incl. denne linje) 2 Checksum for udvalgt felt: - ALL_CONNECTION: sum af de 3 sidste cifre i alle GSRN numre (number(20)). - MASTERDATA: sum af alle postnumre (number(20)). - METERDATA: sum af alle værdier (målinger) (number(25.3)) M O Antal skal stemme med antallet af linjer i filen Til hver filtype er der defineret checksumsberegniner for specifikke felter Eksempel Slettet:.43 Slettet:. Dok , Sag /28

19 - : sum af de 3 sidste cifre i alle GSRN numre (number(20)). Slettet: Eksempel: FTR Eksempel: ALL_CONNECTION Filen indeholder den fulde liste af målepunkter der skal migreres for netvirksomheden. I footerlinjen (FTR) i checksumfeltet summen af de tre sidste cifre i alle GSRN numre. Eksempel på fil for "ALL_CONNECTION": HDR ALL_CONNECTION T15:43Z 327 Load af de første målepunkter<lf> DATA <LF> DATA <LF> DATA <LF> DATA <LF> DATA <LF> DATA <LF> DATA <LF> FTR <LF> 11.6 Eksempel: MASTERDATA Filen indeholder stamdata for målepunkter. I footerlinjen (FTR) i checksumfeltet angives summen af alle postnumre (felt nr. 13). Detaljeret feltbeskrivelse findes i regnearket "Migration DataFields" Eksempel på fil for MASTERDATA: HDR MASTERDATA T15:43Z 327 Load af stamdata for fire målepunkter<lf> DATA E32 E17 E Tonne Kjærsvej 65A 7000 osv DATA E32 E17 E Tonne Kjærsvej osv <LF> DATA E32 E17 E Tonne Kjærsvej osv <LF> DATA E32 E17 E Tonne Kjærsvej osv <LF> FTR <LF> 11.7 Eksempel: METERDATA Filen indeholder registrerede målinger for målepunkter. I footerlinjen (FTR) angives summen af alle værdier i checksumfeltet. Detaljeret feltbeskrivelse findes i regnearket "Migration DataFields" Eksempel på fil for METERDATA: HDR METERDATA T15:43Z 327 Load af registreringer for to målepunkter<lf> DATA T16:00Z T17:00Z E <LF> DATA T17:00Z T18:00Z E <LF> DATA T16:00Z T17:00Z E <LF> DATA T17:00Z T18:00Z E <LF> DATA T18:00Z T19:00Z E <LF> FTR <LF> : Tysk (Tyskland) Dok , Sag /28

20 11.8 Eksempel: Filen indeholder en liste af målepunkter der ønskes slettet i migreringssystemet. I footerlinjen (FTR) i checksumfeltet summen af de tre sidste cifre i alle GSRN numre. Eksempel på fil for "": HDR T15:43Z 327 Slet forkerte testmålepunkter<lf> DATA <LF> DATA <LF> DATA <LF> DATA <LF> FTR <LF> Dok , Sag /28

21 11.9 Konvention for filnavne Filnavnene på filer der skal migreres, skal overholde følgende navnekonvention: <filtype>_<netområdenr>_<migreringsnr>.dat Hvor <filtype> ALL_CONNECTION, MASTERDATA, METERDATA eller <netområdene> DE-nummer på netområde. Angives med 3 tegn. - evt. foranstillet nul. <migreringsnr> Entydigt løbenummer pr. netvirksomhed. Skal angives med 5 tegn - evt. foranstillet nul. Eksempler på tilladte filnavne: ALL_CONNECTION_023_00001.dat MASTERDATA_023_00001.dat METERDATA_023_00001.dat _023_00002.dat : Dansk Dok , Sag /28

22 Appendix A - Krav til måledata Dette appendix beskriver de krav der ligger til grund for fastsættelse af hvilke fra hvilken dato måledata (og masterdata) skal migreres. Forskriftskrav I pseudo-forskrifterne H1 og D1 er de generelle krav til måledata beskrevet. I pseudo-forskrift H1 (afsnit 3.5) er der flg. krav til timeafregnede målepunkter: "For timeafregnede kunder kan historiske timedata hentes, så længe kunden har været registreret på målepunktet, dog højst 1 år" Dette krav medfører, at timedata skal migreres fra I pseudo-forskrift H1 (afsnit 3.5) er der flg. krav til skabelonafregnede målepunkter: "For skabelonafregnede målepunkter kan kundens registrerede skabelonafregnede forbrug for de seneste 3 år samt det forventede årsforbrug hentes i DataHub'en 1." " 1 Alene forbrug fra 1. januar 2011 og frem vil være tilgængelig i DataHub'en" Fodnotens bemærkning blev tilføjet i H1, da go-live tidspunktet for DataHub var Som følge af ændret idriftsættelsesdato, fortolkes fodnoten som: "Alene forbrug fra 1. oktober 2011 og frem vil være tilgængelig i DataHub'en" Denne fortolkning medfører, at måledata for skabelonafregnede målepunkter skal migreres fra I pseudo-forskrift D1 (afsnit 5.1.1) er følgende krav: "Netvirksomheden skal mindst en gang månedligt lave en kontrol af, om de måledata for skabelonafregnede målepunkter, der ligger i DataHub'en indtil 3 år tilbage, er identiske med dem, der ligger i netvirksomhedens database." Da måledata ved idriftsættelsen af DataHub ikke er tilgængelige 3 år tilbage, vil dette krav kun være gældende for de migrerede data - indtil data efterhånden opbygges i DataHub. Denne tolkning af kravet er konfirmeret i Ekspertpanelet, og kravet får ingen betydning for datamigreringen. Saldoafregning For at kunne gennemføre saldoafregningen fra januar 2012 i DataHub, skal der migreres måledata for skabelonafregnede målepunkter således at forbruget for januar 2012 er kendt for alle skabelonafregnede målepunkter. Dette vil være dækket af de ovenstående krav fra pseudoforskrifterne, og medfører derfor ikke skærpede krav til migreringen. Dok , Sag /28

23 Appendix B - Fejlmeldinger ved migrering Nedenstående beskriver fejlmeldinger der kan forekomme ved indlæsningen af migreringsfiler. Bemærk, at dette er fejlmeldinger som beskrevet i design dokumentet for systemet, og der kan forekomme ændringer i det færdigudviklede system. : Dansk : Dansk : Dansk : Dansk : Dansk First the files will be checked whether they can be imported. The following checks will be performed during this phase: Error Code Validation File Type Error Message DM-001 DM-002 Check whether all the files are in UTF-8 without BOM. Check whether the records are ended with the correct delimiter. ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, File <filename> is not UTF-8 without BOM.* File <filename> has records that are not ended with a carriage return / linefeed (CR / LF). * As soon as one file is not in the correct format, the rest of the files will not be checked any more. If any of these checks is not successful, the files will be rejected and the total run will be stopped completely. Otherwise the files will be imported into the migration environment. During the import the following checks will be performed on the files. If errors are found during this import all these errors will be logged and represented in an error report. The files will be rejected and the total run will be stopped. The maximum number of errors that will be reported in the file will be 500. The following validations will be performed on the imported files: Error Code Validation File Type Error Message DM-101 DM-102 DM-103 DM-104 DM-105 DM-106 There is one header record present. The header record is not in the right format. There is no data record present. There is one footer record present. The footer record is not in the right format. The grid area in the header is different from the grid area in the file ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, There is no or more than one header record present. The header record is not in the right format. There is no data record present. There is no or more than one footer record present. The footer record in file is not in the right format. The grid area <header.meteringgridareaident ification> in the header is not Dok , Sag /28

24 Error Code Validation File Type Error Message DM-107 DM-108 DM-109 DM-110 DM-111 DM-112 DM-113 DM-114 DM-115 name. the same as the grid area <METERING_GRID_AREA_IDEN TIFICATION> in the file name. The grid area in the body is different from the grid area in the file name. The run number in the header is different from the run number in the file name. The number of records in the footer is not the same as the actual number of records in the file. The sum of the last three numbers of the GSRN s is not the same as the checksum for the sum in the footer of the file. The sum of the postal codes is not the same as the checksum for postal codes in the footer of the file. The sum of the quantities is not the same as the checksum for quantities in the footer of the file. The length of an attribute in the file is longer than the maximum length specified in the file definition for the body. The type of an attribute in the file is not conforming to the type specified in the file definition for the body. The metering point ID holds 18 digits, the last digit contains the checksum of the preceding 17 digits, i.e. sum(odd x 3, even x 1) mod 10. MASTERDATA ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA METERDATA ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION The grid area <body.meteringgridareaidentifi cation> in the body is not the same as the grid area <METERING_GRID_AREA_IDEN TIFICATION> in the file name. The run number <header.runnr> in the header is not the same as the run number <RUNNR> in the file name. In file the number of records <footer.numberofrecords> in the footer is not the same as the actual number of records <file.numberofrecords> in the file. The sum of the last three numbers of the GSRN s <sum of all GSRNs> is not the same as the checksum for GSRN s <footer.summeteringpointids> in the footer of the file. The sum of the postal codes <sum of all postcodes> is not the same as the checksum for postal codes <footer.sumpostcodes> in the footer of the file. The sum of the quantities <sum of all quantities> is not the same as the checksum for quantities <footer.sumquantities> in the footer of the file. The length of attribute <attribute name> is longer than the maximum length specified in the file definition for the body. The type of the attribute <attribute name> is different from the type of the of the attribute specified in the file definition for the body. The metering point ID <MeteringPointId> specified is not a valid GSRN / EAN18 code (wrong checksum). DM-116 The start or end time of METERDATA The attribute <attribute name> Dok , Sag /28

25 Error Code Validation File Type Error Message DM-117 DM-118 DM-119 DM-120 DM-121 DM-122 DM-123 a meter data record is not conform format YYYY-MM-DDTHH:MMZ. The metering point ID in the file has to be unique. The combination of metering point ID and occurrence has to be unique. The combination of metering point ID and start time has to be unique. The combination of metering point ID and end time has to be unique. An attribute in the file is mandatory in the file definition for the body. There must be files present to process. The combination of a file and one or more of the other files is not allowed. ALL_CONNECTION, MASTERDATA METERDATA METERDATA ALL_CONNECTION, MASTERDATA, METERDATA, ALL_CONNECTION, MASTERDATA, METERDATA, of metering point ID <MeteringPointId> is not in format YYYY-MM-DDTHH:MMZ. The metering point ID <MeteringPointId> is not unique in the file. The metering point ID <MeteringPointId> with occurrence <Occurrence> is not unique in the file. The metering point ID <MeteringPointId> and start time <StartTime> is not unique in the file. The metering point ID <MeteringPointId> and end time <EndTime> is not unique in the file. The attribute <attribute name> is mandatory in the file definition for the body.* There are no files present for run number <RUNNR> and grid area <METERING_GRID_AREA_IDEN TIFICATION> to process.** In a run a combination of a file and one or more of the other files is not allowed.** * This applies for GridOperatorId, MeteringPointId, MeteringGridAreaIdentification, Occurrence and EnergyTimeSeriesMeasureUnit of MasterData and for MeteringPointId and EnergyQuantity of MeterData. These fields are checked in this stage instead of during the validations in the staging area, since they are necessary to be filled for the migration process. ** The run number cannot be used anymore, because the run has already been started. After uploading the files into the staging area validations will be done on the uploaded data. When an error occurs during the validation of all connections or master data, all master data and meter data of the metering point will be rejected. When an error occurs during the validation of the meter data all meter data of the metering point will be rejected. All errors on the validation will be logged. The following validations will be done during this phase: Error Code Validation Entity Error Message DM-201 DM-202 Metering point is imported by the same grid operator as before. Metering point is imported by another grid operator as well. ALL_CONNECTION ALL_CONNECTION Metering point <MeteringPointId> in ALL_CONNECTION has already been delivered by the same grid operator. Metering point <MeteringPointId> in ALL_CONNECTION has already been delivered by grid operator <GridOperatorId>. DM-203 Metering point in the MASTERDATA Metering point <MeteringPoin-... [3]... [4]... [5]... [6]... [7]... [8]... [9]... [10]... [11]... [12]... [13] Dok , Sag /28

26 Error Code Validation Entity Error Message DM-204 DM-205 DM-206 DM-207 DM-208 DM-209 DM-210 DM-211 DM-212 MASTERDATA file has not been delivered in ALL_CONNECTION file yet (or has been deleted in the past). A master data state that has already been migrated to DataHub cannot be replaced. Type of metering point in the MASTERDATA file should not be changed. The occurrence of the new connection state of a metering point in the MASTERDATA file should not be before the occurrences of the already present connection states in the migration area. The new connection state of a metering point with occurrence in the MASTERDATA file is not different for the other fields to the current master data connection state in the migration area. Metering point in the METERDATA file has not been delivered in ALL_CONNECTION file yet (or has been deleted in the past). No MASTERDATA available for this metering point between start and end date of meter data. Meter data that has already been migrated to IS-Change cannot be replaced any more. Metering point is not yet present, therefore it cannot be deleted. Metering point has already been migrated. MASTERDATA MASTERDATA MASTERDATA MASTERDATA METERDATA METERDATA METERDATA tid> in the MASTERDATA file has not been delivered in ALL_CONNECTION file or has been deleted. The records for this metering point will be rejected. For metering point <Metering- PointId> a connection state with occurrence <Occurrence> has already been migrated to Data- Hub. This state cannot be replaced anymore. The type of metering point <TypeOfMP> of metering point <MeteringPointId> in the MASTERDATA file must not be changed. The occurrence <Occurrence> of the new connection state of metering point <MeteringPointId> in the MASTERDATA file may not be before the occurrence <Occurrence>* of the already present connections states in the migration area. The new connection state of metering point <MeteringPointId> with occurrence <Occurrence> in the MASTERDATA file is not different for the other fields to the current master data connection state with occurrence <Occurrence> in the migration area. Metering point <MeteringPointId> in the METERDATA file has not been delivered in ALL_CONNECTION file or has been deleted. The records for this metering point will be rejected. No MASTERDATA available for <MeteringPointId> between start and end date of meter data. The records delivered in the METERDATA file for this metering point will be rejected.** For metering point <Metering- PointId> meter data with start time <StartTime> has already been migrated to DataHub. This data cannot be replaced anymore. Metering point <MeteringPointId> is not yet present, therefore it cannot be deleted. Metering point <MeteringPointId> in : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke : Ikke Dok , Sag /28

27 Error Code Validation Entity Error Message DM-213 DM-214 DM-215 DM-216 DM-217 DM-218 DM-219 DM-220 DM-221 DM-222 DM-223 DM-224 The metering grid area of a metering point must belong to the correct grid operator. The metering point has been delivered by another grid operator. If a meter data record with a start time before the occurrence of the master data state has already been migrated the master data state cannot be migrated. The start time for meter data is mandatory. The end time for meter data is mandatory. The meter data number of values for a time serie doesn't match the meter reading occurrence of the master data The quantity status for meter data is mandatory. The quantity status for meter data has domain values 56 (Estimated), E01 (Registered). The energy quantity for meter data is mandatory. The new connection state of a metering point with occurrence in the MASTERDATA file is not different for the other fields to the previous master data connection state in the same file. Overlap in meter data periods is not allowed The end time for meter data cannot be in the future. MASTERDATA METERDATA METERDATA METERDATA METERDATA METERDATA METERDATA MASTERDATA METERDATA METERDATA has already been migrated to DataHub. Metering grid area <Metering- GridAreaIdentification> for metering point <MeteringPointId> doesn't belong to grid operator <GridOperatorId>.*** The metering point <Metering- PointId> has been delivered by another grid operator <GridOperatorId>. For metering point <Metering- PointId> a meter data record with start time <StartTime> has already been migrated. Therefore the connection state with occurrence <Occurrence> cannot be entered anymore. Meter data start time is missing for metering point <Metering- PointId>. Meter data end time is missing for metering point <Metering- PointId>. The meter data number of values for a time series doesn't match the meter reading occurrence for metering point <MeteringPointId>. Meter data quantity status is missing for metering point <MeteringPointId>. Meter data quantity status <QuantityStatus> for metering point <MeteringPointId> has wrong value (outside domain). Meter data energy quantity is missing for metering point <MeteringPointId>. The new connection state of metering point <MeteringPointId> with occurrence <Occurrence> in the MASTERDATA file is not different for the other fields to the previous master data connection state with occurrence <Occurrence> in the same file. Meter data record for Metering- Point <MeteringPointId> and <StartTime> is rejected. There is already a record present with an overlapping period. The end time for meter data record for MeteringPoint <MeteringPointId> and start time : Ikke : Ikke... [14]... [15]... [16]... [17]... [18]... [19]... [20]... [21]... [22] 0 yyyy... [23] Dok , Sag /28

28 Error Code Validation Entity Error Message <StartTime> is rejected. The end time <EndTime> is in the future. * The most recent occurrence will be shown. ** Only the whole meter data period has to be shown, so not all meter data values individual. *** For MASTERDATA and METERDATA it will be done below. In the error reports on these validation, not only the error message will be shown but when applicable also the MeteringPointId and for the master data the Occurrence and for meter data StartTime and EndTime will be shown. With this information it is possible to identify the record that has been rejected. There will be no validations on the completeness of meter data. The reports will show which meter data values are missing. Of course before migration all meter data has to be present. Dok , Sag /28

29 Side 10: [1] Slettet Jens Grundtvig :55:00 Nedenstående tabel viser eksempel på sammenhængen mellem aflæsninger og startdato for migrering af måledata: Målepunkt Aflæsning 1 Aflæsning 2 Aflæsning 3 Aflæsning 4 Måledata migreres fra Side 15: [2] Slettet Jens Grundtvig :29: Alle netvirksomheder Alle netvirksomheder skav have indsendt formular til ENDK vedr. ønskede brugernavne (formular udsendes af ENDK) Side 25: [3] Jens Grundtvig :05:00 Engelsk Side 25: [4] Jens Grundtvig :05:00 Engelsk Side 25: [5] Jens Grundtvig :05:00 Engelsk Side 25: [6] Jens Grundtvig :05:00 Engelsk Side 25: [7] Jens Grundtvig :05:00 Engelsk Side 25: [8] Jens Grundtvig :05:00 Engelsk Side 25: [9] Jens Grundtvig :05:00 Engelsk Side 25: [10] Jens Grundtvig :05:00 Engelsk Side 25: [11] Jens Grundtvig :11:00 Ikke Side 25: [12] Jens Grundtvig :11:00 Ikke Side 25: [13] Jens Grundtvig :11:00 Ikke Side 27: [14] Jens Grundtvig :11:00 Engelsk Side 27: [14] Jens Grundtvig :11:00 Engelsk