Servicii de implementare a soluțiilor informatice de operațiuni bancare și de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție)

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 |.

We refer only to the red (negative) balance in the chart of accounts.

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.

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.

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 |

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.

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.

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.

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.

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.

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.

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.

It relates to all types of loans (including repos) granted with securities (SECs).

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.

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.

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.

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. Î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.

Î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.

1. Prin vizibilitate „online" se înțelege posibilitatea de a înregistra și a vizualiza înregistrările contabile generate automat în timp real sau aproape de timp real, fără a fi necesare proceduri/intervenții suplimentare manuale de actualizare, sincronizare sau validare a acestora. Sistemul ERP trebuie să permită utilizatorilor autorizați accesul imediat la informațiile contabile aferente fiecărei tranzacții interne, indiferent de departament sau modulul sursă (ex. achiziții, trezorerie, etc.). 2. Da, se acceptă un timp de propagare tehnică de maxim 1 minut, considerându-se acest interval ca fiind "aproape de timp real", cu condiția ca această întârziere să nu afecteze trasabilitatea, integritatea și disponibilitatea informațiilor contabile în fluxurile operaționale. Propagarea trebuie să fie automată, fără intervenție manuală.

Blocarea/închiderea unui cont trebuie să prevină utilizarea acestuia în noi înregistrări contabile, dar să păstreze accesul la toate tranzacțiile anterioare înregistrate, inclusiv în rapoarte, bilanțuri și verificări. Deblocarea/redeschiderea trebuie să restabilească posibilitatea de a folosi acel cont în operațiuni curente, fără a afecta datele istorice privind înregistrările contabile reflectate în acel cont.

Se solicită un nivel complet de detaliu care să includă cel puțin: - Data și ora modificării (deschidere, blocare, închidere, redeschidere, etc.), - Utilizatorul care a efectuat modificarea (deschidere, închidere, redeschidere, blocare, etc.), - Tipul modificării (deschidere, închidere, redeschidere, blocare, etc.), - Motivul modificării. În ceea ce privește maparea conturilor cu conturi analitice din diferite module și actualizarea acestora, sistemul cu modulul GL ( balanța contabilă, cartea mare) trebuie să păstreze toate datele centralizat ale conturilor analitice dintre modulele sistemelor ERP și Corebanking, trebuie să permită vizualizarea și gestionarea centralizată a mapărilor între conturile contabile, clienti etc. La fel și aici, orice actualizare a mapărilor trebuie să permită monitorizarea istoricului: cine , când și ce modificări a efectuat. Totodată, în cazul în care un cont este modificat (ex: închis sau redenumit), sistemul trebuie să avertizeze utilizatorul dacă acest cont este mapat în alte module și să solicite careva acțiuni cum ar fi înlocuire, remapare, etc.

Redeschiderea este un proces de excepție și poate fi folosit doar cu aprobare și escaladările necesare. Scenariile în care trebuie redeschis un cont deja închis pot fi: - Relansarea unor activități pentru care conturile închise se utilizau (de ex. o activitate care nu se petrecea timp de 5 ani, a fost reintrodusă). - Reluarea utilizării acelui cont , de ex. un cont al unui client (angajat al BNM) care a fost închis anterior, dar care devine din nou activ. - Corectarea sau completarea unor înregistrări contabile aferente perioadelor anterioare, în cazul în care este necesară o înregistrare contabilă suplimentară sau corectivă cu implicarea unui cont închis, acesta trebuie redeschis. Eroare umană sau închidere prematură, dacă un cont a fost închis din greșeală, este necesară redeschiderea acestuia pentru a permite continuarea activității.

Blocarea/închiderea unui cont trebuie să prevină utilizarea acestuia în noi înregistrări contabile, dar să păstreze accesul la toate tranzacțiile anterioare înregistrate, inclusiv în rapoarte, bilanțuri și verificări. Deblocarea/redeschiderea trebuie să restabilească posibilitatea de a folosi acel cont în operațiuni curente, fără a afecta datele istorice privind înregistrările contabile reflectate în acel cont.

Da, conform pct.10 din Anunțul de participare, ofertantul poate depune oferta pentru mai multe loturi (pentru un singur lot sau pentru ambele loturi). Da, evaluarea va fi efectuată pe fiecare lot separat, prin urmare puteți participa cu depunerea ofertei Dvs doar pentru un lot.

Nu, un operator economic poate depune o singură ofertă pe lot. Depunerea de două oferte pe același lot de către același operator economic, individual sau în asociere, duce la respingerea ambelor oferte. Totodată, menționăm că ofertele alternative nu se admit, conform pct.11 din Anunțul de participare. Suplimentar, atragem atenția la prevederile din Documentaţia standard pentru realizarea achiziţiilor publice de bunuri şi servicii, aprobată prin Ordinul Ministrului Finanțelor nr.115/2021, pct.65 „Ofertantul nu are dreptul de a depune decât o singură ofertă de bază.

Conceptul de „formule contabile integrate (consolidate)" se referă la situațiile în care un document generează multiplele formule contabile per tranzacție. Exemple 1. tranzacția de vânzare a unei valori mobiliare din portofoliul BNM generează consolidat toate înregistrările în cascadă. - prețul de vânzare - valoarea nominală - câștigul din vânzare - închide diferențele de valoare din conturile acumulate 2. Vânzarea mijlocului fix, înregistrează prin documentul de vânzare - venitul din vânzare și creanța aferentă - amortizarea - valoarea de bilanț - valoarea reziduală etc. 3. Calculul dobânzii per portofoliu - operațiune consolidată zilnică care înregistrează venitul per fiecare operațiune - per fiecare ISIN. 4. Achitarea periodică (la o data anumită a facturilor scadente - un proces, un document consolidat, dar înregistrare pe fiecare în parte).

BNM nu intenționează să interfereze cu politicile contractuale ale furnizorului de licențe. Astfel, achiziția licențelor necesare pentru implementare va fi gestionată în conformitate cu cerințele producătorului. În cazul în care este necesară semnarea unui acord de licențiere cu producătorul licențelor, BNM este deschisă să accepte condițiile impuse de acesta. Cu toate acestea, obligația financiară aferentă licențelor necesare până la etapa de Go-Live va rămâne în sarcina Ofertantului, fiind parte integrantă a responsabilității acestuia pentru implementarea sistemului. NBM does not intend to interfere with the contractual policies of the license provider. Therefore, the procurement of the licenses required for implementation will be managed in accordance with the manufacturer's requirements. If signing a licensing agreement with the license manufacturer is necessary, NBM is open to accepting the conditions imposed by the latter. However, the financial obligation related to the licenses required up to the Go-Live stage will remain the responsibility of the Bidder, as it is an integral part of their responsibility for system implementation.

A se vedea răspunsul de la întrebarea de mai sus. See the response to question above.

Conform cerințelor tehnice, BNM va opta pentru un proces de evidență de gestiune dezvoltat și aplicat pe larg, bazat pe practici și modele implementate la nivel de entități bancare sau alte entități. Contabilitatea de gestiune (managerială) este un sistem de evidență managerială care pe bază de datele din evidența contabilă oferă informații granulare, care permit evidența performanței și luarea deciziilor. 1. Da. Este necesar ca sistemul să permită reflectarea simultană a tranzacțiilor atât în contabilitatea financiară cât și în contabilitatea de gestiune/managerială, și corelarea cu bugetul. Însă sistemele de gestiune manageriale, pot avea unii indicatori suplimentari sau informații manageriale (operaționale) care nu se regăsesc direct într-o operațiune financiară și care pot fi prin operațiuni dedicate evidenței manageriale să fie efectuate direct și doar în sistemul de evidență managerială (de ex. realocarea între centre de cost). 2. Pentru a înregistra tranzacțiile în contabilitatea de gestiune este necesară atribuirea de coduri suplimentare conform unui nomenclator predefinit pentru centrele de cost, proces (activitate) sau proiecte (la nivel de subdiviziune, proces, activitate, serviciu prestat etc) – repartizare directă, sau indirect în baza de anumite chei de alocare. Atribuirea să se facă la etapa înregistrării tranzacției în evidența contabilă financiară, astfel de exemplu o factură fiscală poate fi atribuită direct nu doar pe un cont contabil de cheltuieli, ci și pe centrele de cost sau proiectele pentru care se referă aceasta. Ulterior sunt necesare și operațiuni de alocare între centre de cost, în cazul cheltuielilor indirecte sau și a celor directe, Astfel, distribuirea dată să permită generarea ulterioară de rapoarte manageriale privind costurile suportate pe diferite centre de cost. Pentru detalii, a se vedea cerințele tehnice descrise la 1.1.6 Evidența costurilor și controlul de gestiune. 3. Tranzacțiile ce prevăd înregistrări de venituri sau cheltuieli să fie atribuite unui element prevăzut în buget. Soldul cumulativ (pe parcursul unui an bugetar) al tranzacțiilor atribuite unei linii din bugetul administrativ fix sau alocații pentru investiții, nu trebuie să depășească sumele aprobate alocate pe elementul dat. Pentru detalii, a se vedea cerințele tehnice descrise la 1.1.5 Cerințe față de modulul de bugetare. A se lua în considerare și mapare cu modulul de Procurement (Planul de achiziții). Aceste exemple sunt orientative și sistemele de evidență managerială au incorporate și alte elemente obligatorii sau facultative care sunt urmărite pentru decizii manageriale, corelat cu informații adiționale pentru sistemul de evidență financiară.

Da, soluția ERP trebuie să asigure cerințele contabile IFRS 16 privind leasingul, inclusiv recunoașterea activelor aferente dreptului de utilizare și a obligațiilor aferente contractelor de leasing, calculul amortizării și al dobânzilor, precum și gestionarea modificărilor contractuale. Da, soluția trebuie să considere prevederile IFRS 16 – Contracte de leasing, inclusiv posibilitatea recunoașterii activelor aferente drepturilor de utilizare și a datoriilor de leasing, calculul amortizării și al dobânzii, modificările ulterioare ale contractelor de leasing.Cu toate aceastea, BNM are puține contracte în derulare de leasing operațional.

Da, avem nevoie de funcționalități legate de „Enterprise Asset Management” in limita cerințelor tehnice definite in caietul de sarcini la capitolul 1.1.3 Cerințe față de modulul Imobilizări (Mijloace Fixe) – Imobilizări corporale și necorporale.

Termenul de 15 luni pentru punerea în producție a Lotului II reprezintă un termen maxim recomandat, iar Vendorul este responsabil să estimeze și să propună un termen realist și optim, în funcție de particularitățile soluției sale. Totodată, este important să se țină cont de cerințele Caietului de sarcini, în special Cerințele privind implementarea (1.5. alin.1 lit. d)), fiind esențial de reținut că în faza inițială, când se va realiza planificarea detaliată a implementării pentru ambele loturi, vor fi identificate toate interdependențele, strategiile de gestionare a acestora și traseul critic al proiectului. Acest proces va asigura o claritate suplimentară asupra posibilităților și constrângerilor legate de implementare. Planul detaliat, agreat și coordonat între toate părțile implicate, va deveni un document obligatoriu pentru derularea proiectului.

Da, conform prevederilor cerinței CMP.10 din Caietul de sarcini Autoritatea contractantă va numi un manager de proiect omolog. Managerul de proiect al Beneficiarului are rolul de a organiza resursele Beneficiarului, astfel încât acestea să fie utile pentru proiect şi disponibile după cum este necesar pentru a îndeplini planul de proiect. Managerul de proiect al Beneficiarului oferă o interfaţă oficială de comunicare a problemelor de zi cu zi şi de raportare cu privire la progresele înregistrate de proiect între Managerul de proiect al Ofertantului şi Beneficiar.

