DataHub Bilag 3a Kundens kravspecifikation. 1.0 Udbudsmateriale til udsendelse d. 5. juli EU-udbud 2010/S

Størrelse: px
Starte visningen fra side:

Download "DataHub 31785-10. Bilag 3a Kundens kravspecifikation. 1.0 Udbudsmateriale til udsendelse d. 5. juli 2010. EU-udbud 2010/S 97-149624"

Transkript

1 DataHub 1.0 Udbudsmateriale til udsendelse d. 5. juli DATE MLM ADA NAME DATE REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED EU-udbud 2010/S NAME Doc. no. Energinet.dk

2 Vejledning Vejledning: Bilaget er færdigt, og det er et mindstekrav, at leverandøren ikke foretager ændringer i bilaget Dok /10, Sag 10/3365 2/132

3 Indholdsfortegnelse 1. INDLEDNING Læsevejledning INTRODUKTION TIL DATAHUB PROJEKTET Formål Baggrund Energinet.dk Elmarkedet OVERORDNET BESKRIVELSE Opgavebeskrivelse Projektets scope IT-systemer Interface til aktører og interne it-systemer Vision Overblik over forretningsprocesser Bruger- og interessenttyper Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og mægler Testbrugere: Markedsaktør og it-leverandør Kunder: Elforbruger og elproducent Myndigheder Administrator og superbrugere Brugere fra Energinet.dk Afhængigheder Afgrænsninger FÆLLES KOMPONENTER OG KRAV Administration af system Administration af system kravtabel Bruger- og rettighedsstyring Bruger- og rettighedsstyring kravtabel Workflow Workflow kravtabel Rapportering Rapportering kravtabel Dataudveksling Dataudveksling kravtabel Alternativ webadgang for kunder Alternativ webadgang for kunder kravtabel FUNKTIONSKRAV TIL PORTALEN...38 Dok /10, Sag 10/3365 3/132

4 5.1 Generelle funktionskrav til Portal Kravtabel til generelle funktionskrav til Portal Webformularer Kravtabel til etablering af webformularer Kravtabel til webformularer Krav til DataHub portalen Krav til Aktørtestsystem portalen Funktionskrav til integration af Selvbetjeningsportalen Skærmbilleder menuoversigt Applikation Kravtabel til Selvbetjeningsportalen FUNKTIONSKRAV TIL DATAHUB EN Understøttelse af forretningsprocesser (BRS) Forretningsprocesser (BRS) kravtabel Samlet datamodel Stamdata Stamdata, opdateret på baggrund af markedsprocesser Adgang til stamdata via webportal Stamdata kravtabel Måledata Adgang til måledata via webportal Send måledata til tredje part Måledata kravtabel Beregningsfunktion Statiske beregninger Dynamiske beregninger Automatisk beregning - nettoafregnede værker Beregningsfunktion kravtabel Beregning af residualforbrug, andelstal, fordelte forbrug og saldoafregning Beregning af residualforbrug, andelstal, fordelte forbrug & saldoafr. kravtabel Forberedelse til Samfakturering Samfakturering kravtabel Kvalitetsindeks (KPI) på måledata Beregning af KPI'en "IFIM" KPI på måledata kravtabel Dataudtræk via webservice Dataudtræk kravtabel Rapportering Rapportering kravtabel FUNKTIONSKRAV TIL AKTØRTESTSYSTEMET Aktørtestsystemets formål Overordnet formål med Aktørtestsystemet Brugertyper til Aktørtestsystemet Testtyper Overordnede rammer for Aktørtestsystemet Model for Aktørtestsystemet Overordnet testflow...99 Dok /10, Sag 10/3365 4/132

5 7.2.3 Overordnede krav Funktionelle krav Registrering af it-system kravtabel Administration af testcases Administration af testcases kravtabel Administration af testdata Administration af testdata kravtabel Administration af testforløb Administration af testforløb kravtabel Godkendelse af testforløb Godkendelse af testforløb kravtabel Historik for testforløb Historik for testforløb kravtabel IKKE-FUNKTIONELLE KRAV TIL ARKITEKTUR Generelle arkitekturkrav Generelle arkitekturkrav kravtabel Platform og kommunikation Platform og kommunikation kravtabel Integrationer Eksterne integrationer Integrationer kravtabel ØVRIGE IKKE-FUNKTIONELLE KRAV Sikkerhed Transaktionsspor og revisionsspor Sikkerhed kravtabel Implementering og datamigrering Uddannelse Drift TABEL- OG FIGUROVERSIGT Dok /10, Sag 10/3365 5/132

6 1. Indledning 1.1 Læsevejledning I dette bilag, som indeholder kravspecifikationen, gøres der opmærksom på flg.: Ved referencer til forskrift, menes der de "foreløbige" forskrifter, benævnt pseudoforskrifter i kravspecifikationen Hvis ikke andet specifikt er nævnt, gælder kravene både for DataHub'en, Aktørtestsystemet og Portalen. Hvert afsnit afsluttes med en opsummering af kravene i en kravtabel. Nedenstående illustration viser opbygningen af denne kravspecifikation. Specifikationen består af tre afsnit, der er fælles for DataHub'en og Aktørtestsystemet. Herudover er to specifikke afsnit, der beskriver de specifikke krav for de to hovedsystemer. DataHub Forretningsprocesser Stamdata Måledata Aktørtestsystem Beregningsfunktioner Dataudtræk Registrering af system Testcases Samfakturering Specifikke afregninger Testdata Testforløb Rapportering Kvalitetsindeks (KPI) Testgodkendelse Testhistorik Portal Design & tilgængelighed Webformularer Selvbetjeningsportal Fælles komponenter Systemadministration Rapportering og krav Brugeradministration Workflowadministration Dataudveksling Ikke-funktionelle krav Arkitekturkrav Integrationer Kommunikation Sikkerhed Platform Datamigrering Figur 1-1: Opbygning af kravspecifikationen Dok /10, Sag 10/3365 6/132

7 2. Introduktion til DataHub projektet 2.1 Formål Energinet.dk er af Klima- og Energiministeren blevet bedt om at etablere en DataHub til det danske elmarked. I sommeren 2009 startede Energinet.dk på den baggrund projektet i samarbejde med repræsentativt udvalgte aktører fra det danske elmarked. DataHub'en skal være en Business-to-Business (B2B) løsning (datatrafikalt knudepunkt), som administrerer transaktioner og kommunikation mellem alle elmarkedets aktører i Danmark: Netvirksomheder, elleverandører, balanceansvarlige og Energinet.dk. Dette betyder, at aktørerne skal kommunikere med DataHub'en på en standardiseret måde, og aktørerne ikke længere skal udveksle data bilateralt, som det sker i dag. DataHub'en skal indeholde alle nødvendige data til markedsafregning og tilbudsgivning, som aktørerne har behov for. I tillæg til B2B løsningen, skal kunderne (elforbrugerne) tilbydes adgang til at se egne data (stamdata og elforbrug) vha. sikker adgang på en webportal. DataHub'en skal ikke stille en webportal til rådighed til dette, men skal i stedet tilbyde lettilgængelige webapplikationer, der kan tilgås fra elleverandørernes webportaler. Kunden skal således kunne logge på sin elleverandørs webportal med NemID og elleverandøren skal ved kald af DataHub'ens webapplikationer vise forbrugerens egne data fra DataHub'en i elleverandørens portal. Autentifikation sker via NemID. Endvidere skal legitime interessenter gives adgang til dataudtræk fra DataHub'en til samfundsnyttige formål. 2.2 Baggrund Energinet.dk Mission Som ansvarlig for el- og naturgassystemerne ejer vi den overordnede infrastruktur, sørger for en sikker energiforsyning og skaber rammerne for velfungerende energimarkeder og effektiv indpasning af vedvarende energi Vision Gennem internationale og fortrinsvise markedsbaserede løsninger vil vi muliggøre øget anvendelse af vedvarende energi og bidrage til håndtering af de globale energi- og klimaudfordringer Fakta om Energinet.dk Selvstændig, offentlig virksomhed under Klima- og Energiministeriet Egen bestyrelse Dok /10, Sag 10/3365 7/132

8 Etableret på baggrund af Lov om Energinet.dk Danmark af 14. december 2004 Fusion mellem Elkraft, Eltra og Gastra i 2005 Ca. 500 medarbejdere, hovedparten i Erritsø og Ballerup Ejer og driver energiens motorveje o o Det overordnede el- og naturgasnet Det regionale elnet i Nordsjælland Ejer og driver Gaslageret i Lille Torup mellem Viborg og Års Medejer af den nordiske elbørs, Nord Pool Spot Medejer af den danske gasbørs, Nord Pool Gas Medejer af European Market Coupling Company Årlig omsætning på 8-9 mia. kr. Forbrugerne betaler til vores aktiviteter via tariffer på el- og gasregningen Energinet.dk's kerneopgaver Vores økonomi skal hvile i sig selv, dvs. vi skal ikke skabe overskud Vi har ansvaret for den overordnede forsyningssikkerhed på el- og gasområdet på både kort og lang sigt Vi planlægger og udbygger det danske el- og gassystem Vi sikrer velfungerende konkurrence på markederne for el og gas Vi støtter produktion af miljøvenlig strøm Vi støtter forskning, udvikling og demonstration af nye teknologier til miljøvenlig elproduktion Vi opgør udledningen af stoffer til miljøet fra det samlede energisystem Vi sikrer, at energisektorens beredskab er velfungerende Vi sikrer: o o o o at der altid er strøm i stikkontakterne og gas i hanerne den nødvendige udbygning af el- og gasnettet forsyningen af gas, når produktionen i Nordsøen klinger af at strømmen føres i land fra nye havvindmølleparker Vi udvikler et mere fleksibelt elsystem, der kan håndtere markant mere vedvarende energi Dok /10, Sag 10/3365 8/132

9 Vi sikrer velfungerende markeder for el og gas konkurrence og gennemsigtige priser Vi yder tilskud til miljøvenlig el- og kraftvarmeproduktion Energinet.dk's interne værdier Værdierne fortæller, hvordan vi vil arbejde for at nå vores mål. Vores værdier udtrykker, hvad der kendetegner os, og hvad vi kan forvente af hinanden. Dermed lægger de også fast, hvad vores omverden kan forvente af os. Værdierne er et kompas, der udstikker retningen for alt, hvad vi gør. I løbet af 2009 er vi sammen nået frem til et værdisæt, som vi udfolder efter bedste evne: Udvikling Vi skaber forandring og nye løsninger. Vi har plads til nye idéer, personlig og faglig udvikling Engagement Vi tager ansvar, er opsøgende og vi motiverer hinanden Forretningsorientering Vi er økonomiske ansvarlige, er effektive og er opmærksomme på behov og muligheder i vores omverden Ansvarlighed Vi gør det, vi siger. Vi tager opgave, samfund og miljø alvorligt og vi behandler hinanden og andre med respekt Dok /10, Sag 10/3365 9/132

10 2.2.2 Elmarkedet Engrosmarked Nord Pool Balanceansvarlig Systemansvarlig Balanceansvarlig Detailmarked Elleverandør Elleverandør Elleverandør Netvirksomhed Netvirksomhed Netvirksomhed Figur 2-1: Illustrerer principperne for elmarkedet og viser de aktører, der agerer i markedet. Danmark er opdelt i ca. 85 geografiske netområder, og hvert netområde ejes af en netvirksomhed. Netvirksomhederne har ansvaret for at drive og udbygge ledningsnettene, foretage alle målinger hos forbrugere og producenter i netområdet samt at videreformidle målinger til relevante aktører. Elforbrugeren er fysisk tilsluttet nettet hos den netvirksomhed, hvor forbrugeren geografisk er placeret, og elforbrugeren kan indgå aftale om køb af el med en af de ca. 100 elleverandører der agerer i Danmark. Elforbrugeren kan altså vælge at skifte elleverandør, men kan ikke skifte netvirksomhed. Elleverandørerne handler deres energi med de balanceansvarlige på engrosmarkedet. Der er pt. ca. 50 balanceansvarlige i Danmark. De balanceansvarlige køber og sælger el i engrosmarkedet, f.eks. fra den nordiske elbørs Nord Pool. De balanceansvarlige indmelder dagligt deres handelsplaner på timebasis til den systemansvarlige (Energinet.dk), der har det overordnede ansvar for at sikre den fysiske energibalance i elmarkedet (forbrug = produktion), og derudover har ansvaret for et velfungerende elmarked. En mere detaljeret beskrivelse af elmarkedet kan bl.a. ses i "Forskrift A: Principper for elmarkedet" der kan findes på Energinet.dk's hjemmeside. Dok /10, Sag 10/ /132

11 3. Overordnet beskrivelse DataHub projektet er organisatorisk forankret i Markedsafdelingen i Energinet.dk. Til projektet er der oprettet projektkontor med dedikeret projektleder og projektkoordinator. Der vil i projektet være tilknyttet tilstrækkelige ressourcer fra relevante sektioner i Energinet.dk (Elmarked, it, jura osv.). (se Bilag 10). 3.1 Opgavebeskrivelse Følgende 2 dokumenter beskriver det omfang for DataHub projektet, der er aftalt med Energistyrelsen: 11. juni 2009 Energinet.dk "Referencemodel for implementering af et centralt markeds register i det danske elmarked" 3. november 2009 Energinet.dk "Uldne punkter i referencemodellen" Nedenstående dokumenter danner desuden baggrund for DataHub projektet: 21. april 2009 Energistyrelsen: "STAMDATAREGISTER OG DATAHUB til håndtering af måledata i det danske elmarked" 24. april 2009 Connie Hedegaard "L 3 betænkningsbidrag med henblik på etableringen af en DataHub i elmarkedet" 30. april 2009 Det Energipolitiske udvalg "Det Energipolitiske Udvalg L 3 - Bilag 27" Maj 2009 Februar 2008 NordREG "Market Design Common Nordic end-user market" - Report 03/2009 NordREG "Harmonized supplier switching model" - Report 2/2008 Dokumenterne er tilgængelige på Introduktionen af en DataHub i elmarkedet, betyder at de gældende markedsforskrifter for elmarkedet skal revideres. Markedsforskrifterne er et regelsæt udarbejdet af Energinet.dk, der efter høring af markedets aktører, er anmeldt til Energitilsynet i overensstemmelse med loven. De definerer, hvorledes alle aktører i elmarkedet skal agere i forhold til hinanden, og hvilke roller de har. De gældende markedsforskrifter kan findes på Dok /10, Sag 10/ /132

12 Referencedokument af juni 2009 krav til funktionalitet og arbejdsdeling i branchen EU s liberaliseringspakke -eldirektivet -forordning om netadgang Energitilsynet NordREG Harmonized Supplier Switching Model, NordREG Report 2, 2008 Marked Design Rapport 3, 2009 Uldne punkter i referencedokument krav til samfakturering Markedsforskrifter D1, F, H1, H2 - incl: BRS er og RSM er Forretningsprocesser i det danske elmarked Ønskeliste Ændringsønsker fra aktørene DataHub - Kravspecifikation Alle måledata Stamdata alle kunder Leverandørskift Saldoafregning Formidle data til samfakturering kundeadgang via www Aktørtest - Kravspecifikation Ny kommunikationsstandard Aktørsystemer - Ændringsspecifikation Ny kommunikationsstandard Ændrede processer Figur 3-1: Centrale dokumenter Figur 3-1 illustrerer hvorledes de ovenstående dokumenter giver input til udarbejdelsen af nye markedsforskrifter. Udover de nævnte dokumenter, er der input til projektet fra EU Kommisionen ("3. Liberaliseringspakke") og fra Energitilsynet. Der har fra elmarkedets aktører været ønsker om ændringer af uhensigtsmæssigheder i de gældende regler.("ønskeliste") Ultimo juni 2010 er de nye pseudoforskrifter blevet fastlagt, og "Forretningsprocesser for det danske elmarked", der beskriver dataudvekslingen mellem markedets aktører er ligeledes fastlagt i en foreløbig version. Pseudo-forskrifterne er ikke godkendte af Energitilsynet endnu, men lægges til grund for dette udbudsmateriale. På baggrund af de nye markedsforskrifter og beskrivelse af forretningsprocesserne udarbejdes der kravspecifikationer til de it-systemer, der skal varetage EDI-kommunikationen i elmarkedet - herunder DataHub'en og Aktørtestsystemet, som dette udbud omhandler. Aktørerne i markedet skal sideløbende specificere de ændringer, der skal foretages i deres lokale it-systemer (Aktørsystemer) Dok /10, Sag 10/ /132

13 3.2 Projektets scope I nedenstående figur 3.2 er projektets omfang illustreret grafisk. Kunder Mægler Balanceansvarlig På elleverandørens hjemmeside: - se egne målinger - se egne stamdata - se leverandørskifte Elleverandør - modtage målinger - forespørge stamdata - foretage leverandørskifte - forespørge målinger - forespørge stamdata Netvirksomhed -indsende målinger -vedligeholde stamdata for målepunkter -forespørge status på målinger og stamdata - modtage målinger - se statistikdata Offentlig Myndigheder - hent foruddefinerede data Webservices Webportal Selvbetjeningsportal (eksisterende IT-system) -konfigurer system -administration -overvågning -fejlsøgning DataHub Målepunkt -aftagenummer -adresse -elleverandør -balanceansvarlig -kundenavn -gyldighedsperiode Målinger -tid (periode) -værdi -status Funktioner: -Beregninger -Saldoafregning -Revisionsspor -Statistik Aktørtestsystem -måledata PandaService (eksisterende IT-system) Webservices til Webportal Panda (eksisterende IT-system) Afregning på engrosmarkedet: -balanceafregning -afgiftsafregning -udbetaling af pristillæg Figur 3-2: Illustration af DataHub'ens interessenter og funktioner IT-systemer DataHub'ens samlede leverance består af 2 systemer: DataHub'en og Aktørtestsystemet - og de betragtes i dette udbud som 2 separate leverancer DataHub kapitel 6 DataHub'en skal lagre stamdata for alle målepunkter i Danmark, bl.a. adresseinformation, navn på disponent (kunde), elleverandør og netvirksomhed. Disse stamdata er variable over tid. For hvert målepunkt skal der registreres målinger (forbrug, produktion eller udveksling). Disse målinger kan være foretaget på kvarters-, times-, måneds-, kvartals eller årsbasis. DataHub'en vil være en kombineret informations- og transaktionsportal, som dels skal rumme aktuelle og historiske forbrugs- og produktionsdata (målinger), og dels skal håndtere processen for leverandørskifte og flytning (stamdata). Målet er en specialbygget eller specialtilpasset applikation opbygget af standardmoduler. Dok /10, Sag 10/ /132

14 Arkitekturen er lagopdelt (præsentation, logik og data). Slutbrugergrænsefladen skal primært være webbaseret. Systemet skal håndtere store datamængder (målinger) fra ca. 3,2 mio. målepunkter. Systemet skal håndtere store transaktionsmængder, dagligt modtages 1,2 mio. timemålinger, og der forventes ca. 0,5 mio. stamdataændringer pr. år (f.eks. flytninger eller skift af elleverandør). Systemet vil indeholde personfølsomme oplysninger, hvilket stiller krav til sikkerhedsniveauet. Der skal være integrationer til andre systemer hos Energinet.dk. Systemet vil blive omdrejningspunkt for markedskommunikationen, hvorfor der er krav om høj oppetid Aktørtestsystem - kapitel 7 Til test og verifikation af it-kommunikationen fra markedets aktører, skal der udvikles et Aktørtestsystem, hvor aktørerne gennemfører specificerede test-cases. Slutbrugergrænsefladen på Aktørtestsystemet skal være webbaseret. Testscenarierne skal kunne afvikles individuelt af aktørerne og deres it-leverandører, med mindst mulig involvering fra Energinet.dk's side. Aktørtestsystemet skal efterfølgende fungere som en service på markedet ved: o o o test af nye releases nye systemer for eksisterende aktører test af nye aktørers systemer Webportal kapitel 5 Da slutbrugergrænsefladen på både DataHub'en og Aktørtestsystemet skal være webbaseret, ses der en fordel i en løsning, der anvender samme webportal. Webportalen skal give brugerne en oplevelse af et sammenhængende system. Energinet.dk's eksisterende portalløsning ("Selvbetjeningsportal") kan tænkes integreret i denne webportal. Den omtalte integration vil kun gælde for elkunder, altså vil Selvbetjeningsportalen fortsætte med servicering af gaskunder. Denne eventuelle integration er i dette udbudsmateriale beskrevet som en option Interface til aktører og interne it-systemer Netvirksomheder Det er netvirksomhedernes ansvar at vedligeholde stamdata for målepunkter, på nær oplysningen om elleverandør og balanceansvarlig. Det er også netvirksomhedernes ansvar at indmelde målinger pr. målepunkt og eventuelle korrektioner til disse målinger. Dok /10, Sag 10/ /132

