UMIG 6.0 Marktprocessen Processus de marché. Business Requirements Structure Initiate Request

ATRIAS Market Processes UMIG 6.0 Marktprocessen Processus de marché Business Requirements Structure Versie v3.4 / Version v3.4 Voor implementatie / Pour implémentation UMIG 6.0 - BR - ST - 03 - v3.4

1 DOCUMENT VERSIES VERSIONS DU DOCUMENT... 4 1.1 Versie overzicht - Gestion des versions... 4 1.2 Referenties Références... 6 2 CONTEXT - CONTEXTE... 8 2.1 Scope... 8 2.2 Concepten en begrippen Concepts et définitions... 8 3 INITIATE REQUEST... 9 3.1 Proces definitie Définition du Proces... 9 3.2 Procesverloop Déroulement de la procédure... 10 3.3 Procesomschrijving Description des procédures... 10 3.4 Uitzonderingen / Eigenheden - Exceptions / Caractéristiques... 12 3.4.1 Mass Switching... 12 3.4.2 Ex-Ante Testen Tests Ex-Ante... 12 3.4.3 Flags... 13 4 ADDENDUM... 14 4.1 Flags... 14 4.1.1 Introductie Introduction... 14 4.1.2 De verschillende types flags Les différents types de flag... 15 4.1.3 «Request Unlock» Flag... 16 4.1.4 «Desynchronization (SH3)» Flag... 17 4.1.5 «Contestation ED ILC» Flag... 18 4.1.6 «Take Over ILC» Flag... 21 4.2 Update Business Master Data... 22 4.2.1 Timeslicing... 22 4.2.2 Initiator... 22 4.2.3 Outbound Rectification... 23 4.3 Initiate Local Production... 23 4.3.1 Gebruik van labels Utilisation des labels... 23 UMIG 6.0 - BR - ST - 03 - v3.4 2/25

4.4 Initiate Update Access... 24 4.4.1 Effectieve datum - Date effective... 24 5 TABELLEN & INDEXEN TABLES & INDEXES... 25 5.1 Begrippenlijst Glossaire... 25 5.2 Table of Figures... 25 UMIG 6.0 - BR - ST - 03 - v3.4 3/25

1 Document versies Versions du document 1.1 Versie overzicht - Gestion des versions Versie - Version Datum - Date Auteur Beschrijving - Description v1.0 23/11/2012 Atrias MPP MIG6 Project Team v2.0 29/03/2013 Atrias MPP MIG6 Project Team Eerste versie van de Business Requirement Première version du Business Requirement Versie 2 van de Business Requirement na integratie van de feedback aangeleverd door de Business Analisten en Subject Matter Experten van de Net User Interactions werkgroep Version 2 du Business Requirement après l intégration du feedback donnée par le Business Analystes et les Subject Matter Experts du groupe de travail Net User Interactions V3.0 30/06/2013 Atrias MPP MIG6 Project Team V3.1 28/02/2014 Atrias MPP MIG6 Project Team V3.2 31/07/2014 Atrias MPP MIG6 Project Team V3.3 30/06/2015 Atrias MPP MIG6 Project Team V3.3.1 30/09/2015 Atrias MPP MIG6 Project Team Versie 3 ter consultatie Version 3 pour consultation Versie 3.1 ter consultatie Version 3.1 pour consultation Versie 3.2 ter consultatie Version 3.2 pour consultation Versie 3.3 ter consultatie Version 3.3 pour consultation Versie 3.3.1 ter consultatie Version 3.3.1 pour consultation V3.4 31/01/2016 Atrias MPP MIG6 Versie 3.4 voor implementatie UMIG 6.0 - BR - ST - 03 - v3.4 4/25

Project Team Version 3.4 pour implémentation UMIG 6.0 - BR - ST - 03 - v3.4 5/25

1.2 Referenties Références Referentie Référence UMIG 6.0 - GE - XD - 01 - Introduction [1] Omschrijving - Description Bevat een algemene inleiding over de marktprocessen en over de globale concepten die in de verschillende marktprocessen worden gebruikt. Contient une introduction générale aux processus de marché et sur les concepts globaux utilisés dans les différents processus de marché. UMIG 6.0 - BR - ST - 02 - Structuring Process [2] Inleidend document inzake de Structuring marktprocessen: basisbeginselen, mapping MIG4 versus MIG6, definitie en toepassing van de verschillende processen. Document d'introduction aux processus de marché Structuring : concepts de base, mapping MIG4 versus MIG6, définition et application des différents processus. UMIG 6.0 - BR - ST - 03 Handle_Request [3] UMIG 6.0 - BR - ST - 04 - Exchanged Information [4] Document dat het beheersproces beschrijft van een Structuring aanvraag door de markt na de behandeling van het proces. Document décrivant le processus de gestion d'une demande Structuring par le marché ayant subie le premier traitement du processus. 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. UMIG 6.0 - BR - ME - 03 Request Metering [5] Document dat alle processen beschrijft van verzoek om meetgegevens door de markt. Het verzoekproces is gericht op het verkrijgen van de meetgegevens zoals gewenst door de markt. Document qui dércrit l'ensemble des processus de requête de données metering par le marché. Le processus de requête consiste à l'obtention des données de comptage comme souhaitée par le marché. UMIG 6.0 - BR - ST - 04 Timings [6] 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. UMIG 6.0 - BR - ST - 03 - v3.4 6/25

Referentie Référence UMIG 6.0 - BR - ST - 03 Preswitching [7] UMIG 6.0 - BR - ST - 04 - Ex Post Monitoring [8] Omschrijving - Description 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-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. UMIG 6.0 - BR - ST - 04 - Ex Ante Tests [9] UMIG 6.0 - BR - ST - 03 - Rectifications [10] Matrix van alle ex-ante tests die verricht worden voor de verschillende Structuring aanvragen. Deze tests worden verricht in het proces. Matrice de l'ensemble des tests ex-ante effectués pour les différentes demandes Structuring. Ces tests sont effectuées dans le processus. Document dat het rectificatieproces beschrijft (inbound, outbound en spontaan). Document qui décrit le processus de rectification (inbound, outbound, spontanée). UMIG 6.0 - BR - ST - 03 - v3.4 7/25