BNM dispune în prezent de resurse virtualizate suficiente pentru a susține implementarea proiectului în fazele de dezvoltare, testare și acceptanță. După ce vor fi finalizate specificațiile de design, care vor include și specificațiile tehnice de infrastructură, BNM va demara o procedură separată de achiziție pentru a achiziționa resurse hardware suplimentare, necesare pentru a asigura disponibilitatea unei infrastructuri optime la momentul punerii în producție. Currently, NBM has sufficient virtualized resources to support the project during the development, testing, and acceptance phases. Once the design specifications— including the technical infrastructure specifications—are finalized, NBM will initiate a separate procurement procedure to acquire the additional hardware resources needed to ensure that optimal infrastructure is available at Go-Live.

Având în vedere caracteristicile specifice fiecărui modul de licențiere (acces la fiecare modul în mod separat/la toate modulele, acces doar la raportare, acces în funcție de rol (coordonare, autorizare, etc.), etc), numărul de utilizatori unici va fi posibil de stabilit la etapa de analiză și design. Totodată, toate detaliile cu privire la numărul de utilizatori, disponibile la moment au fost introduse în Anexa nr.9 la Caietul de sarcini.

Balanțele contabile ale BNM vor fi generate în modulul Cartea Mare (General Ledger). Decizia cu privire la lotul unde va fi implementată Cartea Mare se va lua în faza de planificare și inițiere a proiectului, în conformitate cu prevederile capitolului 1.5. alin.1 lit. d) Cerințe privind implementarea din Caietul de sarcini.

Prin sintagma „resurse ale beneficiarului” se subînțeleg toate resursele necesare pentru realizarea activităților din cadrul Planului de proiect (resurse umane, resurse IT, etc), cu excepția resurselor financiare, considerând toleranța ”zero” de buget.

Microsoft Project poate fi utilizat pentru planificare, nu avem careva limite cu referire la instrumentele utilizate pentru planificarea activităților proiectului, dacă acestea corespund cerințelor aferente managementului de proiect din Caietul de sarcini.

Planul detaliat de etapă este necesar a fi elaborat pentru toate etapele ulterioare etapei de inițiere, nu doar pentru etapa de analiză și design, conform cerinței CMP. 17 g. i. Totodată, odată cu depunerea ofertei, Ofertantul va prezenta Planul de etapă pentru prima etapă a proiectului (cea ulterioară inițierii proiectului). Planul detaliat va fi elaborat în formatul diagramei Gantt. Partea descriptivă a fiecărui plan detaliat va fi efectiv inclusă în livrabilul „Planul de management de proiectului”, conform setului de cerințe din caietul de sarcini CMP.17, unde vor fi descrise toate elementele de management de proiect (resurse, comunicare, risc, calitate, resurse etc) necesare pentru atingerea obiectivelor proiectului.

Documentația de atribuire prevede în mod explicit că ofertantul trebuie să demonstreze experiență în implementarea soluției ofertate în entități bancare, în baza a cel puțin trei contracte finalizate cu succes în ultimii 7 ani, dintre care unul în ultimii 3 ani, precum și în condițiile valorilor financiare minime indicate pentru fiecare lot. Din această formulare reiese în mod clar că experiența relevantă trebuie să fie dobândită în relație cu entități care funcționează ca instituții bancare, astfel cum sunt acestea definite conform legislației în vigoare și reglementate de autoritățile de supraveghere bancară. Deși argumentele transmise de dumneavoastră (privind implementarea aceleiași soluții, deținerea majoritară de către bănci din Uniunea Europeană și posibilitatea susținerii contractelor cu documente justificative) sunt înțelese, trebuie precizat că: • Instituțiile financiare nebancare (IFN-urile), chiar dacă fac parte din grupuri bancare, nu se califică drept entități bancare în sensul cerinței formulate; • Structura, complexitatea și reglementarea activităților desfășurate de entitățile bancare diferă semnificativ de cele ale IFN-urilor – inclusiv în ceea ce privește sistemele interne, procesele de conformitate, raportare, gestiune a riscului, precum și cerințele de securitate și audit. Aceste particularități justifică în mod obiectiv cerința impusă și o diferențiere clară a experienței relevante; Prin urmare, contractele încheiate cu IFN-uri, indiferent de afilierea acestora la grupuri bancare, nu pot fi considerate conforme cerinței de calificare, întrucât nu respectă cerința esențială privind natura juridică și operațională a beneficiarilor – respectiv aceea de a fi entități bancare. Subliniem faptul că neîndeplinirea cerinței de calificare conduce la respingerea ofertei ca fiind inacceptabilă, conform dispozițiilor legale aplicabile în domeniul achizițiilor publice.

Vă rugăm să consultați răspunsul de la întrebarea de clarificare de mai sus.

Cerința de calificare stipulează în mod clar că experiența relevantă trebuie să provină din contracte de implementare finalizate cu succes în entități bancare. Această cerință vizează nu doar natura soluției implementate sau succesul implementării, ci și specificul instituțional și operațional al beneficiarului, care trebuie să fie o entitate bancară, în sensul reglementărilor aplicabile. În acest context, chiar dacă soluția a fost implementată integral și cu succes într-o instituție financiară nebancară și chiar dacă acest fapt poate fi susținut prin scrisori de recomandare oficiale, scrisorile emise de IFN-uri nu pot substitui documentele justificative aferente experienței în entități bancare, întrucât nu pot dovedi îndeplinirea cerinței esențiale privind tipul entității beneficiare. Mai mult, cerința impusă reflectă realitățile diferențelor semnificative între procesele interne, reglementările și nivelul de complexitate operațională ale instituțiilor bancare față de instituțiile financiare nebancare, diferențe care justifică necesitatea unei experiențe directe în mediul bancar. Prin urmare, scrisorile de recomandare emise de instituții financiare nebancare pot fi anexate la ofertă ca documente informative sau suplimentare, dar nu vor putea fi considerate relevante pentru îndeplinirea cerinței de calificare privind experiența în entități bancare.

În conformitate cu cerințele documentației de atribuire, experiența solicitată de minimum 4 ani a experților trebuie să fie dobândită în proiecte IT desfășurate în sectorul bancar, respectiv în cadrul unor instituții bancare autorizate. Prin urmare, experiența obținută în cadrul instituțiilor financiare nebancare (IFN-uri), chiar dacă acestea fac parte din grupuri bancare și proiectele au fost finalizate cu succes, nu este eligibilă, întrucât IFN-urile nu se încadrează în sectorul bancar în sensul cerinței.

Cerința vizează experiența în cel puțin 2 proiecte de implementare similare ca domeniu și complexitate cu proiectul BNM, derulate în sectorul bancar. Prin urmare, proiectele realizate în cadrul instituțiilor financiare nebancare (IFN-uri), chiar dacă acestea fac parte din grupuri bancare și sunt într-o oarecare măsură comparabile ca perimetru și complexitate, nu sunt eligibile, întrucât nu se încadrează în domeniul bancar, astfel cum este cerut prin documentația de atribuire.

Toate cele menționate și control intern financiar. Perioada contabilă – ziua operațională. Scopul principal al reevaluării zilnice este asigurarea acurateții/preciziei poziției valutare a BNM, cu rol esențial în managementul riscului valutar și în luarea deciziilor operaționale și de politică monetară, inclusiv și din prisma conformității cu cerințele IFRS, reevaluarea zilnică contribuind la o imagine fidelă și actualizată a pozițiilor în valută pe fiecare cont analitic precum și la nivel agregat, în conformitate cu cerințele IFRS, deși acestea nu prevăd obligația reevaluării zilnice, în contextul băncii centrale, reevaluarea zilnică reprezintă o practică internă complementară în vederea asigurării acurateții la data raportării; etc).

Imprimarea selectivă a documentelor este necesară în special pentru operațiunile contabile care implică fluxuri documentare cu cerințe diferite de evidență și arhivare, acestea se referă la: - Documente de trezorerie (ordine/dispoziții de plată, extrase de cont, dispoziții de încasare, etc); Centralizatoare, balanțe de verificare și alte rapoarte.

Sistemul trebuie să aplice următoarele restricții : - Interdicție totală de modificare , nici un utilizator nu trebuie să poată adăuga, modifica sau șterge înregistrările contabile aferente unei perioade închise. - Access doar în regim read - only pentru utilizatorii autorizați. În același timp sistemul trebuie să dețină funcționalități de înregistrări de corectare a perioadelor închise, cu regim de autorizare escaladat, cu intervale sau perioade care ar permite corectarea acestora conform principiilor aplicabile în IAS 8 (corectarea erorilor contabile). Nu pot fi supuse corectării contabile și perioadei, înregistrările în conturile clienților (conturi de conturi curente, depozite, overnight) care afectează sumele de plăți, încasări.

Aceste criterii sunt necesare în cazul în care nu pot fi aplicate soluțiile de înregistrări de corectare, descrise mai jos și pentru care sunt necesare tipuri de document sau funcționalitate la nivel de sistem, care ar fi de natura corecțiilor perioadelor anterioare și care ar înregistra corectarea în ziua corespunzătoare (când înregistrarea urma să aibă loc), dar fără redeschiderea zilei operaționale nemijlocit. Criteriile de redeschidere a zilei operaționale sunt aplicabile pentru deschidere doar Administratorilor de sistem, cu nivelele de autorizare și aprobare suplimentară (Membru al Comitetului Executiv, Director Finanțe). Criteriile pentru cazurile excepționale în care se permite deschiderea zilei anterioare închise se refera la ajustări/corectări în înregistrările contabile deja reflectate (în cazul în care operațiunile de corectare mai jos nu sunt posibile): - Incidente IT care nu au permis înregistrarea corespunzătoare a operaţiunilor în ziua corespunzătoare și remedierea acestora s-a extins în următoarea zi; - În următoarea zi lucrătoare (în procesul verificării zilei operaționale se constată erori, înregistrări automate neînregistrate corespunzător). În situația când înregistrările corespunzătoare de corectare nu pot fi aplicate din motive tehnice.

Prin "document contabil ne-autorizat de nivel critic" înțelegem documentele contabile care nu au trecut integral fluxul complet de autorizare configurat în sistem (de ex. executor, șef al secție, șef departament). Există anumite operațiuni de tip plăți/încasări, inclusiv in valută străină (de ex. plăți finale, decontări interbancare cu data valutei în ziua curentă).

La nivel de tranzacție, este necesară completarea suplimentară în câmpuri separate a liniei de buget și centrului de cost/de profit atribuit direct cheltuielii/venitului înregistrat. Alocarea ulterioară pe alte centre de cost (de pe fiecare centru de cost pe activități de bază, activități de guvernanță și suport și proiecte care sunt capitalizate; de pe activitățile de guvernanță și suport către centrele de cost responsabile de activități de bază și proiecte capitalizate; de pe activități pe servicii prestate, bunuri comercializate/proiecte) va avea loc în modulul de evidență a costurilor și control de gestiune. De menționat că aceste date de gestiune si bugetare sunt suplimentare altor date obligatorii a fi completate privind identificarea documentului (nr, data documentului, data tranzacției/data livrării/prestării etc), datelor privind părțile implicite (furnizor/prestator, responsabil intern etc), date financiare și contabile (conturi contabile, suma, TVA, moneda tranzacției etc), date justificative și administrative (referință contract, descriere tranzacție, semnături/aprobări etc). Alte date alternative care pot fi necesare, conform sistemelor de evidență a costurilor care pot fi necesare pentru deciziile operaționale– m2, unități, proiect, nr personal, centru de investiții, obiectiv, KPI. Aceste exemple sunt orientative și sistemele de evidență managerială au incorporate și alte elemente obligatorii sau facultative care sunt urmărite pentru decizii manageriale, corelat cu informații adiționale pentru sistemul de evidență financiară.

