Sistem informațional de billing și facturare

6 Jan 2026, 22:54

Infrastructura hardware si responsabilitati

Va rugam sa clarificati explicit urmatoarele aspecte legate de infrastructura necesara pentru instalarea si operarea Sistemului Informational de Billing si Facturare: 1. Autoritatea contractanta (SA Energocom) va furniza integral infrastructura hardware / virtuala necesara (on-premise sau cloud privat), sau aceasta intra in responsabilitatea prestatorului? 2. In cazul in care infrastructura este furnizata de SA Energocom, va rugam sa specificati in mod concret: ○ tipul mediului (on-premise, cloud privat, altul); ○ configuratia minima garantata (CPU, RAM, storage, IOPS, retea); ○ existenta sau nu a unui cluster Kubernetes deja instalat si configurat enterprise-ready (HA, networking, storage classes, RBAC, monitoring de baza); ○ existenta resurselor necesare pentru: ■ asigurarea cerintelor de performanta (ex: import >500.000 inregistrari/ora); ■ cerintele de disponibilitate (99.5%); ■ RPO < 1 ora si RTO < 4 ore; ■ Disaster Recovery (site secundar, conectivitate, replicare). 3. In cazul in care NU exista un cluster Kubernetes functional la momentul inceperii proiectului: ○ va rugam sa confirmati daca SA Energocom va pune la dispozitie un Kubernetes gata instalat si configurat, sau ○ daca se asteapta ca prestatorul sa proiecteze, instaleze si configureze integral infrastructura Kubernetes, caz in care va rugam sa clarificati daca acest efort este inclus in obiectul contractului si bugetul alocat. 4. Va rugam sa clarificati si responsabilitatea pentru infrastructura necesara indeplinirii cerintelor de: ○ backup criptat si stocat separat geografic; ○ testare periodica a backup-urilor; ○ Disaster Recovery (hardware, networking, licente, acces). Aceste clarificari sunt necesare pentru a delimita corect responsabilitatile dintre autoritatea contractanta si prestator si pentru a evita riscuri majore de neconformitate tehnica in faza de implementare si acceptanta.

6 Jan 2026, 22:55

Fezabilitatea livrarii raportat la resurse, buget, termen si complexitate

Va rugam sa clarificati direct si fara echivoc cum considera autoritatea contractanta ca este fezabila livrarea, in termenul de 24 de saptamani si cu echipa minima solicitata (1 Developer Backend si 1 Developer Frontend, in cadrul unei echipe totale de 6 persoane), a unui sistem care trebuie sa indeplineasca cumulativ cerintele de mai jos, in conditiile in care acestea descriu o implementare enterprise completa, nu doar dezvoltare de business logic. Fara limitare, documentatia impune sau implica urmatoarele cerinte: A. Arhitectura, platforma si operare ● arhitectura pe microservicii; ● containerizare Docker si orchestrare Kubernetes; ● configurare Kubernetes enterprise-ready (HA, networking, storage, RBAC, policies), inclusiv daca acesta nu este deja disponibil in mediul beneficiarului; ● observability complet: monitorizare, metrici, dashboards, alerte si incident response, folosind instrumente tip Prometheus/Thanos, AlertManager, Grafana (si integrarea acestora cu serviciile); ● logging centralizat si auditabil; ● mecanisme de procesare asincrona pe batch/queue; ● Elasticsearch/Solr pentru cautare; ● Redis pentru caching; ● Kafka/RabbitMQ pentru messaging/evenimente; ● MinIO/S3 pentru documente si PDF-uri; ● CI/CD complet configurat si operational (build, test, scanari, deploy), plus Git workflow; ● scripturi/instrumente de administrare si operare. B. Performanta, scalabilitate si volume ● timpi de raspuns enterprise-grade: ○ <3 secunde pentru operatii standard; ○ <2 secunde pentru cautari; ○ feedback vizual pentru operatii >1 secunda; ● minim 50 utilizatori concurenti, optim 100+; ● volum operational: ~900.000 consumatori (minim 1.000.000 in tabelul de performanta), cu cerinta de scalare pe orizontala; ● import in lot: minim 500.000 inregistrari/ora (optim 1.000.000+/ora); ● procesare asincrona scalabila cu: ○ stop/resume; ○ retry/backoff; ○ idempotenta; ○ persistenta date brute pentru audit; ○ izolare batch-uri si rollback; ○ monitorizare progres si raportare detaliata; ○ audit complet pe actiuni. C. Securitate ● autentificare/autorizare: JWT si RBAC; ● filtrare acces pe adrese IP (allow-list); ● 2FA obligatoriu (cel putin pentru Admin) si SSO; ● integrare cu MS Entra (SSO/2FA) si integrare cu MPass; ● rate limiting la login si la API, backoff progresiv, CAPTCHA dupa 5 incercari esuate, plus blocare automata cont dupa 5 incercari esuate; ● management chei si secrete in HSM/Key Vault, cu rotatie <=90 zile si audit acces; ● OAuth 2.0 / OpenID Connect pentru clienti externi, scopes/audience, JWKS, revocare token, certificate TLS cu durata scurta de viata; ● criptare TLS 1.3 in tranzit si AES-256 in repaus; ● WAF si conformitate OWASP Top 10; ● centralizare loguri, integrare cu SIEM, retentie diferentiata, protectie integritate loguri (WORM); ● SAST/DAST in CI/CD, SCA/scanari dependinte, revizuire cod pentru componente critice; ● penetration testing trimestrial (mentionat) si anual de catre terta parte (mentionat separat); ● pseudonimizare/anonimizare in medii de test, mecanisme GDPR (inclusiv dreptul la stergere/restrictionare), DPIA pentru fluxuri sensibile; ● CIS Benchmarks, hardening OS/K8s/DB, namespace isolation, network policies in Kubernetes; ● patch management lunar, ferestre de mentenanta, urmarire CVE/KEV si remediere prioritara. D. Disponibilitate, backup si continuitate ● disponibilitate 99.5% in programul de lucru (8:00–18:00, luni–vineri); ● RTO < 4 ore si RPO < 1 ora; ● backup-uri zilnice automate, criptate, stocate separat geografic, cu chei distincte si test restaurare lunar; ● monitorizare 24/7 cu alerte automate; ● Disaster Recovery Plan complet, cu site secundar si failover automat pentru servicii critice; ● health-checks, circuit breakers, retry/backoff, testare periodica a planului DR (cel putin semestrial). E. UI/UX, accesibilitate si utilizabilitate ● interfata web responsive (desktop pana la 4K), multi-browser (ultimele 2 versiuni Chrome/Firefox/Edge/Safari); ● multilingv: Romana obligatoriu (alte limbi optional); ● accesibilitate WCAG 2.1 nivel AA; ● navigare intuitiva, meniuri contextuale; ● cautare in timp real; ● ghiduri contextuale, tooltips si FAQ; ● timp invatare <2 ore pentru operatii de baza si completare sarcini <5 minute (cerinte care necesita operationalizare si clarificare). F. Integrari externe, API-uri si documentare ● integrare completa prin API Gateway cu: ○ API Comert (bidirectional); ○ API Bancile (webhook-driven conform caietului); ○ API Contabilitate (bidirectional); ○ clasificatoare nationale; ○ platforma de raportare ANRE; ● API Gateway cu autentificare/autorizare, rutare, validare, audit, rate limiting, gestionare erori standard; ● expunere API-uri cu acces complet (GET) la: calcule, istoric consumator, penalitati, plati, solduri/restante, facturi, recalculari, rapoarte generale cu filtre; ● documentatie OpenAPI/Swagger pentru toate API-urile. G. Testare si calitate ● unit tests si integration tests; ● testare performanta cu volume mari (900.000+); ● testare securitate conform OWASP; ● anonimizare date in test; ● pilot si feedback utilizatori; ● raport complet de testare si integrare.

