Odoo 20: mire számíthatunk?

Szeptember végén, a brüsszeli Odoo Experience 2026-on mutatják be az Odoo következő főverzióját. A hivatalos, teljes release notes még nem jelent meg — a keynote szeptember 24-én reggel indul —, de a tavaszi Partner Days roadmapjéből, a nyilvános GitHub-repókból és a már kiadott 19.x alverziókból elég tiszta kép rajzolódik ki arról, mire készüljünk.

Röviden: az Odoo 20 nem egy szokásos éves ráncfelvarrás. Három dolog történik egyszerre — az AI kilép a demó-fázisból, az Odoo hozzányúl néhány régóta fájó technológiai alaphoz, és tovább egyszerűsödik a modulstruktúra.

Fontos előrebocsátani: az Odoo agilis fejlesztési modellje miatt a roadmap sosem szerződés. A tavasszal bemutatott funkciók egy része R&D-koncepció, és bevett gyakorlat, hogy egyes elemek átcsúsznak a 20.1–20.4 alverziókra. Az alábbiakat ennek megfelelően érdemes olvasni.

1. Az AI végre csinál valamit

Az Odoo 19 AI-funkciói jórészt szöveggenerálásra korlátozódtak: termékleírás, e-mail sablon, chatbot-válasz. Hasznos, de nem változtatta meg senki munkanapját.

A 20-ban ez más. Az AI kikerül a külön AI-appból, és beépül a Könyvelésbe, a Helpdeskbe, a Timesheetbe, a Projektbe és a Website Builderbe. A lényegi különbség, hogy nem csak javasol, hanem végrehajt: természetes nyelvű utasításra keres, létrehoz és tömegesen módosít rekordokat — a felhasználó jogosultságait és a beépített üzleti szabályokat tiszteletben tartva.

A gyakorlatban ez olyasmit jelent, hogy egy értékesítési vezető beírja, hogy ossza újra a múlt havi inaktív leadeket egy adott csapatnak, és a rendszer értelmezi a feltételt, lekérdezi az érintett rekordokat és elvégzi a módosítást. Menük és szűrők nélkül.

Néhány konkrét funkció, ami a roadmapen szerepel:

• AI Audit Agent a Könyvelésben — végigfut egy negyedév pénzügyi checklistjén, ellenőrzi a kivonatokat, megjelöli az anomáliákat.
• Helpdesk oldalsáv — összefoglalja a chattert, választervezetet ír, hasonló múltbeli ticketek alapján megoldást javasol.
• Timesheet asszisztens — a tényleges rendszer-aktivitás (lezárt feladatok, üzenetek, pull requestek) alapján javasol időbejegyzéseket.
• Projekt-generálás PDF-ből — egy műszaki specifikációból vagy SOW-ból fázisokkal és feladatokkal felépített projektet készít.
• AI Website Builder — többlépéses, természetes nyelvű oldalszerkesztés, kontextusfüggő képgenerálással.

A natív MCP-szerver

Ez a kevésbé látványos, de fejlesztői szemmel talán legfontosabb újdonság. Az Odoo saját MCP-szervert (Model Context Protocol) kap, így külső AI-eszközök — Claude, ChatGPT, Cursor — közvetlenül csatlakozhatnak az adatbázishoz, külön gateway nélkül. Ez már a 19.4-ben megjelent, és a 20-ban is benne lesz.

A modul egyetlen végponton, dedikált API-kulccsal védve öt read-only eszközt szállít: kontextus-lekérdezés, modell-listázás, mező-vizsgálat, rekord-keresés és csoportosított analitika. Az írási funkciók léteznek a kódban, de alapból tiltva vannak — külön engedélyezni kell.

Érdemes reális elvárásokkal közelíteni: az „autonóm" jelzőben van marketing is. A jogosultság-érvényesítést és a hibakezelést kiadáskor tesztelni kell, mielőtt bárminek a felelősségét rábízzuk.

2. Technológiai adósság: két nagy leváltás

Paper Muncher — a wkhtmltopdf vége

