Platforma de Management a Pieței de energie cu servicii de implementare

6 янв 2026, 14:52

Structura plăților (80% după livrarea echipamentelor / licențelor / serviciilor)

Având în vedere prevederile pct. 11 din Anunțul de participare, referitoare la structura achitărilor, respectiv: – Etapa II: achitarea a 80% din costul echipamentelor, licențelor livrate și serviciilor prestate „după livrare/prestare”, pe baza de procese-verbale de receptie partiala/totala, pentru fiecare categorie in parte; – Etapa III: achitarea sumei restante după implementarea platformei cu semnarea actului final de primire-predare, precum și prevederile Caietului de sarcini care disting explicit etape separate de „Delivery and installation of hardware equipment and 3rd party software” față de etapele de implementare a serviciilor, vă rugăm să clarificați următoarele aspecte esențiale privind mecanismul de plată: 1. Dacă achitarea celor 80% se realizează: – cumulativ, într-o singură tranșă, exclusiv după livrarea tuturor componentelor (echipamente, licențe și servicii), sau – etapizat, corespunzător fiecărei livrări/prestări efectuate și recepționate distinct (ex. echipamente hardware, licențe software, servicii). 2. Vă rugăm să confirmați în mod expres faptul că: – echipamentele hardware livrate și recepționate pot fi facturate și achitate integral imediat după livrare și recepție, independent de finalizarea serviciilor de implementare; – pentru fiecare etapă de livrare/prestare se va întocmi proces-verbal de recepție, care constituie baza facturării și achitării corespunzătoare. Considerăm că această clarificare este necesară pentru a asigura o corelare corectă între fluxul de livrare, recepție și plată, precum și pentru a permite ofertanților să structureze în mod adecvat oferta financiară și graficul de execuție, în conformitate cu prevederile documentației de atribuire.

6 янв 2026, 14:52

Infrastructura existenta (rack-uri, facilitati, networking, tape storage)

Avand in vedere prevederile Caietului de sarcini, cap. 2.6, precum si referintele privind instalarea si operarea platformei in infrastructura beneficiarului, va rugam sa clarificati urmatoarele aspecte necesare pentru dimensionarea corecta a solutiei tehnice si pentru elaborarea unei oferte conforme: 1. Va rugam sa precizati in mod expres daca rack-urile de 19” mentionate in Caietul de sarcini: – sunt puse la dispozitie de catre beneficiar sau – trebuie incluse in oferta de catre ofertant. In cazul in care rack-urile sunt puse la dispozitie de beneficiar, va rugam sa indicati spatiul disponibil (U liberi), limitarile de greutate, consumul electric disponibil per rack si conditiile de racire. 2. Va rugam sa descrieti facilitatile existente in centrele de date unde urmeaza a fi instalata solutia, inclusiv, fara a se limita la: – alimentarea electrica si nivelul de redundanta; – existenta UPS-urilor si a generatoarelor; – sistemele de climatizare; – responsabilitatile beneficiarului vs. ale ofertantului in ceea ce priveste operarea infrastructurii fizice. 3. In ceea ce priveste componenta de networking, avand in vedere ca in Caietul de sarcini se mentioneaza ca anumite elemente trebuie prevazute de ofertant, va rugam sa clarificati: – la ce echipamente de retea existente ale beneficiarului se va realiza interconectarea; – ce tipuri de interfete sunt necesare (ex. 1G, 10G, 25G etc.); – ce distante de cablare trebuie avute in vedere intre echipamente; – daca switch-urile de acces si/sau core sunt puse la dispozitie de beneficiar sau trebuie incluse in oferta. 4. Va rugam sa puneti la dispozitie o diagrama de infrastructura sau un document de specificatii tehnice care sa descrie mediul existent (hardware, retea, securitate), astfel incat ofertantii sa poata determina in mod unitar ce componente trebuie ofertate si ce componente sunt deja disponibile. 5. In ceea ce priveste referintele la “tape storage”, va rugam sa clarificati daca aceasta tehnologie este o cerinta obligatorie a solutiei sau doar o optiune posibila, precum si sa indicati cerintele concrete de backup si retentie care justifica utilizarea acesteia.