1. Conform IFRS, BNM gestionează următoarele tipuri de provizioane: 1) Provizioane pentru pierderi din deprecierea activelor financiare deținute de către BNM, evaluate la cost amortizat și la valoarea justă prin alte elemente ale rezultatului global, conform IFRS 9; Pentru aceste tipuri de provizioane fiind aplicat modelul „pierderi de credit așteptate” – i.e. Expected Credit Loss (ECL), cu utilizarea datelor aferente scorurilor de risc/rating, probabilității de default, pierderii în caz de default și expunerii estimate, etc. Pierderile de credit așteptate reprezintă o estimare ponderată a probabilității ponderate a valorii actualizate a pierderilor din risc de credit. Acestea sunt evaluate ca valoarea prezentă actualizată a diferenței dintre fluxurile de mijloace bănești datorate BNM conform contractului și fluxurile de mijloace bănești pe care BNM se așteaptă să le primească ca urmare a ponderării mai multor scenarii economice viitoare, actualizate utilizând rata dobânzii efective. Conform modelului de depreciere bazat pe pierderile așteptate recunoașterea pierderilor din depreciere de credit așteptate se efectuează și se actualizează cu o frecvență trimestrială: - pentru o perioadă de 12 luni de acțiune a activului financiar, în cazul în care riscul de credit nu a crescut semnificativ de la data recunoașterii inițiale și -pentru întreaga perioadă de viață a activului financiar, în cazul în care riscul de credit a crescut semnificativ de la data recunoașterii inițiale. BNM evaluează pierderile din de creditare așteptate pe o bază individuală sau pe o bază colectivă pentru portofolii de depozite, valori mobiliare, credite care prezintă caracteristici similare de risc. Această evaluare se bazează pe valoarea actualizată a fluxurilor de mijloace bănești preconizate ale activului, utilizând rata dobânzii efective inițială a activului, indiferent dacă acesta este evaluat individual sau pe bază colectivă. Instrumentele sunt grupate după tipul instrumentului, riscul de credit exprimat prin rating-uri, emitent, sector, garanție etc 2) Provizioane pentru litigii, daune și alte obligații legale – conform IAS 37, pentru: -litigii în curs , obligații asumate în mod legal sau contractual inclusiv eventuale penalități, alte sancțiuni, care derivă din acestea, etc; Pentru acest tip de provizioane fiind utilizată cea mai bună estimare a valorii necesare pentru stingerea obligației, bazată pe informațiile disponibile la data raportării, în dependență de certitudinea rezultatului. 3) Provizioane pentru cheltuieli viitoare previzibile – conform IAS 37, dacă acestea sunt generate de o obligație curentă (ex. costuri de închidere, stocuri neutilizate, imobilizări depreciate etc.). 4) Provizioane pentru concedii neutilizate (IAS 19) – metodologie stabilita – nr de zile de concediu neutilizate la data de raportare x prețul zilei (acest provizion va fi calculat utilizând datele din sistemele de payrol, HR).

Aplicațiile externe specifice din care se vor importa aceste date sunt „e - factura” de pe sfs.md.

1. Veniturile de bază care reprezintă venituri din operațiuni cu metale prețioase monetare; venituri din plasamente externe (rezerve valutare), conturi curente, credite acordate; venituri din portofoliul de titluri de stat și alte investiții; operațiuni în valută străină, inc. diferențele de curs valutar și reevaluare; reluarea provizioanelor, comisioanele și taxele aplicate, etc); Alte venituri, cum ar fi: venituri din vânzarea bancnotelor și monedelor jubiliare și comemorative, alte venituri aferente monedei naționale, venituri din realizarea stocurilor/imobilizărilor/prestări de servicii, sume recuperate/penalități/despăgubiri/venituri, etc. 2.Sursa inițială a datelor pentru veniturile de bază reprezintă sistemul CBS – acestea se vor contabiliza automatizat la procesele aferente. 3. Comisioanele pentru numerar – soluția gestiune numerar și CBS. 4. Comisioanele SAPI – SAPI. 5. Pentru alte venituri: ERP – din tranzacțiile automatizate (prestări servicii, vânzare bunuri, alte vânzari) sau manual pentru veniturile sporadice (recuperări de costuri, alte venituri). Pentru operațiunile aferente veniturilor de bază majoritatea înregistrărilor aferente sunt automatizate.

Sistemul urmează să efectueze, în cadrul procesului de închidere a exercițiului financiar, înregistrările automate aferente reevaluărilor, amortizărilor, închiderii veniturilor și cheltuielilor, calculului rezultatului reportat și acoperirii pierderilor sau alocării profitului în rezervele statutare/conform IFRS. Rezultatul financiar al BNM poate fi fie un profit, fie o pierdere. Mecanismul privind distribuirea rezultatului financiar este prevăzut la art.19 și 20 din Legea nr.548/1995. Profitul disponibil pentru distribuire/pierderea totală reprezintă profitul/pierderea net(ă) obținut(ă) după defalcarea tuturor veniturilor nerealizate în conturile corespunzătoare de rezervă ale veniturilor nerealizate, acoperirea tuturor pierderilor nerealizate din sursele conturilor corespunzătoare de rezervă ale veniturilor nerealizate, până când soldul acestora devine zero şi după defalcarea în capitalul statutar a veniturilor obţinute din suma totală a bancnotelor şi monedelor metalice retrase din circulaţie, dar nepreschimbate în perioada stabilită de către BNM, în conformitate cu articolul 64, aliniatul (3) al Legii nr. 548/1995. La finele anului financiar, profitul disponibil pentru distribuire se alocă pentru majorarea capitalului statutar sau transferarea la veniturile bugetului de stat în limitele prevăzute la art.19 și art.20 ale Legii 548/1995. La finele anului financiar, profitul disponibil pentru distribuire va fi alocat pentru majorarea capitalului statutar în următorul mod: a) dacă mărimea capitalului statutar, până la distribuirea profitului disponibil pentru distribuire la finele anului financiar înainte de distribuirea rezultatului financiar aferent anului curent, constituie mai puţin de 4% din totalul obligaţiilor monetare ale BNM, profitul disponibil pentru distribuire va fi alocat în întregime pentru majorarea capitalului statutar în modul prevăzut la art.19 alin.(3) din Legea 548/1995; b) dacă mărimea capitalului statutar, până la distribuirea profitului disponibil pentru distribuire la finele anului financiar înainte de distribuirea rezultatului financiar aferent anului curent, constituie de la 4% până la 10% din totalul obligaţiilor monetare ale BNM, 50% din profitul disponibil pentru distribuire vor fi alocate pentru majorarea capitalului statutar în modul prevăzut la art.19 alin.(3) din Legea 548/1995, iar 50% din profitul disponibil pentru distribuire vor fi transferate la venitul bugetului de stat; c) dacă mărimea capitalului statutar, până la distribuirea profitului disponibil pentru distribuire la finele anului financiar, constituie mai mult de 10% din totalul obligaţiilor monetare ale BNM, profitul disponibil pentru distribuire va fi transferat în întregime la venitul bugetului de stat. În cazul în care veniturile nerealizate defalcate şi/sau pierderile nerealizate acoperite ale perioadei de gestiune depăşesc mărimea profitului net, această depăşire este acoperită din fondul general de rezervă. Totodată, sistemul informatic trebuie să permită, inclusiv, posibilitatea distribuirii manuale a rezultatului financiar între conturile de capital.

1. Da. Se solicită implementarea formatului actual al situațiilor financiare disponibil pe pagina web. Totodată, structura situațiilor financiare poate fi modificată/completată pe viitor, pe măsura emiterii unor IFRS noi sau amendamente la IFRS urile actuale privind cerințe suplimentare de raportare și notele sau informațiile suplimentare necesară conform notelor informative. 2. Nu se urmărește integrarea directă cu site-ul oficial pentru publicare automată, dar este necesară asigurarea descărcării acestora în formate editabile, pentru eventuale ajustări manuale și semnare. 3. Situațiile financiare sunt întocmite în conformitate cu IFRS, emise de Consiliul pentru Standarde Internaționale de Contabilitate (IASB), în vigoare la data etapei de analiză și design. A se vedea clarificările de mai sus cu toate standardele relevante.

1. Sistemul contabil trebuie să asigure că situațiile financiare sunt generate pe baza codurilor contabile și nu a denumirilor. Pentru a prezenta situațiile financiare comparative, soldurile și sumele din perioada anterioară se reclasifică conform noii structuri contabile. Este necesar ca situațiile financiare (Bilanț contabil, Situația rezultatului global, Situația fluxurilor de mijloace bănești) să poată fi generate și în forma analitică până la nivel de cont analitic. Totodată, corectitudinea întocmirii situațiilor financiare este asigurată de controale interne și audit extern. 2. Prin maparea conturilor vechi cu cele noi în structura balanței contabile. IFRS prevede că, în cazul modificării politicilor contabile sau în prezentarea situațiilor financiare (inclusiv modificări ale structurii conturilor), entitatea trebuie să aplice aceste schimbări retroactiv sau să prezinte datele comparative ajustate corespunzător pentru a menține comparabilitatea. Pentru aceasta, este necesară o matrice de reconciliere care să asocieze fiecare cont vechi cu contul nou sau conturile noi, astfel încât soldurile și tranzacțiile perioadei anterioare să fie reclasificate conform noii structuri. Totodată, în situațiile financiare, conform IFRS, se includ note explicative privind aceste modificări, impactul lor asupra poziției financiare și performanței raportate, și metodele utilizate pentru ajustarea comparativelor.

Să poată fi configurate de utilizatori ca coloane suplimentare.

Datele pot fi colectate din modulul Achiziții (privind contractele semnate) și/sau modulul Bugetare (privind sumele achitate). Nu se intenționează colectarea datelor din aplicații externe pentru obligațiile financiare aferente achizițiilor publice.

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.

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.

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.

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).

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.

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”.

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.

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. 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. 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. 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).

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).

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.

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. 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. 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.

Î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.

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.

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ă.

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.

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.

BNM dispune de câteva subdiviziuni (locații), iar stocurile sunt înregistrate în dependență unde sunt utilizate/stocate, iar soluția trebuie să prevadă posibilitatea mișcării acestora (cu asigurarea perfectării documentelor primare aferente pentru fiecare mișcare).

Cerința respectivă este recomandabilă, iar în cazul în care sistemul prevede asemenea funcționalități, ar fi necesare următoarele posibilități tehnice: Normele de consum sunt definite prin acte interne aprobate în funcție de tipul de resursă consumată (combustibil, energie, etc.) și de condițiile de utilizare. Aceste norme sunt diferențiate în funcție de: perioadele sezonale: vara și iarna se stabilesc de regulă prin intervale calendaristice fixe (ex: aprilie-septembrie pentru vară; octombrie-martie pentru iarnă), sau prin alte criterii stabilite intern. Tipul de traseu: normele variază între intravilan (deplasări în interiorul localităților, cu consum specific redus) și extravilan (deplasări în afara localităților, cu consum mai mare, luând în calcul condiții de drum și distanțe). Sistemul ERP trebuie să permită configurarea acestor norme ca parametri și să efectueze verificarea automată a consumului efectiv față de normativ, semnalând eventualele depășiri. La fel, trebuie sa permita casarea in dependenta de consumul efectiv inregistrat in baza calculatorului de bord.

1. „Începutul inventarierii” este definit ca data și ora la care este inițiat procesul efectiv de inventariere. Începutul inventarierii poate (de regulă) să nu corespundă cu data/situația de referință a activelor, independent de mișcările ulterioare ale acestora (de exemplu, inventarierea începe pe data de 10 decembrie pentru activele conform situației din 01. Decembrie). 2. Da, se dorește ca să fie posibil ca operațiunile curente (intrări/ieșiri) să fie permise în timpul inventarierii (doar pentru anumite active/locuri de amplasare – activare la necesitate), astfel încât activitatea operațională să nu fie întreruptă. Pentru aceasta, sistemul ERP trebuie să permită gestionarea distinctă a acestor tranzacții, prin blocarea valorii de referință a stocului la momentul „înghețării” și înregistrarea ulterioară separată a mișcărilor curente, cu marcaj temporal. În etapa de reconciliere, se va putea compara stocul fizic cu cel „înghețat” ajustat cu operațiunile intervenite între momentul de referință și data finalizării inventarierii.