2 Context - Contexte 2.1 Scope 2.2 Concepten en begrippen Concepts et définitions Figure 1 - Activity Main Structure v1.0 De meeste Structuring aanvragen draaien om twee hoofdprocessen: - : proces waarbij een aanvraag wordt opgestart door een marktpartij en een eerste behandeling ondergaat; - Handle Request : proces waarbij de aanvraag een reeks specifieke subprocessen doorloopt. Het onderhavige document gaat nader in op het proces. De Handle Request wordt behandeld in referentiedocument [3]. La plupart des demandes Structuring se déclinent autour de deux processus principaux : - : processus dans lequel une demande est initiée par une partie de marché et subit un premier traitement ; - Handle Request : processus dans lequel la demande génère une série de sous-processus spécifiques au type de la demande initiée. Le présent document développe plus en détails le processus. Le document traitant du processus Handle Request est le document de référence [3]. UMIG 6.0 - BR - ST - 03 - v3.4 8/25

3 3.1 Proces definitie Définition du Proces Figure 2 - Use Case v1.0 Het proces speelt zich af tussen de Meter Point Administrator (beheerder van de toegangspunten) en de Initiator (initiatiefnemer van de aanvraag). Zoals geïllustreerd in punt 2.1, is het proces het eerste proces dat wordt gelanceerd in het kader van de Structuring modules van MIG6 (zie referentiedocument [2]), ook al vereisen sommige types vragen niet de uitvoering van een maar enkel van het proces Handle Request. 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 Meter Point Administrator; - Kennisgeving van de verwerping of acceptatie door de Meter Point Administrator aan de Initiator. Le processus se déroule entre le Meter Point Administrator (Gestionnaire des Points d accès) et l Initiator (la partie initiatrice de la demande). Comme illustré dans la section 2.1, le processus est le premier processus à être lancé dans le cadre des modules Structuring du MIG6 (voir document de référence [2]) même si certains types de demande ne nécessitent pas son exécution mais seulement celle du processus Handle Request. 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 Meter Point Administrator ; - Notification du rejet ou de l acceptation par le Meter Point Administrator à l Initiator. Op het einde van dit proces en als de aanvraag is aanvaard, loopt het globale A l issue de ce processus et si la demande initiée est acceptée, le processus Structuring proces verder en komt in sommige gevallen het proces Handle Request global Structuring se poursuivra et pourra dans certains cas déclencher le op gang (zie referentiedocument [3]). Als de aanvraag echter wordt verworpen, dan processus Handle Request (voir document de référence [3]). Si par contre la stopt de uitvoering en volgt geen enkele andere actie meer. demande initiée est rejetée, l exécution de la demande s achève là et aucune UMIG 6.0 - BR - ST - 03 - v3.4 9/25

Het is belangrijk voor ogen te houden dat voor ieder begin van een aanvraag, met andere woorden voordat het proces op gang wordt gebracht, de Preswitching LIGHT functionaliteit (referentiedocument [7]) moet worden gebruikt indien de Initiator nog niet verantwoordelijk is voor het Toegangspunt. Indien de Initiator verantwoordelijk is voor het Toegangspunt, dan is de Preswitching FULL functionaliteit ten zeerste aanbevolen, maar zonder enige gebruiksverplichting omdat het niet-gebruik die zou leiden tot de verwerping van de aanvraag door de Initiator bovenal deze laatste zal treffen. 3.2 Procesverloop Déroulement de la procédure autre action n est entreprise. Il est important de garder à l esprit qu avant toute initiation de demande, autrement dit avant le déclenchement du processus, la fonctionnalité du Preswitching LIGHT (document de référence [7]) devra être utilisée lorsque l Initiator n est pas encore responsable du Point d Accès. Lorsque l Initiator est responsable du Point d Accès, la fonctionnalité du Preswitching FULL est fortement recommandée mais aucune obligation d utilisation ne sera prescrite étant donné qu une non-utilisation résultant au rejet de la demande de l Initiator pénalisera avant tout ce dernier. 3.3 Procesomschrijving Description des procédures Figure 3 - Activity v1.0 UMIG 6.0 - BR - ST - 03 - v3.4 10/25

Wordt opgestart wanneer: Dit subproces wordt opgestart zodra een marktpartij een nieuwe aanvraag lanceert, om een belangrijke gebeurtenis aan de markt bekend te maken: registratie van een nieuw contract, verhuizing van een party connected to the grid, bijwerking Business Master Data, Deze aanvraag wordt gematerialiseerd door verzending van een bericht ST-INT-1. Voorkennis: 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). Est initié quand : Ce sous-processus est initié dès qu une partie de marché initie une nouvelle demande afin de notifier au marché un événement notable : enregistrement d un nouveau contrat, déménagement d unparty connected to the grid, mise à jour de Business Master Data, Cette nouvelle demande est matérialisée par l envoi d un message ST-INT-1. 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). Eindigt wanneer: De aanvraag een eerste behandeling (ex-ante testen) heeft ondergaan en op basis daarvan hetzij verworpen, hetzij aanvaard is door de Meter Point Administrator. 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. Bij acceptatie wordt 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 registratie ervan in het toegangsregister. Se termine lorsque: La demande a subi un premier traitement (tests ex-ante) à l issue duquel, elle est soit refusée, soit acceptée par le Meter Point Administrator. 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. Resultaat: De aanvraag van de initiator wordt ofwel aanvaard,geregistreerd, en de partij in kennis gesteld. Of de aanvraag wordt verworpen en dus niet geregistreerd (maar wel gelogd), en de partij in kennis gesteld. Résultat: La demande de la partie initiatrice est soit acceptée, enregistrée et la partie avisée. Soit la demande n est pas enregistrée (mais bien loggée), est refusée et la partie avisée. 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 aan een reeks ex-ante tests (Receive Request, Test Request). - Le Meter Point Administrator reçoit le message et réalise une série de tests ex-ante dessus (Receive Request, Test Request). UMIG 6.0 - BR - ST - 03 - v3.4 11/25

