ATRIAS – Market Processes
UMIG 6.0
Marktprocessen – Processus de marché
Business Requirements
Structuring Process
Versie v3.2 / Version v3.2
Voor consultatie / Pour consultation
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
UMIG 6.0 Structuring Process
DOCUMENTVERSIES – VERSIONS DU DOCUMENT ..........................................................................................................4
1
1.1
Versieoverzicht – Gestion des versions ...............................................................................................................................4
1.2
Referenties – Références ....................................................................................................................................................4
ALGEMEENHEDEN – GÉNÉRALITÉS ..................................................................................................................................6
2
2.1
Definities – Définitions .........................................................................................................................................................6
2.2
Documentstructuur – Structure du document ......................................................................................................................6
BASISCONCEPTEN – CONCEPTS DE BASE ......................................................................................................................8
3
3.1
Introductie – Introduction .....................................................................................................................................................8
3.2
De switching eenheid – L’unité de switching .......................................................................................................................8
3.3
Naar een modulaire aanpak (start/stop) – Vers une approche modulaire (start/stop) .........................................................8
3.3.1
Groepering van scenario’s met modules – ex-ante tests vs ex-post Monitoring – Regroupement des scénarios par
modules – Tests ex-ante vs Monitoring ex-post ..........................................................................................................................8
3.3.2
Het label – Le label ....................................................................................................................................................10
3.3.3
Chronologie van berichten – Chronologie des messages..........................................................................................10
Statussen en locks – Les statuts et locks ..........................................................................................................................11
3.4
3.4.1
Definities van de statussen – Définitions des statuts .................................................................................................11
3.4.2
Lock principe - Principe du lock .................................................................................................................................12
3.4.3
Lock plaatsen/verwijderen – Placement/Enlèvement lock .........................................................................................12
4
INLEIDING OP MODULES – INTRODUCTION AUX MODULES .........................................................................................14
4.1
Introductie – Introduction ...................................................................................................................................................14
4.2
Contractuele aanvragen – Demandes contractuelles ........................................................................................................14
4.3
Aanvragen om wijziging toegang – Demandes de modification d’accès ...........................................................................15
4.4
Aanvragen om bijwerking van gegevens – Demandes de mise à jour de données ...........................................................16
4.5
Aanvragen om rectificatie / annulatie – Demandes de rectification / annulation ................................................................17
5
MODULES MIG6 MODULES ................................................................................................................................................18
5.1
Introductie – Introduction ...................................................................................................................................................18
5.2
Start Access ......................................................................................................................................................................18
5.3
Move In ..............................................................................................................................................................................19
5.4
Move Out ...........................................................................................................................................................................20
5.5
Initiate Local Production ....................................................................................................................................................21
5.6
Initiate Update Access (ODV/OSP) ...................................................................................................................................22
5.7
Initiate Stop Access ...........................................................................................................................................................23
5.8
Initiate Leaving Customer ..................................................................................................................................................24
5.9
Request Start.....................................................................................................................................................................25
5.10
Update Customer Metering Configuration .........................................................................................................................26
5.11
Prepayment .......................................................................................................................................................................27
5.12
Update Technical Master Data ..........................................................................................................................................28
5.13
Update Business Master Data ...........................................................................................................................................29
5.14
Update Balance Responsible Party ...................................................................................................................................29
5.15
Request Rectification .........................................................................................................................................................30
5.16
Cancel Module ...................................................................................................................................................................30
6
MAPPING MIG4.1 VS MIG6..................................................................................................................................................32
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
2/52
UMIG 6.0 Structuring Process
7
BUSINESS REQUIREMENTS STRUCTURE .......................................................................................................................34
7.1
Scope ................................................................................................................................................................................34
7.2
Concepten en begrippen – Concepts et définitions ...........................................................................................................35
8
USER STORIES ....................................................................................................................................................................37
8.1
Introductie – Introduction ...................................................................................................................................................37
8.2
Registratie van contract – Enregistrement de contrat ........................................................................................................37
8.3
Verhuizing van een klant – Déménagement d’un client .....................................................................................................38
8.4
Andere – Autres .................................................................................................................................................................38
BIJLAGEN – ANNEXES .......................................................................................................................................................40
9
9.1
Verhuizingsproces – Processus de déménagement ..........................................................................................................40
9.1.1
Context – Contexte ....................................................................................................................................................40
9.1.2
Verschillende mogelijke situaties – Différentes situations possibles ..........................................................................41
9.1.3
Werking van de module – Fonctionnement du module ..............................................................................................42
9.1.4
Synthese van de Business Rules – Synthèse des Business Rules ...........................................................................45
9.1.5
Regularisatieacties door de toegangshouder – Activités de régularisation du détenteur d’accès ..............................46
9.1.6
Regularisatieacties door de DNB – Activités de régularisation du GRD ....................................................................47
9.1.7
Onjuist label – Label incorrect ...................................................................................................................................47
9.1.8
Refus de la contestation – Refus de la contestation ..................................................................................................47
9.2
Request Start.....................................................................................................................................................................48
9.2.1
Label « Regularization form » ....................................................................................................................................48
9.2.2
Label « Initiate Leaving Customer» ...........................................................................................................................50
9.2.3
Label « Switch Back Brussels » .................................................................................................................................51
10
TABELLEN & INDEXEN – TABLES & INDEXES ............................................................................................................52
10.1
Begrippenlijst – Glossaire ..............................................................................................................................................52
10.2
Table of Figures ...............................................................................................................................................................52
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
3/52
UMIG 6.0 Structuring Process
1 Documentversies – Versions du document
1.1 Versieoverzicht – Gestion des versions
Versie –
Version
Datum – Date
Auteur
V1.0
07/12/2012
Atrias MPP MIG6
Project Team
V2.0
V2.1
29/03/2013
30/04/2013
Atrias MPP MIG6
Project Team
Atrias MPP MIG6
Project Team
Beschrijving – Description
Eerste versie van het Business Requirement Structuring Process
Première version du Business Requirement Structuring Process
Versie 2.0 van het Business Requirement Structuring Process na
integratie van de feedback aangeleverd door de Business Analisten en
Subject Matter Experts van de Net User Interactions werkgroep
Version 2.0 du Business Requirement Structuring Process 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
Versie 2.1 van het Business Requirement Structuring Process met
geïntegreerde inhoud
Version 2.1 du Business Requirement Structuring Process intégrant le
contenu
Version 3.0 voor consultatie
V3.0
V3.1
V3.2
30/06/2013
28/02/2014
31/07/2014
Atrias MPP MIG6
Project Team
Atrias MPP MIG6
Project Team
Atrias MPP MIG6
Project Team
Versie 3.0 pour consultation
Version 3.1 voor consultatie
Versie 3.1 pour consultation
Version 3.2 voor consultatie
Versie 3.2 pour consultation
1.2 Referenties – Références
Referentie – Référence
Omschrijving - Description
UMIG 6.0 - GE - XD - 02 – Introduction [1]
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.
UMIG 6.0 – BR - ST - 03 – Preswitching [2]
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.
UMIG 6.0 – BR - ST - 03 – Initiate Request [3]
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Beschrijving van het proces van aanmaak en eerste behandeling van
een Structuring aanvraag door de markt
4/52
UMIG 6.0 Structuring Process
Referentie – Référence
Omschrijving - Description
Document décrivant le processus de création et de premier traitement
d'une demande Structuring par le marché
UMIG 6.0 – BR - ST - 03 – Handle Request [4]
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 6.0 – BR - ST - 04 – Ex-Ante Tests [5]
Matrix van de volledige ex-ante tests voor de verschillende Structuring
aanvragen. Deze tests worden in het proces 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.
UMIG 6.0 – BR - ST - 04 – Ex-Post Monitoring
[6]
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 – Exchanged
information [7]
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 - ST - 04 – Timings [8]
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.
PoV: “Visie op evolutie van de Belgische
energiemarkt” / “Vision de l’évolution du marché
Belge de l’énergie” [9]
Referentiedocument dat de visie beschrijft op de marktevolutie en dient
als leidraad voor de marktbesprekingen
UMIG 6.0 - GE - XD - 01 – Glossary [10]
Document waarin alle in de documentatie gebruikte begrippen worden
beschreven die specifiek zijn aan de marktprocessen.
Document de référence décrivant la vision de l’évolution du marché
servant de ligne directrice aux discussions de marché
Document qui décrit l'ensemble des termes, spécifiques aux processus
de marché, utilisés dans la documentation.
UMIG 6.0 - BR - ST - 03 – Rectification [11]
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 - 04 - Rectification
Catalogue [12]
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)
UMIG 6.0 - BR - ST - 03 – Prepayment [13]
Document die het voorafbetalingsproces en zijn verschillende types
aanvraag beschrijft
Document qui décrit le processus de prépaiement et les différents types
de demande qui y sont liés.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
5/52
UMIG 6.0 Structuring Process
2 Algemeenheden – Généralités
2.1 Definities – Définitions

Het domein Structure is een van de domeinen die
gedekt zijn door MIG6.0.

Le domaine Structure est l’un des domaines couverts
par le MIG6.0.
“Structuring enables the actors to exchange information (master data) necessary for the later business processes. The different
parties request creation of, changes to or deletion of energy market business objects. Thereafter the information related to the
created, changed or deleted market business object or its attributes is exchanged between relevant parties (roles). The
alignment of master data between the actors in the energy market should result in all participants having the needed information
to fulfill their obligations to the market.” (ebIX)

ebIX definieert het domein Structure als domein "dat
de spelers de mogelijkheid biedt gegevens (master
data) die nodig zijn voor business processen uit te
wisselen. De verschillende partijen vragen om
aanmaak, aanpassing of schrapping van business
objects van de energiemarkt. Vervolgens wordt de
informatie betreffende de aangemaakte, gewijzigde
of geschrapte business objects of hun kenmerken
tussen
de
betrokken
marktpartijen
(rollen)
uitgewisseld. De afstemming van de master data
tussen spelers op de energiemarkt zou ervoor
moeten zorgen dat alle deelnemers van die markt de
nodige informatie hebben voor de goede uitvoering
van hun verplichtingen ten aanzien van de markt." »

ebIX
définit
le
domaine
Structure
comme « permettant aux acteurs d’échanger des
informations (master data) nécessaires à des
processus business. Les différentes parties
demandent la création, le changement ou la
suppression d’objets business du marché de
l’énergie. Par la suite, l’information relative aux objets
business marché créés, modifiés ou supprimés ou à
leurs attributs est échangée entre les parties
pertinentes (rôles). L’alignement des master data
entre acteurs dans le marché de l’énergie devrait
permettre à tous les participants de ce marché d’avoir
les informations requises à la bonne exécution de
leurs obligations envers le marché. »

Naar analogie zullen we zeggen dat "Structure" het
domein is van de processen die alle uitwisselingen
van berichten beschrijven tussen de verschillende
marktspelers in het kader van de aanmaak, wijziging,
schrapping van gegevens verbonden aan business
objects, doorgaans contracten. Door deze
uitwisseling van berichten kunnen alle marktpartijen
die geraakt worden door die business objects hun
systeem bijwerken en zo optimaal aan hun
verplichtingen voldoen.

De façon analogue, nous dirons que le domaine
Structure est celui des processus décrivant
l’ensemble des échanges de messages entre les
différents acteurs du marché dans le cadre de la
création, mise-à-jour, suppression de données liées à
des objets business, typiquement des contrats. Cet
échange de messages permet à l’ensemble des
parties de marché impactées par ces objets business
de mettre à jour leur système et de pouvoir remplir
ainsi au mieux leurs obligations.

Le document UMIG6.0 – BR – ST – 02 – Structuring
Process a comme but d’introduire les grands
concepts relatifs au domaine Structure.

A cette fin, ce document est structuré tel qu’indiqué
ci-dessous :
2.2 Documentstructuur – Structure du document

Het document UMIG6.0 – BR – ST – 02 – Structuring
Process heeft tot doel de hoofdconcepten van het
domein Structure voor te stellen.

