e-Factura SFS

• Cui vorbim:* orice afacere moldovenească care emite facturi către clienți juridici sau B2C cu cerere de factură.

Ce facem

Integrare nativă cu SFS Moldova pentru întregul ciclu de viață al unei e-Facturi:

Adaugă produsele
    ↓
DRAFT (factură pregătită local)
    ↓
SIGN (semnată cu certificatul tău digital)
    ↓
POST (trimisă oficial la SFS, primește RID)
    ↓
ACCEPT / REJECT (cumpărătorul decide)
    ↓
ARCHIVE (factură finalizată, în arhivele tale)

Tot acest ciclu se desfășoară în interfața noastră — nu mai intri vreodată în portalul SFS.

Capabilități

Emitere

• B2C — cumpărător individual care cere factură (rar, dar suportat).
• B2B — cumpărător juridic, cu IDNO validat în baza SFS.
• Export — vânzări în afara Moldovei (cota TVA 0%).
• Stornare — anulare totală sau parțială.

Validări automate

• IDNO valid (format + existență în baza SFS).
• Coduri produse vs. nomenclator.
• Cote TVA aplicate corect (8% / 12% / 20% / 0%).
• Numere consecutive (fără goluri în serie).
• Sume calculate matematic corect.

Autentificare la API e-Factura SFS

• User-api specifice modulului e-Factura — credențiale (username + parolă API) generate de operator în portalul e-Factura SFS și configurate în platforma noastră.
• Important: aceste credențiale sunt dedicate doar API-ului e-Factura, NU sunt credențiale SFS generice. Nu se confundă cu user-api SFS pentru alte sisteme (declarații fiscale, MEV, alte module). Pentru fiecare modul SFS la care vrei integrare API, există set distinct de credențiale.
• Acesta este mecanismul standard de autentificare la API-ul e-Factura. NU folosim USB token pentru API e-Factura (USB token este tipic pentru semnătura digitală generală pe acte legale, nu pentru API-ul e-Factura).
• Configurarea credențialelor la noi se face la onboarding (configurabil de admin operator); credențialele se păstrează cu acces strict limitat în platformă.
• Validarea documentelor (format, sume, IDNO) se face conform cerințelor SFS înainte de trimitere.

Trimitere și urmărire

• Post la SFS după semnare.
• Confirmare rapidă (în 1-5 secunde tipic).
• Retry cu exponential backoff la eroare tranzitorie — parametrii (numărul de retry-uri pentru read/write requests + delay între ele) sunt configurabili în API Request Settings din e-Factura webapp (default: retries=2, retry-delay=2000ms).
• Sincronizare status — la re-listare (deschidere Search invoices, click Refresh).

Statusuri urmărite

Statusurile invoice-urilor vin direct de la API-ul SFS (codurile numerice oficiale + label-uri semantice). Nu inventăm statusuri suplimentare local. Vezi Search invoices pentru filtrare pe status.
Categorii de status vizibile în UI: pending (așteaptă acțiune), accepted (confirmat), rejected (refuzat), cancelled (anulat). Statusul brut + label semantic apar în coloane separate în tabelă.

Exemple de utilizare

Vânzare B2B într-un magazin retail

Vezi e-Factura B2B detaliat. Workflow standard:

1. Casierul scanează produsele.
2. Cumpărătorul cere factură → casierul scanează / tastează IDNO.
3. Sistemul completează automat datele firmei.
4. Confirmă → 5 secunde → factură oficială SFS.

Emitere bulk (la final de zi) — ⚙️ la cerere

Scenariul de emitere batch (semnare + post 50/100/500 facturi într-un flux) nu e accesibil în mod implicit la moment. Cache-management-ul aplicației oferă batch-fetch (sincronizare batch a facturilor deja emise pentru cache local), dar nu batch-emit. Implementarea automatizării end-of-day = ⚙️ ofertată individual ca customizare.

Factură generată din comandă online

Comanda venită prin e-commerce → cumpărător marchează "vreau factură" + introduce IDNO → la finalul comenzii (după plată confirmată), sistemul emite automat factura, o trimite pe e-mail cumpărătorului.

Depozitare arhive

• Important arhitectural: Arhiva fiscală oficială este la SFS (sistemul e-Factura) — acolo se păstrează versiunea oficială a fiecărei facturi cu RID-uri unice și retenție 4+ ani conform legii fiscale MD. Platforma noastră procesează și păstrează cache operațional* al acestor facturi pentru utilizare zilnică (rapoarte, dashboard, audit intern, integrare contabil).

Cache-ul nostru include facturile emise (XML semnat + PDF generat pentru lectură umană):

• Stocate pe servere cu acces controlat (RBAC + audit log; comunicare TLS; backup-uri off-site cu acces restricționat).
• Backup-uri opționale activabile la cerere (vezi oferta curentă).
• Disponibile prin API pentru contabilul tău.
• Stocare operațională configurabilă — păstrăm cât are sens operațional (tipic mai scurt decât 4 ani); pentru retenția oficială 4+ ani sursa rămâne SFS, accesibilă oricând prin RID-uri.