6 янв 2026, 14:53

Experienta similara (contracte derulate pe perioade >12 luni)

Avand in vedere cerinta privind experienta similara, respectiv obligatia de a prezenta contracte de complexitate similara realizate in ultimii 5 ani, cu valoarea fiecarui contract de cel putin echivalentul a 1 milion EUR, va rugam sa clarificati urmatoarele aspecte: 1. In cazul contractelor cu durata mai mare de 12 luni sau al contractelor multianuale, va rugam sa precizati daca pragul minim de 1 milion EUR se raporteaza: – la valoarea totala a contractului, conform acestuia, sau – exclusiv la valoarea livrarilor/prestarilor efectuate in perioada ultimilor 5 ani. 2. In cazul contractelor aflate in derulare, va rugam sa confirmati ca acestea pot fi considerate experienta similara eligibila, cu conditia ca valoarea totala contractata sa fie de cel putin 1 milion EUR, indiferent de stadiul de executie la data depunerii ofertei. Consideram ca aceste clarificari sunt necesare pentru a asigura o interpretare unitara a cerintei privind experienta similara si un tratament egal si nediscriminatoriu al operatorilor economici.

6 янв 2026, 14:53

Garanția de buna executie: acceptarea politei de asigurare

Avand in vedere prevederile pct. 10 din Anuntul de participare, referitoare la constituirea garantiei de buna executie a contractului in cuantum de 5% din valoarea contractului, care prevad constituirea acesteia prin scrisoare de garantie bancara sau prin transfer bancar la contul beneficiarului, va rugam sa confirmati ca, pentru constituirea garantiei de buna executie, 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 cu garantia bancara, cu respectarea cerintelor privind irevocabilitatea, neconditionarea si plata la prima cerere. Mentionam ca utilizarea politelor de asigurare de garantie este recunoscuta de cadrul normativ aplicabil activitatii de asigurare, precum si de practica achizitiilor publice la nivel international, inclusiv in cadrul procedurilor de achizitie sectoriala. Totodata, apreciem ca acceptarea expresa a acestei modalitati alternative de garantare contribuie la asigurarea unui tratament egal si nediscriminatoriu al operatorilor economici, la extinderea concurentei si la evitarea unor potentiale interpretari restrictive care ar putea genera contestatii. In acest context, va rugam sa precizati expres daca autoritatea contractanta confirma acceptarea politelor de asigurare de garantie pentru constituirea garantiei de buna executie sau, dupa caz, sa indicati temeiul legal expres care limiteaza utilizarea acesteia exclusiv la formele prevazute in documentatia de atribuire.

6 янв 2026, 14:54

Relatia dintre garantia de buna executie (5%) si garantia pentru plata in avans (10%)

Avand in vedere prevederile pct. 10 din Anuntul de participare, care prevad constituirea: – garantiei de buna executie a contractului in cuantum de 5% din valoarea contractului; – garantiei pentru plata in avans in cuantum de 10% din valoarea contractului, va rugam sa clarificati relatia dintre aceste doua garantii si modul concret in care acestea functioneaza cumulativ, in special din perspectiva acoperirii riscurilor contractuale. In acest sens, va rugam sa precizati: 1. Daca garantia de buna executie si garantia pentru plata in avans acopera riscuri distincte sau daca exista o suprapunere intre acestea. 2. Daca garantia de buna executie este constituita integral si mentinuta pe toata durata contractului, independent de recuperarea avansului, sau daca aceasta se activeaza / mentine ulterior recuperarii integrale a avansului. 3. Daca, in cazul constituirii ambelor garantii, valoarea cumulata a acestora poate depasi 5% din valoarea contractului pe intreaga durata a derularii acestuia, respectiv daca se ajunge la blocarea simultana a unei garantii totale de 15%. 4. Daca este avuta in vedere reducerea, eliberarea sau ajustarea garantiei de buna executie proportional cu recuperarea avansului, pentru a evita dublarea acoperirii aceluiasi risc. Consideram ca aceasta clarificare este necesara pentru a asigura proportionalitatea masurilor de garantare, corelarea acestora cu riscurile efective ale contractului si pentru a permite ofertantilor evaluarea corecta a impactului financiar al garantiilor solicitate.

