Mesaje gresite transmise sau receptionate

[bogdannedelcu]

Pentru cazurile in care un mesaj a fost trimis gresit exista situatii in care unul din participantii in POSF se pot sesiza astfel:

1. POSF sesizeaza prin corelari la nivelul bazei de date ca mesajul nu poate fi interpretat corect (ex: anulare contract inexistent)
2. OD sesizeaza ca informatiile trimise in mesaj nu permit punerea in aplicare a contractului de retea (ex: POD gresit)

Propunerea este sa folosim urmatorul mecanism in de feedback:

1. POSF nu va mai ruta mesajele catre ceilalti participanti la piata daca nu trece de corelarile la nivelul bazei de date. In cazul in care mesajul nu poate fi interpretat corect va emite NotificationErrorMessage catre autorul mesajului marcand in reasonDesc eroarea pe care a intampinat-o, cu reason="EROARE_PROCESARE". Impactul acestei schimbari este ca toti cei care lucreaza cu API trebuie sa interpreteze aceste notificari iar daca le-au primit sa retrimita mesajul gresit intr-o forma corectata.
2. OD emite NotificationPublishedByOperator cu reason="EROARE_PROCESARE" iar la reasonDesc scrie motivele pentru care nu poate procesa mesajul venit de la FZ

Data de la care aceasta schimbare poate intra in mediul POSF productie este jumatatea lunii Februarie.

[EDistributie]

Buna ziua! In calitate de OD, daca primim un ContractSignedBySupplier pe care nu il procesa, raspundem cu NotificationPublishedByOperator cu reason="EROARE_PROCESARE" iar la reasonDesc completam motivul. Este corect mentinerea procesului suspendat pentru acel loc de consum, pana la primirea corectiei din partea furnizorului? Multumesc!

[APetreDGSR]

Buna ziua, Corelarea si oprirea rutarii mentionate pentru punctul 1 se vor efectua de POSF si in cazul in care Contract Signed by Supplier se completeaza cu previous supplier diferit de cel real/actual din baza de date? Multumesc,

[bogdannedelcu]

Buna ziua! In calitate de OD, daca primim un ContractSignedBySupplier pe care nu il procesa, raspundem cu NotificationPublishedByOperator cu reason="EROARE_PROCESARE" iar la reasonDesc completam motivul. Este corect mentinerea procesului suspendat pentru acel loc de consum, pana la primirea corectiei din partea furnizorului? Multumesc!

Asa trebuie procedat

[bogdannedelcu]

Buna ziua, Corelarea si oprirea rutarii mentionate pentru punctul 1 se vor efectua de POSF si in cazul in care Contract Signed by Supplier se completeaza cu previous supplier diferit de cel real/actual din baza de date? Multumesc,

sau alte situatii cand informatiile din mesaj nu se coreleaza cu ce exista in baza de date.

[EDistributie]

Buna ziua! In calitate de OD, daca primim un ContractSignedBySupplier pe care nu il procesa, raspundem cu NotificationPublishedByOperator cu reason="EROARE_PROCESARE" iar la reasonDesc completam motivul. Este corect mentinerea procesului suspendat pentru acel loc de consum, pana la primirea corectiei din partea furnizorului? Multumesc!

Asa trebuie procedat

Dupa ce OD va suspenda fluxul eronat care sunt urmatorii pasi?

Exemplu de scenariu:

• Furnizorul anuleaza fluxul transmis eronat --> prin NotificationPublishedBySupplier cu campul reason completat ?
• Furnizorul corecteaza si generaza un nou flux de acelasi tip cu acelasi startingDate sau cu startingDate diferit de cel initial?
• OD proceseaza fluxul corect

Va rugam confirmare sau un exemplificare prin alt mod de lucru.

[APetreDGSR]

Buna ziua, Corelarea si oprirea rutarii mentionate pentru punctul 1 se vor efectua de POSF si in cazul in care Contract Signed by Supplier se completeaza cu previous supplier diferit de cel real/actual din baza de date? Multumesc,

sau alte situatii cand informatiile din mesaj nu se coreleaza cu ce exista in baza de date.

Va rugam sa includeti in aceste situatii si cazul in care se transmite o cerere de orice tip cu un POD/CLC eronat (care nu exista in baza de date POSF in portofoliul operatorulul de distributie din mesaj), astfel incat nici acestea sa nu mai fie rutate. Multumim!

[Chirtes-Daniel-EER]

Buna ziua,

Intelegem ca in lista de excludere mesaje initiate de catre FN/FA la mesajele transmise in POSF, POSF va returna in cazul erorii Place with PODCLC: XXXX not found . In urma analizei interne facuta pe mesjele transmise pana in acest moment acesta eroare pote fi cauzata din 2 motive:

1. POD/CLC transmis eronat
2. POD/CLC nu este actualizat in POSF de catre OR

Din acest motiv va rugam sa ne precizati cum sa procedam in cazul in care primim NotificationErrorMessage din POSF in principal pe punctul 2 de mai sus.

Tinind cont de punctul 2 de mai sus venim cu intrebarea - care este motivul pentru care se doreste sa se opresca mesajle POD not found la FN/FA fara sa avem certitudinea ca POD-ul este eronat.

Multumim

[EDistributie]

Buna ziua! In calitate de OD, daca primim un ContractSignedBySupplier pe care nu il procesa, raspundem cu NotificationPublishedByOperator cu reason="EROARE_PROCESARE" iar la reasonDesc completam motivul. Este corect mentinerea procesului suspendat pentru acel loc de consum, pana la primirea corectiei din partea furnizorului? Multumesc!

Asa trebuie procedat

Dupa ce OD va suspenda fluxul eronat care sunt urmatorii pasi?

Exemplu de scenariu:

• Furnizorul anuleaza fluxul transmis eronat --> prin NotificationPublishedBySupplier cu campul reason completat ?
• Furnizorul corecteaza si generaza un nou flux de acelasi tip cu acelasi startingDate sau cu startingDate diferit de cel initial?
• OD proceseaza fluxul corect

Va rugam confirmare sau un exemplificare prin alt mod de lucru.

Va rog confirmare. Multumesc!