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 | Servicii de garanţie (mentenanţă şi suport), aferente soluției informatice de gestionare a resurselor corporative (ERP) | 12 Bucata | |||
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 |
What kind of report are you referring to? Is it a report generated by NBM or by an external party based on which needs to be processed in NBM?
The report in question refers to Consolidated Financial Statements prepared by the NBM on an annual and semi-annual basis. These statements include both the separate financial statements of NBM and those of its subsidiary, the Single Central Securities Depository.
The consolidation process is carried out by NBM in accordance with applicable financial reporting standards. It may involve the application of various consolidation methods, such as full consolidation, the proportionate consolidation method, the equity method, and, where necessary, manual consolidation adjustments.
Data from the separate financial statements of the subsidiary can be imported into the NBM's software system via Excel.
These consolidated financial statements are publicly disclosed and can be accessed on the official website of the National Bank of Moldova at the following link: National Bank of Moldova |.
Are you referring to red balance in chart of account or customer’s account?
We refer only to the red (negative) balance in the chart of accounts.
Could you please explain more about the process expected to happen automatically?
We confirm that the solution is expected to support both manual and automated processes of ac.
The automatic opening/reopening/closing of analytical accounts should be based on predefined transactions performed that have set or accounts or rules, like:
- Purchase of a bond shall automatically open analytical accounts for instrument based on its ISIN/CUSIP: account for nominal value, account for discount/premium; account for unamortized EIR adjustments; for ECL allowance; account for fair value changes; account for interest revenue, interest expense, gains from trading. Moreover, based on different portfolios (for example measured at fair value through OCI, amortized cost of FV at fair value)
- Issuance of security by NBM the system shall automatically generate opening of analytical (account per issuance of nominal value, of discount, account for interest adjustment at EIR)
- opening of an account when a new entity (customer/client/revenue or expenditure element) is created or transaction type).
Automatic closing of analytical accounts that have reached the end of their validity period or are no longer used in transactions: at the derecognition of an instrument – automatic closing of analytical accounts when the operation of derecognition is authorized and reconciled.
Could you please elaborate on this requirement, specifying more details?
This requirement refers to the ability of the system to post accounting entries simultaneously to multiple related accounts within the same transaction or document. For example:
- in a payment transaction, the system should post both to the client’s IBAN account (used for operational purposes i.e. mirror account) and to the NBM internal account (used for NBM accounting).
- similarly, the system should support cases where an intermediate account (e.g. a clearing or transit account) is involved alongside the main account.
This functionality must be rule-based and configurable, allowing multiple accounts to be linked to the same transaction flow without requiring separate manual entries.
Are you referring to a report which has the balance of current period and previous period?
The report in question refers to separate annual and semi-annual (condensed) financial statements of the NBM, prepared in accordance with International Financial Reporting Standards (IFRS). These financial statements present data as of the reporting date and, to ensure comparability in line with IFRS requirements, also include corresponding data as of the previous reporting date (current reporting period and previous reporting period).
The separate financial statements of the NBM are publicly available and can be accessed on the official website at the following link: National Bank of Moldova |
Which modules are applicable for this accounting? Do you mean that different GL should be used for posting the accounting based on the tenor at time of inception?
Yes, modules that account for financial instruments, receivables and liabilities shall permit data for the classification, however the classification shall be done in the GL, reporting and disclosure subledger), which will consolidate all accounting accounts and will be used for preparing the Financial Statements of the NBM.
Do you mean the main system which holds all accounting is CBS and it should have the capability to import entries posted in ERP?
The system which will hold all accounting will be determined at the initiation and planning phase, according to the requirements from The specifications, Implementation Requirements (1.5. paragraph.1 letter. d), but both systems (CBS or ERP) should be capable to import/export entries.
Do you expect accounting period on daily basis? In general this would be defined for a month.
Reporting period for financial statement preparation – annually (with closing of income and expenses, profit allocation) and semi-annually; for management reporting (without notes– IFRS financial position and financial performance – monthly; for accounting – daily (closing of day).
The system should support closing the accounting period on multiple levels, including daily, monthly, quarterly and annual closures, depending on operational and reporting needs.
Could you please elaborate on this requirement, specifying more details?
The system shall perform in the year closing process – automatically posting of revaluations, amortizations, income and expense closing, retained earnings calculation and loss coverage or revenue allocation to different statutory or IFRS reserves.
The financial result of the NBM may be either a profit or a loss.
The profit available for distribution/total loss represents the net profit/loss obtained after allocation of unrealized gains to the corresponding reserves of unrealized gains and after covering unrealized losses from sources of the corresponding reserves of unrealized gains, until their balance becomes zero.
If the reserve of unrealized gains is not sufficient to cover unrealized losses at the end of the financial year, the remaining unrealized losses shall be covered by the General Reserve Fund.
At the end of the financial year, the distributable profit shall be allocated to the increase of the Statutory capital (comprising the Authorized capital—one-third—and the General reserve fund—two-thirds) or transferred to the revenues of the state budget, within the limits stipulated in articles 19 and 20 of the NBM Law no. 548/1995.
In the event that a loss is recorded at the end of the financial year, it shall be covered by the General Reserve Fund.
Could you please elaborate on this requirement, specifying more details?
This requirement refers to the ability of the system to create and manage priority categories for payment orders transmitted via ADPS (Automated Direct Payment System). Priority categories may include classifications such as:
- Urgent payments,
- Standard (Normal) payments,
These categories will determine the processing order and possibly fees associated with the payments. The system should allow configuration of these categories and apply them automatically or manually to payment orders before transmission.
Could you please elaborate on this requirement, specifying more details?
Implementation and configurations of all monetary policy instruments recognized and used by the European Central Bank (reversible transactions - repo/reverse repo agreements or secured loans, outright purchase/sale, term deposits, issuance of debt certificates, currency SWAP operations, etc.), as well as other NBM-specific operations (special purpose loans, emergency liquidity assistance, required reserves, etc.).
Automated import/export of data from Bloomberg Auction System and Depository system as well as manual entry capability, related to the organization of trading sessions of monetary policy instruments.
Could you please elaborate on this requirement, specifying more details?
When importing the information into CBS from other systems, the data needs to be validated and automatically assigned to an auction/transaction based on a predetermined algorithm.
Is it related to Repo? Could you please elaborate on this requirement?
It relates to all types of loans (including repos) granted with securities (SECs).
Could you please elaborate on this requirement, specifying more details?
The system must allow for the annual update of the reference interest rate established by the NBM, which is used for fiscal purposes to determine the taxable benefit associated with facilities granted to employees (interest -free or preferential rate loans).
The interest rate is revised annually, according to the applicable fiscal legislation.
The system should enable manual/configurable entry of the update rate without requiring vendor intervention.
1. Care sunt scenariile în care trebuie redeschis un cont deja închis?
1. Care este Lista sistemelor/serviciilor externe bancii prioritare pentru interconectare
2. Care este metoda de interconectare (ex. API, REST, SOAP...)
3. Avem documentație API disponibila ?
Specificațiile privind interfațarea sunt detaliate în cerințele tehnice din caietul de sarcini. Suplimentar, Anexa 10 oferă o sumarizare a tuturor interfețelor ce trebuie implementate în cadrul proiectului, oferind o imagine de ansamblu asupra punctelor de integrare necesare.
1. Există versiuni specifice ale SIRF care trebuie respectate?
2. Cum se gestionează actualizările SIRF și cum ar trebui soluția să le acomodeze?
IFRS adoptate de IASB, în vigoare și aplicabile la data fazei de analiză și design (link: IFRS - IFRS Accounting Standards Navigator). Cele mai importante standarde specifice și aplicabile de către Banca Națională la data acestei întrebări: IFRS 7,9, 10, 13, 15, 16 și 18, IAS 1, 2, 7, 8, 10, 16, 19, 21, 24, 27, 32,34, 36,37, 38, 39 și IFRIC Sistemul trebuie să fie capabil să acomodeze modificările ulterioare ale standardelor respective.
Soluția trebuie să asigure conformitatea continuă cu actualizările viitoare ale Standardelor Internaționale de Raportare Financiară (IFRS), prin mecanisme flexibile de configurare. Implementarea modificărilor rezultate din noile sau revizuitele standarde IFRS trebuie să se realizeze, în principal, prin configurarea sistemului, fără a necesita dezvoltări personalizate semnificative sau intervenții asupra codului sursă.
Furnizorul va pune la dispoziție instrumente specializate de configurare, șabloane predefinite și/sau motoare de reguli care să permită adaptarea rapidă și eficientă a funcționalităților de raportare financiară și contabilitate în conformitate cu standarde precum IFRS 9, IFRS 15, IFRS 16, precum și cu alte standarde ce pot apărea ulterior.
Soluția trebuie să integreze funcționalități complete de audit trail, care să permită urmărirea tuturor modificărilor relevante asupra tratamentelor contabile, parametrilor de configurare și acțiunilor utilizatorilor, în contextul modificărilor de reglementare contabilă.
Sistemul trebuie să permită păstrarea și accesarea istoricului raportărilor financiare în baza versiunilor anterioare ale standardelor IFRS, precum și refacerea sau reconcilierea acestora, acolo unde este solicitat de normele de reglementare sau de auditorii externi.
1. Ce înseamnă "translatarea la nivel de tranzacție" în contextul raportării SIRF?
2. Puteți oferi un exemplu specific?
Translatarea la nivel de tranzacție presupune cu aplicarea IFRS la nivel de tranzacție și nu doar la o anumită perioadă sau în scop de raportare, prin efectuare de ajustări de tranziție de la un sistem de evidență la IFRS.
1. Care sunt modulele specializate avute în vedere pentru înregistrarea documentelor primare?
2. Care este lista tipurilor de documente primare care trebuie să fie scanate?
1. În cadrul caietului de sarcini sunt indicate care operațiuni sau module reclamă inițierea sau înregistrarea de documente primare, fiecare tip de operațiune necesitând diferite tipuri de documente primare (gestiunea rezervelor valutare, furnizori și plăți, achiziții, trezorerie, plăți, mijloace fixe etc.).
2. Lista tipurilor de documente nu este exhaustivă și sistemul trebuie să permită adaptarea la diferite tipuri sau structuri ale documentelor care pot fi scanate. Acestea pot varia de la: facturi fiscale sau de plată, acte de recepție, acte de prestări servicii, comenzi, deconturi de avans, pentru tranzacții la front-office, ordine de plată, bilete, acte de casare, acte de dare în exploatare etc.
1. Pentru ce tipuri de conturi este necesar să fie disponibil pronosticul soldului?
– Doar conturi de trezorerie? Conturi de venituri/cheltuieli? Toate conturile din planul de conturi?
În sistemul curent aplicăm pentru toate conturile – pronosticul apare la orice cont utilizat în documentul contabil.
Dar, funcționalitatea de prognoză a soldului conturilor se aplică în principal conturilor de creanțe și datorii, unde monitorizarea intrărilor și ieșirilor anticipate este esențială pentru gestionarea fluxului de numerar și asigurarea achitării la timp a obligațiilor. Această funcționalitate este, de asemenea, relevantă, acolo unde este cazul, pentru alte tipuri de conturi, în special conturile de trezorerie și conturile bancare, fiind importantă pentru gestionarea lichidității și menținerea unor solduri disponibile suficiente în valutele corespunzătoare. Totodată, aceasta servește ca măsură de control pentru a asigura că operațiunile se desfășoară doar în limitele soldului disponibil din cont.