1. No category

EDI transaktioner for det danske
elmarked
EDI transaktioner for det danske
elmarked
(EDI guide - RSM)
1. juli 2015
Version 5.6.1
5.6.0
Baseline
5.6.1
1. revision
30.1.2015
30.1.2015
1.2.2015
COO
XKAF
XVJE
29.6.2015 29.6.2015
COO
XKAF
Prepared
Checked
29.06.2015
XVJE
Reviewed Approved
DOC. NO 13/101713-21
DOC. NO.
© Energinet.dk
INDHOLDSFORTEGNELSE
INDHOLDSFORTEGNELSE ............................................................................................. 2
0. Ændringslog ...................................................................................................... 5
1. Referencer ........................................................................................................ 8
2. Introduktion ...................................................................................................... 9
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
Formål og målgruppe ............................................................................... 9
Forretningstransaktioner .......................................................................... 9
Beskrivelse af meddelelsesstruktur ............................................................ 9
Meddelelsesudveksling ............................................................................ 10
XML namespace og versionering for meddelelser ........................................ 10
Validering mod XML skema ...................................................................... 11
Forklaring til elementbeskrivelser ............................................................. 12
Håndtering af delegering ......................................................................... 12
3. Fælleskomponenter ........................................................................................... 15
3.1. ABIE’er ................................................................................................. 15
3.2. Regler for angivelse af kodelisteansvarlig .................................................. 16
4. Håndtering af Header information ....................................................................... 18
4.1. Fælles attributter for meddelelser ............................................................. 18
4.2. HeaderEnergyDocument.......................................................................... 18
4.3. ProcessEnergyContext ............................................................................ 19
5. Requirement Specification Mapping ..................................................................... 21
5.1. RSM-001: Start af leverance.................................................................... 22
5.2. RSM-002: Annuller start af leverance ....................................................... 28
5.3. RSM-003: Genoptag leverance på målepunkt............................................. 33
5.4. RSM-004: Notifikation om skift af elleverandør .......................................... 38
5.5. RSM-005: Ophør af leverance fra elleverandør ........................................... 42
5.6. RSM-006: Forespørg om stamdata ........................................................... 47
5.7. Tomt afsnit ............................................................................................ 52
5.8. RSM-008: Annuller leveranceophør ........................................................... 53
5.9. RSM-009: Kvittering (fejlrapport) ............................................................. 58
5.10. RSM-010: Fremsend diverse forbrugsopgørelser ....................................... 61
5.11. RSM-011: Fremsend forbrug for skabelonafregnet målepunkt samt
tællerstand .................................................................................................. 65
5.12. RSM-012: Fremsend måledata for et målepunkt ....................................... 70
5.13. RSM-013: Fremsend andelstal................................................................ 76
5.14. RSM-014: Fremsend beregnede tidsserier ............................................... 80
5.15. RSM-015: Anmod om måledata på målepunkt .......................................... 85
5.16. RSM-016: Anmod om aggregerede måledata ........................................... 91
5.17. RSM-017: Anmod om engrosydelser ....................................................... 97
5.18. RSM-018: Fremsend hullerlog .............................................................. 102
5.19. RSM-019: Fremsend beregnede engrosydelser ....................................... 105
5.20. RSM-020: Forespørg om serviceydelse .................................................. 110
5.21. RSM-021: Ændring af målepunkt stamdata ............................................ 116
5.22. RSM-022: Fremsend målepunkt stamdata ............................................. 125
5.23. RSM-023: Forespørg om målepunkt stamdata (svar) .............................. 130
5.24. Tomt afsnit ........................................................................................ 135
5.25. Tomt afsnit ........................................................................................ 136
5.26. Tomt afsnit ........................................................................................ 137
5.27. RSM-027: Ændring af kundestamdata ................................................... 138
Dok. 13/101713-21
2 / 237
5.28.
5.29.
5.30.
5.31.
5.32.
5.33.
5.34.
5.35.
RSM-028:
RSM-029:
RSM-030:
RSM-031:
RSM-032:
RSM-033:
RSM-034:
RSM-035:
Fremsend kunde stamdata ................................................... 145
Forespørg om kunde stamdata (svar) .................................... 149
Ændring af afregningsstamdata ............................................. 153
Fremsend afregningsstamdata .............................................. 159
Forespørg om afregningsstamdata ......................................... 163
Ændring af prisliste .............................................................. 169
Fremsend prisliste ............................................................... 175
Forespørg om prisliste .......................................................... 178
6. Kodelister ...................................................................................................... 184
6.1. Datadefinitioner for BusinessReasonCode ................................................ 185
6.2. Datadefinitioner for BusinessRoleCode .................................................... 186
6.3. Datadefinitioner for ChargeTypeCode ...................................................... 187
6.4. Datadefinitioner for CurrencyIdentificationCode ....................................... 187
6.5. Datadefinitioner for DisconnectionTypeCode ............................................ 187
6.6. Datadefinitioner for DocumentFunctionCode ............................................ 187
6.7. Datadefinitioner for DocumentNameCode ................................................ 187
6.8. Datadefinitioner for DataRequestCode .................................................... 189
6.9. Datadefinitioner for EnergyProductIdentificationCode ................................ 189
6.10. Datadefinitioner for MeasurementUnitCommonCode................................ 189
6.11. Datadefinitioner for MeteringPointSubTypeCode ..................................... 189
6.12. Datadefinitioner for MeteringPointTypeCode ........................................... 190
6.13. Datadefinitioner for MeterReadingTypeCode ........................................... 190
6.14. Datadefinitioner for MPAddressWashInstructionTypeCode ........................ 190
6.15. Datadefinitioner for MPConnectionTypeCode .......................................... 190
6.16. Datadefinitioner for MPReadingCharacteristicsCode ................................. 191
6.17. Datadefinitioner for MPRelationTypeCode .............................................. 191
6.18. Datadefinitioner for PhysicalStatusCode ................................................ 191
6.19. Datadefinitioner for QuantityQualityCode ............................................... 191
6.20. Datadefinitioner for ResponseConditionCode .......................................... 191
6.21. Datadefinitioner for ResponseReasonDescriptionCode ............................. 191
6.22. Datadefinitioner for SectorAreaIdentificationCode ................................... 194
6.23. Datadefinitioner for ServiceRequestCode ............................................... 194
6.24. Datadefinitioner for SettlementMethodCode ........................................... 195
6.25. Datadefinitioner for VATClassCode ........................................................ 195
6.26. Datadefinitioner for
AssembledCodeListResponsibleAgencyCodeContentType .................................. 195
7. Håndtering af stamdata ................................................................................... 196
7.1. Stamdata ............................................................................................ 196
8. Datadefinitioner .............................................................................................. 203
8.1. Attributter ........................................................................................... 203
8.2. ChargeInformation ............................................................................... 204
8.3. ChargeTypeOwnerEnergyParty ............................................................... 206
8.4. ConsumerParty .................................................................................... 206
8.5. ContractedCapacityCharacteristics .......................................................... 207
8.6. DurationProfiledPeriod .......................................................................... 207
8.7. EnergyContext ..................................................................................... 208
8.8. EnergyDocument.................................................................................. 208
8.9. EnergyObservation ............................................................................... 208
8.10. EnergyParty ....................................................................................... 209
8.11. EnergyTimeSeries............................................................................... 210
8.12. LocationAddress ................................................................................. 211
8.13. MeterCharacteristic ............................................................................. 214
8.14. MeterFacility ...................................................................................... 215
8.15. MeteringGridAreaUsedDomainLocation .................................................. 215
Dok. 13/101713-21
3 / 237
8.16.
8.17.
8.18.
8.19.
8.20.
8.21.
8.22.
8.23.
8.24.
8.25.
8.26.
8.27.
8.28.
MeteringPointDomainLocation .............................................................. 215
MeteringPointCharacteristic ................................................................. 215
MeteringPointParty ............................................................................. 220
MPServiceEvent .................................................................................. 222
NonContinuousEnergyObservation ........................................................ 222
ProductCharacteristic .......................................................................... 223
ReferenceIdentity ............................................................................... 223
ResponseEvent................................................................................... 224
TimeSeriesPeriod ................................................................................ 224
VolumeEnergyObservation ................................................................... 225
RelatedMeteringPoint .......................................................................... 226
MissingDataRequest ............................................................................ 226
Andre ............................................................................................... 227
9. Webservice interface ....................................................................................... 228
9.1.
9.2.
9.3.
9.4.
Generelle fejlkoder ............................................................................... 228
sendMessage ....................................................................................... 231
peekMessage ....................................................................................... 232
dequeueMessage .................................................................................. 233
10. Figurliste ...................................................................................................... 235
Dok. 13/101713-21
4 / 237
0. Ændringslog
Alle ændringer i forhold til version 5.6.0, udgivet 1. februar 2015.
Version
RSM nummer
Afsnit
5.6.1
Afsnit 2
2.4
5.6.1
Afsnit 2
2.8.2
Rettelse
”Øger behandlingstiden” erstattet med
”forbedrer behandlingstiden”
Enkelte rettelser i tabel for
uddelegering:
 Fremsend diverse
forbrugsopgørelse: (kode D43 skal
anvendes for EL (D20 og E43 udgår
derfor))
 Forbrug for skabelonafregnet
målepunkt: (kode E30 udgår)
Herudover er:
DDQ rettet til EL,
DDM rettet til NV og
DDK rettet til BA
5.6.1
RSM-011
5.11.2 og 5.11.6 E30 “Historical data” er slettet
5.6.1
RSM-012
5.12.8
Indsat:
Generelt skal der være
overensstemmelse mellem de
indsendte værdier og de registrerede
værdier af stamdata på målepunktet.
Antal positioner skal svare til et helt
døgn eller et multiplum af døgn
forResolutionDuration lig PT15M eller
PT1H
Der findes ikke målepunkter med
målepunktstype Grid loss correction
(D13)
5.6.1
RSM-014
5.14.6
Ny MeasurementUnit CommonCode
Z14 Danish Tariff Code
tilføjet
5.6.1
RSM-014
5.14.7
Under andet punkt
(SettlementMethod) tilføjet:
og D13 (Nettabskorrektion)
5.6.1
RSM-018
5.18.2
5.18.5
Payload rettet fra 0..* til 1..*, således
at ”tom” meddelelse ikke er muligt
Dok. 13/101713-21
5 / 237
Version
5.6.1
RSM nummer
RSM-019
Afsnit
5.19.7
Rettelse
Under andet punkt
(SettlementMethod) tilføjet:
og D13 (Nettabskorrektion)
Herudover tilføjet:
 EnergySum angives med op til 2
decimaler.
5.6.1
RSM-021
5.21.8
Feltet EstimatedAnnualVolume er
fjernet fra skema
5.6.1
RSM-021
5.21.9
5.6.1
RSM-022
5.22.6
Nyt/ændret afsnit 5.21.9 opdateret
med nye valideringer
Sidste sætning slettes:
”ProductObligation bliver kun sendt til
System Operator (EZ)”
Der tilføjes:
”Function bliver kun medsendt i
forbindelse med BRS-014:
Målerhåndtering”
5.6.1
RSM-023
5.23.6
Sidste sætning slettes:
”ProductObligation bliver ikke
medsendt”
5.6.1
RSM-027
5.27.8
Feltet MPAddressWashInstructions er
fjernet
5.6.1
RSM-028
5.28.5
Feltet MPAddressWashInstructions er
fjernet
5.6.1
RSM-029
5.29.5
Feltet MPAddressWashInstructions er
fjernet
5.6.1
Afsnit 6
6.18
Afsnittet udgår:
“Datadefinitioner for
PaymentConditionCodeType”
5.6.1
Afsnit 6
6.22 (nu 6.21)
Nye fejlkoder tilføjet (aktiveret
reserverede koder):
D47: Håndtering ikke tilladt for
målepunkt tilhørende
nettoafregningsgruppe
D48: Blokeret for denne operation i
netområde
D49: Anden aktør blokeret for denne
operation i netområde
D50: Ingen delegering tilknyttet
5.6.1
Afsnit 7
5.6.1
Afsnit 8
Dok. 13/101713-21
Opdaterede tabeller
8.4
Navn ændret til kundenavn
6 / 237
Version
RSM nummer
Afsnit
5.6.1
Afsnit 8
8.5
5.6.1
Afsnit 8
8.12
5.6.1
Afsnit 8
8.12.1
5.6.1
Afsnit 8
8.17
5.6.1
Afsnit 8
8.20
Dok. 13/101713-21
Rettelse
ContractedCapacityCharacteristics
opdateret til
Effektgrænse Ampere validering rettet
til Heltal <=3
Effektgrænse kW validering rettet til
Heltal <=6
I husnummer er ”bogstav” rettet til
”bogstav eller andet tegn”
Dørbetegnelse er rettet til Dør
Kontakttype ændret til adressetype
Ændringer i mobil og telefonnummer
beskrivelse
Forbrug over tilladt grænse ændret til
Ignorer grænse
I tællerstand er antal cifre i
MeterReading reduceret fra 18 til 12.
7 / 237
1. Referencer









Forretningsprocesser for det danske elmarked (BRS)
Forskrift F
Forskrift I: Stamdata
XML Schema Part 0: Primer Second Edition
(http://www.w3.org/TR/xmlschema-0/
XML Schema Part 1: Structures Second Edition
(http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html)
XML Schema Part 2: Datatypes Second Edition
(http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html)
XML Path Language (XPath) (http://www.w3.org/TR/xpath/)
“Administrativ nummerering af offentlige veje og stier”
(http://vejdirektoratet.dk/DA/vejsektor/samarbejde/nationalt/CVF/Documen
ts/cvf_procedure_vejledning.pdf)
ebIX® Modelling Methodology
(http://www.ebix.org/Documents/ebIX_methodology_Draft_2r0A_20090427
.doc)
Dok. 13/101713-21
8 / 237
2. Introduktion
Denne bilagsrapport beskriver den samling af forretningstransaktioner, der indgår i
dokumentet "Forretningsprocesser for det danske elmarked".
Bilagsrapporten indeholder en specifikation af håndteringen af
forretningstransaktionerne der bliver anvendt i det danske elmarked.
En forretningstransaktion i dette dokument skal håndteres med udgangspunkt i
reglerne i Forskrift F, som blandt andet beskriver den generelle fejlhåndtering,
hvilket indebærer den validering af meddelelserne, som skal ske før den mere
specifikke forretningstransaktion.
2.1. Formål og målgruppe
Dokumentet har til formål at klarlægge og beskrive forretningstransaktionerne samt
indholdet af data for de beskrevne forretningsprocesser. Dokumentets målgruppe
er alle aktører og disses systemleverandører.
2.2. Forretningstransaktioner
En forretningstransaktion i dette dokument overholder reglerne i Forskrift F, med
tilhørende bilag. En forretningstransaktion er uafhængig af andre
forretningstransaktioner, men kan sammen med andre transaktioner indgå i en
eller flere forretningsprocesser.
En forretningstransaktion beskriver udvekslingen af meddelelser mellem to aktørers
it-systemer. Yderligere specificeres en del af den interne håndtering i en aktørs itsystem, hertil anvendes bl.a. et aktivitetsdiagram.
Udvekslingen af meddelelser mellem it-systemer er illustreret i et
aktivitetsdiagram, hvor navnet på meddelelsen er angivet og hvilke aktører der er
omhandlet (dansk rollemodel anvendes, jævnfør Forskrift F, bilagsrapport 3).
Ved modtagelse af en meddelelse skal det valideres om den er i overensstemmelse
med de forretningsregler der er angivet i Forretningsprocesser for det danske
elmarked, hvorefter svar afsendes.
Hver meddelelse indeholder en liste af attributter, som vises i form af et
klassediagram og i enkelte tilfælde anvendes en dependency matrix. En
dependency matrix anvendes, hvis det er muligt at sende en meddelelse med
forskellig attributter alt efter formål.
Dette dokument beskriver således alle forretningstransaktioner, der indgår i
dokumentet "Forretningsprocesser for det danske elmarked".
Bemærk, at klassediagrammerne der vises sammen med RSM'erne i dette
dokument er de logiske klassediagrammer. De tekniske klassediagrammer bliver
vist i et selvstændigt bilag "Tekniske klassediagrammer".
2.3. Beskrivelse af meddelelsesstruktur
Den strukturelle definition af de enkelte meddelelser er dels beskrevet tekstuelt i
dette dokument, dels specificeret ved hjælp af en række XML Schemaer, som kan
hentes på Energinet.dk’s hjemmeside.
Dok. 13/101713-21
9 / 237
På grund af tekniske begrænsninger i syntaksen for XML Schemaer er der
situationer, hvor attributter vil være angivet som valgfri, på trods af at de logisk vil
være krævet et sted i meddelelsen og valgfri eller endog ikke tilladt et andet sted.
Dette fremkommer når samme datatype genanvendes i samme meddelelse, men i
lidt forskellig kontekst. I disse tilfælde vil afhængigheden for den enkelte instans af
en attribut som beskrivet her i dokumentet være den gældende og den som
DataHub validerer efter.
2.4. Meddelelsesudveksling
Alle beskeder, der kommunikeres via webinterfacet i DataHub, er XML beskeder og
består af:
 En MessageHeader, som indeholder informationer, der bruges til styring af
den bagvedliggende forretningsproces. Det vil sige identifikation af den
enkelte besked og dens indhold og identifikation af den forretningsproces,
beskeden skal behandles af.
 En eller flere Payloads (forretningstransaktioner), som hver indeholder en
forretningsbesked.
En aktør kan sende en eller flere transaktioner i en EDI meddelelse.
Det er dog et krav, at der ved indsendelse af et større antal transaktioner med
samme forretningsårsag, at disse pakkes i hensigtmæssige meddelelsesstørrelser,
idet dette forbedrer behandlingstiden i DataHub mærkbart (Energinet.dk oplyser
om fordelagtige størrelse på de forskellige typer af meddelelser).
Pakning af transaktioner er især nødvendig ved indsendelse af forventet årsforbrug
jævnfør BRS-017: Fremsend forventet årsforbrug - Netvirksomhed samt ved
indsendelse af forbrugsopgørelser jævnfør BRS-020: Forbrugsopgørelse for
skabelonafregnet målepunkt og måledata jævnfør BRS-021: Fremsendelse af
måledata for et målepunkt.
Bemærk at den maksimale størrelse for en meddelelse ikke må overskride den
gældende størrelse, som findes angivet i forskrift F.
2.5. XML namespace og versionering for meddelelser
XML skemaer anvender et target namespace, der er udtrykt som en URI 1 og er
defineret af Energinet.dk. Disse kan eksempelvis være
-
http://www.energinet.dk/schemas/<subnamespace>/<document>/v<version>
un:unece:260:data:EEM-DK_Acknowledgment
XML-skemaer, der er udviklet til kommunikation mellem Energinet.dk og dennes
eksterne parter, anvender et target namespace, der er opbygget på følgende måde:
For meddelelser omfattet af bilaterale aftaler:
http://www.energinet.dk/schemas/<subnamespace>/<document>/v<version>
For meddelelser omfattet af ebIX's rammeværk:
prefix:EEM-DK_<NavnPåForretningsTransaktion>
1
Uniform Resource Identifier
Dok. 13/101713-21
10 / 237
Nedenstående eksempel viser, hvordan navngivning af et namespace kan se ud for
XML-skemaet vedrørende anmeldelse af leverandørskift:
un:unece:260:data:EEM-DK_RequestChangeOfSupplier
XML-skemaernes version angives i filnavnet. Filnavnet består således af navnet på
XML-skemaets rodelement kombineret med versionsnummer. De to dele adskilles
af _ (understreg), som vist herunder:
<organisation>_<rodelementnavn>-<version>.xsd
Nedenstående eksempel viser navngivningen af første version af et XML-skema,
hvor rodelementet er navngivet ”RequestChangeOfSupplier”:
ebIX_DK_RequestChangeOfSupplier_0p9p0.xsd
Attributten ”version” i skema-elementet består af en major version og en minor
version adskilt af et punktum, samt revision. Følgende eksempel gælder for major
version 2, minor version 4, revision 0:
Version=”2.4.0”
Ændringer, der ikke er bagud kompatible, vil medføre ændringer i major versions
nr. Det vil sige fjernelse af ikke valgfri elementer, navneændringer af elementer
eller attributter samt ændringer i strukturen for elementerne.
Ændringer, der er bagud kompatible, medfører kun ændringer i minor versions nr.
Det drejer sig om tilføjelse af valgfri elementer, ændringer i regler for
attributindhold (så længe det ikke indskrænker) og lignende.
Redaktionelle ændringer, såsom kommentarer etc., medfører ændringer på
revisionsniveau.
Det er således muligt, samtidigt, at anvende flere forskellige versioner af et XMLskema. Ved idriftsættelse af en ny version af et XML-skema, kan Energinet.dk
vælge ikke længere at understøtte en eller flere tidligere versioner.
2.6. Validering mod XML skema
XML skemaer2 definerer indhold, struktur og typer for XML meddelelser. Med en XSD
definition er det muligt at:
-
Beskrive indholdet i XML-meddelelsen
Validere XML meddelelsen
Definere datafacetter (restriktioner for dataindhold)
Definere datamønstre (dataformater)
DataHub validerer alle XML meddelelser mod det tilhørende skema. Valideringen
sker i samme webservice session, og afsender bliver øjeblikkeligt orienteret om
resultatet.
2
XML Schema Definition (XSD)
Dok. 13/101713-21
11 / 237
Det er til enhver tid Energinet.dk, der fastlægger, hvilket XML skema der skal
anvendes for en given XML meddelelse.
2.7. Forklaring til elementbeskrivelser
2.7.1. Brug af XPath syntaks
For præcist at kunne identificere de enkelte elementer i en meddelelse benyttes
XPath i tabellerne med feltbeskrivelser. For at undgå at XPath udtrykkene bliver for
lange, benyttes følgende forkortelser for XML namespaces i hele dette dokument:
prefix
XML Namespace
rsm
un:unece:260:data:EEM-DK_RequestChangeOfSupplier
ccts
urn:un:unece:uncefact:documentation:common:3:standard:CoreComponen
tsTechnicalSpecification:3
xbt
urn:un:unece:uncefact:data:common:1:draft
bie
Samme som “rsm” (Skal slettes)
2.8. Håndtering af delegering
En aktør kan selv kommunikere måledata med DataHub eller overlade det til en
anden aktør.
Netvirksomheden er ansvarlig for måledata, men kan uddelegere indsamling,
validering og udveksling til en måleoperatør.
2.8.1. Kommunikation til DataHub
En netvirksomhed kan have flere måleoperatører tilknyttet et netområde.
At autorisationen bliver udført på netområde niveau, betyder at en måleoperatør
kan indsende målinger for alle målepunkter i et netområde, hvor måleoperatøren er
delegeret myndighed.
Det er kun følgende RSM'er, der kan uddelegeres til indsendelser til DataHub'en:
- RSM-010: Fremsend diverse forbrugsopgørelser
- RSM-011: Forbrug for skabelonafregnet målepunkt samt tællerstand
- RSM-012: Fremsendelse af måledata for et målepunkt
Grid owner
Master
GLN10
Meter
operator 1
GLN11
RSM-012 + Negative acknowledgement
DataHub
Meter
operator 2
GLN12
Dok. 13/101713-21
12 / 237
Enhver måleoperatør kan kommunikere med DataHub, hvis de er delegeret
myndighed.
Efter at have sendt en meddelelse vil afsenderen (måleoperatøren) modtage et
direkte svar fra Webservice (godkendt/afvist). Ud over dette svar er den eneste
meddelelse, en måleoperatør kan modtage, en afvisningsbesked for RSM’n eller en
negativ acknowledgement (RSM-009).
DataHub vil altid sende en RSM-009 meddelelse til den fysiske afsender.
Hver aktør i markedet har sin egen kø, som er identificeret via aktørens GLN
nummer. Dette betyder, at hvis en måleoperatør indsender på vegne af flere
netvirksomheder, vil alle meddelelser til måleoperatøren blive placeret i én kø.
Hvis en aktør har flere forskellige systemer til indsendelse af meddelelser, er det
aktørens eget ansvar at distribuere disse meddelelser internt.
2.8.2. Kommunikation fra DataHub
Valg af den korrekte modtager af en meddelelse fra DataHub sker på RSM- og
forretningsårsags- niveau. Det er muligt at vælge en anden modtager end den
ansvarlige for hver RSM meddelelse.
Der vil være følgende muligheder for at uddelegere modtagelsen jævnfør tabel:
-
RSM
Navn
Årsag
Ansvarlig aktør
RSM-010
Fremsend diverse forbrugsopgørelse
E80
EL/NV
RSM-010
Fremsend diverse forbrugsopgørelse
E30
EL
RSM-010
Fremsend diverse forbrugsopgørelse
D43
EL
RSM-011
Forbrug for skabelonafregnet målepunkt
D10
EL
RSM-011
Forbrug for skabelonafregnet målepunkt
D19
EL/NV
RSM-012
Fremsend måledata for et målepunkt
D06
EL
RSM-012
Fremsend måledata for et målepunkt
E23
EL/NV
RSM-012
Fremsend måledata for et målepunkt
D42
EL
RSM-013
Fremsend andelstal
D02
EL/BA
RSM-014
Fremsend beregnede tidsserier
D03
NV/EL/BA
RSM-014
Fremsend beregnede tidsserier
D04
NV/EL/BA
RSM-014
Fremsend beregnede tidsserier
D05
NV/EL/BA
RSM-014
Fremsend beregnede tidsserier
D09
NV/EL/BA
RSM-014
Fremsend beregnede tidsserier
D32
NV/EL/BA
RSM-018
Fremsend hullerlog
D25
NV
RSM-018
Fremsend hullerlog
D26
NV
RSM-018
Fremsend hullerlog
D27
NV
RSM-019
Fremsend beregnede engrosydelser
D04
NV/EL
RSM-019
RSM-019
RSM-019
Fremsend beregnede engrosydelser
Fremsend beregnede engrosydelser
Fremsend beregnede engrosydelser
D05
D09
D32
NV/EL
NV/EL
NV/EL
Anvendt forkortelser:
 EL: elleverandør
 BA: Balanceansvarlig aktør
Dok. 13/101713-21
13 / 237


NV: Netvirksomhed
MO: Måleoperatør
Funktionalitet for udveksling af RSM-010/014 sker gennem opdatering af aktørens
oplysninger, hvor der skal angives navn og GLN nummer på de RSM'er, som
aktøren ikke selv ønsker at modtage. Der kan kun være en modtager pr. RSM pr.
forretningsårsagskode.
Anmodninger om data:
- RSM-015: Anmod om måledata
- RSM-016: Anmod om aggregerede måledata
- RSM-017: Anmod om engrosydelser
Disse RSM’er anvendes når en aktør (netvirksomhed, elleverandør, måleoperatør,
balanceansvarlig aktør) ønsker at anmode om måledata. Anmodningen kan
anvendes af både aktøren i de situationer, hvor RSM er uddelegeret til en anden
aktør og af måleoperatøren, som RSM er delegeret til. Modtageren findes ud fra
anmodning og ikke via RSM.
Dok. 13/101713-21
14 / 237
3. Fælleskomponenter
3.1. ABIE’er3
De enkelte meddelelser er dannet ud fra en fælles UML model, som består af et
katalog af entiteter (ABIE). I det følgende gives et overblik over de vigtigste af
disse grundentiteter. Det skal bemærkes, at i dette afsnit dokumenteres den
generelle implementering. I de konkrete meddelelser vil eventuelle specialtilfælde
være dokumenteret.
3.1.1. DomainLocation
Figur 1 - XMLSchema, DomainLocation
3.1.2. ConsumerParty
Denne klasse benyttes blandt andet til at repræsentere kunden, der kan være
enten en person eller en virksomhed.
Figur 2 - XML Schema, ConsumerParty
Bemærk at felterne, CPR og CVR er gensidigt afhængige, således at man kun må
angive enten CPR eller CVR.
3.1.3. Supplier
Denne klasse benyttes til at repræsentere elleverandøren.
Figur 3 - XML Schema, Navn på type
3.1.4. Balance responsible party
Denne klasse benyttes til at repræsentere den balanceansvarlige aktør.
3
Aggregate Business Information Entity
Dok. 13/101713-21
15 / 237
Figur 4 - XML Schema, Navn på type
3.1.5. Metering grid area
Denne klasse benyttes til at repræsentere netområdet.
Figur 5 - XML Schema, Navn på type
3.2. Regler for angivelse af kodelisteansvarlig
Generelle regler
Der bruges et sæt af koder, der er fastlagt i kodelister. Der er forskellige kodelister
– hver med en ansvarlig.
På det danske elmarked bruges 3 sæt af kodelister:
 UN/CEFACTkodeliste som UN/CEFACTer ansvarlig for
 ebIX-kodelisten, som ebIX-organisationen er ansvarlig for
 en dansk kodeliste, som Energinet.dk er ansvarlig for
Når der bruges en kodeliste skal det angives, hvem der er ansvarlig for kodelisten.
Til dette formål bruges attributterne listIdentifier og listAgencyIdentifier.
For UN/CEFACTkoder angives følgende listAgencyIdentifier.
Eksempel:
 <DocumentType listAgencyIdentifier="6">392</DocumentType>
ebiX koder er alle koder startende med ’E’.
For en kode fra ebIX-kode listen bruges følgende attribut:
 listAgencyIdentifier = 260
Eksempel - ebiX kode E22 (Tilsluttet på ’PhysicalStatusOfMeteringPoint’):
 <PhysicalStatusOfMeteringPoint
listAgencyIdentifier="260">E22</PhysicalStatusOfMeteringPoint>
Danske koder er alle koder startende med ’D’.
For en kode fra den danske kodeliste bruges følgende attributter:
 listAgencyIdentfier = 260
 listIdentifier = DK
Eksempel - dansk kode D02 (Afbrudt på ’PhysicalStatusOfMeteringPoint’):

<PhysicalStatusOfMeteringPoint listAgencyIdentifier="260"
listIdentifier=”DK”>D02</PhysicalStatusOfMeteringPoint >
Er denne kodeliste information ikke tilstede som påkrævet vil beskeden ikke blive
accepteret af datahub!
Dok. 13/101713-21
16 / 237
Identifikation af aktører
En aktør identificeres ved enten et GLN nummer eller en EIC kode.
Attributten schemeAgencyIdentifier bruges til at angive, hvilken identifikation der
bruges.

Hvis schemeAgencyIdentifier = 9, er der tale om et 13 cifret GLN nummer. For
nærmere information se GS1 Denmark’s webside.
Eksempel:

<Identification schemeAgencyIdentifier="9">5799999911118</Identification>
Hvis schemeAgencyIdentifier = 305, er der tale om en 16 tegns EIC kode. For
nærmere information se ENTSO-E’s webside
Identifikation af netområde
Et netområde er identificeret ved et 3-cifret nummer.
Attributterne schemeAgencyIdentifier og schemeIdentifier bruges til identifikationen

SchemeAgencyIdentifier=260

schemeIdentifier= DK
Eksempel

<MeteringGridAreaID schemeAgencyIdentifier="260"
schemeIdentifier="DK">073</MeteringGridAreaID>
Identifikation af aftagenummer
Aftagenummeret er identificeret ved et 18-cifret nummer. GS1 Denmark udsteder disse.
Dette angives ved attributten SchemeAgencyIdentifier=9.
Eksempel:

<MeteringPointDomainLocation> <Identification
schemeAgencyIdentifier="9">571313199988888819</Identification>
</MeteringPointDomainLocation>
Aktøren bør inden afsendelse af beskeder selv validere beskederne mod XMLskemaerne for at undgå unødige SOAP-fejl.
Dok. 13/101713-21
17 / 237
4. Håndtering af Header information
4.1. Fælles attributter for meddelelser
Alle meddelelser er bygget op med samme struktur. Et rodelement af typen for den
pågældende meddelelse, samt tre noder:
 HeaderEnergyDocument
 ProcessEnergyContext
 Et eller flere elementer med forretningsindhold, her kaldet PayloadMPEvent.
Figur 6 – XML Schema, Overordnet struktur af meddelelser
4.2. HeaderEnergyDocument
Figur 7 – XML Schema, HeaderEnergyDocument
Meddelelses ID
Klasse
Identification
Type
Validering
Beskrivelse
Ex.
An..35
Afsenders unikke identifikation af meddelelsen
<Identification>17727631</Identification>
DocumentType
Klas-
Dok. 13/101713-21
DocumentType
Type
DocumentTypeCode
18 / 237
se
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2.
Beskrivelse
Ex.
<DocumentType listAgencyIdentifier="260">E44</DocumentType>
Meddelelsesdato
Klasse
Ex.
Creation
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MM:SSZ
Beskrivelse
ISO-8601 standard anvendes.
Dato og tid i UTC+0. Tidspunkt for dannelse af en
meddelelse
<Creation>2010-07-09T13:40:00Z </Creation>
Afsender
Klasse
Ex.
Sender
EnergyParty
Identification
Type
An..35
Validering
CodingScheme = 9 angives 13 cifret GLN nummer.
CodingScheme = 305 angives 16 tegns EIC kode.
Beskrivelse
Entydig identifikation af afsender af meddelelsen.
Aktøren er identificeret af et GLN nummer eller en EIC
kode.
<SenderEnergyParty>
<Identification schemeAgencyIdentifier="9">5799999933318</Identification>
</SenderEnergyParty>
Modtager
Klasse
Ex.
Dokumenttype er koden for type af meddelelse.
Recipient
EnergyParty
Identification
Type
An..35
Validering
CodingScheme = 9 angives 13 cifret GLN nummer.
CodingScheme = 305 angives 16 tegns EIC kode
Beskrivelse
Entydig identifikation af modtager af meddelelsen.
Aktøren er identificeret af et GLN nummer eller en EIC
kode
<RecipientEnergyParty>
<Identification schemeAgencyIdentifier="9">5799999933318</Identification>
</RecipientEnergyParty>
4.3. ProcessEnergyContext
Figur 8 – XML Schema, ProcessEnergyContext
Forretningsårsag
Dok. 13/101713-21
EnergyBusinessProcess
19 / 237
Klasse
Type
BusinessReasonCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2.
Beskrivelse
Ex.
<EnergyBusinessProcess listAgencyIdentifier="260">E03</ EnergyBusinessProcess >
Marked
Klasse
Ex.
EnergyIndustryClassification
Type
SectorAreaIdentificationCode
Validering
Tjekkes mod kodelisten.
EnergyIndustryClassification = 23
Beskrivelse
Angivelse af markedsområde
<EnergyIndustryClassification listAgencyIdentifier="6">23</EnergyIndustryClassification>
Forretningsproces rolle
Klasse
EnergyBusinessProcessRole
Type
BusinessRoleCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2.
Den rolle som aktøren har i forbindelse med
udveksling af meddelelsen
Beskrivelse
Ex.
Beskriver årsag til transaktionen
Se under 'Anvendte koder' for at se gyldige koder.
<EnergyBusinessProcessRole
listAgencyIdentifier="260">DDX</EnergyBusinessProcessRole>
Dok. 13/101713-21
20 / 237
5. Requirement Specification Mapping
På de efterfølgende sider beskrives de enkelte transaktioner.
Dok. 13/101713-21
21 / 237
5.1. RSM-001: Start af leverance
5.1.1. Overblik
Start af leverance
Elleverandør
DataHub
Figur 9 - Use Case Diagram for Start af leverance
Forretningstransaktionen anvendes af elleverandøren til at sende en Request
change of supplier til målepunktsadministratoren (DataHub).
5.1.2. Transaktionsstart
Transaktionen startes af en Request change of supplier meddelelse (Anmod start af
leverance) med DocumentType 392. En meddelelse kan indeholde en eller flere
transaktioner, der alle anvender den samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 E03 Change of balance supplier (skift af elleverandør)
 E65 Customer move-in (almindelig tilflytning)
 D21 Move-in due to other reason (tilflytning af anden årsag)
 D29 Secondary move-in (tilflytning sekundær)
 D30 Switch with short notice (skift med kort varsel)
Dok. 13/101713-21
22 / 237
5.1.3. Aktivitetsdiagram
activity : Start af leverance
Elleverandør
DataHub
Start
Anmod start af leverance
Send anmeldelse
Modtag anmeldelse
Kontrollér anmeldelse
Afvis start af leverance
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend start af leverance
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Fejl skal rettes
Proces OK
Figur 10 - Aktivitetsdiagram for Start af leverance
5.1.4. Anmod start af leverance/Request change of supplier
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
Ved modtagelse valideres meddelelsen derefter i overensstemmelse med reglerne i
Forskrift F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode og en reference til den
oprindelige meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.1.5. Godkend start af leverance/Confirm Change of Supplier
Hvis der ikke opdages fejl ved kontrol af meddelelsen i DataHub lagres
informationen og der sendes en bekræftelse (Confirm change of supplier) med
DocumentType 414 for alle de godkendte transaktioner til elleverandøren.
Dok. 13/101713-21
23 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm change of supplier vil altid indeholde en reference til den oprindelige
meddelelse.
Hvis elleverandøren opdager en uoverensstemmelse, kan der foretages en
annullering, jævnfør RSM-002.
5.1.6. Afvis start af leverance/Reject Change of Supplier
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject change of supplier med
DocumentType 414.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject change of supplier vil altid indeholde en reference til den oprindelige
meddelelse.
Modtager elleverandøren en Reject change of supply kan denne efterfølgende rette
sit system og sende en ny Request change of supplier for målepunktet.
5.1.7. Behandling af svar hos elleverandøren
Ved modtagelse hos elleverandøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.1.8. Besked: Anmod start af leverance/Request change of supplier
Request change of supplier indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
24 / 237
Figur 11 - Klassediagram for Anmod start af leverance
5.1.9. Anvendte koder
Navn
Kode
DocumentNameCode 392
BusinessRoleCode
DDQ
BusinessReasonCode E65
E03
D21
D29
D30
Beskrivelse
Request change of supplier
Balance Supplier
Customer move-in
Change of balance supplier
Move-in due to other reason
Secondary move-in
Switch with short notice
5.1.10. Øvrig beskrivelse
Enten CPR eller CVR skal udfyldes.
Kundenavn (Name) må kun medsendes ved tilflytning, altså for
BusinessReasonCode = E65, D21 eller D29.
Dok. 13/101713-21
25 / 237
5.1.11. Besked: Godkend start af leverance/Confirm Change of Supplier
Confirm change of supplier indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 12 - Klassediagram for Godkend start af leverance
5.1.12. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response
ConditionCode
Kode
414
DDQ
E65
E03
D21
D29
D30
39
Beskrivelse
Confirmation of start of supply
Balance Supplier
Customer move-in
Change of balance supplier
Move-in due to other reason
Secondary move-in
Switch with short notice
Approved
5.1.13. Besked: Afvis start af leverance/Reject Change of Supplier
Reject change of supplier indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 13 - Klassediagram for Afvis start af leverance
Dok. 13/101713-21
26 / 237
5.1.14. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
Kode
414
DDQ
E65
E03
D21
D29
D30
41
D03
Beskrivelse
Confirmation of start of supply
Balance Supplier
Customer move-in
Change of balance
Move-in due to other reason
Secondary move-in
Switch with short notice
Rejected
Missing consumer name or address
D07
D16
D17
D18
D38
E10
E16
E17
E18
E22
Ongoing move process
Incorrect connection status
Incorrect CPR/CVR
Incorrect type of metering point
Stop of supply not registered for metering point
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
Unauthorized balance responsible
Metering point blocked for switching
5.1.15. Unique identification
RSM ID
RSM-001
RSM navn
Start af leverance
RSM version
EDI message for XML:
Message ID
Request change of supplier
Message name
Anmod start af leverance
Schema URI
EDI message for XML:
Message ID
Confirm change of supplier
Message name
Godkend start af leverance
Schema URI
EDI message for XML:
Message ID
Reject change of supplier
Message name
Afvis start af leverance
Schema URI
Dok. 13/101713-21
27 / 237
5.2. RSM-002: Annuller start af leverance
5.2.1. Overblik
Annuller start af
leverance
Elleverandør
DataHub
Figur 14 - Use Case Diagram for Annnuller start af leverance
Forretningstransaktionen anvendes af elleverandøren til at sende en annullering af
et godkendt leverandørskift eller tilflytning til målepunktsadministrator.
5.2.2. Transaktionsstart
Denne transaktion startes af en Request cancel change of supplier (Anmod annuller
start af leverance) meddelelse med DocumentType 392.
Accept af denne meddelelse medfører at elleverandørens allerede godkendte
leverandørskift eller tilflytning annulleres.
En meddelelse kan indeholde en eller flere transaktioner, der alle anvender den
samme EnergyBusinessProcess og samme Function Cancellation.
Beskeden skal indeholde en reference til den oprindelige sendte anmeldelse.
Følgende BusinessReasonCode skal anvendes:
 E03 Change of balance supplier (skift af elleverandør)
 E65 Customer move-in (almindelig tilflytning)
Dok. 13/101713-21
28 / 237
5.2.3. Aktivitetsdiagram
activity : Annuller start af leverance
Elleverandør
DataHub
Anmod annuller start af leverance
Send annullering
Modtag annullering
Kontrollér annullering
Afvis annuller start af leverance
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend annuller start af leverance
Send bekræftelse
Godkendt?
Nej
Annullér skift
Ja
Proces OK
Fejl
Proces OK
Figur 15 - Aktivitetsdiagram for Annuller start af leverance
5.2.4. Anmod annuller start af leverance/Request cancel change of supplier
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
Ved modtagelse valideres meddelelsen derefter i overensstemmelse med reglerne i
Forskrift F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode og en reference til den
oprindelige meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.2.5. Godkend annuller af start af leverance/Confirm cancel change of
supplier
Hvis der ikke opdages fejl ved kontrol af meddelelsen annulleres de allerede
godkendte leverandørskift eller tilflytning fra elleverandøren og DataHub sender en
bekræftelse (Confirm cancel change of supplier) til elleverandøren med
DocumentType 414 for alle de godkendte transaktioner.
Dok. 13/101713-21
29 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm cancel change of supplier vil altid indeholde en reference til den oprindelige
meddelelse.
5.2.6. Afvis annuller af start af leverance/Reject cancel change of supplier
I tilfælde af, at der konstateres en fejl i forhold til forretningsreglerne skal
transaktionen afvises. Dette sker med meddelelsen Reject cancel change of supplier
med DocumentType 414.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject cancel change of supplier vil altid indeholde en reference til den oprindelige
meddelelse.
Modtager elleverandøren en Reject cancel change of supplier kan denne
efterfølgende rette sit system og sende en ny annulleringsmeddelelse for
målepunktet.
5.2.7. Behandling af svar hos elleverandøren
Ved modtagelse hos elleverandøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.2.8. Besked: Anmod Annuller start af leverance/Request cancel change of
supplier
Request cancel change of supplier indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 16 - Klassediagram for Annuller start af leverance
Dok. 13/101713-21
30 / 237
5.2.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
Kode
392
DDQ
E03
E65
1
Beskrivelse
Request change of supplier
Balance Supplier
Change of balance supplier
Customer move-in
Cancellation
5.2.10. Besked: Godkend annuller af start af leverance/Confirm cancel
change of Supplier
Confirm change of supplier indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 17 - Klassediagram for Godkend annuller af start af leverance
5.2.11. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response
ConditionCode
Kode
414
DDQ
E03
E65
39
Beskrivelse
Confirmation of start of supply
Balance Supplier
Change of balance supplier
Customer move-in
Approved
5.2.12. Besked: Afvis annuller af start af leverance/Reject cancel change of
Supplier
Reject cancel change of supplier indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
31 / 237
Figur 18 - Klassediagram for Afvis annuller af start af leverance
5.2.13. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
Kode
414
DDQ
E03
E65
41
D05
D06
E10
E16
E17
Beskrivelse
Confirmation of start of supply
Balance Supplier
Change of balance supplier
Customer move-in
Rejected
Metering point ID does not match the one from
the original document
Reference to transaction ID does not match the
one from the original document
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
5.2.14. Unique identification
RSM ID
RSM-002
RSM navn
Annuller start af leverance
RSM version
EDI message for XML:
Message ID
Request cancel change of supplier
Message name
Annuller start af leverance
Schema URI
EDI message for XML:
Message ID
Confirm cancel change of supplier
Message name
Godkend annullering af start af leverance
Schema URI
EDI message for XML:
Message ID
Reject cancel change of supplier
Message name
Afvis annullering af start af leverance
Schema URI
Dok. 13/101713-21
32 / 237
5.3. RSM-003: Genoptag leverance på målepunkt
5.3.1. Overblik
Genoptag leverance
på målepunkt
DataHub
Elleverandør
Figur 19 - Use Case Diagram for Genoptag leverance på målepunkt
Forretningstransaktionen anvendes af målepunktsadministratoren (DataHub) til at
sende en Request re-allocate change of supplier til elleverandør.
5.3.2. Transaktionsstart
Transaktionen startes af en Request re-allocate change of supplier meddelelse
(Anmod tilbageføring af elleverandør) med DocumentType D01. En meddelelse kan
indeholde en eller flere transaktioner, der alle anvender den samme
EnergyBusinessProcess.
Den følgende BusinessReasonCode skal anvendes:
 D07 Rollback Change-of-supplier (genoptag leverance)
 D33 Incorrect move (fejlagtig flytning)
Dok. 13/101713-21
33 / 237
5.3.3. Aktivitetsdiagram
activity : Genoptag leverance på målepunkt
DataHub
Elleverandør
Start
Anmod tilbageføring af elleverandør
Send anmeldelse
Modtag anmeldelse
Kontrollér anmeldelse
Afvis tilbageføring af elleverandør
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend tilbageføring af elleverandør
Godkendt?
Send bekræftelse
Nej
Ja
Proces OK
Fejl skal rettes
Proces OK
Figur 20 - Aktivitetsdiagram for Genoptag leverance på målepunkt
5.3.4. Anmod tilbageføring af elleverandør / Request re-allocate change of
supplier
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse hos elleverandøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Efterfølgende skal hver transaktion verificeres i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.3.5. Godkend tilbageføring af elleverandør /Confirm re-allocate change of
supplier
Hvis der ikke opdages fejl ved kontrol af meddelelsen hos elleverandøren lagres
informationen og der sendes en bekræftelse (Confirm re-allocate change of
supplier) med DocumentType D02 for alle de godkendte transaktioner til DataHub.
Dok. 13/101713-21
34 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmodningen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm re-allocate change of supplier vil altid indeholde en reference til den
oprindelige meddelelse.
5.3.6. Afvis tilbageføring af elleverandør/Reject re-allocate change of
supplier
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject re-allocate change of
supplier med DocumentType D02.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject re-allocate change of supplier vil altid indeholde en reference til den
oprindelige meddelelse.
5.3.7. Behandling af svar hos DataHub
For syntaksfejl gælder, at beskeden afvises synkront med en SOAP exception.
Modtager DataHub en Confirm re-allocate change of supplier vil elleverandøren
blive genindsat som elleverandør på målepunktet.
Modtager DataHub en Reject re-allocate change of supplier vil DataHub fortsætte
processen med at overføre målepunktet til forsyningspligtig elleverandør.
DataHub kontakter elleverandøren, hvis der er fejl i svar meddelelse.
5.3.8. Besked: Anmod tilbageføring af elleverandør / Request re-allocate
change of supplier
Request re-allocate change of supplier indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 21 - Klassediagram for Anmod tilbageføring af elleverandør
Dok. 13/101713-21
35 / 237
5.3.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Kode
D01
DDQ
D07
D33
Beskrivelse
Request re-allocate change of supplier
Balance Supplier
Rollback Change-of-supplier
Incorrect move
5.3.10. Besked: Godkend tilbageføring af elleverandør /Confirm re-allocate
change of supplier
Confirm re-allocate change of supplier indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 22 - Klassediagram for Godkend tilbageføring af elleverandør
5.3.11. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response
ConditionCode
Kode
D02
DDQ
D07
D33
39
Beskrivelse
Response to re-allocate change of supplier
Balance Supplier
Rollback Change-of-supplier
Incorrect move
Approved
5.3.12. Besked: Afvis tilbageføring af elleverandør/Reject re-allocate
change of supplier
Reject re-allocate change of supplier indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
36 / 237
Figur 23 - Klassediagram for Afvis tilbageføring af elleverandør
5.3.13. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
Kode
D02
DDQ
D33
D07
41
D29
Beskrivelse
Response to re-allocate change of supplier
Balance Supplier
Rollback move process
Rollback Change-of-supplier
Rejected
No existing contract
5.3.14. Unique identification
RSM ID
RSM-003
RSM navn
Genoptag leverance på målepunkt
RSM version
EDI message for XML:
Message ID
Request re-allocate change of supplier
Message name
Anmod tilbageføring af elleverandør
Schema URI
EDI message for XML:
Message ID
Confirm re-allocate change of supplier
Message name
Godkend tilbageføring af elleverandør
Schema URI
EDI message for XML:
Message ID
Reject re-allocate change of supplier
Message name
Afvis tilbageføring af elleverandør
Schema URI
Dok. 13/101713-21
37 / 237
5.4. RSM-004: Notifikation om skift af elleverandør
5.4.1. Overblik
Notifikation om skift
af elleverandør
DataHub
Netvirksomhed
Elleverandør
Figur 24 - Use Case Diagram for Notifikation om skift af elleverandør
Forretningstransaktionen bliver anvendt af målepunktsadministrator til at informere
en ellevandører eller en netvirksomhed om skift af elleverandør.
5.4.2. Transaktionsstart
Transaktionen initieres med en notifikation om skift af elleverandør (Notify Change
of Supplier) med DocumentType E44. En meddelelse kan indeholde en eller flere
transaktioner, der alle skal anvende den samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 E01 Move (flytning)
 E03 Change of balance supplier (skift af elleverandør)
 E06 Unrequested change of balance supplier (overflyt til forsyningspligtig
elleverandør)
 E20 End of supply (leveranceophør)
 E53 Meter reading on demand (anmod om aflæsning)
 E65 Customer move-in (almindelig tilflytning)
 D07 Rollback Change-of-supplier (genoptag leverance på et målepunkt)
 D11 Incorrect process (misligholdt proces)
 D12 Cancel Reading (annuller aflæsning)
 D14 Close down metering point (nedlæg målepunkt)
 D30 Switch with short notice (skift med kort varsel)
 D31 Transfer metering point (overflyt målepunkt)
 D34 End supply due to reallocate (information om stop pga. genoptagelse)
 D35 Continue supply due to rejected reallocate (information om fortsættelse
af leverance)
 D36 Continue supply of customer (genoptag kundeforhold)
 D37 Cancel service request (annuller serviceanmodning)
 D38 End of supply with short notice (stop af leverance med kort varsel)
 D39 Production Obligation (aftagepligt)
 D40 Removed parent relation on meteringpoint (parent relation fjernet fra
målepunkt)
 D41 No disconnection of meteringpoint (netvirksomhed har ikke afbrudt
målepunkt)
 D44 Process cancelled by requesting party (proces stoppet af aktøren)
 D45 Process cancelled by ITX (proces stoppet pga. anden proces)
Dok. 13/101713-21
38 / 237
5.4.3. Aktivitetsdiagram
activity : Notifikation om skift af elleverandør
DataHub
Netvirksomhed / Elleverandør
Start
Send meddelelse Notifikation om
skift af elleverandør
Notifikation om skift af elleverandør
Modtag meddelelse
Kontrollér meddelelse
Proces OK
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Fejl
Håndtér Manuelt
Figur 25 - Aktivitetsdiagram for Notifikation om skift af elleverandør
5.4.4. Notifikation om skift af elleverandør/Notify Change of Supplier
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.4.5. Besked: Notifikation om skift af elleverandør/Notify change of
supplier
Notify change of supplier indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
39 / 237
Figur 26 - Klassediagram for Notifikation om skift af elleverandør
5.4.6. Anvendte koder
Navn
Kode
DocumentNameCode E44
BusinessRoleCode
DDQ
DDM
BusinessReasonCode D07
D11
D12
D14
D30
D31
D34
D35
D36
D37
D38
D39
D40
D41
D44
D45
E01
E03
E06
E20
E53
E65
Beskrivelse
Notification to supplier of contract termination
Balance Supplier
Grid access provider
Rollback Change-of-supplier
Incorrect process
Cancel meter reading request
Close down metering point
Switch with short notice
Transfer metering point
End supply due to reallocate
Continue supply due to rejected reallocate
Continue supply of customer
Cancel service request
End of supply with short notice
Production Obligation
Removed parent relation on meteringpoint
No disconnection of meteringpoint
Process cancelled by requesting party
Process cancelled by ITX
Move
Change of balance supplier
Unrequested change of balance
End of supply
Meter reading on demand
Customer move-in
5.4.7. Øvrig beskrivelse
StartOfOccurrence anvendes ved følgende BusinessreasonCode:
 E06 Unrequested change of balance supplier
 E65 Customer move-in
 D07 Rollback Change-of-supplier
Dok. 13/101713-21
40 / 237







D11
D12
D30
D31
D35
D36
D37
Incorrect process
Cancel Reading
Switch with short notice
Transfer metering point
Continue supply due to rejected reallocate
Continue supply of customer
Cancel service request
EndOfOccurrence anvendes ved følgende BusinessreasonCode:
 E01 Move
 E03 Change of balance supplier
 E53 Meter reading on demand
 E20 End of supply
 D14 Close down metering point
 D34 End supply due to reallocate
 D38 End of supply with short notice
 D39 Production Obligation
 D40 Removed parent relation on meteringpoint
 D41 No disconnection of meteringpoint
 D44 Process cancelled by requesting party
 D45 Process cancelled by ITX
5.4.8. Unique identification
RSM ID
RSM-004
RSM navn
Notifikation om skift af elleverandør
RSM version
EDI message for XML:
Message ID
Notify Change of Supplier
Message name
Notifikation om skift af elleverandør
Schema URI
Dok. 13/101713-21
41 / 237
5.5. RSM-005: Ophør af leverance fra elleverandør
5.5.1. Overblik
Ophør af leverance
fra elleverandør
Elleverandør
DataHub
Figur 27 - Use Case Diagram for Ophør af leverance fra elleverandør
Transaktionen benyttes af elleverandøren til at informere
målepunktsadministratoren (DataHub) om ophør af leverance eller en fraflytning.
5.5.2. Transaktionsstart
Transaktionen initieres med en Request end of supply (anmod om leveranceophør)
med DocumentType 432. En meddelelse kan indeholde en eller flere transaktioner,
der alle skal anvende den samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 E20 End of supply (leveranceophør)
 E66 Consumer move-out (fraflytning)
Dok. 13/101713-21
42 / 237
5.5.3. Aktivitetsdiagram
activity : Ophør af leverance fra elleverandør
Elleverandør
DataHub
Start
Anmod om leveranceophør
Anmod om
leveranceophør
Modtag anmeldelse
Kontrollér anmeldelse
Afvis leveranceophør
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces Slut
Godkend leveranceophør
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 28 - Aktivitetsdiagram for Ophør af leverance fra elleverandør
5.5.4. Anmod om leveranceophør/Request end of supply
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende skal hver transaktion verificeres i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.5.5. Godkend leveranceophør/Confirm end of supply
Dok. 13/101713-21
43 / 237
Hvis meddelelsen valideres korrekt i DataHub lagres den modtagne information og
DataHub sender en bekræftelse (Confirm end of supply) til elleverandøren med
DocumentType E44 for alle de godkendte transaktioner.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmodningen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm end of supply vil altid indeholde en reference til den oprindelige
meddelelse.
5.5.6. Afvis leveranceophør/Reject end of supply
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
meddelelsen afvises. Dette sker med meddelelsen Reject end of supply med
DocumentType E44.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject end of supply vil altid indeholde en reference til den oprindelige meddelelse.
Modtager elleverandøren en Reject end of supply kan elleverandøren efterfølgende
rette sit system og sende en ny Request end of supply for målepunktet.
5.5.7. Behandling af svar hos elleverandøren
Ved modtagelse hos elleverandøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.5.8. Besked: Anmod om leveranceophør/Request end of supply
Request end of supply indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 29 - Klassediagram for Anmod om leveranceophør
Dok. 13/101713-21
44 / 237
5.5.9. Anvendte koder
Navn
Kode
DocumentNameCode 432
BusinessRoleCode
DDQ
BusinessReasonCode E20
E66
Beskrivelse
Notification to grid operator of contract termination
Balance Supplier
End of supply
Consumer move-out
5.5.10. Besked: Godkend leveranceophør/Confirm end of supply
Confirm end of supply indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 30 - Klassediagram for Godkend leveranceophør
5.5.11. Anvendte koder
Navn
Kode
DocumentNameCode E44
BusinessRoleCode
DDQ
BusinessReasonCode E20
E66
Response
39
ConditionCode
Beskrivelse
Notification to grid operator of contract termination
Balance Supplier
End of supply
Consumer move-out
Approved
5.5.12. Besked: Afvis leveranceophør/Reject end of supply
Reject end of supply indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
45 / 237
Figur 31 - Klassediagram for Afvis leveranceophør
5.5.13. Anvendte koder
Navn
Kode
DocumentNameCode E44
BusinessRoleCode
BusinessReasonCode
Response
ConditionCode
ResponseReason
DescriptionCode
DDQ
E20
E66
41
Beskrivelse
Notification to grid operator of contract
termination
Balance Supplier
End of supply
Consumer move-out
Reject
D07
Ongoing move process
D16
D18
E10
E16
E17
Incorrect connection status
Incorrect type of metering point
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
5.5.14. Unique identification
RSM ID
RSM-005
RSM navn
Ophør af leverance fra elleverandør
RSM version
EDI message for XML:
Message ID
Request end of supply
Message name
Anmod om leveranceophør
Schema URI
EDI message for XML:
Message ID
Confirm end of supply
Message name
Godkend leveranceophør
Schema URI
EDI message for XML:
Message ID
Reject end of supply
Message name
Afvis leveranceophør
Schema URI
Dok. 13/101713-21
46 / 237
5.6. RSM-006: Forespørg om stamdata
5.6.1. Overblik
Forespørg om stamdata
Elleverandør
Netvirksomhed
DataHub
Figur 32 - Use Case Diagram for Forespørg om stamdata
Query MasterData (Forespørg om stamdata) anvendes af elleverandør eller
netvirksomhed til at forespørge om stamdata på et målepunkt.
Forespørgslen skal ske på målepunktsniveau og vil, hvis den accepteres, resulterer i
2 svar meddelelser.
5.6.2. Transaktionsstart
Transaktionen initieres med en Query MasterData (Forespørg om stamdata) med
DocumentType D18. En meddelelse kan indeholde en eller flere transaktioner, der
alle skal anvende den samme EnergyBusinessProcess.
Følgende BusinessReasonCode skal anvendes:
 E0G Data alignment for master data metering point (stamdata til kontrol)
Dok. 13/101713-21
47 / 237
5.6.3. Ativitetsdiagram
activity : Forespørg om stamdata
Afsender
DataHub
Start
Anmod forespørg stamdata
Forespørg om stamdata
på målepunkt
Modtag anmodning
Kontrollér anmodning
Afvis forespørg stamdata
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Svar forespørg stamdata, målepunkt (RSM-023)
Svar forespørg stamdata, kunde (RSM-029)
Svar OK?
Send bekræftelse
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 33 - Aktivitetsdiagram for Forespørg om stamdata
5.6.4. Forespørg om stamdata/ Query MasterData
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse i DataHub
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende skal hver transaktion verificeres i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
5.6.5. Information om stamdata til kontrol
Hvis der ikke opdages fejl ved kontrol af Query MasterData meddelelsen sendes de
ønskede stamdata, som angivet i de følgende forretningstransaktioner:
 RSM-023: Svar forespørg stamdata, målepunkt
Dok. 13/101713-21
48 / 237

RSM-029: Svar forespørg stamdata, kunde
De modtagne stamdata vil altid indeholde en reference til den oprindelige
meddelelse.
Stamdata sendes med de informationer, der er gældende på det tidspunkt,
forespørgslen modtages.
5.6.6. Afvis forespørg stamdata/Reject Query MasterData
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
meddelelsen afvises. Dette sker med meddelelsen Reject QueryMasterData med
DocumentType D19.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess E0G som forespørgslen og afvisning sker ved at sætte
statuskode til 41 (rejected) og Reason sat til den relevante kode fra
forretningsreglerne.
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
Modtageren kan efterfølgende rette sit system og sende en ny QueryMasterData for
målepunktet.
5.6.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.6.8. Besked: Forespørg om stamdata / Query MasterData
Query MasterData indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 34 - Klassediagram for forespørg om stamdata
5.6.9. Anvendte koder
Navn
Kode
DocumentNameCode D18
BusinessRoleCode
DDQ
Dok. 13/101713-21
Beskrivelse
Query all master data
Balance Supplier
49 / 237
BusinessReasonCode
DDM
E0G
Grid access provider
Data alignment for master data metering point
5.6.10. Afvis forespørg stamdata /Reject Query MasterData
Reject Query MasterData indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 35 - Klassediagram for afvis forespørg stamdata
5.6.11. Anvendte koder
Navn
Kode
DocumentNameCode D19
BusinessRoleCode
DDQ
DDM
BusinessReasonCode E0G
Response
ConditionCode
ResponseReason
DescriptionCode
Dok. 13/101713-21
Beskrivelse
Reject all master data
Balance Supplier
Grid access provider
Data alignment for master data metering point
41
Reject
E10
Metering point not identifiable
E16
E0I
Unauthorized balance supplier
Unauthorised Grid Access Provider
50 / 237
5.6.12. Unique identification
RSM ID
RSM-006
RSM navn
Forespørg om stamdata
RSM version
EDI message for XML:
Message ID
Query MasterData
Message name
Forespørg om stamdata
Schema URI
EDI message for XML:
Message ID
Reject Metering Point Characteristics
Message name
Afvis forespørg stamdata
Schema URI
Dok. 13/101713-21
51 / 237
5.7. Tomt afsnit
Dette afsnit er med vilje tomt for at sikre nummerkonsistens mellem RSM numre og
afsnitsnumre.
Dok. 13/101713-21
52 / 237
5.8. RSM-008: Annuller leveranceophør
5.8.1. Overblik
Annuller
leveranceophør
Elleverandør
DataHub
Figur 36 - Use Case Diagram for Annnuller leveranceophør
Forretningstransaktionen anvendes af elleverandøren til at sende en annullering af
et godkendt leveranceophør eller en godkendt fraflytning til
målepunktsadministrator.
5.8.2. Transaktionsstart
Denne transaktion startes af en Request cancel end of supply (Anmod annuller
leveranceophør) meddelelse med DocumentType 432.
Accept af denne meddelelse medfører at elleverandørens allerede godkendte
leverandørophør eller fraflytning annulleres.
En meddelelse kan indeholde en eller flere transaktioner, der alle anvender den
samme EnergyBusinessProcess og samme Function Cancellation.
Beskeden skal indeholde en reference til den oprindelige sendte anmeldelse.
Følgende BusinessReasonCode skal anvendes:
 E20 End of supply (leveranceophør)
 E66 Consumer move-out (fraflytning)
Dok. 13/101713-21
53 / 237
5.8.3. Aktivitetsdiagram
activity : Annuller leveranceophør
Elleverandør
DataHub
Anmod annuller leveranceophør
Send annullering
Modtag annullering
Kontrollér anmeldelse
Afvis annuller leveranceophør
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend annuller leveranceophør
Godkendt?
Nej
Send bekræftelse
Annuller leveranceophør
Ja
Proces OK
Fejl
Proces OK
Figur 37 - Aktivitetsdiagram for Annuller leveranceophør
5.8.4. Anmod annuller leveranceophør /Request cancel end of supply
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
Ved modtagelse valideres meddelelsen derefter i overensstemmelse med reglerne i
Forskrift F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode og en reference til den
oprindelige meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.8.5. Godkend annuller leveranceophør /Confirm cancel end of supply
Hvis der ikke opdages fejl ved kontrol af meddelelsen annulleres de allerede
godkendte leveranceophør fra elleverandøren og DataHub sender en bekræftelse
(Confirm cancel end of supply) til elleverandøren med DocumentType E44 for alle
de godkendte transaktioner.
Dok. 13/101713-21
54 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm cancel change of supplier vil altid indeholde en reference til den oprindelige
meddelelse.
5.8.6. Afvis annuller leveranceophør /Reject cancel end of supply
I tilfælde af, at der konstateres en fejl i forhold til forretningsreglerne skal
transaktionen afvises. Dette sker med meddelelsen Reject cancel end of supply
med DocumentType E44.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject cancel end of supply vil altid indeholde en reference til den oprindelige
meddelelse.
Modtager elleverandøren en Reject cancel end of supply kan denne efterfølgende
rette sit system og sende en ny annulleringsmeddelelse for målepunktet.
5.8.7. Behandling af svar hos elleverandøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.8.8. Besked: Anmod annuller leveranceophør /Request cancel end of
supply
Request cancel end of supply indeholder udover header (HeaderEnergyDocument)
og procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 38 - Klassediagram for Anmod annuller leveranceophør
Dok. 13/101713-21
55 / 237
5.8.9. Anvendte koder
Navn
Kode
DocumentNameCode
432
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
DDQ
E20
E66
1
Beskrivelse
Notification to grid operator of contract
termination
Balance Supplier
End of supply
Consumer move-out
Cancellation
5.8.10. Besked: Godkend annuller leveranceophør /Confirm cancel end of
supply
Confirm change end of supply indeholder udover header (HeaderEnergyDocument)
og procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 39 - Klassediagram for Godkend annuller leveranceophør
5.8.11. Anvendte koder
Navn
Kode
DocumentNameCode
E44
BusinessRoleCode
BusinessReasonCode
Response
ConditionCode
DDQ
E20
E66
39
Beskrivelse
Notification to grid operator of contract
termination
Balance Supplier
End of supply
Consumer move-out
Approved
5.8.12. Besked: Afvis annuller leveranceophør /Reject cancel end of supply
Reject cancel end of supply indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
56 / 237
Figur 40 - Klassediagram for Afvis annuller leveranceophør
5.8.13. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
Kode
E44
DDQ
E20
E66
41
D05
D06
E10
E16
E17
Beskrivelse
Notification to grid operator of contract
termination
Balance Supplier
End of supply
Consumer move-out
Rejected
Metering point ID does not match the one from
the original document
Reference to transaction ID does not match the
one from the original document
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
5.8.14. Unique identification
RSM ID
RSM-008
RSM navn
Annuller leveranceophør
RSM version
EDI message for XML:
Message ID
Request cancel end of supply
Message name
Anmod annuller leveranceophør
Schema URI
EDI message for XML:
Message ID
Confirm cancel end of supply
Message name
Godkend annuller leveranceophør
Schema URI
EDI message for XML:
Message ID
Reject cancel end of supply
Message name
Afvis annuller leveranceophør
Schema URI
Dok. 13/101713-21
57 / 237
5.9. RSM-009: Kvittering (fejlrapport)
5.9.1. Overblik
Kvittering
DataHub
Balanceansvarlig
Netvirksomhed
Elleverandør
DataHub
Balanceansvarlig
Netvirksomhed
Elleverandør
Figur 41 - Use Case Diagram for kvittering
Meddelelsen anvendes kun i fejlsituationer, såfremt valideringen af en meddelelse
fejler. Acknowledgement, der specificerer årsagen til fejlen skal sendes inden for én
time.
Hvis Acknowledgement skal anvendes som en kvitteringsmeddelelse vil det blive
beskrevet i den forretningstransaktion (RSM), den anvendes i.
5.9.2. Transaktionsstart
Meddelelsen initieres af en fejl i en transaktion og af en af følgende aktører:
 Netvirksomhed
 DataHub
 Elleverandør
 Balanceansvarlig aktør
 Systemansvarlig (EZ)
 Balanceafregningansvarlig (DDX)
Modtageren af meddelelsen kan være en af de samme aktører.
Acknowledgement meddelelsen vil have DocumentType 294. En meddelelse kan
indeholde en eller flere transaktioner, der alle skal anvende den samme
EnergyBusinessProcess.
Hvilken BusinessReasonCode der skal anvendes afhænger af den meddelelse, som
fejler.
Dok. 13/101713-21
58 / 237
5.9.3. Aktivitetsdiagram
activity : Kvittering
Afsender
Modtager
Start
Kvittering
Send kvittering
Modtag kvittering
Kontrollér meddelelse
Gem informationer
Proces OK
Figur 42 - Aktivitetsdiagram for Kvittering
5.9.4. Kvittering/Acknowledgement
Meddelelsen sendes som beskrevet i klassediagrammet.
Acknowledgement Document skal altid indeholde en reference til den oprindelige
meddelelse.
Acknowledgement Document skal have samme BusinessProcess som den
oprindelige meddelelse.
Modtagelse
Ved modtagelse valideres Acknowledgement Document i overensstemmelse med
reglerne i Forskrift F.
Eventuelle fejl i Acknowledgement Documentet skal håndteres manuelt.
5.9.5. Besked: Kvittering/Acknowledgement
Acknowledgement indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
59 / 237
Figur 43 - Klassediagram for Kvittering
5.9.6. Anvendte koder
Navn
Kode
DocumentNameCode 294
BusinessRoleCode
Response
41
ConditionCode
BusinessReasonCode
Beskrivelse
Application acknowledgement and error report
Se kodeliste i afsnit 6
Rejected
Se kodeliste i afsnit 6
5.9.7. Øvrig beskrivelse
OriginalBusinessDocument Identification skal kun anvendes hvis fejl på transaktion
niveau.
ReasonText er optional.
5.9.8. Unique identification
RSM ID
RSM-009
RSM navn
Kvittering
RSM version
EDI message for XML:
Message ID
Acknowledgement
Message name
Kvittering
Schema URI
Dok. 13/101713-21
60 / 237
5.10. RSM-010: Fremsend diverse forbrugsopgørelser
5.10.1. Overblik
Fremsend diverse
forbrugsopgørelser
DataHub
Elleverandør
Netvirksomhed
DataHub
Elleverandør
Netvirksomhed
Figur 44 - Use Case Diagram for Fremsend diverse forbrugsopgørelser
Transaktionen benyttes af afsender til at sende en Notify Volumes meddelelse
(Notifikation om forbrugsoplysning) til modtageren.
Denne meddelelse kan også anvendes som svar på følgende forretningstransaktion:
 Anmodning om måledata (RSM-015)
I disse tilfælde vil Metered data profiled meddelelsen indeholde en reference til
anmodningen.
Afsender og modtager kan være:
 Netvirksomheden
 DataHub
 Elleverandør
5.10.2. Transaktionsstart
Transaktionen er en notifikation og initieres med en Notify Volumes meddelelse
med DocumentType D23. Meddelelsen kan indeholde en eller flere transaktioner,
der alle skal indeholde den samme kode for EnergyBusinessProcess.
En



af følgende BusinessReasonCodes skal anvendes:
D43 Historical information about consumption (forbrugsinformation)
E30 Historical data (historiske data)
E80 Change of estimated annual volume (forventet årsforbrug)
Dok. 13/101713-21
61 / 237
5.10.3. Aktivitetsdiagram
activity : Fremsend diverse forbrugsopgørelser
Afsender
Modtager
Start
Fremsend
forbrugsoplysning
Notifikation om forbrugsoplysning
Modtag forbrugsoplysning
Kontrollér meddelelse
Gem informationer
Proces OK
Proces OK
Figur 45 - Aktivitetsdiagram for Fremsend diverse forbrugsopgørelser
5.10.4. Notifikation om forbrugsoplysning / Notify Volumes
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse i DataHub
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Derefter valideres meddelelsen i overensstemmelse med reglerne i Forskrift F, EDI
kommunikation.
Modtagelse hos aktør
Ved modtagelse hos aktøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.10.5. Besked: Notifikation om forbrugsoplysning / Notify Volumes
Notify Volumes indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
62 / 237
Figur 46 - Klassediagram for Notifikation om forbrugsoplysning
5.10.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Kode
D23
DDQ
DDM
MDR
D43
E30
E80
Beskrivelse
Notify Volumes
Balance Supplier
Grid Access Provider
Metered data responsible
Historical information about consumption
Historical data
Change of estimated annual volume
5.10.7. Øvrig beskrivelse
Ved udveksling af change of estimated annual volume (forventet årsforbrug)
angives gyldighedsdato i StartOfOccurrence.
Ved udveksling af historical data (historiske data) og change of estimated annual
volume (forventet årsforbrug) må der kun angives 1 position.
For historical data (historiske data) og for historical information about consumption
(forbrugsinformation) angives både StartOfOccurrence og EndOfOccurrence.
I EnergyQuantity skal unitCode = KWH medtages.
Dok. 13/101713-21
63 / 237
5.10.8. Unique identification
RSM ID
RSM-010
RSM navn
Fremsend diverse forbrugsopgørelser
RSM version
EDI message for XML:
Message ID
Notify Volumes
Message name
Notifikation om forbrugsoplysning
Schema URI
Dok. 13/101713-21
64 / 237
5.11. RSM-011: Fremsend forbrug for skabelonafregnet målepunkt
samt tællerstand
5.11.1. Overblik
Fremsend forbrug for
skabelonafregnet målepunkt samt
tællerstand
DataHub
Netvirksomhed
Elleverandør
DataHub
Netvirksomhed
Elleverandør
Figur 47 - Use Case Diagram for Forbrug for skabelonafregnet målepunkt
samt tællerstand
Transaktionen benyttes af afsender til at sende en Non Continuous Metering
meddelelse (notifikation om måleraflæsning) til modtageren.
Denne meddelelse kan også anvendes som svar på følgende forretningstransaktion:
 Anmodning om måledata (RSM 015)
I disse tilfælde vil Non Continuous Metering meddelelsen indeholde en reference til
anmodningen.
Meddelelsen anvendes til følgende formål:
 Fremsendelse af forbrug og tællerstand for skabelonafregnede målepunkter
 Fremsendelse af tællerstand fra netvirksomhed.
 Fremsendelse af forslag til tællerstand fra elleverandør til netvirksomhed
5.11.2. Transaktionsstart
Transaktionen er en notifikation og initieres med en Non Continuous Metering
meddelelse med DocumentType E66. Meddelelsen kan indeholde en eller flere
transaktioner, der alle skal indeholde den samme kode for EnergyBusinessProcess.
En af følgende BusinessReasonCodes skal anvendes:
 D10 Meter reading, profiled consumption (skabelonafregnet forbrug)
 D19 Meter reading (tællerstand)
Dok. 13/101713-21
65 / 237
5.11.3. Aktivitetsdiagram
activity : Fremsend forbrug for skabelonafregnet målepunkt samt tællerstand
Afsender
Modtager
Start
Fremsend besked
med forbrug og / eller tællerstand
Notifikation om måleraflæsning
Modtag måleraflæsning
Kontrollér meddelelse
Gem informationer
Proces OK
Proces OK
Figur 48 - Aktivitetsdiagram for Forbrug for skabelonafregnet målepunkt
samt tællerstand
Afsender kan være:
 Netvirksomheden
 DataHub
 Elleverandør
Modtager kan være:
 DataHub
 Elleverandøren
 Netvirksomheden
Systemansvarlig
5.11.4. Notifikation om måleraflæsning / Non Continuous Metering
Meddelelsen sendes som beskrevet i klassediagrammet.
Meddelelsen kan indeholde følgende funktioner:
 9 Original
 5 Update (for korrektioner)
 1 Cancellation
Bemærk, at en korrektion eller annullering kun kan benyttes, hvis den oprindelige
forbrugsopgørelse for perioden er modtaget og valideret uden fejl. Hvis den første
forbrugsopgørelse er afvist på grund af fejl i meddelelsen, skal meddelelsen sendes
igen som original.
Korrektioner (5) anvendes når forbrug men ikke perioden ændres (start og slut
dato svarer til allerede indsendt periode).
Annullering (1) anvendes når forbrug og perioden ændres (start og slut dato
ændret i forhold til allerede indsendt periode). Netvirksomhed påbegynder
Dok. 13/101713-21
66 / 237
annullering med sidste indsendte opgørelse og fortsætter bagud til periode med fejl
nås. Efterfølgende sendes nye opgørelse som originale meddelelser.
Modtagelse i DataHub
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Derefter valideres meddelelsen i overensstemmelse med reglerne i Forskrift F, EDI
kommunikation.
Modtagelse hos aktør
Ved modtagelse hos aktøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.11.5. Besked: Notifikation om måleraflæsning / Non Continuous Metering
Non Continuous Metering indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 49 - Klassediagram for Notifikation om måleraflæsning
Dok. 13/101713-21
67 / 237
5.11.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
SettlementMethodCode
QuantityQualityCode
EnergyProductIdentificati
onCode
Kode
E66
DDQ
MDR
EZ
D10
D19
9
1
5
KWH
Beskrivelse
Validated metered data, time series
Balance Supplier
Metered data responsible
System Operator
Meter reading, profiled consumption
Meter reading
Original
Cancellation
Update
kWh
D01
VE production
D02
Analysis
D04
Surplus production group 6
D05
Net production
D06
Supply to grid
D07
Consumption from grid
D08
Wholesale services / information
D09
Own production
D10
Net from grid
D11
Net to grid
D12
Total consumption
D13
Grid loss correction
D14
Electrical heating
D99
Internal use
E17
Consumption
E18
Production
E20
Exchange
D04
Surplus production group 6
E01
Profiled
E02
Non profiled
D01
Flex settled
56
Estimated
E01
As read
5790001330590
Tariff
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
5.11.7. Øvrig beskrivelse
For indsendelse af forbrugsmålinger gælder:
 ProductIdentification skal være 8716867000030 (energi).
 UnitType skal være KWH.
 QuantityQuality (statuskode) skal være E01 eller 56.
 EnergyQuantity skal være uden decimaler.
 EnergyQuantity skal være en positiv værdi eller nul.
 Der må kun sendes korrektionsmeddelelser for et forbrugsinterval, hvis der
allerede er modtaget en originalmeddelelse for intervallet.
Dok. 13/101713-21
68 / 237


Angivelse af tidsintervaller skal være fortløbende (ingen huller, ingen
overlap) i relation til tidligere modtagne meddelelser ved modtagelse i
DataHub.
Hvis forbruget er en del af en forretningsproces (undtagen BRS-020:
Forbrugsopgørelse for skabelonafregnet målepunkt) skal sluttidspunktet for
tidsintervallet svare til skæringsdatoen.
For indsendelse af tællerstand gælder:
 Function skal være 9.
 ProductIdentification skal være 8716867000030 (energi).
 UnitType skal være KWH.
 Ved fremsendelse af tællerstand anvendes altid Start.
Angivelse af hvilke attributter, der skal medtages:
Forretningsårsag
Skabelonafregnet
forbrug
Tællerstand
Function
X
X
TypeOfMeteringPoint
X
SettlementMethod
X
MeteringPointIdentification
X
X
MeterIdentification
X *)
X *)
Start
X
X
End
X
EnergyQuantity
X
QuantityQuality
X
Meter Reading
X**)
X
Position
X
X
IncludedProductCharacteristic ->
Identification
X
X
UnitType
X
X
OriginalBusinessDocument
X ***)
X ***)
*) Skal anvendes i forbindelse med BRS-014: Målerhåndtering, men er optionel i
øvrige sammenhænge
**) Optionel
***) Skal anvendes i forbindelse svar på RSM-015, må ikke anvendes i øvrige
sammenhænge
5.11.8. Unique identification
RSM ID
RSM-011
RSM navn
Forbrug for skabelonafregnet målepunkt samt
tællerstand
RSM version
EDI message for XML:
Message ID
Non Continuous Metering
Message name
Notifikation om måleraflæsning
Schema URI
Dok. 13/101713-21
69 / 237
5.12. RSM-012: Fremsend måledata for et målepunkt
5.12.1. Overblik
Fremsend måledata
for et målepunkt
DataHub
Netvirksomhed
DataHub
Netvirksomhed
Systemansvarlig
Elleverandør
Figur 50 - Use Case Diagram for Fremsend måledata for et målepunkt
Transaktionen benyttes af afsender til at sende en Metered data timeseries
meddelelse (fremsend måledata for et målepunkt) til modtageren.
Denne meddelelse kan også anvendes som svar på forretningstransaktionen anmod
om måledata (RSM 015) og vil i dette tilfælde indeholde en reference til
anmodningen.
Afsender kan være:
 Netvirksomheden (MDR)
 DataHub
Modtager kan være:
 DataHub
 Elleverandøren (DDQ)
 Netvirksomheden (DDM/MDR)
 Systemansvarlig (EZ)
5.12.2. Transaktionsstart
Transaktionen er en notification og initieres med en Metered data timeseries med
documenttype E66. Meddelelsen kan indeholde en eller flere transaktioner, der alle
skal indeholde den samme kode for EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D06 Continuous meter reading from profiled metering points (skabelonafregnet
timemålt målepunkt)
 E23 Periodical metering (periodisk opgørelse)
 E30 Historical data (historisk data)
 D42 Periodical flex metering (periodisk flex opgørelse)
Modtageren af meddelelsen bliver ikke orienteret yderligere før den første
fremsendelse.
Modtagerens system skal være i stand til dynamisk at oprette relevante tidsserier i
deres system, eller systemet skal ved oprettelse af målepunktet etablere
grundlaget for modtagelse af måledata for et målepunkt.
Dok. 13/101713-21
70 / 237
5.12.3. Aktivitetsdiagram
activity : Fremsend måledata for et målepunkt
Afsender
Modtager
Start
Send måledata
Notifikation om måledata, målepunkt
Modtag måledata
Kontrollér meddelelse
Gem informationer
Proces OK
Proces OK
Figur 51 - Aktivitetsdiagram for Fremsend måledata for et målepunkt
5.12.4. Notifikation om måledata, målepunkt /Metered data time series
Meddelelsen sendes som beskrevet i klassediagrammet.
Meddelelsen kan indeholde følgende funktioner:
 9 Original
 5 Update (for korrektioner)
Anvendelsen af function lig korrektion (5) må kun anvendes ved afsendelse af
tidsserier fra DataHub.
Modtagelse i DataHub
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Derefter valideres meddelelsen i overensstemmelse med reglerne i Forskrift F, EDI
kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Hvis der ikke opdages fejl ved kontrol af meddelelsen lagres informationen og
transaktionen er slut.
I tilfælde af, at der konstateres en fejl skal meddelelsen afvises med et
Acknowledgement Document med en Reasonkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Ved fejl ved modtagelse af Acknowledgement Document skal disse håndteres
manuelt.
Dok. 13/101713-21
71 / 237
Modtagelse hos aktør
Ved modtagelse hos aktøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.12.5. Oversigt over modtagere af tidsserier for et målepunkt fra DataHub
Nedenstående tabel giver et overblik over modtagere til forskellige typer af
tidsserier. Der kan undtagelsesvis for specifikke målepunkter være yderligere
modtagere end vist i tabellen.
Netvirksomheden skal kunne modtage svar på forespørgsler på egne målepunkter
herunder også udvekslingsmålepunkter og tekniske målepunkter.
Modtagere af enkelt målepunkter (tidsserier):
Målepunktstype/afregningsform Symbol
Modtager Aktør
Forbrug - timeafregnet
FBh
Elleverandør (DDQ)
Forbrug - flexafregnet
FBf
Elleverandør (DDQ)
Forbrug - skabelonafregnet
FBp
Elleverandør (DDQ)
Produktion
P
Elleverandør, Systemansvarlig
(DDQ, EZ)
Udveksling
Ex
Nabonetvirksomhed (DDM)
Øvrige målepunkter
T
Systemansvarlig (EZ)
Elleverandør (DDQ): Øvrige
målepunkter, der kan være
tilknyttet et parent målepunkt
5.12.6. Besked: Notifikation om måledata, målepunkt /Metered data time
series
Metered data time series indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
72 / 237
Figur 52 - Klassediagram for Notifikation om måledata, målepunkt
5.12.7. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
MeasurementUnit
CommonCode
Dok. 13/101713-21
Kode
E66
DDQ
DDM
EZ
MDR
D06
D42
E23
E30
5
9
K3
Beskrivelse
Validated metered data, time series
Balance Supplier
Grid access provider
System Operator
Metered data responsible
Continuous meter reading from profiled
metering points
Periodical flex metering
Periodic metering
Historical data
Update
Original
kVArh
KWH
KWT
MAW
MWH
TNE
Z03
kWh
kW
MW
MWh
Tonne
MVAr
73 / 237
MeteringPointTypeCode
QuantityQualityCode
SettlementMethodCode
EnergyProductIdentificati
onCode
D01
VE production
D02
Analysis
D04
Surplus production group 6
D05
Net production
D06
Supply to grid
D07
Consumption from grid
D08
Wholesale services / information
D09
Own production
D10
Net from grid
D11
Net to grid
D12
Total consumption
D13
Grid loss correction
D14
Electrical heating
D99
Internal use
E17
Consumption
E18
Production
E20
Exchange
36
Revised
56
Estimated
E01
As read
D01
Flex settled
E01
Profiled
E02
Non profiled
5790001330590
Tariff
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
5.12.8. Øvrig beskrivelse
Da det er generisk transaktion, der benyttes til fremsendelse af alle type måledata
på målepunktsniveau, er det ikke muligt at specificere alle kombinationer, men
følgende gælder:
 Generelt skal der være overensstemmelse mellem de indsendte værdier af
stamdata og de registrerede værdier af stamdata på målepunktet.
 SettlementMethod anvendes kun hvis TypeOfMeteringPoint er E17 (forbrug).
 Function skal være 9 fra netvirksomhed.
 Function skal være 5 eller 9 fra DataHub.
 QuantityQuality (statuskode) skal være E01, 36, 56 hvis udfyldt, hvis ikke
skal QuantityMissing være true.
 ResolutionDuration skal være en af følgende PT15M, PT1H, P1M, P1Y
 Position (skal indeholde et antal position svarende til Resolution f. eks. time
= 24 positioner for 1 døgn).
 Antal positioner skal svare til et helt døgn eller et multiplum af døgn for
ResolutionDuration lig PT15M eller PT1H
 EnergyQuantity skal være en værdi med max 3 decimaler for KWH eller
tilsvarende opløsning for andre enheder.
 Der findes ikke målepunkter med målepunktstype Grid loss correction (D13)
 Reference (OriginalBusinessDocument) anvendes kun ved svar på RSM-015.
Dok. 13/101713-21
74 / 237
5.12.9. Unique identification
RSM ID
RSM-012
RSM navn
Fremsend måledata for et målepunkt
RSM version
EDI message for XML:
Message ID
Metered data time series
Message name
Notifikation om måledata, målepunkt
Schema URI
Dok. 13/101713-21
75 / 237
5.13. RSM-013: Fremsend andelstal
5.13.1. Overblik
Fremsend andelstal
DataHub
Elleverandør
Balanceansvarlig
Netvirksomhed
Figur 53 - Use Case Diagram for Fremsend andelstal
Forretningstransaktionen anvendes af DataHub til at sende andelstal til legitime
modtagere:
 Elleverandører
 Balanceansvarlige aktører
 Netvirksomhed
5.13.2. Transaktionsstart
Transaktionen er en notification og består af fremsendelse af Load profile
documenttype E31. En meddelelse kan indeholde en eller flere transaktioner, der
alle bruger den samme EnergyBusinessProcess.
Følgende BusinessReasonCode skal anvendes:

D02 Preparation for imbalance settlement (andelstal)
Modtageren af meddelelsen bliver ikke orienteret yderligere før den første
fremsendelse, modtagerens system skal være i stand til dynamisk at oprette
relevante data i deres system.
Dok. 13/101713-21
76 / 237
5.13.3. Aktivitetsdiagram
activity : Fremsend andelstal
DataHub
Modtager
Start
Send andelstal
Notifikation om andelstal
Modtag andelstal
Kontrollér meddelelse
Gem data
Proces OK
Proces OK
Figur 54 - Aktivitetsdiagram for Fremsend andelstal
5.13.4. Notifikation om andelstal /Load profile
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.13.5. Besked: Notifikation om andelstal /Load profile
Load profile indeholder udover header (HeaderEnergyDocument) og procesklasse
(ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
77 / 237
Figur 55 - Klassediagram for Notifikation om andelstal
5.13.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
QuantityQualityCode
SettlementMethodCode
Dok. 13/101713-21
Kode
E31
DDQ
DDK
MDR
D02
9
KWH
Beskrivelse
Aggregate metered data from the Metered Data
Aggregator, local
Balance Supplier
Balance Responsible party
Metered data responsible
Preparation for imbalance settlement
Original
kWh
E17
E01
E01
Consumption
As read
Profiled
78 / 237
ChargeTypeCode
EnergyProductIdentificati
onCode
D03
Tariff
8716867000030
Energy active
5.13.7. Øvrig beskrivelse
Aggregeringskriteriersom anvendes:
 Elleverandør
 Balanceansvarlig aktør
 Tarif
 Net
ProductIdentification skal være 8716867000030 (energi).
MeteringGridAreaIdentification skal indeholde netområde angivet som DE nummer.
Tidsangivelse i Start og End skal være lig næste kalendermåneds start og slutdato.
ResolutionDuration skal være 1 måned (P1M).
EnergyQuantity skal sendes uden decimaler.
5.13.8. Unique identification
RSM ID
RSM-013
RSM navn
Fremsend andelstal
RSM version
EDI message for XML:
Message ID
Load profile
Message name
Notifikation om andelstal
Schema URI
Dok. 13/101713-21
79 / 237
5.14. RSM-014: Fremsend beregnede tidsserier
5.14.1. Overblik
Fremsend beregnede
tidsserier
DataHub
Balanceansvarlig
Balanceafregningsansvarlig
Netvirksomhed
Systemansvarlig
Elleverandør
Figur 56 - Use Case Diagram for Fremsend beregnede tidsserier
Forretningstransaktionen anvendes af DataHub til at sende beregnede tidsserier til
legitime modtagere:
 Elleverandører (DDQ)
 Balanceansvarlige aktører (DDK)
 Netvirksomheden (MDR, DDM)
 Systemansvarlig (EZ)
 Balanceafregningansvarlig (DDX)
Denne meddelelse kan også anvendes som svar på forretningstransaktionen anmod
om måledata på aggregerede data (RSM-016) og vil i dette tilfælde indeholde en
reference til anmodningen.
5.14.2. Transaktionsstart
Transaktionen er en notification og initieres med en Aggregated MeteredData
TimeSeries (Notifikation om aggregerede tidsserier) med DocumentType E31.
Meddelelsen kan indeholde en eller flere transaktioner, der alle skal indeholde den
samme kode for EnergyBusinessProcess.
Beskeden kan indeholde en af følgende BusinessReasonCodes:
 D03 Temporary (foreløbige)
 D04 1st settlement (fiksering)
 D05 2nd settlement (refiksering)
 D09 Latest available value (tidsserie baseret på aktuelle værdier)
 D32 Correction settlement (Korrektionsafregning)
Modtageren af meddelelse bliver ikke orienteret yderligere før fremsendelse,
modtagerens system skal være i stand til dynamisk at oprette relevante tidsserier i
deres system.
Dok. 13/101713-21
80 / 237
5.14.3. Aktivitetsdiagram
activity : Fremsend beregnede tidsserier
DataHub
Modtager
Start
Fremsend beregnede
tidsserier
Notifikation om aggregerede tidsserier
Modtag beregnede tidsserier
Kontrollér meddelelse
Gem informationer
Proces OK
Figur 57 - Aktivitetsdiagram for Fremsend beregnede tidsserier
5.14.4. Notifikation om aggregerede tidsserier / Aggregated MeteredData
TimeSeries
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.14.5. Besked: Notifikation om aggregerede tidsserier / Aggregated
MeteredData TimeSeries
Aggregated MeteredData TimeSeries indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
81 / 237
Figur 58 - Klassediagram for Notifikation om aggregerede tidsserier
5.14.6. Anvendte koder
Navn
DocumentNameCode
Dok. 13/101713-21
Kode
E31
Beskrivelse
Aggregate metered data from the Metered
Data Aggregator, local
82 / 237
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
QuantityQualityCode
SettlementMethodCode
EnergyProductIdentificati
onCode
DDQ
DDK
DDM
EZ
MDR
DDX
D03
D04
D05
D09
D32
9
K3
Balance Supplier
Balance Responsible Party
Grid access provider
System Operator
Metered data responsible
Imbalance settlement responsible
Temporary
1st settlement
2nd settlement
Latest available value
Correction settlement
Original
kVArh
KWH
kWh
KWT
kW
MAW
MW
MWH
MWh
TNE
Tonne
Z03
MVAr
Z14
Danish Tariff code
H87
STK
E17
Consumption
E18
Production
E20
Exchange
D13
Grid loss correction
36
Revised
56
Estimated
E01
As read
D01
Flex settled
E01
Profiled
E02
Non profiled
5790001330590
Tariff
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
5.14.7. Øvrig beskrivelse
 Version opdateres ved udsendelse af nyt beregningsgrundlag.
 SettlementMethod anvendes kun, hvis TypeOfMeteringPoint er E17 (forbrug)
og D13 (Nettabskorrektion)
 Enten anvendes EnergyQuality og QuantityQuality ellers skal
QuantityMissing anvendes.
 QuantityQuality (statuskode) skal være en godkendt kode (dag 1 til 4 kan
manglende værdier accepteres).
 MeteringGridAreaIdentification skal indeholde netområde angivet som DE
nummer.
 For ResolutionDuration anvendes for øjeblikket kun PT1H.
Dok. 13/101713-21
83 / 237










Position (skal indeholde et antal position svarende til ResolutionDuration f.
eks. time = 24 positioner for 1 døgn).
EnergyQuantity skal være en værdi med max 3 decimaler for kWh eller
tilsvarende opløsning.
Reference (OriginalBusinessDocument) anvendes kun ved svar på RSM-016.
Currency anvendes ikke.
MeasureUnitPriceType anvendes ikke.
ChargeType anvendes ikke.
PartyChargeTypeId anvendes ikke.
ChargeTypeOwnerEnergyParty anvendes ikke.
EnergyPrice og PriceMissing anvendes ikke
EnergySum anvendes ikke
5.14.8. Unique identification
RSM ID
RSM-014
RSM navn
Fremsend beregnede tidsserier
RSM version
EDI message for XML:
Message ID
Aggregated metered data
Message name
Notifikation om aggregerede tidsserier
Schema URI
Dok. 13/101713-21
84 / 237
5.15. RSM-015: Anmod om måledata på målepunkt
5.15.1. Overblik
Anmod om måledata
på målepunkt
Elleverandør
Netvirksomhed
Systemansvarlig
DataHub
Figur 59 - Use Case Diagram for Anmod om måledata på målepunkt
Request for Validated Metered Data (anmod om måledata, målepunkt) anvendes af
elleverandør, systemansvarlig eller netvirksomhed til at forespørge om måledata på
målepunktsniveau hos DataHub.
5.15.2. Transaktionsstart
Transaktionen initieres med en Request for Validated Metered Data (anmod
måledata, målepunkt) med DocumentType E73. En meddelelse kan indeholde en
eller flere transaktioner, der alle skal anvende den samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D06 Continuous meter reading from profiled metering points (skabelonafregnet
timemålt målepunkt)
 D10 Meter reading, profiled consumption (skabelonafregnet forbrug)
 D19 Meter reading (tællerstand)
 D42 Periodical flex metering (periodisk flex opgørelse)
 D43 Historical information about consumption (forbrugsinformation)
 E23 Periodical (periodisk opgørelse)
 E30 Historical data (historiske data)
Dok. 13/101713-21
85 / 237
5.15.3. Aktivitetsdiagram
activity : Anmod om måledata på målepunkt
Afsender
DataHub
Start
Anmod måledata, målepunkt
Anmod om måledata
Modtag anmodning
Kontrollér anmodning
Afvis anmod måledata, målepunkt
Modtag
svar/måledata
Send afvisning
Anmod om
måledata
Afvist?
Transaktion
OK?
Nej
Ja
Nej
Ja
Proces slut
Kontrollér
meddelelse
Måledata
Send måledata
Gem data
Proces OK
Proces slut
Proces OK
Figur 60 - Aktivitetsdiagram for Anmod om måledata på målepunkt
5.15.4. Anmod om måledata, målepunkt/ Request for Validated Metered
Data
Meddelelsen sendes som beskrevet i klassediagrammet.
Søgekriterier
Det er op til aktøren at sammensætte en korrekt forespørgsel. Nedenstående tabel
opstiller de søgeregler der er gældende:
BusinessReason
Code
Search Criteria
E30; D43
MeteringPointIdentification
MeteringPointIdentification+ TimeSeriesPeriod
For BusinessReasonCode D10 all readings (enddates) in the
search interval will be send
D10; E23; D06;
(i.e. starttime of the first reading can be before the search
D19; D42
startdate)
Modtagelse i DataHub
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Dok. 13/101713-21
86 / 237
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.15.5. Måledata/Metered data timeseries
Hvis der ikke opdages fejl ved kontrol af Request for Validated Metered Data
meddelelsen sendes de ønskede måledata til aktøren, som angivet i de følgende
forretningstransaktioner:
 RSM-010: Fremsend diverse forbrugsopgørelser
 RSM-011: Fremsend forbrug for skabelonafregnet målepunkt og tællerstand
 RSM-012: Fremsend måledata for et målepunkt
Måledata meddelelsen vil altid indeholde en reference til den oprindelige
meddelelse.
Meddelelsen sendes som beskrevet i klassediagrammet for pågældende
forretningstransaktion.
5.15.6. Afvis anmod om måledata, målepunkt /Reject Validated Metered
Data
I tilfælde af, at der konstateres en fejl i forhold til forretningsreglerne skal
meddelelsen afvises.
Dette sker med en Reject Request Metered Data meddelelse med DocumentType
ERR og EnergyBusinessProcess. Status kode sættes til 41 (Rejected) samt
Reasoncode sat til den relevante kode fra forretningsreglerne. Desuden udfyldes
Reasontext hvis nødvendigt.
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
5.15.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.15.8. Besked: Anmod om måledata, målepunkt/ Request for Validated
Metered Data
Request for Validated Metered Data indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
87 / 237
Figur 61 - Klassediagram for Anmod om måledata, målepunkt
5.15.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Kode
E73
DDQ
DDM
EZ
MDR
D06
D10
D19
D42
D43
E23
E30
Beskrivelse
Request for Validated Metered Data
Balance Supplier
Grid access provider
System Operator
Metered data responsible
Continuous meter reading from profiled
metering points
Meter reading, profiled consumption
Meter Reading
Periodic flex metering
Historical information about consumption
Periodic metering
Historical data
5.15.10. Besked: Afvis anmod om måledata, målepunkt /Reject Request
Metered Data
Reject Validated Metered Data indeholder udover header (HeaderEnergyDocument)
og procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
88 / 237
Figur 62 - Klassediagram for Afvis anmod om måledata
5.15.11. Anvendte koder
Navn
Kode
DocumentNameCode
ERR
BusinessRoleCode
DDQ
DDM
EZ
MDR
BusinessReasonCode
D06
Response ConditionCode
ResponseReason
DescriptionCode
D10
D19
D42
D43
E23
E30
41
E10
Beskrivelse
Processability Error Report
Balance Supplier
Grid access provider
System Operator
Metered data responsible
Continuous meter reading from profiled
metering points
Meter reading, profiled consumption
Meter Reading
Periodic flex metering
Historical information about consumption
Periodic metering
Historical data
Reject
Metering point not identifiable
E16
E17
D11
D26
E0I
E0H
E50
Unauthorized balance supplier
Requested switch date not within time limits
Combination of search criteria not possible
Unauthorized TSO
Unauthorised Grid Access Provider
Data not availiable
Invalid period
5.15.12. Øvrig beskrivelse
Rollen DDM anvendes hvis der anmodes om måledata på et udvekslingsmålepunkt,
hvor netvirksomheden ikke er måleanvarlig for.
Dok. 13/101713-21
89 / 237
5.15.13. Unique identification
RSM ID
RSM-015
RSM navn
Anmod om måledata
RSM version
EDI message for XML:
Message ID
Reject Request Metered Data
Message name
Anmod om måledata, målepunkt
Schema URI
Dok. 13/101713-21
90 / 237
5.16. RSM-016: Anmod om aggregerede måledata
5.16.1. Overblik
Anmod om aggregerede
måledata
Balanceansvarlig
Balanceafregningsansvarlig
Netvirksomhed
Systemansvarlig
Elleverandør
DataHub
Figur 63 - Use Case Diagram for anmod om aggregerede måledata
Request for Aggregated Metered Data (anmod om aggregerede måledata)
anvendes af elleverandør, balanceansvarlig aktør eller netvirksomhed til at
forespørge om måledata hos DataHub.
5.16.2. Transaktionsstart
Transaktionen initieres med en Request for Aggregated Metered Data med
DocumentType E74. En meddelelse kan indeholde en eller flere transaktioner, der
alle skal anvende den samme EnergyBusinessProcess.
En





af følgende BusinessReasonCode skal anvendes:
D03 Temporary (foreløbige)
D04 1st settlement (fiksering)
D05 2nd settlement (refiksering)
D09 Latest available value (tidsserie baseret på aktuelle værdier)
D32 Correction settlement (korrektionsafregning)
Dok. 13/101713-21
91 / 237
5.16.3. Aktivitetsdiagram
activity : Anmod om aggregerede måledata
Afsender
DataHub
Start
Anmod om aggregerede
måledata
Anmod om aggregerede måledata
Modtag anmodning
Kontrollér anmodning
Afvis anmod om aggregerede måledata
Modtag
svar/måledata
Send afvisning
Anmod om
måledata
Afvist?
Transaktion
OK?
Nej
Ja
Nej
Ja
Proces slut
Kontrollér
meddelelse
Måledata, aggregerede tidsserier
Send måledata
Gem data
Proces OK
Proces slut
Proces OK
Figur 64 - Aktivitetsdiagram for anmod om aggregerede måledata
5.16.4. Anmod om aggregerede måledata / Request for Aggregated
Metered Data
Meddelelsen sendes som beskrevet i klassediagrammet.
Søgekriterier
Det er op til aktøren at sammensætte en korrekt forespørgsel. Nedenstående er
opstillet nogle af de søgeregler der er gældende, men listen er ikke udtømmende.









BalanceSupplier skal bruges i kombination med MeteringGridArea
BalanceSupplier må ikke bruges i kombination med MarketBalanceArea
BalanceSupplier kan bruges I kombination med BalanceResponsibleParty
BalanceResponsibleParty skal bruges i kombination med enten
MeteringGridArea eller MarketBalanceArea
MeteringGridArea kan bruges alene
MarketBalanceArea kan bruges alene
SettlementMethod - (E01, E02) kan kun bruges hvis TypeOfMP = E17
(forbrug)
Andre parametre skal bruges i kombination med TypeofMeteringPoint
TimeSeriesPeriod skal angives
Modtagelse i DataHub
Dok. 13/101713-21
92 / 237
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.16.5. Måledata/Metered data timeseries
Hvis der ikke opdages fejl ved kontrol af Request for Aggregated Metered Data
meddelelsen sendes de ønskede måledata til aktøren, som angivet i
 RSM-014: Fremsend beregnede tidsserier
Måledata meddelelsen vil altid indeholde en reference til den oprindelige
meddelelse.
Meddelelsen sendes som beskrevet i klassediagrammet for RSM-014.
5.16.6. Afvis anmod om aggregerede måledata/Reject Request Metered
Data Aggregated
I tilfælde af, at der konstateres en fejl i forhold til forretningsreglerne skal
meddelelsen afvises.
Dette sker med en Reject Request Metered Data Aggregated meddelelse med
DocumentType ERR og EnergyBusinessProcess. Status kode sættes til 41
(Rejected) samt Reasoncode sat til den relevante kode fra forretningsreglerne.
Desuden udfyldes Reasontext hvis nødvendigt.
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
Modtageren skal derefter modtage meddelelsen uden at sende afvisning til
DataHub.
For fejl, som normalt vil medføre en Acknowledgement, kontaktes DataHub
support.
5.16.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.16.8. Besked: Anmod om aggregerede måledata / Request for Aggregated
Metered Data
Request for Aggregated Metered Data indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
93 / 237
Figur 65 - Klassediagram for Anmod om aggregerede måledata
5.16.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
SettlementMethodCode
MeteringPointTypeCode
Dok. 13/101713-21
Kode
E74
DDQ
DDM
EZ
MDR
DDK
DDX
D03
D04
D05
D09
D32
D01
E01
E02
E17
E18
E20
D13
Beskrivelse
Request for Aggregated Metered Data
Balance Supplier
Grid access provider
System Operator
Metered data responsible
Balance Responsible Party
Imbalance Settlement Responsible
Temporary
1st settlement
2nd settlement
Latest available value
Correction settlement
Flex settled
Profiled
Non profiled
Consumption
Production
Exchange
Grid loss correction
94 / 237
5.16.10. Besked: Afvis anmod om aggregerede måledata /Reject request
aggregated metered data
Reject Request Metered Data Aggregated indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 66 - Klassediagram for Afvis anmod om aggregerede måledata
5.16.11. Anvendte koder
Navn
Kode
DocumentNameCode
ERR
BusinessRoleCode
DDQ
DDM
EZ
MDR
DDK
DDX
BusinessReasonCode
D03
D04
D05
D09
D32
Response ConditionCode
41
ResponseReason
D11
DescriptionCode
D26
E16
E18
E0I
E0H
E50
Dok. 13/101713-21
Beskrivelse
Processability Error Report
Balance Supplier
Grid access provider
System Operator
Metered data responsible
Balance Responsible Party
Imbalance Settlement Responsible
Temporary
1st settlement
2nd settlement
Latest available value
Correction settlement
Reject
Combination of search criteria not possible
Unauthorized TSO
Unauthorized balance supplier
Unauthorized balance responsible
Unauthorised Grid Access Provider
Data not availiable
Invalid period
95 / 237
5.16.12. Unique identification
RSM ID
RSM-016
RSM navn
Anmod om aggregerede måledata
RSM version
EDI message for XML:
Message ID
Request for Aggregated Metered Data
Message name
Anmod om aggregerede måledata
Schema URI
EDI message for XML:
Message ID
Reject Request Metered Data Aggregated
Message name
Afvis anmod om aggregerede måledata
Schema URI
Dok. 13/101713-21
96 / 237
5.17. RSM-017: Anmod om engrosydelser
5.17.1. Overblik
Anmod om
engrosydelser
Netvirksomhed
Systemansvarlig
Elleverandør
DataHub
Figur 67 - Use Case Diagram for anmod om engrosydelser
Request for Aggregated Billing Information (anmod om egrosydelser) anvendes af
elleverandør, balanceansvarlig aktør eller netvirksomhed til at forespørge om
engrosydelser hos DataHub.
5.17.2. Transaktionsstart
Transaktionen initieres med en Request for Aggregated Billing Information med
DocumentType D21. En meddelelse kan indeholde en eller flere transaktioner, der
alle skal anvende den samme EnergyBusinessProcess.
En




af følgende BusinessReasonCode skal anvendes:
D04 1st settlement (fiksering)
D05 2nd settlement (refiksering)
D09 Latest available value (tidsserie baseret på aktuelle værdier)
D32 Correction settlement (korrektionsafregning)
Dok. 13/101713-21
97 / 237
5.17.3. Aktivitetsdiagram
activity : Anmod om engrosydelser
Afsender
DataHub
Start
Anmod om engrosydelser
Anmod om engrosydelser
Modtag anmodning
Kontrollér anmodning
Afvis anmod om engrosydelser
Modtag
svar/engrosydelser
Send afvisning
Transaktion
OK?
Nej
Anmod om
engrosydelser afvist?
Ja
Nej
Proces slut
Ja
Kontrollér
meddelelse
Engrosydelser
Send engrosydelser
Gem data
Proces OK
Proces slut
Proces OK
Figur 68 - Aktivitetsdiagram for anmod om engrosydelser
5.17.4. Anmod om engrosydelser / Request for Aggregated Billing
Information
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.17.5. Engrosydelser
Hvis der ikke opdages fejl ved kontrol af Request for Aggregated Billing Information
meddelelsen sendes de ønskede afregningsdata til aktøren, som angivet i
Dok. 13/101713-21
98 / 237

RSM-019: Fremsend beregnede engrosydelser
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
Meddelelsen sendes som beskrevet i klassediagrammet for RSM-019.
5.17.6. Afvis anmod om engrosydelser/Reject Request for Aggregated
Billing Information
I tilfælde af, at der konstateres en fejl i forhold til forretningsreglerne skal
meddelelsen afvises.
Dette sker med en Reject Request for Aggregated Billing Information meddelelse
med DocumentType ERR og EnergyBusinessProcess. Status kode sættes til 41
(Rejected) samt Reasoncode sat til den relevante kode fra forretningsreglerne.
Desuden udfyldes Reasontext hvis nødvendigt.
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
Modtageren skal derefter modtage meddelelsen uden at sende afvisning til
DataHub.
For fejl, som normalt vil medføre en Acknowledgement, kontaktes DataHub
support.
5.17.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.17.8. Besked: Anmod om engrosydelser/ Request for Aggregated Billing
Information
Request for Aggregated Billing Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
99 / 237
Figur 69 - Klassediagram for Anmod om engrosydelser
5.17.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
ChargeTypeCode
Kode
D21
DDQ
DDM
MDR
EZ
D04
D05
D09
D32
D01
D02
D03
Beskrivelse
Request for Aggregated Billing Information
Balance Supplier
Grid access provider
Metered data responsible
System Operator
1st settlement
2nd settlement
Latest available value
Correction settlement
Subscription
Fee
Tariff
5.17.10. Øvrig beskrivelse
Latest available values (D09) kan først anvendes efter data er fikseret.
Månedsaggregering (MonthlyAggregations) skal anvendes ved BRS-030 – men må
ikke angives ved BRS-028 og BRS-029.
5.17.11. Besked: Afvis anmod om engrosydelser/Reject request aggregated
Billing Information
Reject Request Aggregated Billing Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
100 / 237
Figur 70 - Klassediagram for Afvis anmod om engrosydelser
5.17.12. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
Kode
ERR
DDQ
DDM
MDR
EZ
D04
D05
D09
D32
41
D11
Beskrivelse
Processability Error Report
Balance Supplier
Grid access provider
Metered data responsible
System Operator
1st settlement
2nd settlement
Latest available value
Correction settlement
Reject
Combination of search criteria not possible
D26
E16
E0I
E0H
E50
Unauthorized TSO
Unauthorized balance supplier
Unauthorised Grid Access Provider
Data not availiable
Invalid period
5.17.13. Unique identification
RSM ID
RSM-017
RSM navn
Anmod om engrosydelser
RSM version
EDI message for XML:
Message ID
Request for Aggregated Billing Information
Message name
Anmod om engros ydelser
Schema URI
EDI message for XML:
Message ID
Reject Request for Aggregated Billing
Information
Message name
Afvis anmod om engros ydelser
Schema URI
Dok. 13/101713-21
101 / 237
5.18. RSM-018: Fremsend hullerlog
5.18.1. Overblik
Fremsend hullerlog
DataHub
Netvirksomhed
Figur 71 - Use Case Diagram for Fremsend hullerlog
Transaktionen benyttes af DataHub til at sende en Notify missing data meddelelse
(Notifikation om manglende data) til netvirksomheden.
5.18.2. Transaktionsstart
Transaktionen er en notifikation og initieres med en Notify missing data meddelelse
med DocumentType D24. Meddelelsen kan indeholde en eller flere transaktioner,
der alle skal indeholde den samme kode for EnergyBusinessProcess.
En



af følgende BusinessReasonCodes skal anvendes:
D25 Missing non-profiled time series (hullerlog timeafregnet)
D26 Missing flex time series (hullerlog flexafregnet)
D27 Missing profiled reading (hullerlog skabelonafregnet)
5.18.3. Aktivitetsdiagram
activity : Fremsend hullerlog
DataHub
Netvirksomhed
Start
Fremsend
hullerlog
Notifikation om manglende data
Modtag hullerlog
Kontrollér meddelelse
Gem informationer
Proces OK
Proces OK
Figur 72 - Aktivitetsdiagram for Fremsend hullerlog
5.18.4. Notifikation om manglende data / Notify missing data
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Dok. 13/101713-21
102 / 237
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.18.5. Besked: Notifikation om manglende data / Notify missing data
Notify missing data indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Figur 73 - Klassediagram for Notifikation om manglende data
5.18.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
EventCode
Kode
D24
MDR
D25
D26
D27
Beskrivelse
Notify missing data
Metered data responsible
Missing non-profiled time series
Missing flex time series
Missing profiled reading
Identisk med BusinessReasoncode listen
5.18.7. Øvrig beskrivelse
EventCode er en kodeliste (DataRequestCodeType) som er identisk med
BusinessReasonCodes.
I RequestPeriod skal datotid angives i UTC tid
Dok. 13/101713-21
103 / 237
5.18.8. Unique identification
RSM ID
RSM-018
RSM navn
Fremsend hullerlog
RSM version
EDI message for XML:
Message ID
Notify missing data
Message name
Notifikation om manglende data
Schema URI
Dok. 13/101713-21
104 / 237
5.19. RSM-019: Fremsend beregnede engrosydelser
5.19.1. Overblik
Fremsend beregnede
engrosydelser
DataHub
Netvirksomhed
Systemansvarlig
Elleverandør
Figur 74 - Use Case Diagram for Fremsend beregnede engrosydelser
Forretningstransaktionen anvendes af DataHub til at sende beregnede
engrosydelser til legitime modtagere:
 Elleverandører (DDQ)
 Netvirksomheden (MDR, DDM)
 Systemansvarlig (EZ)
Denne meddelelse kan også anvendes som svar på forretningstransaktionen anmod
om engrosydelser (RSM-017) og vil i dette tilfælde indeholde en reference til
anmodningen.
5.19.2. Transaktionsstart
Transaktionen er en notifikation og initieres med en Notify aggregated wholesale
services (Notifikation om aggregerede engrosydelser) med DocumentType E31.
Meddelelsen kan indeholde en eller flere transaktioner, der alle skal indeholde den
samme kode for EnergyBusinessProcess.
Beskeden kan indeholde en af følgende BusinessReasonCodes:
 D04 1st settlement (fiksering)
 D05 2nd settlement (refiksering)
 D09 Latest available value (tidsserie baseret på aktuelle værdier)
 D32 Correction settlement (korrektionsafregning)
Modtageren af meddelelse bliver ikke orienteret yderligere før fremsendelse,
modtagerens system skal være i stand til dynamisk at oprette relevante tidsserier i
deres system.
Dok. 13/101713-21
105 / 237
5.19.3. Aktivitetsdiagram
activity : Fremsend beregnede engrosydelser
DataHub
Modtager
Start
Fremsend beregnede
engrosydelser
Notifikation om aggregerede engrosydelser
Modtag beregnede engrosydelser
Kontrollér meddelelse
Gem informationer
Proces OK
Figur 75 - Aktivitetsdiagram for Fremsend beregnede engrosydelser
5.19.4. Notifikation om aggregerede engrosydelser / Notify aggregated
wholesale services
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.19.5. Besked: Notifikation om aggregerede engrosydelser / Notify
aggregated wholesale services
Notify aggregated wholesale services indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
106 / 237
Figur 76 - Klassediagram for Notifikation om aggregerede engrosydelser
5.19.6. Anvendte koder
Navn
DocumentNameCode
Dok. 13/101713-21
Kode
E31
Beskrivelse
Aggregate metered data from the Metered
Data Aggregator, local
107 / 237
BusinessRoleCode
BusinessReasonCode
DocumentFunctionCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
QuantityQualityCode
SettlementMethodCode
ChargeTypeCode
CurrencyIdentificationCo
de
EnergyProductIdentificati
onCode
DDQ
DDM
EZ
MDR
D04
D05
D09
D32
9
KWH
Balance Supplier
Grid access provider
System Operator
Metered data responsible
1st settlement
2nd settlement
Latest available value
Correction settlement
Original
kWh
H87
D01
D04
D05
D06
D07
D08
D09
D10
D11
D12
D13
D14
D99
E17
E18
E20
D01
D01
E01
E02
D01
D02
D03
DKK
STK
VE production
Surplus production group
Net production
Supply to grid
Consumption from grid
Wholesale services / information
Own production
Net from grid
Net to grid
Total consumption
Net loss correction
Electrical heating
Internal use
Consumption
Production
Exchange
Calculated
Flex settled
Profiled
Non profiled
Subscription
Fee
Tariff
Denmark – Krone
5790001330590
Tariff
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
5.19.7. Øvrig beskrivelse
 Version opdateres ved udsendelse af nyt beregningsgrundlag.
 SettlementMethod anvendes kun hvis TypeOfMeteringPoint er E17 (forbrug)
og D13 (Nettabskorrektion)
 Enten anvendes EnergyPrice eller PriceMissing.
 Reference (OriginalBusinessDocument) anvendes kun ved svar på RSM-017.
 MeteringGridArea skal indeholde netområde angivet som DE nummer.
 ResolutionDuration skal være en af følgende PT1H, P1D, P1M
Dok. 13/101713-21
108 / 237






Position (skal indeholde et antal position svarende til ResolutionDuration f.
eks. time = 24 positioner for 1 døgn)
MeasurementUnitCommonCode udfyldes med KWH eller H87.
For udsendelse af månedssum anvendes KWH i
MeasurementUnitCommonCode
EnergyQuantity skal være en værdi med max 3 decimaler for kWh eller
tilsvarende opløsning.
QuantityMissing anvendes ikke.
EnergyPrice angives med op til 6 decimaler.
EnergySum angives med op til 2 decimaler.
5.19.8. Unique identification
RSM ID
RSM-019
RSM navn
Fremsend beregnede engrosydelser
RSM version
EDI message for XML:
Message ID
Notify aggregated wholesale services
Message name
Notifikation om aggregerede engrosydelser
Schema URI
Dok. 13/101713-21
109 / 237
5.20. RSM-020: Forespørg om serviceydelse
5.20.1. Overblik
Forespørg om
serviceydelse
Elleverandør
DataHub
DataHub
Netvirksomhed
Figur 77 - Use Case Diagram for Anmod om serviceydelse
Forretningstransaktionen anvendes af elleverandøren til at sende en Request
Service til netvirksomheden via målepunktsadministratoren (DataHub).
5.20.2. Transaktionsstart
Transaktionen startes af en Request Service meddelelse (Anmod om serviceydelse)
med DocumentType D03. En meddelelse kan indeholde en eller flere transaktioner,
der alle anvender den samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 E20 End of supply (leveranceophør)
 D22 Servicerequest (serviceanmodning)
Dok. 13/101713-21
110 / 237
5.20.3. Aktivitetsdiagram
activity : Forespørg om serviceydelse
Elleverandør / Datahub
DataHub / Netvirksomhed
Start
Anmod serviceydelse
Send forespørgsel
Modtag forespørgsel
Kontrollér forespørgsel
Afvis serviceydelse
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend serviceydelse
Godkendt?
Send bekræftelse
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 78 - Aktivitetsdiagram for Forespørg om serviceydelse
5.20.4. Anmod om serviceydelse /Request Service
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse af DataHub / Netvirksomhed
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
Ved modtagelse valideres meddelelsen derefter i overensstemmelse med reglerne i
Forskrift F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Documentet vil indeholde en fejlkode og en reference til den
oprindelige meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
Hvis DataHub ikke finder fejl videresendes Request Service til netvirksomheden.
Netvirksomheden behandler anmodningen om serviceydelse og sender svar.
Dok. 13/101713-21
111 / 237
5.20.5. Godkend serviceydelse /Confirm Service
Confirm Service sendes, hvis netvirksomheden kan imødekomme anmodningen om
service ydelse.
Bekræftelsen sendes med meddelelsen Confirm Service med DocumentType D04
for alle de godkendte transaktioner.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Confirm Service vil altid indeholde en reference til den oprindelige meddelelse.
5.20.6. Afvis serviceydelse /Reject Service
Reject Service sendes i 2 tilfælde:
 Hvis der er konstateret fejl i forhold til forretningsregler, skal transaktionen
afvises.
 Hvis netvirksomheden ikke kan imødekomme anmodningen.
Afvisningen sendes med meddelelsen Reject service med DocumentType D04.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject service vil altid indeholde en reference til den oprindelige meddelelse.
Modtager elleverandøren en Reject Service kan denne efterfølgende rette sit
system og sende en ny Request Service for målepunktet.
5.20.7. Behandling af svar hos elleverandøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.20.8. Besked: Anmod om serviceydelse / Request Service
Request Service indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
112 / 237
Figur 79 - Klassediagram for Anmod om serviceydelse
5.20.9. Anvendte koder
Navn
Kode
DocumentNameCode D03
BusinessRoleCode
DDQ
DDM
BusinessReasonCode E20
D22
ServiceRequestCode D01
D02
D03
D04
D05
D06
D07
D08
D09
D10
D11
D12
D13
D14
D15
Beskrivelse
Request service
Balance Supplier
Grid Access Provider
End of supply
Servicerequest
Disconnect
Close down
Connect
Reading request
Meter check
Flex change
Non-profiled change
Disconnect due to end of supply
The municipality is involved in the
disconnection
The police in involved in the disconnection
The bailiff's court is involved in the
disconnection
Ordinary disconnection – agreed with the
customer
Other reason
Establish electric heating
Remove electric heating
5.20.10. Besked: Godkend serviceydelse/Confirm Service
Confirm Service indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
113 / 237
Figur 80 - Klassediagram for Godkend serviceydelse
5.20.11. Anvendte koder
Navn
Kode
DocumentNameCode
D04
BusinessRoleCode
DDQ
DDM
BusinessReasonCode
E20
D22
Response
39
ConditionCode
Beskrivelse
Response Service request
Balance Supplier
Grid Access Provider
End of supply
Servicerequest
Approved
5.20.12. Besked: Afvis serviceydelse / Reject Service
Reject Service indeholder udover header (HeaderEnergyDocument) og procesklasse
(ProcessEnergyContext) en Payload klasse.
Figur 81 - Klassediagram for Afvis serviceydelse
5.20.13. Anvendte koder
Navn
Kode
Dok. 13/101713-21
Beskrivelse
114 / 237
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
D04
DDQ
DDM
E20
D22
41
D28
Response Service request
Balance Supplier
Grid Access Provider
End of supply
Servicerequest
Rejected
Service request rejected
D02
D41
General error
The municipality must be involved in the
disconnection
The police must be involved in the
disconnection
The bailiff’s court must be involved in the
disconnection
Other rejection reason
Rejection 5
Violated process
Illegal request
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
Unauthorised Grid Access Provider
D42
D43
D44
D45
D20
D27
E10
E16
E17
E0I
5.20.14. Unique identification
RSM ID
RSM-020
RSM navn
Forespørg om serviceydelser
RSM version
EDI message for XML:
Message ID
Request Service
Message name
Anmod start af leverance
Schema URI
EDI message for XML:
Message ID
Confirm Service
Message name
Godkend serviceydelse
Schema URI
EDI message for XML:
Message ID
Reject Service
Message name
Afvis serviceydelse
Schema URI
Dok. 13/101713-21
115 / 237
5.21. RSM-021: Ændring af målepunkt stamdata
5.21.1. Overblik
Ændring af
målepunkt stamdata
Netvirksomhed
DataHub
Figur 82 - Use Case Diagram for Ændring af målepunkt stamdata
Forretningstransaktionen anvendes af en netvirksomhed til at sende opdaterede
stamdata på et målepunkt til målepunktsadministratoren.
5.21.2. Transaktionsstart
Transaktionen startes af en Request Update Master Data MeteringPoint (Anmod
opdater stamdata, målepunkt) med DocumentType E58. En meddelelse kan
indeholde en eller flere transaktioner, der alle anvender samme
EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D14 Close down metering point (nedlæg målepunkt)
 D15 Connect meteringpoint (tilslut målepunkt)
 D39 Production Obligation (aftagepligt)
 E02 New metering point (nyt målepunkt)
 E20 End of supply (leveranceophør)
 E32 Update master data for metering point (opdater stamdata målepunkt)
 E67 Placement of Meter (skift af måler)
 E75 Change of metering method (ændr afregningsform)
 E79 Change of connection status (ændr tilslutningsstatus)
Dok. 13/101713-21
116 / 237
5.21.3. Aktivitetsdiagram
activity : Ændring af målepunkt stamdata
Netvirksomhed
DataHub
Start
Anmod opdater stamdata, målepunkt
Send anmeldelse
Modtag anmeldelse
Kontrollér anmeldelse
Afvis opdater stamdata, målepunkt
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend opdater stamdata, målepunkt
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 83 - Aktivitetsdiagram for Ændring af målepunkt stamdata
5.21.4. Anmod opdater stamdata, målepunkt / Request Update Master Data
MeteringPoint
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Document vil indeholde en fejlkode.
Acknowledgement Document vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.21.5. Godkend opdater stamdata, målepunkt / Confirm Update Master
Data MeteringPoint
Hvis meddelelsen valideres korrekt i DataHub lagres informationen og der sendes
en bekræftelse Confirm Update Master Data MeteringPoint med DocumentType E59
for alle de godkendte transaktioner til aktøren.
Dok. 13/101713-21
117 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Godkend opdatering af målepunkt stamdata vil altid indeholde en reference til den
oprindelige meddelelse.
5.21.6. Afvis opdater stamdata, målepunkt / Reject Update Master Data
MeteringPoint
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject Update Master Data
MeteringPoint med DocumentType E59.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject Update Master Data MeteringPoint vil altid indeholde en reference til den
oprindelige meddelelse.
Modtager aktøren en Reject Update Master Data MeteringPoint kan aktøren
efterfølgende rette sit system og sende en ny anmodning om opdatering af
afregningsstamdata.
5.21.7. Behandling af svar hos aktøren
Ved modtagelse hos aktøren valideres meddelelsen i overensstemmelse med
reglerne i Forskrift F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.21.8. Besked: Anmod opdater stamdata, målepunkt / Request Update
Master Data MeteringPoint
Request Update Master Data MeteringPoint indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
118 / 237
Figur 84 - Klassediagram for Anmod opdater stamdata, målepunkt
Dok. 13/101713-21
119 / 237
5.21.9. Øvrig beskrivelse
Til håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser i afsnit 7: Håndtering af stamdata.
Ved opdatering af målerinformation (BRS-006: Fremsendelse af stamdata) er det
kun nødvendigt at medsende ændrede målerattributter.
Målepunkter af MeteringPointType D13 kan ikke oprettes.
Følgende regler gælder for indsendelse af stamdata:
 For alle MeteringPointType undtaget D01, D02 og D99 skal
EnergyProductIdentification være Energy active.
 For alle MeteringPointType undtaget D01, D02 og D99 skal skal
MeasurementUnit være kWh
 Hvis MeteringPointType er E17 (forbrug) og SettlementMethod er E01
(skabelonafregnet) og hvis NetSettlementGroup er lig 6 (solceller) må der
kun angives en ScheduledMeterReadingDate
 Ved skift af MPReadingCharacteristics fra D02 (manuel) til D01 (automatisk)
skal HourlyTimeSeries (Ja/Nej) medsendes. Hvis HourlyTimeSeries sættes til
Ja skal MeterReadingOccurrence sættes til PT1H ellers skal
MeterReadingOccurrence skal den sættes til ANDET.
 Ved ændring af MeteringPointType og SubTypeOfMeteringpoint lig fysisk skal
alle målerattributter medtages jævnfør BRS-006: Fremsendelse af stamdata
 Ved ændring af SubTypeOfMeteringpoint fra status fysisk til virtuel eller
beregnet fjerner DataHub alle målerinformationer fra målepunktet.
 Ved oprettelse af et fysisk målepunkt skal alle målerattributter medtages.
 Function må kun anvendes i forbindelse med håndtering af måler (BRS-014:
Målerhåndtering)
 ProductObligation kan kun anvendes af System Operator (EZ).
 MPCapacity skal medsendes for forbrugs- og produktions-målepunkter, hvor
nettoafregningsgruppe er forskellig fra gruppe 0. Må ikke medsendes for
forbrugs- og produktions-målepunkter, hvor nettoafregningsgruppe er
gruppe 0. Kan sendes for D01 og D05 til D12 målepunkter.
 MPConnectionType medtages kun for forbrugs- og produktions-målepunkter,
hvor nettoafregningsgruppe er forskellig fra gruppe 0. Feltet må ikke
medsendes i andre situationer.
 For MeteringPointType E17 gælder følgende vedrørende
MeterReadingOccurrence og MPReadingCharacteristics:
Dok. 13/101713-21
120 / 237
1
Type Of
Meteringpoint
Consumption
E17
Settlement
Method
Profiled
E01
4
7
P1M
Meter Reading Occurrence
PT1H
PT15M
ANDET
Allowed
Allowed
Allowed
Non-profiled
E02
Flex
D01
3
6
P1Y
Manual
D02
2
5
MPReading
Characteristics
Automatic
D01
Allowed
Allowed
Production
E18
Exchange
E20
D01, D02, D04, D05,
D06, D07, D08, D09,
D10, D11, D12, D13,
D14, D99
5.21.10. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
PhysicalStatusCode
MPReadingCharacteristicsCo
de
SettlementMethodCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
Dok. 13/101713-21
Allowed
Kode
E58
Allowed
Allowed
Allowed
Allowed
Allowed
Allowed
DDM
EZ
D14
D15
D39
E02
E20
E32
E67
E75
E79
D02
D03
E22
E23
Beskrivelse
Request to change metering point
attributes
Grid Access Provider
System Operator
Close down metering point
Connect meteringpoint
Production Obligation
New metering point
End of supply
Update master data metering point
Placement of Meter
Change of metering method
Change of connection status
Closed down
New
Connected
Disconnected
D01
Automatic meter reading
D02
D01
E01
E02
K3
Manual meter reading
Flex settled
Profiled
Non profiled
kVArh
KWH
KWT
MAW
MWH
TNE
Z03
D01
D02
D04
D05
D06
D07
D08
D09
kWh
kW
MW
MWh
Tonne
MVAr
VE production
Analysis
Surplus production group
Net production
Supply to grid
Consumption from grid
Wholesale services / information
Own production
121 / 237
MeteringPointSubTypeCode
MeterReadingTypeCode
DocumentFunctionCode
DisconnectionTypeCode
MPConnectionTypeCode
MPAddressWashInstruction
TypeCode
EnergyProductIdentification
Code
D10
D11
D12
D13
D14
D99
E17
E18
E20
D01
D02
D03
D01
D02
2
3
4
D01
D02
D01
D02
D01
Net from grid
Net to grid
Total consumption
Grid loss correction
Electrical heating
Internal use
Consumption
Production
Exchange
Physical
Virtual
Calculated
Accumulated
Balanced
Addition
Deletion
Change
Remote disconnection
Manual disconnection
Direct connected
Installation connected
Washabel
D02
Not washabel
5790001330590
Tariff
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
5.21.11. Besked: Godkend opdater stamdata, målepunkt / Confirm Update
Master Data MeteringPoint
Confirm Update Master Data MeteringPoint indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
Charge Event klasse.
Dok. 13/101713-21
122 / 237
Figur 85 - Klassediagram for Godkend opdater stamdata, målepunkt
5.21.12. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
Kode
E59
DDM
D14
D15
D39
E02
E20
E32
E67
E75
E79
39
Beskrivelse
Confirm change metering point attributes
Grid Access Provider
Close down metering point
Connect meteringpoint
Production Obligation
New metering point
End of supply
Update master data metering point
Placement of Meter
Change of metering method
Change of connection status
Confirmed
5.21.13. Besked: Afvis opdater stamdata, målepunkt / Reject Update
Master Data MeteringPoint
Reject Update Master Data MeteringPoint indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 86 - Klassediagram for Afvis opdater stamdata, målepunkt
5.21.14. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Dok. 13/101713-21
Kode
E59
DDM
D14
D15
D39
E02
E20
E32
E67
E75
E79
Beskrivelse
Confirm change metering point attributes
Grid Access Provider
Close down metering point
Connect meteringpoint
Production Obligation
New metering point
End of supply
Update master data metering point
Placement of Meter
Change of metering method
Change of connection status
123 / 237
Response ConditionCode
ResponseReason
DescriptionCode
41
D15
Rejected
Incorrect settlement
D16
D18
D19
D31
D33
D34
D36
D46
E10
E17
E0I
E16
Incorrect connection status
Incorrect type of meteringpoint
Functioncode not allowed
Incorrect meter information according to rules
Metering point is part of a calculation structure
Parent metering point has children
Metering point cannot be connected
Incorrect Metering GridArea
Metering point not identifiable
Requested switch date not within time limits
Unauthorised Grid Access Provider
Unauthorized balance supplier
5.21.15. Unique identification
RSM ID
RSM-021
RSM navn
Ændring af målepunkt stamdata
RSM version
EDI message for XML:
Message ID
Request to change metering point attributes
Message name
Anmod opdater stamdata, målepunkt
Schema URI
EDI message for XML:
Message ID
Confirm change of metering point attributes
Message name
Godkend opdater stamdata, målepunkt
Schema URI
EDI message for XML:
Message ID
Reject change of metering point attributes
Message name
Afvis opdater stamdata, målepunkt
Schema URI
Dok. 13/101713-21
124 / 237
5.22. RSM-022: Fremsend målepunkt stamdata
5.22.1. Overblik
Fremsend målepunkt
stamdata
DataHub
Elleverandør
Figur 87 - Use Case Diagram for Fremsend målepunkt stamdata
Forretningstransaktionen anvendes af målepunktsadministratoren til at sende
stamdata på et målepunkt til elleverandøren.
5.22.2. Transaktionsstart
Transaktionen startes af en Notify Master Data MeteringPoint (Notifikation om
stamdata, målepunkt) med DocumentType E07. En meddelelse kan indeholde en
eller flere transaktioner, der alle anvender samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D07 Rollback Change-of-supplier (genoptag leverance)
 D15 Connect meteringpoint (tilslut målepunkt)
 D21 Move-in due to other reason (tilflytning af anden årsag)
 D29 Secondary move-in (tilflytning sekundær)
 D30 Switch with short notice (skift med kort varsel)
 D31 Transfer metering point (overflyt målepunkt)
 D33 Incorrect move (fejlagtig flytning)
 D36 Continue supply of customer (genoptag kundeforhold)
 D39 Production Obligation (aftagepligt)
 E02 New metering point (nyt målepunkt)
 E03 Change of balance supplier (skift af elleverandør)
 E06 Unrequested change of balance supplier (overflyt til forsyningspligtig
elleverandør)
 E32 Update master data for metering point (opdater målepunkt)
 E56 Change of Balance Responsible Party (skift af balanceansvarlig aktør)
 E65 Customer move-in (almindelig tilflytning)
 E67 Placement of Meter (skift af måler)
 E75 Change of metering method (ændr afregningsform)
 E79 Change of connection status (ændr tilslutningsstatus)
5.22.3. Aktivitetsdiagram
Dok. 13/101713-21
125 / 237
activity : Fremsend målepunkt stamdata
DataHub
Elleverandør
Start
Send Notifikation om
stamdata, målepunkt
Notifikation om stamdata, målepunkt
Modtag meddelelse
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 88 - Aktivitetsdiagram for Fremsend målepunkt stamdata
5.22.4. Notifikation om stamdata, målepunkt / Notify Master Data
MeteringPoint
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.22.5. Besked: Notifikation om stamdata, målepunkt / Notify Master Data
MeteringPoint
Notify Master Data MeteringPoint indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
126 / 237
Dok. 13/101713-21
127 / 237
Figur 89 - Klassediagram for Notifikation om stamdata, målepunkt
5.22.6. Øvrig beskrivelse
I afsnit 7: Håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser.
Function bliver kun medsendt i forbindelse med BRS-014: Målerhåndtering.
5.22.7. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
PhysicalStatusCode
MPReadingCharacteristics
Code
SettlementMethodCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
Dok. 13/101713-21
Kode
E07
DDQ
D07
D15
D21
D29
D30
D31
D33
D36
D39
E02
E03
E06
E32
E56
E65
E67
E75
E79
D02
D03
E22
E23
Beskrivelse
Notify Master Data MeteringPoint
Balance Sypplier
Rollback Change-of-supplier
Connect meteringpoint
Move-in due to other reason
Secondary move-in
Switch with short notice
Transfer metering point
Incorrect move
Continue supply of customer
Production Obligation
New metering point
Change of balance supplier
Unrequested change of balance supplier
Update master data metering point
Change of Balance Responsible Party
Customer move-in
Placement of Meter
Change of metering method
Change of connection status
Closed down
New
Connected
Disconnected
D01
Automatic meter reading
D02
D01
E01
E02
K3
Manual meter reading
Flex settled
Profiled
Non profiled
kVArh
KWH
KWT
MAW
MWH
TNE
Z03
D01
D02
D04
D05
kWh
kW
MW
MWh
Tonne
MVAr
VE production
Analysis
Surplus production group
Net production
128 / 237
MeteringPointSubTypeCode
MeterReadingTypeCode
DisconnectionTypeCode
MPConnectionTypeCode
MPAddressWashInstruction
TypeCode
DocumentFunctionCode
D06
D07
D08
D09
D10
D11
D12
D13
D14
D99
E17
E18
E20
D01
D02
D03
D01
D02
D00
D01
D02
D00
D01
D02
D01
Supply to grid
Consumption from grid
Wholesale services / information
Own production
Net from grid
Net to grid
Total consumption
Grid loss correction
Electrical heating
Internal use
Consumption
Production
Exchange
Physical
Virtual
Calculated
Accumulated
ResetAfterReading
Not determined
Remote disconnection
Manual disconnection
Not determined
Direct connected
Installation connected
Washabel
D02
2
3
4
Not washabel
Addition
Deletion
Change
5.22.8. Unique identification
RSM ID
RSM-022
RSM navn
Fremsend målepunkt stamdata
RSM version
EDI message for XML:
Message ID
Notify Master Data MeteringPoint
Message name
Notifikation om stamdata, målepunkt
Schema URI
Dok. 13/101713-21
129 / 237
5.23. RSM-023: Forespørg om målepunkt stamdata (svar)
5.23.1. Overblik
Forespørg om målepunkt
stamdata (svar)
DataHub
Netvirksomhed
Elleverandør
Figur 90 - Use Case Diagram for Forespørg om målepunkt stamdata
Response Master Data MeteringPoint (svar forespørg stamdata, målepunkt)
anvendes som svar på en Query all master data (forespørg om stamdata) i RSM006.
Svaret sker på målepunktsniveau.
5.23.2. Transaktionsstart
Denne transaktion er svaret på forespørg om stamdata, RSM-006 (Query all master
data). Afhængigt af hvilken aktør, som har initieret forespørgslen, sendes svaret til
enten elleverandør eller netvirksomhed.
Transaktionen sendes med en Response MasterData MeteringPoint (Svar forespørg
stamdata, målepunkt) med DocumentType D20.
En meddelelse kan indeholde en eller flere transaktioner, der alle anvender samme
EnergyBusinessProcess.
Den følgende BusinessReasonCode skal anvendes:
 E0G Data alignment for master data metering point (stamdata til kontrol)
Dok. 13/101713-21
130 / 237
5.23.3. Aktivitetsdiagram
activity : Forespørg om målepunkt stamdata (svar)
DataHub
Netvirksomhed / Elleverandør
Start
Send Notifikation om
stamdata, målepunkt
Svar forespørg stamdata, målepunkt
Modtag notifikation
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 91 - Aktivitetsdiagram for Forespørg om målepunkt stamdata
5.23.4. Svar forespørg stamdata, målepunkt / Response MasterData
MeteringPoint
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.23.5. Besked: Svar forespørg stamdata, målepunkt / Response
MasterData MeteringPoint
Response MasterData MeteringPoint indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) og en Payload
klasse.
Dok. 13/101713-21
131 / 237
Dok. 13/101713-21
132 / 237
Figur 92 - Klassediagram for Svar forespørg stamdata, målepunkt
5.23.6. Øvrig beskrivelse
I afsnit 7: Håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser.
Function bliver ikke medsendt.
5.23.7. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
PhysicalStatusCode
MPReadingCharacteristicsCo
de
SettlementMethodCode
MeasurementUnit
CommonCode
MeteringPointTypeCode
MeteringPointSubTypeCode
Dok. 13/101713-21
Kode
D20
DDM
DDQ
E0G
D02
D03
E22
E23
Beskrivelse
Response MasterData MeteringPoint
Grid Access Provider
Balance Supplier
Data alignment for master data metering
point
Closed down
New
Connected
Disconnected
D01
Automatic meter reading
D02
D01
E01
E02
K3
Manual meter reading
Flex settled
Profiled
Non profiled
kVArh
KWH
KWT
MAW
MWH
TNE
Z03
D01
D02
D04
D05
D06
D07
D08
D09
D10
D11
D12
D13
D14
D99
E17
E18
E20
D01
D02
D03
kWh
kW
MW
MWh
Tonne
MVAr
VE production
Analysis
Surplus production group
Net production
Supply to grid
Consumption from grid
Wholesale services / information
Own production
Net from grid
Net to grid
Total consumption
Grid loss correction
Electrical heating
Internal use
Consumption
Production
Exchange
Physical
Virtual
Calculated
133 / 237
DisconnectionTypeCode
MPConnectionTypeCode
MPAddressWashInstruction
TypeCode
D01
D02
D01
D02
D01
Remote disconnection
Manual disconnection
Direct connected
Installation connected
Washabel
D02
Not washabel
5.23.8. Unique identification
RSM ID
RSM-023
RSM navn
Forespørg om målepunkt stamdata
RSM version
EDI message for XML:
Message ID
Response Master Data MeteringPoint
Message name
Svar forespørg stamdata, målepunkt
Schema URI
Dok. 13/101713-21
134 / 237
5.24. Tomt afsnit
Dette afsnit er med vilje tomt for at sikre nummerkonsistens mellem RSM numre og
afsnitsnumre.
Dok. 13/101713-21
135 / 237
5.25. Tomt afsnit
Dette afsnit er med vilje tomt for at sikre nummerkonsistens mellem RSM numre og
afsnitsnumre.
Dok. 13/101713-21
136 / 237
5.26. Tomt afsnit
Dette afsnit er med vilje tomt for at sikre nummerkonsistens mellem RSM numre og
afsnitsnumre.
Dok. 13/101713-21
137 / 237
5.27. RSM-027: Ændring af kundestamdata
5.27.1. Overblik
Ændring af
kundestamdata
Elleverandør
DataHub
Figur 93 - Use Case Diagram for Ændring af kundestamdata
Forretningstransaktionen anvendes af en elleverandøren til at sende opdaterede
kundestamdata på et målepunkt til målepunktsadministratoren.
5.27.2. Transaktionsstart
Transaktionen initieres af en elleverandør som sender en Request Update Master
Data Consumer (Anmod opdater stamdata, kunde) med DocumentType D15. En
meddelelse kan indeholde en eller flere transaktioner, der alle anvender samme
EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 E03 Change of balance supplier (skift af elleverandør)
 E34 Update master data consumer (opdater stamdata kunde)
 E65 Customer move-in (almindelig tilflytning)
 D21 Move-in due to other reason (tilflytning af anden årsag)
 D29 Secondary move-in (tilflytning sekundær)
 D30 Switch with short notice (skift med kort varsel)
Dok. 13/101713-21
138 / 237
5.27.3. Aktivitetsdiagram
activity : Ændring af kundestamdata
Elleverandør
DataHub
Start
Anmod opdater stamdata, kunde
Send opdatering
Modtag opdatering
Kontrollér meddelelse
Afvis opdater stamdata, kunde
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend opdater stamdata, kunde
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 94 - Aktivitetsdiagram for Ændring af kunde stamdata
5.27.4. Anmod opdater stamdata, kunde / Request Update Master Data
Consumer
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Ved indholdsfejl vil Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.27.5. Godkend opdater stamdata, kunde / Confirm Update Master Data
Consumer
Hvis meddelelsen valideres korrekt i DataHub lagres informationen og der sendes
en bekræftelse Confirm Update Master Data Meter med DocumentType D16 for alle
de godkendte transaktioner til aktøren.
Dok. 13/101713-21
139 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Godkend opdatering af målepunkt Kunde vil altid indeholde en reference til den
oprindelige meddelelse.
5.27.6. Afvis opdater stamdata, Kunde / Reject Update Master Data
Consumer
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject Update Master Data
Consumer med DocumentType D16.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject Update Master Data Consumer vil altid indeholde en reference til den
oprindelige meddelelse.
Modtager aktøren en Reject Update Master Data Consumer kan aktøren
efterfølgende rette sit system og sende en ny anmodning om opdatering af
kundestamdata.
5.27.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
Aktøren modtager meddelelsen uden at sende bekræftelse eller afvisning til
DataHub.
For syntaksfejl i meddelelsen gælder, at beskeden afvises synkront med en SOAP
exception.
For andre fejl, som normalt vil medføre en Acknowledgement, kontaktes DataHub
Support.
5.27.8. Besked: Anmod opdater stamdata, kunde / Request Update Master
Data Consumer
Request Update Master Data Consumer indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
140 / 237
Figur 95 - Klassediagram for Anmod opdater stamdata, kunde
5.27.9. Øvrig beskrivelse
I afsnit 7: Håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser.
Følgende attributter kan aldrig opdateres med ændring af kundestamdata:
 MeteringPointIdentification
 WebAccessCode

StartDate

HasBalanceSupplier
Dok. 13/101713-21
141 / 237
Såfremt CVR (kundeCVR) er udfyldt i FirstConsumerConsumerParty må
SecondConsumerConsumerPartyName aldrig være udfyldt, men CVR
(DataagangsCVR) for SecondConsumerConsumerParty skal udfyldes.
CPR/CVR må kun anvendes, hvis Name er udfyldt i FirstConsumerConsumerParty.
CPR må kun anvendes, hvis Name er udfyldt i SecondConsumerConsumerParty.
For kontaktadresser gælder at for hver adressetype (MPRelationType) kun må de
maksimalt sendes 1 gang.
5.27.10. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
PaymentConditionCodeTy
pe
MP_RelationType
Kode
D15
DDQ
E03
E34
E65
D21
D29
D30
D01
Beskrivelse
Request update Metering Point Party
Balance Supplier
Change of balance supplier
Update master data consumer
Customer move-in
Move-in due to other reason
Secondary move-in
Switch with short notice
On account payment/prepaid
D02
D03
D04
D05
On account payment/postpaid
On account payment/ Mixed prepaid-post paid
Supplied electricity/postpaid
On account payment/prepaid - combined with
adjustment for previous payment period
Disconnection card
Reading card
Voting card
Address 4
D01
D02
D03
D04
5.27.11. Besked: Godkend opdater stamdata, kunde / Confirm Update
Master Data Consumer
Confirm Update Master Data Consumer indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
Charge Event klasse.
Dok. 13/101713-21
142 / 237
Figur 96 - Klassediagram for Godkend opdater stamdata, kunde
5.27.12. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
Kode
D16
DDQ
E03
E34
E65
D21
D29
D30
39
Beskrivelse
Response update Metering Point party
Balance Supplier
Change of balance supplier
Update master data consumer
Customer move-in
Move-in due to other reason
Secondary move-in
Switch with short notice
Confirmed
5.27.13. Besked: Afvis opdater stamdata, kunde / Reject Update Master
Data Consumer
Reject Update Master Data Consumer indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 97 - Klassediagram for Afvis opdater stamdata, kunde
5.27.14. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
Dok. 13/101713-21
Kode
D16
DDQ
E03
E34
E65
D21
D29
D30
41
D16
Beskrivelse
Response update Metering Point party
Balance Supplier
Change of balance supplier
Update master data consumer
Customer move-in
Move-in due to other reason
Secondary move-in
Switch with short notice
Rejected
Incorrect connection status
143 / 237
DescriptionCode
D17
D18
E10
E16
E17
Incorrect CPR/CVR
Incorrect type of meteringpoint
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
5.27.15. Unique identification
RSM ID
RSM-027
RSM navn
Ændring af kunde stamdata
RSM version
EDI message for XML:
Message ID
Request Update Masterdata Consumer
Message name
Anmod opdater stamdata, kunde
Schema URI
EDI message for XML:
Message ID
Confirm Update Masterdata Consumer
Message name
Godkend opdater stamdata, kunde
Schema URI
EDI message for XML:
Message ID
Reject Update Masterdata Consumer
Message name
Afvis opdater stamdata, kunde
Schema URI
Dok. 13/101713-21
144 / 237
5.28. RSM-028: Fremsend kunde stamdata
5.28.1. Overblik
Fremsend kunde
stamdata
DataHub
Netvirksomhed
Elleverandør
Netvirksomhed
Figur 98 - Use Case Diagram for Fremsend kunde stamdata
Forretningstransaktionen anvendes af målepunktsadministratoren til at sende
kunde stamdata på et målepunkt til elleverandør elleverandør eller netvirksomhed.
Afsender er normalt DataHub, men i forbindelse med fremsendelse af forslag om
kontaktinformation er netvirksomheden afsender.
5.28.2. Transaktionsstart
Transaktionen startes af en Notify Master Data Consumer (Notifikation om
stamdata, kunde) med DocumentType E21. En meddelelse kan indeholde en eller
flere transaktioner, der alle anvender samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D07 Rollback Change-of-supplier (genoptag leverance)
 D21 Move-in due to other reason (tilflytning af anden årsag)
 D28 Proposal contact information (forslag kontaktinformation)
 D29 Secondary move-in (tilflytning sekundær)
 D30 Switch with short notice (skift med kort varsel)
 D31 Transfer metering point (overflyt målepunkt)
 D33 Incorrect move (fejlagtig flytning)
 D36 Continue supply of customer (genoptag kundeforhold)
 E03 Change of balance supplier (skift af elleverandør)
 E06 Unrequested change of balance supplier (overflyt til forsyningspligtig
elleverandør)
 E20 End of supply (leveranceophør)
 E34 Update master data consumer (opdater stamdata kunde)
 E65 Customer move-in (almindelig tilflytning)
 E66 Consumer move-out (fraflytning)
5.28.3. Aktivitetsdiagram
Dok. 13/101713-21
145 / 237
activity : Fremsend kunde stamdata
DataHub
Elleverandør / Netvirksomhed
Start
Send Notifikation om
stamdata, kunde
Notifikation om stamdata, kunde
Modtag stamdata
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 99 - Aktivitetsdiagram for Fremsend kunde stamdata
5.28.4. Notifikation om stamdata, kunde / Notify Master Data Consumer
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.28.5. Besked: Notifikation om stamdata, Kunde / Notify Master Data
Consumer
Notify Master Data Consumer indeholder udover header (HeaderEnergyDocument)
og procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
146 / 237
Figur 100 - Klassediagram for Notifikation om stamdata, kunde
5.28.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Dok. 13/101713-21
Kode
E21
DDQ
DDM
D07
D21
D28
D29
D30
Beskrivelse
Master data, Consumer
Balance Supplier
Grid Access Provider
Rollback Change-of-supplier
Move-in due to other reason
Proposal contact information
Secondary move-in
Switch with short notice
147 / 237
MP_RelationType
D31
D33
D36
E03
E06
E20
E34
E65
E66
D01
D02
D03
D04
Transfer metering point
Incorrect move
Continue supply of customer
Change of balance supplier
Unrequested change of balance supplier
End of supply
Update master data consumer
Customer move-in
Customer move-out
Disconnection card
Reading card
Voting card
Address 4
5.28.7. Øvrig beskrivelse
I afsnit 7: Håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser.
Ved anvendelse til fremsendelse af kontaktinformation fra netvirksomhed til
elleverandør skal følgende attributter ikke medtages:
 ElectricalHeating
 ElectricalHeatingDate
 WebAccessCode
 Cosumercategory
 FirstConsumerParty
 SecondConsumerParty
 HasBalanceSupplier
 SupplyStart
5.28.8. Unique identification
RSM ID
RSM-028
RSM navn
Fremsend kunde stamdata
RSM version
EDI message for XML:
Message ID
Notify Masterdata Consumer
Message name
Notifikation om stamdata, kunde
Schema URI
Dok. 13/101713-21
148 / 237
5.29. RSM-029: Forespørg om kunde stamdata (svar)
5.29.1. Overblik
Forespørg om kunde
stamdata (svar)
DataHub
Netvirksomhed
Elleverandør
Figur 101 - Use Case Diagram for Forespørg om kunde stamdata
Response Master Data Consumer (Svar forespørg stamdata, kunde) anvendes som
svar på en Query all master data (anmod forespørg stamdata) i RSM-006.
Svaret sker på målepunktsniveau.
5.29.2. Transaktionsstart
Denne transaktion er svaret på forespørg om stamdata, RSM-006 (Query all master
data). Afhængigt af hvilken aktør, som har initieret forespørgslen, sendes svaret til
enten elleverandør eller netvirksomhed.
Transaktionen sendes med en Response MasterData, Consumer (Svar forespørg
stamdata, måler) med DocumentType D17.
En meddelelse kan indeholde en eller flere transaktioner, der alle anvender samme
EnergyBusinessProcess.
Den følgende BusinessReasonCode skal anvendes:
 E0G Data alignment for master data metering point (stamdata til kontrol)
Dok. 13/101713-21
149 / 237
5.29.3. Aktivitetsdiagram
activity : Forespørg om kunde stamdata (svar)
DataHub
Netvirksomhed / Elleverandør
Start
Send Notifikation om
stamdata, kunde
Svar forespørg stamdata, kunde
Modtag svar
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 102 - Aktivitetsdiagram for Forespørg om kunde stamdata
5.29.4. Svar forespørg stamdata, kunde/ Response MasterData, Consumer
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.29.5. Besked: Svar forespørg stamdata, kunde / Response MasterData,
Consumer
Response MasterData, Consumer indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) nedenstående
Payload Charge Event klasse.
Dok. 13/101713-21
150 / 237
Figur 103 - Klassediagram for Svar forespørg stamdata, kunde
5.29.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
MP_RelationType
Dok. 13/101713-21
Kode
D17
DDM
DDQ
E0G
D01
Beskrivelse
Response MasterData Party
Grid Access Provider
Balance Supplier
Data alignment for master data metering point
Disconnection card
151 / 237
D02
D03
D04
Reading card
Voting card
Address 4
5.29.7. Øvrig beskrivelse
I afsnit 7: Håndtering af stamdata findes en nærmere beskrivelse af de forskellige
attributter, der skal anvendes for forskellige målepunktstyper og forskellige
forretningsprocesser.
Kun nuværende elleverandør på målepunkt får PaymentCondition med i svar.
5.29.8. Unique identification
RSM ID
RSM-029
RSM navn
Forespørg om kunde stamdata (svar)
RSM version
EDI message for XML:
Message ID
Response Master Data Consumer
Message name
Svar forespørg stamdata, kunde
Schema URI
Dok. 13/101713-21
152 / 237
5.30. RSM-030: Ændring af afregningsstamdata
5.30.1. Overblik
Ændring af
afregningsstamdata
Netvirksomhed
Elleverandør
TSO
DataHub
Figur 104 - Use Case Diagram for Ændring af afregningsstamdata
Forretningstransaktionen anvendes af en aktør til at sende opdaterede
afregningsstamdata på et målepunkt til målepunktsadministratoren.
5.30.2. Transaktionsstart
Transaktionen kan initieres af
 Netvirksomheden
 Elleverandør
 TSO
Transaktionen startes af en Request Update Master Data Charge (Anmod opdater
stamdata, afregning) med DocumentType D05. En meddelelse kan indeholde en
eller flere transaktioner, der alle anvender samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D17 Update masterdata settlement (Opdater stamdata afregning)
Dok. 13/101713-21
153 / 237
5.30.3. Aktivitetsdiagram
activity : Ændring af afregningsstamdata
Afsender
DataHub
Start
Anmod opdater stamdata, afregning
Send opdatering
Modtag anmeldelse
Kontrollér meddelelse
Afvis opdater stamdata, afregning
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend opdater stamdata, afregning
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 105 - Aktivitetsdiagram for Ændring af afregningsstamdata
5.30.4. Anmod opdater stamdata, afregning / Request Update Master Data
Charge
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Document vil indeholde en fejlkode.
Acknowledgement Document vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.30.5. Godkend opdater stamdata, afregning / Confirm Update Master
Data Charge
Hvis meddelelsen valideres korrekt i DataHub lagres informationen og der sendes
en bekræftelse Confirm Update Master Data Charge med DocumentType D06 for
alle de godkendte transaktioner til aktøren.
Dok. 13/101713-21
154 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Godkend opdatering af afregning stamdata vil altid indeholde en reference til den
oprindelige meddelelse.
5.30.6. Afvis opdater stamdata, afregning / Reject Update Master Data
Charge
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject Update Master Data
Charge med DocumentType D06.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject Update Master Data Charge vil altid indeholde en reference til den
oprindelige meddelelse.
Modtager aktøren en Reject Update Master Data Charge kan aktøren efterfølgende
rette sit system og sende en ny anmodning om opdatering af afregningsstamdata.
5.30.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.30.8. Besked: Anmod opdater stamdata, afregning / Request Update
Master Data Charge
Request Update Master Data Charge indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
155 / 237
Figur 106 - Klassediagram for Anmod opdater stamdata, afregning
5.30.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
ChargeTypeCode
DocumentFunctionCode
Kode
D05
DDM
DDQ
EZ
D17
D01
D02
D03
2
3
4
Beskrivelse
Request Update Master Data Charge
Grid Access Provider
Balance Supplier
System Operator
Update masterdata settlement
Subscription
Fee
Tariff
Addition
Deletion
Change
5.30.10. Øvrig beskrivelse
For tarif gælder at ”ChargeOccurrences” altid skal være 1. For abonnement og
gebyrer skal ChargeOccurences være et heltal større end 0.
I afsnit 7 Stamdata er der angivet hvilke attributter der skal anvendes for
forskellige målepunktstyper og forskellige forretningsprocesser.
5.30.11. Besked: Godkend opdater stamdata, afregning / Confirm Update
Master Data Charge
Confirm Update Master Data Charge indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
156 / 237
Figur 107 - Klassediagram for Godkend opdater stamdata, afregning
5.30.12. Anvendte koder
Navn
Kode
DocumentNameCode
D06
BusinessRoleCode
DDM
DDQ
EZ
BusinessReasonCode
D17
Response ConditionCode
39
Beskrivelse
Response Master Data Charge
Grid Access Provider
Balance Supplier
System Operator
Update masterdata settlement
Aproved
5.30.13. Besked: Afvis opdater stamdata, afregning / Reject Update Master
Data Charge
Reject Update MasterData Charge indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 108 - Klassediagram for Afvis opdater stamdata, afregning
5.30.14. Anvendte koder
Navn
Kode
Dok. 13/101713-21
Beskrivelse
157 / 237
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Response ConditionCode
ResponseReason
DescriptionCode
D06
DDM
DDQ
EZ
D17
41
D14
Response MasterData Charge
Grid Access Provider
Balance Supplier
System Operator
Update masterdata settlement
Rejected
Incorrect charge information
D16
D18
D26
E10
E16
E17
E50
E0I
Incorrect connection status
Incorrect type of meteringpoint
Unauthorized TSO
Metering point not identifiable
Unauthorized balance supplier
Requested switch date not within time limits
Invalid period
Unauthorised Grid Access Provider
5.30.15. Unique identification
RSM ID
RSM-030
RSM navn
Ændring af afregningsstamdata
RSM version
EDI message for XML:
Message ID
Request Update Master Data Charge
Message name
Anmod opdater stamdata, afregning
Schema URI
EDI message for XML:
Message ID
Confirm Update Master Data Charge
Message name
Godkend opdater stamdata, afregning
Schema URI
EDI message for XML:
Message ID
Reject Update Master Data Charge
Message name
Afvis opdater stamdata, afregning
Schema URI
Dok. 13/101713-21
158 / 237
5.31. RSM-031: Fremsend afregningsstamdata
5.31.1. Overblik
Fremsend
afregningsstamdata
DataHub
Elleverandør
Netvirksomhed
Figur 109 - Use Case Diagram for Fremsend afregningsstamdata
Forretningstransaktionen anvendes af målepunktsadministratoren til at sende
afregnings stamdata på et målepunkt til elleverandør og /eller netvirksomhed.
5.31.2. Transaktionsstart
Transaktionen startes af en Notify Master Data Charge (Notifikation om stamdata,
afregning) med DocumentType D07. En meddelelse kan indeholde en eller flere
transaktioner, der alle anvender samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:
 D07 Rollback Change-of-supplier (genoptag leverance)
 D17 Update masterdata settlement (opdater stamdata afregning)
 D21 Move-in due to other reason (tilflytning af anden årsag)
 D29 Secondary move-in (tilflytning sekundær)
 D30 Switch with short notice (skift med kort varsel)
 D31 Transfer metering point (overflyt målepunkt)
 D33 Incorrect move (fejlagtig flytning)
 D36 Continue supply of customer (genoptag kundeforhold)
 E02 New metering point (nyt målepunkt)
 E03 Change of balance supplier (skift af elleverandør)
 E06 Unrequested change of balance supplier (overflyt til forsyningspligtig
elleverandør)
 E32 Update master data for metering point (opdater stamdata målepunkt)
 E65 Customer move-in (almindelig tilflytning)
Dok. 13/101713-21
159 / 237
5.31.3. Aktivitetsdiagram
activity : Fremsend afregningsstamdata
DataHub
Elleverandør/Netvirksomhed
Start
Send Notifikation om
stamdata, afregning
Notifikation om stamdata, afregning
Modtag notifikation
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 110 - Aktivitetsdiagram for Fremsend afregningsstamdata
5.31.4. Notifikation om stamdata, afregning / Notify Master Data Charge
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.31.5. Besked: Notifikation om stamdata, afregning / Notify Master Data
Charge
Notify Master Data Charge indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) en Payload klasse.
Dok. 13/101713-21
160 / 237
Figur 111 - Klassediagram for Notifikation om stamdata, afregning
5.31.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
ChargeTypeCode
DocumentFunctionCode
Dok. 13/101713-21
Kode
D07
DDQ
DDM
D07
D17
D21
D29
D30
D31
D33
D36
E01
E02
E03
E06
E32
E65
D01
D02
D03
2
3
4
Beskrivelse
Notify Master Data Charge
Balance Supplier
Grid Access Provider
Rollback Change-of-supplier
Update masterdata settlement
Move-in due to other reason
Secondary move-in
Switch with short notice
Transfer metering point
Incorrect move
Continue supply of custome
Move
New metering point
Change of balance supplier
Unrequested change of balance supplier
Update master data metering point
Customer move-in
Subscription
Fee
Tariff
Addition
Deletion
Change
161 / 237
5.31.7. Øvrig beskrivelse
I afsnit 7 Stamdata er der angivet hvilke attributter der skal anvendes for
forskellige målepunktstyper og forskellige forretningsprocesser.
5.31.8. Unique identification
RSM ID
RSM-031
RSM navn
Fremsend afregningsstamdata
RSM version
EDI message for XML:
Message ID
Notify Master Data Charge
Message name
Notifikation om stamdata, afregning
Schema URI
Dok. 13/101713-21
162 / 237
5.32. RSM-032: Forespørg om afregningsstamdata
5.32.1. Overblik
Forespørg om
afregningsstamdata
Netvirksomhed
Elleverandør
TSO
DataHub
Figur 112 - Use Case Diagram for afregningsstamdata
Query Master Data Charge (forespørg stamdata, afregning) anvendes af
elleverandør og netvirksomhed til at forespørge om afregnings stamdata på et
målepunkt. Anmodning skal ske på målepunktsniveau.
5.32.2. Transaktionsstart
Transaktionen kan initieres af
 Netvirksomhed
 Elleverandør
 TSO
Transaktionen benyttes af afsender til at sende en Query Master Data Charge med
DocumentType D08 (forespørg stamdata, afregning) til målepunktsadministratoren
(DataHub). En meddelelse kan indeholde en eller flere transaktioner, der alle skal
anvende den samme EnergyBusinessProcess.
Den følgende BusinessReasonCode skal anvendes:
 E0G Data alignment for master data metering point (stamdata til kontrol)
Dok. 13/101713-21
163 / 237
5.32.3. Aktivitetsdiagram
activity : Forespørg om afregningsstamdata
Afsender
DataHub
Start
Forespørg stamdata, afregning
Anmod om stamdata, afregning
Modtag anmodning
Kontrollér meddelelse
Afvis forespørg stamdata, afregning
Modtag
svar/stamdata
Send afvisning
Anmod om
stamdata, afregning
Afvist?
Transaktion
OK?
Nej
Ja
Nej
Ja
Proces slut
Kontrollér
meddelelse
Svar forespørg stamdata, afregning
Send stamdata, afregning
Gem data
Proces OK
Proces slut
Proces OK
Figur 113 - Aktivitetsdiagram for Forespørg om afregningsstamdata
5.32.4. Forespørg stamdata afregning / Query Master Data Charge
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Herefter valideres meddelelsen i overensstemmelse med reglerne i Forskrift F, EDI
kommunikation.
Acknowledgement Document vil indeholde en fejlkode.
Acknowledgement Document vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.32.5. Svar forespørg stamdata, afregning / Response Master Data Charge
Hvis der ikke opdages fejl ved kontrol af Query meddelelsen sendes de ønskede
stamdata (Response Master Data Charge) til aktøren med DocumentType D09.
Dok. 13/101713-21
164 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess E0G som forespørgslen. Herefter er transaktionen slut.
Response Master Data Charge vil altid indeholde en reference til den oprindelige
meddelelse.
Stamdata sendes med de informationer, der er gældende på det tidspunkt,
anmodningen modtages.
Antallet af attributter vil variere afhængig af modtagerens rolle.
5.32.6. Afvis forespørg stamdata, afregning / Reject Master Data Charge
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
meddelelsen afvises.
Dette sker med meddelelsen Reject Master Data Charge med DocumentType D09.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess E0G som forespørgslen og afvisning sker ved at sætte
statuskode til 41 (rejected) og Reason sat til den relevante kode fra
forretningsreglerne.
Meddelelsen vil altid indeholde en reference til den oprindelige meddelelse.
Modtageren kan efterfølgende rette sit system og sende en ny Query MasterData
Charge for målepunktet.
5.32.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.32.8. Besked: Forespørg stamdata, afregning / Query Master Data Charge
Query Master Data Charge indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) nedenstående Payload Charge Event klasse.
Dok. 13/101713-21
165 / 237
Figur 114 - Klassediagram for Forespørg stamdata, afregning
5.32.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Kode
D08
DDM
DDQ
EZ
E0G
Beskrivelse
Query Master Data Charge
Grid Access Provider
Balance Supplier
System Operator
Data alignment for master data metering point
5.32.10. Besked: Svar forespørg stamdata, afregning / Response Master
Data Charge
Response Master Data Charge indeholder udover header (HeaderEnergyDocument)
og procesklasse (ProcessEnergyContext) nedenstående Payload Charge Event
klasse.
Dok. 13/101713-21
166 / 237
Figur 115 - Klassediagram for svar forespørg stamdata, afregning
5.32.11. Anvendte koder
Navn
Kode
DocumentNameCode
D09
BusinessRoleCode
DDM
DDQ
EZ
BusinessReasonCode
E0G
ChargeTypeCode
D01
D02
D03
Beskrivelse
Response Master Data Charge
Grid Access Provider
Balance Supplier
System Operator
Data alignment for master data metering point
Subscription
Fee
Tariff
5.32.12. Øvrig beskrivelse
I afsnit 7 Stamdata er der angivet hvilke attributter der skal anvendes for
forskellige målepunktstyper og forskellige forretningsprocesser.
5.32.13. Besked: Afvis forespørg stamdata, afregning / Reject Master Data
Charge
Reject Master Data Charge indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) nedenstående Payload Charge Event klasse.
Dok. 13/101713-21
167 / 237
Figur 116 - Klassediagram for afvis forespørg stamdata, afregning
5.32.14. Anvendte koder
Navn
Kode
DocumentNameCode
D09
BusinessRoleCode
DDM
DDQ
EZ
BusinessReasonCode
E0G
Response ConditionCode
41
ResponseReason
D26
DescriptionCode
E10
E16
E50
E0I
E0H
Beskrivelse
Response Master Data Charge
Grid Access Provider
Balance Supplier
System Operator
Data alignment for master data metering point
Rejected
Unauthorized TSO
Metering point not identifiable
Unauthorized balance supplier
Invalid period
Unauthorised Grid Access Provider
Data not availiable
5.32.15. Unique identification
RSM ID
RSM-032
RSM navn
Forespørg om afregningsstamdata
RSM version
EDI message for XML:
Message ID
Query Master Data Charge
Message name
Forespørg stamdata afregning
Schema URI
EDI message for XML:
Message ID
Response Master Data Charge
Message name
Svar forespørg stamdata, afregning
Schema URI
EDI message for XML:
Message ID
Reject Master Data Charge
Message name
Afvis forespørg stamdata, afregning
Schema URI
Dok. 13/101713-21
168 / 237
5.33. RSM-033: Ændring af prisliste
5.33.1. Overblik
Ændring af prisliste
Netvirksomhed
TSO
DataHub
Figur 117 - Use Case Diagram for Ændring af prisliste
Forretningstransaktionen anvendes af en aktør til at sende en opdateret prisliste til
målepunktsadministratoren.
5.33.2. Transaktionsstart
Transaktionen kan initieres af
 Netvirksomheden
 TSO
Transaktionen startes af en Request Update Charge Information (Anmod opdater
prisliste) med DocumentType D10. En meddelelse kan indeholde en eller flere
transaktioner, der alle anvender samme EnergyBusinessProcess.
En af følgende BusinessReasonCode skal anvendes:

D18 Update charge information (opdater prisinformation)
Dok. 13/101713-21
169 / 237
5.33.3. Aktivitetsdiagram
activity : Ændring af prisliste
Afsender
DataHub
Start
Anmod opdater prisliste
Send opdatering
Modtag opdatering
Kontrollér meddelelse
Afvis opdater prisliste
Modtag svar
Send afvisning
Transaktion
OK?
Nej
Ja
Behandl svar
Proces slut
Godkend opdater prisliste
Send bekræftelse
Godkendt?
Nej
Ja
Proces OK
Ret fejl
Proces OK
Figur 118 - Aktivitetsdiagram for Ændring af prisliste
5.33.4. Anmod opdater prisliste /Request Update Charge Information
Meddelelse sendes som beskrevet i klassediagrammet.
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation og en evt. fejl rapporteres via en Acknowledgement
Document.
Acknowledgement Document vil indeholde en fejlkode.
Acknowledgement Document vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende verificeres hver transaktion i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
5.33.5. Godkend opdater prisliste / Confirm Update Charge Information
Hvis meddelelsen valideres korrekt i DataHub lagres informationen og der sendes
en bekræftelse (Confirm update Charge information) med DocumentType D11 for
alle de godkendte transaktioner til netvirksomheden.
Dok. 13/101713-21
170 / 237
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Godkend opdatering af prisliste vil altid indeholde en reference til den oprindelige
meddelelse.
5.33.6. Afvis opdater prisliste / Reject Update Charge Information
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen og sende en ny anmodning om
opdatering med DocumentType D11.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject Update Charge Information vil altid indeholde en reference til den
oprindelige meddelelse.
Modtager netvirksomheden en Reject Update Charge Information kan denne
efterfølgende rette sit system og sende en ny anmodning om opdatering af
prisliste.
5.33.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.33.8. Besked: Anmod opdater prisliste / Request Update Charge
Information
Request Update Charge Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Dok. 13/101713-21
171 / 237
Figur 119 - Klassediagram for Anmod opdater prisliste
5.33.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
ChargeTypeCode
VATClassCode
DocumentFunctionCode
Kode
D10
DDM
EZ
D18
D01
D02
D03
D01
D02
2
3
4
Beskrivelse
Request Update Charge Information
Grid Access Provider
System Operator
Update charge information
Subscription
Fee
Tariff
No VAT
VAT
Addition
Deletion
Change
5.33.10. Øvrig beskrivelse
TaxIndicator kan kun sættes til true for ChargeTypeCode D03 (tarif), for de øvrige
koder skal den sættes til false.
I IntervalEnergyObservation angives 0, 1 eller 24 positioner.
Dok. 13/101713-21
172 / 237
5.33.11. Besked: Godkend opdater prisliste / Confirm Update Charge
Information
Confirm Update Charge information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 120 - Klassediagram for Godkend opdater prisliste
5.33.12. Anvendte koder
Navn
Kode
DocumentNameCode
D11
BusinessRoleCode
DDM
EZ
BusinessReasonCode
D18
ResponseConditionCode
39
Beskrivelse
Response Update Charge Information
Grid Access Provider
System Operator
Update charge information
Approved
5.33.13. Besked: Afvis opdater prisliste / Reject Update Charge Information
Reject Update Charge Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) en Payload
klasse.
Figur 121 - Klassediagram for Afvis opdater prisliste
Dok. 13/101713-21
173 / 237
5.33.14. Anvendte koder
Navn
Kode
DocumentNameCode
D11
BusinessRoleCode
DDM
EZ
BusinessReasonCode
D18
Response ConditionCode
41
ResponseReason
D14
DescriptionCode
D19
D23
D26
D27
E17
E87
E90
E0I
Beskrivelse
Response update Charge information
Grid Access Provider
System Operator
Update charge information
Rejected
Incorrect charge information
Functioncode not allowed
Resolution not correct
Unauthorized TSO
Illegal request
Requested switch date not within time limits
Number of observations dosn't fit observation
period/resolution
Measurement beyond plausibility limits
Unauthorised Grid Access Provider
5.33.15. Unique identification
RSM ID
RSM-033
RSM navn
Ændring af prisliste
RSM version
EDI message for XML:
Message ID
Request Update Charge Information
Message name
Anmod opdater prisliste
Schema URI
EDI message for XML:
Message ID
Confirm Update Charge Information
Message name
Godkend opdater prisliste
Schema URI
EDI message for XML:
Message ID
Reject Update Charge Information
Message name
Afvis opdater prisliste
Schema URI
Dok. 13/101713-21
174 / 237
5.34. RSM-034: Fremsend prisliste
5.34.1. Overblik
Fremsend prisliste
DataHub
Elleverandør
Netvirksomhed
Figur 122 - Use Case Diagram for Fremsend prisliste
Forretningstransaktionen anvendes af målepunktsadministratoren til at sende en
prisliste til elleverandør og /eller netvirksomhed.
5.34.2. Transaktionsstart
Transaktionen startes af en Notify Charge Information (notifikation om prisliste)
med DocumentType D12. En meddelelse kan indeholde en eller flere transaktioner,
der alle anvender samme EnergyBusinessProcess.
Den følgende BusinessReasonCode skal anvendes:
 D18 Update masterdata charge (opdater stamdata prisinformation)
5.34.3. Aktivitetsdiagram
activity : Fremsend prisliste
DataHub
Elleverandør/Netvirksomhed
Start
Send Notifikation om prisliste
Notifikation om prisliste
Modtag notifikation
Kontrollér meddelelse
Meddelelse
OK?
Nej
Ja
Gem informationer
Proces OK
Proces OK
Fejl
Håndter manuelt
Figur 123 - Aktivitetsdiagram for Fremsend prisliste
5.34.4. Notifikation om prisliste / Notify charge information
Meddelelse sendes som beskrevet i klassediagrammet.
Dok. 13/101713-21
175 / 237
Modtagelse
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.34.5. Besked: Notifikation om prisliste / Notify charge information
Notify Charge Information indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) nedenstående Payload klasse.
Figur 124 - Klassediagram for Notifikation om prisliste
5.34.6. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
Dok. 13/101713-21
Kode
D12
DDQ
Beskrivelse
Notify charge information
Balance Supplier
176 / 237
BusinessReasonCode
ChargeTypeCode
VATClassCode
DocumentFunctionCode
DDM
D18
D01
D02
D03
D01
D02
2
3
4
Grid Access Provider
Update masterdata charge
Subscription
Fee
Tariff
No VAT
VAT
Addition
Deletion
Change
5.34.7. Unique identification
RSM ID
RSM-034
RSM navn
Fremsend prisliste
RSM version
EDI message for XML:
Message ID
Notify charge information
Message name
Notifikation om prisliste
Schema URI
Dok. 13/101713-21
177 / 237
5.35. RSM-035: Forespørg om prisliste
5.35.1. Overblik
Forespørg om prisliste
Netvirksomhed
Elleverandør
TSO
DataHub
Figur 125 - Use Case Diagram for Forespørg om prisliste
Query Charge Information (Forespørg om prisliste) anvendes af elleverandør,
netvirksomhed og TSO til at forespørge om prislister. Forespørgsel kan ske med
følgende kriterier:
 Aktør
 Pristype
 Pristype ID
 Datointerval
5.35.2. Transaktionsstart
Transaktionen initieres med en Query Charge Informatin med DocumentType D13.
En meddelelse kan indeholde en eller flere transaktioner, der alle skal anvende den
samme EnergyBusinessProcess.
Følgende BusinessReasonCode skal anvendes
 E0G Data alignment for master data metering point (stamdata til kontrol)
Dok. 13/101713-21
178 / 237
5.35.3. Aktivitetsdiagram
activity : Forespørg om prisliste
Afsender
DataHub
Start
Forespørg om prisliste
Forespørg om prisliste
Modtag forespørgsel
Kontrollér meddelelse
Afvis forespørg om prisliste
Modtag
svar/prisliste
Forespørg om
prisliste
Afvist?
Send afvisning
Transaktion
OK?
Nej
Ja
Ja
Nej
Proces slut
Kontrollér
meddelelse
Svar forespørg om prisliste
Send prisliste
Gem data
Proces OK
Proces slut
Proces OK
Figur 126 - Aktivitetsdiagram for forespørg om prisliste
5.35.4. Forespørg om prisliste / Query Charge Information
Meddelelsen sendes som beskrevet i klassediagrammet.
Modtagelse
I tilfælde af at der sker verifikationsfejl i forhold til skemaet, skal meddelelsen
afvises synkront med en SOAP Exception.
Derefter valideres meddelelsen i overensstemmelse med reglerne i Forskrift F, EDI
kommunikation og en evt. fejl rapporteres via en Acknowledgement Document.
Acknowledgement Documentet vil indeholde en fejlkode.
Acknowledgement Documentet vil altid indeholde en reference til den oprindelige
meddelelse.
Efterfølgende skal hver transaktion verificeres i overensstemmelse med
forretningsreglerne, som beskrevet i Forretningsprocesser for det danske elmarked.
I tilfælde af at der sker verifikationsfejl i forhold til skemaet eller indholdet, skal
meddelelsen afvises.
Dok. 13/101713-21
179 / 237
5.35.5. Svar forespørg om prisliste / Response Query Charge Information
Hvis meddelelsen valideres korrekt, sendes den ønskede prisliste (Response Query
Charge Information) til aktøren med Document Type D14.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og godkendelsen sker ved at sætte
statuskoden til 39 (approved). Herefter er transaktionen slut.
Godkend forespørgsel af prisliste vil altid indeholde en reference til den oprindelige
meddelelse.
5.35.6. Afvis forespørg om prisliste / Reject Query Charge Information
I tilfælde af, at der konstateres en fejl i forhold til forretningsregler skal
transaktionen afvises. Dette sker med meddelelsen Reject Query Charge
Information med DocumentType D14.
Meddelelsen sendes som beskrevet i klassediagrammet indeholdende samme
EnergyBusinessProcess som anmeldelsen, og afvisning sker ved at sætte status
kode til 41 (Rejected) og Reason sat til den relevante kode fra forretningsreglerne.
Reject Query Charge Information vil altid indeholde en reference til den oprindelige
meddelelse.
Modtager elleverandøren, netvirksomheden eller TSO en Reject Charge Information
kan aktøren efterfølgende rette sin forespørgsel og sende en ny forespørgsel om
prisliste.
5.35.7. Behandling af svar hos aktøren
Ved modtagelse valideres meddelelsen i overensstemmelse med reglerne i Forskrift
F, EDI kommunikation.
Ved indholdsfejl, som normalt vil medføre en Acknowledgement, skal der ske
henvendelse til DataHub Support.
5.35.8. Besked: Forespørg om prisliste / Query charge information
Query Charge Information indeholder udover header (HeaderEnergyDocument) og
procesklasse (ProcessEnergyContext) nedenstående Payload Request Charge
Information klasse.
Dok. 13/101713-21
180 / 237
Figur 127 - Klassediagram for Forespørg på prisliste
5.35.9. Anvendte koder
Navn
DocumentNameCode
BusinessRoleCode
BusinessReasonCode
Kode
D13
DDM
DDQ
EZ
E0G
Beskrivelse
Query Charge information
Grid Access Provider
Balance Supplier
Systemoperator
Data alignment for master data metering point
5.35.10. Besked: Svar forespørg om prisliste / Response Query charge
information
Response Query Charge Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) nedenstående
Payload Charge Information klasse.
Dok. 13/101713-21
181 / 237
Figur 128 - Klassediagram for Svar forespørg om prisliste
5.35.11. Anvendte koder
Navn
Kode
DocumentNameCode
D14
BusinessRoleCode
DDM
DDQ
EZ
BusinessReasonCode
E0G
ChargeTypeCode
D01
D02
D03
VATClassCode
D01
D02
Beskrivelse
Response Charge information
Grid Access Provider
Balance Supplier
Systemoperator
Data alignment for master data metering point
Subscription
Fee
Tariff
No VAT
VAT
5.35.12. Besked: Afvis Forespørg om prisliste / Reject Query charge
information
Dok. 13/101713-21
182 / 237
Reject Query Charge Information indeholder udover header
(HeaderEnergyDocument) og procesklasse (ProcessEnergyContext) nedenstående
Payload Charge Event klasse.
Figur 129 - Klassediagram for Afvis forespørgsel af prisliste
5.35.13. Anvendte koder
Navn
Kode
DocumentNameCode
D14
BusinessRoleCode
DDM
DDQ
EZ
BusinessReasonCode
E0G
ResponseReason
D26
DescriptionCode
E16
E0I
E0H
E50
Beskrivelse
Response Charge information
Grid Access Provider
Balance Supplier
Systemoperator
Data alignment for master data metering point
Unauthorized TSO
Unauthorized balance supplier
Unauthorised Grid Access Provider
Data not availiable
Invalid period
5.35.14. Unique identification
RSM ID
RSM-035
RSM navn
Forespørg om prisliste
RSM version
EDI message for XML:
Message ID
Query Charge Information
Message name
Forespørg om prisliste
Schema URI
EDI message for XML:
Message ID
Response Query Charge Information
Message name
Forespørg om prisliste
Schema URI
EDI message for XML:
Message ID
Reject Query Charge Information
Message name
Afvis forespørg om prisliste
Schema URI
Dok. 13/101713-21
183 / 237
6. Kodelister
I det følgende afsnit vises de mulige værdier og betydning af enumererede koder.
Det tilladte værdisæt af en kodeliste kan være begrænset i hver enkelt meddelelse
ud fra et forretningsmæssigt perspektiv. I tilfælde hvor den samme kodeliste bliver
brugt flere gange i samme meddelelse vil kodelisten da indeholde
foreningsmængden af tilladte værdier i den pågældende meddelelse.
Dok. 13/101713-21
184 / 237
6.1. Datadefinitioner for BusinessReasonCode
Kode
D02
D03
D04
D05
D06
D07
D09
D10
D11
D12
D13
D14
D15
D16
D17
D18
D19
D20
D21
D22
D23
D24
D25
D26
D27
D28
D29
D30
D31
D32
D33
D34
D35
D36
D37
Beskrivelse
Preparation for imbalance
settlement
Temporary
1st settlement
2nd settlement
Continuous meter reading
from profiled metering
points
Rollback Change-ofsupplier
Latest available value
Meter reading, profiled
consumption
Incorrect process
Cancel meter reading
request
Change of supply to
supplier of last resort
Close down metering point
Connect meteringpoint
Update masterdata
settlement
Update charge information
Meter Reading
Electrical heating
Move-in due to other
reason
Servicerequest
Not used
Not used
Missing non-profiled time
series
Missing flex time series
Missing profiled reading
Proposal contact
information
Secondary move-in
Switch with short notice
Transfer metering point
Correction settlement
Incorrect move
End supply due to
reallocate
Continue supply due to
rejected reallocate
Continue supply of
customer
Cancel service request
Dok. 13/101713-21
Kommentar
Andelstal
Kodeansvarlig
DK
Foreløbige
Fiksering
Refiksering
Skabelonafregnet
timemålt målepunkt
DK
DK
DK
DK
Genoptag leverance
DK
Nyeste værdier
Skabelonafregnet
forbrug
Misligholdt proces
Annuller
aflæsningsanmodning
Skift til forsyningspligt
DK
DK
Nedlæg målepunkt
Tilslut målepunkt
ikke anvendt
Opdater stamdata
afregning
Opdater prisinformation
Tællerstand
Elvarme
Tilflytning af anden
årsag
Serviceanmodning
Anvendes ikke
Anvendes ikke
Hullerlog timeafregnet
DK
DK
DK
DK
Hullerlog flexafregnet
Hullerlog
skabelonafregnet
Forslag
kontaktinformation
Tilflytning sekundær
Skift med kort varsel
Overflyt målepunkt
Korrektionsafregning
Fejlagtig flytning
Information om stop
pga. genoptagelse
Information om
fortsættelse af
leverance
Genoptag kundeforhold
DK
DK
Annuller
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
185 / 237
D38
D39
D40
D41
D42
D43
D44
D45
End of supply with short
notice
Production Obligation
Removed parent relation
on meteringpoint
No disconnection of
meteringpoint
Periodic flex metering
Historical information
about consumption
Process cancelled by
requesting party
Process cancelled by ITX
E01
E02
E03
E05
E06
Move
New metering point
Change of balance supplier
Cancellation
Unrequested change of
balance supplier
E0G
Data alignment for master
data metering point
End of supply
Periodic metering
E20
E23
E30
E32
E34
E53
E56
E65
E66
E67
E75
E79
E80
E84
Historical data
Update master data
metering point
Update master data
consumer
Meter reading on demand
Change of Balance
Responsible Party
Customer move-in
Customer move-out
Placement of Meter
Change of metering
method
Change Connection Status
Change of estimated
annual volume
Update master data meter
serviceanmodning
Stop af leverance med
kort varsel
Aftagepligt
Parent relation fjernet
fra målepunkt
Netvirksomhed har ikke
afbrudt målepunkt
Periodisk flex
forbrugsopgørelse
Forbrugsinformation
DK
DK
DK
DK
DK
DK
Proces stoppet af
aktøren
Proces stoppet pga.
anden proces
Flytning
Nyt målepunkt
Skift af elleverandør
Annullering
Overflyt til
forsyningspligtig
elleverandør
Stamdata til kontrol
DK
Leveranceophør
Periodisk
forbrugsopgørelse
Historiske data
Opdater stamdata
målepunkt
Opdater stamdata
kunde
Anmod om aflæsning
Skift af balanceansvarlig
aktør
Almindelig tilflytning
Fraflytning
Skift af måler
Ændr afregningsform
ebIX
ebIX
Ændr tilslutningsstatus
Forventet årsforbrug
ebIX
ebIX
Opdater stamdata måler
ebIX
DK
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
6.2. Datadefinitioner for BusinessRoleCode
Kode
DDK
DDM
DDQ
DDX
DDZ
Beskrivelse
Balance responsible party
Grid access provider
Balance power supplier
Imbalance settlement
responsible
Metering Point
Dok. 13/101713-21
Kommentar
Kodeansvarlig
ebIX
ebIX
ebIX
ebIX
ebIX
186 / 237
DEA
EZ
MDR
Administrator
Metered data aggregator
System Operator
Metered data responsible
ebIX
ebIX
ebIX
6.3. Datadefinitioner for ChargeTypeCode
Kode
D01
D02
D03
Beskrivelse
Subscription
Fee
Tariff
Kommentar
Abonnement
Gebyr
Tarif
Kodeansvarlig
DK
DK
DK
6.4. Datadefinitioner for CurrencyIdentificationCode
Kode
DKK
EUR
NOK
SEK
Beskrivelse
Denmark – Krone
Euro
Norwegian – Krone
Sweden – Krona
Kommentar
Kodeansvarlig
ebIX
ebIX
ebIX
ebIX
6.5. Datadefinitioner for DisconnectionTypeCode
Kode
D01
D02
Beskrivelse
Remote disconnection
Manual disconnection
Kommentar
Fjern afbrydelig
Manual afbrydelig
Kodeansvarlig
DK
DK
6.6. Datadefinitioner for DocumentFunctionCode
Kode
1
2
3
4
5
9
Beskrivelse
Cancellation
Addition
Deletion
Change
Update
Original
Kommentar
Annullering
Opret
Stop
Ændr
Korrektion
Original
Kodeansvarlig
UN/CEFACT
UN/CEFACT
UN/CEFACT
UN/CEFACT
UN/CEFACT
UN/CEFACT
6.7. Datadefinitioner for DocumentNameCode
Kode
294
392
414
432
D01
D02
D03
D04
Beskrivelse
Application
acknowledgement and error
report
Request change of supplier
Confirmation of start of
supply
Notification to grid operator
of contract termination
Request re-allocate change
of supplier
Response re-allocate
change of supplier
Request Service
Response Servicerequest
Dok. 13/101713-21
Kommentar
Kodeansvarlig
UN/CEFACT
Anmod start af
leverance
Svar start af leverance
UN/CEFACT
Anmod om
leveranceophør
Anmod tilbageføring af
elleverandør
Svar tilbageføring af
elleverandør
Service anmodning
Svar service anmodning
UN/CEFACT
UN/CEFACT
DK
DK
DK
DK
187 / 237
D05
D06
Request Update Master
Data Charge
Response Update Master
Data Charge
D07
Notify Master Data Charge
D08
D17
Query Master Data Charge
Response Master Data
Charge
Request update charge
information
Response update charge
information
Notify charge information
Query charge information
Response charge
information
Request update Metering
Point party
Response update Metering
Point party
Response MasterData party
D18
D19
Query all master data
Reject all master data
D20
D22
Response MasterData
MeterinPoint
Request for Aggregated
Billing Information
Response MasterData Meter
D23
Notify Volumes
D24
Notify missing data
E07
Master data, metering point
E08
Master data, meter
E10
Request for Master data,
Metering point
Master data, Consumer
D09
D10
D11
D12
D13
D14
D15
D16
D21
E21
E31
E38
E41
E42
E44
Aggregate metered data
from the Metered Data
Aggregator, local
Request Master data, meter
Request to Meter
administrator (MA) for
change in Meter-db
Response from Meter
administrator (MA) for
change in Meter-db
Notification to supplier of
Dok. 13/101713-21
Anmod opdater
stamdata, afregning
Svar opdater stamdata,
Afregning
Notifikation om
stamdata, Afregning
Forespørg stamdata,
afregning
Svar forespørg
stamdata, afregning
Anmod opdater prisliste
DK
Svar anmod opdater
prisliste
Notifikation om prisliste
Forespørg om prisliste
Svar forespørg om
prisliste
Anmod opdater
stamdata, kunde
Svar anmod opdater
stamdata, kunde
Svar forespørg
stamdata, kunde
Forespørg om stamdata
Afvis Forespørg
stamdata
Svar forespørg
stamdata, målepunkt
Anmod om engros
ydelser
Svar forespørg
stamdata, måler
Notifikation om
forbrugsoplysning
Notifikation om
manglende data
Notifikation om
stamdata, målepunkt
Notifikation om
stamdata, måler
Anvendes p.t. ikke
DK
Notifikation om
stamdata, kunde
Aggregated MeteredData
TimeSeries
ebIX
Anvendes ikke
Anmod opdater
stamdata, måler
ebIX
ebIX
Svar Anmod opdater
stamdata, måler
ebIX
Notifikation om skift af
ebIX
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
ebIX
ebIX
ebIX
ebIX
188 / 237
E58
E59
E66
E73
E74
ERR
contract termination
Request to change
metering point attributes
Confirmation/rejection of
change metering point
attributes
Validated metered data,
time series
Request for validated
metered data
Request aggregated
metered data
Processability Error Report
elleverandør
Anmod opdater
stamdata, målepunkt
Svar Anmod opdater
stamdata, målepunkt
Validerede måledata
Anmod måledata,
målepunkt
Anmod om aggregerede
måledata
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
6.8. Datadefinitioner for DataRequestCode
Kode
Beskrivelse
Kommentar
Indeholder kopi af Datadefinitioner for BusinessReasonCode
Kodeansvarlig
6.9. Datadefinitioner for EnergyProductIdentificationCode
Kode
5790001330590
5790001330606
8716867000016
8716867000023
8716867000030
8716867000047
Beskrivelse
Tariff
Fuel quantity
Power active
Power reactive
Energy active
Energy reactive
Kommentar
Kodeansvarlig
GS1
GS1
GS1
GS1
GS1
GS1
6.10. Datadefinitioner for MeasurementUnitCommonCode
Kode
AMP
K3
Beskrivelse
Ampere
kVArh
KWH
KWT
MAW
MWH
TNE
Z03
kWh
kW
MW
MWh
Tonne
MVAr
Z14
H87
Danish Tariff code
STK
Kommentar
Ampere
KiloVolt-Ampere reactive
hour
Kilowatt-hour
Kilowatt
Megawatt
Megawatt-hour
metric ton
MegaVolt-Ampere
reactive power
KT Tarifkode
Antal styk
Kodeansvarlig
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
6.11. Datadefinitioner for MeteringPointSubTypeCode
Kode
D01
D02
D03
Beskrivelse
Physical
Virtual
Calculated
Dok. 13/101713-21
Kommentar
Fysisk
Virtuel
Beregnet
Kodeansvarlig
DK
DK
DK
189 / 237
6.12. Datadefinitioner for MeteringPointTypeCode
Kode
D01
D02
D03
D04
Beskrivelse
VE production
Analysis
Not used
Surplus production group 6
D05
D06
D07
D08
D09
D10
D11
D12
Net production
Supply to grid
Consumption from grid
Whole sale services /
information
Own production
Net from grid
Net to grid
Total consumption
D13
D14
D15
Net loss correction
Electrical heating
Reserved for later use
D16
Reserved for later use
D17
Reserved for later use
D18
Reserved for later use
D19
Reserved for later use
D20
Reserved for later use
D99
E17
E18
E20
Internal use
Consumption
Production
Exchange
Kommentar
VE produktion
Analysemålepunkt
Anvendes ikke
Overskudsproduktion
gruppe 6
Nettoproduktion
Leveret til net
Forbrugt fra net
Afregningsgrundlag/
Information
Egenproduktion
Netto fra net
Netto til net
Brutto forbrug
Kodeansvarlig
DK
DK
DK
DK
Nettabskorrektion
Elvarme
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Intern brug
Forbrug
Produktion
Udveksling
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
ebIX
ebIX
ebIX
6.13. Datadefinitioner for MeterReadingTypeCode
Kode
D01
D02
Beskrivelse
Accumulated
Balanced
Kommentar
Akkumulerende
Salderende
Kodeansvarlig
DK
DK
6.14. Datadefinitioner for MPAddressWashInstructionTypeCode
Kode
D01
D02
Beskrivelse
Washabel
Not washabel
Kommentar
Vaskbar
Ikke vaskbar
Kodeansvarlig
DK
DK
6.15. Datadefinitioner for MPConnectionTypeCode
Kode
D01
D02
Beskrivelse
Direct connected
Installation connected
Dok. 13/101713-21
Kommentar
Direkte tilsluttet
Installationstilsluttet
Kodeansvarlig
DK
DK
190 / 237
6.16. Datadefinitioner for MPReadingCharacteristicsCode
Kode
D01
D02
Beskrivelse
Automatic meter reading
Manual meter reading
Kommentar
Kodeansvarlig
DK
DK
6.17. Datadefinitioner for MPRelationTypeCode
Kode
D01
D02
D03
D04
Beskrivelse
Disconnection card
Reading card
Voting card
Address 4
Kommentar
Afbryderkort
Aflæsningskort
Valgkort
Adresse 4
Kodeansvarlig
DK
DK
DK
DK
6.18. Datadefinitioner for PhysicalStatusCode
Kode
D01
D02
D03
E22
E23
Beskrivelse
Not used
Closed down
New
Connected
Disconnected
Kommentar
Anvendes ikke
Nedlæg
Ny
Tilsluttet
Afbrudt
Kodeansvarlig
DK
DK
DK
ebIX
ebIX
6.19. Datadefinitioner for QuantityQualityCode
Kode
D01
36
56
E01
Beskrivelse
Calculated
Revised
Estimated
As read
Kommentar
Beregnet
Kodeansvarlig
DK
UN/CEFACT
UN/CEFACT
ebIX
6.20. Datadefinitioner for ResponseConditionCode
Kode
39
41
Beskrivelse
Approved
Rejected
Kommentar
Kodeansvarlig
UN/CEFACT
UN/CEFACT
6.21. Datadefinitioner for ResponseReasonDescriptionCode
Kode
D01
D02
D03
D04
D05
D06
D07
D08
Beskrivelse
The document is approved
General error
Missing consumer name or
address
Not used
Metering point ID does not
match the one from the
original document
Reference to transaction ID
does not match the one
from the original document
Ongoing move process
Balance supplier does not
match the current Balance
Dok. 13/101713-21
Kommentar
Dokument er godkendt
Generel fejl
Kundeinformation er ikke
korrekt
Anvendes ikke - erstattes
af E0I
Målepunkt svarer ikke til
målepunkt fra originalt
dokument
Reference til transaktions
ID svarer ikke til Id fra
originalt dokument
Igangværende flytning
Elleverandør svarer ikke
til nuværende
Kodeansvarlig
DK
DK
DK
DK
DK
DK
DK
DK
191 / 237
D09
Supplier
Not used
D11
Combination of search
criteria not possible
D12
Invalid Quantity Quality
Code
DataHub Internal error
Incorrect charge
information
Incorrect settlement
Incorrect connection status
D13
D14
D15
D16
D17
D18
D19
D20
D21
D22
D23
D24
D25
D26
D27
D28
D29
D30
D31
Incorrect CPR/CVR
Incorrect type of
meteringpoint
Functioncode not allowed
Violated process
Cancel Meterreading
Change of supply on MP,
new
Resolution not correct
Incorrect contract
information
Balance Responsible Party
does not match the current
Balance Responsible Party
Unauthorized TSO
Illegal request
Service request rejected
D39
No existing contract
Not used
Incorrect meter
information according to
rules
Metering point sub type
cannot be changed
Metering point is part of a
calculation structure
Parent metering point has
children
Balance supplier exist at
metering point
Metering point cannot be
connected
Illegal metering point sub
type
Stop of supply not
registered for metering
point
Ongoing stop of supply
D40
Illegal process
D32
D33
D34
D35
D36
D37
D38
Dok. 13/101713-21
elleverandør
Anvendes ikke - erstattes
af E0H
Kombination af
søgekriterier er ikke
mulig
Invalid kvantumstatus
kode
Intern fejl i DataHub
Afregningsstamdata ikke
korrekt
Afregningsform er forkert
Tilslutningsstatus er
forkert
CPR/CVR er ikke korrekt
Målepunktstype ikke
korrekt
Funktionskode ikke tilladt
Misligholdt proces
Annuller aflæsning
Leverandørskift på
målepunkt, nyoprettet
Tidsopløsning ikke
korrekt
Information om kontrakt
ikke korrekt
Balanceansvarlig aktør
svarer ikke nuværende
Balanceansvarlig aktør
TSO er ikke korrekt
Anmodning er ikke lovlig
Anmodning om
serviceydelse er afvist
Kontrakt findes ikke
Registrering af måler er
ikke i overensstemmelse
med regler
Målepunktsart kan ikke
ændres
Målepunkt er en del af
beregningsstruktur
Der er child målepunkter
tilknyttet målepunktet
Målepunkt har tilknyttet
elleverandør
Målepunkt kan ikke
tilsluttes
Målepunktsart er ikke
korrekt
Leveranceophør er ikke
meldt på målepunkt
Igangværende
leveranceophør
Ugyldig proces
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
192 / 237
D41
D42
D43
D44
D45
D46
D47
The municipality must be
involved in the
disconnection
The police must be
involved in the
disconnection
The bailiff’s court must be
involved in the
disconnection
Other rejection reason
Rejection 5
Incorrect MeteringGridArea
Operation not allowed for
net settlement group 6
D48
D50
Marketplayer is blocked for
operation in this
MeteringGridArea
Other marketplayer is
blocked for operation in
this MeteringGridArea
No delegation found
D51
Reserved for later use
D52
Reserved for later use
D53
Reserved for later use
D54
Reserved for later use
D55
Reserved for later use
D56
Reserved for later use
D57
Reserved for later use
D58
Reserved for later use
D59
Reserved for later use
D60
Reserved for later use
E09
Installation not identifiable
E10
Metering point not
identifiable
Measuring problem
Other Reason
Unauthorized balance
supplier
Requested switch date not
within time limits
Unauthorized balance
D49
E11
E14
E16
E17
E18
Dok. 13/101713-21
Kommunen skal
inddrages i afbrydelsen
DK
Politiet skal inddrages i
afbrydelsen
DK
Fogedretten skal
inddrages i afbrydelsen
DK
Anden afvisningsårsag
Afvisningsårsag 5
Netområde er ikke
korrekt
Håndtering ikke tilladt for
målepunkt tilhørende
nettoafregningsgruppe 6
Blokeret for denne
operation i netområde
DK
DK
DK
Anden aktør blokeret for
denne operation i
netområde
Ingen delegering
tilknyttet
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Installation er ikke
tilgængelig
Problem med målepunkt
DK
Problem med måledata
Anden årsag til fejl
Elleverandør er ikke
korrekt
Dato er ikke indenfor
angivet tidsfrist
Balanceansvarlig aktør er
ebIX
ebIX
ebIX
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
ebIX
ebIX
ebIX
ebIX
193 / 237
E19
E22
E29
E47
E50
E51
E55
E59
E61
E73
E81
E86
E87
E90
E91
E97
E98
E0H
E0I
responsible
Meter readings not within
limits
Metering point blocked for
switching
Product code unknown or
not related to MP
No ongoing switch for MP
Invalid period
Invalid number of decimals
Unathorised metered data
responsible
Already existing relation
Meter not identifiable
Incorrect measure unit
MeteringPoint is not
connected
Incorrect value
Number of observations
dosn't fit observation
period/resolution
Measurement beyond
plausibility limits
Estimate is not acceptable
Measurement should not
be zero
Measurement has wrong
sign
Data not available
Unauthorised Grid Access
Provider
ikke korrekt
Tællerstand er ikke
korrekt
Målepunkt blokeret for
skift
Ukendt produktkode
ebIX
ebIX
ebIX
Ingen igangværende
leverandørskift på
målepunkt
Invalid periode
Antal decimaler er forkert
Måledataansvarlig er ikke
korrekt
Relation eksisterer
allerede
Ukendt måler
Måleenhed ikke korrekt
Målepunkt er ikke
tilsluttet
Ukorrekt værdi
Antal værdier passer ikke
med tidsopløsning
ebIX
Måledata er udenfor
grænse
Estimat er ikke korrekt
Måling må ikke være nul
ebIX
Måling har forkert
fortegn
Ingen data tilgængelig
Netvirksomhed ikke
korrekt
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
ebIX
6.22. Datadefinitioner for SectorAreaIdentificationCode
Kode
23
Beskrivelse
Electricity supply industry
Kommentar
Kodeansvarlig
UN/CEFACT
6.23. Datadefinitioner for ServiceRequestCode
Kode
D01
D02
D03
D04
D05
D06
D07
D08
D09
Beskrivelse
Disconnect
Close down
Connect
Reading request
Meter check
Flex change
Non-profiled change
Disconnect due to end of
supply
The municipality is
involved in the
disconnection
Dok. 13/101713-21
Kommentar
Afbrydelse
Nedlæggelse
Genåbning
Ekstra aflæsning
Målerundersøgelse
Skift til Flexafregning
Skift til Timeafregning
Afbrydelse ved
leveranceophør
Kommunen skal
inddrages i afbrydelsen
Kodeansvarlig
DK
DK
DK
DK
DK
DK
DK
DK
DK
194 / 237
D10
D13
D14
D15
D16
The police is involved in
the disconnection
The bailiff's court is
involved in the
disconnection
Ordinary disconnection –
agreed with the customer
Other reason
Establish electric heating
Remove electric heating
Reserved for later use
D17
Reserved for later use
D18
Reserved for later use
D19
Reserved for later use
D20
Reserved for later use
D11
D12
Politiet skal inddrages i
afbrydelsen
Fogedretten skal
inddrages i afbrydelsen
DK
Afbrydelse – anmodet af
kunde
Anden årsag
Etabler elvarme
Fjern elvarme
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
Reserveret til senere
brug
DK
DK
DK
DK
DK
DK
DK
DK
DK
DK
6.24. Datadefinitioner for SettlementMethodCode
Kode
D01
E01
E02
Beskrivelse
Flex settled
Profiled
Non profiled
Kommentar
Kodeansvarlig
DK
ebIX
ebIX
6.25. Datadefinitioner for VATClassCode
Kode
D01
D02
Beskrivelse
No VAT
VAT
Kommentar
Ingen moms
Moms
Kodeansvarlig
DK
DK
6.26. Datadefinitioner for
AssembledCodeListResponsibleAgencyCodeContentType
Kode
6
9
260
305
DK
Beskrivelse
UN/CeFACT
GS1=EAN International
ebIX = EDIEL Nordic forum
ETSO / ENTSO-E
Danish code list
Dok. 13/101713-21
Kommentar
Kodeansvarlig
UN/CEFACT
GS1
ebIX
ENTSO-E
DK
195 / 237
7. Håndtering af stamdata
7.1. Stamdata
MeteringPoint Master Data
MeteringPoint ID
Parent MeteringPoint
Occurrence
PhysicalStatusOfMeteringPoint
Settlement Method
Meter Reading Occurence
ScheduledMeter ReadingDate
MP Reading Characteristic
Hourly Times Series
MeteringPointSubType
TypeOfMeteringPoint
DisconnectionType
MPConnectionType
NetSettlementGroup
MeteringGridArea
Maximum Current
Maximum Power
MPCapacity
Estimated Annual Consumption
Product Type
UnitType
Ignore Mandatory Limit
Power Plant
Production Obligation
From Grid
To Grid
LocationDescription
BalanceSupplierID
SupplyStart
BalanceResponsiblePartyId
Meter Identification
Meter Conversion Factor
Meter NumberOfDigits
Meter Reading Type
Meter Unit Type
MPAddressWashInstruction
Streetname
Street Code
Building Number
Floor ID
Room ID
City Sub Div Name
Post Code
City Name
Municipality Code
Country Code
Function
Reference
ChildMeteringPoint
D99 Intern beregning
Målepunktsstamdata
Målepunkts ID
Parent målepunkts ID
Gyldighedsdato
Tilslutningsstatus
Afregningsform
Aflæsningsfrekvens
Nominel aflæsningsdag
Aflæsningsform
Timedata
Målepunkts art
Målepunktstype
Afbrydelsesart
Tilslutningstype
Nettoafregningsgruppe
Netområde
Effektgrænse Ampere
Effektgrænse kW
Anlægskapacitet
Forventet årsforbrug
Produkt
Energienhed
Ignorer tilladt grænse
VærksGSRN
Aftagepligt
Fra net
Til net
Målepunktskommentar
Elleverandør ID
Start af leverance
Balanceansvarlig ID
Målernummer
Måleromregningsfaktor
Målercifre
Målertype
Målerenhed
Vaskeanvisning
Vejnavn
Vejkode
Husnummer
Etage
Lejligheds ID
Supplerende bynavn
Postnummer
Postdistrikt
Kommunekode
Landekode
Funktionskode
Reference
Child målepunkt
D14 Elvarmeafgift
Beskrivelse af attributter
E17
E17
E17
E18
E20
D01
D02
D04
D05
D06
D07
D08
D09
D10
D11
D12
D13
Skabelon Manuel
Skabelon Fjernaflæst
Time/ Flex afregnet
Produktion
Udveksling
VE Produktion
Analyse
Overskudsprod. Gr. 6
Netto produktion (M1)
Leverance til net (M2)
Træk fra net (M3)
Afregning/information
Egen produktion
Netto fra net (NFN)
Netto til net (NTN)
Total forbrug (BFB)
Nettabskorrektion
7.1.1. Dependency Matrix for attributter for tilladte målepunktsstamdata
Nedenstående tabel viser, hvilke felter de forskellige målepunktstyper kan
indeholde.
Må aldrig medsendes for målepunktstype
Må medsendes
Dok. 13/101713-21
196 / 237
Kundestamdata
Forretningsårsag
Målepunkts ID
Gyldighedsdato
Elvarme
Elvarme Afgiftsstart
Webadgangskode
DE branchekode
Kundenavn1
Kundenavn2
CPR 1
CPR 2
CVR
DataadgangsCVR
LeverandørStatus
Start af Leverance
AdresseType
Identisk med MP
Navn 1
Navn 2
Vejnavn
Vejkode
Husnummer
Etage
Dør
Supplerende bynavn
Postnummer
Postdistrikt
Kommunekode
Landekode
Telefonnr
Mobil
Email
Reference
Consumer Master Data
BusinessreasonCode
MeteringPoint ID
Occurrence
ElectricalHeating
ElectricalHeatingDate
WebAccessCode
ConsumerCategory
FirstConsumerPartyName
SecondConsumerPartyName
ConsumerCPR 1
ConsumerCPR 2
ConsumerCVR
DataAccessCVR
HasBalanceSupplier
SupplyStart
MPRelationType
SameAsMPAddress
Name1
Name2
Streetname
StreetCode
BuildingNumber
FloorID
RoomID
CitySubDivisionName
PostCode
CityName
MunicipalityCode
CountryCode
Phonenumber
Mobile
Email
Reference
Produktion
Forbrug
7.1.2. Dependency Matrix for attributter for tilladte kundestamdata
Nedenstående tabel viser, hvilke felter de forskellige målepunktstyper kan
indeholde
E17 E18
Må aldrig medsendes
Må medsendes
Dok. 13/101713-21
197 / 237
7.1.3. Dependency Matrix for relevante attributter for indsendte
målepunktsstamdata.
Nedenstående tabel viser følgende for de forskellige BRS’er, som netvirksomheden
indsender målepunktsstamdata for:
 Hvilke attributter der kan opdateres i processen.
 Hvilke attributter, der må medsendes.
Tabellen skal sammenholdes med hvilke attributter, der er tilladt for den enkelte
målepunktstype. Ændringer i attributter, som ikke er relevante i forhold til
processen vil blive ignoreret, hvis formatet for attribut overholdes.
BRS BRS BRS BRS BRS BRS BRS BRS BRS
002 004 006 007 008 012 013 014 036
E20 E02 E32 D14 D15 E75 E79 E67 D39
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Forretningsårsag
Målepunkts ID
MeteringPoint ID
Parent målepunkts ID
Parent MeteringPoint
Gyldighedsdato
Occurrence
Tilslutningsstatus
PhysicalStatusOfMeteringPoint
Afregningsform
Settlement Method
Aflæsningsfrekvens
Meter Reading Occurence
Nominel aflæsningsdag
ScheduledMeter ReadingDate
Aflæsningsform
MP Reading Characteristic
Timedata
Hourly Times Series
Målepunkts art
MeteringPointSubType
Målepunktstype
TypeOfMeteringPoint
Afbrydelsesart
DisconnectionType
Tilslutningstype
MPConnectionType
Nettoafregningsgruppe
NetSettlementGroup
Netområde
MeteringGridArea
Effektgrænse Ampere
Maximum Current
Effektgrænse kW
Maximum Power
Anlægskapacitet
MPCapacity
Forventet årsforbrug
Estimated Annual Consumption
Produkt
Product Type
X
X
Energienhed
UnitType
X
X
Ignorer tilladt grænse
Ignore Mandatory Limit
X
X
VærksGSRN
Power Plant
X
X
Aftagepligt
Production Obligation
Fra net
From Grid
X
X
Til net
To Grid
X
X
Målepunktskommentar
LocationDescription
X
X
Elleverandør ID
BalanceSupplierID
Start af leverance
SupplyStart
Balanceansvarlig ID
BalanceResponsiblePartyId
Målernummer
Meter Identification
X1) X1)
Måleromregningsfaktor
Meter Conversion Factor
X1) X1)
Målercifre
Meter NumberOfDigits
X1) X1)
Målertype
Meter Reading Type
X1) X1)
Målerenhed
Meter Unit Type
X1) X1)
Vaskeanvisning
MPAddressWashInstruction
X
X
Vejnavn
Streetname
X
X
Vejkode
Street Code
X
X
Husnummer
Building Number
X
X
Etage
Floor ID
X
X
Lejligheds ID
Room ID
X
X
Supplerende bynavn
City Sub Div Name
X
X
Postnummer
Post Code
X
X
Postdistrikt
City Name
X
X
Kommunekode
Municipality Code
X
X
Landekode
Country Code
X
X
Funktionskode
Function
Reference
Reference
Child målepunkt
ChildMeteringPoint
X) Valideres og opdateres ved indsendelse fra netvirksomhed jf. regler som beskrevet i BRS
1) Medsendes kun for målepunktsart lig fysisk
Må aldrig medsendes
Må medsendes
BRS-006 status nyoprettet. Ændring af målepunktstype behandles
efter regler i BRS-004
Medsendes jævnfør regler
Dok. 13/101713-21
X
X1)
X1)
X1)
X1)
X1)
X
198 / 237
Kundestamdata
Consumer Master Data
Forretningsårsag
Målepunkts ID
Gyldighedsdato
Elvarme
Elvarme Afgiftsstart
Webadgangskode
DE branchekode
Kundenavn1
Kundenavn2
CPR 1
CPR 2
KundeCVR
DataadgangsCVR
LeverandørStatus
Start af Leverance
BusinessreasonCode
MeteringPoint ID
Occurrence
ElectricalHeating
ElectricalHeatingDate
WebAccessCode
ConsumerCategory
FirstConsumerPartyName
SecondConsumerPartyName
ConsumerCPR 1
ConsumerCPR 2
ConsumerCVR
DataAccessCVR
HasBalanceSupplier
SupplyStart
E17
X
X1)
X1)
Netvirksomhed
(kun
videresendelse)
Elleverandør
Elleverandør
7.1.4. Dependency Matrix for relevante attributter for indsendte
kundestamdata.
Nedenstående tabel viser for de forskellige BRS’er som netvirksomheden og
elleverandren indsender kundestamdata for følgende:
 For elleverandører:
o Hvilke attributter der kan opdateres i processen.
o Hvilke attributter, der må medsendes.
 For netvirksomheden:
o Hvilke attributter, der skal og kan medsendes.
Tabellen skal sammenholdes med hvilke attributter, der er tilladt for den enkelte
målepunktstype.
E18
X
X
X
X
X2)
X2)
X2)
X2)
X
X
X2)
X2)
X2)
X2)
X3)
X3)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X3)
X3)
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Kontaktinformation
AdresseType
Identisk med MP
Navn 1
Navn 2
Vejnavn
Vejkode
Husnummer
Etage
Dør
Supplerende bynavn
Postnummer
Postdistrikt
Kommunekode
Landekode
Telefonnr
Mobil
Email
Reference
MPRelationType
SameAsMPAddress
Name1
Name2
Streetname
StreetCode
BuildingNumber
FloorID
RoomID
CitySubDivisionName
PostCode
CityName
MunicipalityCode
CountryCode
Phonenumber
Mobile
Email
Reference
X = Valideres og opdateres ved indsendelse fra elleverandør jf. regler
som beskrevet i BRS
1) Skal medsendes hvis Elvarmeændring er angivet på MP
2) hvis CPR angivet så skal CVR være blank og omvendt, hvis CPR ikke
opdateres skal det ikke medsendes
3) skal angives, hvis kontaktinformation medsendes
4) Netvirksomhed fremsender kontaktinformation
Dok. 13/101713-21
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
X4)
Medsendes jævnfør regler
Må medsendes
Må aldrig medsendes
199 / 237
od
u
Pr
Navn
Name
Ud
kt
io
ve n
ks
l
V E i ng
Pr
od
uk
Te
ti
kn
isk on
So
lce
lle
Ne
tto
pr
o
Le
ve duk
ra
nc tion
Tr
æ e til (M
kf
ne 1 )
r
t
Af a n
et (M2
re
gn
)
(M
i
Eg ng/ 3)
in
en
f
o
pr
r
Ne odu mat
io
tto
kt
n
fra ion
Ne
tto net
(
N
t
To il ne FN)
ta
l f t (N
or
TN
Ne
b
)
t t a rug
(
b
BF
Elv sko
B)
r
r
ar
m ekt
In eafg ion
te
rn ift
m
ell
em
re
gn
in
g
7.1.5. Dependency Matrix for attributter i målepunktsstamdata sendt fra
DataHub.
Ved fremsendelse af stamdata fra DataHub til aktøren sendes altid det fulde sæt
stamdata som er gældende for aktøren for den specifikke målepunktstype og
tilladte attributter.
E17 E17 E17 E18 E20 D01 D02 D04 D05 D06 D07 D08 D09 D10 D11 D12 D13 D14 D99
SM SF TF
Målepunkts ID
MeteringPoint ID
Parent målepunkts ID
Parent MeteringPoint
Gyldighedsdato
Occurrence
Tilslutningsstatus
PhysicalStatusOfMeteringPoint
Afregningsform
Settlement Method
Aflæsningsfrekvens
Meter Reading Occurence
Nominel aflæsningsdag
ScheduledMeter ReadingDate
Aflæsningsform
MP Reading Characteristic
Timedata
Hourly Times Series
Målepunkts art
MeteringPointSubType
Målepunkts type
TypeOfMeteringPoint
Afbrydelsesart
DisconnectionType
Tilslutningstype
MPConnectionType
6
6
6
6
Nettoafregningsgruppe
NetSettlementGroup
Netområde
MeteringGridArea
AdesseType
MPRelationType
Identisk med MP
SameAsMPAddress
Anlægskapacitet
MPCapacity
6
6
6
6
Forventet årsforbrug
Estimated Annual Consumption
Produkt
Product Type
Måleenhed
UnitType
Ignorer tilladt grænse
Ignore Mandatory Limit
VærksGSRN
Power Plant
Aftagepligt
Production Obligation
Fra net
From Grid
Til net
To Grid
Målepunktskommentar
LocationDescription
Elleverandør ID
BalanceSupplierID
1
1
1
1
Start af leverance
SupplyStart
1
1
1
1
Balanceansvarlig ID
BalanceResponsiblePartyId
1
1
1
1
Målernummer
Meter Identification
2
2
2
2
2
2
2
2
2
Måleromregningsfaktor
Meter Conversion Factor
2
2
2
2
2
2
2
2
2
Målercifre
Meter NumberOfDigits
2
2
2
2
2
2
2
2
2
Målertype
Meter Reading Type
2
2
2
2
2
2
2
2
2
Målerenhed
Meter Unit Type
2
2
2
2
2
2
2
2
2
Vaskeanvisning
MPAddressWashInstruction
Vejnavn
Streetname
4
4
4
4
4
Vejkode
Street Code
4
4
4
4
4
Husnummer
Building Number
4
4
4
4
4
Etage
Floor ID
4
4
4
4
4
Lejligheds ID
Room ID
4
4
4
4
4
Supplerende bynavn
City Sub Div Name
4
4
4
4
4
Postnummer
Post Code
4
4
4
4
4
Postdistrikt
City Name
4
4
4
4
4
Kommunekode
Municipality Code
4
4
4
4
4
Landekode
Country Code
4
4
4
4
4
Funktionskode
Function
5
5
5
5
5
5
5
5
5
Reference
Reference
3
3
3
3
3
3
3
3
3
Child målepunkt
ChildMeteringPoint
7
7
7
7
SM = Skabelon manuel , SF = Skabelon fjernaflæst, TF = Time eller Flex
1) aldrig til netvirksomhed
Sendes under bestemte betingelser
2) kun for målepunktsart lig fysisk
Medsendes ikke
3) Kun ved svar på forespørgsel (RSM-023)
Medsendes
4) alle felter sendes, hvis adresse angivet
5) Må kun udsendes i forbindelse med BRS-014: Målerhåndtering
6) Medtages kun for forbrugs- og produktions-målepunkter, hvor nettoafregningsgruppe er forskellig fra gruppe 0
7) Kun ved svar på forespørgsel, hvis child målepunkt findes
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
4
4
4
4
4
4
4
4
4
4
5
3
7.1.6. Dependency Matrix for attributter i kundestamdata sendt fra
DataHub.
Ved fremsendelse af stamdata fra DataHub til aktøren sendes altid det fulde sæt
stamdata som er gældende for aktøren for den specifikke målepunktstype og
afregningsform.
Dok. 13/101713-21
200 / 237
Netvirksomhed
Fremtidig elleverandør
med samme kunde
Fremtidig elleverandør
med anden kunde
Potentiel elleverandør
Elleverandør
Kundestamdata
F
F1)
F
F1)
F
F1)
F
F1)
F
F
F
F
3*)
4*)
4*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
4*)
4*)
4*)
2)
3*)
4*)
4*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
3*)
4*)
4*)
4*)
2)
2)
2)
Consumer Master Data
Forretningsårsag
Målepunkts ID
Gyldighedsdato
Elvarme
Elvarme afgiftsstart
Webadgangskode
DE branchekode
Kundenavn1
Kundenavn2
CPR 1
CPR 2
KundeCVR
DataadgangsCVR
LeverandørStatus
Start af Leverance
BusinessreasonCode
MeteringPoint ID
Occurrence
ElectricalHeating
F
ElectricalHeatingDate
F1)
WebAccessCode
ConsumerCategory
F
FirstConsumerPartyName
SecondConsumerPartyName
ConsumerCPR 1
ConsumerCPR 2
ConsumerCVR
DataAccessCVR
HasBalanceSupplier
SupplyStart
Kontaktinformation
AdresseType
MPRelationType
3*)
Identisk med MP
SameAsMPAddress
4*)
Navn 1
Name1
4*)
Navn 2
Name2
3*)
Vejnavn
Streetname
3*)
Vejkode
StreetCode
3*)
Husnummer
BuildingNumber
3*)
Etage
FloorID
3*)
Dør
RoomID
3*)
Supplerende bynavn
CitySubDivisionName
3*)
Postnummer
PostCode
3*)
Postdistrikt
CityName
3*)
Kommunekode
MunicipalityCode
3*)
Landekode
CountryCode
3*)
Telefonnr
Phonenumber
4*)
Mobil
Mobile
4*)
Email
Email
4*)
Reference
Reference
2)
F) Kun forbrugsmålepunkter
1) Dato for Elvarme afgiftsstart medsendes altid, hvis elvarme har været angivet
2) Må kun medsendes som svar på forspørgsel (RM-029)
3) Hvis adressetype ikke angivet fremsendes adressefelter ikke
4) Hvis adressetypekode og ”Identisk med MP” er sand skal felt medtages
*) Hvis adressetypekode og ”Identisk med MP” er falsk skal alle felter medtages
Medsendes ikke
Medsendes
Sendes under bestemte
betingelser
Nedenstående diagram viser håndtering af kontaktinformation fra DataHub:
Customer masterdata
from DataHub
Include code
for MPRelation
Type?
No
No attributes
Yes
SameAsMP
Address?
No
All attributes
Yes
Include following attributes: Names, Phone, Mobile and E-mail
Dok. 13/101713-21
201 / 237
7.1.7. Håndtering af opdatering af stamdata til og fra DataHub
Hvis et tekstfelt skal slettes, sker dette ved indsendelse af en ”blank” attribut.
Opdatering af nominelle aflæsningsdage og kontaktinformation sker ved
indsendelse af de nye værdier. DataHub fjerner de eksisterende værdier og
opdatere med indsendt indhold.
7.1.8. Opbygning af målepunkts- og kontaktadresse
Betegnelse
Vejnavn
Streetname
Beskrivelse
Vejnavn skal angives, hvis muligt.
Hvis vejen ikke har fået tildelt et navn
angives ’ukendt’
Vejkoden fra BBR angives hvis den
haves.
Husnummer og eventuelt bogstav.
Vejkode
StreetCode
Husnummer
Buildingnumber
Etage
FloorIdentification
Dør
RoomIdentification
Supplerende
bynavn
CitySub-DivisionName
Postnr
Postcode
Etagen angives med et tal og ved
kælder angives det som K1, K2 osv. I
boligblokke hvor der anvendes TH, MF
mv angives denne information i feltet
Dør
Anvendes til at angive lejlighedsnumre
og lejlighedsplaceringer i
etagebyggeri.
Områdenavn eller lokalnavn. Bruges
hvis vejnavnet forekommer flere
gange under samme postnummer.
Postnummer.
Postdistrikt
CityName
Bynavnet
Kommunekode
MunicipalityCode
Landekode
CountryName
Den trecifrede kode som bruges af
myndighederne. Skal angives, hvis
muligt.
Skal angives med to tegn efter ISO
3166 2-alpha koden.
Øvrig kontakt information
Navn
Name1
Navnet på virksomheden eller
personen, som anføres som kontakt.
Navn2
(Att. / Postboks)
Name2
Email
Email
Tlf
PhoneNumber
Mobil
Mobile
Adressetype
MPRelationType
Identisk med MP
SameAsMPAddress
Dette er et supplementsfelt til Navn.
Det kan anvendes til attention eller
postboks.
En e-mail adresse. Hvis der ønskes
flere adskilles de med semikolon.
Et kontaktnummer. Ved udenlandske
numre angives for eksempel 0044
som +44
Et kontaktnummer. Ved udenlandske
numre angives for eksempel 0044
som +44
Valgkort
Aflæsningskort
Afbryderkort
Adresse 4
Der tillades en adresse for hver type.
Svar er obligatorisk som Ja/Nej
Dok. 13/101713-21
202 / 237
8. Datadefinitioner
Følgende liste af attributter er opdelt i hver sin klasse.
De to Header klasser (HeaderEnergyDocument og ProcessEnergyContext) er
beskrevet i afsnit 4: Håndtering af Header information.
Det første afsnit indeholder generelle attributter, som optræder i mange klasser
som f.eks. ChargeEvent, MasterDataMPEvent, MPEvent.
Herefter kommer klasserne i alfabetisk rækkefølge.
8.1. Attributter
Transaktion ID
Klasse
Ex.
Identification
Type
Text
Validering
An..35
Beskrivelse
Afsenders unikke identifikation af transaktionen
Transaktion ID svarer til Tidsserie ID
<Identification>123456</Identification>
Tidsserie ID
Klasse
Ex.
Identification
Type
Text
Validering
An..35
Beskrivelse
Afsenders unikke identifikation af transaktionen
Transaktion ID svarer til Tidsserie ID
<Identification>123456</Identification>
Funktionskode
Klasse
PayloadMPEvent
Function
Type
DocumentFunctionCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<Function listAgencyIdentifier="6">9</Function>
Gyldighedsdatodato
Klasse
Ex.
Anvendes til at angive hvilken handling, der skal
udføres for en given EnergyBusinessProcess. F.eks.
ændring, sletning.
Occurrence
Type
Datetime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<Occurrence>2010-07-09T22:00:00Z</Occurrence>
Dok. 13/101713-21
203 / 237
Start Dato
Klasse
Ex.
StartOfOccurrence
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<StartOfOccurrence>2010-07-09T22:00:00Z</StartOfOccurrence >
Slut Dato
Klasse
Ex.
EndOfOccurrence
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<EndOfOccurrence>2010-07-09T22:00:00Z </EndOfOccurrence>
Transaktionsreference
Klasse
Ex.
OriginalBusinessDoc
ument
Identitication
Type
Text
Validering
An..35
Beskrivelse
Entydig reference til transaktionen i det oprindelige
dokument
<OriginalBusinessDocument>
<Identification>123456789</Identification>
</OriginalBusinessDocument>
MeddelesesReference
Klasse
Ex.
OriginalBusinessMes
sage
Identification
Type
Text
Validering
An..35
Beskrivelse
Entydig reference til oprindelig meddelelse
<OriginalBusinessMessage>
<Identification>123456789</Identification>
</OriginalBusinessMessage>
8.2. ChargeInformation
Pristype
Klasse
RelatedChargeCharg
eInformation
Dok. 13/101713-21
ChargeType
Type
ChargeTypeCode
Validering
Tjekkes mod kodelisten.
204 / 237
Beskrivelse
Ex.
<ChargeType listIdentifier="DK" listAgencyIdentifier="260">D01</ChargeType>
Pristype ID
Klasse
Ex.
RelatedChargeCharg
eInformation
PartyChargeTypeID
Type
Text
Validering
Må ikke være tom
Må maksimalt være 10 tegn lang
Beskrivelse
ID skal være unikt inden for den enkelte aktør
<PartyChargeTypeID>PSO</ PartyChargeTypeID>
Navn
Klasse
Ex.
Description
RelatedChargeCharg
eInformation
Type
Text
Validering
An..132 Må ikke være tom
Beskrivelse
Navnet på priselementet.
Skal eventuelt angives på regningen.
<Description>Elafgift 2014</Description>
Beskrivelse
Klasse
Ex.
RelatedChargeCharg
eInformation
LongDescription
Type
Text
Validering
An..2048
Beskrivelse
En forklarende tekst om priselementet
<LongDescription>Dette er elafgiftssatsten for 2014</LongDescription>
Momsgruppe
Klasse
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
RelatedChargeCharg
eInformation
VATClass
Type
VATClassCodeType
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<VATClass listIdentifier="DK" listAgencyIdentifier="260">D02</ VATClass >
Afgift
Klasse
TaxIndicator
RelatedChargeCharg
eInformation
Type
Boolean
Validering
Beskrivelse
Ex.
Angiver om der er moms medtaget
Angiver om en tarif er en afgift eller ej.
true = priselement er en afgift
<TaxIndicator>false</TaxIndicator>
Viderefakturering
Dok. 13/101713-21
TransparentInvoicing
205 / 237
Klasse
RelatedChargeCharg
eInformation
Type
Validering
Beskrivelse
Ex.
Ex.
Angiver om elleverandøren skal synliggøre
priselementet på kundefakturaen. true =
Viderefakturering
<TransparentInvoicing>true</TransparentInvoicing>
Antal
Klasse
Boolean
ChargeOccurrences
RelatedChargeCharg
eInformation
Type
Numerisk
Validering
1-999.999.999
Beskrivelse
Antal gange det samme abonnement eller gebyr skal
opkræves.
Ved funktionskode stop ignoreres antal.
<ChargeOccurrences>3</ChargeOccurrences>
8.3. ChargeTypeOwnerEnergyParty
Aktør
Identification
Klasse
Ex.
Type
Text
Validering
CodingScheme = 9 angives 13 cifret GLN nummer.
CodingScheme = 305 angives 16 tegns EIC kode
Beskrivelse
Entydig identifikation af aktør. Aktøren er identificeret
af et GLN nummer eller en EIC kode.
<Identification schemeAgencyIdentifier= "9">5799999933318</Identification>
8.4. ConsumerParty
CPR
Klasse
Ex.
CPR
FirstConsumerConsu
merParty /
SecondConsumerCo
nsumerParty
Type
Text
Validering
10 cifre
Beskrivelse
Personnummer
1 CPR for hver kunde
<CPR>1012196604</CPR>
KundeCVR
Klasse
Ex.
FirstConsumerConsu
merParty /
SecondConsumerCo
nsumerParty
Consumer CVR
Type
Text
Validering
8 cifre
Må kun anvendes under FirstConsumerPartyName
Må aldrig anvendes, hvis CPR er udfyldt
Beskrivelse
CVR nummer
<CVR>10150817</CVR>
Dok. 13/101713-21
206 / 237
DataadgangsCVR
Klasse
Ex.
FirstConsumerConsu
merParty /
SecondConsumerCo
nsumerParty
DataAccess CVR
Type
Text
Validering
8 cifre
Må aldrig anvendes, hvis CPR er udfyldt.
Skal udfyldes, hvis CVR i FirstConsumerParty er
udfyldt.
Beskrivelse
CVR nummer bruges til at tildele adgang til måledata
til 3. part. Kan være identisk med kundens CVR.
<CVR>10150817</CVR>
Kundenavn
Klasse
Ex.
FirstConsumerConsu
merParty /
SecondConsumerCo
nsumerParty
Name
Type
Text
Validering
An..132
Beskrivelse
Navnet på personen/virksomheden.
<Name>Ib Hansen</Name>
8.5. ContractedCapacityCharacteristics
(indgår i stamdata MP)
Effektgrænse Ampere
Klasse
Ex.
LimitationContracted
CapacityCharacterist
ics
MaximumCurrent
Type
Text
Validering
Heltal <= 3 cifre
Beskrivelse
Effektgrænsen i ampere
<MaximumCurrent>350</MaximumCurrent>
Effektgrænse kW
Klasse
Ex.
LimitationContracted
CapacityCharacterist
ics
MaximumPower
Type
Text
Validering
Heltal <= 6 cifre
Beskrivelse
Effektgrænsen i kW
<MaximumPower>3500</MaximumPower>
8.6. DurationProfiledPeriod
(anvendes i forbrugsopgørelser)
Start Dato
Klasse
Dok. 13/101713-21
Start
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
207 / 237
Beskrivelse
Ex.
Startdatoen på en periode. Dato og tid i UTC+0.
<Start>2010-07-09T22:00:00Z</Start>
Slut Dato
Klasse
Ex.
End
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Slutdatoen på en periode. Dato og tid i UTC+0.
<End>2010-07-09T22:00:00Z</End>
8.7. EnergyContext
 Se ProcessEnergyContext
8.8. EnergyDocument
 Se HeaderEnergyDocument
8.9. EnergyObservation
(indgår i tidsserie data)
Position
Klasse
IntervalEnergyObser
vation
Position
Type
Validering
Beskrivelse
Ex.
Ex.
IntervalEnergyObser
vation
EnergyQuantity
Type
Decimal
Validering
Quantity <= 18 cifre.
Beskrivelse
Mængden opgives i den enhed der er angivet i attribut
UnitTypemed op til antal tilladte decimaler.
Mængdeangivelse for en position i et givent interval.
<EnergyQuantity>123.4</EnergyQuantity>
Kvantum mangler
Klasse
Den relative position for en periode i et interval.
Positionen er angivet ved et numerisk heltal startende
med 1
<Position>1</Position>
Kvantum
Klasse
Integer
IntervalEnergyObser
vation
QuantityMissing
Type
Validering
Beskrivelse
Dok. 13/101713-21
Boolean
Indikation af ingen værdi (værdi true).
Anvendes KUN ved manglende værdi. Kun tilladt indtil
208 / 237
fiksering.
Ex.
<QuantityMissing>true</QuantityMissing>
Kvantum status
Klasse
Ex.
IntervalEnergyObser
vation
QuantityQuality
Type
QuantityQualityCode
Validering
Tjekkes mod kodelisten.
Beskrivelse
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Hvordan Quantity er målt.
<QuantityQuality listAgencyIdentifier=”6”>56</QuantityQuality>
Pris
Klasse
Ex.
EnergyPrice
IntervalEnergyObser
vation
Type
Decimal
Validering
Max 6 decimaler
Beskrivelse
Dkk pr. kvantum med op til og med seks decimalers
nøjagtighed
<EnergyPrice>0.2212</EnergyPrice>
Pris mangler
Klasse
IntervalEnergyObser
vation
PriceMissing
Type
Validering
Beskrivelse
Ex.
Ex.
Indikation af ingen værdi (true)
Anvendes KUN ved manglende værdi
<PriceMissing>true</PriceMissing>
Beløb
Klasse
Boolean
EnergySum
IntervalEnergyObser
vation
Type
Decimal
Validering
Max. 6 decimaler
Beskrivelse
Summen som bruges til aggregeringerne i
engrosafregningsgrundlaget
<EnergySum>193829.23</EnergySum>
8.10. EnergyParty
Identification
Balanceansvarlig aktør
Klasse
Ex.
BalanceResponsibleE
nergyParty
Type
Text
Validering
CodingScheme = 9 angives 13 cifret GLN nummer.
CodingScheme = 305 angives 16 tegns EIC kode
Beskrivelse
Entydig identifikation af balanceansvarlig aktør.
Aktøren er identificeret af et GLN nummer eller en EIC
kode.
<BalanceResponsibleEnergyParty schemeAgencyIdentifier= "9">
<Identification>5799999933318</Identification>
Dok. 13/101713-21
209 / 237
</BalanceResponsibleEnergyParty>
Identification
Elleverandør
Klasse
Ex.
BalanceSupplierEner
gyParty
Type
Text
Validering
CodingScheme = 9 angives 13 cifret GLN nummer.
CodingScheme = 305 angives 16 tegns EIC kode
Beskrivelse
Entydig identifikation af elleverandør. Aktøren er
identificeret af et GLN nummer eller en EIC kode.
<BalanceSupplierEnergyParty schemeAgencyIdentifier= "9">
<Identification>5799999933318</Identification>
</BalanceSupplierEnergyParty>
8.11. EnergyTimeSeries
(indgår i tidsserie data)
Valuta
Currency
Klasse
Type
CurrencyIdentificationCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Valutaen hvormed de enkelte værdier opgives. Valuta
kan f.eks. være DKK, NOK, SEK og EUR.
ISO 4217 3 bogstavskode anvendes
<Currency listAgencyIdentifier=”260”>DKK</Currency>
PrisType
Klasse
ChargeType
Type
ChargeTypeCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<ChargeType listIdentifier="DK" listAgencyIdentifier="260">D02</ ChargeType >
PrisType ID
Klasse
Ex.
Abonnement / Gebyr / tarif
PartyChargeTypeID
Type
Text
Validering
Må maksimalt være 10 tegn lang
Beskrivelse
Aktørens eget ID
<PartyChargeTypeID>A16</ PartyChargeTypeID>
Version
Klasse
Dok. 13/101713-21
Version
Type
Text
Validering
Skal være tal på op til 10 cifre
210 / 237
Beskrivelse
Ex.
Et fortløbende nummer som øges ved nye
beregninger.
<Version>3</Version>
8.12. LocationAddress
Vejnavn
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Streetname
Type
Text
Validering
Må maksimalt være 40 tegn lang
Beskrivelse
Skal angives, brug evt. N/A
<StreetName>Enebærvej</StreetName>
Vejkode
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
StreetCode
Type
Text
Validering
StreetCode = 4 cifre
Beskrivelse
Skal angives hvis muligt (kan være umuligt, hvis ny
vej eller installation på ukendt vej - fx markvej).
Vejkoden skal altid have fire cifre, og disse skal være i
intervallet 0001-9999. Vejkoden udgør sammen med
kommunekode en entydig identifikation af den
navngivne vej med tilhørende vejnavn.
<StreetCode>0405</StreetCode>
Husnummer
BuildingNumber
Klasse
Text
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Validering
<= 6 tegn
Beskrivelse
Husnummer og et evt. bogstav eller andet tegn, som
er en fuldgyldig del af husnummeret.
<BuildingNumber>14A</BuildingNumber>
Etage
Klasse
Ex.
FloorIdentification
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Type
Text
Validering
FloorIdentification <= 2 tegn
Beskrivelse
Eksempler på Etage: S, 1, 2 - skal angives hvis
relevant (f.eks. ved etagebyggeri).
<FloorIdentification>2</FloorIdentification>
Dør
Klasse
RoomIdentification
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Dok. 13/101713-21
Type
Text
Validering
RoomIdentification <= 4 tegn
Beskrivelse
th, tv, m.f. og andre - skal angives hvis relevant (fx
ved etagebyggeri)
211 / 237
Ex.
<RoomIdentification>th</RoomIdentification>
Supplerende bynavn
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
CitySubDivisionName
Type
Text
Validering
<= 25 tegn
Beskrivelse
Skal angives, hvis anderledes end postdistrikt
<CitySubDivisionName>Vejlby</CitySubDivisionName
Postnummer
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Postcode
Type
Text
Validering
For målepunktsadresse: I Danmark max 4 tegn foranstillede nuller anvendes
For kontaktadresser: An..10
Beskrivelse
En kode, der specificerer postnummer for en adresse
<Postcode>8240</Postcode>
Postdistrikt
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
CityName
Type
Text
Validering
CityName <= 25 tegn
Beskrivelse
<CityName>Risskov</CityName>
Kommunekode
Klasse
Ex.
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
MunicipalityCode
Type
Text
Validering
MunicipalityCode = 3 cifre
Beskrivelse
Kombinationen af vejnummer og kommunekode
fastlægger entydigt hvor vejstykket ligger. Specielt
interessant hvis en vej løber gennem flere kommuner.
<MunicipialityCode>845</MunicipialityCode>
Land
Klasse
Ex.
CountryName
InstallationLocationA
ddress /
MeteringPointLocatio
nAddress
Type
Text
Validering
CountryName = 2 tegn. Tjekkes mod ISO 3166 2Alpha kode
Beskrivelse
Der udveksles forkortelser - ikke navne
<CountryName>DK</CountryName>
8.12.1. Tilføjelser til kontaktadresse
Kontaktnavn
Dok. 13/101713-21
Name1
212 / 237
Klasse
Ex.
Type
Text
Validering
An..132
Beskrivelse
Navn på kontaktperson
<Name1>Ib Hansen</Name1>
Kontaktnavn2
Klasse
Ex.
Name2
Type
Text
Validering
An..132
Beskrivelse
Dette er et supplementsfelt til Navn. Det kan anvendes
til attention eller postboks.
<Name2>Irene Hansen</Name2>
Adressetype
Klasse
MPRelationType
Type
MPRelationTypeCode
Validering
Skal findes i listen af koder
Typen af kontaktadresse.
Der er en type for afbryderkort, aflæsningskort og
valgkort, adresse 4.
Ex.
<MPRelationType listIdentifier=”DK” listAgencyIdentifier=”260”>D01</ MPRelationType>
Email
Email
Klasse
Ex.
Type
Text
Validering
Må maksimalt være 60 tegn lang
Beskrivelse
Angiver en email til kontakten. Ved flere emails
adskilles de med semikolon.
<Email>navn@domæne.dk</Email>
Mobil
Mobile
Klasse
Ex.
Type
Text
Validering
Må maksimalt være 20 tegn lang
Beskrivelse
Mobilnummer på kontakten. Angives med cifre og
tegnet ’+’.
<Mobile>004523343566</Mobile>
Telefonnr
Klasse
Ex.
PhoneNumber
Type
Text
Validering
Må maksimalt være 20 tegn lang
Beskrivelse
Telefonnummer på kontakten. Angives med cifre og
tegnet ’+’.
<PhoneNumber>004523343599</PhoneNumber>
Dok. 13/101713-21
213 / 237
Identisk med MP
Klasse
PayloadMPEvent/Con
sumerConsumerPart
y
SameAsMPAddress
Type
Validering
Beskrivelse
Ex.
Boolean
Indikerer om adressen er identisk med målepunktets
eller ej. Identisk lig true
<SameAsMPAddress>true</SameAsMPAddress>
8.13. MeterCharacteristic
Måleromregningsfaktor
Klasse
MeterDetailMeterCha
racteristic
ConversionFactor
Type
Validering
Beskrivelse
Ex.
Ex.
MeterDetailMeterCha
racteristic
NumberOfDigits
Type
Text
Validering
<= 5 karakterer
Beskrivelse
Målecifrene angiver antal betydende cifre og antal
decimaler adskilt med ”.”
Bruges af support hensyn f.eks. Ved overløb af tæller.
Dvs. hvis angivet som 5.2 og måleren runder de
99999.99 startes forfra
<NumberOfDigits>5.2</NumberOfDigits>
Målertype
Klasse
Omregningsfaktoren for at kunne udlede forbruget ud
fra tællerstanden (8 betydende cifre, 4 decimaler)
<ConversionFactor >1.03</ConversionFactor >
Målercifre
Klasse
Decimal
MeterDetailMeterCha
racteristic
MeterReadingType
Type
MeterReadingTypeCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<MeterReadingType listIdentfier=”DK” listAgencyIdentfier=”260”>D01<MeterReadingType>
Målingsenhed
Klasse
Angiver om måleren måler salderende eller
akkumulerende
MeterDetailMeterCha
racteristic
UnitType
Type
MeasurementUnitCommonCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Angiver måleenheden for hvilken måleren måler
<UnitType listAgencyIdentifier=”260”>KWH</UnitType>
Dok. 13/101713-21
214 / 237
8.14. MeterFacility
Måler ID
Klasse
Ex.
MeteringInstallation
MeterFacility
MeterIdentification
Type
Text
Validering
MeterIdentification <= 15 tegn
Beskrivelse
Målerens nummer
<MeterIdentification>303039</MeterIdenfication>
8.15. MeteringGridAreaUsedDomainLocation
Netområde
Klasse
Ex.
Identification
Type
Text
Validering
MeteringGridAreaIdentification = 3 cifre og
schemeIdentifier = "DK"
Beskrivelse
Netområde er en betegnelse for et net, som
administreres af en netvirksomhed. Dansk Energis
kode anvendes (DE nr.)
<MeteringGridAreaUsedDomainLocation>
<Identification
schemeAgencyIdentifier="260" schemeIdentifier="DK">027</Identification>
</MeteringGridAreaUsedDomainLocation>
8.16. MeteringPointDomainLocation
Målepunkts ID
Klasse
Ex.
Identification
Type
Text
Validering
GSRN nummer = 18 cifre
Beskrivelse
Entydig identifikation af et målepunkt.
GSRN nummer = 18 cifre og schemeAgencyIdentifier
=9
<MeteringPointDomainLocation>
<Identification schemeAgencyIdentifier= "9">579999993331812345</Identification>
</MeteringPointDomainLocation>
8.17. MeteringPointCharacteristic
Forventet årsforbrug
Klasse
MeteringPointCharac
teristic
Dok. 13/101713-21
EstimatedAnnualVolume
Type
Decimal
Validering
EstimatedAnnualVolume <= 18 cifre heltal
Beskrivelse
Det forventede årlige volumen (ofte baseret på sidste
års faktiske forbrug). Angives i kWh uden decimaler.
Opgives altid i kWh. Det er valgfrit, om unitCode
angives.
215 / 237
Ex.
<EstimatedAnnualVolume>1234</EstimatedAnnualVolume>
Timedata
Klasse
MeteringPointCharac
teristic
HourlyTimeSeries
Type
Validering
Beskrivelse
Ex.
Ex.
MeteringPointCharac
teristic
MeteringGridAreaID
Type
Text
Validering
MeteringGridAreaIdentification = 3 cifre og
schemeAgencyIdentifier = "DK”
Beskrivelse
Netområde er en betegnelse for et net, som
administreres af en netvirksomhed. Dansk Energis
kode anvendes (DE nr.)
<MeteringGridAreaUsedDomainLocation>
<Identification
schemeAgencyIdentifier="260" schemeIdentifier="DK">027</Identification>
</MeteringGridAreaUsedDomainLocation>
Aflæsningsfrekvens
Klasse
Ex.
MeteringPointCharac
teristic
MeterReadingOccurrence
Type
Text
Validering
P1Y, P1M, PT1H, PT15M eller ANDET
Beskrivelse
ISO standard ISO 8601 anvendes til at udtrykke
opløsning
Enten format: PnYnMnDTnHnMnS, hvor nY udtrykker
antallet af år og så videre til nM et antal af minutter og
nS et antal sekunder.
Eller teksten "ANDET"
<MeterReadingOccurrence>PT1H</MeterReadingOccurrence>
Nettoafregningsgruppe
Klasse
Ex.
Angiver om et skabelonafregnet målepunkt modtager
timedata eller ej (true = timedata)
<HourlyTimeSeries>true</HourlyTimeSeries>
Netområde
Klasse
Boolean
MeteringPointCharac
teristic
NetSettlementGroup
Type
Text
Validering
<=2 cifre
Beskrivelse
Der angives værdien 0 for målepunkter, som ikke er
nettoafregnet.
<NetSettlementGroup>0</NetSettlementGroup>
Dok. 13/101713-21
216 / 237
Aflæsningsform
Klasse
MeteringPointCharac
teristic
MPReadingCharacteristics
Type
MPReadingCharacteristicsCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Angivelse af, hvordan målepunktet aflæses
(fjernaflæst eller manuelt)
Kun relevant for skabelonafregnede målepunkter
<MPReadingCharacteristics listIdentifier="DK" listAgencyIdentifier=
"260">D01</MPReadingCharacteristics>
Tilslutningsstatus
Klasse
MeteringPointCharac
teristic
PhysicalStatusOfMeteringPoint
Type
PhysicalStatusCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<PhysicalStatusOfMeteringPoint
listAgencyIdentifier="260">E22</PhysicalStatusOfMeteringPoint>
Nominel aflæsningsdag
Klasse
Ex.
MeteringPointCharac
teristic
ScheduledMeterReadingDate
Type
Text
Validering
MMDD. Skal være gyldig kombination af måned (MM)
og dag (DD).
Beskrivelse
Nominelle aflæsningsdage på et skabelonafregnet
målepunkt. Attributten kan gentages op til 12 gange
(12 datoer)
<ScheduledMeterReadingDate>1220</ScheduledMeterReadingDate>
Afregningsform
Klasse
Målepunktets status
MeteringPointCharac
teristic
SettlementMethod
Type
SettlementMethodCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<SettlementMethod listAgencyIdentifier="260">E02</SettlementMethod>
Målepunktstype
Klasse
Målepunktets afregningsform
MeteringPointCharac
teristic
TypeOfMeteringPoint
Type
MeteringPointTypeCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Målepunktets type
<TypeOfMeteringPoint listAgencyIdentifier="260">E17</TypeOfMeteringPoint>
Målepunktsart
Dok. 13/101713-21
SubTypeOfMeteringPoint
217 / 237
Klasse
Ex.
MeteringPointCharac
teristic
Type
MeteringPointSubTypeCode
Validering
Tjekkes mod kodelisten.
Beskrivelse
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
< MeteringPointSubTypeCode listIdentifier="DK"
listAgencyIdentifier="260">D01</MeteringPointSubTypeCode >
FraNet
Klasse
Ex.
MeteringPointCharac
teristic
FromGrid
Type
Text
Validering
MeteringGridAreaIdentification = 3 cifre og
schemeIdentifier = "DK"
Beskrivelse
Netområde er en betegnelse for et net, som
administreres af en netvirksomhed. Dansk Energis
kode anvendes (DE nr.)
<MeteringGridAreaUsedDomainLocation>
<Identification
schemeAgencyIdentifier="260" schemeIdentifier="DK">027</Identification>
</MeteringGridAreaUsedDomainLocation>
TilNet
Klasse
Ex.
ToGrid
MeteringPointCharac
teristic
Type
Text
Validering
MeteringGridAreaIdentification = 3 cifre og
schemeIdentifier = "DK"
Beskrivelse
Netområde er en betegnelse for et net, som
administreres af en netvirksomhed. Dansk Energis
kode anvendes (DE nr.)
<MeteringGridAreaUsedDomainLocation>
<Identification
schemeAgencyIdentifier="260" schemeIdentifier="DK">027</Identification>
</MeteringGridAreaUsedDomainLocation>
Produkt
Klasse
MeteringPointCharac
teristic
Product Type
Type
EnergyProductIdentificationCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Produktidentifikation
Produktet kan eksempelvis være energi eller
effekt. GLN nr. benyttes til angivelse af produkt.
Ex.
<Identification listAgencyIdentifier=”9”>1234567890123</Identification>
Dok. 13/101713-21
218 / 237
Energienhed
Klasse
Ex.
MeteringPointCharac
teristic
UnitType
Type
MeasurementUnitCommonCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Angiver enheden
<UnitType listAgencyIdentifier=”260”>KWH</UnitType>
Målepunktskommentar
Klasse
Ex.
MeteringPointCharac
teristic
LocationDescription
Type
Text
Validering
An..60
Beskrivelse
Eventuel beskrivelse af målers placering
<LocationDescription>Bygning nr. 2</LocationDescription>
VærksGSRN
Klasse
Ex.
MeteringPointCharac
teristic
Powerplant
Type
Text
Validering
GSRN nummer = 18 cifre
Beskrivelse
Entydig identifikation af et målepunkt.
GSRN nummer = 18 cifre og schemeAgencyIdentifier
=9
<PowerPlant>
<Identification schemeAgencyIdentifier= "9">579999993331812345</Identification>
</PowerPlant>
Ignorer tilladt grænse
Klasse
MeteringPointCharac
teristic
IgnoreMandatoryLimit
Type
Validering
Beskrivelse
Ex.
Ex.
MeteringPointCharac
teristic
Production Obligation
Type
Boolean
Validering
Gælder kun for E18 målepunkter
Beskrivelse
Indikation af om produktionen er i aftagepligten.
(værdi true). Anvendes kun i BRS-036
<ProductionObligation>true</ProductionObligation>
Start af leverance
Klasse
Indikation af om forbrug over obligatorisk grænse er
tilladt (værdi true).
< IgnoreMandatoryLimit >true</ IgnoreMandatoryLimit>
Aftagepligt
Klasse
Boolean
MeteringPointPartyC
haracteristic
Dok. 13/101713-21
SupplyStart
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
219 / 237
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Ex.
<SupplyStart>2010-07-09T22:00:00Z</SupplyStart>
Afbrydelsesart
Klasse
Dato for elleverandørens start af leverance
MeteringPointCharac
teristic
DisconnectionType
Type
DisconnectionTypeCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<DisconnectionType listIdentifier="DK" listAgencyIdentifier="260">D02</
DisconnectionType >
Tilslutningstype
Klasse
Kan målepunkt afbrydes automatisk fra system
MeteringPointCharac
teristic
MPConnectionType
Type
MPConnectionType Code
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
< MPConnectionType listIdentifier="DK" listAgencyIdentifier="260">D01</
MPConnectionType >
Vaskeanvisning
Klasse
Beskriver om et (nettoafregnet) målepunkt er direkte
eller installationstilsluttet
MeteringPointCharac
teristic
MPAddressWashInstruction
Type
MPAddressWashInstructionTypeCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<MPAddressWashInstruction listIdentifier="DK"
listAgencyIdentifier="260">D01</MPAddressWashInstruction>
Anlægskapacitet
Klasse
Ex.
Angiver om målepunktets adresse er eller kan
kontrolleres mod officielt register.
MeteringPointCharac
teristic
MPCapacity
Type
Text
Validering
<= 8 tegn
Beskrivelse
Anlæggets kapacitet i kW
<MPCapacity>35425</ MPCapacity>
8.18. MeteringPointParty
DE branchekode
Klas-
MeteringPointPartyC
Dok. 13/101713-21
ConsumerCategory
Type
Text
220 / 237
se
Ex.
haracteristic
Validering
<= 6 cifre
Beskrivelse
Dansk Energis branchekode
<ConsumerCategory>1244</ConsumerCategory>
Elvarme
Klasse
MeteringPointPartyC
haracteristic
ElectricalHeating
Type
Validering
Beskrivelse
Ex.
Ex.
MeteringPointPartyC
haracteristic
ElectricalHeatingDate
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato for start af beregning. Ved beregning tages
udgangspunkt i sidste DDMM
<ElectricalHeatingDate>2010-07-09T22:00:00Z</ElectricalHeatingDate>
Betalingsvilkår
Klasse
Angiver om elleverandøren eventuelt skal korrigere
elafgiften. true = elvarme
<ElectricalHeating>false</ElectricalHeating>
Elvarme Afgiftsstart
Klasse
Boolean
MeteringPointPartyC
haracteristic
PaymentCondition
Type
PaymentConditionCodeType
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<PaymentCondition listIdentifier="DK" listAgencyIdentifier="260">D04
</PaymentCondition>
Webaccess kode
Klasse
Ex.
MeteringPointPartyC
haracteristic
WebAccessCode
Type
Text
Validering
An..132
Beskrivelse
Kunde adgangskode til målepunkt i webportalen.
Genereres af DataHub og sendes til elleverandør og
udleveres af denne til kunden.
<WebAccessCode>123X4K445</WebAccessCode>
Start af leverance
Klasse
Angiver betalingsvilkår som kode
MeteringPointPartyC
haracteristic
Dok. 13/101713-21
SupplyStart
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
221 / 237
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Ex.
<SupplyStart>2010-07-09T22:00:00Z</SupplyStart>
Leverandørstatus
Klasse
MeteringPointPartyC
haracteristic
HasBalanceSupplier
Type
Boolean
Validering
Beskrivelse
Ex.
Dato for elleverandørens start af leverance
Angiver om der er en aktiv elleverandør.
<HasBalanceSupplier>true</ HasBalanceSupplier >
8.19. MPServiceEvent
Serviceanmodning
Klasse
ServiceRequest
Type
ServiceRequestCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Kode for forespørgsel om service.
F.eks. Genåbning.
<ServiceRequest listIdentifier="DK" listAgencyIdentifier="260">D01</ServiceRequest>
8.20. NonContinuousEnergyObservation
Position
Klasse
Ex.
Position
Type
Integer
Validering
<= 10 cifre
Beskrivelse
Den relative position for en periode i et interval.
Positionen er angivet ved et numerisk heltal startende
med 1
<Position>1</Position>
Kvantum
Klasse
EnergyQuantity
Type
Decimal
Validering
EnergyQuantity <= 18 cifre uden decimaler.
Beskrivelse
Ex.
<EnergyQuantity>123</EnergyQuantity>
Kvantum status
Klas-
Dok. 13/101713-21
QuantityQuality
Type
QuantityQualityCode
222 / 237
se
Ex.
Validering
Tjekkes mod kodelisten.
Beskrivelse
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Hvordan EnergyQuantity er målt.
<QuantityQuality listIdentifier=”DK” list listAgencyIdentifier=”260”>DK</QuantityQuality>
Tællerstand
Klasse
Ex.
MeterReading
Type
Decimal
Validering
MeterReading <= 12 cifre
Uden decimaler
Beskrivelse
Tællerstand som er aflæst sammen med forbruget.
<MeterReading>123456</MeterReading>
8.21. ProductCharacteristic
Identifikation
Klasse
Identification
Type
EnergyProductIdentificationCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Produktidentifikation
Produktet kan eksempelvis være energi eller
effekt. GLN nr. benyttes til angivelse af produkt.
Ex.
<Identification listAgencyIdentifier=”9”>1234567890123</Identification>
Målingsenhed
Klasse
UnitType
Type
MeasurementUnitCommonCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Angiver måleenheden
<UnitType listAgencyIdentifier=”260”>KWH</UnitType>
Målingsprisenhed
Klasse
MeasureUnitPriceType
Type
MeasurementUnitCommonCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Enheden hvormed de enkelte værdier måles.
For forbrugsmålinger vil enheden være kWh.
<MeasureUnitPriceType>KWH</MeasureUnitPriceType>
8.22. ReferenceIdentity
Reference
Dok. 13/101713-21
Identitication
223 / 237
Klasse
Ex.
OriginalBusinessDoc
umentReferenceIden
tity
Type
Text
Validering
An..35
Beskrivelse
Entydig reference til transaktionen i det oprindelige
dokument
<Identification>123456789</Identification>
8.23. ResponseEvent
Transaction ID
Klasse
Ex.
Identification
Type
Text
Validering
An..35
Beskrivelse
Afsenders unikke identifikation af transaktionen
< Identification>246810 </ Identification>
Status
StatusType
Klasse
Type
ResponseConditionCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
Status på svaret af en tidligere transaktion. Status kan
enten være godkendt (39) eller afvist (41)
<StatusType listAgencyIdentifier=”6”>39</StatusType>
Afvisningsårsag
Klasse
ResponseReasonType
Type
ResponseReasonDescriptionCode
Validering
Tjekkes mod kodelisten.
Kodelisteansvarlig udfyldes jævnfør afsnit 3.2
Beskrivelse
Ex.
<ResponseReasonType listAgencyIdentifier="260">E10</ResponseReasonType>
Fejlbeskrivelse
Klasse
Ex.
Kode for afvisningsårsag. Anvendes i forbindelse med
status lig afvist til at beskrive årsag for afvisning.
Se under 'Anvendte koder' for at se gyldige koder.
ReasonText
Type
Text
Validering
An..512
Beskrivelse
Optionel. Anvendes i Acknowledgement
< ReasonText >Afregningsform er ikke korrekt</ReasonText >
8.24. TimeSeriesPeriod
Tidsopløsning
Klas-
Dok. 13/101713-21
ResolutionDuration
Type
Text
224 / 237
se
Ex.
Validering
Format: PnYnMnDTnHnMnS, hvor nY udtrykker antallet
af år og så videre til nM et antal af minutter og nS et
antal sekunder
Beskrivelse
Resolution definerer den præcision som tidsinterval er
opdelt i. Resolution udtrykkes med ISO 8601.
Resolution PT1H udtrykker således en opløsning på 1
time
< ResolutionDuration>PT1H</ ResolutionDuration>
Start Dato
Klasse
Ex.
Start
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<Start>2010-07-09T22:00:00Z </Start>
End
Slut Dato
Klasse
Ex.
Type
DateTime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<End>2010-07-09T22:00:00Z </End>
8.25. VolumeEnergyObservation
Position
Klasse
Ex.
Position
Type
Integer
Validering
<= 10 cifre
Beskrivelse
Den relative position for en periode i et interval.
Positionen er angivet ved et numerisk heltal startende
med 1
<Position>1</Position>
Kvantum
Klasse
Dok. 13/101713-21
EnergyQuantity
Type
Decimal
Validering
Quantity <= 18 cifre.
Beskrivelse
Mængden opgives i den enhed der er angivet i attribut
energyTimeSeriesMeasureUnitmed op til antal tilladte
decimaler.
Mængdeangivelse for en position i et givent interval.
225 / 237
Ex.
<EnergyQuantity>1234</EnergyQuantity>
8.26. RelatedMeteringPoint
Parent målepunkt
Klasse
Ex.
ParentRelatedMeteri
ngPoint
Identification ParentMeteringPoint
Type
Text
Validering
GSRN nummer = 18 cifre
Beskrivelse
Entydig identifikation af et parent målepunkt.
GSRN nummer = 18 cifre og schemeAgencyIdentifier
=9
<Identification schemeAgencyIdentifier= "9">579999993331812345</Identification>
Child målepunkt
Klasse
Ex.
ChildRelatedMeterin
gPoint
Identification ChildMeteringPoint
Type
Text
Validering
GSRN nummer = 18 cifre
Beskrivelse
Entydig identifikation af det tilknyttede målepunkt på
et parent målepunkt.
GSRN nummer = 18 cifre og schemeAgencyIdentifier
=9
<Identification schemeAgencyIdentifier= "9">579999993331812345</Identification>
8.27. MissingDataRequest
Eventkode
Klasse
Ex.
MissingDataRequest
EventCode
Type
DataRequestCode
Validering
Tjekkes mod kodelisten
Beskrivelse
Angiver forretningsårsagen, hvis denne findes, for de
manglende data.
<EventCode schemeAgencyIdentifier="260" schemeIdentifier="DK">true</ EventCode>
Rykkerdato
Klasse
Ex.
RequestPeriod
Type
Datetime
Validering
Formatet er YYYY-MM-DDTHH:MMZ. Det tjekkes at
klokkeslæt er 22:00 (sommertid) eller 23:00
(vintertid). I meddelelsen skal datotid dog angives
efter ISO 8601 som inkluderer sekunder.
Beskrivelse
Dato og tid i UTC+0. Dækker i mange tilfælde over
skæringsdato.
<RequestPeriod>2010-07-09T22:00:00Z</RequestPeriod>
Gentagelser
Klasse
MissingDataRequest
Dok. 13/101713-21
NumberOfReminders
Type
Integer
Validering
226 / 237
Beskrivelse
Ex.
Fortløbende nummerering af hvor mange rykkere der
er udsendt.
< NumberOfReminders>true</ NumberOfReminders>
8.28. Andre
Månedsaggregeringer
Klasse
RequestChargeInfor
mation
MonthlyAggregations
Type
Validering
Beskrivelse
Ex.
Boolean
Angiver i en forespørgsel om der skal inkluderes
månedsaggregeringer
<MonthlyAggregations>true</ MonthlyAggregations>
Dok. 13/101713-21
227 / 237
9. Webservice interface
9.1. Generelle fejlkoder
9.1.1. Transport level (HTTP)
Error code
Type
Meaning
401
Security
Access Denied – in case of issues obtaining the users identity.
403
Security
Problem establishing SSL channel with client certificate
404
System
Requested resource not found (e.g. incorrect SOAP address)
413
System
Content length too large
500
System
In case of any unidentified errors.
9.1.2. Applikation level (SOAP)
Error code
Type
Meaning
MP-MED-0000
System
General Failure
MP-MED-0001
Syntax
Schema validation of service operation (SOAP request) failed
MP-MED-0002
Security
System configuration error
MP-MED-0003
Security
User not authorised (e.g. no rights for the operation, user blocked or
inactive)
MP-MED-0004
Security
Unknown SOAP request
MP-MED-0005
System
Back-end timeout
9.1.3. Parametre til SOAP metoder
Webservice grænsefladen definerer en struktur ”MessageContainer”, som benyttes i
flere metoder.
Figur 130 – XMLSchema, MessageContainer_Type
Element
Type
Notes
MessageReference
xs:string[0..35]
ID, som genereres af det afsendende system og bruges til at
identificere det enkelte kald til DataHub. Skal være unik over tid
DocumentType
xs:string[0..200]
Definerer hvilken forretningsbesked, som udveksles. Se afsnit
9.1.4 for en komplet liste over værdier.
MessageType
xs:string={XML}
Beskriver hvilket format forretningsbeskeden er udtrykt i. Kan kun
være XML
Payload
xs:any
processContents=skip
Forretningsbeskeden indsættes under dette element.
Dok. 13/101713-21
228 / 237
1.1.1.1
Håndtering af indhold
Alle data der udveksles skal være I XML format og sendes som UTF-8.
<?xml version="1.0" encoding="utf-8"?>
9.1.4. DocumentType
Direction
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
DataHub -> Actor
Actor -> DataHub
DataHub -> Actor
DataHub -> Actor
Business Message used in Payload
RSM Message Name
DocumentType (in message)
(XML Namespace)
RSM-001 Request change of supplier
RequestChangeOfSupplier
EEM-RequestChangeOfSupplier
RSM-001 Confirm Change of Supplier
ConfirmChangeOfSupplier
EEM-ConfirmChangeOfSupplier
RSM-001 Reject Change of Supplier
RejectChangeOfSupplier
EEM-RejectChangeOfSupplier
RSM-002 Request cancel change of supplier
RequestCancelEndOfSupply
EEM-RequestCancelEndOfSupply
RSM-002 Confirm cancel change of supplier
ConfirmCancelChangeOfSupplier
EEM-ConfirmCancelChangeOfSupplier
RSM-002 Reject cancel change of supplier
RejectCancelChangeOfSupplier
EEM-RejectCancelChangeOfSupplier
RSM-003 Request re-allocate change of supplier RequestReallocateChangeOfSupplier EEM-RequestReallocateChangeOfSupplier
RSM-003 Confirm re-allocate change of supplier ConfirmReallocateChangeOfSupplier EEM-ConfirmReallocateChangeOfSupplier
RSM-003 Reject re-allocate change of supplier
RejectReallocateChangeOfSupplier EEM-RejectReallocateChangeOfSupplier
RSM-004 Notify Change of Supplier
NotifyChangeOfSupplier
EEM-NotifyChangeOfSupplier
RSM-004 Notify Change of Supplier
NotifyChangeOfSupplier
EEM-NotifyChangeOfSupplier
RSM-005 Request end of supply
RequestEndOfSupply
EEM-RequestEndOfSupply
RSM-005 Confirm end of supply
ConfirmEndOfSupply
EEM-ConfirmEndOfSupply
RSM-005 Reject end of supply
RejectEndOfSupply
EEM-RejectEndOfSupply
RSM-006 Query MasterData
QueryMasterData
EEM-QueryMasterData
RSM-006 Reject Query MasterData
RejectQueryMasterData
EEM-RejectQueryMasterData
RSM-008 Request cancel end of supply
RequestCancelEndOfSupply
EEM-RequestCancelEndOfSupply
RSM-008 Confirm cancel end of supply
ConfirmCancelEndOfSupply
EEM-ConfirmCancelEndOfSupply
RSM-008 Reject cancel end of supply
RejectCancelEndOfSupply
EEM-RejectCancelEndOfSupply
RSM-009 Acknowledgement
Acknowledgement
EEM-Acknowledgement
RSM-009 Acknowledgement
Acknowledgement
EEM-Acknowledgement
RSM-010 Notify Volumes
NotifyVolumes
EEM-NotifyVolumes
RSM-010 Notify Volumes
NotifyVolumes
EEM-NotifyVolumes
RSM-011 Non Continuous Metering
NonContinuousMetering
EEM-NonContinuousMetering
RSM-011 Non Continuous Metering
NonContinuousMetering
EEM-NonContinuousMetering
RSM-012 Metered data time series
MeteredDataTimeSeries
EEM-MeteredDataTimeSeries
RSM-012 Metered data time series
MeteredDataTimeSeries
EEM-MeteredDataTimeSeries
RSM-013 Load profile
LoadProfile
EEM-LoadProfile
RSM-014 Aggregated MeteredData TimeSeries
AggregatedMeteredDataTimeSeries EEM-AggregatedMeteredDataTimeSeries
RSM-015 Request for Validated Metered Data
RequestMeteredDataValidated
EEM-RequestMeteredDataValidated
RSM-015 Reject Validated Metered Data
RejectRequestMeteredData
EEM-RejectRequestMeteredData
RSM-016 Request for Aggregated Metered Data RequestMeteredDataAggregated
EEM-RequestMeteredDataAggregated
RSM-016 Reject Request Metered Data AggregatedRejectRequestMeteredDataAggregatedEEM-RejectRequestMeteredDataAggregated
RSM-017 Request for Aggregated Billing Information
RequestAggregatedBillingInformation EEM-RequestAggregatedBillingInformation
RSM-017 Reject Request for Aggregated Billing Information
Reject_AggregatedBillingInformation EEM-Reject_AggregatedBillingInformation
RSM-018 NotifyMissingData
NotifyMissingData
EEM-DK_NotifyMissingData
RSM-019 NotifyAggregatedWholesaleServices
NotifyAggregatedWholesaleServices EEM-DK_NotifyAggregatedWholesaleServices
RSM-020 Request Service
RequestServices
EEM-RequestServices
RSM-020 Request Service
RequestServices
EEM-RequestServices
RSM-020 Confirm Service
ConfirmServices
EEM-ConfirmServices
RSM-020 Confirm Service
ConfirmServices
EEM-ConfirmServices
RSM-020 Reject Service
RejectServices
EEM-RejectServices
RSM-020 Reject Service
RejectServices
EEM-RejectServices
RSM-021 Request to change metering point attributes
RequestUpdateMasterDataMP
EEM-RequestUpdateMasterDataMP
RSM-021 Confirm change of metering point attributes
ConfirmUpdateMasterDataMP
EEM-ConfirmUpdateMasterDataMP
RSM-021 Reject change of metering point attributes
RejectUpdateMasterDataMP
EEM-RejectUpdateMasterDataMP
RSM-022 Notify Master Data MP
NotifyMasterDataMP
EEM-NotifyMasterDataMP
RSM-023 Response MasterData MP
ResponseMasterDataMP
EEM-ResponseMasterDataMP
RSM-027 Request Update Master Data Consumer RequestUpdateMasterDataConsumer EEM-RequestUpdateMasterDataConsumer
RSM-027 Confirm Update Master Data Consumer ConfirmUpdateMasterDataConsumer EEM-ConfirmUpdateMasterDataConsumer
RSM-027 Reject Update Master Data Consumer RejectUpdateMasterDataConsumer EEM-RejectUpdateMasterDataConsumer
RSM-028 Notify Master Data Consumer
NotifyMasterDataConsumer
EEM-NotifyMasterDataConsumer
RSM-029 Response MasterData, Consumer
ResponseMasterDataConsumer
EEM-ResponseMasterDataConsumer
RSM-030 Request Update Master Data Charge
RequestUpdateMasterDataCharge
EEM-RequestUpdateMasterDataCharge
RSM-030 Confirm Update Master Data Charge
ConfirmUpdateMasterDataCharge
EEM-ConfirmUpdateMasterDataCharge
RSM-030 Reject Update Master Data Charge
RejectUpdateMasterDataCharge
EEM-RejectUpdateMasterDataCharge
RSM-031 Notify charge information
NotifyChargeInformation
EEM-NotifyChargeInformation
RSM-032 Query Master Data Charge
QueryMasterDataCharge
EEM-QueryMasterDataCharge
RSM-032 Response Masterdata Charge
ResponseMasterDataCharge
EEM-ResponseMasterDataCharge
RSM-033 Request update price information
RequestUpdateChargeInformation EEM-RequestUpdateChargeInformation
RSM-033 Confirm update price information
ConfirmUpdateChargeInformation EEM-ConfirmUpdateChargeInformation
RSM-033 Reject update price information
RejectUpdateChargeInformation
EEM-RejectUpdateChargeInformation
RSM-034 Notify charge information
NotifyChargeInformation
EEM-NotifyChargeInformation
RSM-035 Query Charge Information
QueryChargeInformation
EEM-QueryChargeInformation
RSM-035 Response Query Charge Information
ResponseQueryChargeInformation EEM-ResponseQueryChargeInformation
RSM-035 Reject Query Charge Information
RejectQueryChargeInformation
EEM-RejectQueryChargeInformation
Dok. 13/101713-21
229 / 237
9.1.5. Namespaces i XML dokumenter
XML namespace af forretningsbeskeden kan enten være defineret inde i beskeden
eller i “MessageContainer” som standard:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<urn:SendMessageRequest xmlns:urn="urn:www:datahub:dk:b2b:v01">
<urn:MessageContainer>
<urn:MessageReference>MsgRef001</urn:MessageReference>
<urn:DocumentType>RequestMPCharacteristics</urn:DocumentType>
<urn:MessageType>XML</urn:MessageType>
<urn:Payload>
<DK_RequestMPCharacteristics
xmlns="un:unece:260:data:EEM-DK_RequestMPCharacteristics:v01">
<HeaderEnergyDocument>
<Identification>MES032</Identification>
<DocumentType listAgencyIdentifier="260">E10</DocumentType>
<Creation>2002-11-07T12:00:00Z</Creation>
<!-- ...snip... -->
</HeaderEnergyDocument>
Eksempel, der viser angivelse af XML namespace som prefiks, her ”mm”, i
MessageContainer:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<urn:SendMessageRequest xmlns:urn="urn:www:datahub:dk:b2b:v01"
xmlns:mm="un:unece:260:data:EEM-DK_RequestMPCharacteristics:v01">
<urn:MessageContainer>
<urn:MessageReference>MsgRef001</urn:MessageReference>
<urn:DocumentType>RequestMPCharacteristics</urn:DocumentType>
<urn:MessageType>XML</urn:MessageType>
<urn:Payload>
<mm:DK_RequestMPCharacteristics>
<mm:HeaderEnergyDocument>
<mm:Identification>MES032</mm:Identification>
<!-- ...snip... -->
</mm:HeaderEnergyDocument>
9.1.6. Eksempel på SOAP exception
Alle fejl fra DataHub vil være på den nedenstående form:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Client</faultcode>
<faultstring>B2B-009:2127360337054</faultstring>
<faultactor />
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Tallet til højre for kolonnet I elementet “faultstring” kan benyttes af Energinet.dk til
at identificere fejlen.
9.1.7. SOAP metoder
Alle metodekald anses for at være succesfulde, med mindre der returneres en SOAP
exception, som beskrevet i afsnit 9.1.6.
Dok. 13/101713-21
230 / 237
9.2. sendMessage
The sendMessage operation is invoked in order to transmit a business document
(the payload) to DataHub for processing. DataHub performs basic security and
syntax checking synchronously and returns the messageId from the payload as a
confirmation that it has taken ownership of the document and will proceed to
process it. If a semantical or business related error arises during processing,
DataHub can send an RSM-009 (Acknowledgement or APERAK) to the actor with
the source of the error, otherwise the actor can treat the message as being
successfully processed.
9.2.1. Error codes
The following error codes can be returned as part of the synchronous validation by
DataHub
Error
Code
Type
Meaning
B2B-001
Security
The given DocumentType is not recognised
B2B-002
Security
The user of the SendMessage operation is not allowed to
send this type of message (DocumentType) for its role
B2B-003
Syntax
The provided Ids are not unique and have been used before
B2B-004
Syntax
Content size of Payload too large for the given
MessageType, se Forskrift F, bilagsrapport 4, section 2.9)
B2B-005
Syntax
Syntax validation failed for Business Message in Payload
B2B-006
Syntax
MessageType does not match the Business Message in
Payload
B2B-007
System
Internal transformation failed
B2B-008
Security
Sender Identification in the Business Message is not
authorised or user of the SendMessage operation has no
relation with the organisation (i.e. Sender Identification)
B2B-009
System
The provided Ids are not unique in the Business Message
(e.g. same TransactionId or TimeseriesId used in the same
message), or duplicate Ids in requests when calling the
SendMessage operation in parallel.
B2B-010
Syntax
Sender Role and/or Recipient Role not provided (see [RSM]
dependency matrices)
B2B-011
Security
Invalid recipient
B2B-900
System
Internal server error
9.2.2. sendMessageRequest
<?xml version="1.0" encoding="utf-8"?>
<sendMessageRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MessageContainer>
<MessageReference
xmlns="urn:www:datahub:dk:b2b:v01">UV204-2012-09-10T13-12-49.0867</MessageReference>
<DocumentType xmlns="urn:www:datahub:dk:b2b:v01">RequestChangeOfSupplier</DocumentType>
<MessageType xmlns="urn:www:datahub:dk:b2b:v01">XML</MessageType>
<Payload xmlns="urn:www:datahub:dk:b2b:v01">
<DK_RequestChangeOfSupplier xmlns="un:unece:260:data:EEM-DK_RequestChangeOfSupplier:v1">
<HeaderEnergyDocument>
<Identification>MsgId-UV204-20120910-131249.0592</Identification>
<!-- MessageIdentification, This is the value that will be returned -->
<DocumentType listAgencyIdentifier="6">392</DocumentType>
<!-- 392="Request change of supplier" -->
Dok. 13/101713-21
231 / 237
<Creation>2012-09-10T13:12:00.00Z</Creation>
<!-- Date and time for the composition of the message -->
<SenderEnergyParty>
<Identification schemeAgencyIdentifier="9">5799995000007</Identification>
<!-- 9=GS1, GLN of sending party -->
</SenderEnergyParty>
<RecipientEnergyParty>
<Identification schemeAgencyIdentifier="9">5790001330569</Identification>
<!-- 9=GS1, GLN of receiving party -->
</RecipientEnergyParty>
</HeaderEnergyDocument>
<ProcessEnergyContext>
<EnergyBusinessProcess listAgencyIdentifier="260">E03</EnergyBusinessProcess>
<!-- 260="ebIX", E03="Change of Balance Supplier" -->
<EnergyIndustryClassification listAgencyIdentifier="6">23
</EnergyIndustryClassification>
<!-- Must be 23 for the electricity market -->
<EnergyBusinessProcessRole listAgencyIdentifier="260">DDQ</EnergyBusinessProcessRole>
<!— Balance Supplier -->
</ProcessEnergyContext>
<PayloadMPEvent>
<Identification>Sess_Id-20120910-131249.0683</Identification>
<!-- TransactionIdentification, Unique transaction id -->
<StartOfOccurrence>2012-09-29T22:00:00.00Z</StartOfOccurrence>
<!-- Requested switch-date-->
<MeteringPointDomainLocation>
<Identification schemeAgencyIdentifier="9">571313188812345024</Identification>
<!-- 9=GS1, MeteringPointIdentification -->
</MeteringPointDomainLocation>
<BalanceSupplierEnergyParty>
<Identification schemeAgencyIdentifier="9">5799995000007</Identification>
<!-- 9=GS1, Balance supplier -->
</BalanceSupplierEnergyParty>
<BalanceResponsiblePartyEnergyParty>
<Identification schemeAgencyIdentifier="9">5799554400002</Identification>
<!-- 9=GS1, Balance responsible -->
</BalanceResponsiblePartyEnergyParty>
</PayloadMPEvent>
</DK_RequestChangeOfSupplier>
</Payload>
</MessageContainer>
</sendMessageRequest>
9.2.3. sendMessageResponse, XML:
<?xml version="1.0" encoding="utf-8"?>
<sendMessageResponse
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MessageId>MsgId-UV204-20120910-131249.0592</MessageId>
</sendMessageResponse>
Notice that it is the value of //ns:HeaderEnergyDocument/ns:Identification that is returned
in the sendMessageResponse.
9.3. peekMessage
peekMessage is a nonmutating operation and can safely be called periodically in a
loop by the client. It is advised to implement a simple scheduler, which calls
peekMessage at regular intervals when no message is waiting and immediately
after a successful dequeueOperation in order to empty the queue for outgoing
messages.
9.3.1. Error codes
Error Code
B2B-900
Dok. 13/101713-21
Type
System
Meaning
Internal server error
232 / 237
9.3.2. peekMessageRequest
<?xml version="1.0" encoding="utf-8"?>
<peekMessageRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />
There are no arguments to this operation.
9.3.3. peekMessageResponse
<?xml version="1.0" encoding="utf-8"?>
<peekMessageResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MessageContainer>
<MessageReference xmlns="urn:www:datahub:dk:b2b:v01">ENDK_ATS-2012-09-10T13-1338.0708</MessageReference>
<DocumentType xmlns="urn:www:datahub:dk:b2b:v01">ConfirmChangeOfSupplier</DocumentType>
<MessageType xmlns="urn:www:datahub:dk:b2b:v01">XML</MessageType>
<Payload xmlns="urn:www:datahub:dk:b2b:v01">
<DK_ConfirmChangeOfSupplier xmlns="un:unece:260:data:EEM-DK_ConfirmChangeOfSupplier:v1">
<HeaderEnergyDocument>
<Identification>MsgId-datahub--20120910-131338.0568</Identification>
<!-- MessageIdentification, This is the one to be used in dequeueMessage -->
<DocumentType listAgencyIdentifier="6">414</DocumentType>
<!-- 414="Confirmation of start of supply" -->
<Creation>2012-09-10T13:13:00.00Z</Creation>
<!-- Date and time for the composition of the message -->
<SenderEnergyParty>
<Identification schemeAgencyIdentifier="9">5790001330569</Identification>
<!-- 9=GS1, GLN of sending party -->
</SenderEnergyParty>
<RecipientEnergyParty>
<Identification schemeAgencyIdentifier="9">5799995000007</Identification>
<!-- 9=GS1, GLN of sending party -->
</RecipientEnergyParty>
</HeaderEnergyDocument>
<ProcessEnergyContext>
<EnergyBusinessProcess listAgencyIdentifier="260">E03</EnergyBusinessProcess>
<!-- 260="ebIX", E03= "Change of Balance Supplier" -->
<EnergyIndustryClassification listAgencyIdentifier="6">23
</EnergyIndustryClassification>
<!-- Must be 23 for the electricity market -->
<EnergyBusinessProcessRole listAgencyIdentifier="260">DDQ</EnergyBusinessProcessRole>
<!— Balance Supplier -->
</ProcessEnergyContext>
<PayloadResponseEvent>
<Identification>Sess_Id-20120910-131338.0630</Identification>
<!-- TransactionIdentification, Unique transaction id -->
<StatusType>39</StatusType>
<!-- Response status, 39="Approved"-->
<OriginalBusinessDocumentReferenceIdentity>
<Identification>Sess_Id-20120910-131249.0683</Identification>
<!-- OriginalBusinessDocumentIdentificiation, TransactionIdentification from ChangeOf-Supplier-Request-->
</OriginalBusinessDocumentReferenceIdentity>
<MeteringPointDomainLocation>
<Identification schemeAgencyIdentifier="9">571313188812345024</Identification>
<!-- 9=GS1, MeteringPointIdentification -->
</MeteringPointDomainLocation>
</PayloadResponseEvent>
</DK_ConfirmChangeOfSupplier>
</Payload>
</MessageContainer>
</peekMessageResponse>
9.4. dequeueMessage
dequeueMessage is called to dequeue a message using the message id that is
obtained when calling peekMesage.
9.4.1. Error codes
Error
Type
Dok. 13/101713-21
Meaning
233 / 237
Code
B2B-201
System
Cannot dequeue the current message in the
MessageQueue (i.e. the MessageId does not match the
MessageId that has been peeked before)
B2B-900
System
Internal server error
9.4.2. dequeueMessageRequest
<?xml version="1.0" encoding="utf-8"?>
<DequeueMessageRequest xmlns="urn:www:datahub:dk:b2b:v01">
<MessageId>MsgId-datahub--20120910-131338.0568</MessageId>
</DequeueMessageRequest>
9.4.3. dequeueMessageResponse
<?xml version="1.0" encoding="utf-8"?>
<ns0:DequeueMessageResponse xmlns:ns0="urn:www:datahub:dk:b2b:v01"/>
Dok. 13/101713-21
234 / 237
10. Figurliste
Figur 1 - XMLSchema, DomainLocation ............................................................ 15
Figur 2 - XML Schema, ConsumerParty ............................................................ 15
Figur 3 - XML Schema, Navn på type .............................................................. 15
Figur 4 - XML Schema, Navn på type .............................................................. 16
Figur 5 - XML Schema, Navn på type .............................................................. 16
Figur 6 – XML Schema, Overordnet struktur af meddelelser ............................... 18
Figur 7 – XML Schema, HeaderEnergyDocument ............................................... 18
Figur 8 – XML Schema, ProcessEnergyContext ................................................. 19
Figur 9 - Use Case Diagram for Start af leverance ............................................ 22
Figur 10 - Aktivitetsdiagram for Start af leverance ............................................ 23
Figur 11 - Klassediagram for Anmod start af leverance ...................................... 25
Figur 12 - Klassediagram for Godkend start af leverance ................................... 26
Figur 13 - Klassediagram for Afvis start af leverance ......................................... 26
Figur 14 - Use Case Diagram for Annnuller start af leverance ............................. 28
Figur 15 - Aktivitetsdiagram for Annuller start af leverance ................................ 29
Figur 16 - Klassediagram for Annuller start af leverance .................................... 30
Figur 17 - Klassediagram for Godkend annuller af start af leverance ................... 31
Figur 18 - Klassediagram for Afvis annuller af start af leverance ......................... 32
Figur 19 - Use Case Diagram for Genoptag leverance på målepunkt .................... 33
Figur 20 - Aktivitetsdiagram for Genoptag leverance på målepunkt ..................... 34
Figur 21 - Klassediagram for Anmod tilbageføring af elleverandør ....................... 35
Figur 22 - Klassediagram for Godkend tilbageføring af elleverandør .................... 36
Figur 23 - Klassediagram for Afvis tilbageføring af elleverandør .......................... 37
Figur 24 - Use Case Diagram for Notifikation om skift af elleverandør ................. 38
Figur 25 - Aktivitetsdiagram for Notifikation om skift af elleverandør ................... 39
Figur 26 - Klassediagram for Notifikation om skift af elleverandør ....................... 40
Figur 27 - Use Case Diagram for Ophør af leverance fra elleverandør .................. 42
Figur 28 - Aktivitetsdiagram for Ophør af leverance fra elleverandør ................... 43
Figur 29 - Klassediagram for Anmod om leveranceophør ................................... 44
Figur 30 - Klassediagram for Godkend leveranceophør ...................................... 45
Figur 31 - Klassediagram for Afvis leveranceophør ............................................ 46
Figur 32 - Use Case Diagram for Forespørg om stamdata .................................. 47
Figur 33 - Aktivitetsdiagram for Forespørg om stamdata ................................... 48
Figur 34 - Klassediagram for forespørg om stamdata ........................................ 49
Figur 35 - Klassediagram for afvis forespørg stamdata ...................................... 50
Figur 36 - Use Case Diagram for Annnuller leveranceophør ................................ 53
Figur 37 - Aktivitetsdiagram for Annuller leveranceophør ................................... 54
Figur 38 - Klassediagram for Anmod annuller leveranceophør ............................ 55
Figur 39 - Klassediagram for Godkend annuller leveranceophør .......................... 56
Figur 40 - Klassediagram for Afvis annuller leveranceophør................................ 57
Figur 41 - Use Case Diagram for kvittering ...................................................... 58
Figur 42 - Aktivitetsdiagram for Kvittering ....................................................... 59
Figur 43 - Klassediagram for Kvittering ........................................................... 60
Figur 44 - Use Case Diagram for Fremsend diverse forbrugsopgørelser ............... 61
Figur 45 - Aktivitetsdiagram for Fremsend diverse forbrugsopgørelser ................. 62
Figur 46 - Klassediagram for Notifikation om forbrugsoplysning .......................... 63
Figur 47 - Use Case Diagram for Forbrug for skabelonafregnet målepunkt samt
tællerstand .................................................................................................. 65
Figur 48 - Aktivitetsdiagram for Forbrug for skabelonafregnet målepunkt samt
tællerstand .................................................................................................. 66
Figur 49 - Klassediagram for Notifikation om måleraflæsning ............................. 67
Figur 50 - Use Case Diagram for Fremsend måledata for et målepunkt ................ 70
Figur 51 - Aktivitetsdiagram for Fremsend måledata for et målepunkt ................. 71
Figur 52 - Klassediagram for Notifikation om måledata, målepunkt ..................... 73
Figur 53 - Use Case Diagram for Fremsend andelstal ........................................ 76
Dok. 13/101713-21
235 / 237
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
54 - Aktivitetsdiagram for Fremsend andelstal .......................................... 77
55 - Klassediagram for Notifikation om andelstal ...................................... 78
56 - Use Case Diagram for Fremsend beregnede tidsserier ........................ 80
57 - Aktivitetsdiagram for Fremsend beregnede tidsserier ......................... 81
58 - Klassediagram for Notifikation om aggregerede tidsserier ................... 82
59 - Use Case Diagram for Anmod om måledata på målepunkt .................. 85
60 - Aktivitetsdiagram for Anmod om måledata på målepunkt .................... 86
61 - Klassediagram for Anmod om måledata, målepunkt ........................... 88
62 - Klassediagram for Afvis anmod om måledata .................................... 89
63 - Use Case Diagram for anmod om aggregerede måledata .................... 91
64 - Aktivitetsdiagram for anmod om aggregerede måledata ..................... 92
65 - Klassediagram for Anmod om aggregerede måledata ......................... 94
66 - Klassediagram for Afvis anmod om aggregerede måledata .................. 95
67 - Use Case Diagram for anmod om engrosydelser ................................ 97
68 - Aktivitetsdiagram for anmod om engrosydelser ................................. 98
69 - Klassediagram for Anmod om engrosydelser ................................... 100
70 - Klassediagram for Afvis anmod om engrosydelser ............................ 101
71 - Use Case Diagram for Fremsend hullerlog ....................................... 102
72 - Aktivitetsdiagram for Fremsend hullerlog ........................................ 102
73 - Klassediagram for Notifikation om manglende data .......................... 103
74 - Use Case Diagram for Fremsend beregnede engrosydelser ................ 105
75 - Aktivitetsdiagram for Fremsend beregnede engrosydelser ................. 106
76 - Klassediagram for Notifikation om aggregerede engrosydelser ........... 107
77 - Use Case Diagram for Anmod om serviceydelse ............................... 110
78 - Aktivitetsdiagram for Forespørg om serviceydelse ............................ 111
79 - Klassediagram for Anmod om serviceydelse .................................... 113
80 - Klassediagram for Godkend serviceydelse ....................................... 114
81 - Klassediagram for Afvis serviceydelse ............................................. 114
82 - Use Case Diagram for Ændring af målepunkt stamdata..................... 116
83 - Aktivitetsdiagram for Ændring af målepunkt stamdata ...................... 117
84 - Klassediagram for Anmod opdater stamdata, målepunkt ................... 119
85 - Klassediagram for Godkend opdater stamdata, målepunkt ................ 123
86 - Klassediagram for Afvis opdater stamdata, målepunkt ...................... 123
87 - Use Case Diagram for Fremsend målepunkt stamdata ...................... 125
88 - Aktivitetsdiagram for Fremsend målepunkt stamdata ....................... 126
89 - Klassediagram for Notifikation om stamdata, målepunkt ................... 128
90 - Use Case Diagram for Forespørg om målepunkt stamdata ................. 130
91 - Aktivitetsdiagram for Forespørg om målepunkt stamdata .................. 131
92 - Klassediagram for Svar forespørg stamdata, målepunkt.................... 133
93 - Use Case Diagram for Ændring af kundestamdata ............................ 138
94 - Aktivitetsdiagram for Ændring af kunde stamdata ............................ 139
95 - Klassediagram for Anmod opdater stamdata, kunde ......................... 141
96 - Klassediagram for Godkend opdater stamdata, kunde ...................... 143
97 - Klassediagram for Afvis opdater stamdata, kunde ............................ 143
98 - Use Case Diagram for Fremsend kunde stamdata ............................ 145
99 - Aktivitetsdiagram for Fremsend kunde stamdata ............................. 146
100 - Klassediagram for Notifikation om stamdata, kunde ....................... 147
101 - Use Case Diagram for Forespørg om kunde stamdata ..................... 149
102 - Aktivitetsdiagram for Forespørg om kunde stamdata ...................... 150
103 - Klassediagram for Svar forespørg stamdata, kunde ........................ 151
104 - Use Case Diagram for Ændring af afregningsstamdata .................... 153
105 - Aktivitetsdiagram for Ændring af afregningsstamdata ..................... 154
106 - Klassediagram for Anmod opdater stamdata, afregning .................. 156
107 - Klassediagram for Godkend opdater stamdata, afregning ................ 157
108 - Klassediagram for Afvis opdater stamdata, afregning...................... 157
109 - Use Case Diagram for Fremsend afregningsstamdata ..................... 159
110 - Aktivitetsdiagram for Fremsend afregningsstamdata ....................... 160
Dok. 13/101713-21
236 / 237
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
Figur
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
- Klassediagram for Notifikation om stamdata, afregning ................... 161
- Use Case Diagram for afregningsstamdata .................................... 163
- Aktivitetsdiagram for Forespørg om afregningsstamdata ................. 164
- Klassediagram for Forespørg stamdata, afregning .......................... 166
- Klassediagram for svar forespørg stamdata, afregning .................... 167
- Klassediagram for afvis forespørg stamdata, afregning ................... 168
- Use Case Diagram for Ændring af prisliste ..................................... 169
- Aktivitetsdiagram for Ændring af prisliste ...................................... 170
- Klassediagram for Anmod opdater prisliste .................................... 172
- Klassediagram for Godkend opdater prisliste ................................. 173
- Klassediagram for Afvis opdater prisliste ....................................... 173
- Use Case Diagram for Fremsend prisliste ...................................... 175
- Aktivitetsdiagram for Fremsend prisliste ....................................... 175
- Klassediagram for Notifikation om prisliste .................................... 176
- Use Case Diagram for Forespørg om prisliste ................................. 178
- Aktivitetsdiagram for forespørg om prisliste ................................... 179
- Klassediagram for Forespørg på prisliste ....................................... 181
- Klassediagram for Svar forespørg om prisliste ............................... 182
- Klassediagram for Afvis forespørgsel af prisliste ............................. 183
– XMLSchema, MessageContainer_Type .......................................... 228
Dok. 13/101713-21
237 / 237