Adresa ACUE Anexa Nr. 252/23.05.2022

[bogdannedelcu]

1. După încheierea unui contract în platformă (cererile de schimb de furnizor, schimb de piață, activare loc nou de consum, reactivare loc de consum existent), furnizorul (FZ) are obligația de a transmite în termen de 24 de ore informația în POSF printr-un mesaj "contractsignbysupplier". POSF va transmite fluxul ContractSignedBySupplier cu datele contractului către operatortul de rețea (OR)?

În aceste condiții, se impun umătoarele clarificări:  POSF este canalul unic de comunicare pe care atât FZ cât și OR trebuie să-l utilizeze pentru operarea cererilor de schimbare furnizor?  FZ și OR pot utiliza canalele existente de comunicare (automatizări realizate între platformele proprii de-a lungul timpului în linie cu legislația în vigoare), cu condiția de a notifica și POSF pentru actualizarea datelor?

Context:  În încercarea de a clarifica dacă POSF este canalul unic de comunicare pentru schimbarea de furnizor, răspunsul furnizat a fost că POSF nu exclude alte canale de comunicare . În același timp, au fost și răspunsuri care au indicat că FZ și OR nu vor comunica direct, în cazul în care platforma POSF este indisponibilă;  În același timp, nu s-au furnizat scheme de proces pentru schimburile de date între actori: OR, FZ, POSF astfel încât să existe o concluzie clară asupra procesului viitor;  Tot în cadrul discuțiilor s-a menționat că, într-o primă fază, POSF strânge datele pentru raportare, dar nu în mod specific pentru platforma unică la nivel național pentru schimbarea furnizorului . Totuși, acest lucru este oarecum contrazis de tipologia mesajelor prevăzute pentru schimbul de date între POSF/FZ/OR;  Nu în ultimul rând, nu este clar ce se întâmplă în situația în care un OR primește o solicitare atât dinspre FZ , cât și din POSF. Care cerere se procesează în această situație?

[bogdannedelcu]

Ref:  POSF este canalul unic de comunicare

POSF este canalul unic de comunicare pentru platforma pe care se realizeaza schimbarea furnizorului si baza de date unica a informatiilor despre contractele de furnizare incheiate. Operarea schimbarilor si contractarilor pentru schimbarea furnizorului in orice situatie se face prin intermediul platformei, chiar daca contractarea s-a realizat initial in afara acesteia.

Ref  FZ și OR pot utiliza canalele existente de comunicare

FZ si OR pot utiliza orice canal existent de comunicare care nu are legătură cu schimbarea furnizorului din POSF și atât timp cât în POSF respectă regulile stabilite prin Regulament. POSF transmite partilor (furnizori, operatori de retea, client) notificarile si documentele si nu invers. Fiecare parte isi realizeaza atributiile potrivit functiunilor POSF stabilite de regulament, conform notificarilor primite de la POSF.

[bogdannedelcu]

Ref nu exclude alte canale de comunicare

Pentru orice alte comunicari decat cele legate de contractarea furnizarii. Procesul de contractare si schimbare prin POSF este automat.

[bogdannedelcu]

Ref  Nu în ultimul rând, nu este clar ce se întâmplă în situația în care un OR primește o solicitare atât dinspre FZ , cât și din POSF. Care cerere se procesează în această situație?

Furnizorul nu are dreptul sa solicite direct. OR va ignora cererea si va sesiza ANRE incalcarea de catre furnizor a reglementarilor. Regulamentul stabileste clar ca solicitarile se trimit catre OR DOAR prin intermediul POSF (de catre platforma, in mod automat). Furnizorul realizeaza contracterea in POSF sau inregistrarea in POSF a contractului incheiat in afara platformei. OR este apoi notificat in cadrul procesului tehnic de schimbare/contractare.

Daca OR are nevoie de date suplimentare de la Furnizor le poate solicita transfera pe un flux informational separat. Se va tine cont insa de termenele, data, ziua, ora de la transmiterea mesajelor prin POSF.

[bogdannedelcu]

Ref 2. 2. Se impune o confirmare că intervalul de 24 h de inițiere a procedurii pentru schimbarea furnizorului prevăzut la art 41 din Ordinul ANRE nr. 3/2022 nu este aplicabil pentru situațiile de la art 34 alin 1 lit b în care contractele sunt încheiate în afara POSF. În aceste cazuri, termenul este cel specificat de 3 zile lucrătoare (2 zile pentru transmiterea datelor + 1 zi schimbare furnizor).

