Suport și mentenanță Odoo: ce primiți de la editor și ce trebuie să cereți integratorului

Un ERP nu se oprește la ziua punerii în producție. Facturile trebuie să plece în continuare prin RO e-Factura, declarațiile cerute de ANAF trebuie să rămână conforme, utilizatorii pierd parole, un modul comunitar nu mai funcționează după o actualizare. Aici intervine suportul Odoo, iar întrebarea practică pentru o PME din România este simplă: cine răspunde, pentru ce și în ce termen?

Răspunsul are două jumătăți. Editorul vă dă un cadru (abonament, versiuni, upgrade-uri), iar integratorul vă dă ce lipsește: cunoașterea procesului dumneavoastră, a modulelor adăugate și a particularităților contabilității românești. Pagina aceasta explică împărțirea, ce înseamnă mentenanța Odoo și TMA Odoo în practică, ce clauze să cereți și cum se schimbă prestatorul fără să destabilizați firma.

Ce acoperă editorul, ce acoperă integratorul

Confuzia vine din faptul că ambii „fac suport". De fapt, nu răspund la aceleași întrebări.

Suportul inclus în abonamentul Odoo

Conform paginii de prețuri a editorului, suportul inclus înseamnă acces nelimitat prin e-mail, de luni până vineri (24/5), în engleză, franceză, spaniolă sau olandeză. Pachetul cuprinde și platforma de e-learning, precum și mutarea către versiuni noi (upgrade-urile). Este un suport despre produsul standard: un comportament neașteptat al unei aplicații Odoo, o eroare de program, o întrebare despre o funcție.

Reținerea importantă pentru un decident: suportul se oferă într-o limbă străină și are ca obiect produsul, nu firma dumneavoastră. Dacă un contabil nu înțelege de ce o notă contabilă nu se generează conform planului de conturi românesc, un răspuns în engleză despre meniul standard nu rezolvă problema.

Ce rămâne pe umerii integratorului

Integratorul este cel care a configurat fluxurile, a scris adaptările și cunoaște istoricul deciziilor. Rolul lui acoperă, în mod normal:

• suportul aplicativ: răspunsuri la întrebările utilizatorilor, în română, despre cum se face o operațiune în sistemul dumneavoastră;
• corectarea incidentelor legate de configurare sau de dezvoltările specifice;
• mentenanța preventivă: verificarea sarcinilor automate, a copiilor de siguranță, a performanței;
• gestionarea actualizărilor: pregătire, test, punere în producție;
• evoluțiile: rapoarte noi, fluxuri de aprobare, conectori, module suplimentare.

Dacă lucrați cu modulele comunitare sau cu dezvoltări proprii, acestea nu intră în suportul editorului: le susține cel care le-a scris sau cel care le-a preluat prin contract. Mai multe despre acest subiect în pagina despre dezvoltările și personalizările Odoo.

Suport, mentenanță, TMA: vocabular fără ambiguități

Pe piață aceste cuvinte se amestecă. Iată cum să le citiți într-o ofertă.

În ofertele locale veți vedea și „mentenanță" folosit pentru tot. Cereți să vi se spună ce intră concret în fiecare linie și ce se facturează separat.

Mentenanța legată de reglementările din România

Un ERP folosit în România nu este stabil doar pentru că rulează fără erori. Se schimbă formatul unei declarații, evoluează cerințele pentru RO e-Factura, SAF-T (D406) sau RO e-Transport, iar sistemul trebuie să urmeze. Această muncă este o mentenanță adaptativă și trebuie să apară explicit în contract:

• cine urmărește modificările cerute de ANAF și anunță clientul;
• cine adaptează sistemul și în ce termen, în raport cu data de aplicare;
• dacă adaptarea este inclusă în TMA sau se facturează ca proiect;
• cine o testează cu contabilul dumneavoastră înainte de producție.

Ghidurile noastre despre facturarea electronică în ERP și despre cerințele legale pentru un ERP arată de ce această clauză cântărește mult. Un contract care tace despre subiect lasă o zonă gri exact acolo unde termenele sunt cele mai strânse.

Actualizările: cel mai mare subiect al mentenanței Odoo

Odoo evoluează repede, iar planificarea versiunilor este o parte centrală a mentenanței, nu un detaliu tehnic.

Cum funcționează ciclul de viață