6 янв 2026, 14:54

Clarificare privind cerinta referitoare la source-code (open-source vs acces deplin al beneficiarului)

Avand in vedere cerinta privind prezentarea declaratiei pe proprie raspundere referitoare la natura source-code-ului Platformei, precum si metodologia de evaluare aferenta factorului „Source-code (SC)”, va rugam sa clarificati urmatoarele aspecte: 1. Va rugam sa precizati ce se intelege in mod concret prin „source-code open-source” in contextul acestei achizitii, respectiv daca aceasta presupune publicarea codului sub o licenta open-source standard sau daca este suficienta punerea integrala a codului la dispozitia beneficiarului. 2. Va rugam sa confirmati daca punctajul maxim aferent factorului „Source-code (SC)” se acorda in situatia in care beneficiarul primeste acces complet, nelimitat si permanent la source-code-ul dezvoltat in cadrul proiectului, cu drept de utilizare, modificare si adaptare ulterioara, chiar daca platforma sau anumite componente de baza utilizate nu sunt open-source. 3. Va rugam sa precizati daca scopul acestei cerinte este asigurarea independentei beneficiarului fata de furnizor pe termen lung, respectiv posibilitatea de a mentine, extinde si adapta solutia fara restrictii tehnice sau contractuale. Consideram ca aceste clarificari sunt necesare pentru a asigura o evaluare corecta si obiectiva a ofertelor, axata pe drepturile efective acordate beneficiarului asupra solutiei livrate, si nu exclusiv pe clasificarea formala a licentei software.

6 янв 2026, 14:54

Clarificare privind volumetria si cresterea estimata a datelor (dimensionare hardware, backup, DR)

Avand in vedere prevederile Caietului de sarcini, cap. 2.1, referitoare la cerintele de stocare a datelor pe o perioada de minimum 10 ani, precum si informatiile privind existenta a doua site-uri mentionate la cap. 2.2, va rugam sa clarificati urmatoarele aspecte necesare pentru dimensionarea corecta a infrastructurii hardware, a solutiilor de backup si a mecanismelor de redundanta si disaster recovery: 1. Va rugam sa confirmati volumul actual al datelor care trebuie gestionate de MMS, defalcat pe principalele categorii (date operationale, date istorice, log-uri, rapoarte, arhive), astfel incat ofertantii sa poata porni de la o baza comuna de calcul. 2. Va rugam sa indicati estimarea de crestere anuala a volumelor de date, exprimata procentual sau in valori absolute, avuta in vedere de beneficiar pentru perioada de retentie de 10 ani mentionata in Caietul de sarcini. 3. In lipsa unor estimari explicite de crestere, va rugam sa precizati ce ipoteze de dimensionare ar trebui utilizate de ofertanti la elaborarea ofertei, pentru a evita riscul subdimensionarii solutiei. 4. Va rugam sa clarificati daca valorile de volumetrie mentionate in Caietul de sarcini la cap. 2.1 reprezinta doar situatia curenta sau daca acestea includ deja o proiectie de crestere pe termen mediu. 5. Avand in vedere ca anumite aspecte sunt mentionate ca urmand a fi finalizate in faza de Detailed Design, va rugam sa precizati care sunt cerintele minime obligatorii ce trebuie avute in vedere inca din faza de ofertare, in special din perspectiva capacitatii de stocare, backup si replicare intre site-uri. Consideram ca aceste clarificari sunt esentiale pentru a permite ofertantilor elaborarea unor oferte comparabile, realiste si conforme cu nevoile reale ale beneficiarului pe intreaga durata de exploatare a sistemului.

6 янв 2026, 14:54

Clarificare privind cerintele de backup si disaster recovery (DR)

