Open points - livrabile; termene; planificare

[AndreeaCristinaStoica]

Buna ziua Va rugam sa ne transmiteti un plan de proiect complet cu termene si livrabile , un plan de proiect care poate fi urmarit, prioritizat si implementat de toate partile implicate. De asemenea este necesar sa avem responsabili si persoane de contact pentru fiecare stream al proiectului Va rugam sa ne furnizati : • Functional analysis: start date- Ene date; livrabil doc analiza functionala – responsabili – nu a fost livrat niciun astfel de document pana in acest moment • Technical analysis: start date- Ene date; livrabil doc design si analiza tehnica – responsabili - nu a fost livrat niciun astfel de document pana in acest moment • Development: start – end date; cate medii sunt disponibile? Dev & UAT? • System test - Test list preparation; Data preparation; Execution - start date- Ene date ; pers contact • Functional integration test - Test list preparation; Data preparation; Execution; start- end date; (pt fiecare etapa); calendar planificare furnizori & distrib; pers resp si echipa suport din partea POSF • User acceptance test - Test list preparation; Data preparation; Execution; start- end date; (pt fiecare etapa); ce tool pentru gestionarea UAT se va folosi considerand si nr mare al partilor implicate in proiect ; configurare prezentare • Configuration Management (CM) & roll-out - start- end date; resp; • Post production support Data migration • Analysis & Entity definition : start end date; livrabil doc specif migrare; reponsabili • Migration Rules consolidation : dates; resp • Tools development: start-end dates • Migration dry runs : cate dry runs vor fi? Start-end date?; de la ce data se vor face extragerile de catre parti pentru a asigura consistenta datelor? Validare migrare resp perioade; test and prod.

Va rugam sa ne puneti la dispoziție toate aceste informatii pentru a putea incepe alocarea de resurse si prioritizarea acestor activitati in vederea implementarii proiectului, adaptarea fluxurilor si sitstemelor intern . in momentul de fata nu exista o documentație funcționala , nu exista o documentatie tehnica completa pe care sa o folosim pentru a starta sau estima in vreun fel efortul si resursele. Avem furnizata o structura de elemente fara scheme logice de process complete sau mesaje complete care se vor transmite intre sisteme ( s-a exemplificat un singur mesaj PlaceCreatedByOperator.xml).

Multumesc

[bogdannedelcu]

Buna ziua,

Proiectul POSF prevede implicarea operatorilor în partea de testare și feedback, această testare nu va fi materializată prin livrabile și acceptanță. Modul de organizare al fiecărui operator și responsabilii pentru a realiza testarea nu este componentă a proiectului ANRE, de aceea ANRE nu trebuie să vă comunice persoane de contact sau responsabilii implicați în dezvoltarea și implementarea POSF. In GIT se postează întrebările reprezentanților operatorilor, așa cum ați făcut și dvoastră și tot aici veți primi răspunsurle din partea ANRE.

În conformitate cu planul de proiect sunt programate două sesiuni de testare funcțională a POSF. În prima sesiune de testare se vor testa în cadrul ANRE functionalitățile platformei cu date de test minimale, fără a fi necesară intervenția operatorilor. În cea de-a doua sesiune de testare, care este corelată cu alte activități din cadrul contractului, vor fi testate și integrările cu operatorii.

ANRE estimează ca testările și integrările cu operatorii să înceapă în 25.05.2022. Instalarea în productie este planificată să se desfășoare începând cu 08.07.2022. Aceste date sunt utile pentru dumneavoastră necesitând implicarea dumneavoastră pentru testarea integrării și apoi cooperare pentru testarea pe parcursul instalării în productie a platformei.

Se va furniza lista de teste pentru operatori – pe baza scenariilor de business (exemplu: se inițiiază procesul procesul pentru un client casnic cu 2 locuri de consum).

In acest repository GIT va fi publicat doar standardul pentru interoperabilitate POSF care va cuprinde:

• formatul mesajelor care se vor schimba intre sistemul POSF si Furnizori/Operatori precum
• API de acces la sistemul POSF.

Separat vom transmite coordonatele de acces la un mediu de test pe care doritorii vor putea sa il foloseasca pentru a adapta sistemele proprii la acest standard. Am publicat un mockup al mediului de test la adresa https://github.com/posfgit/standard/tree/main/samples/python pe care il puteti descarca pentru teste pe infrastructura dvs. IT. Mediul de test va rămâne functional inclusiv după operaționalizare POSF, iar în cazul în care operatorii nu reusesc să finalizeze la timp integrările, vor avea posibilitatea să încarce prin intermediul interfeței (bulk).

