UMIG Marktprocessen Processus de marché. Business Requirements Structure Rectification

Transcriptie

1 ATRIAS Market Processes UMIG Marktprocessen Processus de marché Business Requirements Structure Versie 6.5 / Version 6.5 Voor implementatie / Pour implémentation UMIG - BR - ST v6.5

2 1 DOCUMENT VERSIES - VERSIONS DU DOCUMENT... 5 Versieoverzicht Gestion des versions... 5 Referenties Références ALGEMEENHEDEN - GÉNÉRALITÉS... 7 Definities Définitions Inbound Rectificaties s Inbound Outbound Rectificaties s outbound Spontane Rectificaties rectifications spontanées... 9 Rectificatie principes Principes de rectification Partieel netting - Netting partiel Einde van een rectificatie fin d une rectification Envelop Enveloppe Catalogus rectificatiecodes - Catalogue codes de rectifications Rectificatie van FEE, PSO en TRC Rectificaiton de FEE, PSO et TRC Toegelaten Rectificatieperiode Période de Rectificaiton permise CONTEXT CONTEXTE Scope Begrippen en definities - Concepts et définitions Procesverloop - Déroulement de la procédure REQUEST REQUEST RECTIFICATION Proces Definitie - Définition du Proces Procesverloop - Déroulement de la procedure Procesomschrijving - Description des procédures HANDLE RECTIFICATION PROCESS (GLOBAL) Proces Definitie - Définition du Proces Procesomschrijving - Déroulement de la procedure HANDLE RECTIFICATION INBOUND UMIG - BR - ST v6.5 2/76

3 Proces definitie - Définition du Proces Procesverloop - Déroulement de la procédure Request Approval to Impacted Party Proces definitie Définition du Proces Procesverloop - Déroulement de la procédure Procesomschrijving Description des procédures Uitzonderingen/eigenheden - Exceptions / Caractéristiques Handle Rejection of Request Process Definitie- Définition du Proces Procesverloop - Déroulement de la procédure Procesomschrijving Description des procédures Handle Proces Definitie - Définition du Proces Procesverloop - Déroulement de la procédure Handle Undo Redo Handle Results HANDLE RECTIFICATION OUTBOUND Proces definitie - Définition du Proces ProceProcesverloop - Déroulement de la procédure Procecesomschrijving Description des procédures Uitzonderingen/eigenheden Exceptions/Caractéristiques Reden van Negative Closing Ticket Raisons de Negative Closing Ticket insturen van gecorrigeerde Business Master Data introduction des Business Master Data corrigés HANDLE SPONTANEOUS RECTIFICATION Procesverloop - Déroulement de la procédure Procesomschrijving Description des procédures Uitzonderingen/eigenheden Exceptions/Caractéristiques Rectificatie van de spontane rectificaties - de rectifications spontanées Reden van spontane rectificaties - Raison de rectifications spontanées UMIG - BR - ST v6.5 3/76

4 9 ROLLEN ROLES ANNEXES Rectificatie ingevolge betwisting ILC - suite à une contestation ILC Verandering van Asset met nood aan een UTIL-TS zonder wisselwerking met oude Time Slices - Changements d Asset avec besoin d un UTIL-TS sans interaction avec anciens TimeSlices Verandering van Asset met nood aan een UTIL-TS met wisselwerking met oude Time Slice- Changements d Asset avec besoin d un UTIL-TS avec interaction avec ancien TimeSlice Customer Switch in het verleden Customer Switch dans le passé Correctie van UTIL-TS in het verleden Correction d un UTIL-TS dans le passé Correctie van de TRC Correction du TRC Spontane Rectificatie Spontanée Inbound Rectificatie Inbound Cancel Process in het verleden (Mystery Switch) Mystery Switch na Start Access Mystery Switch na ILP waarbij de TMD wijziging kan worden teruggedraaid - Mystery Switch après ILP et la modification des TMD peut être annulée Mystery Switch na ILP waarbij de TMD wijziging niet kan worden teruggedraaid Customer Switch met verandering van opname-/communicatiefrequentie van maandelijks naar jaarlijks- Customer Switch avec changement de fréquence de relève / communication de mensuelle à annuelle Combined Switch met wisselwerking met oude TimeSlice - Combined Switch avec interaction avec ancien timeslice Rectificatie van een AMR d un AMR Wijziging kwartierwaarden zonder rectificatie modification des valeurs quart-horaires sans rectification Wijziging kwartierwaarden, dagaggregatie reeds uitgestuurd modification des valeurs quart-horaires après envoi de l aggrégation journalière Wijziging kwartierwaarden in een billingrelevant volume modification des valeurs quart-horaires d un volume billingrelevant Bundeling van Tickets Regroupement des Tickets TABELLEN & INDEXEN TABLES & INDEXES Begrippenlijst Glossaire Table of Figures UMIG - BR - ST v6.5 4/76

5 1 Document versies - Versions du document Versieoverzicht Gestion des versions Versie - Version Datum - Date Auteur Beschrijving - Description V1.0 22/02/2013 V1.1 30/03/2013 V2.0 30/04/2013 V3.0 30/06/2013 V3.1 28/2/2014 V3.2 31/7/2014 V3.3 30/06/2015 V /09/2015 V3.4 31/01/2016 V6.5 30/06/2016 Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Atrias MPP UMIG Project Team Eerste versie van de Business Requirement Première version du Business Requirement Versie 1.1 van de Business Requirement na integratie van de feedback aangeleverd door de Business Analisten en Subject Matter Experten van de UMIG werkgroepen Version 1.1 du Business Requirement après l intégration du feedback donnée par le Business Analystes et les Subject Matter Experts des groupes de travail UMIG Versie 2.0 van de Business Requirement na integratie van de feedback aangeleverd door de Business Analisten en Subject Matter Experten van de UMIG werkgroepen op de versie 1.1 Version 2.0 du Business Requirement après l intégration du feedback donnée par le Business Analystes et les Subject Matter Experts des groupes de travail UMIG sur la version 1.1 Version 3.0 voor consultatie Version 3.0 pour consultation Version 3.1 voor consultatie Version 3.1 pour consultation Version 3.2 voor consultatie Version 3.2 pour consultation Version 3.3 voor consultatie Version 3.3 pour consultation Version voor consultatie Version pour consultation Version 3.4 voor implementatie Version 3.4 pour implémentation Version 6.5 voor implementatie Version 6.5 pour implémentation UMIG - BR - ST v6.5 5/76

6 Referenties Références Referentie - Référence UMIG - GE - XD - 02 Introduction [1] UMIG BR - ST - 03 Preswitching [2] UMIG BR - ST - 04 Ex-Ante Tests [3] UMIG BR - ST - 04 Ex-Post Monitoring [4] UMIG - BR - ST Catalogue [5] UMIG BR - ST - 04 Exchanged information [6] UMIG BR - ST - 04 Timings [7] UMIG BR ST - 03 Initiate Request [8] UMIG - GE - XD - 01 Glossary [9] UMIG BR ME 02 Measure Process [10] UMIG BR ST 03 Handle Request [11] Omschrijving - Description Document dat een algemene introductie geeft van de marktprocessen en de globale concepten die gebruikt worden in de verschillende processen. Contient une introduction générale aux processus de marché et sur les concepts globaux utilisés dans les différents processus. Beschrijving van het proces van beschikbaarstelling van gegevens verbonden aan een toegangspunt aan een vragende partij. Document décrivant le processus de mise à disposition de données liées à un point d'accès à une partie demandeuse. Matrix van de volledige ex-ante testen voor de verschillende Structuring aanvragen. Deze testen worden in de processus Initiate Request uitgevoerd. Matrice de l'ensemble des tests ex-ante effectués pour les différentes demandes Structuring. Ces tests sont effectuées dans le processus Initiate Request. Matrix van de volledige ex-post monitoring per module en per label: regels, impact op de markt en gevolgen. Matrice de l'ensemble du monitoring ex-post effectué par module et par label : règles, impacts sur le marché et conséquences. Document met alle rectificatie codes en hun bepalingen (additionele velden, tests Level2) Document reprenant l'ensemble des codes de rectification ainsi que leurs spécificités (champs additionnels, tests Level2) Matrix van alle berichten en gegevens die worden uitgewisseld in het kader van de verschillende Structuring aanvragen. Matrice de l'ensemble des messages et des données échangées dans le cadre des différentes demandes Structuring. Matrix van alle timingregels die gelden in het kader van de verschillende Structuring aanvragen. Matrice de l'ensemble des règles de temps applicables dans le cadre des différentes demandes Structuring. Beschrijving van het proces van aanmaak en eerste behandeling van een Structuring aanvraag door de markt. Document décrivant le processus de création et de premier traitement d'une demande Structuring par le marché. Document waarin alle in de documentatie gebruikte begrippen worden beschreven die specifiek zijn aan de marktprocessen. Document qui décrit l'ensemble des termes, spécifiques aux processus de marché, utilisés dans la documentation. Inleidend document over het Measure proces, dat de doelstellingen en algemene beginselen van toepassing op de verschillende sub-processen beschrijft Document d introduction au processus Measure qui décrit l objectif de celui-ci ainsi que les principes généraux applicables aux différents sous-processus Beschrijving van het beheersproces van een Structuring aanvraag door de markt na de eerste behandeling van het proces Initiate Request. Document décrivant le processus de gestion d'une demande Structuring par le marché ayant subie le premier traitement du processus Initiate Request. UMIG - BR - ST v6.5 6/76