Performanță

Volume suportate:

• Toate pachetele: nelimitat, în limita traficului pachetului (rate-limit tehnic intern configurabil per cont pentru a respecta cotele SFS).

Timp emitere per factură: 1-5 secunde tipic.

Cazuri de gestionare avansate

Re-emitere după rejection

SFS sau cumpărătorul refuză factura cu motiv specific → sistemul:

1. Afișează motivul clar (în română).
2. Te conduce la câmpul problematic.
3. Cu un click "Corectează + re-trimite", reia fluxul de la semnare.

Anulare după acceptare (storno e-Factura) — semi-asistat

Conform procedurii SFS:

1. Identifici factura emisă (după număr / dată / cumpărător).
2. Atingi "Storno" → alegi tipul (total / parțial).
3. Sistemul ghidează generarea facturii de storno (sumă negativă, mapare la factura originală).
4. Trimiterea către API e-Factura SFS se face cu credențialele tale user-api e-Factura — flux semi-asistat (sistemul orchestrează, autentificarea folosește credențialele tale).
5. SFS validează → ambele facturi (originală + storno) sunt în arhiva oficială SFS; cache-ul nostru se actualizează corespunzător.

Operator care emite din greșeală

Dacă un casier emite o factură pe IDNO greșit:

1. Detectează imediat (verificare după acceptance).
2. Inițiază storno cu motiv "eroare IDNO" + emite nouă pe IDNO corect.
3. Cumpărătorul primește notificare clară (factura veche anulată, factura nouă în loc).

Audit complet

Fiecare emitere logează:

• Cine a emis (user + rol + POS).
• Când (timestamp la secundă).
• Sumele (înainte / după TVA).
• IDNO cumpărător + datele asociate.
• Statusuri intermediare (sign, post, response SFS).
• Eventuale corecții ulterioare.

Inalterabil — pentru audit / dispută.

Tur vizual — e-Factura webapp

Aplicația e-Factura webapp e interfața directă cu API-ul SFS pentru operator. Fluxul general: pornești, alegi identitatea (contul user-api cu care emiți/citești), apoi ai acces la meniul principal cu toate operațiunile disponibile pentru acel actor.

Notă privacy: în capturile de mai jos IDNO-urile reale + numele companiilor apar blur-uite intenționat (privacy demo). În sistem real, operatorul vede text clar.

Pick-identity — alege identitatea

Când deschizi aplicația, primul pas e să alegi identitatea (contul user-api generat în portalul SFS). Fiecare identitate are propriul rate limit (0 / 5000 calls/h) și lista de IDNO-uri asociate (o identitate poate reprezenta mai multe entități fiscale).

• Header — Switch identity + Menu. După ce alegi o identitate, butonul Switch identity te readuce la lista de identități (necesar dacă operator lucrează pentru mai multe firme dintr-o singură sesiune). Menu* te readuce la meniul principal al aplicației (de la orice sub-view).

• Card identitate.* Fiecare card conține: numele identității ("E-Factura API — companie — user"), ID-ul intern (e-factura-<slug>), serviciul (e-factura), timestamp-uri de creare/expirare, rate-limit curent (calls/h), lista de IDNO-uri asociate.

• Buton "Use IDNO"* — trimite request cu un IDNO tastat manual (util când vrei să emiți pentru un IDNO care nu apare în listă — subject to permission check).

• Buton "Apply"* (API Request Settings) — persistă ajustările la retries + retry delay (retries la read/write requests, delay între retry-uri).

• IDNO chip clickable* — fiecare IDNO listat pe cardul unei identități e clickable direct — te bagă în meniul principal cu acel IDNO ca actor implicit.

Menu principal — 10 module

După selectarea identității, meniul principal expune modulele API disponibile pentru acel actor:

• Test connection — ping SFS, verifică că serverul răspunde.
• Activity logs — istoric API calls pentru identitatea curentă (filtrabil).
• Taxpayer lookup — caută unul sau mai multe IDNO-uri, primești nume, VAT, tip, status registration.
• Bank account lookup — listează conturi bancare înregistrate pentru un IDNO (sau valideaza IBAN).
• Open invoice by series — deschide invoice specific prin Seria + Number, vezi XML/PDF.
• Search invoices — form complet cu filtre pe IDNO, status, date; tabelă sortabilă rezultat.
• Invoices waiting for signature — invoice-uri primite ce necesită acțiune (buyer perspective).
• Accepted invoices — istoric invoice-uri acceptate.
• Rejected invoices — istoric invoice-uri respinse.
• Invoice cache — gestionează cache-ul local XML: view stats, check unsynced, batch-sync.

Search invoices — filtre + tabelă rezultat

Cel mai folosit view după setup — form comprehensive pentru găsirea invoice-urilor:

• Filtre header: Actor Role (Supplier / Buyer / Transporter), API E-Invoice ID, Buyer IDNO, Supplier IDNO, Transporter IDNO, Seria, Number, Invoice Status (dropdown), Invoice Type, Issued On (interval), Delivered On (interval), Registered On (interval).
• Coloane rezultat (configurabile prin Columns Show/Hide): #, IDX, SerianNumber, Status, Status (label), InvoiceStatus, InvoiceStatus (label), Timestamp, Message, Cache, Issued Date, Supplier, etc.
• Butoane utilitare: Columns Show/Hide (arată/ascunde coloane per view), Export Options (export CSV / XLSX / JSON al rezultatului), Table Quick Configuration (preset-uri view).
• Search local (Search: în dreapta) filtrează rezultatul curent client-side.

Notă: tabela e goală în captură pentru că nu s-a apăsat încă "Search" (button verde). După apăsare, rezultatele apar în tabelă cu paginare + sortare.

E2E — apasă Search + listare invoice-uri

După ce filtrele sunt setate (ex: date range de 90 zile) și se apasă butonul verde 🔍 Search, tabela se populează cu rezultate reale de la API SFS. Cache-ul local se actualizează cu invoice-urile aduse.





Notă privacy: coloanele SUPPLIER / BUYER rămân goale în captură pentru că invoice-urile sunt încă UNCACHED (nu s-au adus detaliile XML). După ce se rulează Sync unsynced din Invoice cache, aceste coloane se populează cu numele companiilor.

E2E — vizualizare detaliu invoice

Click pe butonul ▶ din stânga rândului expandează rândul cu detaliul complet al invoice-ului: metadata (Seria, Number, Status, TimeStamp, InvoiceStatus, Xml size) + preview XML/PDF cu structura fiscală (FURNIZOR, CUMPĂRĂTOR, IDNO-uri, adrese, IBAN, Bănci, linii, totaluri).
Butoane disponibile per invoice:

• 📄 PDF (Portrait) — descarcă PDF-ul în format portrait
• 📄 PDF (Landscape) — descarcă PDF-ul în format landscape
• 🙈 Hide Invoice — colapsează detaliul
• 🔍 View XML — deschide XML-ul raw într-un tab nou
• ♻ Refresh — re-cache invoice-ul de la SFS

E2E — Invoice cache management

Modulul Invoice cache din meniu deschide cache management-ul local. Cache-ul stochează XML-urile invoice-urilor aduse de la SFS pentru consultare rapidă offline (dashboard, rapoarte, audit intern) fără roundtrip la SFS pentru fiecare vizualizare.

• Structura view-ului:*

• Stats top row: CACHED INVOICES (câte invoice-uri sunt în cache local), UNSYNCED (câte există local dar nu au XML sincronizat), API CALLS/H (rate limit curent + max).
• ACTOR ROLE dropdown — cache-ul poate fi filtrat pe rol (Buyer / Supplier / Transporter). Ex: Buyer (2) = 2 invoice-uri în cache ca buyer.
• INTERVAL BETWEEN REQUESTS (MS) — cadența dintre request-urile de sync (default 1500ms — respectă rate-limit SFS).
• Butoane sync:
• 🔍 Check unsynced — scanează cache-ul pentru invoice-urile fără XML.
• 🔄 Sync unsynced — aduce XML-urile pentru cele fără (batch-fetch).
• 🔁 Refresh ALL — re-fetch tot cache-ul (util după update SFS).
• 📊 Refresh stats — recalculează stats.
• Invoice Import section (pentru buyer perspective): 4 stats — IMPORTABLE, ALREADY EXISTS, LINKED (NOTES), NOT BUYER. Butonul 🔍 Check import status scanează invoice-urile primite de la alți supplieri și clasifică fiecare (importabil în ERP? deja există? linkat prin notă? nu suntem buyer?).

• Flow tipic pentru un buyer nou: 1. După activare identitate, cache e gol (0 invoices, 0 unsynced). 2. Rulează 🔍 Check unsynced — cache-ul se populează cu shell-uri de invoice (fără XML încă). 3. Rulează 🔄 Sync unsynced — XML-urile se aduc în batch (respectând rate-limit + intervalul configurat). 4. Rulează 🔍 Check import status — vezi câte sunt importabile în ERP (produs corespondent găsit după MPN etc). 5. Pentru cele IMPORTABLE*, poți continua cu flow-ul de import automat în storage-groups.

E2E — Test connection (ping SFS)

Modulul Test connection trimite un ping simplu la SFS pentru validarea că serverul răspunde și identitatea funcționează. Util ca prim pas la troubleshooting sau după activare identitate nouă.


După apăsare Send Test, serverul răspunde cu textul echo-uit + timestamp — util pentru latency check + validare fault de rețea.

E2E — Taxpayer lookup

Modulul Taxpayer lookup interoghează SFS pentru date despre unul sau mai multe IDNO-uri. Util pentru:

• Validare IDNO client înainte de emitere factură B2B
• Verificare status VAT (plătitor activ / nu)
• Verificare că actorul e înregistrat în e-Factura (poate primi facturi electronice)

Următorul pas

→ Imprimante fiscale sau Notificări.