Referitor la suport, vom asigura suport tehnic post implementare prin intermediul unui ServiceDesk dedicat.

Pe pagina principala au fost listate tipurile de mesaje care au fost identificate pana acum iar in interiorul schemei XSD precum si in documentatia PDF asociata sunt descrise in detaliu continutul campurilor din fiecare mesaj.

Ramanem deschisi la sugestiile dvs. de imbunatatire a standardului, sau orice probleme veti intalni pe parcursul implementarii.

Bogdan

[AndreeaCristinaStoica]

Buna ziua

Va rugam sa ne ajutati cu furnizarea informatiilor lipsa sintetizate mai jos care ne blocheaza posibilitatea de a avansa cu definirea si implementarea specificatiei. (rolul nostru este Furnizor de EE si GN)

1. Va rugam sa ne puneti la dispozitie specificatia de migrare a datelor in sitemul POSF pentru fiecare parte( furnizor/distribuitor), cel putin un draft existent in momentul de fata & deadline pentru vers finala. Este punct blocant pentru testare si este o activitate complexa ce necesita timp si effort semnificativ atat BSN cat si tehnic.
2. Avand in vedere faptul ca se vor initia teste de integrare intr-o luna va rugam sa ne spuneti care este deadline la care vom primi toate informatiile astfel incat sa ne putem pregati pentru acestea. Va rugam sa ne puneti la dispozitie: a. Lista si structura tuturor mesajelor care se vor initia din sistemul furnizorului catre POSF b. lista si structura mesajelor care se vor initia din POSF catre sistemul furnizorului c. cu ce date se vor face testarile din 25.05? s-a migrat ceva in mediul de test, aveti niste exemple valide pentru toate tipurile de mesaje, in baza unor date existente in test , Va rugam sa ni le puteti la dispozitie
3. Am creat mediul de test conform documentatiei DVS. Observatia noastra este ca pentru cozile de mesaje nu sunt validari. Se poate posta orice tip de mesaj indifferent de structura lui.
4. Va rugam sa ne confirmati intelegerea cu privire la ofertele disponibile in POSF, nu va fi necesara o alta migrare sau integrare cu sistemele de pricing ale furnizorului, se va folosi in exclusivitate comparator-de-tarife. Deja existent la ANRE
5. Va rugam sa ne puneti la dispozitie scenarii E2E prin evidentiere lor printr-o “ sequence diagram” . Tabelul cu mesaje nu este suficent pentru a deduce un E2E flow si secventialitatea lor.
6. Va rugam sa ne puneti la dispozitie documente in baza caroara putem intelege procesele implementate; triggers, functionalitatea, data modelul platformei POSF. O documentatie functionala a sistemului, un draft pentru un user manual (mandatory cf ordinului)
7. Va rugam sa ne puneti la dispozitie mesajele prin care se vor transfera documente intre sisteme Ne este necesara structura si directia lor (system sursa & system destinatie – lista a tuturor mesajelor; doc si tip document ) ,. Va rugam sa ne spuneti in ce format se vor transmite aceste documenete.
8. Se pot solicita useri pentu mediul de test al platformei ANRE? Ne-ar ajuta foarte mult sa intelegem fluxul implementat; mesajele care se vor tramite catre client si operatori inlusiv momentul, fazele proceselor din POSF, actiunile posibile de anulare etc si momentul din cadrul fluxului in care sunt posibile aceste actiuni. Va rugam sa ne tranmiteti un deadline pentru momentul la care putem avea sin oi access la un mediu de test al platformei.
9. Va rog sa ne puneti la dispozitie regulide validare implementate in platforma POSF. Ca de ex: a. Email; telefon; fix mobil; CNP; CUI; ONRC code etc – toate aceste informatii au impact major in sistemele partilor implicate pot reprezenta procese majore de cleaning sau modificari cu impact semnificativ in Procese. Va rog sa puneti la dispozitie documentatia din care sa reiasa toate validarile din POSF care impacteaza operatorii. deadline
10. Observam obligativitate pentru campuri care nu exista in sistemul furnizorului sau nu sunt obligatoriu de colectat insa in mesaj sunt mandatory ca de ex: a. De contact: tel si/ sau email ale clientului: elem ContactAddress b. Uninterrupltible; vulnerable; prosumer – sunt caracteristici ale contractului tehnic nu ale Clientului cum sunt structurate in mesaj. (un client poate avea mai multe locuri de consum active 1:1 contract tehnic pentru care poate avea atributele de nedeconectabil; vulnerabil; prosumer)
11. Cum se va gestiona integrarea in baza nomenclatorului de adrese? POSF se va integra in exclusivitate cu DB https://renns.ancpi.ro/renns-public/? In situatia migrarii, operatorii (furnizori si Distribuitori) vor avea in system adrese “duplicat” ca de ex cu denumire usor diferita fata de ce a nomenclatorului renns, se vor accepta la migrare si acestea? In situatia asta va fi o BD POSF care nu se va putea folosi la integrarea cu operatorii care au validari si nomenclator propriu.
12. Cum se vor gestiona situatiile clientilor cu lipsa CNP sau al situatiilor CUI/CNP existent in sistemul mai multor operatori cu nume&prenume si adrese de domiciliu diferite ca de ex Engie are pt acelasi CNP nume: Stoica Andreea; Enel : Stoica Andreea Cristina + adrese de domiciliu & date de contact diferite?