15 Den primære kommunikation mellem netvirksomhederne og DataHub'en skal ske via EDIudveksling (webservice), men DataHub'en skal tilbyde adgang via en webportal, således at netvirksomhederne kan udføre forretningstransaktioner og kontrolfunktioner i DataHub'en Elleverandører Når en elleverandør overtager en kunde på et målepunkt, er det elleverandørens ansvar at ajourføre "elleverandør" oplysningen på målepunktet. Elleverandøren har ret til de målinger, der er foretaget på de målepunkter, hvor elleverandøren har kunder. Den primære kommunikation mellem elleverandørerne og DataHub'en sker via EDI-udveksling, men DataHub'en skal tilbyde adgang via en webportal, således at elleverandørerne f.eks. kan hente måledata og stamdata samt udføre kontrolfunktioner i DataHub'en Mægler En mægler har samme muligheder som en elleverandør for at forespørge på kundestamdata og historiske målinger for kunder. Mægleren kan ikke udføre opdaterende forretningstransaktioner som f.eks. skift af elleverandør, eller ændring af stamdata Balanceansvarlige Den balanceansvarlige er aktøren i engrosmarkedet, der handler el med elleverandørerne (detailmarkedet). De balanceansvarlige aktører skal modtage målinger pr. elleverandør fra Data- Hub'en. Den primære kommunikation mellem balanceansvarlige og DataHub'en sker via EDI-udveksling, men DataHub'en skal tilbyde adgang via en webportal, således at den balanceansvarlige f.eks. kan hente måledata og stamdata samt udføre kontrolfunktioner i DataHub'en Kunde, offentlighed og myndigheder Alle elkunder i Danmark skal ved indlogning på deres elleverandørs webportal kunne se registrerede stamdata og registreret forbrug på egne målepunkter samt oplysninger om eventuelle registrerede leverandørskift på målepunktet. Disse oplysninger skal stilles til rådighed for elleverandøren fra DataHub'en som webapplikationer. Det er et krav til elleverandørerne, at indlogningen på deres portal sker ved "NemID". Myndigheder skal via webportalen kunne hente foruddefinerede dataudtræk, og uden indlogning (offentlighed) skal webportalen vise diverse statistikdata for elmarkedet Energinet.dk DataHub'en administreres af Energinet.dk. Der skal kunne udføres systemkonfigureringer, overvågning af systemet, administration af brugere/rettigheder samt fejlsøgninger i processer. Energinet.dk skal desuden kunne foretage diverse rapporteringer via standardværktøjer, evt. ved integration med Energinet.dk's eksisterende Datawarehouse løsning. Dok /10, Sag 10/ /132

16 Panda, PandaService og Selvbetjeningsportal Panda er et eksisterende it-system hos Energinet.dk. Panda udfører afregningen i engrosmarkedet primært på basis af målinger der fremover modtages fra DataHub'en. På basis af det beregnede forbrug pr. netområde beregner Panda de net-, system- og PSOafgifter der skal opkræves hos netvirksomhederne. Alle produktionsanlæg i Danmark (værker og vindmøller) er registreret med relevante stamdata i Panda, og i Panda beregnes hver måned det pristillæg, der skal udbetales til ejerne af produktionsanlæggene. Alle afregningsbilag og stamdata for produktionsanlæg fra Panda gøres tilgængelige på Energinet.dk's Selvbetjeningsportal, hvor der pt. er registreret ca brugere. Da brugerne af Data- Hub'en også vil være brugere af den eksisterende Selvbetjeningsportal, er der i dette udbudsmateriale en option om integration af Selvbetjeningsportalen ind i DataHub portalen. Den omtalte integration vil kun gælde for elkunder, altså vil Selvbetjeningsportalen fortsætte med servicering af gaskunder Vision På sigt forventes DataHub'en at skulle udbygges med yderligere funktionalitet, hvoraf nogle emner kan nævnes: Elbiler Det forventes, at der i forbindelse med udbredelse af elbiler i Danmark vil blive etableret offentlige ladestandere til elbiler. DataHub'en kan her få en central rolle mht. håndtering af målinger/afregninger fra disse ladestandere. Figur 3-3 illustrerer et eksempel på et design, hvor DataHub'en modtager detailregistreringer fra de offentlige ladestandere, evt. via netvirksomheden. På baggrund heraf kan forbruget opgøres pr. kort (=virtuelt målepunkt), pr. kunde og pr. elleverandør. Dok /10, Sag 10/ /132

17 Model for håndtering af elbiler, der lader ved offentlige ladestanderne BALANCEANSVARLIG Tidsserier pr. elleverandør ELLEVERANDØR 16 2 Aftale Bestilling af reg. kraft /SPOT Levering af reg. kraft /SPOT OPERATØR 1 Aftale Samlet faktura 19 Samlet faktura 20 KUNDE Oprettelse af målepunkt 3 4 Målepunkt sendes 18 Fakturalinjer 15 Tidsserier pr. målepkt. 6 Validering af målepunkt id Styring 8Identificering af målepunkt id kwh 5 Elbilen lader ved ladestanderen Ladestander identificerer målepunkt 7 Målepunkt id er aktiv OFF. LADESTANDER Tidsserier pr. målepkt. Fakturalinjer pr. målepkt. 12 NETVIRKSOMHED Hjemtagning af timeværdier 13 Ladestanderens eget forbrug Oprettelse af kunden Opladning af elbil Styring Afregning af kunden Figur 3-3: Model for elbiler der lader ved offentlige ladestandere Nordisk detailmarked Integrationen mellem det danske elmarked og det øvrige Norden står overfor en række store udfordringer. Det skyldes de nordiske energiministres beslutning om at danne et fælles nordisk slutbrugermarked i Elbranchens forskellige interessenter er allerede i nordisk sammenhæng gået sammen i et projekt for at forberede indførelsen af dette fælles detailmarked. Projektet koordineres af NordREG 1. Der er nedsat fire task forces (TF) som skal fremkomme med løsningsforslag til realiseringen af det fælles slutbrugermarked. De fire TF s omhandler følgende Target market model TF (formandskab: NordREG) Balance and settlement TF (formandskab: Nordiske TSO er) Data exchange TF 2 (formandskab: Nordenergi) Customer interface model TF (formandskab: Nordenergi). 1 Forum of Nordic Energy Regulators. 2 Collaboration between the Nordic electricity industry associations Dok /10, Sag 10/ /132

18 Den endelige afrapportering til EMG 3 fra de fire TF s skal finde sted til september Det forekommer på nuværende tidspunkt svært at prognosticere, hvilke forhold som opnår første prioritet, og hvilke forhold som prioriteres som mindre væsentlige. Det skyldes, at processen først er ved at starte op nu. Der er dog ingen tvivl om, at alle interessenter skal udvise særdeles stor fleksibilitet, hvis energiministrenes ønsker skal kunne tilgodeses allerede i Der er en række punkter, som antages at indgå i de videre overvejelser: Det skal være sikkert og nemt for forbrugerne at købe elektricitet fra enhver nordisk leverandør. Det samme gælder leverandørernes adgang til at være aktiv på hele det nordiske marked. Harmoniseringen af slutbrugemarkedet skal ske på en omkostningseffektiv måde. Der skal være et incitament til at markedets aktører leverer en høj kvalitet ved udveksling af data og meddelelser. Markedsreglerne skal kunne administreres, og være klare, transparente og samtidig robuste overfor fremtidige tiltag. Forventningerne til designet af det nordiske detailmarked er, at en dansk elleverandør kun skal kommunikere med den danske DataHub, men kan agere i markedet i de øvrige tilknyttede lande. Det forventes således at være de nationale DataHub's, der skal kommunikere på tværs af grænserne Samfakturering I dag modtager elkunder, der har skiftet elleverandør, både en faktura fra sin netvirksomhed og fra sin elleverandør. Her kan DataHub'en få en rolle mht. udveksling af bl.a. fakturaoplysninger, således at der udsendes en samlet faktura fra elleverandøren til kunden. DataHub'en skal være forberedt til samfakturering (beskrevet i afsnit 6.7) men dette område kan forventes at blive udvidet med flere funktionaliteter Afregning i engrosmarkedet Afregningerne for engrosmarkedet, der i dag foretages i Panda systemet, forventes med fordel at ville kunne integreres i DataHub'en. 3 Electricity Market Group (EMG) of Nordic Council of Ministers Dok /10, Sag 10/ /132

19 Netvirksomhed Balanceansvarlig Hent afregningsbilag Vedligehold stamdata Anlægsejer Hent afregningsbilag Energistyrelsen Stamdataregisteret Stamdata prod.anlæg Selvbetjeningsportal Stamdata produktionsanlæg Afregningsbilag Afregningsbilag Panda Stamdata prod.anlæg Stamdata produktionsanlæg Afregning på engrosmarkedet: -balanceafregning -afgiftsafregning -udbetaling af pristillæg Posteringer pr. kunde Hent afregningsbilag Udbetaling af pristillæg SAP Bogføring NemKonto Faktura: - Balanceafregning - Afgiftsafregning Målinger DataHub Figur 3-4: Panda Som illustreret i figur 3-4 vil Panda modtage målinger fra DataHub'en, og på basis af disse foretage følgende tre typer afregninger: Balanceafregning: På timeniveau beregnes differencen mellem de planlagte produktioner/forbrug og målingerne for hver balanceansvarlige, og denne differens (ubalance) prissættes til afregning overfor den balanceansvarlige. Afgiftsafregning: For hvert netområde beregnes netområdets forbrug på basis af forbrugs-, produktions- og udvekslingsmålingerne. På basis af det opgjorte forbrug opkræves hvert netområde med tre typer afgifter: Systemtarif, Nettarif og PSO-tarif. Udbetaling af pristillæg: Vindmøller og øvrige el-produktionsanlæg kan være berettiget til at modtage et pristillæg til deres produktion. Disse pristillæg beregnes i Panda pr. produktionsanlæg, og udbetalingen foretages til anlægsejerne. Som illustreret i figur 3-4 foretages de ovenstående tre typer afregninger i Panda, og der dannes detaljerede afregningsbilag (pdf-filer), som er tilgængelige for kunderne via Selvbetjeningsportalen. Dok /10, Sag 10/ /132

20 Panda foretager den egentlige beløbsberegning for alle afregningerne, og posteringerne pr. kunde overføres til SAP. Fra SAP udskrives faktura til de balanceansvarlige og netvirksomhederne, og udbetalingen af pristillæg til produktionsanlægsejerne sker via NemKonto. Stamdata for produktionsanlæg: Energinet.dk er pålagt en opgave fra Energistyrelsen om varetagelse af "stamdataregister for produktionsanlæg", og denne opgave varetages også af Panda-systemet. Netvirksomhederne skal via Selvbetjeningsportalen indberette og vedligeholde stamdata for alle produktionsanlæg i Danmark. Disse stamdata valideres i Panda og indberettes på månedsbasis til Energistyrelsen sammen med produktions- og afregningsdata Vision kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Beskrivelse af forberedelse til opfyldelse af visioner Det skal beskrives, hvorledes det leverede system vil kunne opfylde de udvidelser som beskrevet i visioner afsnit Tabel 3-1: Vision kravtabel 3.3 Overblik over forretningsprocesser Markedsforskrifterne beskriver de grundlæggende forretningsregler. Reglerne fra forskrifterne er nedbrudt i enkelte forretningsprocesser, kaldet BRS - Business Requirement Specification og EDI transaktionerne i de enkelte forretningsprocesser er beskrevet i RSM dokumentationen (Requirement Specification Mapping). Markedsforskrift Markedsregler Forretningsprocesser for det danske elmarked BRS Business Requirement Specification EDI-Transaktioner RSM Requirement Specification Mapping DataHub'en skal overholde alle regler beskrevet i Markedsforskrifter og "Forretningsprocesser for det danske elmarked", og ved evt. uoverensstemmelse mellem dokumenterne er Markedsforskrifterne de gældende dokumenter. Det skal bemærkes, at der i forbindelse med DataHub projektet er udarbejdet nye forskrifter, kaldet pseudo-forskrifter. Pseudo-forskrifterne er endnu ikke godkendt af Energitilsynet, men lægges til grund for dette udbud. Dok /10, Sag 10/ /132

21 Nedenstående tabel viser alle markedsforskrifter for elmarkedet og deres relevans for dette projekt. Markedsforskrift Relevans A Principper for elmarkedet Ikke relevant for DataHub'en - men definerer flere grundlægende principper i elmarkedet. B Vilkår for adgang til elmarkedet Ikke relevant for DataHub'en C1 Vilkår for balanceansvar Ikke relevant for DataHub'en C2 Balancemarkedet og balanceafregning Ikke relevant for DataHub'en C3 Planhåndtering - daglige procedurer Ikke relevant for DataHub'en D1 Pseudo-forskrift: Afregningsmåling Er revideret kraftig aht. DataHub projektet, og er vedlagt udbudsmaterialet i revideret udgave. Den reviderede udgave er ikke officielt gældende i markedet. D2 Tekniske krav til elmåling Ikke relevant for DataHub'en E Miljøvenlig elproduktion og anden udligning Ikke relevant for DataHub'en F Pseudo-forskrift: EDI-kommunikation i elmarkedet Er revideret kraftig aht. DataHub projektet og er vedlagt udbudsmaterialet i revideret udgave. Den reviderede udgave er ikke officielt gældende i markedet. G Diskretionspolitik og procedurer vedr. datasikkerhed Relevant H1 Pseudo-forskrift: Skift af elleverandør Er revideret kraftig aht. DataHub projektet, og er vedlagt udbudsmaterialet i revideret udgave. Den reviderede udgave er ikke officielt gældende i markedet. H2 Pseudo-forskrift: Måling og skabelonafregning Er revideret kraftig aht. DataHub projektet, og er vedlagt udbudsmaterialet i revideret udgave. Den reviderede udgave er ikke officielt gældende i markedet. I Pseudo-forskrift: Stamdata Nyudarbejdet forskrift aht. til DataHub projektet. Forskriften fastlægger krav til stamdata for målepunkter og aktører i relation til oprettelse/ vedlige- Dok /10, Sag 10/ /132

22 holdelse i DataHub'en. Tabel 3-2: Markedsforskrifter Forretningsprocesserne er beskrevet i "Forretningsprocesser for det danske elmarked" og beskriver meddelelsesflowet mellem kunde, elleverandør, balanceansvarlig, netvirksomhed og Data- Hub. Processerne beskriver både meddelelser der udveksles som EDI meddelelser, og meddelelser der udveksles f.eks. pr. brev. Pseudo-forskrifterne er vedlagt dette udbudsmateriale, mens øvrige forskrifter kan findes på Energinet.dk's hjemmeside. Forretningsprocesserne i elmarkedet, der er beskrevet i dokumentet "Forretningsprocesser for det danske elmarked", listes i nedenstående tabel. Områder BRS er Forretningsprocesserne, der beskriver hvorledes en kunde skifter elleverandør, eller en elleverandør opsiger kontrakten med en kunde. Desuden beskrives processen, der udreder et fejlagtigt leverandørskifte. BRS Leverandørskift BRS Leveranceophør BRS Håndtering af fejlagtigt leverandørskift Stamdata for målepunktet og kunden udveksles mellem DataHub'en og henholdsvis netvirksomhed og elleverandør. BRS Oprettelse af målepunkt BRS Anmodning om stamdata BRS Fremsendelse af stamdata Til- og fraflytning af kunder til et målepunkt er en proces, der involverer netvirksomhed, DataHub og elleverandør. BRS Fraflytning - meldt til netvirksomheden BRS Tilflytning - meldt til netvirksomheden BRS Tilflytning - meldt til elleverandøren BRS Fraflytning - meldt til elleverandøren Netvirksomheden har det primære ansvar for vedligeholdelse af stamdata for målepunktet, herunder skift af afregningsform og afbrydelse/genåbning af målepunktet. BRS Skift af afregningsform BRS Afbrydelse og genåbning af målepunkt Udover stamdata, skal der udveksles målinger (registreringer) mellem aktøren i markedet og BRS Forbrugsopgørelse for skabelonafregnet målepunkt Dok /10, Sag 10/ /132

23 DataHub'en. BRS Fremsendelse af måledata for et målepunkt DataHub'en foretager beregninger på basis af de fremsendte basale målinger, og fremsender af resultatet fra disse beregninger. BRS Fremsendelse af andelstal BRS Fremsendelse af beregnede tidsserier Endelig kan aktøren anmode om måledata eller beregningsresultater fra DataHub'en. BRS Anmodning om historiske data BRS Anmodning om måledata Tabel 3-3: Forretningsprocesser i elmarkedet (Business Requirement Specifications) 3.4 Bruger- og interessenttyper Brugerne af DataHub og Aktørtestsystemet kan overordnet opdeles i to grupper: Gruppen "Kunder", der udelukkende tilgår DataHub'ens funktionaliteten via en webapplikation, indlejret i elleverandørens portal. Gruppen af professionelle brugere der tilgår både DataHub og Aktørtestsystemets funktionalitet, via systemets webportal. Dette er illustreret i nedenstående figur. NemId validering Kunder DanId Elleverandør portal Markedsaktører Testbrugere Myndigheder Webapplikation Portal Autentifikation Brugerrettigheder DataHub funktionalitet Aktørtestsystem funktionalitet Administrator Brugere Figur 3-5: Oversigt over brugeradgang I dette materiale dækker betegnelsen "brugere" alle der tilgår funktionalitet i DataHub'en eller Aktørtestsystemet, uanset om tilgangen sker via DataHub'ens portal eller via en elleverandørs Dok /10, Sag 10/ /132

24 portal. Men i materialet er der ikke differentieret på, om funktionerne skal være gældende i én eller begge portaler, da det endelige design af autentifikationsmetoder og brugerrettigheder skal ske i samarbejde med Energinet.dk. En mere detaljeret gennemgang af de forskellige brugertyper følger herefter Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og mægler De primære brugere af DataHub'en er aktørerne i elmarkedet. Det forventes, at aktørerne vil anvende portaladgangen til DataHub'en til at følge status på egne forretningsprocesser og på EDI-kommunikationen. Der er ca. 250 virksomheder der typisk forventes at have 1-5 daglige brugere på DataHub'en. Brugerne forventes at have almindeligt it-kendskab og har forståelse for forretningsprocesserne. Brugerne vil anvende systemet i almindelig kontortid Testbrugere: Markedsaktør og it-leverandør Inden en markedsaktør kan agere på markedet vha. EDI-kommunikation, skal aktørens itsystem godkendes i Aktørtestsystemet. Ligeledes skal markedets aktører have mulighed for at tilgå DataHub testsystemet (Preproduktionssystemet) bl.a. til brug i undervisning af nye medarbejdere. Markedets aktører vil derfor tilgå Aktørtestsystemet og DataHub testsystemet i rollen som testbruger. Aktørernes it-leverandører har behov for test af nye releases af aktørernes it-systemer og har derfor samme behov for tilgang til Aktørtestsystemet, som markedets aktører Kunder: Elforbruger og elproducent Alle elforbrugere og elproducenter i Danmark skal have adgang til egne stamdata og målinger fra DataHub'en via elleverandørens webportal. En forudsætning er, at kunden er logget på elleverandørens webportal med NemID, og at denne autentifikation anvendes ved kald af Data- Hub'ens webapplikation. Der er her et potentiale på ca. 3,5 mio. brugere med et meget varieret it-kendskab, og med et varieret forbrugsmønster Myndigheder Enkelte myndigheder har behov for tilgang til DataHub'en for udtræk af bl.a. statistikdata for processerne. Der vil her være tale om meget få brugere med et behov for begrænset funktionalitet, og anvendelsen forventes at være meget sporadisk. Dok /10, Sag 10/ /132

25 3.4.5 Administrator og superbrugere Energinet.dk varetager administrationen af DataHub'en og Aktørtestsystemet og har ansvaret for den daglige drift. Det forventes, at der hos Energinet.dk vil være 2-5 administratorer og 2-5 superbrugere Brugere fra Energinet.dk Energinet.dk har ansvar for den daglige drift af systemet, herunder support til aktørerne i markedet. De brugere har bl.a. ansvaret for overvågning af forretningsprocesser, udredning af fejl, og ansvar for definition og kontrol af andelstalsberegning og saldoafregning. 3.5 Afhængigheder Der er i projektets implementeringsfase store afhængigheder til test og implementering af ændringerne, der skal foretages i it-systemerne hos markedets aktører. Den endelige opstart af DataHub-systemet kan ikke ske før alle aktørers it-systemer er testet og godkendt, og alle initielle stamdata er loadet og verificeret i DataHub'en. 3.6 Afgrænsninger Dette projekt omhandler ikke: Ændringer i aktørernes it systemer Ændringer der skal foretages i Energinet.dk's eksisterende it-systemer Dok /10, Sag 10/ /132

26 4. Fælles komponenter og krav DataHub Forretningsprocesser Stamdata Måledata Aktørtestsystem Beregningsfunktioner Dataudtræk Registrering af system Testcases Samfakturering Specifikke afregninger Testdata Testforløb Rapportering Kvalitetsindeks (KPI) Testgodkendelse Testhistorik Portal Design & tilgængelighed Webformularer Selvbetjeningsportal Fælles komponenter Systemadministration Rapportering og krav Brugeradministration Workflowadministration Dataudveksling Ikke-funktionelle krav Arkitekturkrav Integrationer Kommunikation Sikkerhed Platform Datamigrering Dette afsnit beskriver krav til fælles komponenter for DataHub og Aktørtestsystemet, f.eks. system- og brugeradministration. 4.1 Administration af system Den daglige administration af DataHub'en og Aktørtestsystemet vil ske hos Energinet.dk. Administrationsopgaven for DataHub'en og Aktørtestsystemet forventes for administrationsbrugerne primært at være: Systemkonfigurering Bruger- og rettighedsadministration (beskrevet i afsnit 4.2) Workflow-administration (beskrevet i afsnit 4.3) Overvågning af dataudveksling (webservices) og processer Udredning af fejl i forbindelse med udførelse af workflow Overvågning og udredning af fejlmeldinger/advarsler fra DataHub-processer DataHub'en skal internt, f.eks. ved planlagte jobs, udføre overvågning på egne processer og melde evt. registrerede uhensigtsmæssigheder til administrationsbrugerne. Denne overvågning kan f.eks. være: Dok /10, Sag 10/ /132

