O cerere germană de integrare Odoo numește aproape întotdeauna trei părți: consultantul fiscal cu DATEV, magazinul online pe Shopware sau JTL și, de anul trecut, factura electronică. Partea tehnică a conectării lor este rareori problema. Problema este că fiecare dintre cele trei așteaptă datele într-o formă pe care Odoo nu o produce singur și că nimeni nu spune asta la început.
Așa că, pe rând: ce conține de fapt imaginea standard, ce nu conține și ce cusături a trebuit să cos de mână.
Ce aduce Odoo pentru Germania - numărat, nu presupus
Imaginea de lucru a Odoo 19 Community are 659 de module. Exact unul dintre ele este german: l10n_de, planul de conturi. Module cu DATEV în nume: niciunul. Modulul european one-stop-shop l10n_eu_oss este acolo, la fel și lista de formate pentru facturi electronice, care cunoaște deja XRechnung.
Acest singur număr decide forma oricărui proiect german. Exportul contabil este fie munca ta, fie produsul altcuiva. Imutabilitatea este o setare pe care trebuie mai întâi s-o găsești. Factura electronică este mai aproape decât cred cei mai mulți. Iar tot ce îi trebuie magazinului depinde în întregime de conector.
DATEV: exportul e treaba ta, iar formatul e jumătatea mai mică
Pentru că în cutie nu e nimic, întrebarea este doar cine scrie exportul: un modul plătit, un partener sau eu. Oricine ar fi, partea grea nu este fișierul CSV. DATEV vrea înregistrări contabile, nu documente: cont și cont corespondent, o cheie fiscală, numărul documentului după care consultantul tău face reconcilierea și o dată care cade în perioada corectă. Odoo îți dă bucuros toate patru - odată ce cineva a hotărât ce cont din Odoo corespunde cărui număr din planul de conturi al consultantului și ce se întâmplă cu cazurile care nu au deloc număr.
Cazurile fără număr sunt cele care strică închiderea de lună: o restituire care trece peste granița perioadei, o plată care sosește înaintea facturii, o plată de la marketplace care e o singură linie pentru două sute de comenzi. De aceea îi cer consultantului înregistrările lunii trecute înainte să scriu o singură linie de cod pentru export: fișierul acela spune mai mult despre mapare decât orice ședință.
GoBD: imutabilitatea e un comutator și trebuie acționat devreme
Odoo are ce cer regulile germane, doar că implicit este dezactivat. Jurnalele au restrict_mode_hash_table; activează-l și fiecare înregistrare validată primește un inalterable_hash și un secure_sequence_number, astfel încât un rând modificat poate fi detectat. Compania are restrictive_audit_trail pentru jurnalul de modificări care nu are voie să fie curățat.
Două capcane. Prima: jurnalul are și has_unhashed_entries - recunoașterea onestă că tot ce a fost înregistrat înainte de activarea modului rămâne în afara lanțului și nicio setare ulterioară nu repară asta. Activează-l la go-live, nu când se anunță controlul. A doua este integrarea însăși: un conector care „corectează” o factură validată pentru că magazinul a modificat comanda strică exact proprietatea pe care hash-ul trebuie s-o dovedească. Corecturile sunt documente noi - o notă de credit, o stornare - iar conectorul trebuie scris așa din prima zi.
Magazin: Shopware sau JTL, iar întrebarea e cine deține datele
Amândouă comunică destul de bine - Shopware prin Admin API-ul său, JTL prin propria bază de date și conector - și niciuna dintre acestea nu e motivul pentru care proiectele o iau razna. Motivul este că stocul și prețul există pe ambele părți și ambele părți cred că au dreptate.
Un singur tabel lămurește lucrurile înainte de orice cod: fiecare câmp care trece granița și, alături, singurul sistem care are voie să-l modifice. Stocul îi aparține lui Odoo, magazinul este informat. Prețurile aparțin de obicei magazinului, pentru că acolo au loc campaniile. Orice câmp care primește răspunsul „ambele” va deveni un tichet de suport în cursul trimestrului.
Apoi detaliul german care costă cel mai mult timp: magazinele gândesc în prețuri brute, Odoo gândește în prețuri nete. Scoate nouăsprezece la sută din 49,99 € și adaugă-l la loc, de câteva mii de ori, iar diferențele de cenți apar în contabilitate ca o listă nesfârșită de mici neconcordanțe pe care nimeni nu le poate explica. Hotărăște o dată ce parte decide suma pe care o vede clientul, transmite-o ca atare și lasă cealaltă parte să o calculeze din ea.
E-factura: XRechnung este deja în cutie
De la începutul lui 2025, companiile germane trebuie să poată primi facturi structurate; obligația de a le trimite vine în etape. Vestea bună este că Odoo 19 oferă deja formatul: pe fișa clientului, lista de formate de factură include „Germany (XRechnung)” alături de Factur-X și Peppol BIS 3.0. Accesul la Peppol propriu-zis se află în module separate.
Pentru o integrare asta înseamnă un singur lucru: factura care pleacă din sistemul tău este un document cu câmpuri, nu un PDF cu o imagine a lor. Tot ce îi trebuie XML-ului - referința cumpărătorului, defalcarea taxelor, unitatea de măsură - trebuie să fie în înregistrare înainte ca exportul să ruleze, ceea ce de obicei mă trimite înapoi la conectorul magazinului ca să adun câmpuri pe care nu le-a mapat nimeni.
Cum încep un astfel de proiect
Un apel și trei întrebări care decid estimarea: ce plan de conturi folosește consultantul tău și dacă exportul trebuie să urmeze o practică de înregistrare existentă; dacă modul hash este activ și de când; ce sistem deține stocul, prețul și fișa clientului. Răspunsurile încap pe o pagină, iar acea pagină este specificația integrării.
Dacă ai deja un conector și funcționează, întrebarea utilă este alta: ce face când rulează de două ori și cum afli că azi-noapte nu a rulat deloc? Pentru partea asta sunt chemat de obicei.