1. Imprimarea etichetelor cu coduri de bare/QR este necesară în special pentru imobilizările corporale, stocuri și bunurile materiale aflate în gestiune (cu valoare mică). 2. Soluția ERP trebuie să fie capabilă atât să genereze automat coduri de bare/QR, asociate unic fiecărui articol la momentul înregistrării acestuia în sistem, cât și să le citească ulterior prin scanare, pentru procese precum identificare, actualizare sau inventariere.

Tipurile de operațiuni sunt: Vânzări cu generarea documentelor de casă (în cazul achitărilor în numerar) și documentelor contabile (în cazul decontărilor prin sisteme de plăți (instant sau decontări pe bază brută sau netă)) cu reflectarea la venituri.

Procedura internă aferentă primirii numerarului de la producător în partea ce ține de ERP se referă doar la reflectarea plății aferente producerii numerarului și înscrierea acestuia în cont de extrabilanț.

1. Structura Bugetului administrativ fix la nivel de articol se reglementează prin acte normative interne si nu se modifică decât prin hotărârea managementului (Consiliu de supraveghere) - ultima modificare în anul 2016. Structura bugetului administrativ fix este disponibila pe pagina web oficiala la următorul link: Banca Națională a Moldovei | Articolele de buget sunt divizate în subarticole și elemente de venituri/cheltuieli (linii de buget), care, dacă apare necesitatea, pot fi ajustate anual în dependență de necesitățile identificate pentru anul bugetar. Astfel, este necesar ca sistemul să permită crearea de linii de buget noi și modificarea mapării acestora in fiecare an bugetar, până la aprobarea acestuia. Structura detaliată pe elemente detaliate (dezagregate la cel mai mic nivel) va fi prezentată în cadrul procedurii de analiză și design. Se vor ajusta unele elemente după modulul de bugetare standardizat al dezvoltatorului (bazat pe experiența similară a entităților financiare sau similare după dimensiune și activitate). 2. Revizuirile periodice la nivel de articol din buget se efectuează doar în baza unei hotărâri a managementului (Consiliu de supraveghere). Revizuirile in interiorul articolului de buget – se efectuează in baza unei note de rectificare inițiate de subdiviziunea responsabila de gestionarea sumei planificate și aprobată de management (membru Comitet executiv).

1.Structura Alocațiilor pentru investiții la nivel de articol se reglementează prin acte normative interne si nu se modifică decât prin hotărârea managementului (Consiliu de supraveghere) - ultima modificare în anul 2016. Structura alocațiilor pentru investiții este disponibila pe pagina web oficiala la următorul link: Banca Națională a Moldovei | Articolele din Alocații pentru investiții sunt divizate în sub articole și elemente de investiții capitale care, sunt definite anual în dependență de necesitățile de investiții capitale identificate. Astfel, este necesar ca sistemul să permită crearea de elemente noi și modificarea mapării acestora in fiecare an bugetar, până la aprobarea acestora. Structura detaliată pe elemente detaliate (dezagregate la cel mai mic nivel) va fi prezentată în cadrul procedurii de analiză și design. Se vor ajusta unele elemente după modulul de bugetare standardizat al dezvoltatorului (bazat pe experiența similară a entităților financiare sau similare după dimensiune și activitate). 2. Alocațiile pentru investiții cuprind într-un articol separat sumele aprobate în calitate de sursă de finanțare pentru contracte (de investiții capitale sau cheltuieli curente administrative) ce se planifică a se încheia pe parcursul anului bugetar, dar a căror executare (livrare/ prestare) urmează parțial sau total în anii următori celui bugetar – în scopul asigurării conformității cu prevederile Legii 131/2015 privind achizițiile publice.

1. Bugetul variabil este structurat pe categorii de instrumente de investiții /de politică monetară – nu există o structură aprobată. În principal, coincid cu structura claselor de venituri si cheltuieli prevăzute in planul de conturi. Sistemul trebuie să permită ajustarea acestuia de la o perioadă la alta (an bugetar). 2. Actualizarea datelor prognozate se va face in baza datelor primite de la subdiviziuni responsabile de prognoza cu completarea directa in ERP. Completarea datelor efective se va asigura prin importare din CBS. 3. Prognoza bugetului operațional variabil se efectuează considerând ratele de politică monetară prognozate pentru anul bugetar, structura/soldul portofoliul, inclusiv evoluția acestuia în prognoză, datele istorice, alte date. Structura detaliată pe elemente detaliate (dezagregate la cel mai mic nivel) va fi prezentată în cadrul procedurii de analiză și design. Se vor ajusta unele elemente după modulul de bugetare standardizat al dezvoltatorului (bazat pe experiența similară a entităților financiare sau similare după dimensiune și activitate).

1. Prognoza/planificarea se face la nivel de linie de buget (element de cheltuiala/venit) in valuta originala, pentru un an bugetar divizata pe trimestre, cu completarea obiectivului strategic la care se referă, după caz, și argumentarea necesității planificării si/sau modalitatea de estimare. Liniei de buget îi este atribuit un cont contabil analitic, subdiviziunea responsabil și beneficiară/e. 2. La moment, prognozele/propunerile de buget se prezintă în fișiere excel care sunt compilate ulterior de managerul de buget si introduse in aplicație separata pentru evidenta ulterioara privind executarea acestuia (aplicația utilizata doar pentru bugetul variabil operațional si bugetul administrativ fix; alocațiile pentru investiții se gestionează în totalitate în excel). Se urmărește ca sistemul informatic ce urmează a fi implementat sa permită completarea datelor enumerate direct in modulul Buget. Da, datele efective privind executarea bugetelor se completează automat in baza datelor din Cartea mare, prin interfațarea dintre aplicațiile CBS si ERP – pentru bugetul operațional variabil.

Soluția solicitată urmează să fie structurată după modele de procese, module și conținuturi care vor conține cel puțin datele de mai jos (utilizate la moment), totodată vor încorpora cerințele din sisteme performante de bugetare și gestiune resurse: - Nr. d/o; - Nr. cont analitic; - Tip buget (Admin, CAPEX, Operațional); - Articol buget; - Denumire element de buget; - Activul aferent (față de care se aplică bugetare – după caz); - Proiect (dacă e cazul); - Cost centrul (dacă diferă departament); - Coloane dedicate pentru completarea sumelor prognozate/planificate per trimestru pentru fiecare valuta; - Suma totala prognozata/planificata (ce însumează sumele trimestriale planificate recalculate in MDL in baza cursului mediu valutar prognozat per trimestru); - Sold stoc la 01 ianuarie; - Sold neexecutat contract în derulare la finele anului precedent; - Valoare contracte ce urmează a fi încheiate. Suma totala planificata = Sold stoc + sold neexecutat contracte + valoare contracte ce urmează a fi încheiate. - Detaliile privind modul de estimare a valorii bugetate/prognozate și, în cazul bugetului administrativ fix si alocațiilor pentru investiții - argumentarea necesității planificării; - Nr obiectivului strategic – daca poate legat; - Subdiviziunea responsabilă/subdiviziunile beneficiare. După aprobare - > linia creată, alocată la planul de achiziție.

Descrierea de mai jos este exemplul utilizat de BNM la moment, dar soluția solicitată poate să fie structurată după modele de procese, module și conținuturi de generații noi care vor acomoda cerința și prin alt flux. Prin încărcarea și configurarea planului strategic detaliat in ERP cu numere de referință atribuite fiecărui obiectiv astfel, încât subdiviziunea responsabilă de planificare să poată selecta automat nr obiectivului strategic pentru fiecare linie de buget planificată – dacă poate fi aliniat unui obiectiv. La fel, se acceptă corelarea planului strategic cu bugetul automat – în baza de anumite reguli predefinite pentru anumite articole/proiecte – daca sistemul va permite.

Descrierea de mai jos este exemplul utilizat de BNM la moment, dar soluția solicitată poate să fie structurată după modele de procese, module și conținuturi de generații noi care vor acomoda cerința și prin alt flux care deja este în sistemul ofertat. Pentru a menține comparabilitatea datelor bugetare între ani: - Toate articolele de buget vor fi codificate într-un nomenclator master, menținut la nivel central si imposibil de ajustat de la o perioada la alta; - La etapa de inițiere a procesului de elaborare a bugetului, se va duplica structura bugetului actual cu posibilitatea de completare cu linii bugetare suplimentare, cu marcarea altor elemente nerecurente ca inactive ERP-ul trebuie să susțină raportare multi-anuală standardizată, pe baza acestor mapări.

Bugetul este construit pornind de la fiecare unitate structurala din cadrul entității, care comunică propriile necesități bugetare, justificate pe baza activităților planificate. Aceste propuneri sunt apoi consolidate de subdiviziunea responsabilă de bugetare si gestionarea surselor aprobate. Metoda de sus în jos – la nivel de organizație se stabilesc anumiți indicatori minimi sau maximi, care se redistribuie ulterior subdiviziunilor sau liniilor de bugetare. Metoda de sus în jos poate aplica și ajustări în bugetul propus de subdiviziune în faza de reconciliere și balansare la indicatorii stabiliți la nivel de organizație.

Rata inflației (medie anuală, pentru anumite sectoare) – estimarea per trimestru bugetar viitor; utilizată în estimarea sumelor bugetate; PIB – valoarea nominala, rata prognozata de creștere; indicator utilizat pentru justificarea bugetului total, calculul indicatorilor relativi; Costul resurselor – ratele de politica monetara, alte rate de referință, rata medii de finanțare prognozate; utilizate pentru estimarea bugetului variabil operațional; Rata de schimb valutar – cursuri medii trimestriale prognozate (USD; EUR); utilizate pentru conversia sumelor planificate in valuta si pentru reevaluarea ulterioara a bugetelor la cursul actual. În cazul în care răspunsul nu corespunde întrebării adresate, reveniți va rog cu detalii suplimentare privind datele de furnizat solicitate. Rata dobânzii la nivel de portofoliu Volumul activității (indicatorilor specifici) – active, datorii specifice.

Cu posibilitatea definirii a unui/ mai multe praguri de alerta: - % din bugetul aprobat - Daca rata lunară depășește media istorica cu un anumit % - Trend prognozat mai mare decât cel bugetat etc - Alte.