27 Overvågning og rapportering af låsninger mellem processer Overvågning og rapportering af evt. løbske eller låste processer Overvågning og rapportering om uregelmæssigheder i kommunikationen: F.eks. lange svartider, unormalt antal kald af webservices eller mange meddelelser i kø til/fra en aktør. Overvågning og rapportering af unormalt cpu-, memory- eller diskforbrug Der skal findes processer til at udføre almindeligt vedligehold på applikationen, som f.eks.: Oprydning og sletning af fejlede workflows Oprydning/arkivering af logtabeller og meddelelseskøer Administrationen af Aktørtestsystemet vil udover ovennævnte være: Konfigurering af testcases og testdata Opfølgning og godkendelse af testforløb Disse yderligere krav for Aktørtestsystemet er beskrevet i afsnit Administration af system kravtabel Krav Krav- Kravtitel Kravbeskrivelse ID type MK/K/O K Administrationsinterface Administrationsinterfacet skal være tilgængeligt over WAN. Administrationsdelen af DataHub'en og Aktørtestsystemet behøver ikke nødvendigvis at være webbaseret, men skal overholde krav til brugervenlighed og tilgængelighed som beskrevet i afsnit K Parameterstyring - systemopsætning Systemadministrator skal have adgang til et niveau af systemopsætning, som overordnet sætter rammerne for og danner overblik over systemets brug. Parameteropsætningen og konfigurationsstyringen skal være separat for DataHub'en og Aktørtestsystemet K Systemadministrators overvågning af processer Systemadministrator skal have værktøjer til rådighed til overvågning af den aktuelle drift af systemet, f.eks. overvågning af status på alle Dok /10, Sag 10/ /132

28 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O aktuelle processer, eller status på EDIkommunikation (webservices). Det skal være muligt at se yderligere detaljer omkring de enkelte processer K Systemets egen overvågning af processer Systemet skal selv overvåge kritiske processer, og melde evt. observerede fejl eller uhensigtsmæssigheder til systemadministrator vha. mail eller SMS. Fejl der observeres kan f.eks. være løbske/låste processer eller uregelmæssigheder i webservice kommunikationen K Modstandsdygtig i forhold til fejl En fejl må ikke efterlade systemet i en ustabil eller udefineret tilstand K Processer til vedligehold Der skal findes processer til almindelig vedligeholdelse af systemet, f.eks. sletning af forældede logmeldinger eller mulighed for at fjerne fejlede workflows K Testfunktioner i driftssituationen til bl.a. webservices Systemet skal indeholde værktøjer, der på en overskuelig måde verificerer enkelte delfunktioner i systemet i driftsøjeblikket. Det kan fx være et test-værktøj, der kan kalde de enkelte webservices og verificere, at de svarer som forventet, eller starter et test-workflow, der verificerer, at workflow-funktionen virker ok K Definition af kalender Systemadministratoren skal have mulighed for opsætning af den kalender, der gælder for hele systemet Herunder definition af helligdage, arbejdsdage og start/slut på sommertid K Ugenummerering I brugerinterface (webportal og rapportering) skal systemet anvende dansk ugenummerering K Notifikation af systemadministrator Det skal være muligt at konfigurere, hvorledes systemadministrator skal notificeres af systemet, via mail eller SMS til mobiltlf. og hvilket logningsniveau, der ønskes rapporteret. Dok /10, Sag 10/ /132

29 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Fejltekster Systemets fejltekster skal kunne redigeres af systemadministratoren. Tabel 4-1: Administration af system - kravtabel 4.2 Bruger- og rettighedsstyring Vedligeholdelse af brugere og brugerrettigheder i DataHub'en og Aktørtestsystemet sker af systemadministratoren hos Energinet.dk. Som beskrevet i afsnit 3.4 kan brugerne til DataHub'en og Aktørtestsystemet deles i følgende fem grupper: Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og mæglere Kunder: Elforbruger og elproducent Testbrugere: Markedsaktør og IT-leverandør Myndigheder Systemadministrator, superbrugere og brugere hos Energinet.dk Brugergruppen "Kunder" er med 3,5 mio. potentielle brugere, klart den største. Autentifikation og rettigheder til denne gruppe skal ske fuldt automatiseret. Autentifikation skal foretages via NemID. Rettighederne for de øvrige 4 brugergrupper skal vedligeholdes af systemadministratoren, men autentifikation kan med fordel foretages via NemID Bruger- og rettighedsstyring kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Fælles brugeradministration for DataHub'en og Aktørtestsystemet Administrationen af brugere skal være fælles for DataHub'en og Aktørtestsystemet, men det skal dog være muligt at definere forskellige roller til samme bruger i de to systemer K Brugerinterface til brugeradmini- Al administration af brugere og rettigheder skal ske gennem et velfungerende brugerinterface, Dok /10, Sag 10/ /132

30 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O stration og skal opfylde krav til brugervenlighed og tilgængelighed som beskrevet i afsnit 5.1 Det er dog ikke et krav, at brugeradministrationen skal ske via webportalen K Princip for brugerstyring Systemadministratoren vedligeholder brugeroplysninger og rettigheder. Brugerstyringen skal opfylde følgende overordnede målsætninger: Autentifikation - (hvem er brugeren) Autorisation - (hvad må brugeren) K Vedligeholdelse af brugergrupper Systemadministratoren skal kunne oprette og vedligeholde et ubegrænset antal brugerroller i systemet, herunder tildele/fjerne rettigheder i systemet til en brugergruppe K Vedligeholdelse af brugere Systemadministratoren skal kunne redigere alle oplysninger for en specifik bruger og skal ligeledes kunne låse adgangen for denne MK Autentifikation af brugergruppen "Kunder" via NemID Autentifikation af brugere i brugergruppen "Kunder" skal ske via NemID, og skal her anvende NemID's portlets til dette K Autentifikation af øvrige brugergrupper De fire brugergrupper markedsaktører, testbrugere, myndigheder og administrationsbrugere (dvs. undtaget "Kunder") - skal autentificeres via NemID - eller via ordinær brugeradministration i systemet. Ved ordinær autentifikation, skal det være muligt at definere mindstekrav til styrke af password, passwordlængde og udløb af password K Rollebaseret rettighedsstruktur Brugerrettighederne skal tildeles gennem en rollebaseret bruger- /rettighedsstruktur. En bruger kan typisk have flere (og forskellige) roller i DataHub'en og i Aktørtestsystemet K Rettigheder håndteres uanset til- Der skal tages hensyn til en brugers rettigheder til funktioner og data, uanset hvorledes bruge- Dok /10, Sag 10/ /132

31 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O gang til systemet ren tilgår systemet (f.eks. webportal eller webservices). Rettighedshåndteringen må derfor ikke være implementeret i brugergrænsefladen K Rettigheder til data på aktørniveau. Rettigheder til data tilknyttes på aktørniveau. Eksempel: En bruger hos en elleverandør, må kun få adgang til de målepunkter denne elleverandør er tilknyttet, og kun få adgang til de målinger, som tilhører disse målepunkter K Vedligeholdelse af brugeroplysninger Brugergrupperne - undtaget brugere i brugergruppen "Kunder" - skal selv kunne registrere yderligere brugeroplysninger, fx. adresse eller telefonnummer K Vedligeholdelse af password For de brugere, hvor der ikke anvendes NemID som autentifikation, skal det være let at ændre eget password K "Glemt password" og "Glemt brugernavn" funktion For de brugere, hvor der ikke anvendes NemID som autentifikation, skal der findes standardiserede funktioner til "Glemt password" og "Glemt brugernavn" K Decentral vedligeholdelse af brugere hos aktørerne I brugergrupperne - undtaget "Kunder" - skal det være muligt at oprette en bruger med rollen "aktør administrator" - der har ansvar for oprettelse/vedligeholdelse af brugere i denne aktørs egen virksomhed K Rapportering af brugerdefintioner Der skal findes rapportfunktioner til dokumentation af brugere, deres tilknytning til brugerroller og brugerrollernes rettigheder i systemet MK Revisionslog af brugerændringer Alle ændringer, der foretages mht. brugeropsætning og brugerrettigheder, skal logges i systemet, med angivelse af hvilken bruger der har foretaget rettelsen og tidspunktet for rettelsen K Rapportering af ineffektive brugere af systemet Der skal findes rapportfunktioner til dokumentation af brugere på portalen, som ikke har været logget ind i en periode (parameterstyret). Dok /10, Sag 10/ /132

32 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Understøttelse af SAML 2.0 standard I relation til overførsel af information om identitet og rettigheder, skal DataHub'en understøtte SAML 2.0 standarden, jf. standarden på OIO. 4 Tabel 4-2: Bruger- og rettighedsstyring - kravtabel 4.3 Workflow Workflow-funktionalitet er en meget central mekanisme, som anvendes til behandlingen af de forskellige forretningsprocesser i DataHub'en, og til processering af testcases i Aktørtestsystemet. I DataHub'en forventes det, at alle forretningsprocesser (BRS'ere) defineres ved at konfigurere et workflow svarende til hver proces. I Aktørtestsystemet vil de testcases, som aktørerne skal gennemføre, kunne defineres i et workflow. Da det kan forventes, at der vil ske ændringer til de definerede forretningsprocesser i forbindelse med ændringer i markedsreglerne, skal definitionerne af workflows være fleksible over tid. Der forventes at være mange samtidige aktive workflows i en normal situation, hvilket kræver velfungerende overvågningsværktøjer til at sikre sig, at alle processer gennemløbes ok, og der skal findes gode værktøjer til fejlfinding af workflow Workflow kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Oprettelse og redigering af workflow Der skal være anvendelige værktøjer til oprettelse og redigering af workflow i systemet. 4 Dok /10, Sag 10/ /132

33 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Brugerinterface til workflow administration Al administration af workflow skal ske gennem et velfungerende brugerinterface, og skal opfylde krav til brugervenlighed og tilgængelighed som beskrevet i afsnit 5. Det er dog ikke et krav, at administrationen af workflow skal ske via webportalen K Status for workflow Det skal være muligt for brugere i DataHub'en at se overordnet status for alle aktive workflows og at kunne se detaljerede oplysninger for specifikke processer K Fejlmelding fra workflow Hvis en workflow-proces fejler, skal dette logges i DataHub'en og systemadministratoren skal notificeres K Ændring af aktivt workflow Det skal være muligt for brugere at ændre status eller forløb på et aktivt workflow K Flere versioner af workflow definitioner Det skal være muligt at definere flere versioner af samme workflow i forbindelse med ændring af processer K Rollback ved afbrudte workflow Det skal være muligt at foretage rollback for de transaktioner, der indgår i et workflow ved en evt. afbrydelse af workflowet K Logning af workflow Alle workflow processer skal logge procesflowet og der skal være mulighed for at foretage evt. fejlsøgning senere K Dokumentation af workflow Der skal findes rapportfunktioner, der giver en overskuelig dokumentation af workflow definitioner K Konfigurering af tidsfrister Pseudo-forskrifterne H1, H2 og D1 definerer mange tidsfrister for processer og kan forventes at blive ændret på sigt. Disse tidsfrister skal være konfigurerbare i workflowprocesserne. Dok /10, Sag 10/ /132

34 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Midlertidig annullering af tidsfrister I forbindelse med fejlsituationer, kan der være behov for en midlertidig annullering af aktuelle tidsfrister, defineret i workflow. Hvis f.eks. kommunikationen til DataHub'en har været afbrudt et døgn, må aktørernes efterfølgende indsendelser af data ikke blive afvist pga. overskridelse af tidsfrist. Tabel 4-3: Workflow kravtabel 4.4 Rapportering I vurderingen af tilbuddet vil der blive lagt positiv vægt på, at rapportering fra DataHub'en og Aktørtestsystemet kan foretages via en veldefineret arkitektur. Det er et krav, at der skal leveres et generelt rapporteringsværktøj, som bl.a. kan levere de rapporter som DataHub'en og Aktørtestsystemet har behov for (se krav beskrevet i specifikke afsnit). Der skal samtidig leveres en integrationsløsning til Energinet.dk's eksisterende Datawarehouse platform SAP / BW (ETL proces). Evt. kan det ovenstående rapporteringskrav opfyldes ved brug af Energinet.dk's SAP / BW. Kravene til indholdet i de enkelte rapporter er specificeret under de specifikke krav til Data- Hub'en og Aktørtestsystemet Rapportering kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Rapporteringsarkitektur Der skal leveres et generelt rapporteringsværktøj, som bl.a. kan levere de rapporter, som er specificeret i de specifikke afsnit under DataHub og Aktørtestsystem K Integration med eksisterende SAP BW / BO Der skal leveres en integrationsløsning til Energinet.dk's eksisterende SAP / BW og SAP BO rapporteringsplatform K Afvikling af rapportering Afvikling af rapporteringskørsler må ikke påvirke svartider for brugerne eller øvrige transaktioner Dok /10, Sag 10/ /132

35 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Rapporteringsgrænseflade Brugergrænsefladen skal være webbaseret, hvor brugerobjekter kan indlejres i andre webløsninger eller portaler K Rapporteringsformat Rapportoutput skal være i pdf format og regnearksformat (XML og csv). Tabel 4-4: Rapportering kravtabel 4.5 Dataudveksling Principper og regler for dataudveksling med DataHub'en er beskrevet i pseudoforskrift F og i de tilhørende bilag. Det er her bl.a. beskrevet, at al dataudveksling sker via synkrone og asynkrone webservices. DataHub'en skal udover webservices også have mulighed for udveksling af data via SMTP ( ). Dette skyldes, at DataHub'en, udover dataudveksling med aktørerne i det danske elmarked, også skal udveksle data med f.eks. NordPool (elbørsen) og de øvrige nordiske samt nordeuropæiske systemansvarlige, og her er kommunikationsmetoden SMTP. Den forventede funktionalitet af webservice, kan skitseres således: Funktionalitet Dataudveksling beskrevet i forretningsprocesserne Asynkron webservice. Store transaktionsmængder, og store datameddelelser. Simple forespørgsler på data fra aktørernes itsystemer Synkron webservice. Som service til aktørernes egne it-systemer, skal der stilles en række webservices til rådighed fra DataHub'en. Nogle webservices kan være sammenfaldende med forretningsprocesserne, f.eks. "hent stamdata for målepunkt", eller "hent status for transaktioner indsendt i dag" Simple forespørgsler/opdateringer på data fra Portal Synkron webservice. Dataudveksling til/fra webportalen forventes at ske ved kald af webservices. Her vil der også være tale om muligheder for opdateringer af data i DataHub'en. Tabel 4-5:Funktionalitet af webservices Anvendelse af webservices i elmarkedet har indtil nu været begrænset til de balanceansvarliges indmelding af handelsplaner til Energinet.dk, ellers har al dataudveksling i elmarkedet foregået Dok /10, Sag 10/ /132

36 via SMTP ( ). Webservices er således nyt i dette forretningsområde, og det må forventes, at krav og ønsker til nye webservices fra aktørerne vil vokse i takt med modningen af anvendelsen. Webservices der tilbydes i DataHub'en skal også være tilgængelige i Aktørtestsystemet Dataudveksling kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O MK Krav fra pseudo-forskrift F Webservice skal opfylde krav til dataudveksling, som beskrevet i pseudo-forskrift F og bilagene til denne forskrift K Dataudveksling via SMTP Dataudveksling med DataHub'en skal alternativt kunne ske med SMTP (mail). Dataformat er det samme som ved udveksling via webservices, beskrevet i pseudo-forskrift F K Dataudveksling med webportal Kommunikation og dataudveksling mellem webportalen og DataHub'en skal ske ved webservicekald K Testfunktion til webservices Der skal til systemadministratoren findes webforms, der kan anvendes til test af de enkelte webservices K Webservices i DataHub og Aktørtestsystem Webservices, der tilbydes i DataHub'en, skal også være tilgængelige i Aktørtestsystemet Tabel 4-6: Dataudveksling - kravtabel 4.6 Alternativ webadgang for kunder I opgavebeskrivelsen, der danner grundlag for dette projekt, er det et krav at alle elkunder i Danmark får adgang til at se egne stamdata og måledata i en webportal. I denne kravspecifikation er dette formuleret som et krav om, at DataHub'en stiller en indlejret webapplikation til rådighed, og at elleverandørerne anvender denne webapplikation i deres egen portal. Et alternativ til dette er, at DataHub'en selv tilbyder en portalløsning, hvor kunden logger ind med NemID og her kan se egne stamdata og måleregistreringer. Dok /10, Sag 10/ /132

37 Funktionaliteterne i DataHub'en vedr. kunder, f.eks. tilknytning af et målepunkt til en kunde vil være uændret - det er blot DataHub'en, der stiller portalen til rådighed for kunden, herunder understøttelse af indlogning med NemID Alternativ webadgang for kunder kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O O Alternativ webadgang for brugergruppen "Kunder" Det skal belyses hvilke økonomiske, tids- og systemmæssige konsekvenser det har for projektet, at DataHub'en tilbyder indlogning til alle kunder, via NemID, på DataHub-portalen. Funktionaliteten for kunderne skal i portalen være uændret i forhold til de i øvrigt specificerede krav i dette bilag. Tabel 4-7: Alternativ webadgang for kunder - kravtabel Dok /10, Sag 10/ /132

38 5. Funktionskrav til Portalen Dette afsnit beskriver generelle krav til portalløsningen. DataHub Forretningsprocesser Stamdata Måledata Aktørtestsystem Beregningsfunktioner Dataudtræk Registrering af system Testcases Samfakturering Specifikke afregninger Testdata Testforløb Rapportering Kvalitetsindeks (KPI) Testgodkendelse Testhistorik Portal Design & tilgængelighed Webformularer Selvbetjeningsportal Fælles komponenter Systemadministration Rapportering og krav Brugeradministration Workflowadministration Dataudveksling Ikke-funktionelle krav Arkitekturkrav Integrationer Kommunikation Sikkerhed Platform Datamigrering 5.1 Generelle funktionskrav til Portal DataHub'en skal primært understøtte de operationelle datastrømme og processer, der driver elmarkedet. Men der er også krav til en brugervenlig webportal. Brugerne af portalen kan primært opdeles i tre grupper: Netvirksomhed, elleverandør, balanceansvarlig og it-leverandør - som kan anvende portalen som det daglige værktøj mod DataHub'en og Aktørtestsystemet. Elkunde (elforbruger, elproducent) og myndighed - som kan anvende portalen til opslag efter behov. Offentligheden - som kan anvende portalen til statistik opslag efter behov. Portalen skal være en fælles løsning for DataHub'en og Aktørtestsystemet og skal sikre en god og effektiv kommunikation til alle brugere af DataHub'en. For at sikre at brugerne kan bruge systemet med minimal instruktion og support, findes der en række principper relateret til brugeroplevelsen: Systemet skal være umiddelbart forståeligt. Dok /10, Sag 10/ /132

39 Det skal være nemt at lære systemet at kende og med tiden bruge mere avancerede funktioner. Systemet skal kunne betjenes af en række forskellige brugere med forskellige forudsætninger og behov Systemet skal være attraktivt for brugeren at bruge, den grafiske brugergrænseflade skal give brugeren lyst til at bruge systemet Systemet skal have mulighed for at følge standarder, juridiske krav og best practice ang. brugervenlighed Brugergrænsefladen skal være rig og omfatte tekst, tabeller, grafik herunder grafer og animation. Design Der er ikke udarbejdet en specifik designmanual for DataHub'en. Webportalens design skal så vidt muligt ligne Energinet.dk's kommende hjemmeside (idriftsættes august 2010). Energinet.dk's Design- og styleguide er vedlagt som bilag. Brugervenlighed Portalen skal støtte brugerne med intuitive brugergrænseflader, som skal sikre: Let genkendelighed både visuelt og sprogligt, så det passer til brugernes faglige omgivelser Ensartethed og konsistens. Det gælder layout, ikoner, tekst, funktionalitet og menuer. Hurtigst mulig adgang til relevant funktionalitet. Portalen skal så vidt muligt følge krav om tilgængelighed jf. Standarder for offentlige hjemmesider og tilgængelighed (WCAG 2.0-AA Web Content Accessibility Guidelines), men Energinet.dk er ikke underlagt lovkrav om opfyldelse af WCAG. Det er ligeledes et ønske at portalen, så vidt muligt, følger retningslinierne for IT- og Telestyrelsens Bedst på Nettet. Der lægges vægt på, at det er muligt at tilgå indhold med brug af andre browsere end Internet Explorer. Der skal browser-optimeres til MSIE, Firefox, Safari og Chrome. Hjælpefunktioner og dokumentation Brugerne har brug for at kunne finde relevant hjælp og vejledning, når behovet opstår i systemet. Der er behov for en intuitiv og selvforklarende brugergrænseflade, som understøttes af hjælpefunktioner kombineret med et godt visuelt (grafisk) overblik. Som selvhjælp til brugerne skal der være adgang til diskussionsforum og FAQ. Dok /10, Sag 10/ /132