7 2 Algemeenheden - Généralités Definities Définitions Onder rectificatie in ruime zin wordt het proces begrepen waarbij een vermoeden van foutieve verbruiksgegevens of relationele (Business Master Data) of transactionele (Structure aanvragen) of technische gegevens (Technical Master Data) geëvalueerd en eventueel rechtgezet worden. Het domein "Rectificatie" voorziet in gestructureerde processen om afwijkingen te melden, op te volgen en op te lossen. Er wordt een onderscheid gemaakt tussen drie types situaties : Inbound Rectificaties: een Balance Supplier is zich bewust van een afwijking of een fout begaan door een andere marktpartij of hemzelf (bv. Mystery Switch) en wenst dit gecorrigeerd te zien; Outbound Rectificaties: een DNB is zich bewust van een afwijking of een fout begaan door een Balance Supplier en wenst dit gecorrigeerd te zien; Spontane Rectificaties: een DNB is zich bewust van een fout die zij heeft begaan en verbetert dit Inbound Rectificaties s Inbound Aan inbound rectificaties zal steeds de module Request Request voorafgaan. Er wordt gesproken van inbound rectificaties in volgende gevallen : 1. Annulering van een effectieve module in het verleden door de Balance Supplier die de Initiator was van deze module: uitsluitend voor Mystery Switches, een aanvraag van dit type kan niet meer dan één module voor contractregistratie terug gaan (het is bijv. niet mogelijk om een Mystery Switch te annuleren indien er in tussentijd een andere module van Start Access of Initiatiate Local Production effectief is geweest, maar het zal wel mogelijk zijn om over meer dan één module Update Technical Master Data terug te gaan) of tot 37 maanden in het verleden (laatste reconciliatierun). Dit type aanvraag vereist het akkoord van de partijen die eventueel getroffen worden door de annulering van de module; 2. Annulering van een (al of niet effectieve) module door de geïmpacteerde Balance Supplier 1 (dit wil zeggen die niet de initiafnemer was van de module die hij wil annuleren): uitsluitend voor Mystery Switches, een aanvraag van dit type kan niet meer dan één module voor contractregistratie terug gaan (het is Par rectification en général est entendu, au sens large, le processus permettant d'évaluer une présomption d'erreur dans les données de consommation, les données relationnelles (Business Master Data), transactionnelles (demandes Structure) ou encore dans les données techniques (Technical Master Data) et éventuellement, d'y remédier. Le domaine "" prévoit des processus structurés pour rapporter les anomalies, les suivre et les résoudre. On distingue trois types de situations: Inbound: un Balance Supplier se rend compte d une anomalie ou d une erreur commise par une autre partie de marché ou luimême (par ex. Mystery Switch) et souhaite la voir corrigée Outbound: un GRD se rend compte d une anomalie ou d une erreur commise par une autre partie de marché et souhaite la voir corrigée Spontanée: un GRD se rend compte d une erreur qu il a commise et la corrige. Le module Request Request précède toujours la rectification Inbound. On parle de Inbound dans les quatre cas suivants : 1. Annulation d un module effectif dans le passé par le Balance Supplier initiateur de ce module : uniquement pour les mystery switches, une demande de ce type ne pourra pas aller plus loin qu un module d enregistrement de contrat dans le passé (p.ex. il ne sera pas possible d annuler un Mystery Switch si un autre module de Start Access ou Initiate Local Production a été effectif entre temps mais il sera par contre par exemple possible de passer au-dessus d un module d Update Technical Master Data) ou jusqu à 37 mois dans le passé (correspondant à la dernière réconciliation). Ce type de demande impliquera la demande d accord des parties éventuellement impactées si le module devait être annulé ; 2. Annulation d un module (effectif ou non) par le Balance Supplier impacté 2 (c est-à-dire n ayant pas lancé le module qu il demande d annuler) : uniquement pour les mystery switches, une demande de ce type ne pourra pas aller plus loin qu un module d enregistrement de contrat dans le passé 1 In de rest van dit document wordt met het begrip "Balance Supplier" zowel commerciële leveranciers, sociale leveranciers als DNB-leveranciers aangeduid. 2 Dans la suite de ce document, par Balance Supplier sera systématiquement compris fournisseur commercial, fournisseur social ou fournisseur GRD. UMIG - BR - ST v6.5 7/76

8 bijv. niet mogelijk om een Mystery Switch te annuleren indien er in tussentijd een andere module van Start Access of Initiatiate Local Production effectief is geweest, maar het zal wel mogelijk zijn om over meer dan één module Update Technical Master Data terug te gaan) of tot 37 maanden in het verleden (laatste reconciliatierun). Dit type aanvraag vereist het akkoord van de partijen die eventueel getroffen worden door de annulering van de module; 3. Door de Balance Supplier gevraagde rectificaties. Er zijn zes types rectificaties mogelijk: a. Metering; b. Relational Message (bijv. aanvaarding/verwerpingsbericht missing (Structuring/Settlement/Metering/Bill/Operate); c. Technical Message (Structuring); d. Switching (Structuring) (uitsluitend voor rectificaties die verband houden met een Start Access met betwisting); e. Settlement. f. Billing (uitsluitend voor Transaction Costs) In al de bovenstaande gevallen beperkt de module Request Request zich, net zoals alle andere NUI-modules, tot één toegangspunt. Het zal dus niet mogelijk zijn via deze module massaal rectificatieaanvragen te lanceren. Voordat een aanvraag tot rectificatie is gelanceerd door de Balance Supplier, moet deze zeker zijn dat de situatie niet opgelost kan worden door middel van beschikbare informatie in de Preswitching (zie referentiedocument [2]) of via de Portal. In het geval dat de beschikbare informatie niet voldoende is, kan een Request aanvraag worden gestart. De verwerking van inbound rectificaties vereist acties van de MPA en de DNB in sommige gevallen. Er wordt gebruikgemaakt van zogenaamde tickets om de Initiator van de module in staat te stellen te volgen welk gevolg er gegeven wordt aan zijn aanvraag: (p.ex. il ne sera pas possible d annuler un Mystery Switch si un autre module de Start Access ou Initiate Local Production est devenu effectif entretemps, mais il sera par contre par exemple possible de passer au-dessus d un module d Update Technical Master Data) ou jusqu à 37 mois dans le passé (la dernière réconciliation). Ce type de demande implique l accord des parties éventuellement impactées si le module devait être annulé; 3. s demandées par le Balance Supplier. Ces rectifications pouvant être de six types : a. Metering ; b. Relational Message (p.ex.missing d acceptation/rejet) (Structuring/Settlement/Metering/Bill/Operate) ; c. Technical Message (Structuring) ; d. Switching (Structuring) (uniquement pour les rectifications liées au Start Access de contestation) ; e. Settlement. f. Billing (uniquement pour des Transaction Costs) Pour tous les cas susmentionnés, et comme pour tous les autres modules NUI, le module Request se limite à un seul Point d Accès. Il ne sera donc pas possible d initier via ce module des demandes de rectification en masse. Avant qu une demande de rectification ne soit lancée par le Balance Supplier, celuici doit être sûr que la situation ne peut pas être réglée au moyen des informations mises à disposition dans le Preswitching (voir document de référence [2]) ou via le Portal. Dans le cas où les informations mises à disposition ne suffisent pas, une demande de Request pourra être initiée. Le traitement des rectifications Inbound nécessite des actions de la part du MPA et du GRD dans certains cas. Des tickets sont utilisés pour permettre à la partie initiatrice du module de suivre l état d aboutissement de sa demande : Accept: zijn aanvraag is ontvangen, aanvaard en de gepaste verwerking is gestart; Reject: de aanvraag is ontvangen, maar is geweigerd door de ex-ante testen. Negative closing ticket: de aanvraag is geaccepteerd, maar de gewenste/vereiste verwerking heeft niet kunnen plaatsvinden. De behandeling van de rectificatie wordt beëindigd; Positive closing ticket: zijn aanvraag is correct verwerkt kunnen worden (de gerectificeerde periode kan verschillen van deze die initieel opgegeven werd in de aanvraag, alsook is het mogelijk dat andere domeinen beïnvloed en dus eveneens gerectificeerd worden). De behandeling van de rectificatie wordt beëindigd. UMIG - BR - ST v6.5 8/76 Accept : sa demande a été reçue, acceptée et le traitement adéquat a démarré ; Reject : sa demande a été reçue, mais est rejetée par les tests ex-ante; Negative closing ticket : sa demande a été acceptée mais le traitement adéquat n a pas pu/dû y être apporté. Le traitement de la rectification s achève ; Positive closing ticket : sa demande a été traitée et tout le traitement adéquat a pu y être apporté (la période rectifiée peut différér de celle initialement indiquée dans la demande, de même que d autres domaines peuvent être impactés et du coup rectifiés également). Le traitement de la rectification s achève.

9 We wijzen erop dat het akkoord van andere marktpartijen vereist kan zijn in het kader van inbound rectificaties. Als deze partijen akkoord gaan met de verwerking van de rectificatie, ontvangen ze eventueel, indien vereist, rectificatieberichten in het kader van het spontane rectificatieproces (zie onder) en niet in het kader van de module Request Request. Bovendien zal er, ten opzichte van de markt, geen link gemaakt worden tussen spontane rectificaties die uitgevoerd werden volgend op de behandeling van inbound rectificaties Outbound Rectificaties s outbound Rectificaties geïnitieerd door de DNB, die slechts betrekking hebben op de Business Master Data en een actie impliceren van de Balance Supplier die bevoegd is voor het toegangspunt waarvoor de Business Master Data (via UBMD, SA of ILP) moeten worden gestuurd, worden outbound rectifications genoemd. De verwerking vereist acties van de Balance Supplier en de MPA. De MPA controleert de ontvankelijkheid van de aanvraag en vervolgens geeft de Balance Supplier een positief of negatief gevolg aan de aanvraag van de DNB. Als er een positief gevolg gegeven wordt, stuurt de Balance Supplier een positive close en een module-aanvraag om de Business Master Data bij te werken In geval van een negatief gevolg stuurt de Balance Supplier enkel een negative close. Zie ook chapter 7 Outbound voor meer details Spontane Rectificaties rectifications spontanées In het geval van spontane rectificaties, corrigeert de DNB op eigen initiatief berichten waarvan hij weet dat ze verkeerd zijn en verstuurt hij de gecorrigeerde versie van deze berichten naar de partijen waarop de rectificaties betrekking hebben. De DNB zal steeds zelf een spontane rectificatie opstarten, wanneer een structure module opgestart wordt (door de DNB of door een Balance Supplier) waarvan de Effectieve Datum in een uitgestuurd BillingRelevant Volume ligt. Aan het Closing Ticket wordt, naast de rectificatie code, eventueel een aanvullende reden gekoppeld (in de vorm van een veld met vrije tekst) die nadere informatie zal verstrekken over de reden van de spontane rectificatie aan de betrokken partij die deze berichten ontvangt. A noter que dans le cadre des rectifications inbound, l accord d autres parties de marché peut être requis. Si ces parties signalent toutes leur accord avec le traitement de la rectification, elles recevront éventuellement, et si requis, des messages de rectification dans le cadre du processus de rectification spontanée (voir plus bas) et non pas dans le cadre du module Request Request. Par ailleurs, aucun lien ne sera fait, du point de vue du marché, entre des éventuelles rectifications spontanées liées au traitement de rectifications inbound. Les rectifications initiées par le GRD, qui ne concernent que des Business Master Data et qui impliquent une action du Balance Supplier compétent pour le point d accès pour lequel les Business Master Data (via UBMD, SA ou ILP) doivent être corrigés, sont des rectifications Outbound. Le traitement de telles situations nécessite des actions de la part du Balance Supplier et du MPA. Le MPA vérifie la recevabilité de la demande et ensuite le Balance Supplier donnera une issue positive ou négative à la demande du GRD. Si l issue est positive, le Balance Supplier enverra un positive close et une requête de module en vue de mettre à jour les Business Master Data Si l issue est négative, le Balance Supplier enverra uniquement un negative close. Voir aussi chapitre 7 Outbound pour davantage de détails. En cas de rectification spontanée, le GRD de sa propre initiative rectifie des messages qu il sait être faux et envoie la version corrigée de ces messages aux parties impactées par ces rectifications. Le GRD démarrera toujours une rectification spontanée lorsqu un module structure est démarré (par le GRD ou par un Balance Supplier) dont la Date Effective se situe dans une période d un Volume BillingRelevant. A noter qu au closing ticket, au-delà du code de rectification, il sera éventuellement associé une raison complémentaire (présente sous la forme d un Free text) qui fournira de plus amples informations sur la raison des rectifications spontanées à la partie impactée et recevant ces messages. UMIG - BR - ST v6.5 9/76

10 Rectificatie principes Principes de rectification Bij rectificatie horen een reeks van principes. Deze worden hieronder toegelicht. Une série de principes accompagne la rectification. Ils sont commentés ci-dessous Partieel netting - Netting partiel Het principe van gedeeltelijke netting heeft zijn oorsprong in het undo-redo principe. Dit principe wil dat wanneer een fout is vastgesteld, de gehele periode vanaf de meest recente datum wanneer een informatie verstuurd is geweest tot aan de datum van de laatste timeslice die geïmpacteerd is; fout ongedaan wordt gemaakt (undo) om alles te kunnen reconstrueren met de gecorrigeerde gegevens tot aan de datum van de laatste versturing van informatie (redo). Het undo-redo principe zou de bron kunnen zijn van vele te versturen berichten indien het principe van gedeeltelijke netting niet werd toegepast. Dit nettingprincipe houdt in dat alleen de gegevens die beïnvloed worden door de rectificatie en de daaropvolgende updates van deze gegevens opnieuw worden verstuurd. Er wordt uiteraard rekening gehouden met de verbanden tussen de types gegevens (d.w.z de gridfee is afhankelijk van de metering, die zelf afhankelijk is van de TMD, die op zijn beurt afhankelijk kan zijn van de RMD). Indien de Technical Master Data gewijzigd worden, zal de metering voor de betrokken periode aangepast kunnen worden. In dat geval zal de herverzending van de metering vereisen dat de gridfee opnieuw verzonden wordt. In het kader van gedeeltelijke netting daarentegen worden, wanneer er een rectificatie wordt uitgevoerd op een metering slice, alle daaropvolgende metering slices opnieuw verstuurd, maar niet de Technical of Relational Master Data slices die dateren van na de eerste gerectificeerde metering slice, indien deze niet gewijzigd zijn. Gedeeltelijke netting wordt derhalve toegepast: Horizontaal: zodra er een slice wordt gewijzigd, worden alle volgende slices aangepast en verstuurd. Dat is het principe "replay the movie"; Verticaal: zodra een slice van een specifiek domein wordt gerectificeerd, worden alle slices van de gerelateerde domeinen tevens verstuurd. Uitzondering op horizontale netting: TMD TMD kan gerectificeerd worden (redo), zonder eerst de bestaande TMD te annuleren (undo). De nieuwe TMD zal immers alle volgende TMD-slices overschrijven. Le principe de netting partiel tient son origine dans le principe d undo-redo. Ce principe veut que lorsque une erreur est décelée, l ensemble de la période allant de la date la plus récente à laquelle une information a été envoyée jusqu au dernier timeslice impacté, soit défait (undo) pour ensuite pouvoir être reconstruit entièrement avec les données corrigées jusqu à la date du dernier envoi d information (redo). Le principe d undo-redo pourrait être à la source de beaucoup de messages à envoyer si le principe de netting partiel n était pas appliqué. Le netting partiel veut que seules les données impactées par la rectification et les mises à jour suivantes de ces données soient ré-envoyées en tenant bien entendu compte de la dépendance des types de données (i.e. le gridfee dépend du metering qui lui-même dépend des Technical Master Data, qui à leur tour peut être dependent des RMD). Si les Technical Master Data sont modifiés, du metering pour la période concerné pourra être lui aussi modifié, dans quel cas le ré-envoi du metering impose de réenvoyer le gridfee. Par contre, dans le cadre du netting partiel, si un slice de metering est rectifié, on ré-envoie tous les slices de metering suivant, mais on ne ré-envoie pas les slice Technical Master Data ultérieurs au premier slice de metering rectifiés pour autant que les Technical Master Data ne soient pas modifiés. Le netting partiel s applique donc: Horizontalement : dès qu un slice est touché, tous les slices suivants sont impactés et envoyés. C est le principe du replay the movie. Verticalement : lorsqu un slice d un domaine particulier est rectifié, tous les slices des domaines dépendants sont également envoyés. Exception au principe du netting horizontal : TMD Les TMD peuvent être rectifiés (redo), sans avoir annulé (undo) les TMD précédents. En effet, les nouveaux TMD écraseront de toute façon tous les slices TMD ultérieurs. Ter vergelijking, de full netting zou enkel bestaan uit het sturen van verbeterde berichten (dwz dat het undo-redo principe plotseling niet toegepast zou worden) en de no-netting zou bestaan uit het sturen van al de berichten die verstuurd waren sinds de datum waarop de fout werd verbeterd (het uno-redo principe zou in het extreem worden gevolgd) En comparaison le netting full ne consisterait qu à envoyer le message corrigé (le principe d undo-redo ne serait du coup pas appliqué) et le no-netting consisterait à envoyer tous les messages ayant été envoyés depuis la date à laquelle l erreur a été corrigée (le principe d undo-redo serait ici suivi à son extrême). UMIG - BR - ST v6.5 10/76

11 2.2.2 Einde van een rectificatie fin d une rectification De algemene regel is dat een rectificatie (met uitzondering van outbound rectificaties, zie hieronder) eindigt met de verzending van een Closing Ticket met undo-informatie en berichten ERR, d.w.z. informatie ter annulering van eerder verzonden berichten (Undo-informatie) of rectificatieberichten (ERR). Deze berichten worden gegenereerd door de Meter Point Administrator of de DNB in het kader van een van zijn rollen (Metered Data Responsible, Meter Administrator enz.). De marktpartij die deze berichten ontvangt, moet deze correct verwerken (d.w.z. verwerking van alle berichten en in de volgorde die is opgegeven in het Closing Ticket) in haar systemen om ervoor te zorgen dat de situatie die resulteert uit de rectificatie, correct geregistreerd wordt. De verwerking van deze berichten mag in geen geval voor de marktpartij die de undo-informatie en/of berichten ERR ontvangen heeft, de verplichting inhouden een marktaanvraag te lanceren. Voor berichten betreffende Technical Master Data is de werkwijze lichtjes anders: de regel is dat, in geval van een rectificatie van de Technical Master Data, als de effectieve datum van de Master Data een timeslice metering overschrijdt, het bericht van de Master Data gemarkeerd wordt als een rectificatie (ERR) en anders als een gewone update van de Technical Master Data. Derhalve zullen deze zichtbaar zijn in het kader van de rectificaties die zijn aangevraagd door de markt: - in Preswitching FULL, voor de Balance Supplier die de rectificatieaanvraag gelanceerd heeft; - in Preswitching LIGHT, via de status Lock, die eventueel geactiveerd kan worden door de DNB en waaraan de reden "" wordt gekoppeld. In de andere gevallen, dit wil zeggen de spontane of outbound rectificaties, zal er niets zichtbaar zijn voor de rectificatie is uitgevoerd. In deze fase worden de wijzigingen die voortvloeien uit de rectificatie, geregistreerd en zijn ze zichtbaar via Preswitching FULL (outbound en spontaan) en eventueel via Preswitching LIGHT (spontaan, als de gerectificeerde gegevens deel uitmaken van de gegevens die ter beschikking gesteld worden in deze categorie van Preswitching). En règle générale, l issue d une rectification (excepté pour les rectifications outbound, voir ci-dessous) impliquera l envoi d un Closing Ticket comprenant l information undo et des messages ERR qui correspondent à des annulations de messages déjà envoyés (information undo) et à des messages rectifications (ERR). Ces messages sont générés par le Meter Point Administrator ou le GRD dans le cadre de l un de ses rôles (Metered Data Responsible, Meter Administrator, ). La partie de marché recevant ces messages devra les traiter adéquatement (i.e. traitement de tous les messages et dans l ordre indiqué dans le closing ticket) dans ses systèmes afin d enregistrer correctement la situation correspondant à la situation rectifiée. Dans aucun cas, le traitement de ces messages n impliquera l obligation de lancement d une demande de marché de la part d une partie de marché ayant reçu de l information undo et/ou des messages ERR. Concernant les messages de Technical Master Data, le fonctionnement est quelque peu différent : la règle est que lorsqu une rectification sur des Technical Master Data a lieu, si la date effective de ces Master Data dépasse un timeslice metering, alors le message des Master Data aura une indication ERR, dans les cas contraire, il s agira d un simple Update des Technical Master Data. Aussi, dans le cadre de rectifications demandées par le marché, celles-ci seront visibles : - dans le Preswitching FULL, pour le Balance Supplier ayant initié la demande de rectification ; - dans le Preswitching LIGHT, via le statut lock qui pourra éventuellement être activé par le GRD et auquel sera rattaché la raison. Dans les autres cas, c est-à-dire les rectifications spontanées ou outbound, rien ne sera visible avant que la rectification n ait été effectuée. A ce moment, les modifications induites par la rectification seront enregistrées et visibles via le Preswitching FULL (outbound et spontanées) et éventuellement via le Preswitching LIGHT (spontanées, si les données rectifiées font partie des données mises à disposition dans cette catégorie de Preswitching). UMIG - BR - ST v6.5 11/76

12 2.2.3 Envelop Enveloppe Opgelet: Deze sectie heeft betrekking op een Business-mededeling. Het is aan de technici om te bepalen op welke manier het principe zal worden geïmplementeerd. Attention : cette section reflète un avis business. Il appartiendra aux techniciens de définir la façon dont ce principe sera implémenté. Het enveloppeprincipe is een concept dat wordt toegepast in geval van een Positive Closing Ticket voor inbound en spontane rectificaties. Dit principe houdt in dat alle rectificatieberichten (undo en redo berichten) tegelijkertijd verstuurd worden naar de partij die de module Request Request heeft aangevraagd of die getroffen wordt door spontane rectificaties. Le principe d enveloppe est un concept apparaissant dans le cas d un Positive Closing Ticket pour les rectifications inbound et spontanées. Ce principe consiste à envoyer tous les messages de rectification (messages undo et messages redo) en même temps à la partie ayant fait la demande du module de Request Request ou faisant l objet de rectifications spontanées. Dat betekent dat de Initiator van de module bij de ontvangst van een Positive Closing Ticket met betrekking tot de Request, alle berichten ontvangt die aan de behandeling van de rectificatie verbonden zijn. Cela signifie qu à la réception du Positive Closing Ticket relatif à la demande du Request, la partie initiatrice du module recevra l ensemble des messages liés au traitement de la rectification. Het positief Closing Ticket bevat bovendien de referentie van die berichten die het voorwerp hebben uitgemaakt van een rectificatie, gerangschikt in een logische volgorde, zodat de Initiator weet welke berichten samenhangen met zijn aanvraag tot Request en in welke volgorde ze moeten worden uitgevoerd opdat de rectificatie correct verwerkt wordt in zijn systemen. Le Positive Closing Ticket contiendra en plus la référence de ces messages ainsi qu un ordre logique de ceux-ci de sorte à ce que la partie initiatrice connaisse quels sont les messages liés à sa demande de Request et dans quel ordre doivent-ils être exécutés afin que la rectification soit correctement prise en compte dans ses systèmes. In geval van spontane rectificaties, dit wil zeggen als een partij berichten ontvangt die het voorwerp hebben uitgemaakt van een rectificatie, zonder zelf een rectificatie aangevraagd te hebben, geldt eveneens het enveloppeprincipe: de partij ontvangt een Positive Closing Ticket waarin wordt aangegeven welke berichten aangepast zijn en in welke volgorde ze verwerkt moeten worden. Dans le cas de rectification spontanée, c'est-à-dire lorsqu une partie reçoit des messages de rectification mais sans avoir elle-même initié de demande de Request, le principe d enveloppe sera aussi d application : la partie recevra un Positive Closing ticket lui indiquant quels sont les messages rectifiés et dans quel ordre ils doivent être processés. De logische volgorde met betrekking tot de sortering van referenties van gerectificeerde berichten in het closing ticket is als volgt: L ordre logique pour le classement des références des messages rectifiés dans le closing ticket est le suivant : - Eerst moet de undo-informatie (indien er is) worden verwerkt, volgens - En premier, l information Undo (si il y en a) doit être traitée, dans onderstaande volgorde: l ordre suivant: 1. Gridfee en settlement berichten (indien er zijn), van het meest 1. Messages de gridfee et settlement (s il y en a), du plus récent au recente tot het oudste (voor meer informatie ivm credit plus vieux (pour plus d information par rapport aux messages berichten, zie hoodstuk 0); crédit, voir chapitre 0); 2. Metering berichten (indien er zijn), van het meest recente tot het 2. Messages de metering (s il y en a), du plus récent au plus vieux; oudste; 3. Technical Master Data berichten (indien er zijn), van het meest 3. Messages de Master Data techniques (s il y en a), du plus récent recente tot het oudste; au plus vieux; 4. In het geval van Structure rectificaties (ST11 ST14): Relational 4. En cas de rectifications Structure (ST11 ST14): des messages Master Data berichten (indien er zijn), van het meest recente tot Relational Master Data (s il y en a), du plus récent au plus vieux. het oudste. UMIG - BR - ST v6.5 12/76

13 - Vervolgens komen de Redo berichten (indien er zijn) voor die als volgt gesorteerd zullen zijn: 1. In het geval van Structure rectificaties (ST11 ST14): Relational Master Data (indien er zijn), van het oudste tot het meest recente; 2. Technical Master Data (indien er zijn), van het oudste tot het meest recente; 3. Metering berichten (indien er zijn), van het oudste tot het meest recente; 4. Gridfee en settlement berichten (indien er zijn), van het oudste tot het meest recente. - Ensuite, les messages de Redo (s il y en a), qui seront classés dans l ordre suivant : 1. En cas de rectifications Structure (ST11 ST14): des messages Relational Master Data (s il y en a) du plus vieux au plus récent; 2. Messages de Master Data techniques (s il y en a), du plus vieux au plus récent; 3. Messages de metering (s il y en a), du plus vieux au plus récent; 4. Messages de gridfee et settlement (s il y en a), du plus vieux au plus récent. Tenslotte, indien de DNB in het kader van een van zijn rollen of de Meter Point Administrator, na de verzending van een enveloppe ingevolge een rectificatie, tot het besef zou komen dat er nog bepaalde berichten/gegevens gewijzigd moeten worden, zal hij een spontane rectificatie lanceren met een andere enveloppe dan degene die gebruikt is tijdens de vorige verwerking. Enfin, si après l'envoi d'une enveloppe, le GRD dans le cadre de l un de ses rôles ou le Meter Point Administrator devait se rendre compte qu'il faut encore modifier certains messages/données, il initiera une rectification spontanée avec une autre enveloppe que celle utilisée lors du précédent traitement. Catalogus rectificatiecodes - Catalogue codes de rectifications Iedere rectificatie bevat een rectificatiecode (zie refentiedocument [6].) Deze code stelt de Initiator van de aanvraag in staat de fout die hij heeft vastgesteld, aan te geven (bijv. niet-ontvangen LOSS-bericht). Toute rectification contient un code de rectification (voir document de référence [6]). Ce code permet à l initateur d une telle demande d indiquer l erreur qu il a constaté (p.ex. message de LOSS non reçu). Deze codes worden meestal gekoppeld aan bijkomende velden, die de partijen die acties moeten verrichten in het kader van de verwerking van de aanvraag, in staat stellen te beschikken over alle informatie die ze nodig hebben om de verwerking behoorlijk en met kennis van zaken uit te voeren. Deze bijkomende velden zijn eveneens opgenomen in het referentiedocument [6]. A ces codes seront, dans la plupart des cas, associés des champs additionnels qui permettront aux parties devant effectuer les actions liées au traitement de la demande de disposer de toutes les informations afin de pouvoir mener ce traitement adéquatement et en connaissance de cause. Ces champs additionnels sont également repris dans le document de référence [6]. Alle rectificatiecodes zijn opgenomen in de catalogus van rectificatiecodes die ter beschikking gesteld wordt in de documentatie van UMIG (zie referentiedocument [5]). L ensemble des codes de rectification est repris dans le catalogue des codes de rectification disponible dans la documentation du UMIG (voir document de référence [5]). UMIG - BR - ST v6.5 13/76

14 Rectificatie van FEE, PSO en TRC Rectificaiton de FEE, PSO et TRC CreditNota Voor het wegnemen van FEE, PSO en TRC volstaat het niet om enkel undoinformatie toe te voegen in het Closing Ticket. Om boekhoudkundig correct te blijven, moet de oorspronkelijke afrekening ongedaan gemaakt worden via een CreditNota. Bijgevolg wordt hier een uitzondering gemaakt op het undo-redo principe. In plaats van undo-informatie in het Closing Ticket, zullen er opnieuw FEE-, PSO- en TRC-berichten worden aangemaakt, waarin alle lijnen van het oorspronkelijk bericht gecrediteerd worden. Elk van deze credit berichten mapt op het oorspronkelijke FEE, PSO of TRC bericht en zal een referentie naar dit oorspronkelijke bericht bevatten. In het Closing Ticket zal eveneens gerefereerd worden naar alle credit berichten horende bij de rectificatie. Note de Crédit Pour l enlèvement de FEE, PSO et TRC il ne suffit pas de seulement rajouter l information Undo dans le closing ticket. En vue de procéder correctement au niveau comptable, le décompte original doit être annulé par une Note de Crédit. En conséquence, une exception est faite au principe undo-redo. Au lieu d envoyer l information undo dans le Closing Ticket, des nouveaux messages FEE, PSO et TRC seront créés, qui créditent toutes les lignes du message original. Chacun de ces messages «crédit» correspond à un message FEE, PSO ou TRC original et contiendra une référence à ce message original. Dans le closing ticket, référence sera faite à tous les messages «crédit» qui font partie de la rectification. Inbound rectificatie voor TRC Enkel voor TRC is inbound rectificatie mogelijk. In dat geval zal de DNB standaard antwoorden met een Negative Closing, type No Treatment, en (indien nodig) vervolgens een spontane rectificatie opstarten om de transactiekosten te corrigeren. In het Negative Closing bericht, zal de DNB aangeven (via het No Treatment Reason veld) dat een spontane rectificatie volgt. inbound pour des TRC Une rectification inbound est seulement possible pour des TRC. Dans ce cas le GRD répondra toujours avec un «Negative Closing», type «No Treatment», et déclenchera ensuite (si nécessaire) une rectification spontanée pour corriger les frais de transaction. Dans le message «Negative Closing», le GRD indiquera (en utilisant le champ «No Treatment Reason») qu une rectification spontanée suit. Toegelaten Rectificatieperiode Période de Rectificaiton permise Een rectificatie aanvraag mag niet verder teruggaan dan de laatste reconciliatierun. Voor meer informatie met betrekking tot specifieke situaties, zie referentiedocument [10]. Indien er toch gegevens moeten worden rechtgezet die verder teruggaan in het verleden dan de toegelaten rectificatieperode, dient dit bilateraal te worden overeengekomen en rechtgezet tussen de Balance Supplier(s) en de DNB. De correcties worden uitgevoerd met een specifieke rectificatiecode en met de standaard berichtenuitwisseling. Une demande de rectification ne peut aller plus loin dans le passé que le dernier run de reconciliation. Pour davantage d information par rapport à des situations spécifiques, voir document de référence [10]. S il y a quand même lieu de rectifier des données qui vont plus loin dans le passé que la période de recification permise, alors l exécution de cette corretion est convenue bilatéralement entre le(s) Balance Supplier(s) et le GRD. Les corrections sont exécutées avec un code de rectification spécifique et l échange de messages standard. UMIG - BR - ST v6.5 14/76

15 3 Context Contexte Scope Figure 1 - Use Case - Overview v1.0 UMIG - BR - ST v6.5 15/76

16 Begrippen en definities - Concepts et définitions Het globale rectificatieproces draait rond 2 hoofdprocessen: - Request Request : proces waarbij er een aanvraag wordt gelanceerd door een partij die een fout heeft opgemerkt in een gegeven of een bericht of die een verwacht bericht niet ontvangen heeft en waarbij deze aanvraag een eerste verwerking ondergaat. Het proces Request Request vindt plaats voor inbound rectificaties, maar niet voor outbound en spontane rectificaties; - Handle Process: proces waarbij een serie subprocessen worden uitgevoerd die specifiek zijn aan het type rectificatie (spontaan, inbound of outbound). Het onderhavige document gaat nader in op die verschillende processen en de subprocessen waaruit ze bestaan. Merk op: tijdens het verloop van het globale rectificatieproces wordt in sommige gevallen het proces Notify Social Supplier gebruikt. Meer uitleg hierover, en in welke gevallen dit gebruikt wordt, is te vinden in referentiedocument [11]. Le processus global s articule autour de 2 processus principaux : - Request Request : processus dans lequel une demande est initiée par une partie ayant remarqué une erreur dans une donnée ou un message ou n ayant pas reçu un message attendu et durant lequel cette demande subit un premier traitement. Le processus Request Request est parcouru pour les rectifications inbound, mais pas pour les rectifications spontanées et outbound; - Handle Process : processus dans lequel une série de sousprocessus spécifiques au type de rectification (spontanée, inbound ou outbound) est réalisée. Le présent document développe plus en détails l ensemble de ces processus et des sous-processus qui les composent. Remarque : pendant le déroulement du processus global de rectification, dans certains cas, le processus Notify Social Supplier est utilisé. Une explication détaillée ainsi que les cas dans lesquels ce processus est utilisé, se trouvent dans le document de référence [11]. Procesverloop - Déroulement de la procédure Figure 2 - Activity v1.1 UMIG - BR - ST v6.5 16/76

17 4 Request Request Proces Definitie - Définition du Proces Het proces Request Request vindt plaats tussen de Initiator van een rectificatieaanvraag (d.i. de partij die een fout in een gegeven of een bericht heeft opgemerkt of die een verwacht bericht niet ontvangen heeft) en de Responsible (die verantwoordelijk is voor de coördinatie van de rectificaties). Enkel de rectificaties van het type inbound worden getroffen door dit proces. Figure 3 - Use Case Request Request v1.0 Le processus Request Request se déroule entre l Initiator d une demande de Request (i.e. partie ayant remarqué une erreur dans une donnée ou un message ou n ayant pas reçu un message attendu) et le Responsible (le responsable de la coordination des rectifications).seules les rectifications de type inbound sont concernées par ce processus. Het kan opgedeeld worden in drie hoofdstappen: - Aanmaak en verzending van een aanvraag door de Initiator; - Ontvangst en eerste behandeling van de aanvraag door de Responsible; - Kennisgeving van de verwerping of acceptatie door de Responsible aan de Initiator. Il peut être divisé en trois étapes principales : - Création et envoi d une demande par l Initiator; - Réception et premier traitement de la demande par le Responsible; - Notification du rejet ou de l acceptation par le Responsible à l Initiator. Aan het einde van dit proces en indien de aanvraag geaccepteerd wordt, wordt deze beschouwd als effectief en wordt het globale proces voortgezet en het globale proces Handle Process gestart (zie sectie 5). Als de aanvraag echter wordt verworpen, dan stopt de uitvoering en volgt geen enkele andere actie meer. A l issue de ce processus et si la demande initiée est acceptée, la demande est considérée effective et le processus global se poursuivra et déclenchera le processus global Handle Process (voir section 5). Si par contre la demande initiée est rejetée, l exécution de la demande s achève là et aucune autre action n est entreprise. UMIG - BR - ST v6.5 17/76

18 Procesverloop - Déroulement de la procedure Figure 4 - Activity Request Request v1.0 UMIG - BR - ST v6.5 18/76

19 Procesomschrijving - Description des procédures Startsignaal: Dit subproces wordt gestart zodra een Initiator een nieuwe aanvraag lanceert teneinde een fout in een bericht of een marktsituatie te laten rechtzetten of om te vragen om de verzending van een nog niet ontvangen bericht. Deze aanvraag wordt gematerialiseerd door verzending van een bericht ST-INT-1. Est initié quand: Ce sous-processus est initié dès qu un Initiator initie une nouvelle demande afin de demander au marché de corriger une erreur décelée dans un message, dans une situation de marché ou encore afin de demander l envoi d un message n ayant pas encore été reçu. Cette demande est matérialisée par l envoi d un message ST-INT-1. Pre-requisites: Om een aanvraag te kunnen opstarten, moet de Initiator toegang hebben tot het uitwisselingssysteem voor de markt en beschikken over de nodige en voldoende informatie om zijn bericht te kunnen aanmaken (bv. toegangspunt, gewenst type aanvraag, rectificatiecode). Pré-requis: Pour pouvoir initier une demande, l Initiator doit avoir accès au système d échange mis en place pour le marché et disposer des informations nécessaires et suffisantes pour pouvoir générer son message (p.ex. point d accès, type de demande souhaitée, code de rectification). Eindigt wanneer: de aanvraag een eerste behandeling heeft ondergaan en op basis daarvan hetzij verworpen, hetzij aanvaard is door de Responsible. Bij verwerping wordt een bericht ST-INT-2 gestuurd naar de initiator van de aanvraag om hem in kennis te stellen van de verwerping van zijn aanvraag door de markt. In geval van acceptatie wordt er naar de Initiator van de aanvraag een bericht ST-INT-3 gestuurd om hem in kennis te stellen van de aanvaarding van zijn aanvraag en de registratie ervan in het toegangsregister en wordt er een bericht ST-INT-9 (open) gestuurd om hem het ticketnummer van zijn aanvraag mee te delen. Se termine lorsque: La demande a subi un premier traitement à l issue duquel, elle est soit refusée, soit acceptée par le Responsible. Dans le cas d un refus, un message ST-INT-2 est envoyé à la partie initiatrice de la demande pour la notifier du rejet par le marché de sa demande. Dans le cas d une acceptation, un message ST-INT-3 est envoyé à la partie initiatrice de la demande pour la notifier de l acceptation et de l enregistrement de sa demande dans le registre d accès et un message ST-INT-9 (open) est envoyé pour lui communiquer le numéro de ticket associé à sa demande. Resultaat: Ofwel wordt de aanvraag van de Initiator geaccepteerd en geregistreerd en wordt er een ticketnummer gestuurd naar de Initiator. Of de aanvraag wordt verworpen en dus niet geregistreerd, en de Initiator in kennis gesteld. Résultat: La demande de la partie initiatrice est soit acceptée, enregistrée et un numéro de ticket envoyé à l Initiator de la demande. Soit la demande n est pas enregistrée, est refusée et l Initiator avisé. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Initiator lanceert de aanvraag (Create Request) op basis van de gegevens verzameld via de verschillende kanalen waarover hij beschikt (preswitching, contact klant, ). - L Initiator initie la demande (Create Request) grâce aux informations récoltées via les différents canaux dont il dispose (preswitching, contact client, ). - Vervolgens stuurt de Initiator een bericht ST-INT-1 naar de Meter Point Administrator (Send Request). - L Initiator envoie après cela un message ST-INT-1 vers le Meter Point Administrator (Send Request). - De Meter Point Administrator ontvangt het bericht en onderwerpt het - Le Meter Point Administrator reçoit le message et réalise une série de aan een reeks tests (Receive Request, Test Request). tests dessus (Receive Request, Test Request). Al deze tests zijn opgenomen in referentiedocument [3] en in L ensemble de ces tests est repris dans le document de référence [3] UMIG - BR - ST v6.5 19/76

20 referentiedocument [5] in de tab Tests Level2. Het is belangrijk op te merken dat afhankelijk van de eventuele flags in het bericht ST-INT-1 (zie referentiedocument [8]), de realisatie van deze ex-ante tests in verschillende stappen kan worden verricht. - Afhankelijk van het resultaat van de op de aanvraag verrichte tests, zijn er twee mogelijkheden: ainsi que dans le document de référence [5] dans l onglet Tests Level2. Il est important de noter qu en fonction des flags éventuels contenus dans le message ST-INT-1 (voir document de référence [8]), la réalisation de ces tests ex-ante peut être réalisée en plusieurs étapes. - En fonction du résultat des tests effectués sur la demande, deux options sont possibles : o De aanvraag wordt verworpen omdat ze faalt voor een of meerdere tests van een categorie: in dat geval wordt naar de Initiator een verwerpingsbericht ST-INT-2 gestuurd (Send Response). Het bericht wordt door hem ontvangen (Receive Negative Response), het proces Request Request eindigt en de behandeling van de aanvraag stopt hier. Het bericht bevat een of meer verwerpingscodes, eventueel met opgave van de reden van de verwerping. Deze verwerpingscodes en redenen worden beschreven in referentiedocumenten [3] en [5]. o La demande est rejetée car elle échoue à un ou plusieurs tests d une catégorie : dans quel cas un message de rejet ST-INT-2 est envoyé à l Initiator (Send Response). Le message est reçu par celui-ci (Receive Negative Response), le processus Request Request s achève et le traitement de la demande se termine ici. Le message contient un ou plusieurs codes de rejet accompagnés éventuellement d une indication de la raison de ce code de rejet. Ces codes de rejet et leurs raisons sont repris dans les documents de référence [3] et [5]. o De aanvraag wordt aanvaard, in welk geval de wijzigingen die voortvloeien uit de acceptatie van de aanvraag geregistreerd worden (Handle Data Changes). Een acceptatiebericht ST-INT- 3 en een ST-INT-9 (open) bericht met het ticketnummer dat toegewezen is aan de rectificatieaanvraag (Request ) worden gestuurd naar de Initiator (Send Response). Het bericht wordt door hem ontvangen (Receive Response). Hier eindigt het proces Request Request en begint het proces Handle Process. o La demande est acceptée, dans quel cas les changements induits par l acceptation de la demande sont enregistrés (Handle Data Changes). Un message d acceptation ST-INT-3 et un message ST-INT-9 (open) avec le numéro de ticket associé à la demande de Request sont envoyés à l Initiator (Send Response). Le message est reçu par celui-ci (Receive Response), le processus Request Request se termine ici et le processus Handle Process est déclenché. UMIG - BR - ST v6.5 20/76

21 5 Handle Process (global) Proces Definitie - Définition du Proces Figure 5 - Use Case Handle Process v1.0 Het globale proces Handle Process wordt beheerd door de Responsible en maakt het mogelijk alle activiteiten te starten die verband houden met de complete verwerking van een rectificatie, of deze nu plaatsvindt op aanvraag (inbound en outbound) of spontaan (spontane rectificaties). Le processus global Handle Process est géré par le Responsible et permet d initier toutes les activités liées au traitement complet d une rectification qu elle soit demandée (rectifications inbound et outbound) ou spontanée (rectifications spontanées). UMIG - BR - ST v6.5 21/76

22 Voor de inbound rectificatie volgt dit proces op het proces Request Request, waarbij de Responsible een eerste, min of meer generieke, verwerking van de binnenkomende aanvraag verricht. Op het einde van die behandeling aanvaardt of verwerpt de Responsible de aanvraag. Indien de aanvraag geaccepteerd wordt, wordt het proces Handle Process gestart. Wordt de aanvraag echter verworpen, dan wordt het proces Handle Process nooit opgestart. Voor de outbound en spontane rectificaties, is het globale proces Handle Process het eerste gestarte proces. Het proces Handle Process bestaat uit drie processen: - Handle Inbound : proces waarbij de inbound rectificatieaanvragen (Request Inbound) op de juiste manier verwerkt worden; - Handle Outbound: proces waarbij de outbound rectificatieaanvragen (Request Outbound) op de juiste gepaste manier verwerkt worden. - Handle Spontaneous : proces waarbij de spontane rectificatie op de juiste gepaste manier verwerkt worden. Pour les rectifications inbound, ce processus suit le processus de Request Request dans lequel le Responsible effectue un premier traitement plus ou moins générique sur la demande entrante. A l issue de ce traitement, le Responsible accepte ou rejette la demande. Si la demande est acceptée, le processus Handle Process est déclenché. Si la demande est rejetée, le processus Handle Process ne sera jamais déclenché. Pour les rectifications outbound et spontanées, le processus global Handle Process est le premier processus déclenché. Le processus Handle Process se compose de trois processus : - Handle Inbound : processus dans lequel le traitement adéquat aux types de demandes de Request Inbound est apporté ; - Handle Outbound : processus dans lequel le traitement adéquat aux types de demandes de Request Outbound est apporté ; - Handle Spontaneous : processus dans lequel le traitement adéquat aux rectifications spontanées est apporté. UMIG - BR - ST v6.5 22/76

23 Procesomschrijving - Déroulement de la procedure Figure 6 - Activity Handle Process v1.0 UMIG - BR - ST v6.5 23/76

24 6 Handle Inbound Proces definitie - Définition du Proces Figure 7 - Use Case Handle Inbound v1.0 Het proces Handle Inbound wordt beheerd door de Responsible en maakt het mogelijk alle activiteiten die verband houden met de complete verwerking van de inbound rectificaties te starten. Dit proces maakt deel uit van het globale proces Handle Process en volgt altijd op het proces Request Request, waarbij de Responsible een eerste, min of meer generieke, verwerking van de binnenkomende aanvraag verricht. Op het einde van die behandeling aanvaardt of verwerpt de Responsible de aanvraag. Indien de aanvraag geaccepteerd wordt, wordt het proces Handle Inbound gestart. Wordt de aanvraag echter verworpen, dan wordt het proces Handle Inbound nooit opgestart. Le processus Handle Inbound est géré par le Responsible et permet d initier toutes les activités liées au traitement complet des rectifications inbound. Ce processus fait partie du processus global Handle Process et fait toujours suite au processus de Request Request dans lequel le Responsible effectue un premier traitement plus ou moins générique sur la demande entrante. A l issue de ce traitement, le Responsible accepte ou rejette la demande. Si la demande est acceptée, le processus Handle Inbound est déclenché. Si la demande est rejetée, le processus Handle Inbound ne sera jamais déclenché. UMIG - BR - ST v6.5 24/76

25 Het proces Handle Inbound bestaat uit drie subprocessen: - Request Approval to Impacted Party: proces waarbij het akkoord gevraagd wordt van iedere partij die getroffen zou worden door de eventuele verwerking van de rectificatie; - Handle Rejection of Request : proces waarbij een Negative Closing Ticket wordt gestuurd naar de Initiator en het globale Handle Inbound proces wordt geeindigd indien een of meer getroffen partijen niet akkoord zijn gegaan met de verwerking van de rectificatie (Failure). - Handle : proces dat de eigenlijke verwerking van de rectificatie omvat (Undo/Redo-principe, enveloppeprincipe enz.). Aan het einde van dit proces is de verwerking van de aanvraag voltooid. De afloop kan positief (Positive Closing Ticket) of negatief (Negative Closing Ticket) zijn. Le processus Handle Inbound se compose de trois sous-processus : - Request Approval to Impacted Party: processus dans lequel un accord est demandé à chaque partie impactée par le traitement de la rectification, si ce traitement devait avoir lieu ; - Handle Rejection of Request : processus dans lequel si une ou plusieurs des parties impactées ont marqué leur désaccord pour le traitement de la rectification (failure), un negative closing ticket est envoyé à l Initiator et le processus global Handle Inbound s achève. - Handle : processus dans lequel le traitement proprement dit de la rectification a lieu (principe d undo-redo, principe d enveloppe,...). A l issue de ce processus, le traitement de la demande est terminé et l issue peut soit être positive (positive closing ticket) soit négative (negative closing ticket). Procesverloop - Déroulement de la procédure Figure 8 - Activity Handle Inbound v1.0 UMIG - BR - ST v6.5 25/76

26 Request Approval to Impacted Party Proces definitie Définition du Proces Figure 9 - Use Case Request Approval To Impacted Party v1.1 Het proces Request Approval to Impacted Party speelt zich af tussen de Responsible en een of meer Impacted Parties (partijen die getroffen zouden worden door de verwerking van de aanvraag van de Request ). Het kan opgedeeld worden in drie hoofdstappen: - Nagaan of er al dan niet Impacted Parties zijn - Indien er minstens één Impacted Party wordt gevonden, zal de Responsible een akkoordaanvraag aanmaken en verzenden; - Ontvangen van de antwoorden van iedere Impacted Party en verwerking van hun feedback. Le processus Request Approval to Impacted Party se déroule entre le Responsible) et une ou plusieurs Impacted Party (partie impactée si le traitement de la demande de Request devait avoir lieu). Il peut être divisé en trois étapes principales : - Vérification de la présence ou non d Impacted Parties - Si au moins une Impacted Party est déterminée, création et envoi d une demande d accord par le Responsible; - Réception des réponses de chaque Impacted Party et traitement de leur feedback. Aan het einde van dit proces weet de Responsible of hij al of niet verder kan gaan met de verwerking van de rectificatieaanvraag. Na afloop van dit proces zal in ieder geval het proces Handle Rejection of Request (indien minstens één Impacted Party niet akkoord gaat) of het proces Handle (indien de Responsible bij de verwerking van de feedback concludeert dat alle Impacted Parties hebben ingestemd met de verwerking van de rectificatieaanvraag of indien de Responsible vaststelt dat er geen Impacted Party is) gestart worden. A l issue de ce processus, le Responsible sait s il peut ou non aller plus loin dans le traitement de la demande de Request. Dans tous les cas, suite à ce processus, le processus Handle Rejection of Request (dans le cas du désaccord d au moins une Impacted Party) ou le processus Handle (si le Responsible lors du traitement des feedbacks détermine que toutes les Impacted Parties ont marqué d une façon ou d une autre leur accord pour le traitement de la demande de Request ou si le Responsible détermine qu il n y a pas d Impacted Party) sera déclenché. UMIG - BR - ST v6.5 26/76