Het is opgebouwd als volgt:
-
Basisconcepten:
samenvatting
van
de
sleutelconcepten van het domein Structure
ontwikkeld in het kader van MIG6 om de
processen te ondersteunen;
-
Introductie modules: rubriek die op algemene
wijze beschrijft welk type aanvraag gebruikt moet
worden voor welk gewenst type actie;
-
MIG6 Modules: beschrijving van de in het kader
van MIG6 gedefinieerde modules, hun
toepassingsgebied en heropname van de
MIG6.0-documenten waarin het verloop wordt
uitgelegd;
-
Mapping MIG4.1 vs MIG6.0: mapping van de
scenario’s van MIG4.1 met de modules en labels
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
-
Concepts de base : récapitulatif des concepts
clefs du domaine Structure développés dans le
cadre du MIG6 pour soutenir les processus;
-
Introduction modules : section décrivant de façon
générale quel type de demande doit être utilisé
pour quel type d’action désirée ;
-
Modules MIG6 : description des modules définis
dans le cadre du MIG6, de leur périmètre
d’application et reprise des documents MIG6.0
qui expliquent leur déroulement;
-
Mapping MIG4.1 vs MIG6.0 : mapping des
scénarios connus en MIG4.1 avec les modules et
labels définis dans le MIG6
6/52
UMIG 6.0 Structuring Process
bepaald in MIG6;
-
Business Requirements Structure: inleiding
betreffende
de
Business
Requirements
Structuring documenten;
-
Use cases – user stories: een reeks van use
cases illustreren verschillende soorten situaties
die zich op de markt kunnen voordoen en de
bijbehorende acties die moeten worden
genomen.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
-
Business Requirements Structure: introduction
aux documents de Business Requirements
Structuring ;
-
Use cases – user stories : série de use cases
illustrant différents types de situation pouvant
être rencontrés dans le marché et les actions
associées à prendre.
7/52
UMIG 6.0 Structuring Process
3 Basisconcepten – Concepts de base
3.1 Introductie – Introduction
De constructie van de processen van het domein Structure in
het kader van MIG6 berust op een reeks basisconcepten die
ontwikkeld zijn in dit hoofdstuk. Deze basisconcepten zijn
soms geldig voor alle processen (bv. status en lock) en soms
slechts voor één proces (bv. verhuizingsproces).
La construction des processus du domaine Structure dans le
cadre du MIG6 s’appuie sur une série de concepts de base
développés dans le présent chapitre. Ces concepts de base
sont valables tantôt pour tous les processus (ex. statuts et
lock) tantôt uniquement pour un processus (ex. processus de
déménagement).
3.2 De switching eenheid – L’unité de switching
Gezien de verschillende behoeften die de marktpartijen
kunnen hebben, is het belangrijk om een gemeenschappelijke
sleutel te vinden voor de uitwisseling van deze berichten: de
switching-eenheid. Deze gemeenschappelijke sleutel en de
scenario’s liggen aan de basis van de marktprocessen.
Etant donné les différents besoins qu’il peut y avoir pour les
acteurs de marché, il est important de trouver une clef
commune pour la communication de ces messages : l’unité de
switching. Cette clef commune et les scénarios constituent la
base des processus de marché.
Om misverstanden te vermijden, willen we de term "Switching"
reserveren voor de marktprocessen en -partijen. Bijgevolg
zullen wij nooit een derde partij "switchen". De
beheersmodaliteiten van de relatie tussen toegangspunt en
derde partijen worden verduidelijkt buiten MIG.
Dans un souci de clarté, nous souhaitons réserver le terme
“Switching” aux processus et parties de marché.
En
conséquence, on ne « switchera » jamais une tierce partie.
Les modalités de gestion de la relation entre point d’accès et
parties tierces ne sont pas reprises dans le MIG.
We wensen ook de switching-eenheid te behouden op het
niveau van het toegangspunt: het laatstgenoemde blijft de
switch eenheid voor de markspelers (toegangshouder,
balance responsible, DNB, ...).
L’unité de switching est maintenue au niveau du point
d’accès : ce dernier reste l’unité de switch pour les acteurs de
marché (détenteur d’accès, balance responsible, GRD, ...).
Dit betekent dat:
we niet mogen "switchen" op een lager niveau, bv.
berekende meting;
we niet mogen "switchen" op een hoger niveau, bv.
op klantniveau (switch multi-sites);
eenzelfde klant die over meerdere toegangspunten
beschikt door verschillende toegangshouders van
levering voorzien kan worden (bv. een bepaalde
toegangshouder voor elektriciteit en een andere voor
gas).
Ceci implique :
qu’on ne pourra « switcher » à un niveau inférieur,
p.ex. comptage calculé
qu’on ne pourra « switcher » à un niveau plus élevé,
p.ex. au niveau du client (switch multi-sites)
qu’un même client qui a plusieurs points d’accès peut
être fourni par différents détenteurs d’accès (p.ex. un
détenteur d’accès donné pour l’électricité et un autre
pour le gaz).
Indien de markrelaties moeten wijzigen, zal dit altijd gebeuren
op het niveau van het toegangspunt in functie van de
regelgeving.
Si les relations de marché doivent changer, ceci se fera
toujours au niveau du point d’accès en fonction des
règlements.
3.3 Naar een modulaire aanpak (start/stop) – Vers une approche modulaire (start/stop)
START/STOP betreft een aanpak waarbij marktscenario’s op
een modulaire manier zijn gebouwd en worden uitgevoerd.
In deze context zijn de MIG4.1-scenario’s gegroepeerd per
module en worden ze niet meer beschouwd als afzonderlijke
workflows. De aanpak wordt START/STOP genoemd in
zoverre de belangrijkste modules toelaten om een
contractuele relatie te starten of te stoppen.
Dergelijke aanpak biedt vele voordelen en is in lijn met de
wensen uitgedrukt in de Point of View (referentiedocument [9])
en binnen de markt, met name om "klantprocessen sneller,
interactiever, eenvoudiger en transparanter te maken".
3.3.1
START/STOP désigne une approche dans laquelle les
scénarios de marché sont construits et exécutés de façon
modulaires. Dans cette optique, les scénarios du MIG4.1
sont regroupés par module et ne sont plus considérés
comme des workflows distincts. L’approche s’intitule
START/STOP dans la mesure où les modules principaux
permettent soit de démarrer une relation contractuelle soit de
la stopper.
Les avantages d’une telle approche sont multiples et sont
alignés avec la volonté exprimée dans le Point of View
(document de référence [9]) et à travers le marché de « rendre
les processus clients plus rapides, plus interactifs, plus
simples et plus transparents ».
Groepering van scenario’s met modules – ex-ante tests vs ex-post Monitoring – Regroupement des scénarios par
modules – Tests ex-ante vs Monitoring ex-post
De groepering van scenario’s per module impliceert niet dat de
notie "scenario" niet zal blijven bestaan maar voortaan wordt
dit als "label" aangeduid (notie "label" is behandeld in de
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Le regroupement des scénarios par module n’implique pas la
disparition de la notion de scénario. Celle-ci sera en fait
reprise à travers l’utilisation d’un label (notion couverte dans la
8/52
UMIG 6.0 Structuring Process
volgende sectie).
section prochaine).
De logische groepering van scenario’s per module werd
grotendeels gedaan op basis van tests die gemeenschappelijk
zijn tussen verschillende scenario's in een module. Deze tests
betreffen voornamelijk de verificatie van de basisgegevens die
gebruikt zijn in het transactionele bericht zoals de verificatie
van communicatiestandaarden (gedefinieerd en bekend in de
markt), het bestaan van de ID van het toegangspunt zoals
bekend in het toegangsregister, het GLN-nummer van de
toegangshouder, ...
La logique de regroupement des scénarios par module a été
réalisée en grosse partie en fonction des tests qui sont
communs entre les différents scénarios repris dans un
module. Ces tests consistent principalement en la vérification
des données de base utilisées dans le message transactionnel
telles que la vérification des standards de communication
(définis et connus dans le marché), l’existence de l’ID du point
d’accès tel que connu dans le registre d’accès, le numéro GLN
du détenteur d’accès, ...
Deze aanpak heeft een drievoudig doel:
de partij responsabiliseren die een module initieert
voor de juistheid van de gegevens en het respect
voor de marktregels;
de huidige processen vereenvoudigen (bv. met
betrekking tot de interacties);
een modulaire werking verzekeren.
Le but poursuivi avec cette approche est triple :
responsabiliser la partie qui initie un module quant à
l’exactitude des données et au respect des règles de
marché;
simplifier les processus actuels (p.ex. concernant les
interactions);
garantir un fonctionnement modulaire.
Deze groepering zal uitgevoerd zijn op basis van zogenaamde
ex-ante tests, in tegenstelling tot de ex-post tests die
gerelateerd zijn aan monitoring.
Ce regroupement sera opéré sur base de tests dits ex-ante,
en opposition avec les tests ex-post, ces derniers étant liés au
monitoring.
Ex-ante tests zijn tests die noodzakelijk zijn om de goede
uitvoering van de transactie op de markt te verzekeren
(verplichte tests zoals de verificatie van het bestaan van de
toegangshouder vermeld in een bericht). Deze tests zijn vooral
onafhankelijk van het label (= scenario's die we vandaag
kennen), zijn generiek en specifiek aan een module (uitgaande
van de groepering op basis van de tests).
Les tests ex-ante sont les tests qui sont nécessaires pour
assurer la bonne exécution de la transaction sur le marché
(tests obligatoires tels que la vérification d’existence du
détenteur d’accès indiqué dans un message). Ces tests sont
pour la plupart indépendants du label (= les scénarios que
nous connaissons actuellement), sont génériques et propres à
un module (étant donné le regroupement sur base des tests).
Ex-post (monitoring) tests zijn bedoeld om de naleving van de
markafspraken en ook om de naleving van bepaalde zaken in
de wetgeving te controleren (noodzakelijke tests). Ze worden
uitgevoerd na de lancering van een transactie op de markt (op
voorwaarde dat deze de ex-ante tests heeft doorstaan).
Les tests ex-post (monitoring) visent à contrôler le respect des
règles de marché et aussi de certains éléments de la
législation (tests nécessaires). Ils sont menés après le
lancement d’une transaction sur le marché (à condition que
celle-ci satisfasse aux tests ex-ante).
Dit onderscheid tussen ex-ante en ex-post leidt tot
responsabilisering
van
de
partijen,
aangezien
de
initiatiefnemer van het scenario de juistheid van de informatie
in het bericht moet verzekeren. De voordelen van een
dergelijke aanpak zijn ook slechts tastbaar indien er een
aanvaardbaar evenwicht bestaat tussen ex-ante en ex-post
door extreme situaties te voorkomen, waarin:
- of de grote meerderheid van tests ex-ante wordt
uitgevoerd;
- of de grote meerderheid van de tests wordt
overgebracht naar de ex-post monitoring: risico dat
een groter aantal berichten foutieve gegevens bevat.
Cette distinction entre ex-ante et ex-post mène à une
responsabilisation des parties puisque l’initiateur du scénario
doit assurer l’exactitude des informations qu’il passe dans le
message. Aussi les avantages d’une telle approche ne sont
palpables que s’il existe un équilibre acceptable entre ex-ante
et ex-post en évitant les situations extrêmes où :
- soit la grande majorité des tests est effectuée en exante ;
- soit la grande majorité des tests est transférée en
monitoring ex-post : risque d’avoir un plus grand
nombre de messages contenant de mauvaises
informations.
Merk tevens op dat de ex-ante tests per categorie
gegroepeerd zijn (zie referentiedocument [5]) en dat ze
categorie per categorie worden uitgevoerd. Met andere
woorden, als een aanvraag een of (meerdere) tests 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 tests
binnen een categorie.
A noter aussi que les tests ex-ante sont regroupés par
catégorie (voir document de référence [5]) et qu’ils sont lancés
catégorie par catégorie. En d’autres mots, si une demande
échoue à un (ou plusieurs) tests 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.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
9/52
UMIG 6.0 Structuring Process
Op basis van
het label
Sur base du
label
Op basis van
de module
Sur base du
module
Inkomend
Bericht
Message
entrant
Test ExAnte
Behandeling van de transactie
in het Toegangsregister
Enregistrement transaction
dans Registre d’Accès
Stuuren van een uniek bericht
met error code(n)
Envoi message unique avec
code(s) d’erreur
Monitoring
Ex-Post
t
Rechstreeks reeks / Enchaînement immédiat
Pas d’enchaînement immédiat / Onrechstreeks reeks
Figure 1 - Tests Ex-Ante versus Ex-Post Monitoring v1.0
3.3.2
Het label – Le label
Het gebruik van het label laat in een module toe om de notie
van scenario’s te behouden. Het label wordt gebruikt om:
de ex-post monitoring van de marktafspraken te
verzekeren: na te gaan of de marktregels gerelateerd
aan het scenario gerespecteerd zijn (timings, ...); ;
te zorgen voor een goed verloop van de workflows bij
de marktpartijen ("welk scenario betreft het?");») ;
de marktpartijen toe te laten om de rapportering aan
de regulator te verzekeren;
de
marktpartijen
toe
te
laten
de
juiste
context/informatie te kennen voor het beantwoorden
van vragen van netgebruikers en voor het oplossen
van problemen/vragen.
Le label permet de conserver la notion des scénarios à travers
l’utilisation des modules. Il est utilisé pour :
Assurer le monitoring ex-post des accords de
marché : vérifier que les règles de marché liées au
scénario sont bien respectées (timings, ...) ;
Assurer le bon déroulement des workflows chez les
parties de marché (« de quel scénario s’agit-il ? ») ;
Permettre aux acteurs de marché d'assurer le
reporting au régulateur ;
Permettre aux parties de marchés de connaître le
contexte/l’information correcte et pouvoir ainsi
répondre aux questions des Utilisateurs du réseau et
pouvoir résoudre les problèmes/questions.
Dit label wordt verzonden door de initiator van het bericht: de
partij die het scenario initieert is verantwoordelijk voor het label
en dient het label van het relevante scenario aan te leveren
(principe van de responsabilisering van de marktpartijen).
Ce label sera transmis par l’initiateur du message : la partie
qui initie le scénario en est responsable et doit fournir le label
du scénario concerné (principe de responsabilisation des
parties de marché).
3.3.3
Chronologie van berichten – Chronologie des messages
Zodra een bericht verzonden is en de ex-ante tests doorstaat,
is dit onmiddellijk geregistreerd. Voorbeeld: een transactie met
een effectieve datum van 30 dagen in de toekomst wordt
gelanceerd en betreft een verandering in de relatie
toegangshouder-klant. De wijziging in deze relatie wordt
geregistreerd op de aanvraagdatum en zal automatisch van
toepassing zijn op de effectieve datum.
Lorsqu’un message est envoyé et passe les tests ex-ante,
celui-ci est directement enregistré. Par exemple, une
transaction avec une date effective située 30 jours dans le
futur est lancée et concerne un changement dans la relation
détenteur d’accès-client. Le changement dans cette relation
sera enregistré à la date de la demande et sera
automatiquement d’application à la date effective.
Bovendien, dankzij de scheiding van ex-ante tests en ex-post
monitoring, zal er niet langer onderscheid gemaakt worden
tussen een testingperiode, annulatieperiode of frozen periode.
De post-processing periode, die nodig is om de werken op het
terrein te realiseren, wordt geïntegreerd in het "lock"-principe
(zie volgende sectie). Dit principe is van toepassing op
klassieke en slimme meters (de relevante scenario's zullen
uiteraard niet hetzelfde zijn).
Par ailleurs, grâce à la séparation entre tests ex-ante et le
monitoring ex-post, il ne faudra plus faire de distinction entre
périodes de test, d’annulation ou frozen. Quant à la période de
post-processing, qui est nécessaire à la réalisation des
travaux sur le terrain, elle sera intégrée dans le principe du
« lock » (voir section suivante). Ce principe sera appliqué pour
les compteurs classiques et intelligents (bien entendu les
scénarios concernés ne seront pas les mêmes).
Betreffende de lancering van scenario's in het verleden
(Structuring bericht), is er geen business reden om
Concernant le lancement de scénarios dans le passé
(message Structuring), il n’y a pas de raison business d’avoir
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
10/52
UMIG 6.0 Structuring Process
standaardtransacties verder dan 60 dagen in het verleden toe
1
te laten.
des transactions standards autorisées à plus de 60 jours dans
2
le passé.
Tot slot, wat betreft de rectificaties, deze worden gerealiseerd
volgens het undo/redo-principe: de timeslices worden
verwijderd/teruggezet tot op de dag waarop de correctie
betrekking heeft en waarop alles weer herbouwd is.
Enfin, concernant les rectifications, celles-ci seront réalisées
selon le principe d’undo/redo : les timeslices sont
enlevées/remises jusqu’au jour où la correction doit être
apportée et où tout est à nouveau reconstruit.
Wij maken een onderscheid tussen twee gevallen:
1. Generieke gevallen waarvoor de toepassing van
het undo/redo-principe geautomatiseerd en
geautoriseerd is tot aan de dichtstbijzijnde datum
van de definitief gereconcilieerde maand
(bv. X - 35 maanden waarbij X de maand
van systeemdatum is)
Deux cas seront distingués :
1. Les cas génériques pour lesquels l’application du
principe de l’undo/redo est automatisée et
autorisée jusqu’à la date la plus proche
du mois réconcilié définitivement (p.ex. X –
35 mois où X est le mois de la date
système)
of
van de datum van een fysiek scenario (bv.
meterwijziging).
De
gevallen
waarvoor
undo/redo
niet
geautomatiseerd is en waarvoor de aanpassing
manueel zal gebeuren.
ou
de la date d’un scénario physique (p.ex.
changement compteur).
Les cas pour lesquels l’undo/redo ne sera pas
automatisé et pour lesquels l’adaptation sera
faite manuellement.
-
2.
-
2.
3.4 Statussen en locks – Les statuts et locks
3.4.1
Definities van de statussen – Définitions des statuts
Om de fysieke realiteit en de markt-, dus de contractuele
realiteit duidelijk te onderscheiden, wordt een opsplitsing
gemaakt tussen de fysieke status en de contractuele status.
Fysieke status
Statut physique
Afin de scinder clairement la réalité physique de la réalité du
marché, c’est-à-dire contractuelle, une distinction est opérée
entre le statut physique et le statut contractuel.
Definieert de fysieke status van het toegangspunt: open, gesloten, verwijderd. Onderhouden
door de DNB.
Définit l’état physique du point : ouvert, fermé, supprimé. Maintenu par le GRD.
Contractuele status
Statut contractuel
Definieert de contractuele status van het toegangspunt, met andere woorden, bepaalt of een
leveringscontract van aankoop of verkoop van energie is geregistreerd in het
toegangsregister voor dit specifiek toegangspunt. In het kader van een Move In zal deze
status pas actief zijn wanneer de ingebruikname heeft plaatsgevonden. Deze relatie wordt
beheerd door de toegangshouder in functie van enerzijds de evolutie van de commerciële,
contractuele links op het toegangspunt en anderzijds de switching-modaliteiten die van
toepassing zijn.
Définit l'état contractuel du point d'accès, c'est-à-dire détermine si un contrat de fourniture
d’achat ou de vente d'énergie est enregistré dans le registre d'accès pour ce point d'accès
particulier. Dans le cadre d’un Move In, ce statut ne sera actif que lorsque la mise en
service aura eu lieu. Cette relation est maintenue par le détenteur d’accès en fonction d'une
part de l'évolution des liens contractuels commerciaux sur ce point d'accès et d'autre part
des modalités de switching en vigueur.
Beide gegevens zullen dus per toegangspunt beschikbaar
zijn. Toegestane combinaties worden a priori bepaald en de
vereiste controles worden opgenomen zijn in de modules en
in de monitoring die de niet-toegestane combinaties
identificeert en waarvoor rectificaties kunnen worden gestart.
Deux informations seront donc disponibles par point d’accès.
Les combinaisons autorisées seront déterminées a priori et
les contrôles requis seront introduits dans les modules et
dans le monitoring qui identifiera les combinaisons non
permises et pour lesquelles des rectifications pourront être
1
De beperking van 60 dagen in het verleden betekent voor de markt dat de aankondiging van verhuizingen op meer dan 60 dagen niet beheerd
kan worden. En dat de indexen van een verhuizing die meer dan 60 dagen in het verleden ligt niet meegedeeld kunnen worden voor een
verhuisdatum die wel binnen de limiet van 60 dagen valt.
2
La contrainte des 60jours dans le passé signifie pour le marché que l’annonce de déménagements antérieurs à 60 jours ne pourra pas être
gérée. Et que les index d’un déménagement situé plus loin que 60 jours dans le passé ne pourront pas être communiqués pour une date de
déménagement tombant elle bien dans l’intervalle limite des 60 jours.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
11/52
UMIG 6.0 Structuring Process
Deze statussen zijn dus niet louter informatief, maar worden
ook in de marktprocessen gebruikt: beide gegevens moeten
daarom voortdurend onderhouden worden. Bovendien wordt
de contractuele status in de gehele E2E-keten van
marktprocessen gebruikt (metering, structuring, settlement &
gridfee).
3.4.2
-
initiées. Ces statuts ne sont donc pas uniquement informatifs,
mais sont aussi utilisés dans les scénarios de marché: les
deux informations devront donc être maintenues en continu.
Par ailleurs, le statut du contrat sera utilisé sur toute la
chaîne E2E des processus de marché (metering, structuring,
settlement & gridfee).
Lock principe - Principe du lock
De markt wil de werking van de processen versnellen door ze
onder meer makkelijker en transparanter te maken. Deze wil
vertaalt zich in de afschaffing van de frozen en postprocessing periodes die in vorige versies van de MIG de
marktwerking blokkeerden.
La volonté du marché est d’accélerer le fonctionnement des
processus en les rendant entre autres choses plus faciles et
transparents. Cette volonté se traduit par la suppression des
périodes frozen et de post-processing qui dans des versions
antérieures du MIG bloquaient le fonctionnement du marché.
In die periodes moest een toegangshouder die ondanks alles
een transactie wilde doorvoeren, een beveiligde E44
procedure opstarten in de gevallen dat het blokkerend proces
een einde levering betrof (bv. Drop).
Pendant ces périodes, un détenteur d’accès souhaitant faire
malgré tout passer une transaction devait initier une
procédure de E44 Sécurisé dans les cas où le processus
bloquant était un processus de fin de fourniture (p.ex. Drop).
Het verdwijnen van de bevroren en post-processing periodes
heeft aanleiding gegeven tot de ontwikkeling van de lock, die
werkt als volgt:
La disparition des périodes frozen et post-processing a
motivé le développement du lock dont le principe est le
suivant :
de DNB heeft de mogelijkheid om een toegangspunt tijdelijk
te blokkeren, dat wil zeggen de behandeling van alle
binnenkomende transacties voorkomen. Deze ‘lock’ zal in
een reeks situaties geplaatst worden die werden vastgelegd
door de DNB en die aan de markt worden meegedeeld in de
vorm van een reden:
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. Ce ‘lock’ sera placé dans une série
de situations définies par le GRD, ces situations seront
communiquées sous la forme de raison au marché :
reden van Werken (wanneer een DNB bezig is met, of zal
overgaan tot de uitvoering van werken aan een toegangspunt),
reden van Rectificatie (wanneer een DNB bezig is met de
uitvoering van rectificaties gekoppeld aan een
toegangspunt).
3.4.3
raison de Travaux (lorsqu’un GRD est en train ou va
réaliser des travaux sur un point d’accès),
raison de Rectifications (lorsqu’un GRD est en train
d’effectuer des rectifications liées à un point d’accès).
Lock plaatsen/verwijderen – Placement/Enlèvement lock
De locks op het niveau van het contract en die op fysiek
niveau hebben een verschillende impact op de marktwerking:
Lock op contractniveau = lock op de markttransacties
(uitgezonderd voor transacties m.b.t. Update BRP,
Update BMD en Prepayment) het punt is onder andere
niet meer "switchable" (alle binnenkomende modules
worden geweigerd, uitgezonderd de Update BRP,
Update BMD en Prepayment-modules);
Lock op fysiek niveau = lock van de DNB-transacties,
voor de markt onzichtbare lock.
Les locks au niveau du contrat et ceux au niveau physique
ont des impacts différents sur le fonctionnement du marché :
Lock au niveau du contrat = lock sur les transactions de
marché (exception faite des transactions liées au Update
BRP, Update BMD et prépaiement)  le point n’est plus
‘switchable’ entre autres (chaque module entrant est
refusé excepté les demandes des modules Update BRP,
Update BMD et Prepayment);
Lock au niveau physique = lock des transactions GRD,
lock invisible pour le marché.
De twee types lock kunnen geplaatst worden door de DNB (of
door leverancier X of door de Metering Point Administrator).
Een commercieel toegangshouder kan een toegangspunt niet
locken daar dit de werking van de geliberaliseerde markt zou
verstoren.
Les deux types de lock peuvent être placés par le GRD (ou
par le fournisseur X ou par le Metering Point Administrator).
Un détenteur d’accès commercial ne pourra pas locker un
point d’accès car cela constituerait une entrave au
fonctionnement du marché libéralisé.
Kort gezegd, beslist de DNB (of leverancier X of de Metering
Point Administrator) om de markt te blokkeren op een punt
waarvan hij meent dat het op dat ogenblik problemen zou
kunnen opleveren. Er zijn veel dergelijke situaties en ze
moeten bepaald worden door de DNB. Wel moet bij plaatsing
van een lock door de DNB, altijd de reden van die lock
vermeld worden (Werken of Rectificatie) en eventueel (als de
DNB die informatie heeft) de voorziene einddatum van de
En bref, le GRD (ou par le fournisseur X ou par le Metering
Point Administrator) décide de bloquer le marché sur un point
pour lequel il estime que momentanément cela pourrait
causer un préjudice. Ces situations sont multiples et diverses
et doivent être déterminées par le GRD. Néanmoins, le
placement du lock par le GRD devra toujours indiquer la
raison du lock (Works ou Rectification) et éventuellement (si
le GRD détient cette information) la date de fin prévue du
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
12/52
UMIG 6.0 Structuring Process
lock.
De lancering van een aanvraag door de toegangshouder op
een locked toegangspunt zal leiden tot verwerping van zijn
aanvraag (in het verwerpingsbericht worden de reden van de
lock en optionele einddatum vermeld).
Balance
Supplier
lock.
Le lancement d’une demande de la part d’un détenteur
d’accès sur un point d’accès locked entraînera le rejet de sa
demande (dans le message de rejet, la raison du lock et son
optionnelle date de fin seront reprises).
Metering Point
Administrator
DGO
Lock
(reason + enddate(opt))
Statut LOCK
Module x
Reject with lock
reason and enddate
Figure 2 - Request Unlock v1.0
De toegangshouder wiens marktproces geblokkeerd zou zijn,
kan altijd toestemming vragen aan de DNB om de situatie zo
mogelijk te deblokkeren via de flag Request Unlock (zie
referentiedocument [3]). De DNB heeft dan de mogelijkheid
om de aanvraag van de toegangshouder al dan niet te
aanvaarden.
Le détenteur d’accès dont le processus de marché serait
bloqué peut toujours demander l’autorisation au GRD
d’éventuellement débloquer la situation via le flag Request
Unlock (voir document de référence [3]). Le GRD a alors la
possibilité d’accepter ou non la demande du étenteur d’accès.
Merk op dat een sociale leverancier die een klant met
schulden heeft, geen lock zal plaatsen op een toegangspunt.
Zo zal in geval dat een commerciële toegangshouder een
toegangspunt zou willen overnemen, de sociale leverancier
een aanvraag tot annulatie van deze overname door de
commerciële toegangshouder moeten sturen (cancel module
zie 5.16).
A noter qu’un fournisseur social ayant un client présentant
des dettes, ne placera pas de lock sur le point d’accès. De
sorte à ce que si un détenteur d’accès commercial essayait
de reprendre le point d’accès, le fournisseur social enverra
une demande d’annulation de la reprise par le détenteur
d’accès commercial (cancel module voir 5.16).
Ook is het belangrijk te preciseren dat een toegangshouder
de (contractuele) lock-status van een toegangspunt zal
kunnen nagaan door raadpleging van de preswitching LIGHT
of FULL (zie referentiedocument [2]).
Aussi, il est important de préciser qu’un détenteur d’accès
aura la possibilité de connaître le statut lock (contractuel) lié à
un point d’accès grâce à une consultation du preswitching
LIGHT ou FULL (voir document de référence [2]).
Tot slot herinneren we eraan dat de lock maar een tijdelijke
status is, die in de eerste plaats tot doel heeft het beheer van
uitzonderlijke situaties te vergemakkelijken. Indien echter een
lock op een toegangspunt de lancering van een transactie
door een toegangshouder zou blokkeren, zal hij steeds over
de mogelijkheid beschikken om aan de DNB tot wie dit
toegangspunt behoort, te vragen om een "unlock" op dit punt
te realiseren. Ex-post monitoring regels zouden toegepast
kunnen worden om het correcte gebruik van de lock door de
DNB's te verifiëren, net als het correcte gebruik van de flag
"Request Unlock" door de toegangshouders (bv. vraag om
unlock op een toegangspunt dat niet locked is, herhaalde
vragen om unlock binnen een korte tijd).
Pour conclure, rappelons que le lock n’est qu’un statut
temporaire et qu’il a avant tout pour vocation de faciliter la
gestion de situations exceptionnelles. Si toutefois, un lock sur
un point d’accès venait à bloquer le lancement d’une
transaction par un détenteur d’accès, celui-ci aura toujours la
possibilité de demander au GRD responsable du point de
réaliser un « unlock » du point. Des règles de monitoring expost pourraient par ailleurs être appliquées pour vérifier la
bonne utilisation du lock par les GRDs, tout comme
l’utilisation correcte du flag « Request Unlock » par les
détenteurs d’accès (p.ex. demande d’unlock sur un point
d’accès pas locked, demandes à répétition d’unlock sur un
court intervalle de temps).
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
13/52
UMIG 6.0 Structuring Process
4 Inleiding op modules – Introduction aux modules
4.1 Introductie – Introduction

