Norme tehnice din 19 ianuarie 2011

Capitolul IDispoziţii generale

Articolul 1

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.

Articolul 2

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

Articolul 3

Decuplarea utilizatorului de la SNEP se face automat la închiderea navigatorului internet.

Capitolul IIProceduri de securitate şi asigurarea disponibilităţii

Articolul 4

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.

Articolul 5

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.

Articolul 6

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.

Articolul 7

Administratorii SNEP, angajaţi ai operatorului SNEP, se vor autentifica cu certificat electronic pe staţiile de administrare a SNEP.

Articolul 8

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.

Capitolul IIIStandardul de interfaţare şi interconectare

Articolul 9

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.

Articolul 10

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.

Articolul 11

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.

Articolul 12

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.

Articolul 13

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.

Articolul 14

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.

Articolul 15

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

Articolul 16

Fişierele transmise prin SNEP privitoare la tranzacţii vor conţine numai tranzacţii aferente unei singure zile.

Articolul 17

Anexele 1-5 fac parte integrantă din prezentele norme tehnice.

Anexa 1

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

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:

1

Mesaj invalid

Anexa 2

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

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.

Anexa 3

la normele tehnice

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

Fişierul "contribuabili.csv"

Este generat cu o aplicaţie de calcul tabelar şi va conţine pe fiecare linie următoarele informaţii cu privire la contribuabili:

CNP/NIF sau CIF/CUI, Nume, "Adresa"

┌────┬───────────────────────────────┬──────────────────────┬──────────────────┐

│Nr. │ CNP/NIF sau CIF/CUI │ Nume │ Adresa │

│crt.│ │ │ │

├────┼───────────────────────────────┼──────────────────────┼──────────────────┤

├────┼───────────────────────────────┼──────────────────────┼──────────────────┤

├────┼───────────────────────────────┼──────────────────────┼──────────────────┤

└────┴───────────────────────────────┴──────────────────────┴──────────────────┘

unde:

–CUI-CNP/NIF pentru persoane fizice sau CIF/CUI pentru persoanele fizice autorizate;

–Nume-numele şi prenumele/denumirea persoanei care are obligaţia de plată;

–Adresa-adresa persoanei care are obligaţia de plată.

Anexa 4

la normele tehnice

4.1.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ă pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare

https://www.domeniu_ANAF.ro/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 Ministerul Finanţelor Publice - Agenţia Naţională de Administrare Fiscală care furnizează web-service-ul, de ex.:

https//www.domeniu_ANAF.ro/server.php">

Metoda care returneaza sumele de plată cu detaliile acestora pentru un cui dat

https://www.domeniu_ANAF.ro/server.php#getSumeDePlataPePersoana" />

4.2 Descrierea standardului de interfaţare şi interconectare între SNEP şi aplicaţia informatică dezvoltată de Ministerul Finanţelor Publice - Agenţia Naţională de Administrare Fiscală pentru comunicarea obligaţiilor de plată constituite de instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare: interfaţare şi interconectare pentru comunicarea obligaţiilor de plată

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:

cuiInstitutie - CUI instituţie

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

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)

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.

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.

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 - în cazul în care s-a produs o eroare şi serviciul este indisponibil.

EXEMPLU DE SOAP FAULT:

Response de la:

1

Mesaj invalid

Anexa 5

la normele tehnice

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ă

Fişierul "AdminCreante.xml"

Este generat cu o aplicaţie pusă la dispoziţia instituţiile publice beneficiare care nu deţin un sistem de gestiune a obligaţiilor bugetare, în mod gratuit, de către Ministerul Finanţelor Publice - Agenţia Naţională de Administrare Fiscală, având următoarea structură:

xmlns="mfp:anaf:dgti:administrare_creante:declaratie:v1"targetNamespace="mfp:anaf:dgti:administrare_creante:declaratie: v1"elementFormDefault="qualified" attributeFormDefault=" unqualified" version="1.02" xml:lang="ro">