Aki üzemeltetett már Odoo-t nagyobb terheléssel, ismeri a problémát. A PDF-generálás mögött álló wkhtmltopdf egy 2014-es WebKit-re épül, 2020 óta hivatalosan elavult, a fejlesztése leállt. Ebből következik a hibás betűtípus-renderelés, a hiányzó szöveg és kép, a memóriaszivárgás, a modern CSS — flexbox, grid — értelmezésének hiánya. Ráadásul a működése egy teljes böngészőt utánoz: ablakot nyit, betölti az oldalt, nyomtatási előnézetbe lép, újrarendel — nagyjából háromszoros felesleges munkát végezve.

Nagy riportoknál ez már nem kényelmetlenség, hanem üzemeltetési kockázat: egy több ezer oldalas főkönyvi kivonat sok ezer külön HTML-fájlra bomlik, amit a motor egyszerre próbál megnyitni, és belefut az operációs rendszer fájl-limitjébe.

Az Odoo saját megoldást épített rá: a Paper Muncher egy C++ nyelven, nulláról írt renderelő motor, nyílt forráskóddal. A projekt deklarált célja, hogy egy nagy főkönyvi kivonatot legalább százszor gyorsabban generáljon a wkhtmltopdf-nél, a HTML/CSS feldolgozás minősége felett kötött kompromisszum nélkül. PDF mellett SVG-t és képformátumokat is tud.

Az ütemezéssel kapcsolatban érdemes óvatosnak lenni. Az Odoo eredetileg a 19.1-et jelölte meg első bevezetési célnak, és a teljes érettséget két évre becsülte. A 20-ban ez nagy valószínűséggel opt-in alternatíva lesz, nem alapértelmezés — a wkhtmltopdf teljes kiváltása reálisan a 21–22 körül zárul le.

Ettől függetlenül: ha van olyan rendszered, ahol a riportnyomtatás ma fájdalom, ez lesz a 20 legkézzelfoghatóbb haszna.

API: a JSON-2 átállás

Az Odoo külső API-ja történelmileg XML-RPC-re és JSON-RPC-re épült. A gond nem csak a protokoll kora, hanem hogy nincsenek absztrahált REST-végpontok — nincs egyszerű GET /invoices. Helyette közvetlen ORM-metódushívások vannak, ami azt jelenti, hogy az integrációt író fejlesztőnek ismernie kell az Odoo belső adatmodelljét. Ez sokakat elriasztott, és megnehezítette a no-code eszközök, egyedi frontendek vagy például a PowerApps csatlakoztatását.

A 19-ben megjelent az új JSON-2 API (/json/2/<model>/<method>, bearer API-kulccsal, Swagger-szerű dokumentációval), és a 20-ban folytatódik az átállás.

Itt fontos egy elterjedt félreértést tisztázni. Több cikk azt írja, hogy az XML-RPC „megszűnik az Odoo 20-ban". Ez nem így van. A hivatalos dokumentáció szerint a 20-ban csak a db (database) szolgáltatás szűnik meg. A common és object szolgáltatások a 22-es verzióban, tehát 2028 őszén. Az Odoo Online-on a kivezetés valamivel korábbi. És ami sokakat megnyugtathat: a @route(type='jsonrpc') kontrollerek — amelyek a 18-ig type='json' néven futottak — nem érintettek.

Ez nem jelenti, hogy ráérünk. Aki ma XML-RPC-n integrál, annak érdemes elkezdenie a JSON-2-re való átállást — ez már a 19-en is megtehető, nem kell megvárni a 20-at.

Ami a motorháztető alatt még változik

A PostgreSQL és Python emelése infrastruktúra-tervezési kérdés — régebbi Ubuntu LTS-en futó szerverek nem viszik. Az Owl 3 pedig a migrációs becslés egyik legnagyobb kockázati tétele: teljesítményjavulást hoz minden nézetben, de a custom JS widgetek átdolgozását igényelheti.

Emellett érkezik egy böngészőben futó PDF report editor is, ahol a QWeb sablon forrása és az élő előnézet egymás mellett látszik — ez a napi fejlesztői munkában komoly időmegtakarítás.

3. Egyszerűsítés: kevesebb modul, több gyári funkció

Field Service beolvad a Planningbe

A leglátványosabb architekturális változás: a Field Service megszűnik önálló alkalmazásként, és teljes egészében a Planning modulba olvad. Egyetlen felület marad az erőforrás-ütemezésre — emberekre és eszközökre egyaránt.