Avand in vedere prevederile Caietului de sarcini, cap. 2.2, referitoare la existenta a doua site-uri si la cerintele generale de disponibilitate si siguranta a datelor, va rugam sa clarificati cerintele specifice de backup si disaster recovery, astfel incat ofertantii sa poata dimensiona corect solutia propusa: 1. Va rugam sa precizati cerintele tinta privind Recovery Point Objective (RPO) si Recovery Time Objective (RTO) pentru principalele componente ale sistemului MMS. 2. Va rugam sa clarificati daca cele doua site-uri trebuie sa functioneze in regim active/active, active/passive sau intr-o alta configuratie, precum si ce nivel de automatizare este asteptat pentru mecanismele de failover si failback. 3. Va rugam sa indicati cerintele privind frecventa si tipologia backup-urilor (ex. full, incremental, snapshot), precum si perioada de retentie a acestora, inclusiv distinctia intre backup operational si arhivare pe termen lung. 4. In cazul in care anumite cerinte de backup si DR sunt deja asigurate partial de infrastructura existenta a beneficiarului, va rugam sa precizati care sunt aceste responsabilitati si care sunt cele care revin ofertantului. Consideram ca aceste clarificari sunt necesare pentru a asigura o delimitare clara intre cerintele de disponibilitate, backup si disaster recovery si pentru a permite ofertantilor elaborarea unor solutii tehnice comparabile si adecvate nivelului de criticitate al sistemului MMS.

6 янв 2026, 14:55

Clarificare privind structura documentului (Contents neconform / inconsistent)

In urma analizarii Caietului de sarcini, am constatat ca sectiunea „Contents / Table of Contents” nu reflecta in mod corect structura efectiva a documentului, existand mai multe neconcordante intre capitolele listate si continutul real al acestuia. Cu titlu de exemplu, in Contents sunt mentionate capitole si subcapitole care nu se regasesc in document (ex. 5.5.3 „Common Platform for Replacement Reserves”), iar in alte cazuri numerotarea din Contents directioneaza catre sectiuni diferite fata de cele efectiv existente in document. Avand in vedere importanta Caietului de sarcini pentru elaborarea unei oferte complete si conforme, va rugam: 1. Sa confirmati daca versiunea publicata a Caietului de sarcini este completa si finala. 2. Sa corectati si sa republicati sectiunea „Contents / Table of Contents”, astfel incat aceasta sa reflecte in mod fidel structura si continutul documentului. 3. Sa indicati daca exista capitole sau cerinte tehnice suplimentare care, desi mentionate in Contents, nu au fost incluse in documentul publicat. Consideram ca aceasta clarificare este necesara pentru a elimina orice ambiguitate privind cerintele aplicabile si pentru a asigura tratament egal tuturor ofertantilor.

6 янв 2026, 14:55

Clarificare privind cerinta „Time resolution of input data”

Avand in vedere prevederile Caietului de sarcini, cap. 2.4.3 – „Time resolution of input data”, va rugam sa clarificati urmatoarele aspecte pentru a intelege in mod unitar cerintele functionale si impactul acestora asupra solutiei tehnice: 1. Va rugam sa precizati ce reprezinta in mod concret rezolutia temporala de „4 seconds”, respectiv pentru ce tipuri de date sau procese este necesara aceasta rezolutie si daca aceasta se aplica tuturor modulelor MMS sau doar unor cazuri specifice. 2. Va rugam sa definiti ce inseamna in mod practic cerinta „MMS shall handle” o anumita rezolutie temporala, respectiv daca aceasta implica: – stocarea datelor la acea rezolutie; – procesarea si calculul rezultatelor; – agregarea si raportarea; – sau toate cele de mai sus. 3. Va rugam sa furnizati exemple concrete de utilizare pentru cel putin urmatoarele rezolutii: – 1 minute; – 1 semester, astfel incat ofertantii sa poata intelege modul de aplicare a cerintei in scenarii reale de business. 4. In ceea ce priveste mentiunea conform careia, in anumite cazuri speciale, MMS trebuie sa poata gestiona date cu rezolutie mai mica de 1 minut, va rugam sa precizati: – care sunt aceste cazuri speciale; – daca exista o rezolutie minima tinta; – daca aceste cazuri trebuie avute in vedere in mod obligatoriu in faza de ofertare. Consideram ca aceste clarificari sunt necesare pentru a asigura o interpretare coerenta a cerintelor privind rezolutia temporala a datelor si pentru a evita dimensionarea excesiva sau insuficienta a solutiei propuse.