6 Jan 2026, 22:56

Fezabilitatea livrarii raportat la resurse, buget, termen si complexitate

Va rugam sa clarificati direct si fara echivoc cum considera autoritatea contractanta ca este fezabila livrarea, in termenul de 24 de saptamani si cu echipa minima solicitata (1 Developer Backend si 1 Developer Frontend, in cadrul unei echipe totale de 6 persoane), a unui sistem care trebuie sa indeplineasca cumulativ cerintele de mai jos, in conditiile in care acestea descriu o implementare enterprise completa, nu doar dezvoltare de business logic. Fara limitare, documentatia impune sau implica urmatoarele cerinte: A. Arhitectura, platforma si operare ● arhitectura pe microservicii; ● containerizare Docker si orchestrare Kubernetes; ● configurare Kubernetes enterprise-ready (HA, networking, storage, RBAC, policies), inclusiv daca acesta nu este deja disponibil in mediul beneficiarului; ● observability complet: monitorizare, metrici, dashboards, alerte si incident response, folosind instrumente tip Prometheus/Thanos, AlertManager, Grafana (si integrarea acestora cu serviciile); ● logging centralizat si auditabil; ● mecanisme de procesare asincrona pe batch/queue; ● Elasticsearch/Solr pentru cautare; ● Redis pentru caching; ● Kafka/RabbitMQ pentru messaging/evenimente; ● MinIO/S3 pentru documente si PDF-uri; ● CI/CD complet configurat si operational (build, test, scanari, deploy), plus Git workflow; ● scripturi/instrumente de administrare si operare. B. Performanta, scalabilitate si volume ● timpi de raspuns enterprise-grade: ○ <3 secunde pentru operatii standard; ○ <2 secunde pentru cautari; ○ feedback vizual pentru operatii >1 secunda; ● minim 50 utilizatori concurenti, optim 100+; ● volum operational: ~900.000 consumatori (minim 1.000.000 in tabelul de performanta), cu cerinta de scalare pe orizontala; ● import in lot: minim 500.000 inregistrari/ora (optim 1.000.000+/ora); ● procesare asincrona scalabila cu: ○ stop/resume; ○ retry/backoff; ○ idempotenta; ○ persistenta date brute pentru audit; ○ izolare batch-uri si rollback; ○ monitorizare progres si raportare detaliata; ○ audit complet pe actiuni. C. Securitate ● autentificare/autorizare: JWT si RBAC; ● filtrare acces pe adrese IP (allow-list); ● 2FA obligatoriu (cel putin pentru Admin) si SSO; ● integrare cu MS Entra (SSO/2FA) si integrare cu MPass; ● rate limiting la login si la API, backoff progresiv, CAPTCHA dupa 5 incercari esuate, plus blocare automata cont dupa 5 incercari esuate; ● management chei si secrete in HSM/Key Vault, cu rotatie <=90 zile si audit acces; ● OAuth 2.0 / OpenID Connect pentru clienti externi, scopes/audience, JWKS, revocare token, certificate TLS cu durata scurta de viata; ● criptare TLS 1.3 in tranzit si AES-256 in repaus; ● WAF si conformitate OWASP Top 10; ● centralizare loguri, integrare cu SIEM, retentie diferentiata, protectie integritate loguri (WORM); ● SAST/DAST in CI/CD, SCA/scanari dependinte, revizuire cod pentru componente critice; ● penetration testing trimestrial (mentionat) si anual de catre terta parte (mentionat separat); ● pseudonimizare/anonimizare in medii de test, mecanisme GDPR (inclusiv dreptul la stergere/restrictionare), DPIA pentru fluxuri sensibile; ● CIS Benchmarks, hardening OS/K8s/DB, namespace isolation, network policies in Kubernetes; ● patch management lunar, ferestre de mentenanta, urmarire CVE/KEV si remediere prioritara. D. Disponibilitate, backup si continuitate ● disponibilitate 99.5% in programul de lucru (8:00–18:00, luni–vineri); ● RTO < 4 ore si RPO < 1 ora; ● backup-uri zilnice automate, criptate, stocate separat geografic, cu chei distincte si test restaurare lunar; ● monitorizare 24/7 cu alerte automate; ● Disaster Recovery Plan complet, cu site secundar si failover automat pentru servicii critice; ● health-checks, circuit breakers, retry/backoff, testare periodica a planului DR (cel putin semestrial). E. UI/UX, accesibilitate si utilizabilitate ● interfata web responsive (desktop pana la 4K), multi-browser (ultimele 2 versiuni Chrome/Firefox/Edge/Safari); ● multilingv: Romana obligatoriu (alte limbi optional); ● accesibilitate WCAG 2.1 nivel AA; ● navigare intuitiva, meniuri contextuale; ● cautare in timp real; ● ghiduri contextuale, tooltips si FAQ; ● timp invatare <2 ore pentru operatii de baza si completare sarcini <5 minute (cerinte care necesita operationalizare si clarificare). F. Integrari externe, API-uri si documentare ● integrare completa prin API Gateway cu: ○ API Comert (bidirectional); ○ API Bancile (webhook-driven conform caietului); ○ API Contabilitate (bidirectional); ○ clasificatoare nationale; ○ platforma de raportare ANRE; ● API Gateway cu autentificare/autorizare, rutare, validare, audit, rate limiting, gestionare erori standard; ● expunere API-uri cu acces complet (GET) la: calcule, istoric consumator, penalitati, plati, solduri/restante, facturi, recalculari, rapoarte generale cu filtre; ● documentatie OpenAPI/Swagger pentru toate API-urile. G. Testare si calitate ● unit tests si integration tests; ● testare performanta cu volume mari (900.000+); ● testare securitate conform OWASP; ● anonimizare date in test; ● pilot si feedback utilizatori; ● raport complet de testare si integrare. Toate acestea de mai sus, inainte de a incepe dezvoltarea functionalitatilor de business de care are in fapt nevoie beneficiarul! H. Cerinte functionale majore (in paralel cu cele tehnice) ● import date din API Comert pentru consumatori/locuri de consum/indici; ● calcul consumuri si valori financiare: ○ PF vs PJ; ○ 3 tipuri presiune (joasa/medie/inalta); ○ conversie m3 -> kWh pe baza capacitatii calorice; ○ tarife configurabile fara modificari de cod; ○ TVA, penalitati; ○ perioade si subperioade cu tarife diferite; ● recalculari complexe cu versionare si fara modificare/stergere istoric; ● generare facturi ca entitati logice, cu versionare, rapoarte de generare/accesare, export date pentru tipar, grafice etc.; ● integrare bancara cu prevenire dubla procesare, monitorizare tranzactii si audit; ● dashboard operational complet (control procese import/calcul, rezultate, tarife, rapoarte, user management cu RBAC). Solicitarile noastre de clarificare 1. Va rugam sa indicati explicit ce componente din lista de mai sus sunt deja furnizate „as-is” de catre SA Energocom (ex: Kubernetes functional si enterprise-ready, CI/CD existent, monitorizare/observability existente, SIEM, Key Vault/HSM, WAF, DR site, storage S3/MinIO, Kafka/RabbitMQ, Elasticsearch, Redis, etc.) si deci nu intra in livrarea prestatorului. 2. Va rugam sa confirmati care cerinte sunt obligatorii pentru acceptanta si Go-Live si care sunt acceptate ca livrare etapizata ulterior sau pe care Autoritatea contractanta le considera optionale, avand in vedere termenul de 24 de saptamani. 3. Va rugam sa explicati pe ce baza a fost stabilita echipa minima (in special 1 BE + 1 FE), in raport cu cerintele enterprise de mai sus (inclusiv Kubernetes, CI/CD, observability, securitate avansata, integrari si volum), care in practica necesita eforturi dedicate semnificative chiar si fara implementarea logica de business. 4. Va rugam sa confirmati ca ofertantii pot propune dimensionarea echipei peste minimul indicat si/sau o planificare realista pe faze, fara ca oferta sa fie considerata neconforma, avand in vedere ca in forma actuala cerintele sunt disproportionate fata de resurse, buget si termen.