In het onderhavige hoofdstuk kan een persoon die
geen kennis heeft van de marktwerking in het
algemeen, het type marktaanvraag (module) vinden
dat hij in gang zou moeten zetten om een gewenste
actie voor een Toegangspunt uit te voeren.

Een uitvoeriger beschrijving van deze aanvragen is
opgenomen in hoofdstuk 5 : definitie, resultaat,
toepasbaarheid.

Wij onderscheiden vier categorieën van aanvragen:
1. Contractuele aanvragen: iedere aanvraag die
gevolgen heeft voor de contractuele toestand
van een Toegangspunt, zoals geregistreerd in
het Toegangsregister en in de systemen van de
marktpartijen;
2. Aanvragen tot wijziging van toegang: iedere
aanvraag die geen contractuele impact heeft
maar die leidt tot een wijziging van de toegang
van het Toegangspunt;
3. Aanvragen om bijwerking van gegevens: iedere
aanvraag die er hoofdzakelijk op gericht is
gegevens verbonden aan een voor een
Toegangspunt
geregistreerd
contract
te
wijzigen;
4. Aanvragen om rectificatie of annulatie: iedere
aanvraag om rectificatie of annulatie van
uitgewisselde marktberichten.

Dit hoofdstuk is opgebouwd per categorie en wijst de
lezer, aan de hand van stroomschema’s en vragen
die hij zich zou kunnen stellen aangaande het type
actie, op de geschikte module.

Heeft de lezer, na het doorlopen van alle categorieën,
niet het type aanvraag dat hij zoekt gevonden, dan
betekent dit:
hetzij – en waarschijnlijk – dat de aanvraag die
hij zoekt deel uitmaakt van een ander domein;
hetzij dat de aanvraag die hij zoekt niet bestaat
in de MIG6-marktprocessen.

Le présent chapitre permet à une personne n’ayant
pas de connaissance du fonctionnement de marché
en général, de retrouver le type de demande de
marché (modules) qu’il devrait initier pour réaliser
une action souhaitée sur un Point d’Accès.

Une description plus détaillée de ces demandes est
reprise dans le chapitre 5 : définition, résultat,
applicabilité.

Nous distinguons quatre catégories de demande :
1. Demandes contractuelles : toute demande
ayant des retombées sur la situation
contractuelle d’un Point d’Accès, c’est-à-dire
telle qu’enregistrée dans le Registre d’Accès et
dans les systèmes des parties de marché ;
2. Demandes de modification d’accès : toute
demande n’ayant pas d’impact contractuel mais
entraînant une modification de l’accès du Point
d’Accès ;
3. Demandes de mise à jour de données : toute
demande visant principalement à modifier des
données liées à un contrat enregistré pour un
Point d’Accès ;
4. Demandes de rectification ou d’annulation :
toute demande de rectification ou d’annulation
de messages de marché échangés.

Ce chapitre est structuré par catégorie et indique au
lecteur, au moyen de flow et de questions qu’il
pourrait se poser par rapport au type d’action qu’il
souhaiterait voir effectuée, le nom du module
recommandé.

Si après avoir consulté l’ensemble des catégories, le
lecteur ne devait pas avoir trouvé le type de demande
qu’il recherche, c’est
Soit, et probablement, que la demande qu’il
recherche fait partie d’un autre domaine ;
Soit que la demande qu’il recherche n’existe
pas dans les processus de marché MIG6.

Sept types de demande ayant un impact sur la
situation contractuelle d’un Point d’Accès ont été
définies. Elles sont regroupables en deux souscatégories :
4.2 Contractuele aanvragen – Demandes contractuelles

Er zijn zeven types van aanvragen gedefinieerd die
een impact hebben op de contractuele toestand van
een Toegangspunt. Ze kunnen onderverdeeld
worden in twee subcategorieën:
1.
2.
Aanvragen verbonden aan de start van een
contract:
Request Start
Move In
Initiate Local Production
Start Access
Aanvragen verbonden aan de beëindiging van
een contract:
Initiate Stop Access
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
1.
2.
Demandes liées à un démarrage de contrat :
Request Start
Move In
Initiate Local Production
Start Access
Demandes liées à une fin de contrat :
Initiate Stop Access
Move Out
14/52
UMIG 6.0 Structuring Process
-
Move Out
Initiate Leaving Customer
-
Initiate Leaving Customer
Figure 3 - Contractual Requests v1.0
4.3 Aanvragen om wijziging toegang – Demandes de modification d’accès

Er zijn twee types van aanvragen gedefinieerd die
een wijziging meebrengen van de toegang voor een
Toegangspunt:
Initiate Update Access
Prepayment (merk op dat voor het label
Balance Notification het eerder gaat over een
update)
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx

Deux types de demande entraînant une modification
de l’accès d’un Point d’Accès sont définies:
Initiate Update Access
Prepayment (à noter que pour le label Balance
Notification, il s’agit plutôt d’une mise à jour)
15/52
UMIG 6.0 Structuring Process
Access
modification
wished?
Yes
Prepayment
desactivated or to
be desactivated?
No
No
See other
categories
Prepayment
Yes
Initiate
Update
Access
Figure 4 - Access Modification Requests v1.0
4.4 Aanvragen om bijwerking van gegevens – Demandes de mise à jour de données

Er zijn vier types van aanvragen gedefinieerd voor
wijziging van gegevens verbonden aan een
Toegangspunt. Ze kunnen onderverdeeld worden in
twee subcategorieën:

Quatre types de demande de modification de
données liées à un Point d’Accès sont définies. Elles
sont regroupables en deux sous-catégories :
1.
Aanvragen opgestart door de toegangshouder:
Update Customer Metering Configuration
Update BRP
Update Business Master Data
1.
Demande initiée par le détenteur d’accès :
Update Customer Metering Configuration
Update BRP
Update Business Master Data
2.
Aanvragen opgestart door de DNB in zijn rol van
Meter Administrator:
Update Technical Master Data
2.
Demande initiée par le GRD dans son rôle de
Meter Administrator :
Update Technical Master Data
Figure 5 - Data Update Requests v1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
16/52
UMIG 6.0 Structuring Process
4.5 Aanvragen om rectificatie / annulatie – Demandes de rectification / annulation

Er zijn twee types van aanvragen gedefinieerd om
rectificaties of annulaties van andere aanvragen of
ontvangen berichten van de markt te realiseren:
Cancel
Request Rectification
Rectication or
cancelation ?
Yes

Deux types de demande sont définies pour réaliser
des rectifications ou des annulations d’autres
demandes ou messages reçus du marché :
Cancel
Request Rectification
Not effective
module
cancellation?
No
No
Yes
Request
Cancel
Request
Rectification
See other
domains
Figure 6 - Rectification or Cancellation Requests v1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
17/52
UMIG 6.0 Structuring Process
5 Modules MIG6 Modules
5.1 Introductie – Introduction
Volgens de modulaire aanpak (zie sectie 3.3.1), werd een lijst
van 15 modules opgesteld.
Suivant l’approche modulaire (voir section 3.3.1), une liste de
15 modules a été dressée.
Deze modules zijn:
- ofwel een samenvoeging van scenario’s zoals gekend in
MIG4.1.
Een MIG4.1-scenario kan in feite gezien worden als een
geheel van functionaliteiten (bv. wijziging van specifieke
waarden in het toegangsregister) en marktregels (bv. het
scenario kan niet gelanceerd worden op meer dan 100
dagen in de toekomst). De samenvoeging van de
MIG4.1-scenario’s in de modules steunt op hun
functionaliteiten.
ofwel zuivere nieuwigheden.
Ces modules sont :
- soit des regroupements de scénarios tels que connus
dans le MIG4.1.
Un scénario MIG4.1 peut en fait être entrevu comme
étant un ensemble de fonctionnalités (p.ex. modification
de valeurs particulières dans le registre d’accès) et de
règles de marché (p.ex. le scénario ne peut pas être
lancé à plus de 100jours dans le futur). Les modules
regroupent les scénarios MIG4.1 en fonction de leurs
fonctionnalités.
soit de pures nouveautés.
De notie label laat toe rekening te houden met marktregels die
specifiek zijn voor een scenario.
Dit hoofdstuk geeft een overzicht van de functionaliteiten van
de verschillende modules die in MIG6 zijn gedefinieerd en
bevat, na de omschrijving van de modules en hun label, een
stroomschema dat aan de lezer aangeeft in welke MIG6documenten de processen worden uitgelegd.
La notion de label permet de tenir compte des règles de
marché propres à un scénario.
Cette section donne un aperçu des fonctionnalités des
différents modules définis en MIG6 et reprend, après les
définitions des modules et de leur label, un flow indiquant au
lecteur quels sont les documents du MIG6 expliquant les
processus.
De afbeelding hieronder bevat alle vormen die gebruikt
worden om de te raadplegen documenten weer te geven:
La figure ci-dessous reprend l’ensemble des formes utilisés
pour représenter la série des documents à consulter :
-
De vorm waar de module erin staat, geeft de betrokken
module weer;
-
La forme avec module indiqué dedans indique le module
concerné ;
-
De "document"-vormen geven de te raadplegen
documenten weer:

In paars: een algemeen document dat bepaalde
aspecten van de betrokken module behandelt;

In blauw: een document betreffende een andere
dan de betrokken module, die er echter
rechtstreeks verband mee houdt;

In grijs: een document dat de betrokken module
uitlegt;

In oranje: een aanvullend document bij het
beschreven proces.
-
Les formes « documents » indiquent les documents à
consulter :

En mauve : un document général traitant de
certains aspects du module concerné ;

En bleu : un document traitant d’un autre module
que celui concerné mais qui est directement lié à
celui-ci ;

En gris : un document expliquant le module
concerné ;

