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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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