6 Jan 2026, 22:58

Drepturi de proprietate intelectuala si utilizarea codului proprietar

Va rugam sa clarificati explicit regimul de proprietate intelectuala aplicabil in cadrul acestui proiect, dupa cum urmeaza: 1. Este permis scenariul in care sistemul este dezvoltat pe baza unei platforme existente, cu cod proprietar al prestatorului, iar: ○ componentele dezvoltate specific pentru SA Energocom (customizari, adaptari, integrari, extensii) sunt transferate integral in proprietatea SA Energocom; ○ codul de baza al platformei ramane proprietatea prestatorului? 2. In cazul in care nu este permis utilizarea unei platforme existente si se solicita dezvoltarea integrala a sistemului de la zero, va rugam sa clarificati daca: ○ prestatorul isi poate pastra drepturile de utilizare, reproducere si reutilizare a codului dezvoltat, in paralel cu drepturile depline acordate SA Energocom; ○ se accepta un regim de co-proprietate sau drepturi neexclusive, astfel incat drepturile partilor sa nu se limiteze reciproc. 3. Prin sintagma „cod sursa complet cu drepturi nelimitate”, autoritatea contractanta intelege: ○ exclusivitate absoluta asupra codului (inclusiv interdictia reutilizarii de catre prestator), sau ○ drepturi nelimitate de utilizare, modificare si exploatare pentru SA Energocom, fara a exclude drepturile prestatorului asupra aceluiasi cod? Clarificarea acestor aspecte este esentiala pentru definirea corecta a modelului de livrare, pentru protejarea drepturilor de proprietate intelectuala ale partilor si pentru evitarea unor interpretari restrictive care pot afecta participarea operatorilor economici cu solutii mature, enterprise-grade.

6 Jan 2026, 22:58

Clarificari privind cerintele tehnice (Capitolul 5)

Va rugam sa clarificati urmatoarele aspecte din Capitolul 5 – Cerinte tehnice: 1. Alerte si notificari ○ Ce tipuri de alerte si notificari sunt asteptate (operationale, functionale, de securitate, de business)? ○ Care sunt evenimentele concrete care trebuie sa genereze alerte? ○ Prin ce canale se asteapta livrarea alertelor (UI, email, SMS, webhook etc.)? 2. Cautare in timp real ○ Ce entitati trebuie sa poata fi cautate in timp real (ex: consumatori, contracte, locuri de consum, facturi, plati, recalculari)? ○ Ce criterii de cautare sunt necesare pentru fiecare entitate? 3. Baza de date ○ Documentatia mentioneaza explicit PostgreSQL. ○ Va rugam sa confirmati daca MS SQL Server este acceptat ca alternativa, in cazul in care sunt respectate toate cerintele functionale si non-functionale. 4. Tehnologii recomandate (pct. 5.2.1) ○ Avand in vedere ca acestea sunt mentionate ca „recomandate”, va rugam sa confirmati ca sunt acceptate si alte stack-uri tehnologice, cu conditia indeplinirii cerintelor de arhitectura, performanta si securitate. ○ Va rugam sa precizati care este obiectivul urmarit prin recomandarea tehnologiilor mentionate (ex: scalabilitate, mentenanta, standardizare), pentru a permite ofertantilor sa propuna solutii echivalente din punct de vedere tehnic, probabil fiind cel mai relevant atingerea indicatorilor de performanta doriti. Aceste clarificari sunt necesare pentru a evita interpretari diferite ale cerintelor tehnice si pentru a permite formularea unor oferte comparabile, corect dimensionate si conforme cu intentia reala a autoritatii contractante.

6 Jan 2026, 22:59

Clarificari privind integrarile externe obligatorii

Documentatia descrie un volum semnificativ de integrari externe critice (Comert, Bancile, Contabilitate), insa nu defineste in mod concret sistemele tinta, rolul fiecaruia, responsabilitatile partilor si fluxurile reale de date. In forma actuala, cerintele sunt insuficient definite pentru a permite o estimare corecta a efortului si a riscurilor de implementare. Va rugam sa clarificati in mod structurat si detaliat urmatoarele aspecte: A. Clarificari generale privind integrarile externe 1. Va rugam sa listati explicit toate sistemele externe cu care Sistemul de Billing si Facturare trebuie sa se integreze, incluzand pentru fiecare: ○ denumirea sistemului; ○ rolul functional in ecosistem; ○ daca sistemul este intern SA Energocom sau apartine unui tert; ○ cine este responsabil pentru dezvoltarea, mentenanta si disponibilitatea fiecarui API. 2. Va rugam sa confirmati existenta mediilor de test (sandbox/UAT) pentru fiecare integrare externa si disponibilitatea documentatiei tehnice aferente (specificatii API, exemple request/response). B. Integrarea cu API Comert (5.4.7.2 si 5.4.7.3) 3. Va rugam sa clarificati ce reprezinta concret „API Comert”: ○ este un sistem intern SA Energocom sau un sistem extern? ○ este sursa unica si autoritativa pentru datele comerciale (clienti, contracte, locuri de consum, contoare, indici, tarife)? 4. Va rugam sa descrieti fluxurile reale de date intre Sistemul de Billing si API Comert, separat pentru: ○ date transmise catre Comert (ex: rezultate calcule, facturi, plati, penalitati, recalculari); ○ date receptionate din Comert (ex: clienti, contracte, locuri de consum, indici, ajustari). 5. Va rugam sa specificati cheile unice comune utilizate pentru corelarea entitatilor intre sisteme (client, contract, loc de consum, contor, factura). 6. In cazul cerintelor: ○ „recalcul per volum”, ○ „recalcul per sume”, ○ „recalcul pe perioada” va rugam sa furnizati exemple concrete de scenarii, incluzand: ○ obiectul recalcularii (loc de consum / factura / perioada); ○ datele primite prin API; ○ rezultatul asteptat in Sistemul de Billing. 7. Va rugam sa detaliati ce tipuri de ajustari si corectii financiare pot fi primite din Comert si cum trebuie tratate acestea (ex: override valori, diferente, corectii retroactive). C. Integrarea cu bancile (5.4.7.4) 8. Va rugam sa clarificati modelul real de integrare cu bancile, avand in vedere ca, in practica, sistemele bancare nu functioneaza prin integrare live directa cu fiecare furnizor: ○ se preconizeaza integrare directa prin API live cu fiecare banca? ○ sau model bazat pe plati initiate de client (ex: cod de bare), cu raportari periodice de incasari din partea bancilor? 9. Va rugam sa listati bancile concrete cu care este necesara integrarea si sa indicati: ○ daca exista documentatie API disponibila; ○ daca bancile pun la dispozitie medii de test. 10. Va rugam sa detaliati criteriile exacte de corelare a platilor cu facturile si consumatorii (ex: numar factura, cod client, cod loc de consum, suma, data). 11. Va rugam sa specificati statusurile posibile ale unei plati in sistem (ex: receptionata, validata, partiala, respinsa, procesata, duplicata). 12. In contextul cerintei de „prevenire procesare dubla”, va rugam sa clarificati cum se asteapta autoritatea contractanta sa fie gestionate platile multiple valide, inclusiv: ● mai multe plati pentru aceeasi factura; ● plati duplicate venite din surse diferite; ● plati efectuate dupa sold zero. 13. Va rugam sa clarificati cerinta privind „rapoarte privind intrarile financiare”: ● cate rapoarte sunt necesare; ● ce diferente functionale exista intre ele; ● de ce este necesara existenta mai multor rapoarte distincte. D. Integrarea cu sistemul de contabilitate (5.4.7.5 si 5.4.7.6) 14. Va rugam sa specificati sistemul/sistemele de contabilitate cu care trebuie realizata integrarea (denumire, vendor, versiune). 15. Documentatia prevede atat: ● export de date catre Contabilitate, cat si ● import de date din Contabilitate. Va rugam sa clarificati mecanismele concrete de evitare a duplicarii datelor, in special pentru plati, in situatia in care aceeasi plata poate tranzita ambele fluxuri. 16. Va rugam sa explicati ce inseamna concret: ● „Sistemul trebuie sa primeasca recalculari initiate din contabilitate”; ● „Sistemul trebuie sa primeasca corectii si ajustari contabile”, incluzand ce date se transmit, in ce format si ce efect functional au asupra facturilor, soldurilor si istoricului. E. Clarificari de responsabilitate si risc 17. Va rugam sa confirmati cine este responsabil in cazul indisponibilitatii sau neconformitatii API-urilor externe (Comert, banci, contabilitate) si cum se trateaza impactul asupra termenelor de livrare si acceptanta.

