Export contabil SAGA — acum și XML, nu doar .dbf, testat cu o contabilă reală

Am lansat prima versiune a exportului pentru SAGA — programul de contabilitate folosit de multe firme mici și mijlocii din România — în format .dbf, pentru persoane, deșeuri, intrări și ieșiri. Câteva zile mai târziu, contabila unui client a încercat să-l importe. SAGA n-a dat nicio eroare. Pur și simplu n-a preluat nimic.

Așa arată, de multe ori, un bug real în producție: nu un mesaj de eroare, ci o tăcere care te lasă să crezi că a mers.

Ce s-a întâmplat de fapt

Formatul .dbf pe care l-am construit inițial era o interpretare proprie, bazată pe documentația generală de format dBase — nedocumentată oficial de SAGA pentru acest scop exact. Când ne-am uitat direct pe manualul oficial SAGA, am găsit răspunsul: pagina de import de date documentează explicit doar formatul XML, nu .dbf. Asta explică de ce importul tăcea — probabil SAGA nici nu recunoștea structura fișierului ca fiind un input valid pentru acel ecran.

Am construit exporturile XML de la zero, pentru persoane, companii și deșeuri, alături de .dbf-ul existent — l-am lăsat activ până la o confirmare reală de import reușit, ca să nu pierdem singura variantă funcțională dacă noul format avea și el probleme.

Testat efectiv, pas cu pas, cu contabila

Aici a contat cel mai mult verificarea live, nu presupunerea. Am trecut prin fiecare export împreună cu contabila, cu capturi de ecran reale din SAGA:

• Pentru persoane fizice, câmpul Cod_fiscal acceptă direct CNP-ul — nu trebuia inventat un alt identificator.
• SAGA își alocă singur coduri interne secvențiale pentru fiecare intrare nouă — dacă am fi forțat un identificator propriu pe acel câmp, am fi riscat exact același eșec tăcut ca la .dbf. Codul nostru intern merge în schimb pe un câmp separat, dedicat potrivirii stabile la re-importuri ulterioare.
• Exportul de articole (deșeuri) respingea complet importul dacă tipul de articol lipsea — un mesaj clar, "alegeți tipul de articol", dar care bloca tot fișierul, nu doar linia respectivă. Tipul de articol e un nomenclator configurabil diferit de la o firmă la alta în SAGA, deci nu putea fi hardcodat generic — am adăugat un câmp de configurare per client, editabil dintr-un formular protejat împotriva modificărilor accidentale.
• La exportul de intrări, un alt import eșua complet cu eroarea "codul județului trimis este invalid" — pentru că trimiteam textul liber introdus de operator ("București") în loc de codul standard folosit de SAGA. Am refolosit aceeași logică de normalizare a județului deja construită pentru integrarea cu e-Factura.

Corecția care conta cel mai mult pentru client

Cea mai importantă corecție a venit direct de la Stefan, după ce a văzut rezultatul în SAGA: numărul de document care apărea pe facturile de intrare era codul intern de urmărire din aplicație (de tipul COL-26-0043), nu numărul legal de borderou (de tipul BRD000013) pe care contabila îl aștepta și pe care îl caută la reconciliere.

Diferența pare mică, dar contează enorm pentru cine face contabilitate — un document contabil trebuie să poarte numărul legal, recunoscut oficial, nu un identificator intern al aplicației. Aceeași confuzie exista, nedescoperită până atunci, și în vechiul export .dbf. Am corectat-o în ambele formate și am adăugat un test dedicat, ca să nu revină neobservată la o schimbare viitoare.

De ce contează pentru un operator

Un export contabil care nu funcționează la import nu e o problemă vizibilă imediat — apare abia când contabila încearcă efectiv să-l folosească, de multe ori la finalul lunii, sub presiune de timp. Verificarea live cu o contabilă reală, pe SAGA real, nu pe presupuneri despre cum ar trebui să arate formatul, e diferența dintre un export care "pare corect" și unul care chiar funcționează la contabilitatea ta.

Dacă lucrezi cu SAGA, exportul XML e acum recomandat explicit din pagina de rapoarte — .dbf-ul rămâne disponibil, dar XML e formatul documentat oficial și testat direct cu un caz real de import.