Al deze tests zijn opgenomen in referentiedocument [9] en worden kort beschreven in punt 3.4.2. Het is belangrijk op te merken dat afhankelijk van de eventuele flags in het bericht ST-INT-1, de realisatie van deze ex-ante tests in verschillende stappen kan worden verricht (zie punt 4.1). - Naar gelang het resultaat van de op de aanvraag verrichte tests, zijn er twee mogelijkheden: L ensemble de ces tests est repris dans le document de référence [9] et est décrit de façon plus succincte dans la section 3.4.2. Il est important de noter qu en fonction des flags éventuels contenus dans le message ST-INT-1, la réalisation de ces tests ex-ante peut être réalisée en plusieurs étapes (voir section 4.1). - 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 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 referentiedocument [9]. 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 Initiate 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 sur la raison de ce code de rejet. Ces codes de rejet et leurs raisons sont repris dans le document de référence [9]. o De aanvraag wordt aanvaard, in welk geval de wijzigingen die voortvloeien uit de acceptatie van de aanvraag geregistreerd worden in het Toegangsregister (Handle Data Changes). Er wordt naar de Initiator een acceptatiebericht ST-INT-3 gestuurd (Send Response). Het bericht wordt door hem ontvangen (Receive Response), het proces eindigt hier en de behandeling van de aanvraag loopt verder als er nog stappen nodig zijn. Deze andere stappen vallen onder het proces Handle Request. o La demande est acceptée, dans quel cas les changements induits par l acceptation de la demande sont enregistrés dans le Registre d Accès (Handle Data Changes). Un message d acceptation ST-INT-3 est envoyé à l Initiator (Send Response). Le message est reçu par celui-ci (Receive Response), le processus se termine ici et le traitement de la demande peut continuer si d autres étapes sont nécessaires. Ces autres étapes sont gérées dans le processus Handle Request. 3.4 Uitzonderingen / Eigenheden - Exceptions / Caractéristiques 3.4.1 Mass Switching De lancering van de massa marktaanvragen volgen dezelfde logica als de lanceringen van de normale marktaanvragen. Dit betekent dat een marktpartij die een aanzienlijk aantal marktaanvragen van hetzelfde type wenst te initiëren, deze aanvragen één per één zal moeten lanceren en deze zullen op een normale manier verwerkt worden. Les lancements en masse de demandes de marché suivent la même logique que les lancements normaux de demandes de marché. Cela signifie qu une partie de marché souhaitant initier un nombre conséquent de demandes de marché du même type devra initier ces demandes une à une et que le traitement normal y sera apporté. 3.4.2 Ex-Ante Testen Tests Ex-Ante UMIG 6.0 - BR - ST - 03 - v3.4 12/25

Er worden vier categorieën ex-ante tests onderscheiden: A. Generieke tests: gemeenschappelijke tests voor ieder type aanvraag (bv. initiator gekend door de markt? uitwisselingsprotocol gerespecteerd?) ); B. Moduletests: tests eigen aan de werking van een module (bv. tijdsinterval voor het opstarten van een module (Cmin en Cmax), validatie XML Synthax Validator?); C. Specifieke tests: testen van de ontvankelijkheid van een aanvraag naar gelang het gebruikte label. Deze tests worden als specifiek aangemerkt in zoverre ze gebaseerd zijn op het label van een aanvraag, wat zoveel mogelijk te vermijden is om de in MIG6 voorgestelde modulaire aanpak te behouden ; D. Interactietests: testen van de al dan niet toegelaten interacties tussen de opgestarte module en in het toegangsregister al geregistreerde module(s) maar nog niet effectief. Quatre catégories de tests ex-ante sont distinguées : A. Les tests génériques : tests communs à presque tout type de demande (p.ex. initiateur connu du marché? protocole d échange respecté? ); B. Les tests de module : tests propres au fonctionnement d un module (p.ex. intervalle de temps pour le lancement d un module (Cmin et Cmax), validation XML Synthax Validator?) ; C. Les tests spécifiques : tests sur la recevabilité d une demande en fonction du label utilisé. Ces tests sont qualifiés de spécifique dans la mesure où ils se basent sur le label d une demande ce qui doit dans la mesure du possible être évité afin de conserver l approche modulaire proposée en MIG6 ; D. Les tests d interaction : tests sur les interactions permises ou non entre le module initié et celui ou ceux déjà enregistrés dans le registre d accès et encore non effectif. De volgorde waarin de tests worden beschreven, is die voorgesteld voor hun uitvoering (categorie A, dan B, dan C en ten slotte D). Het lijkt logisch om eerst na te gaan of de grondslagen van een aanvraag correct zijn, alvorens verder te gaan en bijvoorbeeld de interacties te controleren. Met andere woorden, als een aanvraag minstens één test binnen een categorie niet doorstaat, worden de tests van de volgende categorie niet verricht en bevat het verwerpingsbericht alleen de verwerpingscode(s) verbonden aan de niet doorstane test(s) binnen een categorie. L ordre indiqué pour la description des tests est celui proposé pour leur exécution (catégorie A, puis B, puis C et enfin D). En effet, il semble logique de vérifier que les bases d une demande sont correctes avant d aller plus loin et de vérifier par exemple les interactions. En d autres mots, si une demande échoue à au moins un test au sein d une catégorie, les tests de la catégorie suivantes ne seront pas réalisés et le message de rejet ne contiendra que le (ou les) code(s) de rejet lié(s) au(x) test(s) échoué(s) au sein d une catégorie. Ook merken we op dat afhankelijk van het type aanvraag, slechts bepaalde categorieën nodig kunnen zijn. Sommige verwerpingscodes zullen gepaard gaan met een aanvullende indicatie van de precieze reden van de verwerping. Referentiedocument [9] beschrijft alle tests die verricht worden per testcategorie en per type aanvraag (module), de bijbehorende verwerpingscodes en eventueel de redenen. Précisons aussi qu en fonction du type de demande (module), seules certaines catégories peuvent être nécessaires. Aussi, pour certains codes de rejet, des indications supplémentaires seront données afin d indiquer à l initiateur du message plus exactement la raison du code de rejet. Le document de référence [9] reprend l ensemble des tests effectués par catégorie de tests et par type de demande (module), les codes de rejet associés et éventuellement les raisons. 3.4.3 Flags Zie punt 4.1. Voir section 4.1. UMIG 6.0 - BR - ST - 03 - v3.4 13/25

