Dolibarr workflow: megrajzolható az automatizálás?
Mi lenne, ha megrajzolhatnánk a Dolibarr munkafolyamatait?
Vizuális folyamatépítés a Dolibarrban: közösségi ötlet, beépített Workflow modul és egy gyakorlati példa arra, mit érdemes automatizálni.
Az ügyfél elfogadta az ajánlatot. Valakinek rendelést kell készítenie, valakinek ellenőriznie kell a vállalt határidőt, és jó lenne, ha minderről a megfelelő kolléga is értesülne. Mi lenne, ha ezt a folyamatot egymáshoz kapcsolt elemekből lehetne megrajzolni a Dolibarrban?
Egy közösségi ötlet, amely továbbgondolásra érdemes
A Dolibarr nemzetközi fórumán 2025. október 10-én rycks egy készülő, no-code munkafolyamat-szerkesztőt mutatott be. A rövid bejelentés a Scratch mögötti eszközökre épülő vizuális szerkesztést említi, és egy capdolirun című bemutatóra hivatkozik. Az eredeti fórumbejegyzés alapján ez közösségi fejlesztési kezdeményezés; a bejelentés önmagában nem igazolja a jelenlegi készültséget vagy a saját Dolibarr-verziónkkal való kompatibilitást.
A téma azért izgalmas, mert egy látható folyamatábra közös nyelvet adhat az üzleti munkatársnak és a fejlesztőnek. Egy „ha ez történt, akkor ez következzen” szabályon könnyebb együtt gondolkodni, ha mindenki ugyanazokat a döntési pontokat látja. Ez a cikk az ötlet gyakorlati lehetőségeit járja körül, nem friss kiadásról szóló hír.
A Dolibarrban már van beépített Workflow modul
A hivatalos Workflow-dokumentáció szerint a Dolibarr része egy modul, amely üzleti objektumok automatikus létrehozását kapcsolhatja össze. A leírás példája: az aláírtként lezárt ajánlatból automatikusan rendelés készülhet. A modult adminisztrátorként kell aktiválni, az elérhető kapcsolatok pedig a bekapcsolt moduloktól függenek.
A dokumentált alapmodul és a fórumban bemutatott vizuális szerkesztő két külön dolog. A hivatalos leírásból nem következik, hogy minden telepítésen rendelkezésre áll egy szabadon rajzolható, tetszőleges üzleti szabályokat kezelő felület. Első lépésként ezért a saját rendszer Workflow-beállításait érdemes megvizsgálni: lehet, hogy a kívánt egyszerű kapcsolat már ott elérhető.
Egy ajánlat útja: mit rajzolnánk fel?
Vegyünk egy kitalált nagykereskedelmi példát. Az alábbi folyamat saját tervezési javaslat, nem a közösségi szerkesztő ellenőrzött funkciólistája.
- Esemény: az ügyfél elfogadta az ajánlatot, és a munkatárs rögzítette az ennek megfelelő állapotot.
- Ellenőrzés: tartozik már rendelés ehhez az ajánlathoz? Ha igen, azt kell megnyitni, nem még egyet létrehozni.
- Művelet: ha nincs kapcsolódó rendelés, készüljön egy, az előre tisztázott adatokkal és kezdőállapottal.
- Emberi döntés: a felelős ellenőrizze a teljesíthetőséget és a szállítási határidőt.
- Visszajelzés: legyen látható, hogy a folyamat sikerült, megállt egy döntésnél, vagy javításra vár.
Ez a rajz már a fejlesztés előtt felvet egy hasznos kérdést: a rendelés elkészítése és a szállítás megígérése ugyanaz a döntés? A példában külön lépések. A virtuális készletről szóló cikkünk megmutatja, miért érdemes a teljesíthetőséget önállóan vizsgálni.
A legérdekesebb nyíl az, amely visszafelé mutat
A bemutatókon általában minden elsőre sikerül. A napi munkában viszont az ügyfél módosít, a kolléga kétszer kattint, vagy egy kapcsolat megszakad. Éppen ezért a folyamatábra értékét az is adja, hogy meg lehet rajzolni rajta a kivételek útját.
Mi történjen, ha az ajánlatot újra megnyitják? Ki kapjon feladatot, ha hiányzik egy szükséges adat? Honnan tudjuk, hogy az értesítés ment ki kétszer, vagy maga a rendelés jött létre kétszer? Ezekre a kérdésekre a vizuális felület önmagában nem válaszol. A szabályokat a csapatnak kell meghatároznia, a megvalósításban pedig ellenőrizhetővé tenni.
Az ismétlés kezelése különösen jó próba: ugyanazt az eseményt kétszer feldolgozva is csak a szándékolt üzleti eredmény szülessen. Egy már elkészült rendelés felismerése például hasznosabb lehet, mint egy újabb értesítés arról, hogy ismét lefutott az automatizmus.
Öt próba, mielőtt rábízzuk a napi munkát
- Normál eset: egy elfogadott ajánlatból a megfelelő ügyfélhez, megfelelő tételekkel jön létre a kívánt rendelés.
- Ismételt esemény: a második feldolgozás után sem keletkezik indokolatlan másolat.
- Hiányzó adat: a munkatárs érthetően látja, miért állt meg a folyamat és mit kell pótolnia.
- Megváltozott üzleti helyzet: az ajánlat módosítása után egyértelmű, mely adatot kell újra ellenőrizni.
- Felelősség: a csapat tudja, kihez tartozik az elakadás, és ki folytathatja a munkát.
A próba során mérjük az újragépelések számát, az ajánlat elfogadásától a rendelés elkészüléséig eltelt időt és a kézi beavatkozások okát. Ezek saját mérési szempontok: nem ígért megtakarítások és nem egy modul teljesítményadatai.
Először egyetlen kapcsolatot tegyünk rendbe
Jó kiindulópont egy lapra felírni: „Amikor ez történik, ezekkel a feltételekkel ez legyen a következő lépés.” Ezután a saját Dolibarr tesztkörnyezetében megvizsgálható, mennyit old meg a beépített Workflow modul, és hol lenne szükség kiegészítőre vagy fejlesztésre.
A vizuális szerkesztő ötletének legnagyobb hozadéka talán már a bevezetés előtt megjelenik: a csapat kénytelen pontosan megfogalmazni, hogyan dolgozik. Az automatizálás így egy közösen érthető szabály végrehajtása lesz. További gondolatokhoz olvassa el az ERP-okosítás sorrendjéről szóló útmutatónkat.
Források
- Dolibarr fórum: Nocode workflow editor for dolibarr :) – a közösségi fejlesztés eredeti, 2025. október 10-i bejelentése.
- Dolibarr Wiki: Module Workflow – a beépített modul rendeltetése, aktiválása és függése az aktív moduloktól.
Forrásellenőrzés: 2026. október 1. A nagykereskedelmi példa, a folyamatjavaslat és a tesztszempontok a szerkesztőség saját gondolatai.
Címkék: Dolibarr · workflow · no-code · automatizálás · folyamatfejlesztés
Nézze meg, milyen Dolibarr-folyamat illeszkedhet a vállalkozásához, vagy küldje el röviden a saját helyzetét.
Ez a Dolibarr.hu szerkesztett, magyar nyelvű útmutatója.