Dacă în buget a avut loc o rectificare care vizează și planul de achiziție, să fie opțiunea automată de „Verificare și actualizare plan achiziții”. Sistemul va notifica persoana responsabilă din subdiviziunea de achiziții care va verifica și fie va accepta fie va respinge modificarea și în planul de achiziție. Planul se modifică pe elemente și sume doar după ce se fac modificările în buget, nu poate fi situația inversă. Alte coloane din plan, care nu au legătură cu bugetul nu se vor corela cu bugetul, dar vor putea fi modificate distinct. Fiecare departament (subdiviziune structurală) poate modifica doar bugetul său nu și bugetul altor subdiviziuni, respectiv, nu pot fi situații paralele. Modalitatea de implementare a funcționalității de modificare a bugetului/planului de acțiuni: automatizată, cu notificare, reversare, aprobare, coordonare este necesară la nivel de sistem, astfel ca modificările între cele 2 să fie coerente și compatibile cu practicile și controalele interne între cele 2 documente și regulile principale în bugetare, achizițiilor și cost control (de ex. dacă o solicitare de majorare a planului de achiziții este efectuată, dar sistemul pe linia respectivă de buget sau cost centru alocat în planul de achiziții nu identifică resurse suficiente, atunci această modificare se respinge automat fie se escaladează la departamentul financiar pentru modificare de buget alt exemplu: realocarea unei linii bugetare pe altă linie bugetară va declanșa automat modificarea planului de achiziții și în dependență de acțiunea selectată – va exclude poziția din planul de achiziții fie o va modifica, fie în cazul în care achiziția pe linia respectivă de buget deja s-a realizat și e angajată, va notifica managerul de buget despre imposibilitatea efectuări realocărilor și va declanșa notificări și fluxurile necesare; alt exemplu: un buget suplimentar este primit pe parcursul anului pentru o achiziție, modificare de buget poate automat genera majorarea planului de achiziții, fie poate notifica despre disponibilitate de buget și dreptul de alocare a noilor resurse în planul de achiziții (în dependență de flux); alt exemplu: o achiziție este inițiată, valoarea cotată este mai mare decât valoarea din planul de achiziție, subdiviziunea solicită majorarea planului și majorarea bugetului, prin indicarea sursei din același centru de cost și același tip de cheltuieli. În acest caz, sistemul aplică controalele setate (același centru de cost, aceeași linie bugetară și aceleași cheltuieli) și efectuează modificările automatizat la nivel de plan de achiziție și buget, cu notificare. alt exemplu: Managerul de proiect solicită anularea poziției din planul de achiziții, Sistemul actualizează automat bugetul și eliberează fondurile alocate, modificarea este înregistrată în istoricul bugetar cu justificare și audit trail. an alt exemplu: Din cauza variației cursului EUR/MDL, valoarea estimată pentru o achiziție de software trebuie actualizată sau se efectuează actualizarea trimestrială (la necesitate). Flux: sistemul aplică regulile de ajustare predefinite (ex. % indexare trimestrială, la PAAP și buget). Se notifică automat utilizatorii și managerul financiar. Noua valoare este transmisă către sistemul de Achiziție și documentele aferente sunt marcate ca „revizuite”, spre aprobare.

Informația a fost inclusă cu scop informativ, deoarece raportarea se face printr-o platformă națională. Important este doar ca soluția achiziționată să facă distincție între aceste categorii de achiziții.

Toate elementele de buget sunt determinate in baza unei prognoze, în cazul în care entitatea nu dispune de date exacte privind sumele efective a fi înregistrate în anul bugetar (oferta comerciala, contract semnat în derulare). Într-o aplicație de bugetare și planificare financiară, prognoza trebuie să acopere toate componentele relevante ale situațiilor financiare și ale bugetului, nu doar amortizarea. Obiectivul este de a obține o imagine realistă și anticipativă a poziției financiare și performanței BNM pentru perioadele viitoare.

1. Surse de completare - alte module din ERP – completare automată - rapoarte statistice periodice completate de subdiviziuni - sisteme externe (aplicații de evidență a timpului de munca) etc 2. Urmează a fi predefinite la etapa de design a modulului pe bază de funcționalitățile sistemului selectat (acesta trebuie să fie un sistem de evidența managerială a costurilor cu formule de alocare prestabilite și adaptabile).

Sursele din ERP și CBS (datele istorice). La fel sursa de date poate fi în fișiere Excel, date introduse manuale, Bloomberg (gestiunea portofoliilor valutare), CBS, Limitat. Bază istorică + prognoză

Descrierea de mai jos este exemplul analizat de BNM la moment, dar soluția a fost solicitată să vină cu modele, fluxuri și activități deja prestabile (bune practici testate) care vor fi preluate. - Introducere a unui centru de cost de sub activitate unde sunt automat colectate aceste sume; - Rapoarte comparative: cost complet / cost eficient / cost ajustat; - alte posibilități oferite de soft.

Rugăm respectuos să explicați întrebarea, în cazul în care răspunsul de mai jos formulat este insuficient. Durata de viață economică poate fi mai lungă decât durata de amortizare contabilă. După expirarea amortizării, activul continuă să funcționeze - nu mai generează cheltuială privind amortizarea acestuia, dar îi trebuie asigurată mentenanța. Analiza duratei de viață reale ajută la: - Planificarea privind înlocuirea activului; - Identificarea riscului de subestimare a costurilor reale de întreținere; - Optimizarea duratei de amortizare.

Plan provizoriu de achiziții (PPA) este un plan de achiziții care nu are legătură cu bugetul și servește drept instrument de planificare și inițiere a achizițiilor până la aprobarea bugetului. Doar Planul anual de achiziții (PAA) va fi corelat cu bugetul. Diferența între PPA și PAA constă în aceea că în ultimul apare încă o coloană cu elementele de cheltuieli care fac legătura cu bugetul. PPA este preluat automat in PAA.

Ideea este următoarea: subdiviziunile elaborează planul subdiviziunii și îl transmit către departamentul de achiziții spre verificare (de jos în sus), în cazul în care se identifică careva erori, soluția trebuie să permită departamentului de achiziții să propună modificări, ajustări care să fie coordonate/acceptate de subdiviziunea vizată (de sus în jos).

Dacă în buget sunt create noi elemente de cheltuieli sau sunt modificate elementele de cheltuieli existente, care vizează și planul de achiziție, să fie generată automat acțiunea de „Verificare și actualizare plan achiziții”. Sistemul va notifica persoana responsabilă din subdiviziunea de achiziții care va verifica și fie va accepta fie va respinge modificarea și în planul de achiziție. Semiautomat înseamnă că o persoană din departamentul de achiziții va verifica și valida sau respinge actualizarea.

Planul de achiziții include 4 capitole: Bunuri, Servicii, Lucrări, Exceptate. Fiecare capitol include mai multe poziții și mai multe coloane, una din coloane va fi Statutul achiziției, unde se va reflecta, în funcție de etapa achiziției, unul din următoarele statute: neinițiat, inițiat, inițiat repetat, anulat, contract, executat. Important, pe o poziție din plan pot fi mai multe achiziții inițiate, de exemplu, dacă nu s-au atribuit toate loturile din prima achiziție, atunci se reinițiază, iar aceste statute ar trebui să fie pentru fiecare inițierea de achiziție distinct reflectate. Pentru mai multe detalii, va rugam sa consultați PAA publicat pe pagina oficiala a BNM Plan de achiziții al BNM | Banca Națională a Moldovei.

Planificarea stocurilor se va realiza diferențiat pe categorii, în funcție de natura articolelor, frecvența consumului, termenele de livrare și specificul procesului de achiziții. Pentru articolele uzuale, nivelul minim de stoc se va calcula ca produs între consumul mediu zilnic și numărul de zile estimat pentru completarea ciclului de aprovizionare (care include toate etapele: inițiere, aprobare, achiziție, livrare), la care se va adăuga un stoc de siguranță. Pentru articolele critice, sezoniere sau cu termen de expirare, se vor aplica reguli suplimentare de control al stocului, bazate pe risc, sezonalitate sau valabilitate.

1 Informații specifice de urmărit: Număr și dată garanție, tip garanție (ofertă/de bună execuție), furnizor/ofertant/contraparte, suma garanției, moneda, modalitatea de constituire: transfer, scrisoare, banca emitentă, perioada de valabilitate, data scadenței, obiectul contractului/procedura de achiziție aferentă, datele bancare pentru garanțiile prin transfer (CF, IBAN, codul băncii), adresa de restituire pentru garanțiile sub formă de scrisoare de garanție (la necesitate, dacă scrisoare necesită restituire) statutul garanției (activă, expirată, rambursată, executată). 2. Rambursarea garanțiilor se face pa baza unui flux setat la nivel de sistem: - Rambursarea manuală înainte de scadență – la inițierea manuală de către subdiviziunea Direcția achiziții; - Rambursarea automatizată – la data scadenței garanției, sistemul inițiază rambursarea garanției, spre verificare financiară și autorizare plată (sau spre plată) conform datelor bancare sau adresei din descrierea garanției din sistem.

Informații specifice de urmărit pentru garanțiile de bună execuție: Număr și dată garanție, furnizor/prestator/executor contract, contract asociat, procedura de achiziție sau contractul aferent căruia se aplică (legat de comanda sau contractul din sistemul de achiziție) suma garanției, moneda, modalitatea de constituire: rețineri din facturi, scrisoare de garanție bancară; banca emitentă, perioada de valabilitate, termen de returnare/eliberare, statut (activă, expirată, rambursată, executată), datele bancare pentru garanțiile prin transfer (CF, IBAN, codul băncii), adresa de restituire pentru garanțiile sub formă de scrisoare de garanție (la necesitate, dacă scrisoare necesită restituire) condiții de executare sau restituire. Pentru sumele reținute din facturi: furnizor/prestator, factura din care s-a făcut reținerea, suma reținută, procentul reținut, moneda, contractul asociat, etc.

Tipuri de documente: pdf, word, excell, jpg, email. Unele documentele pdf vor fi semnate electronic și este necesară existența unui mecanism care să valideze și să afișeze semnătura electronică aplicată.

Se așteaptă ca generatorul de rapoarte să dispună de o interfață modernă, intuitivă și prietenoasă cu utilizatorii non-tehnici, similară cu cele oferite de instrumentele moderne de Business Intelligence (BI). Utilizatorii trebuie să poată selecta cu ușurință seturi de date, să aplice filtre multiple, să salveze și să reutilizeze criteriile de selecție, fără a fi necesare cunoștințe tehnice avansate sau scriere de cod.

La darea în exploatare, soluția va asigura generarea rapoartelor standarde oferite în mod nativ de soluție și un număr minim de 75 de rapoarte customizate pentru fiecare lot, adițional la cele oferite în mod standard (nativ) de către soluție, care vor include atât un număr de rapoarte predefinite cât și speciale. Numărul de rapoarte standard predefinite va fi posibil de estimat în cadrul etapei de analiză și design.

1. Instituțiile de stat către care se transmit aceste rapoarte sunt: Serviciul Fiscal de Stat, Biroul Național de Statistică; Aplicațiile web specifice pentru transmitere sunt: www.sfs.md. 2. Da, există formatul electronic – XML, CSV

Componenta de generare a rapoartelor trebuie să fie suficient de flexibilă pentru a permite configurarea de rapoarte ad-hoc de către două categorii de utilizatori, cu niveluri diferite de competențe tehnice. Utilizatorii non-tehnici trebuie să poată crea rapoarte printr-o interfață grafică intuitivă, folosind filtre, grupări și opțiuni de afișare simple, fără a necesita cunoștințe de interogare a bazelor de date. În același timp, utilizatorii cu profil tehnic vor avea posibilitatea de a construi rapoarte avansate, cu interogări complexe, transformări și agregări de date. Accesul la date pentru configurarea rapoartelor va fi controlat, utilizatorii având vizibilitate doar asupra unui set predefinit de câmpuri, stabilit în funcție de rolurile și drepturile asociate.

Lista preliminară a tipurilor de excepții pentru care este necesar raport de excepție: tranzacții anulate, tranzacții în curs de execuție , tranzacții respinse (de ex anulate în SAPI), tranzacții duplicate, stornate, etc. Menționăm că lista excepțiilor este una orientativă și va fi definitivată în cadrul etapei de analiză și design.

Prin „on-line” se înțelege capacitatea sistemului de a genera rapoarte operaționale la cerere, cu execuție imediată, în baza datelor disponibile în acel moment, fără întârziere sau preprocesare prealabilă. Acest tip de raportare este esențial în contextul proceselor operaționale critice, precum verificarea soldurilor, a limitelor sau a mișcărilor contabile. Astfel, termenul implică atât disponibilitatea în timp real a funcției de generare a raportului, cât și actualitatea datelor prezentate în raport.

Pentru rapoartele nestandarde, configurate ad-hoc de către utilizatori, utilizatorii vor putea alege tipul de grafic și aspectul acestuia, iar pentru cele predefinite și cele speciale, tipul de grafic și aspectul acestuia vor fi determinate la etapa de analiză și design.

Lista formatelor de export menționată este exemplificativă, nu exhaustivă. Totuși, se așteaptă ca soluția să suporte exportul în cele mai uzuale formate, precum XLSX, CSV, XML, PDF și altele similare. În ceea ce privește structura fișierelor exportate, nu există cerințe prestabilite sau template-uri standard, cu excepția cazurilor în care rapoartele au un caracter reglementat de cadrul legal. Pentru aceste situații, template-urile necesare vor fi furnizate în etapa de analiză și design, în vederea asigurării conformității.

Se așteaptă ca soluția să permită utilizatorilor personalizarea flexibilă a rapoartelor existente, fără intervenție din partea echipei IT. Printre elementele care ar trebui să poată fi modificate se numără: adăugarea sau eliminarea câmpurilor din raport, modificarea ordinii acestora, aplicarea de filtre și criterii de selecție, gruparea datelor după unul sau mai mulți parametri, sortarea și formatarea rezultatelor (de exemplu, stiluri de afișare, evidențiere condițională, agregări). De asemenea, utilizatorii trebuie să aibă posibilitatea de a salva versiunile personalizate ale rapoartelor pentru reutilizare ulterioară.

Interacțiunea prin acțiuni de tip „click” și „drag and drop” este așteptată atât în contextul generatorului de rapoarte ad-hoc, cât și pentru personalizarea rapoartelor standard, în măsura în care acestea permit modificări. Scopul este de a oferi o experiență intuitivă și accesibilă utilizatorilor non-tehnici, permițându-le să ajusteze conținutul, structura și prezentarea rapoartelor fără a scrie cod.

Soluția trebuie să fie compatibilă cu cele mai utilizate browsere moderne, precum Google Chrome, Microsoft Edge și Mozilla Firefox, în versiunile lor suportate oficial de producători. De asemenea, se așteaptă ca tehnologiile web utilizate (ex. HTML5, CSS3, JavaScript) să fie conforme cu standardele actuale, pentru a asigura o experiență stabilă, responsivă și securizată în mediul web. Eventualele cerințe suplimentare privind compatibilitatea vor fi discutate în etapa de analiză și design.

Dimensiunile cheie pentru analizele multidimensionale vor fi stabilite în funcție de specificul proceselor și structurii organizaționale și pot include, de exemplu: tipul de activitate, subdiviziunea, perioada de analiză / referință (zi, lună, trimestru, an), utilizatorul/responsabilul de proces, tipul operațiunii sau categoria de cheltuială/venit. Indicatorii de performanță vor fi definiți în cadrul etapei de analiză, împreună cu echipele funcționale, și pot include: timpi de procesare, gradul de realizare a activităților planificate, volume procesate, rata de eroare, sau alți KPI relevanți pentru monitorizarea eficienței și eficacității proceselor interne. Soluția trebuie să permită configurarea și urmărirea acestor indicatori în mod flexibil, inclusiv posibilitatea de a agrega, filtra și compara datele pe diverse dimensiuni.

Prin text derulant se subînțelege „scrolling text” ceea ce presupune afișarea parțială a informației de mai multe caractere într-o casetă derulantă. Prin „narative” se subînțeleg indicatorii în format descriptiv/text.

Lista tipurilor de grafice este una exemplificativă, nu exhaustivă. Totodată, așteptarea este că aceste forme reprezentate sunt cele mai reprezentative și soluția va dispune de aceste funcționalități. Pentru rapoartele nestandarde, configurate ad-hoc de către utilizatori, utilizatorii vor putea alege tipul de grafic și aspectul acestuia, iar pentru cele predefinite și cele speciale, tipul de grafic și aspectul acestuia vor fi determinate la etapa de analiză și design.

Da, cerința vizează posibilitatea de a afișa aceleași informații, extrase dintr-un singur set de date, în formate diferite – de exemplu, tabelar și grafic – simultan, într-un mod unificat, cum ar fi într-un dashboard sau o interfață integrată de raportare. Scopul este ca, printr-o singură comandă de executare, utilizatorul să poată vizualiza și interpreta datele atât numeric, cât și vizual, fără a fi necesare acțiuni suplimentare sau generări separate.

Formatul și structura detaliată a metadatelor vor fi definite în etapa de analiză, în funcție de specificul soluției și al cerințelor ce reies din necesitățile identificate pe procese. Totuși, în mod implicit, metadatele trebuie să includă cel puțin următoarele informații: denumirea câmpului, descrierea acestuia, tipul de date (numeric, text, dată etc.), formatul, valorile permise (acolo unde este cazul), relațiile dintre entități (chei primare/străine), frecvența actualizării și sursa datelor. Accesul la aceste metadate trebuie asigurat pentru utilizatorii avansați implicați în dezvoltarea de rapoarte și analize, într-o formă structurată, clară și ușor de consultat, astfel încât să le permită înțelegerea corectă a structurii și conținutului datelor disponibile, fără a necesita intervenții tehnice frecvente.

Soluția trebuie să permită conectarea flexibilă la surse de date externe, pentru a facilita extinderea și corelarea informațiilor utilizate în raportare. În acest sens, este necesar ca soluția să ofere conectori universali (ex. ODBC), care să permită accesul la diferite baze de date relaționale (ex. Oracle, SQL Server, PostgreSQL), posibilitatea de a importa date din fișiere Excel/CSV, precum și integrarea cu surse externe prin intermediul serviciilor web (API REST/SOAP). Lista exactă a surselor de date va fi stabilită în etapa de analiză, în funcție de cerințele operaționale și funcționale ale BNM.

Formatarea condițională a datelor la nivel de sistem este una obligatorie, conform cerinței din caietul de sarcini. Totodată, formatarea condițională a datelor la nivel de utilizator este una binevenită.

Cerința se referă la salvarea filtrelor la nivel de utilizator. Totodată, dacă soluția va suporta partajarea filtrelor cu alți utilizatori, acest aspect va fi binevenit.

Alte modele de comparație sunt cele pe care soluția le poate oferi, suplimentar la cele de tip „date – to -date” și „year-to-date”, cum ar fi „month – over – month”, „quarter over quarter”, „year-to-year”, etc. În contextul cerinței, DTD se referă la „date-to-date”, inserția ,,document type definition” se referă la o omisiune de detaliere a abrevierii.

Pentru rapoartele nestandarde, configurate ad-hoc de către utilizatori, utilizatorii vor putea crea și aplica propriile șabloane de stil, iar pentru cele predefinite și cele speciale, șabloanele de stil vor fi determinate la etapa de analiză și design.

Soluția trebuie să încorporeze tehnici specifice de prognoză utilizate pe larg de entități din sectorul bancar în bugetare sau contabilitate de gestiune. Dintre cele mai uzuale ar fi: - Simulări – pentru testarea diferitor ipoteze și impactul acestora asupra bugetelor și costurilor. - Medie mobilă – pentru detectarea tendințelor pe termen scurt. - Regresie liniară – pentru modelarea relațiilor dintre costuri si variabile explicabile (de ex. volum de activitate, prețuri materiale).

Principalii indicatori economico-financiari care trebuie simulați sunt: - indicatori bugetari și operaționali (prognoza veniturilor si cheltuielilor, a rezultatului financiar); - indicatori de eficienta si performanta instituționala ( cost per proces, per proiect, serviciu prestat etc); - prognoza poziției financiare; etc.

De regulă, rapoartele vor fi semnate cu semnătură calificată. Totodată, în cazul rapoartelor destinate altor contrapărți, sistemul va asigura posibilitatea aplicării semnăturii avansate. Aplicația trebuie să suporte explicit (la implementare) integrarea cu serviciul național de semnătură electronică calificată (Msign – msign.gov.md).

Formatul de export către DataWarehouse va fi stabilit de comun acord la etapa de analiză și design în funcție de capabilitățile soluției, arhitectura tehnică agreată etc. și poate include fișiere (CSV, XML), conexiuni directe la baza de date (prin ODBC/JDBC), sau integrare prin API-uri. Așteptarea este ca soluția să ofere flexibilitate în alegerea metodei de export, inclusiv posibilitatea programării extragerilor automate. În prezent, în cadrul BNM sunt utilizate mai multe instrumente de tip BI, fără o soluție unică preferată. Prin urmare, soluția propusă trebuie să fie deschisă integrării cu instrumente BI standard de pe piață (ex. Microsoft Power BI, Tableau, Qlik, SAS Visual Analytics etc.), în baza unor mecanisme comune de interconectare și acces la date.

Anularea/corectarea automată se referă la faptul că soluția trebuie să permită, conform unor reguli prestabilite, în baza unui declanșator manual/automat (API, reguli de business, etc.) să anuleze / corecteze pașii / etapele din flux precedenți. De exemplu, dacă tranzacțiile cu privire la o factură nu au fost finalizate în ziua operațională, la închiderea zilei operaționale tranzacțiile respective se vor anula în mod automat. Este de menționat că orice acțiune de anulare/corectare automată trebuie să indice utilizatorul care a inițiat anularea/corectarea, timpul efectuării modificării, etc cu păstrarea istoricului acțiunilor efectuate (trasabilitatea completă).

Tranzacțiile semi-automate presupun implicarea la o anumită etapă a unui utilizator cu funcție de inițiere sau validare a unei tranzacții. Necesitatea intervenției utilizatorului depinde de o anumită caracteristică a tranzacției (contrapartidă, valoare, etc) conform unor reguli prestabilite (matrice de aprobare).

Documente standardizate sunt documente aferente unor tranzacții/operațiuni recurente, de obicei generate automat, au formate prestabilite, reglementate de norme contabile,legislație fiscală sau proceduri interne. Documentele în formă liberă sunt documente fără un format fix utilizate complementar, în special atunci când nu există un document standard corespunzător sau în situații atipice (de ex. în contextul corecțiilor, ajustărilor sau tranzacțiilor atipice).

Formule contabile integrate sunt acele formule contabile care sunt direct legate de procesele operaționale ale sistemului (ex: achiziții , plăți, salarizare, amortizare etc) și care se generează automat pe baza acțiunilor efectuate în sistem. Aceste formule sunt predefinite și asigură înregistrarea în contabilitate în timp real, fără intervenție manuală. De ex: la înregistrarea unei facturi de la furnizor, sistemul generează automat nota contabilă aferentă; la calcularea salariilor, sistemul înregistrează automat cheltuiala și reținerile corespunzătoare. Formulele contabile neintegrate sunt cele care nu sunt asociate direct cu procesul operațional și trebuie generate și completate manual de către utilizator (de ex: note contabile cu formă liberă pentru Debit cont și Credit Cont, o operațiune neuzuală, înregistrările contabile de corectare etc).

Formularul este un tip de „document template” specific, care derivă din cadrul legal.

Având în vedere volumetria tranzițiilor care este mică comparativ cu orice altă entitate care de regulă are mai multe locații, clienți, furnizori, etc, volumetria tranzițiilor BNM nu constituie un punct critic care ar afecta performanța sistemului.

Ordinea închiderii tranzacțiilor va fi configurată în cadrul sistemului, individual pe fiecare tip de tranzacție.

Prin scanarea codului de bare/cod QR se subînțelege preluarea anumitor informații dintr-un anumit câmp, cele mai uzuale extrageri fiind identificatorul unui activ sau referință link la un document/tranzacție. Cu referire la „selectare/link la alte documente, module”, sistemul va permite redirecționarea la document/modul indicat în link. Detaliile vor fi convenite la etapa de analiză și design.

Așteptarea este ca limita de dimensiune per fișier să fie un parametru configurabil. În general, limita uzuală este de 50 MB per fișier. Modalitatea de stocare și accesare pentru atașamente va fi asigurată de soluția oferită.

Cca 20-25 tipuri de comisioane și penalități diferite, formulele de calcul de regulă se bazează pe următoarele principii: -% din suma (din baza de calcul din tranzacția supusă comisionării); -% din sumă + sumă fixă min sau maxim (cu intervale de suma (min/max)) -Sumă absolută pe unitate de tranzacție; -Sumă absolută periodică; și alte tipuri (posibil pe viitor sa avem sume fixe, %+suma fixa). Totodată, sistemul nu va limita tipul și numărul de comision care trebuie gestionat.

Reversarea înregistrării contabile în limita soldului inițial presupune reversarea (stornarea) doar în limita sumei înregistrate inițial în cont și trasată apoi în sold (de ex. daca inițial s-a reflectat la cheltuieli suma de 1000 u.c., sumă trasată în sold, atunci stornarea cheltuielii respective poate fi efectuată doar în limita soldului inițial de 1000 u.c.).

Sistemul trebuie să permită definirea rolurilor și a limitelor pe fiecare rol, conform cerințelor din caietul de sarcini. Respectiv, fiecărui rol îi va fi atribuit unui anumit utilizator. Drept exemple de limite la nivel de executor: o tranzacție încheiată de un dealer (executor), suma plăților autorizate de un contabil vs. un director contabilitate; tranzacții care pot fi autorizate de anumiți executori din contabilitate (de ex. imposibilitatea autorizării de un contabil salarizare a unor operațiuni de administrare active financiare etc.)

Exemple de metadate care trebuie integrate și utilizate în căutări pot fi: după tip tip de tranzacție, după executor, etc. Sistemul trebuie să asigure flexibilitate în stabilirea metadatelor. Totodată, tipul căutărilor și metadatele asociate vor fi stabilite la etapa de analiză și design.

Sistemul trebuie să fie suficient de flexibil astfel încât să permită că toți parametrii de proces să fie configurabili, dar în general, nu sunt modificări frecvente în domeniul legislației contabile/fiscale.

În general, toate protocoalele/formatele standardizate sunt aplicabile și acceptabile. Totodată, preferabil sunt protocoalele REST/JSON și mecanismul de autentificare JSON Web Token (JWT).

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. Totodată, este de menționat că toată documentația necesară va fi transmisă la etapa de analiză și design. Toate integrările trebuie realizate prin ESB, prin API-uri. Frecvența de încărcare a datelor va fi stabilită în funcție de sistem, sursă și procese vizate.

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. Totodată, este de menționat că toată documentația necesară va fi transmisă la etapa de analiză și design. Toate integrările trebuie realizate prin ESB, prin API-uri. Frecvența de încărcare a datelor va fi stabilită în funcție de sistem, sursă și procese vizate.

Cazurile/tipurile de documente care vor necesita semnătură electronică avansată calificată sunt cele solicitate conform legislației în vigoare a Republicii Moldova. Lista completă a cazurilor/tipurilor de documente va fi determinată la etapa de analiză și design. Documentația tehnică pentru integrarea cu infrastructura PKI națională va fi pusă la dispoziție de către Beneficiar la etapa de implementare a proiectului. Fluxul de semnare trebuie să fie integrat în fluxul general de gestiune a proceselor implementat în cadrul soluției.

Furnizorul soluției Core-banking, conform cerințelor trebuie să fie și furnizorul componentei de integrare (Enterprise Service Bus – ESB). Respectiv, furnizorul soluției de Corebanking, are și rolul de coordonator integrator principal. Acesta va avea responsabilitatea de a elabora și valida arhitectura generală de integrare, de a defini formatele de schimb de date și protocoalele utilizate, precum și de a valida conformitatea tuturor interfețelor (ERP, Core-banking, sisteme adiacente) cu cerințele de integrare stabilite. BNM va acționa ca autoritate de arbitraj și validare în cazurile în care apar divergențe tehnice sau funcționale între participanți.

Aplicația Va-Bank este o soluție dezvoltată și întreținută in-house de către echipa tehnică a BNM. În contextul preluării datelor necesare pentru perioada de tranziție, echipa de implementare BNM va pune la dispoziția ofertantului seturile de date necesare, în funcție de necesitățile de integrare și de evidență contabilă temporară. Transferul de date se va putea realiza prin diferite metode agreate de părți cum ar fi fișiere CSV structurate, generate automat sau la cerere, sau prin scripturi de extragere automată la nivel de bază de date, pentru a permite integrarea mai eficientă și adaptată specificului soluției propuse. Structura exactă a datelor (ex. solduri, rulaje zilnice, conturi analitice etc.), formatele, câmpurile, volumele estimate și frecvența de actualizare vor fi stabilite și documentate în detaliu în cadrul etapei de analiză și design, în colaborare directă cu echipa tehnică a BNM.

Conform CI.175 Perioada de exploatare experimentală pentru fiecare soluție ofertată începe cu a doua zi după finalizarea etapei de Go live și durează cel puțin 3 luni. Activitățile principale aferente suportului oferit în perioada de exploatare experimentală (soak) a se consulta în Caietul de sarcini Compartimentul 2.7. Perioada de exploatare experimentală (soak), CI.167 – CI.183.

Cerințele cu privire la Cartea Mare (General Ledger) sunt stabilite și incluse în cerințele funcționale ale ambelor loturi, la lot I - „1. Evidența contabilă și gestiune financiară” și la lot II - „1. Cerințe față de procesele aferente soluției ERP - 1. Evidența contabilă și gestiunea financiară și materială”. 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. IMPORTANT: Data: 06.06.2025 / 10:13 Subiectul întrebării: Soluția trebuie să permită utilizarea conturilor intermediare, de oglindă sau conturilor concurente pe aceași tranzacție/document (de ex. IBAN client și contul contabil al BNM). Întrebare: 1.Puteți explica mai detaliat conceptul de "conturilor intermediare, de oglindă sau conturilor concurente" și cum ar trebui să funcționeze acestea în practică? Deoarece s-a acordat un răspuns eronat la această întrebare mai sus, Vă rog să găsiți răspunsul corect și complet la întrebarea acordată: Această cerință se referă la capacitatea sistemului de a efectua înregistrări contabile simultan în mai multe conturi aferente în cadrul aceleiași tranzacții sau aceluiași document. De exemplu: - într-o tranzacție de plată, sistemul trebuie să efectueze înregistrări atât în contul IBAN al clientului (utilizat în scopuri operaționale, adică cont în oglindă), cât și în contul intern al BNM (utilizat pentru evidența contabilă a BNM). - de asemenea, sistemul trebuie să susțină cazurile în care este implicat un cont intermediar (de exemplu, un cont de decontare sau tranzit), alături de contul principal. Această funcționalitate trebuie să fie bazată pe reguli și să fie configurabilă, permițând asocierea mai multor conturi aceluiași flux tranzacțional, fără a necesita înregistrări manuale separate. Fiecărui participant în Sistemul automat de plăți interne (SAPI), administrat de BNM, i se deschide în SAPI câte un cont de decontare pentru efectuarea decontărilor cu alți participanți SAPI (de ex.: 3521nnnn – cont curent al unei bănci comerciale în SAPI, 4851nnnn – cont curent al BNM în SAPI), conturi care sunt deschise paralel și în registrele contabile ale BNM din sistemul informațional de evidență contabilă, acestea reprezintă conturile „de oglinda”. BNM recepționează din SAPI datele despre decontările efectuate între participanții SAPI și le înregistrează în sistemul sistemul informațional intern de evidență contabilă, astfel soldurile conturilor corespunzătoare în sistemul intern al BNM și cele din SAPI coincid. În ordinele de plată perfectate în sistemele interne ale participanților SAPI și al BNM sunt indicate conturile IBAN sau conturile bilanțiere interne. Ordinele de plată se transmit în SAPI prin instrucțiuni de plată (mesaje MX) în care sunt indicate atât conturile IBAN, cât și conturile de decontare ale plătitorului și ale beneficiarului. În SAPI decontarea are loc între conturile de decontare ale participanților SAPI, iar conturile IBAN sunt utilizate pentru decontările finale în sistemele interne ale participanților. Conturile de tranzit 4851 ale BNM deschide în SAPI (BNM are 2 conturi 4851 deschise în SAPI) sunt utilizate pentru decontările care au loc în SAPI cu alți participanți. Exemple: a) Ordin de plata inițiat de BNM în adresa unei bănci rezidente: 1. Dt IBAN al BNM - MD55NB000000000000929221 ”Cheltuieli de intretinere si reparatie a obiectelor social-culturale” Ct 48514140 ”Cont de tranzit privind decontarile interbancare” (cont de decontare al BNM in SAPI) 2. Dt 48514140 ”Cont de tranzit privind decontarile interbancare” (cont de decontare al BNM in SAPI) Ct 35214325 (cont de decontare al bancii rezidente in SAPI) (si deja in sistemul bancii rezidente Ct IBAN- MD50ML000000022516211534) b) Ordin de plata inițiat de o bancă rezidentă în adresa BNM: 1. Dt 35214325 (cont de decontare al bancii rezidente in SAPI) (si deja in sistemul bancii rezidente Dt IBAN- MD20VI103600099000056MDL) Ct 48514140 ”Cont de tranzit privind decontarile interbancare” (cont de decontare al BNM in SAPI)_ 2. Dt 48514140 ”Cont de tranzit privind decontarile interbancare” (cont de decontare al BNM in SAPI) Ct IBAN- MD36NB000000000035243701 ”Disponibilitati ale bancilor rezidente rezervate pentru operatiuni in numerar - BC "XXX" S.A.” Vă mulțumesc.

