Achiziție - 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)

1. Ce diferențiază un "document template" de un "formular"?

... afișează tot conținutul

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

... afișează tot conținutul

1. Există considerații de performanță pentru documente cu un număr foarte mare de înregistrări?

... afișează tot conținutul

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.

... afișează tot conținutul

1. Cum se va defini și configura această ordine de închidere?
2. Va fi o regulă globală sau specifică per tip de tranzacție/modul?

... afișează tot conținutul

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

... afișează tot conținutul

1. Pentru "scanare cod de bare/cod QR", ce informații se așteaptă a fi extrase și cum vor fi mapate pe câmpurile documentului?
2. Pentru "selectare/link la alte documente, module", cum va funcționa această legătură și ce date vor fi preluate/afișate?

... afișează tot conținutul

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.

... afișează tot conținutul

1. Există o limită de dimensiune sau tipuri de fișiere acceptate pentru atașamente?
2. Cum vor fi stocate și accesate aceste atașamente?

... afișează tot conținutul

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

... afișează tot conținutul

1. Câte tipuri diferite de comisioane/penalități trebuie gestionate?

... afișează tot conținutul

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.

... afișează tot conținutul

1. Ce se înțelege prin "limite de sold inițial" în contextul reversării?

... afișează tot conținutul

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

... afișează tot conținutul

1. Ce inseamna setarea limitelor la nivel de executor?

... afișează tot conținutul

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

... afișează tot conținutul

1. Ce tipuri de metadate specifice trebuie integrate și utilizate în căutări?

... afișează tot conținutul

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.

... afișează tot conținutul

1. Care sunt cele mai frecvente modificari in zona de parametri?

... afișează tot conținutul

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.

... afișează tot conținutul

1. Pentru API, ce protocoale/formate de date sunt preferate (ex: REST/JSON, SOAP/XML)?
2. Ce mecanisme de autentificare și autorizare se vor utiliza pentru API?

... afișează tot conținutul

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

... afișează tot conținutul

Care sunt "soluțiile informatice externe" principale de la care se vor încărca date/documente? Ce metode de integrare sunt preferate (ex: API-uri, transfer de fișiere, baze de date partajate)? Cât de frecventă va fi această încărcare de date?

... afișează tot conținutul

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.

... afișează tot conținutul

Puteți lista principalele sisteme/servicii interne ale băncii și sursele/sistemele externe cu care este necesară interconectarea? Ce tip de date vor fi schimbate și în ce direcție (inbound/outbound)? Ce protocoale/tehnologii de interconectare sunt preferate sau impuse de sistemele existente?

... afișează tot conținutul

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.

... afișează tot conținutul

Care sunt exact cazurile/tipurile de documente care vor necesita semnătură electronică avansată calificată? Integrarea cu infrastructura PKI națională implică utilizarea unor servicii/API-uri specifice? Aveți documentație tehnică pentru această integrare? Cum se va gestiona fluxul de semnare în cadrul aplicației?

... afișează tot conținutul

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.

... afișează tot conținutul

Cum se realizează coordonarea dacă ofertantul ERP nu este același cu cel Core-banking?
Ce responsabilități exacte are coordonatorul în asigurarea interoperabilității?

... afișează tot conținutul

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.

... afișează tot conținutul

Care este structura datelor în Va-Bank ce trebuie preluată (formate, volume)?
Ce interfețe oferă Va-Bank pentru extragere?

... afișează tot conținutul

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.

... afișează tot conținutul

Care este durata exactă a perioadei de „exploatare experimentală”?
Ce tipuri de activități sunt incluse în suport (bug fix, configurare, asistență utilizatori)?

... afișează tot conținutul

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.

... afișează tot conținutul

Există cerințe funcționale deja definite pentru Cartea Mare?
Trebuie integrată cu sisteme existente sau complet nouă?

... afișează tot conținutul

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.

... afișează tot conținutul

Există un model de referință pentru procesele BNM care să fie folosit ca punct de plecare pentru "procese preconfigurate"?
Ce nivel de fidelitate se așteaptă de la mediul de demonstrație? Este obligatoriu să fie funcțional sau poate fi și simulare?
În ce format trebuie livrată demonstrarea capabilităților (capturi video, sesiuni live, documentare)?
Există un sablon pentru specificațiile de design care trebuie livrate?
Cele 75 de rapoarte customizate – se va oferi o listă cu cerințe sau trebuie propuse de ofertant?
Care sunt celelalte solutii informatice utilizate de BNM in acest moment? Ne puteti furniza o lista si o scurta descriere a acestora? Se doreste si integrarea efectiva cu acestea in scopul prezentului proiect sau doar analiza acestora?

... afișează tot conținutul

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.

... afișează tot conținutul

Cum se face validarea parametrilor de configurare (tabel, demo)?

Interfețele pentru integrare cu alte aplicații – sunt sincrone sau asincrone?

Există un model de date agreat de BNM pentru armonizarea surselor?

Puteti furniza lista si o scurta descrierea a celorlalte aplicatii utilizate de BNM cu care se doreste integrarea? Integrarea propriu-zisa se doreste sa fie inclusa in scopul acestui proiect sau va fi dezvoltata ulterior, intr-un alt proiect, pe baza specificatiilor?

... afișează tot conținutul

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.

... afișează tot conținutul