posfgit / standard

9 stars 13 forks source link

Observatii POSF - Delgaz Grid #10

Open ConsuelaKozmaDEGR opened 2 years ago

ConsuelaKozmaDEGR commented 2 years ago

Solicitam vizibilitate asupra etapelor proiectului care presupune implicarea utilizatorilor POSF, asa incat participantii/viitorii utilizatori ai POSF sa poata analiza si evalua impactul proiectului/etapelor asupra propriilor procese care vor suferi transformari si pentru a aloca resursele necesare asigurarii fezabilitatii POSF; respectivele etape ale proiectului nu au fost inca transmise de ANRE. De asemenea solicitam transmiterea calendarului tehnic avut in vedere cu privire la interconctarea sitemelor informatice ale utilizatorilor cu POSF, pe etape, cu fiecare utilizator POSF; calendarul nu a fost inca transmis de ANRE. Diagrama cu fluxul de informatii nu reflecta in totalitate prevederile Regulamentului, aprobat cu Ord nr. 3/2022 asa incat sa se poata evalua impactul fezabililitatii fiecarui pas de proces din cadrul fluxului de informatii necesar asigurarii functionalitatii POSF.

Observatii punctuale:

  1. In procesele de modificare a contractelor de distributie existente ne sunt necesare urmatoarele informatii pe care nu le-am regasit in obiectele existente:

    • cod CAEN, tip client (casnic/non-casnic)- informatii necesare in cazul raportarilor catre autoritati care au compententa de a solicita acest tip de informatii (solicitari din partea Ministerului Mediului, Ministerului Energiei) - va putem pune la dispozitie aceste raportari
    • Nume si prenume client/Denumire client - aceste informatii sunt necesare pentru : o situatiile in care este necesara notificarea clientilor (lipsa acces pt citire index, inlocuire contor sau in cazul depasirii puterii aprobate prin aviz sau certificat de racordare) o transmitere date de masurare, informatie care este cuprinsa in anexele la contract o transmitere preavize de deconectare in cazul in care locul de consum se afla in situatia de a nu avea asigurata furnizarea EE/GN prin contract
    • programul de distributie - necesar pentru incheierea contractului, transmis de catre UD la incheierea contractului
  2. Referitor la diagrama cu fluxul de informatii, este necesara structura fiecarui mesaj schimbat de partile implicate .De ex, ce structura de mesaj de asteapta de la operatorul de distributie pe raspunsul ConventionSignedByOperator

  3. Vom primi separat fluxurile de informatii specifice fiecarui tip de proces? (ex. modificari administrative , FUI , prelungiri contracte, etc). De exemplu, din setul de informatii primit nu am identificat fluxul de informatii in cazul trecerii locurilor de consum la FUI (retragere/suspendare licenta)

  4. In contextul termenului de schimbare furnizor in 24h, cum se vor trata locurile de consum care la momentul schimbarii furnizorului sunt deconectate pentru neplata? (ex. se face schimbarea de furnizor cu statusul de la momentul respectiv ? nu se reflecta in material fluxul de informatii intre partile implicate )

  5. Cum se trateaza cazul in care pentru acelasi POD se trimit in platforma solicitari de la 2 furnizori diferiti iar PODul nu este in situatia de a putea legal sa incheie contracte cu 2 furnizori? (ex. Clientii cu consum de gaze naturale mic, care nu se incadreaza la prevederile de la Art. 14 din Regulamentul de Furnizare Gaze Naturale)

  6. Este neclar cum va ajunge in sistemul informatic al distribuitorului indexul autocitit, transmis de catre client, nu s-a regasit in diagrama flux informatii si ce se intampla in cazul in care indexul autocitit este eronat/mult diferit de cel istoric. Este necesara prezentarea criteriilor de validare a informatiilor preluate.

  7. Nu s-a regasit in fluxul de informatii cum ajunge informatia de la OD cu privire la locurile noi de consum , cum sunt introduse acestea in POSF de catre OD si cum ajunge informatia cu privire la incheierea de contract de furnizare, informatie necesara pentru a starta procesul de PIF.

  8. Nu s-au regasit in fluxul de informatii cazurile in care procesul de contractare este startat cu un CLC/POD eronat sau cazurile in care sunt necesare corectii in baza de date OD.

  9. Este necesara posibilitatea incarcarii in masa a solicitarilor in cazul in care este necesara operarea manuala in platforma.