4 Addendum 4.1 Flags 4.1.1 Introductie Introduction De flags zijn een nieuw concept ingevoerd in MIG6. Een flag biedt iedere initiator van een marktbericht de mogelijkheid om zijn hoofdaanvraag vergezeld te doen gaan van een bijkomende aanvraag, die van de flag. Afhankelijk van het type aanvraag, kunnen een of meer flags geactiveerd worden. Deze vereisen een bijzondere behandeling vanwege de Meter Point Administrator en de DNB. Les flags sont un nouveau concept introduit dans le MIG6. Par flag, est entendue la possibilité qu a l Initiator de faire accompagner sa demande de base par une demande annexe, celle du flag. En fonction du type de demande, un ou plusieurs flags pourront être activés et ceux-ci nécessiteront un traitement particulier de la part du Meter Point Administrator et du GRD. Het doel van deze flags is de marktwerking te versnellen door iedere Initiator die een nieuwe marktaanvraag wil lanceren die een bijzondere behandeling zou vereisen, de mogelijkheid te geven om samen met de basisaanvraag, de bijzondere behandeling aan te vragen (aangegeven door de geactiveerde flag). Le but de ces flags est d accélerer le fonctionnement du marché en laissant la possibilité à tout Initiator souhaitant initier une nouvelle demande de marché pour laquelle un traitement particulier devrait être apporté, de demander en même temps que la demande de base, celle du traitement particulier (indiqué par le flag activé). Afhankelijk van de gevraagde bijzondere behandeling, onderscheidt men verschillende behandelingstermijnen en verschillende verantwoordelijkheden: ofwel de Meter Point Administrator of de Meter Point Administrator en de DNB. En fonction du traitement particulier demandé, on distingue différents temps de traitement et différentes responsabilités : soit le Meter Point Administrator soit le Meter Point Administrator et le GRD. Wanneer de DNB betrokken is bij de behandeling van een flag, rust op hem geen enkele resultaatsverbintenis; het is dus mogelijk dat na het verstrijken van de maximaal toegekende termijn voor de behandeling van een flag, de aanvraag wordt verworpen omdat er geen behandeling heeft plaatsgevonden of kan plaatsvinden. Ook en om ieder misbruik te voorkomen, zullen alle aanvragen met flags die onterecht zijn geactiveerd, systematisch verworpen worden. Tot slot is het belangrijk op te merken dat sommige flags een impact kunnen hebben op de uitvoering van de ex-ante tests. De activering van een flag impliceert dat een specifieke behandeling nodig zal zijn om de aanvraag te kunnen aanvaarden/verwerpen. Deze specifieke behandelingen worden beschreven in de volgende punten. Lorsque le GRD est impliqué par le traitement d un flag, il n y a aucune obligation de résultat de sa part, il est donc possible qu à l issue du temps maximal imparti pour le traitement d un flag, la demande soit rejetée car aucun traitement n a été réalisé ou ne peut être réalisé. De même et pour prévenir tout abus d utilisation, toute demande contenant un ou plusieurs flags activés de façon abusive sera systématiquement rejetée. Enfin, il est important de noter que certains flags peuvent avoir un impact sur la réalisation des tests ex-ante. En effet, l activation d un flag indique qu un traitement spécifique devra être apporté pour pouvoir accepter/rejeter la demande. Ces traitements spécifiques sont repris dans les sections qui suivent. UMIG 6.0 - BR - ST - 03 - v3.4 14/25

4.1.2 De verschillende types flags Les différents types de flag Er worden 4 types flags onderscheiden die, afhankelijk van de terrein- en de klantsituatie en afhankelijk van het type aanvraag, al dan niet beschikbaar zijn. On distingue 4 types de flag qui en fonction des situations terrain et client ainsi qu en fonction du type de la demande, seront disponibles ou non. FLAGS Request Unlock Actie van de DNB / Action du GRD X Maximale termijn voor de behandeling / Délai maximal pour le traitement 2 werk dagen 2 jours ouvrables 1 Start Access Move In / Initiate Local Production Desynchronization (SH3) X N.V.T. / N.A. X X Contestation ED ILC N.V.T. / N.A. N.V.T. / N.A. X Take over ILC N.V.T. / N.A. N.V.T. / N.A. X Alle andere modules / Tous les autres modules X X X De maximumtermijn voor behandeling is de extra tijd die maximaal wordt toegekend voor behandeling van een aanvraag met geactiveerde flags. Concreet betekent dit dat de verwerpingsberichten (ST-INT-2) of acceptatieberichten (ST-INT-3) uiterlijk na die termijn kunnen worden verstuurd. Le délai maximal de traitement indique le temps maximal supplémentaire que peut induire le traitement d une demande avec flags activés. Cela signifie concrètement que les messages de rejet (ST-INT-2) ou d acceptation (ST- INT-3) pourront être envoyés au plus tard après cette durée. Bij een flag Request Unlock of Desynchronization (SH3), wordt een actie verwacht van de DNB. In het geval van de flag "Request Unlock" beschikt deze ten hoogste over de maximumtermijn om te reageren. Reageert hij niet, dan is de aanvangssituatie waarschijnlijk onveranderd en zal de aanvraag bijgevolg verworpen worden. Reageert de DNB echter vóór het verstrijken van de maximumtermijn, dan wordt dit gemeld aan de Metering Point Administrator, die de behandeling van de aanvraag zal hernemen (heruitvoering van het geheel van ex-ante tests). Dans le cas d un flag «Request Unlock» ou «Desynchronization (SH3)», une action sera attendue du GRD. Dans le cas du flag «Request Unlock», ce dernier aura au maximum le temps du délai maximal pour réagir. S il ne réagit pas, la situation de départ sera vraisembablement inchangée et la demande du coup rejetée. Si par contre le GRD réagit avant que le délai maximal de traitement ne soit atteint, le Metering Point Administrator en sera avisé et reprendra alors le traitement de la demande (ré-exécution de l ensemble des tests ex-ante). Bij de flags Contestation ED ILC en Take over ILC wordt een actie verwacht van de Metering Point Administrator maar de Start Access kan Dans les cas des flags «Contestation ED ILC» et «Take over ILC», une action sera attendue de la part du Metering Point Administrator mais le Start Access pourra être enregistré automatiquement. 1 «Ouvrables» au sens des calendriers régionaux, à partir de la date d acceptation de la demande 1 Werkdagen» volgens de regionale kalenders, vanaf de datum van de aanvaarding van de aanvraag. UMIG 6.0 - BR - ST - 03 - v3.4 15/25

