RO
NORME TEHNICE din 19 ianuarie 2011
Table of Provisions (20)
Statutory Text (20 Articles)
Prezentele norme stabilesc cadrul tehnic corespunzător implementării şi operării Sistemului naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar.
la normele tehnice
1.1. Standardul de interfaţare şi interconectare pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare
version="1.0" ?
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php"
xmlns: soap="http://schemas.xmlsoap. org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns: soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns: wsdl="http://schemas.xmlsoap.org/wsdl/"
name="InformatiiPlataZF" targetNamespace="Aici va apărea namespace-ul aplicaţiei dezvoltate de instituţia care furnizează web service-ul, de ex.
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php">
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php">
Metoda care returnează sumele de plată cu detaliile acestora pentru un CUI dat
Metoda care primeşte sumele şi tipurile pentru care s-a făcut plata pe un CUI
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php
#getSumeDePlataPePersoana"/>
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php#inregistrareIncasari"/>
https://www.domeniu_institutie_publica.ro/ghiseu_institutie_publica/ghiseu/server.php"/>
1.2. Descrierea standardului de interfaţare şi interconectare pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare
Servicii web client
Reguli generale
Datele string se vor trimite codate în format UTF8.
Checksumul (suma de control) din fiecare mesaj se va compune pe valorile codate UTF8.
Requesturile SOAP trebuie să fie valide din punct de vedere XML.
Web-service - debite/sume cu detalii
Cerere
Denumire: getSumeDePlataPePersoana
Descriere: Cererea este trimisă de ghiseul.ro către web-service-ul instituţiei, care va răspunde cu date despre persoana corespunzătoare CUI-ului trimis.
Parametri
Explicaţiile parametrilor
CUI - CNP/NIF sau CIF/CUI (pentru persoane fizice autorizate)
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083837), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 38)
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- se aplică algoritmul pe valoarea CUI-ului.
Răspuns
Denumire: getSumeDePlataPePersoanaResponse
Descriere: Este răspunsul web-service-ului server al instituţiei la cererea adresată de web-service-ul client de pe ghiseul.ro. Răspunsul conţine o listă cu sume de plătit de către persoana al cărei CUI este trimis prin mesajul getSumeDePlataPePersoana. Sumele sunt grupate pe tipuri de sume; tipurile de sume pot fi prioritizate.
Parametri
Explicaţiile parametrilor
sume - un array cu sumele de plătit grupate pe tipuri de sume
idTipSuma - codul tipului de sumă
valoare - suma datorată pentru tipul de sumă idTipSuma de forma întreg.douăzecimale (ex.: 57.32)
prioritate - prioritatea în care trebuie să se plătească suma; tipurile de sumă pot să fie prioritizate sau nu; fiecare tip de sumă care se doreşte a fi prioritizată va avea un număr de prioritizare unic obligatoriu pozitiv;
prioritate = 1 este cel mai prioritar tip de sumă, apoi cel cu prioritate = 2 etc.;
restul tipurilor de sumă care nu se doresc a fi prioritizate vor avea prioritate = 0 şi vor putea să fie plătite numai după ce sunt plătite sumele pe tipurile de sumă cu prioritate.
detaliiHeader - un array de stringuri (ex.: Proprietate Debit Rămăşiţă Majorări Penalităţi)
detaliiBody - un array de obiecte LinieDetaliiSume; conţine detaliile de plată corespunzător tipului de sumă idTipSuma
LinieDetaliiSume - un array de stringuri (ex.: denumire, suma debit, suma rămăşiţă, suma majorare, suma penalitate); acestea vor apărea utilizatorilor în format tabelar.
dataCalcul - data la care s-a calculat valoarea obligaţiilor de plată, în format aaaallzz, unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15)
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083837), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 38)
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor: idTipSuma, valoare, apoi pe rând valorile din detaliiHeader luate în ordinea din array, apoi valorile din detaliiBody.
OBSERVAŢIE: detaliiHeader şi detaliiBody trebuie să conţină acelaşi număr de câmpuri.
Web-service - înregistrare plăţi acceptate
Cerere
Denumire: inregistrareIncasari
Descriere: Web-service-ul client de pe ghiseul.ro trimite un mesaj spre web-service-ul server de la instituţie cu detalii despre încasarea acceptată de procesatorul de plăţi electronice. Mesajul conţine numărul plăţii, data plăţii şi sumele totale pe tipuri de sume plătite de persoana respectivă.
Parametri
Explicaţiile parametrilor
order - numărul încasării
cui - CNP/NIF sau CIF/CUI (pentru persoane fizice autorizate)
data - data plăţii de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-09-15 08:38:12)
sume - array de obiecte SumaIncasata; listă cu sumele plătite pe tipuri de sume
SumaIncasata conţine câmpurile
idTipSuma - codul tipului de sumă
valoare - totalul plătit pe tipul de sumă idTipSuma de forma întreg.douăzecimale (ex.: 1234.50)
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este
luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor: order, cui, data, apoi pe rând valorile din arrayul cu sume.
Răspuns
Denumire: inregistrareIncasariResponse
Descriere: Web-service-ul server al instituţiei răspunde web-service-ului client de la ghiseul.ro. Va răspunde cu 1 dacă a reuşit să facă descărcarea plăţii în sistemul local al instituţiei. Altfel va răspunde cu 0.
Parametri
Explicaţiile parametrilor
inregistrareIncasariResult - este 1 dacă s-a înregistrat încasarea cu succes, 0 dacă înregistrarea nu s-a putut efectua.
Tratarea erorilor (Soap Fault) pentru ambele servicii
Se va trimite Soap Fault cu 1, 2 sau 3 în următoarele cazuri specifice
1 - în cazul în care nu s-a verificat integritatea mesajului;
2 - în cazul în care CUI-ul nu este valid sau nu există în baza de date;
3 - s-a produs o eroare şi serviciul este indisponibil.
EXEMPLU DE SOAP FAULT
Response de la: version="1.0" encoding="UTF-8"?
1
Mesaj invalid
(1) În sensul prezentului ordin, abrevierile utilizate au următoarele semnificaţii
a) HTTPS - protocol de comunicare securizată prin internet;
b) SNEP - Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar.
(2) În sensul prezentului ordin, următorii termeni se definesc după cum urmează
a) utilizator - instituţie publică beneficiară, instituţie publică prestatoare, persoană fizică sau persoană fizică autorizată care are obligaţii de plată, instituţie de credit şi instituţie de credit acceptatoare, având CNP/NIF sau CIF/CUI valid;
b) pagină web - document electronic, accesibil prin internet;
c) navigator internet - program pentru calculator care permite vizualizarea paginilor web;
d) operator SNEP - Centrul Naţional de Management pentru Societatea Informaţională (CNMSI);
e) contribuabil - persoană fizică sau persoană fizică autorizată care efectuează plata online a taxelor şi impozitelor utilizând cardul bancar prin intermediul SNEP;
f) instituţii publice beneficiare - instituţii publice care desfăşoară activităţi de încasare online a taxelor şi impozitelor utilizând cardul bancar prin intermediul SNEP.
la normele tehnice
2.1. Standardul de interfaţare şi interconectare pentru actualizarea în SNEP a informaţiilor privind contribuabilii, precum şi a registrului tipurilor de taxe pentru instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare
version="1.0" ?
xmlns:tns="https://www.ghiseul.ro/ghiseul_admin/public/transfer/transfer"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
name="Transfer"
targetNamespace="https://www.ghiseul.ro/ghiseul_admin/public/transfer/transfer">
Returneaza o valoare
Returneaza 0 dacă operatia de scriere a datelor s-a efectuat cu succes
Returneaza 0 dacă operatia de scriere a datelor s-a efectuat cu succes
Returneaza 0 dacă operatia de scriere a datelor s-a efectuat cu succes
Returneaza cea mai recenta data a unei persoane pentru institutia data sau '0' dacă nu exista o ultima data
Returneaza 0 dacă operatia de actualizare a datelor s-a efectuat cu succes
Returneaza cea mai recenta data a unei persoane fizice autorizate pentru institutia data sau '0' dacă nu exista o ultima data
Returneaza 0 dacă operatia de actualizare a datelor s-a efectuat cu succes
Returneaza cea mai recenta data tipuri_sume pentru institutia data sau '0' dacă nu exista o ultima data
Returneaza 0 dacă operatia de actualizare a datelor s-a efectuat cu succes
Returneaza ultimul cod din tabela de stergeri pentru institutia data sau '0' dacă nu exista ultimul cod
Returneaza 0 dacă operatia de stergere a datelor s-a efectuat cu succes
2.2. Descrierea standardului de interfaţare şi interconectare pentru actualizarea în SNEP a informaţiilor privind contribuabilii, precum şi a registrului tipurilor de taxe pentru instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare
Servicii web-server actualizare regiştri
Reguli generale
Datele string se vor trimite codate în format UTF8.
Checksumul (suma de control) din fiecare mesaj se va compune pe valorile codate UTF8.
Requesturile SOAP trebuie să fie valide din punct de vedere XML.
Web service - transfer persoane
Cerere
Denumire: transferPersoane
Descriere: Cererea cu datele persoanelor care se transferă este trimisă de web-service-ul client al instituţiei către webservice-ul server de la ghiseul.ro. Se vor transfera toate persoanele care sunt în evidenţa instituţiei, nedecedate şi care au CNP/NIF sau CIF/CUI (pentru persoane fizice autorizate) valid. Transmiterea datelor se va face pe pachete. Într-un pachet se pot trimite maximum 1.000 de persoane.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de la ghiseul.ro
userClient - numele userului care a înrolat instituţia la ghiseul.ro
date - un array de obiecte PersoanaTransfer; listă cu datele persoanelor
PersoanaTransfer conţine câmpurile
CUI - CNP/NIF sau CIF/CUI (pentru persoane fizice autorizate)
nume - numele şi prenumele
adresa - adresa persoanei
cod - identificatorul unic al persoanei în baza de date a instituţiei
data - data creării sau data ultimei modificări (dacă a fost modificată) a persoanei în baza de date a instituţiei; de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
utilizator - numele utilizatorului care face transferul, de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheia de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, CUI, nume, adresa, data.
Răspuns
Denumire: transferPersoaneResponse
Descriere: Web-service-ul server de la ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit transferul persoanelor.
Parametri
Explicaţiile parametrilor
transferPersoaneResult
0 - transfer reuşit
Soap Fault - la transfer nereuşit (vezi "Tratarea erorilor")
Web service - transfer persoane fizice autorizate
Cerere
Denumire: transferFirme
Descriere: Cererea cu datele de transfer este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro . Transmiterea datelor se va face pe pachete. Într-un pachet se pot trimite maximum 1.000 de persoane. Se vor transfera toate persoanele care sunt în evidenţa instituţiei şi care au CIF/CUI (pentru persoane fizice autorizate) valid.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
date - un array de obiecte FirmaTransfer; listă cu datele firmelor
FirmaTransfer conţine câmpurile
CUI - CIF/CUI (pentru persoane fizice autorizate)
nume - denumirea persoanei
adresa - adresa persoanei
cod - identificatorul unic al persoanei în baza de date a instituţiei
data - data creării sau data ultimei modificări a persoanei în baza de date a instituţiei, de forma
aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
utilizator - numele utilizatorului care face transferul, de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, CUI, nume, adresa, data.
Răspuns
Denumire: transferFirmeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit transferul persoanelor.
Parametri
Explicaţiile parametrilor
transferFirmeResult
0 - transfer reuşit
Soap Fault - la transfer nereuşit (vezi "Tratarea erorilor")
Web-service - transfer tipuri de sume (tipuri de taxe)
Cerere
Denumire: transferTipuriSume
Descriere: Cererea cu datele de transfer este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se vor transfera toate tipurile de sume care sunt în evidenţa instituţiei ce au codul IBAN valid. Transmiterea datelor se va face pe pachete. Într-un pachet se pot trimite maximum 1.000 de tipuri de sume.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
date - un array de obiecte TipVenitTransfer; listă cu tipurile de sume
TipVenitTransfer conţine câmpurile
cod - identificatorul unic al tipului de sumă din baza de date a instituţiei
idNomUnic - identificatorul unic al tipului de taxă din Nomenclatorul unic de tipuri de taxe
nume - denumirea tipului de sumă
iban - codul IBAN corespunzător tipului de venit (în combinaţie cu câmpul platitor) debit = 1 tipul de sumă cu debit reprezintă tipurile de venit pentru care există solduri în baza de date a instituţiei; vor fi afişate în secţiunea Plăţi cu autentificare (se va afişa suma totală de plată adusă prin web-service de la instituţie) şi în secţiunea Plăţi fără autentificare
= 0 tipul de venit fără debit - la aceste tipuri de sume utilizatorul poate să completeze suma pe care doreşte să o plătească; se vor transfera doar cele care se doreşte să apară în interfaţa utilizatorului; vor fi afişate numai în secţiunea Plăţi fără autentificare
= 2 tipul de venit amenda - vor apărea în secţiunea Plăţi fără autentificare; în această secţiune se vor putea plăti amenzile în maximum 48 de ore; utilizatorul trebuie să completeze numărul, seria procesului-verbal şi suma pe care o are de plătit
valInitiala - va fi completată pentru tipurile de sume cu debit = 0; va apărea în secţiunea Plăţi fără autentificare ca suma propusă de plată, cu posibilitate de modificare
inactiv = 1 nu mai e folosit de instituţie; = 0 folosit
data - data creării sau data ultimei modificări a tipului de sumă în baza de date a instituţiei, de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
platitor = 0 persoană fizică şi juridică, = 1 persoană fizică, = 2 persoană juridică (în combinaţie cu iban)
utilizator - numele utilizatorului care face transferul, de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, idNomUnic, nume, iban, debit, valInitiala, inactiv, platitor, data
Răspuns
Denumire: transferTipuriSumeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit transferul tipurilor de sume.
Parametri
Explicaţiile parametrilor
transferTipuriSumeResult
0 - transfer reuşit
Soap Fault - la transfer nereuşit (vezi "Tratarea erorilor")
Web-service - getUltimaDataPersoane
Cerere
Denumire: getUltimaDataPersoane
Descriere: Cererea este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se cere cea mai mare dată de creare sau dată de modificare din persoane de pe ghiseul.ro.
Cererea este utilă pentru web-service-ul actualizare persoane care va trimite toate persoanele modificate după această dată.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
Răspuns
Denumire: getUltimaDataPersoaneResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Serverul va răspunde cu 0 sau un string în format de dată.
În funcţie de răspunsul dat prin getUltimaDataPersoaneResponse se vor alege înregistrările care trebuie trimise la actualizare persoane.
Parametri
Explicaţiile parametrilor
getUltimaDataPersoaneResult
- 0 dacă nu există înregistrări cu Data modificare diferită de null (la updatePersoane se vor trimite toate înregistrările ca la transferPersoane)
- un string în formatul aaaa-ll-zz oo:mm:ss (numit "ultimaDataModificarePersoane"), reprezentând cea mai recentă Data modificare din persoane; (la updatePersoane se vor trimite înregistrările cu Data modificare locală >= ultimaDataModificarePersoane primită ca răspuns la acest serviciu)
Web-service - actualizare persoane
Cerere
Denumire: actualizarePersoane
Descriere: Cererea cu datele de actualizare este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Vor trimite toate persoanele modificate după data returnată de getUltimaDataTipuriSumeResponse
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia la ghiseul.ro
date - un array de obiecte PersoanaTransfer; listă cu datele persoanelor
PersoanaTransfer conţine câmpurile
CUI - CNP/NIF al persoanei fizice
nume - numele şi prenumele
adresa - adresa persoanei
cod - identificatorul unic al persoanei în baza de date a instituţiei
data - data creării sau data ultimei modificări a persoanei în baza de date a instituţiei, de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
utilizator - numele utilizatorului care face transferul, de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), II este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, cui, nume, adresa, data
Răspuns
Denumire: actualizarePersoaneResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit actualizarea persoanelor.
Parametri
Explicaţiile parametrilor
actualizarePersoaneResult
0 - actualizare reuşită
Soap Fault - la actualizare nereuşită (vezi "Tratarea erorilor")
Web-service - getUltimaDataFirme
Cerere
Denumire: getUltimaDataFirme
Descriere: Cererea este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se cere cea mai mare dată creare sau dată modificare de pe ghiseul.ro
Cererea este utilă pentru web-service-ul actualizare persoane fizice autorizate care va trimite toate datele modificate după această dată.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
Răspuns
Denumire: getUltimaDataFirmeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Serverul va răspunde cu 0 sau un string în format de dată.
În funcţie de răspunsul dat prin getUltimaDataFirmeResponse se vor alege înregistrările care trebuie trimise la actualizare.
Parametri
Explicaţiile parametrilor
getUltimaDataFirmeResult
- 0 dacă nu există înregistrări cu data diferită de null (la actualizareFirme se vor trimite toate înregistrările ca la transferFirme)
- un string în formatul aaaa-ll-zz oo:mm:ss (numit "ultimaDataModificareFirme"), reprezentând cea mai recentă dată (la actualizareFirme se vor trimite înregistrările cu Data modificare locală >= ultimaDataModificareFirme primită ca răspuns la acest serviciu)
Web-service - actualizare persoane fizice autorizate
Cerere
Denumire: actualizareFirme
Descriere: Cererea cu datele de actualizare este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Vor trimite toate datele modificate după data returnată de getUltimaDataTipuriSumeResponse
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
date - un array de obiecte FirmaTransfer; listă cu datele persoanelor fizice autorizate
FirmaTransfer conţine câmpurile
cui - CIF/CUI persoanei fizice autorizate
nume - denumirea persoanei fizice autorizate
adresa - adresa persoanei fizice autorizate
cod - identificatorul unic al persoanei fizice autorizate în baza de date a instituţiei
data - data creării sau data ultimei modificări a persoanei fizice autorizate în baza de date a instituţiei, de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
utilizator - numele utilizatorului care face transferul de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control a integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheia de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, cui, nume, adresa, data
Răspuns
Denumire: actualizareFirmeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit actualizarea datelor.
Parametri
Explicaţiile parametrilor
actualizareFirmeResult
0 - actualizare reuşită
Soap Fault - la actualizare nereuşită (vezi Tratarea erorilor)
Web-service - getUltimaDataTipuriSume
Cerere
Denumire: getUltimaDataTipuriSume
Descriere: Cererea este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se cere cea mai mare dată creare sau dată modificare din tipurile de sume de pe ghiseul.ro
Cererea este utilă pentru web-service-ul actualizare tipuri sume care va trimite toate tipurile de sume modificate după această dată.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
Răspuns
Denumire: getUltimaDataTipuriSumeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Serverul va răspunde cu 0 sau un string în format de dată.
În funcţie de răspunsul dat prin getUltimaDataTipuriSumeResponse se vor alege înregistrările care trebuie trimise la actualizare tipuri sume.
Parametri
Explicaţiile parametrilor
getUltimaDataTipuriSumeResult
- 0 dacă nu există înregistrări cu data diferită de null (la actualizareTipuriSume se vor trimite toate înregistrările ca la transferTipuriSume)
- un string în formatul aaaa-ll-zz oo:mm:ss (numit "ultimaDataModificareTipuriSume"), reprezentând cea mai recentă dată din tipuri sume (la actualizareTipuriSume se vor trimite înregistrările cu Data modificare locală >= ultimaDataModificareTipuriSume primită ca răspuns la acest serviciu)
Web-service - actualizare tipuri sume
Cerere
Denumire: actualizareTipuriSume
Descriere: Cererea cu datele de actualizare este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Vor trimite toate tipurile de sume modificate după data returnată de getUltimaDataTipuriSumeResponse
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
date - un array de obiecte TipSumaTransfer; listă cu tipurile de sume
TipSumaTransfer conţine câmpurile
cod - identificatorul unic al tipului de sumă din baza de date a instituţiei
idNomUnic - identificatorul unic al tipului de taxă din Nomenclatorul unic de tipuri de taxe
nume - denumirea tipului de sumă
iban - codul IBAN corespunzător tipului de venit (în combinaţie cu câmpul plătitor)
debit = 1 tipul de sumă cu debit - reprezintă tipurile de venit pentru care există solduri în baza instituţiei; vor fi afişate în secţiunea Plăţi cu autentificare (se va afişa suma totală de plată adusă prin web-service de la instituţie) şi în secţiunea Plăţi fără autentificare
= 0 tipul de venit fără debit - la aceste tipuri de sume utilizatorul poate să completeze suma pe care doreşte să o plătească; se vor transfera doar cele care se doreşte să apară în interfaţa utilizatorului; vor fi afişate numai în secţiunea Plăţi fără autentificare
= 2 tipul de venit Amenda - vor apărea în secţiunea Plăţi fără autentificare; în această secţiune se vor putea plăti amenzile în maximum 48 de ore; utilizatorul trebuie să completeze numărul, seria procesului-verbal şi suma ce o are de plătit
valInitiala - poate fi completată pentru tipurile de sume cu debit = 0;
inactiv = 1 nu mai e folosit de instituţie; = 0 folosit
data - data creării sau data ultimei modificări a tipului de sumă în baza de date a instituţiei; de forma aaaa-ll-zz oo:mm:ss (ex.: 2010-10-22 16:06:12)
platitor = 0 persoană fizică şi juridică, = 1 persoană fizică, = 2 persoană juridică (în combinaţie cu iban)
utilizator - numele utilizatorului care face transferul; de forma idClient.userWindows@numeStatie
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, idNomUnic, nume, iban, debit, valInitiala, inactiv, platitor, data
Răspuns
Denumire: actualizareTipuriSumeResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit actualizarea tipurilor de sume.
Parametri
Explicaţiile parametrilor
actualizareTipuriSumeResult
0 - actualizare reuşită
Soap Fault - la actualizare nereuşită (vezi Tratarea erorilor)
Web-service - getUltimCodStergeri
Cerere
Denumire: getUltimCodStergeri
Descriere: Cererea este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se cere cel mai mare cod al ştergerilor reuşite de instituţia respectivă pe ghiseul.ro
Poate fi util pentru web-service-ul Stergere care va trimite toate codurile de şters mai mari decât acest cod.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
Răspuns
Denumire: getUltimCodStergeriResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Serverul va răspunde cu 0 sau un string cu codul.
În funcţie de răspunsul dat prin getUltimCodStergeriResponse se vor alege înregistrările care trebuie trimise la ştergere transfer.
Parametri
Explicaţiile parametrilor
getUltimCodStergeriResult
- 0 dacă nu există înregistrări pentru instituţia respectivă
- un string reprezentând cel mai recent cod şters de la instituţia respectivă (la ştergere se vor trimite înregistrările cu cod local >= cod primit ca răspuns la acest serviciu)
Web-service - stergere
Cerere
Denumire: stergere
Descriere: Cererea cu datele de şters este trimisă de web-service-ul client al instituţiei către web-service-ul server de pe ghiseul.ro. Se vor trimite un set de date, persoane şi persoane fizice autorizate, care se doresc a fi şterse la ghiseul.ro. Acestea se vor alege în funcţie de răspunsul dat de getUltimCodStergeriResult. Aceasta presupune implementarea la instituţie a unei cozi de aşteptare a operaţiilor de ştergere.
Parametri
Explicaţiile parametrilor
idClient - codul de client primit de pe ghiseul.ro
userClient - numele userului care a înrolat instituţia pe ghiseul.ro
date - un array de obiecte StergereTransfer; listă cu codurile de şters
StergereTransfer conţine câmpurile
cod -identificatorul unic al ştergerii
codObiectSters - identificatorul unic (id) al persoanei sau persoanei fizice autorizate în baza de date a instituţiei
fizjur =1 persoana, = 2 persoana fizică autorizată
timestamp - timestamp în formatul aaaallzzoommss (ex.: 20100915083812), unde aaaa este anul (ex.: 2010), ll este luna (ex.: 09), zz este ziua (ex.: 15), oo este ora (ex.: 08), mm sunt minutele (ex.: 38), ss sunt secundele (ex.: 12)
primulPachet = 1 dacă este primul pachet din transfer, 0 dacă nu e primul pachet
ultimulPachet = 1 dacă este ultimul pachet din transfer, 0 dacă nu e ultimul pachet
check - suma de control al integrităţii mesajului; algoritmul folosit este HMAC-SHA1 cu cheie de criptare;
- algoritmul se aplică pe stringul obţinut prin concatenarea în ordine a valorilor din arrayul date: cod, codObiectSters,fizjur
Răspuns
Denumire: stergereResponse
Descriere: Web-service-ul server de pe ghiseul.ro răspunde web-service-ului client al instituţiei. Va răspunde cu 0 dacă a reuşit ştergerea datelor.
Parametri
Explicaţiile parametrilor
stergereResult
0 - actualizare reuşită
Soap Fault - la actualizare nereuşită (vezi Tratarea erorilor)
Tratarea erorilor Soap Fault
Se va trimite Soap Fault cu 1, 2, 3 sau 4 în următoarele cazuri specifice
1 - în cazul în care nu s-a verificat integritatea mesajului (valoarea check incorectă)
2 - în cazul în care codul instituţiei nu este corect (valoarea idClient incorectă)
3 - în cazul în care utilizatorul instituţiei nu este corect (valoarea userClient incorectă)
4 - s-a produs o eroare şi serviciul este indisponibil
5 - "Introducere TIP SUMA se face manual" - nu se pot face operaţii pe tipuri de sume decât manual (dacă în profil instituţie din modulul Ghişeul administrare este setat "Introducere manuală tipuri de venit")
6 - "Error. Există mai multe persoane cu acelaşi CNP (".$cui.") în pachet" - se parcurge lista de persoane trimise, iar la primul CNP care apare de 2 ori în acelaşi pachet se va răspunde cu acest Soap Fault
6 - "Error. Există mai multe persoane fizice autorizate cu acelaşi CUI (".$cui.") în pachet" - se parcurge lista de persoane fizice autorizate trimise, iar la primul CUI care apare de 2 ori în acelaşi pachet se va răspunde cu acest Soap Fault
7- "Error. CNP-uri invalide": ".$cui1, $cui2,.... " - se parcurge lista de persoane trimise, se concatenează CNP-urile invalide şi răspunde cu acest Soap Fault dacă există cel puţin unul invalid
7 - "Error. CIF-uri invalide": ".$cui1, $cui2,.... " - se parcurge lista de persoane fizice autorizate trimise, se concatenează CF-urile invalide şi răspunde cu acest SoapFault dacă există cel puţin unul invalid
7 - "Error. Tip suma fără IBAN": ".$nume1, $nume2,..." Tip suma cu debit invalid: ".$nume1, $nume2,... " IBAN-uri invalide: ".$iban1, $iban2,... " Tip suma cu IdNomUnic invalid: ".$nume1, $nume2,... " Tip suma cu plătitor invalid: ".$nume1, $nume2,.... " se parcurge lista de tipuriSume trimise şi se concatenează numele celor care nu au niciun IBAN, separat numele celor care nu au debit valid (0, 1 sau 2), separat IBAN-urile invalide, separat numele celor care nu au IdnomUnic valid (completat dar invalid - dacă nu e completat nu se consideră invalid), separat numele celor care nu au plătitor valid (0, 1 sau 2). Dacă cel puţin una dintre categorii are ceva completat atunci se răspunde cu acest Soap Fault. (dacă la una dintre categorii nu există niciun item, atunci nu va apărea deloc categoria respectivă.)
Ex.: "7", "Error. Tip suma fără IBAN: Taxa Auto" IBAN-uri invalide: RO88TREZ02121340202XXXXX, RO88TREZ02121340202XXXXX
8 - "Număr prea mare de entităţi per pachet (maximum 1000)" - dacă numărul de obiecte (persoane, persoane fizice autorizate sau tipuriSume) din array-ul "$data" este mai mare decât 1000, atunci se răspunde cu acest Soap Fault.
"9", "Testare nefinalizată pentru operaţia ".$nume_operaţie."! Vă rugăm să folosiţi modulul de testare!"
(Ex.: "Testare nefinalizată pentru operaţia TRANSFER TIPURI SUME! Vă rugăm să folosiţi modulul de testare!")
"10", "Instituţie fără trimitere date prin web-services"
(Dacă în tabela instituţii, pentru instituţia curentă, câmpul B_CU_SERVICES e pus pe 0 să nu poată transfera nimic. Se returnează un soap fault prin care se anunţă că este pusă bifa pe "Fără trimitere date prin web-services" în profil instituţie.
Verificarea se face la orice apel al unei funcţii.
Decuplarea utilizatorului de la SNEP se face automat la închiderea navigatorului internet.
Operatorul SNEP are obligaţia de a defini şi a implementa, până la darea în producţie a sistemului, proceduri şi mecanisme necesare pentru asigurarea securităţii şi disponibilităţii sistemului, la nivelul tuturor componentelor acestuia, astfel încât SNEP să funcţioneze la parametrii stabiliţi prin pct. 4.1 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95.
Operatorul SNEP are obligaţia de a implementa proceduri în domeniul cybersecurity care să asigure protecţia SNEP, a utilizatorilor şi a datelor acestora. Procedurile vor viza aspecte precum: colectarea şi analiza logurilor, protecţia împotriva tipurilor de atacuri informatice cunoscute, testarea periodică pentru identificarea posibilelor breşe de securitate.
Operatorul SNEP va implementa proceduri şi mecanisme pentru a asigura în implementarea şi operarea SNEP respectarea prevederilor Legii nr. 677/2001 pentru protecţia persoanelor cu privire la prelucrarea datelor cu caracter personal şi libera circulaţie a acestor date, cu modificările şi completările ulterioare.
Administratorii SNEP, angajaţi ai operatorului SNEP, se vor autentifica cu certificat electronic pe staţiile de administrare a SNEP.
Operatorul SNEP va monitoriza funcţionarea componentelor SNEP, inclusiv a liniilor de comunicaţii. În cazul funcţionării necorespunzătoare a componentelor monitorizate ale SNEP, operatorul SNEP va proceda conform procedurilor interne.
Instituţiile publice beneficiare înregistrate vor implementa conectorii corespunzători pentru realizarea comunicaţiei între aplicaţia proprie de gestiune a contribuabililor şi debitelor acestora şi SNEP utilizând protocolul HTTPS, fără a fi însă obligatorie utilizarea unui certificat de server calificat.
Standardul de interfaţare şi interconectare pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare, precum şi descrierea acestuia sunt puse la dispoziţie de Ministerul Comunicaţiilor şi Societăţii Informaţionale cu titlu gratuit, conform anexei nr. 1.
Standardul de interfaţare şi interconectare pentru actualizarea în SNEP a informaţiilor privind contribuabilii, precum şi a registrului tipurilor de taxe pentru instituţiile publice beneficiare care deţin un sistem de gestiune a obligaţiilor bugetare, precum şi descrierea acestuia sunt puse la dispoziţie de Ministerul Comunicaţiilor şi Societăţii Informaţionale cu titlu gratuit, conform anexei nr. 2.
Formatul electronic standardizat al fişierelor transmise operatorului SNEP de către instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare pentru înregistrarea şi actualizarea în SNEP a informaţiilor privind contribuabilii, precum şi descrierea acestuia sunt puse la dispoziţie de Ministerul Comunicaţiilor şi Societăţii Informaţionale cu titlu gratuit, conform anexei nr. 3.
Standardul de interfaţare şi interconectare între SNEP şi aplicaţia informatică dezvoltată de Ministerul Finanţelor Publice - Agenţia Naţională de Administrare Fiscală, conform pct. 3.2.2.2 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95, pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare, precum şi descrierea acestuia sunt puse la dispoziţie de Ministerul Comunicaţiilor şi Societăţii Informaţionale cu titlu gratuit, conform anexei nr. 4.
Formatul electronic standardizat al fişierelor transmise Ministerului Finanţelor Publice - Agenţia Naţională de Administrare Fiscală de către instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare pentru actualizarea informaţiilor privind obligaţiile de plată, precum şi descrierea acestuia sunt puse la dispoziţie de Ministerul Comunicaţiilor şi Societăţii Informaţionale cu titlu gratuit, conform anexei nr. 5.
Numele fişierelor transmise prin SNEP vor respecta următorul format
Idemitent_Iddestinatar_data_numarordine_tipfisier_nrfisier.extensie, cu următoarele clarificări, cu respectarea definiţiilor prevăzute la pct. 1.4 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95
a) pentru fişierele prevăzute la pct. 3.5.3 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95
Idemitent: "SNEP"
Iddestinatar: [BIC al instituţiei de credit acceptatoare]
data: [data calendaristică, în format aaaallzz]
numarordine [generat automat de către SNEP]
tipfisier: "TA", unde TA reprezintă tranzacţii autorizate
nrfisier: [generat automat de către SNEP, ca număr al fişierului]
extensie: [se stabileşte de către operatorul SNEP în funcţie de tipul conţinutului];
b) pentru fişierele prevăzute la pct. 3.5.8 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95
Idemitent: [BIC al instituţiei de credit acceptatoare]
Iddestinatar: "SNEP"
data: [data calendaristică, în format aaaallzz]
numarordine [generat de către instituţia de credit acceptatoare]
tipfisier: "TD", unde TD reprezintă tranzacţii decontate
nrfisier: [generat de către instituţia de credit acceptatoare, ca număr al fişierului]
extensie: [se stabileşte de către operatorul SNEP în funcţie de tipul conţinutului];
c) pentru fişierele prevăzute la pct. 3.6.2 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95
Idemitent: "SNEP"
Iddestinatar: [CIF al instituţiei publice beneficiare]
data: [data calendaristică, în format aaaallzz]
numarordine [generat automat de către SNEP]
tipfisier: "TASP", unde TASP reprezintă tranzacţii autorizate de SNEP către instituţia publică beneficiară
nrfisier: [generat automat de către SNEP, ca număr al fişierului]
extensie: [se stabileşte de către operatorul SNEP în funcţie de tipul conţinutului];
d) pentru fişierele prevăzute la pct. 3.7.3 din Normele metodologice privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar, aprobate prin Ordinul ministrului comunicaţiilor şi societăţii informaţionale, al ministrului administraţiei şi internelor şi al ministrului finanţelor publice nr. 168/14/95
Idemitent: [CIF al instituţiei publice beneficiare]
Iddestinatar: [BIC al instituţiei de credit acceptatoare]
data: [data calendaristică, în format aaaallzz]
numarordine [generat de către instituţia publică beneficiară]
tipfisier: "TR", unde TR reprezintă tranzacţii restituite
nrfisier: [generat automat de către instituţia publică beneficiară, ca număr al fişierului]
extensie: [se stabileşte de către instituţia publică beneficiară].
Fişierele transmise prin SNEP privitoare la tranzacţii vor conţine numai tranzacţii aferente unei singure zile.
Anexele 1-5 fac parte integrantă din prezentele norme tehnice.
privind Sistemul naţional electronic de plată online a taxelor şi impozitelor utilizând cardul bancar
Capitolul I
Dispoziţii generale
Capitolul II
Proceduri de securitate şi asigurarea disponibilităţii
Capitolul III
Standardul de interfaţare şi interconectare