A Business Central legnagyobb ereje nem az, amit dobozból kapsz — hanem az, hogy pontosan a cége folyamataira szabható anélkül, hogy elveszítené a jövőbeli frissíthetőséget.

Sok cégvezető úgy gondol egy ERP-rendszerre, mint egy dobozos szoftverre, amit vagy elfogad az ember úgy, ahogy van, vagy másikra vált. A Business Central testreszabása kapcsán ez a kép félrevezető: a Microsoft Dynamics 365 Business Central kifejezetten úgy épült fel, hogy a beállítási lehetőségeken túl valódi, kódszintű testreszabást is lehessen rá építeni — anélkül, hogy ez veszélyeztetné a jövőbeli frissítéseket.

A kérdés a legtöbb KKV-nál nem az, hogy „lehet-e” testreszabni a Business Centralt, hanem hogy „érdemes-e” — és ha igen, hol húzódik a határ a gyors, olcsó konfiguráció és a hosszabb, komolyabb fejlesztési munka között. Ez az útmutató ezt a határvonalat próbálja tisztázni, a saját tapasztalatunk alapján.

Testreszabás vs. konfiguráció: mi a különbség?

Konfiguráció: a rendszerben már eleve benne lévő beállítási lehetőségek bekapcsolása és paraméterezése — számlázási sablonok, jóváhagyási limitek, jogosultsági szerepkörök, számsorok, dimenziók. Ehhez nem kell fejlesztő, gyors és kockázatmentes.

Testreszabás: amikor a szabvány funkció nem fedi le az igényt, és tényleges AL-kód (a Business Central saját fejlesztői nyelve) írására van szükség — ez lehet egy kiegészítő mező, egy egyedi riport, egy automatizált folyamat vagy egy külső rendszerrel való integráció.

Milyen jelek mutatják, hogy egyedi fejlesztésre van szükséged?

• Excel-mentőöv: bizonyos folyamatokat még mindig Excelben old meg valaki, mert a rendszer „nem tudja” — ez tipikusan hiányzó funkció jele.
• Iparág-specifikus folyamat: például gyártásban egy egyedi anyagszükséglet-számítás, kereskedelemben egy sajátos árazási logika, ami nem illik egyik standard modulba sem.
• Rendszerek közötti szakadék: egy webshop, egy gyártásirányítási rendszer vagy egy régi, még élő alkalmazás adatai manuálisan vándorolnak át — az integráció hiánya.
• Egyedi jóváhagyási vagy dokumentum-folyamat: a cég belső szabályzata bonyolultabb jóváhagyási láncot vagy dokumentum-generálást igényel, mint amit a standard workflow-modul kínál.
• Magyar szabályozási igény, ami nincs lefedve: olyan hazai előírás vagy jelentési kötelezettség, amit a globális szabvány build alapból nem kezel.
• Ismétlődő, manuális adminisztráció: ha egy kollégának minden hónapban ugyanazt a több lépéses, unalmas feladatot kell elvégeznie, az szinte mindig automatizálható.

Tipikus testreszabási példák a gyakorlatból

A testreszabási igények cégenként nagyon eltérőek, de van néhány visszatérő típus, amivel rendszeresen találkozunk:

• Egyedi mezők és nyomtatványok: extra adatmezők egy törzsadaton vagy bizonylaton, saját arculatú számla- vagy szállítólevél-sablon.
• Integrációk: webshop-rendszerek, NAV Online Számla, bankkapcsolat, gyártásirányítási vagy raktárkezelő (WMS) rendszerek összekötése a Business Centrallal.
• Egyedi riportok és dashboardok: vezetői kimutatások, amelyek több modul adatát kombinálják egyetlen nézetben.
• Automatizált jóváhagyási és értesítési folyamatok: Power Automate- vagy AL-alapú workflow-k, amelyek kiváltják a manuális e-mailezést.
• Iparág-specifikus modulok: például gyártási sorozatszám-követés, projektalapú elszámolás vagy bérleti/szolgáltatási ütemezés.

Hogyan zajlik a testreszabási folyamat a JADE-nél?

1. Igényfelmérés és megvalósíthatósági vizsgálat: feltérképezzük a jelenlegi folyamatot, és megnézzük, mennyire fedi le egy meglévő, kész AppSource-kiegészítő vagy egy standard beállítás — sokszor kiderül, hogy egyáltalán nem kell egyedi fejlesztés.
2. Specifikáció és ajánlat: pontosan leírjuk, mit fog csinálni a fejlesztés, mennyi idő és mennyi költség alatt, hogy ne legyen menet közbeni meglepetés.
3. Fejlesztés extension-ként, nem a core kód módosításával: ez a legfontosabb technikai elv — bővebben lásd lentebb.
4. Tesztelés éles adatok másolatán: a fejlesztést egy elkülönített teszt-környezetben próbáljuk ki, mielőtt bármi élesbe kerülne.
5. Éles telepítés és betanítás: a bevezetés után rövid oktatást tartunk az érintett kollégáknak.
6. Dokumentáció és utókövetés: minden testreszabást dokumentálunk, hogy egy jövőbeli frissítés vagy csapatváltás ne okozzon meglepetést.

A legfontosabb buktató: sose nyúlj a core kódhoz

A régi Dynamics NAV-világban a testreszabás gyakran azt jelentette, hogy valaki közvetlenül belenyúlt az alaprendszer forráskódjába. Ez rövid távon működött, de hosszú távon komoly problémát okozott: minden frissítés vagy verzióváltás során a módosításokat kézzel kellett újra „összefésülni” az új kóddal — pontosan ez az a fájdalom, amit a régi NAV/Navision-rendszerek Business Centralra migrálása kapcsán a legtöbb ügyfelünktől hallunk.

A Business Central ezt a problémát az extension-alapú fejlesztési modellel oldja meg: minden testreszabás egy különálló, a core kódtól elválasztott „kiegészítő csomagként” épül be a rendszerbe. Egy Microsoft-frissítés így nem írja felül és nem töri el a testreszabásokat — a kettő egymástól függetlenül frissül. Amikor testreszabást kér valakitől, mindig érdemes rákérdezni, hogy az extension-alapú modellt követi-e; ha valaki a core kód módosítását javasolja, az hosszú távon ugyanabba a zsákutcába vezet, mint a régi NAV-testreszabások.

Mennyibe kerül és mennyi idő alatt készül el egy testreszabás?

Nincs egyetlen érvényes válasz, mert a tartomány nagyon széles: egy egyszerű egyedi mező vagy nyomtatvány néhány nap alatt elkészül, míg egy komplexebb integráció vagy egy teljes egyedi modul heteket vehet igénybe. A költséget alapvetően három tényező határozza meg: hány objektumot (tábla, oldal, riport, kódegység) érint a fejlesztés, van-e külső rendszerrel való integráció, és mennyi tesztelést igényel a folyamat kritikussága miatt. Ezért kezdjük mindig alapos igényfelméréssel és konkrét ajánlattal, mielőtt bármi elindulna — így elkerülhető, hogy menet közben derüljön ki a valós költség és határidő.

Gyakran ismételt kérdések

Gondolkodik egyedi fejlesztésen?

Ha úgy érzi, hogy a jelenlegi Business Central-beállítás már nem követi a cége valós folyamatait, érdemes egy rövid, kötelezettség nélküli egyeztetéssel kezdeni — együtt eldöntjük, hogy tényleg fejlesztésre van-e szükség, vagy egy egyszerűbb beállítással is megoldható a probléma.