e-Factura în Magento 2: ce cere legea și ce se strică, de fapt, în magazin

Aproape toate articolele despre e-Factura explică legea. Sunt utile pentru contabil și inutile pentru cine trebuie să o facă să funcționeze într-un magazin cu mii de comenzi pe lună. Articolul ăsta e despre partea a doua: ce se întâmplă concret când conectezi un Magento 2 la SPV și de ce „am instalat un modul” nu înseamnă că ești conform.

Ce cere legea, pe scurt

Cadrul s-a construit în patru etape: OUG 120/2021 a introdus sistemul pentru relația cu instituțiile publice, OUG 115/2023 a făcut obligatoriu B2B-ul, OUG 28/2024 a adus sancțiunile și clarificarea termenului, iar OUG 69/2024 a extins obligația la B2C.

• De când: B2C e obligatoriu de la 1 ianuarie 2025 pentru operatorii stabiliți în România, când livrarea are loc în România din punct de vedere al TVA.
• În cât timp: XML-ul trebuie transmis în SPV în maximum 5 zile lucrătoare de la emiterea facturii. Termenul e unificat, la fel pentru B2B și B2C.
• Ce se întâmplă dacă nu: amenzile din OUG 28/2024 se aplică per factură netransmisă — 5.000-10.000 lei pentru contribuabilii mari, 2.500-5.000 pentru cei mijlocii, 1.000-2.500 pentru restul.

Reține partea care contează pentru arhitectură: per factură netransmisă. Într-un magazin cu 3.000 de comenzi pe lună, o integrare care eșuează tăcut la 2% din facturi înseamnă 60 de facturi pe lună. Riscul nu e teoretic, e multiplicativ.

De ce nu e „doar un modul”

Magento are un obiect numit invoice. Numele induce în eroare: e un document intern de gestiune, care marchează că o comandă a fost facturată. Nu e o factură fiscală românească. Nu are serie și număr dintr-un registru fiscal, nu are structura cerută de standardul CIUS-RO și nu conține obligatoriu toate câmpurile pe care le validează ANAF.

Un modul de e-Factura face traducerea dintre cele două. Cât de bine o face se vede abia în cazurile de la margine — și magazinele reale trăiesc în cazurile de la margine.

Cele nouă locuri unde cedează implementarea

1. Momentul emiterii, care pornește ceasul

Cele 5 zile lucrătoare curg de la emiterea facturii. Într-un magazin, „emiterea” poate fi la plasarea comenzii, la încasare, la expediere sau la livrare — și fiecare configurare de Magento face altceva. Dacă factura se generează automat la plasare, dar comanda se anulează a doua zi, ai emis un document pe care acum trebuie să îl stornezi. Dacă se generează la expediere, ceasul pornește mai târziu, dar ai facturi restante când depozitul are întârzieri.

2. Facturile parțiale

Magento permite mai multe facturi pe aceeași comandă — normal, când expediezi în tranșe. Fiecare e un document fiscal distinct și fiecare are propriul termen de transmitere. Integrările făcute în grabă transmit doar prima.

3. Stornările și retururile

Un credit memo din Magento corespunde unei facturi de stornare, care merge și ea în SPV. La un magazin cu retururi frecvente — modă, încălțăminte — asta e o parte importantă din volum, nu o excepție.

4. Cotele de TVA și codurile de categorie

Standardul cere coduri de categorie fiscală, nu doar un procent. Cota redusă, scutirile, taxarea inversă și livrările intracomunitare au fiecare codul lor. Configurarea de taxe din Magento aproape niciodată nu se mapează unu-la-unu, iar diferența apare ca eroare de validare abia după transmitere.

5. Datele clientului

La B2B ai nevoie de CUI valid, verificat. La B2C, structura e alta și nu trebuie să trimiți date pe care nu ești obligat să le transmiți. Adresele au nevoie de coduri de țară și de județ în formatul standardului, nu de textul liber pe care îl completează clientul la checkout.

6. Ce se întâmplă când SPV respinge

O transmitere respinsă nu e o transmitere. Ai nevoie de o coadă cu reîncercare, cu un număr limitat de încercări și cu vizibilitate: cineva trebuie să vadă, într-un ecran, ce facturi au eșuat și de ce. O integrare de tip „trimite și uită” îți lasă amenzi pe care le descoperi peste luni.

7. Trimiterea dublă

Reîncercarea fără idempotență produce duplicate. Trebuie să existe o cheie stabilă pe factură și o verificare înainte de fiecare trimitere, altfel un cron care rulează de două ori îți transmite același document de două ori.

8. Arhivarea documentului semnat

Documentul cu valoare legală e cel semnat de ANAF, întors din SPV, nu XML-ul pe care l-ai trimis tu. Trebuie descărcat, legat de comandă și păstrat. Multe integrări transmit corect și nu descarcă nimic înapoi.

9. Cronul care nu rulează

Toată mecanica de mai sus depinde de cron. Cronul Magento se oprește mai des decât crede lumea — după un deploy, după un upgrade, când coada se blochează pe un job. Fără monitorizare pe vechimea celei mai vechi facturi netransmise, afli că nu mai merge din amendă.

Cum verifici un modul înainte să îl cumperi

Întrebările de mai jos separă modulele serioase de cele care doar generează XML. Sunt aceleași pe care le punem noi când evaluăm unul pentru un client:

Dacă la trei dintre ele răspunsul e vag, modulul îți rezolvă demonstrația și îți lasă problema.

Ce facem noi, concret

Nu vindem un modul propriu. Alegem unul potrivit, îl configurăm pe fluxul real al magazinului și adăugăm ce lipsește — de regulă monitorizarea și tratarea erorilor. Verificarea intră în analiza de cod, iar supravegherea lunară în abonamentul de mentenanță, lângă patch-urile de securitate.

Un detaliu care se ignoră des: integrarea asta atinge checkout-ul și comenzile, adică exact zonele în care un upgrade de Magento poate strica ceva. Dacă ești pe o versiune ieșită din suport, rezolvă întâi versiunea — altfel construiești peste o fundație care oricum trebuie schimbată.