En orange : un document complémentaire au
processus décrit.
-
De pijl geeft de volgorde aan waarin de verschillende
opgenomen documenten moeten worden gelezen.
-
La flèche qui indique l’ordre dans lequel les différents
documents repris devraient être lus.
Module
UMIG 6.0 - BR - ST
- Level –
Document title
UMIG 6.0 - BR - ST
- Level –
Document title
UMIG 6.0 - BR - ST
- Level –
Document title
UMIG 6.0 - BR - ST
- Level –
Document title
Figure 7 - Convention v1.0
5.2 Start Access
Wanneer een toegangshouder een contract heeft gesloten met
een klant en hij dit contract wil registreren in het
toegangsregister of wanneer een sociaal leverancier of
leverancier X een klant te zijnen laste moet nemen.
Lorsqu’un détenteur d’accès a signé un contrat avec un client
et souhaite enregistrer ce contrat dans le registre d’accès ou
lorsqu’un fournisseur social ou X doit reprendre un client à sa
charge.
Er worden 4 labels onderscheiden:
On distingue 4 labels :
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
18/52
UMIG 6.0 Structuring Process
-
Supplier Switch: de klant op het Toegangspunt waarop
de Start Access aanvraag betrekking heeft blijft gelijk
maar de toegangshouder verandert;
-
Supplier Switch : le client sur le Point d’Accès visé dans
la demande de Start Access reste le même mais le
détenteur d’accès change ;
-
Customer Switch: de toegangshouder op het
Toegangspunt waarop de Start Access aanvraag
betrekking heeft blijft gelijk maar de klant verandert;
-
Customer Switch : le détenteur d’accès sur le Point
d’Accès visé dans la demande de Start Access reste le
même mais le client change ;
-
Combined Switch: de toegangshouder en de klant op het
Toegangspunt waarop de Start Access aanvraag
betrekking heeft veranderen;
-
Combined Switch : le détenteur d’accès et le client
changent sur le Point d’Accès visé dans la demande de
Start Access ;
-
Switch Back Brussels: wanneer een klant beheerd door
de SOLR moet teruggaan naar de markt bij zijn
commerciële toegangshouder (aangezien er geen schuld
meer is tegenover deze laatste of zijn statuut als
beschermde klant is verloren). Deze label is enkel van
toepassing in Brussel;
-
Switch Back Brussels : lorsqu'un client géré par le SOLR
doit retourner dans le marché auprès de son détnteur
d’accès commercial (étant donné qu’il n'a plus de dettes
envers ce dernier ou qu’il a perdu son statut de client
protégé). Ce label n’est d’application qu’à Bruxelles ;
-
Switch To SOLR : wanneer een klant het kenmerk van
beschermde klant ontvangt, wordt hij in beheer genomen
door de SOLR en wordt zijn contract tijdelijk opgeheven.
Na aanzuivering van zijn schulden of bij verlies van het
beschermd statuut, moet de klant terugkeren naar zijn
commerciële leverancier om daar verder beleverd te
worden volgens zijn bestaand contract. Dit wordt
uitgevoerd via het label Switch Back Brussels. Deze
label is enkel van toepassing in Brussel.
-
Switch To SOLR : lorsqu’un client
reçoit la
caractéristique de client protégé, il est pris en charge par
le SOLR et son contrat commercial est temporairement
suspendu. Après apurement de ses dettes ou perte du
statut protégé, le client doit retourner vers son
fournisseur commercial pour poursuivre son contrat
existant cela est réalisé avec le label Switch Back
Brussels. Ce label n’est d’application qu’à Bruxelles.
Nota: merk op dat zelfs al is dit niet het primaire doel van de
Start Access module, dit ook een wijziging toelaat van de
configuratie van het Toegangspunt van de aanvraag.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
Start
Access
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
Note : à noter que même si ce n’est pas là la vocation
première du module de Start Access, celui-ci permet
également de demander un changement de la configuration
du Point d’Accès de la demande.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Start Access
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 8 - Start Access Documentation v1.0
5.3 Move In
Wanneer een toegangshouder een contract heeft gesloten met
een klant en hij vaststelt dat het Toegangspunt inactief is. Hij
stuurt dan een Move In aanvraag die dienst doet als "groen
licht" en stelt de Meter Administrator in kennis dat de
indienststelling van het Toegangspunt kan plaatshebben als
de DNG dat aanvraagt aan zijn DNB.
Lorsqu’un détenteur d’accès a signé un contrat avec un client
et qu’il constate que le Point d’Accès est inactif. Il envoie alors
une demande de Move In faisant office de « green light » et
notifier au Meter Administrator qu’une mise en service du
Point d’Accès peut être effectuée lorsque l’URD en fera la
demande à son GRD.
Er is maar één label: Move In.
Il n’y a qu’un seul label : Move In.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
19/52
UMIG 6.0 Structuring Process
Nota: merk op dat zelfs al is dit niet het primaire doel van de
Move In module, dit ook een wijziging toelaat van de
configuratie van het Toegangspunt van de aanvraag.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
UMIG 6.0 - BR - ST
- 03 Preswitching
Move In
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
Note : à noter que même si ce n’est pas là la vocation
première du module de Move In, celui-ci permet également de
demander un changement de la configuration du Point
d’Accès de la demande.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Move In
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle_Request
Handle Cancel
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
UMIG 6.0 - BR - ST
- 04 Timings
Figure 9 - Move In Documentation v1.0
5.4 Move Out
Wanneer een klant aan zijn toegangshouder laat weten dat hij
zijn contract wil beëindigen en zijn Toegangspunt buiten dienst
wil stellen. De toegangshouder stuurt dan een Move Out
aanvraag die dienst doet als "rood licht" en stelt de Meter
Administrator ervan in kennis dat het Toegangspunt buiten
dienst mag worden gesteld als de DNG dat aanvraagt aan zijn
DNB. Een dergelijke actie kan ook worden uitgevoerd door de
Meter Administrator, maar zal dan in gang gezet worden door
een andere module, de Update Technical Master Data. Een
specifiek label (BA9: Move Out) geeft aan dat de Meter
Administrator een Toegangspunt buiten dienst heeft gesteld.
Hierdoor wordt de verantwoordelijkheid stopgezet van de
toegangshouder die actief is voor het Toegangspunt.
Er is maar één label: Move Out.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
Move
Out
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
Lorsqu’un client notifie à son détenteur d’accès qu’il souhaite
mettre fin à son contrat et mettre hors service son Point
d’Accès. Le détenteur d’accès envoie alors une demande de
Move Out faisant office de « red light » et notifier au Meter
Administrator qu’une mise hors service du Point d’Accès peut
être effectuée lorsque l’URD en fera la demande à son GRD.
Une telle action peut aussi être effectuée par le Meter
Administrator mais sera initiée via un autre module, celui du
Update Technical Master Data. Un label dédié (BA9 : Move
Out) indiquera le fait que le Meter Administrator a mis hors
service un Point d’Accès. Cela aura pour effet de stopper la
responsabilité du détenteur d’accès actif sur le Point d’Accès.
Il n’y a qu’un seul label : Move Out.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Move Out
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Cancel
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 10 - Move Out Documentation v1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
20/52
UMIG 6.0 Structuring Process
5.5 Initiate Local Production
Wanneer een contract werd gesloten voor een ander lokaal
productieproces dan dat van toepassing bij de aanvraag.
Lorsqu’un contrat a été signé pour un processus de production
locale autre que celui d’application lors de la demande.
Er worden 5 labels onderscheiden:
On distingue 5 labels :
-
Supplier Switch: de actieve klant op het HeadPoint
opgegeven in de Initiate Local Production aanvraag blijft
dezelfde maar de toegangshouder en het lokale
productieproces veranderen;
-
Supplier Switch : le client sur le HeadPoint indiqué dans la
demande de Initiate Local Production reste le même que
celui actif précédemment mais le détenteur d’accès et le
processus de production locale changent ;
-
Customer Switch: de toegangshouder op het HeadPoint
waarop de Initiate Local Production aanvraag betrekking
heeft blijft dezelfde maar de klant en het lokale
productieproces veranderen;
-
Customer Switch : le détenteur d’accès sur le HeadPoint
visé dans la demande de Initiate Local Production reste le
même que celui actif précédemment mais le client et le
processus de production locale changent ;
-
Combined Switch: de toegangshouder, de klant en het
lokale productieproces veranderen op het HeadPoint
waarop de Initiate Local Production aanvraag betrekking
heeft;
-
Combined Switch : le détenteur d’accès, le client ainsi que
le processus de production locale changent sur le
HeadPoint visé dans la demande de Initiate Local
Production;
-
Update Process: de toegangshouder en de actieve klant
op het HeadPoint blijven dezelfde maar het lokale
productieproces waarop de Initiate Local Production
aanvraag betrekking heeft verandert;
-
Update Process : le détenteur d’accès et le client actif sur
le HeadPoint restent les mêmes mais le processus de
production locale indiqué dans la demande de Initiate
Local Production change.
-
Switch Back Brussels: wanneer een klant beheerd door de
SOLR in de markt moet teruggaan bij zijn commerciële
leverancier (aangezien er geen schuld meer is tegenover
deze laatste of zijn statuut als beschermde klant is
verloren). Deze label is enkel van toepassing in Brussel.
De terugname laat toe om op het zelfde moment een
proces verandering van de toegepaste lokale productie uit
te voeren;
-
Switch Back Brussels : lorsqu'un client géré par le SOLR
doit retourner dans le marché auprès de son détenteur d’
commercial (n'a plus de dettes envers ce dernier ou a
perdu son statut de client protégé). Ce label n’est
d’application qu’à Bruxelles. La reprise permet d’effectuer
en même temps un changement du processus de
production locale d’application ;
-
Switch To SOLR : wanneer een klant het kenmerk van
beschermde klant ontvangt, wordt hij in beheer genomen
door de SOLR en wordt zijn contract tijdelijk opgeheven.
Na aanzuivering van zijn schulden of bij verlies van het
beschermd statuut, moet de klant terugkeren naar zijn
commerciële leverancier om daar verder beleverd te
worden volgens zijn bestaand contract. Deze label is
enkel van toepassing in Brussel. De terugname laat toe
om op het zelfde moment een proces verandering van de
toegepaste lokale productie uit te voeren.
-
Switch To SOLR : lorsqu’un client reçoit la caractéristique
de client protégé, il est pris en charge par le SOLR et son
contrat commercial est temporairement suspendu. Après
apurement de ses dettes ou perte du statut protégé, le
client doit retourner vers son fournisseur commercial pour
poursuivre son contrat existant cela est réalisé avec le
label Switch Back Brussels. Ce label n’est d’application
qu’à Bruxelles. La reprise permet d’effectuer en même
temps un changement du processus de production locale
d’application.
Nota: merk op dat zelfs al is dit niet het primaire doel van de
Initiate Local Production, dit ook een wijziging toelaat van de
configuratie van het Toegangspunt van de aanvraag.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken. Deze
documenten zijn weergegeven in het onderstaande
stroomschema.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Note : à noter que même si ce n’est pas là la vocation première
du module d’Initiate Local Production, celui-ci permet également
de demander un changement de la configuration du Point
d’Accès de la demande.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces documents
sont repris dans le flow ci-dessous.
21/52
UMIG 6.0 Structuring Process
ILP
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Initiate Local Production
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 11 - Initiate Local Production Documentation v1.0
5.6 Initiate Update Access (ODV/OSP)
Wanneer een toegangshouder zijn verantwoordelijkheid en die
van de klant op het Toegangspunt niet wil veranderen maar de
toegang wil veranderen om het contract te kunnen voortzetten
en daarom de realisatie van een toegangsprestatie vraagt.
Er worden 4 labels onderscheiden:
-
-
-
-
Budget Meter Installation / Activation: wanneer een nietbeschermde Waalse Residentiële klant in gebreke is van
betaling ten aanzien van zijn toegangshouder en deze
laatste bij die netgebruiker een Budgetmeter wil laten
plaatsen/activeren. Dit label is enkel van toepassing in
Wallonië;
Budget
Meter
Deactivation:
wanneer
een
toegangshouder de bij een Distributienetgebruiker (DNG
of Net User) geplaatste Budgetmeter wil desactiveren.
Dit label is enkel van toepassing in Wallonië;
Power Limiter Installation: Wanneer een Residentiële
klant in Brussel schulden heeft bij zijn toegangshouder
en deze beslist om het ter beschikking gestelde
vermogen te beperken door de plaatsing van een
vermogensbegrenzer (LIMPU) aan te vragen;
Power Limiter Removal: Wanneer een toegangshouder
heeft beslist om te leveren zonder beperking van het ter
beschikking gestelde vermogen, door de verwijdering
van de LIMPU aan te vragen. Dit type aanvraag volgt
logischerwijze op een aanvraag om plaatsing van een
LIMPU.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Lorsqu’un détenteur d’accès ne souhaite pas modifier sa
responsabilité ainsi que celle du client sur le Point d’Accès
mais souhaite modifier l’accès pour pouvoir continuer le
contrat et demande pour ce faire la réalisation d’une prestation
d’accès.
On distingue 4 labels :
-
Budget Meter Installation / Activation : lorsqu’un client
Résidentiel non-protégé wallon est en défaut de
paiement vis-à-vis de son détenteur d’accès et que ce
dernier souhaite voir poser/activer un Compteur à
Budget chez cet Utilisateur du Réseau. Ce label n’est
d’application qu’en Wallonie ;
-
Budget Meter Deactivation : lorsqu’un détenteur d’accès
souhaite désactiver le Compteur à Budget installé d’un
Utilisateur du Réseau de Distribution (URD ou Net User).
Ce label n’est d’application qu’en Wallonie ;
-
Power Limiter Installation : lorsqu’un client Résidentiel à
Bruxelles présente des dettes auprès de son détenteur
d’accès et que celui-ci décide alors de limiter la
puissance mise à disposition en demandant le
placement d’un LIMiteur de PUissance (LIMPU) ;
-
Power Limiter Removal : lorsqu’un détenteur d’accès
décide de réaliser la fourniture sans limiter la puissance
mise à sa disposition en demandant l’enlèvement du
LIMPU. Ce type de demande fait logiquement suite à
une demande de Placement d’un LIMPU.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
22/52
UMIG 6.0 Structuring Process
Figure 12 - Initiate Update Access Documentation v1.0
5.7 Initiate Stop Access
Wanneer een toegangshouder zijn verantwoordelijkheid voor
een Toegangspunt op termijn wenst te beëindigen maar eerst
een reeks stappen moeten worden gerealiseerd alvorens hij
zijn verantwoordelijkheid over het Toegangspunt verliest.
Lorsqu’un détenteur d’accès souhaiter voir sa responsabilité à
terme se terminer mais qu’une série d’étapes doivent être
réalisées avant qu’il ne perde sa responsabilité sur le Point
d’Accès.
Er worden 5 labels onderscheiden:
On distingue 5 labels :
-
Residential Drop: wanneer een klant met een
Residentieel contract in gebreke is van betaling bij zijn
toegangshouder, kan deze laatste beslissen om zich van
die klant te ontdoen. Die klant wordt dan door de sociale
leverancier overgenomen op de Dropdatum, als hij niet
tijdig een nieuw contract met een toegangshouder heeft
kunnen aangaan. Dit label is niet van toepassing in
Brussel maar uitsluitend in Wallonië, voor beschermde
residentiële klanten. Voor Vlaanderen is er geen enkele
beperking, behalve dat de Distributienetgebruiker (DNG
of Net User) residentieel moet zijn;
-
Residential Drop : lorsqu’un client avec un contrat
Résidentiel est en défaut de paiement auprès de son
détenteur d’accès, ce dernier peut décider de se départir
de ce client. Ce client sera alors repris par le fournisseur
social à la date de Drop, s’il n’a pas pu signer à temps
un nouveau contrat avec un détenteur d’accès. Ce label
n’est pas d’application à Bruxelles et est uniquement
valable en Wallonie pour les clients résidentiels
protégés. Pour la Flandre, aucune restriction si ce n’est
que l’Utilisateur du Réseau de Distribution (URD ou Net
User) doit être résidentiel ;
-
Non-Residential Drop: wanneer een klant met een Nietresidentieel contract in gebreke is van betaling bij zijn
toegangshouder, kan deze laatste beslissen om zich van
die klant te ontdoen. Uiterlijk op de Dropdatum (als de
klant niet tijdig een nieuw contract met een
toegangshouder heeft kunnen aangaan) zal het
Toegangspunt ofwel buiten dienst worden gesteld of, als
dit niet mogelijk is, onttrokken worden aan de
verantwoordelijkheid van de toegangshouder die de
Dropaanvraag heeft gedaan. In Brussel blijft na de
Dropdatum het Toegangspunt, indien dit niet buiten
dienst kon worden gesteld, bij de toegangshouder tot het
buiten dienst wordt gesteld;
-
Non-Residential Drop: lorsqu’un client avec un contrat
Non-Résidentiel est en défaut de paiement auprès de
son détenteur d’accès, ce dernier peut décider de se
départir de ce client. Au plus tard à la date de Drop (si le
client n’a pas pu signer à temps un nouveau contrat avec
un détenteur d’accès), le Point d’Accès sera soit mis
hors service soit lorsque cela n’est pas possible retiré de
la responsabilité du détenteur d’accès ayant fait la
demande de Drop. A Bruxelles, passé la date de Drop, si
le Point d’Accès n’a pas pu être mis hors service, le
Point d’Accès reste chez le détenteur d’accès jusqu’à ce
qu’il soit mis hors service ;
-
Residential
End-of-Contract:
in
bepaalde
omstandigheden kunnen de toegangshouder of de klant
beslissen om hun contract te beëindigen of het niet meer
te verlengen. Dit label is van toepassing wanneer het
contract Residentieel is en het einde van de
verantwoordelijkheid wordt geregistreerd op de End-ofContractdatum als de klant niet tijdig een nieuw contract
met een toegangshouder heeft kunnen aangaan,
behalve in Brussel waar het Toegangspunt, indien de
acties van de Distributienetbeheerder nog niet konden
uitgevoerd worden op de End-of-Contractdatum, bij de
toegangshouder blijft tot deze acties zijn uitgevoerd.
-
Residential
End-of-Contract
:
dans
certaines
circonstances, le détenteur d’accès ou le client peut
décider de mettre fin à son contrat ou de ne pas le
prolonger. Ce label est d’application lorsque le contrat
est Résidentiel et la fin de responsabilité sera
enregistrée à la date du End-of-Contract si le client n’a
pas pu signer à temps un nouveau contrat avec un
détenteur d’accès, sauf à Bruxelles où, lorsque les
actions du Gestionnaire de Réseau de Distribution n’ont
pas pu être encore réalisées à la date du End-ofContract, le Point d’Accès reste chez le détenteur
d’accès jusqu’à ces actions aient été menées.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
23/52
UMIG 6.0 Structuring Process
-
Non-Residential
End-of-Contract:
in
bepaalde
omstandigheden kunnen de toegangshouder of de klant
beslissen om hun contract te beëindigen of het niet meer
te verlengen. Dit label is van toepassing wanneer het
contract Niet-residentieel is en het einde van de
verantwoordelijkheid wordt geregistreerd op de End-ofContractdatum als de klant niet tijdig een nieuw contract
met een toegangshouder heeft kunnen aangaan,
behalve in Brussel waar het Toegangspunt, indien de
acties van de Distributienetbeheerder nog niet konden
uitgevoerd worden op de End-of-Contractdatum, bij de
toegangshouder blijft tot deze acties zijn uitgevoerd.
-
Non-Residential End-of-Contract : dans certaines
circonstances, le détenteur d’accès ou le client peut
décider de mettre fin à son contrat ou de ne pas le
prolonger. Ce label est d’application lorsque le contrat
est Non-Résidentiel et la fin de responsabilité sera
enregistrée à la date du End-of-Contract si le client n’a
pas pu signer à temps un nouveau contrat avec un
détenteur d’accès, sauf à Bruxelles où, lorsque les
actions du Gestionnaire de Réseau de Distribution n’ont
pas pu être encore réalisées à la date du End-ofContract, le Point d’Accès reste chez le détenteur
d’accès jusqu’à ces actions aient été menées.
-
Cut off Brussels: wanneer een klant met een
Residentieel contract in gebreke is van betaling bij zijn
toegangshouder, kan deze laatste beslissen om zich van
die klant te ontdoen, op voorwaarde dat een rechter
hiertoe toestemming heeft gegeven.Het bewijs van
vonnis moet verplicht worden voorgelegd bij een
aanvraag tot Cut-off door de toegangshouder. Dit label is
enkel van toepassing in Brussel.
-
Cut off Brussels : lorsqu’un client avec un contrat
Résidentiel est en défaut de paiement auprès de son
détenteur, ce dernier peut décider de se séparer de ce
client à condition qu’un juge ait donné son accord. La
preuve du jugement doit obligatoirement être fournie
dans la demande de cut-off du détenteur d’accès. Ce
label est d’application à Bruxelles uniquement.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
ISA
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Init Stop Access
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 13 - Initiate Stop Access Documentation v1.0
5.8 Initiate Leaving Customer
Deze module is een nieuwigheid in MIG6 en stelt een
toegangshouder in staat de beëindiging van de
verantwoordelijkheid van een klant en van zichzelf voor een
Toegangspunt te vragen zonder dit punt echter buiten dienst
te stellen naar aanleiding van een verhuizing van de
Distributienetgebruiker (DNG of Net User) van dit
Toegangspunt.
Ce module est une nouveauté MIG6 et permet à un détenteur
d’accès de demander d’arrêter la responsabilité d’un client
ainsi que la sienne sur un Point d’Accès donné sans toutefois
mettre hors service celui-ci suite au déménagement de
l’Utilisateur du Réseau de Distribution (URD ou Net User) de
ce Point d’Accès.
Nota : meer uitleg over deze module is opgenomen in sectie
9.1.
Note : des explications additionnelles sur ce module sont
reprises dans la section 9.1.
Er worden 2 labels onderscheiden:
On distingue 2 labels :
-
With Handover Document: wanneer de aanvraag van de
klant die zijn verhuizing bekendmaakt aan zijn
toegangshouder vergezeld is van een correct ingevuld
document van energieovername;
-
With Handover Document : lorsque la demande du client
notifiant son déménagement à son détenteur d’accès est
accompagnée d’un Document de reprise des énergies
dûment complété ;
-
Without Handover Document: wanneer de aanvraag van
de klant die zijn verhuizing bekendmaakt aan zijn
-
Without Handover Document : lorsque la demande du
client notifiant son déménagement à son détenteur
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
24/52
UMIG 6.0 Structuring Process
toegangshouder niet vergezeld is van een document van
energieovername of vergezeld is van een slecht ingevuld
document van energieovername, of wanneer een klant
verhuisd is zonder zijn toegangshouder te verwittigen of
gewoonweg omdat zijn aanvraag niet behandeld kan
worden als aanvraag "With Handover Document".
d’accès n’est pas accompagnée d’un Document de
reprise des énergies ou est accompagnée d’un
Document de reprise des énergies mal complété ou
qu’un client a déménagé sans en notifier son détenteur
d’accès ou encore lorsque la demande ne peut tout
simplement pas être traitée comme demande « With
Handover Document ».
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
ILC
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate_Request
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR – ST
- 03 Handle Request
Handle Init Leaving Cust
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
Without
Handover
document
OR
UMIG 6.0 - BR – ST
- 03 Handle Request
Handle ILC Without andover doc
UMIG 6.0 - BR – ST
- 04 Exchanged Information
With
Handover
document
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
UMIG 6.0 - BR – ST
- 03 Handle Request
Handle ILC With handover doc
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 03 Handle_Request
Handle Request Start
Figure 14 - Initiate Leaving Customer Documentation v1.0
5.9 Request Start
Deze module stelt de Meter Point Administrator of de
Distributienetbeheerder in staat om een toegangshouder te
verwittigen dat hij geacht wordt verantwoordelijk te worden
voor een Toegangspunt. Deze module is een notificatie.
Ce module permet au Meter Point Administrator ou au
Gestionnaire du Réseau de Distribution de notifier à un
détenteur d’accès qu’il est supposé devenir responsable d’un
Point d’Accès. Ce module est une notification.
Nota : meer uitleg over deze module is opgenomen in sectie
9.2.
Note : des explications additionnelles sur ce module sont
reprises dans la section 9.2.
Er worden 3 labels onderscheiden:
On distingue 3 labels :
-
Regularization form: wanneer een regularisatieformulier
wordt ondertekend tussen de Distributienetbeheerder in
zijn hoedanigheid van Metered Data Collector (MDC) en
de actieve Distributienetgebruiker (DNG of Net User) op
een Toegangspunt zonder dat er een contract is bij een
toegangshouder. De MDC informeert de Meter Point
Administrator die de toegangshouder in kennis stelt van
zijn verplichting;
-
Regularization
form :
lorsqu’un
formulaire
de
régularisation est signé entre le Gestionnaire du Réseau
de Distribution en sa qualité de Metered Data Collector
(MDC) et l’Utilisateur du Réseau de Distribution (URD ou
Net User) actif sur un Point d’Accès sans avoir un
contrat auprès d’un détenteur d’accès. Le MDC notifie
cela au Meter Point Administrator qui notifie le détenteur
d’accès de son obligation ;
-
Initiate Leaving Customer: als na een Initiate Leaving
Customer aanvraag met label "With Handover
-
Initiate Leaving Customer : suite à une demande de
Initiate Leaving Customer avec label « With Handover
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
25/52
UMIG 6.0 Structuring Process
Document", de Meter Point Administrator geen Start
Access aanvraag ontvangt binnen 10 kalenderdagen, zal
hij de toegangshouder die vermeld is in het
energieovernamedocument verwittigen dat hij geacht
wordt het Toegangspunt te zijnen laste te nemen;
-
Switch Back Brussels: wanneer een klant ten laste van
de SOLR zijn status als beschermde klant heeft verloren
of het niet meer kan bewijzen. In deze situatie initieert de
SOLR een Request Start bericht met label Switch Back
Brussels om de laatste commerciële toegangshouder die
belast was met deze klant te vragen om deze weer terug
te nemen. Dit label kan uiteraard ook gebruikt worden
wanneer een klant zijn schulden heeft betaald bij de
commerciële toegangshouder en de klant plotseling kan
overgenomen worden door deze toegangshouder.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
Request
Start
Document », si le Meter Point Administrator ne reçoit pas
de demande de Start Access endéans les 10 jours
calendrier, il notifiera le détenteur d’accès indiqué dans
le document de reprise des énergies du fait qu’il est
supposé reprendre le Point d’Accès à sa charge ;
-
Switch Back Brussels : lorsqu’un client sous la charge du
SOLR a perdu ou ne peut plus prouver son statut de
client protégé. Dans une telle situation, le SOLR initie
alors un message Request Start avec label Switch Back
Brussels pour demander au dernier détenteur d’accès
commercial ayant été en charge de ce client de le
reprendre. Ce label peut également être utilisé lorsqu’un
client a apuré ses dettes auprès du détenteur d’accès
commercial et que ce client peut du coup être repris par
ce détenteur d’accès.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Start Access
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 15 - Request Start Documentation v1.0
5.10 Update Customer Metering Configuration
Wanneer een klant de configuratie van zijn Toegangspunt wil
wijzigen, kan hij dit vragen aan zijn toegangshouder, die een
module Update Customer Metering Configuration zal
verzenden. Deze module kan geen interventie meebrengen op
het terrein vanwege de Meter Operator en alle configuraties
die gevraagd kunnen worden zullen door de Meter
Administrator worden meegedeeld aan de Metered Point
Administrator, die ze aan de toegangshouder ter beschikking
zal stellen via de Preswitching-tool. Naast de eigenlijke
configuratiewijzigingen laat de module Update Customer
Metering Configuration ook toe de status "Leegstand" van een
Toegangspunt te veranderen.
Lorsqu’un client souhaite modifier la configuration de son Point
d’Accès, il peut le demander à son détenteur d’accès qui
enverra un module Update Customer Metering Configuration.
Ce module ne peut pas entraîner d’intervention sur le terrain
de la part du Meter Operator et toutes les configurations qu’il
sera possible de demander seront communiquées par le Meter
Administrator au Meter Point Administrator qui les mettre à
disposition du détenteur d’accès via l’outil du Preswitching. A
côté des changements de configuration proprement dits, le
module Update Customer Metering Configuration permettra
également de modifier le statut « Maison Vide » d’un Point
d’Accès.
Er is maar
Configuration.
Metering
Il n’y a qu’un seul label: Update Customer Metering
Configuration.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
één
label:
Update
Customer
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
26/52
UMIG 6.0 Structuring Process
UCMC
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Upd Cust Metering Config
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 16 - Update Customer Metering Configuration Documentation v1.0
5.11 Prepayment
Wanneer de toegangshouder die verantwoordelijk is voor een
Toegangspunt
met
geactiveerde
functionaliteit
van
voorafbetaling een marktbericht wenst te lanceren in verband
met deze functionaliteit (notificatie van resterend krediet,
onderbreking of herstelling van de levering, notificatie van
kritisch niveau van resterend krediet).
Nota : de voorafbetaling die in MIG6 wordt vermeld heeft
betrekking op de voorafbetaling in het kader van de ODV en
niet in het kader van de commerciële voorafbetaling. Dit kan
eventueel worden uitgewerkt in een latere versie van deze
MIG.
Er worden 5 labels onderscheiden:
Lorsque le détenteur d’accès en charge d’un Point d’Accès
avec fonctionnalité du prépaiement activée souhaite initier un
message de marché en lien avec cette fonctionnalité
(notification de crédit restant, interruption ou rétablissement de
la fourniture, notification d’arrivée à un crédit restant critique).
Note : le prépaiement dont il est fait mention dans le MIG6
concerne le prépaiement dans le cadre des OSP et non pas le
prépaiement commercial. Celui-ci pourra éventuellement être
développé dans une version ultérieure de ce MIG.
On distingue 5 labels :
-
Preventive Alarm: wanneer de toegangshouder zich
realiseert dat het resterende krediet van een
Toegangspunt met voorafbetaling nagenoeg een
bepaalde drempel bereikt die samen met de regulatoren
wordt vastgelegd;
-
Preventive Alarm : lorsque le détenteur d’accès se
rend compte que le crédit restant d’un Point d’Accès
avec prépaiement s’approche d’un certain seuil à
définir avec les régulateurs;
-
Rescue Credit Alarm: wanneer de toegangshouder zich
realiseert dat het resterende krediet van een
Toegangspunt met voorafbetaling een drempel bereikt
die samen met de regulatoren wordt vastgelegd;
-
Rescue Credit Alarm : lorsque le détenteur d’accès
se rend compte que le crédit restant d’un Point
d’Accès avec prépaiement atteint un seuil à définir
avec les régulateurs ;
-
Prepayment Interruption: wanneer de toegangshouder de
levering van energie wil onderbreken of beperken voor
een Toegangspunt met geactiveerde functionaliteit van
voorafbetaling;
-
Prepayment Interruption : lorsque le détenteur
d’accès souhaite interrompre la fourniture d’énergie
ou la limiter pour un Point d’Accès avec fonctionnalité
du prépaiement activée;
-
Prepayment
Re-establishment:
wanneer
de
toegangshouder
voor
een
Toegangspunt
met
geactiveerde functionaliteit van voorafbetaling de levering
van energie wil herstellen of de opgelegde leveringslimiet
wil opheffen als gevolg van herlading van het krediet van
de klant;
-
Prepayment Re-establishment : lorsque le détenteur
d’accès souhaite rétablir la fourniture d’énergie ou
enlever la limite posée dessus pour un Point d’Accès
avec fonctionnalité de prépaiement suite à une
recharge de crédit du client ;
-
Balance Notification : lorsque la fonctionnalité du
prépaiement est active, le détenteur d’accès en
charge
du
Point
d’Accès
communique
quotidiennement le crédit restant ainsi que les kWh
restants calculés au moyen des consommations qu’il
aura reçu au préalable.
-
Balance Notification: wanneer de functionaliteit van
voorafbetaling actief is, dan deelt de toegangshouder die
verantwoordelijk is voor het Toegangspunt dagelijks het
resterende krediet evenals de resterende kWh mee die
berekend worden aan de hand van het verbruik dat hij
vooraf heeft ontvangen.
In de MIG6-documentatie wordt het verloop van het proces
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
La documentation du MIG6 décompose le déroulement du
27/52
UMIG 6.0 Structuring Process
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
UMIG 6.0 - BR – ST
- 04 Exchanged Information
Ces
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 03 Prepayment
Prepayment
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
processus en différents documents et chapitres.
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 17 - Prepayment Documentation v1.0
5.12 Update Technical Master Data
Wanneer de Meter Administrator de Technical Master Data
verbonden aan een Toegangspunt bijwerkt, gebruikt hij deze
module om dit ter kennis te brengen van de Meter Point
Administrator, die de Technical Master Data overmaakt aan de
actieve toegangshouder op het betrokken Toegangspunt.
Lorsque que le Meter Administrator réalise une mise à jour
des Master Data Techniques liées à un Point d’Accès, il utilise
ce module pour le notifier au Meter Point Administrator qui
transmet les Master Data Techniques au détenteur d’accès
actif sur le Point d’Accès concerné.
De verzending van de Technical Master Data die zich
voordoet in het kader van een module (bv. Start Access) zal
gebeuren in het kader van die module zonder tussenkomst
van de module Update Technical Master Data die op
onafhankelijke wijze door de Meter Administrator wordt
geactiveerd.
En effet, l’envoi des Master Data techniques apparaissant
dans le cadre d’un module (p.ex. Start Access) se fera dans le
cadre de ce module et ne fera pas intervenir le module Update
Technical Master Data qui est déclenché de façon
indépendante par le Meter Administrator.
Er zijn 6 labels:
Il y a 6 labels :
-
-
-
-
-
B01 Initial Master Data: wanneer de Meter Administrator
de Technical Master Data bijwerkt, wat een overgang
met zich meebrengt van de verantwoordelijkheid van
een toegangshouder van een oud Toegangspunt naar
het aangeduide Toegangspunt in de Technical Master
Data;
BA1 update metering point master data - index sent:
wanneer de Meter Administrator de Technical Master
Data verbonden aan een Toegangspunt en de daaraan
gekoppelde meter(s) bijwerkt en wanneer als gevolg van
deze update een metering-bericht moet worden
verzonden;
BA2 update meter master data - no index sent: wanneer
de Meter Administrator de Technical Master Data
betreffende de meter(s) gekoppeld aan een bepaald
Toegangspunt moet bijwerken en wanneer als gevolg
van deze update geen enkel metering-bericht moet
worden verzonden;
B03 update metering point master data - no index sent:
wanneer de Meter Administrator de Technical Master
Data verbonden aan een Toegangspunt en de daaraan
gekoppelde meter(s) bijwerkt en wanneer als gevolg van
deze update geen enkel metering-bericht moet worden
verzonden;
B04 update meter master data - index sent: wanneer de
Meter Administrator de Technical Master Data
betreffende de meter(s) gekoppeld aan een bepaald
Toegangspunt moet bijwerken en wanneer als gevolg
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
-
-
-
-
-
B01 Initial Master Data : lorsque le Meter Administrator
réalise une mise à jour des Master Data techniques
entraînant un basculement de responsabilité d’un
détenteur d’accès d’un ancien Point d’Accès vers le
Point d’Accès indiqué dans les Master Data techniques ;
BA1update metering point master data - index sent :
lorsque le Meter Administrator réalise une mise à jour
des Master Data techniques concernant le Point d’Accès
et le(s) compteur(s) associé(s) et que faisant suite à
cette mise à jour, un message metering devra être
envoyé ;
BA2 update meter master data - no index sent : lorsque
le Meter Administrator réalise une mise à jour des
Master Data techniques concernant le(s) compteur(s)
associé(s) à un Point d’Accès donné et que faisant suite
à cette mise à jour, aucun message metering ne doit être
envoyé ;
B03 update metering point master data - no index sent :
lorsque le Meter Administrator réalise une mise à jour
des Master Data techniques concernant le Pointd’Accès
et le(s) compteur(s) associé(s) et que faisant suite à
cette mise à jour, aucun message metering ne doit être
envoyé ;
B04 update meter master data - index sent : lorsque le
Meter Administrator réalise une mise à jour des Master
Data techniques concernant le(s) compteur(s) associé(s)
à un Point d’Accès donné et que faisant suite à cette
mise à jour, un message metering devra être envoyé.
28/52
UMIG 6.0 Structuring Process
-
van deze update een metering-bericht moet worden
verzonden;
BA9 move out: wanneer de Meter Administrator de
Technical Master Data bijwerkt ten gevolge van een
buitendienststelling van een Toegangspunt.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
UTMD
-
BA9 move out : lorsque le Meter Administrator réalise
une mise à jour des Master Data techniques suite à une
mise hors service d’un Point d’Accès.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 03 Handle Request
Handle Upd Technical Master Data
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 18 - Update Technical Master Data Documentation v1.0
5.13 Update Business Master Data
Wanneer de toegangshouder die instaat voor een
Toegangspunt de Business Master Data voor een
Toegangspunt bijwerkt, gebruikt hij deze module om dit te
kennis te brengen van de Meter Point Administrator.
Lorsque le détenteur d’accès en charge d’un Point d’Accès
réalise une mise à jour des Business Master Data pour un
Point d’Accès, il utilise ce module pour le notifier au Meter
Point Administrator.
Er is maar één label: Update Business Master Data.
Il n’y a qu’un seul label : Update Business Master Data.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UBMD
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 19 - Update Business Master Data Documentation v1.0
5.14 Update Balance Responsible Party
Wanneer de Balance Responsible Party / Shipper moet
worden gewijzigd voor een of voor een reeks
Toegangspunten, gebruikt de toegangshouder belast met het
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Lorsque le Balance Responsible Party / Shipper doit être mis à
jour pour un ou un set de Point d’Accès, le détenteur d’accès
en charge du ou des Points d’Accès utilise ce module.
29/52
UMIG 6.0 Structuring Process
of de Toegangspunten deze module.
Il n’y a qu’un seul label : Update Balance Responsible Party.
Er is maar één label: Update Balance Responsible Party.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
UBRP
UMIG 6.0 - BR - ST
- 03 Preswitching
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 20 - Update Balance Responsible Party Documentation v1.0
5.15 Request Rectification
Wanneer een marktpartij een geaccepteerde en effectieve
marktaanvraag wenst te rectificeren, wanneer een marktpartij
een index wenst te rectificeren, of wanneer een marktpartij
een marktaanvraag die gelanceerd werd door een andere
marktpartij en die nog niet effectief is, wenst te annuleren, dan
wordt hiervoor de module Request Rectification gebruikt.
Lorsqu’une partie de marché souhaite rectifier une demande
de marché acceptée et effective, lorsqu’une partie de marché
souhaite rectifier un index ou bien encore lorsqu’une partie de
marché souhaite annuler une demande de marché initiée par
une autre partie de marché et pas encore effective, le module
Request Rectification sera le module à utiliser.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
Rectification
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR - ST
- 03 Rectification
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR – ME
- 02 Measure Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
UMIG 6.0 - BR – ST
- 04 Rectification Catalogue
Figure 21 - Rectification Documentation v1.0
5.16 Cancel Module
Wanneer de initiator van een geaccepteerde marktaanvraag
deze wenst te annuleren, en wanneer deze nog niet effectief
is, of wanneer de Meter Point Administrator of een sociale
leverancier/SOLR voor zeer specifieke gevallen een nog niet
effectieve marktaanvraag wenst te annuleren, dan wordt
hiervoor de module Cancel Module gebruikt. Hierdoor kan een
door de Meter Point Administrator geregistreerde maar nog
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Lorsque l’initiateur d’une demande de marché acceptée
souhaite annuler cette dernière et que celle-ci n’est pas
encore effective ou lorsque le Meter Point Administrator ou un
fournisseur social/SOLR pour des cas bien spécifiques
souhaitent annuler une demande de marché encore non
effective, le module Cancel Module sera celui à utiliser. Il
permet l’annulation d’une demande de marché enregistrée par
30/52
UMIG 6.0 Structuring Process
niet
effectieve
marktaanvraag
worden
geannuleerd.
Opgemerkt wordt dat alle nog niet effectieve marktaanvragen
kunnen geannuleerd worden via de module Cancel Module.
le Meter Point Administrator mais pas encore effective. A noter
que toutes les demandes de marché encore non effective
peuvent être annulées via le module Cancel Module.
Er is maar één label: Cancel Module.
Il n’y a qu’un seul label : Cancel Module.
In de MIG6-documentatie wordt het verloop van het proces
opgesplitst in verschillende documenten en hoofdstukken.
Deze documenten zijn weergegeven in het onderstaande
stroomschema.
La documentation du MIG6 décompose le déroulement du
processus en différents documents et chapitres. Ces
documents sont repris dans le flow ci-dessous.
Cancel
Module
UMIG 6.0 - BR - ST
- 03 Preswitching
UMIG 6.0 - BR - ST
- 03 Initiate Request
UMIG 6.0 - BR - ST
- 04 Ex-ante Tests
UMIG 6.0 - BR – ST
- 04 Exchanged Information
UMIG 6.0 - BR - ST
- 03 Handle Request
Notify Impacted Party
UMIG 6.0 - BR - ST
- 04 Timings
UMIG 6.0 - BR - ST
- 01 Introduction
UMIG 6.0 - BR - ST
- 02 Structuring Process
UMIG 6.0 - BR - ST
- 04 Ex-post Monitoring
Figure 22 - Cancel Module Documentation V1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
31/52
UMIG 6.0 Structuring Process
6 Mapping MIG4.1 vs MIG6
Oorsprong
Source
Situatie / Situation
MIG 6 Modules/ Modules MIG6
MIG4
Supplier Switch
Start Access + label Supplier Switch
MIG4
Move In
Move In
MIG4
Customer Switch
Start Access + label Customer Switch
MIG4
Combined Switch MMR & AMR
Start Access + label Combined Switch
MIG4
Combined Switch YMR
Start Access + label Combined Switch
MIG4
Residential Drop
Initiate Stop Access + label Residential Drop
MIG4
Non-Residential Drop
Initiate Stop Access + label Non-Residential Drop
MIG4
Supplier Switch after Drop
Start Access + label Supplier Switch
Move Out