bogdannedelcu commented 2 years ago

Buna ziua, raspund punct cu punct:

  1. ref cod caen: odul CAEN in cazul persoanelor juridice nu este necesar pentru schimbarea furnizorului. POSF nu poate fi extins pentru alte scopuri. Cu toate acestea, codul CAEN este o informaţie care se regăseşte sau se poate regasi în contractul de furnizare a energiei încheiat de clientul noncasnic cu furnizorul; contractul este pus la dispoziţia CF de către furnizor indiferent daca se face contractarea in POSF sau in afara. ref nume/prenume - Aceste informatii despre nume/prenume/denumire client final sunt in POSF/Regulament. ref programul de distributie - Programul de distributie este o anexa la contractul de distributie a gazelor naturale.

  2. revenim cu structura si exemplu pentru fiecare mesaj

  3. Am actualizat versiunea XSD cu mesajele de tip FUI. Prelungirea contractelor recomandam sa se faca prin act aditional si transmiterea de mesaje specifice contractelor respective

  4. Locurile deconectate se trateaza la fel din punct de vedere al schimbarii furnizorului ca si cele conectare, cu deosebirea ca reluarea alimentarii se va face cand se sting cauzele care au condus la deconectare. Deci acest aspect nu are importanta in procesul de schimbare dar informatii despre starea conectat/deconectat a locului de consum se vor stoca si afisa.

  5. Conform reglementarilor in vigoare un client final poate avea simultan mai mult de un furnizor la un loc de consum (POD/CLC), cu mentiunea ca, pentru GN, doar clientii finali cu un consum mai mare de 28.000 MWh/an au dreptul sa incheie pentru un loc de consum mai multe contracte cu furnizori diferiti (clientii finali din categoriile de consum C4 si C5, informatia privind categoria clientului fiind prevazuta in POSF). O solicitare de schimbare se refera la unul dintre contractele existente, iar in acest caz nu pot exista simultan doua solicitari de schimbare. O noua solicitare din partea clientului e posibila doar dupa terminarea procedurii tehnice de schimbare si conduce la denuntarea contractului anterior.

  6. Exista doua autocitiri: cea de la momentul initierii schimbarii si cea de la data efectiva a schimbarii. Ambele implica o valoare introdusa de client dar si o poza a contorului. Daca a doua nu se intampla, este sarcina operatorului de retea sa faca o citire. Validarea indexului o face furnizorul nou in baza informatiilor primite. In plus, este la latitudinea furnizorului sa solicite la contractare, spre exemplu, o factura recenta pentru a cunoaste un index anterior. Din punct de vedere al mesajelor, mesajul care transmite contractul semnat, luam ca exemplu ContractSignedByClient va include entitatea Place care are in cadrul TechnicalData indexul contoarului. Aplicatia WebPOSF va permite clientului sa completeze aceasta informatie. In masura in care si Furnizorul va putea trimite si el la randul sau in cadrul mesajului ContractSignedBySupplier indexul citit pe locul de consum.

  7. Locurile noi de consum se introduc in POSF de catre operatorul de retea la terminarea lucrarilor instalatiie de racordare, pentru a se putea incheia contractul de furnizare. Anterior oricărei puneri în funcțiune, OD trebuie să primească din partea executantului procesul verbal de receptie tehnica a instalatiei de utilizare și contractul incheiat cu un furnizor de gaze naturale de client pentru respectivul loc de consum. Numai după ce OD primește aceste documente se semnează procesul-verbal de punere în funcţiune a instalaţiei de utilizare. OD publica in sistem mesajul PlaceCreatedByOperator sau PlaceUpdatedByOperator iar furnizorii pot interoga un loc de consum folosind API-ul descris in standard /place/getByCode pentru a lua datele unui loc de consum pe baza codului acestuia

  8. CLC/POD sunt date validate, introduse de operatorii de retea. Clientul final alege CLC/POD corespunzator adresei postale. Furnizorul verifica corectitudinea CLC/POD ales. Daca CLC/POD este utilizat de alt client final, furnizorul nu valideaza incheierea contractului decat daca primeste documente justificative (ex. incheie contract chirias in loc de proprietar). Idem, validarea adresei postale o face furnizorul in cazul in care exista diferente intre informatia cunoscuta de operatorul de retea si cea cunoscuta de furnizor. Adresele se aduc la zi cu baza de date furnizata de ANCPI.

  9. Pentru o incarcare in masa punem la dispozitie API-ul prin care se pot publica aceste mesaje din platforme IT proprii.

