Dezvoltare Odoo: cât să personalizați și când să rămâneți la standard

Când o firmă spune „vrem Odoo adaptat la procesele noastre", cuvântul „adaptat" poate însemna trei lucruri foarte diferite: câteva setări bine alese, o extensie deja existentă sau un modul scris de la zero. Diferența contează, pentru că dezvoltarea Odoo nu se plătește o singură dată. Ea se plătește și la fiecare actualizare, la fiecare schimbare de personal și la fiecare modificare fiscală.

Pagina de față vă ajută să împărțiți cerințele pe niveluri, să știți ce se poate face fără cod, ce cere un dezvoltator și cum judecați un partener înainte să semnați.

Ce înseamnă personalizare Odoo: patru niveluri, nu unul

Cea mai utilă regulă este să urcați treptele pe rând și să vă opriți la prima care rezolvă problema.

Un proiect sănătos are multe cerințe la nivelurile 1 și 2, câteva la 3 și un număr mic la 4. Dacă lista voastră arată invers, fie procesele sunt cu adevărat atipice, fie cerințele au fost formulate prea devreme ca „programare" și nu ca nevoie de afaceri. Merită să le recitiți cu ajutorul unui model de caiet de sarcini ERP.

Configurarea: ce se rezolvă fără niciun rând de cod

Înainte de orice dezvoltare, verificați ce acoperă deja modulele Odoo. Odoo anunță 50 de aplicații principale, iar comunitatea a contribuit cu peste 50 000 de aplicații suplimentare. Cu o ofertă atât de largă, o cerință care pare „specială" are adesea un răspuns în setări sau într-o aplicație existentă.

Câteva exemple tipice pentru o PMM din România:

• numerotarea și șabloanele facturilor, care țin de configurare;
• circuitul de aprobare a comenzilor de achiziție, după valoare sau după centrul de cost;
• câmpuri suplimentare pe fișa de client, utile unui contabil sau unui agent de vânzări;
• alerte automate pentru facturi scadente sau stocuri sub un prag.

Tot aici intră și particularitățile legate de Odoo în România: plan de conturi, TVA, raportări către ANAF. Acestea se tratează întâi prin localizarea existentă și abia apoi, dacă rămâne un gol, prin dezvoltare.

Odoo Studio: personalizare fără cod, cu o condiție de licență

Odoo Studio permite, fără programare, personalizarea câmpurilor, vizualizărilor, modelelor, aplicațiilor, regulilor de automatizare, webhook-urilor, rapoartelor PDF, regulilor de aprobare și regulilor de securitate. Pentru un director financiar care vrea un raport propriu sau un câmp obligatoriu pe comenzi, este adesea calea cea mai rapidă.

Există însă un detaliu comercial pe care mulți îl descoperă târziu. Studio face parte din formula Odoo Custom. Instalarea Studio pe o bază aflată în formula Standard declanșează automat trecerea la Custom: printr-o comandă complementară cu termen de 30 de zile, în cazul unui contract anual, sau printr-o trecere automată la următorul ciclu de facturare, în cazul unui contract lunar. La fel, instalarea Studio sau adăugarea de societăți mută o bază gratuită în Custom.

Diferența de preț, după cifrele publicate de Odoo, este următoarea:

Costurile Odoo.sh nu sunt incluse în prețul Custom. Pentru o imagine completă a bugetului, citiți și pagina despre prețurile Odoo: decizia „folosim Studio" se traduce într-o diferență lunară înmulțită cu numărul de utilizatori cu acces backend, deci merită calculată din timp.

Dezvoltarea specifică: când are sens un modul la comandă

Un modul la comandă se justifică atunci când nevoia este durabilă, specifică firmei și nu poate fi acoperită curat de configurare, Studio sau o extensie existentă. Situații în care întâlnim des această nevoie:

• un calcul de preț sau de comision cu reguli proprii, imposibil de exprimat prin liste de prețuri;
• un flux de producție cu etape sau controale care nu există în aplicația standard;
• o integrare cu un sistem intern sau cu un partener, descrisă în pagina despre integrările Odoo;
• o logistică internă (rute, depozite, ambalare) cu particularități de sector.

Din punct de vedere tehnic, modulele Odoo se scriu în Python, cu vizualizări descrise în XML și, la nevoie, componente de interfață în JavaScript. Dezvoltatorii pot crea module pe baza Odoo și le pot distribui sub licența aleasă, cu condiția ca aceasta să fie compatibilă cu cea a ediției de bază: LGPLv3 pentru Community, restricțiile Enterprise pentru Enterprise. Implicația practică: un modul scris pentru Enterprise nu se poate oferi liber, iar codul pe care îl comandați trebuie să aibă clarificat, în contract, cine deține drepturile asupra lui.

API-ul extern: o cale alternativă la modulul la comandă

Uneori nu e nevoie să modificați Odoo, ci să îl conectați. Documentația oficială prezintă JSON-2 ca API curent, cu chei de API, drepturi de acces, alegerea bazei de date și tranzacții, în timp ce XML-RPC și JSON-RPC sunt tratate ca metode istorice, cu un ghid de migrare spre JSON-2. Accesul la API-ul extern este rezervat formulei Custom.

Dacă un integrator vă propune o legătură bazată pe protocoalele istorice, întrebați de ce și ce plan există pentru trecerea la JSON-2. Este un test simplu al faptului că echipa urmărește documentația curentă.

Impactul asupra actualizărilor: de ce contează cât de adânc intervenim

Fiecare personalizare adaugă o „datorie" tehnică. Modulele care extind comportamentul standard (adaugă un câmp, o regulă, un buton) sunt de regulă mai ușor de adaptat la o versiune nouă. Cele care înlocuiesc sau duplică logica de bază sunt exact cele care se strică la schimbarea versiunii.