MIG4
Move Out

! Wijziging !
Op termijn wordt de aanvraag van de klant niet langer
rechtstreeks door de DNB geïnitieerd.
DNB kan afsluiten o.w.v. technische redenen: Update
Technical Master Data
! Changement !
A terme, les demandes de Move Out client ne seront
plus initiées directement par le GRD.
Un GRD pourra mettre hors service (p.ex. pour raisons
de sécurité) via le module Update Technical Master
Data.
Nieuw !
Move Out via Supplier
Move Out
MIG4
Residential End-of-Contract
Initiate Stop Access + label Residential End-of-Contract
MIG4
Non-Residential End-of-Contract
Initiate Stop Access + label Non Residential End-of-Contract
MIG4
Supplier Switch after EoC
Start Access + label Supplier Switch
MIG4
Sleeping Move In
Move In
Sleeping Move Out
Move Out
MIG4
Move Out Zonder Afspraak (MOZA)
Initiate Leaving Customer + label Without Handover
Document
Nieuw !
Verhuizing: indien een vertrekkende klant zijn
verhuizing meldt
Nouveau !
Nieuw !
Nouveau !
Initiate Leaving Customer + label With Handover Document
or Without Handover Document
Nouveau !
Déménagement : lorsqu’un client notifie son
déménagement
MIG4
MOZA Brussels
Initiate Leaving Customer + label Without Handover
Document
MIG4
Supplier Switch to SoLR
Start Access + label Switch to SOLR
MIG4
Supplier Switch back to commercial supplier
Start Access + label Switch Back Brussels
MIG4
Cancel supplier switch to SoLR
Cancel
MIG4
Cancel switch back to commercial supplier
Cancel
MIG4
Installation power limiter
Initiate Update Access + label Power Limiter Installation
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
32/52
UMIG 6.0 Structuring Process
Oorsprong
Source
Situatie / Situation
MIG 6 Modules/ Modules MIG6
MIG4
Removal Power Limiter
Initiate Update Access + label Power Limiter Removal
MIG4
Pose Compteur à budget
Initiate Update Access + Budget Meter Installation /
Activation
Desactivation CàB
Initiate Update Access + label Budget Meter Desactivation
MIG4
Mystery Switch before ED
Cancel or Request Rectification
MIG4
Mystery Switch after ED
Request Rectification
Nieuw !
Nouveau !
Nieuw !
Prepayment
Nouveau !
MIG4
Master Data Party Change
Update Business Master Data
MIG4
Master Data Update by DGO
Update Technical Master Data
MIG4
Wissel van EV_VNG
Update Balance Responsible Party
MIG4
Snapshot Master Data
Preswitching
MIG4
MD Rectification
Request Rectification
MIG4
Rectification Structuring
Request Rectification
MIG4
Rectification Metering
Request Rectification
MIG4
Cancel Leverancierswissel
Cancel
MIG4
Cancel Move In
Cancel
MIG4
Cancel Customer Switch
Cancel
MIG4
Cancel Combined Switch
Cancel
MIG4
Annulation Drop
Cancel
MIG4
Cancellation End of Contract
Cancel
MIG4
Cancel supplier switch by social supplier
Cancel
MIG4
Cancel drop by social supplier
Cancel
MIG4
Annulation pose CàB
Cancel
Nieuw !
Update Customer Metering Configuration
Nouveau !
Nieuw !
Nouveau !
E44 Secured / Unsollicited Cancel
Flag « Unlock » vlag + Request Rectification
E44 REG / Procédure de régularisation
Request Start + label : Regularization Form
Nieuw !
Nouveau !
Nieuw !
Nouveau !
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Cancel ook van toepassing voor elke nog niet effectieve
module
Cancel aussi d’application pour tout module encore non
effectif
33/52
UMIG 6.0 Structuring Process
7 Business Requirements Structure
7.1 Scope
De verschillende modules die hierboven in het document
geintroduceerd zijn, worden gemodelleerd in de Business
Requirments die de UML2.0-methodologie exploiteren.
Les différents modules introduits ci-avant dans le document
sont modélisés dans des Business Requirements qui
exploitent la méthodologie UML2.0.
De onderstaande afbeelding geeft de gehele Structuringscope weer volgens de UML2.0-methodologie.
L’image ci-dessous reprend l’ensemble du scope Structuring
illustré suivant la méthodologie UML2.0.
Figure 23 - Use Case Structure v1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
34/52
UMIG 6.0 Structuring Process
7.2 Concepten en begrippen – Concepts et définitions
De Structuring aanvragen draaien voornamelijk om twee
hoofdprocessen:
-
Initiate Request;
Handle Request.
Les demandes Structuring se déclinent pour la plupart autour
de deux processus principaux :
-
Initiate Request ;
Handle Request.
Figure 24 - Activity Main Structure v1.0
Deze processen maken de volgende acties mogelijk:
Ces processus permettent de réaliser les actions suivantes :
-
Initiate Request: proces waarbij een aanvraag wordt
opgestart door een marktpartij en een eerste
behandeling ondergaat (referentiedocument [3]);
-
Initiate Request : processus dans lequel une
demande est initiée par une partie de marché et subit
un premier traitement (document de référence [3]);
-
Handle Request: proces waarbij de aanvraag een
reeks subprocessen op gang brengt die specifiek zijn
voor het ingezette type aanvraag (referentiedocument
[4]); er zijn 2 subprocessen:
-
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 (document
de référence [4]), ces sous-processus sont au
nombre de 2 :
1.
2.
Notifiy Impacted Party: wanneer een of
meerdere partijen invloed ondervinden van de
behandeling van een aanvraag, worden zij
daarvan verwittigd (dat wil zeggen dat zij de
gevolgen ondergaan van de behandeling van de
aanvraag zonder de mogelijkheid te hebben om
deze te beïnvloeden);
Handle Request Activities: behandeling van
restactiviteiten verbonden aan het type aanvraag
in behandeling.
1.
Notifiy Impacted Party : si une ou plusieurs
parties sont impactées par le traitement d’une
demande, elles en sont averties (c’est-à-dire
qu’elles subissent les conséquences du
traitement de la demande sans avoir la
possiblité d’interférer sur celui-ci);
2.
Handle Request Activities : traitement des
activités résiduelles liées au type de la demande
en cours de traitement.
De onderstaande tabel illustreert de inschakeling van
processen en subprocessen al naargelang de verschillende
types aanvraag.
Le tableau ci-dessous illustre le déclenchement des processus
et sous-processus en fonction des différents types de
demande.
Opgemerkt wordt dat de modules Request Rectification en
Prepayment opgenomen zijn in specifieke documenten en dat
deze ook het voorwerp uitmaken van specifieke processen.
A noter que les modules Request Rectification et Prepayment
sont repris dans des documents spécifiques et sont couverts
par des processus spécifiques également.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
35/52
UMIG 6.0 Structuring Process
INITIATE
REQUEST
HANDLE REQUEST
Notify Impacted Handle Request
Party
Activities
Start Access
x
x
x
Initiate Leaving Customer
x
x
x
Initiate Stop Access
x
x
x
Initiate Update Access
x
x
x
Move In
x
Move Out
x
x
x
Initiate Local Production
x
x
x
Request Start
x
x
Update Customer Metering Configuration
x
x
Update Business Master Data
x
Update Balance Responsible Party
x
Update Technical Master Data
x
Request Rectification
x
Cancel
x
Prepayment
x
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
x
x
x
x
x
x
36/52
UMIG 6.0 Structuring Process
8 User stories
8.1 Introductie – Introduction
In dit hoofdstuk komen verschillende situaties aan bod die in
de markt kunnen voorkomen.
Dans ce chapitre, différentes situations pouvant apparaître sur
le marché sont reprises.
Voor elke situatie wordt vermeld welke passende actie een
end user dient te nemen.
Pour chaque situation est indiquée l’action adéquate à prendre
de la part d’un end user.
De lijst van situaties is niet uitputtend en is vooral bedoeld om
de lezer te tonen hoe in elk van de gevallen op te treden.
La liste des situations reprises n’est pas exhaustive et a
comme objectif premier de montrer au lecteur comment agir
en fonction des cas rencontrés.
8.2 Registratie van contract – Enregistrement de contrat
Een nieuwe klant contacteert mij en wil een contract
registreren. Eerste stap voor de registratie van ieder contract
is het raadplegen van de Preswitching. Zo kan ik me op de
hoogte stellen van de situatie van het punt (fysieke status,
service catalogus met configuraties en beschikbare services,
…).
Un nouveau client me contacte et souhaite enregistrer un
contrat. Le point de départ à l’enregistrement de tout contrat
est la consultation du Preswitching. Grâce à cette
consultation, je suis en mesure de connaître la situation du
point (statut physique, service catalogue avec les
configurations et services disponibles, …).
Ongeacht de aanvraag die ik daarna zal moeten opstarten, is
het essentieel dat de klant mij de gewenste service en
configuratie meedeelt. Bijvoorbeeld compensatieservice met
meetregime 3, jaarlijkse opnamefrequentie voor facturatie en
maandelijkse opnamefrequentie voor informatie.
Peu importe la demande que je devrai initier par la suite, il est
primordial que le client me communique le service et la
configuration qu’il souhaite y appliquer. Par exemple, service
de compensation avec un régime de comptage 3, une
fréquence de relève pour facturation annuelle et une
fréquence de relève pour information mensuelle.
Naar gelang zijn vraag en de situatie van het punt,
onderscheidt men verschillende gevallen:



Zijn installatie is nog niet actief. In dat geval is de te
lanceren aanvraag een Move In. De startdatum van het
contract zal overeenstemmen met de datum van
indienststelling van de installatie. Opgemerkt wordt dat in
de aanvraag een datum vermeld moet zijn, die de door
de klant gewenste datum van indienststelling moet
weerspiegelen. Het is wel aan de klant om contact op te
nemen met zijn DNB om zijn installatie in dienst te
stellen.
Zijn installatie is actief maar ik ben nog niet actief als
toegangshouder op het betrokken toegangspunt:
-
als de klant net op dit toegangspunt is ingetrokken, is
de te lanceren aanvraag een Start Access met label
Combined Switch;
-
als de klant reeds actief was op dit toegangspunt
maar met een andere toegangshouder, dan is de te
lanceren aanvraag een Start Access met label
Supplier Switch.
Zijn installatie is actief en ik ben reeds actief als
toegangshouder op het betrokken toegangspunt:
En fonction de sa demande et de la situation du point, on
distingue les différents cas :

Son installation n’est pas encore active. Dans pareil cas,
la demande à initier est une demande de Move In. La
date de démarrage du contrat correspondra à la date de
mise en service de l’installation. A noter qu’une date doit
être indiquée dans la demande et que celle-ci doit
refléter la date de mise en service souhaitée par le client.
Il appartient néanmoins à ce dernier de prendre contact
avec son GRD afin de mettre en service son installation.

Son installation est active. Si je ne suis pas encore actif
comme détenteur d’accès :
-
sur ce point d’accès et que le client vient
d’emménager sur ce point d’accès, alors la demande
à initier est un Start Access avec label Combined
Switch ;
sur ce point d’accès et que le client était déjà actif
sur ce point d’accès mais avec un autre détenteur
d’accès, alors la demande à initier est un Start
Access avec label Supplier Switch.
Son installation est active. Si je suis déjà actif comme
détenteur d’accès :
-

