Articolul este disponibil doar în limba română.
Unde se termină determinismul
O factură e-Factura vine ca XML, cu structură fixă: o citești exact, fără AI. Dar o comandă trimisă pe e-mail ca PDF, un CMR scanat sau factura unui furnizor străin nu au o structură pe care s-o poți parcurge cu reguli. Aici este zidul din teza „Munca dintre sisteme”: partea care cerea până acum un om care citește.
Modelele de limbaj citesc aceste documente aproape ca un om. Nu înseamnă că le putem crede pe cuvânt. De aceea citirea e înconjurată de o buclă.
Bucla, pas cu pas
- Primirea. Documentul vine pe e-mail, prin încărcare sau din SPV. Îl păstrăm neschimbat, ca original.
- Citirea. Textul se extrage direct din PDF; pentru scanări trece prin OCR.
- Extragerea pe o schemă fixă. Modelul completează câmpuri definite dinainte: client, CUI, produse, cantități, prețuri, totaluri, date de livrare. Nu scrie text liber.
- Verificarea cu reguli. Suma liniilor trebuie să dea totalul, TVA-ul trebuie să fie calculat corect, CUI-ul trebuie să existe la ANAF, produsele trebuie să existe în nomenclator.
- Decizia. Dacă toate regulile trec, documentul intră automat, dacă firma a ales asta pentru acel tip de document. Dacă nu, ajunge la cineva din echipă, cu câmpurile problemă marcate.
- Urma. Fiecare câmp știe din ce pagină a documentului vine, iar fiecare corecție se păstrează.
De ce o schemă, și nu o conversație
Un model întrebat „ce scrie în document?” răspunde frumos și diferit de fiecare dată. Un model obligat să completeze aceleași câmpuri produce date care se pot verifica. Regulile de la pasul 4 funcționează doar pentru că pasul 3 a produs structură.
O schemă pentru o comandă, în schiță:
{
"client": { "denumire": "...", "cui": "..." },
"livrare": { "adresa": "...", "data": "..." },
"linii": [ { "cod": "...", "denumire": "...", "cantitate": ..., "pret_unitar": ... } ],
"total_fara_tva": ..., "tva": ..., "total": ...
}Și câteva dintre regulile care urmează:
| Regulă | Ce verifică | Dacă nu trece |
|---|---|---|
| totaluri | suma liniilor dă totalul, iar TVA-ul e calculat corect | documentul merge la un om |
| partener | CUI-ul există la ANAF și corespunde clientului | documentul merge la un om |
| produse | fiecare cod există în nomenclator sau are o asociere confirmată | linia se marchează |
| duplicat | același document n-a mai fost preluat | documentul se oprește |
Ce facem cu greșelile
O greșeală prinsă de reguli nu ajunge în ERP. O corecție făcută de cineva din echipă se transformă, unde se poate, într-o regulă sau într-o asociere nouă: codul furnizorului legat de produsul corect, formatul de dată al unui anumit client. În Agentique, datele clienților nu sunt folosite la antrenarea modelelor AI; ce se îmbunătățește sunt regulile și asocierile din sistem.
Unde l-am folosit
- În ERP-ul de transport pe care îl dezvoltăm și îl întreținem, CMR-urile, comenzile de transport și facturile sunt citite automat, iar datele extrase completează comanda.
- În Agentique, documentele firmei devin căutabile, iar fiecare răspuns vine cu documentul și pagina din care provine.
Semne că o soluție de „citire cu AI” nu e gata de producție
- Nu există reguli după model: ce a citit AI-ul intră direct în sistem.
- Nu poți vedea din ce parte a documentului vine o valoare.
- Nu există o coadă de verificare pentru documentele care nu trec regulile.
- Nu știi ce se întâmplă cu datele tale după ce au fost citite.
Vrei asta în firma ta?
La auditul digital gratuit ne uităm cum lucrează firma ta acum și îți spunem ce se poate automatiza, cu sau fără AI, și cât costă.