Lucrurile de urmărit:

1. Versiunea țintă. Un modul scris pentru o versiune trebuie verificat și, adesea, adaptat pentru următoarea. Detalii despre ritmul și alegerea ediției găsiți în pagina despre versiunile și edițiile Odoo.
2. Dependențele. Un modul care se sprijină pe alte module comunitare moștenește riscul acestora.
3. Studio și codul. Personalizările făcute în Studio se verifică la fel ca modulele: la migrare nu sunt „gratuite".
4. Locul de găzduire. Libertatea de a instala module proprii depinde de formula și de modul de găzduire; Odoo se oferă ca Odoo Online (SaaS), Odoo.sh sau instalare proprie, ultimele două în formula Custom.

Când proiectul trece de la o versiune la alta, un inventar al personalizărilor este primul document cerut. Aceeași logică se aplică în migrarea Odoo.

Bune practici: standard, documentație, teste

Cele mai solide proiecte respectă câteva reguli simple.

Rămâneți la standard cât de mult posibil

Adaptați procesul la aplicație înainte de a adapta aplicația la proces. Dacă o cerință vine din „așa am făcut mereu", discutați-o în atelierul de analiză. Mulți dintre cei care au o listă lungă de dezvoltări descoperă, după câteva luni de utilizare, că jumătate nu mai sunt necesare.

Documentați fiecare modul

Pentru fiecare dezvoltare, cereți o fișă scurtă: ce problemă rezolvă, ce modele și câmpuri atinge, cine a cerut-o, cum se testează. Fără ea, un modul devine opac în clipa în care dezvoltatorul pleacă.

Lucrați cu un mediu de test separat

Orice modificare se verifică pe o copie a bazei, cu date reprezentative, înainte de a intra în producție. Pentru un serviciu financiar, de exemplu, o schimbare într-un flux de facturare trebuie încercată pe scenarii reale: factură cu mai multe cote de TVA, notă de credit, export către RO e-Factura. Cereți scenarii de test scrise și semnate de reprezentantul departamentului în cauză.

Păstrați codul într-un depozit versionat

Codul trebuie să stea într-un depozit cu istoric, la care aveți acces și dvs., nu doar furnizorul. Este o asigurare simplă împotriva dependenței de o singură persoană.

Planificați întreținerea de la început

Un modul are nevoie de cineva care îl poate corecta și după go-live. Includeți în ofertă ce se întâmplă la o eroare, cine răspunde și în ce condiții; vedeți și pagina despre suportul și mentenanța Odoo.

Cum evaluați un dezvoltator sau un integrator Odoo

Alegerea partenerului contează mai mult decât alegerea tehnică. Odoo vorbește despre peste 21 000 de parteneri în lume, așa că oferta este largă și calitatea diferă mult. Ca să separați răspunsurile bune de cele de vitrină, puneți întrebări concrete:

• Cum clasificați această cerință? Un partener serios o încadrează la unul dintre cele patru niveluri și explică de ce nu propune ceva mai simplu.
• Ce se întâmplă la următoarea versiune? Așteptați un răspuns despre testare, buget separat și calendar, nu o promisiune generală.
• Cine deține codul și unde stă? Răspunsul trebuie să fie în contract.
• Cum arată un mediu de test și cine validează? Un integrator care testează doar în producție este un risc.
• Ce referințe pot verifica în domeniul meu? Cereți să vorbiți cu o firmă comparabilă, în sectorul dvs. Odoo pentru industrii vă ajută să formulați întrebările potrivite.
• Cum arată predarea? Documentație, instruire a utilizatorilor-cheie, acces la depozit.

Un semn bun este un partener care vă propune să reduceți lista de dezvoltări. Un semn rău este lipsa oricărei întrebări despre procesele dvs. înainte de ofertă. Pentru un cadru mai larg, citiți cum alegeți un partener Odoo și cum alegeți un integrator ERP.

Dacă aveți deja un proiect cu multe module la comandă și vă temeți de actualizare sau de dependența de un singur dezvoltator, un audit al proiectului Odoo poate stabili ce se păstrează, ce se simplifică și ce se rescrie.

Cazul particular al obligațiilor fiscale din România

Pentru o firmă din România, tentația este să „rezolvați" fiscalitatea prin cod propriu: e-Factura, SAF-T (D406), RO e-Transport. Aici prudența este de două ori mai mare, pentru că regulile și formatele se schimbă la inițiativa ANAF, nu a dvs. Un modul proprietar care reproduce o regulă fiscală rămâne în urmă de îndată ce regula se modifică.

Practic, procedați așa:

1. verificați ce oferă versiunea Odoo folosită și ce acoperă integratorul prin localizare;
2. rezervați dezvoltarea pentru ceea ce e specific firmei, de exemplu felul în care datele din depozit ajung în declarații;
3. cereți în contract cine actualizează modulul când se schimbă formatul.

Dacă facturarea electronică e punctul sensibil, începeți cu ghidul despre ERP și facturarea electronică, apoi reveniți la întrebarea cât din nevoie trebuie să fie dezvoltat.

În concluzie

Personalizarea unui ERP este un instrument, nu un scop. Cu Odoo aveți un catalog bogat, un instrument fără cod și posibilitatea de a scrie module proprii; arta este să le folosiți în această ordine și să păstrați baza cât mai aproape de standard. Un proiect bine condus se vede la prima actualizare: se desfășoară calm, fiindcă personalizările sunt puține, documentate și testate. Planul complet al unui proiect este descris în pagina despre implementarea Odoo.

Numele programelor menționate sunt mărci ale editorilor respectivi și apar doar cu titlu informativ. Acest site este independent și nu este afiliat niciunui editor.