Potrivit documentației editorului, fiecare versiune majoră beneficiază de trei ani de suport standard după lansare, pe Odoo Online, Odoo.sh și pe server propriu. După acest termen urmează un suport extins, plătit, disponibil doar pe Odoo.sh (pentru un număr limitat de versiuni) și pe server propriu. Versiunile intermediare de tip SaaS apar la fiecare două-trei luni, rulează doar pe Odoo Online și nu dau dreptul la suport extins.

Două consecințe practice:

• Corecțiile de securitate se livrează numai în perioada de suport standard. În suportul extins, asistența și corecțiile de erori rămân posibile doar când sunt fezabile tehnic.
• Pe Odoo Online și Odoo.sh, upgrade-ul către o versiune majoră este obligatoriu o dată la doi ani, iar versiunile intermediare trebuie actualizate în săptămânile care urmează noii versiuni; Odoo trimite preaviz.

Documentația adaugă că, după cei trei ani de suport standard, mai există doi ani pentru a face upgrade-urile necesare înainte de a pierde orice suport.

Calendarul versiunilor

Conform paginii versiunilor suportate:

Versiunea 20.0 era anunțată pentru septembrie 2026, cu suport standard până în septembrie 2029. Verificați întotdeauna pagina editorului înainte de a lua o decizie, pentru că aceste date se actualizează.

Concret: dacă firma dumneavoastră rulează încă pe 17.0, vă aflați la sfârșitul suportului standard și un plan de migrare ar fi trebuit să fie deja pe masă. Pentru detalii despre alegerea versiunii și a ediției, vedeți versiunile și edițiile Odoo; pentru trecerea propriu-zisă, migrarea Odoo.

Cum se pregătește un upgrade fără surprize

Procedura editorului prevede obținerea unei baze de test actualizate, pentru a valida noua versiune înainte de producție; unele servicii rămân în afara perimetrului SLA-ului de upgrade. Sarcina integratorului este cea care contează: să verifice dezvoltările specifice, să reia modulele comunitare, să pună contabilul și responsabilul de stoc să testeze scenariile reale. Un upgrade pe care nu l-au testat utilizatorii nu este un upgrade validat.

Ce să cereți într-un contract de suport sau de TMA

Un contract bun descrie clar cine face ce și în cât timp. Elementele pe care le verificăm la o ofertă:

Perimetrul

• aplicațiile și dezvoltările acoperite, cu lista modulelor comunitare;
• mediile incluse (producție, test, pregătire);
• ce înseamnă „incident" și ce înseamnă „cerere de modificare";
• excluderile, scrise explicit.

Nivelurile de serviciu (SLA)

Cereți o clasificare a urgențelor și, pentru fiecare clasă, un termen de preluare și un termen de remediere sau de soluție de ocolire. Un sistem blocat în ziua închiderii lunii sau în ziua depunerii unei declarații nu are aceeași urgență ca o schimbare de culoare într-un raport. Precizați intervalul orar de acoperire: zilele lucrătoare, orele de birou, eventual zilele de închidere contabilă.

Verificați și canalul de contact (ticket, e-mail, telefon), limba, precum și cine este interlocutorul cunoscut. Un contract fără cap de linie numit devine un ghișeu anonim.

Responsabilitățile pentru actualizări

Contractul trebuie să spună cine pregătește upgrade-ul, cine face testele, cine decide data punerii în producție și ce se întâmplă cu dezvoltările specifice care nu mai sunt compatibile. Când un modul comunitar nu mai este întreținut de autor, cine preia răspunderea?

Securitate, copii de siguranță și continuitate

Precizați cine verifică copiile de siguranță, cine testează restaurarea și unde sunt stocate datele. Pentru o instanță găzduită de prestator sau pe un server propriu, aspectele acestea sunt în sarcina cuiva, iar acel cineva trebuie numit. Detaliile de găzduire sunt în pagina despre Odoo în cloud.

Raportarea și revizuirea

Cereți un raport periodic: tichete deschise, timp de rezolvare, cauze recurente. Un contract care nu produce nicio cifră nu se poate evalua. Prevedeți o revizuire anuală a perimetrului, pentru că folosirea sistemului evoluează.

Ce să prevedeți în buget

Fără cifre inventate, iată structura costurilor pe care o veți regăsi în orice ofertă:

Tarifele editorului sunt publice. Formula Standard costă 24,90 EUR pe utilizator și pe lună, iar Custom 44,90 EUR pe utilizator și pe lună (reducere de la 31,10 EUR, respectiv 56,90 EUR, valabilă 12 luni pentru utilizatorii comandați la început); costurile Odoo.sh nu sunt incluse în Custom. Utilizatorii portal (clienți, furnizori) nu se numără ca utilizatori plătiți. Pagina despre prețurile Odoo detaliază aceste formule, iar ghidul costul unui ERP arată cum se construiește un buget complet, în RON, fără a uita costurile recurente.

Un reflex sănătos: raportați costul suportului nu la o sumă anuală izolată, ci la ce evită. O zi în care facturarea este blocată, o închidere de lună întârziată sau o eroare de gestiune descoperită târziu costă adesea mai mult decât contractul.

Suport sau plată la solicitare: cum alegeți

Nu orice firmă are nevoie de un contract complet.

• Contract cu SLA: potrivit când mai mulți utilizatori lucrează zilnic în sistem, când aveți fluxuri critice (facturare, producție, depozit) sau dezvoltări specifice numeroase.
• Bloc de ore reîncărcabil: o soluție de mijloc, utilă când cererile sunt neregulate, dar vreți să aveți prioritate la prestator.
• Plată la solicitare: acceptabilă pentru un sistem simplu, cu aplicații standard, puțini utilizatori și foarte puține modificări.

Pentru o PME care abia a pus în producție primele aplicații, primele luni cer un suport apropiat. Intensitatea scade, apoi, pe măsură ce utilizatorii capătă autonomie, ceea ce depinde și de calitatea instruirii Odoo primite la lansare.

Cum schimbați prestatorul de suport

Schimbarea integratorului este mai rară decât ar trebui. Motivele sunt cunoscute: răspunsuri lente, rotație a consultanților, lipsa competenței pe o versiune nouă, un prestator care nu mai e disponibil. Alt motiv, mai prozaic, este teama de dependență. Se poate face cu metodă.

1. Recuperați ce vă aparține. Cerere scrisă pentru codul dezvoltărilor specifice, documentația, accesul la mediul de test, lista modulelor comunitare și versiunile lor, jurnalul incidentelor.
2. Comandați un audit al stării. Un nou prestator are nevoie de o fotografie fidelă: versiunea, dezvoltările, datoriile tehnice. Vedeți auditul unui proiect Odoo, care poate stabili și dacă merită reluat codul existent.
3. Planificați o perioadă de tranziție. Cei doi prestatori lucrează în paralel o perioadă convenită, cu un transfer de cunoștințe documentat.
4. Alegeți momentul. Evitați săptămânile de închidere contabilă și intervalele cu termene fiscale; o fereastră naturală este imediat după un upgrade validat.
5. Verificați contractul vechi. Termenii de reziliere, preavizul, clauzele privind codul și datele.

Dacă nu aveți încă un nou partener, pagina cum alegeți un partener Odoo enumeră criteriile, iar ghidul alegerea integratorului ERP le pune într-un cadru mai larg. Noi nu facem proiectul: facem legătura cu integratori calificați, iar dumneavoastră comparați ofertele.

Greșeli frecvente în suportul Odoo

• Să credeți că abonamentul editorului înlocuiește integratorul. Nu răspunde pentru configurarea dumneavoastră.
• Să amânați upgrade-urile până când suportul standard expiră. Corecțiile de securitate dispar atunci, iar migrarea devine un proiect mare în loc de o mentenanță obișnuită.
• Să acumulați dezvoltări fără documentație. Orice schimbare de prestator devine dureroasă.
• Să nu numiți un responsabil intern. Un „key user" care filtrează cererile și le prioritizează reduce volumul de tichete și accelerează rezolvarea.
• Să lăsați legislația în afara contractului. Adaptările pentru e-Factura, SAF-T (D406) sau e-Transport se negociază din timp, nu în săptămâna termenului.

Dacă proiectul abia începe, ar fi util să includeți suportul în discuția despre implementarea Odoo: ce se predă, ce se documentează și cine rămâne responsabil după lansare sunt întrebări mai ușor de rezolvat înainte de semnarea contractului de proiect decât după.

Pregătiți cererea dumneavoastră

Pentru a primi oferte comparabile, adunați câteva elemente: versiunea Odoo folosită, modul de găzduire, aplicațiile active, numărul de utilizatori în termeni generali, lista dezvoltărilor specifice, reglementările pe care sistemul trebuie să le urmeze și problemele recurente din ultimul an. Cu aceste informații, un integrator poate propune un perimetru realist, iar dumneavoastră puteți compara serios mai multe propuneri.

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.