6 Jan 2026, 22:59

Clarificari privind cerintele de business si regulile de facturare

Documentatia contine cerinte tehnice si non-functionale extinse, insa nu defineste suficient de concret cerintele de business care determina logica de calcul, facturare, penalitati, scadenta, alocare plati, sold, template-uri de factura, rapoarte si operatiuni de recalculare. In lipsa acestor clarificari, nu este posibila estimarea corecta a efortului si nici asumarea responsabilitatii pentru corectitudinea facturarii. Va rugam sa clarificati in detaliu urmatoarele aspecte de business: A. Preturi, tarife si sursa preturilor pe loc de consum 1. Cum si de unde se preiau preturile/tarifele aplicabile pentru fiecare loc de consum? ○ sunt furnizate de „Comert”, de un sistem ANRE, de alt sistem intern, sau sunt introduse manual? ○ exista mai multe componente de pret (ex: componenta energie/gaz, transport, distributie, alte componente)? ○ cum se determina pretul aplicabil pe subperioade (ex: modificare tarif in timpul lunii)? 2. Care este structura completa de preturi (lista tuturor tipurilor de tarife/componente) si cum se aplica acestea in calculul facturii corelat cu cantitatile rezultate din indexi? B. Indexi, citiri, estimari si conversii 3. Indexii se primesc pentru fiecare contor: ○ de unde vin (distributie / Comert / alt sistem), prin ce canal (API, fisiere, alt mecanism) si in ce format? ○ ce campuri vin obligatoriu (index initial, index final, data inceput/data final, tip citire etc.)? 4. Exista conceptul de tipuri de citire (ex: estimat, citit, autocitit)? Daca da: ○ cum se prioritizeaza tipurile de citire in calcul? ○ cum se trateaza trecerea de la estimat la citit (regularizari)? 5. Cum se trateaza scenariile de inconsistente intre importuri, de tip: ○ in sistem exista index final X la perioada anterioara, iar la importul curent index initial Y este < X; ○ datele de inceput/sfarsit citire sunt suprapuse sau inversate; ○ lipsesc indexi (si se cere calcul mediu) – ce regula de calcul mediu se aplica? 6. Conversia m3 -> kWh: ○ de unde preluam capacitatea calorica (valoare fixa? variaza pe perioada/zone?) ○ cum se aplica in cazul subperioadelor? C. Penalitati (sursa, reguli, TVA, gratie) 7. Cum stim ce clienti/contracte au penalitati si cuantumul lor: ○ penalitatile se calculeaza exclusiv in sistemul nou sau sunt preluate din alt sistem? ○ care este sursa autoritativa? 8. Confirmati explicit regulile de calcul al penalitatilor: ○ penalitatea se calculeaza sau nu si la valoarea penalitatilor facturate anterior (dobanda la dobanda)? ○ penalitatile sunt sau nu purtatoare de TVA (si conform carei reguli legale din RM)? ○ exista perioada de gratie? daca da, care sunt regulile (per tip client/contract)? 9. De unde preluam datele necesare calculului penalitatilor (scadenta, plati alocate, sold)? D. Scadenta (sursa, configurare, reguli) 10. De unde preluam setarea privind data scadentei pe contracte/consumatori? 11. Ce reguli de calcul scadenta sunt posibile si trebuie implementate (exhaustiv), de exemplu: ● numar zile calendaristice / lucratoare de la emitere / transmitere / primire; ● o data fixa in luna; ● ultima zi din luna; ● reguli diferite PF vs PJ; ● exceptii (sarbatori, weekend etc.)? E. Alocarea platilor (reguli, exceptii, sub-inchiriere, plati multiple) 12. Care este logica oficiala de alocare a incasarilor la facturi, inclusiv ordinea de prioritate intre scenarii, de exemplu: ● plata cu referinta explicita la numar factura; ● alocare la cea mai veche factura neachitata; ● alocare pe contract; ● alocare pe loc de consum. 13. Exista scenarii in care, in cadrul aceluiasi contract, exista locuri de consum sub-inchiriate si achitate separat de chiriasi? ● daca da, cum se face alocarea platilor distinct pe loc de consum si cum se reflecta soldul? 14. Cum se trateaza platile multiple valide: ● doua plati in aceeasi zi pe aceeasi factura; ● plati partiale; ● plati peste suma; ● plati dupa sold zero? F. Sold (definitie si calcul) 15. Care este logica de calcul a soldului: ● sold per contract sau sold per loc de consum? ● cum se reflecta alocarea platilor in sold, mai ales in scenarii cu multiple locuri de consum? G. Facturare (single vs multi-loc, structura factura, reguli) 16. Confirmati daca se vor emite facturi care includ mai multe locuri de consum pe o singura factura (ex: clienti PJ cu mai multe puncte, lanturi retail). ● daca da, care este regula de grupare (per contract, per client, per OSD, per adresa etc.)? 17. Care este structura completa a facturii (campuri obligatorii, sume, componente, sold, termene, grafice) si regulile de calcul corelate cu cantitatile din indexii primiti? H. Template-uri, tipar, export si distributie 18. Exista deja definit template-ul de factura tiparibila care sa contina toate elementele mentionate (detalii, preturi, grafice, termene etc.)? ● daca da, solicitam sa fie puse la dispozitie template-urile existente. 19. Cate template-uri vor exista (minim) si care sunt diferentele (PF vs PJ, alte tipuri)? 20. Documentatia mentioneaza „exportarea datelor in format prestabilit pentru tipar”: ● care este exact formatul prestabilit (structura, campuri, extensie)? ● unde se exporta si catre cine se transmite (contabilitate / tipograf / alt sistem)? ● dupa ce regula de grupare/segmentare se transmite (OSD, localitate, adresa etc.)? 21. Anexele cu explicatii legislative si metode de plata: ● sunt generate/atasate automat de sistem sau sunt adaugate de printator? ● daca sunt generate de sistem, care este continutul si cine il furnizeaza? 22. Coduri de bare: ● se cer coduri de bare pe factura pentru procesare de printator si/sau pentru plata la automate/banci/offline? ● care este standardul, structura si continutul codului de bare? I. „Accesare factura” si rapoarte de accesare 23. Documentatia mentioneaza rapoarte privind facturile generate si „accesate”. ● ce inseamna exact „accesata” (vizualizata de cine? intern? client final? prin link securizat?) ● ce evenimente se considera acces (opening link, download, render, view in portal etc.)? J. Integrarea bancara – clarificare de model functional 24. Pentru cerintele de integrare bancara (interogare factura, initiere plata, confirmare), solicitam sa clarificati in detaliu: ● care este modelul real agreat cu bancile (live API vs raportari periodice); ● specificatiile request/response si metodele API; ● mecanismul de identificare factura/consumator (ce campuri se trimit); ● cum se trateaza imposibilitatea practica de a preveni plati duble la nivel bancar, si cum trebuie sistemul sa gestioneze aceasta situatie fara a respinge plati valide. K. Roluri si permisiuni 25. Confirmati rolurile ce trebuie implementate si matricea de permisiuni: ● ce are voie sa faca Admin vs Operator; ● exista si alte roluri in afara de cele doua mentionate? ● exista aprobari (SoD - Segregation of Duties) pentru actiuni critice si care sunt acestea? L. Recalculari – manualizare, volum si comportament asteptat 26. Pentru recalculari, documentatia impune selectare motiv, descriere detaliata si confirmare explicita inainte de finalizare. Va rugam sa explicati: ● ce volum de recalculari estimati si de ce este necesara manualizarea acestui flux; ● in ce scenarii recalcularea este manuala vs automata; ● daca acest flux se aplica doar exceptiilor sau ca proces curent. 27. „Verificare recalculari existente” si „afisare avertizari corespunzatoare”: ● ce inseamna concret „corespunzatoare” (warning vs blocare, reguli clare)? ● daca exista o recalculare anterioara, care este comportamentul asteptat (oprire, override, aprobare)? Aceste clarificari sunt esentiale pentru definirea corecta a regulilor de business si pentru evitarea implementarii unor logici presupuse, care pot conduce la rezultate incorecte din punct de vedere legal sau operational.