6 янв 2026, 14:55

Clarificare privind punerea la dispozitie a unui draft de contract

Avand in vedere ca documentatia de atribuire nu include un proiect sau un draft de contract aferent achizitiei „Platforma de Management a Pietei de energie cu servicii de implementare”, va rugam sa puneti la dispozitia ofertantilor, anterior termenului limita de depunere a intrebarilor de clarificare (astfel incat sa putem propune ajustari sau sa cerem clarificari), un draft de contract care sa includa principalele clauze contractuale, inclusiv, fara a se limita la: – obiectul contractului si structura acestuia; – termenele si conditiile de livrare si receptie; – mecanismele de plata; – garantiile solicitate si corelarea acestora; – clauzele de raspundere si limitarile de raspundere; – dreptul de utilizare al software-ului creat in scopul proiectului, in conformitate cu oferta prestatorului si dereptul de proprietate intelectuala; – conditiile de modificare si incetare a contractului. Consideram ca punerea la dispozitie a unui draft de contract in limba romana este necesara pentru a permite ofertantilor evaluarea corecta a drepturilor, obligatiilor si riscurilor contractuale, formularea unor oferte realiste si evitarea unor clarificari sau renegocieri semnificative ulterior desemnarii ofertantului castigator.

6 янв 2026, 14:56

Clarificare privind participarea in asociere si indeplinirea criteriilor de eligibilitate

Avand in vedere ca documentatia de atribuire nu precizeaza in mod expres regimul participarii operatorilor economici in asociere (consortiu), va rugam sa clarificati urmatoarele aspecte: 1. Va rugam sa confirmati ca este permisa participarea la procedura de achizitie in asociere de operatori economici. 2. In cazul in care participarea in asociere este permisa, va rugam sa precizati care sunt elementele minime obligatorii ale asocierii, inclusiv: – forma documentelor de asociere; – desemnarea liderului de asociere; – responsabilitatile fiecarui membru al asocierii. 3. Va rugam sa confirmati faptul ca, in cazul unei asocieri, criteriile de eligibilitate se indeplinesc cumulativ, la nivelul asocierii. Consideram ca aceste clarificari sunt necesare pentru a asigura transparenta procedurii, un tratament egal al operatorilor economici si o intelegere corecta a conditiilor de participare in cazul ofertelor depuse in asociere.

6 янв 2026, 14:56

Clarificare privind metodologia de evaluare a experientei similare

Avand in vedere metodologia de evaluare aferenta factorului „Experienta similara”, conform careia punctajul se acorda proportional cu numarul de contracte similare realizate in ultimii 5 ani, va rugam sa clarificati urmatoarele aspecte: 1. Va rugam sa precizati daca scopul acestui criteriu este confirmarea existentei unei experiente relevante in dezvoltarea de solutii similare sau departajarea ofertantilor exclusiv pe baza numarului de contracte prezentate. 2. In forma actuala, criteriul permite obtinerea punctajului maxim de catre ofertantul care prezinta cel mai mare numar de contracte, fara a exista un plafon sau un prag maxim, ceea ce poate conduce la situatii in care relevanta experientei nu este reflectata in mod obiectiv. Va rugam sa precizati daca se are in vedere stabilirea unui prag minim de contracte pentru acordarea punctajului maxim. 3. Va rugam sa clarificati daca prezentarea unui numar minim de contracte similare (de exemplu, un contract care indeplineste cerinta de valoare si complexitate) este suficienta pentru obtinerea punctajului maxim aferent factorului „Experienta similara”. 4. In cazul in care punctajul se mentine proportional cu numarul de contracte, va rugam sa precizati daca exista un numar maxim de contracte care pot fi luate in considerare la calculul punctajului, pentru a evita departajari artificiale intre ofertanti cu niveluri similare de experienta. Consideram ca aceste clarificari sunt necesare pentru a asigura relevanta, proportionalitatea si caracterul obiectiv al criteriului de evaluare privind experienta similara, precum si pentru a evita situatii in care diferenta de punctaj nu reflecta in mod real diferenta de capacitate tehnica intre ofertanti.

