SAP Business One és
benzinkúti rendszer
integrációja
Pázmány Péter Katolikus Egyetem
Információs Technológiai Kar
Elektronikus kereskedelem szakirányú továbbképzés
Buzsáky Andrea
Témavezető: Hernádi Bálint
Budapest, 2013.
Nyilatkozat 2
Nyilatkozat
Alulírott Buzsáky Andrea, a Pázmány Péter Katolikus Egyetem Információs Technológiai
Kara Szakirányú Továbbképzésének hallgatója kijelentem, hogy ezt a diplomatervet meg nem
engedett segítség nélkül, saját magam készítettem, és a diplomamunkában csak a megadott
forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de
átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a
diplomamunkát más szakon még nem nyújtottam be.
.......................................................................
Buzsáky Andrea
Tartalomjegyzék 3
Tartalomjegyzék
Nyilatkozat ................................................................................................................................. 2
Tartalomjegyzék ......................................................................................................................... 3
Tartalmi összefoglaló ................................................................................................................. 5
Abstract ...................................................................................................................................... 6
Bevezetés .................................................................................................................................... 7
1. Integrált vállalatirányítási rendszerek ................................................................................. 8
1.1. Az ERP kialakulása .................................................................................................... 8
1.1. ERP bevezetése ........................................................................................................ 11
2. SAP Business One ............................................................................................................ 13
2.1. SAP Business One .................................................................................................... 13
2.1.1. Lekérdezések .................................................................................................... 17
2.1.2. Rendszerinformációk ........................................................................................ 18
2.1.1. Felhasználói mezők, felhasználói táblák .......................................................... 20
2.2. Addonok ................................................................................................................... 21
2.2.1. Microsoft SQL Server 2008 R2 Management Studio ....................................... 22
2.2.2. SDK .................................................................................................................. 23
2.2.3. Fejlesztői környezet .......................................................................................... 24
3. Üzemgazdasági háttér ....................................................................................................... 25
3.1. Cikktörzs, készletgazdálkodás .................................................................................. 25
3.1.1. Raktárak ............................................................................................................ 26
3.2. Partnertörzs ............................................................................................................... 26
3.2.1. Speciális partnerek ............................................................................................ 27
3.2.2. Partnerszinkron ................................................................................................. 27
3.3. Árak, árlisták, kedvezmények .................................................................................. 28
3.4. Jövedéki adó ............................................................................................................. 29
3.5. Bizonylatok ............................................................................................................... 30
3.5.1. Készletgazdálkodás .......................................................................................... 30
3.5.2. Gyártás .............................................................................................................. 32
Tartalomjegyzék 4
3.5.3. Beszerzés .......................................................................................................... 32
3.5.4. Értékesítés ......................................................................................................... 34
4. SBO és benzinkúti rendszer integrációja .......................................................................... 38
4.1. Interfész konfiguráció ............................................................................................... 38
4.1.1. Kutak definíciói ................................................................................................ 38
4.1.2. Csomagok ......................................................................................................... 38
4.1.3. Fizetési mód kódok ........................................................................................... 39
4.1.4. Időzített árszinkron ........................................................................................... 39
4.1.5. Speciális üzleti partnerek .................................................................................. 39
4.1.6. Paraméterek ...................................................................................................... 40
4.2. Fájlkezelés ................................................................................................................ 40
4.2.1. Bejövő fájlok .................................................................................................... 40
4.2.2. Adatok írása ...................................................................................................... 41
4.3. Szinkronizálandó adatok........................................................................................... 41
4.3.1. Kimenő adatok .................................................................................................. 41
5. További fejlesztési tervek ................................................................................................. 43
Összefoglalás ............................................................................................................................ 44
Köszönetnyilvánítás ................................................................................................................. 45
Irodalomjegyzék ....................................................................................................................... 46
Tartalmi összefoglaló 5
Tartalmi összefoglaló
Az informatika egyre fontosabb szerepet kap mind a mindennapjainkban, mind pedig az üzleti
életben. Ma már szinte el se tudjuk képzelni, milyen lehetett az élet nélküle – sőt, ha elutazunk
pár napra, szinte pánikba esünk, hogy nem tudunk kapcsolatot tartani elektronikus
„barátainkkal”, hazatérve pedig első dolgunk az olvasatlan leveleink (melyekből alig három
nap alatt is összegyűlt vagy száz) elolvasása.
Az üzleti életben még fontosabb az állandó naprakészség. Vállalatunkat folyamatosan
ellenőrizni kell, figyelni a piac minden egyes rezdülését, hogy versenyképesek tudjunk
maradni. Ehhez jól kell ismernünk a saját vállalatunkat, amiben nagy segítséget nyújtanak az
integrált vállalatirányítási rendszerek. Ezek a rendszerek lefedik a vállalat irányításának szinte
valamennyi területét, és lehetővé teszik további modulok beillesztését is.
Diplomamunkámban egy ilyen rendszer, egy SAP Business One bevezetéséről fogok írni. A
bevezetés nehézsége abból fakadt, hogy az SAP-nak az ügyfél benzinkútjain használt
WinPetrol rendszerrel együtt kell működnie. Ennek az integrációnak a logikáját, folyamatait
ismertetem.
Abstract 6
Abstract
Information technology is getting a more important role both in our everyday lives and in the
business. We can hardly imagine, how people could live without it – we can hardly manage
those few days on holidays, when we can’t be in contact with our electronic “friends”, and as
we get back home, our first task is reading our unread mails (almost a hundred of them, and
we were away only for three days).
In the business life, being always up-to-date is even more vital. We always must control our
company, monitor every breath of the market to be successful – or at least survive. For this we
need to know the state of our company well, and this is where the enterprise resource planning
(ERP) systems can help us. These systems cover almost every part of the enterprise
management, and allow us to integrate additional modules.
In my thesis I present the installation of an ERP system, the SAP Business One. The difficulty
in this project was that the SAP has to cooperate with the WinPetrol system operating on the
gas stations of the partner. In this thesis I present the logic and processes of this integration.
Bevezetés 7
Bevezetés
Az informatika a kezdetektől fogva jelen van az üzleti életben, mára szinte nélkülözhetetlenné
vált. A gyorsan változó piacon azonnal reagálnunk kell az eseményekre, hogy vállalatunk
versenyképes maradjon. Pillanatok alatt, a semmiből jelennek meg új vállalatok, és ugyanilyen
gyorsan tűnhetnek el a süllyesztőben, és senki nem emlékszik rájuk többet.
A gyors reakcióhoz, megalapozott döntésekhez nyújtanak segítséget az integrált
vállalatirányítási rendszerek (angolul ERP, Enterprise Resource Planning). Az ERP rendszerek
moduláris felépítésű szoftverrendszerek, melyek lehetővé teszik további modulok
integrációját, és akár külső, idegen szoftverekkel is képesek együttműködni.
Egy ERP rendszer a német SAP AG. által kis- és középvállalkozások számára kínált SAP
Business One, mellyel szakdolgozatomban én is foglalkozom.
A T-Systems Magyarország Zrt. ERP ágazatának SAP Business One-nal foglalkozó
csapatának fejlesztő gyakornokaként volt alkalmam részt venni SAP Business One
bevezetésekben, és a már bevezetett rendszerek üzemeltetésében.
A szakdolgozatomban leírt megoldás az ügyfél benzinkútjain működő WinPetrol üzemanyag-
kereskedelmi rendszer és az SAP Business One együttműködését teszi lehetővé. Ahhoz
azonban, hogy ezt megértsük, távolabbról kell indulni: az első fejezetekben ismertetem az
ERP rendszerek kialakulását, sajátosságait, valamint az SAP Business One-t. Mivel
fejlesztésről van szó, fontosnak láttam ismertetni néhány olyan eszközt, melyek a
fejlesztéseket segítik. Ezek után következik az üzemgazdasági háttér ismertetése, majd
magának a szinkronizációnak a folyamata.
Integrált vállalatirányítási rendszerek 8
1. Integrált vállalatirányítási rendszerek
Az integrált vállalatirányítási rendszerek feladata egy vállalat napi, rövid- és középtávú
fennmaradásához szükséges erőforrás-tervezése. Angol megnevezése is erre utal: Enterprise
Resource Planning, vagyis vállalati erőforrás-tervezés (ERP). Az erőforrás lehet emberi,
pénzügyi, vagy akár technikai erőforrás is, melyre szükség van a vállalat fennmaradásához.
Napjainkban az információ is az, sőt, a legértékesebb erőforrások egyike.
Egy ERP rendszer nem egyetlen szoftver, hanem egy több részből álló szoftvercsomag,
melynek egyes moduljai egymásra épülnek, kommunikálnak, és, ami az egyik legfontosabb
előrelépés volt a különálló rendszerek után: ugyanazokat az adatokat használják, tehát a
rendszer egy adatbázisra épül. Vagyis nincs többszörös adatbevitel, nincs ebből származó
duplikáció, ami inkonzisztens adatokat eredményezhet. Ezáltal javul az adatminőség is.
Nem minden üzleti alkalmazást nevezhetünk azonban ERP-nek. Vannak úgynevezett vállalati
rendszerek, vagy vállalati szoftverek (ES – enterprise software vagy enterprise system),
melyek valóban megkönnyítik, támogatják az erőforrás-tervezést, de magát a tervezést nem
végzik el. Ilyenek lehetnek például az úgynevezett ügyfélkapcsolati rendszerek (CRM –
customer-relationship management).
Thomas Wallace és Michael Kremzar így írja le az ERP-t: olyan, vállalati szintű eszközök
halmaza, mely
segíti a bevételek és kiadások egyensúlyban tartását,
képes a vásárlókat és a beszállítókat egyetlen, teljes ellátási láncba kapcsolni,
üzleti folyamatok alkalmazásával segíti a döntéshozatalt,
átfogja és integrálja az értékesítés, marketing, gyártás, üzemeltetés, logisztika,
beszerzés, pénzügy, termékfejlesztés és HR folyamatokat,
mindezek által segíti a produktivitást és az ügyfelek kiszolgálását, párhuzamosan
pedig a költségek és raktárkészletek csökkentését
és megteremti a sikeres e-commerce (elektronikus kereskedelem) alapjait. [1]
1.1. Az ERP kialakulása
A vállalatirányítási rendszerek kialakulása szorosan köthető az informatika fejlődéséhez.
Ahogy a 80-as, 90-es években elterjedtek a számítógépek, szinte rögtön felmerült az igény az
egyes egységek közötti kommunikációra. Először megjelentek a hierarchikus rendszerek,
majd, ahogy nőtt a teljesítmény, és fejlődött a technológia, az együttműködő
munkaállomásokból hálózatok jöttek létre. Végül, az internet megjelenésével a cégek
kiléphettek az irodák falai közül, és segítségével szorosabbra vonhatták kapcsolataikat.
Integrált vállalatirányítási rendszerek 9
A technológia fejlődését az integráció fejlődése is követte. A szoftverfejlesztés hajnalán a
koncepció az egy feladat – egy szoftver volt. Ez persze azzal járt, hogy egy vállalaton belül
sok, akár több száz programot is használtak: minden egyes feladatra a gyártás, a pénzügy, a
készletnyilvántartás, stb. terén külön-külön program volt.
Kezdetben ezen különálló rendszerek között az egyedüli kapcsolatot az ember jelentette.
Bevitték az adatokat (kézzel), ezeket feldolgozta a program, visszaadta az eredményt. A
feldolgozott adatokat kinyomtatták, átvitték a másik géphez, újra begépelték, és így tovább.
Ez természetesen rengeteg hibaforrást rejt magában. Az integráció első lépése az volt, amikor
az adatbevitelt már nem bízták az emberre, hanem a programok maguk végezték el. A
legegyszerűbb módszer, ha megegyezünk egy adatstruktúrában és fájlformátumban, amit az
egyik szoftver előállít, letesz egy előre definiált helyre, majd a másik szoftver ugyanonnan
beolvas, értelmez, és feldolgoz (eleinte ez is manuálisan ment: a felhasználó kimentette az
adatokat, majd betöltötte a másik programba). Sok esetben ma is ugyanezt a módszert
használjuk, néhány példa erre:
A könyvelői szoftverek a Könyvelői Kamara által előirányzott szabványt használják.
A Könyvelői Kamara weboldalán elérhető annak az XML formátumnak a
specifikációja, melyet ezek a szoftverek importálni tudnak [2].
A NAV által használt ÁNYK (Általános Nyomtatványkitöltő Program) szintén XML
fájlokat tud importálni. Valamennyi nyomtatvány ugyanazt a sémát követi, ennek
pontos specifikációja a NAV oldalán érhető el [3].
Ennél már fejlettebb, de sokkal több körültekintést és a felektől szoros együttműködést
igényel, amikor a kommunikáció teljesen automatizált, a szoftverek emberi beavatkozás nélkül
végzik a teljes adatátvitelt. Erre egy példa az EDI (electronic data interchange – elektronikus
adatcsere): az egyik fél (például egy kereskedő) meghatározza az adatok formátumát
(Európában a legelterjedtebb formátum az ENSZ EDIFACT szabványa), a protokollt, a
titkosítási és aláírási módokat, és a partnerek (például a beszállítók) a specifikáció alapján
küldik a megfelelő dokumentumokat.
Hasonló lépcsőfokok vezettek az ERP kialakulásához is. A 60-as évek elején alakult ki az
ERP ősének tekinthető MRP (material requirements planning, vagyis anyagszükséglet
tervezés). Az IBM fejlesztette, feladata az anyagok megrendelésének felügyelete volt. Alapja
az úgynevezett általános gyártási egyenlet volt: a késztermék, az alapanyag-szükséglet és a
raktárkészlet alapján meghatározza a beszerzendő alapanyagok listáját, s ezek mennyiségét.
Ezt az egyenletet négy kérdéssel is felírhatjuk:
Integrált vállalatirányítási rendszerek 10
Mit gyártunk?
Mire van szükségünk?
Mink van?
Mit kell beszereznünk?
Ha előállítunk valamit – bármi legyen is az – ezt a négy kérdést mindenképpen meg kell
vizsgálnunk.
A felhasználók azonban hamar rájöttek, hogy az MRP ennél többet is tud, mint hogy csak azt
jelezze, ha új megrendelésre van szükség: nyomon tudta követni a rendelések határidejének és
esedékességének tervezését, és ezt össze tudta hangolni a gyártási folyamatokkal. Ezt hívjuk
prioritástervezésnek.
Egy dolog hiányzott még, hogy az ERP fejlődésének következő lépését elérjük: a kapacitás,
ami legalább annyira fontos, mint a prioritás. Az MRP-ben már megvoltak a kapacitástervezés
feltételei is. Néhány további funkció, mint például a keresletmenedzsment, erőforrás-
analizálás és más funkciók hozzáfejlesztésének eredményeként jött létre a zártláncú (closed-
loop) MRP. Ez már tudott visszajelzéseket adni a tervezési funkciók számára a gyártásról,
ezáltal a terveket szükség szerint módosítani lehet. Tehát a prioritásokat képes volt a
körülményekhez képest változtatni.
A 70-es években érkeztünk el az MRP II.-höz. Az MRP rövidítés itt már mást jelent:
manufacturing resource planning, vagyis gyártási erőforrás-tervezés. Három fontos új
funkciója van a zártláncú MRP-hez képest:
Értékesítés és üzemeltetés tervezés
Pénzügyi tervezés
Szimulációk: a „mi lenne, ha” kérdésekre kísérel meg választ adni. Ma már rendkívül
részletes előrejelzéseket képesek készíteni a tervező rendszerek.
Végül, az 1990-es évekre elérkeztünk az Enterprise Resource Planninghez, vagyis a vállalati
erőforrás-tervezéshez. Alapjai megegyeznek az MRP II. alapjaival, azonban egy sokkal
átfogóbb rálátást biztosít az üzleti folyamatokra.
Egy, az egész vállalatot átfogó rendszerről van szó, mely integrálja mind az értékesítési,
gyártási és pénzügyi információkat – mindezt valósidőben. A vásárlókat és beszállítókat
ellátási lánccá fogja össze, melyet kiegészít az erőforrás-tervezéssel, így a szimulációk még
hatékonyabbakká, az előrejelzések pedig pontosabbakká válnak.
Integrált vállalatirányítási rendszerek 11
A fejlődés természetesen nem áll meg, mindig van hova továbblépni. Itt sincs ez másként, a
2000-es évektől beszélhetünk az ERP rendszerek második generációjáról. Ez már nem csak a
belső folyamatokat kezeli, hanem kibővíti azokat a vevői és beszállítói oldali folyamatokkal.
1.1. ERP bevezetése
Az ERP rendszerek legfontosabb feladata, hogy egy gyorsan változó környezetben képes
legyen az üzletet támogatni, hogy az továbbra is versenyképes maradjon.
A nagy ERP rendszerek úgynevezett standard szoftverek, vagyis a vállalat készen
megvásárolhatja. Ennek meg van az az előnye, hogy nem kell hosszas és költséges munkával
kifejleszteni egy saját szoftvert. Azonban, mivel egy elméleti vállalati modell alapján íródtak
meg, a legtöbb funkciót a megrendelő vállalat számára testre kell szabni. Ilyenkor lép színre a
tanácsadó cég. A tanácsadó a szoftver fejlesztőjének partnere. Feladata átlátni a megrendelő
vállalat folyamatait, a vállalati logikát értelmezni, és ezt „lefordítani” a bevezetésre váró ERP
rendszer logikájára.
Egy ERP rendszer bevezetése nagy változás a vállalat életében, és nagy kockázattal is jár. Az
informatika használata ma már nélkülözhetetlen ahhoz, hogy egy vállalat versenyképes
maradjon a folyamatosan változó piacon, ennek egy eleme a vállalatirányítási rendszer.
Átgondoltan bevezetve és jól alkalmazva jelentős előnyökhöz juttathatja a szervezetet, és ha
ezt a vállalat vezetősége felismeri, már jó úton jár.
A rendszer bevezetésekor sokszor kerül sor az üzleti folyamatok áttekintésére,
racionalizálására, ami már egyedül jelentősen növelheti a hatékonyságot. Ebben sokat tudnak
segíteni a tanácsadók is. Az integráció következtében a többször elvégzett feladatok
megszűnnek, mely szintén előnyös: nincs felesleges munka, ami eleve idő- és
pénzmegtakarítás.
Leggyakoribb többször elvégzett munka a többszörös adatbevitel, ami az egyik legnagyobb
veszélyforrás: nem az adatok ellenőrzését segíti elő, hanem inkonzisztenciához vezet. Ami
még rosszabb, ha az adatokat több helyen tároljuk: a redundáns adattárolás szintén
veszélyforrás, melyet az egy helyen, egyszer tárolt adatok kiküszöbölnek, ezáltal javul az adat-
és információminőség.
A valósidejű rendszer nagy előnye, hogy mindig az aktuális információkkal lát el bennünket,
ezáltal jobban előkészített, megalapozottabb vezetői döntéseket hozhatunk, és jobban átlátjuk
a szervezet aktuális helyzetét. Ez segít az új üzleti lehetőségek felismerésében is.
Azonban mindezen előnyök elérése nem könnyű, statisztikák szerint a bevezetések mindössze
50%-a sikeres csak, vagy éri el az elvárt eredményt. Ennek több oka is lehet, Thomas Wallace
Integrált vállalatirányítási rendszerek 12
és Michael Kremzar találóan egy golfütőkészlethez hasonlítja az ERP-t: az átlagembernek, aki
sose járt még golfpálya közelében, hiába adjuk a kezébe a világ legjobb golfütőit, esélye sem
lesz jó eredményt elérni, hiszen nem tud golfozni. Ugyanakkor maga Tiger Woods se fogja
megnyerni a játékot egyetlen ütővel.
Egy ERP rendszertől tehát ne várjunk csodát. Ahhoz, hogy a várt eredményeket elérhessük
vele, meg kell tanulnunk használni – és nem csak a vezetésnek, az egyszeri felhasználóknak is.
Mert a folyamat legfontosabb elemei még mindig a felhasználók.
SAP Business One 13
2. SAP Business One
Az SAP-t öt, korábban az IBM-nél dolgozó német mérnök (Diermar Hopp, Klaus Tschira,
Hans-Werner Hector, Hasso Plattner és Claus Wellenreuther) alapította. Az SAP rövidítés,
jelentése eredetileg Systemanalyse und Programmentwicklung (System Analysis and Program
Development – Rendszeranalízis és szoftverfejlesztés) volt. Később ezt megváltoztatták, ma
már Systeme, Anwendungen und Produkte in der Datenverarbeitungként (Systems,
Applications and Products in Data Processing – Rendszerek, alkalmazások és termékek az
adatfeldolgozásban) hivatkoznak rá.
Az öt alapító célja egy valósidejű adatfeldolgozású rendszer fejlesztése volt, ami akkoriban, a
70-es évek elején meglehetősen impozáns cél volt. 1973-ra el is készültek az első verzióval, ez
volt az SAP R1. Hatalmas sikert értek el vele.
Ez még csak nagygépes (mainframe) környezet volt, de pár hónap alatt elkészült az IBM DOS
rendszer alatt működő verzió is. 1977-ben lépnek ki a nemzetközi piacra, ekkor vezetnek be
először rendszert külföldi vállalatnak.
Folyamatosan bővítik a funkcionalitást, s 1979-ben bemutatják a második verziót, az SAP R2-
t. Ez már egy átfogóbb rendszer, gyakorlatilag a vállalat irányításában szükséges valamennyi
folyamatot le tudja fedni. A vállalat gyorsan fejlődik, 1980-ban beköltöznek Walldorfba, ahol
mára egy kisebb város méretű központot alakítottak ki, s a mai napig itt található központ.
1987-ben elkezdik fejleszteni az új rendszert, az R3-at, amit 1991-ben a CeBIT-en mutattak
be. A CeBIT a világ legnagyobb informatikai kiállítása, melyet a németországi Hannoverben
tartanak évről évre (2013-ban március 5-9-én volt). Az R3 már kliens-szerver architektúrát
használ, és relációs adatbázison működik.
Az R3 megjelenésétől kezdve még rohamosabb fejlődésnek indult a cég. A 90-es években a
nemzetközi terjeszkedésre került a hangsúlyt. A Microsofttal való együttműködés
következtében a Microsoft Windows NT operációs rendszeren is használható kliensprogram is
elkészült. Ahogy a személyi számítógépek elterjedtek, és az informatikai beruházások
költségei csökkentek, egyre elérhetőbbé váltak a vállalati szoftverek.
Magyarországon az SAP 1989. óta van jelen. Világszerte 1500 partnercége van, akik
licenceket értékesítenek, bevezetéseket végeznek és támogatást nyújtanak ügyfeleiknek.
Magyarországon körülbelül 50 partnere van, és több mint 600 bevezetett rendszer működik.
2.1. SAP Business One
Az SAP a 2000-es évek elején ismerte fel azt a piaci rést, hogy a kis- és középvállalkozások
számára nincs elérhető árú, elfogadható minőségű vállalatirányítási rendszer. Az R3
SAP Business One 14
nagyvállalatokra volt optimalizálva, kis- és középvállalkozások számára feleslegesen összetett,
túlméretezett, és drága.
2002 márciusában az SAP felvásárolta az izraeli üzleti alkalmazás-fejlesztő TopManage
Financial Systems vállalatot. Ezzel megnyílt előtte az új piac: a kis- és középvállalkozások
piaca. A TopManage által fejlesztett rendszer – már SAP Business One (röviden SBO) néven
– ideális megoldásnak bizonyult számukra [4].
Az SBO 2004 óta Magyarországon is elérhető, már több mint 500 ügyfélnél került sor sikeres
bevezetésre. Az SAP ajánlása szerint kb. 100 fő alatti cégek számára javasolt. A legújabb, 9-es
verziójú SAP Business One 2013. májusában jelent meg. A 8-as verzió jelenleg a 11-es
patchen áll (8.82 PL11), a patch szintén májusban jelent meg. Én munkám során a 8.82 PL07-
es, illetve (teszt szinten) a 8.82 PL11-es verziókat használtam, de már végzünk teszteket a 9-es
verzióval is.
Az SBO szintén moduláris felépítésű. Az egyes modulok a vállalatirányítás különböző
területeit fedik le, de igény szerint fejleszthetők speciális kiegészítő modulok is. Ezeket a
modulokat hívjuk addonoknak.
1. ábra
Az 1. ábrán láthatjuk az SBO főmenüjét a standard modulokkal. A standard modulok a
következők:
SAP Business One 15
Adminisztráció
A rendszer funkcionalitásának alapbeállításai. Itt lehet a rendszert a vállalat
folyamatainak megfelelően testre szabni. Itt definiálhatók többek között a
valutaárfolyamok, országkódok, periódusok, valamint az addonok kezelése is itt
található.
Pénzügy
Pénzügyi tranzakciók kezelése. Itt található a főkönyv, a naplókönyvelés,
költségkeret, valamint egy Költségszámítás menüpont, ahol költséghelyeket
definiálhatunk, illetve eredménykimutatást készíthetünk az egyes költséghelyekhez.
Üzleti lehetőségek
Értékesítési adatokat vihetünk be, melyeket karbantarthatunk és elemzéseket
végezhetünk vele.
Értékesítés
Értékesítési folyamatok kezelése. A legfontosabb funkciók a vevői rendelések,
kiszállítások, kimenő számlák kezelése, illetve az árajánlatok létrehozása..
Beszerzés
Beszerzési folyamatok kezelése. Szállítói ajánlatok, megrendelések, árubeérkezések,
valamint a bejövő számlák kezelését teszi lehetővé.
Üzleti partnerek
A partnerekkel (vevők, szállítók) kapcsolatos adatok, mint például törzsadatok,
számlaegyenlegek, elérhetőségek.
Bank
A bank modul végzi a pénzügyek kezelését, mint például a pénzbeérkezéseket,
előlegeket, fizetéseket, banki egyeztetést. Itt található a fizetésvarázsló, mellyel ki- és
befizetéseket lehet tömegesen, a tranzakciók alapján generálni.
Készletvezetés
A készletvezetés modulban találhatók a cikktörzsadatok, a cikk-kezelés, árlisták,
raktárak, készlettranzakciók, valamint a raktárak közötti mozgatások.
Gyártás
A gyártási folyamat felügyelete: darabjegyzék, gyártási utasítások
Anyagszükséglet tervezés
Gyártás- és bevételtervezés. Lehetővé teszi feltételes tervezési szcenáriók definiálását.
Szerviz
Szolgáltatások felügyelete.
SAP Business One 16
Emberi erőforrások
Dolgozómenedzsment: dolgozói törzsadatok kezelése, kapcsolatinformációk,
személyügyi beszámolók készítése.
Beszámolók
Beszámolók készítése, a vállalat szinte minden aspektusáról (például vevői és szállítói
követelések, cashflow, könyvvitel, stb.).
A Business One rendszer egy SBO szerverből és a kliensekből áll. A szerveren szükség van
egy adatbázisszerverre (MSSQL), amihez kapcsolódnak a kliensek. Az SBO kliens
alapképernyője látható a 2. ábrán
2. ábra
Baloldalt, a főmenüben láthatók a standard modulok. Jobbra egy keresőmező található, fenn a
menüsor és az eszköztár, alul pedig az üzenetsáv.
A főmenü minden felhasználó számára testre szabható. Jogosultságok beállításával már eleve
korlátozzuk, hogy a felhasználó melyik menüpontot láthatja (vagyis melyik modulhoz fér
hozzá). A felhasználó ezen kívül magának is beállíthatja, mely menüpontokat akarja látni az
eszköztáron található űrlapbeállítások gombbal (3. ábra).
3. ábra
SAP Business One 17
A jogosultságok nagyon fontos pontjai az ERP rendszereknek. Mivel egy nagy rendszerről van
szó, ami átfogja a vállalat teljes irányítását, szigorúan korlátozni kell, ki mihez férhet hozzá,
hiszen veszélyes lehet, ha hozzá nem értő nyúl (vagy akárcsak lát) bele olyan modulokba,
amik a vállalat számára létfontosságúak. Ezt a korlátozást jogosultságok hozzárendelésével
tehetjük meg. Az SBO-ban ezt is az Adminisztráció menüpontban tehetjük meg.
Fejlesztői és tanácsadói eszközöket is tartalmaz az SBO kliens, ezek közül kitérek néhányra,
ami a későbbiekben tárgyalt integráció során hasznos lehet.
2.1.1. Lekérdezések
Mivel adatbázissal dolgozunk, természetesen tudunk lekérdezéseket is futtatni. Ezeket a
lekérdezéseket megírhatjuk és kezelhetjük az SBO-ban is, a Lekérdezések menüpontban. A
Lekérdezéseket az Eszközök menüben találjuk (4. ábra).
4. ábra
A Lekérdezéskezelőben érhetjük el az elmentett lekérdezéseket. Ezek lehetnek riportok,
analitikák, vagy egyéb lekérdezések, melyek a felhasználók (pénzügy, könyvelők, vállalati
döntéshozók) munkáját segítik, de volt arra is példa, hogy addon által használt lekérdezést
tettünk be ide.
A Lekérdezésgenerátor egy olyan eszköz, mellyel a felhasználók egyszerűen állíthatnak össze
SQL lekérdezéseket (5. ábra). A baloldali oszlopban kiválasztjuk a kívánt táblákat, a középső
oszlopban a mezőket. Két tábla esetén, ha tudja (például, ha a két tábla egy fejadat-soradat
táblapár), automatikusan join-olja is őket. Mivel a példában szereplő OCRD és a CRD1
standard táblák, és a CRD1 (partnerek címei) az OCRD (üzleti partnerek) altáblája, ezt
automatikusan meg tudja tenni.
A jobboldali oszlopban a generált kódot kiegészíthetjük feltételekkel, és további GROUP BY
vagy SORT BY utasításokkal. A Végrehajtás gombbal lefuttathatjuk az elkészült
lekérdezésünket, a Műveletek gombra kattintva pedig kinyílik a jobbra lévő panel, ahol
további műveleteket találunk, valamint megadhatunk bemenő paramétereket is a
lekérdezésnek (a Végrehajtás gombra kattintva megjelenik egy paraméterablak, ahol a
paramétert meg kell adnunk).
SAP Business One 18
5. ábra
A Lekérdezésgenerátor hasznos eszköz, mert tanácsadónak és fejlesztőnek sokszor egyszerűbb
az adatokat magából a táblából lekérdezni, mint a felhasználói felületen keresgélni a mezőket
(melyik ablakon van, melyik fülön, felhasználói mező-e, vagy ott lesz az ablakon valahol, és
így tovább), valamint többnyire jobban kéznél is van, mint az MS SQL Management Studio
(l. 2.2.1. fejezet).
2.1.2. Rendszerinformációk
6. ábra
A Nézet menüben van egy Rendszerinformációk menüpont (6. ábra), amit bepipálva egy
nagyon hasznos eszközt kapunk (7. ábra).
SAP Business One 19
7. ábra
A megnyitott űrlapon (SBO-ban ezt formnak nevezzük) az egérrel rámutatva valamelyik
mezőre (nyíllal jelölve) az alsó üzenetsávon láthatjuk az adott mező jellemzőit.
A 7. ábrán a partnertörzs formot láthatjuk, a kiválasztott mező pedig az adatbázis egy
táblájának egy mezőjéhez van kötve. Az üzenetsávon látható értékek, amik hasznosak
lehetnek számunkra:
Felső sorban (ezek a rendszerinformációk bekapcsolása nélkül is láthatók):
• ÜP neve: a mező neve
• 100 characters: a mező mérete
Alsó sorban:
• Norm Thompson Hungária Kft.: a mező értéke, ami a formon is meg van
jelenítve
• Form = 134: a form típusa (most az ÜP-törzs form)
• Item = 7: a kiválasztott mező azonosítója. A mezőazonosító maximum 9
karakter hosszú lehet (ennek felhasználói formok létrehozásakor van nagy
jelentősége)
• Pane = 0: a formon melyik szinten (pane-en) található a mező. Olyankor van
ennek jelentősége, amikor a formon több „fül” is van (mint a példában is
látható Általános, Tárgyalópartnerek, Címek, stb. fülek). Minden fülhez
hozzárendelünk egy pane-t, a mező pedig csak akkor látható, ha a pane-je
megegyezik az aktív fülhöz rendelt pane-hez. A 0 pane-nel rendelkező mezők
mindig láthatók.
• OCRD: a kapcsolt tábla neve, most a partnertörzs
• CardName: a mező neve a táblában, most a cikk megnevezése mező
SAP Business One 20
Nem adatbázishoz kapcsolt mező (pl. a címkék) esetén csak a mező tartalma, valamint a form
és a mező azonosítója látható.
2.1.1. Felhasználói mezők, felhasználói táblák
A standard táblák nagyon sok és sokféle adat tárolását teszik lehetővé, de előfordulhat, hogy
szükségünk van még valamire, amit tárolni szeretnénk. Ez könnyen lehetséges, mivel a
legtöbb táblához felvehetünk felhasználói mezőt (UDF – user defined field). A felhasználói
mezők neve mindig egy U_ prefixszel kezdődik (az 5. ábra látunk erre példát). Ezek a mezők
nem jelennek meg a standard rendszerformokon, de van egy mód, hogy láthatóvá tegyük őket:
a Nézet menüben található Felhasználói mezők menüpont bepipálásával (6. ábra).
Ezután a rendszerformok mellett, ha a formhoz kapcsolt objektumokban van felhasználói
mező, egy kiegészítő panelen megjeleníti őket (8. ábra).
8. ábra
Ha teljesen új dolgot akarunk bevezetni a rendszerbe, új táblára is szükségünk lehet. Ez is
megoldható úgy, létrehozunk egy felhasználói táblát (UDT – user defined table).
Felhasználói táblákhoz létrehozhatunk automatikusan is formot, de ez nem mindig elég. Egy
ilyen formon az inputot nem tudjuk ellenőrizni, a táblák menüpontjai „ömlesztve” kerülnek
bele az Eszközök menü egyik almenüjébe, és a tábla mögött álló logikát sem tükrözik. Ahhoz,
hogy jól használható formunk legyen ezekhez az objektumokhoz, nekünk kell megrajzolnunk,
és az SBO ehhez is kínál eszközt: egy addont, mely egy szerkesztőprogram magában az SBO-
SAP Business One 21
ban. Segítségével megrajzolhatjuk a formokat, amiket aztán a fejlesztésekben is használható
.srf kiterjesztésű XML fájlban elmenthetünk.
Az objektumok lehetővé teszik, hogy az SDK-n keresztül elérjünk bizonyos táblákat, illetve
táblacsoportokat. Az objektumokról részletesebben fogok írni az SDK-ról szóló 2.2.2-es
fejezetben
2.2. Addonok
Az SBO core rendszer forráskódja nem publikus, de az ERP rendszer definíciójából adódóan a
megrendelő igényei szerint szükség lehet kiegészítő modulok, addonok fejlesztésére. Ezek az
addonok az alaprendszerrel együtt futtathatóak, fejlesztésüket vagy egy tanácsadó cég, vagy
maga az SAP végzi el.
A fejlesztések elvégzéséhez rendelkezésre áll egy SDK (software development kit). Ez az
SDK az SAP core rendszerre épül, s az SDK-ra épülnek az addonok. Ez a felépítés látható a 9.
ábra.
9. ábra
Léteznek olyan addonok, melyeket az SAP fejlesztett, a rendszerrel együtt fel lehet ezeket is
telepíteni (ilyen például a tárgyi eszköz addon, vagy a Screen Painter, amivel formokat
rajzolhatunk).
Léteznek viszont olyan addonok, melyeket az ügyfél kérésére a rendszert bevezető
tanácsadócég fejlesztői fejlesztenek le. A 3. fejezettől kezdve is egy ilyen addonról fogok írni,
de előbb tekintsük át az addonok fejlesztéséhez használható eszközöket.
SAP Business One 22
2.2.1. Microsoft SQL Server 2008 R2 Management Studio
10. ábra
A Microsoft SQL Server 2008 R2 Management Studio az adatbázisok menedzselését segíti
(10. ábra).
Az 1-es számmal jelölt mező az Object Explorer, itt látjuk az adatbázisszervert (EREBOR – ez
a saját gépem, mivel a képernyőképek a saját gépemen készültek, és az adatbázisszerver is itt
fut). A Databases könyvtárat lenyitva láthatjuk a szerveren lévő adatbázisokat. A 2-es mezőbe
írhatjuk az SQL scripteket, melyeknek eredménye az alsó, 3-as számmal jelölt mezőben
jelenik meg. Az eredményt ki is másolhatjuk szöveges fájlba vagy akár Microsoft Excelbe is.
Az SQL Management Studio segítségével tudunk adatbázisokat lementeni és betölteni. A
program egy backup (.bak) fájlba menti az adatbázist, amit aztán betölthetünk, és
visszaállíthatjuk a lementett adatbázist. Ez hasznos tud lenni, ha fejlesztések, tesztelések vagy
hibák keresése során le szeretnénk menteni az ügyfél éles adatbázisát. A lementett adatbázist
vagy ugyanazon a szerveren, az éles adatbázis mellé téve tesztadatbázisként tudja használni a
fejlesztő vagy a tanácsadó, de akár saját, belső tesztszerverre, vagy a saját számítógépünkön
futó adatbázisszerverre is feltehetjük. Így nem „szemeteljük tele” az ügyfél éles rendszerét,
mégis azonos, vagy közel azonos környezetben tesztelhetünk.
SAP Business One 23
A 11. ábra egy SBO bejelentkező képernyőt látunk, ahol az választhatjuk ki, hova szeretnénk
bejelentkezni. Kiválaszthatjuk az adatbázisszervert (ez megint az EREBOR), majd az azon
lévő adatbázisok közül a kívánt példányt (mivel ugyanaz a szerver, mint az előző ábrán, látjuk
az azon lévő SBO adatbázisokat).
11. ábra
2.2.2. SDK
Az SAP Business One SDK két nagy részre, két API-ra (Application Programming Interface)
osztható:
UI API (User Interface API – felhasználói interfész API)
DI API (Data Interface API – adat interfész API)
A UI API nevéből is adódóan a felhasználói felületekhez nyújt kapcsolatot. Segítségével
elérhetjük a felhasználói felületet, lehetővé teszi a felhasználói formok létrehozását és
kezelését, hozzáférhetünk a (rendszer- vagy felhasználói) formokon található mezőkhöz.
A DI API ennél már összetettebb, vele a háttérben lévő objektumokhoz és az adatbázishoz
férhetünk hozzá. Ezzel a réteggel állíthatunk üzleti logikát a UI API-val létrehozott
felhasználói felület mögé, valamint ez teszi lehetővé a külső alkalmazásokkal való
együttműködést. Létrehozhatunk vele felhasználói táblákat, felhasználói mezőket, valamint
felhasználói objektumokat.
Bizonyos táblák, illetve táblacsoportok elérhetők a DI API-n keresztül is, úgynevezett
objektumokként. Ezek a táblák jellemzően Document vagy úgynevezett MasterData típusú
táblák lehetnek. Document típusú táblákba kerülnek a bizonylatok – ilyenek például a számlák
és típusaik (kimenő, bejövő, előleg, sztornó, stb.), a megrendelések, szállítólevelek, stb.
MasterData típusúak például a különféle törzsadat táblák (partnertörzs, cikktörzs, dolgozói
törzs, stb.).
SAP Business One 24
Azért említettem táblacsoportokat, mivel ezeket az adatokat nem lehet, vagy legalábbis
nagyon költséges volna egy-egy táblában tárolni. Jellemzően ezeket fej- és soradat
(MasterData és MasterDataLines, illetve Document és DocumentLines) táblákban1 tároljuk,
sőt legtöbbször nem is egy soradat tábla tartozik a fejadathoz.
Az objektumokat nem lehet explicit egy táblához, vagy fej-sor táblastruktúrához kötni, de
behatárolható, melyik objektumot hol keressük. Néhány példa objektumokra:
Partnertörzs: a 2-es típusú objektum, neve oBusinessPartners
o OCRD: a fejadat tábla a partner adataival (partnerkód, név, adószám, stb.)
o CRD1: a partner címei
Kimenő számla: a 13-as típusú objektum, neve oInvoices
o OINV: a fejadat tábla a számla fejadataival (partnerkód és -név, dátumok,
pénznem, státusz, stb.)
o INV1: a számla sorai. Cikkszám és -név, mennyiség, ár, kedvezmény, kiadó
raktár
o INV12: cím
Felhasználói táblákat is hozhatunk létre ilyen fej-sor Document/MasterData struktúrával, sőt
felhasználói objektumot, vagyis UDO-t (User Defined Object) is hozhatunk létre hozzájuk.
2.2.3. Fejlesztői környezet
Fejlesztésekhez több fejlesztői környezetet is használunk. Leggyakrabban a Microsoft Visual
C# 2008 Express Editiont használtam, de bizonyos esetekben szükség volt másik környezetek
használatára. Az ingyenes Express Edition korlátozásainak kiküszöbölésére vettük elő az
ingyenes, nyílt forráskódú Sharp Develop [5] programot. Ez egy rugalmas, ám a Visual Studio
után kissé „fapadosnak” tűnő fejlesztői környezet, amit gyorsan meg lehet szokni. Nagy
előnye, hogy az újabb .NET keretrendszereket is kezelni tudja.
Az újabb fejlesztésekben szükség volt a .NET újabb (4.0, 4.5) verzióinak néhány könyvtárjára,
ezért az ilyen fejlesztéseknél kénytelenek voltunk a Visual Studio Express 2012 for Windows
Desktop fejlesztői környezetre áttérni. Ez már az újak mellett tudja kezelni a régebbi .NET
verziókat, de a felülete nagyon megváltozott a 2008-as verzióhoz képest.
1 Fej- és soradat: vegyünk például egy számlát. A számlán látjuk a fejrészt, itt található a vevő neve,
címe, a számla dátuma, az eladó adatai, a számla alján a végösszeg, esetleg megjegyzések. Ezeket az
adatokat tároljuk a fejadatok közt. A fejrész alatt találjuk a vásárolt termékek listáját. Látjuk a cikk
nevét, a mennyiséget, az árát, akár az áfa összegét is. Ezek a soradatok.
Üzemgazdasági háttér 25
3. Üzemgazdasági háttér
Az ügyfél üzemanyag kis- és nagykereskedelemmel foglalkozik, két benzinkutat üzemeltet. A
benzinkutakon a WinPetrol üzemanyag kereskedelmi rendszer üzemel, ezzel kell az SBO-nak
együttműködnie. Az együttműködést egy, az SBO-hoz fejlesztett, és egy, a WinPetrol rendszer
oldalán működő interfész biztosítja. A kutaknál és a központban folyamatos internetkapcsolat
van.
Az integráció módjának megértéséhez szükség van az üzleti folyamatok hátterének
ismertetésére. Az egyes témakörök végén a témához kapcsolódó szinkronizációs folyamatokra
is kitérek, de a szinkronizációról részletesen csak a 4. fejezetben fogok írni).
Az ügyfélnek két benzinkútja üzemel, de az interfész (természetesen a megfelelő konfigurálás
után) ennél többet is képes lehet kezelni. A szinkronizáció ütemezett, gyakoriságát egy
konfigurációs táblában kell megadni (l. 4.1.6. fejezet).
3.1. Cikktörzs, készletgazdálkodás
Új cikk létrejöhet az SBO-ban és a kutakon is. Az SBO csak a nem zárolt és
szinkronizálhatóként megjelölt cikkeket továbbítja a kutak felé.
Az SBO cikktörzsben nyilvántartjuk a cikkeknek a kutakon futó rendszerben használt
cikkszámát, erre egy-egy felhasználói mező szolgál a cikkek táblájában, aminek nevét a
[@KUTAK] felhasználói tábla U_ITEMCODE mezőjében meg kell adni a konfiguráció során
(l. 4.1.1). A kúton történt cikktörzs módosításkor az adatok szinkronizálandó halmazát a
WinPetrol interfésznek fel kell küldenie az SBO-nak.
A megfelelő integráció érdekében szükség volt néhány felhasználói mező hozzáadására a
cikktörzshöz. Ilyen mezőkről van szó:
Cikkszám az 1. kúton
Cikkszám a 2. kúton
Minimum készlet az 1. kúton
Minimum készlet a 2. kúton
Alkohol termék (Y/N)
Jövedéki adó összege (üzemanyagnál, 10 ppm2 kéntartalom alatti termékekre)
Jövedéki adó összege (üzemanyagnál, 10 ppm kéntartalom feletti termékekre)
Kéntartalom besorolás (1 = 10ppm alatt, 2 = 10 ppm felett)
Szinkronizálandó (Y/N)
2 ppm: parts per million, milliomod rész, 1 ppm = 10
-6
Üzemgazdasági háttér 26
Ármódosítás a kúton megengedve (Y/N)
3.1.1. Raktárak
A rendszerben négy raktárt definiáltunk:
KV: benzinkút 1.
SO: benzinkút 2.
KOZP: központ
UTON: úton levő készlet
A két benzinkutat egy-egy raktárként kezeljük. Külön raktárnak számít a központ, és van egy
raktár az úton levő készleteknek. Az úton raktárnak a raktárak (benzinkutak) közti
készletmozgások esetén van jelentősége (l. 3.5.1. fejezet).
Bizonyos cikkeknél engedélyezett a kúton történő ármódosítás (tehát a kútkezelő manuálisan
módosíthatja az árat). A módosítás a következő szinkronizáció során bekerül az SBO-ba.
3.2. Partnertörzs
A vevők és szállítók egységes struktúrában jelennek meg az SBO-ban, ha egy partner vevő és
szállító is, akkor kétszer szerepel a partnertörzsben. Az üzleti partnereket kóddal látjuk el, ami
7 karakter hosszú, automatikus számkiosztással, prefixszel ellátva. A prefixek:
Vevő: C
Szállító: S
Érdeklődő: L
Az automatikus számkiosztást formázott keresés végzi. A formázott keresés egy, a GUI-hoz
kapcsolódó SQL lekérdezés, amit a form valamelyik mezőjéhez kapcsolhatunk. A
lekérdezésnek megadhatjuk paraméterként a GUI-n megjelenő értékeket, az eredményt pedig
visszaírja abba a mezőbe, melyhez hozzákapcsoltuk. A formázott keresést triggerelheti
valamilyen, a formon történt esemény (itt például a vevőtípus változtatása, vagy mondjuk egy
számlán a partner kiválasztása).
Az üzleti partnerekhez alapértelmezésben több pénznemet rendelünk, a WinPetrol rendszer
felől viszont valamennyi tranzakció pénzneme forint.
Fizetési módokat és feltételeket is tárolunk az egyes partnerekhez. A módot és feltételt
egyben, kombináltan kezeljük, például „Átutalás 10 nap”. A partnereknél az alapértelmezett
fizetési módot tároljuk, amit a bizonylat létrehozásakor természetesen változtatni lehet.
Fizetési módok és feltételek a következők lehetnek:
Üzemgazdasági háttér 27
Átutalásos (+ feltételek)
Készpénzes
Hitelezett készpénzes (ilyenkor a vevő a tankoláskor csak szállítólevelet kap, a
számlát majd több szállítólevél összevonásával állítják ki)
Nyugtás: a vevő nem kér áfás számlát. Az SBO-ban ez is számlának minősül, csak
egy technikai vevő (Nyugtás vevő) nevére állítjuk ki.
Hitelkártyás
Belső felhasználás
A partnertörzshöz a következő felhasználói mezőket adjuk hozzá:
Partner táblához:
o Vevőkód az 1. kúton
o Vevőkód a 2. kúton
o Tárgyalópartner
o Kedvezmény mezők (összesen 15 darab, l. 3.3. fejezet)
o Szinkronizálandó (Y/N)
Szállítási címek táblához:
o Induló pont (pontos kedvezményrendszer használata miatt)
o Mágneskártya (partnerkártya)
o Telephelyi engedély száma
o Költségfajta (0 – nem jelölt, 1 – globális, 2 – lokális)
3.2.1. Speciális partnerek
A két kutat és a központot saját vevő- és szállítókódokkal látjuk el (hat technikai partner). Két
további technikai partner a VPOP (ma már NAV), valamint az Üresváltás (a kútoszlop
karbantartásakor van szükség, l. 3.5.1-es fejezet). A speciális partnerek szerepéről a
Készletgazdálkodás fejezetben fogok részletesen írni.
3.2.2. Partnerszinkron
Készpénzes üzleti partner létrejöhet a kúton és központilag is, hitelszerződéses és átutalásos
vevő viszont csak az SBO-ban keletkezhet. A kúton keletkező új partner a következő
szinkronnal kerül be az SBO-ba, ahol kap SAP-s partnerkódot, s a következő szinkronnal
lekerül a többi kútra is. Csak nem zárolt és szinkronizálható vevőket és szállítókat
szinkronizálunk.
A partnerszinkron két struktúrából áll: partneradatokból és szállítási címekből, a címeket
vevőtörzzsel együtt szinkronizáljuk. Az SBO-ban a rendszámokat (járművek) is szállítási
címként tartjuk számon. Szállítási cím csak központilag keletkezhet, rendszám a kutakon is.
Üzemgazdasági háttér 28
A cég kibocsát partnerkártyákat (mágneskártyák) is, ezek a szállítási címekhez kapcsolhatók
(CRD1.U_KARTYA mezőben tároljuk a kártyaszámot), velük együtt szinkronizálódnak. A
kártyák szintén központilag vannak kezelve.
3.3. Árak, árlisták, kedvezmények
Az SBO-ban minden üzleti partnerhez egy árlistát rendelhetünk. Minden árlistán szerepelhet
minden termék egyetlen pénznemben. Minden kúthoz egy árlista van hozzárendelve, ezeken a
nettó árak szerepelnek. Van továbbá egy központi árlista is. A kutak csak a saját árlistájukat
látják. Ezeken kívül vannak még beszerzési árlisták is, de a kutakra csak a saját értékesítési
árlisták szinkronizálódnak.
Az egyes partnerekhez definiálhatunk kedvezményeket. A kedvezményt definiálhatjuk
százalékosan (pl. 95-ös benzinből 5% kedvezmény) vagy forintosítva (pl. 95-ös benzinből
literenként 5 Ft kedvezmény).
Bizonyos cikkek esetében megengedett az ármódosítás a kúton (l. 3.1). Módosítás esetén az
interfész visszaküldi az SBO-nak a módosított árakat.
Az engedményeket háromféleképpen kezeljük:
Üzleti partner törzsadat: forintális kedvezmény
Kedvezménycsoportok definiálása: gyártókategóriánként megadható
kedvezményszázalék
Engedményes árak üzleti partnereknek: cikkenkénti kedvezményszázalék
A kedvezményeket külön kezeljük üzemanyagok és egyéb termékek esetén. Üzemanyagoknál
egy kedvezményalap árlistát használunk, a vevőkkel kötött szerződések szerint kínálunk
forintos kedvezményeket. Erre szolgálnak az l. 3.2-es fejezetben említett kedvezmény mezők,
melyekkel a cikkenkénti forintos kedvezmények karbantarthatók.
Egyéb termékeknél százalékos kedvezményeket adhatunk, ehhez az SAP Business One
Készletvezetés Árlisták Kedvezményes árak üzleti partnereknek, illetve az
Engedménycsoportok menüpontjában van lehetőségünk (12. ábra).
Üzemgazdasági háttér 29
12. ábra
Az engedménycsoportok menüben vevő-gyártó viszonylatban adhatunk meg kedvezményeket,
míg a kedvezményes áraknál cikkenként.
Létezik még egy kedvezménytípus, az időszaki kedvezmények, ilyen például egy hétvégi
akció. Ilyenkor a cikktörzsben található „Rögzített árú termék” tulajdonságot be kell
kapcsolni, majd az árát minden kút árlistáján módosítani kell. Ez az információ is lekerül a
WinPetrol rendszernek, ami alapján az nem ad kedvezményt az adott cikkre (akciós termékre
nem adunk további kedvezményeket).
Van még egy fontos, árakkal kapcsolatos művelet: az időzített szinkron.
Előfordulhat (különösen üzemanyagtermékek esetén), hogy egy adott cikk árát előre
meghatározott időpontban kell módosítani. Ilyenkor használhatjuk az időzített szinkron táblát
([@IDOZITETTSZINKRON] – a struktúrát l. a 4.1.4-es fejezetben). A táblában megadjuk a
cikkcsoportot, cikkszámot, a szinkron kívánt dátumát és időpontját, valamint a kút
azonosítóját, ahova szinkronizálni szeretnénk. Miután ezt elmentettük, módosíthatjuk a cikk
árát, ami most nem a következő ütemezett szinkronnal, hanem a kívánt időpontban fog csak
lekerülni a kútra.
3.4. Jövedéki adó
Mivel az üzemanyag jövedéki termék, pár szóban kitérnék erre is. A jövedéki adózásról a
2003. évi CXXXVII. törvény rendelkezik [6]. Hatályba lépése 2004. május 1., Magyarország
Európai Unióba lépésének napja.
Üzemgazdasági háttér 30
A jövedéki adó az Európai Unió legharmonizáltabb adóneme. Közvetett adó, vagyis az adó
alanya és teherviselője nem ugyanaz a személy. Az adó a központi költségvetést gyarapítja,
évi bevétel nagyjából 800-900 millió forint (nagyobb mértékű, mint a társasági adó).
Jövedéki termékek a következők:
ásványolaj és származékai
alkoholtermék
sör
bor
pezsgő
köztes alkoholtermék
dohánygyártmány
A jövedéki termék előállítása, behozatala adóköteles tevékenység, szabad forgalomba csak az
adó megfizetése után hozható. Adóköteles jövedéki terméket előállítani csak adóraktárban3
lehet, adó megfizetése nélkül tárolni csak adóraktárban vagy adómentes felhasználó üzemében
lehet. Az adó alapját a termék mennyisége képezi, bizonyos mennyiség után kell adót fizetni.
3.5. Bizonylatok
A szinkronizálandó adatok legnagyobb halmazát a bizonylatok adják. A bizonylatoknak négy
halmazát különböztetjük meg: a készletgazdálkodással, a gyártással, a beszerzéssel, valamint
az értékesítéssel kapcsolatos bizonylatokat. Ebben a fejezetben őket fogom ismertetni.
3.5.1. Készletgazdálkodás
A készletgazdálkodás két részből áll: a készletek felügyelete, valamint a nem partnerhez
köthető készletmozgások. Ajánlat vagy vevői rendelés készítésekor egy felhasználó ellenőrzi a
készleteket, és ez alapján készül az adott cikkre beszerzési döntés vagy adnak ajánlatot a
vevőnek.
Normális esetben készletmozgás csak az SBO-ban keletkezik, a kúton a kútkezelő felel a
készletért.
A készletgazdálkodási tranzakciók beszerzési/értékesítési tranzakciókkal vannak kezelve.
Ezeket az SBO-ban áttárolás vagy anyagkiadás/anyagbevételezés tranzakciókkal kezeljük:
3„az a fizikailag (pl. fallal, kerítéssel, mérési ponttal) elkülönített, – a terméktávvezeték adóraktár és a
kikötői adóraktár kivételével – helyrajzi számmal beazonosított, egy technológiai egységet képező
üzem, raktár, továbbá a 72. § (2) bekezdés a) pontja szerinti helyen kialakított üzlethelyiség a hozzá
tartozó raktárral, ahol az e törvényben meghatározott engedély birtokában jövedéki termék előállítása
folyik, illetve ahol olyan jövedéki termék tárolását, raktározását végzik, amely után az adót még nem
fizették meg” [5]
Üzemgazdasági háttér 31
Áttárolás
o Raktárközi mozgások
Anyagkiadás
o Saját felhasználás
o Leltárhiány
o Üresváltás
o Gyártás
Anyagbevételezés
o Leltártöbblet
o Üresváltás
o Gyártás
Hogy néz ki ez a gyakorlatban? Az áttárolás a raktárak közötti mozgásokat jelenti. Tehát
például van az egyik raktárban (kúton) 1000 liter gázolaj, amit át szeretnék vinni a másik
raktárba. Tudjuk, hogy mindkét kút (és a központ is) fel van véve a partnertörzsben vevőként
és szállítóként.
A WinPetrol rendszerben ekkor keletkezik egy kimenő bizonylat, ahol a 2. kút a vevő, a
fizetési mód pedig B, vagyis belső felhasználás. Az interfész ilyenkor egy áttárolást hajt végre
az 1. kút raktárból az UTON raktárba (kitárolás). Ez a bizonylat a WinPetrolban sztornózható,
sztornózáskor az interfész kikeresi az eredeti bizonylatot, és visszahelyezi az UTON raktárból
a kút raktárába.
Amikor az áru megérkezik a 2. kútra, beszerzési bizonylat rögzül a kitárolásra hivatkozva.
Amikor az SBO interfész megkapja ezt a bizonylatot, akkor újabb áttárolást rögzít, ezúttal az
UTON raktárból a 2. kút raktárba.
Saját felhasználás is lehetséges, ehhez a cég szintén definiálva van technikai vevőként. Itt is B,
vagyis belső felhasználás lesz a fizetési mód, az interfész ilyenkor anyagkiadás tranzakciót
készít. Ez az anyagkiadás nem készít naplókönyvelést, ezeket a bizonylatokat a könyvelőnek
kell a megfelelő módon lekönyvelnie.
A leltár a készletellenőrzés utáni korrekciókor készített bizonylat. A cég a nem
üzemanyagtermékeket havonta leltárazza mindegyik kúton, a leltár eredménye a WinPetrolban
azonnal rögzítésre kerül (leltárhiány vagy leltártöbblet).
Az üzemanyag leltárazására bizonyos cégek, hatóságok jogosultak. A tartályok tisztításakor
történő üledékeltávolítást, valamint a NAV ellenőrzéskor jegyzőkönyvben rögzített eltérést is
leltárral kezelik. A WinPetrol a leltárt beszerzési bizonylatként (pozitív vagy negatív
mennyiségekkel) kezeli, a fizetési mód vagy L, vagy a szállító a NAV (korábban VPOP).
Üzemgazdasági háttér 32
Ezekkel a paraméterekkel azonosítja az interfész a bizonylatot, és anyagkiadás vagy
anyagbevételezés tranzakciókon rögzíti.
Az utolsó pont az üresváltás. Üresváltás a kútoszlop karbantartásakor történik: a karbantartó
kienged x liter üzemanyagot, majd ezt visszatölti a tartályba. Ilyenkor értelemszerűen készül
egy eladási bizonylat (hiszen az üzemanyag-kiadás ténye felkerül a kasszára), viszont rögtön
készül egy ugyanilyen értékű beszerzési tranzakció is. A bizonylatot üresváltás fizetési móddal
küldi a WinPetrol az SBO interfésznek, ami szintén üresváltás jellel ellátott anyagkiadás és
anyagbevételezés tranzakciókat készít.
3.5.2. Gyártás
A kúton történik üzemanyagtermék gyártása is. Ehhez saját adalékanyagokat használnak,
valamint felhasználják a beérkezett dízel és benzin üzemanyagokat alapanyagként.
A WinPetrol rendszer ezt a folyamatot is értékesítési és beszerzési bizonylatokként képezi le, a
fizetési mód ezúttal G (gyártás). Az SBO interfész anyagbevételezés és anyagkiadás
bizonylatokat rögzít.
A késztermék lehet standard áras, de az ár meghatározása történhet a komponensek utolsó
beszerzési árának alkalmazásával is.
3.5.3. Beszerzés
A beszerzési folyamat első lépése a beszerzési rendelés. A beszerzési rendelést központilag
adja le a beszerző ügyelve arra, hogy a következő feltételeknek teljesülniük kell:
Minden kútra (raktárra) önálló beszerzési rendelés készül. Rendszerszinten nem
tudjuk ellenőrizni, hogy a bizonylat ne hivatkozzon több raktárra, ezért a
felhasználónak kell ügyelnie arra, hogy a bizonylat rögzítésekor raktáranként
készítsen rendelést.
Az egy kútra rendelt üzemanyagokat is külön bizonylaton kell rögzíteni. Ha a
felhasználó mégsem így tenne, akkor egy beállítás alkalmazásával az SBO standard
eljárással képes külön bizonylatokat képezni a raktárak alapján.
A szállítótól kapott visszaigazolási számot utólag rögzíteni kell a bizonylat szállítói
referenciaszám mezőjében.
Ekkor (ha ismert) a beszerzési árat is aktualizálja. Az üzemanyagok beszerzési árai a
szállítási módtól is függnek: más kedvezményt ad a beszállító, ha saját szállítással
rendelnek, mint ha a beszállító szállít. A szállítástól függő kedvezményeket egy külön
táblában tároljuk, amit folyamatosan karban kell tartani. Időszaki és mennyiségi
kedvezményeket nem kezelünk.
Üzemgazdasági háttér 33
A szállítókhoz tartozó hitelkeretet is nyilván tartjuk. A beszerzési rendelésen egy felhasználói
mezőben a szállító kiválasztása után megjelenítjük az adott szállítóhoz tartozó hitelkeretből
fennmaradt összeget (tehát a teljes hitelkeret és a szállítóhoz tartozó nyitott megrendelések és
nyitott számlák különbözete). Végül az SBO interfész leküldi a kutakra a rájuk vonatkozó
nyitott rendeléseket.
A beszerzési folyamat következő lépése az árubeérkezés, ami a kúton történik. Az
árubeérkezést a kutas vagy az SBO-tól kapott beszerzési rendelésre hivatkozva rögzíti a
WinPetrol rendszerben, vagy (csak nem üzemanyag esetében) ad hoc módon készíti. Ad hoc
árubeérkezés csak nem üzemanyag termék esetében lehetséges, és a bizonylaton kötelező árat
megadni.
Ha üzemanyagról van szó, a kutas a tényleges mennyiséget veszi készletre az 15°-os névleges
mennyiség megjelölésével.
2003. évi CXXVII. törvény, 51. §
(1) Az adó alapja az ásványolaj mennyisége, az adómértéknél megjelölt
mennyiségi egységben mérve.
(2) Ha az adómértéknél megadott mennyiségi egység liter, akkor azt + 15 °C-ra
átszámított térfogaton kell megállapítani. Az ásványolaj +15 °C hőmérséklethez
tartozó térfogatát a mérésügyről szóló 1991. évi XLV. törvény előírásainak
megfelelően az MSZ ISO 3675 vagy az MSZ ISO 3838 jelű, a kőolajtermékek
sűrűségének meghatározására vonatkozó szabványokban idézett MSZ ISO 91–1
szabványban ismertetettek szerint (csőkészlet esetén számítással) kell
meghatározni. [6]
Az árubeérkezést a hivatkozott beszerzési rendelés számával együtt a WinPetrol átadja az
SBO-nak, ahol bejövő számla készül belőle. Üzemanyag esetén az SBO az egységárat a
névleges mennyiség alapján számolja ki, a számlán pedig már ez az összeg fog szerepelni. A
hivatkozott beszerzési rendeléseket lezárjuk, erre több árubeérkezést már nem lehet majd
készíteni.
A WinPetrolban az árubeérkezés módosítható, ilyenkor újra felküldi az SBO-nak a módosított
bizonylatot, hivatkozva az eredeti bizonylatra. Az SBO ekkor készít egy szállítói visszárut az
eredeti bizonylatból, majd rögzíti a módosított bizonylatot. Ha ilyen sorszámú nyitott
árubeérkezés nincs, az azt jelenti, hogy már lett könyvelve bejövő számla az adott bizonylatra.
Ilyenkor lerögzíti az új bizonylatot, és a megjegyzés mezőben rögzíti, hogy zárt árubeérkezés
lett módosítva.
Üzemgazdasági háttér 34
Árubeérkezés után következik a bejövő számla. A rendszerben cikk (vagyis törzsesített) és
szolgáltatás típusú bizonylatok kezelhetők. Cikk típusú bizonylatok az árubeérkezésre
hivatkozva automatikusan könyvelhetők, míg szolgáltatás típus esetén egy rövid leírás
megadása szükséges a bizonylatsorokban, valamint meg kell adni a főkönyvi számla számát is,
amire a bizonylat könyvelődni fog (ilyen számlák rögzítéséhez számviteli tudás is szükséges).
A hibás számlákat kétféleképpen lehet korrigálni:
Beszerzési helyesbítő számlával: mennyiségi vagy összegbeli korrekciót jelent
Beszerzési jóváírással: negatív előjelű sztornó, a teljes számlát visszavonja
Az SBO-ban az interfész által rögzített árubeérkezés bizonylatot a bejövő papíralapú
számlával manuálisan összevetik. Ha a két bizonylat megfelel egymásnak, az árubeérkezésre
hivatkozva a felhasználó bejövő számlát rögzít, ami a megfelelő főkönyvön le is könyvelődik.
Ezután a számla nyitott, kifizetendő tételként jelenik meg.
Ha a két bizonylat közt eltérés van, a számlát nem szabad lekönyvelni, hanem beszerzési
rendelést kell indítani az SBO-ban. Ekkor a WinPetrol rendszerben helyesbítő árubeérkezés
készül: a hibásan felvett cikk negatív, az esetleges új cikk pozitív mennyiségekkel jelenik meg
rajta. Negatív mennyiségű cikk esetén átadja, hogy a korrigált bizonylatnak melyik sorára
hivatkozik, ebből pedig az interfész az adott árubeérkezésre hivatkozva szállítói visszárut
készít.
3.5.4. Értékesítés
Az értékesítési folyamat az SBO vevői ajánlat bizonylatával indul, majd a vevői rendeléssel
folytatódik. A vevői rendelés után a WinPetrol rendszer veszi át a folyamatot, ugyanis a
készletmozgással járó tranzakciók (szállítás, számla) forrása már a WinPetrol. A WinPetrolban
bármely típusú számla létrejöhet, az SBO-ban csak gyűjtő.
A gyűjtő számla egyfajta egyszerűsített számlaformátum, ahol a sorokat cikkszámokra
szummázva tüntetjük fel. Egy egyszerű példa: a szerződött partner egy hónapban tankolt
ötször 100 l gázolajat és háromszor 50 l 95-ös benzint. A sofőr a kúton csak szállítólevelet
kap, a számlát hó végén állítjuk ki a nyolc szállítólevélből. A számlán ekkor nyolc sor lenne,
mindegyikben feltüntetve a 100 l gázolaj illetve az 50 l benzin. A gyűjtő számlán ehelyett
mindössze két sor szerepel: az 500 l gázolaj, és a 150 l benzin.
3.5.4.1. Vevői ajánlat
Az előbb a vevői ajánlattal kezdtem az értékesítési folyamatot, de a gyakorlatban jellemzően
nem ezzel kezdjük a (időnként ugyan előfordul). Az egyedi ajánlaton az ár a vevőhöz rendelt
árlista alapján kalkulálódik. A vevői ajánlatokat nem szinkronizáljuk.
Üzemgazdasági háttér 35
3.5.4.2. Vevői rendelések
Szerződött vevők esetén alkalmazzuk, akik számára lehetséges a kiszállítás is. Ennek a
folyamata a következő:
Kedvezmény esetén a szerződött kedvezmény rögzítésre kerül.
A rendelésfelvevő rögzíti a rendelést. Rendelést csak raktáranként szabad rögzíteni
(erre a felhasználónak kell ügyelnie).
Az SBO interfész a nyitott rendelés adatokat kutanként továbbítja a WinPetrolnak. Az
esetleges tudnivalókat a kutas számára a megjegyzés rovatban kell feltüntetni (pl.
számlára, szállításra vagy időpontra vonatkozó tudnivalók)
A nyitott rendelések fuvarozását egy erre kijelölt fuvarszervező szervezi meg. Előfordulhat,
hogy a megrendelő a saját telephelyére kéri a megrendelt árut, ilyenkor meg kell szervezni a
kiszállítást. Ha a megrendelő maga kívánja elszállítani a megrendelt termékeket, akkor
biztosítani kell, hogy a szükséges mennyiség a kúton rendelkezésre áll. Ebben az esetben a
kutas közreműködése is szükséges lehet nagy mennyiségű üzemanyag vételezése esetén, mivel
a kútoszlop 1000 liter üzemanyag kiadása után lekapcsol.
Ez nem volt mindig így. Voltak, akik kihasználták, hogy a kútoszlop számlálóján a
megjeleníthető számok a [0, 1000) intervallumba esnek: 2007-ben Gyöngyösön
megtörtént, hogy egy busz csomagterében hordókat helyeztek el, és olyan
mennyiségű üzemanyagot töltöttek bele, hogy a számláló lenullázódott, így a
ténylegesen kitöltött üzemanyag árának töredékét fizették csak [7].
A kutas ezért folyamatosan, többnyire részletekben szolgálja ki a vevői rendelést, majd,
amikor látja, hogy az igényelt mennyiséget kiadta, bezárja a nyitott rendelést. Az információt
megkapja az SBO interfész, ami aztán bezárja a rendelést az SBO-ban is.
3.5.4.3. Szállítás
Szállítás bizonylat csak a WinPetrol rendszerben keletkezhet. Hiteles szállítólevélnél forintos
kedvezménnyel rendelkező vevők esetében a kutas és az áruátvevő 0 Ft-os szállítólevelet lát
csak, de a WinPetrol a helyes árat adja át az SBO-nak. A szállítólevél a WinPetrolban
sztornózható, ekkor az SBO vevői visszárut könyvel, hivatkozva az eredeti szállítólevélre. A
szállítólevélre hivatkozva a WinPetrolban gyűjtő számla készíthető. Raktáron lévő cikkek
esetén a szállítólevél automatikusan módosítja a készletet
3.5.4.4. Számlázás
A számla törvényileg kötelező érvényű dokumentum, beérkezését követően könyvelések
történnek.
Üzemgazdasági háttér 36
Ha a számla raktáron levő cikkeket értékesít, és nem előzte meg szállítólevél, a számla
kibocsátásával együtt készletmódosítás is történik. Figyelni kell arra is, hogy ha a számlát
ugyan megelőzte szállítólevél, de a számlát a szállítólevélre való hivatkozás nélkül hozzák
létre, akkor hibák léphetnek fel a készletvezetésben, mivel a szállítási mennyiség kétszer lett
könyvelve (hiszen a szállítólevél és a számla rögzítése után is történt könyvelés).
Azok az átutalásos vevők, akik tankoláskor nem kaptak számlát, csak szállítólevelet, olyan
nyugtát kapnak a pénztárgépből, amin a „Hitel” felirat szerepel. Az ilyen vevőknek az SBO-
ból készül számla a WinPetrolból szinkronizált szállítólevelekre hivatkozva. Az ilyen számlák
készítését négy fejlesztéssel támogatjuk:
A számlán a teljesítési idő meghatározását egy addon segítségével végzi a felhasználó.
Egy számlán nem szerepelhet egyszerre üzemanyag és nem üzemanyag.
Számlakészítéskor figyelembe kell venni, hogy üzemanyagokra és kenőanyagokra a
standard fizetési feltétel mellett vonatkozhat más fizetési feltétel. Értelemszerűen egy
számlának csak egy fizetési határideje lehet.
Információként a számlán fel kell tüntetni a végösszeget EUR-ban a legutolsó
érvényes árfolyam alapján.
Ha a vevő a kúton nem kér számlát, akkor is számlát rögzítünk, de egy technikai vevőre – ez
az úgynevezett Nyugtás vevő.
Hibás számlákat a bejövő számlákhoz hasonlóan lehet korrigálni:
Sztornó számla (értékesítési jóváírás)
Kimenő helyesbítő számla
Az SBO-ban csak gyűjtő számlát szabad manuálisan sztornózni. Az értékesítési jóváírás a
tételeket mindig visszateszi készletre, ilyenkor az eredeti szállítólevelet újból létre kell hozni.
A helyesbítő számla csak SBO-s gyűjtő számla esetében, csak értékbeli korrekcióra (pl. ár
módosítása) alkalmazható.
WinPetrolban készített gyűjtő számla sztornó esetén az SBO interfész újra létrehozza az
eredeti szállítólevelet, mivel a WinPetrol sztornó nem veszi készletre a sztornózott cikkeket,
csak a szállítóleveleket állítja újra nyitottra.
Nem gyűjtő, hivatkozás nélküli számlák csak a WinPetrol rendszerben keletkeznek. Az SBO-
ban az interfész hozza őket létre, létrehozásuk készletmozgással jár. Csak a kúton
sztornózható, az eredeti számlára való hivatkozással (a sztornó is készletmozgással jár).
Üzemgazdasági háttér 37
A WinPetrolban készített gyűjtő számla a WinPetrolban összevontan kezeli a cikkeket, de az
SBO interfésznek kibontva adja át a tételeket, vagyis a teljes szállítólevél-tartalom látszik. Az
SBO-tól kimenő szinkronban szerepel az utolsó 7 napon gyűjtő számlába foglalt
szállítólevelek sorszáma és a hivatkozó SBO számla száma. Innen tudja a WinPetrol, hogy az
adott szállítólevél már nem számlázható.
Az SBO-ban gyűjtő számla készítésekor figyelni kell arra, hogy minden szállítólevél teljesen
le legyen szállítva. Gyűjtő számlát csak meglévő szállítólevélre hivatkozva szabad készíteni.
SBO és benzinkúti rendszer integrációja 38
4. SBO és benzinkúti rendszer integrációja
4.1. Interfész konfiguráció
Az ügyfél benzinkútjain a Windows alapú WinPetrol rendszer üzemel, amit a gyártó, a
SólyomSoft Szoftverfejlesztő Kft. [8] üzemelteti.
Az interfész rugalmasságát egy sor paraméter biztosítja, ezeket felhasználói táblákban
tároljuk. Induláskor az interfész ellenőrzi, hogy ezek a táblák léteznek-e, s ha nem, akkor
létrehozza őket.
A konfigurációs táblák a következők:
4.1.1. Kutak definíciói
Tábla neve: [@KUTAK]
Ebben a táblában tároljuk az egyes kutak definícióit (jelenleg két benzinkút van). A következő
adatokat tároljuk:
U_CARDCODE: a szinkronizáció miatt szükség lehet az üzleti partnereknek a
WinPetrol rendszerbeli partnerkódjának eltárolására. Ebben a mezőben tároljuk annak
az OCRD (SBO partnertörzs) táblabeli felhasználói mezőnek a nevét, melyben az
ehhez a kúthoz tartozó partnerkódot tároljuk.
U_ITEMCODE: hasonlóan a cikkeknek az adott kúton lévő cikkszámát tároljuk
ebben, az OITM (cikktörzs) táblabeli felhasználói mezőben.
U_CREDITCARD_ACCT: a hitelkártyás fizetés főkönyvi számla. Erre a főkönyvi
számlára könyveljük a hitelkártyás fizetéseket.
U_ID: a kút azonosítója
U_INVSER: mindegyik kútnak saját számlázási számköre van.
U_OWNCUST: saját vásárló kód. A kutak között történhet készletmozgás, ilyenkor a
vevő kút OWNCUST kódja, és a szállító kút OWNSUPP kódja jelenik meg a
számlán.
U_OWNSUPP: saját szállító kód.
U_PENZTAR: pénztár főkönyvi számla.
U_PREFIX: fájlnév prefix (l. 4.2).
U_PRICELIST: a kúthoz tartozó árlista. Mindegyik kútnak van saját árlistája.
U_WHSCODE: a kút raktárkódja. Mindegyik kút külön raktárként van számon tartva.
4.1.2. Csomagok
Tábla neve: [@TRANZAKCIOSZAMOK]
SBO és benzinkúti rendszer integrációja 39
Ebben a táblában tároljuk a kutakról érkezett utoljára feldolgozott csomagok számát. Két
mezője van csupán:
U_ID: kút azonosítója.
U_UTOLSOCSOMAG: az adott kútról utoljára feldolgozott csomag száma.
4.1.3. Fizetési mód kódok
Tábla neve: [@WINWINPETROLFIZMOD]
Az SBO és WinPetrol fizetési módok egymásnak való megfeleltetése.
U_GROUPNUM: SBO fizetési mód
U_GRPNAME: SBO fizetési mód neve
U_WPFIZMOD: WinPetrol fizetési mód
4.1.4. Időzített árszinkron
Tábla neve: [@IDOZITETTSZINKRON]
Ebben a táblában definiálhatunk időzített árszinkronizációt (l 3.3. fejezet). A beállított
cikk/cikkcsoport ára a kívánt időpontban szinkronizálódik le a beállított kútra.
U_ITMSGRCD: cikkcsoport kódja
U_ITEMCODE: cikkszám
U_SZINKRONDATUM: kívánt szinkron dátum
U_SZINKRONIDO: kívánt szinkron idő
U_UTOLSOSZINKRON: utolsó szinkron
U_ID: kút azonosító
Technikailag az adatbázis képes lenne a dátumot és időt egy DATETIME mezőben tárolni,
gyakorlatilag azonban ezt nem tudjuk megtenni, ezért kell külön dátum és idő mező, ahol az
idő egy smallint típusú mező.
4.1.5. Speciális üzleti partnerek
Tábla neve: [@SPECIALISPARTNEREK]
A speciális üzleti partnerek (l. 3.2.1) partnerkódját és -nevét lehet ebben a táblában megadni.
U_CARDCODE: partnerkód
U_OWNCOMPANY: saját cég (Y/N)
U_CARDNAME: partnernév
A saját partnerek (pl. kutak, központ) esetén az U_OWNCOMPANY mezőt Y-ra állítjuk.
SBO és benzinkúti rendszer integrációja 40
4.1.6. Paraméterek
Tábla neve: [@IF_PARAM]
U_PARAMETER: Paraméter értéke
Ebben a táblában tárolunk különféle paramétereket, melyek szükségesek az interfész
működéséhez. Néhány fontosabb ezek közül:
1. BEJOVO: bejövő fájlok elérési útja
2. KIMENO: kimenő fájlok elérési útja
3. SZINKRON: szinkronizáljon-e vagy sem (Y/N)
4. SZINKRONIDO: a szinkronizálás hány másodpercenként történjen
4.2. Fájlkezelés
Az adatok átadása fájlokban történik, az SBO szerveren FTP szerver üzemel. Az adatokat
típusonként egyszerű szöveges fájlokba (.txt) írjuk, majd a fájlokat zip-el tömörítve
elhelyezzük a megfelelő könyvtárban.
4.2.1. Bejövő fájlok
A tömörített fájlok elnevezése 8.3-as formátumú. A fájlnév első nyolc karaktere a tranzakció
sorszáma (00000000-99999999, a 99999999 után újra a 00000000 következik), a kiterjesztés
első két karaktere a kút prefixe ([@KUTAK].U_PREFIX), az utolsó karakter z. Tehát a
00016899.01z az 01-es kútról érkező 16899-as csomag.
A csomagokat sorban dolgozzuk fel, hogy lehetőleg elkerüljük a negatív készleteket. A bejövő
csomag tranzakciószámát a [@TRANZAKCIOSZAMOK] tábla U_UTOLSOCSOMAG
mezőjében kell rögzíteni. Ha egy új csomag érkezik, megnézzük az U_UTOLSOCSOMAG
mező értékét. Ha az érkező csomag a sorrendben a következő, akkor feldolgozzuk, ha nem,
akkor nem szabad feldolgozni, amíg a hiányzó csomag meg nem érkezik.
A hiányzó csomagot a következőképpen kérhetjük: a KIMENO könyvtárban létrehozunk egy
.XXr kiterjesztésű fájlt (XX: kút prefixe, r: „request”), melynek neve megegyezik a hiányzó
csomag nevével. Vagyis, ha a 03-as kútról jövő 00017681-es csomag hiányzik, akkor a
00017681.03r elnevezésű fájlt helyezzük el a KIMENO könyvtárban. A WinPetrol oldalon
lévő interfész újraküldi a kérdéses csomagot, a request fájlt pedig törli.
Ha hiba történt, és az interfész megakad, ellenőrizzük, melyik csomagnál állt meg, és a
csomagot megelőző sorszámú csomag számát beleírjuk az U_UTOLSOCSOMAG mezőbe.
Így a hiba elhárítása után az újraindult interfész ott folytatja a feldolgozást, ahol abbahagyta.
SBO és benzinkúti rendszer integrációja 41
A .txt fájlokban az egyes mezőket mindkét oldalon határoló jelekkel választjuk el, valamint a
sorok végén is záró karakterek vannak. Olyan karaktersorokat kellett találni, melyek a lehető
legkisebb valószínűséggel fordulnak elő az adatok közt, így esett a választás a következő
határoló jelekre:
Mezőhatároló: #!#
Sorzáró: #!!#
4.2.2. Adatok írása
Az adatok kiírása a következőképpen zajlik:
1. Az adatot txt fájlba írjuk.
2. A fájlt egy ideiglenes zip-el tömörítjük.
3. Az ideiglenes zip fájlt a végleges névre átnevezve a KIMENO könyvtárba helyezzük.
4. A KIMENO könyvtárban létrehozunk egy flag fájlt, melynek neve az új zip fájl
létrehozásának timestampje.
A 3. és 4. lépésben, ha a fájl már létezik, azt felülírjuk.
Az export futás logikája a következő: a KIMENO könyvtárban kutanként külön
alkönyvtárakba kerülnek az exportálandó adatok. Az alkönyvtár elnevezése a kútnak
megfelelő prefix. Mindegyik könyvtárban kezelünk egy process.flg nevű fájlt, aminek
funkciója, hogy mind SBO és WinPetrol oldalon csak akkor kezdődik írás vagy feldolgozás,
ha ez a fájl létezik. Tehát SBO oldalon a következő történik:
Mindegyik alkönyvtárban megnézzük, van-e process.flg.
Ha van:
o Töröljük.
o Az exportált adatokat a prefixnek megfelelő alkönyvtárba másoljuk.
o Létrehozzuk a process.flg-t, beleírjuk, hogy SBO:<dátum>
Ha nincs, akkor a túloldal feldolgoz, tehát nem nyúlunk a fájlokhoz.
4.3. Szinkronizálandó adatok
A két rendszer között értelemszerűen nem szinkronizálunk minden adatot, és a kutak sem
mindig egyforma adatokat kapnak.
4.3.1. Kimenő adatok
Vannak kútfüggő és globális adatok. Az alábbi táblázatban a szinkronizálandó adatok, és a
fájlok nevei láthatók:
SBO és benzinkúti rendszer integrációja 42
Adat Fájlnév Tömörített fájl neve
Üzleti partnerek (globális) bp.txt bp.zip
Üzleti partner szállítási címek (globális) address.txt address.zip
Üzleti partnerek (kútfüggő) xxbp.txt xxbp.zip
Cikktörzs (globális) item.txt item.zip
Cikktörzs (kútfüggő) xxitem.txt xxitem.zip
Árak (kútfüggő) xxprices.txt xxprices.zip
Kedvezmények (globális) discount.txt discount.zip
Beszerzési rendelések (kútfüggő) xxopor.txt xxopor.zip
Vevői rendelések (kútfüggő) xxordr.txt xxordr.zip
Lezárt szállítólevelek (kútfüggő) xxodln.txt xxodln.zip
Speciális ÜP kódok (globális) speccard.txt speccard.zip
Üzenetek (kútfüggő) xxmsg.txt xxmsg.zip
A kútfüggő adatok csak az adott kútra szinkronizálódnak. Az ezeknél látható „xxbp.txt”
formátumú fájlnevekben az xx az adott kúthoz tartozó prefix. Tehát a 01bp.txt a 01-es
prefixszel rendelkező kútra szinkronizálandó kútfüggő üzleti partner törzsadat. A globális
adatok minden kútra szinkronizálódnak.
További fejlesztési tervek 43
5. További fejlesztési tervek
Az ügyfélnél a rendszer bevezetése megtörtént, a két rendszer közötti integráció
működőképes, folyamatosan használatban van. Mivel a rendszer üzemeltetését is mi végezzük,
folyamatosan kapcsolatban vagyunk velük, és előfordulnak új igények.
Jelenleg két további fejlesztés van folyamatban:
Kártyák kezelése
A partnerkártyákhoz létrehozunk kártyakategóriákat, melyek feladata a kártyák
használhatóságának korlátozása. Azaz, a kártyával csak bizonyos cikkeket,
cikkcsoportokat lehessen vásárolni (pl. a teherautósofőr tudjon tankolni meg
ablakmosó folyadékot venni, de üdítőt és édességet már ne). A kártyakategóriákhoz
hozzárendelünk cikkcsoportokat és/vagy cikkeket, majd minden kártyát besorolunk
egy (vagy akár több) kártyakategóriába.
Üzenetküldés
Felmerült az igény arra, hogy bizonyos feltételek teljesülése esetén az ügyfeleknek e-
mailben értesítéseket küldjenek (például, ha az ügyfél felhasznált hitelkerete eléri a
szerződésben foglalt hitelkeret 70%-át, vagy a kiegyenlítetlen számlák összege
meghalad egy adott összeget). Ehhez szükség van magának a feltételnek a
definiálására, illetve egy levélsablonra, mely a megfelelő paraméterek átadásával az
ügyfél ide vonatkozó adataival legenerálja a kívánt körlevelet.
Az interfész addon elkészítése óta sok hasznos tapasztalatot szereztünk az integrációval
kapcsolatban. Az SBO azóta túl van több patchen, sőt a 2013. májusában megérkezett új, 9.
verzió is kínál számos újdonságot. Ezért a távolabbi jövőre nézve tervben van az interfész
átdolgozása is, főleg, ha az ügyfél esetleg upgrade-eltetni szeretné az SBO rendszerét.
Összefoglalás 44
Összefoglalás
Diplomatervemben egy SAP Business One rendszer és egy benzinkúti rendszer integrációját
ismertettem. Munkám első fejezeteiben bemutattam az integrált vállalatirányítási rendszereket,
azon belül is részletesebben az SAP Business One-t, annak moduljait, fejlesztői eszközeit.
Ismertettem a rendszer üzemgazdasági hátterét, végül pedig a két rendszer, az SAP és a
WinPetrol közötti interfész működését, az export és import logikát. Bemutattam az
adatstruktúrákat, melyeket a két rendszer átad egymásnak, és az interfész paraméterezését.
A tanácsadói munka rendkívül széles látókört igényel, ami nem hátrány egy fejlesztőnél sem.
Mivel én még csak nemrég kezdtem el az SBO-val foglalkozni, nagyon hasznos volt
számomra látni, hogyan működik egy ilyen rendszer. Mivel a rendszert most is mi
üzemeltetjük, folyamatosan ellenőrizni kell a működését, javítani kell az esetleges hibákat, és
támogatni a felhasználókat. Ilyenkor nagy segítséget jelent, ha az ember átlátja a folyamatokat
és a logikát.
Jelenleg is folyamatban van két addon fejlesztése, melyek ugyan közvetlenül nem
kapcsolódnak a WinPetrol integrációhoz, mégis hasznos dolog ismerni hozzájuk a rendszerben
lévő többi folyamatot. Nem beszélve arról, ha egyszer majd valóban aktuális lesz az interfész
átdolgozása az újabb technológiák felhasználásával.
Köszönetnyilvánítás 45
Köszönetnyilvánítás
Köszönöm a sok segítséget a T-Systems SBO-s csapatának: Balázs Andrásnak, Tóth
Ádámnak, Pribék Ádámnak, Madarász Ákosnak, Hamarák Istvánnak, Karner Zoltánnak, de
leginkább konzulensemnek, Hernádi Bálintnak.
Köszönöm Vető Istvánnak a belső konzulensi szerep elvállalását, valamint Kiss Tímeának és
Kurczina Gergőnek a támogatást és bíztatást, akik nélkül ez a dolgozat soha nem készült volna
el.
Irodalomjegyzék 46
Irodalomjegyzék
[1] T. F. Wallace és M. M. Kremzar, ERP: Making It Happen – The Implementers’ Guide to
Success with Enterprise Resource Planning, New York: John Wiley & Sons, Inc., 2001.
[2] Magyar Könyvvizsgálói Kamara, „Adatexport útmutató,” [Online]. Available:
http://www.mkvk.hu/kamarai/kozlemenyek/adatexport. [Hozzáférés dátuma: 7. június
2013.].
[3] Nemzeti Adó- és Vámhivatal, „Nemzeti Adó- és Vámhivatal,” 2013.. [Online]. Available:
http://nav.gov.hu. [Hozzáférés dátuma: 14. május 2013.].
[4] J. Hetyei, ERP rendszerek Magyarországon a 21. században, 2. kiadás, Budapest:
ComputerBooks, 2009.
[5] SharpDevelop, „SharpDevelop @ic#code,” [Online]. Available:
http://www.icsharpcode.net/opensource/sd/. [Hozzáférés dátuma: 10. június 2013.].
[6] Nemzeti Adó- és Vámhivatal, „2003. évi CXXVII. törvény a jövedéki adóról és a jövedéki
termékek forgalmazásának különös szabályairól,” [Online]. Available:
http://www.njt.hu/cgi_bin/njt_doc.cgi?docid=76336.242345. [Hozzáférés dátuma: 8.
június 2013.].
[7] Népszava online, „Lebukott két üzemanyagcsaló,” 10. augusztus 2007.. [Online].
Available: http://www.nepszava.hu/articles/article.php?id=28372. [Hozzáférés dátuma: 10.
június 2013.].
[8] SólyomSoft Szoftverfejlesztő Kft., „SólyomSoft Szoftverfejlesztő Kft. honlapja,” [Online].
Available: http://www.solyomsoft.hu/. [Hozzáférés dátuma: 9. június 2013.].
