ATRIAS – Market Processes UMIG 6.0 Marktprocessen – Processus de marché Business Requirements Structure Prepayment Versie v3.2 / Version v3.2 Voor consultatie / Pour consultation UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx UMIG 6.0 - Structure Prepayment DOCUMENT VERSIES – VERSIONS DU DOCUMENT ............................................................................................................................................................................. 4 1 1.1 Versieoverzicht – Gestion des versions ................................................................................................................................................................................................... 4 1.2 Referenties – Références ........................................................................................................................................................................................................................ 4 2 CONTEXT - CONTEXTE ............................................................................................................................................................................................................................. 6 2.1 Scope ....................................................................................................................................................................................................................................................... 6 2.2 Begrippen en definities – Concepts et définitions .................................................................................................................................................................................... 6 3 NOTIFY PAYMENT FOR PREPAYMENT ................................................................................................................................................................................................... 8 3.1 Proces Definitie – Définition du Process .................................................................................................................................................................................................. 8 3.2 Procesverloop – Déroulement de la procédure ........................................................................................................................................................................................ 9 3.3 Procesomschrijving – Description des procédures .................................................................................................................................................................................. 9 3.4 Uitzonderingen / Eigenheden - Exceptions / Caractéristiques ............................................................................................................................................................... 10 3.4.1 4 Herlaadplatform van de Balance Supplier - Plateforme de recharge des Balance Supplier........................................................................................................... 10 REQUEST PREPAYMENT ........................................................................................................................................................................................................................ 11 4.1 Proces definitie – Définition du Process ................................................................................................................................................................................................. 11 4.2 Procesverloop - Déroulement de la procédure ....................................................................................................................................................................................... 12 4.3 Procesomschrijving- Description des procédures .................................................................................................................................................................................. 13 4.4 Uitzonderingen / Eigenheden - Exceptions / Caractéristiques ............................................................................................................................................................... 15 4.4.1 5 Flag Request Unlock ...................................................................................................................................................................................................................... 15 HANDLE PREPAYMENT .......................................................................................................................................................................................................................... 16 5.1 Proces definitie – Définition du Process ................................................................................................................................................................................................. 16 5.2 Procesverloop – Déroulement de la procédure ...................................................................................................................................................................................... 17 5.3 Procesomschrijving – Description des procédures ................................................................................................................................................................................ 18 5.4 Uitzonderingen / Eigenheden – Exceptions/Caratéristiques .................................................................................................................................................................. 18 5.4.1 Aanvraag type Balance Notification - Demande du type Balance Notification ............................................................................................................................... 18 5.4.2 Aanvragen type Herstel / Onderbreking voorafbetaling - Demandes du type Rétablissement / Interruption du prépaiement ........................................................ 19 5.4.3 Aanvragen type Preventief alarm - Demandes du type Alarme préventive ................................................................................................................................... 21 5.4.4 Aanvragen type Alarm noodkrediet - Demandes du type Alarme de crédit de secours ................................................................................................................. 22 5.4.5 Chronologie van de Prepayment aanvragen en verantwoordelijkheden - Chronologie des demandes de Prepayment et responsabilités ................................... 23 UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 2/25 UMIG 6.0 - Structure Prepayment 5.4.6 (Des)Activering van de voorafbetalingsfunctionaliteit – (Dés)Activation de la fonctionnalité du prépaiement ................................................................................ 24 5.4.7 Weergave van de voorafbetaling in de Preswitching - Affichage du prépaiement dans le Preswitching ........................................................................................ 24 6 TABELLEN & INDEXEN – TABLES & INDEXES ..................................................................................................................................................................................... 25 6.1 Begrippenlijst – Glossaire ................................................................................................................................................................................................................... 25 6.2 Table of Figures ................................................................................................................................................................................................................................... 25 UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 3/25 UMIG 6.0 - Structure Prepayment 1 Document versies – Versions du Document 1.1 Versieoverzicht – Gestion des versions Versie - Version Datum - Date Auteur V1.0 31/01/2013 Atrias MPP MIG6 Project Team Beschrijving - Description Eerste versie van de Business Requirement Prepayment Première version du Business Requirement Prepayment Versie 2 van de Business Requirement Prepayment na integratie van de feedback aangeleverd door de Business Analisten en Subject Matter Experten van de Net User Interactions werkgroep V2.0 30/04/2013 Atrias MPP MIG6 Project Team 30/06/2013 Atrias MPP MIG6 Project Team Versie 3 voor consultatie V3.0 Atrias MPP MIG6 Project Team Versie 3.1 voor consultatie Atrias MPP MIG6 Project Team Versie 3.2 voor consultatie V3.1 28/02/2014 V3.2 31/07/2014 Version 2 du Business Requirement Prepayment 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 Version 3 pour consultation Version 3.1 pour consultation Version 3.2 pour consultation 1.2 Referenties – Références Referentie - Référence UMIG 6.0 - GE - XD - 02 – Introduction [1] Omschrijving - Description Document dat een algemene introductie geeft van de marktprocessen en de globale concepten die gebruikt worden in de verschillende processen. Contient une introduction générale aux processus de marché et sur les concepts globaux utilisés dans les différents processus. UMIG 6.0 – BR Preswitching [2] - ST - 03 – UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 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. 4/25 UMIG 6.0 - Structure Prepayment Referentie - Référence UMIG 6.0 – BR - ST - 04 – Ex-Ante Tests [3] Omschrijving - Description Matrix van de volledige ex-ante testen voor de verschillende Structuring aanvragen. Deze testen worden in de processus Initiate Request uitgevoerd. Matrice de l'ensemble des tests ex-ante effectués pour les différentes demandes Structuring. Ces tests sont effectuées dans le processus Initiate Request. UMIG 6.0 – BR - ST - 04 – Ex-Post Monitoring [4] Matrix van de volledige ex-post monitoring per module en per label: regels, impact op de markt en gevolgen. UMIG 6.0 – BR - ST - 03 – Handle Request [5] Beschrijving van het beheersproces van een Structuring aanvraag door de markt na de behandeling van het proces Initiate Request. Matrice de l'ensemble du monitoring ex-post effectué par module et par label : règles, impacts sur le marché et conséquences. 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 – Exchanged information [6] Matrix van alle berichten en gegevens die worden uitgewisseld in het kader van de verschillende Structuring aanvragen. UMIG 6.0 – BR - ST - 04 – Timings [7] Matrix van alle timingregels die gelden 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. Matrice de l'ensemble des règles de temps applicables dans le cadre des différentes demandes Structuring. UMIG 6.0 – BR – ST - 03 – Initiate Request [8] Beschrijving van het proces van aanmaak en eerste behandeling van een Structuring aanvraag door de markt. UMIG 6.0 – BR – ST - 02 – Structuring Process [9] Inleidend document inzake de Structuring marktprocessen: basisbeginselen, mapping MIG4 versus MIG6, definitie en toepassing van de verschillende processen. Document décrivant le processus de création et de premier traitement d'une demande Structuring par le marché Document d'introduction aux processus de marché Structuring : concepts de base, mapping MIG4 versus MIG6, définition et application des différents processus. UMIG 6.0 - GE - XD - 01 – Glossary [10] UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx Document waarin alle in de documentatie gebruikte begrippen worden beschreven die specifiek zijn aan de marktprocessen. Document qui décrit l'ensemble des termes, spécifiques aux processus de marché, utilisés dans la documentation. 5/25 UMIG 6.0 - Structure Prepayment 2 Context - Contexte 2.1 Scope Figure 1 - Activity Prepayment v1.0 2.2 Begrippen en definities – Concepts et définitions Het globaal Prepayment proces bestaat in feite uit 3 processen: Notify Payment for Prepayment: proces waarbij een kennisgeving van betaling wordt ontvangen door de Meter Point Administrator voor een Toegangspunt met geactiveerde voorafbetalingsfunctionaliteit en wordt overgemaakt aan de Balance Supplier die geregistreerd is als verantwoordelijke voor het Toegangspunt; Request Prepayment: proces waarbij een aanvraag wordt gelanceerd door de Balance Supplier belast met een Toegangspunt met geactiveerde voorafbetalingsfunctionaliteit en waarbij die aanvraag een eerste behandeling ondergaat; Handle Prepayment: proces waarbij de aanvraag een reeks subprocessen op gang brengt die specifiek zijn voor het betrokken type aanvraag. Le processus global de Prepayment s’articule autour de 3 processus : Notify Payment for Prepayment : processus dans lequel une notification de paiement est reçue par le Meter Point Administrator pour un Point d’Accès avec fonctionnalité prépaiement activée et transmise au Balance Supplier enregistré comme responsable du Point d’Accès ; Request Prepayment : processus dans lequel une demande est initiée par le Balance Supplier en charge d’un Point d’Accès avec fonctionnalité de prépaiement activée et durant lequel cette demande subit un premier traitement ; Handle Prepayement : processus dans lequel la demande génère une série de sous-processus spécifiques au type de la demande initiée. Le présent document développe plus en détails l’ensemble de ces processus. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 6/25 UMIG 6.0 - Structure Prepayment Het onderhavige document gaat nader in op die verschillende processen. Let op: de prepayment die in de MIG6 wordt vermeld heeft betrekking op de prepayment in het kader van de ODV en niet in het kader van de commerciële prepayment. Dit kan eventueel worden uitgewerkt in een latere versie van deze MIG. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 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. 7/25 UMIG 6.0 - Structure Prepayment 3 Notify Payment for Prepayment 3.1 Proces Definitie – Définition du Process Figure 2 - Use Case Notify Payment For Prepayment v1.0 Het proces Notify Payment For Prepayment speelt zich af tussen de Meter Point Administrator en de Balance Supplier die geregistreerd is als verantwoordelijke voor het Toegangspunt. Le processus Notify Payment For Prepayment se déroule entre le Meter Point Administrator et le Balance Supplier enregistré comme responsable du Point d’Accès. Hierbij wordt de Balance Supplier in kennis gesteld van de ontvangst van een betaling voor een bepaald Toegangspunt waarvoor de voorafbetalingsfunctionaliteit actief is. Il permet de notifier le Balance Supplier de la réception d’un paiement pour un Point d’Accès donné et pour lequel la fonctionnalité du prépaiement est active. Op het einde van dit proces kan de Balance Supplier een Prepayment aanvraag lanceren via het proces Request Prepayment (zie sectie 4). A l’issue de ce processus, le Balance Supplier pourra initier une demande de Prepayment via le processus Request Prepayment (voir section 4). UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 8/25 UMIG 6.0 - Structure Prepayment 3.2 Procesverloop – Déroulement de la procédure Figure 3 - Activity Notify Payment For Prepayment v1.0 3.3 Procesomschrijving – Description des procédures Startsignaal: De Meter Point Administrator heeft een betaling van de Payment Processing Agent ontvangen voor een Toegangspunt met geactiveerde voorafbetalingsfunctionaliteit. Est initié quand : Le Meter Point Administrator a reçu un paiement du Payment Processing Agent pour un Point d’Accès avec la fonctionnalité de prépaiement activée. Pre-requisites: Een klant heeft betaald voor herlading voor een Toegangspunt met voorafbetalingsfunctionaliteit via het platform van de Payment Processing Agent. De Payment Processing Agent heeft de herladingsinformatie doorgegeven aan de Meter Point Administrator die, alvorens het proces Notify Payment for Prepayment, op te starten, nagaat of die betaling relevant is rekening houdend met de geregistreerde situatie (Toegangspunt gekend, Toegangspunt met actieve voorafbetaling, ...). Zo ja, dan wordt het proces Notify Payment for Prepayment opgestart en wordt de Payment Pré-requis: Un client a payé une recharge pour un Point d’Accès avec fonctionnalité de prépaiement via la plateforme du Payment Processing Agent. Le Payment Processing Agent a transmis l’information de rechargement au Meter Point Administrator qui avant d’initier son process de Notify Payment for Prepayment, vérifiera que ce paiement est pertinent au sens de la situation enregistrée (Point d’Accès connu, Point d’Accès avec prépaiement actif, …). Si tel est le cas, le processus Notify Payment for Prepayment est initié et le Payment Processing Agent est UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 9/25 UMIG 6.0 - Structure Prepayment Processing Agent in kennis gesteld van het gevolg gegeven aan zijn bericht van herlading (acceptatie of verwerping van de betaling, communicatie van de actieve Balance Supplier op het herladen Toegangspunt bij acceptatie van de betaling). Een bijkomende vereiste voor iedere Prepayment aanvraag is dat er vooraf een voorafbetalingsfunctionaliteit is geactiveerd op het betrokken Toegangspunt dia de module Initiate Update Access, label Budget Meter Installation / Activation (zie referentiedocumenten [10, 6] en ook sectie 5.4.6). 3.4 Eindigt wanneer: De kennisgeving werd verstuurd naar de Balance Supplier die als actief is geregistreerd op het Toegangspunt waarvoor de Payment Processing Agent de herlading heeft ontvangen. Resultaat: De kennisgeving van de betaling is ontvangen door de Balance Supplier, die dan in zijn systemen de passende activiteiten kan opstarten. Verloop: Het proces verloopt als volgt: de Meter Point Administrator beheert de kennisgeving en stuurt ze naar de Balance Supplier belast met het betrokken Toegangspunt (Send Payment Notification), die ze ontvangt (Receive Payment Notification). notifié du traitement apporté à sa notification de rechargement (acceptation ou rejet du paiement, communication du Balance Supplier actif sur le Point d’Accès rechargé dans le cas où le paiement est accepté). A côté de cela, un prérequis à toute demande de Prepayment est d’avoir activé au préalable la fonctionnalité du prépaiement sur le Point d’Accès visé via le module Initiate Update Access, label Budget Meter Installation / Activation (voir documents de référence [10, 6] et également section 5.4.6). Se termine lorsque: La notification de paiement a été envoyée au Balance Supplier enregistré comme actif sur le Point d’Accès pour lequel la recharge a été reçue du Payment Processing Agent. Résultat: La notification de paiement est reçue du Balance Supplier qui peut alors démarrer dans ses systèmes les activités adéquates. Déroulement: Le processus se déroule comme suit : le Meter Point Administrator génère la notification et l’envoie au Balance Supplier en charge du Point d’Accès concerné (Send Payment Notification) qui la reçoit (Receive Payment Notification). Uitzonderingen / Eigenheden - Exceptions / Caractéristiques 3.4.1 Herlaadplatform van de Balance Supplier - Plateforme de recharge des Balance Supplier Het proces Notify Payment For Notification wordt maar opgestart wanneer een betaling verricht wordt via het platform van de Payment Processing Agent dat de Meter Point Adminisitrator verwittigt. De Balance Suppliers kunnen immers op termijn een eigen betalingsplatform ontwikkelen. In dat geval zal dit proces nooit gestart worden. Le processus Notify Payment For Notification n’est initié que lorsqu’un paiement est effectué via la plateforme du Payment Processing Agent qui en notifie le Meter Point Adminisitrator. En effet, les Balance Suppliers pourraient à terme développer leur propre plateforme de paiement dans quel cas, ce processus ne serait jamais déclenché. Merk ook op dat het hele proces tussen het platform van de Payment Processing Agent en de Meter Point Administrator niet wordt beschreven in het kader van MIG6, maar in het kader van het Payment Processing-project. A noter également que l’ensemble du processus entre la plateforme du Payment Processing Agent et le Meter Point Administrator ne sera pas décrit dans le cadre du MIG6 mais bien dans celui du projet Payment Processing. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 10/25 UMIG 6.0 - Structure Prepayment 4 Request Prepayment 4.1 Proces definitie – Définition du Process Figure 4 - Use Case Request Prepayment v1.0 Het proces Request Prepayment speelt zich af tussen de Meter Point Administrator (Beheerder van de Toegangspunten) en een Balance Supplier (de toegangshouder verantwoordelijk voor het Toegangspunt met de geactiveerde voorafbetalingsfunctionaliteit en die voor dit punt een voorafbetalingsaanvraag lanceert). Le processus Request Prepayment se déroule entre le Meter Point Administrator (Gestionnaire des Points d’accès) et un Balance Supplier (le détenteur d’accès en charge du Point d’Accès avec la fonctionnalité de prépaiement activée et initiant une demande de prépaiement pour ce Point). Het kan opgedeeld worden in drie hoofdstappen: Il peut être divisé en trois étapes principales : - Aanmaak en verzending van een aanvraag door een Balance Supplier; Ontvangst en eerste behandeling van de aanvraag door de Meter Point Administrator; Kennisgeving van de verwerping of acceptatie door de Meter Point Administrator aan de Balance Supplier. Na dit proces en als de gelanceerde aanvraag wordt aanvaard, loopt het globaal Prepayment proces verder en triggert het proces Handle Prepayment (zie sectie 5). UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx - Création et envoi d’une demande par un Balance Supplier; Réception et premier traitement de la demande par le Meter Point Administrator ; Notification du rejet ou de l’acceptation par le Meter Point Administrator au Balance Supplier. A l’issue de ce processus et si la demande initiée est acceptée, le processus global Prepayment se poursuivra et déclenchera le processus Handle Prepayment (voir 11/25 UMIG 6.0 - Structure Prepayment Als de aanvraag echter wordt verworpen, dan stopt de uitvoering en volgt geen enkele andere actie meer. 4.2 section 5). Si par contre la demande initiée est rejetée, l’exécution de la demande s’achève là et aucune autre action n’est entreprise. Procesverloop - Déroulement de la procédure Figure 5 - Activity Request Prepayment v1.0 UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 12/25 UMIG 6.0 - Structure Prepayment 4.3 Procesomschrijving- Description des procédures Startsignaal: Dit subproces wordt opgestart wanneer een Balance Supplier een nieuwe aanvraag lanceert om aan de markt een actie te vragen verbonden aan de voorafbetalingsfunctionaliteit: informatie over resterende krediet, herstel / onderbreking van voorafbetaling, preventieve waarschuwing, waarschuwing noodkrediet. Deze aanvraag wordt gematerialiseerd door verzending van een bericht ST-INT-1. Est initié quand : Ce sous-processus est initié dès qu’un Balance Supplier initie une nouvelle demande afin de demander au marché une action liée à la fonctionnalité de prépaiement : information de crédit restant, rétablissement / interruption du prépaiement, alarme préventive, alarme de crédit de secours. Cette demande est matérialisée par l’envoi d’un message ST-INT-1. Pre-requisites: Om een aanvraag te kunnen opstarten, moet de Balance Supplier toegang hebben tot het uitwisselingssysteem voor de markt en beschikken over de nodige en voldoende informatie om zijn bericht te kunnen aanmaken (bv. toegangspunt, gewenst type aanvraag). Een bijkomende vereiste voor iedere Prepayment aanvraag is dat er vooraf een voorafbetalingsfunctionaliteit is geactiveerd op het betrokken Toegangspunt dia de module Initiate Update Access, label Budget Meter Installation / Activation (zie referentiedocumenten [10, 6] en ook sectie 5.4.6). Pré-requis: Pour pouvoir initier une demande, le Balance Supplier doit avoir accès au système d’échange mis en place pour le marché et disposer des informations nécessaires et suffisantes pour pouvoir générer son message (p.ex. point d’accès, type de demande souhaitée). A côté de cela, un prérequis à toute demande de Prepayment est d’avoir activé au préalable la fonctionnalité du prépaiement sur le Point d’Accès visé via le module Initiate Update Access, label Budget Meter Installation / Activation (voir documents de référence [10, 6] et également section 5.4.6). Eindigt wanneer: de aanvraag een eerste behandeling heeft ondergaan en op basis daarvan hetzij verworpen, hetzij aanvaard is door de Meter Point Administrator. Bij verwerping wordt een bericht ST-INT-2 gestuurd naar de initiator van de aanvraag om hem in kennis te stellen van de verwerping van zijn aanvraag door de markt. Bij acceptatie wordt naar de initiator van de aanvraag een bericht ST-INT-3 gestuurd om hem in kennis te stellen van de aanvaarding van zijn aanvraag en registratie ervan in het toegangsregister. Se termine lorsque: La demande a subi un premier traitement à l’issue duquel, elle est soit refusée, soit acceptée par le Meter Point Administrator. Dans le cas d’un refus, un message ST-INT-2 est envoyé à la partie initiatrice de la demande pour la notifier du rejet par le marché de sa demande. Dans le cas d’une acceptation, un message ST-INT-3 est envoyé à la partie initiatrice de la demande pour la notifier de l’acceptation et de l’enregistrement de sa demande dans le registre d’accès. Resultaat: De aanvraag van de initiator wordt aanvaard en geregistreerd. Of de aanvraag wordt verworpen en dus niet geregistreerd, en de partij in kennis gesteld. Résultat: La demande de la partie initiatrice est soit acceptée et enregistrée. Soit la demande n’est pas enregistrée, est refusée et la partie avisée. Verloop: Het proces verloopt als volgt: Déroulement: Le processus se déroule comme suit : - De Balance Supplier lanceert de aanvraag (Create Request) op basis van de gegevens verzameld via de verschillende kanalen waarover hij beschikt (preswitching, contact klant, …). UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx - Le Balance Supplier initie la demande (Create Request) grâce aux informations récoltées via les différents canaux dont il dispose (preswitching, contact client, …). 13/25 UMIG 6.0 - Structure Prepayment - Vervolgens stuurt de Balance Supplier een bericht ST-INT-1 naar de Meter Point Administrator (Send Request) - Le Balance Supplier envoie après cela un message ST-INT-1 vers le Meter Point Administrator (Send Request) - De Meter Point Administrator ontvangt het bericht en onderwerpt het aan een reeks ex-ante tests (Receive Request, Test Request). Al deze tests zijn opgenomen in referentiedocument [3]. - Le Meter Point Administrator reçoit le message et réalise une série de tests ex-ante dessus (Receive Request, Test Request). L’ensemble de ces tests est repris dans le document de référence [3]. - Afhankelijk van het resultaat van de op de aanvraag verrichte tests, zijn er twee mogelijkheden: - En fonction du résultat des tests effectués sur la demande, deux options sont possibles : o De aanvraag wordt verworpen omdat ze faalt voor een of meerdere tests van een categorie: in welk geval een verwerpingbericht ST-INT-2 wordt verstuurd naar de Balance Supplier die de aanvraag heeft gelanceerd (Send Response). Het bericht wordt door hem ontvangen (Receive Negative Response), het proces Request Prepayment eindigt en de behandeling van de aanvraag stopt hier. Het bericht bevat een of meer verwerpingscodes, eventueel met opgave van de reden van de verwerping. Deze verwerpingscodes en redenen worden beschreven in referentiedocument [3]. o La demande est rejetée car elle échoue à un ou plusieurs tests d’une catégorie : dans quel cas un message de rejet ST-INT-2 est envoyé au Balance Supplier à l’initiative de la demande (Send Response). Le message est reçu par celui-ci (Receive Negative Response), le processus Request Prepayment s’achève et le traitement de la demande se termine ici. Le message contient un ou plusieurs codes de rejet accompagnés éventuellement d’une indication sur la raison de ce code de rejet. Ces codes de rejet et leurs raisons sont repris dans le document de référence [3]. o De aanvraag wordt aanvaard, in welk geval de wijzigingen die voortvloeien uit de acceptatie van de aanvraag geregistreerd worden in het Toegangsregister (Handle Data Changes). Er wordt naar de Balance Supplier een acceptatiebericht ST-INT-3 gestuurd (Send Response). Het bericht wordt door hem ontvangen (Receive Response); hier eindigt het proces Request Prepayment en het proces Handle Prepayment wordt op gang gebracht. o La demande est acceptée, dans quel cas les changements induits par l’acceptation de la demande sont enregistrés dans le Registre d’Accès (Handle Data Changes). Un message d’acceptation ST-INT-3 est envoyé au Balance Supplier (Send Response). Le message est reçu par celui-ci (Receive Response), le processus Request Prepayment se termine ici et le processus Handle Prepayment est déclenché. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 14/25 UMIG 6.0 - Structure Prepayment 4.4 Uitzonderingen / Eigenheden - Exceptions / Caractéristiques 4.4.1 Flag Request Unlock De notie “lock” werd voorgesteld in de MIG6 Fundamentals: "De DNB kan een toegangspunt tijdelijk blokkeren, dit wil zeggen de behandeling van inkomende transacties verhinderen". La notion de lock a été introduite dans les Fondamentaux MIG6 : « Le GRD a la possibilité de bloquer temporairement un point d’accès, c’est-à-dire d’empêcher le traitement de toutes les transactions entrantes ». Voor andere types aanvragen die ressorteren onder Structuring kan er gebruikgemaakt worden van een flag "Request Unlock", waarbij de verwerking van de aanvraag tot "Unlock" een termijn van maximaal 2 werkdagen in beslag mag nemen, maar Prepayment-aanvragen hebben een prioritair karakter en moeten zo snel mogelijk uitgevoerd worden. Derhalve mag er geen Lock geplaatst worden op het Toegangspunt van de aanvraag. Een Prepayment-aanvraag zonder “Request Unlock”, op een gelockt Toegangspunt, zal niet kunnen verworpen worden. Etant donné le caractère prioritaire des demandes de Prepayment, on comprend que contrairement aux autres types de demande Structuring pour lesquelles le flag « Request Unlock » est prévu et pour lesquelles un délai de 2 jours ouvrables maximum peut être associé au traitement de la demande d’ « unlock », les demandes Prepayment doivent, elles, être réalisées le plus vite possible et ne peuvent dès lors pas être affectées par la présence d’un lock sur le Point d’Accès de la demande. Une demande de prepayment sans « Request Unlock », faite sur un Point d’Accès locké, ne pourra pas être refusée. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 15/25 UMIG 6.0 - Structure Prepayment 5 Handle Prepayment 5.1 Proces definitie – Définition du Process Figure 6 - Use Case Handle Prepayment v1.0 Het proces Handle Prepayment wordt beheerd door de Meter Point Administrator en maakt het mogelijk alle activiteiten te starten die verband houden met de verwerking van de verschillende types Prepayment-aanvragen. Le processus Handle Prepayment est géré par le Meter Point Administrator et permet d’initier toutes les activités liées au traitement du type de la demande de Prepayment. Zoals geïllustreerd in sectie 2.1 volgt het proces Handle Prepayment altijd op het proces Request Prepayment waarin de Meter Point Administrator de ontvangen aanvraag al een eerste keer, min of meer generiek, verwerkt. Comme illustré dans la section 2.1, le processus Handle Prepayment fait toujours suite au processus de Request Prepayment dans lequel le Meter Point Administrator effectue un premier traitement plus ou moins générique sur la demande entrante. Na deze eerste verwerking heeft de Meter Point Administrator alle restactiviteiten van de Prepayment-aanvraag verwerkt en is het globale proces van de Prepayment voltooid. A l’issue de ce traitement, le Meter Point Administrator a réalisé l’ensemble des activités résiduelles de la demande de Prepayment et le processus global de Prepayment s’achève. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 16/25 UMIG 6.0 - Structure Prepayment 5.2 Procesverloop – Déroulement de la procédure Figure 7 - Activity Handle Prepayment v1.0 UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 17/25 UMIG 6.0 - Structure Prepayment 5.3 Procesomschrijving – Description des procédures Startsignaal: De Meter Point Administrator heeft een Prepayment-aanvraag ontvangen en aanvaard. Est initié quand : Une demande de Prepayment a été reçue et acceptée par le Meter Point Administrator. Pre-requisites: De Prepayment-aanvraag is aanvaard en geregistreerd in het Toegangsregister. Pré-requis: La demande de Prepayment a été acceptée et enregistrée dans le Registre d’Accès. Eindigt wanneer: Alle activiteiten die verband houden met het type Prepayment-aanvraag, zijn uitgevoerd en, indien vereist, is de Balance Supplier ervan op de hoogte gebracht dat deze activiteiten correct zijn uitgevoerd. Se termine lorsque: L’ensemble des activités liées au type de la demande de Prepayment a été réalisé et si requis, le Balance Supplier est notifié de la bonne réalisation de ces activités. Resultaat: Het gevolg van de Prepayment-aanvraag wordt overeenstemming met het type Prepayment-aanvraag. Résultat: L’effet de la demande de Prepayment est appliqué conformément au type de la demande de Prepayment. Déroulement: Le processus se déroule comme suit le Meter Point Administrator réalise l’ensemble des activités liées au type de la demande de Prepayment (Handle Prepayment by MPA). Dans cette activié, le Meter Point Administrator communique au Meter Operator les besoins liés au type de la demande (voir section 5.4). Lorsque le Meter Operator a réalisé ces actions, il le communique au Meter Point Administrator qui en fonction du type de la demande, enverra ou non un message « Prepayment Request Handled » (Send Notification Prepayment Handled) qui signifiera au Balance Supplier la bonne exécution de sa demande. Le Balance Supplier reçoit ce message (Receive Notification Prepayment Handled) et le processus s’achève. 5.4 uitgevoerd in Verloop: Het proces verloopt als volgt: de Meter Point Administrator realiseert alle activiteiten die verband houden met het type Prepayment)aanvraag (Handle Prepayment by MPA). Bij deze activiteit brengt de Meter Point Administrator de Meter Operator op de hoogte van de behoeften in verband met het type aanvraag (zie punt 5.4). Als de Meter Operator deze acties heeft uitgevoerd, deelt hij dit mee aan de Meter Point Administrator, die afhankelijk van het type aanvraag, al of niet een bericht "Prepayment Request Handled" (Send Notification Prepayment Handled) stuurt, om de Balance Supplier op de hoogte te brengen van de correcte uitvoering van zijn aanvraag. De Balance Supplier ontvangt dit bericht (Receive Notification Prepayment Handled) en het proces wordt voltooid. Uitzonderingen / Eigenheden – Exceptions/Caratéristiques 5.4.1 Aanvraag type Balance Notification - Demande du type Balance Notification De Prepayment-aanvragen van het type Balance Notification zijn louter kennisgevingen die dagelijks door de Balance Supplier verstuurd worden wanneer de voorafbetalingsfunctie geactiveerd wordt. Les demandes Prepayment de Balance Notification constituent de pures notification envoyées par le Balance Supplier quotidiennement lorsque la fonctionnalité du prépaiement est activée. Deze kennisgevingen vermelden het resterende krediet dat is berekend op basis van het gemiddelde dagelijkse verbruik en de daaraan Ces notifications indiquent le crédit restant calculé au moyen des consommations quotidiennes et du gridfee associé. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 18/25 UMIG 6.0 - Structure Prepayment gekoppelde gridfee. Deze kennisgevingen worden meegedeeld aan de klant, zodat deze de evolutie van zijn krediet kan volgen en gepaste maatregelen kan nemen om te voorkomen dat zijn Balance Supplier andere types van Prepaymentaanvragen start. Ces notifications seront communiquées au client afin que ce dernier puisse suivre l’évolution de son crédit et prendre les actions adéquates pour éviter l’initiation par son Balance Supplier d’autres types de demandes de Prepayment. Belangrijk om weten is dat er voor dergelijke aanvragen, geen bericht "Prepayment Request Handled" zal worden verstuurd door de Meter Point Administrator. A noter que pour de telles demandes, il n’y aura pas de message « Prepayment Request Handled » envoyé par le Meter Point Administrator. 5.4.2 Aanvragen type Herstel / Onderbreking voorafbetaling - Demandes du type Rétablissement / Interruption du prépaiement Er zijn hier twee mogelijke situaties: de aanvraag is afkomstig van ofwel een commerciële Balance Supplier ofwel een sociale Balance Supplier 5.4.2.1 On distingue deux situations : la demande provient d’un Balance Supplier commercial ou d’un Balance Supplier social. Aanvragen afkomstig van een commerciële Balance Supplier – Demandes issues d’un Balance Supplier commercial Prepayment-aanvragen tot herstel (label Prepayment Re-establishment) en tot onderbreking (label Prepayment Interruption) die afkomstig zijn van commerciële leveranciers, hebben een rechtstreekse invloed op de status die bekend is op de markt. Deze aanvragen kunnen slechts geïnitieerd worden door de Balance Supplier die bevoegd is voor dat toegangspunt en alleen voor toegangspunten waarvoor de voorafbetalingsfunctie al geactiveerd was via een aanvraag Initiate Update Access. Als de Meter Point Administrator een aanvraag tot onderbreking verwerkt, stuurt hij deze door naar de Meter Operator, die de voorafbetalingsfunctie en tegelijkertijd daarmee de energielevering - met onmiddellijke ingang en tot nader order onderbreekt. Deze actie heeft concreet tot gevolg dat de fysieke status van de prepayment omschakelt van actief naar inactief. Als de Meter Point Administrator vervolgens een aanvraag tot herstel verwerkt, maakt hij deze over aan de Meter Operator, die de levering herstelt: de fysieke status van de prepayment verandert dan van inactief naar actief. De onderstaande tabel illustreert de verschillende situaties die zich kunnen voordoen. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx Les demandes Prepayment de rétablissement (label Prepayment Reestablishment) et d’interruption (label Prepayment Interruption) provenant de fournisseurs commerciaux ont un effet direct sur les statuts connus du marché. Ces demandes ne peuvent être initiées que par le Balance Supplier en charge du Point d’accès et que pour des Points d’Accès avec la fonctionnalité du prépaiement activée au préalable via une demande Initiate Update Access. En effet, lorsqu’une demande d’interruption est traitée par le Meter Point Administrator, celui-ci la transmet au Meter Operator qui va alors interrompre jusqu’à nouvel ordre la fonctionnalité de prépaiement et avec cela, la fourniture d’énergie. Cette action se traduit concrètement par un basculement du statut physique du prépaiement qui passe d’actif à inactif. Lorsqu’une demande de rétablissement est traitée par le Meter Point Administrator, celui-ci la transmet au Meter Operator qui va alors rétablir la fourniture : passage du statut physique du prépaiement d’inactif à actif. Le tableau ci-dessous illustre les différentes situations pouvant apparaître. 19/25 UMIG 6.0 - Structure Prepayment Fysieke Status / Statut physique Fysieke Status Prepayment / Statut Physique Prépaiement Contractuele Status / Statut contractuel Betekenis / Signification ACTIEVE / ACTIF ACTIEVE / ACTIF ACTIEVE / ACTIF Toegangspunt met lopende prepayment Point d'Accès avec prépaiement en cours ACTIEVE / ACTIF INACTIEVE / INACTIF ACTIEVE / ACTIF Toegangspunt met onderbroken prepayment Point d'Accès avec prépaiement interrompu ACTIEVE / ACTIF N.A ACTIEVE / ACTIF Actief Toegangspunt zonder prepayment Point d'Accès actif mais sans prépaiement Om de status van de voorafbetalingsfunctie aan te geven, wordt gebruikgemaakt van meerdere velden in de Technical Master Data om de aanwezigheid van de budgetmeter en type meter te bepalen. Als in de Technical Master Data is opgegeven dat er een budgetmeter geïnstalleerd is en als de meter van het type "Smart" is, moet voor de markt duidelijk zijn dat de voorafbetalingsfunctie geactiveerd is. In geval van een gevraagde onderbreking blijven deze waarden onveranderd en verandert alleen de fysieke status van prepayment, zoals aangegeven in de tabel. Derhalve zal het veld Budgetmeter slechts worden meegedeeld aan de partijen die actief zijn op een toegangspunt (Preswitching FULL). Pour identifier l’état de la fonctionnalité prépaiement, plusieurs champs des Master Data techniques seront exploités afin de déterminer la présence du compteur à budget sur l’installation et le type de compteur. Si dans les Master Data techniques il est indiqué qu’un compteur à budget est installé et que le compteur est du type « Smart », le marché comprendra que la fonctionnalité de prépaiement est activée. A noter que lorsqu’une interruption est demandée, ces valeurs resteront inchangées et comme illustré sur le tableau, seul le statut physique du prépaiement évoluera. Aussi, le champ compteur à budget ne sera communiqué qu’aux parties actives sur un Point d’Accès (Preswitching FULL). Belangrijk om weten is dat er na de behandeling van deze aanvragen door de Meter Operator geen bericht "Technical Master Data" wordt gestuurd naar de verantwoordelijke Balance Supplier (de actualisering van de betreffende velden zal niettemin zichtbaar zijn in Preswitching zoals hierboven uitgelegd), maar wel een bericht "Prepayment Request Handled". A noter que pour de telles demandes, et après exécution de celles-ci par le Meter Operator, il n’y aura pas de message de Master Data Techniques envoyé au Balance Supplier responsable (la mise à jour des champs adéquats sera néanmoins visible dans le Preswitching comme expliqué ci-dessus) mais bien un message de « Prepayment Request Handled ». UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 20/25 UMIG 6.0 - Structure Prepayment 5.4.2.2 Aanvragen afkomstig van een sociale Balance Supplier - Demandes issues d’un Balance Supplier social Prepayment-aanvragen tot herstel (label Prepayment Re-establishment) en onderbreking (label Prepayment Interruption) die afkomstig zijn van sociale leveranciers hebben als direct gevolg dat er een stroombeperking op het toegangspunt geactiveerd of opgeheven wordt. Deze aanvragen kunnen slechts geïnitieerd worden door de sociale Balance Supplier die bevoegd is voor dat toegangspunt en alleen voor toegangspunten waarvoor de voorafbetalingsfunctie al geactiveerd was via een aanvraag Initiate Update Access. Les demandes Prepayment de rétablissement (label Prepayment Reestablishment) et d’interruption (label Prepayment Interruption) provenant de fournisseurs sociaux ont comme effet direct un enlèvement ou un placement d’une limitation du courant sur le Point d’Accès visé. Ces demandes ne peuvent être initiées que par le Balance Supplier sociaux en charge du Point d’accès et que pour des Points d’Accès avec la fonctionnalité du prépaiement activée au préalable via une demande Initiate Update Access. Als de Meter Point Administrator een onderbrekingsaanvraag verwerkt, stuurt hij deze door naar de Meter Operator, die daarop de op het toegangspunt ter beschikking gestelde stroom gaat beperken. Na de beperking wordt er nog 10 Ampère stroom beschikbaar gesteld. En effet, lorsqu’une demande d’interruption est traitée par le Meter Point Administrator, celui-ci la transmet au Meter Operator qui va alors placer une limitation sur le courant mis à disposition sur le Point d’Accès. Le courant après limitation sera de 10 Ampères. Als de Meter Point Administrator vervolgens een aanvraag tot herstel verwerkt, maakt hij deze over aan de Meter Operator, die weer de normale waarde van de stroom herstelt (dit wil zeggen onbeperkt). Lorsqu’une demande de rétablissement est traitée par le Meter Point Administrator, celui-ci la transmet au Meter Operator qui va alors rétablir le courant à sa valeur normale (c’est-à-dire non limitée). Belangrijk om weten is dat er na de behandeling van deze aanvragen door de Meter Operator geen bericht "Technical Master Data" wordt gestuurd naar de verantwoordelijke Balance Supplier maar wel een bericht "Prepayment Request Handled". A noter que pour de telles demandes, et après exécution de celles-ci par le Meter Operator, il n’y aura pas de message de Master Data Techniques envoyé au Balance Supplier responsable mais bien un message de « Prepayment Request Handled ». 5.4.3 Aanvragen type Preventief alarm - Demandes du type Alarme préventive De Prepayment-aanvragen tot preventief alarm (label Preventive Alarm) houden geen gevolgen in voor de statussen die besproken werden in de vorige sectie. Deze aanvragen hebben een informatief karakter en komen tot stand wanneer de Balance Supplier zich realiseert dat het resterende krediet van een toegangspunt een in overleg met de regulatoren te bepalen drempel nadert. Les demandes Prepayment d’alarme préventive (label Preventive Alarm) n’ont pas d’impact sur les statuts repris dans la section précédente. Ces demandes ont un caractère informatif et sont réalisées lorsque le Balance Supplier se rend compte que le crédit restant d’un Point d’Accès avec prépaiement s’approche d’un seuil à déterminer avec les régulateurs. Met dit alarm kan de klant erop gewezen worden dat hij het hulpkrediet nadert en dus dat hij zijn voorafbetaling zal moeten bijladen indien hij niet wenst dat zijn levering onderbroken wordt. Cette alarme permet de conscientiser le client de son rapprochement du crédit de secours et par conséquent du fait qu’il devrait aller recharger s’il ne souhaite pas voir sa fonctionnalité de prépaiement interrompue. Als een dergelijke aanvraag aanvaard wordt, stuurt de Meter Point Administrator deze door naar de Meter Operator. Deze moet dan via zijn back-ends een alarm genereren op de meter. Dit alarm kan een pieptoon zijn of een lichtsignaal of een bericht op de meter. De gebruikte Lorsqu’une telle demande est acceptée, le Meter Point Administrator la transmet au Meter Operator. Celui-ci doit alors via ses back-ends générer une alarme sur le compteur. Cette alarme pourrait être un bip ou une lumière ou un message sur le compteur. Dans tous les cas, la UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 21/25 UMIG 6.0 - Structure Prepayment technologie moet nog worden bepaald door de distributienetbeheerder en, afhankelijk van de genomen beslissingen, kunnen de Balance Suppliers op termijn zorgen voor een direct kanaal naar de klant (zonder tussenkomst van het Clearing House) 5.4.4 Nadat dergelijke aanvragen zijn uitgevoerd door de Meter Operator wordt er een bericht "Prepayment Request Handled" gestuurd naar de Balance Supplier om hem te laten weten dat zijn aanvraag correct is uitgevoerd. technologie reste à être définie par les Gestionnaire du Réseau de Distribution et, suivant les décisions prises, les Balance Suppliers pourraient à terme mettre en place un canal direct vers le client (dans ce cas, il n’y aurait pas de transit par le Clearing House) A noter que pour de telles demandes, et après exécution de celles-ci par le Meter Operator, un message de « Prepayment Request Handled » sera envoyé au Balance Supplier pour lui confirmer la bonne exécution de sa demande. Aanvragen type Alarm noodkrediet - Demandes du type Alarme de crédit de secours De Prepayment-aanvragen tot hulpkredietalarm (label Rescue Credit Alarm) houden geen gevolgen in voor de statussen die gekend zijn in de systemen en die besproken werden in de vorige sectie. Deze aanvragen hebben een informatief karakter en komen tot stand wanneer de Balance Supplier zich realiseert dat het resterende krediet van een toegangspunt een in overleg met de regulatoren te bepalen drempel nadert. Les demandes Prepayment d’alarme de crédit de secours (label Rescue Credit Alarm) n’ont pas d’impact sur les statuts connus dans les systèmes et repris dans la section précédente. Ces demandes ont un caractère informatif et sont réalisées lorsque le Balance Supplier 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. Met dit alarm kan de klant erop opmerkzaam gemaakt worden dat er verbreking dreigt indien hij niet bijlaadt. Cette alarme permet de conscientiser le client de l’imminence d’une déconnexion s’il ne pratique aucune recharge. Als een dergelijke aanvraag aanvaard wordt, stuurt de Meter Point Administrator deze door naar de Meter Operator. Deze moet dan via zijn back-ends een alarm genereren op de meter, wat leidt tot een verbreking van het toegangspunt (levering onderbroken of in bepaalde gevallen beperking van de stroom tot 10 A), maar met mogelijkheid tot hernieuwde ingebruikneming door een actie van de netwerkgebruiker. De actie van de Meter Operator heeft tot gevolg dat de energie levering op het terrein tijdelijk wordt onderbroken zonder dat de waarden statussen veranderd worden. En effet, lorsqu’une telle demande est acceptée, le Meter Point Administrator la transmet au Meter Operator. Celui-ci doit alors via ses back-ends générer une alarme sur le compteur ce qui aura comme conséquence la déconnexion du Point d’Accès (livraison sur le terrain interrompue ou dans certains cas, limitation du courant à 10 A) mais tout en autorisant la remise en service via une action de l’Utilisateur du Réseau. L’action du Meter Operator a donc pour effet d’interrompre temporairement le fourniture d’énergie sur le terrain, sans modifier pour autant la situation des statuts. Nadat dergelijke aanvragen zijn uitgevoerd door de Meter Operator wordt er een bericht "Prepayment Request Handled" gestuurd naar de Balance Supplier om hem te laten weten dat zijn aanvraag correct is uitgevoerd. A noter que pour de telles demandes, et après exécution de celles-ci par le Meter Operator, un message de « Prepayment Request Handled » sera envoyé au Balance Supplier pour lui confirmer la bonne exécution de sa demande. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 22/25 UMIG 6.0 - Structure Prepayment 5.4.5 Chronologie van de Prepayment aanvragen en verantwoordelijkheden - Chronologie des demandes de Prepayment et responsabilités De verschillende types Prepayment-aanvragen worden verzonden in chronologische volgorde. Les différents types de demande de Prepayment prévus respectent un ordre chronologique pour leur envoi. Op een toegangspunt waarop de voorafbetalingsfunctie geactiveerd is, zal het krediet - in de veronderstelling dat de klant geen herlading uitvoert - op een bepaald moment een zekere drempel bereiken. Op dat moment kan de Balance Supplier een Prepayment-aanvraag met het label Preventive Alarm lanceren. En effet, soit un Point d’Accès avec fonctionnalité de prépaiement active, à supposer que le client ne pratique aucune recharge, le crédit que celui-ci avait rechargé se rapprochera à un moment donné d’un certain seuil. A ce moment, le Balance Supplier pourra initier une demande Prepayment avec label Preventive Alarm. In de veronderstelling dat deze klant nog altijd geen herlading uitvoert, zal zijn krediet op een gegeven moment de aan het hulpkrediet gekoppelde drempel bereiken. Op dat moment kan de Balance Supplier een Prepayment-aanvraag met het label Rescue Credit Alarm lanceren. Supposons toujours que ce même client n’ait toujours pas pratiqué de recharge et que son crédit atteint désormais un certain seuil correspondant au crédit de secours. A ce moment, le Balance Supplier pourra initier une demande Prepayment avec label Rescue Credit Alarm. Indien de klant ook na dit tweede alarm niet overgaat tot herlading, kan de Balance Supplier een Prepayment-aanvraag met het label Prepayment Interruption lanceren. Deze zal tot gevolg hebben dat de energielevering aan deze klant onderbroken wordt (fysieke status van prepayment wordt inactief). Aussi, si à nouveau, suivant cette deuxième alarme, le client ne pratique toujours aucune recharge, le Balance Supplier initiera une demande Prepayment avec label Prepayment Interruption qui aura pour effet d’interrompre la fourniture d’énergie à ce client (statut physique du prépaiement inactif). Le Balance Supplier, suite à l’interruption du prépaiement, ne demandera de rétablir celui-ci (demande Prepayment label Re-establish Prepayment) que lorsque le client aura pratiqué une recharge de son crédit, recharge suffisante que pour pouvoir rétablir la fourniture du prépaiement. On constate donc qu’à chaque fois, c’est le Balance Supplier en charge du Point d’Accès qui est à l’initiative des demandes. Pour aller plus loin, c’est au Balance Supplier que revient la responsabilité d’envoi de ces messages et de leurs contenus. Ces envois devront par ailleurs être réalisés conformément à la législation en vigueur (p.ex. timings). Na de onderbreking van voorafbetaling zal de Balance Supplier pas om een herstel ervan (Prepayment-aanvraag met het label Re-establish Prepayment) vragen, als de klant zijn krediet herladen heeft voor een bedrag dat volstaat om de levering van voorafbetaling te kunnen herstellen. Het is dus altijd de voor het toegangspunt bevoegde Balance Supplier die het initiatief neemt tot de lancering van de aanvragen. Om verder te gaan, valt de verzending van deze berichten en hun inhoud onder de verantwoordelijkheid van de Balance Supplier. Deze verzendingen moeten daarenboven gerealiseerd worden conform de wetgeving die van kracht is (bijv. timings) UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 23/25 UMIG 6.0 - Structure Prepayment 5.4.6 (Des)Activering van de voorafbetalingsfunctionaliteit – (Dés)Activation de la fonctionnalité du prépaiement De voorafbetalingsfunctie wordt geactiveerd via de module Initiate Update Access met het label Budget Meter Installation / Activation. We wijzen erop dat voorafbetaling een functie is die alleen wordt aangeboden op slimme meters. La fonctionnalité du prépaiement s’active via le module Initiate Update Access avec le label Budget Meter Installation / Activation. A noter que le prépaiement n’est une fonctionnalité offerte que pour les compteurs intelligents. Als deze functie geactiveerd is, geeft het veld Budgetmeter aan dat er een budgetmeter geactiveerd is en blijft de status van de levering actief. Faisant suite à cette activation, le champ compteur à budget indique qu’un compteur à budget est activé et le statut de la fourniture reste actif. Concreet betekent dit dat de activering van de voorafbetalingsfunctie, gezien het hierboven opgegeven chronologisch verloop, slechts aanleiding kan geven tot 2 types Prepayment-aanvragen: - Preventive Alarm - Balance Notification Cela signifie concrètement que faisant suite à une activation de prépaiement, il ne peut, étant donné la chronologie définie plus haut, n’y avoir que 2 types de demande de Prepayment en premier lieu : - Preventive Alarm - Balance Notification La fonctionnalité du prepayment peut être désactivée de deux façons: De voorafbetalingsfunctie kan op 2 manieren gedeactiveerd worden: - Ofwel wenst de Balance Supplier belast met een Toegangspunt met geactiveerde voorafbetalingsfunctionaliteit deze functionaliteit te deactiveren in welk geval hij een een aanvraag Initiate Update Access de Budget Meter Desactivation lanceert - Soit le Balance Supplier en charge du Point d’Accès avec fonctionnalité du prépaiement souhaite désactiver cette fonctionnalité dans quel cas il initiera une demande d’Initiate Update Access de Budget Meter Desactivation ; - Ofwel op de effectieve datum waarop een Start Acces of Initiate Local Production is geaccepteerd op het Toegangspunt (zie referentiedocument [5]). - Soit à la date effective d’un Start Access ou Initiate Local Production ayant été accepté sur ce Point d’Accès (voir document de référence [5]). 5.4.7 Weergave van de voorafbetaling in de Preswitching - Affichage du prépaiement dans le Preswitching Gezien het delicate karakter van de Prepayment, mag het instrument Preswitching LIGHT (zie referentiedocument [2]) niet aangeven of de voorafbetalingsfunctie geactiveerd is op een toegangspunt. Dat wordt verzekerd door de velden Budgetmeter en fysieke status van prepayment slechts weer te geven in Preswitching FULL, wat geen probleem met de vertrouwelijkheid met zich brengt, aangezien de enige Balance Suppliers die daar toegang toe hebben, degene zijn die geregistreerd zijn als verantwoordelijk voor de betreffende toegangspunten. UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx Etant donné le caractère délicat du Prepayment, il ne faut pas que l’outil du Preswitching LIGHT (voir document de référence [2]) soit un indicateur de la présence de la fonctionnalité du prépaiement sur un Point d’Accès. Ce besoin est rempli en n’affichant le champ compteur à budget ainsi que le statut physique du prépaiement que dans le Preswitching FULL, catégorie de Preswitching pour laquelle il n’y a aucun problème de confidentialité puisque les seuls Balance Suppliers y ayant accès sont ceux enregistrés comme responsables sur les Points d’Accès concernés. 24/25 UMIG 6.0 - Structure Prepayment 6 Tabellen & Indexen – Tables & Indexes 6.1 Begrippenlijst – Glossaire Zie document UMIG 6.0 - GE - XD - 01 - Glossary 6.2 Voir le document UMIG 6.0 - GE - XD - 01 - Glossary Table of Figures Figure 1 - Activity Prepayment v1.0 ..................................................................................................................................................................................................................... 6 Figure 2 - Use Case Notify Payment For Prepayment v1.0 ................................................................................................................................................................................. 8 Figure 3 - Activity Notify Payment For Prepayment v1.0 ...................................................................................................................................................................................... 9 Figure 4 - Use Case Request Prepayment v1.0................................................................................................................................................................................................. 11 Figure 5 - Activity Request Prepayment v1.0 ..................................................................................................................................................................................................... 12 Figure 6 - Use Case Handle Prepayment v1.0 .................................................................................................................................................................................................. 16 Figure 7 - Activity Handle Prepayment v1.0 ....................................................................................................................................................................................................... 17 UMIG 6.0 - BR - ST - 03 - Prepayment v3.2.docx 25/25
© Copyright 2024 ExpyDoc
