Verificarea partenerilor noi în ERP: cum o automatizezi fără să încurci pe nimeni

Fișa unui partener nou n-ar trebui să se salveze definitiv până nu a trecut prin două verificări: profilul fiscal din registrul ANAF și listele trimestriale de restanțe la stat. Asta e toată ideea. Restul articolului e despre cum o pui în practică fără să-i încurci pe colegii de la vânzări.

Știi probabil cum arată fluxul acum. Cineva primește CUI-ul pe email, îl bagă în ERP, copiază denumirea de pe un site și merge mai departe. Verificarea, dacă se face, vine după prima factură neîncasată. Ordinea asta se poate inversa cu destul de puțin cod.

Două întrebări diferite

Profilul fiscal îți spune dacă firma poate fi partenerul tău, legal și fiscal. Afli dacă există, dacă e activă, dacă e plătitoare de TVA, dacă e inactivă fiscal și în ce situație juridică se află.

Restanțele la ANAF răspund la altceva: are firma bani să-și plătească obligațiile? O firmă poate arăta impecabil în registru și totuși să figureze cu datorii mari la bugetul de stat. Am văzut destule cazuri de felul ăsta ca să nu mă mai bazez pe o singură sursă. Și costul e mic: un credit pentru profil și trei pentru restanțe, deci patru pe partener.

Un serviciu mic, separat de ERP

Eu n-aș băga logica direct în ERP. Modelul care rezistă cel mai bine e un serviciu separat, pe care ERP-ul îl cheamă când se creează sau se modifică un partener. Serviciul face apelurile, aplică regulile și întoarce una din trei decizii: aprobat, de revizuit sau blocat.

Pașii sunt puțini. Utilizatorul scrie CUI-ul în fișă, iar ERP-ul îl trimite serviciului. Serviciul cere GET /api/v1/registru/firme/{cui} și completează denumirea, adresa, CAEN-ul și regimul de TVA. Apoi cere GET /api/v1/fiscal/{cui}/restante și citește total_restant și direcția din evolutie.directie. Regulile produc decizia, iar ERP-ul o salvează în fișă, cu data verificării.

Câștigul se vede după câteva luni. Regulile se schimbă fără să atingi ERP-ul, iar același serviciu îl pot folosi CRM-ul sau platforma de comenzi online.

Codul

Exemplul rulează pe sandbox, cu CUI-ul de test 90000010. Sandbox-ul cere o cheie API, deci un cont, dar contul e gratuit și nu cere card. Cererile din sandbox nu consumă credite și primesc date fictive. În producție schimbi doar adresa de bază.

import os, requests

BAZA = "https://www.bilantapi.ro/api/sandbox/v1"
ANTETE = {"X-API-KEY": os.environ["BILANTAPI_KEY"]}

def verifica_partener(cui):
    profil = requests.get(f"{BAZA}/registru/firme/{cui}", headers=ANTETE).json()["data"]
    restante = requests.get(f"{BAZA}/fiscal/{cui}/restante", headers=ANTETE).json()["data"]
    return {
        "cui": profil["cui"],
        "denumire": profil["denumire"],
        "stare": profil["stare"],
        "in_insolventa": profil["stare_juridica"]["in_insolventa"],
        "in_lichidare": profil["stare_juridica"]["in_lichidare"],
        "in_dizolvare": profil["stare_juridica"]["in_dizolvare"],
        "platitor_tva": profil["fiscal"]["platitor_tva"],
        "inactiv": profil["fiscal"]["inactiv"]["activ"],
        "are_restante": restante["are_restante"],
        "total_restant": restante["total_restant"],
        "directie": restante["evolutie"]["directie"],
        "contestate": (restante["structura"] or {}).get("contestate", 0),
        "lista_anaf": restante["publicare_curenta"],
    }

Ce lipsește intenționat din exemplu, dar trebuie să existe la tine: un timeout pe fiecare cerere și un tratament separat pentru CUI-ul care nu există. Cererile fără rezultat nu consumă credite, deci o greșeală de tastare nu te costă nimic.

Regulile de decizie