Ehhez jön az utazási idő megjelenítése a Gantt nézetben, útvonal-optimalizálás a térkép nézetben, élő technikus-térkép, anyag-hozzárendelés dolgozókhoz, és testreszabható worksheet property-k. Aki helyszíni szervizt üzemeltet, annak ez érdemi tervezési nyereség.

A Payroll átalakítása

A bérszámfejtésben megszűnik a „Work Entries" (munkabejegyzések) logika, amely a gyakorlatban rendszeresen okozott szinkronizációs hibát. A bér ezentúl közvetlenül a Time Off és jelenlét adatokból dolgozik, egy új „Pay Runs" nézetben, háromlépcsős folyamattal.

Emellett érkezik egy Payroll Dashboard, amely azonnal megmutatja, mi blokkolja a bérfuttatást: szerződés nélküli dolgozó, hiányzó bankszámla, hiányzó azonosító, elavult bérlap — akciógombokkal.

Light User szerep

Új felhasználói szint jelenik meg: alap backend-hozzáférés a teljes jogosultságok nélkül, könnyű meghívással az Employee űrlapról, szükség esetén rendes userré léptethetően. Licencköltség-optimalizálás szempontjából ez potenciálisan érdekes — a pontos árazási hatás egyelőre nem publikus.

4. Modulonként, röviden

Könyvelés — „Pay from Odoo": vendor-fizetések kötegelt kiválasztása és egyetlen aláírással történő banki elküldése, vagy SEPA XML generálás. Univerzális kiegyenlítés bármely főkönyvi számlán, automatikus árfolyam-különbözettel. Több partner-azonosító (VAT, cégjegyzékszám, LEI, DUNS) formátum-validációval. Dokumentumonként váltható adóval/adó nélküli ármegjelenítés. Nyilvános lokalizációs referencia weboldal országonkénti számlatükörrel és adókulcsokkal.

Sales — újrahasznosítható szekció-sablonok árajánlatokhoz, UOM ár-szabályok, új promóciós mechanika, hűségpont-lejárat, „Pay on Invoice", újratervezett Sale Order portál, szerkeszthető árrés a rendelési soron.

CRM — natív multi-pipeline kezelés, új Gmail/Outlook plugin-ek, javított automatikus lead-kiosztás.

Inventory — egyszerűsített készletmodell azoknak, akik nem használnak raktár-útvonalakat: egyetlen „On Hand" mennyiség, kézzel frissíthetően. Emellett újratervezett termék- és tételcímkék, jobb putaway szabályok, batch/wave fejlesztések, és barcode-ban szkennelhető, előre kódolt csomagok bejövő áruhoz.

Manufacturing / PLM — új MO Kanban hetekre bontva, kapacitás-terhelési sávokkal és határidő-jelzőkkel; Work Order Kanban munkaállomásonként, egy kattintásos újratervezéssel; PLM ECO Overview riport, amely egy nézetben mutatja minden mérnöki változtatás hatását, beleértve a BOM költség-deltát.

Project & Timesheets — bárhonnan elérhető timer widget, AI időbejegyzés-javaslatok, tényleges vs. tervezett projekt-árrés riportok.

Website & eCommerce — gyorsabb betöltés, microdata (JSON-LD), SEO-javítások, megújult blog UI. Webshop oldalon automatikus cross-sell, önálló katalógus-oldalak, self-service visszáru-kezelés a portálról, új dashboard, promóció-haladásjelző sáv.

Point of Sale — talán a legtöbb megerősített változás itt van. A hardver-setup radikálisan egyszerűsödik: a böngésző local network access API-jával automatikus eszköz-felismerés, tanúsítvány-import és IoT box-súrlódás nélkül (iOS-en a felismerés egyelőre nem támogatott). Új floor plan editor éttermekhez drag-and-drop szerkesztéssel és többféle asztalformával. Automatikus combo-felismerés, kiosk-fejlesztések, kisebb RAM-igény. Új fizetési integrációk: Mollie, M-Pesa, Bancontact/Wero, valamint készpénzgépek (Glory, Cashdro, Cashmatic).

Marketing — vizuális flow builder omnichannel kampányokhoz: Email, SMS, WhatsApp, Activity, Split, Filter, Delay, kupon és AI-lépések egyetlen ágrajzban. Dinamikus levelezőlisták, AI copywriting. Social oldalon Post Stories és ütemezett első hozzászólás.