6 Jan 2026, 22:59

Tipologia utilizatorilor sistemului

Va rugam sa confirmati explicit daca: 1. Sistemul Informational de Billing si Facturare este destinat exclusiv utilizatorilor interni ai SA Energocom (operatori, administratori, personal financiar/IT); sau daca 2. Se prevede si acces pentru utilizatori externi (ex: clienti PF/PJ) pentru: ○ vizualizarea facturilor; ○ descarcarea documentelor; ○ accesarea istoricului de plati sau consum. In cazul in care nu se prevede acces pentru utilizatori externi, va rugam sa confirmati ca: ● orice referinta la „accesarea facturilor” se refera strict la acces intern sau la acces prin sisteme terte (banci, contabilitate, printatori), nu la un portal clienti. Aceasta clarificare este necesara pentru delimitarea corecta a scope-ului functional si pentru evitarea interpretarii ca fiind necesara dezvoltarea unui portal de clienti, care nu este descris explicit in documentatie.

6 Jan 2026, 23:00

Import date, corectitudinea acestora si responsabilitati

Va rugam sa clarificati in mod concret urmatoarele aspecte privind importul datelor si controlul proceselor operationale: 1. Sursa si mecanismul de import ○ De unde se importa efectiv datele (exclusiv din API Comert sau si din alte surse)? ○ Prin ce mecanism se realizeaza importul (API sincron, API asincron, fisiere, mesaje)? ○ In ce format vin datele (structura, campuri obligatorii)? 2. Corectitudinea datelor si responsabilitati ○ Cine garanteaza corectitudinea datelor importate (SA Energocom / sistemul sursa)? ○ Care este responsabilitatea prestatorului in cazul in care datele primite sunt incorecte, incomplete sau inconsistente? 3. Gestionarea inconsistentei de date Va rugam sa clarificati cum se asteapta sa fie tratate urmatoarele situatii concrete: ○ Index initial al perioadei curente < index final al perioadei anterioare; ○ suprapuneri sau inversari de intervale DataInceput – DataFinal; ○ diferente intre tipurile de citire (citit, autocitit, estimat); ○ corectii retroactive ale indexilor. 4. Estimari si exceptii ○ Exista posibilitatea de a primi indexi estimati? ○ Cine decide cand se folosesc estimari si pe baza caror reguli? ○ Cum se trateaza ulterior trecerea de la estimat la citit/autocitit? 5. Volum si limitari ale sistemului sursa ○ Sistemul din care se importa datele poate sustine in mod real volumul de >500.000 inregistrari/ora? ○ Ce se intampla daca sistemul sursa nu poate sustine acest volum (rate limiting, batch-uri mai mici, ferestre de import)? 6. Oprire, reluare si impact ○ In cazul opririi unui proces de import sau calcul, cum se asigura consistenta datelor? ○ Care este procesul operational asteptat pentru reluare si validare ulterioara? Aceste clarificari sunt esentiale pentru definirea corecta a responsabilitatilor, pentru evitarea disputelor legate de calitatea datelor si pentru implementarea unor mecanisme realiste si sustenabile de import si procesare.

6 Jan 2026, 23:00

Gestionarea tarifelor (valabilitate, aplicare, modificari)

Va rugam sa clarificati urmatoarele aspecte legate de definirea si aplicarea tarifelor in sistem: 1. Data de inceput a unui tarif ○ Un tarif poate incepe sa fie valabil in orice zi calendaristica, inclusiv in interiorul unei luni (ex: 23 ale lunii), sau ○ Tarifele sunt aplicabile exclusiv incepand cu prima zi a unei luni? 2. Aplicarea tarifelor in interiorul unei perioade ○ In cazul in care un tarif nou intra in vigoare in interiorul unei luni, se asteapta: ■ impartirea perioadei in subperioade cu tarife diferite? ■ calcul proportional al consumului si valorilor? Descrieti in detaliu cum doriti sa functioneze sistemul pentru aceste situatii. 3. Data de sfarsit a tarifelor ○ Avand in vedere ca tarifele reglementate sunt valabile pana la emiterea unui nou ordin ANRE, va rugam sa clarificati: ■ cum se stabileste „Data Sfarsit” pentru un tarif la momentul introducerii acestuia in sistem; ■ daca este acceptat ca un tarif sa aiba data de sfarsit necompletata pana la aparitia unui nou tarif. 4. Tipuri de tarife ○ Va rugam sa furnizati lista completa a tipurilor de tarife care trebuie gestionate in sistem. ○ Va rugam sa clarificati modul concret in care fiecare tip de tarif este utilizat in calculul facturii. Aceste clarificari sunt necesare pentru a alinia cerintele tehnice cu realitatea operationala si legislativa si pentru a evita implementarea unor mecanisme artificiale care nu reflecta modul real de aplicare a tarifelor reglementate.

6 Jan 2026, 23:00

Submodulul Rapoarte (volum, complexitate, filtrare)

Va rugam sa clarificati urmatoarele aspecte privind Submodulul Rapoarte: 1. Lista si complexitatea rapoartelor ○ Va rugam sa indicati rapoartele concrete pe care le doriti sau, cel putin: ■ numarul estimat de rapoarte simple; ■ numarul estimat de rapoarte de complexitate medie; ■ numarul estimat de rapoarte complexe. ○ Va rugam sa clarificati ce criterii defineste autoritatea contractanta pentru un raport simplu, mediu sau complex. 2. Filtrare si grupare ○ In documentatie se mentioneaza „filtrare rapoarte dupa OSD, tip contract, perioada”. ○ Va rugam sa confirmati daca: ■ rapoartele in sine sunt diferite in functie de aceste criterii, sau ■ datele din interiorul aceluiasi raport trebuie sa poata fi filtrate si grupate dupa aceste criterii. ○ Va rugam sa clarificati aceasta formulare pentru a evita interpretari diferite la acceptanta. 3. Raportare si performanta ○ Exista cerinte diferite de performanta pentru rapoarte simple vs complexe? ○ Exista rapoarte care trebuie generate in timp real sau toate sunt bazate pe date deja procesate? Aceste clarificari sunt necesare pentru a dimensiona corect mecanismele de raportare si pentru a evita extinderi necontrolate ale scope-ului pe parcursul implementarii.