Va multumim pentru mesaj si ramanem la dispozitie pentru alte clarificari

ConsuelaKozmaDEGR commented 2 years ago

Buna ziua, raspund punct cu punct:

  1. ref cod caen: odul CAEN in cazul persoanelor juridice nu este necesar pentru schimbarea furnizorului. POSF nu poate fi extins pentru alte scopuri. Cu toate acestea, codul CAEN este o informaţie care se regăseşte sau se poate regasi în contractul de furnizare a energiei încheiat de clientul noncasnic cu furnizorul; contractul este pus la dispoziţia CF de către furnizor indiferent daca se face contractarea in POSF sau in afara.

@bogdannedelcu : Revenim catre dvs cu precizarea ca noi in calitate de OD avem nevoie de codul CAEN pentru cazurile de Modificari administrative (nu schimbari de furnizori). Pentru exemplificare mentionam cazul in care prin modificarea administrative solicitata se face trecerea de la client casnic la client non-casnic/ non-casnic la non-casnic . Un alt exemplu elocvent este cazul asociatiilor de proprietari care declara in contractul de furnizare destinatia spatiului (desfasoara activitati comerciale profesionale sau nu). Prin urmare aceasta informatie trebuie sa ajunga la OD. Informatia referitoare la proprietarul/titularul de contract este necesara pentru:

ref nume/prenume - Aceste informatii despre nume/prenume/denumire client final sunt in POSF/Regulament. ref programul de distributie - Programul de distributie este o anexa la contractul de distributie a gazelor naturale. @bogdannedelcu: Cunoastem faptul ca este o anexa la contractul de distributie a gazelor naturale insa nu avem vizibilitate asupra procesului de intocmire a acestei anexe. Anexa la contractul de distributie este creata automat din POSF si transmisa apoi la OD sau care este procesul?

  1. revenim cu structura si exemplu pentru fiecare mesaj

  2. Am actualizat versiunea XSD cu mesajele de tip FUI. Prelungirea contractelor recomandam sa se faca prin act aditional si transmiterea de mesaje specifice contractelor respective @bogdannedelcu Nu este clar care este tipul de mesaj care se va folosi pentru cazul in care un client ramane fara Furnizor. Acest proces este startat de catre OD. In momentul de fata OD transmite catre FUI lista locurilor de consum ramase fara furnizor. Nu este vizibil in specificatiile tehnice ale POSF cum se desfasoara procesul in cazul situatiei mentionate.

  3. Locurile deconectate se trateaza la fel din punct de vedere al schimbarii furnizorului ca si cele conectare, cu deosebirea ca reluarea alimentarii se va face cand se sting cauzele care au condus la deconectare. Deci acest aspect nu are importanta in procesul de schimbare dar informatii despre starea conectat/deconectat a locului de consum se vor stoca si afisa.

  4. Conform reglementarilor in vigoare un client final poate avea simultan mai mult de un furnizor la un loc de consum (POD/CLC), cu mentiunea ca, pentru GN, doar clientii finali cu un consum mai mare de 28.000 MWh/an au dreptul sa incheie pentru un loc de consum mai multe contracte cu furnizori diferiti (clientii finali din categoriile de consum C4 si C5, informatia privind categoria clientului fiind prevazuta in POSF). O solicitare de schimbare se refera la unul dintre contractele existente, iar in acest caz nu pot exista simultan doua solicitari de schimbare. O noua solicitare din partea clientului e posibila doar dupa terminarea procedurii tehnice de schimbare si conduce la denuntarea contractului anterior. @bogdannedelcu : In acest caz, daca un furnizor trimite solicitare pentru un loc de consum care are deja o solicitare nefinalizata in POSF (cu aceeasi data solicitate a schimbarii sau o data diferita), solicitarea noua va fi respinsa sau cum va fi tratat acest caz?

  5. Exista doua autocitiri: cea de la momentul initierii schimbarii si cea de la data efectiva a schimbarii. Ambele implica o valoare introdusa de client dar si o poza a contorului. Daca a doua nu se intampla, este sarcina operatorului de retea sa faca o citire. Validarea indexului o face furnizorul nou in baza informatiilor primite. In plus, este la latitudinea furnizorului sa solicite la contractare, spre exemplu, o factura recenta pentru a cunoaste un index anterior. Din punct de vedere al mesajelor, mesajul care transmite contractul semnat, luam ca exemplu ContractSignedByClient va include entitatea Place care are in cadrul TechnicalData indexul contoarului. Aplicatia WebPOSF va permite clientului sa completeze aceasta informatie. In masura in care si Furnizorul va putea trimite si el la randul sau in cadrul mesajului ContractSignedBySupplier indexul citit pe locul de consum.

@bogdannedelcu Nu este clar flowul de comunicare (care este triggerul prin care OD trebuie sa isi dea seama ca trebuie facuta citirea, care este termenul in care se poate realiza aceasta citire si in care trebuie sa il trimita furnizorului, ce se intampla daca furnizorul nu valideaza indexul nou).

  1. Locurile noi de consum se introduc in POSF de catre operatorul de retea la terminarea lucrarilor instalatiie de racordare, pentru a se putea incheia contractul de furnizare. Anterior oricărei puneri în funcțiune, OD trebuie să primească din partea executantului procesul verbal de receptie tehnica a instalatiei de utilizare și contractul incheiat cu un furnizor de gaze naturale de client pentru respectivul loc de consum. Numai după ce OD primește aceste documente se semnează procesul-verbal de punere în funcţiune a instalaţiei de utilizare. OD publica in sistem mesajul PlaceCreatedByOperator sau PlaceUpdatedByOperator iar furnizorii pot interoga un loc de consum folosind API-ul descris in standard /place/getByCode pentru a lua datele unui loc de consum pe baza codului acestuia

@bogdannedelcu : Din acest raspuns intelegem ca POSF va avea o baza de date cu toate locurile de consum, realizate dar care nu sunt puse in functiune, inclusiv cu cele care au contracte de distributie inactive/reziliate. Va rugam sa ne confirmati daca intelegerea este corecta.

  1. CLC/POD sunt date validate, introduse de operatorii de retea. Clientul final alege CLC/POD corespunzator adresei postale. Furnizorul verifica corectitudinea CLC/POD ales. Daca CLC/POD este utilizat de alt client final, furnizorul nu valideaza incheierea contractului decat daca primeste documente justificative (ex. incheie contract chirias in loc de proprietar). Idem, validarea adresei postale o face furnizorul in cazul in care exista diferente intre informatia cunoscuta de operatorul de retea si cea cunoscuta de furnizor. Adresele se aduc la zi cu baza de date furnizata de ANCPI.
  2. Pentru o incarcare in masa punem la dispozitie API-ul prin care se pot publica aceste mesaje din platforme IT proprii.

Va multumim pentru mesaj si ramanem la dispozitie pentru alte clarificari

