Propunere modificari rutari mesaje

[bogdannedelcu]

In vederea eliminarii anumitor mesaje trimise catre Fostul Furnizor (previousSupplier) propunem modificarea rutarii de mesaje fata de cum este mentionat acum in tabelele de pe GIT. Modificarile nu au un impact restrictiv asupla implementarilor de API asa ca va rugam sa ne transmiteti feedback daca remarcati cazuri de exceptie de la aceste reguli.

1. ContractChangedInfo – nu se va mai trimite la previousSupplier
2. ContractCancelledBySupplier sau ContractCancelledByClient se trimite la previousSupplier doar daca suntem in cele 14 zile de razgandire. Astfel regula care se va aplica este: contract.date + 14 > today => mesajul se trimite la previousSupplier. Pe cale de consecinta mesajele de anulare contract care sunt trimise in afara intervalului de 14 zile pot sa nu mai contina previousSupplier corelat cu isNewContract.
3. ContractNetworkSignedBySupplier – nu se mai trimite catre previousSupplier

UPDATE: Modificarile au fost actualziate pe productie in data de 13.12.2022

[ItSupportRenovatioTrading]

1. ContractChangedInfo – nu se va mai trimite la previousSupplier => nu mai este obligatoriu pe niciun mesaj ContractChangedInfo ?
2. conform formulei de calcul contract.date nu va fi aceeasi cu data semnarii contractului? parerea mea este ca se pierde trasabilitatea informatiilor comerciale daca folosim contract.date ca data efectiva. logic ar fi sa ai 3 date pe un contract:

   Date = data semnare contract StartDate = data intrare furnizare EndDate = data final furnizare

si ar avea mai mult sens pe un CCBS sa pui contract.EndDate ca data efectiva a iesirii acelui POD din relatia comerciala cu FZ. dar, poate in sistemul POSF definitia contract.Date este fie alta, fie dinamica... si doi la mana, contract.date + 14 > today inseamna ca data rezilierii este in viitor, dar mesajul se proceseaza azi.. sau zilnic? sau cum se ajunge la o asa verificare?? nu stiu cum sa abordez o astfel de verificare, putem avea 2-3 exemple?

3. mie, ca furnizor anterior, cred ca mi-ar pasa mai mult sa stiu daca noul furnizor a primit confirmarea de transfer de la OD. Adica noul furnizor sa fi primit ContractNetworkChangedInfo , .. in rest din punctul meu de vedere ContractNewtworkSignedBySupplier este irelevant pentru mine ca vechi furnizor, ceea ce face ca decizia de la punctul 3 sa fie una buna.

[florinser]

Legat de acest topic, pentru punctul 2 (Contract Cancelled) va rog sa clarificati urmatoarele:

1. Cand emitem ContractCancelledBySupplier: Facem o reziliere la cerere client, dupa 6 luni de contract. Ce ar trebui sa completam la “previousSupplier”?

2. Cand primim ContractCancelledBySupplier si suntem previousSupplier -> asta inseamna ca a fost la noi ca FZ, a plecat la alt furnizor si ulterior s-a razgandit in 14 zile:

   • Dupa repunerea contractului anterior ce mesaje ar trebui sa trimita FZ-rii (atat cel la care revine cat si cel la care s-a razgandit) catre POSF? va rog sa tineti cont si de faptul ca este posibil ca FZ de la care a plecat sa fi procesat deja mesajul prin care s-a facut schimbarea de FZ (contractsignedbysupplier), ceea ce inseamna ca a reziliat ctr in sistemul sau.
   • Ce mesaje ar trebui sa primeasca operatorul si cum ar trebui sa le interpreteze?

[Chirtes-Daniel-EER]

Multumim tare mult de initiativa, pentru a avea aceiasi intelegere comuna va rugam, in masura timpului disponibil, sa stabilm o discutie comuna baza pe cele 3 propuneri de mai sus coroborate cu reglementarile in vigoare. Va multumim

[AndreeaCristinaStoica]

@bogdannedelcu

Regula cu privire la contract.date + 14 nu este suficienta pentru obligativitatea completarii sectiunii de PreviousSupplier pt ca nu tine cont in totalitate de ce spune legislatia si anume faptul ca acel contract si-a produs sau nu efectele la data renuntarii. (art 47 ord 3) prin urmare un astfel de mesaj ar trebui sa fie rutat si sa contina previous trader doar in situatia in care :

1. renuntarea s-a facuta la o data < contract.date+14 SI
2. renuntarea s-a facut la o data < contract.startDate ( adica contractul nu si-a produs inca efectele)

pentru situatia in care contract start date >= data renuntare si in toate celelalte situatii de reziliere la cererer client sau conditii comerciale NU trebuie sa avem obligativitate pe inserare previous trader ( pt ca nu mai exista rel comerciala cu previous trader).

In momentul de fata este inserat fara nicio baza legala o astfel de obligativitate si avem sute de cererei in eroare care nu pot fi deblocate

Multumesc

[AndreeaCristinaStoica]

@bogdannedelcu

1. NU mai faceti modificari neanalizate si neplanificate direct in productiv. este absolut inadmisibil un astfel de mod de lucru, complet distructiv si nesustenabil. Va rog sa anlizati sa planificati si sa anuntati din timp astfel de modificari
2. Conditionarea de Contract.date pe mesajul contractSignedBySupplier nu are baza legala. ne puteti spune de ce a fost inserata? sunt contracte de furnizare care se semneaza cu clientul si cu o luna inainte de contract.StartDate si asta se intampla la 90% din locurile de consum noi. Toate aceste contracte sunt in eroare datorita conditionarilor inserate pe mesaj. va rugam sa ridicati aceste conditionari in cel mai scurt timp posibil
3. Mesajul ContractSignedBySupplier pentru tipurile de contract nou in care nu se schimba furnizorul insa se modifica titularul sau se semneaza alt contract comercial pentru acelasi titular dar cu alte conditii comerciale NU ar trebui sa existe obligativitate pentru PreviousSupplier. Ati inserat tot neanuntat si neplanificat aceasta obligativitate VA rugam macar sa nu rutati mesajul in situatia in care previous supplier.id = supplier.id

Multumesc

[bogdannedelcu]

3. Mesajul ContractSignedBySupplier pentru tipurile de contract nou in care nu se schimba furnizorul insa se modifica titularul sau se semneaza alt contract comercial pentru acelasi titular dar cu alte conditii comerciale NU ar trebui sa existe obligativitate pentru PreviousSupplier. Ati inserat tot neanuntat si neplanificat aceasta obligativitate VA rugam macar sa nu rutati mesajul in situatia in care previous supplier.id = supplier.id

mesajele nu se ruteaza inapoi la autor, aceasta regula acopera si cazul descris de dvs.