27 6.3.2 Procesverloop - Déroulement de la procédure Figure 10 - Activity Request Approval To Impacted Party v1.0 UMIG - BR - ST v6.5 27/76

28 6.3.3 Procesomschrijving Description des procédures Startsignaal: Dit subproces wordt gestart zodra er een inbound rectificatieaanvraag (Request Inbound) werd geaccepteerd en geregistreerd. Est initié quand : Ce sous-processus est initié dès qu une demande de Request inbound a été acceptée et enregistrée. Pre-requisites: De Responsible heeft een inbound rectificatieaanvraag geaccepteerd en geregistreerd. De Initiator van deze aanvraag is op de hoogte gesteld van deze aanvaarding doordat de Meter Point Administrator een bericht van het type ST-INT-9 (open) verzonden heeft met vermelding van het ticketnummer dat zal worden gebruikt voor de verwerking van de rectificatieaanvraag. Pré-requis: Le Responsible a accepté et enregistré une demande de Request inbound. L Initiator de cette demande a été averti de l acceptation de celle-ci via l envoi par le Meter Point Administrator d un message de type ST-INT-9 (open) accompagné du numéro de ticket qui sera utilisé pour le traitement de la demande de Request. Eindigt wanneer: Ofwel moet er geen akkoord gevraagd worden aan Impacted Parties. In dat geval neemt het proces direct een einde, zodat er kan worden voortgegaan met het proces Handle. Ofwel is het akkoord van een of meer partijen vereist en gevraagd en concludeert de Responsible bij de verwerking van de feedback van de Impacted Parties na RR1 (zie referentiedocument [7]) dat deze allemaal op een of andere manier hun akkoord gegeven hebben voor de verwerking van de rectificatieaanvraag. Als dat het geval is, neemt het proces een einde, zodat er kan worden voortgegaan met het proces Handle. Ofwel is het akkoord van een of meer partijen vereist en gevraagd en concludeert de Responsible bij de verwerking van de feedback van de Impacted Parties dat minstens een van hen niet akkoord gaat met de verwerking van de rectificatieaanvraag. In dat geval neemt het proces een einde en wordt er voortgegaan met het proces Handle Rejection of Request. Se termine lorsque: Soit aucun accord ne doit être demandé à des Impacted Parties dans quel cas le processus s achève directement pour continuer vers le processus Handle. Soit un ou plusieurs accords sont nécessaires et demandés, et après RR1 (voir document de référence [7]), le Responsible lors du traitement des feedbacks des Impacted Parties détermine qu elles ont toutes marqué d une façon ou d une autre leur accord pour le traitement de la demande de Request Parties dans quel cas le processus s achève pour continuer vers le processus Handle. Soit un ou plusieurs accords sont nécessaires et demandés, et le Responsible lors du traitement des feedbacks des Impacted Parties détermine qu au moins l une d entre elles a marqué son désaccord pour le traitement de la demande de Request Parties. Dans ce cas le processus s achève pour continuer vers le processus Handle Rejection of Request. Resultaat: Ofwel kan de aanvraag van de Initiator verwerkt blijven worden wanneer de Responsible heeft vastgesteld dat hij voor de behandeling een akkoord heeft ontvangen van de geïmpacteerde leverancier(s) of er geen akkoord noodzakelijk was. Of de aanvraag wordt verworpen door een van de geïmpacteerde leverancier(s) en de Initiator wordt in kennis gesteld. Résultat: Soit la demande de la partie initiatrice peut continuer à être traitée lorsque le Responsible a déterminé qu il avait reçu un accord pour le traitement du (des) fournisseur(s) impacté(s) ou qu aucun accord n était nécessaire. Soit la demande de la partie initiatrice est refusée par un des fournisseurs impactés et l initiateur en est avisé. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : UMIG - BR - ST v6.5 28/76