Phone & Discuss — ez üzletileg alulértékelt újdonság: telefonszám vásárolható közvetlenül az Odoóból 100+ országban, és egy drag-and-drop callflow konfigurátorral építhető fel a teljes hívásirányítás — idő-feltételekkel, sorokkal, ország szerinti routinggal, ünnepnap-naptárakkal. Harmadik fél nélküli telefonrendszer. Emellett szinkronizált, kereshető átirat a hívásfelvételek mellett, a CRM/Helpdesk rekordhoz kötve.

Sign — az aláírás kilép az izolációjából: bármely modulból és háttérfolyamatból automatikusan generálható aláíráskérés. Activity, Activity Plan, workflow-állapotváltás vagy automatizált akció is indíthatja, dinamikus (rekord-mezőhöz kötött) aláírókkal. Aláírt dokumentumból automatikusan frissülhetnek Odoo-mezők.

Spreadsheet — új =ODOO.LIST dinamikus formula, amely élő Odoo-adatot hoz be listaként, oszlop-választással és szűrőkkel, automatikus szinkronnal.

Documents & Knowledge — mappák és cikkek megoszthatók egész csoportoknak, konfigurálható Editor/Viewer joggal.

Appointments & Calendar — több naptár kezelése és szinkronizálása, kollégák naptára, személyes foglalási oldalak, slot-buffering, okos idő-felismerés a megbeszélés címéből, és POS floorplan-integráció konkrét asztal foglalásához.

Mobil — nulláról újratervezett felület, nem a desktop kicsinyítése: kiemelt avatar, egymásra rendezett mezők látható címkékkel, nincs vízszintes görgetés, rendes touch-célpontok. PWA-fejlesztésekkel. Natív offline módról is lehet hallani, de erre hivatalos megerősítés nincs — ezt a keynote-ig érdemes feltételesen kezelni.

5. Új iparági csomagok

Az Odoo tovább csökkenti azt a rést, amit korábban egyedi fejlesztéssel kellett kitölteni. A 20-ban bővül vagy megjelenik: Hotel+ (foglaltság-kezelés, Channex channel manager, revenue management, housekeeping), Construction (work item alapú árajánlat, WBS és alvállalkozó-kezelés, teljesítés-alapú számlázás), Real Estate, Recruitment Firm (CRM → Recruitment → Invoicing integrált folyamattal), Auto Repair Shop, Custom Industrial Equipment, Nursing / Retirement Home, Pet Groomer és Community Care.

6. És a migráció?

Itt van a dolog, amit sok bemutató elhallgat.

Odoo.sh-n vagy saját szerveren futó rendszereknél a 20-as frissítés nagyobb ugrás, mint amilyennek látszik. Az Odoo Online ügyfelek év közben, fokozatosan kapják meg a 19.1 → 19.4 változásokat. Az Odoo.sh és on-premise adatbázisok viszont architekturális okokból csak főverziókat futtatnak — vagyis náluk egy év összes fejlesztése egyetlen csomagban érkezik meg. Ez magyarázza a funkciók volumenét, de ugyanez növeli meg a tesztelési igényt.

A frissítési adósság valós költség. Minél távolabb került egy rendszer a gyári folyamatoktól — egyedi kód, harmadik feles modulok, Studio-módosítások —, annál meredekebben nő a migráció ára. Nem ritka, hogy néhány egyedi modul átvitele megközelíti vagy meghaladja az éves licencdíjat.

Ebből viszont következik egy jó hír is. A 20 sok olyan funkciót olvasztott magába gyárilag, amit korábban egyedi fejlesztéssel oldottunk meg: aláírási automatizmusok, kiterjesztett field service, self-service visszáru portál, POS floorplan, callflow. A legköltséghatékonyabb stratégia gyakran nem a custom kód portolása, hanem a kivezetése és a gyári standardhoz való visszatérés. A migrációt így nem költségként, hanem egyszerűsítési projektként érdemes felfogni.

Ne frissíts éles rendszeren a megjelenés hetében. A korai főverziók instabilak, a harmadik feles és OCA modulok még nem portoltak. A bevált eljárás: amint megjelenik a 20, indíts staging ágat, futtass rajta rendszeresen tesztfrissítést, és validáld, hogy az alappillérek — számlázás, raktározás, pénzügyi kimutatások — hibátlanul működnek. A produkciós átállás jöhet a stabilizálódás után.