-
de te lanceren aanvraag is een Start Access met
label Customer Switch;
-
sur ce point d’accès alors la demande à initier est un
Start Access avec label Customer Switch ;
-
maar de klant laat me weten dat hij van lokale
productieservice wil veranderen, dan is de te
lanceren aanvraag een Initiate Local Production
met label Customer Switch.
-
sur l’installation du client mais que celui-ci me dit
vouloir changer de service de production locale,
alors la demande à initier est un Initiate Local
Production avec label Customer Switch.
Het is ook mogelijk dat de klant mij niet rechtstreeks
contacteert maar dat ik een Request Start aanvraag ontvang
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Il se peut également que le client ne me contacte pas
directement et que je reçoive une demande de Request Start
37/52
UMIG 6.0 Structuring Process
met opgave van de gegevens van een klant die mij heeft
aangeduid als gewenste toegangshouder. Als antwoord op
die aanvraag kan ik een Start Access of een Initiate Local
Production aanvraag lanceren met het passende label om
het contract te registreren.
m’indiquant les coordonnées d’un client m’ayant indiqué
comme détenteur d’accès souhaité. Faisant suite à cette
demande, je peux initier une demande de Start Access ou
d’Initiate Local Production avec le label adéquat afin
d’enregistrer le contrat.
8.3 Verhuizing van een klant – Déménagement d’un client
Een klant uit mijn portefeuille is verhuisd.
Un client faisant partie de mon portefeuille a déménagé.



De klant heeft mij in kennis gesteld van zijn verhuizing:
Le client m’a notifié son déménagement :
-
hij laat me weten dat hij zijn installatie buiten dienst
wil stellen. De te lanceren aanvraag is dan een Move
Out. Deze aanvraag zal maar gerealiseerd worden
als de klant contact opneemt met zijn DNB en de
effectieve datum van buitendienststelling dus
verbonden is aan die contactname en aan de tussen
de klant en zijn DNB gemaakte afspraak;
-
il me signale souhaiter mettre hors service son
installation. La demande à initier est alors un Move
Out. Cette demande ne sera réalisée que si le client
prend contact avec son GRD et la date effective de
mise hors service est dès lors liée à cette prise de
contact et au rendez-vous établi entre le client et son
GRD ;
-
hij bezorgt me een naar behoren ingevuld
energieovernameformulier, dit wil zeggen waarin de
gegevens zijn ingevuld die als verplicht zijn
aangemerkt voor een aanvraag omInitiate Leaving
Customer met label With Handover Document. Zo
niet, wordt het label Without Handover Document
gebruikt;
-
il me fournit un Document de reprise des énergies
correctement complété, c’est-à-dire que les données
qu’il contient sont celles indiquées comme
obligatoires pour pouvoir initier une demande
d’Initiate Leaving Customer avec label With
Handover Document. Dans le cas contraire, le label
Without Handover Document sera utilisé ;
-
hij laat me weten dat hij nog geen overnemer heeft
gevonden. In dat geval bestaat de oplossing erin, als
de klant niet wil dat zijn installatie buiten dienst wordt
gesteld, om een aanvraag Update Customer
Metering Configuration te lanceren met activering
van de flag Leegstand. Op die manier zal de
installatie niet buiten dienst worden gesteld, blijft de
klant geregistreerd als actief op het toegangspunt
maar zal zijn verbruik geschat worden zoals voor een
onbewoond huis.
-
il me signale qu’il n’a pas encore trouvé de repreneur.
Dans pareil cas, si le client ne souhaite pas voir mise
hors service son installation, la solution consistera à
lancer une demande Update Customer Metering
Configuration en activant le flag Maison vide. Grâce
à cela, l’installation ne sera pas mise hors service, le
client continuera à être enregistré comme actif sur le
point d’accès mais ses consommations seront
estimées comme étant celles d’une maison inhabitée.
De klant heeft mij niet in kennis gesteld van zijn
verhuizing, de te lanceren aanvraag is een Initiate
Leaving Customer.

Le client ne m’a pas notifié son déménagement, la
demande à initier est un Initiate Leaving Customer.
8.4 Andere – Autres

Een klant uit mijn portefeuille laat me weten dat de
gegevens van de contactpersoon voor de meetgegevens
zijn veranderd. Opdat de marktspelers hun activiteiten
correct zouden kunnen uitvoeren, lanceer ik een
aanvraag om Update Business Master Data om die
gegevens bij te werken. De gegevens worden bijgewerkt
in het toegangsregister en timesliced, wat betekent dat
de gevraagde bijwerking maar effectief zal zijn vanaf de
aanvraagdatum.

Un client faisant partie de mon portefeuille me
communique que les coordonnées de la personne de
contact pour les des données de comptage ont
changées. Pour que les acteurs de marché puissent
exercer correctement leurs activités, j’initie une demande
d’Update Business Master Data qui mettra à jour ces
informations. Ces informations sont mises à jour dans le
registre d’accès et timeslicées ce qui signifie que la mise
à jour demandée sera effective uniquement à partir de la
date de la demande.

Een klant uit mijn portefeuille contacteert me en laat me
weten dat hij vaker informatie over zijn verbruik wenst te
krijgen. Door raadpleging van de Preswitching voor zijn
toegangspunt, krijg ik toegang tot de service catalogus
voor dat punt en kan ik hem de beschikbare
opnamefrequenties ter informatie voorstellen. Volgens
zijn wensen, lancering van een aanvraag om Update
Customer Metering Configuration om de gewijzigde
configuratie van zijn toegangspunt toe te passen zoals
gevraagd,
bijvoorbeeld
preciserend
dat
de
opnamefrequentie voor informatie maandelijks moet zijn,

Un client faisant partie de mon portefeuille me contacte
et m’indique souhaiter recevoir des informations sur sa
consommation plus fréquemment. Via la consultation du
Preswitching pour son point d’accès, j’accède au service
catalogue de son point et je peux lui proposer les
fréquences de relève pour information disponibles.
Suivant sa volonté, initier une demande d’Update
Customer Metering Configuration afin de faire
appliquer le changement de configuration de son point
d’accès tel que demandé en y précisant par exemple que
la fréquence de relève pour information doit être
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
38/52
UMIG 6.0 Structuring Process
mensuelle plutôt
auparavant.
eerder dan jaarlijks zoals vroeger geregistreerd.
qu’annuelle
comme
enregistré

Een klant contacteert mij en zegt dat de voor zijn
facturatie gebruikte index niet klopt. Indien bij nazicht
blijkt dat de index inderdaad fout is, lanceer ik een
aanvraag om Request Rectification met de passende
rectificatiecode.

Un client me contacte et me signale que l’index utilisé
pour sa facturation n’est pas correct. Après vérification
avec lui, s’il apparaît qu’il y a de fait une erreur sur
l’index, j’initie une demande de Request Rectification
avec le code de rectification adéquat.

Na een Start Access aanvraag met effectieve datum in
de toekomst te hebben opgestart, stel ik vast dat ik me
van toegangspunt heb vergist. Als de effectieve datum
nog niet is bereikt, lanceer ik een aanvraag Cancel, die
als gevolg zal hebben dat mijn foutieve Start Access
aanvraag wordt geannuleerd.

Après avoir initié une demande de Start Access avec
une date effective dans le futur, je m’aperçois m’être
trompé de point d’accès. Si la date effective n’est pas
encore atteinte, j’initie une demande Cancel qui aura
pour effet d’annuler ma demande de Start Access
fautive.

Een klant met een lokale productie-installatie contacteert
me omdat hij een contract wil sluiten voor compensatie.
Om dit te kunnen doen, is het gebruik van de
preswitching functionaliteit nodig. Aan de hand van het
identificatienummer van zijn installatie (headpoint), neem
ik toegang tot de Preswitching LIGHT en ga na welke
services voor die installatie beschikbaar zijn. Als de
compensatieservice beschikbaar is, controleer ik of ook
de door de klant gevraagde configuratie beschikbaar is
en zo ja, kan ik een aanvraag om Initiate Local
Production lanceren. Ervan uitgaande dat de klant
reeds deel uitmaakt van mijn portefeuille en reeds actief
was op deze installatie, is het te gebruiken label Update
Process.

Un client disposant d’une installation de production
locale me contacte et souhaite signer un contrat pour de
la compensation. Pour pouvoir réaliser cela, un passage
par la fonctionnalité du preswitching est nécessaire. Au
moyen du numéro d’identification de son installation
(headpoint), j’accède au Preswitching LIGHT et vérifie
l’ensemble des services disponibles sur cette installation.
Si le service de compensation est disponible, je vérifie
que la configuration demandée par le client l’est
également et le cas échéant peut alors initier une
demande d’Initiate Local Production. A supposer que
le client fait déjà partie de mon portefeuille et était déjà
actif sur cette installation, le label a utilisé sera Update
Process.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
39/52
UMIG 6.0 Structuring Process
9 Bijlagen – Annexes
9.1 Verhuizingsproces – Processus de déménagement
9.1.1
Context – Contexte
Het verhuisproces zou aanleiding kunnen geven tot
ongewenste situaties waarbij een toegangspunt fysiek actief
en de contractuele status inactief is, met andere woorden
situaties waarbij de vertrekkende klant vraagt om zijn rekening
af te sluiten terwijl de overnemende klant pas veel later
opduikt.
De in deze MIG voorgestelde oplossing laat het volgende toe:

De overname verzekeren door middel van een officieel en
federaal document van overdracht/overname van energie,
het zogenaamde "energieovernamedocument";

Verplichten dat de regularisatie automatisch gebeurt op
basis van de datum en de meterstanden van de
vertrekkende klant (met mogelijkheid van betwisting via
rectificatie);

De
aanvragen
zonder
energieovernamedocument
beperken.
Dit voorstel geldt alleen voor de toegangspunten die
verbonden zijn aan klassieke meters YMR of aan slimme
meters.
In het verhuisproces worden verschillende situaties
onderscheiden. Deze worden weergegeven in het schema
hieronder (de modules waarvan sprake worden beschreven in
hoofdstuk 5).
Le processus de déménagement pourrait être à l’origine de
situations indésirables où un point d’accès serait actif
physiquement et le statut contractuel inactif, en d’autres morts,
de situations où le client sortant demanderait la clôture de son
compte et où le client repreneur ne se manifesterait que bien
après.
La solution proposée dans ce MIG permet de :

Garantir la reprise par l’intermédiaire d’un document
officiel et fédéral de remise/reprise des énergies, appelé
PV de reprise des énergies.

Obliger que la régularisation de fasse automatiquement
sur base de la date et des index du sortant (avec
possibilité de contester via rectification)

Limiter les demandes sans Document de reprise des
énergies
Cette proposition n’est d’application que pour les points
d’accès liés à des compteurs classiques YMR ou à des
compteurs intelligents.
Dans le processus de déménagement on distingue différentes
situations. Celles-ci sont reprises dans le schéma ci-dessous
(les modules dont il est question sont décrits dans le chapitre
5).
Move
New customer
notifies a move
Leaving customer
notifies a move
Notification with a
takeover
document
Notification
without a
takeover
document
Module
Initiate leaving
customer
Module
Start Access
Nobody notifies a
move
Customer asks
a disconnection
Module
Move-Out
Figure 25 - Customer Moves v1.0
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
40/52
UMIG 6.0 Structuring Process
9.1.2
Verschillende mogelijke situaties – Différentes situations possibles
De overnemer meldt als eerste zijn verhuizing.
Le repreneur signale son emménagement en premier
De toegangshouder van de overnemer lanceert de module
Start Access. Hij begint de energielevering op basis van de
startindex en de verhuisdatum. De toegangshouder van de
vertrekkende klant ontvangt de eindindex en het verbruik. Op
basis van die gegevens ontvangt de vertrekkende klant zijn
slotfactuur. Het bericht zal een code bevatten die aangeeft of
het energieovernamedocument werd ondertekend.
Een verhuizing wordt bij voorkeur op die manier behandeld.
Le détenteur d’accès du repreneur lance le module Start
Access. Il commence la livraison de l’énergie sur base de
l’index de départ et de la date de déménagement. Le
détenteur d’accès du client sortant reçoit l’index de fin et la
consommation. Sur base de ces données, le client sortant
reçoit sa facture de clôture. Le message comportera un code
permettant de savoir si un document de reprise des énergies a
été signé
.
Un déménagement est traité de préférence de cette manière.
De vertrekkende klant meldt als eerste zijn verhuizing.
Le client sortant signale son déménagement en premier
De vertrekkende klant wil zijn verantwoordelijkheid op het
toegangspunt laten beëindigen en verwacht van zijn
toegangshouder dat deze een slotfactuur opmaakt.
Le client sortant souhaite arrêter sa responsabilité sur le point
d’accès et attend de son détenteur d’accès qu’il établisse une
facture de clôture de compte.
De vertrekkende klant heeft hier drie opties:
Pour ce faire, le client sortant a trois possibilités :
1.
Hij kan de afsluiting van de meters vragen
("disconnection").
Zijn toegangshouder start de module "Move out". Het
punt wordt gesloten na afspraak met de netbeheerder
en de factuur wordt opgemaakt op basis van de
indexen en het verbruik vastgesteld op de datum van
afsluiting van de meter.
1.
Il peut demander la fermeture des compteurs
(“disconnection”).
Son détenteur d’accès initie le module Move out. le
point est fermé après rendez-vous avec le
gestionnaire de réseau et la facture est établie sur
base des index et de la consommation arrêtés à la
date de fermeture du compteur.
2.
Hij meldt zijn verhuizing na ondertekening van een
energieovernamedocument met de overnemer. De
toegangshouder lanceert een module Initiate Leaving
Customer met het label With Handover Document.
Om geldig te zijn moet het overnamedocument
voldoen aan volgende voorwaarden:
o Het bestaan van een overnamedocument
wordt
formeel
bevestigd
door
de
vertrekkende klant.
o De verstrekte informatie komt uit een
overnamedocument dat correct en volledig
is ingevuld, d.w.z. met vermelding van de
gegevens van beide partijen, de indexen
van
overdracht/overname,
de
toegangshouder van de overnemer, enz.
o Het
energieovernamedocument
wordt
ondertekend door de vertrekkende klant en
door de overnemer.
o De verhuisdatum respecteert de Cmin.
o De startindex van de volgende Start Access
module voor de overnemer (klant of
eigenaar) moet gelijk zijn aan de eindindex
van de module Initiate Leaving Customer.
2.
Il signale son déménagement après avoir signé un
document de reprise des énergies avec le repreneur.
Le détenteur d’accès lance un module Initiate
Leaving Customer avec le label With Handover
Document.
Pour être valable, le document de reprise, doit
répondre aux conditions ci-après :
o L’existence du document de reprise est
formellement confirmée par le client sortant.
o Les informations données sont issues d’u
document de reprise correctement et
complètement rédigé, càd faisant mention des
données des deux parties, les index de
remise/reprise, le détenteur d’accès du
repreneur,…
o Le document de reprise des énergies est
signé par le client sortant et par le repreneur.
o La date de déménagement respecte la Cmin.
o L’index de départ du module Start Access
suivant, pour le repreneur (client ou
propriétaire) doit être celui utilisé comme
index de fin dans le module Initiate Leaving
Customer.
3.
In bijzondere gevallen kan de klant zijn
verantwoordelijkheid beëindigen zonder garantie dat
zijn slotfactuur gebaseerd is op de meegedeelde
gegevens (of later wordt rechtgezet). Dit is het geval
wanneer het energieovernamedocument niet volledig
of onbestaande is.
De toegangshouder lanceert een module Initiate
Leaving Customer met het label Without Handover
3.
Dans des cas particuliers, le client peut clôturer sa
responsabilité sans garantie que sa facture de clôture
ne soit basée sur les données communiquées (ou ne
soit rectifiée par la suite). C’est le cas lorsque le
document de reprise des énergies n’est pas complet
ou inexistant.
Le détenteur d’accès lance un module Initiate
Leaving Customer avec le label Without Handover
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
41/52
UMIG 6.0 Structuring Process
Document. Le détenteur d’accès reste alors
responsable du point dans le Registre d’Accès
pendant maximum un délai ILC3. Ce nombre de jours
est un paramètre. A Bruxelles, le détenteur d’accès
du client sortant reste responsable jusqu’à ce la
situation soit régularisée par un repreneur ou par une
fermeture des compteurs.
Document.
De
toegangshouder
blijft
dan
verantwoordelijk
voor
het
punt
in
het
Toegangsregister gedurende een termijn van max.
ILC3. Dit aantal dagen is een parameter. In Brussel
blijft de toegangshouder van de vertrekkende klant
verantwoordelijk totdat de situatie geregulariseerd
wordt door een overnemer of door een
meterafsluiting.
Verhuizing die door niemand wordt gemeld
Personne ne signale un déménagement
De toegangshouder van een toegangspunt kan op basis van
externe informatie (retour post, …) beslissen dat hij te maken
heeft met een geval van verhuizing zonder kennisgeving.
In dat geval start de toegangshouder een module "Initiate
Leaving Customer" met het label "Without Handover
Document". Hij beschikt dan echter niet over de indexen.
Aangezien de invoering van de indexen verplicht is voor iedere
verhuizing in het verleden wanneer de aan het toegangspunt
verbonden meter een klassieke meter is, kan de
toegangshouder in dat geval een module ILC lanceren met
effectieve datum minimum Request Date +1. Op die manier is
de invoering van de index niet meer verplicht.
Le détenteur d’accès d’un point d’accès peut décider sur base
d’informations externes (retour poste,…) qu’il s’agit d’une
situation de déménagement sans que personne n’en ait fait
mention.
Le détenteur d’accès lance dans ce cas, un module “Initiate
Leaving Customer” avec le label “Without Handover
Document”. Toutefois, dans ce cas, le détenteur d’accès ne
dispose pas des index. Étant donné que l’introduction des
index est obligatoire pour tout déménagement dans le passé
lorsque le compteur lié au point d’accès est un compteur
classique, le détenteur d’accès pourra dans ce cas, lancer un
module ILC avec une date effective à minimum Request Date
+1. De ce fait, l’introduction d’index n’est plus imposée.
9.1.3
Werking van de module – Fonctionnement du module
9.1.3.1
ILC With Handover Document
De module Initiate Leaving Customer met het label With
Handover Document is slechts van toepassing bij een
verhuizing die aangetoond kan worden door een
energieovernamedocument dat voldoet aan bepaalde
3
voorwaarden . Dit document moet niet noodzakelijk
uitgewisseld worden tussen de marktspelers; het moet
gewoon bij de klant kunnen worden gevraagd als bewijs bij
een eventuele betwisting. In sommige gevallen kan de DNB
het document vragen aan de toegangshouder, die het op zijn
beurt aan zijn klant vraagt.
De onderstaande afbeelding toont de situatie van het
Toegangsregister (AR) na een Initiate Leaving Customer met
label "met overnamedocument" en dit voor alle gewesten.
Le module Initiate Leaving Customer avec label With
Handover Document n’est d’application qu’en cas de
déménagement pouvant être prouvé par un document de
4
reprise des énergies qui répond à certaines conditions . Ce
document ne doit pas nécessairement être échangé entre les
acteurs du marché ; il doit simplement pouvoir être demandé
au client en tant que preuve en cas de contestation éventuelle.
Dans certains cas, le GRD peut le demander au détenteur
d’accès qui le réclamera lui-même à son client.
La figure ci-dessous montre la situation du Registre d’Accès
(RA) après un Initiate Leaving Customer avec le label « avec
document de reprise » et ce, pour toutes les régions.
3
Het bestaan van een overnamedocument wordt formeel bevestigd door de vertrekkende klant. De verstrekte informatie komt uit een overnamedocument dat correct
en volledig is ingevuld, d.w.z. met vermelding van de gegevens van beide partijen, de indexen van overdracht/overname, de toegangshouder van de overnemer, enz.
Het energieovernamedocument wordt ondertekend door de vertrekkende klant en door de overnemer. De verhuisdatum ligt maximaal 30 dagen in het verleden. De
startindex van de volgende Start Access module voor de overnemer (klant of eigenaar) moet overeenstemmen met de eindindex van de module Initiate Leaving
Customer.
4
L’existence du document de reprise est formellement confirmée par le client sortant. Les informations données sont issues d’un document de reprise correctement
et complètement rédigé, càd faisant mention des données des deux parties, les index de remise/reprise, le détenteur d’accès du repreneur,… Le document de
reprise des énergies est signé par le client sortant et par le repreneur. La date de déménagement se situe au maximum 30 jours dans le passé. L’index de départ du
module Start Access suivant, pour le repreneur (client ou propriétaire) doit être celui utilisé comme index de fin dans le module Initiate Leaving Customer
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
42/52
UMIG 6.0 Structuring Process
9.1.3.1.1
Situatie bij de registratie van de ILC – Situation à l’enregistrement du ILC
max Cmin
Moving
Date
Request Date
ILC
Old
Balance Supplier
Customer
“empty”
A
Figure 26 – Initiate Leaving Customer With Handover Document at the Request Date v1.0
De verantwoordelijkheid van de klant voor het toegangspunt
eindigt op de verhuisdatum; datum vermeld op het
energieovernameformulier, evenals de indexen als het gaat
om een klassieke meter. Bij een slimme meter geldt alleen de
datum want de indexen worden gelezen door de DNB op de
verhuisdatum.
9.1.3.1.2
Regularisatie met volgende Start Access – Régularisation avec le Start Access suivant
Moving
Date
Balance Supplier
Customer
La responsabilité du client pour le point d’accès se termine à
la date du déménagement ; date reprise sur le document de
reprise des énergies, ainsi que les index lorsqu’il s’agit de
compteur classique. En cas de compteur intelligent, seule la
date compte car les index seront lus par le GRD à la date de
déménagement.
Request Date
ILC
Start Access
Old
New
A
B
Figure 27 – Initiate Leaving Customer With Handover Document Regularized v1.0
Situatie van het Access Register (AR) na een nieuwe module
Start Access met indexen die overeenstemmen met de
eindindexen meegedeeld in de module Initiate Leaving
Customer. Standaard is de eindindex van een Initiate Leaving
Customer de startindex van de volgende Start Access. Via de
voorgaande Preswitching kan de toegangshouder de in de
module Initiate Leaving Customer meegedeelde indexen
bekijken. Aangezien deze indexen vermeld zijn in het
energieovernamedocument, moeten ze identiek zijn. De
overnemer en zijn toegangshouder worden opgenomen in het
AR op de verhuisdatum.
In principe kan met de SA slechts maximaal 60 kalenderdagen
in het verleden gegaan worden. In het kader van een
verhuizing (een SA volgend op een ILC) kan dit doorbroken
worden door met de SA een flag "take over ILC" mee te
geven.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Situation du Registre d’Accès (RA) suite au nouveau module
Start Access avec des index qui correspondent aux index de
fin renseignés dans le module Initiate Leaving Customer. Par
défaut, l’index fin d’un Initiate Leaving Customer est l’index de
départ du Start Access qui suit. Via le Preswitching en amont,
le détenteur d’accès a la possibilité de voir les index
communiqués dans le module Initiate Leaving Customer. Etant
donné que ces index sont indiqués sur le document de reprise
des énergies, ils doivent être identiques. Le repreneur et son
détenteur d’accès sont repris dans le RA à la date du
déménagement.;
In principe kan met de SA slechts maximaal 60 kalenderdagen
in het verleden gegaan worden. In het kader van een verhuis
(een SA volgend op een ILC) kan dit doorbroken worden door
met de SA een flag “take over ILC” mee te geven
43/52
UMIG 6.0 Structuring Process
9.1.3.1.3
Regularisatie met betwisting van de ILC – Régularisation avec contestation du ILC
Moving
Date
Start Access +
Old
Balance Supplier
Customer
Request date
ILC
A
New
empty
B
Figure 28 – Initiate Leaving Customer With Handover Document Contestated v1.0
Bij betwisting van de start- en eindindex (niet gelijk aan die
van de ILC) kan de nieuwe toegangshouder zijn Start Access
lanceren met aanhechting van een kopie van het
energieovernamedocument, dat dan dient als bewijs in het
kader van de betwisting.
In dit geval stuurt de MPA het energieovernameformulier naar
de vroegere toegangshouder, die dan beslist of hij een
rectificatie wil of niet. (eventueel kan hij ook de op het
document vermelde toegangshouder contacteren)
9.1.3.2
9.1.3.2.1
En cas de contestation des index et date de départ (non
identiques à ceux du ILC), le nouveau détenteur d’accès peut
lancer son Start Access en annexant une copie du document
de reprise des énergie qui sert alors de preuve à la
contestation.
Dans ce cas, le MPA envoie le document de reprise des
énergies à l’ancien détenteur d’accès qui décidera s’il veut une
rectification ou pas. (le cas échéant, il peut contacter
bilatéralement le détenteur d’accès repris sur le document)
ILC Without Handover Document
Situatie bij de registratie van de ILC – Situation à l’enregistrement du ILC
max 30 d
Moving
Date
Request Date
ILC
“empty”
Old
Balance Supplier
Customer
Moving Date + ILC3
A
“empty”
Figure 29 – Initiate Leaving Customer Without Handover Document at the Request Date v1.0
De verantwoordelijkheid van de klant voor het toegangspunt
eindigt op de verhuisdatum. De toegangshouder krijgt een
index, op basis waarvan hij de vertrekkende klant kan
afsluiten. Hij blijft verantwoordelijk voor het punt tot de
volgende Start Access. Bij gebreke van een Start Access,
houdt zijn verantwoordelijkheid evenwel op na ILC3. Na ILC3
en bij gebreke van regularisatie, ontvangt de toegangshouder
de index waarbij zijn verantwoordelijkheid eindigt. Zowel de
toegangshouder als de DNB nemen daaropvolgende acties
om de overnemer te zoeken en een contract met hem te
sluiten om de situatie van het toegangspunt te regulariseren
Tijdens de periode "Balance Supplier = empty", zolang geen
Start Access is gelanceerd, wordt in de allocatie dit
toegangspunt toegewezen aan de residufactor. Indien geen
regularisatie heeft plaatsgehad op het ogenblik van de
definitieve reconciliatie, wordt het eventuele verbruik
toegewezen aan het residu en dus ten laste genomen door de
DNB (opgemerkt wordt dat die situatie zich maar zelden of
nooit zal voordoen).
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
La responsabilité du client pour le point d’accès se termine à
la date du déménagement. Le détenteur d’accès reçoit un
index lui permettant de clôturer le client sortant. Il reste
responsable du point jusqu’au Start Access suivant. A défaut
de Start Access, sa responsabilité est toutefois stoppée après
ILC3. Après ILC3, à défaut d’une régularisation, le détenteur
d’accès reçoit l’index de fin de sa responsabilité. Tant le
détenteur d’accès que le GRD prennent des actions
séquentielles visant à chercher le repreneur et le contracter
afin de régulariser la situation du point d’accès. Durant la
période « Balance Supplier = empty », tant qu’un Start Access
n’est pas lancé, l’allocation du point est attribuée au facteur
résidu. Au cas où aucune régularisation n’est intervenue au
moment de la réconciliation finale, la consommation est mise
au niveau du résidu et donc, prise en charge par le GRD (A
noter que, si cette situation devait se présenter, ce ne serait
que dans de très rares cas).
44/52
UMIG 6.0 Structuring Process
9.1.3.2.2
Regularisatie met volgende Start Access – Régularisation avec le Start Access suivant
Moving
Date
Balance Supplier
Customer
Request Date
ILC
Start Access
Old
New
A
B
Moving Date + ILC3
Figure 30 – Initiate Leaving Customer Without Handover Document Regularized v1.0
Bij lancering van de module "Start Access" moeten de
startindexen identiek zijn aan de eindindexen van de module
Initiate Leaving Customer. Standaard is de eindindex van een
Initiate Leaving Customer de startindex van de volgende Start
Access. Via de voorgaande Preswitching kan de
toegangshouder de in de module Initiate Leaving Customer
meegedeelde indexen bekijken. De overnemer wordt dan
opgenomen in het AR op de verhuisdatum.
Au lancement du module « Start Access » les index de départ
doivent être identiques aux index de fin du module Initiate
Leaving Customer. Par défaut, l’index fin d’un Initiate Leaving
Customer est l’index de départ du Start Access qui suit. Via le
Preswitching en amont, le détenteur d’accès a la possibilité de
voir les index communiqués dans le module Initiate Leaving
Customer. Le repreneur est alors repris dans le RA à la date
du déménagement.
Het principe blijft hetzelfde, ongeacht of de Start Access wordt
verstuurd voor of na de termijn van ILC3.
Le principe reste le même, que le Start Access soit envoyé
avant ou après le délai ILC3.
9.1.3.2.3
Regularisatie met betwisting van de ILC – Régularisation avec contestation du ILC
Moving
Date
Start Access +
Old
Balance Supplier
Customer
Request Date
ILC
A
New
A
B
Figure 31 – Initiate Leaving Customer Without Handover Document Contestated v1.0
Wanneer de overnemer zijn verhuizing meldt op basis van een
overnamedocument met index/datum die verschilt van die
meegedeeld in de module Initiate Leaving Customer. In dat
geval kan de Start Access gelanceerd worden met een
specifieke flag en kopie van het energieovernamedocument in
bijlage. De vorige toegangshouder blijft verantwoordelijk voor
het punt tot de definitieve Start Access. Indien de vertrekkende
klant geen formulier had, is het aan zijn toegangshouder om
zijn slotfactuur eventueel te corrigeren.
9.1.4
9.1.4.1