40 5.1.1 Kravtabel til generelle funktionskrav til Portal Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O Generelle funktionskrav K Brugergrænsefladen Portalen skal kunne anvende portlets, webparts eller lignende i brugergrænsefladen K Standardbaseret webinterface Systemets skærmbilleder skal baseres på XHTML 1.0 eller nyere. Skærmbilledernes layout skal implementeres med CSS 2.0. Skærmbillederne skal kunne gennemgå W3C HTML/XHTML og CSS 2.0 validering uden fejl K Portal software Portalens brugergrænseflade skal baseres på standard portal software og administreres gennem standard CMS K Browser Der skal browser-optimeres til de browsere, der har mere end 5 % markedsandel K Ændringer i drift Brugergrænsefladen i portalen skal kunne tilpasses og konfigureres, mens systemet er drift K Konfigurerbarhed Brugergrænsefladen skal være så fleksibel som mulig. Derfor skal alle links, felter, datoer og grænseværdier kunne konfigureres gennem administrationsinterfacet K Periodisering Der skal være mulighed for at systemadministratoren kan periodisere f.eks. idriftsættelse af webformularer K Opret/rediger tekster Systemadministrator skal kunne oprette og redigere sider og tekster K Sprog Systemet skal kunne håndtere flere sprog i brugergrænsefladen. Sprogvarianter skal ligge som selvstændigt tekstbibliotek, der kan udskiftes og udbygges i takt med behov K Sprog ved startleverance Systemet skal leveres med dansk og engelsk brugergrænseflade. Dok /10, Sag 10/ /132

41 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Valg af sprog I brugergrænsefladen skal det være muligt for brugeren, at vælge hvilket sprog siden ønskes vist med K Tegnsæt og dialog Som default skal brugergrænsefladen være på dansk (herunder også decimal- og tusindtalsseparatorer) og dialog K Skærmopløsning Systemets nye skærmbilleder skal optimeres til skærmopløsning 1024*786 og 16/32 bit farver samt være skalerbart til større skærmopløsninger. Der bør være fleksibilitet for andre standard opløsninger, så systemet kan bruges på en række forskellige enheder K Vedligehold menustruktur Systemadministrator skal kunne redigere i portalens menustruktur K Søgefunktion Der skal etableres søgefunktion, som er til rådighed på alle sider. Der søges på tværs af hele brugergrænsefladen, og søgningen skal fungere som standard wildcard søgning K Sporing af brugernes adfærd Systemadministratoren skal kunne spore brugernes adfærd på specificerede sites. Der skal kunne genereres udtræk over: - hvor ofte de enkelte sider besøges - hvilke filer, der bliver downloadet og hvornår K Print ikon På alle sider skal der være et Print" ikon for start af printdialog K Print layout Ved print af siden, skal siden udskrives uden de faste rammer f.eks.. top og venstremenuer. Der skal på udskriften anføres brødkrummesti og sidens navn. Ud over fjernelse af rammerne skal indholdet stå som på skærmen og må ikke beskæres K Download til regneark På relevante sider skal det være muligt at eksportere de fremsøgte data til regneark i formaterne xml og csv. Dok /10, Sag 10/ /132

42 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Sortering af data Ved visninger af data i tabeller/lister skal det være muligt at sortere data ved klik på kolonneoverskriften K Søgning af data Der skal kunne fremsøges data, og på disse sider skal der anvendes søgefunktion baseret på enkle og gængse principper og standarder for web-brugergrænseflader. Søgningen må ikke være case sensitiv K Filtrering af data På sider, hvor der skal fremsøges data, skal det være muligt at filtrere data ved hjælp af dropdown lister eller wildcard søgning. Design- og brugervenlighed K Design Webportalen og webapplikationens design skal følge retningslinierne for Energinet.dk's hjemmeside, som beskrevet i Energinet.dk's Designog styleguides, vedlagt som bilag. Hvis dette krav ikke kan opfyldes, skal der redegøres for afvigelserne i forhold til design- og styleguides i Løsningsbeskrivelsen K "Bedst på Nettet" Portalen skal følge retningslinierne for IT- og Telestyrelsens Bedst på Nettet". Leverancen skal opnå en vurdering på minimum 4 Netkroner, baseret på "Bedst på nettets" screening (foretaget af Leverandøren) og brugerevaluering (foretaget af brugere i Energinet.dk). Begge tæller ligeligt. Brugerevalueringen kan evt. gennemføres på en brugervenligheds-workshop K Tilgængelighed Portalen skal opfylde retningslinjer angivet i Standarder for offentlige hjemmesider og tilgængelighed (WCAG 2.0 AA Web Content Accessibility Guidelines), K Menustruktur Alle brugere af portalen skal kun se de menupunkter, som vedkommende har adgang til. Dok /10, Sag 10/ /132

43 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Brugervenlighed Brugerne må ikke opleve mistet brugervenlighed i forbindelse med præsentation af systemsider ("siden ikke fundet" mm.) Hjælpefunktioner og dokumentation K Administration af hjælpetekster Det skal være muligt for systemadministratoren at vedligeholde portalens hjælpetekster K Pop up hjælp på felter Det skal være muligt at definere pop up hjælp på felter (hjælpetekst når cursoren hviler på en tekst/felt) K Autotekst på felter Det skal være muligt at anvende autotekst på felter (hjælpetekst vises i et indtastningsfelt) K Vedligeholdelse af vejledninger og informationsmateriale Det skal være muligt at oprette og vedligeholde vejledninger (til download) og andet informationsmateriale. Eksempler på andet informationsmateriale kunne være links, kontaktinformation, markedsinformation el. lign K Online hjælp og vejledning Alle typer af brugere skal kunne finde relevant hjælp og vejledning, når behovet opstår i systemet K Vejledninger Det skal være muligt for brugeren at blive præsenteret for og downloade relevante vejledninger. Diskussionsforum og FAQ K FAQ Portalen skal indeholde en FAQ side, som skal kunne vedligeholdes af systemadministratoren. FAQ skal kunne ses og anvendes af alle interessenter med rettigheder hertil K Diskussionsforum Brugergrænsefladen skal tilbyde standard forum funktionalitet, hvor markedsaktørerne og itleverandører kan vende problemstillinger og lignende, både med Energinet.dk og andre brugere. Dette forum skal bl.a. give brugerne mulighed for at oprette og kommentere på tråde, samt at abonnere på relevante tråde og efter- Dok /10, Sag 10/ /132

44 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O følgende blive adviseret omkring nye indlæg K Standard WIKI funktionalitet FAQ og diskussionsforum ønskes baseret på standard WIKI funktionalitet K Nyheder Nyheder skal kunne kategoriseres og skal kunne præsenteres på forskellig vis overfor systemets brugere. Eksempelvis ved at aktuelle nyheder vises på én side og gamle nyheder fremfindes på et arkiv, hvor nyhederne er kategoriseret efter et sæt metadata eller via en indbygget søgefunktion, der skal kunne slås til eller fra efter eget valg K Nyhedsbrev abonnement Det skal være muligt at sende information direkte til sitets brugere i forbindelse med diverse nyheder K Nyhedsbrev tilmelding Markedsaktører og it-leverandører skal selv kunne til- og framelde sig som abonnenter på nyhedsbreve, som varierer efter brugerens interesseprofil K Nyhedsbrev sikkerhed Systemet skal automatisk sikre, at abonnenterne ikke kan se hinandens -adresser i de udsendte nyhedsbreve eller anden information der kan vise de øvrige abonnenters identitet K Nyhedsbrev udsendelse Det skal være muligt at sende forskellige nyhedsbreve til forskellige grupper af abonnenter K Nyhedsbrev arkiv Det skal være muligt at se nyhedsbrevskladder og udsendte nyhedsbreve i et internt arkiv K Nyhedsbrev oversigt Det skal være muligt genere en oversigt over, hvilke nyhedsbreve, den enkelte abonnent har modtaget. Tabel 5-2: Kravtabel for Generelle funktionskrav til portal Dok /10, Sag 10/ /132

45 5.2 Webformularer I DataHub'en skal der findes webformularer til en række formål såsom forespørgsler mellem aktører i markedet, bestilling af ændringer i stamdata etc. Anvendelsen af webformularer skal bl.a. sikre anonymiteten mellem elleverandør og netvirksomhed. Webformularer forventes at blive en meget anvendt funktion i DataHub'en, og det er derfor vigtigt, at de kan ændres og nye tilføjes på en let tilgængelig måde efter behov. Webformular-eksempel på forespørgsel fra netvirksomhed til elleverandør: En netvirksomhed har fået en henvendelse fra en kunde vedr. en fejlagtig flytning. Netvirksomheden skal afklare dette med kundens elleverandør og vælger derfor webformularen "Forespørgsel til elleverandør". Da netvirksomheden ikke kender målepunktets elleverandør, skal forespørgslen foregå via webformular til DataHub'en for at sikre anonymiteten. I denne webformular skal netvirksomheden: Vælge det aktuelle målepunkt vha. en søgefunktion eller fra en valgliste der viser netvirksomhedens målepunkter. Vælge om meddelelsen skal sendes til tidligere, nuværende eller kommende elleverandør (radio button el. checkboks). Formulere problemet i en tekstboks Evt. udfylde afsenderens kontaktoplysninger, mailadresse el. telefon "Sende" til elleverandør Herefter skal DataHub'en finde oplysningerne på den pågældende elleverandør og sende oplysninger fra webformularen til elleverandøren pr. mail. DataHub'en arkiverer webformularen Kravtabel til etablering af webformularer Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Kunde til netvirksomhed vedr. et målepunkt Forespørgsel til netvirksomhed vedr. et målepunkt. F.eks. hvis kunden har spørgsmål til det målte forbrug eller til et fremsendt aflæsningskort K Kunde til elleverandør vedr. et målepunkt Forespørgsel til elleverandør vedr. et målepunkt. F.eks. hvis kunden har spørgsmål til det afregnede forbrug eller til tidligere, nuværende Dok /10, Sag 10/ /132

46 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O eller kommende elleverandør K Kunde til netvirksomhed vedr. forkerte stamdata Oplysning til netvirksomhed vedr. forkerte stamdata på et målepunkt f.eks. disponentnavn K Kunde til elleverandør vedr. fejlagtig leverandørskift Forespørgsel til nuværende eller kommende elleverandør i forbindelse med udredning af fejlagtig flytning på et specifikt målepunkt K Elleverandør til netvirksomhed vedr. måling på et målepunkt Forespørgsel til netvirksomhed vedr. målinger på et specifikt målepunkt. F.eks. atypisk eller manglende måling på et målepunkt K Elleverandør til anden elleverandør vedr. leverandørskift Forespørgsel til tidligere, nuværende eller kommende elleverandør i forbindelse med problemer ved et leverandørskifte på et specifikt målepunkt K Elleverandør til øvrige markedsaktører vedr. målepunkt Information til øvrige markedsaktører, der er relateret til et specifikt målepunkt. Kan vedrøre tidligere, nuværende eller kommende elleverandør K Elleverandør til Energinet.dk Forespørgsel til Energinet.dk: Markedsrelaterede spørgsmål, support til DataHub funktioner, spørgsmål vedr. aktørtest etc K Netvirksomhed til elleverandør vedr. fejlagtig flytning Forespørgsel til tidligere, nuværende el. kommende elleverandør i forbindelse med udredning af fejlagtig flytning på et specifikt målepunkt K Netvirksomhed til elleverandør vedr. fejlagtig leverandørskifte Forespørgsel til tidligere, nuværende eller kommende elleverandør i forbindelse med udredning af fejlagtig leverandørskifte på et specifikt målepunkt K Netvirksomhed til øvrige markedsaktører vedr. målepunkt Information til øvrige markedsaktører der er relateret til et specifikt målepunkt K Netvirksomhed til Energinet.dk Forespørgsel til Energinet.dk. F.eks. markedsrelaterede spørgsmål, support til DataHub funktioner, spørgsmål vedr. aktørtest etc. Dok /10, Sag 10/ /132

47 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K It-leverandør til Energinet.dk Forespørgsel til Energinet.dk. Fx. support til funktioner eller spørgsmål vedr. aktørtest K It-leverandør til øvrige itleverandører eller markedsaktør Information eller forespørgsel til øvrige itleverandører el. markedsaktører vedr. aktørtest. Tabel 5-2: Kravtabel til etablering af webformularer Kravtabel til webformularer Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Webformular videreudvikling Der skal findes et designværktøj til oprettelse og ændring af webformularer. Der lægges vægt på, at løsningen skal være åben og let tilgængelig for løbende ændringer af de elektroniske formularer, og at nye formularer kan tilføjes uden brug af ekstern ekspertbistand. Man skal kunne udvide anvendelse af formularer i takt med, at behovet opstår K Vedhæfte bilag I forbindelse med udfyldelse af formularer skal der være mulighed for at vedhæfte eller medsende bilag. Som minimum i Word, pdf-, eller regnearksformat K Print af webformular Alle elektroniske formularer skal i den eksisterende form kunne printes af brugeren K Arkivering webformular Systemet skal give mulighed for en arkivering af udfyldte blanketter. Indsendelser skal kunne gemmes og ekspederes i et arkiv til formålet. Systemadministratoren skal have mulighed for at slette fra arkivet K Søgning i arkiv Systemadministratoren have mulighed for fritekstsøgning og filtrering på status, side, dato og/eller feltspecifikt indhold i arkivet. Tabel 5-2: Kravtabel for webformularer Dok /10, Sag 10/ /132

48 5.3 Krav til DataHub portalen Brugerne af DataHub portalen vil både være professionelle brugere, og it-svage brugere. Brugerne kan grupperes således: Systemadministratorer, superbrugere og brugere (Energinet.dk) Markedsaktører er de primære brugere af systemet. Kunder - elforbruger, elproducenter og myndigheder Offentlig - den offentlige del af portalen Nedenstående tabel viser de primære overordnede funktioner, der skal kunne udføres via Data- Hub portaldelen for de enkelte brugergrupper. De enkelte funktioner er nærmere beskrevet i afsnit 6 Funktion System Markeds Kunder Offentlig admin aktører Stamdata for aktør CRUD 5 RU R R Stamdata for målepunkt CRUD CRU R Måledata CRUD CRU R Beregningsfunktion CRUD CRUD Rapportering CRUD R R R Procesovervågning og styring (workflow) CRUD CRU Tabel 5-1 Overordnede funktioner 5.4 Krav til Aktørtestsystem portalen Brugerne af Aktørtestsystemet vil være professionelle brugere, og kan opdeles i to grupper: Systemadministrator, superbrugere og brugere (Energinet.dk) Markedsaktører og it-leverandører er de primære brugere af systemet. 5 CRUD: Create, Read, Update, Delete Dok /10, Sag 10/ /132

49 De overordnede funktioner der skal kunne udføres via portalen i Aktørtestsystemet for de enkelte brugergrupper vil være: Funktion Systemadministrator Aktør & itleverandør Registrering af it-system der skal testes CRUD CRUD Administration af testcases CRUD R Administration af testdata CRUD CRUD Administration af testforløb CRUD R Godkendelse af testforløb CRUD Historik for testforløb R R Tabel 5-2: Funktioner per brugergruppe i Aktørtestsystemet De specifikke funktionskrav til Aktørtestsystemet er specificeret i kapitel Funktionskrav til integration af Selvbetjeningsportalen "Selvbetjening" er betegnelsen for den eksisterende webapplikation placeret på https://selvbetjening.energinet.dk. Selvbetjeningsportalen (SBP) anvendes både af el- og gaskunder, og er funktionsmæssigt opdelt efter dette, men brugerstyring og administration er fælles for hele portalen. Da brugerne på SBP også vil være brugere på DataHub'en, ses en fordel i at integrere Energinet.dk's Selvbetjening i DataHub portalen. Den omtalte integration vil kun gælde for el-kunder, altså vil Selvbetjeningsportalen fortsætte med servicering af gas-kunder. Dok /10, Sag 10/ /132

50 Netvirksomhed Balanceansvarlig Hent afregningsbilag Hent Vedligehold Hent afregningsbilag stamdata afregningsbilag Selvbetjeningsportal Anlægsejer Indberet rådighed Konverteres til DataHub portalløsning Webform Bruger/rettighed Indberet servicebesøg Servicevirksomhed Flyttes uændret til DataHub portalløsning Forretningslogik Webservice: Afregningsbilag Stamdata Webservice: Hent oplysning pr. CVR-nr PandaService Stamdata produktionsanlæg Afregningsbilag CVR-register Figur 5-1: Oversigt over Selvbetjeningsportal Ovenstående Figur 5-1 viser den overordnede opbygning af SBP, og brugerne af denne. Portalen har webservice integrationer til PandaService, hvorfra der hentes oplysninger om stamdata for produktionsanlæg, og afregningsbilag. Og fra CVR-registeret hentes adresseoplysninger på de ca anlægsejere, der er oprettet i portalen. Brugerne på SBP er medarbejdere hos netvirksomhederne, hos de balanceansvarlige og anlægsejere (ejere af en vindmølle eller et værk). Brugerne oprettes, og deres rettigheder vedligeholdes af Energinet.dk. Brugerne kan på Selvbetjening se deres egne afregningsbilag, stamdata for de produktionsanlæg de ejer og evt. servicebesøg på deres vindmøller. Når Panda overfører nye afregningsbilag til SBP, modtager de berørte brugere en notifikation via om, at der er nye bilag. En del ejere af værker skal af hensyn til deres afregning, dagligt indberette om deres anlæg er til rådighed for markedet. Denne indberetning af rådighed, sker via funktioner i SBP. Virksomheder, der servicerer vindmøller i Danmark, skal i portalen indberette datoen for servicebesøg, de har foretaget på de enkelte vindmøller, og datoen for det næste planlagte servicebesøg skal registreres. Portalens database og forretningslogik skal genbruges ved integrationen, så integrationen vedrører altså udelukkende skærmbilleder og brugerstyringen. Dok /10, Sag 10/ /132

51 Integration mellem eksisterende SBP funktion og brugergrænseflade i DataHub'en vil være baseret på WCF (Windows Communication Foundation). Energinet.dk leverer et færdigt API, som denne del af brugergrænsefladen baseres på. For at give et overblik over systemet, gennemgås i næste afsnit skærmbillederne fra systemet, og efterfølgende et kort overblik over applikationsstrukturen Skærmbilleder menuoversigt Til forståelse af funktionaliteten vises efterfølgende skærmdumps af relevante skærmbilleder fra SBP, som ønskes integreret i DataHub'en. Alle brugere til SBP er tildelt rettigheder iht. deres rolle i el-markedet. Efter indlogning vises en oversigt over de menupunkter, som brugeren har rettigheder til. Menuoversigten har følgende punkter med tilhørende skærmbilleder: Stamdata - vindmølle- og værksdata Rådighed - indmelding af rådighedsdage for værker Dokumenter - afregningsbilag m.m. System - konfigurationer, logs m.m Stamdata Produktionsanlæg oversigt Produktionsanlægs oversigten viser alle el-producerende anlæg, som er registreret hos Energinet.dk. Brugerne kan kun se de anlæg, som de har rettigheder til, f.eks. hvis de: Ejer en vindmølle eller værk, er netvirksomhed for anlægget, er en servicevirksomhed etc. Dok /10, Sag 10/ /132

52 Skærmbilledet har mange filtreringsmuligheder, og det er valgfrit, om afmeldte anlæg ønskes vist i oversigten. På siden er der også mulighed for at danne en Excel fil over fremsøgte anlæg. Ved oprettelse kan der gemmes data for et anlæg i en 'kladde', således at brugeren på et senere tidspunkt kan afslutte redigeringen og indsende data for anlægget. Når en bruger har oprettet/redigeret et anlæg i SBP, vises en lille rød trekant ved 'Navn'. Trekanten fjernes, når rettelsen er foretaget i Panda, og SBP er opdateret med disse data (se Figur 5-1: Oversigt over Selvbetjeningsportal) Fra oversigten kan vælges et anlæg, og man kan se alle detaljer for dette i et nyt skærmbillede Produktionsanlæg, stamdata for et anlæg Alle felter for et enkelt anlæg vises og brugerens rettigheder bestemmer, om data kan redigeres eller om det kun er visningsfelter. Stamdata er grupperet under faneblade, men de kan også vises i listeform. På felterne er der forskellig funktionalitet, f.eks.: GSRN nummer tildeles automatisk af SBP ved oprettelse af et anlæg. Der er validering på en del af felterne, f.eks. for: Syntaks, krydsvalidering, obligatorisk udfyldning, grænseværdier m.m. Validering af CVR-nummer mod CVR-registeret online i skærmbilledet. Relevante felter udfyldes automatisk med data. Har en bruger oprettet/redigeret stamdata for et anlæg og gemmer disse, bliver der sendt en mail til brugerens egen mailadresse og til Energinet.dk. Disse stamdata opdateres derefter manuelt i Panda af Energinet.dk. En gang dagligt opdateres alle Panda stamdata med PandaService. Dok /10, Sag 10/ /132

53 Ved klik på 'Historik' vises anlæggets forskellige gyldighedsperioder. Der kan også her vælges at se detaljer for anlægget i et nyt skærmbillede Vedligehold ændringer I skærmbilledet kan systemadministrator se alle oprettelser, ændringer eller kladder på anlæg, der er foretaget i SBP. Systemadministrator kan efter behov vælge at køre en 'roll back' pr. transaktion ved at slette disse data i oversigten. Dok /10, Sag 10/ /132

54 CVR-data rapport Det er muligt at kontrollere CVR-nummer mod CVR-registeret for ejere af anlæg. Kontrollen kan udføres pr. netområde, for vindmøller og/eller værker eller på kortnavn for anlæg. Resultatet af kontrollen, SBP data kontra CVR data med markering af forskelle, vises i en Excel-fil på skærmen eller sendes pr. mail til systemadministrator. Kontrollen køres som batch job én gang ugentligt for alle anlæg i SBP Oversigt over servicevirksomheder Oprettelse af godkendte servicevirksomheder, som derefter har ret til at indberette servicebesøg for vindmøller Indlæs servicebesøg En Servicevirksomhed kan levere en Excel-fil med data for sine servicebesøg hos vindmøller i stedet for at indberette data manuelt. Denne fil indlæses i SBP og gemmes i databasen. Dok /10, Sag 10/ /132