Nu există un model de referință pentru procesele BNM. Ca punct de plecare pentru preconfigurarea proceselor viitoare ale soluției vor servi procesele descrise (To Be), care vor fi adaptate la funcționalitățile soluției dacă în mod critic nu va fi necesară customizarea solutiei. Cu referire la sesiunile demo – nu avem aștepări exacte de fidelitate, nivelul de fidelitate va fi în măsura flexibilității soluția (workflow-uri, customizări posibile, etc) și capacității de configurare și parametrizare a proceselor. Insistăm ca sesiunile demo să fie pe efectuate pe un sistem funcțional, nu simulare. Format sesiunilor demo este unul live. BNM nu are un șablon pentru specificațiile de design. Șablonul specificațiilor de design va fi cel al ofertantului, conform metodologiei aplicate de către acesta. Lista celor 75 de rapoarte customizate pentru fiecare lot, adițional la cele oferite în mod standard de către soluție, va fi definită în comun de către BNM și Ofertant în etapa de analiza și design. Soluțiile utilizate la moment de către BNM și cu care va necesita să fie integrată soluția ofertată sunt enumerate în Anexa 10. 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. BNM a inclus în perimetrul acestui proiect necesitatea privind integrarea efectivă de către Ofertantul câștigător, a soluției IT ofertate cu soluțiile enumerate în Anexa 10 la Caietul de sarcini.

