SAP Business One és benzinkúti rendszer integrációja

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.

2.

Integrált vállalatirányítási rendszerek ................................................................................. 8 1.1.

Az ERP kialakulása .................................................................................................... 8

1.1.

ERP bevezetése ........................................................................................................ 11

SAP Business One ............................................................................................................ 13 2.1.

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.

3.

SAP Business One .................................................................................................... 13

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

Üzemgazdasági háttér ....................................................................................................... 25 3.1.

Cikktörzs, készletgazdálkodás .................................................................................. 25

3.1.1. 3.2.

Raktárak ............................................................................................................ 26

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

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. 5.

4

Kimenő adatok.................................................................................................. 41

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 üzemanyagkereskedelmi 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.


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 

Mit gyártunk?



Mire van szükségünk?



Mink van?



Mit kell beszereznünk?

10

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ásanalizálás és más funkciók hozzáfejlesztésének eredményeként jött létre a zártláncú (closedloop) 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.


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


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 R2t. 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 PL07es, 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ó:

2



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)

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:


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.


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).


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.


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 

Áttárolás o





31

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).


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.


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.


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.


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.


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 SBObó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 SBOban 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).


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]


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.


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.


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:

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:


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 emailben é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.].

SAP Business One és benzinkúti rendszer integrációja

Recommend Documents