InternalErrorException
Documentat în ghidul de integrare SFS.
Apelul returnează InternalErrorException. Spre deosebire de erorile de autentificare și autorizare, aceasta nu indică o problemă în cererea dumneavoastră: este o eroare apărută în timpul procesării, de partea platformei.
Ce spune ghidul
„A apărut o eroare internă în timpul procesării solicitării."
Nimic mai mult. Fără subcoduri, fără cauze enumerate, fără indicații de remediere.
Ce înseamnă practic
Este singura dintre cele trei erori documentate la care nu aveți ce corecta în propriul sistem. Credențialele sunt bune, cererea a fost acceptată spre procesare, iar ceva a eșuat dincolo de acest punct.
Asta o face eroarea care contează cel mai mult pentru felul în care vă construiți integrarea: dacă un apel poate eșua fără vina apelantului, sistemul dumneavoastră are nevoie de un comportament definit pentru acel caz — nu de o excepție care oprește procesarea unui lot întreg.
Contextul merită știut: platforma este raportată ca fiind lentă sau inaccesibilă în anumite perioade, în special în zilele de 22–24 ale lunii — problemă semnalată SFS de EBA Moldova în iulie 2024. Nu putem afirma că cele două lucruri sunt legate; sursele sunt diferite și niciuna nu o spune.
O precizare despre formulare
Ghidul nu folosește un text unic pentru motivul acestei erori. Am găsit patru variante de formulare în document, în funcție de metodă — de exemplu, la SearchInvoices motivul este scris mai scurt decât la celelalte. Citatul de mai sus este varianta majoritară.
Nu deduceți din asta că există patru erori diferite: codul este același. Este o inconsecvență de redactare a documentului, catalogată în auditul intern al ghidului, §5 (document de lucru, nepublicat).
Cele două canale de eroare
Documentată în tabelele „Erori” ale celor opt metode de citire: CheckInvoicesStatus, GetAcceptedInvoices, GetInvoicesBySeriaNumber, GetInvoicesContentForPrint, GetInvoicesForSigning, GetInvoicesQRcodes, GetTaxpayersInfo, SearchInvoices.
Metodele Post* nu au tabele de erori în ghid: ele raportează eșecul prin Status = 3 („eroare la executare”) și ErrorMessage, iar la anulare și prin statutul fiecărei facturi. Un eșec intern la transmitere va apărea, deci, pe celălalt canal — nu ca excepție.
Ce puteți face
- Reluați apelul mai târziu. Este singura acțiune care are sens la o eroare de partea platformei.
- Nu reluați în buclă strânsă: dacă platforma are o problemă, apelurile repetate nu o rezolvă.
- Păstrați
RequestId-ul cererii. Este identificatorul dumneavoastră, iar dacă întrebați SFS despre un caz anume, este ce vă permite să îl indicați. - Dacă eroarea persistă, verificați la SFS.
Nu recomandăm un interval de reîncercare anume: ghidul nu prevede unul, iar o cifră inventată aici ar arăta ca o recomandare oficială.
Payload observat
Nu deținem încă un răspuns capturat de pe platformă pentru acest caz.
Ajută depus?
Nu astăzi — depus nu există. Nu am făcut niciodată un apel către această platformă.
Aceasta este însă exact situația pe care specificația depus își propune să o absoarbă: o factură primită de la sistemul clientului este pusă într-o coadă și retransmisă când platforma răspunde din nou, în loc ca eșecul să ajungă la utilizator. Este o soluție proiectată, nu construită, și nu vă ajută acum.
Vezi și
- AuthenticationFailedException
- e-Factura nu se deschide sau merge foarte încet
- Cum transmiteți o factură electronică prin API (cross-cluster D4)
depus este în dezvoltare.
Verificat la: 2026-08-17
Acest material are caracter informativ și nu constituie consultanță juridică sau fiscală. Pentru situația concretă a companiei dumneavoastră, adresați-vă unui consultant autorizat sau instituției competente.
Stadiu: în recenzie