Clarificari suplimentare

[EDistributie]

Buna ziua,

Avem nevoie de clarificari suplimentare privind urmatoarele puncte:

I. Migrarea datelor de catre OR in POSF:

1. Cand se va incepe migrarea informatiilor ce trebuie a fi puse la dispozitie de OR, pentru baza de date POSF atat pentru partea de testare (25.05) cat si pentru punerea in productie (08.07)? Informatiile trimise pentru partea de testare vor fi folosite si pentru mediul productiv?
2. Cum va fi facuta migrarea datelor si cand vom avea la dispozitie structura pe care trebuie sa o pregatim pt migrare (de exemplu: tipul/formatul, dimensiunea fisierului este limitata, etc.) ?

II.Structuri fluxuri, scheme proces, campuri:

1. Cand puteti sa ne furnizati exemple JSON pentru fiecare tip de mesaj (API request) relevant pentru Operatori (ce primeste si trebuie sa trimita)?
2. Cum se transmit informatiile privind prelungirea contractelor(de furnizare) la OR?

III.Adrese:

1. Coordonatele GPS vor fi informatii suplimentare (xs:attribute name="geohash, latitude, longitude" use="optional")? Vor fi necesare la migrarea datelor?
2. Vor fi necesare informatii URBAN/RURAL ?
3. Va rugam clarificati daca informatiile extra, cum ar fi "Localitate, Sat, Bloc, Etaj, Apartament" pot fi descompuse in campuri dedicate, si nu concatenate(se pot omite anumite informatii esentiale).

IV. Definitii conventii:

1. La ce se refera elementele: ConventionSignedByClient, ConventionSignedByOperator, ConventionSignedBySupplier: • la conventie de consum (asa cum apar in intrebarile si raspunsurile: Conventie de consum si date ID); • la conventie de retea (In documentatia pusa la dispozitie de ANRE, elementul Convention are definitia “Conventie contract de retea” si tip (ConventionType) “tripartita” sau “multipartita”) acestea sunt exceptii de la fluxul normal; • conventie de exploatare.
2. Conform ordinului 82 art.22, conventia de consum este parte obligatorie din contractul de furnizare si incepand cu 01 ianuarie 2022 OR are obligatia de a factura aceste valori furnizorului in cazul locurilor de consum pt care nu exista index citit de catre OR sau de catre clientul final, astfel, in aceasta situatie:
   • Ce fluxuri vor fi utilizate pentru transmiterea conventiilor de consum catre OR?

V. Alte intrebari:

1. Care este mesajul prin care distribuitorul este notificat ca procedura de schimbare furnizor s-a finalizat cu succes ?
2. De ce in sistemele informatice ale operatorului de retea trebuie sa se faca verificarea existentei simultane a 2 contracte active pe locul de consum? Nu se poate face din POSF aceasta verificare?
3. Este posibila inregistrarea retroactiva in platforma a cererilor, in cazul licitatiilor?
4. Cum vor fi tratate rezilierile si reactivarile aceluiasi locului de consum cu aceeasi data?

Multumesc!

[bogdannedelcu]

Ref i: Puteti incepe trimiterea de date de test la POSF folosind mesajele din standard. Incepeti cu locurile de consum completand mesaje de tip PlaceUpdatedByOperator. Migrarea va fi una continua pana cand toate platformele vor ajunge la zi cu transmiterea datelor.

[bogdannedelcu]

Ref ii: mesajele format JSON au aceeasi structura ca si formatele XML, urmariti exemplele din Postman care au in Body si elemente JSON si XML. In Swagger gasiti structura detaliata pentru fiecare entitate https://posf-beta.anre.ro/broker/swagger-ui/index.html#/

[bogdannedelcu]

Ref iii: GPS este optional, vom sparge campul de adresa pe mai multe detalii, revenim cu update la standard. Nu este necesar urban/rural in POSF

[bogdannedelcu]

Ref v:

1. ContractSignedBySupplier - este ultima etapa cand un contract este semnat final de Furnizor. Se presupune ca a fost semnat deja de Client fie electronic fie pe hartie la ghiseu.
2. Este o alegere facuta la nivel de proiect deoarece sistemul POSF nu valideaza din punct de vedere legal mesajele trimise de parti, cel mult poate limita din aplicatia WebPOSF aceste anomalii, insa daca POSF va primi mesaje XML de al furnizori care dubleaza contractele pe un loc de consum, atunci aceasta regula trebuie infiintata la Operator, cel care a creat si poate modifica locul de consum. POSF devine o baza de date si o arhiva a tuturor modificarilor, poate fi un loc in care sa se verifice anumite anomalii (dubluri) dar nu va limita activitatea celor care publica date in sistem. Vom colabora cu totii permanent pentru a identifica eventuale probleme si a gasi mecanisme pentru a reduce riscul aparitiei lor.
3. Mesajele definite in standard au atribut de tip timestamp iar in interiorul Contractelor se poate stabili data/ora arbitrar. POSF nu verifica daca data din contract este retroactiva datei Timestamp a mesajului, in sensul ca nu respinge astfel de mesaje. Cu toate acestea este posibil ca pe viitor sa definim reguli care sa identifice abateri de la regulament pe care le vom transmite autorilor de mesaje.
4. Prin mesaje succesive in ordinea in care evenimentele s-au petrecut. Daca doriti sa analizam un scenariu punctual va rugam detaliati speta.

[bogdannedelcu]

Ref iv: 1. Elementele Convention* se refera la conventia de retea.

[EDistributie]

Buna ziua,

Va multumim pentru raspunsurile oferite. Puteti sa ne ajutati in continuare cu urmatoarele subiecte:

1. Este posibil ca elementul correspondenceAddress (din elementele Company, Person) sa contina campuri distincte asemenea celor pentru adresa sediu/domiciliu campul Address ?

Elemente Adresa sediu/domiciliu:

2. Campul extra (referitor la prima imagine) la ce foloseste?

3. In elementul contract exista campurile correspondenceClientAddress respectiv correspondenceClientContactAddress; aceleasi informatii se trimit si in elementele Client-Company – correspondenceAddress si Client - Company- correspondenceAddress-contactAddress (persoana juridica) respectiv Client – Person - correspondenceAddress si Client-Person - correspondenceAddress – contactAddress (persoana fizica) care fac parte tot din elemental contract. Se pot elimina date pentru a nu dubla informatiile transmise?

4. Pentru ContractSignedBySupplier, elementul contractWithOperatorNeeded este tot timpul false? Iar pentru ContractNetworkSignedByClient elementul contractWithOperatorNeeded este tot timpul true? Ca si OR, intelegem ca fluxul ContractNetworkSignedByClient reprezinta semnarea contractului de catre client in relatie directa cu OR.

5. Pentru adresele sediu/docmiciliu (address), loc de consum (address), corespondenta (correspondenceAddress), se poate adauga si informatia Tip arteră separat de elementul street? Exemplu pentru locatia: Bulevardul Unirii

• Tip arteră= Bulevardul
• street= Unirii

Va multumim!

[EDistributie]

@bogdannedelcu Va rog, ne puteti ajuta doar cu raspunsul la intrebarea 1 (Este posibil ca elementul correspondenceAddress (din elementele Company, Person) sa contina campuri distincte asemenea celor pentru adresa sediu/domiciliu campul Address ? ) ? Multumim!

[bogdannedelcu]

Ambele sunt de tip Address, nu sunt string.

[bogdannedelcu]

Ref 2: extra este pentru orice alt element de identificare al unei companii

[bogdannedelcu]

Ref 3: Sunt optionale, completati ce aveti la migrare

[bogdannedelcu]

Ref 4: contractWithOperatorNeeded se pune true atunci cand clientul doreste contract de retea direct cu OR, in ambele mesaje ContractSignedByClient si ContractSignedBySupplier. OR vede prima data mesajul de la Furnizor, iar un functie de aceasta bifa contractWithOperatorNeeded va crea sau nu contract de retea cu clientul prin ContractNetworkSignedByOperator sau va lua in evidenta noul furnizor la locul de consum prin ContractNetworkChangedInfo

ContractNetworkSignedByClient nu se foloseste pentru moment

[bogdannedelcu]

Ref 5: da, se numeste StreetType