Nu, nu confirmam. Termenul prevazut la art. 41 este cel prevazut de Directiva 944 si Lege pentru realizarea procesului tehnic. Acesta incepe de la initierea procedurii de schimbare adica fie dupa validarea de furnizor a contractului nou in cazul incheierii acestuia prin POSF, fie la momentul inregistrarii acestuia in POSF de furnizor, cand contractul a fost incheiat in afara POSF.

[bogdannedelcu]

Ref 3. POSF nu prevede un câmp explicit cu data efectivă a schimbării furnizorului, care nu poate fi mai devreme decât ziua lucrătoare t+2 (ex dacă se inițiază schimbarea în ziua de 19 la orice ora, atunci schimbarea efectivă nu poate avea loc mai devreme de ziua de 21 ora 00). Solicităm modificarea termenului de 24 h (art 34 alin 1 lit a, art 41 și art 43 lit d) cu cel de o zi lucrătoare. Există în ordin alte termene exprimate în zile lucrătoare și nu ore.

Exista pe entitatea Contract campul startingDate denumit "data efectiva a schimbarii furnizorului".

Termenul de 24 de ore este cel prevazut de Directiva si Lege si nu se poate modifica sau asocia cu o zi lucratoare. Termenele de la art. 34/43 si 41 sunt termene succesive, fiecare dintre ele avand alt rol.

[bogdannedelcu]

Ref 4. S-a furnizat o listă cu mesaje și descrierea lor . Lista este finală? Considerăm că mesajele ar trebui incluse în scheme logice necesare pentru fluența fiecărui proces care se va derula prin POSF. Când vor fi transmise aceste scheme ?

Lista este publica pe pagina GIT. Daca în cadrul procesului de testare reiese necesitatea modificării listei, se va realiza.

[bogdannedelcu]

Ref 5. Având în vedere că în data de 25.05.2022 se dorește începerea testelor cu operatorii, în ce zile se vor derula aceste teste ? Momentan nu se cunosc informații despre migrare.

Desi am anuntat initial ca 25.05.2022 incep testarile, dezvoltatorul a reusit sa o faca mai devreme astfel că eprezentanții tehnici ai fiecarui operator cunosc faptul ca deja de 2 saptamani se pot efectua testari. Este imperios necesar ca TOȚI operatorii sa se inroleze pe GIT HUB si sa inceapa testarile

[bogdannedelcu]

Ref 6. Nu am regăsit următoarele informații:  Calendarul tehnic privind interconecatrea sistemelor informatice  Diagrama cu fluxul de informații (actualizată cnf regulamentului)  Diagramele de flux pentru fiecare dintre procesele tratate.

Aceste informatii sunt prezentate pe GIT va rugam puneti intrebari punctuale si vom raspunde

[bogdannedelcu]

Ref 7. Schema actualizată conține informații doar despre 3 pași în procesul de schimbare furnizor și se detaliază doar câteva schimburi de mesaje. Avem nevoie de schemele complete pentru toate procesele. Când vor fi puse la dispoziție?

schema prezentata este cu titlu de concept pentru a ilustra modalitatea de comunicare asincrona. Pentru fiecare mesaje se prezinta in tabel detaliile necesare.

[bogdannedelcu]

Ref 8. Întrucât regulamentul prevede că indexul autocitit de la data inițerii procesului este obligatoriu pentru client, considerăm că, în cazul în care clientul își dorește schimbarea de furnizor în 24 h, este obligatoriu un singur index autocitit transmis la data efectivă a schimbării, pentru a evita un neajuns la client care ar fi în situația de a transmite indexul în 2 zile consecutive.

Nu, deoarece nu in toate cazurile e vorba de doua zile consecutive. Primul index este la data la care clientul initiaza contractarea, insa din cazul solicitarii de furnizor de documente suplimentare si/sau clarificari, durata pana la initierea procesului tehnic de 24 de ore poate fi mult mai mare, chiar daca clientul alege schimbarea efectiva in prima zi dupa acest interval. Deci este necesar si al doilea index autocitit sau citit de OR.

[bogdannedelcu]

Ref 9. Din schema de mesaje rezultă că indexul este opțional atât la inițiere , cât și la data începerii, în timp ce seria și tipul de contor sunt informații obligatorii de introdus. Solicităm clarificări în acest sens.

Seria si tipul se completeaza de catre OR cand publica informatiile despre locul de consum, informatiile vor fi preluate prin API din POSF

[bogdannedelcu]

Ref 10. Pentru situațiile în care datele contorului nu sunt accesibile clientului (ex ecran opac, modificări tehnice) POSF trebuie să permită schimbarea de furnizor într-o perioada mai mare de 24 de ore.

