A számla már a Business Centralban van. Miért dolgozunk vele még egyszer?
2026-10-06
Ugyanazon a gépen, amelyen délután még űrhajókat lőttünk, délelőtt akár készletet is lehetett nyilvántartani. A Commodore 64 üzleti felhasználása ma mosolyt csalhat az arcunkra, pedig komoly problémára adott választ: hogyan lehet kevesebb kézi munkával rendben tartani egy vállalkozás adatait? A kérdés azóta is velünk van. Csak közben a floppylemeztől eljutottunk az összekapcsolt, felhőben is működő vállalatirányításig.
1. Amikor a joystick mellé nyilvántartás is jutott
A Commodore 64-ről sokaknak a játékok, a kék képernyő és a betöltésre várakozás jut eszébe. Egy raktárkészlet vagy főkönyvi kivonat valószínűleg jóval hátrébb szerepel az emlékek között.
Pedig a gépnek volt ilyen élete is.
A Timeworks Business Systems sorozata C64-en készletkezelést, értékesítési elemzést, vevő- és szállítónyilvántartást, számlázást, bérszámfejtést és főkönyvi feladatokat kínált. A COMPUTE! magazin 1988. májusi vásárlási útmutatója szerint a programokat egymással is össze lehetett kapcsolni. A sorozat tagjai darabonként 49,95 dollárért szerepeltek a kínálatban.
Vagyis már egy olyan gépen is megjelent az ügyviteli funkciók összekapcsolásának igénye, amelyet ma leginkább a nappaliban álló tévé előtt képzelünk el.
Magyar példa is akad. A Neumann Társaság Informatikatörténeti Adattára szerint a Fővárosi Építőipari Üzemgazdasági és Ügyviteltechnikai Iroda, a FÜTI 1987-ben KIÜGYES néven költségvetés-készítő programot adott ki Commodore 64/128-ra. Építőipari költségvetést tehát ugyanazon a gépcsaládon is lehetett készíteni, amelyhez mások a következő játékot keresték.
A C64 hazai elterjedésében a Novotrade is szerepet játszott: gépek kerültek munkahelyekre, iskolákba és otthonokba. A magyar Commodore-történet ezért a szórakozás mellett a munkáról és a tanulásról is szól.
Az ügyviteli számítástechnika persze jóval korábban elkezdődött, nagyobb számítógépeken. A C64 ebben a történetben az a pont, ahol egy ismerős, személyes méretű gép is belépett az irodába.
2. Hatvannégy kilobájtban is elfért egy üzleti probléma
Az 1982-ben megjelent C64 alapkiépítésben 64 kilobájt RAM-mal, nagyjából 1 MHz-es processzorral és 40 oszlopos, 25 soros szöveges képernyővel dolgozott. A program és az éppen kezelt adatok a szűk memórián osztoztak; a tartós tároláshoz külső eszköz kellett.
Egy széles táblázat megjelenítése ilyen képernyőn már önmagában tervezési feladat volt. A fejlesztőnek el kellett döntenie, mely mezők férjenek el egyszerre, mit rövidítsen, és mit mutasson külön oldalon.
A memóriakorlát az adatok kezelésére is hatott. Nem lehetett természetesnek venni, hogy minden adat mindig a memóriában várja a következő műveletet. Egy lemezes alkalmazásnál az adatszerkezet, a keresés módja és a lemezműveletek száma nagyon is számított.
Képzeljünk el egy kereskedést: eladtunk tíz darab terméket.
Egy egyszerű készletnyilvántartóban rögzítjük a kiadást, módosul a mennyiség, majd elmentjük az adatokat. Már ez is sokat ér: kevesebb kézi számolás, könnyebben előkereshető tételek, rendezettebb lista.
De az eladásnak további következményei vannak. Számla készül. A vevő tartozik. Bevétel keletkezik. Felmerül a kérdés, hogy mennyi volt az eladott áru költsége, és kell-e újabb készletet rendelni.
A tíz darab ugyanaz maradt. A körülötte lévő feladat kezdett nagyra nőni.
3. A PC több helyet adott – és újabb feladatokat hozott
A PC-k, a merevlemezek és a nagyobb memóriák terjedésével egyre több adatot lehetett kezelni, gyorsabban és kényelmesebben. A DOS-os ügyviteli programok világában a billentyűzetes menük és a karakteres képernyők továbbra is otthonosak maradtak, de a kapacitás már más lehetőségeket kínált.
Gyakori megoldás volt a fájlokban tárolt nyilvántartás, például a dBASE és a hozzá hasonló adatkezelési környezetek használata. A vállalkozás saját igényeire készített programban külön állományba kerülhettek a vevők, a termékek és a bizonylatok.
A fejlődés azonban nem minden cégnél jelentett azonnali összekapcsolódást.
Lehetett egy jó számlázó, egy jó raktárprogram és egy jó könyvelési rendszer. Ha nem cseréltek megfelelően adatot, az embernek kellett összekötnie őket: kinyomtatott listával, újabb adatbevitellel vagy állományok másolásával.
A példánk tíz terméke így több helyen is megjelent. És minden újabb kézi rögzítés újabb alkalmat adott egy elírásra.
A számítógép gyorsult. Az adat útja ettől még maradhatott hosszú.
4. Mi történik, ha ketten ugyanazt a készletet látják?
Egyetlen felhasználónál viszonylag egyszerű eldönteni, ki módosítja az adatot: az, aki éppen a gépnél ül.
Több munkaállomásnál már érdekesebb a helyzet.
Tegyük fel, hogy tíz darab van készleten. Két munkatárs egyszerre olvassa ezt az adatot. Az egyik hat darab eladását rögzíti, a másik ötét. Ha mindketten a korábban látott mennyiségből számolnak, és ellenőrzés nélkül felülírják az eredményt, az egyik módosítás elveszhet. A nyilvántartás négy vagy öt darabot mutathat, miközben összesen tizenegyet adtak el.
Ennek kezeléséhez összehangolt adatbázis-műveletek kellenek. A zárolás vagy más konkurenciakezelési megoldás segít megakadályozni, hogy az egyidejű módosítások észrevétlenül felülírják egymást.
A tranzakciókezelés pedig összetartozó változtatásokat fog össze. Ha egy művelethez több adat módosítása szükséges, meghatározható, hogy ezek együtt váljanak véglegessé, vagy hiba esetén visszagördüljenek.
A felhasználó ebből gyakran csak egy rövid várakozást vagy hibaüzenetet lát. A háttérben viszont a rendszer az adatok következetességét védi.
Azt, hogy szabad-e készleten felül értékesíteni, már az üzleti szabályok döntik el. Az adatbázis önmagában nem tudja, hogy a raktár ajtaján éppen beérkezett-e egy új szállítmány.
5. Amikor a raktár és a könyvelés közös történetet kezdett írni
A hálózat lehetővé teszi a közös adat elérését. Az integrált vállalatirányítás ennél tovább megy: összekapcsolja az üzleti események következményeit is.
Az ERP – vállalati erőforrás-tervezési, a gyakorlatban vállalatirányítási rendszer – szemléletében az értékesítés, a beszerzés, a készlet és a pénzügy egymásra épülő folyamatok.
Visszatérve a tíz termékhez: a rendszernek ismernie kell a vevőt, a cikket, az árat és a megfelelő könyvelési beállításokat. A kiszállítás és a számlázás kapcsolódik egymáshoz, miközben akár eltérő időpontban is történhet.
A Business Centralban például egy cikket tartalmazó rendelés kiszállításának és számlázásának könyvelése a megfelelő cikk-, vevő- és főkönyvi tételeket hozza létre. A kiszállítás és a számlázás együtt vagy külön is elvégezhető.
Így az eladás több nézőpontból vizsgálható, egymáshoz kapcsolódó adatok alapján. Az értékesítő a vevőt és a rendelést látja, a raktáros a kiadást, a pénzügy pedig a követelést és a könyvelési tételeket.
Ehhez jó törzsadatok és helyes beállítások kellenek. Egy rossz cikkszám vagy könyvelési kapcsolat integrált környezetben is problémát okoz – csak éppen több folyamatra hat.
6. Navision, Dynamics NAV, Business Central: itt már valódi a rokonság
A C64-es ügyviteli programok és a Business Central között nincs közvetlen termékcsaládi leszármazás. A közös szál az üzleti igény: adatokból használható nyilvántartást, majd összehangolt működést kialakítani.
A Navision, a Microsoft Dynamics NAV és a Business Central esetében viszont valódi terméktörténeti kapcsolatról beszélhetünk.
A Microsoft 2002-ben vásárolta fel a Navisiont. A termékcsalád később Microsoft Dynamics NAV néven vált ismertté, majd a Microsoft 2018. április 2-án elindította a Dynamics 365 Business Central felhőszolgáltatást. A bejelentés kifejezetten a Dynamics NAV technológiai és funkcionális alapjaira épülő megoldásként mutatta be az új szolgáltatást.
Ez azért lényeges, mert a Business Central mögött hosszú ideje fejlődő ügyviteli logika áll.
Közben a használat és az üzemeltetés is változott: más lett, hogyan férünk hozzá a rendszerhez, hogyan bővítjük, és hogyan kapcsoljuk össze a vállalkozás többi eszközével.
7. A felhő és az API: a program kilép az iroda falai közül
A felhős működés megváltoztatja az üzemeltetés felelősségeit. A Business Central online változatánál az infrastruktúra és a szolgáltatás frissítéseinek kezelése jelentős részben a szolgáltatóhoz kerül. A vállalkozásnak ettől még foglalkoznia kell a jogosultságokkal, az adatokkal és a saját megoldásainak működésével.
A böngészős felület pedig megkönnyíti, hogy az ügyviteli rendszer a munkahelyi számítógépen túl is elérhető legyen.
Legalább ilyen fontos változás az API, vagyis a programok közötti adatcserét lehetővé tevő interfész. A Microsoft a REST API-kat ajánlja a Business Central külső rendszerekkel történő integrálására; beépített és egyedileg fejlesztett API-k is használhatók.
A tíz termék megrendelése így akár egy webáruházból is érkezhet. Megfelelő integrációval az adatok bekerülhetnek az ügyviteli rendszerbe, és később a készletinformáció is visszajuthat a webáruházhoz.
Ez komoly tervezést igényel. Mi történik, ha megszakad a kapcsolat? Hogyan akadályozzuk meg, hogy ugyanaz a rendelés kétszer kerüljön be? Ki kap értesítést, ha az adatátadás hibás?
A floppy helyét átveheti az API, de a hibakezelés továbbra is mérnöki feladat.
8. Egyedi igények: hogyan fejlesszünk úgy, hogy később is működjön?
A vállalkozások ritkán működnek teljesen egyformán. Egy szálloda, egy nagykereskedő és egy szolgáltató eltérő folyamatokat, mezőket és ellenőrzéseket kérhet ugyanattól az ERP-től.
A Business Centralban az AL nyelven fejlesztett bővítmények többek között táblákat, képernyőket és riportokat egészíthetnek ki. A fejlesztők eseményekhez kapcsolódó saját logikával is bővíthetik a működést.
Ez lehetőséget ad arra, hogy az egyedi igényekhez készített megoldás elkülönüljön az alapalkalmazástól. Egy későbbi frissítésnél ettől még szükség van kompatibilitási ellenőrzésre és tesztelésre.
A fontos kérdés tehát már a fejlesztés elején megjelenik: hogyan lesz az új funkció karbantartható, és hogyan illeszkedik majd a rendszer következő változatához?
A C64-es programnál a szűk memória volt látványos korlát. Egy mai ERP-fejlesztésnél gyakran a kapcsolatok, a függőségek és a hosszú távú működtethetőség jelentik a nehezebb feladatot.
9. A tíz darab termék maradt. A körülötte lévő munka változott meg.
A fejlődés során a számítógép először egy-egy nyilvántartási feladatban segített. Később több ember közös munkáját tette lehetővé, összekapcsolta az üzleti folyamatokat, majd más rendszerekkel is adatot kezdett cserélni.
Ezek a lépések átfedik egymást. Egyszerű programok ma is hasznosak lehetnek, összetett vállalati rendszerek pedig már a mikrogépek előtt is léteztek. Egy adott vállalkozásnak mindig a saját működéséhez megfelelő megoldást kell megtalálnia.
A legjobb kérdés ezért ma is nagyon konkrét:
Egy termék eladásához hány helyen kell adatot rögzíteni, hány ellenőrzést kell kézzel elvégezni, és hányszor kell valakinek megkérdeznie egy kollégát?
A válasz sokkal többet mond egy rendszer hasznosságáról, mint a képernyőjének szépsége.
A Loginformnál a Business Central bevezetését és fejlesztését ezekből a napi feladatokból kiindulva érdemes megtervezni. Hol várakozik az adat? Hol ismétlődik a munka? Melyik ellenőrzést végezhetné el a rendszer?
Ha ezekre jó választ adunk, a technikai fejlődés a munkanapban is érezhető lesz.
A floppy címkéjére ez is ráfért volna.
Források és további olvasnivaló
Magyar vonatkozások:
- Neumann Társaság, Informatikatörténeti Adattár – FÜTI: a KIÜGYES költségvetés-készítő program.
- Neumann Társaság, Informatikatörténeti Adattár – Novotrade Rt.: magyarországi gépforgalmazás és szoftverfejlesztés.
- A jövő múltja – Commodore 64: gépbemutató és technikai adatok.
Korabeli programok és a technikai fejlődés:
- COMPUTE!, 1988. május – Buyer’s Guide: a Timeworks C64-es ügyviteli programjai.
- Microsoft Learn – Transaction locking and row versioning guide: párhuzamos adatkezelés és tranzakciók.
- Microsoft – Microsoft Acquires Navision, 2002.
- Microsoft – Dynamics 365 Business Central is now live!, 2018.
Business Central:
