Bijlage 1 -BIJZONDERE VOORWAARDEN
Bijlage 1 -BIJZONDERE VOORWAARDEN
SPECIFIEKE ELEMENTEN EIGEN AAN DE DNB
VOOR HET UITVOEREN VAN DE “ALGEMENE VOORWAARDEN” EN DE “TARIEFVOORWAARDEN” VAN DIT CONTRACT
Bijlage 2: CONTROLE VAN DE GASMETERS IN DE ONTVANGSTATIONS
In Ontvangstations die per jaar een totale hoeveelheid van meer dan 5 miljoen m³(n) meten, worden de meters onderworpen aan een periodieke controle van de metrologische prestaties.
De frequentie en het type controle is in functie van het type Ontvangstation.
Er wordt onderscheid gemaakt tussen Ontvangstations met meerdere meetlijnen waarbij de meters in serie kunnen worden geschakeld en Ontvangstations waarbij deze serieschakeling niet mogelijk is.
I. Controles in Ontvangstations met serieschakeling:
Voor deze Ontvangstations wordt een jaarlijkse inspectie van de meters via een serieschakeling uitgevoerd.
Indien het verschil tussen de meetresultaten van de in serie geschakelde meters kleiner of gelijk is aan 1%, wordt er geen bijkomende actie ondernomen. In het tegenovergestelde geval (verschil groter dan 1%) wordt het goede functioneren van de meter(s) in twijfel getrokken en dienen deze opnieuw te worden geijkt of vervangen.
Naast de jaarlijkse inspecties via serieschakeling worden de metrologische prestaties van één van de meters na maximum 15 jaar gecontroleerd. Het afwisselend controleren van de ene of de andere meter van een installatie met twee lijnen maakt het mogelijk de frequentie van een controle voor een gegeven meter op 30 jaar te brengen.
De controle van de metrologische prestaties van de meter gebeurt door:
Xxxxx het demonteren en opsturen van de meter voor revisie en herijking naar een geaccrediteerde ijkbank:
o Revisie houdt minimum het vervangen van de lagers en van de versleten onderdelen in.
o En de teller zal conform zijn aan de geannexeerde regels van het KB van 20 december 1972 betreffende de gasmeters en herijkt zijn volgens NBN EN 12261.
Indien een meter enkel wordt herijkt zonder revisie kan hij opnieuw in gebruik worden genomen voor een duur van maximaal 10 jaar vóór de volgende controle.
Ofwel plaatsen van een nieuwe meter.
Indien betrouwbare “in service check” technieken beschikbaar zijn, zullen deze als alternatief voor een herijking / vernieuwing kunnen worden gebruikt onder volgende voorwaarden:
o De “in service check” techniek wordt door zowel de DNB als Fluxys Belgium als betrouwbaar erkend.
o Indien de nauwkeurigheid van de “in service check” tot op 1% gebeurt kan de meter in dienst blijven voor een duur van maximaal 10 jaar tussen twee controles.
o Indien de nauwkeurigheid van de “in service check” tot op 2% gebeurt kan de meter in dienst blijven voor een duur van maximaal 5 jaar tussen twee controles.
II. Controles in Ontvangstations zonder serieschakeling:
Voor deze Ontvangstations gebeurt de controle van de meter(s) na maximum 15 jaar.
De controle van de metrologische prestaties van de meter gebeurt door
Xxxxx het demonteren en opsturen van de meter voor revisie en herijking naar een geaccrediteerde ijkbank:
o Revisie houdt minimum het vervangen van de lagers en van de versleten onderdelen in.
o En de teller zal conform zijn aan de geannexeerde regels van het KB van 20 december 1972 betreffende de gasmeters en herijkt zijn volgens NBN EN 12261.
Indien een meter enkel wordt herijkt zonder revisie kan hij opnieuw in gebruik worden genomen voor een duur van maximaal 5 jaar vóór de volgende controle.
Ofwel plaatsen van een nieuwe meter.
Toepassen van betrouwbare “in service check” technieken kunnen als alternatief voor een herijking / vernieuwing gebruikt worden onder volgende voorwaarden:
o De “in service check” techniek wordt door zowel de DNB als Fluxys Belgium als betrouwbaar erkend.
o Indien de nauwkeurigheid van de “in service check” tot op 1% gebeurt kan de meter in dienst blijven voor een duur van maximaal 5 jaar tussen twee controles.
De ten laste name van de kosten voor bovenvermelde maatregelen gebeurt als volgt:
De kosten voor de revisie / herijking of vernieuwing zijn ten laste van de eigenaar van de telling van het Ontvangstation.
Voor de jaarlijkse serieschakelingen:
o Voorbereiding en herschikking van de configuratie door de beheerder van het Ontvangstation (Fluxys Belgium of DNB)
o Meten, vergelijken, en rapporteren van de resultaten door Fluxys Belgium;
o Alle rapporten van de jaarlijkse serieschakelingen, onafhankelijk van de eigenaar, worden aan de DNB ter beschikking gesteld.
Een overgangsperiode wordt voorzien om tot de invoering van de controles en revisie/ herijking of vernieuwing om de 15 à 30 jaar te komen:
Tegen 2019, 95 % van alle betrokken installaties in het regime van de controles en revisie / herijking of vernieuwing.
Eind 2020, moeten alle betrokken installaties bovenvermelde maatregelen volgen.
Nieuwe installaties moeten voldoen aan de Algemene Voorschriften Synergrid.
Bijlage 3 -MESSAGE INTERCHANGE AGREEMENT “ MIA ”
INHOUD....................................................................................................................................
1.2 Overzicht versies met revisies van de MIA 4
1.3 Verschilpunten ten opzichte van de vorige versie 4
2.3 Basisprincipe van allocatie 8
2.3.2 Onderscheid tussen RLP, SLP en lokale productie 9
2.3.3 Definitie van bottom-up/top-down allocatie 10
2.3.4 KCF-berekening voor de SLP’s 10
2.3.6 Kwaliteit van de maandelijkse allocatie: ICF en DAI 11
2.4 Notatieconventie voor de berichtuitwisselingstijd 12
2.4.1 Vóór het begin van de maand 12
2.4.3 Na het einde van de maand 12
3 VOORAFGAANDE MEDEDELINGEN 14
3.3 Portfolio, clientswitch en productionswitch 14
3.3.2 Opvolging van berichten 14
3.4 Troubleshooting van portfolio en clientswitch 21
3.4.2 Indicatieve timing voor “troubleshooting” van portfolio en clientswitch 22
3.5 Starten en afsluiten van een combinatie XXX-XXX 00
3.7 Infeed en calorische bovenwaarde 23
3.8 Maandelijkse telemetingen 24
3.9 Combinatie GOS/Bevrachter 24
4.4.1 Meting voor uurlijks telegelezen RLP-Afnamepunten en lokale producties (niet- gevalideerd) 27
4.4.2 Meting voor alle telegelezen RLP-Afnamepunten en lokale producties (niet- gevalideerd) 28
4.5 Opvolging van berichten 28
4.6.1 Vervangwaarden – basisalgoritme 28
5.3.2 Gedetailleerde statusdiagrammen 33
5.3.3 Gedetailleerde activiteitendiagrammen 36
5.3.4 Eenvoudig procesexemplaar 41
5.3.7 Vereenvoudigd proces in het “Use Case”-formaat 43
5.3.8 Versienummers van de gegevens 44
5.4.1 Termijnen en reactietijden 46
5.4.2 Gegevens afkomstig van de DNB’s 47
6.1.3 Inhoud van de berichten 49
6.1.4 Naamgeving van de files 49
6.1.5 Scheidingstekens voor numerieke waarden en decimalen 50
6.2 Headers en footers van berichten 52
6.3 Portfoliobericht (FLXPOR) 54
6.4 Clientswitchbericht (FLXCLS) 55
6.5 Productionswitchbericht (FLXPRS) 57
6.6 Hourly Metering-bericht (FLXHMT) 59
6.7 Daily Metering-bericht (FLXDMT) 61
6.12 Allocatiebericht (FLXALL) 70
6.13 Bericht Infeed-GCV (INFEEDGCV) 74
6.14 ICFDAI-bericht (ICFDAI) 77
6.15 Feedbackbericht (FEEDBACK) 81
6.16 Broadcastbericht (BROADCAST) 83
6.17 ARS Shipper Combinations 84
7 OVERZICHTSTABEL VAN DE TIJDSBEPERKINGEN 86
BIJLAGE II: LIJST MET FOUTBERICHTEN 90
BIJLAGE III: CONTACT FLUXYS 97
BIJLAGE IV: TEKENSET VOOR VRIJE-TEKSTVELDEN 97
1 Document versies
1.1 Algemeen principe
De verschillende versies van de MIA worden aangeduid met één cijfer, dat verhoogt iedere keer dat ingrijpende wijzigingen in het protocol worden aangebracht.
Kleinere veranderingen binnen éénzelfde versie zullen worden aangeduid door te spreken van een revisie van de MIA, met een cijfer dat verhoogd zal worden voor elke verandering. Deze minder belangrijke wijzigingen kunnen te maken hebben met de procesbeschrijving (zie hoofdstukken 3, 4 en 5), alsook met de verschillende berichtspecificaties (zie hoofdstuk 6). Elk van de genoemde paragrafen zal eveneens van een versienummer worden voorzien, telkens beginnend met het versienummer van de betrokken MIA.
Het versienummer voor processen en berichtspecificaties, zal bestaan uit drie cijfers. Het eerste cijfer is de versie van de MIA. Het tweede cijfer is voor wijzigingen die afstemming tussen de DNB’s en Fluxys vereisen. Het laatste cijfer is voor veranderingen die voor sommige partijen compatibiliteit met een vorig versienummer inhouden. Iedere keer dat het versienummer van de MIA toeneemt, worden de laatste twee cijfers van de processen en berichtspecificaties opnieuw op x.1.0. ingesteld, waarbij x staat voor het nieuwe versienummer van de MIA.
Een voorbeeld om een en ander te verduidelijken: het KCF-bericht wordt in januari 2006 – volgens MIA- versie 0 – verstuurd met een punt als decimaalteken. Het versienummer van het bericht is 0.1.0. Op 1 maart wordt ditzelfde bericht verstuurd met een komma. Dat is niet compatibel met het verleden, en bijgevolg is het versienummer van het bericht 0.2.0. Vanaf 8 maart wordt de MIA-versie 1 van kracht, wat betekent dat de berichtspecificatie voortaan overeenkomt met 1.0.0 voor alle berichten en processen, ook voor het KCF-bericht.
1.2 Overzicht versies met revisies van de MIA
Versie | Herziening | Datum van inwerkingtreding | Verschil t.o.v. vorige versie |
0 | 1 | … - 28/2/2006 | |
0 | 2 | 1/3/2006 | KCF-GRF bericht met “,” als decimale teken |
1 | 0 | 8/3/2006 | Validatiecodes metingen voor gemengde DNB’s: M wordt geweigerd V = gevalideerd |
1 | 1 | 13/12/2006 | Mogelijkheid om het nieuwe KCFd- bericht te versturen en wijziging van het INFEEDGCV-bericht |
2 | 0 | 15/01/2009 | Uniformisering van de formaten; aanpassing voor GOS door GOS: ICF-DAI, versienummers voor GRF en Allocation. |
2 | 1 | 13/07/2010 | Review van het document |
2 | 1 | 1/04/2012 ??? | Wijzigingen door Biomethaan productie |
1.3 Verschilpunten ten opzichte van de vorige versie
In deze nieuwe versie is een begin gemaakt met de uniformisering van de gemeenschappelijke elementen: koptekst (header) en voettekst (footer) van het bericht. Zo hoeft men niet langer de beschrijving van deze gedeelten voor elk berichttype te herhalen.
Verder is het aantal decimalen geüniformiseerd: twee decimalen voor de volumes in m³ en voor de energie in kWh; vier decimalen voor de GCV in kWh/m³; acht decimalen voor de GRF, KCF en ICF; geen enkele decimaal voor de DAI.
In de onderstaande tabel staat een overzicht van de nieuwe velden en andere wijzigingen die in versie
2.x.x zijn aangebracht (ten opzichte van versie 1.1.0)
Berichttype | Header | Body | Footer | ||
Portfolio | |||||
Productionswitch | - Veld MARKET | Toevoeging van NAME en TYPE. | de | velden | |
Clientswitch | - Veld MARKET | Toevoeging van NAME en TYPE. | de | velden | |
Hourly Metering | - Geldigheidscode: H, E of ? (niet gebruikt) | ||||
Daily Metering | - Geldigheidscode: H, V, E, M of ? (niet gebruikt) - Leeg veld voor de onbestaande uren (in plaats van 0 voor energie en X voor de geldigheidscode) | ||||
Foutbericht | - Veld MARKET - drie specifieke velden (type, referentie en datum-tijd van het oorspronkelijke bericht) | ||||
GRF | - Veld MARKET | - Velden GRF VERSION - Veld ALLOC VERSION - Lege velden voor onbestaande uren | Toegevoegd | ||
KCF | - Veld MARKET | - Aanhalingstekens verwijderd tussen de regio en het SLP-type - Lege velden voor onbestaande uren | Toegevoegd | ||
KCD | Toegevoegd | ||||
Allocation | - Veld MARKET | - Veld GRF VERSION - Veld ALLOC VERSION - Leeg veld voor de onbestaande uren (in plaats van 0 voor energie en X voor de kwaliteitscode) | |||
Infeed-GCV | - Velden MARKET en MIA- versienummer - "INFEEDGCV" in plaats van "INFGCV" | - Volumes en energie met twee decimalen (in plaats van 0) - ";" aan het regeleinde - Einduur inbegrepen - Leeg veld voor de onbestaande uren | Toegevoegd | ||
ICF-DAI | VOLLEDIG NIEUW BERICHT | ||||
Feedback | VOLLEDIG NIEUW BERICHT | ||||
Broadcast | VOLLEDIG NIEUW BERICHT |
ARS Shipper Combinations | VOLLEDIG NIEUW BERICHT |
Verder zijn nieuwe foutberichten gedefinieerd: zie punt 2.4, 2.5 en 2.6 in bijlage II.
De uitdrukking "TM Client" (“telemetered client” of telegelezen DNB-Eindafnemer) is vervangen door "RLP-Afnamepunt".
2 Algemeen
2.1 Situering
Het settlement-proces beoogt de infeed bestaande uit de infeed vanuit het Fluxys grid (Infeed FLX) en de lokale productie (LPR), te verdelen onder de verschillende marktpartijen op basis van diverse concepten, zoals het reële lastprofiel (RLP), het synthetische lastprofiel (SLP), het standaardjaarverbruik (SJV) enz. De daartoe vereiste berekeningen worden uitgevoerd onder de verantwoordelijkheid van de distributienetbeheerder (DNB).
2.2 Procesdefinitie
Er wordt onderscheid gemaakt tussen twee allocatieprocessen:
Operationeel evenwicht.
Het operationele evenwicht heeft tot doel de infeed_FLX en aardgasverkopen op te volgen zodat het evenwicht op de gasnetten bewaard kan blijven. In dit scenario moeten Fluxys, de bevrachters alsook de leveranciers op de hoogte worden gebracht van de recentste verbruiksgegevens van de toegangspunten die een hoog verbruik kennen, van de recentste productiegegevens van de lokale producties alsook van de geschatte gegevens voor de toegangspunten met een synthetisch lastprofiel (SLP). Bedoeling hiervan is dat de betrokken partijen zo nodig hun nominaties rekening houdend met dit verbruik kunnen aanpassen om de netten in evenwicht te houden.
Fluxys berekent deze allocatie uurlijks op basis van de door de DNB’s doorgegeven informatie (meting, portfolio’s, clientswitch, productionswitch) en de infeedgegevens. Deze informatie wordt door Fluxys aan de bevrachters doorgegeven.
Dit proces wordt ook uurlijkse allocatie of allocatie 1 genoemd.
Maandelijkse allocatie:
De berekening van de maandelijkse allocatievolumes gebeurt op basis van het reële verbruik en schattingen. Deze berekening wordt uitgevoerd door de som van de allocaties voor afname (RLP en SLP) die de DNB’s op een specifiek Geaggregeerd OntvangstStation (GOS) hebben vastgelegd te vergelijken met de infeed (infeed_FLX en lokale productie) op deze GOS.
De na beëindiging van dit proces verkregen allocatie wordt door de DNB’s meegedeeld aan de andere marktdeelnemers (Fluxys, bevrachters en leveranciers).
Deze allocatie wordt ook maandelijkse allocatie of allocatie 2b genoemd (opmerking: de allocatie 2a die in de vorige MIA-versies aan bod kwam, wordt niet langer uitgevoerd).
De infeed die per uur en per GOS wordt uitgelezen wordt verdeeld onder:
o de reële lastprofielen of RLP, dat wil zeggen het gevalideerde reële verbruik per uur en per toegangspunt;
o de lokale productie, dat wil zeggen het gevalideerde reële verbruik per uur en per productie;
o de schattingen voor de toegangspunten die niet over een systeem voor telelezing beschikken.
Het allocatieproces levert derhalve de volgende resultaten op:
- voor Fluxys: de hoeveelheden per bevrachter;
- voor de bevrachters: de hoeveelheden per leverancier;
- voor de leveranciers: de hoeveelheden per bevrachter.
Het gasallocatieproces berust op drie belangrijke stappen: het berekenen van de bottom-up allocatie (door de DNB), het berekenen van de residufactor (door Fluxys) en het berekenen van de definitieve allocatiewaarden of top-down allocatie (door de DNB). Deze informatie wordt vervolgens door de DNB doorgegeven aan Fluxys, aan de bevrachters en leveranciers.
In beide gevallen (operationeel evenwicht en maandelijkse allocatie) wordt de infeed_FLX onder de bevrachters verdeeld. Deze verdeling vindt plaats per GOS, per DNB en per uur.
De eenheid waarmee het gasverbruik en de infeed worden berekend is het kilowattuur (kWh). Daarom is verderop in dit document altijd sprake van energie.
2.3 Basisprincipe van allocatie
GOS
Infeed
Infeed FLX
VNG 1 | ||||
VNG 2 | ||||
VNG 3 | ||||
VNG 1 | ||||
VNG 2 | ||||
VNG 3 | ||||
VNG 1 | ||||
VNG 2 | ||||
VNG 3 | ||||
VNG 1 | ||||
VNG 2 | ||||
VNG 3 | ||||
VNG 1 | ||||
VNG 2 | ||||
VNG 1 | VNG 3 | |||
VNG 1 | ||||
VNG 2 | ||||
VNG 2 | ||||
VNG 3 | ||||
GRF
Lokale Producties
Residu
SLP 31(h, stand.) * KCF(SLP31, h) * Σ SJV(SLP31) per DNB per VNG SLP 32(h, stand.) * KCF(SLP32, h) * Σ SJV(SLP32) per DNB per VNG
SLP 41(h, stand.) * KCF(SLP41, h) * Σ SJV(SLP41) per DNB per VNG
RLP DNB, jaarlijks per DNB per VNG RLP DNB, uurlijks per DNB per VNG RLP Fluxys, uurlijks per DNB per VNG
LPR DNB, uurlijks per DNB voor één VNG
(t) = de letter t als parameter van een waarde stelt een tijdsperiode voor; wat allocaties betreft, gaat het altijd om een gasuur.
InFLX (t) = infeed gedurende tijdsperiode t aangeleverd vanuit het Fluxys grid.
In(t) = infeed gedurende tijdsperiode t bestaande uit de som van de infeed vanuit het Fluxys grid en de infeed vanuit lokale productie.
KCF (t)
= klimaatcorrectiefactor die gedurende tijdsperiode t toegepast moet worden. In de huidige
toestand zijn er drie formules om de KCF te berekenen: één voor het profiel S31, één voor het profiel S41, en één voor het profiel S32. In de drie gevallen wordt voor heel België dezelfde waarde toegepast.
SLP ConsumptionTGU (t)
= de som van het geschatte verbruik van alle SLP-Afnamepunten van een
bevrachter (TGU) die actief is in het desbetreffende GOS gedurende tijdsperiode t gelijk aan één gasuur; het verbruik wordt geschat op basis van het standaardjaarverbruik waarop de klimaatcorrectiefactor wordt toegepast.
NTGU
SLP ConsumptionTGU(i) (t)
i 1
= de som van het geschatte verbruik van alle SLP-Afnamepunten
van alle bevrachters (TGU’s of vervoersnetgebruikers (VNG’s)) die actief zijn in het desbetreffende GOS gedurende tijdsperiode t gelijk aan één gasuur; het verbruik wordt geschat op basis van het standaardjaarverbruik (SJV) waarop de klimaatcorrectiefactor (KCF) wordt toegepast.
RLP supply pointsTGU (t) = de som van het gemeten verbruik van alle RLP-Afnamepunten van een bevrachter (TGU of vervoersnetgebruiker (VNG)) die actief is in het desbetreffende GOS gedurende
tijdsperiode t gelijk aan één gasuur; is geen meting beschikbaar tijdens het uurlijkse allocatieproces, dan wordt de vervangwaarde gebruikt.
NTGU
RLP supply pointsTGU(i) (t) = de som van het gemeten verbruik van alle RLP-Afnamepunten van
i 1
alle bevrachters (TGU’s of vervoersnetgebruikers (VNG’s)) die actief zijn in het desbetreffende GOS gedurende tijdsperiode t gelijk aan één gasuur; is geen meting beschikbaar, dan wordt de vervangwaarde gebruikt.
LPRTGU (t) = de som van de gemeten lokale producties van een bevrachter (TGU of vervoersnetgebruiker (VNG)) die actief is in het desbetreffende GOS gedurende tijdsperiode t gelijk aan één gasuur; is geen meting beschikbaar tijdens het uurlijkse allocatieproces, dan wordt de vervangwaarde gebruikt.
NTGU
LPRTGU(i) (t) = de som van alle gemeten lokale producties van alle bevrachters (TGU’s of
i 1
vervoersnetgebruikers (VNG’s)) die actief zijn in het desbetreffende GOS gedurende tijdsperiode t gelijk aan één gasuur; is geen meting beschikbaar, dan wordt de vervangwaarde gebruikt.
GRF (t)
= residufactor van het GOS die gedurende tijdsperiode t moet worden toegepast en die via
het uurlijkse allocatieproces wordt vastgelegd.
GRF (t, n)= residufactor op een GOS gedurende tijdsperiode t gelijk aan één gasuur, berekend via de berekeningslus n tijdens het maandelijkse allocatieproces. Bij aanvang van het proces gebruikt men
GRF (t, 0) 1; deze waarde wordt ook uitgedrukt als GRF (0) 1.
2.3.2 Onderscheid tussen RLP, SLP en lokale productie
Er bestaan twee soorten DNB-Eindafnemers.
1. RLP-Afnamepunten, waarvoor elke dag of elk uur de uurlijkse verbruikswaarden worden doorgegeven.
Op te merken valt dat nu voor alle RLP-Afnamepunten de metingen uitgelezen worden door de DNB’s die de informatie doorgeven aan Fluxys. Er zijn geen uitzonderingen meer waarvoor de metingen rechtstreeks door Fluxys worden uitgelezen.
Een RLP-Afnamepunt heeft een van volgende 2 types:
a. uurlijks uitgelezen (GOL): verwacht jaarverbruik > 1 miljoen m³(n)
b. dagelijks uitgelezen: verwacht jaarverbruik < 1 miljoen m³(n)
2. SLP-Afnamepunten waarvan het verbruik op langere termijn (maandelijks, jaarlijks) wordt uitgelezen. Daarom worden deze verbruiken geschat, aan de hand van een SLP profiel. Een SLP-profiel toont hoe de dag (vakantie, werkdag…) en de temperatuur invloed hebben op het gasverbruik. Er bestaan 3 SLP-profielen: huishoudelijke eindafnemers (S41), kleine industriële eindafnemers (S31) en industriële grootafnemers (S32). De SLP-factor voor één uur, vermenigvuldigd met een schatting van de hoeveelheid gas die een bepaalde bevrachter jaarlijks voor een bepaald SLP-profiel op een GOS afneemt, geeft het uurlijkse SLP-verbruik voor dit SLP-profiel dat bevoorraad wordt via de bevrachter.
Er bestaat 1 soort lokale productie.
1. Biomethaan productie, waarvoor elk uur de uurlijkse productiewaarden worden doorgegeven. Op te merken valt dat nu voor alle lokale producties de metingen uitgelezen worden door de DNB’s die de informatie doorgeven aan Fluxys. Slechts 1 TGU kan gas leveren vanuit één lokale productie.
2.3.3 Definitie van bottom-up/top-down allocatie
In Figuur 1 staat het principe van de uurlijkse allocatie op basis van een bottom-up allocatie. Wat een GOS en DNB betreft, is de bottom-up allocatie samengesteld uit
- gemeten verbruiksgegevens van de RLP-Afnamepunten als positieve allocatie;
- geschatte verbruiksgegevens van de SLP-Afnamepunten als positieve allocatie;
De som van de bottom-up allocaties van alle DNB’s die op een GOS actief zijn wordt vergeleken met de infeed (infeed_FLX en lokale productie). Op basis van deze vergelijking wordt een correctiefactor (GRF) berekend om de infeed te dekken: het SLP-verbruik wordt vermenigvuldigd met deze GRF.
Deze berekening wordt op uurbasis uitgevoerd.
Aangezien de bevrachters en leveranciers voor de DNB-Eindafnemers en lokale producties bekend zijn, kan men vervolgens bepalen hoe de infeed verdeeld moet worden per bevrachter en per leverancier.
Wat een GOS en een DNB betreft, is de top-down allocatie samengesteld uit
- gemeten verbruiksgegevens van de RLP-Afnamepunten als positieve allocatie;
- de geschatte verbruiksgegevens van de SLP-Afnamepunten als positieve allocatie, vermenigvuldigd met de GRF-factor.
Een bottom-up allocatie is in feite gewoon hetzelfde als een top-down allocatie, zij het dan gebaseerd op een GRF=1.
2.3.4 KCF-berekening voor de SLP’s
Bij wijze van dienstverlening aan de DNB’s berekent Fluxys de klimaatcorrectiefactor (KCF) zodat het geschatte verbruik van de SLP-Afnamepunten voor de DNB in kwestie kan worden bepaald. In de KCF wordt rekening gehouden met de invloed van de gemeten temperaturen op het gasverbruik. De KCF wordt berekend op basis van de volgende formule:
KCF( t )
SLPreal (t) ,
SLPstand (t)
Beide SLP’s moeten positief en verschillend van nul zijn. Dit betekent bijgevolg dat de KCF altijd
positief is. In uitzonderlijke gevallen kan de berekening van SLPreal een negatief resultaat opleveren, wat echter niet met de werkelijkheid kan overeenkomen: dat zou immers betekenen dat de DNB- Eindafnemer gas in het net injecteert. Om dit te voorkomen wordt de volgende uitzondering toegepast:
IF SLPreal ≤ 0
THEN KCF = 0,1
SLPreal = SLPstand * 0,1
waarbij SLPreal de SLP-factor is die op de waargenomen temperaturen berust, terwijl SLPstand de SLP- factor is die op de standaardtemperaturen berust.
De KCF wordt uurlijks berekend voor het voorafgaande uur. De KCF wordt dagelijks aan de DNB’s meegedeeld (voor elk uur van de vorige dag). Men spreekt hier van een tijdelijke (of niet-gevalideerde) KCF aangezien die berust op niet-gevalideerde temperatuurwaarden.
De KCF wordt opnieuw berekend bij het begin van de volgende maand. In dit geval gaat het om de gevalideerde KCF omdat die berust op gevalideerde temperatuurwaarden. De KCF wordt maandelijks doorgegeven aan de DNB’s in een bericht met de waarde voor elk uur van de afgelopen maand.
Om het operationele evenwicht te bewaren past Fluxys de KCF zelf toe op de portfolio’s die door de DNB’s worden meegedeeld.
Wat de maandelijkse allocatie betreft, is het de DNB die de KCF toepast op het standaardverbruik van zijn portfolio met SLP-Afnamepunten.
Wanneer het SLP-verbruik en het RLP-verbruik voor alle bevrachters wordt gesommeerd verminderd met de lokale productie, krijgt men een positief of negatief residu ten opzichte van de infeed. Dit residu wordt op basis van een GRF verdeeld over het geschatte verbruik van de SLP-Afnamepunten. De GRF wordt berekend op basis van de volgende formule:
NTGU NTGU
NTGU
InFLX ( t ) LPRTGU(i) ( t ) - RLP supply pointsTGU(i) ( t ) GRF( t ) i 1 i 1
SLP ConsumptionTGU(i) ( t )
i 1
Deze berekening wordt elk uur “t” uitgevoerd.
De op die manier berekende allocaties dienen voor het operationele evenwicht (elk uur een berekening voor het voorafgaande uur) en voor de maandelijkse allocatie.
In beide gevallen is de input voor de berekening verschillend:
- wat het operationele evenwicht betreft (niet gevalideerde gegevens): infeed_FLX, de RLP-metingen, de LPR-metingen en de SLP-portfolio’s afkomstig van de DNB’s.
- wat de maandelijkse allocatie betreft: gevalideerde infeed, de allocatie (bottom-up of top-down) zoals die hierboven nader is uitgewerkt.
Bij wijze van dienstverlening aan de DNB’s berekent Fluxys de GRF die het mogelijk maakt voor de DNB in kwestie de allocatie te berekenen.
De GRF wordt op de DNB’s toegepast en zij sturen Fluxys aangepaste allocaties op.
Moet de allocatie opnieuw worden berekend, dan berekent Fluxys een SLPCF, waarvan de formule vergelijkbaar is met die voor de GRF.
NTGU NTGU
NTGU
InFLX (t) LPRTGU(i) ( t ) - RLP supply pointsTGU(i) ( t ) SLPCF(t, n 1) i1 i1
SLP ConsumptionTGU(i) ( t )* GRF ( t, n)
i 1
Met de SLPCF berekent Fluxys een nieuwe GRF en verstuurt die naar de DNB’s. De GRF wordt berekend op basis van de volgende formule:
GRF( t, n 1) GRF(t, n)* SLPCF(t, n 1)
waarbij geldt dat GRF(0) = 1.
De laatste GRF(n) moet opnieuw op de basiscijfers van de allocaties worden toegepast omdat het mogelijk is dat deze laatste veranderd zijn. De GRF-factor wordt naar de DNB’s verstuurd. De DNB past deze factor toe op zijn gegevens en stuurt de definitieve allocaties terug.
Op te merken valt dat als de basiscijfers van de allocatie (dat wil zeggen de bottom-up allocatie) en de infeed niet veranderd zijn sedert de berekening van de vorige GRF, de SLPCF gelijk zal zijn aan 1 en de nieuwe GRF (n+1) gelijk zal zijn aan de vorige GRF(n).
2.3.6 Kwaliteit van de maandelijkse allocatie: ICF en DAI
De kwaliteit van een bottom-up allocatie (of een top-down allocatie) kan beoordeeld worden op basis van twee factoren die de dekkingsgraad van de infeed aangeven, enerzijds in absolute waarde en anderzijds in relatieve waarde:
- De ICF (Infeed Coverage Factor) is het dekkingspercentage van de infeed (infeed_FLX + lokale productie). Deze factor geeft aan welk percentage van de infeed van een GOS gedekt wordt door de som van de afname (RLP en SLP) van de gezamenlijke DNB’s die op dit GOS actief zijn
ICF = (RLP-verbruik + gecorrigeerd geschat SLP-verbruik) / infeed_FLX + Lokale Productie
- De DAI (Difference Allocation Infeed) geeft het verschil in absolute waarde (uitgedrukt in kWh) tussen de infeed (infeed_FLX + lokale productie) en de som van de afname allocaties (RLP en SLP) van de DNB’s die op het GOS actief zijn.
DAI = | RLP-verbruik + gecorrigeerd geschat SLP-verbruik – Infeed FLX – Lokale Productie |
2.4 Notatieconventie voor de berichtuitwisselingstijd
2.4.1 Vóór het begin van de maand
M – 3 kalenderdagen: verwijst naar de derde kalenderdag vóór het begin van de maand.
Voorbeeld: voor de allocatie van de maand april is M-3 gelijk aan 29 maart, terwijl M-1 gelijk is aan 31 maart.
M – 3 werkdagen: verwijst naar de derde werkdag vóór het begin van de maand.
Voorbeeld: voor de allocatie van april 2008, is M-3 gelijk aan 27 maart, terwijl M-2 gelijk is aan 28 maart en M-1 gelijk is aan 31 maart 2008 (aangezien 29 en 30 maart respectievelijk op een zaterdag en een zondag valt).
M/10: verwijst naar de tiende kalenderdag van de maand.
M/10 werkdagen: verwijst naar de tiende werkdag van de maand.
2.4.3 Na het einde van de maand
M + 10 kalenderdagen: verwijst naar de tiende kalenderdag na het einde van de maand, dat wil zeggen de tiende dag van de volgende maand. Voor de allocatie van februari bijvoorbeeld, is M+10 gelijk aan 10 maart.
M + 10 werkdagen: verwijst naar de tiende werkdag na het einde van de maand. Voor de allocatie van februari 2008 bijvoorbeeld, is M+10 gelijk aan 14 maart 2008.
Worden als niet-werkdagen beschouwd:
- alle zaterdagen en zondagen;
- alle wettelijke feestdagen in België;
- alle dagen waarop de maatschappelijke zetel van Fluxys gesloten is.
Als een bericht vóór datum X verstuurd moet worden, gaat men ervan uit dat het bericht tijdig op zijn bestemming is aangekomen als de FTP-transmissie voltooid is vóór de daarop volgende dag (X+1) om
8.00 uur lokale tijd.
2.5 Foutbericht
Iedere keer dat een DNB een bericht verstuurt naar Fluxys volgens de berichtspecificatie die nader is omschreven in hoofdstuk 6, verstuurt Fluxys, wanneer in het geheel of een deel van dit bericht een fout wordt ontdekt (onjuist formaat of niet-overeenkomende gegevens), een foutbericht met opgave van de reden waarom de verwerking is mislukt. Aan de hand van dit foutbericht kan de DNB de foutieve berichten aanpassen.
Het foutbericht geeft aan waarom de verwerking mislukt is. Het gedeelte van het bericht waarin de fout zich bevond, zal niet worden verwerkt. Dit foutieve "gedeelte" kan niet alleen het volledige bericht zijn (bijvoorbeeld onjuist formaat in de header van het bericht), maar ook betrekking hebben op bepaalde berichtregels, of één enkele regel (bijvoorbeeld een regel in een HMetering-bericht waarin een foutief veldscheidingsteken staat) of een waarde (bijvoorbeeld een meetwaarde met een ongeldige meetstatus in een regel met meerdere meetwaarden).
Een aantal voorbeelden van foutberichten:
Ongeldige bevrachter
Ongeldige GOS-DNB combinatie
Leeg bericht
Formaatfout
Bericht voor afgesloten periode
…
Het foutbericht volgt de berichtspecificatie FLXFAU.
Voor de berichten waarvan het veld SUBJECT, TO, FROM of MS onleesbaar is, kan voorlopig geen foutbericht door Fluxys gewaarborgd worden.
2.6 Gasdag
Een gasdag begint om 6.00 uur lokale tijd en eindigt de dag daarna om 6.00 uur lokale tijd.
3 Voorafgaande mededelingen
3.1 Versienummer
Het versienummer voor de informatie in dit hoofdstuk is 2.1.0.
Deze specificatie is niet veranderd ten opzichte van de versie 1.1.0. Het berichtformaat is licht herwerkt, zoals nader toegelicht in de paragraaf 1.3 ‘Verschilpunten ten opzichte van de vorige versie’.
3.2 Doel
In dit hoofdstuk staan de mededelingen die plaatsvinden vóór het begin van de gasmaand en waarin nuttige gegevens zijn vermeld voor het proces ‘Operationeel evenwicht’ dat is beschreven in hoofdstuk 4 en/of voor het proces ‘Maandelijkse allocatie’ dat is beschreven in hoofdstuk 5.
3.3 Portfolio, clientswitch en productionswitch
De voorlopige clientswitch, productionswitch en de voorlopige portfolio (of de eerste clientswitch, productionswitch en de eerste portfolio) moeten Fluxys uiterlijk bereiken op M-3 werkdagen.
Op het ogenblik dat een noemenswaardige wijziging in de situatie van clientswitch, productionswitch of portfolio duidelijk wordt bij de DNBs, zal dit onmiddellijk gecommuniceerd worden aan Fluxys door het opsturen van nieuwe portfolio, productionswicth of clientswitch-berichten, ook al was het eerste (maar intussen achterhaalde) bericht tijdig aan Fluxys overgemaakt.
Alle wijzigingen behalve het tussentijds veranderen van de portfoliowaarden worden door de betrokken partijen als noemenswaardig beschouwd.
In het wijzigingsbericht staan de waarden van de eerste tot de laatste dag van de maand. Om de uurlijkse allocatie te berekenen worden echter uitsluitend de toekomstige waarden gebruikt (operationeel evenwicht).
De gevalideerde cliëntswitch en productionswitch moeten Fluxys uiterlijk bereiken tegelijkertijd met de eerste maandelijkse allocatie op M + 14 (gegevens van de maand M).
3.3.2 Opvolging van berichten
Een productionswitch-, clientswitch- of portfoliobericht bevat de informatie voor een DNB waarop het bericht betrekking heeft, en wel voor precies één gasmaand.
De portfolioberichten bevatten per bericht alle informatie van één DNB (en eventueel enkel één GOS). Een clientswitch-bericht bevat alle informatie van alle RLP-Afnamepunten van één DNB.
Een productionswitch-bericht bevat alle informatie van alle lokale producties van één DNB.
Nieuwe RLP-Afnamepunten, lokale producties of nieuwe portfolio’s voor een bepaalde DNB worden met andere woorden aan Fluxys meegedeeld door een extra lijn met het RLP-Afnamepunt, lokale productie of de portfolio en de geldigheidsperiode in de gasmaand op te nemen in het bericht. Wanneer een RLP-Afnamepunt, lokale productie of portfolio inactief wordt, wordt dit weergegeven door het betrokken RLP-Afnamepunt, lokale productie of de portfolio vanaf de datum waarop hij inactief wordt, niet meer op te nemen in het bericht.
Wanneer een RLP-Afnamepunt, lokale productie of portfolio slechts voor een gedeelte van de gasmaand actief is, wordt dit aangeduid door de activiteitsperiode in het bericht op te nemen. Als een RLP-Afnamepunt bijvoorbeeld actief is van de eerste tot de tiende dag van de gasmaand, en vervolgens van de twintigste dag tot het einde van de gasmaand, heeft dit tot gevolg dat het bericht twee regels met de respectievelijke periodes bevat.
Wanneer een clientswitch-, productionswitch- of portfoliobericht niet tijdig is aangekomen bij Fluxys, worden vervangingswaarden gebruikt, waardoor de situatie uit de voorbije gasmaand verlengd wordt. Wanneer echter een clientswitch-, productionswitch- of portfoliobericht toekomt waarin een bepaald
RLP-Afnamepunt, lokale productie of portfolio niet meer aanwezig is voor (een bepaald deel van) de gasmaand, krijgt dit RLP-Afnamepunt, lokale productie of deze portfolio de status “inactief” voor de betrokken periode, en wordt deze niet meer in rekening gebracht voor de allocatie. Een bericht zal dus telkens de volledige informatie voor de volledige gasmaand weergeven, en dit volgens de afgesproken inhoud van het bericht:
Portfolio: alle portfolio’s van de DNB (en eventueel GOS);
Clientswitch: alle RLP-Afnamepunten van de DNB;
Productionswitch: alle lokale producties van de DNB. Het bovenstaande punt wordt geïllustreerd in de volgende figuur.
Client switch message Fluxys database
RLP point a RLP point b RLP point c
RLP point a RLP point b RLP point c
January
RLP point a RLP point b RLP point c
February
RLP point a RLP point b RLP point c
RLP point a RLP point b RLP point c
March
RLP point a RLP point c
RLP point a RLP point c
April
RLP point a RLP point b RLP point c
RLP point a RLP point b RLP point c
May
Bemerk dat RLP-Afnamepunt b in Figuur 2 inactief is voor de hele gasmaand april, aangezien het niet in het clientswitch bericht voor april zit. Evengoed had het van 1/4 tot 10/4 in de clientswitch kunnen zitten, in welk geval hij vanaf 11/4 tot het einde van april inactief zou zijn geworden.
Zoals aangegeven in Figuur 3 hieronder, worden de metingen niet door Fluxys aanvaard als geen enkele clientswitch met de gegevens over DNB-Eindafnemer voor de meting ontvangen is op D-3 werkdagen, waarbij D de dag is waarop de meting ontvangen is. Met andere woorden, als de
clientswitch te laat binnenkomt, kan de verwerking van de meting voor nieuwe RLP-Afnamepunten in deze clientswitch, of voor RLP-Afnamepunten met informatie die tegenstrijdig is met de reeds gekende informatie (zie Figuur 4 hieronder), pas gegarandeerd worden drie dagen nadat een gecorrigeerde clientswitch probleemloos is verwerkt.
Fluxys zal niet verantwoordelijk gesteld worden voor de allocaties die gebeuren of gebeurd zijn zonder de meting in rekening te brengen.
Metering arrives for unknown client
Fluxys
DGO
ErrorMessage
DATE = 20/1
Metering
For 3/1 - 20/1
Client switch
“No client info for january for client”
Contains client from 3/1 - 31/1
Metering
DATE = 23/1
For 3/1 - 23/1
Een RLP-Afnamepunt wordt geacht per dag niet meer dan 1 “owning” DNB te hebben. Zoals blijkt uit Figuur 4 hieronder wordt een RLP-Afnamepunt dat van DNB verandert, opgenomen in de clientswitch van de “oude” DNB voor de eerste periode (al dan niet een volledige gasmaand), en in de clientswitch van de “nieuwe” DNB voor de daarop volgende periode. Zijn er echter twee conflicterende clientswitches voor hetzelfde RLP-Afnamepunt (dat wil zeggen één RLP-Afnamepunt dat aanwezig is in twee clientswitches van twee verschillende DNB’s met overlappende perioden), dan wordt het eerst aanvaarde bericht door Fluxys als het juiste beschouwd. Als de tweede conflicterende clientswitch aankomt, zal er een foutbericht worden uitgestuurd, zowel naar de “late” DNB, als naar de DNB die het eerste en aanvaarde clientswitch-bericht heeft verstuurd. Beide DNB’s moeten dan tot een akkoord komen en een nieuw verbeterd bericht sturen. Als er sprake is van een verkeerde situatie, zal de “oude” DNB vervolgens eerst een verbeterd clientswitch-bericht sturen. Daarna kan de “nieuwe” DNB een verbeterd clientswitch bericht sturen met het RLP-Afnamepunt erin.
Conflicting client switches
“old” DGO “new” DGO
Fluxys
DGO 1
DGO 2
Metering
DATE =
25/12
Client switch
DATE =
4/1
ErrorMessage
Client switch
ErrorMessage
For january with client x For 1/1 for client x
For january with client x
“client” x was sent by DGO2 for january
“client” x was sent by DGO1 for january
Client switch
Metering
DATE =
5/1
Metering is still accepted For january without client x
DATE =
6/1
Client switch
For january with client x
DATE =
9/1
Metering
For 1/1 - 9/1
Figuur 5 stelt de volgende situatie voor. Stel dat DNB x en DNB y clientswitch berichten sturen met hetzelfde RLP-Afnamepunt voor dezelfde gasmaand. Stel dat ze bovendien ook beide meting sturen voor dit RLP-Afnamepunt. De DNB die volgens het hierboven beschreven systeem niet verantwoordelijk is voor het RLP-Afnamepunt (die een clientswitch-bericht heeft gestuurd, terwijl er al een clientswitch-bericht van een andere DNB is toegekomen) zal een foutbericht krijgen voor elke meting die hij naar Fluxys stuurt. Alleen metingen van de DNB die verantwoordelijk is voor het RLP- Afnamepunt volgens het bovenstaande systeem, zullen worden aanvaard.
Metering coming from “not owning” DGO
“old” DGO “new” DGO
Fluxys
DGO 1
DGO 2
Client switch
Metering
ErrorMessage
Metering
For january with client x For 1/1 for client x
“client owned by DGO2 on 14/1”
For 1/1 for client x
Wanneer er voor nieuwe RLP-Afnamepunten vervangingswaarden voor metering nodig zijn, en deze nog niet kunnen worden berekend wegens gebrek aan historische gegevens, zullen deze gelijkgesteld worden aan 0.
Zoals te zien is in Figuur 6 zal zich het volgende voordoen wanneer een RLP-Afnamepunt switcht van DNB, maar de periodes van de “oude” DNB en de “nieuwe” DNB niet naadloos aansluiten. Wanneer de “oude” DNB toch metingen zou sturen voor het RLP-Afnamepunt, zal hij een bericht krijgen met daarin de melding dat het RLP-Afnamepunt inactief is. Wanneer de “nieuwe” DNB metingen stuurt voor het RLP-Afnamepunt, krijgt hij een bericht met daarin de melding dat het RLP-Afnamepunt tot de “oude” DNB behoort voor de gegeven dag.
Non Conflicting client switches
“old” DGO “new” DGO
Fluxys
DGO 1
DGO 2
Client switch
Client switch
15/12-31/12 for client x
1/12-13/12 for client x
ErrorMessage
Metering
For 14/1 for client x
“client is inactive on 14/1”
Metering
For 14/1 for client x
ErrorMessage
“client not owned by DGO2 on 14/1”
Wanneer het clientswitch- of portfoliobericht een onbestaande GOS-DNB combinatie zou bevatten, zal er een foutbericht door Fluxys worden gestuurd en worden de betrokken lijnen in het bericht geweigerd. In antwoord hierop zal dan eerst een nieuwe GOS-DNB combinatie worden aangemaakt (communicatie via mail), en het clientswitch-, productionswitch-/ portfoliobericht (evenals de intussen gestuurde metingen voor de betrokken RLP-Afnamepunt(en) of lokale producties wanneer het om een clientswitch of productionswitch bericht gaat) zal nogmaals gestuurd worden indien de GOS-DNB combinatie aangemaakt is.
Bevat het clientswitch-, production- of portfoliobericht een bevrachter die geen vervoerscontract heeft op het GOS in kwestie, dan wordt een foutbericht verstuurd en worden de desbetreffende berichtregels geweigerd. Is de inconsistentie tussen de DNB en Fluxys uitgeklaard (hetzij bij de DNB, hetzij bij Fluxys na onderling overleg), dan wordt het clientswitch-, productionswitch- of portfoliobericht opnieuw verstuurd (samen met de intussen verstuurde metingen voor het (de) RLP-Afnamepunt(en) of lokale productie in kwestie, voor zover het om een clientswitchbericht of productionswitch gaat).
Wanneer een clientswitch bericht een lokale productie bevat of wanneer een productionswitch bericht een RLP-Afnamepunt bevat, zal een foutbericht verstuurd worden en worden de desbetreffende berichtregels geweigerd. Het bericht moet na correctie opnieuw verstuurd worden.
3.3.3 Vervangwaarden voor portfolio, clientswitch en productionswitch berichten
Heeft Fluxys op gasdag 1 van gasmaand M nog steeds geen geldig (portfolio-/productionswitch-/ clientswitch) bericht van een DNB (voor een bepaald GOS) ontvangen, dan beschouwt Fluxys de situatie van de vorige gasdag (M-1 dag) als geldig.
Voorbeeld op basis van het FLXCLS-bericht: men ontvangt het volgende bericht voor de gasmaand januari 2004:
[BODY START]
01012004 06:00;01022004 05:00;RLP1 NAME;RLP1 TYPE;RLP1 EAN;GOS EAN;VNG1 EAN;DNB EAN;
01012004 06:00;01022004 05:00;RLP2 NAME;RLP2 TYPE;RLP2 EAN;GOS EAN;VNG2 EAN;DNB EAN;
01012004 06:00;16012004 05:00;RLP3 NAME;RLP3 TYPE;RLP3 EAN;GOS EAN;VNG1 EAN;DNB EAN; [BODY END]
Is geen enkel geldig bericht binnengekomen voor de gasmaand februari, dan wordt de volgende situatie als geldig beschouwd op de eerste gasdag van februari:
[BODY START]
01012004 06:00;02022004 05:00;RLP1 NAME; RLP1 TYPE;RLP1 EAN;GOS EAN;VNG1 EAN;DNB EAN;
01012004 06:00;02022004 05:00;RLP2 NAME; RLP2 TYPE;RLP2 EAN;GOS EAN;VNG2 EAN;DNB EAN; [BODY END]
Op te merken valt dat RLP3 niet in de vervangwaarden gebruikt wordt omdat de combinatie RLP3- VNG1 niet langer geldig was vanaf de gasdag 16 januari tot het einde van de gasmaand januari.
Heeft Fluxys op 2 februari nog steeds geen geldig bericht ontvangen, dan wordt de volgende situatie als geldig beschouwd:
[BODY START]
02012004 06:00; 03022004 05:00;RLP1 NAME; RLP1 TYPE; RLP1 EAN;ARS EAN;VNG1 EAN;DNB EAN;
02012004 06:00; 03022004 05:00;RLP2 NAME; RLP2 TYPE; TLP2 EAN;ARS EAN;VNG2 EAN;DNB EAN; [BODY END]
Dit gaat zo verder tot Fluxys een geldig bericht voor de huidige periode ontvangt.
Het te gebruiken formaat wordt nader omschreven in:
- 6.3 Portfoliobericht (FLXPOR)
- 6.4 Clientswitchbericht (FLXCLS)
Wat de portfolio betreft, is de kwaliteitscode voor het operationele evenwicht altijd gelijk aan « H ».
Alle bovenvermelde berichten worden via FTP (File Transfer Protocol) verstuurd.
3.4 Troubleshooting van portfolio en clientswitch
Deze communicatie laat zich niet in een proces inpassen omdat die uitsluitend plaatsvindt als reden daartoe bestaat, dat wil zeggen in het uiterst ongewone geval dat er zich onoplosbare problemen voordoen, en in voorkomend geval op aanvraag.
Deze mededeling kan alleen plaatsvinden wanneer de informatie waarvan sprake niet in het desbetreffende bericht meegedeeld kan worden:
Afsluiten van alle portfolio’s van een DNB1
Afsluiten van alle RLP-Afnamepunten of lokale producties van een DNB2
1 Volgens het afgesproken protocol zou dit alleen kunnen worden aangegeven door een leeg portfolio bericht, en dat wordt
Afsluiten van een RLP-Afnamepunt of lokale productie
Wijziging van een RLP-Afnamepunt naar een lokale productie of omgekeerd
Deze vier gevallen zijn opgenomen omdat de informatie waarvan sprake niet in het desbetreffende bericht kan worden meegedeeld.
Bij het afsluiten van een RLP-Afnamepunt (lokale productie) ontbreekt het RLP-Afnamepunt (de lokale productie) in de clientswitch (productionswich), maar de DNB’s moeten dit duidelijkheidshalve op voorhand bevestigen per e-mail (al dan niet op verzoek van Fluxys). De DNB-Eindafnemer (producent) wordt dan door Fluxys definitief afgesloten in zijjn systemen.
Deze mededeling mag ook gebruikt worden, zij het dan alleen in noodgevallen, om via bilateraal overleg problemen op te lossen die niet afgehandeld kunnen worden volgens het proces dat nader omschreven is in hoofdstuk 4 ‘Operationeel evenwicht’. Als algemene regel geldt dat fouten die optreden in de berichten van de DNB’s niet door Fluxys worden opgelost, en dat Fluxys geen enkele manuele aanpassing in zijn database doorvoert.
3.4.2 Indicatieve timing voor “troubleshooting” van portfolio en clientswitch
Initialisatie/Verandering naam van een RLP-Afnamepunt of lokale productie
Dit zal worden meegedeeld op het ogenblik dat de DNB over de informatie beschikt.
Initialisatie/Verandering type van een RLP-Afnamepunt
Dit zal worden meegedeeld op het ogenblik dat de DNB over de informatie beschikt.
Afsluiten alle portfolios van een DNB / afsluiten alle RLP-Afnamepunten / afsluiten van alle lokale producties van een DNB
Deze informatie dient aan Fluxys overgemaakt te worden ten laatste 14 werkdagen voor de datum waarop de stop van kracht wordt. Er worden nieuwe clientswitches, productionswitches en portfolio’s verstuurd die de gewijzigde situatie weergeven vanaf de dag dat de nieuwe situatie zich voordoet.
Afsluiten van een RLP-Afnamepunt of lokale productie
Deze informatie wordt zo snel mogelijk, en ten laatste 3 werkdagen voor de datum waarop het RLP- Afnamepunt of lokale productie afgesloten wordt, aan Fluxys meegedeeld. Vindt geen mededeling plaats, dan vraagt Fluxys bevestiging aan de DNB om dit RLP-Afnamepunt of lokale productie definitief te kunnen afsluiten bij Fluxys op de huidige dag.
Probleemoplossing
Deze mededeling mag ook gebruikt worden, zij het dan alleen in noodgevallen, om problemen op te lossen die niet afgehandeld kunnen worden volgens het proces dat nader omschreven is in hoofdstuk 4 ‘Operationeel evenwicht’. Als algemene regel geldt dat fouten die optreden in de berichten van de DNB’s niet door Fluxys worden opgelost, en dat Fluxys geen enkele manuele aanpassing in zijn database doorvoert.
Het te gebruiken formaat wordt nader omschreven in:
- 6.3 Portfoliobericht (FLXPOR)
- 6.4 Clientswitchbericht (FLXCLS)
- 6.5 Productionswitchbericht (FLXPRS)
Wat de portfolio betreft, is de kwaliteitscode voor het operationele evenwicht altijd gelijk aan « H ». Hiervoor is geen enkel formaat bepaald. Het bericht zal duidelijk bevatten
In geval van afsluiting van alle portfolio’s van een DNB: de DNB stuurt een email naar Fluxys met de naam van de DNB en de portfolio’s waarop dit van toepassing is, alsook de datum waarop ze worden afgesloten;
2 Volgens het afgesproken protocol zou dit alleen kunnen worden aangegeven door een leeg clientswitch bericht, en dat wordt
In geval van afsluiting van alle RLP-Afnamepunten van een DNB: de DNB stuurt een email naar Fluxys met de naam van de DNB en de RLP-Afnamepunten waarop dit van toepassing is, alsook de datum waarop ze worden afgesloten.
In geval van afsluiting van alle lokale producties van een DNB: de DNB stuurt een email naar Fluxys met de naam van de DNB en de lokale producties waarop dit van toepassing is, alsook de datum waarop ze worden afgesloten.
Alle bovenvermelde berichten worden via FTP (File Transfer Protocol) verstuurd.
3.5 Starten en afsluiten van een combinatie GOS-DNB
Deze communicatie laat zich niet in een proces inpassen omdat dit uitzonderlijk gebeurd en niet geautomatiseerd is met een bericht.
Deze mededeling vindt alleen plaats voor zover reden daartoe bestaat. Enkel de betrokken DNB x kan een GOS-DNBx starten of afsluiten.
Het starten of het afsluiten van een bestaande GOS-DNB combinatie, dient meegedeeld te worden ten laatste 7 werkdagen voor het ingaan van de start of het afsluiten.
Hiervoor is geen enkel formaat bepaald. Het bericht zal naast de aanduiding of het om een start- of stopbericht gaat, duidelijk bevatten om welke DNB en GOS het gaat, en voor welke periode.
Deze communicatie zal gebeuren per mail. De “sent” datum van de mail zal in rekening worden gebracht i.v.m. de timing.
3.6 Klimaatcorrectiefactor
Fluxys stelt de waarden van de klimaatcorrectiefactor, doorgaans afgekort tot "KCF", beschikbaar voor de DNB.
Er moet een geldige KCF beschikbaar worden gesteld, wil men het proces Maandelijkse allocatie starten dat nader is omschreven in hoofdstuk 5.
- De tijdelijke (niet-gevalideerde) KCF-waarden worden dagelijks verstuurd door Fluxys: het bericht bevat één KCF-waarde per uur voor de voorafgaande gasdag.
- De definitieve (gevalideerde) KCF-waarden worden door Fluxys verstuurd op datum M+5 werkdagen en bevatten alle gegevens voor alle gasdagen van de maand M.
Het te gebruiken formaat wordt nader omschreven in:
Alle bovenvermelde berichten worden via FTP (File Transfer Protocol) verstuurd.
3.7 Infeed en calorische bovenwaarde
Fluxys stelt de volgende gegevens beschikbaar aan de DNB:
- de calorische bovenwaarde (CBW), dat wil zeggen de waarden van de CBW in kWh/m³ voor elke opgestelde meetlijn die tot het GOS behoort.
- de infeed, dat wil zeggen de meetgegevens voor elke opgestelde meetlijn die tot het geaggregeerde ontvangststation behoort, uitgedrukt in m³ en in kWh.
Uiterlijk vijf werkdagen na de 20e dag van de gasmaand in kwestie stelt Fluxys de niet-gevalideerde infeedgegevens en CBW beschikbaar aan de DNB voor de periode van de 21e dag van de voorafgaande gasmaand tot de 20e dag van de gasmaand waarvan sprake.
Uiterlijk vóór de 10e werkdag van de volgende gasmaand stelt Fluxys de gevalideerde infeedgegevens en CBW van de voorafgaande gasmaand beschikbaar aan de DNB.
Het te gebruiken formaat wordt nader omschreven in:
- 6.13 Bericht Infeed-GCV (INFEEDGCV)
Alle bovenvermelde berichten worden via FTP (File Transfer Protocol) verstuurd.
3.8 Maandelijkse telemetingen
De periode voor een gevalideerd meetbericht is één gasmaand; de structuur van de hoofdtekst (body) is op dagbasis opgemaakt (begindatum – einddatum) en wordt bijgevolg herhaald per dag en per RLP- Afnamepunt.
Het formaat van de gevalideerde metingen voor alle RLP-Afnamepunten en lokale producties is volledig conform het formaat van de ongevalideerde metingen voor alle RLP-Afnamepunten en lokale producties (FLXDMT), maar met een “V” als kwaliteitscode in de betrokken kolommen.
Het te gebruiken formaat wordt nader omschreven in:
- 6.7 Daily Metering-bericht (FLXDMT)
3.9 Combinatie GOS/Bevrachter
De door Fluxys terbeschikkingstelling aan de DNB van de combinatie GOS/Bevrachter die de transportcontracten omvat zoals gecontracteerd door de bevrachters met Fluxys, meestal aangeduid als "ARS / Shipper Combinations."
De door Fluxys terbeschikkingstelling van de combinatie GOS/Bevrachter laat aan de DNB toe om van zijn allocatieberichten de bevrachters te verwijderen die in het toegangsregister van de DNB zijn opgenomen maar die geen transportcapaciteit hebben onderschreven bij Fluxys.
- Het bericht «ARS/Shipper Combinations » wordt door Fluxys verstuurd op de datum M+3 werkdagen en bevat alle maandelijkse gegevens van de maand M.
Het te gebruiken formaat staat beschreven in 6.16.
Alle bovenvermelde berichten worden per email verstuurd worden.
3.10 Opmerking
Meetberichten zijn voor een probleemloze verwerking afhankelijk van de goede verwerking van een clientswitch-, productionswitchbericht voor de betrokken gasmaand. Na de correctie van een verkeerd of onvolledig clientswitch-, productionswitchbericht, zullen alle metingen voor de RLP- Afnamepunten of lokale producties die vermeld waren in het betrokken clientswitch-, productionswitchbericht, onmiddellijk opnieuw worden opgestuurd door de betrokken DNB.
Indien sinds het opsturen van het laatste clientswitch-, productionswitch- of portfoliobericht een GOS-DNB combinatie gestart of afgesloten is, zal communicatie over het starten of afsluiten van de GOS-DNB combinatie moeten plaatsvinden alvorens het volgende clientswitch-, productionswitch- of portfoliobericht wordt opgestuurd (zie 3.6). Indien die communicatie niet plaatsvindt, kan de correcte verwerking van het clientswitch-, productionswitch- of portfoliobericht niet gewaarborgd worden.
Als er zich een situatie zou voordoen die niet gepland is in de MIA, is multilateraal overleg tussen alle betrokken partijen noodzakelijk.
4 Operationeel evenwicht
4.1 Versienummer
Het versienummer voor de informatie in deze paragraaf is 2.1.0.
Functioneel gezien is deze specificatie niet veranderd ten opzichte van versie 1.1.0, ook al is dit hoofdstuk aangevuld. Ook het berichtformaat is ongewijzigd gebleven, behoudens het toevoegen van de velden Name en Type in de clientswitch.
4.2 Doel
Het doel van het hierna beschreven proces is het bewaken van het operationele evenwicht op het Vervoer- en Distributienet. Het proces heeft plaats op uurlijkse basis.
4.3 Procesomschrijving
Gezien het belang van het bewaken van het operationeel evenwicht op het Vervoer- en Distributienet, stelt de DNB aan Fluxys de hiernavermelde gegevens ter beschikking :
uiterlijk drie werkdagen vóór het begin van de maand (M – 3 werkdagen)
o een lijst met de RLP-Afnamepunten (“Client Switch”) met vermelding van de betrokken bevrachter, het betrokken GOS en de geldigheidsperiode;
o een lijst met de lokale producties (“Production Switch”) met vermelding van de betrokken bevrachter, het betrokken GOS en de geldigheidsperiode;
o per SLP-profiel het geaggregeerde geschatte jaarverbruik en het geannualiseerde maandverbruik, met vermelding van de betrokken bevrachter en het betrokken GOS.
Deze mededelingen worden nader omschreven in hoofdstuk 3 Voorafgaande mededelingen
zodra mogelijk en uiterlijk binnen het volgende gasuur, de niet-gevalideerde uurlijkse meetgegevens in energie per RLP-Afnamepunt en lokale productie met vermelding van de betrokken bevrachter en het betrokken GOS;
uiterlijk op de volgende werkdag, de niet-gevalideerde uurlijkse meetgegevens van de voorafgaande gasdag in energie per RLP-Afnamepunt en lokale productie wanneer het verwachte jaarvolume kleiner is dan 1 miljoen m³(n).
Als bepaalde gegevens onvolledig zijn of ontbreken, past Fluxys het tussen de partijen overeengekomen vervangingsalgoritme toe.
Heeft Fluxys een vervoerscontract met een bevrachter op een GOS waarvoor geen enkele informatie (clientswitch, productionswitch of portfolio) is verstuurd, dan gebruikt Fluxys 0 als waarde voor het operationele evenwicht van deze bevrachter.
Zoals blijkt uit Figuur 7, worden voor het uurlijkse allocatieproces uitsluitend berichten verstuurd van de DNB’s naar Fluxys.
Het eindresultaat van deze allocatie wordt naar de bevrachters verstuurd. Deze mededeling valt evenwel buiten het bestek van dit document.
Belangrijke opmerking:
Iedere keer dat een bericht wordt ontvangen, kan Fluxys in voorkomend geval een foutbericht terugsturen. Duidelijkheidshalve is dit foutbericht niet in het bovenstaande schema opgenomen. Het kan zijn dat het proces wordt voortgezet, ook al houden de fouten verband met een gedeelte van de berichtregels; hebben de fouten betrekking op de volledige berichtinhoud, dan wordt het proces stopgezet totdat de DNB een juist bericht verstuurt.
Zoals blijkt uit Figuur 7 zal het clientswitch-, productionswitch- en portfoliobericht worden overgemaakt aan Fluxys. De volledige inhoud van het clientswitchbericht en productionswitch en een gedeelte van de inhoud van het portfoliobericht worden als “master data” (stamgegevens) beschouwd. Deze berichten vermelden immers voor elk RLP-Afnamepunt, lokale productie of elk SLP-profiel door welke DNB op welk GOS deze wordt beheerd en aan welke bevrachter deze verbonden is. Het portfoliobericht bevat terzelfdertijd de numerieke waarden in kWh voor elk van deze gegevens. Het clientswitchbericht en productionswitch bevat geen numerieke verbruikswaarden; deze worden verstuurd door middel van de meetberichten. RLP-metingen kunnen dagelijks of uurlijks worden gestuurd, metingen op lokale producties moeten uurlijks gestuurd worden.
4.4 Timing
4.4.1 Meting voor uurlijks telegelezen RLP-Afnamepunten en lokale producties (niet- gevalideerd)
De metingen voor de uurlijks telegelezen RLP-Afnamepunten en lokale producties kunnen meegerekend worden in de uurlijkse allocatie tot H+25’. Na dit tijdstip is de berekening van de allocatie voor het operationeel evenwicht gestart, en worden de metingen niet meer in rekening gebracht voor het operationele evenwicht.
In elk geval dienen de metingen voor de uurlijks gelezen RLP-Afnamepunt en lokale producties Fluxys bereikt te hebben één uur na het uur waarop ze betrekking hebben.
sd Operationeel evenwicht - één DNB
DNB
Fluxys
< M - 3 wd ( uiterlijk drie werkdagen vóór het einde van de maand )
Clientswitch (RLP)
Productionswitch (LPR)
Portfolio (SLP)
Elke dag van de maand
Elk uur van de dag
Metering van de uurlijks uitgelezen RLP-afnamepunten en lokale producties
Metering van de alle RLP-afnamepunten en uurlijks uitgelezen lokale producties
4.4.2 Meting voor alle telegelezen RLP-Afnamepunten en lokale producties (niet-gevalideerd)
Om de vervangwaarden voor de uurlijks en dagelijks gelezen RLP-Afnamepunten en uurlijks gelezen lokale producties up-to-date te houden, zullen de metingen voor alle telegelezen RLP-Afnamepunten en lokale producties verstuurd worden na één werkdag en ten laatste binnen de week volgend op de dag waarop de metingen betrekking hebben.
De metingen voor de uurlijks telegelezen RLP-Afnamepunten en lokale producties komen dus nogmaals toe, terwijl de metingen voor de dagelijks telegelezen RLP-Afnamepunten voor het eerst toekomen.
4.5 Opvolging van berichten
In het algemeen wordt afgesproken dat validatiecodes bepalend zijn voor het aanvaarden of verwerpen van een bericht. Een geschatte waarde zal worden verworpen, en het vervangwaardenalgoritme van Fluxys zal in werking treden. Bevat een binnenkomend bericht een meting die een lagere validatiecode heeft dan de code van het vorige bericht (zie 6.6 en 6.7 wat de validatiecodes betreft), dan wordt voor het laatste bericht een waarschuwingsbericht verstuurd.
Gevalideerde metingen kunnen andere gevalideerde metingen overschrijven.
4.6 Vervangwaarden
Ontbreken er meetgegevens afkomstig van de DNB, dan moet Fluxys hiervoor vervangwaarden gebruiken in afwachting dat een bericht binnenkomt met de juiste waarden voor de ontbrekende gegevens.
Een geschatte meting wordt door Fluxys altijd verworpen, wat als gevolg heeft dat een vervangwaarde wordt berekend door Fluxys.
4.6.1 Vervangwaarden – basisalgoritme
Ontbreekt een waarde voor een bepaald uur tijdens een bepaalde gasdag, dan neemt Fluxys als vervangwaarde het rekenkundig gemiddelde van de waarden voor vier voorafgaande gelijke gasuren. Zijn er voor het verleden slechts 3, 2 of 1 waarde(n) beschikbaar, dan neemt Fluxys het gemiddelde van die respectieve waarden.
Is geen enkele waarde beschikbaar voor de voorafgaande vier weken, dan wordt 0 als vervangwaarde gebruikt, ook al bestaan er waarden voor de periode die verder teruggaat dan vier weken. Zijn de waarden waarop het vervangalgoritme wordt toegepast zelf vervangwaarden, dan worden deze als geldige waarden beschouwd.
Met een “gelijk gasuur” wordt hetzelfde uur nummer op een gelijke dag in de week bedoeld. Bijvoorbeeld, als een waarde ontbreekt voor dinsdag 7 oktober 2003 om 7 uur, zullen de waarden voor dinsdag 30 september 2003, dinsdag 23 september 2003, dinsdag 16 september 2003 en dinsdag 9 september 2003 telkens om 7 uur worden genomen, en zal hiervan het gemiddelde worden berekend.
Het uur wordt altijd in lokale tijd uitgedrukt. Bijvoorbeeld, als een waarde ontbreekt voor woensdag 5 november 2003 om 8 uur lokale tijd (08:00 GMT+1), zullen de waarden van woensdag 29 oktober 2003 om 8 uur lokale tijd (08:00 GMT+1), woensdag 22 oktober 2003 om 8 uur lokale tijd (07:00 GMT+1),
woensdag 15 oktober 2003 om 8 uur lokale tijd (07:00 GMT+1) en woensdag 8 oktober 2003 om 8 uur lokale tijd (07:00 GMT+1) gebruikt worden voor de berekening. Er wordt geen rekening gehouden met feestdagen, vakantiedagen, seizoenen…
De vervangwaarde wordt overschreven zodra een geldig bericht met een geldige waarde binnenkomt in het systeem.
4.6.1.1 Vervangwaarden – overgang van zomertijd naar wintertijd
a) Vervangwaarde voor het 25e uur van de overgangsdag
Voor het 25e uur van de gasdag 25 oktober 2003 – waarop de overgang van zomertijd naar wintertijd plaatsvindt, gebruikt men dezelfde vervangwaarde als berekend voor het 24e uur van die gasdag.
b) Op een overgangsdag gebaseerde vervangwaarde
De op gewone (niet-overgangs)dagen gebaseerde vervangwaarden berusten op de lokale tijd, ook al vindt de overgang van zomertijd naar wintertijd plaats binnen de periode van vier weken. Is een vervangwaarde echter gebaseerd op, onder andere, een lange dag (overgang van zomertijd naar wintertijd), dan is de lokale tijd die overeenkomt met het ie gasuur voor de lange gasdag één uur kleiner dan voor de andere dagen, en wel voor i = {22,23,24}.
Gasuur | Lokale tijd |
25/10/2003 | |
1 | 06:00 |
25/10/2003 | |
2 | 07:00 |
25/10/2003 | |
3 | 08:00 |
25/10/2003 | |
4 | 09:00 |
25/10/2003 | |
5 | 10:00 |
25/10/2003 | |
6 | 11:00 |
25/10/2003 | |
7 | 12:00 |
25/10/2003 | |
8 | 13:00 |
25/10/2003 | |
9 | 14:00 |
25/10/2003 | |
10 | 15:00 |
25/10/2003 | |
11 | 16:00 |
25/10/2003 | |
12 | 17:00 |
25/10/2003 | |
13 | 18:00 |
25/10/2003 | |
14 | 19:00 |
25/10/2003 | |
15 | 20:00 |
25/10/2003 | |
16 | 21:00 |
25/10/2003 | |
17 | 22:00 |
25/10/2003 | |
18 | 23:00 |
26/10/2003 | |
19 | 00:00 |
26/10/2003 | |
20 | 01:00 |
26/10/2003 | |
21 | 02:00 |
26/10/2003 | |
22 | 02:00 |
26/10/2003 | |
23 | 03:00 |
26/10/2003 | |
24 | 04:00 |
26/10/2003 | |
25 | 05:00 |
Schematisch uitgedrukt:
Gasuur | Lokale tijd | Gasuur Lokale tijd | |
18/10/2003 | 01/11/2003 | ||
1 | 06:00 | 1 06:00 | |
18/10/2003 | 01/11/2003 | ||
2 | 07:00 | 2 07:00 | |
18/10/2003 | 01/11/2003 | ||
3 | 08:00 | 3 08:00 | |
18/10/2003 | 01/11/2003 | ||
4 | 09:00 | 4 09:00 | |
18/10/2003 | 01/11/2003 | ||
5 | 10:00 | 5 10:00 | |
18/10/2003 | 01/11/2003 | ||
6 | 11:00 | 6 11:00 | |
18/10/2003 | 01/11/2003 | ||
7 | 12:00 | 7 12:00 | |
18/10/2003 | 01/11/2003 | ||
8 | 13:00 | 8 13:00 | |
18/10/2003 | 01/11/2003 | ||
9 | 14:00 | 9 14:00 | |
18/10/2003 | 01/11/2003 | ||
10 | 15:00 | 10 15:00 | |
18/10/2003 | 01/11/2003 | ||
11 | 16:00 | 11 16:00 | |
18/10/2003 | 01/11/2003 | ||
12 | 17:00 | 12 17:00 | |
18/10/2003 | 01/11/2003 | ||
13 | 18:00 | 13 18:00 | |
18/10/2003 | 01/11/2003 | ||
14 | 19:00 | 14 19:00 | |
18/10/2003 | 01/11/2003 | ||
15 | 20:00 | 15 20:00 | |
18/10/2003 | 01/11/2003 | ||
16 | 21:00 | 16 21:00 | |
18/10/2003 | 01/11/2003 | ||
17 | 22:00 | 17 22:00 | |
18/10/2003 | 01/11/2003 | ||
18 | 23:00 | 18 23:00 | |
19/10/2003 | 02/11/2003 | ||
19 | 00:00 | 19 00:00 | |
19/10/2003 | 02/11/2003 | ||
20 | 01:00 | 20 01:00 | |
19/10/2003 | 02/11/2003 | ||
21 | 02:00 | 21 02:00 | |
19/10/2003 | 02/11/2003 | ||
22 | 03:00 | 22 03:00 | |
19/10/2003 | 02/11/2003 | ||
23 | 04:00 | 23 04:00 | |
19/10/2003 | 02/11/2003 | ||
24 | 05:00 | 24 05:00 |
4.6.1.2 Vervangwaarden – overgang van wintertijd naar zomertijd
a) Op een overgangsdag gebaseerde vervangwaarde
Om een vervangwaarde te berekenen die onder andere gebaseerd is op de dag waarin de overgang van wintertijd naar zomertijd plaatsvindt (voor 2004 is dit 27 maart), dan zijn voor het 24e gasuur slechts drie waarden beschikbaar, omdat er voor deze gasdag geen 24e uur is.
Net als bij de overgang van zomertijd naar wintertijd, moet men bij de overgang van wintertijd naar zomertijd ermee rekening houden dat, om een vervangwaarde te berekenen die onder andere op deze gasdag gebaseerd is, de lokale tijd die overeenkomt met het ie gasuur voor deze gasdag één uur groter is dan voor de andere dagen, en wel voor i = {21,22,23}.
Schematisch uitgedrukt:
Gasuur | Lokale tijd | Gasuur | Lokale tijd | Gasuur | Lokale tijd |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
1 | 06:00 | 1 | 06:00 | 1 | 06:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
2 | 07:00 | 2 | 07:00 | 2 | 07:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
3 | 08:00 | 3 | 08:00 | 3 | 08:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
4 | 09:00 | 4 | 09:00 | 4 | 09:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
5 | 10:00 | 5 | 10:00 | 5 | 10:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
6 | 11:00 | 6 | 11:00 | 6 | 11:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
7 | 12:00 | 7 | 12:00 | 7 | 12:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
8 | 13:00 | 8 | 13:00 | 8 | 13:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
9 | 14:00 | 9 | 14:00 | 9 | 14:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
10 | 15:00 | 10 | 15:00 | 10 | 15:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
11 | 16:00 | 11 | 16:00 | 11 | 16:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
12 | 17:00 | 12 | 17:00 | 12 | 17:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
13 | 18:00 | 13 | 18:00 | 13 | 18:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
14 | 19:00 | 14 | 19:00 | 14 | 19:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
15 | 20:00 | 15 | 20:00 | 15 | 20:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
16 | 21:00 | 16 | 21:00 | 16 | 21:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
17 | 22:00 | 17 | 22:00 | 17 | 22:00 |
20/03/2004 | 27/03/2004 | 03/04/2004 | |||
18 | 23:00 | 18 | 23:00 | 18 | 23:00 |
21/03/2004 | 28/03/2004 | 04/04/2004 | |||
19 | 00:00 | 19 | 00:00 | 19 | 00:00 |
21/03/2004 | 28/03/2004 | 04/04/2004 | |||
20 | 01:00 | 20 | 01:00 | 20 | 01:00 |
21/03/2004 | 28/03/2004 | 04/04/2004 | |||
21 | 02:00 | 21 | 03:00 | 21 | 02:00 |
22 | 21/03/2004 | 22 | 28/03/2004 | 22 | 04/04/2004 |
03:00 | 04:00 | 03:00 | |||
23 | 21/03/2004 04:00 | 23 | 28/03/2004 05:00 | 23 | 04/04/2004 04:00 |
24 | 21/03/2004 05:00 | 24 | 04/04/2004 05:00 |
Wordt een vervangwaarde berekend voor het 23e uur van deze gasdag 3 april 2004 (4 uur lokale tijd), dan gebruikt men de waarden voor het 23e uur van 27 maart (5 uur lokale tijd), het 23e uur van 20 maart (4 uur lokale tijd), het 23e uur van 13 maart (4 uur lokale tijd) en het 23e uur van 6 maart (4 uur lokale tijd).
4.7 Berichtspecificatie
De niet-gevalideerde metingen voor de uurlijks telegelezen RLP-Afnamepunten worden verstuurd:
- hetzij uurlijks, in het formaat dat nader omschreven is in 6.6 Hourly Metering-bericht (FLXHMT)
- hetzij dagelijks, in het formaat dat nader omschreven is in 6.7 Daily Metering-bericht (FLXDMT): in dit laatste geval bevat elk bericht alle uren van een gasdag.
De niet-gevalideerde metingen voor de uurlijks telegelezen lokale producties worden verstuurd: uurlijks, in het formaat dat nader omschreven is in 6.6 Hourly Metering-bericht (FLXHMT)
In normale gevallen is de kwaliteitscode voor het operationele evenwicht gelijk aan H.
Wordt ‘?’ als validatiecode gebruikt, dan worden de betrokken waarden niet gebruikt, maar berekent Fluxys een vervangwaarde.
4.8 Communicatiemedium
Alle bovenvermelde berichten worden via FTP (File Transfer Protocol) verstuurd.
5 Maandelijkse allocatie
5.1 Versienummer
Het versienummer voor de informatie in dit hoofdstuk is 2.1.0.
Deze specificatie is ingrijpend gewijzigd ten opzichte van versie 1.1.0. Het betreft hoofdzakelijk wijzigingen in het proces dat voortaan plaatsvindt “per GOS”. Verder is de allocatie 2a achterwege gelaten.
5.2 Doel
Het maandelijkse allocatieproces beoogt de infeed (in energie gevalideerd op uurbasis) van elk GOS te verdelen onder de verschillende DNB’s en onder de bevrachters en de leveranciers.
De per uur en per GOS uitgelezen infeed wordt verdeeld op basis van de reële lastprofielen of RLP’s (dat wil zeggen volgens het gevalideerde reële verbruik per uur en per toegangspunt), de lokale productie (dat wil zeggen volgens de gevalideerde reële productie per uur en lokale productie) en de synthetische lastprofielen of SLP’s (dat wil zeggen volgens het geschatte verbruik voor de toegangspunten die niet over een systeem voor telelezing beschikken).
Het gasallocatieproces berust op drie belangrijke stappen:
- het berekenen van de bottom-up allocatie (door de DNB);
- het berekenen van de residufactor (door Fluxys);
- het berekenen van de definitieve allocatiewaarden (door de DNB), dat wil zeggen de som van het geschatte verbruik van de SLP’s vermenigvuldigd met de GRF en het reële verbruik min de lokale productie.
Dit proces wordt ook allocatie 2b of “accounting allocation” genoemd.
5.3 Procesomschrijving
Het maandelijkse allocatieproces heeft tot doel de infeed van een bepaalde gasmaand te verdelen onder de verschillende DNB’s en onder de verschillende bevrachters en leveranciers. Deze verdeling vindt plaats op basis van de volgende informatie per GOS, per DNB en per bevrachter:
de gevalideerde metingen van de RLP-Afnamepunten in energie op uurbasis, geaggregeerd per DNB en per bevrachter;
de gevalideerde metingen van de lokale producties in energie op uurbasis, geaggregeerd per DNB en per bevrachter;
het geschatte verbruik van de SLP-Afnamepunten, gevalideerd in energie op uurbasis, en geaggregeerd per DNB, per bevrachter en per SLP;
de infeed van het GOS, gevalideerd in energie op uurbasis.
De RLP-, LPR- en SLP-gegevens worden door de DNB beschikbaar gesteld aan Fluxys.
Om de DNB in staat te stellen het geschatte verbruik te berekenen volgens de synthetische lastprofielen (SLP), stelt Fluxys klimaatcorrectiefactoren (KCF) per uur beschikbaar aan de DNB.
Om de DNB in staat te stellen de definitieve allocatiewaarden te berekenen volgens de synthetische lastprofielen (SLP), stelt Fluxys de GOS-residufactor, ook GRF genoemd, beschikbaar aan de DNB.
De berekening wordt uitgevoerd door de som van de maandelijkse allocaties voor afname (RLP en SLP) die de DNB’s op een specifiek GOS hebben vastgesteld te vergelijken met de som van infeed_FLX en de allocaties voor lokale productie (LPR) op dit GOS.
Hierbij wordt ook rekening gehouden met de eventueel nog door Fluxys telegelezen RLP- Afnamepunten op het distributienet, waarvan de waarden niet zijn opgenomen in de allocatiegegevens van de DNB’s.
De na beëindiging van dit proces verkregen allocatie wordt door de DNB’s meegedeeld aan de andere marktdeelnemers (bevrachters en leveranciers).
5.3.2 Gedetailleerde statusdiagrammen
Hieronder wordt het proces grafisch voorgesteld in de vorm van statusdiagrammen. Er is een verschillend diagram voor de DNB en voor Fluxys. Dit diagram geldt voor één procesexemplaar (“process instance”) en beschrijft met andere woorden het proces voor een bepaalde maand en voor een bepaald GOS.
Deze diagrammen zijn de volledigste en best samengevatte uitdrukkingsvorm van het proces en de daarmee samenhangende regels.
Deze diagrammen volgen de UML-standaard. De pijlen verwijzen naar de “statusovergangen”. Een statusovergang wordt gespecificeerd volgens de conventie:
Trigger [Voorafgaande voorwaarde] / Gevolg
Als het proces zich in een bepaalde status bevindt, brengt elke gebeurtenis die niet is gespecificeerd als trigger van een overgang vanuit deze status geen enkele statuswijziging teweeg. Fluxys stuurt een foutbericht terug ingeval de DGO (distributienetbeheerder of DNB) een bericht verstuurt dat niet in een overgang van de huidige status is gespecificeerd.
5.3.2.1 Gezien vanuit het oogpunt van de DNB
In het eerste diagram (Figuur 8) wordt het proces volledig omschreven rekening houdend met alle berichten.
Het tweede diagram (Figuur 9) is een vereenvoudigde versie waarin geen rekening is gehouden met bepaalde broadcastberichten: dit diagram geldt voor een DNB die uitsluitend op één GOS actief is.
Belangrijke opmerking voor het statusdiagram van de DNB:
Als een statusovergang wordt getriggerd door een bericht naar Fluxys te versturen en de DNB ontvangt een foutbericht van Fluxys, dan wordt de statusovergang ongedaan gemaakt en wordt de vorige processtatus hersteld (duidelijkheidshalve wordt dit niet vermeld in het diagram).
5.3.2.2 Gezien vanuit het oogpunt van Fluxys
Het diagram van Figuur 10 stelt het proces voor wat Fluxys betreft en wordt uitsluitend ter informatie opgegeven.
sm Accounting Allocation - State Diagram - DGO | |
The allocation process from the point of view of the DGO This is the state diagram of the allocation process for one given GOS and one given MONTH Future from the point of view of the DNB KCF Received / Allocation accepted on GRF Version Nr=0 (using GRF(0)=1) Open Allowed to send (additional v ersions of) allocation to Fluxys «Invariant» GRF Received / {The GRF Version number on Allocation to be sent on which allocations are accepted is GRF Received - GRFVersionNr=GRFVersionNr+1 Broadcast receiv ed - set when entering the state "GRF received" and remains Allocation to be Waiting for GRF unchanged after leaving the calculated and sent state ; it is 0 the first time the process enters the state and it is Allocation sent incremented by +1 each time to Fluxys Broadcast received the process reenters the state "New GRF Requested" from any other state.} Additional version of Additional version of allocation sent to Fluxys allocation sent Allocation Sent - RecalculateGRF Waiting for ICF-DAI Sent - Waiting for ICF-DAI or broadcast Broadcast received "All Alloc Received" ICF-DAI Additional version of All Allocations received allocation sent received at Fluxys ICF-DAI received Additional version of "RecalculateGRF" allocation sent ICF-DAI Received - sent Feeback to be sent ICF-DAI received again "AcceptAlloc" sent ICF-DAI "Recalculate GRF" sent received "AcceptAlloc" Sent - AcceptAlloc sent Broadcast Waiting for ICF-DAI received "New Additional version of allocation sent or Broadcast GRF Requested" Broadcast received "All AcceptAlloc Received" Broadcast received "New Broadcast receiv ed "All GRF Requested" AcceptAlloc Receiv ed" Broadcast received "Accepted" Broadcast received "New GRF Requested" Accepted "CancelAcceptAlloc" sent to Fluxys [Error found in allocation] Broadcast received "New GRF "CloseAlloc" sent to Fluxys "CancelAcceptAlloc" Requested" "CancelAcceptAlloc" sent to Fluxys sent [Error found in allocation] "CancelAcceptAlloc" Broadcast "CloseAlloc" sent to Fluxys CloseAlloc Sent sent to Fluxys received "New GRF Requested" Broadcast received "All CloseAlloc Received" Broadcast received "New GRF Requested" Broadcast receiv ed "All CloseAlloc Receiv ed" Broadcast received "Closed" Broadcast received "New GRF Requested" Closed "ReopenAlloc" Broadcast received "New GRF Requested" Error found requested by email in allocation | |
Figuur 8 - Statusdiagram van de DNB voor de maandelijkse allocatie
sm Accounting Allocation - State Diagram - DGO - simplified v ersion without optional broadcast | |
The allocation process from the point of view of the DGO This is the state diagram of the allocation process for one given GOS and one given MONTH Future from the point of view of the DNB KCF Received / Allocation accepted on GRF Version Nr=0 (using GRF(0)=1) Open Allowed to send (additional v ersions of) allocation to Fluxys «Invariant» {The GRF Version number on GRF Received / which allocations are accepted is GRF Received - Allocation to be sent on GRFVersionNr=GRFVersionNr+1 set when entering the state "GRF received" and remains Allocation to be unchanged after leaving the calculated and sent state ; it is 0 the first time the GRF Received / process enters the state and it is Allocation sent Allocation to be sent on GRFVersionNr=GRFVersionNr+1 incremented by +1 each time to Fluxys the process reenters the state from any other state.} Additional version of allocation sent to Fluxys Additional version of allocation sent Allocation Sent - RecalculateGRF Waiting for ICF- Sent - Waiting for DAI ICF-DAI or broadcast ICF-DAI received ICF-DAI received Additional version of allocation sent ICF-DAI Received - Feeback to be sent "RecalculateGRF" sent ICF-DAI "AcceptAlloc" sentreceived again ICF-DAI received "Recalculate GRF" sent "AcceptAlloc" Sent - Additional version of allocation sent Waiting for ICF- AcceptAlloc sent DAI or Broadcast Broadcast received "Accepted" Accepted "CancelAcceptAlloc" sent to Fluxys [Error found in allocation] "CloseAlloc" sent to Fluxys "CancelAcceptAlloc" sent "CancelAcceptAlloc" sent to Fluxys "CloseAlloc" sent to Fluxys CloseAlloc Sen[Et rror found in allocation] "CancelAcceptAlloc" sent to Fluxys Broadcast received "Closed" Closed "ReopenAlloc" requested by email Error found in allocation GRF Received / Allocation to be sent on GRFVersionNr=GRFVersionNr+1 | |
Figuur 9 - Vereenvoudigd statusdiagram van de DNB voor de maandelijkse allocatie
sm Accounting Allocation - State Diagram - Fluxys | |
The allocation process from the «default» This is the state diagram of the allocation process point of view of the Fluxys. Future for one given GOS and one given MONTH from the point of view of Fluxys. KCF sent / Allocation accepted on GRF Version Nr=0 (using GRF(0)=1) Open (Additional v ersions of) allocations from DGO are accepted (must be based on last GRF sent) First or additional version of allocation received [Allocation still missing from at least one DGO] «Invariant» {The GRF Version number on which allocations are accepted is set when entering the state "GRF sent" GRF Sent - GRF sent / and remains unchanged after leaving the state ; it is Waiting For Alloc Allocations accepted on GRFVersionNr=GRFVersionNr+1 0 the first time the process enters the state and it is incremented by +1 each time the process reenters the state from any other state.} First version of allocation received from last DGO [Allocation received from every DGO] / Broadcast sent All Allocations Additional version of Feedback received [An ICF-DAI has already been sent under present GRF Version Nr] Received allocation received Additional version of ICF-DAI sent allocation received Feedback received from last DGO [["RecalculateGRF" received from ICF-DAI Sent - at least one DGO] OR [LoopNr=0]] / New GRF Waiting For Broadcast sent requested "AcceptAlloc" or "RecalculateGRF" received Feedback [Still no feedback received from at least one DGO] "AcceptAlloc" received from last DGO [["AcceptAlloc" received from each DGO] and [LoopNr > 0]] / Broadcast sent All Manual Reject / "AcceptAlloc" Broadcast sent Received Manual Approval [[ICF-DAI good enough] and [LoopNr > 0]] / Broadcast sent Accepted - "CancelAccept" received from one DGO / "ClosetAlloc" received [Still no Waiting for Broadcast sent feedback received from at least one DGO] Feedback from Market Last "CloseAlloc" received ["CloseAlloc" received from each DGO] / Broadcast sent Manual Reject / Broadcast sent All "CloseAlloc" received Manual Approval by Fluxys / Broadcast sent Manual Reopen (on initiative of Fluxys or on request of a DGO) / Closed - Broadcast sent Settlement running | |
Figuur 10 - Statusdiagram van Fluxys voor de maandelijkse allocatie
5.3.3 Gedetailleerde activiteitendiagrammen
De onderstaande diagrammen tonen de afzonderlijke activiteitenstromen voor de DNB en Fluxys. Aangezien een groot aantal DNB’s op één GOS (op de meeste GOS’en) actief kan zijn en talloze lusbewerkingen en lusfuncties (“loops”) mogelijk zijn, is het niet mogelijk het volledige proces in één diagram te detailleren waarin de DNB(‘s) en Fluxys gecombineerd zijn.
Deze diagrammen worden bij wijze van uitleg gegeven en dienen als hulpmiddel om meer inzicht te verschaffen in de statusdiagrammen die uitsluitend de nauwkeurige procesdefinitie geven.
5.3.3.1 Gezien vanuit het oogpunt van de DNB
In het eerste diagram (Figuur 11) wordt het proces volledig omschreven rekening houdend met alle berichten.
Het tweede diagram (Figuur 12) is een vereenvoudigde versie waarin geen rekening is gehouden met bepaalde broadcastberichten: dit diagram geldt voor een DNB die uitsluitend op één GOS actief is.
5.3.3.2 Gezien vanuit het oogpunt van Fluxys
Het diagram van Figuur 13 stelt de activiteiten voor wat Fluxys betreft en wordt uitsluitend ter informatie opgegeven.
ad Accounting Allocation - Activ ity Diagram - DGO | |
In a normal instance of this process there will be 2 computations of ICF-DAI and 1 computation of GRF, and this the minimum. Wait for KCF [KCF Received] /GRF Version Nr = 0 (value=1) Apply last GRF on allocation and send /GRF Version Nr = GRF Version Nr + 1 [Error Found] Wait for next event - 1 [New state Fluxys = "All Alloc Received"] [Error Found] Modify Alloc, re-apply last Wait for next event - 2 GRF and send [ICF-DAI Received] [Not if LoopNr=0] My choice Send "AcceptAlloc" Send "RecalculateGRF" [Error found] [Error [Changed [New State = GRF Wait for found] my mind] Requested] GRF [Changed Wait for next my mind] [ICF-DAI [ICF-DAI Wait for next event - 3 Received] Received] event - 4 [New State Fluxys = [New State Fluxys = "All AcceptAlloc "GRF Requested"] Received"] Wait for broadcast [New State Fluxys = "GRF Requested"] [New State Fluxys = "Accepted"] One could enable the DGO to send a modified [New State Fluxys = "GRF Requested"] allocation just after The process Do any necessary receiving the new state will follow only check... and wait for "New GRF Requested". one of the possible broadcast [New State Instead the DGO will have arrows starting Fluxys = "GRF to wait for the GRF before from this activity. [No error found] [Error Requested"] he can send his new data. found] Send "CancelAccept" Consequence of this may be (not always) that 2 GRF loops will be necessary. Send "CloseAlloc" to But it is preferred to keep Fluxys the process simple. [Changed my mind] [New State Fluxys = "GRF Requested"] Wait for next event - 5 [New State Fluxys = «ByPhoneAndMail» "All CloseAlloc Send "ReopenAlloc" Received"] [New State Fluxys = "GRF Requested"] Wait for next event - 6 [New State Fluxys = Error found in allocation data "Closed"] Close allocation - start settlement «ByPhoneAndMail» "ReopenAlloc" Received from Fluxys | |
[GRF Received]
Figuur 11 – Activiteitendiagram van de DNB voor de maandelijkse allocatie
ad Accounting Allocation - Activ ity Diagram - DGO - Simplified scenario with no ov erwrite of message | |
In a normal instance of this process there will be 2 computations of ICF-DAI and 1 computation of GRF, and this the minimum. Wait for KCF [KCF Received] /GRF Version Nr = 0 (value=1) Apply last GRF on allocation and send /GRF Version Nr = GRF Version Nr + 1 [Error Found] Wait for next event - 2 Modify Alloc, re-apply last GRF and send [ICF-DAI Received] [Not if LoopNr=0] My choice Send "AcceptAlloc" Send "RecalculateGRF" Wait for next [ICF-DAI [ICF-DAI [New State = GRF Wait for event - 3 Received] Received] Requested] GRF Wait for next [New State Fluxys = event - 4 "Accepted"] [New State Fluxys = "GRF Requested"] The process Do any necessary [New State Fluxys = "GRF Requested"] will follow only check... and wait for one of the possible broadcast arrows starting [Error from this [No error found] found] [New State activity. Fluxys = "GRF Requested"] Send "CancelAccept" Send "CloseAlloc" to «ByPhoneAndMail» Fluxys Send "ReopenAlloc" [New State Fluxys = "GRF Requested"] Wait for next event - 6 [New State Fluxys = Error found in allocation data "Closed"] Close allocation - start settlement «ByPhoneAndMail» "ReopenAlloc" Received from Fluxys | |
[GRF Received]
ad Accounting Allocation GOS per GOS - Activ ity Diagram - Fluxys | |
Send Monthly KCF Wait for Send GRF Allocations Send Broadcast "All Alloc Receiv ed" Compute ICF-DAI and send Verify GRF Wait for feedback from DGO's - 1 [All feedback is "AcceptAlloc"] [New Alloc received] [1 "RecalculateGRF" and no new alloc, and all feedback received] LoopNr = 0 ? Send Broadcast "New GRF Compute GRF [Yes] Requested" [No] Send Broadcast "All AcceptAlloc Receiv ed" Manually Confirm or Reject [N] Accepted ? [Y] Send Broacast "Accepted" Wait for feedback from DGO's - 2 [1 "CancelAccept"] [All "CloseAlloc"] Send Broadcast "All CloseAlloc Receiv ed" Manually Confirm or Reject Accepted ? [N] [Y] Error found in Infeed Send Broadcast "Closed" «ByPhoneAndMail» Send "Reopen" «ByPhoneAndMail» "ReopenAlloc" received from a DGO | |
Figuur 13 - Activiteitendiagram van Fluxys voor de maandelijkse allocatie
5.3.4 Eenvoudig procesexemplaar
Figuur 14 toont de berichten die tijdens het maandelijkse allocatieproces worden uitgewisseld voor een GOS waarop één enkele DNB actief is. In de bovenvermelde activiteitendiagrammen staat volledige informatie over de sprongen of vertakkingen die veroorzaakt kunnen worden door de interacties van andere DNB’s op het GOS.
sd Monthly Allocation GOS per GOS - one DGO - Standard | |
IRM-KMI Fluxys DGO Monthly overview of observed temperatures Climat Correction Factor Allocation (based on GRF=1) ICF-DAI If allocation "RecalculateGRF" modified GRF Allocation based on last GRF If RecalculateGRF ICF-DAI If allocation modified "Accept" or "RecalculateGRF" If CancelAccept "ConfirmAccept" "Close" or "CancelAccept" "ConfirmClose" | |
Figuur 14 Sequentiediagram van de maandelijkse allocatie
Iedere keer dat een bericht wordt ontvangen, kan Fluxys een foutbericht terugsturen. Duidelijkheidshalve is dit foutbericht niet in het bovenstaande schema opgenomen.
Alvorens de processtappen meer in detail te beschrijven, geven we hieronder een samenvatting van de berekeningen die tijdens het proces worden uitgevoerd:
- ICF- en DAI-berekening:
Na ontvangst van de door de DNB’s vastgelegde allocaties, berekent Fluxys de ICF en de DAI om de kwaliteit van de laatste allocaties te beoordelen, zoals uitgelegd in 2.3.6 Kwaliteit van de maandelijkse allocatie: ICF en DAI.
Fluxys berekent ook voor elke DNB afzonderlijk de geaggregeerde allocatiegegevens waarmee de DNB kan nagaan of Fluxys de laatst verstuurde gegevens wel degelijk heeft ontvangen en toegepast. Deze geaggregeerde gegevens omvatten het versienummer van de door de DNB verstuurde allocatie en de geaggregeerde sommen per DNB, per bevrachter en per SLP. Dit vervangt de verzending van informatieverzoeken ("query’s") naar de DNB’s zoals bepaald in de MIA 1.1.
Fluxys verstuurt de ICF en de DAI samen met de geaggregeerde allocatiegegevens in een ICF-DAI- bericht.
GRF-berekening
Fluxys telt de allocaties van de verschillende DNB’s samen voor elk GOS, vergelijkt het totaal met de infeed en berekent een nieuwe SLPCF om de infeed te laten dekken. Deze SLPCF wordt vermenigvuldigd met de vorige GRF om een nieuwe GRF te berekenen die naar de DNB’s wordt verstuurd. Aangezien de GRF aanvankelijk gelijk is aan 1 en één enkele GRF wordt berekend, is de GRF dan gelijk aan de SLPCF.
Allocatieberekening
De DNB’s passen de GRF toe op het SLP-gedeelte, voegen hun eigen RLP- en LPR-gegevens daaraan toe en versturen de op die manier berekende nieuwe allocatie naar Fluxys. De som van deze nieuwe allocaties dekt precies de infeed als geen enkele DNB zijn basiscijfers heeft gewijzigd en voor zover Fluxys zijn infeedgegevens niet heeft gewijzigd. Bijgevolg moeten de ICF en de DAI respectievelijk gelijk zijn aan 1 en 0 kWh.
Hieronder wordt het proces vereenvoudigd voorgesteld in het formaat van een gebruiksgeval: | ||
1. Bij het begin van de volgende maand bezorgt het KMI Fluxys de gevalideerde temperatuurgegevens per uur voor de volledige maand. 2. Fluxys berekent op basis hiervan de klimaatcorrectiefactor (KCF) en geeft die door aan de DNB’s zodat zij het geschatte verbruik van de SLP-Afnamepunten kunnen berekenen. Versienummer GRF = 0 Versienummer ICF-DAI = 1 3. De DNB verstuurt zijn bottom-up allocatie naar Fluxys op basis van de factor GRF(0)=1. | ||
4. Zodra Fluxys de allocaties heeft ontvangen van alle DNB’s die op het GOS actief zijn, verstuurt Fluxys onmiddellijk een broadcastbericht naar alle DNB’s. Daarna berekent Fluxys de ICF en de DAI als ook de geaggregeerde allocatiegegevens voor elke DNB afzonderlijk. Vervolgens verstuurt Fluxys al deze gegevens naar de DNB’s in het ICF-DAI-bericht. 5. Na ontvangst van het ICF-DAI-bericht heeft elke DNB twee keuzemogelijkheden: | ||
Versienummer ICF-DAI = oude waarde + 1 (de stappen 4 en 5 worden herhaald totdat 1DNB het laatste ICF-DAI-bericht beantwoordt met een bericht "RecalculateGRF"). | ||
Na het ontvangen van 1 feedback bericht ‘RecalculateGrf’ verstuurt Fluxys onmiddellijk naar alle DNB’s een broadcastbericht. | ||
7. Heeft minstens één DNB gevraagd de GRF opnieuw te berekenen, dan voert Fluxys deze berekening uit en wordt een GRF-bericht naar de DNB’s verstuurd. Versienummer GRF = oude waarde + 1 Versienummer ICF-DAI = Versienummer ICF-DAI uit stap 5 8. De DNB’s passen de GRF toe op het SLP-gedeelte, voegen hun eigen RLP- en LPR-gegevens daaraan toe en versturen de op die manier berekende nieuwe allocatie naar Fluxys. De som van deze nieuwe allocaties dekt precies de infeed als geen enkele DNB zijn basiscijfers heeft gewijzigd en voor zover Fluxys zijn infeedgegevens niet heeft gewijzigd. Bijgevolg moeten de ICF en de DAI respectievelijk gelijk zijn aan 1 en 0 kWh. | ||
Zodra Fluxys de allocaties heeft ontvangen van alle DNB’s die op het GOS actief zijn, verstuurt Fluxys onmiddellijk een broadcastbericht naar alle DNB’s. Daarna berekent Fluxys de ICF en de DAI alsook de geaggregeerde allocatiegegevens voor elke DNB afzonderlijk. Vervolgens verstuurt Fluxys het ICF-DAI-bericht naar de DNB’s. Na ontvangst van het ICF-DAI-bericht heeft elke DNB drie keuzemogelijkheden: Versienummer ICF-DAI = oude waarde + 1 (de stappen 8 en 9 worden herhaald totdat alle DNB’s het laatste ICF-DAI-bericht beantwoord hebben met een bericht "AcceptAlloc"of één DNB met een bericht “RecalculateGRF”). | ||
10. | ||
- vragen een nieuwe GRF te berekenen: versturen van een feedbackbericht "RecalculateGRF" - de laatste allocatieresultaten aanvaarden: versturen van een feedbackbericht "AcceptAlloc". | ||
Hebben alle DNB’s feedback gegeven in de vorm van een bericht "AcceptAlloc" of één DNB een bericht "RecalculateGRF", dan verstuurt Fluxys onmiddellijk naar alle DNB’s een broadcastbericht, waarna Fluxys de feedbackberichten beoordeelt. (de stappen 7 tot 11 worden herhaald totdat alle DNB’s het laatste ICF-DAI-bericht beantwoord hebben met een bericht "AcceptAlloc" en Fluxys de allocatie ook aanvaardt). | ||
en leveranciers door en maakt daarbij een keuze tussen twee mogelijkheden die elk verschillende gevolgen hebben: | |
- Versturen van een feedbackbericht "CancelAccept": terug naar stap 7 - Versturen van een feedbackbericht "CloseAlloc" (de stappen 7 tot 11 worden herhaald totdat alle DNB’s een bericht "CloseAlloc" versturen en Fluxys ook wil afsluiten. Dit dient ten laatste 90 werkdagen na het maandeinde (M+90 werkdagen) gebeurd te zijn.). | |
13. Fluxys verstuurt een broadcastbericht "Closed" naar alle DNB’s.
14. Het settlement-proces kan nu van start gaan….
5.3.8 Versienummers van de gegevens
Iedere keer dat hij allocatiegegevens verstuurt, moet de DNB een versienummer opgeven. Dit nummer bestaat uit twee gehele getallen die kleiner zijn dan 100; beide getallen worden hoofdversienummer en subversienummer genoemd. De versies moeten niet doorlopend worden genummerd. Het kan immers zijn dat de DNB in zijn computersysteem een tussentijdse versie behoudt die niet aan Fluxys wordt doorgegeven.
Elke allocatieverzending moet gemarkeerd worden door een unieke combinatie van twee versienummers.
Voor elke berekening wordt het GRF-nummer verhoogd. De GRF(0) is altijd gelijk aan 1 en wordt nooit formeel doorgegeven aan de DNB’s. Het versienummer van de GRF wordt bij elke lus met 1 verhoogd.
Na elke GRF-berekening wordt het versienummer van de ICF-DAI teruggezet op 1. Dit nummer wordt met 1 verhoogd bij elke ICF-DAI-lus (dat wil zeggen iedere keer dat een DNB een gewijzigde allocatie doorstuurt in plaats van de vorige ICF-DAI te beantwoorden). Om een ICF-DAI te identificeren moet men ook het versienummer van de GRF doorgeven (waarop de top-down allocaties gebaseerd zijn) samen met het versienummer van de ICF-DAI.
In de onderstaande tabel staat een voorbeeld. Op te merken valt dat het hier om een extreem voorbeeld gaat: normaliter verstuurt elke DNB slechts twee allocaties, eindigt het GRF-versienummer met 1, en zijn er slechts twee ICF-DAI’s (versie 0.1 en 1.1). De heropeningsprocedure vindt dus alleen bij uitzondering plaats.
DGO
Transmissions from DGO
Transmissions from Fluxys to DGO
A C F
GRF(0) = 1
Loop 0
v0.0 v0.1 v2.0
v1,1 v1.2 v0.0
v3. Recalc. Recalc. v3.1 Recalc. Recalc. Recalc. Recalc. Recalc.
ICF-DAI (0,1) + version DGO + date&hour ICF-DAI (0,2) + version DGO + date&hour ICF-DAI (0,3) + version DGO + date&hour
GRF(1) GRF(1) + version DGO + date&hour
Loop 1
v4.0 v2.1 v1.0
v4.1 Accept
Recalc. Accept Accept
ICF-DAI (1,1) + version DGO + date&hour ICF-DAI (1,2) + version DGO + date&hour
GRF(2) GRF(2) + version DGO + date&hour
Loop 2
v4.2 v3.1 v2.0
Accept Accept Accept Close Close Close
ICF-DAI (2,1) + version DGO + date&hour ConfirmAccept
ConfirmClose
RE-OPEN
GRF(3) GRF(3) + version DGO + date&hour
Loop 3
v5.0 v4.1 v3.0
Recalc. Accept Accept
ICF-DAI (3,1) + version DGO + date&hour
GRF(4) GRF(4) + version DGO + date&hour
Loop 4
v6.0 v5.1 v4.0
Accept Accept Accept Close Close Close
ICF-DAI (4,1) + version DGO + date&hour ConfirmAccept
ConfirmClose
Figuur 15 Voorbeeld van versienummers
5.4 Sequentie en timing
5.4.1 Termijnen en reactietijden
De datums (uitgedrukt in werkdagen vanaf het begin van de volgende maand) en de reactietijden (uitgedrukt in werkdagen) zijn te verstaan als maxima, niet als vaste datums.
De reactietijd (ook antwoordtijd of responstijd genoemd) wordt geteld in aantal werkdagen van 8.00 tot
8.00 uur lokale tijd, zoals uitgelegd in het onderstaande voorbeeld voor een maximale reactietijd van twee werkdagen:
- als een bericht binnenkomt op maandag om 7.30 uur, zijn de twee werkdagen maandag en dinsdag, en moet de andere partij het antwoord normaal ontvangen vóór woensdag om 8.00 uur.
- komt een bericht binnen op maandag om 8.30 uur, dan zijn de twee werkdagen dinsdag en woensdag, en moet de andere partij het antwoord normaal ontvangen vóór donderdag om 8.00 uur.
Wat Fluxys betreft, gaat de reactietijd in op het ogenblik dat het laatste bericht wordt ontvangen van alle berichten van de verschillende DNB’s die tijdens de desbetreffende maand op het GOS actief zijn. In twee gevallen gaat de reactietijd evenwel in direct na ontvangst van een bericht van een DNB:
- ontvangst van een gewijzigde allocatie na ontvangst van de laatste allocatie en na verzending van de ICF-DAI, maar vóór verzending van alle feedbackberichten;
- ontvangst van een bericht "CancelAccept" als het proces de status "Accepted" heeft.
In de volgende tabel staat, puur indicatief, een mogelijke reactietijd van Fluxys:
Activiteit | Reactietijd in aantal werkdagen |
Berekening van de ICF-DAI | 1 |
Berekening van de GRF | 4 |
Verzending van een bericht "ConfirmAccept" of een bericht "New GRF Requested" na ontvangst van de berichten "AcceptAlloc" van alle DNB’s | 2 |
Verzending van een bericht "ConfirmClose" of een bericht "New GRF Requested" na ontvangst van de berichten "CloseAlloc" van alle DNB’s | 4 |
In de volgende tabel staat, puur indicatief, een mogelijke reactietijd van de DNB’s:
Activiteit | Reactietijd in aantal werkdagen |
Analyseren van de ICF-DAI en verzenden van een feedbackbericht "RecalculateGRF" of "Accept" | 2 (1 dag indien GRFVersion=0) |
Toepassen van de KCF en GRF en verzenden van de allocatie | 3 |
Reageren op een broadcastbericht "Accepted" door een feedbackbericht "CancelAccept" of "Close" te versturen | 2 |
Reageren op een broadcastbericht "" of een bericht "New GRF Requested" na ontvangst van de berichten "CloseAlloc" van alle DNB’s | 4 |
In de figuur Xxxxxx 16 hieronder wordt de opeenvolging van berichten voor een eenvoudig geval voorgesteld, dat wil zeggen met één enkele berekening van de GRF en twee versies van de ICF-DAI.
sd Monthly Allocation - one DGO - Basic scenario with timing | |
IRM-KMI Fluxys DGO Monthly overview of observed temperatures Climat Correction Factor M+5wd Allocation (based on GRF=1) M+14 wd ICF-DAI M+15 wd "RecalculateGRF" M+16 wd GRF M+20 wd Allocation based on last GRF M+23 wd ICF-DAI M+24 wd "Accept" or "RecalculateGRF" M+26 wd "ConfirmAccept" M+28 wd "Close" or "CancelAccept" M+90wd "ConfirmClose" | |
Figuur 16 Indicatieve timing in een eenvoudig geval van het maandelijkse allocatieproces
5.4.2 Gegevens afkomstig van de DNB’s
Alle gegevens die voor het uurlijkse allocatieproces worden ontvangen, worden bij het begin van de volgende maand gevalideerd. Dit houdt in dat Fluxys van de DNB’s de volgende gegevens dient te ontvangen:
gevalideerde portfolio’s en gevalideerde clientswitches en productionswitches;
gevalideerde metingen (uurlijks en dagelijks telegelezen RLP-Afnamepunt en uurlijks uitgelezen lokale producties)
De gevalideerde gegevens worden uiterlijk op M+10 werkdagen naar Fluxys verstuurd.
5.5 Berichtspecificatie
Deze paragraaf verwijst enkel naar de naamgeving van de berichtspecificatie. De volledige berichtspecificatie is terug te vinden in hoofdstuk 6 ‘Berichtspecificatie’.
5.6 Communicatiemedium
Alle bovenvermelde berichten die tussen Fluxys en de DNB’s worden uitgewisseld (in beide richtingen), gebruiken FTP als communicatiemiddel voor zover de berichten met een vaste berichtspecificatie overeenstemmen.
De enige uitzondering hierop is het aanvragen van een heropening van het allocatieproces van een maand : deze berichten worden per e-mail verstuurd (eventueel na een mondelinge communicatie).
6 Berichtspecificatie
6.1 Algemene afspraken
Het versienummer voor de informatie in dit hoofdstuk is 2.1.0.
De berichten moeten in UTF-8 gecodeerd worden, maar alleen tekens met twee bytes worden aanvaard (Unicode range U+0080 tot U+07FF). Deze definitie omvat de eerste 256 codes van de Unicode waarvan de codering overeenstemt met ISO-8859-1. Dat is voldoende voor het Latijnse alfabet, inclusief accenttekens.
Het regelscheidingsteken bestaat uit twee tekens: "Carriage Return" gevolgd door "Line Feed" (CR-LF). Opmerking: bij FTP-overdracht van een Unix-systeem naar een Windows-systeem wordt LF automatisch vervangen door CR-LF als de optie "ASCII" ingeschakeld is (en omgekeerd).
6.1.3 Inhoud van de berichten
Elk bericht mag uitsluitend informatie bevatten over één enkele DNB, die wordt aangeduid in het veld MS van het bericht. Een bericht wordt geacht de informatie te bevatten over één of meer GOS’en waarop de DNB actief is.
Een leeg bericht zal als ongeldig beschouwd worden.
Een portfolio- of clientswitchbericht bevat telkens de gegevens voor één enkele gasmaand. Er zijn wel meerdere berichten voor dezelfde gasmaand mogelijk (bijvoorbeeld gevalideerde en niet-gevalideerde gegevens). Bovendien is het ook mogelijk dat een RLP-Afnamepunt/ lokale productie /portfolio in het midden van een gasmaand inactief wordt, en dat de geldigheidsperiode voor dat RLP-Afnamepunt / lokale productie /portfolio bijgevolg niet gelijk is aan de laatste dag van de gasmaand. Maar elke gasdag in de geldigheidsperiode van het bericht moet deel uitmaken van dezelfde gasmaand als die waarvan de kleinste gasdag in het bericht deel uitmaakt. Als er datums worden aangetroffen die niet in deze gasmaand liggen, zal er een foutbericht worden verstuurd en zal het volledige bericht worden geweigerd. Indien er een periode kleiner dan een gasmaand wordt aangetroffen in het bericht, zal verondersteld worden dat voor het complement van deze gasmaand deze gegevens (portfolio/productionswitch/clientswitch) niet door de betrokken DNB kunnen worden verschaft. Er wordt geen foutbericht verstuurd. Deze situatie zal als gevolg hebben dat de betrokken portfolio’s, lokale producties of RLP-Afnamepunten inactief worden, tenzij het gaat om een clientswitch of productionswitch en een andere DNB gegevens opstuurt voor het complementaire gedeelte van de gasmaand.
Het clientswitchbericht bevat de informatie over een RLP-Afnamepunt, met name het GOS, de DNB en de bevrachter. Een RLP-Afnamepunt kan binnen éénzelfde gasmaand van GOS en/of DNB veranderen, op de grens van een gasdag. De periodiciteit om van bevrachter te veranderen komt doorgaans overeen met een gasmaand. Hetzelfde geldt voor de lokale producties in het productionswitchbericht.
Aangezien een portfolio uniek bepaald wordt precies door de GOS-DNB-VNG-SLP type combinatie, gelden dergelijke beperkingen niet voor een portfoliobericht. Een verandering van één van de samenstellende delen voor een bepaalde portfoliocombinatie, resulteert in het stopzetten van de bestaande portfolio en het creëren van een nieuwe portfolio.
Periodes voor éénzelfde RLP-Afnamepunt, lokale producties of portfolio in éénzelfde bericht, mogen mekaar niet overlappen.
6.1.4 Naamgeving van de files
De filenamen van de berichten met een vastgesteld formaat, zijn voor Fluxys transparant. De berichten zullen wel de extensie .txt hebben.
6.1.5 Scheidingstekens voor numerieke waarden en decimalen
Het decimale teken is gelijk aan de komma. Er is geen scheiding voor duizendtallen.
Als een gegeven met twee decimalen is gedefinieerd, zijn deze decimalen verplichte invoer: zo is "271" bijvoorbeeld niet conform, maar "271,00" wel.
Het aantal decimalen is geüniformiseerd: twee decimalen voor de volumes in m³ en voor de energie in kWh; vier decimalen voor de GCV in kWh/m³; acht decimalen voor de GRF, KCF en ICF; geen enkele decimaal voor de DAI.
Een EAN-GLN-nummer zal altijd uit 13 cijfers bestaan. Een EAN-GSRN-nummer zal altijd uit 18 cijfers bestaan.
De tijdsaanduiding in alle berichten heeft telkens betrekking op de aangegeven “TIME ZONE”. Deze tijdzone is altijd GMT+1. (In lokale tijd uitgedrukt, zou men twee gasuren krijgen die beginnen op twee uur in lokale tijd, bij de overgang van zomertijd naar wintertijd).
In het MIA-formaat worden datum en uur altijd uitgedrukt in de notatie "DDMMYYYY hh :00".
Een gasuur wordt voorgesteld door de datum en het uur die als eerste worden vermeld, en omvat de zestig daarop volgende minuten. Een gasuur dat bijvoorbeeld gaat van twaalf tot dertien uur op 4 december 2008 wordt uitgedrukt als "04122008 12 :00"
Langere tijdsperioden dan één uur worden voorgesteld door het begingasuur en het eindgasuur. Er wordt altijd van uitgegaan dat de begin- en einduren binnen de periode vallen.
De meeste MIA-records of –berichten hebben betrekking op gasdagen. Een gasdag wordt voorgesteld door het begingasuur en het eindgasuur. Een gasdag gaat altijd van 6 uur tot 5 uur, uitgedrukt in lokale tijd.
Omgezet in de Greenwichtijd GMT+1 betekent dit dat een gasdag gaat van: 6 uur tot 5 uur gedurende de wintertijd (lokale tijd = GMT+1)
van 5 uur tot 4 uur gedurende de zomertijd (lokale tijd = GMT+2)
van 5 uur tot 5 uur op de overgangsdag van zomertijd naar wintertijd: dag van 25 uren van 6 uur tot 4 uur op de overgangsdag van wintertijd naar zomertijd: dag van 23 uren
In lokale tijd: er zijn twee onregelmatigheden in de opeenvolging van de uren
Dag gedurende wintertijd
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 | 05 |
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 03 | 04 | 05 |
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 | 05 |
Laatste dag die begint met de wintertijd en eindigt in de zomertijd Dag gedurende zomertijd
Laatste dag die begint met de zomertijd en eindigt in de wintertijd
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 02 | 03 | 04 | 05 |
In GMT+1:
Dag gedurende wintertijd
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 | 05 |
06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 |
05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 |
Laatste dag die begint met de wintertijd en eindigt in de zomertijd Dag gedurende zomertijd
Laatste dag die begint met de zomertijd en eindigt in de wintertijd
05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 00 | 01 | 02 | 03 | 04 | 05 |
Bepaalde MIA-berichten strekken zich uit over een gasmaand. Een gasmaand omvat alle gasdagen die in de kalendermaand beginnen. Met andere woorden, voorgesteld in het MIA-formaat heeft de gasmaand januari 2006 betrekking op de periode:
van 01012006 06:00
tot 01022006 05:00.
Zie ook 3.3.3 Vervangwaarden voor portfolio, clientswitch en productionswitch berichten en 4.6.1.1 Vervangwaarden – overgang van zomertijd naar wintertijd voor een voorbeeld.
Alle velden zullen ingevuld zijn, tenzij dit anders wordt aangegeven.
Daar waar in de velden “vrije tekst” is toegelaten (dit betekent dat er geen beperkingen worden opgelegd aan de tekst), worden enkel alfanumerieke karakters verwacht, die behoren tot de set zoals weergegeven in Xxxxx XXX.
Wanneer in een veld een puntkomma (;) zou voorkomen, die niet als veldscheiding is bedoeld, zal de inhoud van het hele veld tussen accolades ({}) staan.
De velden met de waarde voor de irrelevante uren worden blanco (oningevuld) gelaten. Het gaat hier om:
- de velden met de waarde van het 25e uur voor dagen met 23 of 24 uren;
- de velden met de waarde van het 24e uur voor dagen met 23 uren.
6.2 Headers en footers van berichten
De gegevens staan in een tekstbestand (.txt-formaat) met een koptekst (header), een hoofdtekst (body) en een voettekst (footer).
Elk onderdeel van het bericht wordt gekenmerkt door een tag die tussen vierkante haken ([]) staat. De tag en de eigenlijke informatie worden gescheiden door een puntkomma. De puntkomma vervult verder de delimiter-rol, en scheidt verschillende waarden en verschillende lijnen.
Een bericht bestaat uit drie delen:
- de koptekst (header);
- de hoofdtekst (body);
- de voettekst (footer).
De hoofdtekst bestaat uit meerdere regels (records genoemd), waarvan het formaat voor elk berichttype afzonderlijk gedefinieerd moet worden.
De koptekstspecificatie van een MIA-bericht in versie 2.0.0, bevat 7 regels.
Elke regel bestaat uit een tag gevolgd door een puntkomma, en één of meerdere waardes, telkens gevolgd door een puntkomma.
Elke regel wordt gevolgd door een regelscheidingsteken, zoals dit gedefinieerd is in 6.1.2 Opmaak.
Op te merken valt dat de header van het foutbericht drie extra regels bevat wat Foutbericht (FLXFAU) betreft, zoals nader omschreven in 6.8
Metagegev en | Beschrijving | Tag | Voorbeeld | Commentaar | |||
SUBJECT | Type van het bericht. De berichtregel met deze tag bevat twee velden (naast de tag zelf) | [SUBJECT] | | PORTFOLIO 2.0.0 | |||
TIME ZONE | Tijdzone waar datum en uur geldig zijn | [TIME ZONE] | +0100 | Bevat de tijd die bij de Greenwichtijd wordt opgeteld in het formaat +HH24MI; dit is altijd +0100 | |||
CREATED ON | Tijdstip van creatie van het bericht. De berichtregel met deze tag bevat twee velden (naast de tag zelf) | [CREATED ON] | | 02092004 19:31 | Het tijd- en datumformaat is DDMMYYYY;HH24:MI | ||
MARKET | [MARKET] | 27 | 27 voor gas | ||||
TO | EAN-GLN van geadresseerde (ontvanger) van bericht | de het | [TO] | 5499775125103 | EAN-GLN van FLUXYS of van een communicatie partner | ||
FROM | EAN-GLN van afzender van bericht | de het | [FROM] | 9999999999999 | EAN-GLN van FLUXYS of van een communicatie partner | ||
MS | EAN-GLN van betrokken partij | de | [MS] | 9999999999999 | EAN-GLN betrokken DNB | van | de |
1. Het veld SUBJECT bevat twee tekenreeksen (“strings”), gescheiden door een puntkomma " ;": berichttype en versienummer van het berichtformaat. De volgende waarden zijn mogelijk:
a. PORTFOLIO;2.0.0
b. CLIENTSWITCH;2.0.0
c. PRODUCTIONSWITCH;2.0.0
d. HMETERING;2.0.0
e. DMETERING;2.0.0
f. FAULTMESSAGE;2.0.0
g. GRF;2.0.0
h. KCF;2.0.0
i. KCFD;2.0.0
j. ALLOCATION;2.0.0
k. INFEED-GCV;2.0.0
l. ICFDAI;2.0.0
m. FEEDBACK;2.0.0
2. Het veld TIME ZONE bevat de uren die bij de Greenwichtijd (GMT) opgeteld moeten worden om in de juiste tijdzone te komen. Het te gebruiken formaat is +HH24MI. De waarde zal altijd gelijk zijn aan +0100.
3. Het veld CREATED ON bevat de datum en het uur waarop het bericht is aangemaakt, in het formaat DDMMYYY;HH24:MI.
4. Het MARKET-veld bevat de code voor gas, en zal altijd gelijk zijn aan 27
5. Het veld TO bevat het EAN-GLN-nummer van de geadresseerde (ontvanger) van het bericht, dat wil zeggen het EAN-GLN-nummer van Fluxys of van een communicatiepartner.
6. Het veld FROM bevat het EAN-GLN-nummer van de afzender van het bericht (Fluxys of DNB of meetbedrijf).
7. Het MS-veld bevat het EAN-GLN -nummer van de betrokken DNB Voorbeeld van een berichtkoptekst (header):
[SUBJECT];PORTFOLIO;2.0.0; [TIME ZONE];+0100;
[CREATED ON];12102004; 03:00:00; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];9999999999999;
De hoofdtekst bevat één of meer regels. Elke regel vormt een record.
Elke record wordt gevolgd door een regelscheidingsteken, zoals dit gedefinieerd is in 6.1.2 Opmaak. Elk veld wordt gevolgd door een puntkomma.
Het recordformaat wordt voor elk berichttype afzonderlijk gedefinieerd. Cf. infra.
Als getallen met decimalen worden opgegeven, is het decimaalteken altijd een komma (“,”). Zie de regel 6.1.5 Scheidingstekens voor numerieke waarden.
De koptekstspecificatie van een MIA-bericht in versie 2.0.0, bevat één enkel veld.
Elk veld bestaat uit een tag gevolgd door een puntkomma, en een waarde gevolgd door een puntkomma.
Elk veld wordt gevolgd door een regelscheidingsteken, zoals dit gedefinieerd is in 6.1.2 Opmaak.
Metagegeven | Beschrijving | Tag | Voorbeeld | Commentaar |
Aantal regels | Aantal records in de hoofdtekst (body) | [NUMBER OF LINES IN BODY] | 12 |
Voorbeeld van een berichtvoettekst:
[NUMBER OF LINES IN BODY];2;
6.3 Portfoliobericht (FLXPOR)
Het portfoliobericht (FLXPOR) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
De lijst van het geschatte jaarverbruik (portfolio) wordt verzonden naar Fluxys via ftp. De timing van de berichten wordt nader toegelicht in de bovenstaande paragrafen.
Het veld SUBJECT bevat de tekenreeks "PORTFOLIO" gevolgd door het versienummer (“2.0.0”).
De body bevat één afzonderlijke lijn voor elke unieke combinatie van een DNB, een bevrachter, een GOS, een SLP-type en een opgegeven periode. Er mag bovendien geen overlap bestaan voor de periodes van éénzelfde DNB-VNG-GOS-SLP combinatie.
Er zijn negen kolommen in een lijn.
Kolomnr. | Naam | BESCHRIJVING | Voorbeeld | Opmerking | |||
1 | START DATE and TIME | Startdatum (inbegrepen) | en | uur | 20092004 05:00 | Datum en weergegeven formaat HH24:00; | uur worden volgens DDMMYYYY |
2 | END DATE and TIME | Einddatum (inbegrepen) | en | uur | 21092004 04:00 | Datum en weergegeven formaat HH24:00; | uur worden volgens DDMMYYYY |
3 | TGU and Load profile | SUM wordt door xxxxxxx gevolgd. Tussen haakjes: EAN-GLN-nummer van de bevrachter (of VNG) type van lastprofiel Tussen haakjes worden de velden door een komma “,” gescheiden. | SUM(5499760575906, S31) | Bevrachter voor wie de som wordt gemaakt. Type lastprofiel: - S31 < 150000 KWH (industriële kleinafnemers) - S32 = ≥ 150000 KWH (industriële grootafnemers) - S41 (huishoudelijke DNB- Eindafnemers) | |||
4 | Management | Energierichting | E12-E17 | E12-E17 = verbruik | |||
5 | Unit | Eenheid waarde. | van | de | KWH | KWH = kilowattuur | |
6 | SYC | Standaardjaarverbruik | 46650,00 | De waarden worden met twee cijfers na het decimaalteken weergegeven. Het maximaal aantal cijfers voor de komma is 25. | |||
7 | Quality | Kwaliteitscode van de waarde | H | De kwaliteitscode is altijd ‘H’. | |||
8 | ARS | Het EAN-GSRN- nummer van het GOS | 000000000000000000 | Het EAN-GSRN-nummer van het GOS waarvoor het standaardjaarverbruik (SJV) wordt berekend. | |||
9 | PCT | Procent compleet | 100 | 100% | |||
1. Een kolom voor de begindatum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het uur is inbegrepen in de geldigheidsperiode.
2. Een kolom voor de einddatum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het einduur is inbegrepen in de geldigheidsperiode.
3. Een kolom voor de bevrachter en het lastprofiel. De syntaxis is als volgt:
het woord SUM, gevolgd door een haakje
het EAN-GLN-nummer van de bevrachter, gevolgd door een komma
het type lastprofiel
1. S31: < 150000 KWH (industriële kleine DNB-Eindafnemers)
2. S32: ≥ 150000 KWH (industriële grote DNB Eindafnemers)
3. S41: huishoudelijke DNB-Eindafnemers
en een sluitend haakje Voorbeeld: SUM(5499760575906,S31)
4. Een kolom om de richting van de energiestroom aan te duiden; de kolomwaarde is altijd gelijk aan E12-E17.
5. De eenheid van de volgende waarden, die altijd gelijk is aan KWH.
6. Een kolom voor de waarde van het standaardjaarverbruik. Een allocatiewaarde kan maximum vijfentwintig cijfers voor, en twee cijfers na de komma hebben.
7. Kwaliteitscode voor de waarde, altijd gelijk aan “H”
8. Het EAN-GSRN-nummer van het GOS waarop het standaardjaarverbruik van toepassing is.
9. Kolom voor het percentage van de gevalideerde gegevens. Zal altijd gelijk zijn aan 100%
Voorbeeld van een portfoliobericht, met fictieve EAN-nummers:
[SUBJECT];PORTFOLIO;2.0.0; [TIME ZONE];+0100;
[CREATED ON];12102004; 03:00:00; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];9999999999999;
[BODY START]
14102004 05:00;15102004 04:00;SUM(9999999999999,S31);E12- E17;KWH;77526,12;H;888888888888888888;100;
14102004 05:00;15102004 04:00;SUM(9999999999999,S31);E12- E17;KWH;46650,00;H;777777777777777777;100;
14102004 05:00;15102004 04:00;SUM(9999999999999,S32);E12- E17;KWH;15348,87;H;777777777777777777;100;
[BODY END]
[NUMBER OF LINES IN BODY];3;
6.4 Clientswitchbericht (FLXCLS)
Het clientswitchbericht (FLXCLS) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header.
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "CLIENTSWITCH" gevolgd door het versienummer (“2.0.0”).
Er zijn 8 kolommen in een lijn.
Kolo mnr. | Naam | Beschrijving | Voorbeeld | Opmerking |
1. | DATE FROM | Begindatum en uur van de geldigheidsperiode (inbegrepen) | 01092004 05:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
2. | DATE TO | Einddatum en uur van de geldigheidsperiode (inbegrepen) | 01102004 04:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
3. | EAN OF RLP SUPPLY POINT | Het EAN-GSRN-nummer van het RLP-Afnamepunt | 666666666666666666 | |
4. | NAME RSP | De naam van het RLP- Afnamepunt | Sucrerie Dupont | |
5. | TYPE RSP | Het type van het RLP- Afnamepunt | H | Mogelijke waarden: - H (uurlijks) - D (dagelijks) |
6. | ARS_EAN | Het EAN-GSRN-nummer van het GOS | 888888888888888888 | |
7. | TGU_EAN | Het EAN-GLN-nummer van de bevrachter | 7777777777777 | |
8. | DGO_EAN | Het EAN-GLN nummer van de DNB | 9999999999999 |
1. Een kolom voor de beginperiode van de geldigheid van dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de eindperiode van de geldigheid van dit bericht (eindperiode inclusief), in het formaat DDMMYYYY HH24:00.
3. Het EAN-GSRN-nummer van het RLP-Afnamepunt
4. De naam van het RLP-Afnamepunt
5. Het type van het RLP-Afnamepunt. ‘H’ betekent uurlijks. Dit wil zeggen dat elk uur de afname van het punt via een ‘HMETERING’ bericht (zie 6.5) naar FLUXYS wordt gestuurd. ‘D’ betekent dagelijk. Dit wil zeggen de de afnames van het punt enkel met een ‘DMETERING’ (zie 6.6) naar FLUXYS wordt gestuurd.
6. Het EAN-GSRN-nummer van het GOS
7. Het EAN-GLN-nummer van de bevrachter
8. Het EAN-GLN nummer van de DNB
Voorbeeld van een clientswitchbericht, met fictieve EAN-nummers en bewust onvolledig gehouden (ontbrekende records):
[SUBJECT];CLIENTSWITCH;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02112004;18:23; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];9999999999999;
[BODY START]
01082004 05:00;01092004 04:00;
666666666666666666;Xxxxxxxx Xxxxxx;H;888888888888888888;7777777777777;
9999999999999;
01082004 05:00;01092004 04:00;
555555555555555555;Suikerfabriek Vandenbrugge;H;888888888888888888; 7777777777777;9999999999999;
[BODY END]
[NUMBER OF LINES IN BODY];2;
6.5 Productionswitchbericht (FLXPRS)
Het productionswitchbericht (FLXPRS) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header.
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "PRODUCTIONSWITCH" gevolgd door het versienummer (“2.0.0”).
Er zijn 8 kolommen in een lijn.
Kolo mnr. | Naam | Beschrijving | Voorbeeld | Opmerking |
1. | DATE FROM | Begindatum en uur van de geldigheidsperiode (inbegrepen) | 01092004 05:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
2. | DATE TO | Einddatum en uur van de geldigheidsperiode (inbegrepen) | 01102004 04:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
3. | EAN OF PRODUCTI ON POINT | Het EAN-nummer van de lokale productie | 666666666666666666 | |
4. | NAME PRODUCTI ON POINT | De naam van de lokale productie | Production point X | |
5. | TYPE PRODUCTI ON POINT | Het type van de lokale productie | H | Mogelijke waarde: - H (uurlijks) |
6. | ARS_EAN | Het EAN-GSRN-nummer van het GOS | 888888888888888888 | |
7. | TGU_EAN | Het EAN-GLN-nummer van de bevrachter | 7777777777777 | |
8. | DGO_EAN | Het EAN-GLN nummer van de DNB | 9999999999999 |
1. Een kolom voor de beginperiode van de geldigheid van dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de eindperiode van de geldigheid van dit bericht (eindperiode inclusief), in het formaat DDMMYYYY HH24:00.
3. Het EAN-GSRN-nummer van het productie-punt
4. De naam van het productie-punt
Het type van het productie-punt. ‘H’ betekent uurlijks. Dit wil zeggen dat elk uur de productie van het punt via een ‘HMETERING’ bericht (zie 6.5) naar FLUXYS wordt gestuurd voor de niet gevalideerde gegevens.
5. Het EAN-GSRN-nummer van het GOS
6. Het EAN-GLN-nummer van de bevrachter
7. Het EAN-GLN nummer van de DNB
Voorbeeld van een productionswitchbericht, met fictieve EAN-nummers en bewust onvolledig gehouden (ontbrekende records):
[SUBJECT];PRODUCTIONSWITCH;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02112004;18:23; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];9999999999999;
[BODY START]
01082004 05:00;01092004 04:00;
666666666666666666;???;H;888888888888888888;7777777777777; 9999999999999;
01082004 05:00;01092004 04:00;
555555555555555555;???;H;888888888888888888; 7777777777777;9999999999999; [BODY END]
[NUMBER OF LINES IN BODY];2;
6.6 Hourly Metering-bericht (FLXHMT)
Het bericht voor de uurlijkse meting (FLXHMT) wordt in versie 2.1.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "HMETERING" gevolgd door het versienummer (“2.1.0”).
De body bevat één regel per RLP-Afnamepunt of lokale productie.
Een regel bestaat uit zestien kolommen (waarvan twee kolommen vier keer worden herhaald aangezien het gegeven per kwartier wordt gedefinieerd: 8 + (4 x 2) = 16).
Kolomnr. | Naam | Beschrijving | Voorbeeld | Commentaar | |||
1 | DATE TIME | Geldigheidsdatum en -uur (volgens de tijdzone weergegeven in de header; GMT+1). | 20092004 23:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; | |||
Tijdsinterval voor de meting in het voorbeeld is 23:00 - 00:00 | |||||||
2 | CLIENT- | Het EAN-GSRN- | 888888888888888888 | Het EAN-GSRN- | |||
PRODUCTI | nummer van het | nummer van het RLP- | |||||
ON-EAN- | RLP-Afnamepunt of | Afnamepunt of van de | |||||
GSRN | van de lokale | lokale productie | |||||
productie | waarvoor de waarde | ||||||
wordt gemeten. | |||||||
3 | ENERGY | Actieve | A+ | A+ voor | RLP- | ||
DIRECTIO | energierichting van | Afnamepunten | |||||
N | het net naar de | A- voor | lokale | ||||
verbruiker of lokale | producties | ||||||
productie | |||||||
4 | UNIT | Eenheid waarden | van | de | KWH | Voor gas KWH = kilowattuur | |
5 – 8 | VALUE | De gemeten | | 123,00 | De waarden worden | ||
waarden. Voor gas | met twee cijfers na het | ||||||
is het tijdsinterval | decimaalteken | ||||||
1 uur. Dit betekent | weergegeven. | ||||||
dat alleen het | Maximum 10 cijfers | ||||||
laatste interval van | voor de komma. | ||||||
15 minuten wordt | |||||||
ingevuld. De | |||||||
andere waardes | |||||||
blijven leeg. | |||||||
9 – 12 | QUALITY CODE | De kwaliteitscode van de waarde | | Toegestane waarden: H = gemeten waarde. E = geschatte waarde | |||
| H | (de reële waarde kon niet worden gemeten ) ? = onzekere of | |||||
ontbrekende waarde. | |||||||
13 | Number of intervals an | Voor gas is dit aantal gelijk aan 1. | 1 | 1 interval voor één uur: de eerste drie van | |||
Kolomnr. | Naam | Beschrijving | Voorbeeld | Commentaar | |
hour | de vier blijven leeg | intervallen | |||
14 | Free text | Leeg | Free text | ||
15 | Serial number the meter | of | Leeg | Free text | |
16 | Channel number the meter | of | Leeg | Free text | |
1. Een kolom voor de geldigheidsdatum en uur van dit bericht, in het formaat DDMMYYYY HH24:00.
2. Het EAN-GSRN-nummer van het RLP-Afnamepunt of van de lokale productie waarvoor de meting geldt.
3. Een kolom om aan te duiden of het om actieve energie richting net en DNB-Eindafnemer gaat of om lokale productie; de kolomwaarde is altijd gelijk aan A+ of A-.
4. De eenheid van de volgende waarden, die altijd gelijk is aan KWH.
5-8. Deze vier kolommen zijn bedoeld voor een meting per kwartier. Aangezien het hier om een uurlijkse meting gaat, wordt de gemeten waarde, tot op twee decimalen precies, in de vierde kolom (kolom 8) ingevuld. De voorafgaande drie kolommen blijven telkens leeg.
13. Aantal intervallen per uur. Dit zal gelijk zijn aan 1.
14. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
15. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
16. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
Voorbeeld van een HMETERING-bericht, met fictieve EAN-nummers:
[SUBJECT];HMETERING;2.0.0; [TIME ZONE];+0100;
[CREATED ON];12102011;23:15; [MARKET];27; [TO];5499775125103; [FROM];5499757493404; [MS];5414488000905;
[BODY START]
12102011 22:00;541448810000279900;A+;KWH;;;;33333,47;;;;H;1;WIENERBERGER NV - XXXXXXXXXX;;;
12102011 22:00;541448810000279610;A+;KWH;;;;23330,41;;;;H;1;XXXXXXXXX POTATOES;;;
12102011 22:00;541448810000279627;A+;KWH;;;;2222,67;;;;H;1;XXXXXX NV;;;
12102011 22:00;541448810000279658;A+;KWH;;;;980,60;;;;H;1;XXXXXXX;;;
12102011 22:00;541448810000279672;A-;KWH;;;;300,31;;;;H;1;PRODUCTION X;;; [BODY END] [NUMBER OF LINES IN BODY];5;
Het bericht voor de dagelijkse meting en de gevalideerde meetgegevens (FLXDMT) wordt in versie 2.0.0 als volgt gespecificeerd: - een koptekst (header), zoals gedefinieerd in 6.2.1 Header - een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst - een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer | |||||||
Het veld SUBJECT bevat de tekenreeks "DMETERING" gevolgd door het versienummer (“2.0.0”). | |||||||
De body bevat één regel per RLP-Afnamepunt of lokale productie en gasdag. Voor lokale producties wordt dit bericht enkel gebruikt om gevalideerde meetgegevens door te sturen. Er zijn tweehonderdennegen kolommen in een record. De waarde en de kwaliteitscode worden honderd keer herhaald aangezien het gegeven per kwartier van de dag wordt herhaald. Een dag met 25 uren is mogelijk voor de overgang tussen zomertijd en wintertijd: 9 + ( (24 + 1) x 4 x 2 ) = 209. | |||||||
Kolomnr. | Naam | Beschrijving | Voorbeeld | Commentaar | |||
1 | START DATE and TIME | Geldigheidsdatum en -uur (volgens de tijdzone weergegeven in de header; GMT+1). | 20092004 05:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; | |||
2 | END DATE and TIME | 21092004 04:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; Het laatste uur is inbegrepen. Vb: 20092004 05:00; 21092004 04:00; omvat één gasdag in de zomer. | ||||
3 | CLIENT- PRODUCT ION | Het EAN-GSRN- nummer van het RLP-Afnamepunt of van de lokale productie | 88888888888 8888 | Het EAN-GSRN-nummer van het RLP-Afnamepunt of van de lokale productie waarvoor de waarde wordt gemeten. | |||
4 | ENERGY DIRECTIO N | Actieve energierichting van het net naar de verbruiker of lokale productie | A+ | A+ voor RLP-Afnamepunten A- voor lokale producties | |||
5 | Unit | Eenheid waarden | van | de | KWH | Voor gas KWH = kilowattuur | |
6 – 105 | Values | De gemeten waarden. Voor gas is het tijdsinterval 1 uur. Dit betekent dat alleen het laatste interval van 15 minuten wordt ingevuld. De andere waardes blijven xxxx. | x x x x x x x x … | 000,00 63,12 | De waarden worden met twee cijfers na het decimaalteken weergegeven. Maximum cijfers voor de komma zijn 10. Er zijn 100 (25 x 4) kolommen beschikbaar. *Voor een normale dag: Voor de eerste 96 (24 x 4) kolommen, wordt de gemeten waarde telkens, in de vierde kolom ingevuld. De andere velden blijven leeg, inclusief de vier velden van het 25e uur. *Voor een korte dag (overgang | ||
Kolomnr. | Naam | Beschrijving | Voorbeeld | Commentaar | ||
van wintertijd naar zomertijd): | ||||||
Voor de eerste 92 (23 x 4) | ||||||
kolommen, wordt de gemeten | ||||||
waarde telkens, in de vierde | ||||||
kolom ingevuld. De andere velden | ||||||
blijven leeg, inclusief de acht | ||||||
velden van het 24e en 25e uur. | ||||||
*Voor een lange dag | ||||||
(overgang van zomertijd naar | ||||||
wintertijd): Voor de 100 kolommen | ||||||
wordt de gemeten waarde telkens | ||||||
in de vierde kolom ingevuld. De | ||||||
andere velden blijven leeg. | ||||||
106-205 | Quality | De kwaliteitscode van de waarde | | De mogelijke waarde van de kwaliteitscode kan zijn: H = gemeten waarde. | ||
| H | V = gevalideerde waarde. E = geschatte waarde (de reële waarde kon niet worden gemeten) | ||||
| M = manueel aangepaste waarde ? E = onzekere of ontbrekende waarde (de reële waarde kon niet worden gemeten) | |||||
… | H | Er zijn 100 kolommen beschikbaar. | ||||
| *Voor een normale dag: | |||||
| Voor de eerste 96 (24 x 4) kolommen, wordt de gemeten waarde telkens, in de vierde | |||||
| kolom ingevuld. De andere velden blijven leeg, inclusief de vier | |||||
velden van het 25e uur. | ||||||
*Voor een korte dag (overgang | ||||||
van wintertijd naar zomertijd): | ||||||
Voor de eerste 92 kolommen | ||||||
wordt de reële waarde telkens in | ||||||
het vierde veld ingevuld. De | ||||||
andere velden blijven leeg, | ||||||
inclusief de acht velden van het | ||||||
24e en 25e uur. | ||||||
*Voor een lange dag | ||||||
(overgang van zomertijd naar | ||||||
wintertijd): voor de 100 kolommen | ||||||
wordt telkens in het vierde veld | ||||||
een reële waarde ingevuld. De | ||||||
andere velden blijven leeg. | ||||||
206 | Interval | Voor gas is dit | 1 | 1 interval voor één uur: de eerste | ||
interval gelijk aan 1. | drie van de vier intervallen blijven | |||||
leeg. | ||||||
207 | Free text | Leeg | Vrije tekst | |||
208 | Serial | Leeg | Vrije tekst | |||
number of | ||||||
gascounter | ||||||
209 | Channel | Leeg | Vrije tekst | |||
number of | ||||||
gascounter | ||||||
1. Een kolom voor de begindatum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de einddatum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de geldigheidsperiode.
3. Het EAN-GSRN-nummer van het RLP-Afnamepunt of van de lokale productie waarvoor de meting geldt.
4. Een kolom om aan te duiden dat het om actieve energie richting van net naar DNB- Eindafnemer of van lokale productie naar het net gaat; de kolomwaarde is altijd gelijk aan A+ of A-.
5. De eenheid van de volgende waarden, die altijd gelijk is aan KWH.
6-105. Deze honderd kolommen zijn bedoeld voor een meting per kwartier, zijnde 25 x kwartierwaarden. Aangezien het hier om een uurlijkse meting gaat, wordt de gemeten waarde, tot op twee decimalen precies, telkens in de vierde kolom (kolom 9, 13…) ingevuld. Xx xxxxxxxxxxxx 0 xxxxxxxx blijven telkens leeg. Het 25e uur dient voor de overgang van zomertijd naar wintertijd, wanneer dus ook in de 105e kolom een waarde wordt ingevuld. Voor alle andere dagen blijft deze kolom leeg. Voor de overgang van wintertijd naar zomertijd blijft bovendien ook het 24e uur (dus kolom 101) leeg. Een meetwaarde kan maximaal tien cijfers vóór en twee cijfers na het decimaalteken hebben.
206. Aantal intervallen per uur. Dit zal gelijk zijn aan 1.
207. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
208. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
209. Vrije tekst waarmee de geadresseerde (ontvanger) van het bericht geen rekening houdt.
Voorbeeld van een DMETERING-bericht, met fictieve EAN-nummers:
[SUBJECT];DMETERING;2.0.0; [TIME ZONE];+0100;
[CREATED ON];14092011;10:42; [MARKET];27; [TO];5499775125103; [FROM];939053105; [MS];5412999998;
[BODY START]
13092011 05:00;14092011
04:00;449206000123937;A+;KWH;;;;913,96;;;;884,15;;;;695,40;;;;685,47;;;;715,27;;;;645,73;;;;983,50;;;;1380,87;;;;1370,93
;;;;1907,39;;;;1609,36;;;;1172,25;;;;1231,85;;;;1202,05;;;;1122,58;;;;1172,25;;;;1261,66;;;;1460,34;;;;1122,58;;;;1072,90;;;;1 043,10;;;;1023,23;;;;1062,97;;;;1043,10;;;;;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;
;;H;;;;H;;;;H;;;;H;;;;H;;;;;1;;;;
13092011 05:00;14092011
04:00;00000000000000;A+;KWH;;;;918,35;;;;1127,98;;;;788,59;;;;878,43;;;;748,66;;;;968,26;;;;439,21;;;;728,69;;;;678,78;;;;
618,89;;;;1227,80;;;;1277,71;;;;1157,92;;;;1207,83;;;;1197,85;;;;1187,87;;;;1088,05;;;;1008,19;;;;948,30;;;;938,32;;;;948,30;;
;;958,28;;;;1157,92;;;;1367,55;;;;;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;; H;;;;H;;;;H;;;;;1;;;;
13092011 05:00;14092011
04:00;54206000122909;A+;KWH;;;;2317,72;;;;2418,01;;;;2295,44;;;;2496,01;;;;2150,58;;;;2262,01;;;;2161,72;;;;2217,44;;;;
2273,15;;;;2328,87;;;;2072,58;;;;2262,01;;;;2106,01;;;;2161,72;;;;2083,72;;;;1738,29;;;;1704,86;;;;2206,29;;;;2172,87;;;;213
9,44;;;;2217,44;;;;2128,29;;;;2128,29;;;;2061,44;;;;;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;
;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;;1;;;;
13092011 05:00;14092011
04:00;546000123845;A+;KWH;;;;774,88;;;;725,20;;;;645,73;;;;725,20;;;;715,27;;;;755,01;;;;1301,39;;;;1351,07;;;;1261,66;;;;
1241,79;;;;1182,18;;;;1231,85;;;;1261,66;;;;1192,12;;;;1231,85;;;;1231,85;;;;735,14;;;;685,47;;;;675,53;;;;745,07;;;;735,14;;;;
685,47;;;;715,27;;;;715,27;;;;;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;;H;;;; H;;;;H;;;;;1;;;;
13092011 05:00;14092011 04:00;541448811000009634;A-
;KWH;;;;0,00;;;;100,00;;;;112,00;;;;58,00;;;;84,00;;;;33,00;;;;623,00;;;;211,00;;;;31,00;;;;2,30;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0
,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;0,00;;;;;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;
;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;V;;;;;1;;;; 13092011 05:00;14092011
[BODY END]
[NUMBER OF LINES IN BODY];5;
6.8 Foutbericht (FLXFAU)
Het foutbericht in versie 2.0.0 als volgt gespecificeerd:
- een soortgelijke header als die welke in 6.2.1 Header is gedefinieerd, met drie extra velden
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "FAULTMESSAGE" gevolgd door het versienummer (“2.0.0”).
De header bestaat uit de standaard header regels gevolgd door drie extra regels: ORIGINAL TYPE, ORIGINAL REFERENCE en ORIGINAL RECEPTION.
Metagegeven | Beschrijving | Tag | Voorbeeld | Opmerking |
SUBJECT | ||||
TIME ZONE | ||||
CREATED ON | ||||
MARKET | ||||
TO | ||||
FROM | ||||
MS | ||||
ORIGINAL TYPE | Het berichttype waarop dit foutbericht betrekking heeft | [ORIGINAL TYPE] | ALLOCATIE | Mogelijke waarden: {CLIENTSWITCH, PRODUCTIONSWITC H, PORTFOLIO, HMETERING, DMETERING, ALLOCATION, FEEDBACK} |
ORIGINAL REFERENCE | De referentie van het bericht waarop dit xxxxxxxxxxx betrekking heeft | [ORIGINAL REFERENCE] | De naam van het bericht waarop dit foutbericht betrekking heeft | |
ORIGINAL RECEPTION | De datum en het uur waarop Fluxys het desbetreffende bericht ontvangen heeft. De lijn met de tag, bevat (buiten de tag zelf) twee velden | [ORIGINAL RECEPTION] | 02102004 20:02 | De datum en tijd worden opgegeven in het formaat DDMMYYYY;HH24:MI |
7. Het ORIGINAL TYPE-veld bevat het type bericht waarop het foutbericht van toepassing is.
8. Het ORIGINAL REFERENCE-veld bevat de referentie naar het bericht waarop het foutbericht van toepassing is. Concreet zal dit de filenaam van het bericht zijn.
9. Het ORIGINAL RECEPTION-veld bevat het ogenblik waarop het bericht waarop het foutbericht van toepassing is, ontvangen werd bij Fluxys.
Een record bestaat uit zes velden.
Kolomnr. | Naam | Beschrijving | Voorbeeld | Opmerking |
1 | LEVEL | kan “warning” of “error” zijn | WARNING | Warning: aanvaard Error: geweigerd |
2 | CODE | De foutcode | 2.3 | Kan meer of minder gedetailleerd zijn. Kan zowel 1 als 1.2.5 zijn. Hoe meer cijfers, hoe groter de detailleringsgraad. |
3 | DESCRIPTION | Foutbeschrijving | Shipper with EAN not valid on date | |
4 | REFUSED PART INDICATION | Xxxxx aan welk berichtgedeelte geweigerd is als gevolg van de fout | Line | Mogelijke waarden: {nothing, message, line, value} |
5 | LOCATION | Xxxxx aan in welk berichtgedeelte de fout is vastgesteld | Body(line 12) | Optioneel. Zal gegeven worden als de locatie in het bericht gekend is. |
6 | DETAILS | Geeft de details van de vastgestelde fout | {01082004 05:00;01092004 04:00; 666666666666666666; 888888888888888888; 7777777777777; 9999999999999;} | Optioneel. De details worden zo nauwkeurig mogelijk weergegeven. |
1. Een kolom die aangeeft of het om een waarschuwing (warning) dan wel om een fout (error) gaat. Het type WARNING geeft aan dat rekening is gehouden met het berichtgedeelte in kwestie, terwijl het type ERROR resulteert in het verwerpen (weigeren) van het desbetreffende berichtgedeelte.
2. Een kolom voor de errorcode. De errorcode kan van een hoger niveau zijn (enkel cijfers uit de hogere lagen, bijvoorbeeld: 1.1 Format Fault. Invalid Content), maar kan ook erg gedetailleerd zijn (cijfers van de hoogste tot de lagere lagen, bijvoorbeeld: 1.1.4.1.1 Format Fault. Invalid Content. Invalid Validity Code. Unknown code).
3. Een kolom voor de verklarende tekst. Deze kolom zal een tekstuele vertaling van de fault code bevatten. Zie de lijst in de bijlage II: 0 Lijst met foutberichten.
4. Een veld om aan te duiden welk deel van het bericht geweigerd werd naar aanleiding van de fout waarover de lijn in het foutbericht gaat. Dit kan zijn: “line” (regel), “message” (bericht), “value” (waarde) of “nothing” (niets).
5. Een kolom om aan te geven in welk deel van het bericht de fout gelocaliseerd is. Dit veld is optioneel, en zal enkel worden ingevuld indien mogelijk.
6. Een veld voor verdere details. De details zullen gegeven worden voor zover dit mogelijk is. Algemeen gesteld zijn er 2 types details:
- In het geval van formaatfouten, de tekst waarin de fout was gevonden. Deze tekst zal zelf veldscheidingen (;) bevatten, daarom zal de tekst omgeven zijn door accolades ({}).
- In het geval van inconsitenties met Fluxysgegevens, meer details om de fout te kunnen plaatsen, zoals EAN nummers of datums.
Het aantal regels hangt af van de vastgestelde fouten. Indien een fout wordt gevonden die ervoor zorgt dat het hele bericht wordt geweigerd, zal dit aanleiding geven tot het staken van de verwerking van het bericht. Er kunnen in dat stadium al een aantal fouten gevonden zijn, waarvoor regels zijn opgenomen in het foutbericht, maar in elk geval zal de fout waarvoor het bericht wordt geweigerd, aanleiding geven tot de laatste regel in het bericht.
Wordt een fout vastgesteld in verschillende regels van het oorspronkelijke bericht – bijvoorbeeld een bevrachter die niet langer actief is op een GOS, dan worden evenveel foutberichten gegeven als er regels waren met deze bevrachter en dit GOS.
Een regel in het oorspronkelijk bericht kan ook aanleiding geven tot meerdere regels in het foutbericht, met name in het geval van de DMETERING berichten, waar elke waarde apart kan verworpen worden omwille van een niet geaccepteerde validatiecode (E,?,M).
De regels met SUB metering worden geweigerd zonder dat hiervoor een expliciet waarschuwing (warning) wordt gegeven. Anders gezegd: deze regels worden genegeerd, maar er wordt geen enkel foutbericht teruggestuurd.
In het foutbericht worden de regels niet noodzakelijkerwijs in dezelfde volgorde opgenomen als in het oorspronkelijke bericht.
Voorbeeld van een bericht FAULTMESSAGE, met fictieve EAN-nummers:
[SUBJECT];FAULTMESSAGE;2.0.0; [TIME ZONE];+0100;
[CREATED ON];18012006; 09:38; [MARKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];9999999999998;
[ORIGINAL TYPE];DMETERING;
[ORIGINAL REFERENCE];DMet20060501.txt; [ORIGINAL RECEPTION];18012006; 09:27; [BODY START]
Error;1.1.4.1;Format Fault. Invalid Content. Invalid Validity Code;Line;Body(Line 1);{22022006 19:00;22022006 20:00;888888888888888888;A+;KWH;;;;0;;;;0;;;;?;;;;H;1;;;};
Error;1.1.4.1;Format Fault. Invalid Content. Invalid Validity Code;Line;Body(Line 2);{22022006 19:00;22022006 20:00;9999999999999999999;A+;KWH;;;;0;;;;0;;;;?;;;;H;1;;;};
[BODY END]
[NUMBER OF LINES IN BODY];2;
6.9 GRF bericht (FLXGRF)
Het bericht voor de GRF (FLXGRF) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "GRF" gevolgd door het versienummer (“2.0.0”).
Voor elke gasdag bevat de body een aparte regel.
De periode is altijd een gasmaand: begindatum = eerste dag van de maand en einddatum = laatste dag van de maand.
Elke regel FLXGRF telt 30 kolommen (waarvan één of twee kolommen leeg kunnen zijn, naargelang van de datum):
Kolomnr. | Naam | Beschrijving | Voorbeeld | Commentaar |
1. | DATE_FROM | Start datum en uur (inbegrepen) | 02092004 05:00 | Datum en uur wordt weergegeven volgens formaat DDMMYYYY HH24:00; |
2. | DATE_TO | Eind datum en uur (inbegrepen) | 03092004 04:00 | Datum en uur wordt weergegeven volgens formaat DDMMYYYY HH24:00; |
3. | ARS_EAN- GSRN | Het EAN-GSRN-nummer van het GOS | 888888888888888 888 | |
4. | GRF_VERSIO N | Versienummer van de GRF | 2 | |
5. | ALLOC_VERSI ON | Versienummer van de allocatie van een DNB samengesteld uit 2 afzonderlijke nummers (ALLOC_MAJOR en ALLOC_MINOR) gescheiden door een punt | 3.0 | Verschilt voor elke XXX |
0-00 | XXX0 – XXX00 | GRF voor uur #1 – GRF voor uur #23 | 0,99723458 | GRF’s worden tot op acht decimalen precies weergegeven |
29-30 | GRF24 & GRF25 | GRF voor uur #24 & GRF voor uur #25 | 0,99723458 | GRF’s worden tot op acht decimalen precies weergegeven Kan leeg zijn. |
1. Een kolom voor de begindatum en het beginuur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:MI.
2. Een kolom voor de einddatum en het einduur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:MI. Het einduur is begrepen in de geldigheidsperiode.
3. Het EAN-GSRN-nummer voor het betrokken GOS.
4. Het versienummer van de GRF, ook lusnummer genoemd.
5 Het versienummer van de laatste allocatie die is ontvangen van de DNB voor wie het bericht bestemd is.
6-30. In deze vijfentwintig kolommen wordt één GRF-waarde per uur opgenomen, tot op acht decimalen precies. De eerste drieëntwintig kolommen (kolommen 6-28) zijn altijd ingevuld. Het 25e uur (kolom 30) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom 29) leeg.
Voorbeeld van een GRF-bericht, met fictieve EAN-nummers, en bewust onvolledig gehouden (ontbrekende kolommen in de records, en ontbrekende records):
[SUBJECT];GRF;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02102004;18:23; [MARKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];9999999999999;
[BODY START]
01092004 05:00;02092004 04:00;888888888888888888;2;3;0;
0,96581178;0,90436767;0,90798626;0,92065776;0,93833766;0,93154395;0,96581178
; 0,92065776;0,93833766;0,93154395;………………;
02092004 05:00;03092003 04:00;888888888888888888;2;3;0;
0,96581178;0,90436767;0,90798626;0,92065776;0,93833766;0,93154395;0,96581178
;0,92065776;0,93833766;0,93154395;………………;
……………… [BODY END]
[NUMBER OF LINES IN BODY];31;
6.10 KCF bericht (FLXKCF)
Het bericht voor de KCF (FLXKCF) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "KCF" gevolgd door het versienummer (“2.0.0”).
Voor elke gasdag en voor elk SLP-type bevat de body een aparte regel.
Er zijn (afhankelijk van de dag) tussen zevenentwintig en negenentwintig kolommen in een regel.
Kolom nr. | Naam | Beschrijving | Voorbeeld | Opmerking | ||
1 | DATE_FRO M | Start datum (inbegrepen) | en | uur | 02092003 06:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
2 | DATE_TO | Eind datum (inbegrepen) | en | uur | 03092003 05:00 | Datum en uur worden weergegeven volgens formaat DDMMYYYY HH24:00; |
3 | REGION_CO DE | Code voor de regio waarin de SLP berekend is | UDF | Lengte is max 4. Toegestane waarden zijn KST, UDF, CNT, KMP, BLT, ARD | ||
4 | SLP Type | SLP Type | S31 | Maximumlengte: 3. Toegestane waarden zijn X00, X00, X00. | ||
5-27 | KCF1 KCF23 | – | KCF voor uur #1 – KCF voor uur #23 | 0,99723458 | KCF’s worden tot op 8 decimalen precies weergegeven | |
28-29 | KCF24 KCF25 | & | KCF voor uur #24 & KCF voor uur #25 | 0,99723458 | KCF’s worden tot op 8 decimalen precies weergegeven. Kan leeg zijn. | |
1. Een kolom voor de begin datum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de eind datum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de geldigheidsperiode.
3. De code voor de regio in dewelke de SLP berekend is. De mogelijke waarden zijn KST (kust), UDF (undefined), CNT (centrum), KMP (Kempen), BLT (Belgisch Lotharingen) en ARD (Ardennen). In de praktijk wordt alleen de UDF-code gebruikt. Alleen de temperaturen van Ukkel worden gebruikt omdat die representatief zijn voor het centrum van België.
4. Het SLP type. De mogelijke waarden zijn X00, X00 en S41.
5-29. In deze vijfentwintig kolommen wordt één KCF-waarde per uur opgenomen, tot op acht decimalen precies. De eerste drieëntwintig kolommen (kolommen 5-27) zijn altijd ingevuld. Het 25e uur (kolom 29) dient voor de overgang van zomertijd naar wintertijd.
Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom 28) leeg.
Voorbeeld van een KCF-bericht, met fictieve EAN-nummers, en bewust onvolledig gehouden (ontbrekende kolommen in de records, en ontbrekende records):
[SUBJECT];KCF;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02102004;18:23; [MARKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];9999999999999;
[BODY START]
02092004 05:00;03092003
04:00;UDF;S32;0,87081502;0,84904841;0,86439488;0,82544247;0,82295690;0,73680
142;0,77955230;0,78848951;0,83843599;…
………
[BODY END]
[NUMBER OF LINES IN BODY];93;
6.11 KCFD bericht (FLXKCD)
Het bericht voor de KCFD (FLXKCD) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "KCFD" gevolgd door het versienummer (“2.0.0”).
De body is precies identiek aan die welke in 6.1010 KCF bericht (FLXKCF), 6.10.2 Body is gedefinieerd.
Zie 6.1010 KCF bericht (FLXKCF), 6.10.3 Voorbeeld
6.12 Allocatiebericht (FLXALL)
Het bericht voor de DNB-allocaties (FLXALL) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "ALLOCATION" gevolgd door het versienummer (“2.0.0”).
De body bevat één afzonderlijke regel voor elke unieke combinatie van een dag, een bevrachter, een lastprofiel en een GOS.
Een regel bestaat uit 59 kolommen.
Kolom nr. | Naam | Beschrijving | Voorbeeld | Opmerking |
1 | DATE FROM | Start datum en uur | 20092004 05:00 | Datum wordt gegeven volgens |
Kolom nr. | Naam | Beschrijving | Voorbeeld | Opmerking |
(inbegrepen) | formaat DDMMYYYY HH24:00; | |||
2 | DATE TO | Eind datum en uur (inbegrepen) | 21092004 04:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
3 | TGU, LOAD PROFILE | SUM wordt door xxxxxxx gevolgd. Tussen haakjes: Het EAN-GLN- nummer van de bevrachter type van lastprofiel Tussen haakjes worden de velden door een komma “,” gescheiden. | SUM (8888888888888, S41) | SUM (EAN bevrachter, lastprofiel); het EAN-GLN-nummer van de bevrachter voor wie de som is gemaakt. Type van lastprofiel: - S30: reëel lastprofiel, zowel gebruikt voor verbruik als voor lokale productie - S31: < 150000 KWH (industriële kleinafnemers) - S32: ≥ 150000 KWH (industriële grootafnemers) - S41: huishoudelijke gasverbruikers - S88: laatste ontvangen GRF - S98: reële belastingfactor + SLP gas |
4 | MANAGEME NT | Energierichting | E12-E17 | E12-E17 = verbruik E12-E18 = lokale productie - Voor SLP S30, kan dit veld de waarde X00-X00 xx X00- X00 bevatten - Voor SLP S31, S32 en S41, moet dit veld de waarde E12- E17 bevatten - Voor SLP S88 moet dit veld de waarde E12-E17 bevatten. - Voor SLP S98 kan dit veld de waarde X00-X00 xx X00- X00 bevatten |
5 | SWITCHING CATEGORY | Switching category (frequentie type van afname), MONTHLY, YEARLY, TELE METERED | B17 | Type van afname frequentie: - B17 Monthly - B18 Yearly - E13 Continuous (TM client) - Voor SLP S31, S32 en S41, moet dit veld opgevuld worden met de waardes B17 of B18. - Voor SLP S30, moet dit veld de waarde E13 bevatten - Voor SLP S88 en S98 moet dit veld leeg zijn. |
6 | UNIT | Eenheid van de waarden | KWH | Voor gas KWH = kWh Optioneel voor S88. |
7-31 | VALUES | De waarden | 123,00 456,12 222,78 … | De waarde heeft twee cijfers na de komma. Het decimaalteken is een komma (“,”). Het maximumaantal |
Kolom nr. | Naam | Beschrijving | Voorbeeld | Xxxxxxxxx |
x 0 | xxxxxxx xxxx het decimaalteken bedraagt 25. | |||
32-56 | QUALITY CODE | De kwaliteitscode voor de waarden in referentie (zelfde positie). | H H H … | De kwaliteitscode voor een reële waarde is altijd “H”. De laatste twee velden kunnen leeg zijn. |
57 | ARS EAN- GSRN | Het EAN-GSRN - nummer van het GOS | 77777777777777 7777 | Het EAN-GSRN -nummer van het GOS |
58 | GRF_VERSIO N | Versienummer van de gebruikte GRF | 2 | Moet identiek zijn voor alle records van hetzelfde GOS en dezelfde maand |
59 | ALLOC_VER SION | Versienummer van het allocatiebericht van de DNB samengesteld uit twee nummers (ALLOC_MAJOR en ALLOC_MINOR) Gescheiden door een punt. | 11.0 |
1. Een kolom voor de begindatum en het beginuur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de einddatum en het einduur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de geldigheidsperiode.
3. Een kolom voor de bevrachter en het lastprofiel. De syntax is als volgt:
het woord SUM, gevolgd door een haakje
het EAN-GLN-nummer van de bevrachter, gevolgd door een komma
het type lastprofiel
1. S30: echt lastprofiel
S30 met energierichting E12-E17: som van alle telegelezen RLP- Afnamepunten
S30 met energierichting E12-E18: som van alle telegelezen lokale producties
2. S31: < 150000 KWH (industriële kleine DNB-Eindafnemers)
3. S32: ≥ 150000 KWH (industriële grote DNB-Eindafnemers)
4. S41: huishoudelijke DNB-Eindafnemers
5. S88: laatste ontvangen GRF
6. S98: som van X00, X00, X00 en S41. Indien er lokale productie is, worden er 2 records S98 verwacht: één met energierichting E12-E17 en één met energierichting E12-E18.
en een sluitend haakje
Voorbeeld: SUM(5499760575906,S31)
4. Een kolom om de richting van de energiestroom aan te duiden; de kolomwaarde is altijd gelijk aan E12-E17 voor verbruik of E12-E18 voor lokale productie. Indien er productie is op een GOS, worden beide totalen verwacht.
- Voor SLP S30, kan dit veld de waarde E12-E17 of E12-E18 bevatten
- Voor SLP S31, S32 en S41, moet dit veld de waarde E12-E17 bevatten (geen lokale productie mogelijk)
- Voor SLP S88 moet dit veld de waarde E12-E17 bevatten (bij conventie)
- Voor SLP S98 kan dit veld de waarde E12-E17 of E12-E18 bevatten
5. Type afname frequentie
B17 Monthly
B18 Yearly
E13 Continuous (TM client)
- Voor SLP S31, S32 en S41, moet dit veld ingevuldt worden met de waarde B17 of B18
- Voor S30 moet dit veld E13 bevatten.
- Voor S88 en S98 moet dit veld leeg blijven
6. De eenheid van de volgende waarden, die altijd gelijk is aan KWH. Alleen wanneer de code in het vorige veld S88 is, kan dit veld leeg blijven.
7-31. In deze vijfentwintig kolommen wordt één allocatie per uur opgenomen, tot op twee decimalen precies. Het 25e uur (kolom 30) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen blijft deze kolom leeg. Voor de overgang van wintertijd naar zomertijd blijft bovendien ook het 24e uur (kolom 29) leeg. Een allocatiewaarde kan maximum vijfentwintig cijfers voor, en twee cijfers na de komma hebben.
32-56. De kwaliteitscode voor de kolommen 6-30. Er is één enkele waarde mogelijk: "H" voor een gemeten waarde. Het veld voor het 25e uur blijft leeg voor elke dag, behalve bij overgang van zomertijd naar wintertijd, en het veld voor het 24e uur blijft leeg voor de overgang van wintertijd naar zomertijd.
57. Het EAN-GSRN-nummer van het GOS waarop de allocatiegegevens van toepassing zijn.
58. Het versienummer van de GRF die op de allocatiegegevens is toegepast. Xxxx identiek zijn voor alle records van hetzelfde GOS en dezelfde maand.
59. Het versienummer van de allocatiegegevens: twee positieve gehele getallen, gescheiden door een punt. Xxxxxx identiek zijn voor alle regels in een bericht.
Voorbeeld van een allocatiebericht, met fictieve EAN-nummers en bewust onvolledig gehouden (ontbrekende records en ontbrekende kolommen in de records):
[SUBJECT];ALLOCATION;2.0.0; [TIME ZONE];+0100;
[CREATED ON];20042004;11:46; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];9999999999999;
[BODY START]
01032004 06:00;02032004 05:00;SUM(8888888888888,S30);E12-E17;E13;KWH;1000,37;1200,09
…;800,11;;H;H …;H;;6465112;2;11.0;
01032004 06:00;02032004 05:00;SUM(8888888888888,S30);E12-E18;E13;KWH;500,48;600,08
…;400,22;;H;H …;H;;465465465;2;11.0;
01032004 06:00;02032004 05:00;SUM(8888888888888,S31);E12-E17;B17;KWH;520,48;731,10
…;321,35;;H;H …;H;; 454451;2;11.0;
01032004 06:00;02032004 05:00;SUM(8888888888888,S32);E12-E17;B18;KWH;720,59;931,21
…;589,35;;H;H …;H;; 48944889;2;11.0;
01032004 06:00;02032004 05:00;SUM(8888888888888,S41);E12-E17;B17;KWH;920,60;1131,32
…;633,22;;H;H …;H;; 445641;2;11.0;
01032004 06:00;02032004 05:00;SUM(541151158,S88);E12-E17;;KWH;0,95;0,92
…;1,03;;H;H …;H;; 15115151;2;11.0;
01032004 06:00;02032004 05:00;SUM(51561888888,S98);E12-E17;;KWH;3162,04;2793,61
…;2344,03;;H;H …;H;; 844465456;2;11.0;
01032004 06:00;02032004 05:00;SUM(51561888888,S98);E12-E18;;KWH;500,48;600,08
…;400,22;;H;H …;H;; 844465456;2;11.0;
[BODY END]
[NUMBER OF LINES IN BODY];8;
6.13 Bericht Infeed-GCV (INFEEDGCV)
Het bericht voor de infeed en de GCV (Infeed-GCV) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "Infeed-GCV" gevolgd door het versienummer (“2.0.0”).
Voor elke gasdag en meetlijn bevat de body een aparte regel..
Er zijn (afhankelijk van welke dag) tussen vijfenzeventig tot éénentachtig kolommen in een record:
Kolom nr. | Naam | Beschrijving | Voorbeeld | Opmerking |
1 | DATE_FROM | Startdatum (inbegrepen) | 21092004 05:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
2 | DATE_TO | Einddatum (inbegrepen) | 22092004 04:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
3 | EAN-GSRN ARS | Het EAN-GSRN - nummer van het GOS | 000000000000000000 | |
4 | EAN-GSRN RS | Het EAN-GSRN van het OS | 541449500001625705 | |
5 | EAN-GSRN MET_LINE | EAN-GSRN van elke meetlijn van het GOS | 541449500001641774 | |
6 | FLXNODE | Nummer van Fluxys-knooppunt | 23151 | |
7 | FLXLINE | Fluxys lijn nummer | 1 | |
8-30 | VOL01 – VOL23 | Volumes in m³(n) van uur #1 tot uur #23 | 12546,11 | De volumes worden weergegeven met twee decimalen. |
31-32 | VOL24 & VOL25 | Volumes in m³(n) van uur #24 tot uur #25 | 13507,47 | De volumes worden weergegeven met twee decimalen. Kunnen leeg zijn. |
33-55 | GCV01 – GCV23 | GCV in kWh/m³(n) voor uur #1 en uur #23 | 11,5681 | GCV heeft een nauwkeurigheid van 4 cijfers na de komma |
56-57 | GCV24 & GCV25 | GCV in kWh/m³(n) voor uur #24 en uur #25 | 11,5681 | De calorische bovenwaarde (GCV) wordt tot op vier decimalen precies weergegeven. Kan leeg zijn. |
58-80 | ENER01-ENER23 | Energie in kWh voor uur #1 tot uur #23 | 145133,31 | De energie wordt uitgedrukt in kWh en met twee decimalen weergegeven. |
81-82 | ENER24-ENER25 | Energie in kWh voor uur #24 en uur #25 | 145182,81 | De energie wordt uitgedrukt in kWh en met twee decimalen weergegeven. Kunnen leeg zijn. |
83-105 | WGHT01-WGHT23 | Gewicht van de lijn in de OS hergroepering voor uur #1 tot uur #23 | 0,5 | Toegestane waarden: 1 0,5 0 -1 |
106- 107 | WGHT24&WGHT2 5 | Gewicht van de lijn in de OS hergroepering voor uur #24 en uur #25 | 0,5 | Toegestane waarden: 1 0,5 0 -1 |
108 | STATUS | STATUS voor de gasdag voor de lijn | 2 | 0 = no data 1 = voor alle niet gevalideerd data 2 = voor sommige niet gevalideerd data 3 = alle gevalideerd data |
1. Een kolom voor de begindatum en uur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00.
2. Een kolom voor de einddatum en ur van de geldigheidsperiode voor dit bericht, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de geldigheidsperiode.
3. Het EAN-GSRN -nummer van het GOS.
4. Het EAN-GSRN nummer van het OS.
5. Het EAN-GSRN nummer van elke meetlijn van het GOS.
6. Het knooppuntnummer van Fluxys
7. Het meetlijnnummer van Fluxys
8-32. In deze vijfentwintig kolommen wordt één volumewaarde per uur vermeld, uitgedrukt in cijfers met twee decimalen en met m3(n) als eenheid. Deze uurlijkse volumewaarde is gelijk aan de meetwaarde vermenigvuldigd met het uurlijkse gewicht van de meetlijn dat in veld 83-107 terug te vinden is. De eerste drieëntwintig kolommen (8-30) zijn altijd ingevuld. Het 25e uur (kolom 32) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom 31) leeg.
33-57. In deze vijfentwintig kolommen wordt een calorische bovenwaarde (GCV) per uur vermeld, tot op vier cijfers na het decimaalteken precies, uitgedrukt in kWh/m³(n). De eerste drieëntwintig kolommen (33-55) zijn altijd ingevuld. Het 25e uur (kolom 57) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom 56) leeg.
58-82. In deze vijfentwintig kolommen wordt één energiewaarde per uur vermeld, uitgedrukt in cijfers met twee decimalen en met kWh als eenheid. Deze uurlijkse energiewaarde is gelijk aan de meetwaarde vermenigvuldigd met het uurlijkse gewicht van de meetlijn dat in veld 83-107 terug te vinden is. De eerste drieëntwintig kolommen (58-80) zijn altijd ingevuld. Het 25e uur (kolom 82) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom 81) leeg.
83-107. Deze vijfentwintig kolommen zijn bedoeld voor de waarde van het gewicht van de meetlijn in de OS hergroepering. De waarde kan gelijk zijn aan 1, 0, -1 of 0,5. De eerste drieëntwintig kolommen (83-105) zijn altijd ingevuld. Het 25e uur (kolom 107) dient voor de overgang van zomertijd naar wintertijd. Voor alle andere dagen moet deze kolom leeg blijven. Voor de overgang van wintertijd naar zomertijd is bovendien ook het 24e uur (kolom
108) leeg.
108. De status voor de betrokken gasdag. Er zijn vier waarden mogelijk: 0 voor geen gegevens, 1 voor alle gegevens, maar niet gevalideerd, 2 voor bepaalde niet-gevalideerde gegevens, 3 voor alle gevalideerde gegevens.
Voorbeeld van een bericht Infeed-GCV voor 1 dag met 2 OS-lijnen en met fictieve EAN-nummers. Het bericht is bewust onvolledig gehouden (ontbrekende kolommen):
[SUBJECT];Infeed-GCV;2.0.0; [TIME ZONE];+0100;
[CREATED ON];24102004; 18:23:00; [MATKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];9999999999999;
[BODY START]
21092004 05:00;22092003 04:00;777777777777777777;666666666666666666;
444444444444444444;99999;1;12946,11;;;;…;;;11,6052;;;…;;;150240,81;;;; …
;;;1;;;…;;;2;
….
….
22092003 05:00;23092003 04:00; 777777777777777777;555555555555555555;
333333333333333333;99999;3;12954,47;;;;…;;;11,6222;;;…;;;150553,38;;;; …
;;;0,5;;;…;;;2; [BODY END]
[NUMBER OF LINES IN BODY];31;
6.14 ICFDAI-bericht (ICFDAI)
Het bericht voor de ICF en DAI (ICFDAI) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
In het ICF-DAI-bericht ontvangt de DNB:
- de ICF en de DAI;
- het totaal van zijn allocatie volgens type (S30, S31, S32, S41) en richting van de energiestroom per bevrachter. De DNB kan deze gegevens vergelijken met deze die hij naar Fluxys heeft verstuurd;
- het totaal van de allocaties van alle DNB’s van het GOS volgens type en per bevrachter.
Op basis hiervan kan de DNB eenvoudig berekenen welke invloed een wijziging in zijn eigen cijfers op de allocatie heeft. Hij kan eveneens bij benadering een algemene maandelijkse GRF berekenen.
Other DGO's | |||
DAI | |||
S30 S31 S32 S41
Infeed
A B C
Totaal voor de DNB
voor elke bevrachter van deze DNB op dit GOS
Opmerking: de DAI is een absolute waarde
S30 | S31 | S32 | S41 |
S30 | S31 | S32 | S41 |
S30 | S31 | S32 | S41 |
S30 | S31 | S32 | S41 |
A Totaal voor alle DNB's
B voor elke bevrachter die actief is op het C GOS
D
De DNB ontvangt de infeed via een INFEED-GCV bericht, zoals beschreven in hoofdstuk 6.13 Bericht Infeed-GCV (INFEEDGCV). Hij kan de infeed ook opnieuw berekenen op basis van de formule:
Infeed = | DAI / (ICF - 1) |
Het veld SUBJECT bevat de tekenreeks "ICFDAI" gevolgd door het versienummer (“2.0.0”).
De body bevat een aparte regel voor elk bestaande combinatie SLP type-energiestroomrichting (bestaande combinaties zijn: S30 E12-E18, S30 E12-E17, S31 E12-E17, S32 E12-E17, S41 E12-E17)
voor elke bevrachter, die tijdens de maand in kwestie actief is op het betrokken GOS voor de DNB voor wie het bericht bestemd is.
Het bericht kan ook bevrachters bevatten met wie de DNB niet op dit GOS werkt, maar die wel degelijk actief zijn voor andere DNB’s: in dit geval staat de waarde 0 in het veld TOTAL DGO.
Heeft de DNB geen gegeven voor een combinatie verstuurd, dan verschijnt die evenmin in het ICFDAI- bericht, tenzij een andere DNB een dergelijke combinatie heeft verstuurd.
De periode is altijd een gasmaand. Een regel bestaat uit 13 kolommen:
Kolom nr. | Naam | Beschrijving | Voorbeeld | Commentaar | ||
1. | DATE_FROM | Eerste uur van de periode (inbegrepen) | 01092004 05:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; | ||
2. | DATE_TO | Laatste uur van de periode (inbegrepen) | 01102004 04:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; | ||
3. | GOS_EAN-GSRN | Het EAN-GSRN - nummer van het GOS | 00000000000000000 8 | GOS = ARS | ||
4. | GRF_VERSION | Versienummer de GRF | van | 2 | ||
5. | ICFDAI_VERSION | Versienummer de ICF en DAI | van | 1 | ||
6. | ICF | ICF | 0,99723458 | De ICF wordt tot op acht decimalen precies weergegeven | ||
7. | DAI | DAI | 3487 | De DAI wordt uitgedrukt in kWh, zonder decimalen | ||
8. | ALLOC_VERSION | Versienummer van de allocatie van de DNB, samengesteld met 2 getallen (ALLOC_MAJOR en ALLOC_MINOR) geschedeiden door een punt | 3.0 | Verschilt DNB | voor | elke |
9. | SLP | S31 | Eén van de volgende vier waarden: - S30 (=RLP) - S31 - S32 - S41 | |||
10. | MANAGEMENT | Energierichting | E12-E17 | E12-E17 = verbruik E12-E18 = lokale productie - Voor SLP S30, kan dit veld de waarde E12-E17 of E12-E18 bevatten - Voor SLP S31, S32 en S41, moet dit veld de waarde E12-E17 bevatten | ||
11. | TGU_EAN-GSRN | Het EAN-GSRN- nummer van de TGU | 00000000000000000 8 | TGU = bevrachter | ||
12. | TOTAL DGO | Totaal op het GOS voor de bevrachter, voor de DNB voor het SLP-type en voor de Energierichting | 1452064,49 | In kWh decimalen Verschilt DNB | met voor | twee elke |
13. | TOTAL TGU | Totaal op het GOS voor de bevrachter, | 99723458,92 | In kWh decimalen | met | twee |
voor het SLP-type en voor de Energierichting, voor alle DNB’s | Identieke waarde voor alle DNB’s |
1. Een kolom voor het eerste gasuur van de periode, in het formaat DDMMYYYY HH24:00. Het beginuur is begrepen in de periode.
2. Een kolom voor het laatste gasuur van de periode, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de periode.
3. Het EAN-GSRN-nummer van het betrokken GOS.
4. Het versienummer van de GRF, ook lusnummer genoemd.
5. Voor elk GRF-nummer begint het versienummer van de ICF en de DAI opnieuw met 1.
6. De ICF berekend volgens de laatste allocaties die van de verschillende DNB’s ontvangen zijn.
7. De DAI berekend volgens de laatste allocaties die van de verschillende DNB’s ontvangen zijn.
8. De versienummers van de laatste allocatie ontvangen van de DNB voor wie het bericht bestemd is.
9 Het SLP-type (S31, S32, S41), of S30 voor de telegelezen DNB-Eindafnemers.
10. Een kolom om de richting van de energiestroom aan te duiden; de kolomwaarde is altijd gelijk aan E12-E17 voor verbruik of E12-E18 voor lokale productie. Indien er productie is op een GOS, worden beide totalen verwacht.
- Voor SLP S30, kan dit veld de waarde E12-E17 of E12-E18 bevatten
- Voor SLP S31, S32 en S41, moet dit veld de waarde E12-E17 bevatten
11. Het EAN-GSRN-nummer van de betrokken bevrachter.
12. De totale energiehoeveelheid die tijdens de aangeduide periode voor de aangeduide bevrachter op het aangeduide GOS is afgeleverd door tussenkomst van deze DNB (vermeld in de header) bij DNB-Eindafnemers van het opgegeven SLP-type en energierichting.
13. De totale energiehoeveelheid die tijdens de aangeduide periode voor de aangeduide bevrachter op het aangeduide GOS is afgeleverd door tussenkomst van alle DNB’s bij DNB-Eindafnemers van het opgegeven SLP-type en energierichting.
Voorbeeld van een ICFDAI-bericht met fictieve EAN-nummers en bewust onvolledig gehouden:
[SUBJECT];ICFDAI;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02102004;18:23; [MARKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];9999999999999;
[BODY START]
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S30;E12- E17;7777777777777;989,17;5656,48;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S30;E12- E18;7777777777777;89,17;656,48;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S31;E12- E17;7777777777777;33,51;5674,44;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S32;E12- E17;7777777777777;12345678,29;123456789,11;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S41;E12- E17;7777777777777;98999,92;98999,54;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S30;E12- E17;2555555555552;333,64;3336,35;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S30;E12-E18;
2555555555552;0,00;0,00;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S31; E12- E17;2555555555552;0,61;0,19;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S32; E12- E17;2555555555552;678,83;679,93;
01092007 05:00;01102007 04:00;9999999999999;2;1;0,96581178;67;3.0;S41; E12- E17;2555555555552;9,85;2524,87;
[BODY END]
[NUMBER OF LINES IN BODY];10;
6.15 Feedbackbericht (FEEDBACK)
Dit berichtformaat wordt gebruikt iedere keer dat een DNB feedback moet versturen naar Fluxys als reactie op van Fluxys ontvangen informatie. Dit bericht bevat weinig of geen gegevens (behalve de aanduiding van de maand en het GOS).
Het feedbackbericht (FEEDBACK) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Het veld SUBJECT bevat de tekenreeks "FEEDBACK" gevolgd door het versienummer (“2.0.0”).
De body bevat één enkele regel voor de volledige maand. De periode is altijd een gasmaand.
Een regel bestaat uit zes kolommen:
Kolom nr. | Naam | Beschrijving | Voorbeeld | Commentaar |
1. | DATE_FROM | Eerste uur van de periode (inbegrepen) | 01092004 05:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
2. | DATE_TO | Laatste uur van de periode (inbegrepen) | 01102004 04:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
3. | ARS_EAN- GSRN | Het EAN-GSRN - nummer van het GOS | 88888888888888 8888 | |
4. | GRF_VERSIO N | Versienummer van de GRF | 2 | |
5. | ICFDAI_VERSI ON | Versienummer van de ICF en DAI | 1 | FACULTATIEF. Alleen ingevuld als het gaat om feedback op de ICF - DAI. |
6. | FEEDBACK | RecalculateGRF |
1. Een kolom voor het eerste gasuur van de periode, in het formaat DDMMYYYY HH24:00. Het beginuur is begrepen in de periode.
2. Een kolom voor het laatste gasuur van de periode, in het formaat DDMMYYYY HH24:00. Het einduur is begrepen in de periode.
3. Het EAN-GSRN-nummer van het betrokken GOS.
4. Het versienummer van de GRF, ook lusnummer genoemd.
5. Voor elk GRF-nummer begint het versienummer van de ICF-DAI opnieuw met 1.
6. De feedback kan één van de volgende waarden aannemen:
- RecalculateGRF
- AcceptAlloc
- CancelAccept
- CloseAlloc
Voorbeeld van een feedbackbericht met fictieve EAN-nummers:
[SUBJECT];FEEDBACK;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02102004;18:23; [MARKET];27; [TO];5499775125103; [FROM];9999999999999; [MS];8888888888888;
[BODY START]
01092007 05:00;01102007 04:00;123456789012345678;2;1;AcceptAlloc; [BODY END]
[NUMBER OF LINES IN BODY];1;
6.16 Broadcastbericht (BROADCAST)
Dit berichtformaat wordt gebruikt iedere keer dat Fluxys informatie over de statuswijziging van het proces verstuurt naar alle DNB’s (die tijdens een specifieke maand op een bepaald GOS actief zijn): dat is onder meer het geval telkens als Fluxys in een processtadium het laatste bericht van alle DNB’s ontvangt, of als Fluxys ervoor kiest een extra lusbewerking uit te voeren om de GRF te berekenen.
Het broadcastbericht (BROADCAST) wordt in versie 2.0.0 als volgt gespecificeerd:
- een koptekst (header), zoals gedefinieerd in 6.2.1 Header
- een hoofdtekst (body) van het bericht, zoals gedefinieerd in 6.2.2 Hoofdtekst
- een voettekst (footer), zoals gedefinieerd in 6.2.3 Footer
Dit berichttype wordt gebruikt om de DNB’s te waarschuwen voor een statuswijziging van het proces bij Fluxys. Dat is met name het geval wanneer Fluxys het laatste bericht ontvangt van alle berichten die verwacht worden van alle DNB’s die voor een specifieke maand op een bepaald GOS actief zijn.
Het veld SUBJECT bevat de tekenreeks "BROADCAST" gevolgd door het versienummer (“2.0.0”).
De body bevat één enkele regel voor de volledige maand. De periode is altijd een gasmaand.
Een record bestaat uit zes kolommen:
Kolom nr. | Naam | Beschrijving | Voorbeeld | Commentaar |
1. | DATE_FROM | Eerste uur van de periode (inbegrepen) | 01092004 05:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
2. | DATE_TO | Laatste uur van de periode (inbegrepen) | 01102004 04:00 | Datum wordt gegeven volgens formaat DDMMYYYY HH24:00; |
3. | ARS_EAN- GSRN | Het EAN-GSRN - nummer van het GOS | 88888888888888 8888 | |
4. | GRF_VERSIO N | Versienummer van de GRF | 2 | |
5. | DATETIME Incoming Message | Datum en uur waarop Fluxys het inkomende bericht ontvangt | 21102004 14:31 | |
6. | SUBJECT Incoming message | Onderwerp van het inkomende bericht | FEEDBACK | FEEDBACK of XXXXXX |
7. | NEW STATE | Nieuwe status van het allocatieproces voor deze maand en dit GOS | New GRF Requested | Mogelijke waarden: - All Allocations Received - New GRF Requested - All AcceptAlloc Received - Accepted - All CloseAlloc Received - Closed |
Voorbeeld van een broadcastbericht met fictieve EAN-nummers:
[SUBJECT];BROADCAST;2.0.0; [TIME ZONE];+0100;
[CREATED ON];02102004;18:23; [MARKET];27; [TO];9999999999999; [FROM];5499775125103; [MS];8888888888888;
[BODY START]
01092007 05:00;01102007 04:00;123456789012345678;1;21102004
14:31;FEEDBACK;Accepted; [BODY END]
[NUMBER OF LINES IN BODY];1;
6.17 ARS Shipper Combinations
Het bericht ARS Shipper Combinations heeft niet dezelfde structuur als de andere berichten, door het feit dat het in Excelvorm doorgegeven wordt.
De specificatie van het bericht ARS Shipper Combinations, versie 2.0.0, ziet eruit als volgt:
o Eerste lijn: ARS Shipper Combinatie
o Tweede lijn: Period, is de periode gedurende dewelke de combinatie wordt doorgegeven, en is altijd gelijk aan een maand.
o Derde lijn: beschrijving van de volgende lijnen
o Volgende lijnen: elke lijn bevat voor een bepaald GOS de onderschrijvingsperiode van transportcapaciteit bij Fluxys voor een bepaalde bevrachter.
Kolom N° | Naam | Beschrijving | Voorbeeld | Commentaar | ||
A | ARS Ean | Het EAN-GSRN - nummer van het GOS | 000000000000000000 | |||
B | ARS Name | Naam van het GOS zoals gekend bij Fluxys | IVERLEK (GOS) | DILBEEK | ||
C | Shipper Ean | De EAN-GLN nummer van de bevrachter | 8888888888888 | |||
D | Shipper Name | Naam van de bevrachter zoals gekend bij Fluxys | SHIPPER1 | |||
E | Start Date | Startdatum van de combinatie GOS- Bevrachter (incluis) | 01/02/2010 | Datum wordt volgens DDMMYYYY | gegeven formaat | |
F | End Date | Einddatum van de combinatie GOS- Bevrachter (incluis) | 28/02/2010 | Datum wordt volgens DDMMYYYY | gegeven formaat | |
Voorbeeld van een ARS Shipper Combinations bericht met fictieve EAN-nummers :
ARS Shipper Combinations
Period: 01/02/2010 - 28/02/2010
Ars Ean | Ars Name | Shipper Ean | Shipper Name | Start Date |
541460900000000108 | ALG AMAY (GOS) | 1111111111111 | SHIPPER1 | 01/02/2010 |
541460900000000108 | ALG AMAY (GOS) | 2222222222222 | SHIPPER2 | 01/02/2010 |
541460900000000108 | ALG AMAY (GOS) | 3333333333333 | SHIPPER3 | 01/02/2010 |
541460900000000108 | ALG AMAY (GOS) | 4444444444444 | SHIPPER4 | 01/02/2010 |
7 Overzichtstabel van de tijdsbeperkingen
7.1 Berichtenuitwisseling
In de onderstaande tabel staat de frequentie waarmee bericht worden uitgewisseld, alsook een indicatieve timing.
Proces operationeel evenwicht | Eenmaal per uur | |
Portfolio , clientswitch en productionswitch | – Een voorlopig bestand tussen drie en vijf werkdagen vóór het begin van de maand met correcties tot uiterlijk tien werkdagen na het einde van de maand. - Het gevalideerde bestand tegelijkertijd met de eerste maandelijkse allocatie op M + 14 (gegevens van de maand M). | |
Uurlijks uitgelezen RLP-metingen en lokale producties | Eenmaal per uur | |
Dagelijks uitgelezen RLP-metingen en lokale producties | Eenmaal per dag | |
Gevalideerde RLP-metingen en lokale producties | Eenmaal per maand, M+14wd | |
Niet-gevalideerde infeed-GCV | Eenmaal per maand, M/20+5wd, de gegevens van de 21e dag van de voorafgaande maand tot de 20e dag van de maand M | |
Gevalideerde infeed-GCV | Eenmaal per maand, M+10wd (gegevens van de maand M) | |
Tijdelijke KCF | Eenmaal per dag (gegevens van de voorafgaande dag) | |
Gevalideerde KCF | Eenmaal per maand, M+5wd (gegevens van de maand M) | |
Proces maandelijkse allocatie | Eenmaal per maand, start bij het begin van de volgende maand na transmissie van de gevalideerde KCF. | |
Allocation | - Veranderlijk aantal verzendingen - De verzendingsdatum is ook veranderlijk Zie 5.4.1 Termijnen en reactietijden | |
GRF | ||
ICF-DAI | ||
Feedback | ||
Zie ook:
- 3.4.2 Indicatieve timing voor “troubleshooting” van portfolio en clientswitch
Bijlage I: Woordenlijst
De volgende lijst bevat de begrippen die in de MIA gebruikt worden, samen met de verklaring ervan.
Allocation
= Engelse term voor “allocatie” zoals opgenomen in het Standard Aansluitingscontract (punt 3.17.5).
ARS: Aggregated Receiving Station
= Engelse term voor “GOS” (Geaggregeerd Ontvangstation) zoals gedefinieerd in het Standard Aansluitingscontract.
ARS-DGO combination
= Engelse term voor “GOS-DNB”-combinatie
Balancing allocation
= Engelse term voor “operationeel evenwicht” zoals opgenomen in het Standard Aansluitingscontract (punt 3.17.4).
Clientswitch
= het clientswitchbericht bevat informatie over de RLP-Afnamepunten.
DGO: Distribution Grid Operator
= Engelse term voor “DNB” zoals gedefinieerd in het Standard Aansluitingscontract.
EAN: European Article Number
= uniek numeriek veld dat dient om een marktpartij of toegangspunt eenduidig te identificeren. Zie EAN-GLN en EAN-GSRN.
EAN-GLN
= uniek numeriek veld met 13 posities dat dient om een marktpartij eenduidig te identificeren.
EAN-GSRN
= uniek numeriek veld met 18 posities dat dient om een toegangspunt eenduidig te identificeren.
Fault
= Engelse term voor “fout”
Faultmessage
= Engelse term voor “foutbericht”
Fout
= een fout (in het Engels: fault) omvat de begrippen “error” (fout) en “warning” (waarschuwing). In geval van een error wordt een gedeelte van het bericht geweigerd, terwijl er bij een warning niets geweigerd wordt. De aanleiding van een fout kan het niet respecteren van de gespecificeerde formaten zijn, evenals een inconsistentie met bepaalde master data, met timing of met rechten om master data te veranderen.
Foutbericht
= bericht dat Fluxys naar de DNB verstuurt als één of meer fouten in het bericht van de DNB staan.
Frozen berichtspecificatie
= de berichtspecificatie voor de gemengde DNB’s in de overgangsfase (MIA 1), zoals overeengekomen tussen Fluxys en de gemengde DNB’s. Deze berichtspecificatie berust op
het formaat dat gebruikt wordt tussen de DNB en andere marktpartijen, maar werd “bevroren”, wat betekent dat de berichtspecificatie niet gewijzigd wordt voor elke nieuwe versie van het formaat tussen de gemengde DNB’s en de andere marktpartijen.
Deze specificatie is achterwege gelaten in de versie 2.0.0 van de MIA.
GCV: Gross Calorific Value
= Engelse term voor “CBW” zoals gedefinieerd in het Standard Aansluitingscontract.
GOL: Gas On Line
= aanduiding van de uurlijks telegelezen RLP-Afnamepunten.
GOS-DNB-combinatie
= deze combinatie geeft aan dat een DNB x actief is op een GOS y. Meerdere DNB’s kunnen actief zijn op een GOS, en één DNB kan actief zijn op meerdere GOS’en.
GRF: GOS-residufactor
= de GOS-residufactor is de factor waarmee het verschil tussen de infeed en de som van de DNB-allocaties naar evenredigheid (pro rata) wordt verdeeld over het SLP-verbruik.
KCF: klimaatcorrectiefactor
= factor die maatgevend is voor de invloed van de gemeten temperaturen op het gasverbruik, zoals gedefinieerd per SLP-type.
= SLP real / SLP stand
KMI: Koninklijk Meteorologisch Instituut
= de partij die als taak heeft de temperaturen door te geven waarmee de KCF wordt berekend.
LPR: Local production / Lokale Productie
= Productie faciliteit die gas (b.v.. biomethaan) op het net van de DNB injecteert.
M+x
= x werkdagen vóór het einde van de maand M. Zo komt M+10 voor januari 2006 bijvoorbeeld overeen met 14 februari.
M-x
= x werkdagen vóór het begin van de maand M. Zo komt M-3 voor januari 2006 bijvoorbeeld overeen met 28 december 2005.
Master data
= niet-numerieke stamgegevens die Fluxys gebruikt om een allocatie te berekenen. De “master data” omvat informatie over het GOS, informatie over de DNB, combinaties tussen GOS-DNB, combinaties tussen GOS-bevrachter, lastprofielen, informatie over de DNB- Eindafnemer en over de portfolio.
Meting
= de meetwaarden van de RLP-Afnamepunten worden respectievelijk uurlijks of dagelijks naar Fluxys verstuurd.
MIA: Message Interchange Agreement
= het document – bijlage 3 van het Standaard Aansluitingscontract – met de doelstellingen, reactietijden, sequentiediagrammen, het berichtprotocol en de berichtspecificaties voor het operationele evenwicht, de allocatie, de infeed en de calorische bovenwaarde.
Portfolio
Een portfoliobericht bevat voor een DNB, voor elk GOS waarop de DNB actief is, de geschatte hoeveelheden gas (kWh) die de bevrachters in een “standaardjaar” (dat wil zeggen
met normale temperaturen) voor de SLP-profielen afnemen. Deze portfoliowaarden worden met de SLP factor vermenigvuldigd om een reëel beeld van de consumptie te krijgen.
Productionswitch
= het productionswitchbericht bevat informatie over de lokale producties
RLP supply point of TM Client: "telemetered client" / telegelezen DNB-Eindafnemer
= Engelse term voor “RLP-Afnamepunt” zoals gedefinieerd in het Standard Aansluitingscontract.
RLP: Real Load Profile In het Nederlands: reëel lastprofiel. Meetmodel van een afnamepunt dat uitgerust is met een meetinstallatie die op afstand wordt uitgelezen (telelezing).
SLP consumptie
= geschat gasverbruik per GOS voor de SLP-Afnamepunten
SLP supply point
= Engelse term voor “SLP-Afnamepunt” zoals gedefinieerd in het Standard Aansluitingscontract.
SLP: Synthetic Load Profile
= gemodelleerd meetmodel van een DNB-Eindafnemer die niet is uitgerust met een op afstand uitgelezen meetinstallatie. Het synthetische lastprofiel heeft als doel de distributie af te stemmen op het verbruik in de tijd.
SLPCF: SLP-correctiefactor
= deze factor wordt toegepast om de GRF te berekenen.
SLP-profiel
= in een SLP-profiel worden de SLP-Afnamepunten gegroepeerd die hetzelfde verbruiksprofiel delen. Er bestaan 3 SLP profielen:
SLP31 (kleine industriële DNB-Eindafnemers) SLP32 (grote industriële DNB-Eindafnemers) SLP41 (residentiële DNB-Eindafnemers)
Supplier
= Engelse term voor “leverancier” zoals gedefinieerd in het Standard Aansluitingscontract.
SYC: Standard Year Consumption
= synoniem met portfolio. In het Nederlands ook SJV (standaardjaarverbruik) genoemd.
Temperatuur
= de temperatuur voor een specifiek uur kan vier statussen hebben. In oplopende volgorde van belang zijn deze statussen: standard, forecast, current en observed.
TGU: Transport Grid User of Shipper
= Engelse term voor bevrachter, in het Nederlands ook afgekort tot VNG (vervoersnetgebruiker) zoals gedefinieerd in het Standard Aansluitingscontract.
Bijlage II: Lijst met foutberichten
Lijst met foutberichten
De volgende tabel geeft de foutcode (faultcode) en de foutbeschrijving (fault description) voor de FLXFAU-berichten:
Code | Beschrijving | Beschrijving | Opmerking | |||
1 | Format Fault | Foutief Formaat | In MIA 1 Formaten gegeven | worden bijna uitsluitend op | alle dit | foutieve niveau |
1.1 | Format Fault. Invalid Content | Foutief Formaat. niet correct. | Inhoud | |||
1.1.1 | Format Fault. Invalid Content. Empty field | Foutief Formaat. Inhoud niet correct. Xxxx xxxx | ||||
1.1.2 | Format Fault. Invalid Content. Control character in field | Xxxxxxx Xxxxxxx. niet correct. character in veld | Inhoud Control | |||
1.1.3 | Format Fault. Invalid Content. Invalid type | Foutief Formaat. Inhoud niet correct. Type niet correct. | ||||
1.1.4 | Format Fault. Invalid Content. Invalid value for field | Foutief Formaat. Inhoud niet correct. Waarde niet correct voor veld | Voor vast verwachte waardes (bv. KWH, A+, PCT…) | |||
1.1.4.1 | Format Fault. Invalid Content. Invalid Validity Code | Foutief Formaat. niet Geldigheidscode correct. | Inhoud correct. niet | - Hmetering / Dmetering: het gedetailleerde foutformaat voor “E”, “M” en “?” wordt verstuurd met MIA 1 3 | ||
1.1.4.1.1 | Format Fault. Invalid Content. Invalid Validity Code. Unknown code | Foutief Formaat. Inhoud niet correct. Geldigheidscode niet correct. Code onbekend | ||||
1.1.4.2 | Format Fault. Invalid Content. Invalid Load Profile | Xxxxxxx Xxxxxxx. niet correct. Lastprofiel | Inhoud Ongeldig | |||
1.1.4.2.1 | Format Fault. Invalid Content. Invalid Synthetic Load Profile | Xxxxxxx Xxxxxxx. Inhoud niet correct. Ongeldig SLP | ||||
1.1.4.3.1 | Format Fault. Invalid Content. Invalid Switching category. | Foutief Formaat. Inhoud niet correct. Ongeldige Switching categorie | ||||
1.1.4.3.2 | Format Fault. Invalid Content. Invalid Switching category. Empty Field | Foutief Formaat. Inhoud niet correct. Ongeldige Switching categorie, leeg veld | ||||
1.1.4.3.3 | Format Fault. Invalid Content. Invalid Switching category. Invalid SLP / Switching category combination. | Foutief Formaat. Inhoud niet correct. Ongeldige combinatie SLP / switching categorie | ||||
1.1.5 | Format Fault. Invalid Content. Invalid Number | Foutief Formaat. Inhoud niet correct. Getal niet correct | ||||
1.1.5.1 | Format Fault. Invalid Content. Invalid Number. Too many decimals | Foutief Formaat. Inhoud niet correct. Getal niet correct. Te veel cijfers na | ||||
3 geeft in tegenstelling tot “M” en “E” aanleiding tot een warning.
de komma | |||||
1.1.5.2 | Format Fault. Invalid Content. Invalid Number. Too many integers | Foutief Formaat. Inhoud niet correct. Getal niet correct. Te veel gehele getallen | |||
1.1.5.3 | Format Fault. Content. Invalid Wrong decimal sign | Invalid Number. | Foutief Formaat. Inhoud niet correct. Getal niet correct. Teken van decimaal niet correct | ||
1.1.5.4 | Format Fault. Content. Invalid Negative number | Invalid Number. | Foutief Formaat. Inhoud niet correct. Getal niet correct. Negatief getal | Voor de allocatieberichten worden negatieve waarden niet genegeerd | |
1.1.6 | Format Fault. Invalid Content. Invalid EAN code | Foutief Formaat. Inhoud niet correct. EAN code niet correct | |||
1.1.6.1 | Format Fault. Invalid Content. Invalid EAN code. Too many characters | Xxxxxxx Xxxxxxx. Inhoud niet correct. EAN code niet correct. Te veel karakters | |||
1.1.6.2 | Format Fault. Invalid Content. Invalid EAN code. Too little characters | Xxxxxxx Xxxxxxx. Inhoud niet correct. EAN code niet correct. Te weinig karakters | |||
1.1.6.3 | Format Fault. Invalid Content. Invalid EAN code. Invalid character(s) | Xxxxxxx Xxxxxxx. Inhoud niet correct. EAN code niet correct. Karakter(s) niet correct | |||
1.1.7 | Format Fault. Invalid Content. Empty Message | Foutief Formaat. niet correct. | Inhoud | ||
1.1.8 | Format Fault. Invalid Content. [MS] field invalid | Foutief Formaat. Inhoud niet correct. [MS] xxxx niet correct | - Tag ontbreekt, tag ongeldig, letters in EAN van DNB, te veel / te weinig tekens - Leeg [MS] xxxx zal ook deze code krijgen voor versie 8/3, in plaats van 1.1.1.1 | ||
1.1.9 | Format Fault. Missing Field | Foutief Formaat. Inhoud niet correct. Veld ontbreekt | |||
1.1.9.1 | Format Fault. Missing Field: BODY - Missing Body Start | Foutief Formaat. Inhoud BODY niet correct. Veld [Body Start] ontbreekt | |||
1.1.9.2 | Format Fault. Missing Field: BODY - Missing Body End | Foutief Formaat. Inhoud BODY niet correct. Veld [Body End] ontbreekt | |||
1.1.9.3 | Format Fault. Missing Field: BODY - Missing Number of Lines | Xxxxxxx Xxxxxxx. Inhoud BODY niet correct. Veld [Number of Lines] ontbreekt | |||
1.1.9.4 | Format Fault. Missing Field: HEADER - Missing Subject | Foutief Formaat. Inhoud HEADER niet correct. Veld [Subject] ontbreekt | |||
1.1.9.5 | Format Fault. Missing Field: HEADER - Missing TimeZone | Xxxxxxx Xxxxxxx. Inhoud HEADER niet correct. Veld [TimeZone] ontbreekt | |||
1.1.9.6 | Format Fault. Missing Field: HEADER - Missing Create On | Xxxxxxx Xxxxxxx. Inhoud HEADER niet correct. Veld [Create On] ontbreekt | |||
1.1.9.7 | Format Fault. Missing Field: HEADER - Missing Market | Xxxxxxx Xxxxxxx. Inhoud HEADER niet correct. Veld [Market] ontbreekt | |||
1.1.9.8 | Format Fault. Missing Field: HEADER - Missing To | Xxxxxxx Xxxxxxx. Inhoud HEADER niet correct. Veld [To] ontbreekt | |||
1.1.9.9 | Format Fault. Missing Field: | Xxxxxxx Xxxxxxx. | Inhoud | ||
HEADER - Missing From | HEADER niet correct. Veld [From] ontbreekt | ||||||
1.1.9.10 | Format Fault. Missing Field: HEADER - Missing Body MS | Xxxxxxx Xxxxxxx. Inhoud HEADER niet correct. Veld [MS] ontbreekt | |||||
1.2 | Format Fault. separator | Wrong | field | Xxxxxxx Xxxxxxx. Veld scheiding onjuist | |||
1.3 | Format tag | Fault. | Non-existing | Foutief Formaat. Onbestaande tag | |||
1.4 | Format Fault. Wrong number of fields in line | Foutief Formaat. Aantal velden in een lijn niet correct | |||||
1.5 | Format Fault. Wrong number of lines in message | Xxxxxxx Xxxxxxx. Aantal lijnen in een bericht niet correct | |||||
1.6 | Format Fault. Indication | Invalid | Time | Foutief Formaat. Ongeldige tijdsindicatie | Het gedetailleerd foutief formaat, met zijn ondercode, wordt voor MIA 1 gezonden. | ||
1.6.1 | Format Fault. Invalid Time Indication. Overlapping | Foutief Formaat. Ongeldige tijdsindicatie. Overlapping | De check voor deze code en daarmee samenhangende subcodes voor de 8/3 release leiden enkel tot het verzenden van een waarschuwing. De laastste lijn in deze code zal voor de 8/3 release beschouwd worden als definitief. | ||||
1.6.1.1 | Format Fault. Indication. Measurements client and time | Invalid Time Overlap. for same | Xxxxxxx Xxxxxxx. Ongeldige tijdsindicatie. Overlapping. Metingen voor zelfde RLP afnamepunt en periode | Metingen verschijnen een aantal keer voor dezelfde RLP afnamepunt en periode | |||
1.6.1.2 | Format Fault. Invalid Time Indication. Overlap. Information for same client and time | Xxxxxxx Xxxxxxx. Ongeldige tijdsindicatie. Overlapping. Informatie voor zelfde RLP afnamepunt en periode | Informatie verschijnt voor dezelfde RLP periode . | een aantal afnamepunt | keer en | ||
1.6.1.3 | Format Fault. Invalid Time Indication. Overlap. SYC for same portfolio and time | Xxxxxxx Xxxxxxx. Ongeldige tijdsindicatie. Overlapping. SJV voor zelfde portfolio en periode | De waarde van het SJV verschijnt meermaals voor dezelfde portfoliocombinatie (SLP-profiel – VNG - GOS – DNB) en dezelfde tijdsperiode. | ||||
1.6.1.4 | Format Fault. Invalid Time Indication. Overlap. Allocation record for same day | Xxxxxxx Xxxxxxx. Ongeldige tijdsaanduiding. Overlapping. Allocatierecord voor dezelfde dag | Allocatierecord verschijnt meermaals voor hetzelfde lastprofiel en dezelfde tijdsperiode. | ||||
1.6.3 | Format Fault. Invalid Time Indication. At least one hour is no gasday delimiter | Foutief Formaat. Ongeldige tijdsindicatie. Minstens één uur is geen gasdaglimiet | - Dmetering / Allocatie / Portfolio: deze code wordt gegeven als het begin- of einduur geen gasdaglimiet is - Allocatie / Portfolio: deze code wordt gegeven als de einddatum vóór de begindatum valt | ||||
1.6.3.1 | Format Fault. Invalid Time Indication. Hour is no gasday delimiter. Hour is not first hour gasday | Foutief Formaat. Ongeldige tijdsaanduiding: geen gasdaglimiet. Het uur is niet het eerste uur van de gasdag | - Clientswitch: deze code wordt buiten de normale gevallen gegeven als het uur van de begindatum geen gasdaglimiet is | ||||
1.6.3.2 | Format Fault. Invalid Time Indication. Hour is no gasday delimiter. Hour is not last hour gasday | Foutief Formaat. Ongeldige tijdsaanduiding: geen gasdaglimiet. Het uur is niet het laatste uur van de gasdag | - Clientswitch: deze code wordt buiten de normale gevallen gegeven als het uur van de einddatum geen gasdaglimiet is | ||||
1.6.4 | Format Fault. Invalid Time Indication. Period exceeds borders of gasmonth | Foutief Formaat. Ongeldige tijdsindicatie. Periode overschrijdt de limieten van gasmaand | - Clientswitch/Portfolio: deze code wordt buiten de normale gevallen ook gegeven als een gasdag in het bericht niet valt in de gasmaand die verband houdt met dit | ||||
bericht. - Clientswitch: deze code wordt buiten de normale gevallen ook gegeven als de einddatum vóór de begindatum valt | |||
1.6.5 | Format Fault. Invalid Time Indication. Start datetime after end datetime | Xxxxxxx Xxxxxxx. Ongeldige tijdsindicatie. Tijd van startdatum na tijd van einddatum | - Dmetering: deze code wordt gegeven als de einddatum vóór de begindatum valt |
2 | Inconsistency | Inconsequentie | |
2.1 | Inconsistency With Master Data | Inconsequentie met Master Data | |
2.1.1 | Inconsistency With Master Data. Unknown EAN | Inconsequentie met Master Data. Onbekend EAN voor VNG | |
2.1.1.1 | Inconsistency With Master Data. Unknown EAN for TGU | Inconsequentie met Master Data. Onbekend EAN voor VNG | |
2.1.1.2 | Inconsistency With Master Data. Unknown EAN for ARS | Inconsequentie met Master Data. Onbekend EAN voor GOS | |
2.1.1.3 | Inconsistency With Master Data. Unknown EAN for DGO | Inconsequentie met Master Data. Onbekend EAN voor DNB | |
2.1.1.4 | Inconsistency With Master Data. Unknown EAN for client | Inconsequentie met Master Data. Onbekend EAN voor RLP afnamepunt | |
2.1.1.4.1 | Inconsistency With Master Data. Unknown EAN. New client has been created | Inconsequentie met Master Data. Onbekend EAN. Nieuw RLP afnamepunt is gecreëerd | |
2.1.1.7 | Inconsistency With Master Data. Unknown EAN for production point. | Inconsequentie met Master Data. Onbekend EAN voor lokale productie | Fault is also given when the EAN code is the code of an RSP or when a supply point is found in a Productionswitch. |
2.1.2 | Inconsistency With Master Data. Party is not active for at least one day in period | Inconsequentie met Master Data. Partij is minstens één dag niet actief in de periode | |
2.1.2.1 | Inconsistency With Master Data. TGU is not active for at least one day in period | Inconsequentie met Master Data. VNG is minstens één dag niet actief in de periode | - Clientswitch en productionswitch: deze code wordt ook gebruikt als het EAN van de VNG niet bestaat |
2.1.2.2 | Inconsistency With Master Data. ARS is not active for at least one day in period | Inconsequentie met Master Data. GOS is minstens één dag niet actief in de periode | - Clientswitch en productionswitch: deze code wordt ook gebruikt als het EAN van het GOS niet bestaat |
2.1.2.3 | Inconsistency With Master Data. DGO is not active for at least one day in period | Inconsequentie met Master Data. DNB is minstens één dag niet actief in de periode | |
2.1.2.4 | Inconsistency With Master Data. Client is not active for at least one day in period | Inconsequentie met Master Data. DNB-Eindafnemer is minstens één dag niet actief in de periode | Niet actief betekent dat de DNB- Eindafnemer of lokale productie niet opgenomen is in het laatst ontvangen clientswitchbericht of productionswitchbericht. Deze check en dit foutbericht worden niet geïmplementeerd in de 8/3 release |
2.1.2.5. | Inconsistency With Master Data. Client is closed for at least one day in period | Inconsequentie met Master Data. DNB-Eindafnemer is minstens één dag gesloten in de periode | Gesloten betekent dat het RLP- Afnamepunt of lokale productie manueel werd afgesloten, door de einddatum aan te passen |
2.1.3 | Inconsistency With Master Data. Invalid Combination | Inconsequentie met Master Data. Combinatie niet correct. |
2.1.3.1 | Inconsistency With Master Data. Invalid Combination. TGU has no contract on ARS | Inconsequentie met Master Data. Combinatie niet correct. De VNG heeft geen contract op het GOS | Het hoogste niveau van detail beschikbaar voor 8/3. Deze foutmelding zal na 1/10/2012 niet meer voorkomen, door het wegvallen van de allocation agreements. |
2.1.3.1.1 | Inconsistency With Master Data. Invalid Combination. TGU never had a contract on ARS | Inconsequentie met Master Data. Combinatie niet correct. De VNG heeft nooit een contract gehad op het GOS | Deze foutmelding zal na 1/10/2012 niet meer voorkomen, door het wegvallen van de allocation agreements. |
2.1.3.1.2 | Inconsistency With Master Data. Invalid Combination. TGU has no contract on ARS for at least one day in period | Inconsequentie met Master Data. Combinatie niet correct. De VNG heeft voor minstens één dag in de periode geen contract op het GOS | Deze foutmelding zal na 1/10/2012 niet meer voorkomen, door het wegvallen van de allocation agreements. |
2.1.3.2 | Inconsistency With Master Data. Invalid Combination. DGO is not active on ARS | Inconsequentie met Master Data. Combinatie niet correct. De DNB is niet actief op het GOS. | |
2.1.3.2.1 | Inconsistency With Master Data. Invalid Combination. DGO never was active on ARS | Inconsequentie met Master Data. Combinatie niet correct. De DNB is niet actief op het GOS | - Veld MS: deze code wordt ook gebruikt als het EAN van de DNB niet bestaat |
2.1.3.2.2 | Inconsistency With Master Data. Invalid Combination. DGO is not active on ARS for at least one day in period | Inconsequentie met Master Data. Combinatie niet correct. De DNB is minstens één dag in de periode niet actief op het GOS | |
2.1.4 | Inconsistency With Master Data. No portfolio messages are accepted for the ARS. | Inconsequentie met Master Data. Er worden geen portfolioberichten voor het GOS aanvaard. | |
2.1.5 | Inconsistency With Master Data. No S31 S32 S41 code in allocationmessages are accepted for the ARS. | Inconsequentie met Master Data. Er worden geen codes S31, S32 en S41 in het allocatiebericht voor dit GOS aanvaard. | |
2.2 | Inconsistency With Timing | Inconsequentie met Timing | |
2.2.1 | Inconsistency With Timing. Message Too late | Inconsequentie met Timing. Bericht te laat | |
2.2.2 | Inconsistency With Timing. Period has been closed | Inconsequentie met Timing. Periode is afgesloten | De check voor deze code en daarmee samenhangende subcodes is niet aanwezig in de 8/3 release |
2.2.2.1 | Inconsistency With Timing Period has been closed. GRFv has been sent | Inconsequentie met Timing. Periode is afgesloten. GRFv is verzonden | |
2.2.2.2 | Inconsistency With Timing Period has been closed Final GRFd has been sent | Inconsequentie met Timing. Periode is afgesloten. Finaal GRFd is verzonden | |
2.2.3 | Inconsistency With Timing. Status lower than earlier received value | Inconsequentie met Timing. Lager Status is lager dan eerder ontvangen waarde | - Dmetering: de status van het laatst ontvangen bericht is lager dan die van eerder ontvangen berichten. |
2.2.4 | Inconsistency With Timing. Message Too soon | Inconsequentie met Timing. Bericht te vroeg | Xxxxxxxxx wanneer Xxxxxxxxx- berichten “te vroeg” binnenkomen, dat wil zeggen vóór of tijdens het uur waarop het bericht betrekking heeft. |
2.2.5 | Inconsistency - unknown allocation period | Inconsequentie: Allocatie periode is ongekend |