A legacy ERP körülbelül 40 előre definiált workflow-sablonnal jön. RMA feldolgozás, drop-ship rendelés, több raktáras transzfer, gyártási ütemezés, inventúra-eltérés zárás — a magyar KKV szektor 2010-es évek elejéig kialakult folyamatait fedik le. A sablonok módosíthatók tenant-szinten (custom lépések, custom jóváhagyók), és túlnyomó többségük tisztán átültethető a modern Admin → Flows motorra.
Mit ad egy sablon
Minden workflow-sablon négy dolgot tartalmaz:
- Lépés-gráf. A folyamat állapotai és az átmenetek (pl. RMA:
received → inspecting → approved → refunded). - Szerep-mapping. Melyik lépés melyik felhasználói szerepkört igényli (raktáros, vezető raktáros, könyvelő).
- Esemény-hook-ok. Melyik lépés-átmenet milyen rendszereseményt vált ki (számlakorrekció, készletmódosulás, e-mail értesítés).
- SLA timer. Lépésenként opcionális — pl. RMA
received → inspectingmax 48 óra, különben eszkaláció.
A legacy ERP-ben a sablonok PHP-osztályok (workflow_*.inc.php), tenant-szintű felülbírálás egy YAML config-fájllal. A modern Admin → Flows engine ugyanezt JSON definíciókban tárolja, és a tenant UI-n szerkeszthető.
A 40-ből 37 tisztán portolható
A migráció során megnéztük mind a 40-et. 37 közvetlenül megy: a lépés-gráfot átírjuk JSON-ra, a szerep-mapping átmegy 1:1, az esemény-hook-ok a modern stack megfelelő API-jaira mutatnak, az SLA timer az új Flows-engine timer-rendszerébe ülnek be. Egy közepes méretű tenantnál ez 2–3 mérnöknap.
A három sablon, ami NEM megy tisztán
1. Magyar EKAER bejelentés workflow. A 2015-ös EKAER szabályozás óta él, és a teljes folyamata a NAV régi WSDL API-jára van kötve, amit a NAV 2024 vége óta nem támogat aktívan. Az új stackben nem építjük újra; a NAV Online Számla 3.0 más műfaj. Aki ezt még használja, ott a legacy ERP-n marad ez a modul, amíg a NAV ki nem kapcsolja a WSDL endpoint-ot. Akkor egy migráció-stop pontot ér el.
2. Kétlépcsős vám-deklaráció. EU-n kívüli (svájci, brit) tételekre van egy egyedi sablon, ami egy harmadik fél (PHP-alapú, 2012-es) vámközvetítő szolgáltatásra integrál. A szolgáltatás API-ja egzotikus (XML-RPC), a klienseink közül csak ketten használják, és mindkettő külön szerződésben kérte, hogy ne mozdítsuk. A modern Flows engine-ben nincs XML-RPC kliens, és a két ügyfél miatt nem építünk be.
3. Munkabér-elszámolás ERP-ből. A legacy ERP-ben a bér-modul integráltan szerepel — a modern stackben szándékosan nem. A bér Magyarországon olyan szabályozási mező, hogy nem akarunk dedikált bér-szoftver szintű felelősséget vállalni érte. A jelenlegi tenantok közül a bért használók a legacy-n maradnak, vagy átállnak Nexon/KulcsBér/Magasház-szerű külső megoldásra.
Mit jelent ez az átállási projektnek
Gyakorlati hatás: a workflow-migráció a sprint plan-ben általában a 4–6. hetére esik, és átlag 4–7 mérnöknapot vesz fel egy 12–25 fős tenantnál. A három nem-portolható sablon valamelyikének használata nem blokkolja a migrációt — egyszerűen a legacy ERP fennmarad ezekre a folyamatokra, API-only módon, és az új stack a többit veszi át.
Egy retorikai kérdés
Miért nem építjük újra a három problémás sablont? Mert nem ér meg annyit. A NAV WSDL kifutó, a vám-XML-RPC két ügyfeles, a bér saját szakma. A modern Netorigo stack erőforrásai a 37 sablonnál és a saját, új workflow-knál termelnek értéket — nem ott, ahol a piaci visszahúzódás amúgy is megoldja a problémát.
A workflow-rétege egy ERP-nek mindig az utolsó, ami migrálódik, mert ez tartalmazza a legtöbb tenant-specifikus tudást. A sablon-alapú megközelítés azért működik, mert nagy részben standardizál — a tenant-egyediségek pedig a felülbírálásban koncentrálódnak.