6 янв 2026, 14:56

Clarificare privind criteriile de receptie si acceptanta

Avand in vedere ca documentatia de atribuire nu defineste criterii detaliate de receptie si acceptanta a platformei, va rugam sa precizati: 1. Care sunt criteriile obiective pe baza carora se va considera ca platforma este implementata cu succes si poate fi acceptata de beneficiar. 2. Daca receptia finala este conditionata exclusiv de indeplinirea cerintelor din Caietul de sarcini sau si de cerinte suplimentare identificate ulterior. In cazul in care exista cerinte suplimentare, care vor fi procedurile de tratate a acestora, atunci cand acestea se afla in scopul proiectului sau atunci cand acestea se afla in afara scopului proiectului 3. Daca sunt prevazute teste de acceptanta (UAT) si, in caz afirmativ, care sunt criteriile de trecere / respingere. 4. Daca eventualele neconformitati minore pot conduce la amanarea receptiei finale sau doar la remedieri ulterioare, fara impact asupra platii. Nu este prevazuta perioada de remediere. 5. In CS este prevazut ca Moldelectrica va aproba in prealabil documentele de proiectare (HLD&LLD) In acest sens consideram utile a fi precizate minim durata de timp in care beneficiarul va realiza acest lucru precum si procedura/metodologia utilizata pentru acest flux.

6 янв 2026, 14:57

Clarificare privind receptiile partiale

Avand in vedere livrarea etapizata a componentelor (echipamente, licente, servicii), va rugam sa precizati: 1. Daca sunt acceptate receptii partiale pentru livrarile intermediare. 2. Daca pentru fiecare receptie partiala se va intocmi un proces-verbal distinct care sa permita facturarea si plata corespunzatoare. 3. Daca receptiile partiale pot fi conditionate de livrari viitoare sau de functionalitati care nu sunt aferente etapei respective.

6 янв 2026, 14:57

Clarificare privind drepturile de proprietate intelectuala

Avand in vedere cerintele privind source-code-ul si drepturile beneficiarului asupra solutiei livrate, va rugam sa clarificati: 1. Ce drepturi de utilizare, modificare si adaptare vor fi transferate beneficiarului asupra componentelor dezvoltate specific in cadrul proiectului. 2. Daca permiteti furnizorului sa isi pastreaza dreptul de reutilizare a componentelor dezvoltate in cadrul proiectului.

6 янв 2026, 14:57

Clarificare privind cerintele de securitate (tehnica si organizationala)

Va rugam sa precizati cerintele specifice de securitate aplicabile platformei, inclusiv: 1. Daca sunt necesare certificari sau standarde specifice (ex. ISO 27001, ISO 9001, ISO 20000-1, ISO 37001). 2. Daca exista cerinte speciale privind accesul personalului furnizorului in infrastructura beneficiarului.

6 янв 2026, 14:57

Clarificare privind numarul de utilizatori si roluri

Pentru o dimensionare corecta a solutiei, va rugam sa precizati: 1. Numarul estimat de utilizatori simultani. 2. Tipurile principale de roluri si nivelurile de acces. 3. Daca exista variatii semnificative ale incarcarii in anumite perioade (ex. inchideri de piata, raportari).

6 янв 2026, 14:58

Clarificare privind integrari si dependente externe

Avand in vedere dependenta MMS de sisteme externe, va rugam sa clarificati: 1. Lista sistemelor externe cu care MMS trebuie sa se integreze. 2. Modalitatea de integrare (API, fisiere, mesaje). 3. Responsabilitatea beneficiarului privind disponibilitatea si corectitudinea datelor furnizate de sistemele externe. 4. Responsabilitatea beneficiarului de a asigura toate conditiile necesare pentru toate integrarile, in timp util. 5. Anterior transmiterii ofertei este necesara cunoasterea exacta a tututor integrarilor precum si a diagramei de interconectare a acestora.

6 янв 2026, 14:58

Clarificare privind modificarile de scope