automatisch geregistreerd worden. Overigens, als er verschillende flags geactiveerd zijn, kunnen deze achtereenvolgens behandeld worden en de maximumduur voor de behandeling van de flags is ten hoogste gelijk aan de individuele behandelingstermijn van elk van de geactiveerde flags. Opgemerkt wordt dat onterecht geactiveerde flags, dit wil zeggen die geactiveerd zijn zonder reden, automatisch zullen leiden tot verwerping van de betrokken aanvraag. Par ailleurs, si plusieurs flags sont activés, ceux-ci pourront être traités séquentiellement et la durée totale de traitement des flags pourra au maximum être égale au délai individuel de traitement de chacun des flags activés. A noter qu un flag activé de façon abusive, c est-à-dire sans qu il y ait de raison à son activation, verra automatiquement la demande qu il accompagne rejetée. 4.1.3 «Request Unlock» Flag De notie lock werd voorgesteld in de MIG6 Fundamentals: "De DNB kan een toegangspunt tijdelijk blokkeren, dit wil zeggen de behandeling van inkomende transacties verhinderen". La notion de lock a été introduite dans les Fondamentaux MIG6 : «Le GRD a la possibilité de bloquer temporairement un point d accès, c est-à-dire d empêcher le traitement de toutes les transactions entrantes». Met de flag "Request Unlock" kan de initiator een "unlock" aanvragen van het toegangspunt waarvoor hij een nieuwe marktvraag wil lanceren. Als de "unlock"-aanvraag niet wordt gedaan en het toegangspunt "locked" is, zal de opgestarte transactie systematisch falen bij de ex-ante test "Is het toegangspunt locked?".». Le flag «Request Unlock» permet à l Initiator de demander un «unlock» du Point d Accès pour lequel il souhaite lancer une nouvelle demande de marché. En effet, si la demande «d unlock» n est pas réalisée et que le Point d Accès est «locked», la transaction lancée échouera systématiquement au test ex-ante «Le Point d Access est-il locked?». Als de Initiator deze flag heeft geactiveerd, zal de Metering Point Administrator in een eerste fase alle ex-ante tests verrichten behalve de "Is het toegangspunt locked?". Als de transactie al deze tests doorstaat, stuurt de Metering Point Administrator de aanvraag te "unlocken" naar de DNB, die ze behandelt. Uiterlijk 2 werkdagen later heeft de DNB er de Metering Point Administrator er al dan niet van in kennis geteld dat de aanvraag werd behandeld. De Metering Point Administrator verricht dan alle ex-ante tests (inclusief overblijvende test van de lock-status van het toegangspunt). Als de tests falen, wordt de aanvraag verworpen. Worden de tests wel doorstaan, dan stuurt de Metering Point Administrator een acceptatiebericht naar de Initiator en wordt de transactie verder behandeld. Concreet betekent dit dat als de DNB de unlock aanvraag niet heeft gerealiseerd, het toegangspunt locked blijft en de aanvraag bijgevolg verworpen wordt. Dans le cas où l Initiator a activé ce flag, le Metering Point Administrator réalisera dans un premier temps l ensemble des tests ex-ante excepté celui du lock «Le Point d Access est-il locked?». Si la demande réussit à l ensemble de ces tests, le Metering Point Administrator envoie la demande de «unlock» au GRD qui la traite. Après 2 jours ouvrables au plus tard, le GRD a communiqué ou non au Metering Point Administrator que la demande a été traitée. Le Metering Point Administrator réalise alors l ensemble des tests ex-ante (test résiduel sur le statut lock du Point d Accès compris). Si les tests échouent, la demande est alors rejetée. Si les tests réussissent, le Metering Point Administrator envoie un message d acceptation à l Initiator et continue le traitement normal de la transaction. Cela signifie concrètement que si le GRD n a pas réalisé la demande «d unlock», le Point d Accès sera toujours «locked» et la demande du coup rejetée. Opgemerkt wordt dat als de flag "Request Unlock" geactiveerd is terwijl het toegangspunt niet locked is, de aanvraag automatisch verworpen zal worden. A noter que si le flag «Request Unlock» est activé alors que le Point d Accès n est pas «locked», la demande sera automatiquement rejetée. Tevens, gezien de lock een tijdelijke status is, is het aan de Toegangshouders om niet automatisch een aanvraag met een flag Request Unlock te initiëren wanneer deze aanvraag niet dringend is en deze nog tot het einde van de lock UMIG 6.0 - BR - ST - 03 - v3.4 16/25 Aussi, étant donné que le lock est un statut temporaire, il appartiendra aux détenteurs d accès de ne pas d office initier une demande avec un flag «Request Unlock» lorsque cette demande n a pas un caractère urgent et que

zou kunnen wachten om geïnitieerd te worden. Indien echter een aanvraag met flag Request Unlock toch voor goede redenen gestuurd wordt en exante testen doorstaat, zal deze aanvraag steeds naar de DNB gestuurd worden en dat de verantwoordelijkheid om deze lock op te heffen steeds bij hem ligt. celle-ci pourrait attendre la fin du lock pour être initiée. S il s agit là de bon sens, il n en reste pas moins qu une demande avec flag «Request Unlock» qui réussit aux tests ex-ante sera toujours envoyée au GRD et que la responsabilité de défaire le lock incombe à ce dernier. 4.1.4 «Desynchronization (SH3)» Flag Deze flag stemt overeen met een rectificatienotificatie. Deze wordt gebruikt wanneer een toegangshouder na een contact met de party connected to the grid een Move In of een Start Access of een Initiate Local Production wenst te starten en meldt dat er sprake is van inconsistentie tussen de situatie in het systeem wat betreft de fysieke status (assets) en de situatie op het terrein: de klant heeft energie, status actief terrein maar in de assets is het Toegangspunt als inactief geregistreerd, en omgekeerd. De initiator die een dergelijke situatie vaststelt door communicatie met de party connected to the grid en het gebruik van Preswitching, start zijn aanvraag op met de flag Desynchronization (SH3) geactiveerd. In dit geval zal de Metering Point Administrator in een eerste fase alle ex-ante tests verrichten. Als de transactie al deze tests doorstaat, dan stuurt de Metering Point Administrator de notificatie van desynchronisatie naar de DNB, die het bericht behandelt zonder dat het een impact heeft op de aanvraag (met andere woorden zonder dat dit de markt blokkeert en zonder mogelijkheid van verwerping van de aanvraag a posteriori). Ce flag correspond à une notification de rectification. Il est utilisé dans le cas où suite à un contact avec le party connected to the grid, un détenteur d accès souhaitant initier un Move In ou un Start Access ou un Initiate Local Production, notifie qu il y a une inconsistance entre la situation enregistrée dans les systèmes concernant le statut physique (assets) et la situation sur le terrain : le client a de l énergie, statut terrain actif, mais dans les assets le Point d Accès est enregistré comme étant inactif physiquement, et réciproquement. L Initiator constatant cette situation grâce à une communication avec le party connected to the grid et à l utilisation du Preswitching lancera sa demande avec le flag «Desynchronization (SH3)» activé. Dans ce cas, le Metering Point Administrator réalisera dans un premier temps l ensemble des tests exante. Si la transaction réussit à l ensemble de ces tests, le Metering Point Administrator enverra alors la notification de désynchronisation au GRD qui la traite sans que cela n aie d impact sur la demande (c est-à-dire sans que cela ne bloque le marché et sans possibilité de rejet de la demande a posteriori). De initiator die deze flag activeert zal de mogelijkheid hebben de door de party connected to the grid verstrekte gegevens (bv. meterstand, vertrekdatum, dagindex, ) toe te voegen. Deze gegevens zullen via de gestructureerde velden ingevoerd kunnen worden en deze zijn; - Index gelezen op verhuisdatum; - Verhuisdatum; - Index gelezen op de aanvraagdatum; - Free text (voor alle bijkomende informatie). L Initiator activant ce flag aura la possibilité de rajouter des informations que le party connected to the grid lui aura transmises. Ces informations pourront être rentrées via des champs structurés qui sont : - index lu à la date d emménagement ; - date d emménagement ; - index lu à la request date ; - free text (pour toute information additionnelle). De onderstaande tabel geeft de verschillende situaties weer waarbij het gebruik van de flag SH3 al dan niet mogelijk is (I = Inactief; A = actief): Le tableau ci-dessous reprend les différentes situations où l utilisation du flag SH3 est possible ou non (I = Inactif, A = actif): UMIG 6.0 - BR - ST - 03 - v3.4 17/25