6 Jan 2026, 23:01

Integrare API Comert (rol, fluxuri, chei de corelare)

Documentatia defineste API Comert ca fiind „sursa centrala si autoritativa a tuturor datelor comerciale” si, in acelasi timp, cere fluxuri bidirectionale intre Sistemul de Billing si Comert (atat “→ Comert”, cat si “← Comert”). In forma actuala, nu este suficient de clar ce este “Comert”, cum se delimiteaza responsabilitatile intre sisteme si care sunt cheile si payload-urile concrete, in special pentru recalculari si ajustari financiare. Va rugam sa clarificati punctual urmatoarele: 1. Ce reprezinta concret “Comert” (sistem/aplicatie/modul) si care este rolul lui operational in fluxul de billing: ○ este un sistem existent (in productie) sau urmeaza sa fie dezvoltat separat? ○ este “system of record” pentru: clienti, contracte, locuri de consum, contoare, indexi, perioade de citire, tip citire (estimat/citit/autocitit), tarife/preturi, scadente, penalitati? 2. Cheile comune / identificatorii unici utilizati pentru corelarea entitatilor intre Comert si Sistemul de Billing: ○ care este identificatorul unic pentru client (PF/PJ), contract, loc de consum (NLC?), contor, factura? ○ exista un ID unic de factura folosit de toate sistemele (Comert, Billing, Contabilitate, Bancile) sau exista mapare intre ID-uri? ○ va rugam sa confirmati daca exista un “master key” comun pentru toate entitatile sau trebuie implementata o tabela de mapare. 3. Pentru API Comerț – API Gateway ← Comerț (date primite din Comert), va rugam sa furnizati exemple concrete (payload minimal + campuri obligatorii) pentru cerintele: ○ API-COM-10 “recalcul per volum consumat” – se aplica la nivel de loc de consum, contor, contract sau factura? Cum se identifica exact obiectul recalculului? ○ API-COM-11 “recalcul pe sume si plati” – se transmit sume noi (override) sau doar diferente? Se transmit si instructiuni de realocare plati? ○ API-COM-12 “recalcul pe perioada” – cum se defineste perioada (luna calendaristica, interval date, subperioade)? Ce se intampla cu facturile deja emise pe acea perioada? ○ API-COM-13 “ajustari financiare” – ce tipuri de ajustari sunt permise (ex: discount, corectie retroactiva, anulare logica, regularizare) si cum trebuie reflectate (factura de regularizare, reflectare in factura curenta/urmatoare, note interne)? 4. Pentru API Comerț – API Gateway → Comerț (date furnizate catre Comert), va rugam sa clarificati care este setul minim de date pe care Billing trebuie sa il expuna catre Comert si cu ce scop operational, pentru cerintele: ○ API-COM-01/06 “calcule consumatori / date factura” ○ API-COM-02 “istoric consumator (consumuri, facturi, plati, penalitati)” ○ API-COM-03 “penalitati” ○ API-COM-04 “plati, solduri si restante” ○ API-COM-05 “recalculari” ○ API-COM-07 “rapoarte generale cu filtre” In mod concret: Comert foloseste aceste date pentru afisare in UI, pentru operatiuni (initiere recalcul), pentru raportare, sau pentru export catre alte sisteme? 5. Responsabilitatea pentru reguli si date: ○ Comert transmite doar date brute (indexi, contracte etc.) iar Billing aplica toate regulile de calcul, sau Comert transmite si reguli/parametri de calcul (preturi, scadente, exceptii, penalitati)? ○ in caz de discrepanta intre datele din Comert si rezultatele din Billing, care sistem este considerat autoritativ si care este fluxul de rezolvare? 6. Cerintele de disponibilitate si limitari pentru API Comert: ○ exista SLA / rate limits / ferestre de mentenanta ale API Comert? ○ exista un mecanism acceptat pentru “back-pressure” daca API Comert nu poate sustine volumul necesar (corelat cu import >500k/h)? Aceste clarificari sunt necesare pentru a evita implementarea pe presupuneri, in special pe zona de recalculari si ajustari financiare, unde lipsa exemplelor concrete duce inevitabil la interpretari diferite si risc de neconformitate.

6 Jan 2026, 23:01

Integrarea cu sistemele bancare (API Banci)

Va rugam sa clarificati in mod concret urmatoarele aspecte privind integrarea cu bancile: 1. Sisteme bancare si documentatie ○ Cu ce sisteme bancare trebuie realizata integrarea? ○ Pentru cate banci? ○ Exista documentatie tehnica oficiala (API, formate, protocoale) care poate fi pusa la dispozitie? 2. Mecanismul real de plata ○ Confirmati daca integrarea se realizeaza: ■ prin interogare live a sistemului de billing de catre banci, sau ■ prin utilizarea de coduri de bare / identificatori de plata, urmata de transmiterea ulterioara a incasarilor prin rapoarte periodice (periodice: zilnice / orare). ○ Va rugam sa descrieti fluxul real de plata, pas cu pas, asa cum este utilizat in prezent sau planificat, asa cum l-ati discutat cu banca/bancile partenera(e). 3. Corelarea platilor ○ Pe baza caror criterii se coreleaza platile cu: ■ facturile; ■ consumatorii; ■ locurile de consum? ○ Cum se trateaza: ■ platile fara referinta clara; ■ platile multiple pentru aceeasi factura in aceeasi zi; ■ platile duplicate raportate de sisteme diferite? 4. Statusuri de procesare ○ Care sunt statusurile posibile ale unei plati (ex: primita, validata, respinsa, alocata, partial alocata)? ○ Care sunt tranzitiile permise intre aceste statusuri? 5. Rapoarte privind intrarile financiare ○ Cate rapoarte diferite sunt necesare pentru intrarile financiare si care este scopul fiecaruia? ○ Exista diferente de continut sau doar de filtrare/grupare? ○ Va rugam sa justificati necesitatea mai multor rapoarte, daca este cazul. Aceste clarificari sunt necesare pentru a alinia cerintele documentatiei cu modul real de functionare al sistemelor bancare si pentru a evita implementarea unor fluxuri care nu pot fi sustinute operational.

6 Jan 2026, 23:01

Integrarea cu sistemele de contabilitate

Va rugam sa clarificati in mod explicit urmatoarele aspecte privind integrarea cu sistemele de contabilitate: 1. Import si export plati ○ Care este sistemul master pentru plati: sistemul de billing sau sistemul de contabilitate? ○ Cum se evita dublarea platilor, in situatia in care: ■ o plata este exportata din sistemul de billing catre contabilitate; ■ ulterior, aceeasi plata este retransmisa din contabilitate catre sistemul de billing? ○ Va rugam sa descrieti mecanismul concret de prevenire a duplicarii, avand in vedere ca pot exista mai multe plati valide pe aceeasi factura, in aceeasi zi, de la acelasi client. 2. Identificatori si corelare ○ Ce identificatori unici sunt utilizati pentru corelarea platilor intre sisteme? ○ Exista un identificator global de tranzactie sau se foloseste o combinatie de campuri? 3. Recalculari initiate din contabilitate ○ Ce inseamna concret „Sistemul trebuie sa primeasca recalculari initiate din contabilitate”? ○ Ce date sunt transmise efectiv (perioada, factura, sume, motiv)? ○ Ce actiuni trebuie sa efectueze sistemul de billing pe baza acestor date? 4. Corectii si ajustari contabile ○ Ce tipuri de corectii si ajustari contabile pot fi primite? ○ Care este impactul asteptat asupra: ■ facturilor; ■ platilor; ■ soldurilor? Aceste clarificari sunt necesare pentru a defini un flux contabil coerent, pentru a preveni dublarea datelor si pentru a asigura consistenta intre sistemul de billing si sistemele contabile.