Va rugam sa precizati: 1. Daca este prevazut un mecanism formal de change request pentru cerintele identificate ulterior semnarii contractului. 2. Modul in care modificarile de scope vor fi evaluate din punct de vedere al impactului asupra costului si termenului. 3. Daca modificarile pot fi impuse unilateral de beneficiar.

6 янв 2026, 14:58

Clarificare privind obligatiile post-implementare

Avand in vedere costul de deservire al platformei pe 3 ani, va rugam sa clarificati: 1. Ce activitati sunt incluse in perioada de deservire gratuita de 1 an. 2. Ce nivel de suport este asteptat in aceasta perioada (SLA). 3. Daca activitatile de suport si mentenanta pot influenta receptia finala a platformei.

15 янв 2026, 16:48

Clarification

Could the deadline for the proposal be postponed to 13.2.? This will allow more precise proposal based on the specification available from Moldelectrica.

15 янв 2026, 17:38

On prem vs cloud

Is it required that system is installed on-premise? Or is it also possible to provide Software as a service? Is it possible that the solution is deployed to cloud environment (such as MS Azure) due to security reasons, as cloud might offer more secure environment?

15 янв 2026, 17:40

Bidder status

If we decide to submit the proposal on behalf of Consortium of 2 companies, is it OK if the registration on the portal is done for one of them, and in the proposal it is clearly stated this is submitted by a consortium? Is it possible that some of the Mandatory requirements (such as Revenue per 3 years of the bidder, References, etc) is fulfilled by a third party, which capacity does bidder rely on? In such case, is it OK if the bidder states that it relies on the capacity of third party and submits the bid under its own bidder account?

15 янв 2026, 17:41

Open source definition

One of the evaluation criteria is "open-source SW". How do you define open source software? Does Moldelectrica plan to re-sell the software procured (which would fulfill the general definition of open-source SW?) Or is the goal to receive the source codes for the customisations of standard product prepared for Moldelectrica? In case we can hand over such source codes - does it fulfill your understanding of open source? Can you elaborate this topic?

15 янв 2026, 17:43

Contract

Would you be able to define contract for the delivery and maintenance and support? It may influence the delivery or the pricing. Especially the definition of SLAs, penalties, liabilities etc.

16 янв 2026, 09:08

Environments to be provided

The specification refers to different sets of environments to be provided and supported by the Contractor. - In Section 0.3 Contractor, it is stated that Production, Test, and Disaster Recovery sites are encompassed by this procurement. - In Section 2.1 System-level requirements, it is stated that, in addition to the Production System, a Development and Testing System replicating the Production System with its own infrastructure shall be provided. Moreover, The documentation specifies an expectation of two sites for the environments (Production), namely a Main site and a Disaster Recovery (DR) site. As part of our proposed technical solution, we would like to consider an alternative architecture based on an Active–Active deployment across three geographically separated locations, consisting of two primary nodes and an additional arbiter node. Could you please confirm whether such an architecture would be acceptable within the scope of the tender requirements, provided that it fully satisfies (or exceeds) the stated availability, resilience, and disaster recovery objectives ? Are there any possibility to deploy application into 3 geographically separated locations for higher availability of future MMS system ? ​ Related to this, Could you please also confirm whether it is permissible to host the DEV environment at the contractor’s premises or within the contractor’s infrastructure, rather than at the premises of the contracting authority, provided that all security, confidentiality, access control, and compliance requirements specified in the tender documentation are fully met? ​ Could you please confirm the complete and definitive list of environments to be provided under the contract (e.g. Production, Test, Disaster Recovery, etc.)? This clarification is important for proper sizing and cost estimation of the MMS solution.

16 янв 2026, 09:09

Billing and invoicing scope

Could you please clarify whether the MMS solution is expected: - only to generate billing data and export it to external financial systems, or - to generate the actual invoices (including invoice documents) within the MMS?

16 янв 2026, 09:10

Scope of future European market integrations