Clientul reclama acest fapt OR care e obligat sa remedieze. Pana atunci clientul este in imposibilitatea de a initia schimbarea, ceea ce nu are nicio legatura cu termeneul de 24 de ore care este ulterior initierii.

[bogdannedelcu]

Ref 11. Din discuțiile avute la nivel tehnic, rezultă că furnizorul trebuie să valideze indexul furnizat de client în procesul de contractare pe baza unor elemente ajutătoare (poză contor sau ultima factură emisă), fapt care nu este conform reglementărilor în vigoare și care nu poate fi realizat de către furnizor. Se impune o clarificare în acest sens.

Nu trebuie sa valideze nimic. Ii parvine si tine sema de el, dupa caz. Poza reprezinta o dovada. Daca valoare din poza nu corespunde cu valoarea inscrisa de client, furnizorul ii cere clientului sa corecteze prin mesaj specific ContractMoreInfo

[bogdannedelcu]

Ref 12. La semnarea unui contract de furnizare regulamentul prevede și semnarea unei convenții de consum. Convenția de consum, propusă de furnizor și agreată sau modificată de client, are la bază istoricul de consum aferent acelui loc de consum. În condițiile în care pe platforma POSF nu este prevăzut schimbul de date referitor la istoricul de consum și stocarea/ schimbul de date din convenție, cum va fi semnată aceasta pentru procesul lansat din POSF? Ce fluxuri vor fi utilizate pentru transmiterea convențiilor de consum către OR?

In POSF nu are cum sa propuna furnizorul o conventie de consum precompletata. Clientul alege oferta din POSF si compleetaza documentele, inclusiv conventia. Doar la contractarea in afara platformei se poate intampla sa i se sugereze o conventie bazata pe istoric, daca noul furnizor cunoaste un astfel de istoric.

[bogdannedelcu]

Ref 13. Furnizorul nu are atribuții în ceea ce privește validarea adreselor locurilor de consum . Cum se poate rezolva acest aspect prin POSF?

Este corect. Ce ar fi de rezolvat? OR introduce adresa locului de consum pe care o stie el, iar furnizorul va folosi aceasta adresa sau va introduce alta pe contract la executionAddress, conform documentelor pe care i I le pune la dispozitie clientul

[bogdannedelcu]

Ref _14. Nu există un proces prealabil lansării soluției POSF de populare a bazei de date cu informațiile despre toate locurile de consum și despre clienți. În clarificări s-a menționat că acest fapt se va realiza prin intermediul mesajelor standard care presupun popularea bazei de date progresiv post go live. O astfel de abordare ridică următoarele întrebări:

 cât va dura popularea bazei de date POSF, ținând cont că volumul de informații este foarte mare, zeci de mii / milioane de locuri de consum și clienți cu un set de date consistent?  odată cu migrarea POD-urilor se vor migra și convențiile de consum din baza de date a OR?  ce se întâmplă cu contractarea prin POSF dacă baza de date nu este populată cu aceste informații?  ce se întâmplă dacă vin mesaje de update la nivelul unui loc de consum care nu a fost încă migrat în platformă?  dacă baza de date nu este populată cu datele despre locurile de consum și clienți, cum poate POSF să intermedieze schimbarea de furnizor și să fie un canal unic de comunicare pentru FZ și OR? _

Mai multe detalii aici: https://github.com/posfgit/standard/#inrolarea-in-sistem-migrarea-datelor-existente

[bogdannedelcu]

Ref _15. Nomenclatorul de adrese al OR/FZ va fi diferit față de nomenclatorul POSF, iar "Adresa" este un câmp obligatoriu în multe din mesaje. Ce se întâmplă dacă "Adresa" trimisă de FZ este diferită de cea din POSF? Cum va putea decide operatorul uman adresa corectă? Se impune clarificarea termenului “vizual”.

Răspunsul primit în platforma GitHub: Se vor salva în baza de date POSF toate adresele transmise. Dacă vor exista diferențe, un operator uman va alege vizual adresa corectă în următorul act emis. POSF pune la dispoziție un API prin care se poate extrage adresa unui Place așa cum este ea înregistrată în baza de date la constituirea acelui loc de consum. _

Mai multe clarificari privind adresele aici: https://github.com/posfgit/standard/#cateva-consideratii-despre-adrese

[bogdannedelcu]