Situatie op het Terrein / Situation sur le Terrain Fysiek Status / Statut Physique I A I A Contractueel Status / Statut Contractuel I A I A I A I A Start Start Start Start Move Module te initiëren / Module à initier Move In Access N.V.T. / Access Move In Access Access In* / ILP N.A. / ILP / ILP / ILP Flag SH3? N.V.T. / N.A. SH3 SH3 N.V.T. / N.A. I A 4.1.5 «Contestation ED ILC» Flag Het betreft een aanvraag om rectificatie van de effectieve datum en meterstand in geval van een aanvraag type Start Access na een verhuizing (aanvraag type Initiate Leaving Customer (ILC)). Il s agit d une demande de rectification de l effective date et de l index dans le cas d une demande de type Start Access faisant suite à un déménagement (demande de type Initiate Leaving Customer (ILC)). Als de nieuwe party connected to the grid (die van de Start Access) de voor de ILC gebruikte index/effectieve datum betwist, zal de toegangshouder die de Start Access lanceert, deze flag activeren om de betwiste gegevens te wijzigen tegelijk met de registratie van het contract. Hiertoe moet de toegangshouder het door de nieuwe party connected to the grid verstrekte Overnameformulier bij zijn bericht voegen, zo niet zal zijn aanvraag om betwisting en registratie van het contract (Start Access) geweigerd worden. Tevens dienen bepaalde velden van het Overnameformulier in de aanvraag overgenomen te worden zonder dewelke deze aanvraag niet als correct vervolledigd beschouwd kan worden en bijgevolg verworpen zal worden. Verder wordt opgemerkt dat deze flag niet geactiveerd kan worden als de effectieve datum van de Start Access gelijk is aan die van de ILC. In dat bijzondere geval zal de Start Access gelanceerd worden zonder flag en kan de toegangshouder indien hij wenst, een rectificatie van de startindex vragen door verzending van een afzonderlijke Request Rectification aanvraag (eventueel na eerst contact met de toegangshouder van de Initiate Leaving Customer). Si le nouveau party connected to the grid (celui du Start Access) conteste l index/la date effective utilisés pour le ILC, le détenteur d accès lancant le Start Access activera ce flag afin de modifier les données contestées en même temps que l enregistrement du contrat. A cette fin, le détenteur d accès devra annexer dans son message le Document de reprise communiqué par le nouveau party connected to the grid sans quoi sa demande de contestation et d enregistrement de contrat (Start Access) sera refusée. De même, certains champs du Document de reprise devront être recopiés dans la demande sans quoi celle-ci ne pourra pas être considérée comme correctement complétée et sera du coup rejetée. A noter aussi que ce flag ne pourra pas être activé si la date effective indiquée dans le Start Access de contestation est la même que celle du ILC. Dans ce cas particulier, le Start Access sera lancé sans flag et si le détenteur d accès le souhaite, il pourra demander une rectification de l index de début en envoyant une demande de Request Rectification séparée (en ayant éventuellement été contacté au préalable par le détenteur d accès du Initiate Leaving Customer). Laten we aannemen dat de Start Access aanvraag aanvaard wordt. De verantwoordelijkheden van de toegangshouders worden dan geregistreerd als volgt: Supposons que la demande de Start Access soit acceptée. Les responsabilités des détenteur d accèss seront enregistrées comme suit : UMIG 6.0 - BR - ST - 03 - v3.4 18/25