From the specification, it appears that the requirements include multiple processes that are not yet applicable to the Moldovan energy market, such as integration with JAO, MARI, and PICASSO platforms, as well as the application of flow-based methodology. Given that: a) such mechanisms are still evolving at the European level, b) Moldova currently does not have access to these platforms, and c) meaningful testing would not be possible during the 12-month MMS implementation period, we believe that implementing, configuring, and testing these processes at this stage may not be an efficient use of budget and effort, and would likely require additional changes once Moldova is actually ready to join these platforms. Would you consider reshaping these requirements so that the MMS solution is architecturally ready to support such integrations in the future, without requiring their full implementation and testing within the current project scope?

16 янв 2026, 09:10

Time zones

The specification states that data should be presented in different time zones. However, several core processes - particularly scheduling and settlement - are based on daily or monthly periods. Could you please clarify which time zone Moldelectrica intends to use to define the boundaries of a “day” and a “month” within the MMS? If different time zones are to be applied for different processes, we would appreciate it if you could specify the relevant processes and the corresponding time zones for each. This clarification will help ensure consistent implementation and avoid ambiguities in period-based calculations.

16 янв 2026, 09:11

Provision of market schedules

Could you please clarify whether the market schedules resulting from the Day-Ahead and Intraday markets will be provided to the MMS: - exclusively by the Market Operator, or - by both the Market Operator and market participants, with subsequent matching performed within the MMS?

16 янв 2026, 09:12

Clarification Request on Identity Management and Authentication Architecture

Active Directory / LDAP Provisioning Scope The documentation states that an Active Directory (AD) central server using LDAP shall be hosted by the MMS for user authentication. Could you please clarify whether this requirement implies that the Contractor is expected to deliver and operate a dedicated AD/LDAP service as part of the solution, or whether integration with an existing directory service provided by the contracting authority would be acceptable, provided that all functional and security requirements are fully met ? ​ Authentication Mechanisms, SSO, and Second Factor The documentation refers to SSO authentication, LDAP / AD secure authentication, and mandatory two-factor authentication (2FA). Given that the target system is web-based, could you please clarify whether the use of modern, web-oriented authentication mechanisms (e.g. federation or token-based SSO solutions backed by AD) is acceptable in place of, or in combination with, direct LDAP-based authentication, while still maintaining AD as the authoritative identity source ? ​

16 янв 2026, 09:13

Clarification Request on Hardware Installation, Maintenance, and Access

The tender documentation specifies the delivery of on-premises hardware infrastructure, including servers, storage, network equipment, and associated warranties. In this context, could you please clarify the following: Hardware Installation Is the Contractor expected to perform the physical installation of the hardware (rack mounting, cabling, initial power-up) on the contracting authority’s premises, or will these activities be performed by the contracting authority with the Contractor providing guidance and supervision as required ? ​ Hardware Maintenance During Warranty Period During the warranty and maintenance period, could you please clarify whether the Contractor is expected to provide on-site hardware maintenance and replacement activities, or whether such activities will be handled by the contracting authority (or a designated third party), with coordination from the Contractor ? ​ Physical Access to On-Premises Infrastructure Given that the solution is on-premises and subject to physical security controls, could you please clarify the expected level of physical access for Contractor personnel to the hardware infrastructure (e.g. escorted access, pre-approved access lists, security clearance procedures) for installation, maintenance, and warranty-related activities ? ​ Responsibility Matrix for Delivered Infrastructure Could you please clarify the expected responsibility matrix for the delivered infrastructure, in particular the allocation of responsibilities between the Contractor and the contracting authority for hardware operation, monitoring, incident handling, routine maintenance, and lifecycle management during the warranty and support period ? ​

16 янв 2026, 09:14

Clarification Request on Technical Specifications for Workstations

The tender documentation specifies the number of workstations and monitor configurations; however, requirements for the remaining workstation components are not explicitly defined. In order to ensure full compliance, could you please clarify the expected scope and specifications for the workstations beyond the monitors, including but not limited to computing hardware characteristics (e.g. CPU, memory, storage), graphics capabilities to support multi-monitor configurations, operating system requirements, preinstalled software, and any security or hardening standards to be applied ? ​ Additionally, please clarify whether the workstations are expected to be based on standard enterprise-grade hardware and operating systems, and whether approval or alignment with the contracting authority’s existing workstation standards is required.