Lorsque le repreneur signale son emménagement sur base
d’un document de reprise avec un index/date différent de ce
qui fut annoncé dans le module Initiate Leaving Customer.
Dans ce cas, le Start Access peut être lancé avec un flag
spécifique et copie du document de reprise des énergies en
annexe. Le détenteur d’accès précédent reste responsable du
point jusqu’au Start Access final. Si le client sortant n’avait pas
de formulaire, il est de la responsabilité de son détenteur
d’accès de corriger éventuellement sa facture de clôture.
Synthese van de Business Rules – Synthèse des Business Rules
Label « With Handover Document »
Einde verantwoordelijkheid van de klant op de
meegedeelde datum en indexen (onder voorbehoud van
validatie).
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx


Fin de la responsabilité du client à la date et aux index
communiqués (sous réserve de validation).
Fin de la responsabilité du détenteur d’accès dès
45/52
UMIG 6.0 Structuring Process

Einde van de verantwoordelijkheid van de toegangshouder
bij ontvangst van de volgende Start Access (in principe op
dezelfde datum en met dezelfde index, en verstuurd
binnen een vrij korte termijn).
 De volgende Start Access zal automatisch gebaseerd zijn
op de datum en de indexen die gevalideerd werden in de
module Initiate Leaving Customer.
 Bij (gerechtvaardigde) betwisting, zal de volgende Start
Access gemerkt zijn met een “flag” en informatie bevatten
betreffende de DNG en de tussentijdse toegangshouder,
plus een kopie van het energieovernameformulier.
 Bij gebreke van Start Access binnen een termijn van ILC1,
richt de DNB een Request Start aan de nieuwe op het punt
voorziene toegangshouder. Deze laatste moet reageren
binnen een termijn van [...].
9.1.4.2










réception du Start Access suivant (qui en principe sera à
la même date et aux mêmes index, et envoyé dans un
délai assez court).
La Start Access suivant sera automatiquement basé sur
le date et les index validés du module Initiate Leaving
Customer
En cas de contestation (justifiée), Le Start Access qui suit
sera « flaggé » et contiendra les informations relatives à
l’URD et au détenteur d’accès intermédiaire, ainsi qu’une
copie du document de reprise des énergies.
A défaut de Start Access dans un délai de ILC1, le GRD
lance un Request Start vers le nouveau détenteur d’accès
prévu sur le point. Ce dernier doit agir dans un délai
Label « Without Handover Document »
Einde verantwoordelijkheid van de klant op de
meegedeelde datum en indexen (onder voorbehoud van
validatie).
De einddatum voor de toegangshouder is de datum van
de volgende Start Access en kan niet later vallen dan ILC3
na de verhuisdatum. Op ILC3 wordt het punt als "empty"
beschouwd en dus zonder toegangshouder op het niveau
van het AR. (in Brussel is ILC3 gelijk aan oneindig en blijft
de toegangshouder verantwoordelijk voor het punt tot de
regularisatie)
Na ILC3 wordt het eventuele verbruik dat geregistreerd
wordt tussen de verhuizing en de regularisatie van het
punt toegewezen aan de residufactor en, in voorkomend
geval, aan de restterm na reconciliatie (behalve in Brussel
bij een periode langer dan ILC3).
De volgende Start Access zal automatisch gebaseerd zijn
op de datum en de indexen die gevalideerd werden in de
module Initiate Leaving Customer.
Bij (gerechtvaardigde) betwisting wordt het tussentijds
verbruik toegewezen aan de toegangshouder van de
vertrekkende klant, die beslist of hij de slotfactuur aan zijn
klant al dan niet corrigeert.
De toegangshouder onderneemt onmiddellijk specifieke
acties om de overnemer te vinden en de situatie te
regulariseren.
Bij het ontbreken van een Start Access binnen 30 dagen,
neemt de DNB acties om de situatie te regulariseren.







Fin de la responsabilité du client à la date et aux index
communiqués (sous réserve de validation).
La date de fin pour le détenteur d’accès est la date du
Start Access suivant et ne peut être supérieure à ILC3
après la date du déménagement. A ILC3, le point est
réputé « empty » et donc sans détenteur d’accès au
niveau du RA. (à Bruxelles ILC3 est égal à l’infini et le
détenteur d’accès reste responsable du point jusqu’à la
régularisation)
Après ILC3, les éventuelles consommations enregistrées
entre le déménagement et la régularisation du point sont
attribuées au résidu et, le cas échéant, au restterm après
réconciliation. (sauf à Bruxelles si la période est
supérieure à ILC3)
La Start Access suivant sera automatiquement basé sur le
date et les index validés du module Initiate Leaving
Customer
En cas de contestation (justifiée), les consommations
intermédiaires sont attribuées au détenteur d’accès du
client sortant qui décidera de corriger la facture de clôture
de son client ou pas.
Le détenteur d’accès entame directement des actions
spécifiques en vue de trouver le repreneur et de
régulariser la situation.
A défaut de Start Access dans un délai de 30 jours, le
GRD prend des actions pour régulariser la situation
9.1.5
Regularisatieacties door de toegangshouder – Activités de régularisation du détenteur d’accès
De toegangshouder moet acties ondernemen om de Le détenteur d’accès doit prendre des actions afin de trouver
overnemer van een toegangspunt te vinden in geval van een le repreneur d’un point d’accès ayant fait l’objet d’un Initiate
Initiate Leaving Customer met label "Without Handover Leaving Customer avec label « Without Handover Document
Document". Het ontbreken van een document wil niet zeggen ». L’absence de document ne veut pas dire que le client
dat de vertrekkende klant geen informatie kan geven over de sortant ne sait pas donner d’informations concernant le
overnemer of de eigenaar van het gebouw. Er zijn voor de repreneur ou le propriétaire de l’immeuble. Diverses actions
toegangshouder dus verschillende acties mogelijk:
sont donc possibles pour le détenteur d’accès :



De gegevens betreffende een potentiële overnemer of de
eigenaar inwinnen bij de vertrekkende klant.
De potentiële overnemer of de eigenaar contacteren om de
situatie te regulariseren.
Zo nodig, de bewoner van het betrokken gebouw
aanschrijven opdat hij de situatie zou regulariseren bij de
toegangshouder van zijn keuze.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx



Collecter les informations concernant un repreneur
potentiel ou le propriétaire, auprès du client sortant.
Contacter le repreneur potentiel ou le propriétaire afin de
régulariser la situation.
Le cas échéant, écrire à l’habitant de l’immeuble concerné
pour qu’il régularise sa situation auprès du détenteur
d’accès de son choix.
46/52
UMIG 6.0 Structuring Process
9.1.6
9.1.6.1
Regularisatieacties door de DNB – Activités de régularisation du GRD
Afwezigheid van een Start Access en label “With Handover Document” – Absence de Start Access et label
“With Handover Document”
Indien ILC1 na de behandeling van een module Initiate
Leaving Customer met label "With Handover Document" geen
Start Access is geregistreerd, meldt de MPA de
toegangshouder van de overnemer (via een Request Start) dat
een regularisatie op het toegangspunt wordt verwacht (de
toegangshouder van de overnemer is aangeduid in het
document en moet ook opgenomen worden in het bericht van
de module Initiate Leaving Customer). Bij het uitblijven van
een reactie na ILC2, zal de MPA het oorspronkelijke label fout
verklaren en wijzigen. Op dat ogenblik wordt de vroegere
toegangshouder in kennis gesteld van de wijziging en moet hij
dus de voorziene acties ondernemen om de situatie te
regulariseren. De ILC3-termijn begint op de datum van
notificatie van de wijziging van het label.
9.1.6.2
ILC1 après la traitement d’un module Initiate Leaving
Customer avec label « With Handover Document», si aucun
Start Access n’est enregistré, MPA avise (via Request Start) le
détenteur d’accès du repreneur, qu’une régularisation sur le
point d’accès est attendue. (le détenteur d’accès du repreneur
étant indiqué sur le document, celui-ci doit être également
repris dans le message du module Initiate Leaving Customer.
A défaut d’un réaction après ILC2, MPA déclarera le label
initial comme étant erroné et le modifiera. A ce moment,
l’ancien détenteur d’accès est avisé de ce changement et doit
donc entamer les actions prévues pour régulariser la situation.
Le délai de ILC3 commence à la date de notification de
changement du label.
Afwezigheid van een Start Access 30 kalenderdagen na het uitsturen van een ILC « Without Handover
Document » – Absence de Start Access 30 jours calendrier après l’envoi d’un ILC “Without Handover
Document”
Als de acties van de toegangshouder van de vertrekkende
klant niets opleveren, neemt de DNB het na 30 kalenderdagen
over:
À défaut de résultats suite aux actions entreprises par le
détenteur d’accès du client sortant, le GRD prend le relai
après 30 jours calendrier :

Zoeken eigenaar (of bevestiging) bij het kadaster,


Zoeken
overnemer
via
andere
Rijksregister/kruispuntbank – TBC),
Recherche du propriétaire (ou confirmation) auprès du
cadastre,

Bezoek ter plaatse om zich te vergewissen dat het
gebouw leegstaat,
Recherche du repreneur par d’autres moyens (ex :
Registre national/banque carrefour – TBC),

Visite sur place afin de vérifier que l’immeuble est vide,

Eventueel gebruik van het regularisatieformulier,

Utilisation éventuelle du formulaire de régularisation,

Brief aan de bewoner van het gebouw, waarin gewezen
wordt op de mogelijke onderbreking van levering bij
gebrek aan regularisatie.

Courrier à l’habitant de l’immeuble, mentionnant la
possibilité d’une interruption des fournitures à défaut d’une
régularisation.

Onderbreking van de leveringen.

Interruption des fournitures.

