Servicii de implementare a soluției informatice de operațiuni bancare (licențe, servicii de implementare și servicii de garanție);
Servicii de implementare a soluției informatice de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție)
suma planificată 72,126,666.67 MDL
Lot | Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
---|---|---|---|---|---|
Servicii de implementare a soluției informatice de operațiuni bancare (licențe, servicii de implementare și servicii de garanție) | 57,079,166.67 MDL | 72200000-7 | Licenţe aferente soluției informatice de operaţiuni bancare (CBS), cu 1 an de suport de la producător inclus | 1 Bucata |
02.01.2026 - 30.12.2028 bd. Grigore Vieru, 1 |
72200000-7 | Licenţe complementare pentru rularea CBS (cu excepţia licenţelor pentru sistemele de operare), cu 1 an de suport standard de la producător inclus | 1 Bucata | |||
72200000-7 | Servicii de implementare ale soluției informatice de operațiuni bancare (CBS) | 1 Bucata | |||
72200000-7 | Servicii de instruire aferente soluției informatice de operațiuni bancare (CBS) | 1 Bucata | |||
72200000-7 | Servicii de integrare | 1 Bucata | |||
72200000-7 | Servicii privind dezvoltări suplimentare și solicitări de schimbare | 2000 Bucata | |||
72200000-7 | Servicii de garanţie (mentenanţă şi suport) aferente soluției informatice de operațiuni bancare (CBS) | 12 Bucata | |||
Servicii de implementare a soluției informatice de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție) | 15,047,500.00 MDL | 72200000-7 | Licenţe aferente soluției informatice de gestionare a resurselor corporative (ERP), cu 1 an de suport de la producător inclus | 1 Bucata |
02.01.2026 - 30.12.2028 bd. Grigore Vieru, 1 |
72200000-7 | Licenţe complementare pentru rularea ERP (cu excepţia licenţelor pentru sistemele de operare), cu 1 an de suport standard de la producător inclus | 1 Bucata | |||
72200000-7 | Servicii de implementare ale soluției informatice de gestionare a resurselor corporative (ERP) | 1 Bucata | |||
72200000-7 | Servicii de instruire aferente soluției informatice de gestionare a resurselor corporative (ERP) | 1 Bucata | |||
72200000-7 | Servicii de integrare | 1 Bucata | |||
72200000-7 | Servicii privind dezvoltări suplimentare și solicitări de schimbare | 1000 Bucata | |||
72200000-7 | Servicii de garanţie (mentenanţă şi suport), aferente soluției informatice de gestionare a resurselor corporative (ERP) | 12 Bucata |
1. Ce se înțelege prin "consolidarea datelor contabile în pași"?
2. Care sunt criteriile pentru rapoartele de excepții și de reconciliere?
Consolidarea în pași presupune procesarea pe etape a datelor contabile importate zilnic din diferite sisteme operaționale, cum ar fi achiziții , plăți etc în modulul principal contabil.
Criteriile pentru rapoarte de excepție urmăresc evidențierea erorilor, omisiunilor sau abaterilor față de regulile contabile definite, de ex sume negative nepermise, diferențe de sumă totală debitoare și creditoare, înregistrări dublate etc.
Consolidarea datelor contabile în pași presupune consolidarea datelor în rapoarte/registre înainte și după importul zilnic de înregistrări din sistemele-sursă, cu generarea urmare importului de înregistrări a rapoartelor de excepții (Lista tranzacțiilor eronate, lipsă sau cu mapare incorectă (cu detalii per cont, dată, sursă) și rapoarte de reconciliere (comparație solduri și tranzacții – ce s-a importat vs. ce era așteptat (eventual semnalizare automatizată a abaterilor peste un prag prestabilit)). Criteriile pentru rapoartele de reconciliere ajută la verificarea corespondenței între datele din sistemele sursă și înregistrările contabile consolidate, de ex suma totala a facturilor din achiziții egală cu înregistrările contabile aferente, total plați din SAPI = sume înregistrate în contabilitate.
1. Care este "regula unică de înregistrare" pentru articolele extrabilanțiere?
Regula de înregistrare a articolelor extrabilanțiere constă în reflectarea acestora în conturile din afara bilanțului în scopuri de evidență doar, fără impact asupra balanței contabile bilanțiere. Înregistrarea în extrabilanț – este sistem în partidă simplă (doar în DR sau CR).
Conturile extrabilanţiere sunt destinate generalizării informaţiei privind:
-obligaţiunile emise şi luate de BNM (Cambii, garanții, gajuri) şi evidența gajurilor și garanțiilor primite);
-evidența contractelor de credit;
-tranzacțiile la termen (SWAP, FORWARD, options);
-tranzacții cu data tranzacției diferită de data decontării (datele nominale);
-evidenţa monedei naţionale în tezaur: toate operațiunile cu moneda primită de la producător în stoc; procesate; primite în rezerva de numerar, constatate rebut, retrase din circulaţie fără putere circulatorie, şi celei necorespunzătoare circulației (uzate) transmise spre tocare/topire.
-evidența diverselor valori și documente și documente.
-active primite/transmise în custodie, păstrare, utilizare;
-datorii contingente (angajamente de capital, litigii etc.)
-documente cu regim special.
Care sunt "alte nivele de agregare" necesare?
Ce tipuri de verificări și reconcilieri specifice sunt necesare?
1. Alte nivele de agregare pe care sistemul să le prevadă:
- Tipuri de instrumente financiare;
- Tipuri de operațiuni/flux;
- Perioada;
- Clasă de active/pasive;
- Proiect;
- Cod al operațiunii pentru raportarea statistică a balanței de plăți;
- Alt element (câmp) care va fi disponibil în cadrul sistemului la și care poate fi
2. Balanța de verificare trebuie să includă automat următoarele verificări și reconcilieri interne:
- verificarea și asigurarea automată a egalității între totalul sumelor debitoare și creditoare;
- reconcilierea soldurilor: sold inițial + debit – credit = sold final (la nivel de cont); precum și a soldurilor finale pe conturi „pereche” (ex. conturi în oglindă: active/pasive, creanțe/datorii);
- controlul soldurilor nepermise/negative: avertizare dacă soldul apare într-o parte neconformă (ex. cont de pasiv cu sold debitor/negativ);
- validarea consistenței între sumele conturilor analitice și celui sintetic;
- verificarea soldurilor în valută exprimate în MDL: reconcilierea valorilor exprimate în valută străină și în echivalent lei, dacă valoarea în lei este corect calculată;
- verificarea soldurilor zero pentru conturi închise: conturile de venituri și cheltuieli trebuie să fie închise la final de exercițiu;
- reconcilierea între module: control automat al corespondenței între datele contabile și cele din modulele operaționale (ex. plăți, achiziții, active, trezorerie).
Care sunt variațiile specifice ale Registrului Jurnal necesare?
Puteți oferi exemple de tipuri de operațiuni și cum ar trebui să difere registrul?
Variațiile (opțiunile de filtrare) de formare /generare a Registrului Jurnal, pot fi:
- în dependență de tipul de operațiune;
- pe conturi/grupe de conturi;
- valută;
- subdiviziune;
- tipuri de documente;
- tip de angajament;
- altele, după posibilitate.
De ex. – pentru operațiuni de trezorerie, registrul jurnal poate fi filtrat pe: contul contraparte x, tip angajament, tip de valută, cu indicarea cursului valutar aferent.
Care sunt "alte" criterii de filtrare necesare pentru fișa contului? Ce se înțelege prin filtrare după "excepție"?
Alte criterii de filtrare necesare pentru fișa contului sunt:
Valuta, responsabilul de înregistrare.
Filtrarea după ”excepție” presupune aplicarea unui filtru pentru anumite caracteristici care deviază de la un nivel sau statut predefinit, de ex. cu statut ”neautorizat”.
1. Care sunt criteriile pentru "grup de tranzacții"?
2. Ce informații specifice trebuie să conțină aceste centralizatoare?
Prin „grup de tranzacții" se înțelege un ansamblu de operațiuni care au în comun unul sau mai multe din următoarele criterii:
Responsabilul de autorizare, tipul operațiunii (plată, transferuri prin card, transferuri între conturi, etc), tipul documentului etc.
Centralizatoarele trebuie să reflecte toate operațiunile autorizate în sistem la o anumită dată și să conțină următoarele informații: nr de ordine, nr documentului, tipul documentului, data operațiunii, nr. executorului responsabil de generarea documentului, denumirea beneficiarului, codul fiscal, BIC-ul băncii, contul, cod IBAN, suma în valută, suma echivalentă în lei, moneda tranzacției, destinația plății, totaluri pe compartimente și pe executori.
1. Care sunt cerințele specifice ale legislației locale pentru registrul de casă?
2. Cum se va realiza preluarea conturilor din CBS?
Registrul de casă urmează a fi adaptat la necesitățile de prezentarea informațiilor pentru BNM, similar modelului aprobat prin Ordinul Ministrului Finanțelor al RM nr.216 din 28.12.2015 (model standard), care să conțină următoarele elemente:
-Data registrului;
-Nr. operațiunii;
-Datele privind plătitorul/beneficiarul sumei încasate/eliberate;
-Referința la nr. ordinului de încasare/eliberare a numerarului;
-Temeiul (descrierea operațiunii);
-Contul corespondent;
-Suma încasată/eliberată;
-Total sume încasate/eliberate;
-Soldul la sfârșitul zilei;
-Numărul de dispoziții de încasare/plată;
-alte câmpuri, după caz, pentru configurare.
Sistemul trebuie să fie capabil să importe automat toate operațiunile în numerar procesate în CBS, fie prin interfață directă fie prin fișiere intermediare XML, etc generate zilnic.
1. Cum se definesc "operațiuni în curs de clarificare" și "instrucțiuni neexecutate" sau "care nu au fost executate"?
1. Operațiunile în curs de clarificare reprezintă acele tranzacții înregistrate într-un cont special „pentru operațiuni în curs de clarificare” care nu pot fi procesate complet sau clasificate corect întrucât nu corespund unor cerințe/reguli, ca de exemplu:
operațiuni cu date care lipsesc sau care nu corespund documentelor confirmative (IBAN incomplet, cod fiscal, sumă incorectă, destinația plății completată incorect, sume care nu pot fi atribuite unui cont analitic distinct deoarece nu există un cont deschis pentru operațiunea respectivă/contraparte etc);
2.Instrucțiuni neexecutate reprezintă ordine (instrucțiuni de plată) care nu au fost autorizate sau preluate de către sistem pentru executare din cauza: erorilor, timpului expirat (cut off time), datelor incomplete, fonduri insuficiente, etc.
1. Ce înseamnă "ușor de configurat" din perspectiva utilizatorului final?
2. Există exemple de astfel de rapoarte specifice care pot fi anticipate?
1. Ușor de configurat” - fără cunoștințe tehnice avansate sau implicarea departamentului IT, utilizatorul de date să poată:
- să creeze și să personalizeze rapoarte prin interfețe intuitive, tip drag-and-drop sau formulare simple;
- să selecteze criterii și și să aplice filtre (ex: perioadă, centre de cost, conturi, proiecte) fără configurări suplimentare;
- să salveze și să reutilizeze șabloane de rapoarte;
- să vizualizeze rezultatele imediat și să exporte rapoartele în formate uzuale (PDF, Excel, etc.);
- să ajusteze layout-ul și nivelul de detaliu al raportului după necesități;
- să configureze alerte și distribuții automate ale rapoartelor către destinatari.
Astfel, utilizatorii cu roluri financiare, de control sau management să poată obține rapid informațiile necesare fără suport IT.
2. Lista finală a rapoartelor care trebuie să fie elaborate în cadrul proiectului va fi definită în faza de analiză.
Pentru mai multe detalii, vezi cerințele tehnice din caietul de sarcini de la cap. 3 „Raportarea”.
1. Puteți detalia aceste mecanisme de alocare?
2. Ce se înțelege prin "coadă de așteptare" în acest context?
1. Prin „mecanisme prestabilite de alocare” se înțelege capacitatea sistemului de a direcționa automat anumite tipuri de intrări/operațiuni către destinațiile sau responsabilii alocați, conform unor reguli configurabile:
-După tip de activ/produs – de exemplu, înregistrările contabile generate de un instrument financiar (operațiune de open market etc.) se alocă automat în conturile și centrele de responsabilitate corespunzătoare acelui activ/produs.
- După modul – tranzacțiile provenite dintr-un anumit modul (ex: CBS, piețe financiare) pot fi procesate diferit sau transmise către alte fluxuri.
- După subdiviziune/responsabil – intrările pot fi alocate automat unei subdiviziuni (ex: Departamentul piețe financiare/Departamentul financiar-contabil, etc) sau unui utilizator în funcție de responsabilitate.
- După tipul sau natura tranzacției – ex: alocarea automată a documentelor cu risc ridicat (de la anumite praguri) în fluxuri cu aprobare suplimentară.
- După caracteristici contabile sau bugetare – cum ar fi cont analitic, cod sursă de finanțare, etc.
2. În acest context, „coadă de așteptare” (queue) se referă la un mecanism automatizat de gestionare a fluxurilor de lucru/procesare (workflow), unde tranzacțiile sau documentele care necesită procesare sunt plasate într-o listă ordonată și atribuite:
- fie în funcție de prioritățile stabilite (ex: termene de plată);
- fie în ordinea sosirii (FIFO – first in, first out).
1. Care sunt regulile specifice pentru fiecare dintre cele 3 direcții de aliniere?
2. Ce se întâmplă dacă există discrepanțe?
Reguli specifice pentru fiecare direcție de aliniere
a. Plan de achiziții vs. Buget
Se validează dacă bunul sau serviciul:
este prevăzut în planul de achiziții aprobat;
are alocare bugetară corespunzătoare pe linie de buget.
Nu se poate iniția o achiziție fără existența sa în plan și fără acoperire bugetară disponibilă.
b. Buget vs. Contract
Se verifică dacă:
valoarea contractului se încadrează în bugetul aprobat;
există buget alocat pentru întreaga perioadă contractuală sau pentru fiecare perioada bugetata.
Un contract nu poate fi înregistrat dacă depășește bugetul disponibil, fără aprobare suplimentară sau rectificare.
c. Plan de achiziții vs. Contract
Se verifică:
dacă obiectul, specificațiile și valorile din contract corespund cu poziția aprobată în planul de achiziții;
dacă termenele și condițiile contractuale sunt conforme cu planificarea.
Contractul trebuie să fie derivat din planul de achiziții.
2. Ce se întâmplă în cazul apariției unor discrepanțe
- Se notifică automat responsabilii;
- Se inițiază o rectificare bugetară sau de plan;
- Alte măsuri de control conform procedurilor (măsuri de control recunoscute la nivel COSO).
1. Ce se înțelege prin acces "online"?
Prin acces online se înțelege posibilitatea utilizatorilor autorizați de a vizualiza și consulta, în timp real, toate documentele asociate unui furnizor sau a unei tranzacții fără a fi necesară extragerea manuală a documentelor din arhivă sau transmiterea lor prin e-mail.
1. Cum se vor gestiona actualizările legislative privind impozitul reținut la sursă și convențiile de evitare a dublei impuneri?
Soluția trebuie să permită configurarea cotelor de impozit la sursa de plată și Convențiilor între state, prin stabilirea codurilor de operațiuni care pot fi impozabile cu TVA, impozit pe venit reținut și a codurilor de țară, introducerea modificărilor legislative de către persoana responsabilă al beneficiarului cu menținerea istoricului cotelor de impozit și modificărilor aplicate.
1. Care sunt criteriile de reconciliere?
2. Procesul va fi automat, manual sau o combinație?
1. Reconcilierea între extrasele de cont și plățile înregistrate în modulul Conturi spre plată se va face pe baza unor criterii prestabilite de potrivire (matching), precum:
-număr referință plată/document (ex: număr OP, număr factură);
-suma plății (cu posibilitate de toleranță configurabilă);
-data plății (sau încadrarea într-un interval anumit);
-valuta tranzacției;
-furnizor/beneficiar (cod unic sau IBAN)
-descriere sau cod identificator în extrasul bancar (ex: referință MT103).
Sistemul trebuie să permită configurarea unor reguli flexibile de reconciliere, inclusiv pentru:
-plăți parțiale, plăți cumulate (pentru mai multe facturi într-o singură tranzacție);
-avansuri.
2. Procesul trebuie să fie automatizat după reguli prestabilite urmat de proces manual pentru unele cazuri când reconcilierea automatizată generează excepții sau imposibilitate de reconciliere (plată în avans sau în cazul lipsei unei referințe).
1. Cum se va determina clasificarea între termen scurt și termen lung? Perioadele de evidență menționate sunt fixe sau configurabile de utilizator?
2. Sunt datoriile financiare pe termen lung in scopul ERP (Lot 2)?
1. Divizarea se face în conformitate cu prevederile IFRS 7.
Clasificarea pe:
- Termen scurt (curent): active și datorii cu scadență estimată în mai puțin de 12 luni de la data raportării;
- Termen lung (necurent): active și datorii cu scadență mai mare de 12 luni de la data raportării.
Considerând
a. riscul de lichiditate – în funcție de scadența contractuală reziduală la data de raportare.
b. riscul ratei dobânzii – în funcție de scadența contractuală (pentru instrumentele cu rata fixa) și data actualizării ratelor dobânzii (pentru instrumentele cu rata flotanta).
Perioadele de evidență sunt fixe.
2. Datoriile financiare sunt în mare parte din CBS. Alte datorii față de furnizori (cu termen lung de achitare și finanțare) pot fi parte din ERP. La fel datoriile de leasing financiar pe termen lung pot fi parte din ERP.
Cum se va gestiona amortizarea în funcție de plafonul stabilit?
În cazul activelor cu valoare mai mică decât un plafon stabilit de BNM conform politicilor sale contabile, sistemul va trebui să aplice un tratament diferențiat:
-fie recunoaștere imediată ca cheltuială (nu se capitalizează), sau recunoscute ca OMVSD;
-recunoaștere ca imobilizare corporală și amortizare în dependență de durata de funcționare utilă (DFU).
Atribuirea se va realiza individual, pentru fiecare activ în parte.
1. Ce tipuri de echipamente (scanere) vor fi utilizate?
2. Soluția trebuie să fie compatibilă cu anumite standarde de coduri de bare/QR?
BNM intenționează să utilizeze echipamente scanere portabile de coduri de bare/QR, care pot fi: (Bluetooth/Wi-Fi), compatibile cu stații de lucru sau tablete; capabile să scaneze coduri 1D (barcode) și 2D (QR code); compatibile cu sistemul ERP-ul prin aplicație dedicată sau interfață web.
Soluția ERP trebuie să permită:
- asocierea codului unic cu activul și generarea automată a etichetei cu număr de inventar și cod (barcode/QR);
- sistemul trebuie să permită încărcarea și stocarea datelor privind activul (denumire, gestionar, caracteristici (culoare, dimensiuni, marcă, tip activ), gestionar, data intrării, valoarea de intrare, valoarea contabilă; poza,etc;
- scanarea pentru identificare, actualizare, inventariere.
Totodată, nu sunt impuse careva cerințe/constrângeri referitor la standarde de coduri de bare/QR.
1. Se aplică reevaluarea conform unui standard național (de ex. SNC) sau IFRS?
2. Dacă da, ce tratament se aplică excedentului?
BNM aplică IFRS, iar excedentul rezultat din reevaluare se va recunoaște conform IAS 16 – imobilizări corporale, în alte elemente ale rezultatului global și se va acumula în contul destinat „rezerve din reevaluare”.
Excedentul nu este recunoscut în contul de profit și pierdere (P&L), cu excepția cazului în care acesta anulează o reevaluare negativă anterioară recunoscută în P&L.
La derecunoașterea activului, surplusul de reevaluare poate fi transferat direct în rezultatul reportat (profitul nerepartizat), fără a afecta P&L. Conform politicilor contabile în vigoare BNM nu ține evidența ulterioară a imobilizărilor corporale la valoarea reevaluată.
1. Care sunt rapoartele statistice specifice necesare și care sunt formatele acestora?
2-INV-TRIM-cu privire la investiții
2-INV-ANUAL –cu privire la investiții
Formatul EXCEL, XML
Modelele acestora sunt aici - > Investiţii, construcţii şi fondul locativ, informațiile în operațiunile contabile urmează să dețină clasificatoare ale operațiunilor pentru maparea operațiunilor date conform câmpurilor inclusiv din aceste rapoarte (INV datele sunt similare celor din Situațiile financiare, Nota Imobilizări corporale și necorporale, doar pe o categorie diferită de agregare.
1. Rog model de flux de lucru pentru gestionarea provizioanelor .
Gestionarea provizioanelor pentru imobilizările depreciate începe cu identificarea periodică a indiciilor de depreciere, cum ar fi deteriorarea fizică, scăderea valorii de piață sau modificări în utilizarea activului (care pot începe la inventariere sau identificare separată, ocazională, a anumitor bunuri).
În cazul în care valoarea recuperabilă estimată (valoarea de utilizare sau valoarea justă minus costuri de vânzare) este mai mică decât valoarea contabilă, se recunoaște o pierdere din depreciere, reflectată printr-o ajustare contabilă automată. Aceste ajustări sunt revizuite la fiecare perioadă de raportare, iar în cazul în care condițiile de depreciere dispar, sistemul trebuie să permită reluarea ajustării, în limita valorii nete recuperabile.