6 Jan 2026, 23:02

Object storage (MinIO / S3)

Va rugam sa clarificati urmatoarele aspecte privind cerinta de object storage: 1. Prin mentiunea „MinIO/S3”, autoritatea contractanta solicita in mod explicit: ○ utilizarea MinIO instalat on-premise, sau ○ accepta orice solutie compatibila cu API-ul S3, inclusiv servicii de tip cloud public (ex: AWS S3)? 2. In cazul in care este acceptata utilizarea unui serviciu cloud compatibil S3: ○ cine furnizeaza si administreaza acest serviciu (SA Energocom sau prestatorul)? ○ exista restrictii privind locatia geografica a datelor? 3. In cazul in care se solicita explicit MinIO on-premise: ○ infrastructura necesara (hardware, storage, networking) este pusa la dispozitie de SA Energocom? ○ prestatorul are doar responsabilitatea configurarii si integrarii? Aceasta clarificare este necesara pentru a defini corect arhitectura de stocare a documentelor si pentru a evita presupuneri diferite privind mediul de operare si responsabilitatile partilor.

6 Jan 2026, 23:02

Cerinte de performanta si criterii de acceptanta

Va rugam sa clarificati explicit urmatoarele aspecte privind cerintele de performanta: 1. Criterii de acceptanta ○ Care dintre valorile mentionate (minime sau optime) sunt utilizate ca prag oficial de acceptanta a sistemului? ○ Valorile „optime” sunt: ■ obiective orientative, sau ■ cerinte obligatorii pentru acceptanta? 2. Metodologia de testare ○ Cum se vor testa cerintele de performanta inainte de Go-Live: ■ teste controlate de autoritatea contractanta? ■ teste realizate de prestator? ■ teste comune? ○ Ce volume de date si ce scenarii de incarcare vor fi utilizate la testare (numar utilizatori, volum consumatori, volume import)? 3. Mediul de testare ○ Testele de performanta se vor realiza: ■ in mediul de productie; ■ intr-un mediu de pre-productie? ○ Cine furnizeaza infrastructura pentru acest mediu? 4. Rezultate si remedieri ○ In cazul in care anumite praguri nu sunt atinse la prima rulare, care este procesul de remediere si retestare? ○ Exista un numar maxim de iteratii de testare acceptate? Aceasta clarificare este esentiala pentru a defini corect criteriile de acceptanta si pentru a evita situatii de blocaj contractual generate de interpretari diferite ale performantelor asteptate.

6 Jan 2026, 23:02

Disponibilitate, RPO/RTO, backup si Disaster Recovery

Va rugam sa clarificati explicit urmatoarele aspecte privind disponibilitatea si fiabilitatea sistemului: 1. Calculul disponibilitatii ○ Cum se calculeaza disponibilitatea de 99.5%, avand in vedere ca sistemul va fi instalat in infrastructura SA Energocom? ○ Care este metodologia concreta utilizata pentru masurare in faza de acceptanta? 2. RPO (Recovery Point Objective) ○ Va rugam sa confirmati ca SA Energocom va furniza infrastructura necesara (storage, replicare, networking) pentru a putea asigura RPO < 1 ora. ○ Care sunt mecanismele de replicare asteptate (snapshot, replicare sincrona/asincrona)? 3. RTO (Recovery Time Objective) ○ Va rugam sa confirmati ca SA Energocom va furniza resursele hardware si de retea necesare pentru atingerea RTO < 4 ore. ○ Care este scenariul de referinta utilizat pentru calculul RTO (failover, restaurare backup, DR site)? 4. Backup-uri ○ Ce se asteapta concret de la prestator in ceea ce priveste: ■ configurarea mecanismelor de backup; ■ testarea lunara a backup-urilor? ○ Cine este responsabil pentru rularea efectiva a backup-urilor si pentru stocarea acestora? 5. Disaster Recovery ○ Va rugam sa confirmati ca SA Energocom va pune la dispozitie toate resursele necesare pentru DR (hardware, networking, software, conectivitate intre site-uri). ○ Confirmati ca responsabilitatea prestatorului este elaborarea planului de Disaster Recovery (documentatie) si nu furnizarea infrastructurii DR. Aceste clarificari sunt esentiale pentru delimitarea corecta a responsabilitatilor si pentru evitarea asumarii unor obligatii care depasesc controlul prestatorului.

6 Jan 2026, 23:02

Cerinte de securitate (Cap. 5.5.4)

Va rugam sa clarificati explicit urmatoarele aspecte privind cerintele de securitate: 1. Blocare cont vs CAPTCHA ○ In documentatie se mentioneaza atat: ■ blocarea automata a contului dupa 5 incercari esuate, cat si ■ afisarea CAPTCHA dupa 5 incercari esuate. ○ Va rugam sa clarificati care este comportamentul corect asteptat, avand in vedere ca cele doua cerinte sunt contradictorii. 2. Protectia integritatii logurilor (WORM) ○ Ce intelege autoritatea contractanta prin „protectie integritate loguri (WORM)”? ○ Ce mecanism concret se asteapta sa fie implementat (ex: storage imutabil, semnare loguri, sistem dedicat)? 3. SIEM ○ Ce solutie SIEM este utilizata de SA Energocom? ○ Ce tip de loguri trebuie integrate in SIEM si cu ce nivel de detaliu? ○ Care este politica de retentie diferentiata (operational vs securitate)? 4. Testare de securitate ○ Documentatia mentioneaza: ■ teste de penetrare trimestriale; ■ teste anuale realizate de o terta parte. ○ Va rugam sa clarificati: ■ care dintre acestea sunt obligatorii in perioada contractuala; ■ cine este responsabil pentru executia lor; ■ cum se coreleaza cu durata contractului si perioada de suport post-livrare. 5. SAST / DAST / SCA ○ Pentru scanarile de dependinte si SAST/DAST in CI/CD: ■ cine furnizeaza toolurile necesare? ■ prestatorul are libertatea de a propune toolurile utilizate? 6. Backup-uri criptate si stocate separat geografic ○ Va rugam sa confirmati daca SA Energocom furnizeaza infrastructura necesara pentru stocare separata geografic. ○ Ce rol concret are prestatorul in testarea lunara a restaurarii backup-urilor? 7. Patching si hardening ○ Va rugam sa clarificati ce se asteapta concret de la prestator in ceea ce priveste: ■ politicile de patching; ■ hardening (OS, Kubernetes, baze de date), avand in vedere ca aceste activitati depind de controlul asupra infrastructurii. Aceste clarificari sunt necesare pentru a elimina contradictiile din cerintele de securitate si pentru a delimita corect responsabilitatile intre prestator si autoritatea contractanta.

6 Jan 2026, 23:03

Cerinte de utilizare si UX (Cap. 5.5.5)

Va rugam sa clarificati urmatoarele aspecte privind cerintele de utilizare: 1. Timp de invatare < 2 ore ○ Ce intelege autoritatea contractanta prin „operatii de baza”? ○ Care sunt functionalitatile concrete care trebuie sa poata fi invatate in acest interval? ○ Cum se masoara acest criteriu si cine il valideaza? 2. Completare sarcini < 5 minute pentru operatii frecvente ○ Care sunt „operatiile frecvente” vizate? ○ Va rugam sa confirmati ca acest timp se refera la interactiunea utilizatorului, fara a include timpii de procesare asincrona pe server. 3. Accesibilitate – WCAG 2.1 nivel AA ○ Avand in vedere ca sistemul este unul intern, inhouse, va rugam sa clarificati: ■ daca aceasta cerinta este obligatorie integral; ■ ce criterii WCAG sunt considerate aplicabile in acest context. 4. Ajutor integrat (ghiduri contextuale, tooltips, FAQ) ○ Ce intelege autoritatea contractanta prin: ■ ghiduri contextuale; ■ tooltips; ■ FAQ? ○ Exista un continut minim asteptat sau exemple concrete? Aceste clarificari sunt necesare pentru a putea implementa cerinte de UX masurabile si realiste si pentru a evita interpretari subiective la acceptanta.