29 - De Responsible vergaart alle informatie die nodig is om te bepalen of er Impacted Parties zijn (Gather Actions Information) 3. - Indien de Responsible concludeert dat er geen enkele Impacted Party om toestemming gevraagd moet worden, neemt het proces een einde, zodat er kan worden voortgegaan met het proces Handle. - Indien de Responsible bepaalt dat er minstens één akkoord nodig is, zal hij een akkoordaanvraag ST-INT-10 opstellen en versturen naar iedere Impacted Party (Send Request Approval ) en ieder van deze partijen ontvangt de aanvraag en verwerkt deze eventueel (Receive Request Approval, Handle Request Approval, Send Positive Response, Send Negative Response). - Gedurende RR1 na de verzending van de akkoordaanvraagen worden alle antwoorden, zowel de positieve als negatieve (bericht ST-INT-11), ontvangen door de Responsible (Receive Positive Response, Receive Negative Response). Er wordt dus geen rekening gehouden met antwoorden die ontvangen worden na RR1. Als er van een Impacted Party geen antwoord ontvangen wordt, zal de Responsible deze stilte beschouwen als een positief antwoord. - Indien alle antwoorden ontvangen worden voor RR1 dagen, verwerkt de Responsible alle feedback (Process Feedback) en bepaalt hij hoe het verder moet: - Le Responsible rassemble toutes les informations nécessaires pour pouvoir déterminer si des Impacted Parties existent (Gather Actions Information) 4. - Si le Responsible détermine qu il n y a aucun accord d Impacted Party à demander, le processus s achève pour continuer vers le processus Handle. - Si le Responsible détermine qu il y a au moins un accord nécessaire, il prépare et envoie une demande d accord ST-INT-10 à chaque Impacted Party déterminée (Send Request Approval ) et chacune d entre elles reçoit la demande et la traite éventuellement (Receive Request Approval, Handle Request Approval, Send Positive Response, Send Negative Response). - Pendant RR1 suivant l envoi de ou des demandes d accord, toute réponse, soit-elle positive ou négative (message ST-INT-11), est reçue par le Responsible (Receive Positive Response, Receive Negative Response). Une réponse reçue après RR1 n est donc pas prise en compte. Aussi, si aucune réponse n est reçue de la part d une Impacted Party, le Responsible considèrera ce silence comme étant une réponse positive. - Si toutes les réponses sont reçues avant RR1 jours, le Responsible traite tous les feedbacks (Process Feedback) et détermine l issue adéquate : o alle Impacted Parties hebben op een of andere manier hun akkoord gegeven voor de verwerking van de rectificatie, in dat geval wordt het proces voltooid om door te gaan met het proces Handle. o toutes les Impacted Parties ont marqué d une façon ou d une autre leur accord pour le traitement de la rectification dans quel cas le processus s achève pour continuer vers le processus Handle. o Minstens één Impacted Party heeft aangegeven niet akkoord te gaan met de verwerking van de rectificatie. In dat geval wordt het proces beëindigd, om door te gaan met het proces Handle Rejection of Request. o au moins une Impacted Party a marqué son désaccord pour le traitement de la rectification dans quel cas le processus s achève pour continuer vers le processus Handle Rejection of Request. 3 Dit wordt mogelijk gemaakt middels de gebruikte rectificatiecode (zie referentiedocument [5]). 4 Cela est rendu possible au moyen du code de rectification utilisé (voir document de référence [5]). UMIG - BR - ST v6.5 29/76