Start Access + Flag «Contestation ED ILC» Toegangshouder van de ILC / Détenteur d accès du ILC ED ILC ED Start Access Request date Toegangshouder van de Start Access / Détenteur d accès du Start Access Figure 4 - "Contestation ED ILC" flag usage v1.0 Ingevolge de acceptatie van de Start Access en ongeacht het label van de ILC, wordt de verantwoordelijkheid van de toegangshouder die de ILC gelanceerd heeft, automatisch verlengd tot de effectieve datum van de Start Access met de overeenkomstige index zoals weergegeven in de figuur hieronder. Dit principe geldt niet voor de periode na ILC3, waarna de Balance Supplier-Initiator definitief ontheven is van zijn verantwoordelijkheid voor het Toegangspunt. Concreet betekent dit dat een bericht met de eindmeterstand en daaraan gekoppeld verbruik moet worden opgestuurd naar de toegangshouder die de ILC heeft aangevraagd. Er zijn hier twee mogelijke situaties: - Indien het gaat om een ILC met label With Handover Document, dan wordt het verbruik tussen de effectieve datum van de ILC en de datum van uitvoering van de Start Access ten laste genomen van de toegangshouder van de ILC. - Indien het gaat om een ILC met label Without Handover Document, dan wordt het verbruik tussen de effectieve datum van de ILC en de datum van uitvoering van de Start Access door de toegangshouder van de ILC overgedragen naar de party connected to the grid die de aanvraag voor de ILC gedaan heeft. Faisant suite à l acceptation du Start Access, et peu importe le label du ILC, la responsabilité du détenteur d accès ayant initié l ILC sera automatiquement prolongée jusqu à la date effective du Start Access et avec l index associé comme illustré sur la figure ci-dessous. Ce principe n est pas en vigueur après la période ILC3, où le Balance Supplier-Initiator est déchargé définitevement de sa responsabilité du point d accès du ILC lancé. Cela signifie concrètement qu un message metering d index de fin et de consommations associées devra être envoyé au détenteur d accès ayant initié l ILC. On distingue deux situations : - Si le label du ILC est With Handover Document, la consommation entre la date effective du ILC et la date effective du Start Access sera prise à la charge du détenteur d accès de l ILC ; - Si le label du ILC est Without Handover Document, la consommation entre la date effective du ILC et la date effective du Start Access sera reportée par le détenteur d accès du ILC sur le party connected to the grid ayant fait la demande de l ILC. ED ILC Toegangshouder van de ILC / Détenteur d accès du ILC ED Start Access / ILC Figure 5 - "Contestation ED ILC" flag effect v1.0 Toegangshoudevan de Start Access / Détenteur d accès du Start Access UMIG 6.0 - BR - ST - 03 - v3.4 19/25

Het is dus aan deze toegangshouder om die acties te ondernemen die hij nodig acht om de situatie te behandelen. In de situatie waar de toegangshouder en/of de party connected to the grid genoteerd op het Overnamedocument gebruikt voor de betwisting verschillen van deze in de ILC, zou de toegangshouder die de ILC geïnitieerd heeft contact kunnen opnemen met de toegangshouder waarvan hij veronderstelt diegene te zijn die het toegangspunt ten laste moet nemen tijdens de tussenliggende periode die loopt vanaf de initiële effectieve datum van de ILC tot die van de Start Access. Indien de toegangshouder van de tussenliggende periode de aanvraag als legitiem erkent, zal deze een Request Rectification initiëren die als gevolg zal hebben dat het tussenliggende volume aan hem toegewezen wordt. 2 Teneinde misverstanden te vermijden, en gegeven dat de DNB die de aanvraag ontving hier verder geen onderzoek naar doet, is het ideaal gezien aan de toegangshouder die de ILC initieerde om de situatie te begrijpen en te overleggen met de eventueel andere betrokken partijen alvorens te proberen de situatie op te lossen door het versturen van andere marktaanvragen. Il appartiendra alors à ce détenteur d accès d entreprendre les actions qu il juge nécessaire pour traiter la situation. Ainsi dans la situation où le détenteur d accès et/ou le party connected to the grid indiqués dans le Document de reprise de contestation diffèrent de ceux du ILC, le détenteur d accès ayant initié l ILC pourra contacter un détenteur d accès qu il pense être celui supposé reprendre le point d accès à sa charge pendant la période intermédiaire allant de la date effective initiale de l ILC jusqu à celle du Start Access. Si ce détenteur d accès intermédiaire reconnait la demande comme légitime, il initiera un Request Rectification qui aura comme conséquence de lui réattribuer le volume intermédiaire. 3 Afin d éviter les incompréhensions, et étant donné que le GRD recevant une telle demande ne prendra pas position par rapport à celle-ci, il appartient idéalement au détenteur d accès initiateur de comprendre la situation et de se concerter avec les éventuelles parties impactées avant d essayer de la résoudre par le lancement d autres demandes de marché. Dit betekent dat het Overnamedocument gebruikt voor het indienen van de betwisting systematisch zal overgemaakt moeten worden aan de toegangshouder van de ILC zodat deze met kennis van zaken kan reageren en de juiste partijen kan contacteren. Indien de toegangshouder die het voorwerp uitmaakt van de betwisting vaststelt dat het voor deze betwisting gebruikte Overnamedocument niet exploiteerbaar is, dan kan hij ook een aanvraag Request Rectification doen opdat de Start Access wel degelijk op de effectieve datum van de ILC zou starten met dezelfde indexen. Cela signifie que le Document de reprise utilisé pour réaliser la contestation devra systématiquement être transmis au détenteur d accès de l ILC afin que celui-ci puisse agir en connaissance de cause et contacter les parties adéquates. Aussi, si le détenteur d accès subissant la contestation constate que le Document de reprise utilisé pour la contestation n est pas exploitable, il aura alors la possibilité d initier une demande de Request Rectification afin que le Start Access démarre bien à la date effective du ILC et avec les mêmes index. 2 Opgemerkt wordt dat die situaties wellicht heel weinig zullen voorkomen. In geval van een Initiate Leaving Customer zonder Overnameformulier, zal de toegangshouder die de ILC heeft gelanceerd zich niet kunnen verzetten tegen de verlenging van zijn verantwoordelijkheid aangezien hij geen Overnameformulier voor zijn ILC kan voorleggen. Bij een Initiate Leaving Customer met Overnameformulier daarentegen, betreft de periode tussen de Start Access en de ILC maar ten hoogste 15 kalenderdagen; na die termijn wordt de ILC immers omgezet naar een label zonder Overnameformulier. Ter herinnering: alle details betreffende de werking van de module ILC zijn terug te vinden in het referentiedocument [5]. 3 Notons que ces situations risquent d être que très peu rencontrées. En effet, dans le cas d un Initiate Leaving Customer sans Document de reprise, le détenteur d accès du ILC ne pourra vraisemblablement pas contester le rallongement de responsabilité subi étant donné qu il ne disposera pas d un Document de reprise pour son ILC. Et, dans le cas d un Initiate Leaving Customer avec Document de reprise, la période concernée entre le Start Access et l ILC ne concernera que 15 jours calendrier au plus, sans quoi l ILC aura déjà basculé vers un label sans Document de reprise. Pour rappel, tous les détails de fonctionnement du module ILC peuvent être retrouvés dans le document de référence [5]. UMIG 6.0 - BR - ST - 03 - v3.4 20/25