6 Jan 2026, 23:03

Suport si garantie post-livrare (6 luni)

Va rugam sa clarificati in mod explicit urmatoarele aspecte privind suportul si garantia de 6 luni: 1. Domeniul suportului ○ Ce activitati sunt incluse in suport: ■ corectarea defectelor software? ■ ajustari minore functionale? ■ suport operational (monitorizare, restart servicii, interventii infrastructura)? ○ Va rugam sa confirmati ca suportul se refera exclusiv la componenta software livrata, nu la operarea infrastructurii. 2. Interval de suport ○ Va rugam sa confirmati ca SLA-ul se aplica luni–vineri, in timpul programului de lucru, asa cum este indicat in documentatie. ○ Exista cerinte de suport in afara programului de lucru? 3. Corelare cu cerintele tehnice ○ Avand in vedere cerintele din capitolele privind: ■ observability; ■ securitate; ■ backup si DR; va rugam sa clarificati ce responsabilitati concrete are prestatorul in perioada de suport si ce responsabilitati revin exclusiv SA Energocom. 4. Mod de lucru ○ Care este mecanismul de solicitare a suportului (ticketing, email, alt sistem)? ○ Exista un numar estimat de incidente pe luna utilizat la dimensionarea suportului? Aceste clarificari sunt necesare pentru a delimita clar obligatiile post-livrare si pentru a evita extinderea necontrolata a scope-ului contractului in faza de suport.

6 Jan 2026, 23:03

Transfer proprietate si drepturi asupra codului

Va rugam sa confirmati explicit regimul drepturilor de proprietate intelectuala aplicabil codului sursa livrat, dupa cum urmeaza: 1. Prin transferul „codului sursa complet cu drepturi nelimitate”, autoritatea contractanta intelege: ○ acordarea catre SA Energocom a unor drepturi nelimitate, neexclusive de utilizare, modificare si exploatare a codului, fara a restrictiona drepturile prestatorului; sau ○ transferul unor drepturi exclusive, care limiteaza sau elimina dreptul prestatorului de a reutiliza codul in alte proiecte. 2. Va rugam sa confirmati ca prestatorul isi pastreaza dreptul deplin de utilizare, reproducere si reutilizare a codului dezvoltat, inclusiv in alte proiecte, fara ca acest lucru sa afecteze in vreun fel drepturile SA Energocom asupra codului livrat. 3. In cazul in care autoritatea contractanta solicita exclusivitate, va rugam sa precizati explicit acest lucru, impreuna cu temeiul legal si impactul asupra modelului de ofertare. Aceasta clarificare este esentiala pentru definirea corecta a relatiei contractuale si pentru evitarea unor interpretari ulterioare care pot conduce la dispute juridice.

6 Jan 2026, 23:03

Garantie de oferta (1%)

Avand in vedere prevederile din Anuntul de participare referitoare la constituirea garantiei de oferta in cuantum de 1% din valoarea ofertei, va rugam sa clarificati urmatoarele: 1. Confirmati daca, pe langa scrisoarea de garantie bancara si transferul bancar, autoritatea contractanta accepta si utilizarea unei polite de asigurare de garantie, emisa de o societate de asigurari autorizata, ca instrument de garantare echivalent din punct de vedere juridic si financiar. 2. In cazul in care raspunsul este negativ, va rugam sa indicati temeiul legal expres care limiteaza constituirea garantiei de oferta exclusiv la formele mentionate in documentatia de atribuire. Mentionam ca utilizarea politelor de asigurare de garantie reprezinta o practica uzuala in procedurile de achizitie, contribuind la asigurarea unui tratament egal si nediscriminatoriu al operatorilor economici.

6 Jan 2026, 23:04

Draft contract (conditii juridice si comerciale)

Avand in vedere complexitatea proiectului, volumul de cerinte impuse prestatorului si riscurile asociate (tehnice, operationale si juridice), va rugam sa puneti la dispozitia ofertantilor un draft de contract care va sta la baza semnarii cu ofertantul castigator. De asemenea, va rugam sa il puneti la dispozitie intr-un timp util in care ofertantii sa aiba timp sa-l analizeze si sa revina cu intrebari de clarificare asupra acestuia. In mod specific, solicitam ca draftul de contract sa includa, fara a se limita la, urmatoarele aspecte: ● conditii de acceptanta (criterii, etape, termene); ● regimul penalitatilor si al raspunderii contractuale; ● clauze privind intarzierile cauzate de factori externi (ex: indisponibilitate API-uri externe, infrastructura beneficiarului); ● clauze privind proprietatea intelectuala si drepturile asupra codului sursa; ● clauze privind suportul si garantia post-livrare; ● mecanisme de modificare a cerintelor (change management); ● conditii de incetare, suspendare sau reziliere a contractului. Furnizarea draftului de contract este esentiala pentru formularea unei oferte conforme, realiste si responsabile si pentru evitarea unor interpretari ulterioare divergente asupra obligatiilor partilor

6 Jan 2026, 23:04

Confirmare inexistenta garantie de buna executie

Avand in vedere documentatia de atribuire publicata (Anuntul de participare si Caietul de sarcini), va rugam sa confirmati daca, in afara garantiei de oferta de 1% prevazute in Anuntul de participare, nu se solicita constituirea niciunei alte garantii pe durata derularii contractului, inclusiv garantie de buna executie. Aceasta clarificare este necesara pentru a asigura o intelegere unitara a conditiilor de participare si pentru a evita interpretari ulterioare diferite asupra obligatiilor ofertantului.

6 Jan 2026, 23:04

Licente third-party si costuri asociate

In contextul cerintelor tehnice din documentatie, care presupun utilizarea unor componente software standard si de infrastructura (ex: baze de date, solutii de monitorizare si observability, instrumente de securitate, CI/CD, scanare dependinte, SAST/DAST, SIEM, WAF etc.), va rugam sa clarificati urmatoarele: 1. Confirmati daca toate costurile aferente licentelor software third-party necesare pentru instalarea, operarea si utilizarea Sistemului (inclusiv, dar fara a se limita la: baze de date, instrumente de monitorizare, securitate, scanare cod, backup, SIEM, WAF) sunt: ○ suportate de autoritatea contractanta, sau ○ trebuie incluse integral in pretul ofertei. 2. Va rugam sa precizati daca autoritatea contractanta impune sau recomanda explicit utilizarea unor produse comerciale specifice (vendor, versiune) sau daca este acceptata utilizarea de solutii open-source, cu conditia indeplinirii cerintelor functionale, de performanta si securitate. 3. In cazul utilizarii de solutii open-source, va rugam sa clarificati daca exista restrictii privind tipul de licenta acceptata (ex: GPL, AGPL, LGPL, Apache, MIT), avand in vedere cerintele privind transferul drepturilor asupra codului si reutilizarea acestuia. 4. Va rugam sa confirmati daca, pe durata exploatarii sistemului, autoritatea contractanta va asigura reinnoirea si mentenanta licentelor third-party utilizate, acolo unde este cazul. Aceasta clarificare este necesara pentru o estimare corecta a costurilor totale, pentru evitarea unor riscuri juridice legate de licentiere si pentru asigurarea conformitatii solutiei livrate cu cerintele contractuale