30 6.3.4 Uitzonderingen/eigenheden - Exceptions / Caractéristiques Approval needed In de catalogus van de rectificatiecodes is terug te vinden welke inbound rectificatiecodes het akkoord van Impacted Parties kunnen vereisen. Handle Rejection of Request Approval needed Le catalogue des codes de rectification indique quels sont les codes de rectification inbound pouvant nécessiter l accord d Impacted Parties Process Definitie- Définition du Proces Figure 11 - Use Case Handle Rejection Of Request v1.0 Het proces Handle Rejection of Request speelt zich af tussen de Responsible en de Initiator van de rectificatieaanvraag. Dit proces volgt systematisch op het proces Request Approval to Impacted Party waarbij de Responsible heeft vastgesteld dat minstens één Impacted Party niet akkoord gaat met de verwerking van de rectificatieaanvraag. Via dit proces kan de Responsible de Initiator van de aanvraag op de hoogte stellen van de verwerping van zijn aanvraag (Negative Closing Ticket Request Denied). Aan het einde van dit proces is het proces Handle Inbound voltooid. Le processus Handle Rejection of Request se déroule entre le Responsible et l Initiator de la demande de Request. Ce processus fait systématiquement suite au processus Request Approval to Impacted Party dans lequel le Responsible a déterminé qu au moins une Impacted Party a marqué son désaccord pour le traitement de la demande de Request. Ce processus permet au Responsible de communiquer à l Initiator le rejet de sa demande (negative closing ticket Request Denied). A l issue de ce processus, le processus Handle Inbound s achève. UMIG - BR - ST v6.5 30/76

31 6.4.2 Procesverloop - Déroulement de la procédure Figure 12 - Activity Handle Rejection Of Request v Procesomschrijving Description des procédures Startsignaal: Ingevolge het proces Request Approval to Impacted Party heeft de Responsible vastgesteld dat minstens één Impacted Party niet akkoord gaat met de verwerking van de rectificatieaanvraag. Est initié quand : Suite au processus Request Approval to Impacted Party, le Responsible détermine qu au moins une Impacted Party a marqué son désaccord pour le traitement de la rectification. Pre-requisites: In het kader van het proces Request Approval to Impacted Party hebben een of meer Impacted Parties negatief geantwoord op de vraag of ze akkoord gingen met de verwerking van de rectificatieaanvraag. Pré-requis: Dans le cadre du processus Request Approval to Impacted Party, une ou plusieurs Impacted Parties ont répondu négativement à la demande d accord pour le traitement de la rectification. Eindigt wanneer: Een Negative Closing Ticket - Request Denied werd verstuurd naar de Initiator om deze ervan op de hoogte te brengen dat zijn rectificatieaanvraag (Request ) verworpen werd omdat een of meer Impacted Parties niet akkoord zijn gegaan. Se termine lorsque: Un negative closing ticket request denied a été envoyé à l Initiator pour lui communiquer le rejet de sa demande de Request étant donné le désaccord d une ou plusieurs Impacted Parties. UMIG - BR - ST v6.5 31/76

32 Resultaat: De Initiator wordt op de hoogte gebracht van de verwerping van zijn rectificatieaanvraag. Résultat: L Initiator est notifié du rejet de sa demande de Request. Verloop: Het proces verloopt als volgt: De Responsible genereert en stuurt een Negative Closing - Request Denied message (Send Ticket Processing Notification) naar de Initiator van de inbound rectificatieaanvraag, die deze mededeling ontvangt (Receive Ticket Processing Notification). Dit bericht bevat onder meer de ID van de weigerende partij. Déroulement: Le processus se déroule comme suit : le Responsible génère et envoie un negative closing request denied message (Send Ticket Processing Notification) à l Initiator de la demande de Request inbound qui la reçoit (Receive Ticket Processing Notification). Ce message contient entre autres l ID du parti refusant. UMIG - BR - ST v6.5 32/76

33 Handle Proces Definitie - Définition du Proces Figure 13 - Use Case Handle v1.0 Het proces Handle volgt systematisch op het proces Request Approval to Impacted Party wanneer de Responsible bepaald heeft dat de rectificatieaanvraag verwerkt kan worden. Dit stelt de Responsible in staat de rectificatie te verwerken en bestaat uit twee processen: - Handle Undo-Redo: proces dat de eigenlijke verwerking van de aanvraag omvat; - Handle Results: proces waarbij de afloop van de verwerking wordt meegedeeld aan de Initiator. Na afloop hiervan zijn de processen Handle en Handle Inbound voltooid. Le processus Handle fait systématiquement suite au processus Request Approval to Impacted Party dans lequel le Responsible a déterminé que le traitement de la rectification pouvait être apporté. Ce processus permet au Responsible de réaliser le traitement de la rectification et se compose de deux processus : - Handle Undo-Redo : processus dans lequel le traitement proprement dit de la demande est apporté ; - Handle Results : processus dans lequel l issue du traitement est communiquée à l Initiator. A l issue de ces processus, le processus Handle et Handle Inbound s achèvent. UMIG - BR - ST v6.5 33/76

34 6.5.2 Procesverloop - Déroulement de la procédure Figure 14 - Activity Handle v Handle Undo Redo Proces definitie - Définition du Proces Figure 15 - Use Case Handle Undo-Redo v1.0 Het proces Handle Undo Redo wordt uitgevoerd door de Responsible (die verantwoordelijk is voor de coördinatie van de rectificaties). Dit proces volgt op het proces Request Approval to Impacted Party. Le processus Handle Undo Redo est réalisé par le Responsible (le responsable de la coordination des rectifications). Ce processus fait suite au processus Request Approval to Impacted Party. Dit proces stelt de Responsible in staat de eigenlijke verwerking van de rectificatieaanvraag uit te voeren. Aan het einde van dit proces wordt het proces Handle Process voortgezet en start het proces Handle Results. Ce processus permet au Responsible de réaliser le traitement proprement dit de la demande de la rectification. A l issue de ce processus, le processus Handle Process se poursuit pour déclencher le processus Handle Results. UMIG - BR - ST v6.5 34/76

35 ProceProcesverloop - Déroulement de la procédure Procesomschrijving Description des procédures Startsignaal: Het proces Request Approval to Impacted Party is voltooid of bleek niet nodig en de Responsible heeft bepaald dat de eigenlijke verwerking van de rectificatie kan starten. Figure 16 - Activity Handle Undo-Redo v1.1 Est initié quand : Lorsque le processus Request Approval to Impacted Party est achevé ou n était pas nécessaire et que le Responsible a déterminé que le traitement proprement dit de la rectification pouvait démarrer. Pre-requisites: Pré-requis: Voor alle inbound rectificatieaanvragen is een voorafgaande voorwaarde Dans tous les cas de Request inbound, un pré-requis à ce voor de uitvoering van dit proces dat de rectificatieaanvraag geaccepteerd processus est que la demande de Request a été acceptée et en geregistreerd werd en dat de Initiator van de aanvraag een enregistrée et que l Initiator de cette demande a reçu un message ST-INT- acceptatiebericht ST-INT-3 ontvangen heeft. UMIG - BR - ST v6.5 35/76

36 In de gevallen waar nodig is het akkoord van de eventuele Impacted Parties gevraagd en de Responsible heeft bepaald dat er gestart kan worden met de verwerking van de rectificatie. 3 d acceptation. Dans les cas si nécessaire, l éventuel accord d Impacted Parties a été demandé et le Responsible détermine que le traitement de la rectification peut démarrer. Eindigt wanneer: De eigenlijke verwerking van de rectificatie heeft plaatsgevonden (Undo/Redo-principe). Se termine lorsque: Le traitement proprement dit de la rectification a été apporté (principe undo-redo). Resultaat: Het Undo/Redo-principe is toegepast. Résultat: Le principe undo-redo a été apporté. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Responsible analyseert de rectificatieaanvraag en verricht vervolgens en indien gewenst de verwerking die nodig is afhankelijk van het type rectificatieaanvraag (Rectify Data For Metering, Rectify Data For Gridfee, Rectify Data For Structure, Rectify Data For Settle), dit wil zeggen afhankelijk van de gebieden die getroffen worden door de aanvraag (Metering, GridFee, Structure, Settle). - De bewerking van een specifiek gebied zal, in de meeste gevallen, een actie vereisen van de distributienetbeheerder in het kader van één van zijn rollen (bijv. Meter Administrator indien rectificatie betrekking heeft op de Technical Master Data), naast de bewerkingen die uitgevoerd moeten worden door de Responsible. De verwerking van het gebied kan dan pas voltooid worden nadat de DNB zijn verwerking in het kader van zijn getroffen rol heeft voltooid en dit heeft meegedeeld aan de Responsible. - Als de verwerking van een gebied voltooid is, zal de Responsible controleren of er geen ander gebied getroffen is en ook behandeld moet worden. Als dat het geval is, wordt de verwerking herstart en dat tot alle getroffen gebieden verwerkt zijn. - De volgorde van alle ERR berichten (Undo-Redo) die naar de markt gestuurd moet worden in het kader van een rectificatieaanvraag, zal beslist worden door de Responsible. Na deze verwerking is het proces Handle Undo-Redo voltooid en wordt het proces Handle Results gestart. - Le Responsible analyse la demande de rectification et apporte ensuite et si requis le traitement nécessaire au type de la demande de rectification (Rectify Data For Metering, Rectify Data For Gridfee, Rectify Data For Structure, Rectify Data For Settle), c est-àdire en fonction du ou des domaines impactés par la demande (Metering, GridFee, Structure, Settle). - Le traitement d un domaine en particulier nécessitera, dans la plupart des cas, une action de la part du Gestionnaire de Réseau de Distribution dans le cadre d un de ses rôles (p.ex. Meter Administrator si la rectification concerne des Master Data Techniques) en plus de celle du Responsible. Le traitement du domaine ne pourra alors s achever que lorsque le GRD dans le cadre de son rôle impacté aura achevé le traitement et l aura communiqué au Responsible. - Lorsque le traitement associé à un domaine est terminé, le Responsible vérifiera si un autre domaine n est pas lui aussi impacté et doit être traité. Si tel est le cas, le traitement est redéclenché et ce jusqu à ce que l ensemble des domaines impactés ait été couvert. - L ordre de l ensemble des messages ERR (Undo-Redo) qui doivent être envoyés au marché, dans le cadre d une demande de rectification, sera déterminé par le Responsible. - Suite à ce traitement, le processus Handle Undo-Redo s achève et le processus Handle Results est déclenché. UMIG - BR - ST v6.5 36/76

37 6.5.4 Handle Results Proces Definitie - Définition du Proces Figure 17 - Use Case Handle Results v1.0 Het proces Handle Results speelt zich af tussen de Responsible en de Initiator. Dit proces volgt altijd op het proces Handle Undo-Redo. Le processus Handle Results se déroule entre le Responsible et l Initiator. Ce processus fait toujours suite au processus Handle Undo-Redo. Aan het einde van dit proces zijn de processen Handle en Handle Inbound & Spontaneous voltooid. A l issue de ce processus, les processus Handle et Handle Inbound & Spontaneous s achèvent. UMIG - BR - ST v6.5 37/76

38 Procesverloop - Déroulement de la procédure Figure 18 - Activity Handle Results v1.1 UMIG - BR - ST v6.5 38/76

39 Procesomschrijving Déscription des procédures Startsignaal: Dit subproces wordt gestart zodra er een rectificatieaanvraag behandeld is via het subproces Handle Undo-Redo. Est initié quand : Ce sous-processus est initié dès qu une demande de Request a été traitée via le sous-processus Handle Undo-Redo. Pre-requisites: Het subproces Handle Undo-Redo is beëindigd. Pré-requis: Le sous-processus Handle Undo-Redo est terminé. Eindigt wanneer: Wanneer de Initiator op de hoogte is gebracht van het gevolg dat gegeven is aan zijn aanvraag (verzending en ontvangst van een bericht ST-INT-9, Positive of Negative Closing Ticket - Request Not Treated) en, in het geval van een Positive Closing Ticket, wanneer hij alle berichten ontvangt die het voorwerp hebben uitgemaakt van een rectificatie (enveloppeprincipe). Se termine lorsque: L Initiator a été notifiée de l issue apportée à sa demande (envoi et réception d un message ST-INT-9, positive ou negative closing ticket request not treated) et, dans le cas d un positive closing ticket, reçoit l ensemble des messages rectifiés (principe d enveloppe). Resultaat: In het geval van een Positive Closing Ticket ontvangt de Initiator een bericht ST-INT-9 en wordt het enveloppeprincipe toegepast. In het geval van een Negative Closing Ticket - Request Not Treated ontvangen de Initiator een bericht ST-INT-9. Résultat: Dans le cas d un Positive Closing Ticket, un message ST-INT-9 est reçu de l Initiator et le principe d enveloppe appliqué. Dans le cas d un Negative Closing Ticket - Request Not Treated, un message ST-INT-9 est reçu de l Initiator. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Responsible controleert de afloop van de verwerking. - Le Responsible vérifie l issue du traitement. - Indien de verwerking een positieve afloop kent, wordt er een Positive Closing Ticket ST-INT-9 gegenereerd en gestuurd naar de Initiator (Send Positive Ticket Processing Notification) en ook een enveloppe met alle berichten die het voorwerp hebben uitgemaakt van de rectificatie (Send Rectified Data Envelop). De Initiator ontvangt deze (Receive Positive Ticket Processing Notification, Receive Rectified Data Envelop). Dan is het proces voltooid. - Si l issue est positive, un Positive Closing Ticket t ST-INT-9 est généré et envoyé à l Initiator (Send Positive Ticket Processing Notification) de même que l enveloppe contenant l ensemble des messages rectifiés (Send Rectified Data Envelop) qui les reçoit (Receive Positive Ticket Processing Notification, Receive Rectified Data Envelop). Le processus s achève alors. - Indien de verwerking een negatieve afloop kent, wordt er een Negative Closing Ticket - Request Not Treated ST-INT-9 gegenereerd en gestuurd naar de Initiator. Deze ontvangt dit bericht (Send Negative Ticket Processing Notification, Receive Negative Ticket Processing Notification). Dan is het proces voltooid. - Si l issue est négative, un Negative Closing Ticket - Request Not Treated ST-INT-9 est généré et envoyé à l Initiator qui le reçoit (Send Negative Ticket Processing Notification, Receive Negative Ticket Processing Notification). Le processus s achève alors. UMIG - BR - ST v6.5 39/76

40 Uitzonderingen/Eigenheden Exceptions/Caractéristiques Reden van Negative Closing Ticket In het bericht Negative Closing Ticket - Request Not Treated zal een Free text veld opgenomen zijn en zal door de Responsible kunnen ingevuld worden teneinde aan de markt aan te geven wat de reden is van de niet-verwerking van de aanvraag. Raison de negative closing ticket Un champ «Free text» sera prévu dans le message du negative closing ticket request not treated et pourra être rempli par le Responsible afin d indiquer au marché la raison de non traitement de la demande. Annulatie van een effectieve Mystery Switch Wanneer de aanvraag van een Request Inbound de annulatie van een reeds effectieve Mystery Switch betreft, is het mogelijk dat de configuratie of zelfs de gecontracteerde dienst op het ogenblik van de Mystery Switch verschillen van deze die van toepassing waren voor de switch. Annulation de Mystery Switch Effectif Lorsque la demande de Request Inbound concerne une annulation de Mystery Switch déjà effectif, il se peut que la configuration ou même le service contracté lors du Mystery Switch diffèrent de ceux d application avant le switch. Dit kan tot gevolg hebben dat de tengevolge van de behandeling van de rectificatieaanvraag opnieuw toegewezen meetgegevens onder een andere vorm aangeleverd worden dan deze gekend voor de mystery switch. De DNB zal immers niet steeds over de nodige gegevens beschikken om hem toe te laten de situatie te reconstrueren zoals in de starttoestand. Cela peut avoir comme conséquence que les données metering réattribuées suite au traitement de la demande de rectification soient fournies sous une autre forme que celle connue avant le mystery switch. En effet, le GRD ne disposera pas toujours des données nécessaires lui permettant de reconstruire la situation avec la situation connue au départ. Eveneens zal, tengevolge van de behandeling, de configuratie en of dienst mogelijk niet gelijkgesteld worden aan die zoals gekend voor de Mystery Switch. Daarvoor zou de Balance Supplier een aanvraag Update Customer Metering Configuration of Initiate Local Production moeten indienen. Aussi, suite au traitement, la configuration et ou le service ne devra pas être remis égal à ce qui était connu avant le Mystery Switch. Il faudra pour cela, que le Balance Supplier initie une demande d Update Customer Metering Configuration ou d Initiate Local Production. UMIG - BR - ST v6.5 40/76

