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 ü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.
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á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.
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ákban 1 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 ppm 2 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.