4.1.6 «Take Over ILC» Flag Het betreft een aanvraag die toelaat de ex-ante test verbonden aan de verst in het verleden gelegen datum (Cmin) als effectieve datum (ED) te omzeilen. De effectieve datum van een Start Access die volgt op een Initiate Leaving Customer moet immers altijd (behoudens betwisting door de party connected to the grid) gelijk zijn aan de ED (effectieve datum) van de Initiate Leaving Customer. Het kan evenwel gebeuren dat de Start Access meer dan 60 kalenderdagen in het verleden na de ILC werd gelanceerd. In dat geval moet de flag Take over ILC geactiveerd worden zodat de Start Access niet systematisch verworpen wordt bij de test Effectieve datum Start Access meer dan 60 kalenderdagen in het verleden (Cmin)?». Opgelet! Een aanvraag met ED op meer dan 35 maanden in het verleden zal verworpen worden. Il s agit d une demande permettant de passer le test ex-ante lié à la date la plus éloignée dans le passé possible (Cmin) pour la date effective (ED). En effet, un Start Access suivant un Initiate Leaving Customer devra toujours (sauf contestation du party connected to the grid) avoir une ED égale à celle du Initiate Leaving Customer (ILC). Cependant, il se peut que le Start Access soit lancé plus de 60 jours calendrier dans le passé suivant le ILC. Dans un tel cas, le flag «Take over ILC» devra être activé et permettra au Start Access de ne pas systématiquement être rejeté suivant le test «Date effective du Start Access située au-delà de 60jours calendrier dans le passé (Cmin)?». Attention cependant à ce qu une demande avec ED située à plus de 35 mois dans le passé sera rejetée. Tevens wordt opgemerkt dat als de datum van de ILC niet meer dan 60 dagen in het verleden ligt, de activering van deze flag automatisch zal leiden tot weigering van de Start Access; hetzelfde geldt als de flag geactiveerd wordt terwijl de Start Access aanvraag niet volgt op een ILC, deze wordt automatisch geweigerd. A noter aussi que si la date du ILC ne se situe pas à plus de 60 jours dans le passé, ce flag, s il est activé, entraînera le rejet automatique de la demande de Start Access de même que si le flag est activé et que la demande de Start Access ne fait pas suite à un ILC, cette demande sera automatiquement rejetée. Start Access + Flag «Take Over ILC» Toegangshouder van de ILC / Détenteur d Accès du ILC ED ILC / Start Access Cmin (-60c.d.) Toegangshouder van de Start Access / Détenteur d Accès du Start Access Request date Figure 6 - "Take Over ILC" flag usage v1.0 UMIG 6.0 - BR - ST - 03 - v3.4 21/25

4.2 Update Business Master Data 4.2.1 Timeslicing Aanvragen van het type Update Business Master Data bevatten geen effectieve datum. De gegevens in dit soort aanvragen zijn van toepassing vanaf de acceptatie van de aanvraag. Les demandes du type Update Business Master Data ne contiennent pas de date effective, les données qu elles contiennent sont d application à partir de l acceptation de la demande. Dit betekent dat de Business Master Data getimesliced zijn per datum van update: voor een gegeven datum bestaat er slechts één set van gegevens Business Master Data, maar voor een gegeven periode kunnen verschillende sets van gegevens Business Master Data bestaan. Cela signifie que les Business Master Data sont timeslicées par date de mise à jour : pour une date donnée, il n existe qu un set de données Business Master Data, mais pour une période donnée, plusieurs sets de données Business Master Data peuvent exister. Een Update Business Master Data zal steeds volgens het delta principe verlopen. Concreet wilt dit zeggen dat enkel de gecommuniceerde set van Business Master Data kan leiden tot het bijwerken hiervan in het CMS. Indien de Busines Master data van een bepaalde rol (bijvoorbeeld building owner ) : o Wel aanwezig zijn, zullen al de gegevens van deze rol bijgewerkt worden in het CMS. Dit betekent dat lege velden ook als 'leeg' overgenomen zullen worden in het CMS. o Niet aanwezig zijn, zullen al de gegevens van deze rol niet bijgewerkt worden in het CMS. Un Update Business Master Data se déroulera toujours selon le principe du delta. Concrètement cela veut dire que seulement le set du Business Master Data communiqué peut conduire à une mise-à-jour de ces données dans le CMS. Si des Business Master Data d un certain rôle (p.ex. building owner ) : o Sont bien présent, les données de ce rôle seront mis-à-jour dans le CMS. Ça veut dire que des champs vides seront repris comme vide dans le CMS. Ne sont pas présent, les données de ce rôle ne seront pas mis-à-jour dans le CMS. 4.2.2 Initiator De aanvragen van type Update Business Master Data mogen komen van de toegangshouder die verantwoordelijk is voor het toegangspunt. Les demandes du type Update Business Master Data ne peuvent provenir que du détenteur d accès en charge du Point d Accès. De aanvragen afkomstig van een toegangshouder kunnen een beperkte set van gegevens bevatten. Om te weten welke deze gegevens zijn, zie UMIG 6.0 BR XD 04 Relational Master Data Ownership. Ces demandes provenant d un détenteur d accès ne contiendront qu un set de données limité. Pour savoir quelles sont ces données, voir UMIG 6.0 BR XD 04 Relational Master Data Ownership Indien een Distributienetbeheerder echter beseft dat gegevens die door de toegangshouder gecommuniceerd werden (via een Update Business Master Data of via een contractregistratiemodule) volgens hem niet correct zijn, kan de DNB aan de toegangshouder vragen deze te corrigeren via een outbound rectificatie verzoek (zie sectie 4.2.3). De DGO kan deze echter niet rechtstreeks in het CMS bijwerken. Bijgevolg zal de DGO ook nooit verantwoordelijk gehouden kunnen worden voor de juistheid van deze gegevens. UMIG 6.0 - BR - ST - 03 - v3.4 22/25 Néanmoins, si un Gestionnaire du Réseau de Distribution devait s apercevoir que des données communiquées par le détenteur d accès (soit via un module Update Business Master Data soit via un module d enregistrement de contrat) s avèrent selon lui erronées, il pourra demander au détenteur d accès de rectifier celles-ci via une demande de rectification outbound (voir section 4.2.3). Le DGO ne peut pas mettre-à-jour ces données directement dans le CMS. Par conséquent, le DGO ne peut jamais être tenu responsable sur la conformité de ces données.