41 7 Handle Outbound Proces definitie - Définition du Proces Figure 19 - Use Case Handle Outbound v1.0 Het proces Handle Outbound maakt deel uit van het globale proces Handle Process en wordt beheerd tussen de Responsible en een Impacted Party (de Balance Supplier die bevoegd is voor het toegangspunt waarop de rectificatieaanvraag betrekking heeft) en maakt het mogelijk alle activiteiten te starten die verband houden met de complete verwerking van de outbound rectificaties. Dit proces maakt deel uit van het proces Handle Process. Le processus Handle Outbound fait partie du processus global Handle Process et est géré entre le Responsible et une Affected Party (le Balance Supplier en charge du Point d Accès repris dans la demande de Request ) et permet d initier toutes les activités liées au traitement complet des rectifications outbound. Ce processus fait partie du processus Handle Process. UMIG - BR - ST v6.5 41/76

42 ProceProcesverloop - Déroulement de la procédure Figure 20 - Activity Handle Outbound v1.0 Procecesomschrijving Description des procédures Startsignaal: Als de Responsible een signaal ontvangt van een outbound rectificatie Est initié: Lorsque le Responsible reçoit un signal d une outbound Pre-requisites: Een afwijking of een fout in de relationele masterdata zoals opgegeven UMIG - BR - ST v6.5 42/76 Pré-requis: Une deviation ou erreur dans les masterdata relationnels comme spécifié

43 door de leverancier, werd geindentificeerd door de DNB, waardoor het proces van de outbound rectificatie start. par le fournisseur, a été identifié par le GRD, ce qui déclenche le processus rectification outbound Eindigt wanneer: De Responsible heeft een Positive of Negative Closing Ticket ontvangen van de Affected Party. Se termine lorsque: Le Responsible a reçu un positive ou negative closing ticket de l Affected Party. Resultaat: Voor outbound rectificaties heeft de Affected Party een kennisgeving van de aanvraag ontvangen en hierop positief of negatief gereageerd. Résultat: Pour les rectifications outbound, l Affected a été avertie de la demande et y a apporté une réponse positive ou négative. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Responsible (dit wil zeggen in dit geval de Meter Point Administrator) maakt de rectificatieaanvraag ST-INT-1 (Send Rectify Data For Outbound) over aan de Affected Party (dit wil zeggen de Balance Supplier die bevoegd is voor het toegangspunt waarvoor een outbound rectificatieaanvraag werd ontvangen) en deelt het ticketnummer dat is toegewezen aan deze aanvraag mee. Dit ticketnummer zal in het antwoord van de Affected Party (Balance Supplier), of het nu positief of negatief is (Positive of Negative Closing Ticket), gebruikt worden teneinde Responsible toe te laten de opvolging van de status van de aanvraag te verzekeren. - Le Responsible (c est-à-dire ici le Meter Point Administrator) transmet la demande de Request ST-INT- 1 (Send Rectify Data For Outbound) à l Affected Party (c est-à-dire le Balance Supplier en charge du Point d Accès pour lequel une demande de rectification outbound a été reçue) ainsi que le numéro de ticket associé à cette demande. Ce numéro de ticket sera utilisé dans la réponse de l Affected Party (Balance Supplier), qu elle soit positive ou négative (Positive ou Negative Closing Ticket), afin de permettre au Responsible d assurer un suivi du statut de la demande. - De Balance Supplier ontvangt deze informatie (Receive Rectify Data For Outbound) en verwerkt deze (Handle Request Rectify Date For Outbound). - Le Balance Supplier reçoit ces informations (Receive Rectify Data For Outbound) et les traite (Handle Request Rectifify Date For Outbound). - Na afloop van deze verwerking, start en stuurt de Balance Supplier ofwel een Negative Closing Ticket ST-INT-9, indien hij van mening is dat de aanvraag niet ontvankelijk is (Send Negative Response Rectify Data For Outbound), ofwel een Positive Closing Ticket ST- INT-9, indien de aanvraag ontvankelijk is en de rectificatie moet worden uitgevoerd (Send Positive Response Rectify Data For Outbound). - A l issue de ce traitement, le Balance Supplier initie et envoie soit un negative closing ticket ST-INT-9 s il estime que la demande n est pas recevable (Send Negative Response Rectify Data For Outbound), soit un positive closing ticket ST-INT-9 si la demande est recevable et qu une rectification doit être apportée (Send Positive Response Rectify Data For Outbound). - In beide gevallen ontvangt de Responsible het verzonden bericht (Receive Negative Response Rectify Data For Outbound, Receive Positive Response Rectify Data For Outbound) en behandelt het op de juiste manier.. - Dans les deux cas, le Responsible reçoit ce message s il est envoyé (Receive Negative Response Rectify Data For Outbound, Receive Positive Response Rectify Data For Outbound) et le traite adéquatement. UMIG - BR - ST v6.5 43/76

44 Uitzonderingen/eigenheden Exceptions/Caractéristiques Reden van Negative Closing Ticket Raisons de Negative Closing Ticket In het bericht Negative Closing Ticket - Request Not Treated is een veld opgenomen waarin de reden van de niet-verwerking van de aanvraag kan worden opgegeven. Un champ sera prévu dans le message du negative closing ticket request not treated afin d indiquer au marché la raison de non traitement de la demande insturen van gecorrigeerde Business Master Data introduction des Business Master Data corrigés Wanneer de Affected Party een positieve closing ticket verstuurt, betekent dit dat zij, zoals aangegeven in de aanvraag voor outbound rectificatie, de verkeerde Business Master Data zal corrigeren. Deze correctie vertaalt zich in de versturing van een aanvraag Update Business Master Data bericht of, in sommige gevallen, van een Start Access of Initiate Local Production. Deze versturing is niet beheerd in het kader van het Rectificatie proces, maar in het kader van de betrokken module. Er worden dus twee processen opgestart voor één enkele aanvraag. Echter, om een goede naspeurbaarheid tussen de processen te verzekeren, zal het positive closing ticket het Transaction ID van aanvraagbericht van de corrigerende module moeten bevatten. Lorsque l Affected Party envoie un positive closing ticket, cela signifie qu elle va comme indiqué dans la demande de rectification outbound, corriger les Business Master Data erronées. Cette correction se traduit par l envoi d une requête de Module Update Business Master Data ou, le cas échéant, d un Module Start Acces ou Initiate Local Production. Cet envoi n est pas géré dans le cadre du processus et est bien géré dans le cadre du module concerné, on voit donc deux processus déclenchés pour une seule demande. Néanmoins, pour garantir une bonne traçabilité entre les processus, le positive closing ticket devra contenir le Transaction ID de la requête du module «corrigeant»,. UMIG - BR - ST v6.5 44/76

45 8 Handle Spontaneous Figure 21 - Use Case Handle Spontaneous v1.0 Het proces Handle Spontaneous maakt deel uit van het globale proces Handle Process en wordt beheerd tussen de Responsible en een Impacted Party (de partij geïmpacteerd door de gerealiseerde spontane rectificatie en die daarom gecorrigeerde berichten moet ontvangen) en maakt het mogelijk alle activiteiten te starten die verband houden met de complete verwerking van de spontane rectificaties. Dit proces maakt deel uit van het proces Handle Process. Le processus Handle Spontaneous fait partie du processus global Handle Process et est géré entre le Responsible et une Affected Party (la partie affectée par la rectification spontanée réalisée et qui doit dès lors recevoir les messages rectifiés) et permet d initier toutes les activités liées au traitement complet des rectifications spontanées. Ce processus fait partie du processus Handle Process. UMIG - BR - ST v6.5 45/76

46 Procesverloop - Déroulement de la procédure Figure 22 - Activity Handle Spontaneous v1.1 Procesomschrijving Description des procédures Startsignaal: Als de Responsible een signaal heeft ontvangen van een spontane rectificatie Est initié quand : Lorsque le Responsible a reçu un signal de rectification spontanée. Pre-requisites: Een afwijking of een fout werd geïdentificeerd in een bericht verstuurd naar de markt door de verantwoordelijke partij van dit bericht, waardoor het proces van de spontane rectificatie start. Pré-requis: Une anomalie ou une erreur a été identifiée dans un message envoyé au marché par la partie responsable de ce message suite à laquelle le processus de rectification spontanée est mis en route. UMIG - BR - ST v6.5 46/76

47 Eindigt wanneer: De Responsible heeft een Positive Ticket en een envelope van gerectificeerde berichten naar de Affected Party gestuurd. Se termine lorsque: Le Responsible a envoyé un positive closing ticket et l enveloppe des messages rectifiés aux Affected Party. Resultaat: De Affected Party( s) hebben een Positive Closing Ticket ontvangen en de enveloppes verbonden met de spontane rectificaties zijn gerealiseerd. Résultat: La ou les Affected Party ont reçus les positive closing ticket et les enveloppes associées des rectifications spontanées ayant été réalisées. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Responsible verricht de verwerking die nodig is afhankelijk van het type rectificatie (Rectify Data For Metering, Rectify Data For Gridfee, Rectify Data For Structure, Rectify Data For Settle), dit wil zeggen afhankelijk van de domeinen die getroffen worden door de aanvraag (Metering, GridFee, Structure, Settle). - Als de verwerking van een domein voltooid is, zal de Responsible controleren of er geen ander domein getroffen is en ook behandeld moet worden. Als dat het geval is, wordt de verwerking herstart en dat tot alle getroffen domeinen verwerkt zijn. De volgorde van alle ERR berichten (Undo-Redo) die naar de markt gestuurd moeten worden, in het kader van de rectificatie, zal door de Responsible, conform het nettingprincipe, beslist worden. - Indien de verwerking van al de domeinen volledig afgehandeld is, wordt er een Positive Closing Ticket ST-INT-9 gestuurd naar de Affected Party (Send Positive Ticket Processing Notification) en ook een enveloppe met alle berichten die het voorwerp hebben uitgemaakt van de rectificatie (Send Rectified Data Envelop). De Affected Party ontvangt deze (Receive Positive Ticket Processing Notification, Receive Rectified Data Envelop). Dan is het proces voltooid - Le Responsible analyse la rectification à réaliser et apporte ensuite et si requis le traitement nécessaire au type de rectification (Rectify Data For Metering, Rectify Data For Gridfee, Rectify Data For Structure, Rectify Data For Settle), c est-à-dire en fonction du ou des domaines impactés par la demande (Metering, GridFee, Structure, Settle). - Lorsque le traitement associé à un domaine est terminé, le Responsible vérifiera si un autre domaine n est pas lui aussi impacté et doit être traité. Si tel est le cas, le traitement est redéclenché et ce jusqu à ce que l ensemble des domaines impactés ait été couvert. L ordre de l ensemble des messages ERR (Undo- Redo) qui doivent être envoyés au marché, dans le cadre de la rectification, sera déterminé par le Responsible conformément aux principes de netting. - Lorsque tous les domaines ont été traités, un positive closing ticket ST-INT-9 est généré et envoyé à ou aux Affected Party (Send Positive Ticket Processing Notification) de même que l enveloppe contenant l ensemble des messages rectifiés (Send Rectified Data Envelop) qui les reçoivent (Receive Positive Ticket Processing Notification, Receive Rectified Data Envelop). Le processus s achève alors. UMIG - BR - ST v6.5 47/76

48 Uitzonderingen/eigenheden Exceptions/Caractéristiques Rectificatie van de spontane rectificaties - de rectifications spontanées Een Balance Supplier die een spontane rectificatie wenst te betwisten, zal het kunnen doen via een andere aanvraag voor rectificatie, met de juiste code (zie referentiedocument [5]). Niettemin zal hij de initiële spontane rectificatie niet kunnen verwerpen. Un Balance Supplier souhaitant contester une rectification spontanée pourra le faire par une autre demande de rectification, avec le code adéquat (voir document de référence [5]). Néanmoins il lui sera impossible de rejeter cette rectification spontanée initiale Reden van spontane rectificaties - Raison de rectifications spontanées Teneinde de partij die geimpacteerd is door de spontane rectificatie te informeren over de reden van deze rectificatie, kunnen verschillende velden van het closing ticket gebruikt worden: - Catalogue code : de code uit de rectificatiecataloog naar dewelke de spontane rectificatie refereert ; - Free Text : een bijkomende toelichting over de reden van deze rectificatie; - Attachment: een toegevoegd document dat de aanvraag staaft of toelicht. Merk op dat minstens 1 van de velden " Catalogue Code" of "Free Text" ingevuld moet zijn. Afin d indiquer à la partie de marché impactée par une rectification spontanée, la raison de cette rectification, plusieurs champs du positive closing ticket pourront être complétés: - Catalogue code : le code du catalogue de rectification auquel la rectification spontanée réfère ; - Free Text : une indication supplémentaire de la raison de cette rectification ; - Attachment : une pièce jointe justifiant ou expliquant la rectification. Au moins 1 des champs Catalogue Code» ou «Free Text» doit être rempli. UMIG - BR - ST v6.5 48/76

49 9 Rollen Roles Figure 23 - Roles v1.1 UMIG - BR - ST v6.5 49/76

50 10 Annexes Rectificatie ingevolge betwisting ILC - suite à une contestation ILC De aanvragen van het type Start Access ingevolge een Initiate Leaving Customer kunnen een flag "Contestation ED ILC" (zie referentiedocument [8]) bevatten. De regel is dat iedere aanvraag van het type Start Access die niet voorzien is van deze flag, automatisch wordt gekoppeld aan de aanvraag van het type ILC, om geen "gat" te laten tussen het einde van het contract dat wordt geregistreerd via de ILC en het begin van het contract dat wordt geregistreerd met de Start Access. Met deze flag is het dus mogelijk de effectieve datum en de daaraan gekoppelde meterstand van de ILC te wijzigen, teneinde de Start Access te laten beginnen op de datum en de meterstanden die worden meegedeeld in de Start Access betwistingsaanvraag. Merk op dat, om de Start Access van betwisting te kunnen aanvaarden, deze aanvraag vergezeld moet zijn van een Energie Overname Document dat de reden van de betwisting bewijst. Les demandes de Start Access faisant suite à un Initiate Leaving Customer peuvent contenir un flag de «Contestation ED ILC» (voir document de référence [8]). En effet, sans ce flag, la règle est que toute demande de Start Access sera automatiquement rattachée à la demande d ILC afin de ne pas laisser de «trou» entre la fin du contrat enregistrée via l ILC et le début du contrat enregistré avec le Start Access. Avec ce flag, il est donc possible de modifier la date effective et l index associé de l ILC afin que le Start Access démarre à la date et aux index renseignés dans la demande de Start Access de contestation. A noter que, pour qu une demande de Start Access de contestation soit acceptée, celle-ci devra être accompagné d un Document de reprise des énergies attestant du fondement de la contestation. Figure 24 - Contestation Flag effect v1.0 t1 t2 (ILC) t3 (SA) t4 BS1 (ILC) Set 1 BS2 (SA) Set 2 A B C Figure 25 Contestation Flag effect Use case v1.0 UMIG - BR - ST v6.5 50/76