Validarea parametrilor de configurare va fi realizată într-o manieră etapizată. Validarea primară va avea loc în cadrul etapei de analiză și design, printr-un proces colaborativ între echipa ofertantului și echipa BNM. Aceasta se va realiza în baza practicilor și metodologiilor proprii ale ofertantului, care vor fi expuse și descrise în oferta tehnică. Totodată, BNM se așteaptă ca aceste practici să fie susținute de mecanisme concrete, precum tabele de parametri configurabili, exemple de configurare contextualizate, prototipuri funcționale sau demo-uri, sesiuni de validare aplicativă împreună cu utilizatorii relevanți etc. Interfețele de integrare cu alte aplicații pot fi atât sincrone, cât și asincrone, în funcție de natura procesului de activitate și de caracteristicile sistemelor sursă/țintă. În general, se preferă utilizarea unor API-uri REST/JSON sau web services SOAP, dar detaliile privind tehnologiile exacte și modul de integrare vor fi stabilite în cadrul procesului de proiectare a arhitecturii de integrare. BNM urmărește armonizarea modelelor de date printr-o abordare standardizată, pentru asigurarea coerenței semantice și structurale între sistemele integrate. Specificațiile privind interfațarea sunt detaliate în cerințele 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. Integrarea efectivă a aplicațiilor critice, considerate parte a fluxurilor operaționale vizate de noul sistem, este obligatoriu a fi inclusă în cadrul perimetrului prezentului proiect.

Versiunile minime suportate pentru sistemul de operare (OS) și sistemul de gestiune a bazelor de date (DB) vor fi stabilite în etapa de analiză și design, ținând cont de compatibilitatea cu infrastructura tehnică existentă și de cerințele soluției ofertate. Cu toate acestea, este de așteptat ca soluția propusă să fie compatibilă cu ultimele versiuni majore stabile ale sistemelor de operare enterprise (ex: Red Hat Enterprise Linux, Windows Server) și ale sistemelor de baze de date uzuale (ex: Oracle, PostgreSQL, Microsoft SQL Server), astfel încât să se asigure suportul pe termen lung, securitatea și stabilitatea necesare unui sistem critic. În ceea ce privește tehnologiile de gestionare a mediilor, nu se impune utilizarea unei soluții specifice (ex: Ansible, Kubernetes etc.), însă este preferabil ca soluția propusă să permită automatizarea și orchestrarea eficientă a instalărilor, configurărilor și actualizărilor, asigurând o administrare coerentă, sigură și scalabilă a tuturor mediilor (producție, testare, dezvoltare și instruire). Orice propunere tehnologică în acest sens va fi evaluată în funcție de eficiența, flexibilitatea și compatibilitatea sa cu platformele deja existente în cadrul BNM.