Ref _16. Vă rugăm să precizați cum va fi utilizat nomenclatorul RENNS pentru:

 realizarea unui proces de contractare prin POSF? În această situație ce se întâmplă cu adresa locului de consum existentă deja în baza de date POSF, va fi conform nomenclator sau OR?  care sunt responsabilitățile OR/FZ în cazul în care această adresă, selectată de Client pe baza nomenclator RENNS, nu coincide cu adresele din sistemele lor?  pentru realizarea unui proces de contractare prin platforma FZ? În această situație ce se întâmplă cu adresa locului de consum dacă este diferită sau nu există în nomenclatorul RENNS ?  cine este actorul care spune că adresa este cea corectă: FZ/OR/POSF/client final ?  în adresele completate (adresă loc de consum, adresă sediu, adresă corespondență) se poate adăuga și informația “Tip arteră” (exemplu bulevard, stradă, calea, aleea) separat de elementul street? _

Mai multe clarificari privind adresele aici: https://github.com/posfgit/standard/#cateva-consideratii-despre-adrese

[bogdannedelcu]

Ref Mai multe clarificari privind adresele aici: https://github.com/posfgit/standard/#cateva-consideratii-despre-adrese

Nu se desfasoara fluxuri in POSF, doar se raporteaza mesaje care sunt redirectionate celor interesati conform legii.

[bogdannedelcu]

Ref 18. Vă rugăm să detaliați modalitățile de aplicare a situațiilor de renunțare la CFE încheiat la distanță prevăzute la art 47 alin 3 lit b) din Ord ANRE nr 3/2022. Opțiunea clientului de a schimba furnizorul în 24 h anulează dreptul acestuia prevăzut la art 47 alin 3 din Ordin. Solicităm modificarea Ordinului prin anularea acestui drept.

Art. 47 detaliaza modul de tratament si procedura in diferitele situatii care pot aparea cu ocazia renuntarii, astfel ca nu intelegm intrebarea referitoare la un drept anulat si la ce anume detalii va referiti (?) Dealtfel consideram ca in acest moment nu discutam despre modificari ale regulamentului ci despre clarificari privind implementarea aplicatiei.

[bogdannedelcu]

Ref _19. Arhitectura POSF se bazează pe publicarea unor mesaje standard, ca urmare a acțiunilor survenite, ca de ex: creare loc de consum, actualizare loc de consum, semnare contract client, anulare contract, etc. Soluția propusă, care presupune publicarea și consumarea acestor mesaje standard prin intermediul POSF de către FZ și OR, are o serie de aspecte care nu au fost clarificate până în acest moment :

 care sunt mecanismele de validare a datelor transmise prin intermediul acestor mesaje? ex: ce se întâmplă dacă mesajul transmis cuprinde doar o parte din date?  care sunt mecanismele de tratare a erorilor care pot surveni odată cu procesarea acestor mesaje? ex: ce se întâmplă dacă un mesaj nu conține POD, sau acesta este incorect?  cum se păstrează acuratețea bazei de date POSF și ale FZ, OR dacă în cadrul POSF nu există astfel de mecanisme?_

Se valideaza schema XSD, daca nu respecta este respins, inclusiv POD daca este obligatoriu. Referitor la acuratete vor fi analize ulterioare cu actiuni de imbunatatire pe care le vom propune tuturor

[AndreeaCristinaStoica]

@bogdannedelcu -

legat de:
_Ref 12. La semnarea unui contract de furnizare regulamentul prevede și semnarea unei convenții de consum. Convenția de consum, propusă de furnizor și agreată sau modificată de client, are la bază istoricul de consum aferent acelui loc de consum. În condițiile în care pe platforma POSF nu este prevăzut schimbul de date referitor la istoricul de consum și stocarea/ schimbul de date din convenție, cum va fi semnată aceasta pentru procesul lansat din POSF? Ce fluxuri vor fi utilizate pentru transmiterea convențiilor de consum către OR?

In POSF nu are cum sa propuna furnizorul o conventie de consum precompletata. Clientul alege oferta din POSF si compleetaza documentele, inclusiv conventia. Doar la contractarea in afara platformei se poate intampla sa i se sugereze o conventie bazata pe istoric, daca noul furnizor cunoaste un astfel de istoric._

va rog sa inserati un min de validare in interfata functie de putere pentru conventia inserata de client

[AndreeaCristinaStoica]

@bogdannedelcu

Referitor la : Ref 18. Vă rugăm să detaliați modalitățile de aplicare a situațiilor de renunțare la CFE încheiat la distanță prevăzute la art 47 alin 3 lit b) din Ord ANRE nr 3/2022. Opțiunea clientului de a schimba furnizorul în 24 h anulează dreptul acestuia prevăzut la art 47 alin 3 din Ordin. Solicităm modificarea Ordinului prin anularea acestui drept.