ConsuelaKozmaDEGR commented 2 years ago

Va rugam sa ne trasmiteti diagramele de flux pentru fiecare dintre procesele tratate prin platforma POSF. Ele ne sunt necesare cat de repede posibil pentru a putea aprecia impactul operational si financiar asupra proceselor si aplicatiilor noastre si pentru a realiza dezvoltarile necesare astfel incat interconectarea aplicatiilor noastre cu platforma POSF sa devina fezabila.

bogdannedelcu commented 2 years ago

Ref: Din acest raspuns intelegem ca POSF va avea o baza de date cu toate locurile de consum, realizate dar care nu sunt puse in functiune, inclusiv cu cele care au contracte de distributie inactive/reziliate. Va rugam sa ne confirmati daca intelegerea este corecta.

API /place/getByCode va raspunde cu descrierea unui loc de consum asa cum a fost publicata de catre Operator, prin cel mai recent mesaj PlaceUpdatedByOperator pentru cod-ul locului respectiv.

bogdannedelcu commented 2 years ago

Ref: Nu este clar flowul de comunicare (care este triggerul prin care OD trebuie sa isi dea seama ca trebuie facuta citirea, care este termenul in care se poate realiza aceasta citire si in care trebuie sa il trimita furnizorului, ce se intampla daca furnizorul nu valideaza indexul nou).

Raspuns, depinde de cine identifica aceasta nevoie. Daca o identifica aplicatia WebPOSF aceasta va notifica clientul si il va obliga sa introduca noul index iar sistemul POSF va transmite un mesaj ContractChangedInfo. Totusi e posibil ca clientul sa nu raspunda solicitarii. Daca operatorul de retea va transmite noul index va folosi acelasi mesaj ContractChangedInfo in care va completa data si valoarea noului index.

bogdannedelcu commented 2 years ago

Ref: Nu este clar care este tipul de mesaj care se va folosi pentru cazul in care un client ramane fara Furnizor. Acest proces este startat de catre OD. In momentul de fata OD transmite catre FUI lista locurilor de consum ramase fara furnizor. Nu este vizibil in specificatiile tehnice ale POSF cum se desfasoara procesul in cazul situatiei mentionate.

Raspuns: am publicat noile mesaje in care sunt incluse si cele care tin de FUI https://github.com/posfgit/standard#mesaje-pe-tema-fui

bogdannedelcu commented 2 years ago

Ref: In acest caz, daca un furnizor trimite solicitare pentru un loc de consum care are deja o solicitare nefinalizata in POSF (cu aceeasi data solicitate a schimbarii sau o data diferita), solicitarea noua va fi respinsa sau cum va fi tratat acest caz?

Raspuns: POSF tine evidenta tutror cererilor finalizate sau nefinalizate, sistemul inregistreaza toate mesajele primite conforme cu standardul. Exista o aplicatie WebPOSF care permite clientilor finali sa creeze cereri de schimbare. O singura cerere de schimbare poate fi la un moment dat in starea "In lucru" pe un contract.

ConsuelaKozmaDEGR commented 2 years ago

@bogdannedelcu Este esential ca schimbul de date dintre POSF si OD, Furnizori sa fie structurat pe tipuri de procese de contractare avand in vedere ca fiecare tip de proces implica modificari diferite in aplicatiile IT utilizate de OD/Furnizori in vederea incheierii contractelor de distributie/furnizare. Exemple de tipuri de procese:

bogdannedelcu commented 2 years ago

Arhitectura software POSF se bazeaza pe pattern-ul Event Sourcing. Pentru fiecare din procesele enuntate mai sus exista mesaje care inregistreaza respectivele evenimente in log-ul sistemului.

ConsuelaKozmaDEGR commented 2 years ago

@bogdannedelcu Va rugam sa documentati secventa de mesaje pentru fiecare dintre flowurile de contractare mentionate mai sus astfel incat sa ne putem alinia toate partile implicate si sa nu se produca desincronizari in platforma POSF. Multumim.