kanalen
(bv.
Deze acties zijn vergelijkbaar met die voorzien in het kader
van de Moza gebruikt in de vroegere MIG-versies.
Ces actions sont semblables à celles prévues dans le cadre
des Moza utilisés dans les versions antérieures du MIG.
9.1.7
Onjuist label – Label incorrect
Het is mogelijk dat de DNB, na afsluiting van de vertrekkende
klant en op basis van de daarna verzamelde gegevens,
vaststelt dat het label "With Handover Document" verkeerd
werd gebruikt (al dan niet bewust). In dat geval wordt de
toegangshouder van de vertrekkende klant verwittigd en
onderneemt hij acties om het punt te regulariseren. Het is aan
hem om de slotfactuur van de vertrekkende klant eventueel te
corrigeren. De MPA wijzigt dan het label van de module.
Suite à la clôture du client sortant et sur base des informations
collectées par la suite, il est possible que le GRD constate que
le label « With Handover Document » ait été utilisé de manière
erronée (sciemment ou pas). Dans ce cas, le détenteur
d’accès du client sortant est avisé et entame des actions de
régularisation du point. Il lui appartient d’éventuellement
corriger la facture de clôture du client sortant. Le MPA modifie
alors le label du module.
9.1.8
Refus de la contestation – Refus de la contestation
Wanneer de toegangshouder die een Start Access in gang Lorsque le détenteur d’accès initiant un Start Access conteste
zet, de datum en/of index van de ILC betwist, kan hij de flag la date et/ou l’index du ILC, il peut activer le flag
“betwisting”
activeren
en
een
kopie
van
het « contestation » et joindre une copie du document de reprise
energieovernameformulier bijvoegen als bewijsmateriaal van des énergies comme preuve probante de sa contestation. La
zijn betwisting. Het bewijs wordt dan overgemaakt aan de preuve est ensuite transmise au détenteur d’accès précédent
vorige toegangshouder (initiator van de ILC). Deze analyseert (initiateur du ILC). Ce dernier, à l’analyse du document doit
het overnameformulier en moet kunnen tussenkomen als het pouvoir intervenir lorsque le document ne répond pas aux
niet voldoet aan de acceptatiecriteria van het bewijs (bv. het is critères d’acceptation de la preuve. (ex : il ne s’agit pas du
niet het officiële document, het is onvolledig of niet document officiel, il est incomplet ou non signé,…)
ondertekend, …)
In dat geval heeft de oude toegangshouder de mogelijkheid Dans ce cas, l’ancien détenteur d’accès a la possibilité de
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
47/52
UMIG 6.0 Structuring Process
om de betwisting te verwerpen en zal de MPA de Start Access
verbeteren op basis van een gewone aanvraag; namelijk: op
de datum en met de indexen van de ILC.
rejeter la contestation et le MPA corrigera le Start Access sur
base d’une demande normale ; à savoir : à la date et aux
index de l’ILC.
9.2 Request Start
Sommige markttransacties impliceren het achtereenvolgens
opstarten van andere transacties. Deze kunnen opgestart
worden door de actieve toegangshouder op het toegangspunt
of door een derde toegangshouder. In beide gevallen is er een
probleem indien de aansluitend op te starten transactie niet is
opgestart
binnen
de
krachtens
de
marktregels
overeengekomen termijn en moet een oplossing worden
gevonden om de toegangshouder die de transactie moet
opstarten te herinneren aan zijn verantwoordelijkheid.
Certaines transactions de marché impliquent le lancement en
cascade d’autres transactions. Celles-ci peuvent être lancées
par le détenteur d’accès actif sur le point d’accès ou par un
détenteur d’accès tiers. Dans les deux cas, si après un temps
convenu dans les règles du marché, le lancement de la
transaction devant être lancée en cascade n’a pas lieu, un
problème se pose et une solution doit être trouvée pour
rappeler la responsabilité qui incombe au détenteur d’accès
devant lancer la transaction.
In die optiek werd de module Request Start uitgewerkt. Deze
module wordt
Le module Request Start a été créé dans cette optique. Ce
module sera
-
hetzij rechtstreeks in gang gezet door de Metering Point
Administrator en "opgestuurd" naar de toegangshouder;
hetzij in gang gezet door de DNB, in welk geval de
Metering Point Administrator ze doorgeeft aan de
toegangshouder.
-
Hij wordt gebruikt in drie situaties:
-
ingevolge een regularisatieformulier;
ingevolge een module Initiate Leaving Customer met het
label “With Handover Document” dat na ILC1 niet
gevolgd is door een Start Access;
ingevolge het verlies van het statuut van beschermde
klant in Brussel
-
9.2.1
9.2.1.1
-
soit déclenché directement par le Metering Point
Administrator et « envoyé » vers le détenteur d’accès ;
soit déclenché par le GRD dans quel cas le Metering
Point Administrator le transmettre au détenteur d’accès.
-
Il sera utilisé dans trois situations :
-
suite à un formulaire de régularisation;
suite à un module Initiate Leaving Customer avec le
label « With Handover Document » qui n’est pas suivi
d’un Start Access après ILC1 ;
suite à la perte du statut de client protégé à Bruxelles
-
Label « Regularization form »
Algemeenheden – Généralités
Het regularisatieformulier heeft contractuele waarde tussen
twee partijen. Een regularisatie kan enkel worden aangevat
voor punten verbonden aan klassieke meters met jaarlijkse
opname of aan smart meters.
Le formulaire de régularisation a la valeur d’un contrat entre
deux parties. Une régularisation ne peut être entamée que
pour les points liés à des compteurs classiques en relevé
annuel ou à des compteurs smart.
Iedere distributienetgebruiker (DNG), zowel residentieel als
niet-residentieel, is verplicht om een leveringscontract te
sluiten met een toegangshouder. Sommige DNG’s laten dat na
en verhuizen zonder hun toegangshouder te verwittigen.
Tout utilisateur de réseau de distribution (URD), tant
résidentiel que non résidentiel, a l’obligation de signer un
contrat de fourniture avec un détenteur d’accès d’énergie.
Certains URD négligent cet aspect et déménagent sans en
aviser leur détenteur d’accès.
Om
die
situaties
recht
te
zetten,
regularisatieformulier worden gebruikt.
moet
een
Met dit formulier heeft de DNG die ergens intrekt drie
mogelijkheden:
-
-
-
Hij laat weten een contract te hebben met een
toegangshouder voor zijn oude adres en aanvaardt
dat de DNB de klantgegevens en gegevens
betreffende
het
toegangspunt
aan
de
toegangshouder bezorgt;
Hij heeft nog geen toegangshouder en aanvaardt dat
de toegangshouder van de vroegere bewoner hem
energie levert; in dat geval kan hij van
toegangshouder veranderen met kennisgeving een
maand op voorhand.
Hij kan vragen om afsluiting van zijn meter.
De DNB kan een regularisatieformulier laten invullen en
ondertekenen als het gaat om een nieuwe klant. Dit
regularisatieformulier wordt ofwel ingevuld door de klant naar
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Pour régulariser ces situations, il faut utiliser le formulaire de
régularisation.
Avec ce formulaire, l’URD qui emménage a trois possibilités :
-
-
-
Il signale avoir un contrat avec un détenteur d’accès
pour son ancienne adresse et accepte que le GRD
transmette les informations du client et du point
d’accès au détenteur d’accès ;
Il n’a pas encore de détenteur d’accès et accepte que
le détenteur d’accès de l’ancien occupant, le
fournisse en énergie ; dans ce cas, il peut changer de
détenteur d’accès moyennant un préavis d’un mois
Il peut demander la fermeture de son compteur
Le GRD peut faire remplir et signer un formulaire de
régularisation s’il s’agit d’un nouveau client. Ce formulaire de
régularisation est soit rempli par ce client suite à un courrier,
soit lors d’une visite terrain (visite administrative ou visite
technique).
48/52
UMIG 6.0 Structuring Process
aanleiding van een schrijven of bij een bezoek ter plaatse
(administratief of technisch bezoek).
De DNB kan ook een regularisatieformulier laten invullen en
ondertekenen met de eigenaar van het goed.
Le GRD peut également faire remplir et signer un formulaire
de régularisation avec le propriétaire du bien.
Dit formulier biedt de eigenaar drie mogelijkheden:
Avec ce formulaire, le propriétaire a trois possibilités :
Hij heeft nog geen toegangshouder en aanvaardt dat
de toegangshouder van de vroegere bewoner hem
energie levert; in dat geval kan hij van
toegangshouder veranderen met kennisgeving een
maand op voorhand.
Om een onderbreking van de toevoer te voorkomen,
opteert hij voor een "leegstandscontract" bij de
toegangshouder voor elektriciteit en/of gas van de
vorige bewoner. Zodra een nieuwe bewoner zijn
intrek neemt en de nodige stappen heeft genomen bij
een toegangshouder van zijn keuze, wordt dit
leegstandscontract opgeheven.
Hij kan vragen om afsluiting van zijn meter.
De DNB kan dan de module Request Start aanmaken om een
lopend scenario te annuleren of aan een toegangshouder
vragen om het punt over te nemen. De DNB moet
verificatieprocedures volgen om zich te vergewissen van de
geldigheid van het document.
-
-
9.2.1.2

-
-
Il n’a pas encore de détenteur d’accès et accepte que
le détenteur d’accès de l’ancien occupant, le
fournisse en énergie ; dans ce cas, il peut changer de
détenteur d’accès moyennant un préavis d’un mois
Afin d’éviter une coupure d’alimentation, il opte pour
un contrat « maison vide » auprès du détenteur
d’accès d’électricité et/ou de gaz naturel du
précédent résident. Dès qu’un nouveau résident
s’installera et aura accompli les démarches
nécessaires auprès d’un détenteur d’accès de son
choix, son contrat « maison vide » sera clôturé.
Il peut demander la fermeture de son compteur
Le GRD aura alors l’occasion de générer le module Request
Start afin d’annuler un scénario en cours ou de demander à un
détenteur d’accès de reprendre le point. Le GRD doit mener
des procédures de vérifications pour s’assurer de la validité du
document.
Verplichtingen – Obligations
Toegangshouder:

Détenteur d’accès :
De toegangshouder die een regularisatieformulier ontvangt,
moet het behandelen en binnen maximaal 5 werkdagen na
ontvangst ervan een Start Access met het passende label
versturen.
Le détenteur d’accès qui reçoit un formulaire de régularisation
doit le traiter et envoyer un Start Access avec le label adéquat
dans un délai maximum de 5 jours ouvrables dès réception du
formulaire de régularisation.
Uitzonderingen:
Exceptions :
-
-
-
Onvolledig formulier (absoluut noodzakelijke velden
voor de regularisatie, waaronder de index, zijn niet
ingevuld) of niet ondertekend formulier;
Poging tot bedrog door de DNG (bv.: Het
regularisatieformulier is ingevuld en ondertekend
door de klant die op het ogenblik geregistreerd is als
actieve klant, omzeiling van een drop of van plaatsing
budgetmeter
door
de
klant-wanbetaler
via
klantenwissel onder echtgenoten, enz.);
Het formulier is ingevuld en ondertekend door een
minderjarige.
…
-
-
-
Formulaire incomplet (des champs absolument
nécessaires à la régularisation, p.ex. l’index, sont
manquants) ou non signé ;
Tentative de tromperie de la part de l’URD (ex : Le
formulaire de régularisation est complété et signé par
le client actuellement enregistré comme client actif,
détournement d’un drop ou d’une pose compteur à
budget par le client mauvais payeur via changement
d’un client entre époux,…) ;
Le formulaire est complété et signé par un mineur
d’âge.
…
De opgegeven toegangshouder dient het punt over te nemen
en contacteert de klant om een contract met hem te proberen
sluiten.
Le détenteur d’accès repris est tenu de reprendre le point et
contacte le client pour tenter de signer un contrat avec le
client.


DNB:
De DNB kan een regularisatieprocedure inzetten bij ieder
bezoek op een leveringspunt waar de aanwezige DNG niet de
DNG is die vermeld is als actieve klant op het betrokken punt.
Onder meer:
-
Depannage
Meteropname
Plaatsing of desactivering van een budgetmeter
Verandering van meter
Gepland bezoek in het kader van een module ILC,
IUA, ISA
Na retour van een brief
Op verzoek van een Waalse beschermde klant
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
GRD :
Le GRD peut débuter une procédure de régularisation lors de
toute visite sur un point de fourniture où l’URD présent n’est
pas celui renseigné comme client actif sur le point concerné.
Entre autre :
-
Dépannage
Relevé
Placement ou désactivation d’un compteur à budget
Changement de compteur
Visite programmée dans le cadre d’un module ILC,
IUA, ISA
Après un retour de courrier
A la demande du client protégé wallon
49/52
UMIG 6.0 Structuring Process
-
…
-
…
De DNB kan een regularisatieprocedure inzetten per brief
(brieven verstuurd ingevolge een module Initiate Leaving
Customer of een Initiate Stop Access).
Le GRD peut débuter une procédure de régularisation par
courrier (courriers envoyés suite à un module de Initiate
Leaving Customer ou d’un Initiate Stop Access).
De DNB moet de nodige controles verrichten bij de ontvangst
van het document, voordat hij het aan de toegangshouder
doorgeeft:
Le GRD doit effectuer les contrôles nécessaires à la réception
du document et ce, avant de le transmettre au détenteur
d’accès :
-
Controle van alle verplichte velden.
Fraudecontrole.
Het Clearing House moet ook de eventuele lopende modules
Initiate Update Access of Initiate Stop Access annuleren
(volgens de interactieregels).
9.2.1.3
-
Contrôle de tous les champs obligatoires.
Contrôle fraude.
La Clearing House annule les éventuels modules Initiate
Update Access ou Initiate Stop Access en cours (via les règles
d’interactions).
Kenmerken van het RF – Caractéristiques du FR
Het regularisatieformulier moet zo snel mogelijk ingevuld
worden zodat de toegangshouder het kan behandelen.
Le formulaire de régularisation doit être complété le plus
possible pour que le détenteur d’accès puisse le traiter.
Het is belangrijk dat de verplichte velden naar behoren worden
ingevuld. Niettemin kan de afwezigheid van verplichte
gegevens die de mogelijkheid om de situatie te regulariseren
niet hinderen, geen aanleiding geven tot systematische
weigering vanwege de toegangshouders.
Il est important de remplir au mieux les champs obligatoires.
Toutefois, l’absence de données obligatoires mais n’entravant
pas la possibilité de régulariser la situation ne pourra faire
l’objet de rejets systématiques de la part des détenteurs
d’accès.
De andere (niet verplichte) gegevens hebben allemaal nut en
die velden moeten dus zoveel mogelijk ingevuld worden.
Les autres données (non obligatoires) ont toute leur utilité et
ces champs doivent donc pouvoir être complétés le plus
possible.
Als de klant verschillende aansluitingen heeft (elektriciteit en
gas bijvoorbeeld) op hetzelfde adres en voor dezelfde
toegangshouder, kan één enkel formulier worden gebruikt.
Bij een onvolledig ingevuld formulier contacteert de
toegangshouder de DNB. Het proces wordt niet opgeschort.
De DNB neemt dan de nodige maatregelen om de
ontbrekende gegevens aan te vullen en stuurt het formulier
terug naar de toegangshouder binnen 5 werkdagen.
De vermelde toegangshouder is verplicht het punt over te
nemen. Hij kan de klant contacteren om een contract af te
sluiten.
9.2.2
Si le client dispose de plusieurs raccordements (électricité et
gaz par exemple) à la même adresse et pour le même
détenteur d’accès, un seul formulaire peut être utilisé.
En cas de formulaire incomplet, le détenteur d’accès contacte
le GRD. Le processus n’est pas suspendu. Le GRD prend
alors les dispositions afin de compléter les données
manquantes et renvoie le formulaire au détenteur d’accès
dans les 5 jours ouvrables.
Le détenteur d’accès repris est tenu de reprendre le point. Il
peut contacter le client pour effectuer un contrat.
Label « Initiate Leaving Customer»
ILC1 na de behandeling van een module Initiate Leaving
Customer met label "With Handover Document", indien geen
Start Access is geregistreerd, richt de Metering Point
Administrator een module Request Start aan de
toegangshouder die door de overnemer op het
overnamedocument is vermeld. Deze Request Start maakt het
mogelijk de toegangshouder van de overnemer te laten weten
dat een regularisatie op het toegangspunt wordt verwacht. Hij
neemt alle gegevens betreffende de overnemer vermeld in de
module Initiate Leaving Customer over.
De Metering Point Administrator staat niet in voor de opvolging
van de regularisatie. Indien de toegangshouder geen Start
Access lanceert, wordt het label van de module gewijzigd en
wordt
de
oorspronkelijke
toegangshouder
opnieuw
verantwoordelijk voor het punt (zie PP Verhuizing).
De Metering Point Administrator verricht een monitoring maar
er zijn geen sancties aan verbonden aangezien het
overnamedocument geen contractuele waarde heeft tussen
beide partijen. Als er echter geen Start Access is opgestart
ILC2 na de Request Start, gaat het punt terug naar de
toegangshouder die de ILC heeft aangevraagd.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
ILC1 après la traitement d’un module Initiate Leaving
Customer avec label « With Handover Document », si aucun
Start Access n’est enregistré, le Metering Point Administrator
lance un module Request Start au détenteur d’accès repris par
le repreneur sur le PV de reprise. Ce Request Start permet
d’aviser le détenteur d’accès du repreneur, qu’une
régularisation sur le point d’accès est attendue. Il reprend
toutes les informations concernant le repreneur repris dans le
module Initiate Leaving Customer.
Le Metering Point Administrator ne traite pas la gestion de
suivi de la régularisation. Si le détenteur d’accès ne lance pas
un Start Access, le label du module sera modifié et le
détenteur d’accès initial sera à nouveau responsable du point
(cf. PP Déménagement).
Le Metering Point Administrator effectue un monitoring mais
celui-ci n’est pas pénalisant car le PV de reprise n’ a pas la
valeur d’un contrat entre les deux parties. Par contre, si aucun
Start Access n’est lancé ILC2 après le Request Start, le point
sera remis chez le détenteur d’accès demandeur du ILC.
50/52
UMIG 6.0 Structuring Process
9.2.3
Label « Switch Back Brussels »
Als een klant bij de SOLR zijn statuut van beschermde klant
heeft verloren of hij die niet meer kan aantonen, lanceert de
SOLR een bericht Request Start met label Switch Back
Brussels om de laatste commerciële toegangshouder die
instond voor deze klant te vragen om hem terug te nemen.
Aangezien de klant sedert zijn overschakeling naar de SOLR
kan verhuisd zijn, moet de aan de toegangshouder gerichte
Request Start aanvraag, naast de gewone velden die vereist
worden voor alle types Request Start aanvragen, de
referenties vermelden van het Toegangspunt waarvoor hij
indertijd een geregistreerd contract met die klant had.
Door het combineren van het oude en het nieuwe
Toegangspunt is de Balance Supplier die de aanvraag
Request Start ontvangt in staat een passende Start Access
aanvraag te initiëren. De DNB kan dan de module Request
Start aanmaken om een lopend scenario te annuleren of aan
een toegangshouder vragen om het punt over te nemen. De
DNB moet verificatieprocedures volgen om zich te
vergewissen van de geldigheid van het document.
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
Si un client étant chez le fournisseur SOLR a perdu ou ne peut
plus prouver son statut de client protégé, le fournisseur SOLR
initie alors un message Request Start avec label Switch Back
Brussels pour demander au dernier détenteur d’accès
commercial ayant été en charge de ce client de le reprendre.
Etant donné que le client peut, depuis son basculement chez
le fournisseur SOLR, avoir déménagé, il faudra que la
demande de Request Start adressée au détenteur d’accès
indique à ce dernier en plus des champs normaux prévus
dans toutes les types de demande de Request Start, les
références du Point d’Accès pour lequel il avait à l’époque un
contrat enregistré avec ce client.
Au moyen de la combinaison de l’ancien Point d’Accès et du
nouveau Point d’Accès, le détenteur d’accès recevant la
demande de Request Start sera alors en mesure d’initier une
demande de Start Access adéquate. Le GRD aura alors
l’occasion de générer le module Request Start afin d’annuler
un scénario en cours ou de demander à un détenteur d’accès
de reprendre le point. Le GRD doit mener des procédures de
vérifications pour s’assurer de la validité du document.
51/52
UMIG 6.0 Structuring Process
10 Tabellen & Indexen – Tables & Indexes
10.1 Begrippenlijst – Glossaire
Zie document UMIG 6.0 - GE - XD - 01 - Glossary
Voir le document UMIG 6.0 - GE - XD - 01 - Glossary
10.2 Table of Figures
Figure 1 - Tests Ex-Ante versus Ex-Post Monitoring v1.0 .............................................................................................................10
Figure 2 - Request Unlock v1.0 .....................................................................................................................................................13
Figure 3 - Contractual Requests v1.0 ............................................................................................................................................15
Figure 4 - Access Modification Requests v1.0 ...............................................................................................................................16
Figure 5 - Data Update Requests v1.0 ..........................................................................................................................................16
Figure 6 - Rectification or Cancellation Requests v1.0 ..................................................................................................................17
Figure 7 - Convention v1.0 ............................................................................................................................................................18
Figure 8 - Start Access Documentation v1.0 .................................................................................................................................19
Figure 9 - Move In Documentation v1.0 .........................................................................................................................................20
Figure 10 - Move Out Documentation v1.0 ....................................................................................................................................20
Figure 11 - Initiate Local Production Documentation v1.0 .............................................................................................................22
Figure 12 - Initiate Update Access Documentation v1.0 ................................................................................................................23
Figure 13 - Initiate Stop Access Documentation v1.0 ....................................................................................................................24
Figure 14 - Initiate Leaving Customer Documentation v1.0 ...........................................................................................................25
Figure 15 - Request Start Documentation v1.0..............................................................................................................................26
Figure 16 - Update Customer Metering Configuration Documentation v1.0 ..................................................................................27
Figure 17 - Prepayment Documentation v1.0 ................................................................................................................................28
Figure 18 - Update Technical Master Data Documentation v1.0 ...................................................................................................29
Figure 19 - Update Business Master Data Documentation v1.0 ....................................................................................................29
Figure 20 - Update Balance Responsible Party Documentation v1.0 ............................................................................................30
Figure 21 - Rectification Documentation v1.0 ................................................................................................................................30
Figure 22 - Cancel Module Documentation V1.0 ...........................................................................................................................31
Figure 23 - Use Case Structure v1.0 .............................................................................................................................................34
Figure 24 - Activity Main Structure v1.0 .........................................................................................................................................35
Figure 25 - Customer Moves v1.0 .................................................................................................................................................40
Figure 26 – Initiate Leaving Customer With Handover Document at the Request Date v1.0 ........................................................43
Figure 27 – Initiate Leaving Customer With Handover Document Regularized v1.0 .....................................................................43
Figure 28 – Initiate Leaving Customer With Handover Document Contestated v1.0 .....................................................................44
Figure 29 – Initiate Leaving Customer Without Handover Document at the Request Date v1.0 ...................................................44
Figure 30 – Initiate Leaving Customer Without Handover Document Regularized v1.0 ................................................................45
Figure 31 – Initiate Leaving Customer Without Handover Document Contestated v1.0 ................................................................45
UMIG 6.0 - BR - ST - 02 - Structuring Process v3.2.docx
52/52

Gare du Nord / Noordstation

Simonis - Elisabeth

Stockel / Stokkel

laatste nieuwsbrief - Prins Willem Alexander

Gun kinderen hun eigen label 1

Gun kinderen hun eigen label.indd

UMIG 6.0 Marktprocessen – Processus de marché General and/or

presentatie

Weekbrief 1, 24 augustus 2007 - Oranje Nassauschool Zandvoort

Bladmuziek afdrukken - Vrijeschoolliederen