Da, cheltuielile de logistică aferent instruirilor fizice se vor include ca linie în oferta financiara „Detalierea ofertei financiare pentru serviciile de implementare” conform Anexei nr.3. BNM va pune la dispoziție propriile facilitați pentru tipărirea materialelor.

Același Plan de conturi va fi utilizat pentru toate operațiunile contabile, respectiv registre. Numărul de registre contabile va fi determinat la etapa de analiză și design.

Obiectul licitației cuprinde atât licențele principale, cât și licențele complementare aferente soluțiilor informatice solicitate, conform pct. 1.6 din modelul de contract, care prevede următoarele: „Obiectul Contractului îl reprezintă livrarea de către Furnizor/Prestator în favoarea Cumpărătorului/Beneficiarului a soluției informatice de operaţiuni bancare și/sau a soluției informatice de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție), conform prevederilor menționate în Anexele nr.1, 2, 6 și 7 la prezentul Contract, precum și prestarea serviciilor de garanție (mentenanță și suport) pe o perioadă de 12 luni din data semnării actului de acceptanță finală a soluției, în condițiile Anexei nr. 5 a prezentului Contract.” Licențele complementare sunt prevăzute explicit în Specificația tehnică și Specificația de Preț, cu mențiunea că: „Cantitatea va fi determinată în procesul de ofertare, în baza datelor furnizate în Anexa nr. 9 a Caietului de sarcini.” Prin urmare, toate componentele menționate, inclusiv licențele complementare, fac parte integrantă din obiectul contractului și trebuie reflectate corespunzător în oferta financiară. Totodată, reamintim că acest proiect este unul cu preț fix și toleranță zero la modificarea bugetului, astfel cum este specificat în documentația de atribuire. Ca urmare, solicitările de majorare ulterioară a valorii contractului prin acorduri adiționale pentru elemente care pot fi previzionate sau estimate în etapa de ofertare nu vor fi admise.

Cerința privind garantarea disponibilității codurilor sursă (CNF.196) este satisfăcută prin încheierea unui acord de protecție de tip escrow, încheiat între Furnizor și un agent escrow recunoscut, selectat și agreat împreună cu BNM. Acest mecanism nu presupune cesiunea drepturilor de proprietate intelectuală, ci are rolul de a asigura accesul la codul sursă exclusiv în cazurile în care Furnizorul nu mai poate asigura mentenanța soluției (de ex. faliment, lichidare, reorganizare, refuz expres de prestare a serviciilor de suport). Acordul de tip escrow se activează la solicitarea BNM, solicitare care poate fi emisă în orice moment după acceptanța finală a soluției și pe parcursul perioadelor ulterioare de garanție, mentenanță și suport, iar transmiterea codurilor sursă se va realiza în termen de cel mult 30 de zile lucrătoare, dacă Părțile nu convin altfel.

Cerința privind cesiunea codurilor sursă se aplică aplicațiilor ce fac parte din soluția propusă, inclusiv celor oferite în regim de licențiere neexclusivă, în măsura în care acestea sunt dezvoltate de ofertant și nu implică soluții complementare/third-party aflate în afara controlului direct al acestuia. Pentru componentele dezvoltate sau personalizate în cadrul proiectului, toate codurile sursă vor fi puse la dispoziția BNM, fără a fi necesar un acord escrow separat. În cazul aplicațiilor licențiate neexclusiv, dar care sunt parte integrantă a soluției ofertate, acestea pot face obiectul unui acord de tip escrow la solicitarea BNM, pentru a garanta continuitatea operațională. Aplicațiile terțe (complementare), aflate sub alte regimuri de licențiere, nu intră sub incidența cerinței privind cesiunea codurilor sursă.

Obligația de transmitere a codurilor sursă în cadrul unui acord de tip escrow nu este limitată la o singură livrare. Aceasta include și actualizările ulterioare ale codului sursă, în măsura în care astfel de actualizări sunt aplicate componentelor soluției aflate în exploatare în mediul de producție. Actualizările trebuie reflectate corespunzător în depozitul escrow, pentru a asigura că versiunea de cod sursă stocată corespunde cu cea efectiv utilizată de BNM. Termenul de 30 de zile lucrătoare se referă exclusiv la obligația de a încheia un acord escrow la solicitarea BNM, solicitare care poate fi emisă în orice moment după acceptanța finală a soluției și pe parcursul perioadelor ulterioare de garanție, mentenanță și suport. Condițiile privind actualizarea codului sursă vor fi stabilite ulterior, de comun acord, în cadrul acordului escrow.

Cerința privind acordul de tip escrow se aplică, la solicitarea BNM, tuturor componentelor aplicațiilor livrate sub licență neexclusivă, în măsura în care acestea fac parte integrantă din soluția ofertată (excluzând licențele complementare). Pentru componentele dezvoltate în cadrul proiectului, inclusiv orice personalizări sau extensii realizate asupra soluțiilor existente, toate codurile sursă aferente vor fi transmise BNM în mod direct.

Da, este permisă includerea unor sub etape, cum ar fi faze pilot, acestea putând fi tratate ca activități în cadrul etapelor de proiect, cu respectarea obiectivelor și livrabilelor finale prevăzute în planul general de implementare. Planul de proiect va fi întocmit de către ofertant la discreția acestuia, reieșind din experiența și bunele practici privind implementare unor asemenea soluții IT, considerând cerințele față de managementul proiectului, în special CMP.17 și coordonarea cu Beneficiarul (BNM).

În regimul activ/pasiv (DR) nu este necesară activarea simultană a licențelor în ambele locații. Pe mediul de rezervă se planifică operarea doar în cadrul testărilor anuale de continuitate. Pentru centrul DR este așteptat failover manual.

Există matrice de aprobare predefinite, dar este de menționat că matricele de aprobare sunt definite pe roluri, nu pe persoane. Cerința CNF 260 se refera la delegarea rolurilor acordate unor anumitor persoane în vederea înlocuirii/exercitării unor anumitor drepturi. În acest sens, aplicația va permite delegarea rolurilor.

„Templaturi” se referă la documente care au un caracter reglementat de cadrul legal și pentru care există anumite cerințe specifice. Pentru aceste situații, template-urile necesare vor fi furnizate și vor putea fi definite la etapa de analiză și design.

Da, curent, interfațarea se va efectua cu un singur Document Management System (adică sistemul SGED, menționat la cerința CI32). Totodată, rugăm a se considera cerința CI 32: „Ținând cont de limitările sistemelor actuale ce urmează a fi înlocuite (ca perimetru al acestei achiziții), este important de menționat că soluțiile de automatizare ce au fost implementate pentru părți din fluxurile de lucru pe procese/subprocese (process related workflows), se regăsesc în afara acestor sisteme, fiind implementate în cea mai mare parte în cadrul Sistemului de gestiune electronică a documentelor (SGED). Având în vedere acest fapt, la etapa respectivă Ofertantul selectat va efectua revizuirea/analiza fluxurilor actuale de date inclusiv pe cele efectuate prin intermediul SGED, în vederea creării unei imagini end-to-end asupra procesului ce urmează a fi automatizat și preluării de către soluția ofertată a acelor părți de procese, astfel încât să se asigure automatizarea maximă a procesului și a evita orice dispersare nejustificată a proceselor susținute de sistemul ofertat”.

Volumul de date estimat după 3 ani nu este considerat semnificativ din perspectiva performanței sau a dimensionării bazei de date. Numărul de tranzacții zilnice este relativ redus, situându-se în general la nivelul a câtorva zeci de tranzacții pe zi. Prin urmare, dimensiunea bazei de date este estimată a fi foarte modestă, iar creșterea acesteia în următorii ani nu este de natură să genereze constrângeri de performanță, stocare sau scalabilitate pentru soluția propusă. Totuși, o estimare mai precisă privind volumul de documente, tranzacții și dimensiunea bazei de date va fi elaborată în cadrul etapei de analiză și design, în funcție de structura finală a soluției și a proceselor automatizate.

Se așteaptă ca sistemul să dispună de funcționalități de auditare cât mai detaliate, în conformitate cu cerințele din Caietul de sarcini – 1.9.5. Audit și monitorizare a securității.

Soluția trebuie să se integreze cu un singur furnizor PKI la nivel național, cu serviciul național de semnătură electronică calificată (Msign – msign.gov.md).

Considerând cerința CP 22, soluția trebuie să dispună de funcționalități de tip „dreptul de a fi uitat/anonimizare”.

În conformitate cu CNF.79 „Aplicația va avea interfețe standard pentru exportul de date în cadrul instrumentelor Data Warehouse.”, care este aplicabilă atât pentru lotul I cât și pentru lotul II.

Informațiile cu privire la interfațarea cu alte sisteme este descrisă în anexa nr. 10 „Perspectiva de interoperabilitate”. CBS nu va prelua funcționalitățile operaționale aferente sistemelor descrise în anexa 10, fiind necesară interfațarea cu acestea, cu excepția SGED (Sistemului de gestiune electronica a documentelor), pentru care rugăm a se considera cerința CI 32: „Ținând cont de limitările sistemelor actuale ce urmează a fi înlocuite (ca perimetru al acestei achiziții), este important de menționat că soluțiile de automatizare ce au fost implementate pentru părți din fluxurile de lucru pe procese/subprocese (process related workflows), se regăsesc în afara acestor sisteme, fiind implementate în cea mai mare parte în cadrul Sistemului de gestiune electronică a documentelor (SGED). Având în vedere acest fapt, la etapa respectivă Ofertantul selectat va efectua revizuirea/analiza fluxurilor actuale de date inclusiv pe cele efectuate prin intermediul SGED, în vederea creării unei imagini end-to-end asupra procesului ce urmează a fi automatizat și preluării de către soluția ofertată a acelor părți de procese, astfel încât să se asigure automatizarea maximă a procesului și a evita orice dispersare nejustificată a proceselor susținute de sistemul ofertat”.

În conformitate cu pct.10 din Anunțul de participare, ofertantul poate depune oferta pentru mai multe loturi (pentru un singur lot sau pentru ambele loturi), respectiv se ia în considerare cazul în care se implementează un singur sistem. Curent, nu există elementele operaționale diferite pentru cele două sisteme. O analiză mai detaliată cu privire la acest aspect va fi realizată pe parcursul etapei de analiză și design. Nu există constrângerea ca sistemul să funcționeze în 2 instanțe diferite pentru a conferi independență operațională / contabilă / funcționare în regim DR la centrul de rezerva. Conform cerințelor CDM.6.g și CDM.7.c–d, responsabilitatea ofertantului constă în furnizarea metodologiei, instrumentelor, regulilor de calitate, suportului tehnic și consultanței necesare pentru curățarea și completarea datelor, în cadrul procesului de migrare. Activitățile efective de modificare a datelor în datele sursă rămân responsabilitatea echipei BNM, însă validarea calității datelor și asigurarea integrității în vederea importului în noua soluție se vor face în colaborare strânsă cu ofertantul, în medii controlate de BNM. Astfel, participarea Ofertantului la activitățile de curățare și îmbogățire a datelor vizează în principal sprijinul metodologic și tehnic privind definirea regulilor de calitate, identificarea inconsistențelor și structurarea datelor pentru migrare, în contextul extragerii în formate specifice soluției propuse. Ofertantul nu este responsabil de efectuarea operațională a curățării datelor direct în datele sursă ale BNM, ci va furniza suport sub forma serviciilor de consultanță, validare, instrumente și mecanisme automate (acolo unde este posibil) pentru a asigura integritatea, completitudinea și consistența datelor migrate. Executarea efectivă a corecțiilor în datele sursă rămâne responsabilitatea echipei BNM.