51 Het effect van deze betwisting is automatisch: als de Start Access met betwisting door de Meter Point Administrator is aanvaard, ziet de Balance Supplier van de ILC automatisch de datum van de beëindiging van zijn verantwoordelijkheid over het Toegangspunt verschuiven naar de effectieve datum van de Start Access en hij ziet ook de index van Start Access van betwisting. Echter, de Balance Supplier die de betwisting ondergaat, i.e. de Balance Supplier van de ILC, zal op basis van de informatie die hij ontvangen heeft in de betwisting (in aanvragen van het type Start Access met geactiveerde betwistingsflag moet opgegeven worden welke oude klant en welke Balance Supplier geacht worden actief te zijn op het toegangspunt) en de informatie die hij heeft kunnen vergaren in het kader van de verhuizing (ILC met overnameformulier), ook de nieuwe situatie kunnen betwisten die aan hem wordt opgelegd. Tussentijds volume opnieuw toewijzen aan een derde Balance Supplier (ST12) De Balance Supplier die de betwisting ondergaat, kan dit doen door contact op te nemen met de tussenliggende Balance Supplier teneinde hem te vragen om het volume tussen de Effective Date van de ILC en die van de Start Access voor zijn rekening te nemen. De tussenliggende Balance Supplier zal dan een inbound rectificatieaanvraag met de code ST12 "Rectificatie ingevolge betwisting ILC" kunnen starten door te verwijzen naar de aanvraag van het type ILC waaraan de betwisting gekoppeld is. Op basis van de informatie waarover de Meter Point Administrator beschikt in zijn systemen (ILC voorafgaand aan betwisting en Start Access), zal hij de situatie op een gepaste manier kunnen verwerken. De verwerking van een dergelijke aanvraag heeft de volgende hertoewijzing tot gevolg. L effet de cette contestation est automatique : si le Start Access de contestation est accepté par le Meter Point Administrator, le Balance Supplier de l ILC voit automatiquement sa fin de responsabilité déplacée à la date effective du Start Access et l index du Start Access de contestation. Néanmoins, le Balance Supplier subissant la contestation, i.e. le Balance Supplier ayant initié l ILC, pourra sur base des informations qu il aura reçu dans la contestation (les demandes de Start Access avec le flag de contestation activé doivent préciser l ancien client et Balance Supplier supposés actifs sur le Point d Accès) et des informations qu il aura pu récolter dans le cadre du déménagement (ILC avec PV de reprise), lui aussi contester cette nouvelle situation qui lui est imposée. Réattribuer le volume intermédiaire à un Balnce Supplier tiers (ST12) Le Balance Supplier subissant la contestation pourra faire cela en contactant le Balance Supplier intermédiaire afin de lui demander de prendre à sa charge le volume entre la date initiale de l ILC et celle du Start Access. Le Balance Supplier intermédiaire pourra alors initier une demande de Request avec code «suite contestation ILC» en référant à la demande de l ILC ayant subie la contestation. Sur base des informations que le Meter Point Administrator a dans ses systèmes (ILC avant contestation et Start Access), il sera à même de traiter adéquatement la situation. Le traitement d une telle demande aura comme conséquence la réattribution suivante. Figure 26 - of Contestation ST12 v1.0 Figure 27 ST12 Use case v1.0 UMIG - BR - ST v6.5 51/76

52 Volgorde Actie Referentie Initiator (BS3) 1 Redo TMD Set 1 2 Redo Util-TS B 3 Redo Util-VI B 4 Redo Util-FEE B 5 Initial Loss Affected Party (BS ILC) 1 Undo Loss (t3) 2 Initial Util-FEE B 3 Undo Util-VI B 4 Undo Util-TS B 5 Initial Loss (t2) Affected Party (BS SA) 1 Initial Util-FEE C 2 Undo Util-VI C 3 Undo Util-TS C 4 Redo TMD Set 2 4 Redo Util-TS C 5 Redo Util-VI C 6 Redo Util-FEE C Table 1 ST12 Closing Ticket v1.0 Figure 28 ST12 Messages v1.0 Het Closing Ticket bevat de volgende informatie: Volgorde Referentie (Transaction Id) Actie Document type Module Label Date From Date To Table 1 bevat de informatie voor volgorde, referentie en actie ter verduidelijking van de use case. Merk op dat de naam van het bericht waarnaar wordt gerefereerd hier enkel voor duidelijkheid van de use case wordt weergegeven. In een echt Closing Ticket zal hier de Transaction Id komen van het bericht waarnaar wordt gerefereerd. Le Closing Ticket contient l information suivante : Ordre Référence (transaction ID) Action Document type Module Label Date From Date To La Table 1 contient l information au niveau de l ordre, référence et action en vue de clarifier le use case. Notez que la dénomination du message auquel est fait référence ne figure ici que pour clarifier le use case. Dans un Closing Ticket «réel», la référence contiendra le Transaction ID du message référé. UMIG - BR - ST v6.5 52/76

53 Noteer dat de behandeling van een dergelijk aanvraag op geen enkele wijze de toestand zoals gekend door de Balance Supplier van de Start Access zal beïnvloeden (desalniettemin zullen hem berichten in verband met de behandeling van de rectificatieaanvraag toegestuurd worden, omwille van het principe van horizontale netting.). De Balance Supplier van de ILC zal rectificatieberichten ontvangen om het einde van zijn contract op de Effective Date van de Start Access ongedaan te maken en terug te zetten op de Effective Date van de ILC. De Balance Supplier die de Initiator was van de inbound rectificatieaanvraag ontvangt een volume bericht van Metering (inclusief Start Index en Eind Index). De datum van de Start Index stemt overeen met de ED van de ILC. De datum van de Eind Index stemt overeen met de ED van de Start Access. Ongegronde betwisting (ST13) De Balance Supplier die de betwisting ondergaat, kan de betwisting annuleren indien bijvoorbeeld de informatie die is ingevoerd in de aanvraag van het type Start Access van de betwisting niet correct is (bv. Energie Overname Document in attachment niet correct ingevuld). In een dergelijk geval zal hij een inbound rectificatieaanvraag met de code ST13 "Verwerping van betwisting ILC" starten met verwijzing naar de Start Access. De Meter Point Administrator is in staat op basis van deze informatie de situatie te verwerken en de gevolgen van de betwisting van de Start Access te annuleren. De situatie na deze verwerking is dan als volgt: A noter que le traitement d une telle demande n impacte en rien la situation connue du Balance Supplier du Start Access (néanmoins des messages liés au traitement de la demande de rectification lui seront envoyés, suite au principe de netting horizontal). Par contre, quant au Balance Supplier de l ILC, il recevra les messages de rectification en vue d enlever la date de fin de son contrat à la date effective du Start Acces, et de la remettre à la date effective de l ILC. Le Balance Supplier initiateur de la demande de Request recevra quant un messages metering lui indiquant le volume qui correspond à sa période de fourniture (y inclus les Index Start et Final). La date du Start Index correspond à la date effective de l ILC. La date du End Index correspond à la date effective du Start Access. Contestation non fondée (ST13) Le Balance Supplier subissant la contestation pourra également faire cela en annulant la contestation si par exemple les informations saisies dans la demande de Start Access de contestation ne sont pas cohérentes (p.ex. Document de reprise des énergies en attachment incorrectement complété). Dans un tel cas, il initiera une demande de Request avec code «Rejet de contestation ILC» et référant à la demande du Start Access de contestation. Sur base de ces informations, le Meter Point Administrator sera à même de traiter la situation et annulera l effet de contestation du Start Access. La situation après ce traitement sera la suivante : Figure 29 of contestation ST13 v1.0 UMIG - BR - ST v6.5 53/76

54 C Affected Party (BS SA) Initiator (BS ILC) Closing FEE C ERR Credit TS B ERR TS C ERR VI B ERR VI C ERR RR ST13 Closing Loss FEE B ERR Credit TMD Set 2' ERR MPA Figure 30 ST13 Use Case v1.0 Volgorde Actie Referentie Initiator (BS ILC) 1 Undo Loss (t3) 2 Initial Util-FEE B 3 Undo Util-VI B 4 Undo Util-TS B 5 Initial Loss (t2) Affected Party (BS ILC) 1 Initial Util-FEE C 2 Undo Util-VI C 3 Undo Util-TS C 4 Redo TMD Set 2 5 Redo Util-TS B 6 Redo Util-TS C 7 Redo Util-VI B 8 Redo Util-VI C 9 Redo Util-FEE B 10 Redo Util-FEE C FEE B ERR FEE C ERR Table 2 ST13 Closing Ticket v1.0 Figure 31 ST13 Messages v1.0 UMIG - BR - ST v6.5 54/76

55 De Balance Supplier die zijn Start Access met betwistingsflag ziet veranderen in een Start Access zonder flag ontvangt berichten van spontane rectificatie met als vrije tekst de vermelding "Betwisting geannuleerd". Als deze Balance Supplier zijn aanvraag van het type Start Access met betwisting wil herstarten, moet hij zijn Start Access annuleren (via een Request met de code ST-11) en een nieuwe Start Access met betwistingsflag starten en daarbij de velden behoorlijk invullen. De Balance Supplier van de ILC zal daarentegen rectificatieberichten ontvangen om het einde van zijn contract op de Effective Date van de Start Access ongedaan te maken en terug te zetten op de Effective Date van de ILC. Table 2 bevat de informatie voor volgorde, referentie en actie in het Closing Ticket ter verduidelijking van de use case. Le Balance Supplier voyant son Start Access de contestation ramené à un Start Access sans flag recevra des messages de rectification spontanée (Start Index, ED, ) avec comme free text une mention indiquant «Contestation annulée». Si ce Balance Supplier souhaite néanmoins ré-initier sa demande de Start Access de contestation, il devra annuler son Start Access (via un Request code ST-11) et relancer un nouveau Start Access avec le flag de contestation et remplir les champs de façon adéquate. Le Balance Supplier de l ILC, par contre, recevra des messages de rectification en vue d enlever la date de fin de son contrat à la date effective du Start Access, et de la remettre à la date effective de l ILC. La Table 2 contient l information au niveau de l ordre, référence et action en vue de clarifier le use case. UMIG - BR - ST v6.5 55/76

56 Verandering van Asset met nood aan een UTIL-TS zonder wisselwerking met oude Time Slices - Changements d Asset avec besoin d un UTIL-TS sans interaction avec anciens TimeSlices Voorbeeld: verandering van meter gestart via een module Update TMD (niet via Request ) zonder activering van spontane rectificaties, aangezien er nog geen billingrelevant volume was uitgestuurd op de ED van de verandering van meter. Dit voorbeeld toont het verschil aan dat bestaat tussen een update bericht en een rectificatiebericht. De Technical Master Data zijn per definitie van toepassing tot in de oneindigheid tenzij een andere set van Technical Master Data ontvangen is en dan wordt deze laatste van toepassing tot in de oneindigheid. Exemple : changement de compteur initié via un module Update TMD (pas via Request ) sans déclenchement de rectifications spontanées, puisqu aucun volume billingrelevant n avait encore été envoyée à la date effective due changement de compteur. Cet exemple met en évidence la distinction qu il existe entre un message de mise à jour et un message de rectification. Les Master Data techniques sont par définition valables jusqu à l infini à moins qu un autre set de Master Data techniques ne soit reçu et devienne celui valide jusqu à l infini. Changement Asset 01/07/11 01/08/11 01/09/11 01/07/11 01/08/11 01/09/11 Relationele slices Lev A Lev A Metering/gridfee slices B C B C D Technical MD Set 1 Set 1 Set 2 Figure 32 - Asset change v1.0 Impacted Party MPA Update TMD Set2 TS D Startindex UMIG - BR - ST v6.5 56/76

57 Verandering van Asset met nood aan een UTIL-TS met wisselwerking met oude Time Slice- Changements d Asset avec besoin d un UTIL- TS avec interaction avec ancien TimeSlice Voorbeeld: verandering van meter in het verre verleden gestart via een module Update TMD (niet via Request ) die heeft geleid tot de verzending van berichten ERR via het proces van de spontane rectificaties, aangezien er al een billingrelevant volume was uitgestuurd op de ED van de verandering van meter. Exemple : changement de compteur loin dans le passé initié via un module Update TMD (pas via Request ) avec comme conséquence l envoi de messages ERR via le processus de rectifications spontanées, puisqu il y avait déjà un volume billingrelevant envoyé à la date effective du changement de compteur. Figure 33 - Asset change with UTIL-TS v1.0 Het Closing Ticket zal de undo-informatie bevatten, alsook een referentie naar de credit berichten en een referentie naar de redo- en update-berichten (zie Table 3). In dit Closing Ticket zal ook worden aangegeven in welke volgorde de undoinformatie en de andere berichten verwerkt dienen te worden. Le Closing Ticket contiendra l information undo, ainsi que des références vers les messages crédit, et vers les messages update et redo (voir Table 3). Dans ce closing ticket il sera également indiqué dans quel ordre l information undo et les autres messages doivent être traités. UMIG - BR - ST v6.5 57/76

58 Volgorde Actie Referentie 1 Initial Util-FEE C 2 Undo Util-VI C 3 Undo Util-TS C 4 Redo TMD Set 2 5 Redo Util-TS C 6 Redo Util-TS C Figure 34 - Asset Change with UTIL-TS Messages v1.0 7 Redo Util-VI C 8 Redo Util-VI C 9 Redo Util-FEE C 10 Redo Util-FEE C Table 3 - Asset change with UTIL-TS Closing ticket v1.0 UMIG - BR - ST v6.5 58/76

59 Customer Switch in het verleden Customer Switch dans le passé Beginsituatie: Tussen 01/08/11 en 01/09/11 is er een TMD wijziging geweest, waarbij het volume C uitgestuurd werd. Het volgende volume D is eveneens al uitgestuurd wanneer de Start Access wordt aangevraagd. Eindsituatie: Alle volumes na de ED van de customer switch (C en D) worden weggenomen. De customer switch wordt uitgevoerd op ED 01/08/11, waarbij ook TMD Set 1 wordt uitgestuurd. De latere TMD wijziging blijft behouden, daarom wordt ook TMD Set 2 opnieuw uitgestuurd. Vervolgens worden nieuwe volumes C en D uitgestuurd. Situation à l origine: entre le 01/08/11 et le 01/09/11 un changement TMD s est produit, qui a généré l envoi d un volume C. Le volume suivant D a également déjà été envoyé quand le Start Access est demandé. Situation finale : tous les volumes après la Date Effective du Customer Switch (C et D) sont enlevés. Le Customer Switch est exécuté à la ED 01/08/11, date où le TMD set 1 est envoyé. Le changement TMD ultérieur reste d application, par conséquent le TMD Set 2 est également envoyé. Ensuite, les volumes C et D sont envoyés. Start acces Customer switch 01/07/11 01/08/11 01/09/11 01/07/11 01/08/11 01/09/11 Relationele slices Metering/VI/gridfee slices B Technical MD Set 1 Cust A Cust A Cust B Lev A C D Relationele slices Metering/VI/gridfee slices B Lev A C D Set 2 Technical MD Set 1 Set 2' Figure 35 - Customer Switch in the past v1.0 Volgorde Actie Referentie 1 Initial Util-FEE D 2 Initial Util-FEE C 3 Undo Util-VI D 4 Undo Util-VI C 5 Undo Util-TS D 6 Undo Util-TS C 7 Redo TMD Set 2 8 Redo Util-TS C 9 Redo Util-TS D 10 Redo Util-VI C 11 Redo Util-VI D 12 Redo Util-FEE C 13 Redo Util-FEE D Table 4 Customer Switch in the past Closing Ticket v1.0 UMIG - BR - ST v6.5 59/76

60 Correctie van UTIL-TS in het verleden Correction d un UTIL-TS dans le passé Voorbeeld : Rectificatie van meetgegevens voor Brussel (bijvoorbeeld aanpassing piekvermogen) voor een bepaalde periode in het verleden (spontane rectificatie, niet via Request ) met als gevolg het versturen van ERR berichten voor zowel de Util-TS als de Util-FEE en de Util-PSO vanaf de geïmpacteerde periode. Merk op dat dit voorbeeld hetzelfde blijft voor niet-spontane rectificaties via Request. Exemple : La rectification des données de comptage pour Bruxelles (par exemple puissance peak) pour une certaine période dans le passé (rectification spontanée non effectuée via le Request ) avec comme conséquence l envoi d un message ERR et Cancel aussi bien pour l Util-TS que pour l Util-FEE et l Util-PSO depuis la période impactée. Remarquez que cet exemple reste identique pour une rectification non spontannée effectuée via le module Request. Affected Party MPA Closing 01/07/11 01/08/11 01/09/11 Collateral rectification 01/07/11 01/08/11 01/09/11 PSO ERR C Credit PSO ERR B Credit FEE ERR C Credit FEE ERR B Credit TS ERR B TS ERR C Relationele slices Metering/VI/Gridfee/ PSO slices B Cust A Lev A Technical MD Set 1 Set 2 C B Cust A Lev A C Set 1 Set 2 VI ERR B VI ERR C FEE ERR B FEE ERR C PSO ERR B PSO ERR C Figure 36 - Collateral rectification v1.0 UMIG - BR - ST v6.5 60/76

61 Table 5 geeft weer welke informatie en referenties het Closing Ticket zal bevatten. La Table 5 reflète quelle information et références sont reprises dans le closing Ticket.. Volgorde Actie Referentie 1 Initial Util-PSO C 2 Initial Util-PSO B 3 Initial Util-FEE C 4 Initial Util-FEE B 5 Undo Util-VI C 6 Undo Util-VI B 7 Undo Util-TS C 8 Undo Util-TS B 9 Redo Util-TS B 10 Redo Util-TS C 11 Redo Util-VI B 12 Redo Util-VI C 13 Redo Util-FEE B 14 Redo Util-FEE C 15 Redo Util-PSO B 16 Redo Util-PSO C Correctie van de TRC Correction du TRC Table 5 - Collateral rectification - Closing ticket v Spontane Rectificatie Spontanée Voorbeeld: In het kader van een Move In werden transactiekosten aangerekend aan de Balance Supplier. Deze transactiekosten blijken foutief en dienen rechtgezet te worden. Exemple : dans le cadre d un Move In, des frais de transaction ont été imputés au Balance Supplier. Ces frais de transaction s avèrent erronées et doivent être corrigés. Affected Party MPA Closing TRC ERR MVI Credit TRC ERR MVI Figure 37 Spontaneous TRC v1.0 Volgorde Actie Referentie 1 Initial Util-TRC 2 Redo Util-TRC Table 6 Spontaneous TRC Closing Ticket v1.0 UMIG - BR - ST v6.5 61/76