Art. 47 detaliaza modul de tratament si procedura in diferitele situatii care pot aparea cu ocazia renuntarii, astfel ca nu intelegm intrebarea referitoare la un drept anulat si la ce anume detalii va referiti (?) Dealtfel consideram ca in acest moment nu discutam despre modificari ale regulamentului ci despre clarificari privind implementarea aplicatiei.

Detaliati va rog tehnic prn mesajele care se schimba intre sistemele partilor implicate FA; FN; distribuitor; posf; FN1- daca e cazul. va rog o diagrama de proces a mesajelor un exemplu e2e pentru a putea intelege ce implementam. VA ROG sa raspundeti detaliat acestei intrebari a fost adresata de nenumarate ori asta inseamna ca nu este clar. va rog sa nu mai faceti timitere la tabele cu explicarea sumara a mesajelor. ca ati inserat acolo nu este suficient pentru a intelege fluxul E2E

Multumesc

[AndreeaCristinaStoica]

@bogdannedelcu FORTE IMPORTANT!

Ref:  POSF este canalul unic de comunicare

POSF este canalul unic de comunicare pentru platforma pe care se realizeaza schimbarea furnizorului si baza de date unica a informatiilor despre contractele de furnizare incheiate. Operarea schimbarilor si contractarilor pentru schimbarea furnizorului in orice situatie se face prin intermediul platformei, chiar daca contractarea s-a realizat initial in afara acesteia.

Va rog confirmati intelegerea noastra conform raspunsului dvs de mai sus:

POSF este canalul unic de comunicare pentru platforma pe care se realizeaza schimbarea furnizorului - ati facut referire in exclusivitate la schimbarea de furnizor, restul proceselor de contractare ( schimbare de titular fara schimbare de furnizor, activare/reactivare loc de consum inactiv fara ctr de furnizare, contract nou, acelasi client&acelasi furnizor - schimbarea de produs) asa cum spuneti vor fi transmise in POSF doar pentru "actualizarea DB POSF ctr furnizare" baza de date unica a informatiilor despre contractele de furnizare incheiate.

Ceea ce inseamna ca atat furnizorul cat si distribuitorul vor transmite mesajele catre POSF pt actualizare date , mesaje precum :ContractSignedBySupplier - furn; ContractNetworkChangedInfo-dist dupa finalizarea proceselor in "background" numai in scop de actualizare date/contract in POSF. pt aceste tipuri de contractari ne pastram integrarile existente si comunicam POSF la final de proces actualizarile

Multumesc

[AndreeaCristinaStoica]

@bogdannedelcu - te rog sa raspunzi cel putin la ultimul mesaj este foarte important pentru noi sa primim aceasta confirmare! ne blocati dezvoltarile fara aceasta confirmare deoarece primim mesaje contradictorii.

[bogdannedelcu]

Referitor la Ceea ce inseamna ca atat furnizorul cat si distribuitorul vor transmite mesajele catre POSF pt actualizare date , mesaje precum :ContractSignedBySupplier - furn; ContractNetworkChangedInfo-dist dupa finalizarea proceselor in "background" numai in scop de actualizare date/contract in POSF. pt aceste tipuri de contractari ne pastram integrarile existente si comunicam POSF la final de proces actualizarile este ok daca trimiteti dupa finalizarea proceselor in background

[bogdannedelcu]

Referitor la Operarea schimbarilor si contractarilor pentru schimbarea furnizorului in orice situatie se face prin intermediul platformei, chiar daca contractarea s-a realizat initial in afara acesteia. clarific faptul ca mesajele trimise in POSF vor retine ora si ziua la care s-au petrecut respectivele evenimente. Pe baza acestor informatii se vor putea efectua analize ulterioare in privinta respectarii obligatiilor din regulament. Poate un cuvant mai potrivit in locul "operarii schimbarilor" ar fi "inregistrarea schimbarilor" astfel incat sa clarifice necesitatea ca orice schimbare sa fie inregistrata in POSF.

[bogdannedelcu]

Referitor la restul proceselor de contractare ( schimbare de titular fara schimbare de furnizor, activare/reactivare loc de consum inactiv fara ctr de furnizare, contract nou, acelasi client&acelasi furnizor - schimbarea de produs) Clarific faptul ca schimbare de titular este un contract nou si trebuie raportat cu ContractSignedBySupplier. Modificari in cadrul aceluiasi contract de tipul Acelasi client & Acelasi furnizor se raporteaza cu ContractChangedInfo cu mentiuni de act aditional daca aceasta este situatia.