55 Servicebesøg oversigt Oversigten indeholder alle vindmøller, som er registreret i SBP. Brugeren finder den relevante vindmølle og trykker 'Indberet', hvorefter et skærmbillede til indtastning vises. I Servicebesøg indberetning skærmbilledet indtastes dato for aktuelt servicebesøg og dato for næste planlagte besøg. Data gemmes i databasen og er nu tilgængelige i servicebesøg oversigten Rådighed Rådighedsoversigt Rådighedsoversigten viser alle værker og anlæg, som af hensyn til deres afregning, skal indberette om deres anlæg er til rådighed for markedet. Brugeren kan kun se de anlæg, der er rettigheder til og vælger her hvilket anlæg, der ønskes indberettet for (Indberet rådighed). Dok /10, Sag 10/ /132

56 Indberetning af rådighedsdage for anlægget Her indtastes hvilke dage pr. måned anlægget ikke har været til rådighed i den forgangne måned og data gemmes Rådighedsskema årsoversigt Oversigt over indberettede dage i et angivet år, hvor anlægget ikke har været til rådighed Rådigheds godkendelse Ved at angive en skæringsdato fremfindes de anlæg, som mangler at blive godkendt. Systemadministrator markerer herefter anlæggene, som kan godkendes. Dok /10, Sag 10/ /132

57 Rådigheds indberetning For en given måned hentes status for alle anlægs rådighedsdata. Der markeres, hvilke anlæg som ønskes sendt til Panda Rådighedsrykker Der angives en skæringsdato, hvorefter der vises, hvilke anlæg som mangler indberetning før skæringsdatoen. Systemadministrator vælger hvilke anlæg, der skal sendes en rykker til, og indtaster en tekst til mailen. Derefter hentes tilhørende mailadresser til de brugere, som er tilknyttet disse anlæg. Disse vises i et nyt skærmbillede til kontrol. Dok /10, Sag 10/ /132

58 Oversigt over udedage Oversigt som viser indberettede udedage pr. anlæg - opdelt pr. år og pr. måned Driftsoversigt for værket Driftsoversigt pr. værk, viser de beregnede, akkumulerede data som er indsendt til Panda. Dok /10, Sag 10/ /132

59 Dokumenter Dokument oversigt Her kan anlægsejere, netselskaber og balanceansvarlige se deres afregningsbilag som pdf-filer. Dokumenterne er uploadet fra PandaService via en webservice Nyt dokument Det er muligt manuelt at uploade et dokument til SBP. Der skal angives, hvilken gruppe dokumentet skal tilhøre, hvilken periode, om det skal godkendes automatisk, og i hvilken sti dokumentet ligger. Dok /10, Sag 10/ /132

60 Udsende dokument notifikation Når der er uploadet nye dokumenter til SBP, kan der sendes en notifikation via mail til relevante brugere. Modtagere af notifikationen er brugere, som har rettigheder til at se de nye dokumenter System log Viser hvilke kvitteringer, nye password m.m. som er sendt fra SBP via mail pr. en given dato. Dok /10, Sag 10/ /132

61 Aktivitetslog Viser hvilke aktiviteter der er sket på SBP, grupperet pr. handling. Logning af bruger login, fejl ved indlogning og indberetning af rådighed Dokument konfiguration I oversigten findes alle dokumenttyper i SBP. Her kan systemadministrator konfigurere hvilke brugerroller, som må se de enkelte dokumenttyper. Dok /10, Sag 10/ /132

62 Generér GSRN numre Systemadministratoren har her mulighed for at hente og vise GSRN numre i SBP uden at oprette anlæg. Tildeling af GSRN sker kun i SBP for at sikre éntydigheden Applikation Energinet.dk's selvbetjeningsportal er bygget som en webapplikation med anvendelse af CMS 2002 til håndtering af applikationens sidestruktur De to følgende figurer illustrerer applikationsopbygningen. Figur 5-2: Applikationsopbygning af SBP Dok /10, Sag 10/ /132

63 Figur 5-3: Nuværende arkitektur tegning Som ovenstående Figur 5-3 illustrerer, er applikationen bygget som en traditionel ASP.NET web applikation, med udgangspunkt i et standard Microsoft teknologi skema. Dok /10, Sag 10/ /132

64 5.5.3 Kravtabel til Selvbetjeningsportalen Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O O Integration af Selvbetjeningsportal Webform og brugerstyring fra den eksisterende Selvbetjeningsportal ønskes integreret i Data- Hub-portalen. Formålet er at opnå en fælles brugerstyring, og at brugerne kun oplever én portal hos Energinet.dk. Alle skærmbilleder skal have samme indhold som i den eksisterende Selvbetjeningsportal. Det er kun den del af Selvbetjeningsportalen der vedrører el, der ønskes integreret. Tabel 5-3: Selvbetjeningsportalen Kravtabel Dok /10, Sag 10/ /132

65 6. Funktionskrav til DataHub en DataHub Forretningsprocesser Stamdata Måledata Aktørtestsystem Beregningsfunktioner Dataudtræk Registrering af system Testcases Samfakturering Specifikke afregninger Testdata Testforløb Rapportering Kvalitetsindeks (KPI) Testgodkendelse Testhistorik Portal Design & tilgængelighed Webformularer Selvbetjeningsportal Fælles komponenter Systemadministration Rapportering og krav Brugeradministration Workflowadministration Dataudveksling Ikke-funktionelle krav Arkitekturkrav Integrationer Kommunikation Sikkerhed Platform Datamigrering I dette afsnit beskrives de specifikke krav til DataHub funktionaliteten. 6.1 Understøttelse af forretningsprocesser (BRS) Alle forretningsprocesser beskrevet i "Forretningsprocesser for det danske elmarked" skal understøttes af DataHub, og Aktørtestsystemet skal kunne simulere disse processer i forbindelse med test af aktørernes IT-systemer. Forretningsprocesserne er beskrevet enkeltvis, og udfordringen med at udarbejde løsninger på evt. konflikter mellem flere samtidige processer skal løses i designfasen i et samarbejde mellem leverandøren og Energinet.dk. Bemærk, at forretningsprocessen "BRS-011: Fejlagtig flytning" er en manuel proces, og derfor ikke indgår i kravtabellen Forretningsprocesser (BRS) kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O Dok /10, Sag 10/ /132

66 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K BRS-001: Leverandørskift DataHub'en modtager og processerer anmodning om skift af elleverandør fra en elleverandør. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-002: Leveranceophør DataHub'en modtager og processerer anmodning om stop af leverance fra en elleverandør. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-003: Håndtering af fejlagtigt leverandørskift DataHub'en modtager og processerer anmodning om fejlagtigt leverandørskifte fra en elleverandør. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-004: Oprettelse af målepunkt DataHub'en modtager og processerer anmodning om oprettelse af et nyt målepunkt fra en netvirksomhed. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-005: Anmodning om stamdata DataHub'en modtager og besvarer en anmodning om stamdata for et målepunkt fra en elleverandør eller en netvirksomhed. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-006: Fremsendelse af stamdata DataHub'en modtager stamdata for et målepunkt fra en netvirksomhed og videresender disse. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-007: Fraflytning - meldt til netvirksomheden DataHub'en modtager fra en netvirksomhed meddelelse om fraflytning af en kunde på et målepunkt og processer dette. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-008: Tilflytning - meldt til netvirksomheden DataHub'en modtager fra en netvirksomhed meddelelse om tilflytning af en ny kunde på et målepunkt og processer dette. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-009: Tilflytning - meldt til elleverandøren DataHub'en modtager fra en elleverandør meddelelse om tilflytning af en ny kunde på et målepunkt og processer dette. DataHub'en skal understøtte funktionerne beskrevet i BRS-009. Dok /10, Sag 10/ /132

67 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K BRS-010: Fraflytning - meldt til elleverandøren DataHub'en modtager fra en elleverandør meddelelse om fraflytning af en kunde på et målepunkt og processer dette. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-012: Skift af afregningsform DataHub'en modtager og processer en meddelelse fra en netvirksomhed om skift af afregningsform for et målepunkt. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-013: Afbrydelse og genåbning af målepunkt DataHub'en modtager og processerer en meddelelse fra en netvirksomhed om afbrydelse eller genåbning af et målepunkt. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-020: Forbrugsopgørelse for skabelonafregnet målepunkt DataHub'en modtager forbrugsopgørelse for et målepunkt fra netvirksomheden og videreformidler dette. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-021: Fremsendelse af måledata for et målepunkt DataHub'en modtager måledata for et målepunkt fra netvirksomheden og videreformidler disse. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-022: Fremsendelse af andelstal DataHub'en fremsender beregnede andelstal til relevante aktører. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-023: Fremsendelse af beregnede tidsserier DataHub'en fremsender resultatet af tidsserieberegninger til relevante aktører. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-024: Anmodning om historiske data DataHub'en modtager og besvarer en anmodning om måledata for et målepunkt fra en elleverandør. DataHub'en skal understøtte funktionerne beskrevet i BRS K BRS-025: Anmodning om måledata DataHub'en modtager og besvarer en anmodning om måledata for et målepunkt fra en elleverandør eller netvirksomhed. DataHub'en skal understøtte funktionerne beskrevet i BRS-025. Dok /10, Sag 10/ /132

68 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Forretningsprocesser via portal Alle forretningsprocesser beskrevet i "Forretningsprocesser for det danske elmarked" skal, hvis muligt og relevant, kunne gennemføres via sider i portalløsningen. (jf. de ovenstående krav i tabellen) Processerne skal udføres præcis med samme funktioner og kontroller som hvis indmeldt via EDI. F.eks. skal det være muligt at oprette et målepunkt (BRS-004) via webportalen, mens fremsendelse af andelstal (BRS-022) ikke er relevant K Visning af status for processer Aktørerne skal via webportalen kunne se aktuelle status på de processer, der vedrører den aktuelle aktør. En elleverandør skal f.eks. kunne se, at han har initieret en leverandørskifteproces, og at status for processen lige nu er at der afventes en måleraflæsning fra netvirksomheden. Skærmbilledet skal tage hensyn til de gældende rettigheder, så en netvirksomhed f.eks. ikke kan spore hvorfra en leverandørskifteproces er initieret K Konflikt mellem parallelle processer Leverandøren skal i et samarbejde med Energinet.dk analysere evt. mulige konflikter mellem flere samtidige parallelle forretningsprocesser, og udarbejde løsninger for disse konflikter. Tabel 6-1: Markedsprocesser kravtabel Dok /10, Sag 10/ /132

69 6.2 Samlet datamodel Konc ernak tør GLN Navn CVR 1 * Aktør Aktør ID AktørIDformat CVR/ P Navn Adresse:Type sammensat adresse Webadresse EDI godkendt It-system kan lukkes Ønkes fejlrapport Tidspunkt for lukning Lukningstidspunktskode Tidspunkt for dannelse af fejlrapport Fejlrapportstidspunktskode 1 * Kontak toplysning Kontaktoplysninger:Type sammensat kontaktoplysning Kontaktoplysningsfunktion 0..1 Balanc eansv arlig Netv irk somhed Ellev erandør 1 Markedsskæringsdato Forsyningspligtig * * * Prisområde Balanc e- Ellev erandør-ba- Prisområdekode ansv arsfuntion Netområde relation Person Firma Prisområdenavn BA funktion Fra_dato Navn CVR Til_dato 0..1 * Adresse:Type sammensat adresse Navn 1 * Fødselsdato Adresse:Type sammensat adresse PID * 1 Valgt 1 * Rolle forsyningspligtig 0..1 * N etområde Fra_dato 1 1 Til_dato * Netområde_nr Netområde_navn Lev eranc eperiode * * Obligatorisk grænse Fra_dato 1 Person- Til_dato Firma- Målepunk trelation 1 1 Målepunk trelation * Fra_dato Fra_dato * Til_dato Til_dato Målepunk t- M ålepunkt * * Netområde relation Målepunkt ID { Person eller Firma} Fra_dato Gyldighedsdato Fra Til Til_dato * 1 Målepunktsadresse:Type sammensat adresse Tilslutningsstatus Indsendte værdier skal tjekkes Basalt målepunkt Webadgangskode T ek nisk målepunk t Afregningsmålepunk t Nettoafregningsgruppe * * Samle- udv ek slingsmålepunk t Aflæsningsfrekvens 1 Samle-nettoafregnet målepunk t Nettoafregningsgruppe Målepunktsart Brændselsart VærksGSRN PSO fritaget VE-Samle- produk tionsmålepunk t 1 Samle- analysemålepunk t 1 Forbrugsmålepunk t Forventet årsforbrug DE Branchekode Over 63A Samle- produk tionsmålepunk t Aflæsningsfrekvens Blokeret for automatisk lev. skift 1 Består af 1 Samle-forbrugs målepunkt - Time Samle-forbrugsmålepunkt - Sk abelon 1 1 Aflæsningsdag (1..12) Forbrug ud over obligatorisk grænse tilladt Består af Forbrugsmålepunkt - Skabelon - Fjernaflæst Forbrugsmålepunkt - Skabelon - Manuel aflæst Består af Består af Består af Består af Består af Indsendelsefrekvens til DataHub Aflæsningsfrekvens * * * * * * * Udv ek slingsmålepunk t M-målepunk t VE- produk tionsmålepunk t Analysemålepunk t Forbrugsmålepunkt - time Forbrugsmålepunkt - sk abelon Produk tionsmålepunk t * * * * * * * UD V tidsseriev æ rdi Nettoafregnet tidsseriev æ rdi VE tidsseriev æ rdi Analyse tidsseriev æ rdi Forbrug tidsseriev æ rdi ForbrugsMP - skabelon tidsseriev æ rdi Sluttid Produk tion tidsseriev æ rdi * * * * IkkeMP tidssserieværdi MP tidsserieværdi Produkt T idsseriedefinition Tidsserieværdi Tid Værdi Status * 1 TS_ID TS_Type Opløsning Enhed Matematisk type Figur 6-1: Samlet logisk datamodel Dok /10, Sag 10/ /132

70 Bemærk, at dette er den samlede logiske datamodel og som sådan ikke skal betragtes som et bud på en fysisk tabelstruktur. Bemærk også, at de beskeder, der fremsendes via EDI med stamdata for et målepunkt, vil rumme fællesmængden af attributter for alle målepunkstyper. Som eksempel kan nævnes, at når der indsendes stamdata for et produktionsmålepunkt, er attributten DE branchekode ikke relevant, men kan alligevel findes i beskeden. I datamodellen (se Figur 6-1: Samlet logisk datamodel) optræder entiteterne Balanceansvarlig, Elleverandør og Netvirksomhed som sub-entitteter af den generelle entitet Aktør. I daglig tale opfattes entiteterne ofte som helt selvstændige entiteter. Nogle selskaber er også koncernforbundne. Bemærk: Nogle firmaer optræder i flere roller. F.eks. er "DONG Energy Frederiksberg Elnet A/S" både netvirksomhed og handelsbalanceansvarlig på det tidspunkt, hvor dette dokument skrives. 6.3 Stamdata Stamdata, opdateret på baggrund af markedsprocesser Målepunkter og målinger I figuren over den samlede datamodel svarer dette til entiteterne under Målepunkts-entiteten (Målepunktsentiteten inklusiv). Yderligere vil stamdata for Afregningsmålepunkter rumme data for op til 2 disponenter (navn, adresse) og også elleverandør ID og netområde ID m.m. Dette anses også for stamdata til målepunktet, og det er i den logiske datamodel realiseret, ikke ved direkte attributter, men gennem associationer. Målepunkter og relaterede entiteter skal kunne vedligeholdes både gennem EDI-kommunikation og gennem webportalen. Set fra DataHub'ens synspunkt er det de samme processer, der aktiveres uanset om vedligeholdet sker gennem EDI eller webportal. DataHub'en skal have skærmbilleder under den generelle webportal, som kan varetage CRUD-funktioner (Create, Read, Update, Delete) for disse entiteter. Se yderligere i forskriften for stamdata "Pseudo-forskrift I - Stamdata". Der er en række markedsprocesser, der basalt set manipulerer med entiteten Målepunkt. Disse markedsprocesser findes i pseudo-forskrift H1. Se f.eks. Leverandørskifte, Flytning samt udløb af kontrakt, og andre. Disse processer vil i nogle tilfælde ændre på målepunktets tilstand (se Figur 6-2). Disse markedsforskrifter er brudt ned til en række BRS'er (processer) og RSM'er (datameddelelser) og disse kan potentielt alle påvirke Målepunkt og målinger. Ansvaret for vedligehold af disse stamdata er principielt altid netvirksomhedens, på nær enkelte undtagelser. Et eksempel er processen BRS-009, hvor tilflytning tilmeldt til elleverandør vil medføre at elleverandøren overskriver Disponentnavn og adresse. Et andet eksempel er feltet "Webadgangskode", der vedligeholdes af DataHub'en og som udveksles via EDI. Et tredje eksempel Dok /10, Sag 10/ /132

71 er, at stamdata rummer felter, der overvejende vedligeholdes af DataHub'en og ikke udveksles i EDI-beskeder. F.eks. "Indsendte værdier skal tjekkes" som for Afregningsmålepunkter altid vil have værdien "Ja" og ikke skal vedligeholdes af netvirksomhederne. Måledata for målepunkter indsendes i form af tidsserier. Selve målingerne er ikke stamdata men til hvert sæt af målinger hører målingens stamdata, se entiteten Tidsseriedefinition. Igen er det vigtig at bemærke, at dette er den logiske model for tidsserier. Det der indsendes følger ikke præcist dette format. Se "Forretningsprocesser for det danske elmarked" bilaget med RSM'er (Requirements Specifications Mapping) herunder klassediagrammer. Cre ate Mete ring Point Stamdata[Tilslutnings status = 'Tilsluttet'] Stamdata[Tilslutnings status = 'Nyoprettet'] Destroy Metering Point Skift elleverandør Nyop rettet [Sidste registreret måling > x år] Tilflytning Stamdata[Tilslutnings status = 'Tilsluttet'] Stamdata Fraflytning Fraflytning Ne dlagt Stamdata[Tilslutnings status = 'Nedlagt'] Skift elleverandør Fraflytning Skift elleverandør T ilsluttet Afbrud t Ina ktivt Tilflytning Modtag måledata Tilflytning Åbn målepunkt Fraflytning Afbryd målepunkt Tilflytning Fraflytning Figur 6-2: Tilstandsdiagram for et Målepunkt Dok /10, Sag 10/ /132

72 Datavask DataHub'en skal, for at opfylde sit formål, som minimum kende alle elmålere (målepunkter) i Danmark identificeret ved et entydigt målepunkt ID (GSRN) på 18 cifre, deres forbrug og deres adresser. Yderligere skal alle afregningsmålere tilknyttes en disponent (kunde), som enten er en privat person eller en juridisk person (virksomheder). Disse kunder har selvsagt også en adresse. Kendskab til navn og adresse på nuværende og tidligere kunde er væsentlig i f.eks. flytteprocessen, hvor oplysninger, via DataHub'en, udveksles mellem elleverandør og netvirksomhed, der udsender aflæsningskort og slutopgørelser. Det er derfor af stor betydning for markedet generelt, at der kan ske en korrekt datavask. Bemærk: Som princip skal datafangst og validering ske hos de aktører, som har den daglige kontakt til kunderne, mens DataHub'en alene tilbyder hjælp til datavask. Datavasken skal altså ikke være en integreret del af alle udvekslinger af adresseoplysninger, men skal være en separat proces, som kan initieres af netvirksomheden eller elleverandøren, hvis og når det ønskes. Bemærk: At en given adresse oplyst af en kunde ikke kan valideres op i mod CVR / CPR betyder ikke nødvendigvis, at kundens oplysninger er forkerte. Der vil til stadighed være en gruppe af kunder / installationer, der er under flytning, har adresse i nyudstykninger, har tekniske adresser uden registrering i offentlige registre eller udenlandske adresser. DataHub'en skal også kunne håndtere sådanne adresser. DataHub'en har i datamodellen adresser opdelt som en sammensat type. Den følger i store træk formatet brugt i aws 6. Typen "Type sammensat adresse" rummer følgende felter - her sorteret alfabetisk: Bynavn Dørbetegnelse Etage GML point Husnummer Kommunekode Land Postboks Postdistrikt Postnummer Vejkode Vejnavn Attributterne er selvforklarende, måske bortset fra Postdistrikt - Bynavn og GML point. Postdistrikt svarer til, hvad almindelige brugere vil kalde navnet på byen, f.eks. svarer postnummer 7000 til postdistrikt Fredericia, mens Bynavn her er optionelt og svarer til bynavn2 (Snoghøj, 6 Adressewebservices Dok /10, Sag 10/ /132