62 Inbound Rectificatie Inbound Voorbeeld: in het kader van een Move In werden transactiekosten aangerekend aan de Balance Supplier. De Balance Supplier merkt dat deze transactiekosten foutief zijn, en stuurt een rectificatie aanvraag om deze recht te zetten. De MPA onderzoekt of de transactiekosten inderdaad gecorrigeerd dienen te worden. Indien wel, zal de MPA een Negative Closing, type No Treatment sturen, en vervolgens een spontane rectificatie opstarten om de transactiekosten te corrigeren. In het Negative Closing bericht, zal de MPA aangeven (via het No Treatment Reason veld) dat een spontane rectificatie volgt. Exemple : dans le cadre d un Move In, des frais de transaction ont été imputés au Balance Supplier. Les Balance Supplier voit que ces frais de transaction sont erronées, et il envoit une demande de rectification pour les corriger. Le MPA contrôle si les frais de transaction doivent effectivement être corrigés. Si oui, le MPA enverra un «Negative Closing», type «No Treatment», et déclencher ensuite une rectification spontanée pour corriger les frais de transaction. Dans le message «Negative Closing», le MPA indiquera (en utilisant le champ «No Treatment Reason») qu une rectification spontanée suit. Initiator MPA RR BI03 Negative Closing Inbound Positive Closing TRC ERR MVI Credit TRC ERR MVI Spontaneous Figure 38 Inbound for TRC v1.0 Volgorde Actie Referentie 1 Initial Util-TRC 2 Redo Util-TRC Table 7 Inbound TRC Positive Closing Ticket v1.0 UMIG - BR - ST v6.5 62/76

63 Cancel Process in het verleden (Mystery Switch) Mystery Switch na Start Access Voorbeeld: een Balance Supplier B heeft in het verleden een Combined Switch gestart, maar na de ED beslist hij deze toch maar te annuleren. In het onderstaande voorstel worden Time Slices C en C samengevoegd in één Time Slice C. Exemple : un Balance Supplier B a initié un Combined Switch dans le passé mais après l ED décide finalement de l annuler. Dans la proposition ci-dessous, les timeslices C et C sont fusionnés un seul timeslice C. 01/07/11 01/08/11 01/09/11 01/10/11 UNDO SA - CCSS 01/07/11 01/08/11 ED 01/09/11 01/10/11 RD Relationele slices Lev A Lev B Lev A Metering/gridfee slices B C C D B C D Technical MD Set 1 Set 1 Figure 39 - Mystery Switch Use Case 1 v1.0 UMIG - BR - ST v6.5 63/76

64 Volgorde Actie Referentie Affected Party 1 Undo Loss 2 Initial Util-FEE C 3 Undo Util-VI C 4 Undo Util-TS C 5 Redo Util-TS C 6 Redo Util-TS D 7 Redo Util-VI C 8 Redo Util-VI D 9 Redo Util-FEE C 10 Redo Util-FEE D Initiator 1 Initial Util-FEE D 2 Initial Util-FEE C 3 Undo Util-VI D 4 Undo Util-VI C 5 Undo Util-TS D 6 Undo Util-TS C 7 Initial Unsolicited Cancel SA Table 8 Mystery Switch Use Case 1 Closing Ticket v1.0 Als de Time Slices C en C niet kunnen worden samengevoegd, worden enkel C en D weggenomen en wordt voor C ook geen nieuw volume uitgestuurd. Si les timeslices C et C ne peuvent être fusionnés, alors uniquement C et D sont enlevés et aucun nouveau volume n est envoyé pour C. UMIG - BR - ST v6.5 64/76

65 Figure 40 Mystery Switch Use Case 2 v1.0 Volgorde Actie Referentie Affected Party 1 Undo Loss 2 Redo Util-TS C 3 Redo Util-TS D 4 Redo Util-VI C 5 Redo Util-VI D 6 Redo Util-FEE C 7 Redo Util-FEE D Initiator 1 Initial Util-FEE D 2 Initial Util-FEE C 3 Undo Util-VI D 4 Undo Util-VI C 5 Undo Util-TS D 6 Undo Util-TS C 7 Initial Unsolicited Cancel SA Table 9 Mystery Switch Use Case 2 Closing Ticket v1.0 UMIG - BR - ST v6.5 65/76

66 Mystery Switch na ILP waarbij de TMD wijziging kan worden teruggedraaid - Mystery Switch après ILP et la modification des TMD peut être annulée Indien Leverancier B een ILP in het verleden wil annuleren, zijn er twee mogelijke eindsituaties met betrekking tot de TMD. Ofwel wordt de TMD teruggedraaid naar de oorspronkelijke Set 1, ofwel is dit niet mogelijk en wordt de gewijzigde Set 2 naar Leverancier A gestuurd. Het voorbeeld hieronder gaat er vanuit dat de TMD wijziging ongedaan gemaakt is, maar dat de volumes C en C niet worden samengevoegd. Si le fournisseur B veut annuler un ILP dans le passé, alors il y a deux résultats possibles au niveau des TMD. Ou bien la modification des TMD est annulée et le set original est d application (set 1), ou bien l annulation n est pas possible et les TMD modifiés (set 2) sont envoyés vers le fournisseur A. L exemple ci-dessous part de l hypothèse que la modification TMD est annulée, mais que les volumes C et C ne sont past fusionnés. UNDO ILP 01/07/11 01/08/11 01/09/11 01/10/11 01/07/11 01/08/11 01/09/11 01/10/11 ED RD Relationele slices Lev A Lev B Lev A Metering/VI/gridfee slices A B C C D A B C C D Technical MD Set 1 Set 2 Set 1 Figure 41 - Mystery Switch Use Case 3 v1.0 UMIG - BR - ST v6.5 66/76

67 Volgorde Actie Referentie Affected Party 1 Undo Loss 2 Redo Util-TS C 3 Redo Util-TS D 4 Redo Util-VI C 5 Redo Util-VI D 6 Redo Util-FEE C 7 Redo Util-FEE D Initiator 1 Initial Util-FEE D 2 Initial Util-FEE C 3 Undo Util-VI D 4 Undo Util-VI C 5 Undo Util-TS D 6 Undo Util-TS C 7 Undo TMD Set 2 8 Initial Unsolicited Cancel ILP Table 10 - Mystery Switch Use Case 3 Closing Ticket v1.0 UMIG - BR - ST v6.5 67/76

68 Mystery Switch na ILP waarbij de TMD wijziging niet kan worden teruggedraaid 01/07/11 01/08/11 01/09/11 01/10/11 UNDO ILP 01/07/11 01/08/11 01/09/11 01/10/11 ED RD Relationele slices Lev A Lev B Lev A Metering/VI/gridfee slices A B C C D A B C C D Technical MD Set 1 Set 2 Set 1 Set 2 Figure 42 Mystery Switch Use Case 4 v1.0 Volgorde Actie Referentie Leverancier A 1 Undo Loss 2 Redo TMD Set 2 3 Redo Util-TS C 4 Redo Util-TS D 5 Redo Util-VI C 6 Redo Util-VI D 7 Redo Util-FEE C 8 Redo Util-FEE D Leverancier B 1 Initial Util-FEE D 2 Initial Util-FEE C 3 Undo Util-VI D 4 Undo Util-VI C 5 Undo Util-TS D 6 Undo Util-TS C 7 Undo TMD Set 2 8 Initial Unsolicited Cancel ILP Table 11 Mystery Switch Use Case 4 Closing Ticket v1.0 UMIG - BR - ST v6.5 68/76

69 Customer Switch met verandering van opname-/communicatiefrequentie van maandelijks naar jaarlijks- Customer Switch avec changement de fréquence de relève / communication de mensuelle à annuelle Bij een customer switch in het verleden waarbij de opname-/facturatiefrequentie verandert van maandelijks naar jaarlijks, moeten maandelijkse volumes die in de tussentijd uitgezonden waren, teruggedraaid worden. Pour un customer swtich dans le passé, ou la fréquence de relève/communication change de mensuelle vers annuelle, des volumes mensuels qui étaient envoyés entretemps, doivent être annulés. Figure 43 - Customer Switch in the past with Configuration change v1.1 Volgorde Actie Referentie Affected Party 1 Initial Util-FEE C 2 Initial Util-FEE B 3 Undo Util-VI C 4 Undo Util-VI B 5 Undo Util-TS C 6 Undo Util-TS B 7 Redo Util-TS B 8 Redo Util-VI B 9 Redo Util-FEE B Table 12 - Customer Switch in the past with Configuration Change Closing Ticket v1.0 UMIG - BR - ST v6.5 69/76

70 Combined Switch met wisselwerking met oude TimeSlice - Combined Switch avec interaction avec ancien timeslice Hetzelfde principe als reeds uitgelegd wordt toegepast: de TimeSlice B wordt verdeeld in 2 timeslices B en B om het begin van de verantwoordelijkheid van Supplier B weer te geven. Daarnaast wordt timeslice C geannuleerd en vervolgens terug aangemaakt om naar Balance Supplier B te sturen. Le même principe que celui précédemment expliqué est appliqué : le timeslice B est divisé en deux timeslices B et B pour refléter le début de responsabilité du Balance Supplier B. A côté de cela, le timeslice C est annulé puis recréé pour être envoyé au Balance Supplier B. Figure 44 - Combined Switch in the past (part2) v1.0 Volgorde Actie Referentie Affected Party 1 Initial Util-FEE C 2 Initial Util-FEE B 3 Undo Util-VI C 4 Undo Util-VI B 5 Undo Util-TS C 6 Undo Util-TS B 7 Redo Util-TS B 8 Redo Util-VI B 9 Redo Util-FEE B Initiator 1 Redo TMD Set 2 2 Redo Util-TS B 3 Redo Util-TS C 4 Redo Util-VI B 5 Redo Util-VI C 6 Redo Util-FEE B 7 Redo Util-FEE C Table 13 - Combined Switch in the past Closing Ticket v1.0 UMIG - BR - ST v6.5 70/76

71 Rectificatie van een AMR d un AMR Wijziging kwartierwaarden zonder rectificatie modification des valeurs quart-horaires sans rectification Use Case 1: Wijziging van kwartierwaarden (timeseries elektriciteit) waarvoor nog geen billingrelevant volume was uitgestuurd en nog geen dagaggregaties werden ontvangen. In dit geval worden de kwartierwaarden gewijzigd met een update, zonder rectificatie. Use Case 1: modification des valeurs quart-horaires (timeseries élec) pour lesquelles aucun volume billingrelevant n a encore été envoyé et les aggrégations journalières ne sont pas encore reçues. Dans ce cas, les valeurs quart-horaires sont modifiées par un update, sans rectification. Figure 45 - AMR Use Case 1 v Wijziging kwartierwaarden, dagaggregatie reeds uitgestuurd modification des valeurs quart-horaires après envoi de l aggrégation journalière Use Case 2: Wijziging van kwartierwaarden (timeseries elektriciteit) waarvoor nog geen billingrelevant volume was uitgestuurd, maar waarbij wel de dagaggregatie reeds was uitgestuurd. In dit geval worden de kwartierwaarden gewijzigd met een rectificatie-update en zal de Balance Supplier dus rectificatie-berichten ontvangen. Use case 2: modification des valeurs quart-horaires (timeseries élec) pour lesquelles aucun volume billingrelevant n a encore été envoyé, mais l aggrégation journalière a bien été envoyée. Dans ce cas, les valeurs quart-horaires sont modifiées par un update rectification. Le Balance Supplier recevra des messages de rectification. UMIG - BR - ST v6.5 71/76

72 Figure 46 - AMR Use Case 2 v1.0 Volgorde Actie Referentie 1 Update Timeseries 15 2 Update Timeseries 15 3 Update Daily aggregations 4 Update Daily aggregations Table 14 - AMR Use Case 2 Closing Ticket v Wijziging kwartierwaarden in een billingrelevant volume modification des valeurs quart-horaires d un volume billingrelevant In dit geval zal de Balance Supplier rectificatie-berichten ontvangen om het volume en de bijhorende gridfee (inclusief VI en eventueel PSO) weg te nemen. Vervolgens worden de kwartierwaarden gewijzigd met behulp van een rectificatie-update. Nadien worden de billingrelevante volumes opnieuw aangemaakt en uitgestuurd naar de Balance Supplier. Dans ce cas, la Balance Supplier recevra des messages de rectification en vue d enlever le volume et le Gridfee associé (y inclus VI et éventuellement PSO). Ensuite les valeurs quart-horaires sont modifiés à l aide d un update rectification. Puis les volumes billingrelevant sont recréés et envoyés au Balance Supplier. UMIG - BR - ST v6.5 72/76

73 Before rectification: Undo: Redo + -update 01/05/11 01/06/11 01/07/11 18/07/11 01/05/11 01/06/11 01/07/11 18/07/11 01/05/11 01/06/11 01/07/11 18/07/11 Gridfee GF1 GF2 Gridfee GF1 GF2 Gridfee GF1 GF2 Metering 15 min Metering 15 min Metering 15 min Metering Daily Metering Daily Metering Daily Metering Monthly CONS1 CONS2 Metering Monthly CONS1 CONS2 Metering Monthly CONS1 CONS2 Figure 47 - AMR Use Case 3 v1.0 Volgorde Actie Referentie 1 Initial Util-FEE Cons 2 2 Initial Util-FEE Cons 1 3 Undo Util-VI Cons 2 4 Undo Util-VI Cons 1 5 Undo Util-TS Cons 2 6 Undo Util-TS Cons 1 7 Update Timeseries 15 8 Update Timeseries 15 9 Update Daily aggregations 10 Update Daily aggregations 11 Redo Util-TS Cons 1 12 Redo Util-TS Cons 2 13 Redo Util-VI Cons 1 14 Redo Util-VI Cons 2 15 Redo Util-FEE Cons 1 16 Redo Util-FEE Cons 2 Table 15 - AMR Use Case 3 Closing Ticket v1.0 UMIG - BR - ST v6.5 73/76

74 Bundeling van Tickets Regroupement des Tickets Wanneer rectificatie-aanvragen worden ontvangen die gerelateerd zijn, kunnen deze aanvragen op initiatief van de DGO worden gebundeld. De aanvragen worden dan behandeld in één ticket, het Master ticket. Het gerelateerde Slave ticket wordt negatief afgesloten. In onderstaand voorbeeld worden rectificatie-aanvragen ontvangen van 2 Balance Suppliers die gerelateerd zijn, omdat ze betrekking hebben op hetzelfde Headpoint. De rectificatie zal worden behandeld in de rectificatie-aanvraag van Initiator 1 onder het Master ticket CMS-ID-001. Het Slave ticket CMS-ID-002 dat werd aangemaakt voor de rectificatie-aanvraag van Initiator 2 zal negatief worden gesloten met reason Not treated en een referentie naar het Master ticket CMS-ID-001. Initiator 2 zal indien nodig rectificatie-berichten ontvangen in het kader van een spontane rectificatie met ticketnummer CMS-ID-001. Quand plusieures demandes de rectification sont reçues, qui sont relatées, alors ces requêtes peuvent être regroupées à l initiative du DGO. Les requêtes sont alors traitées dans un seul ticket, le Master ticket. Le Slave ticket est clôturé par un close négatif. Dans l exemple ci-dessous, deux requêtes de rectification sont reçues de deux Balance Suppliers. Elles sont reliées puisqu elles se rapportent au même Headpoint. La rectification sera traitée dans la requête de rectification d un initiateur 1 sous le Master ticket CMS-ID-001. Le Slave ticket CMS-ID-002 qui a été créé pour la requête de rectification de l Initiator 2 sera clôturé négativement avec raison not treated et une référence au Master ticket CMS-ID-001. L Initiator 2 recevra, si nécessaire, les messages de rectification dans le cadre d une rectification spontanée avec comme numéro de ticket CMS-ID-001. Figure 48 - Ticket Bundling v1.0 UMIG - BR - ST v6.5 74/76