[AndreeaCristinaStoica]

@bogdannedelcu - va rog sa furnizati raspuns complet pentru fiecare punct. Multumesc

[bogdannedelcu]

Ref 1: Se va folosi mecanismul descris aici https://github.com/posfgit/standard#inrolarea-in-sistem-migrarea-datelor-existente, ca si pentru restul standardului asteptam feedback-ul dvs.

[bogdannedelcu]

Ref 2: Lista mesajelor sursa si sistemele catre care POSF redirecteaza gasiti aici https://github.com/posfgit/standard/blob/main/README.md#tipuri-de-mesaje-emitatori-si-receptori iar structura este definita in fisierul XSD https://github.com/posfgit/standard/blob/main/ANRESchema.xsd Puteti incepe testele cu mediul de test, folositi instructiunile descrise aici https://github.com/posfgit/standard/blob/main/TestEnvironment.md

[bogdannedelcu]

Ref 3: Pe mediul de test disponibil la ANRE (https://github.com/posfgit/standard/blob/main/TestEnvironment.md) exista validari de structura XSL/JSON

[bogdannedelcu]

Ref 4: Intelegerea dvs. este corecta. Aplicatia WebPOSF va propune utilizatorilor initierea fluxului de schimbare pornind de la comparatorul existent.

[bogdannedelcu]

Ref 5: Nu punem la dispozitie Sequence Diagrams, integrarea propusa are la baza doar evenimentele publicate in sistem. POSF inregistreaza toate evenimentele si le transmite catre destinatarii indreptatiti sa le receptioneze conform regulamentului. Schema interna de procesare si transmitere a mesajelor este descrisa aici https://github.com/posfgit/standard#mesajul-contractnetworksignedbysupplier

[bogdannedelcu]

Ref 6,7: Evenimentele pe care standardul POSF le defineste rezulta natural din regulament. Au fost descrise in tabelele cu mesaje motivele din spatele publicarii fiecarui mesaj. https://github.com/posfgit/standard#tipuri-de-mesaje-emitatori-si-receptori. Va rugam sa ne transmiteti intrebari pucturale pentru mesajele unde este neclara formularea.

[bogdannedelcu]

Ref 8: Da, va rog transmiteti email ca aici https://github.com/posfgit/standard/issues/18 , accesul il acordam de indata.

[bogdannedelcu]

Ref 9: Gasiti aici https://github.com/posfgit/standard#formatul-valorilor, daca doriti suplimentarea lor va rugam deschideti sesizare separata ca sa o poata urmari toti participantii

[bogdannedelcu]

Ref 10: a. Multumim pentru feedback, am modificat ContactAddress conform solicitarii. b. Nu este clar ce se doreste a fi modificat

[bogdannedelcu]

Ref 11: Intentionam sa punem la dispozitie nomenclatorul RENNS pentru a fi consumat de sistemele IT cu care POSF se integreaza. Anticipam o perioada in care vor coexista adresele actuale ale sistemelor IT ale furnizorilor cat si adresele RENNS, motiv pentru care nu vom impune restrictii/validari in aceasta privinta.

[bogdannedelcu]

Ref 12: La momentul semnarii contractului, agentul economic care incheie actul are obligativitatea conform regulament sa publice un mesaj in POSF cu datele conform actului de identitate, adresa, etc. Referitor la datele vechi acestea vor fi incarcate in sistemul POSF asa cum exista ele, respectanda standardul mesajelor.

[AurelMMUser]

Buna ziua,

Referitor la raspunsul adaugat pt punctul 11, care este stadiul acestui API prin care s-ar putea folosi nomenclatorul RENNS de catre sistemele IT ale furnizorilor?

Multumesc, Aurel Moldoveanu