73 7000 Fredericia). GML point, skal bruges til udpegning af adressen på et kort og er reserveret til fremtidigt brug. I forbindelse med EDIFACT findes også et format Kodetadresse - se nærmere i "EDI transaktioner for det danske elmarked" et bilag til "Forretningsprocesser for det danske elmarked" Adresser på installationer En installation (~et målepunkt) har en adresse af typen "Type sammensat adresse", og netvirksomhederne skal, efter behov, kunne datavaske disse adresser ved hjælp af DataHub'en. Bl.a. vejkode. Bemærk dog at netvirksomhederne kan have mange målepunkter oprettet på veje uden vejkoder tilknyttet i forbindelse med nyudstykninger og lignende Adresser for private kunder DataHub'en har felterne navn, adresse og evt. fødselsdato. Disse felter skal netvirksomhederne efter behov kunne datavaske på ved hjælp af DataHub'en op i mod CPR / aws eller tilsvarende. Når aktørerne engang i fremtiden er klar til at håndtere entydig identifikation af private, skal det ske via en model, hvor CPR ikke udveksles, men kun PID (Personligt ID) numre. DataHub'en er den eneste, der vil kende sammenhængen mellem CPR og PID. På basis af navn, adresse og evt. fødselsdato finder DataHub'en den eller de personer i CPR der matcher, netvirksomheden / elleverandøren godkender, at det er den kunde, der er identificeret, og DataHub'en udleverer et PID, som fremover benyttes som entydig identifikation af kunden. Fuldt gennemført vil det overflødiggøre webadgangskoder som stamdata på et målepunkt, give bedre muligheder for datavask og vil samtidig kunne give langt højere kvalitet i forbindelse med mange af processerne, f.eks. flytninger Adresser og CVR for virksomheder Datavask af adresser er et tilbud til aktørerne. Datavasken skal ske op mod CVR 7 / aws eller tilsvarende. Der skal også ske en validering af CVR Adgang til stamdata via webportal Målepunkter I datamodellen fremgår hvilke stamdata, der findes på et målepunkt, og de skal alle være mulige at fremfinde via en webform. Nedenstående figur viser en råskitse til opbygningen funktionaliteten af denne webform: 7 CVR - Forside, Dok /10, Sag 10/ /132

74 Søgekriterier Resultatliste Detailoplysninger Figur 6-3: Eks. på visning af stamdata for målepunkt. Ovenstående viser et eksempel på, hvorledes visning af stamdata for målepunkter kunne se ud. Figuren er baseret på skærmdumps fra Energinet.dk's Selvbetjeningsportal, med stamdata for produktionsanlæg. I den første webform "Søgekriterier" (øverst) angives søgekriterier for de målepunkter, man ønsker at se. Der skal være valglister, eller søgningerne skal kunne foretages med wildcard. Hvilke felter der skal være mulige at søge på, er afhængig af hvilke rettigheder brugeren som kalder webformen, har. Efter fremsøgningen vises søgeresultatet i en "Resultatliste", hvor der kun vises udvalgte felter af stamdata. Brugeren skal selv kunne vælge hvilke felter, der vises i listen. Der skal kun kunne vælges felter, som brugeren har ret til at se, f.eks. skal en bruger hos en netvirksomhed ikke kunne se feltet "elleverandør". Ved klik på et målepunkt, skal der linkes til en ny webform ("Detailoplysninger"), der viser alle detailinformationer for målepunktets stamdata, herunder også historik for disse. Fra "Resultatliste" skal det også være muligt at linke til en ny webform, hvor målepunktets måledata for en given periode vises. Dok /10, Sag 10/ /132

75 Netvirksomheder og netområder Området er reguleret, idet man skal have bevilling fra Energistyrelsen til at drive netvirksomhed. De nuværende manuelle procedurer for at udstede disse tilladelser forventes opretholdt. Danmark er opdelt i ca. 85 geografiske netområder, og hvert netområde ejes af en netvirksomhed. Nogle netvirksomheder ejer mere end et netområde. Udviklingen i antallet af netvirksomheder går mod færre netvirksomheder, altså mod konsolidering. Antallet af netvirksomheder er lidt lavere end antallet af netområder. Det vurderes, at det ikke kan svare sig at lave strukturerede beskeder til ændringer af stamdata for disse entiteter. DataHub'en skal have skærmbilleder under den generelle webportal, som kan varetage CRUDfunktioner for disse entiteter. Både netvirksomhederne og DataHub'en skal kunne varetage vedligehold af disse entiteter. Den endelige fordeling af, hvilke attributter der kan/må vedligeholdes af hhv. netvirksomheden og DataHub'en, udestår Elleverandører Området er reguleret, idet man fremover skal have tilladelse fra Energinet.dk til at drive elhandel. De nuværende manuelle procedurer for at udstede disse tilladelser forventes opretholdt. Det er svært at sige noget om udviklingen i antallet af elleverandører, men der vil nok ske en svag vækst. Det vurderes, at det ikke kan svare sig at lave strukturerede beskeder til ændringer af stamdata for denne entitet. DataHub'en skal have skærmbilleder under den generelle webportal, som kan varetage CRUDfunktioner for denne entitet. Både elleverandøren og DataHub'en skal kunne varetage vedligehold af denne entitet. Den endelige fordeling af, hvilke attributter der kan/må vedligeholdes af hhv. elleverandøren og DataHub'en, udestår Balanceansvarlige Området er reguleret, idet man skal tegne kontrakt med Energinet.dk for at varetage balanceansvar. De nuværende manuelle procedurer for at udstede disse tilladelser forventes opretholdt. Antallet af aktive balanceansvarlige virksomheder i Danmark er ca. 50 og udviklingen er det svært at spå om, men der vil nok ske en svag reduktion af antallet pga. konsolidering. Det vurderes, at det ikke kan svare sig, at lave strukturerede beskeder til ændringer af stamdata for denne entitet. Dok /10, Sag 10/ /132

76 6.3.3 Stamdata kravtabel Krav Kravtype Kravtitel Kravbeskrivelse MK/K/O K Webforms til stamdata for målepunkter Der skal i webportalen findes skærmbilleder, så markedets aktører og kunder selv kan se og vedligeholde relevante stamdata for målepunkter. Netvirksomheder skal kunne oprette og redigere stamdata for målepunkter tilhørende netvirksomheden. Elleverandører skal kunne søge overordnede stamdata for alle målepunkter, og skal kunne se detailinformation for egne målepunkter K Webapplikation til stamdata for målepunkter Elkunder skal kunne søge overordnede stamdata for egne målepunkter, og skal kunne se detailinformation for disse. DataHub'en skal tilbyde en webapplikation, således at kunder på elleverandørens portal tilbydes ovennævnte funktionalitet K Elleverandør krav til webform til målepunktsstamdata Elleverandøren skal via webforms specifikt kunne: Hente aftagenummer på indflytters kommende målepunkt ved søgning på målepunktets adresse Sortere målepunkter efter CVR-nummer (dette vil vise alle målepunkter for en koncernkunde) K Kundens krav til webadgang til målepunktsstamdata Kunden skal specifikt kunne se: - detaljerede stamdata for alle kundens målepunkter. - tidligere og kommende leverandørskift på alle kundens målepunkter. - kontaktinformation for netvirksomhed og elleverandør(er) for alle kundens målepunkter DataHub'en skal tilbyde en webapplikation, således at kunder på elleverandørens portal tilbydes ovennævnte funktionalitet. Dok /10, Sag 10/ /132

77 Krav Kravtype Kravtitel Kravbeskrivelse MK/K/O K Webforms til opdatering af stamdata for aktører Der skal i webportalen findes skærmbilleder, så markedets aktører (elleverandører, netvirksomheder, balanceansvarlige) selv kan vedligeholde egne relevante stamdata, iflg. Figur 6-1: Samlet logisk datamodel K Offentlige aktøroplysninger (aktørstamdataregister) Der skal på webportalens offentlige del, vises en oversigt over markedets aktører. Her skal vises udvalgte felter fra stamdata, f.eks. Navn, rolle, GLN/EIC nummer, kontaktoplysninger (adresse, , tlf.) o.l MK Datavask af adresser for målepunkter, private og virksomheder Datafangst og validering sker hos de selskaber som har direkte kontakt til kunderne, mens DataHub'en tilbyder hjælp til datavask. Datavasken skal altså ikke være en integreret del af alle udvekslinger af adresseoplysninger, men skal være en separat proces som kan initieres af netvirksomheden eller elleverandøren, hvis og når det ønskes. Datavasken skal foretages mod offentlige registre: CVR, CPR, Adressewebservice el.lign. Resultatet af datavasken skal være en differensliste, der viser de registrerede data i DataHub'en og differensen med det offentlige register K Udbygning af datavaskfunktionalitet Kravene til funktionaliteten i datavask forventes at øges efter idriftsættelsen af systemet, og det er derfor vigtigt at designet af datavasken er forberedt til en senere udvidet funktionalitet MK Brug af CVR til identifikation af virksomheder Pga. den måde hvorpå datafangst sker hos netvirksomhederne, kan der ikke opnås dækkende identifikation af virksomheder baseret på CVR, men som minimum skal DataHub'en kunne afgøre, om et CVR nummer tilhører en eksisterende virksomhed K Brug af PID til entydig identifikation af private DataHub'en skal være forberedt på brug af PID til private kunder. Virksomheder identificeres ved hjælp af CVR. Når aktørerne er klar til at håndtere entydig identifikation af private, skal det ske via en model, hvor CPR ikke udveksles, men kun PID numre. DataHub'en er den eneste, Dok /10, Sag 10/ /132

78 Krav Kravtype Kravtitel Kravbeskrivelse MK/K/O der kender sammenhængen mellem CPR og PID K Brug af geografiske koordinater i adresser Datamodellen rummer en attribut, GML point, der pt. ikke skal indsendes af aktørerne. Det er ikke vigtigt, at det præcist er GML point der anvendes, men DataHub'en skal kunne håndtere geografiske angivelser i fremtiden. Tabel 6-2: Stamdata - kravtabel 6.4 Måledata Den største transaktionsmængde og den største datamængde i DataHub'en vedrører måledata. Det er netvirksomhederne, der har dataansvaret for måledata, og pseudo-forskrift D1 beskriver roller, ansvar, pligter og processer vedrørende måledata. Når måledata er modtaget i DataHub'en fra netvirksomhederne, skal forbrugs- og produktionsmåledata videresendes til de relevante elleverandører. Netvirksomhederne skal via webportalen kunne definere simple beregningsoperationer, der skal foretages på de indsendte målinger, inden målingerne indgår i afregningen. Dette er beskrevet som virtuelle målepunkter i pseudo-forskrift D1. DataHub'en skal foretage simple beregninger på måledata, f.eks. summering pr. elleverandør, og beregningsresultatet skal udsendes til relevante aktører, f.eks. en balanceansvarlig. Af mere specielle beregninger, skal DataHub'en beregne andelstal, og saldoafregningen skal ligeledes foretages i DataHub'en. Saldoafregningen er beskrevet i pseudo-forskrift H2. Endelig skal DataHub'en beregne KPI'er for måledata, hvor der skal måles på kvaliteten af de indsendte målinger, dvs. overholdelse af tidsfrister for indsendelser og korrektioner til indsendte målinger. Bemærk, at der i daglig tale bruges betegnelserne tidsseriedata og måledata om samme begreb, og at måledata både kan være direkte målte værdier eller resultatet af en beregning. Måledata kan dække over energimålinger (kwh, MWh), effektmålinger (kw, MW) eller reaktive energimålinger (kvarh, MVArh), og tidsseriedata kan indeholde priser (øre/kwh, DKK/MWh, NOK/MWh osv.) Adgang til måledata via webportal Brugeren må kun kunne se måledata, som vedkommende er legitim berettiget til. F.eks. må en elleverandør kun se måledata for de målepunkter, han er elleverandør for, og kun for den perio- Dok /10, Sag 10/ /132