Partea asta e a ta și n-o poate scrie nimeni în locul tău. Tabelul de mai jos e un punct de plecare pe trei niveluri, cu praguri orientative. Le ajustezi după mărimea tranzacțiilor și după cât risc îți permiți.

Situație	Decizie sugerată
Firma e radiată sau nu există	Blocat
fiscal.inactiv.activ este adevărat	Blocat până la clarificare
stare_juridica.in_insolventa, in_lichidare sau in_dizolvare este adevărat	De revizuit de departamentul financiar
are_restante e adevărat, iar evolutie.directie e crestere sau noua	De revizuit, fără termen de plată până la analiză
Are restanțe mici și stabile	Aprobat, cu limită de credit redusă
Fără probleme în niciuna dintre verificări	Aprobat

Greșeala pe care o văd cel mai des e să blochezi automat tot ce are o restanță. Listele ANAF includ și firme cu sume contestate, iar răspunsul le arată separat, în structura.contestate și structura.necontestate. Dacă firma nu e pe cea mai nouă listă, structura e null. O regulă prea strictă trimite la revizuire jumătate din parteneri, iar după o lună oamenii învață s-o ocolească. Atunci ai pierdut tot.

Ce rămâne scris în fișă

Pe lângă decizie, salvează data verificării și sursa, ca să știi cât de veche e informația. Pentru modulul de facturare păstrezi regimul de TVA, TVA la încasare și plata defalcată. Pentru rapoarte, codul CAEN principal și județul din sediu. Iar din restanțe, totalul și data listei ANAF din publicare_curenta.

Să zicem că peste un an vine un auditor și întreabă de ce ai dat termen de plată unui client care între timp a intrat în insolvență. Cu câmpurile astea în fișă, răspunsul durează un minut: pe ce date s-a luat decizia și când.

Partenerii vechi se schimbă și ei

Verificarea la creare e doar primul pas. O firmă poate deveni inactivă fiscal, poate intra în insolvență sau poate apărea pe lista de restanțe la un an după ce ai aprobat-o. Aici merg două ritmuri diferite.

Profilul fiscal se actualizează zilnic, așa că îl reverifici înainte de facturile importante sau periodic, pentru partenerii activi. Restanțele le reverifici o dată pe trimestru, după publicarea noii liste ANAF. Mai des n-are sens, pentru că listele sunt trimestriale și ai plăti de mai multe ori pentru aceeași informație.

API-ul nu trimite notificări. Reverificarea o programezi tu, cu o sarcină care rulează la intervalul ales și marchează partenerii a căror decizie s-a schimbat.

Când serviciul nu răspunde

Orice serviciu extern poate fi lent sau indisponibil câteva minute. Hotărăște dinainte ce face ERP-ul atunci. Eu aș salva partenerul cu starea „neverificat” și aș reîncerca automat după câteva minute, fără să blochez munca utilizatorului.

Ce nu ai voie să faci e să tratezi o eroare de rețea ca pe un rezultat curat. Un partener neverificat nu e un partener aprobat. Pune în raportul zilnic lista fișelor rămase neverificate și vei vedea repede dacă s-a blocat ceva.

Trei greșeli care revin

Prima e verificarea doar la creare. Un partener aprobat acum doi ani poate arăta cu totul altfel azi, iar fișa lui îți spune încă „aprobat”.

A doua e suprascrierea datelor introduse de mână. Dacă cineva a corectat adresa de livrare, nu o înlocui cu sediul social la următoarea verificare. Ține separat datele oficiale de cele operaționale.

A treia e lipsa unei căi de excepție. Uneori chiar trebuie să lucrezi cu o firmă semnalată, pentru că e singurul furnizor dintr-o zonă sau pentru că plătește în avans. Prevede o aprobare manuală și notează cine a aprobat și de ce.

Prima versiune a serviciului o poți avea gata într-o după-amiază, pe sandbox. Rutele sunt descrise pe paginile API Informații firmă și API Datorii ANAF, iar schema completă e în documentație. Pentru date reale ai nevoie de un cont, care vine cu 250 de credite gratuite și fără card. La patru credite pe partener, îți ajung pentru vreo 60 de firme verificate cu ambele surse.