Există o categorie de probleme care apar abia după ce ai rezolvat e-Factura.
Factura trece de validatorul ANAF. Schema e corectă, semnătura e bună, SPV-ul o acceptă. Și totuși clientul o refuză — pentru că nu-și găsește în ea numărul lui de comandă, codul lui de articol sau referința de contract.
Validatorul ANAF verifică dacă XML-ul respectă standardul. Cumpărătorul verifică dacă poate să-l proceseze automat la el în sistem. Sunt două lucruri diferite, iar al doilea nu se rezolvă dintr-o setare.
Odoo construiește același XML pentru toți partenerii. Clienții nu cer toți același lucru.
Cum arată, în practică
Patru situații care apar la aproape orice furnizor cu clienți mari:
Un lanț de retail. Cumpărătorul se reconciliază pe numărul lui de comandă și pe codurile lui de articol, și refuză ce nu le poartă. Trebuie completate referința comenzii, punctul de livrare și codul lui de articol — acesta din urmă pe fiecare linie.
O instituție publică. Referința licitației sau a lotului trebuie să călătorească împreună cu factura, iar numărul contractului lângă ea.
Un client cu centre de cost proprii. Vrea codul lui contabil pe factură, ca ea să ajungă la departamentul potrivit la el în firmă.
Un cumpărător care refuză o etichetă. Unele validatoare resping tocmai ce completează Odoo implicit. Aici nu trebuie adăugat nimic, ci scos.
Varianta obișnuită e o dezvoltare pentru fiecare. Trei lanțuri de retail, trei module de întreținut.
1. Un catalog, nu o cale XML
Modulul aduce un catalog de etichete CIUS-RO — în jur de treizeci dintre cele cerute în mod curent — fiecare numită după termenul de business și explicată într-un rând.
Asta schimbă cine poate face configurarea. O cale ca cac:OrderReference/cbc:ID cere pe cineva care cunoaște UBL. „Referința comenzii cumpărătorului", aleasă dintr-o listă, cere pe cineva care cunoaște clientul.
Pentru cazurile pe care catalogul nu le acoperă încă rămâne opțiunea căii personalizate, dar ea e rezervată utilizatorilor tehnici.
2. Regula: ce se completează și de unde
O regulă are patru lucruri:
- eticheta de completat, aleasă din catalog;
- de unde vine valoarea — un câmp citit de pe factură sau de pe linia ei (de exemplu referința adresei de livrare sau codul de bare al produsului), un text fix, o expresie pentru ce nu se poate citi dintr-un singur câmp, sau elimină nodul;
- pe ce documente se aplică — facturi, note de credit sau ambele. Etichetele care există doar pe unul din cele două sunt restrânse automat de catalog;
- dacă suprascrie ce a calculat Odoo, sau completează doar când Odoo a lăsat gol.
Mai există o bifă care contează mult: obligatoriu. O regulă marcată așa oprește exportul cu eroare explicită dacă nu produce valoare, în loc să lase factura să plece fără ea.
3. Profiluri, pentru familii de clienți
Dacă toate cele patruzeci de magazine ale unui lanț cer același lucru, configurarea se face o dată.
Un profil e un set de reguli, atașat apoi fiecărui partener din familia respectivă. Iar profilul se mută pe altă bază de date prin copy-paste: pe profil există un tab JSON cu regulile lui, iar pe baza-țintă un buton de import.
Pentru partenerii care au, pe lângă profil, o cerință numai a lor, regulile se pun direct pe partener.
4. Cine câștigă, când două reguli scriu același lucru
Ordinea e simplă și merită știută, pentru că e singurul loc unde configurarea poate deveni confuză:
- regula de pe partener bate regula din profil, dacă scriu aceeași etichetă;
- un contact moștenește regulile companiei și le poate rafina; dintre două reguli care scriu aceeași etichetă, câștigă cea de pe contact.
Asta acoperă cazul real: lanțul are un profil, iar un singur magazin din el cere ceva în plus.
5. Ce se verifică, și când
Două verificări, în două momente diferite.
La salvarea regulii: o cale care nu există în schema e-Factura pentru tipul de document respectiv e refuzată pe loc. Fără asta, greșeala s-ar vedea abia la generarea XML-ului, ca eroare de randare.
La generarea XML-ului: o regulă marcată obligatorie care n-a produs valoare oprește exportul, cu un mesaj care spune care regulă și care partener. Nu e o avertizare în log, e o oprire.
6. Cine are voie să editeze
Regulile astea decid ce se depune la ANAF. De aceea modulul vine cu un drept de acces separat, neacordat nimănui implicit.
Cine poate edita un partener nu capătă automat și dreptul de a schimba ce se trimite în XML-ul lui. E o separare pe care o apreciezi abia după prima dată când cineva „a ajustat puțin" o regulă.
Ce verifici la prima configurare
- O factură de probă pentru partenerul configurat: generează XML-ul și deschide fișierul atașat. Eticheta e acolo, cu valoarea așteptată?
- O notă de credit pentru același partener, dacă regula se aplică la ambele.
- O regulă obligatorie fără valoare, intenționat: exportul chiar se oprește, cu mesajul corect?
- Un partener fără profil — factura lui trebuie să iasă exact ca înainte.
- Dreptul de acces: cine trebuie să-l aibă, îl are; ceilalți, nu.
De ce merită
Nu pentru că e elegant, ci pentru că alternativa se vede în factură.
O dezvoltare per client înseamnă cod care trebuie întreținut la fiecare versiune de Odoo, pentru o cerință care se schimbă când clientul își schimbă ERP-ul. O regulă din interfață se modifică în două minute, de omul care a vorbit cu clientul.
Iar între timp, facturile nu se mai întorc.
Modulul e pe Odoo Apps, pentru Odoo 19 și 20. Dacă ai clienți care refuză facturi pentru referințe lipsă și te gândeai la o dezvoltare, hai să vorbim.