79 de hvor elleverandøren har haft leverance til kunden (bortset fra i tilbudsfasen, hvor man kan få historiske måledata). Hvilke(t) målepunkt(er) der skal vises data for, kan f.eks. vælges via en webform, som vist i afsnit Der skal kunne vælges at se måledata for et eller flere målepunkter ud fra søgeresultatet. F.eks. ved at vælge én, flere eller alle målepunkter ved hjælp af valgbokse. Værdierne, der vises for et målepunkt, kan være resultatet af en beregning (virtuelt målepunkt). I webformen for måledata skal der som minimum kunne vælges: Periode, der skal vises måledata for Tidsopløsning - skal data vises i 5 minutters-, kvarters-, times- eller måneds opløsning eller summeret pr. døgn, uge, måned eller år. Målingens aktuelle tidsopløsning vises som default. Måledata for 2 målepunkter Figur 6-4: Eksempel på visning af tidsseriedata Ovenstående er et eksempel på, hvorledes visning af tidsseriedata for 2 målepunkter kunne se ud. (Figuren er baseret på skærmdump fra Energinet.dk's Panda system) Send måledata til tredje part Når en kunde har fremsøgt sine måledata for egne målepunkter, skal der være en let adgang til at sende de fremsøgte data til tredje part. Formålet er, at kunden kan fremsende sine måledata til f.eks. en energirådgiver for analyse af elforbruget Måledata kravtabel Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O Dok /10, Sag 10/ /132

80 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O K Daglig modtagelse og kontrol af kvarters- og timeregistrerede måledata DataHub'en skal dagligt modtage kvarters- og timeregistrerede data, og udføre kontrol af modtagne data som beskrevet i pseudo-forskrift D1, afsnit K Modtagelse og kontrol af registreringer fra skabelonafregnede forbrugsmålinger. DataHub'en skal modtage og kontrollere registreringer fra skabelonafregnede forbrugsmålepunkter, som beskrevet i pseudo-forskrift D1, afsnit K Modtagelse og kontrol af måledata for måneds- og kvartalsaflæst produktion DataHub'en skal modtage og kontrollere måledata for måneds- og kvartalsaflæste produktionsanlæg, som beskrevet i pseudo-forskrift D1, afsnit MK Historik for måledata Ved genindsendelse af måledata, skal tidligere data gemmes og disse skal kunne fremfindes. Der skal således være fuld historik (revisionsspor) på alle transaktioner, der vedrører måledata K Fiksering og refiksering af måledata Som beskrevet i pseudo-forskrift D1 (afsnit 4.3), skal DataHub'en på 5.dagen efter driftsdøgnet fiksere (fastfryse) måledata, og efter 3 måneder foretage en refiksering (se pseudo-forskrift D1, afsnit 4.5.1). DataHub'en skal kunne håndtere disse processer K Håndtering af åbne og lukkede systemer Aktørerne kan vælge at modtage korrektioner på måledata (åben), eller alternativt at modtage mail fra DataHub'en om korrektioner (lukket), som beskrevet i pseudo-forskrift D1, afsnit DataHub'en skal kunne håndtere disse processer K Rykkere og fejlrapporter DataHub'en skal som beskrevet i pseudo-forskrift D1, bilag 3, danne og udsende rykkere og fejlrapporter under hensyntagen til de muligheder aktøren har for styring af dette, beskrevet i pseudo-forskrift D1, afsnit K Bestilling af manglende målinger Som beskrevet i pseudo-forskrift D1, afsnit og skal aktørerne via webportalen Dok /10, Sag 10/ /132

81 Krav ID Kravtype Kravtitel Kravbeskrivelse MK/K/O kunne bestille genfremsendelse af målinger. Bestillingsskærmbilledet skal tilbyde en let fremsøgning/gruppering af målinger, bl.a. med mulighed for "marker alle" til genfremsendelsen K Webform til visning af måledata for aktører Systemet skal tilbyde en webform til visning af flere målinger, med en funktionalitet som skitseret i afsnit Webformen skal kunne tilbyde aktører en professionel tilgang til egne måledata K Webadgang til visning af måledata for kunder Kunden skal have mulighed for at se egne målinger, med en funktionalitet som skitseret i afsnit DataHub'en skal tilbyde en webapplikation, således at kunder på elleverandørens portal tilbydes ovennævnte funktionalitet K Afsendelse fra kunde af fremsøgte måledata Når en kunde har fremsøgt sine måledata, skal det være muligt for kunden at sende de fremsøgte data i en mail til en valgfri mailadresse. Måledata vedhæftes i mailen som en fil i regnearksformat, xml eller csv. Kunden skal have mulighed for at give en mailadresse hvortil data skal fremsendes, og der skal være mulighed for at medsende en tekst i mailen. DataHub'en skal tilbyde en webapplikation, således at kunder på elleverandørens portal tilbydes ovennævnte funktionalitet. Tabel 6-3: Måledata - kravtabel 6.5 Beregningsfunktion Statiske beregninger Nogle målinger skal der foretages beregninger på, inden de kan indgå i den videre afregning. Dok /10, Sag 10/ /132

82 Et eksempel på en sådan beregning, kan vises ved de målinger, der foretages ved et produktionsanlæg. Forbrugssted Kollektive forsyningsnet M3 M0 M1 Øvrigt forbrug ~ Egetforbrug til elproduktion Figur 6-5: Nettoafregnet produktionsanlæg Ved kunden måles M0, M1 og M3, som illustreret i Figur 6-5, og kundens forbrug skal beregnes som summen af M0+M1, og denne beregning skal defineres og foretages i DataHub'en. Beregningerne defineres og udføres på tidsserierne, og der vil være behov for at kunne udføre nedenstående beregningsfunktioner, beskrevet i Tabel 6-4: Beregningsfunktioner. Argumenterne til en beregningsfunktion kan enten være to tidsserier (x og y), en tidsserie (x) og resultatet fra en anden beregning (y), eller en tidsserie (x) og en konstant defineret værdi (y). Beregningerne skal altid udføres for hvert element (tidsstempel) i tidsserierne. F.eks. skal "Multiplicer" funktionen udført på to timestidsserier for et døgn, multiplicere de 2 x 24 timesværdier, og ikke multiplicere de to tidsseriers døgnsummer. Funktion Beskrivelse Adder(x,y) Adder værdierne i x med værdierne i y Subtraher(x,y) Subtraher værdierne i x med værdierne i y Multiplicer(x,y) Mulitiplicer værdierne i x med værdierne i y Divider(x,y) Divider værdierne i x med værdierne i y Størst(x,y) Der vælges den største værdi af x eller y Mindst(x,y) Der vælges den mindste værdi af x eller y Afrund(x,k) Afrund x til k antal decimaler Absolut(x) Absolut af værdien x Dok /10, Sag 10/ /132

83 Funktion Beskrivelse Tærskel indenfor(x,k1,k2) Værdien x vælges, hvis denne ligger indenfor det interval der er angivet i k1 og k2 - ellers sættes værdien til nul. Tærskel udenfor(x,k1,k2) Værdien x vælges, hvis denne ligger udenfor det interval der er angivet i k1 og k2 - ellers sættes værdien til nul. Tabel 6-4: Beregningsfunktioner Definition af formler skal kunne gøres af Energinet.dk og af brugere hos netvirksomhederne Dynamiske beregninger Der skal også være mulighed for at definere mere dynamiske beregninger. F.eks. skal man kunne opsætte en beregning med: "summér alt forbrug i netområde A som er tilknyttet elleverandør B". En sådan beregning skal ud fra stamdata på de enkelte målepunkter udlede, hvilke af disse målepunkter, der skal indgå i beregningen. Beregningen skal naturligvis tage hensyn til, at stamdata for de enkelte målepunkter varierer over tid Automatisk beregning - nettoafregnede værker For de såkaldte nettoafregnede produktionsanlæg, skal DataHub'en ud fra de modtagne målinger på et sådant anlæg, benævnt M1, M2 og M3, beregne målingerne "Produktion MP" og "Forbrug MP", som skal indgå i afregningen. Beregningerne kan opsættes manuelt som formler (statiske beregninger), men der ønskes belyst muligheden for, at DataHub'en udfører en automatisk beregning, da beregningsformlerne kan udledes af stamdata for målepunkterne. Nedenfor vises en sammenhæng mellem stamdata for målepunkterne, og hvorledes "Produktion MP" og "Forbrug MP" beregnes. En fuldstændig beskrivelse af principperne bag nettoafregningsmodellen kan ses i bilag til forskrift E: "Retningslinjer for nettoafregning af egenproducenter". Gruppe Installations form Tidsopløsning M1 M2 M3(+M0) Produktion MP Forbrug MP Egenproduktion EP Grp. 1 Grp. 2 Installationstilsluttet X X X M1 M1-M2+M3 M1-pos(M2-M3) Time Direkte X X M1 M3 M1-pos(M1-M3) Installationstilsluttet X X X pos(m2-m3) -1*neg(M2-M3) M1-pos(M2-M3) Time Direkte X X pos(m1-m3) -1*neg(M1-M3) M1-pos(M1-M3) Grp. 4 Grp. 5 Grp. 6 Installationstilsluttet Installationstilsluttet Installationstilsluttet Time Time Årsafregnet X X X X X X X X X M2 - pos(m2-m3) M3 M3-1*neg(M2-M3) M1-M2 M1-M2 M1-pos(M2-M3) X X X X X X M2 - pos(m2-m3) M3 M3-1*neg(M2-M3) Bemærk: M1 og M2 målerne kan være måneds/kvartalsaflæste, men indgår med timesværdier via Energinet.dk's estimater. I nettoafregningsgruppe 4 og 5 må M3 måleren gerne være skabelonafregnet, da den ikke indgår i beregningen af egenproduktionen. Nettoafregningsgruppe 6 skal måske udvides med en model for timesafregnede kunder (er under udvikling) Figur 6-6: Sammenhæng mellem stamdata for målepunkterne, nettoafregning Dok /10, Sag 10/ /132

84 6.5.4 Beregningsfunktion kravtabel Krav Krav- Kravtitel Kravbeskrivelse ID type MK/K/ O K Statiske beregninger på måledata Der skal findes mulighed for at definere beregninger på måledata med matematiske funktioner som beskrevet i afsnit K Periodisering af beregningsdefinitioner Det skal være muligt at definere periodiseringer i forbindelse med beregningsdefinitionen. F.eks. at et formelled i beregningen ikke skal være gyldigt efter et givet tidspunkt K Dynamiske beregninger på måledata Det skal være muligt at definere dynamiske beregninger som f.eks. : "summér alt forbrug i netområde A som er tilknyttet elleverandør B", som beskrevet i afsnit K Webform til beregningsdefinitioner Der skal findes en webform, som på en logisk og overskuelig form kan anvendes til opsætning af beregningsdefinitioner. Formen skal tage hensyn til rettigheder, således at f.eks. en netvirksomhed kun kan medtage målinger i beregningen, som netvirksomheden har ansvaret for K Definition af formler Definition af formler skal kunne defineres af Energinet.dk og af brugere hos netvirksomhederne K Automatisk beregning for nettoafregnede anlæg Der skal beskrives en løsning for automatisk beregning af forbrug og produktion for nettoafregnede anlæg, iflg. beskrivelse i afsnit Tabel 6-5: Beregningsfunktion - kravtabel 6.6 Beregning af residualforbrug, andelstal, fordelte forbrug og saldoafregning I pseudo-forskrift H2 er beskrevet principper og procedurer for beregning af residualforbrug, fordelte forbrug, andelstal samt hvorledes saldoafregning skal udføres. Dok /10, Sag 10/ /132

85 Residualforbruget pr. netområde beregnes på timebasis, og er i princippet det forbrug i netområdet, der ikke er timemålt: Residualforbrug = total forbrug minus timemålt forbrug. Det beregnede residualforbrug (fikseret og refikseret) skal offentliggøres på den offentlige del af webportalen. Figur 6-7: Eksempel på offentliggørelse af residualforbrug. Ovenstående figur viser et eksempel på offentliggørelse af residualforbrug fra Energinet.dk's nuværende Selvbetjeningsløsning. Andelstalsberegningen vedrører udelukkende skabelonafregnede målepunkter og beregner i princippet andelen af skabelonafregnet forbrug, som hver elleverandør har i hvert netområde. De beregnede andelstal udsendes til markedets aktører, som beskrevet i forretningsproces "BRS-022: Fremsendelse af andelstal". Saldoafregningen korrigerer afregningerne mellem elleverandørerne, når den endelige aflæsning fra kunderne er modtaget og hermed erstatter de skønnede værdier. Saldoafregningen er en omfordeling af beløb mellem elleverandørerne. Beregningsresultatet vil være en opgørelse pr. elleverandør, som vil medføre en opkrævning/udbetaling til den enkelte elleverandør, og summen af alle opkrævninger og udbetalinger vil være nul. DataHub'en skal foretage beløbs beregningen og overføre posteringerne (betaling/opkrævning) til Energinet.dk's SAP system via en eksisterende webservice. SAP systemet vil udskrive den endelige faktura/kreditnota til elleverandørerne. Dok /10, Sag 10/ /132

Introduktion til DataHub projekt

Introduktion til DataHub projekt Introduktion til DataHub projekt Rev. 1 6/4-2010 20/4-2010 DATE JGR MBN NAME REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED 20203-10 Energinet.dk Doc. no. DATE NAME Dok. 20203/10, Sag 10/3365 1/11

Læs mere

DataHub. Kraft i Vest. 27. September 2013. John Griem, Energinet.dk

DataHub. Kraft i Vest. 27. September 2013. John Griem, Energinet.dk DataHub Kraft i Vest 27. September 2013 John Griem, Energinet.dk Overblik Om Energinet.dk Baggrund for at lave en DataHub DataHub ens funktionalitet Engrosmodellen Fakta om Energinet.dk Selvstændig, offentlig

Læs mere

Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation

Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation Til Energitilsynet Metodeanmeldelse af markedsforskrift F1 - EDIkommunikation med DataHub'en i elmarkedet 31. januar 2012 HBK/LRP Energinet.dk skal i følge Energistyrelsens bekendtgørelse nr. 1085 af 20.

Læs mere

Pseudo-forskrift H3: Afregning af engrosydelser og afgiftsforhold. Træder i kraft den 1.10.2014. Maj 2013. Rev. 1.0 2013 DATE. Energinet.

Pseudo-forskrift H3: Afregning af engrosydelser og afgiftsforhold. Træder i kraft den 1.10.2014. Maj 2013. Rev. 1.0 2013 DATE. Energinet. Pseudo-forskrift H3: Afregning af engrosydelser og afgiftsforhold Maj 2013 Rev. 1.0 Træder i kraft den 1.10.2014 2013 DATE NAME DATE NAME REV. DESCRIPTION PREPARED Energinet.dk 16954/11. Dok. 129089-13,

Læs mere

De nye markedsregler er beskrevet i pseudo-forskrifter og andre dokumenter. Hele samlingen af dokumenter kan findes under De nye markedsregler.

De nye markedsregler er beskrevet i pseudo-forskrifter og andre dokumenter. Hele samlingen af dokumenter kan findes under De nye markedsregler. DataHub I sommeren 2009 startede vi på baggrund af Klima- og Energiminsiterens beslutning projektet i samarbejde med repræsentativt udvalgte aktører fra det danske elmarked. I April 2012 er det planen,

Læs mere

Medlemsstater - Tjenesteydelseskontrakt - Udbudsbekendtgørelse - Udbud efter forhandling

Medlemsstater - Tjenesteydelseskontrakt - Udbudsbekendtgørelse - Udbud efter forhandling 1/5 Denne bekendtgørelse på TED-webstedet: http://ted.europa.eu/udl?uri=ted:notice:146924-2010:text:da:html DK-Fredericia: It-tjenester: rådgivning, programmeludvikling, internet og support 2010/S 97-146924

Læs mere

BILAG 6. DataHub- og markedsrapportering. 1. Markedsoverblik. 1.1 Leverandørskift. Direktørgruppen. 11. februar 2015 MLN

BILAG 6. DataHub- og markedsrapportering. 1. Markedsoverblik. 1.1 Leverandørskift. Direktørgruppen. 11. februar 2015 MLN BILAG 6 Til Direktørgruppen DataHub- og markedsrapportering 11. februar 2015 MLN Dette notat udgør statusrapporteringen for DataHub drift til Direktørgruppen i februar 2015. Notatet indeholder et generelt

Læs mere

E2E DATAHUB ENGROSMODEL, TESTDREJEBOG

E2E DATAHUB ENGROSMODEL, TESTDREJEBOG E2E DATAHUB ENGROSMODEL, TESTDREJEBOG - BALANCEANSVARLIG 07. januar 2014 Version 0.2 Dok. xxxxx/yy, Sag yy/zzz 1/22 Indholdsfortegnelse 1. Dokumentinformation... 4 1.1 Versionsoversigt... 4 1.2 Reference

Læs mere

BILAG 5. DataHub- og markedsrapportering. 1. Markedsperformance. 1.1 Leverandørskift. Direktørgruppen. 10. juni 2014

BILAG 5. DataHub- og markedsrapportering. 1. Markedsperformance. 1.1 Leverandørskift. Direktørgruppen. 10. juni 2014 BILAG 5 Til Direktørgruppen DataHub- og markedsrapportering 10. juni 2014 Der fremsendes forud for hvert møde i Direktørgruppen en statusrapport, der rapporterer på net- og elhandelsvirksomhedernes performance,

Læs mere

Forskrift H1: Skift af elleverandør, flytning mv. 14/22729-6. Træder i kraft 1. oktober 2015. September 2014. Version 6.7

Forskrift H1: Skift af elleverandør, flytning mv. 14/22729-6. Træder i kraft 1. oktober 2015. September 2014. Version 6.7 Forskrift H1: Skift af elleverandør, flytning mv. September 2014 Version 6.7 Træder i kraft 1. oktober 2015 Sep. 2014 Sep. 2014 Sep. 2014 DATE HBK HLJ SHR NAME REV. DESCRIPTION PREPARED REVIEWED APPROVED

Læs mere

Forretningsprocesser for det danske elmarked. (EDI guide - BRS'ere)

Forretningsprocesser for det danske elmarked. (EDI guide - BRS'ere) Forretningsprocesser for det danske elmarked (EDI guide - BRS'ere) 02. September 2013 Final Draft Version 3.0 DATE NAME DATE NAME DATE NAME DATE REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED XXXXX-XX

Læs mere

Forskrift G - Diskretionspolitik og procedurer omkring datasikkerhed

Forskrift G - Diskretionspolitik og procedurer omkring datasikkerhed Forskrift G - Diskretionspolitik og procedurer omkring datasikkerhed December 2007 Rev. 1 Nov. 2006 Nov. 2006 Jan. 2007 Jan. 2007 DATE LEG BCM/MRP LEG LSO NAME Nov. 2006 DATE HEP/LEG NAME REV. DESCRIPTION

Læs mere

Forskrift H1: Skift af elleverandør 38472-08. Oktober 2008. Version 4.1. Feb. 2008 Aug. 2008 Aug. 2008 Okt. 2008 MRP LRO LRO MRP NAME. Energinet.

Forskrift H1: Skift af elleverandør 38472-08. Oktober 2008. Version 4.1. Feb. 2008 Aug. 2008 Aug. 2008 Okt. 2008 MRP LRO LRO MRP NAME. Energinet. Forskrift H1: Skift af elleverandør Oktober 2008 Version 4.1 Feb. 2008 Aug. 2008 Aug. 2008 Okt. 2008 DATE MRP LRO LRO MRP NAME REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED 38472-08 DOC. NO. DATE

Læs mere

Træder i kraft den 1.3.2013

Træder i kraft den 1.3.2013 Forskrift H2: Skabelonafregning mv. August 2012 Rev. 4.1 Træder i kraft den 1.3.2013 2010 Jun. 2011 Okt. 2011 Okt. 2011 DATE PHQ JHH HBK PHQ NAME Jan. 2012 Jan. 2012 Jan. 2012 Jan 20.12 DATE PHQ PHQ HBK

Læs mere

DataHub hvad er projektets formål?

DataHub hvad er projektets formål? DataHub hvad er projektets formål? Morten Braae Nielsen Afregningschef - El, Elmarked Telefon: +45 7622 4304 Mobil: +45 2333 8509 E-mail: mbn@energinet.dk 1 Problematikker i det danske detailmarked - der

Læs mere

2.1 Brugervenlighed i betjening af opladning. 2.2 Opladningstid. 2.3 Åbne og internationalt standardiserede løsninger

2.1 Brugervenlighed i betjening af opladning. 2.2 Opladningstid. 2.3 Åbne og internationalt standardiserede løsninger Notat Aspekter vedr. krav til elbil ladeinfrastruktur 29. september 2010 ABH/ LRO 1. Baggrund Det vurderes, at en god ladeinfrastruktur i det offentlige rum er værdifuldt for at understøtte en udbredelse

Læs mere

Engrosmodellen. Dialogforum 17-12-2014 14/15485-20 17-12-2014 1

Engrosmodellen. Dialogforum 17-12-2014 14/15485-20 17-12-2014 1 Engrosmodellen Dialogforum 17-12-2014 17-12-2014 1 Agenda 1. Referat fra sidste møde 2. Kort status på projektet 3. Status på love og bekendtgørelser 4. Tilbagemelding fra teknik- og implementeringsgruppens

Læs mere

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang

Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang Udkast til dataudveksling med elleverandører og andre tredjeparter via kundestyret dataadgang 29.04.2015 USS/XSTJ Version 1.3 1. Indledning... 2 2. Proces for kundestyret dataadgang... 2 2.1 Fuldmagtsgivning

Læs mere

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12

Oktober 2013 HLG/XIGA. Opstartsvejledning ATS Engros 1/12 Oktober 2013 HLG/XIGA Opstartsvejledning ATS Engros 1/12 1. ATS Engros vejledning for aktører Formålet med dette dokument er at beskrive, hvordan du kommer i gang med at anvende ATS til test af certifikat

Læs mere

Forskrift A: Principper for elmarkedet

Forskrift A: Principper for elmarkedet Forskrift A: Principper for elmarkedet December 2007 Rev. 1 Juni 2006 Nov. 2006 Jan. 2007 Jan. 2007 DATE LEG/MRP LEG/MRP LEG LSO NAME Sep./Okt. 2006 LEG/MRP REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED

Læs mere

Metodeanmeldelse af forskrift H3: Afregning af engrosydelser

Metodeanmeldelse af forskrift H3: Afregning af engrosydelser Til Sekretariatet for Energitilsynet USS/SHR 4. september 2014 Metodeanmeldelse af forskrift H3: Afregning af engrosydelser og afgiftsforhold Energinet.dk skal ifølge Bekendtgørelse om netvirksomheders,

Læs mere

Metodeanmeldelse af forskrift H1: Skift af elleverandør,

Metodeanmeldelse af forskrift H1: Skift af elleverandør, Til Sekretariatet for Energitilsynet Metodeanmeldelse af forskrift H1: Skift af elleverandør, flytning mv. HBK/SHR 4. september 2014 Energinet.dk skal ifølge Bekendtgørelse om netvirksomheders, regionale

Læs mere

Metodeanmeldelse af markedsforskrift F1 EDIkommunikation

Metodeanmeldelse af markedsforskrift F1 EDIkommunikation Til Energitilsynet Metodeanmeldelse af markedsforskrift F1 EDIkommunikation med DataHub i elmarkedet Juni 2014 HBK/ADA Energinet.dk skal ifølge Energistyrelsens bekendtgørelse nr. 1085 af 20. september

Læs mere

Introduktion til Engrosmodellen

Introduktion til Engrosmodellen Introduktion til Engrosmodellen Juni 2013 Dato - Dok.nr. 1 Intentioner med Engrosmodellen (Uddrag fra bemærkninger til lovforslaget fremsat 25. april 2012, gennemført ved LOV nr 575 af 18/06/2012) forbrugerne

Læs mere

Notat med høringssvar i forbindelse med høring af afsnit 5 i forskrift H1.

Notat med høringssvar i forbindelse med høring af afsnit 5 i forskrift H1. Til Netvirksomheder, elleverandører, balanceansvarlige og øvrige parter 1 Notat med høringssvar i forbindelse med høring af afsnit 5 i forskrift H1. 04. januar 2013 JOG/JOG Energinet.dk gennemførte en

Læs mere

Engrosmodellen. Dialogforum 25-06-2015 14/15485-39 24-06-2015 1

Engrosmodellen. Dialogforum 25-06-2015 14/15485-39 24-06-2015 1 Engrosmodellen Dialogforum 25-06-2015 14/15485-39 24-06-2015 1 Agenda 1. Referat fra sidste møde 2. Status projektet i almindelighed 3. Tilbagemelding fra den koordinerende styregruppe 4. Opfølgning på

Læs mere

Vilkår for deltagelse i DataHub'en ELLEVERANDØR FORBRUG

Vilkår for deltagelse i DataHub'en ELLEVERANDØR FORBRUG Vilkår for deltagelse i DataHub'en ELLEVERANDØR FORBRUG mellem 18. september 2012 LRO/HSF Energinet.dk Tonne Kjærsvej 65 7000 Fredericia Som systemansvarlig operatør i Danmark med pligt til etablering

Læs mere

Den danske rollemodel

Den danske rollemodel Forskrift F: EDI-kommunikation Bilagsrapport 3: Den danske rollemodel November 20 Rev. 2 Dok. løbenr. 79843-07_v2 /2 Indholdsfortegnelse. Den danske rollemodel... 3 2. Oversættelse af roller til dansk...

Læs mere

Engrosmodellen. Udkast til overordnet tidsplan Dialogforum 8-1-2014 2014-01-08 13/81118-36 1

Engrosmodellen. Udkast til overordnet tidsplan Dialogforum 8-1-2014 2014-01-08 13/81118-36 1 Engrosmodellen Udkast til overordnet tidsplan Dialogforum 8-1-2014 2014-01-08 13/81118-36 1 Hvad skal vi opnå med udsættelsen af projektet! At implementere de nye regler omkring forsyningspligt og evt.

Læs mere

Kompensation til havvindmølleparker ved påbudt nedregulering

Kompensation til havvindmølleparker ved påbudt nedregulering Til Produktionsbalanceansvarlige aktører m.fl. 8. januar 2014 HEP-KDJ/HEP Kompensation til havvindmølleparker ved påbudt nedregulering Version 2.0 af 8. januar 2014 Dok. 13/91893-57 1/9 Indholdsfortegnelse:

Læs mere

DataHub Dialogforum Planlægningsmøde

DataHub Dialogforum Planlægningsmøde DataHub Dialogforum Planlægningsmøde Tid Onsdag den 6. juni 2012 Sted Energinet.dk, Tonne Kjærsvej 65, 7000 Fredericia Deltagere Henrik Hornum (Dansk Energi) Poul Berthelsen (NRGi) Niels Toftensberg (DONG

Læs mere

Engrosmodellen. Teknik- og implementeringsgruppen. Møde 21 16. april 2015. 16-04-2015 Dok.nr.: 14/15488-40 1

Engrosmodellen. Teknik- og implementeringsgruppen. Møde 21 16. april 2015. 16-04-2015 Dok.nr.: 14/15488-40 1 Engrosmodellen Teknik- og implementeringsgruppen Møde 21 16. april 2015 1 Agenda 1. Referat fra sidste møde 2. Status projektet i almindelighed 3. Status E2E-test 4. Status datamigrering 5. Håndtering

Læs mere

Engrosmodel. Status for engrosmodel og konkurrencen i detailmarkedet for el. Signe Horn Rosted, Afdelingsleder i Energinet.dk

Engrosmodel. Status for engrosmodel og konkurrencen i detailmarkedet for el. Signe Horn Rosted, Afdelingsleder i Energinet.dk Engrosmodel Status for engrosmodel og konkurrencen i detailmarkedet for el Signe Horn Rosted, Afdelingsleder i Energinet.dk 1 Om Energinet.dk 09-09-2015 Energinet.dk 2 Om Energinet.dk 09-09-2015 Energinet.dk

Læs mere

Vejledning i forhold til nettilslutningen af et solcelleanlæg. Version 60 MW pulje 19. marts 2015

Vejledning i forhold til nettilslutningen af et solcelleanlæg. Version 60 MW pulje 19. marts 2015 Formål. Med hæftet Nettilslutning af solcelleanlæg ønsker Dansk Solcelleforening, TEKNIQ og Dansk Energi at give en samlet oversigt over administrative krav og regler m.m. som gælder for nettilslutning

Læs mere

Forbruger login med NemID Til forbrugsdata på DataHub

Forbruger login med NemID Til forbrugsdata på DataHub Forbruger login med NemID Til forbrugsdata på DataHub 2. maj 2012 JHH Testdrejebog Udført for: Energinet Tonne Kjærsvej 65 7000 Fredericia Steen Jungdal Udført af: Signaturgruppen A/S IT-huset Åbogade

Læs mere

Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test

Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test Teststrategi for DataHub Engrosmodellen End-to-End (E2E) test Et overblik over metode og proces Version 2.0, maj 2015 Maj 2015, dok.nr. 13-100790-2 E2E Teststrategi 1 Målet med E2E test af Engrosmodel

Læs mere

Adgang til kundeportalen

Adgang til kundeportalen Til elleverandørerne Adgang til kundeportalen 3. april 2012 XSTJ/LRO Følgende dokument har til formål at orientere elleverandørerne om implementering og testning af den it-funktionalitet, som skal sikre

Læs mere

DataHub 31572-10. Bilag 01 - Tidsplan. 1.0 Udbudsmateriale til udsendelse d. 5. juli 2010. EU-udbud 2010/S 97-149624

DataHub 31572-10. Bilag 01 - Tidsplan. 1.0 Udbudsmateriale til udsendelse d. 5. juli 2010. EU-udbud 2010/S 97-149624 DataHub Bilag 01 - Tidsplan 1.0 Udbudsmateriale til udsendelse d. 5. juli 2010 30-06-2010 01-07-2010 DATE XRDA ADA NAME DATE REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED EU-udbud 2010/S 97-149624

Læs mere

Er der penge i skidtet?

Er der penge i skidtet? Er der penge i skidtet? Gasnettet, oprindelsescertifikater og ny støtteordning Foreningen for Danske Biogasanlæg Dorte Gren Kristiansen dgk@energinet.dk Dato - Dok.nr. 1 Indhold 1. Energinet.dk s opgaver

Læs mere

Bilag 1 E. Opgavebeskrivelse

Bilag 1 E. Opgavebeskrivelse 20. januar 2014 J.nr. 2009/2018-0001 Ref. Bak/fma Bilag 1 E. Opgavebeskrivelse Indhold 1. Baggrund... 2 2. Forsyningspligtens omfang og indhold... 2 2.1 De udbudte bevillingsområder... 2 2.2 Forsyningspligtens

Læs mere

Energinet.dk s præcisering af balanceansvar

Energinet.dk s præcisering af balanceansvar ENERGITILSYNET Punkt 4 Energitilsynets møde den 19 marts 2013 Sekretariatet for Energitilsynet Energinet.dk s præcisering af balanceansvar Resumé 1. I denne sag anmodes Energitilsynet om at tage stilling

Læs mere

Teknisk forskrift 5.1.2. Definition af anlægsstatus. for termiske kraftværker. tilsluttet transmissionsnettet

Teknisk forskrift 5.1.2. Definition af anlægsstatus. for termiske kraftværker. tilsluttet transmissionsnettet Teknisk forskrift 5.1.2 Definition af anlægsstatus for termiske kraftværker tilsluttet transmissionsnettet 0 Endelig udgave REV. DESCRIPTION 15.03.2015 18.03.2015 20.03.2015 20.03.2015 DATE KDJ XLOC NNM

Læs mere

DATAHUB ENGROSMODEL E2E TEST - VEJLEDNING TIL OPRETTELSE AF PARENT-CHILD RELATIONER

DATAHUB ENGROSMODEL E2E TEST - VEJLEDNING TIL OPRETTELSE AF PARENT-CHILD RELATIONER DATAHUB ENGROSMODEL E2E TEST - VEJLEDNING TIL OPRETTELSE AF PARENT-CHILD RELATIONER 3. marts 2015 Version 1.00 Dok. 13/81170-31 Side 1 af 8 Indholdsfortegnelse 1. Dokumentinformation... 3 1.1 Versionsoversigt...

Læs mere

Gasdetailmarkedet. Workshop 13:00-15:15. 19. November 2014. 19. november dok.nr. 14/24735 Gasdetailmarkedet 1

Gasdetailmarkedet. Workshop 13:00-15:15. 19. November 2014. 19. november dok.nr. 14/24735 Gasdetailmarkedet 1 Gasdetailmarkedet Workshop 13:00-15:15 19. November 2014 19. november dok.nr. 14/24735 Gasdetailmarkedet 1 Program 13.00 Velkommen Dorte Kristiansen, Energinet.dk 13.10 10 års jubilæum og overvejelser

Læs mere

Kravspecification IdP løsning

Kravspecification IdP løsning Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige

Læs mere

Klik på lagkagediagrammerne og se flere detaljer for både netvirksomhedernes og elleverandørernes

Klik på lagkagediagrammerne og se flere detaljer for både netvirksomhedernes og elleverandørernes DataHub Læs her tidligere nyheder på Ninas blog - En ugentlig opdatering om sidste nyt i projektet for markedets aktører 11. marts 2011 JHH Status for netvirksomheder Status for elleverandører Nyheder

Læs mere

Håndtering af fejlagtige leverandørskift

Håndtering af fejlagtige leverandørskift Til: Energitilsynet Håndtering af fejlagtige leverandørskift 7. januar 2013 HEP-HSF/HEP Energitilsynet behandlede den 27. november 2012 Energinet.dk s anmeldte markeds- og målerforskrifter, som ligger

Læs mere

E2E Teststrategi Engrosmodellen

E2E Teststrategi Engrosmodellen E2E Teststrategi Engrosmodellen Et overblik over metode og proces Ver. 1.00 FRE August 2013 1 Kort om: End to End (E2E) Test Generelt om End-to-End (E2E) Test Formålet med at gennemføre en E2E test er

Læs mere

Vilkår for elleverandørers betaling af ydelser fra Energinet.dk og sikkerhedsstillelse

Vilkår for elleverandørers betaling af ydelser fra Energinet.dk og sikkerhedsstillelse Vilkår for elleverandørers betaling af ydelser fra Energinet.dk og sikkerhedsstillelse Maj 2015 Version 1.3 Træder i kraft den 1.4.2016 April 2015 April 2015 Maj 2015 DATE LJD HSF MHS NAME REV. DESCRIPTION

Læs mere

Håndtering af nettoafregnere i DataHub'en

Håndtering af nettoafregnere i DataHub'en Til Netvirksomhederne Elleverandører til orientering 16. september 2013 PHQ Håndtering af nettoafregnere i DataHub'en Afregningsgrundlag for nettoafregnere - Forbrugs MP, Produktions MP og evt. uktions

Læs mere

Koordinerende Styregruppe for Engrosmodellen og DataHub Drift, møde 9

Koordinerende Styregruppe for Engrosmodellen og DataHub Drift, møde 9 Koordinerende Styregruppe for Engrosmodellen og DataHub Drift, møde 9 Tid Onsdag 16. juni 2015, kl. 15.00-17.00 Sted Energinet.dk, Ballerup Deltagere Styregruppens medlemmer: Adm. dir. Peder Ø. Andreasen,

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Program for intern overvågning

Program for intern overvågning Program for intern overvågning Årsberetning 2005 Indhold Hvem er Baggrund Beskrivelse af overvågningsprogrammet - Programmets omfang - Programmets kontroller - Programmets udvikling Programmets gennemførelse

Læs mere

Tilslutning af solcelleanlæg

Tilslutning af solcelleanlæg Tilslutning af solcelleanlæg Sådan gør du, hvis du vil tilslutte et Mikro VE-anlæg (solceller eller hustandsvindmølle) på mindre end eller lig med 6 kw til din el-installation, som er tilsluttet SE s elnet.

Læs mere

Fremme af fleksibelt elforbrug fra små og mellemstore kunder

Fremme af fleksibelt elforbrug fra små og mellemstore kunder Fremme af fleksibelt elforbrug fra små og mellemstore kunder Seminar for netvirksomheder 3. oktober 2011 1 Baggrund Bredt ønske om mere fleksibelt elforbrug - Markedets prissignaler kan sikre en effektiv

Læs mere

At opstille forslag til minimumskrav til opfyldelse af nedenstående målsætninger

At opstille forslag til minimumskrav til opfyldelse af nedenstående målsætninger Engrosmodellen Arbejdsgruppe vedrørende implementering af ændret fremsendelsesmønster for timedata m.m. slutrapport 15. oktober 2014 XVJE 1. Baggrund Arbejdsgruppen har afholdt i alt 4 møder, hvor problematikkerne

Læs mere

Årsregnskab for Energinet.dk

Årsregnskab for Energinet.dk Årsregnskab for Energinet.dk 14. maj 2006 Dette notat uddyber delregnskaberne i Årsrapport for Energinet.dk. Der gives således en forklaring på de væsentligste indtægter og omkostninger på elog gassegmenterne

Læs mere

DataHub Dialogforum Dialogmøde, 06-08-2012

DataHub Dialogforum Dialogmøde, 06-08-2012 DataHub Dialogforum Dialogmøde, 06-08- Tid 10.00-12.00 Sted LYNC møde Deltagere Henrik Hornum (Dansk Energi) Poul Berthelsen (NRGi) Niels Toftensberg (DONG Energy) Lene Erfurt (DONG Energy) Carsten Bang

Læs mere

BILAG 1. Engrosmodel statusopdatering. Indhold. Den Koordinerende Styregruppe for Engrosmodellen og DataHub Drift. 9.

BILAG 1. Engrosmodel statusopdatering. Indhold. Den Koordinerende Styregruppe for Engrosmodellen og DataHub Drift. 9. BILAG 1 Til Den Koordinerende Styregruppe for Engrosmodellen og DataHub Drift Engrosmodel statusopdatering 9. juni 2015 JHH/ADA Det indstilles, at den Koordinerende Styregruppe for Engrosmodellen og Data-

Læs mere

Fremtidens energiforsyning - et helhedsperspektiv

Fremtidens energiforsyning - et helhedsperspektiv Fremtidens energiforsyning - et helhedsperspektiv Gastekniske dage 18. maj 2009 Dorthe Vinther, Planlægningschef Energinet.dk 1 Indhold 1. Fremtidens energisystem rammebetingelser og karakteristika 2.

Læs mere

Teknisk forskrift TF 2.1.2

Teknisk forskrift TF 2.1.2 Teknisk forskrift TF 2.1.2 Automatisk og manuel elforbrugsaflastning 2.3 Gældende pr. 25. juni 2014 19.06.2014 19.06.2014 DATE LGS TSK NAME 2.2 Til NSU (Netsamarbejdsudvalget) (juni 2014) 2.1 Opfølgende

Læs mere

Dialogforum, referat. Tid 7. maj 2014 kl. 13.00 15.00. Deltagere Navn Aktør. Tina Lykke Skafsgaard Hentze Energi Danmark. Martin Christensen

Dialogforum, referat. Tid 7. maj 2014 kl. 13.00 15.00. Deltagere Navn Aktør. Tina Lykke Skafsgaard Hentze Energi Danmark. Martin Christensen Dialogforum, referat Tid 7. maj 2014 kl. 13.00 15.00 Sted LYNC Deltagere Navn Aktør Henrik Hornum Dansk Energi Yvonne Kaysen DONG Energy Tina Lykke Skafsgaard Hentze Energi Danmark Ane Rask Annemette L.

Læs mere

Bekendtgørelse om pristillæg til elektricitet produceret af andre vedvarende energianlæg end vindmøller

Bekendtgørelse om pristillæg til elektricitet produceret af andre vedvarende energianlæg end vindmøller Bekendtgørelse om pristillæg til elektricitet produceret af andre vedvarende energianlæg end vindmøller I medfør af 45, stk. 5, 47, stk. 4, 48, stk. 4, 50, stk. 2 og 5, 50 a, stk. 6 og 7, 53, stk. 1, 57

Læs mere

Automationsstrategi - hvor svært kan det være?

Automationsstrategi - hvor svært kan det være? Automationsstrategi - hvor svært kan det være? Smart Grid: Hvad bliver forskellen på energioptimering og smart grid optimering? v/ Chefkonsulent Steen Kramer Jensen, Energinet.dk 1 Agenda Energinet.dk?

Læs mere

Direktørgruppemøde, møde 3

Direktørgruppemøde, møde 3 Direktørgruppemøde, møde 3 Tid Tirsdag 17. juni kl. 15.00-17.00 Sted Energinet.dk, Ballerup Deltagere Direktørgruppens medlemmer: Adm. dir. Peder Ø. Andreasen, Energinet.dk Direktør Lars Aagaard, Dansk

Læs mere

Notat. Anbefalinger fra kvalitetsgruppen juni 2014 BILAG 3. Sagsfremstilling til Punkt 2.a Datakvalitet

Notat. Anbefalinger fra kvalitetsgruppen juni 2014 BILAG 3. Sagsfremstilling til Punkt 2.a Datakvalitet Notat BILAG 3 Dok. ansvarlig: HHO Sekretær: Sagsnr.: 2007-143 Doknr: d2014-7796-5.0 12-06-2014 Anbefalinger fra kvalitetsgruppen juni 2014 Sagsfremstilling til Punkt 2.a Datakvalitet Sagsfremstilling Direktørgruppen

Læs mere

EDI-kommunikation med DataHub i elmarkedet

EDI-kommunikation med DataHub i elmarkedet Forskrift F1: EDI-kommunikation med DataHub i elmarkedet November 2013 Høringsudgave Version 4.0 Træder i kraft den 1.10.2014 Nov. 2013 Nov. 2013 Nov. 2013 Nov. 2013 DATE CCO HBK LRO LRO NAME REV. DESCRIPTION

Læs mere

Kontraktbilag A - Kravspecifikation

Kontraktbilag A - Kravspecifikation Kontraktbilag A - Kravspecifikation Side 1 af 5 1 Indledning Nærværende kontraktbilag fastsætter de mindstekrav, der gælder for anskaffelsen af elektroniske dørlåse til Lemvig Kommune. Leverandøren gøres

Læs mere

Betalingsbetingelser og sikkerhedsstillelse Engrosmodellen

Betalingsbetingelser og sikkerhedsstillelse Engrosmodellen Betalingsbetingelser og sikkerhedsstillelse Engrosmodellen Maj 2014 Høringsudgave Version 1.0 Træder i kraft den 1.10.2015 Jan. 2014 April 2014 April 2014 DATE MFA HSF SHR NAME REV. DESCRIPTION PREPARED

Læs mere

Forskrift D2: Tekniske krav til elmåling 263352-06. Maj 2007. Rev. 1. Dec. 2006 Dec. 2006 Maj 2007 Maj 2007 DATE HER HEP HER LSO NAME. Energinet.

Forskrift D2: Tekniske krav til elmåling 263352-06. Maj 2007. Rev. 1. Dec. 2006 Dec. 2006 Maj 2007 Maj 2007 DATE HER HEP HER LSO NAME. Energinet. Forskrift D2: Tekniske krav til elmåling Maj 2007 Rev. 1 Dec. 2006 Dec. 2006 Maj 2007 Maj 2007 DATE HER HEP HER LSO NAME REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED 263352-06 Energinet.dk DOC.

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

2015-03-25 Dialogmøde 17, referat

2015-03-25 Dialogmøde 17, referat 2015-03-25 Dialogmøde 17, referat Tid 25. marts 2015 kl. 13.00-15.30 Sted Online-møde Inviterede Navn Aktør Henrik Hornum Dansk Energi Torben Møller Pedersen Dansk Energi Yvonne Kaysen DONG Energy Diana

Læs mere

Elprisstatistik for forsyningspligtprodukter 3. kvartal 2014

Elprisstatistik for forsyningspligtprodukter 3. kvartal 2014 Elprisstatistik for forsyningspligtprodukter 3. kvartal 2014 Indledning Formålet med elprisstatistikken for forsyningspligtprodukter er at afspejle den gennemsnitlige elpris for husholdninger samt små

Læs mere

Enkelt Nemt Effektivt Skalérbart

Enkelt Nemt Effektivt Skalérbart Enkelt Nemt Effektivt Skalérbart Overvåg hele din IT infrastruktur med ét værktøj Som IT ansvarlig er din infrastruktur lig med dit image over for interne som eksterne kunder. Din mulighed for at reagere

Læs mere

Udbudsbeskrivelse. Prækvalifikation. GEV A/S Maj 12014. Forsyning Helsingør A/S

Udbudsbeskrivelse. Prækvalifikation. GEV A/S Maj 12014. Forsyning Helsingør A/S Udbudsbeskrivelse Orientering Montage af om fjernaflæste målerudbud elmålere Prækvalifikation GEV A/S Maj 12014 Forsyning Helsingør A/S Juli 2014 Indholdsfortegnelse Indholdsfortegnelse 1 Indledning...

Læs mere

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4

Læs mere

Bilag 1 N Opgavebeskrivelse

Bilag 1 N Opgavebeskrivelse 15. januar 2013 J.nr. 2201/1182-0006 Ref. BAK Bilag 1 N Opgavebeskrivelse Indhold 1. Baggrund... 2 2. Forsyningspligtens omfang og indhold... 2 2.1 De udbudte bevillingsområder... 2 2.2 Forsyningspligtens

Læs mere

Rolfsted og Omegns Transformerforenings Netselskab Amba.

Rolfsted og Omegns Transformerforenings Netselskab Amba. Rolfsted og Omegns Transformerforenings Netselskab Amba. Program for intern overvågning. 1. Programmets formål og opbygning. To nødvendige forudsætninger for et velfungerende konkurrencemarked for el er,

Læs mere

Datamigreringsstrategi Engrosmodellen

Datamigreringsstrategi Engrosmodellen Datamigreringsstrategi Engrosmodellen Et overblik over metode og proces Ver. 2.0 Maj 2014 DOK NR 13/100808-1 1 Migreringsstrategi Sikre at nuværende funktionalitet i Datahub forbliver uændret frem til

Læs mere

Markedsregister. Agenda:

Markedsregister. Agenda: Markedsregister Agenda: 1. Introduktion 2. Forløb i PM perspektiv 3. Projekt organisation og ansvar 4. Planer, metodik og værktøjer 5. Styring af kritiske forhold: issues & risiko 6. Forventninger til

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

GODKENDELSE AF METODER I DETAIL- MARKEDSFORSKRIFTER (ENGROSMODEL M.V)

GODKENDELSE AF METODER I DETAIL- MARKEDSFORSKRIFTER (ENGROSMODEL M.V) FORMANDENS AFGØRELSE DEN 28. APRIL 2015 GODKENDELSE AF METODER I DETAIL- MARKEDSFORSKRIFTER (ENGROSMODEL M.V) 28. april 2015 Detail & Distribution 14/10476, 14/10478, 15/00115 laa, lrn RESUMÉ 1. Som følge

Læs mere

Teknik- og implementeringsgruppen

Teknik- og implementeringsgruppen Teknik- og implementeringsgruppen Møde 16 16. december 2014 Dok.nr. 14/15488-21 1 Agenda 1. Referat fra sidste møde 2. Status datamigrering og datakonsistens 3. Status E2E-test 4. Nyt lovforslag elafgifter

Læs mere

uddybende beskrivelse af processen i forbindelse med fremsøgning af sagsakter?

uddybende beskrivelse af processen i forbindelse med fremsøgning af sagsakter? UDBUD AF BYGGESAGSSYSTEM OFFENTLIGT UDBUD, OFFENTLIGGJORT DEN 3. JULI 2015. SPØRGSMÅL OG SVAR NR. 1 (17/08/2015) NR. 1. 2. REFERENCE SPØRGSMÅL SVAR Bilag 1. Krav 9 Bilag 1. Krav 17 Er det muligt at få

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Hvad er nødvendigt for et smart elsystem? Fleksibelt elforbrug! Jørgen S. Christensen Afdelingschef Dansk Energi

Hvad er nødvendigt for et smart elsystem? Fleksibelt elforbrug! Jørgen S. Christensen Afdelingschef Dansk Energi Hvad er nødvendigt for et smart elsystem? Fleksibelt elforbrug! Jørgen S. Christensen Afdelingschef Dansk Energi Agenda Elsystemet og fremtiden Produktion og forbrug skal passe sammen Kan vi komme helt

Læs mere

Transportsektoren er en stor udfordring for fremtidens energipolitik. Power to the People. Jørgen S. Christensen, Dansk Energi

Transportsektoren er en stor udfordring for fremtidens energipolitik. Power to the People. Jørgen S. Christensen, Dansk Energi Transportsektoren er en stor udfordring for fremtidens energipolitik Power to the People Jørgen S. Christensen, Dansk Energi 1 Agenda De energipolitiske udfordringer Der er behov for flere brændselstyper

Læs mere

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark Digital post, NemSMS & Fjernprint samt strategien for udvikling af mobile løsninger for Digital post og Min side

Læs mere

Elprisstatistik 2. kvartal 2012

Elprisstatistik 2. kvartal 2012 Elprisstatistik 2. kvartal 2012 Indledning Formålet med elprisstatistikken er at afspejle den gennemsnitlige elpris for husholdninger samt små og store virksomheder. Der kan være lokale prisforskelle,

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Guide til online aktørregister for gasleverandører

Guide til online aktørregister for gasleverandører Guide til online aktørregister for gasleverandører Version 1.0 29. juni 2012 Indhold 1. Introduktion... 2 2. Adgang... 2 2.1 Log-in... 3 3. Stamdata - Master Data... 4 3.1 Personlige data Personal Data...

Læs mere

Elprisstatistik 1. kvartal 2012

Elprisstatistik 1. kvartal 2012 Elprisstatistik 1. kvartal 212 Indledning Formålet med elprisstatistikken er at afspejle den gennemsnitlige elpris for husholdninger samt små og store. Der kan være lokale prisforskelle, der afviger fra

Læs mere

Guideline. EAN-systemet

Guideline. EAN-systemet Guideline Hammershusgade 17 DK-2100 København Ø Tel: 39 27 85 27 Fax: 39 27 85 10 www.ean.dk for anvendelsen af EAN-systemet til entydig identifikation af målepunkter i EL-forsyningssektoren samt EAN-13

Læs mere

2014-10-29 Dialogmøde 12, referat

2014-10-29 Dialogmøde 12, referat 2014-10-29 Dialogmøde 12, referat Tid 29. oktober 2014 kl. 10.00-16.00 Sted Store Bjørn, Erritsø Deltagere Navn Aktør Henrik Hornum Dansk Energi Torben Møller Pedersen Dansk Energi Yvonne Kaysen Diana

Læs mere

Den effektive danske energiforsyning II myndigheder/tilsyn

Den effektive danske energiforsyning II myndigheder/tilsyn Den effektive danske energiforsyning II myndigheder/tilsyn Omstilling til konkurrence og effektivitet Hvad er opnået via benchmarking og regelforvaltning? Jørgen G. Jørgensen Medlem af Energitilsynet Energitilsynet

Læs mere

Effektiv anvendelse af vindkraftbaseret el i Danmark

Effektiv anvendelse af vindkraftbaseret el i Danmark Effektiv anvendelse af vindkraftbaseret el i Danmark Samspil mellem vindkraft, varmepumper og elbiler RESUME VARMEPUMPER Effektiv anvendelse af vindkraftbaseret el i Danmark Udgivet af Oplag: 500 Rapporten

Læs mere

Afgørelse Klage over Energinet.dk s afgørelse om afslag på årsbaseret nettoafregning

Afgørelse Klage over Energinet.dk s afgørelse om afslag på årsbaseret nettoafregning Til: [XXX] Energinet.dk Sendes pr. e-mail til ovenstående Frederiksborggade 15 1360 København K Besøgsadresse: Linnésgade 18, 3. sal 1361 København K Tlf 3395 5785 Fax 3395 5799 www.ekn.dk ekn@ekn.dk Afgørelse

Læs mere

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark

Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5

Læs mere

Bilag 1 Tidsplan Version 0.9 05-05-2014 0

Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,

Læs mere

Dialogforum, referat. Tid 2. april 2014 kl. 10.00 16.00. Påfuglen, Erritsø. Deltagere Navn Aktør. Martin Christensen. 8. april 2014 MMH/XVJE

Dialogforum, referat. Tid 2. april 2014 kl. 10.00 16.00. Påfuglen, Erritsø. Deltagere Navn Aktør. Martin Christensen. 8. april 2014 MMH/XVJE Dialogforum, referat Tid 2. april 2014 kl. 10.00 16.00 Sted Påfuglen, Erritsø Deltagere Navn Aktør Torben Møller Pedersen Yvonne Kaysen Kristoffer Mitens Tina Lykke Skafsgaard Hentze Ane Rask Annemette

Læs mere