XML és EDI alapú integrációs kapcsolat kialakítása SAP Business One rendszer és a kereskedelmi partnerek között.

Átírás

1 XML és EDI alapú integrációs kapcsolat kialakítása SAP Business One rendszer és a kereskedelmi partnerek között. Pázmány Péter Katolikus Egyetem Információs Technológiai Kar Mérnök informatikus MSc Buzsáky Andrea Témavezető: Hernádi Bálint Budapest, 2013.

2 Nyilatkozat 2 Nyilatkozat Alulírott Buzsáky Andrea, a Pázmány Péter Katolikus Egyetem Információs Technológiai Karának 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

3 Tartalomjegyzék 3 Tartalomjegyzék Nyilatkozat... 2 Tartalomjegyzék... 3 Tartalmi összefoglaló... 5 Abstract Bevezetés Integrált vállalatirányítási rendszerek Az ERP kialakulása Üzleti előnyök SAP Business One Az SAP története SAP Business One Addonok Integrációs technológiák XML EDI Integrációs feladatok ismertetése ÁNYK adatexport EDI alapú dokumentumcsere Feladat megvalósítása: ÁNYK adatexport Felhasználói interfész Lekérdezés Adatfeldolgozás XML export XML fájl mentése Feladat megvalósítása: EDI alapú dokumentumcsere Felhasználói interfész Adatok lekérdezése és feldolgozása Számlák elküldése... 46

4 Tartalomjegyzék 4 Összefoglalás és kitekintés Köszönetnyilvánítás Rövidítések jegyzéke Irodalomjegyzék... 50

5 Tartalmi összefoglaló 5 Tartalmi összefoglaló Az informatika egyre nagyobb szerepet játszik életünkben. Szinte észrevétlenül lopódzott be otthonainkba, munkahelyeinkre, segíti mindennapjainkat, és már-már elképzelhetetlennek érezzük, hogyan is lehettünk meg nélküle. Nem csak a mi életünkben, a vállalatoknál is nélkülözhetetlen a számítógépek használata, és ma már nem elég ehhez néhány Excel tábla és egy cím. Olyan eszközre van szükség, ami egymaga képes kezelni a vállalat minden egyes folyamatát, tárolni az összes adatot, és szükség esetén ezekből az adatokból információt tud kinyerni. Ebben segítenek az integrált vállalatirányítási rendszerek, mint például az SAP Business One, amiről ebben a dolgozatomban írok. Ezeknek a rendszereknek nagy ereje, hogy amellett, hogy lefedik a vállalatirányítás szinte valamennyi területét, további modulok beillesztését is lehetővé teszik. Az SAP Business One-hoz is létezik fejlesztői eszköz, mellyel ezt megtehetjük, a következőkben erre mutatok két példát. Két olyan modul, úgynevezett addon fejlesztését mutatom be, mely lehetővé teszi, hogy az SAP Business One-on kívüli rendszerekkel integrálódjunk: egy XML fájl exportját, amit aztán a Nemzeti Adó- és Vámhivatal által kiadott ÁNYK programba importálhatunk, illetve egy gyártó és kereskedő közötti EDI alapú számlaküldést.

6 Abstract 6 Abstract Information technology is playing a greater and greater role in our lives. It sneaked into our homes, workplaces, helps us in our everyday life, and today we cannot even understand how we could have lived without our gadgets. Not only in our lives are computers essential, but in companies as well, and managing a few spreadsheets in Excel and having a company address is not enough. We need more. We need a tool that can manage each process of our company, store every data, and is able to transform these data into information. This is where enterprise resource planning systems can help. In this thesis I focus on SAP Business One enterprise resource planning system. One of the great power of these systems besides covering almost each scope of the company management is that they allow integration of external modules. The SAP Business One as well has a development kit that makes the development of such modules (so called addons) possible. In my thesis, I present two addons. These two addons help the integration with two external systems: the first one lets you export an XML file, which can be imported into the ÁNYK software provided by the National Tax and Customs Administration of Hungary, the other one is an EDI-based integration between a manufacturer and a vendor.

7 Bevezetés 7 1. Bevezetés Évtizedek óta tudjuk, hogy az üzleti életben az informatika használata jó szolgálatot tesz, s mára már egyenesen elkerülhetetlenné vált. A számítógépek elterjedése óta használjuk őket, a legkülönbözőbb felmerülő feladatokra is szoftverek készültek. A globalizáció, a piacok integrálódása, a világkereskedelem fejlődése, és az egyre gyorsabb technológiai fejlődés egyre erősödő piaci versenyt eredményez. A piac gyorsan változik, szinte másodpercenként következnek be olyan események, melyekre azonnal kell reagálni, pillanatok alatt jelennek meg új és új vállalatok, vállalatbirodalmak, és ugyanilyen gyorsan tűnhetnek is el. Gyors, rugalmas reakciókra van ezért szükség, azonnal fel kell tudni mérni a piac és saját vállalatunk helyzetét, s ennek tudatában kell meghoznunk döntésünket, mely saját jövőnket is meghatározza. Nem mindegy tehát, milyen gyorsan, és mennyire átfogóan tudjuk felmérni saját vállalatunk aktuális helyzetét. Ebben segíthetnek az integrált vállalatirányítási (ERP) rendszerek, melyek feladata a vállalatok integrált működésének, a rugalmasabb, áttekinthetőbb üzleti folyamatok támogatása. Ezáltal a vállalat a piacon fontos üzleti előnyökre tehet szert, többek között a jobban előkészített, megalapozott vezetői döntéseknek köszönhetően. Ilyen vállalatirányítási rendszereket több fejlesztőcég is készít, ezek közül is ERP rendszerek terén piacvezető a német SAP AG. Több megoldást is kínál, melyek közül a legmegfelelőbb kiválasztásával, majd az igényeknek megfelelő testre szabásával a lehető legjobb támogatást nyújthassa a vállalatvezetés számára. Kis- és középvállatoknak ajánlott megoldása az SAP Business One, mellyel én is foglalkozom beszámolóm során. Az ERP rendszerek sokoldalúak, de az iparági sajátosságok miatt szükség lehet új funkciókkal való bővítésre. Erre az SAP Business One-nak létezik fejlesztői eszköze, melyben Visual Basic, illetve C# nyelven lehet fejleszteni. Munkám során én C# nyelven dolgoztam. Két fejlesztésről fogok írni, mindkét esetben egy-egy külső rendszerhez való integrációról volt szó. Az egyik egy, a Nemzeti Adó- és Vámhivatal (NAV) Általános Nyomtatványkitöltő Programjához (ÁNYK) való adatexportálás XML formátumban, a másik egy összetettebb feladat, a partner és ügyfele közötti EDI alapú adatcsere megvalósítása. Szakdolgozatomban először áttekintem az integrált vállalatirányítási (ERP) rendszereket, külön kiemelve az általam is ismert SAP Business One-t (SBO). Ezután részletezem az integrációs lehetőségeket és a felhasználható technológiákat, itt is kiemelve az EDI-t és az XML-t. Majd ismertetem a konkrét megoldandó feladatokat, ezek háttereit, az üzleti folyamatot. Végül bemutatom az elkészült megoldást.

8 Integrált vállalatirányítási rendszerek 8 2. Integrált vállalatirányítási rendszerek Amit magyarul integrált vállalatirányítási rendszernek hívunk, angolul Enterprise Resource Planningnek, rövidítve ERP-nek neveznek. Jelentése vállalati erőforrás-tervezés, ami jól leírja az ERP legfontosabb feladatát: a vállalat napi, rövid- illetve középtávon a működéséhez szükséges (humán, technikai, pénzügyi és egyéb) erőforrások tervezése. Az ERP nem szoftver. Az ERP egy több modulból álló szoftvercsomag, melynek moduljai egymásra épülnek, együtt dolgoznak, kommunikálnak, és ugyanazokat az adatokat használják. Nem minden üzleti alkalmazást nevezhetünk ERP-nek. Vannak olyan vállalati rendszerek, vállalati szoftverek (enterprise system vagy enterprise software, röviden ES), melyek nagyban segítik az erőforrás-tervezést, de magát a tervezést rendszerint nem végzik el. Valamint van egy sor olyan funkciójuk, mely nem erőforrás-tervezés, mint például követelések, kötelezettségek számontartása, ügyfélkapcsolat menedzsment (customer relationship management CRM), emberi erőforrások (human resources HR), stb. Thomas Wallace és Michale Kremzar így írja le az ERP-t [1]: 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 Az ERP kialakulása Az 1980-as és 90-es években kezdődött a személyi számítógépek elterjedése. Hamar felvetődött az egymástól független egységek között a kommunikáció igénye, aminek alapjául létrejött a hierarchikus rendszer. Ahogy nőtt a teljesítmény, az irodai rendszerekben együttműködő munkaállomásokból létrejöttek a hálózatok, majd hamarosan, az internet globális elterjedésével a cégek ki is tudtak lépni az irodák falai közül. Ezeken a globális hálózatokon rengeteg számítógép, szoftver, adatbázis tud egymással kapcsolódni. Napjainkban az információ az egyik legnagyobb, legértékesebb erőforrás. Az első erőforrás-tervező rendszert az IBM fejlesztette az 1960-as években, s ez volt a mai ERP rendszerek alapja [1]. Material Requirements Planningnek, vagyis anyagszükséglettervezésnek (röviden MRP) nevezzük. Célja az alapanyagok megrendelésének felügyelete

9 Integrált vállalatirányítási rendszerek 9 volt, logikája négy kérdésre épült, melyek minden gyártási folyamatban felmerülnek, függetlenül a gyártott terméktől. A négy kérdés a következő: Mit gyártunk? Mire van szükségünk? Mink van? Mit kell beszereznünk? Ezt hívjuk általános gyártási egyenletnek, melyre az MRP rendszer is épül: a késztermék (mit gyártunk?), az alapanyag-szükséglet (mi kell hozzá?) és a raktárkészlet (mink van?) alapján meghatározza a beszerzendő alapanyagok listáját, s ezek mennyiségét (mit kell beszereznünk?). Hamar kiderült azonban, hogy az MRP sokkal többre is képes, mint hogy csupán visszajelzéseket küldjön arról, mely alapanyagokat kell beszerezni a gyártás folytatásához. Funkcionalitásával képes volt a rendelések határidejének és esedékességének tervezését nyomon követni, és összehangolni a gyártási folyamatokkal. Ez a maga idejében óriási áttörés volt, hiszen a gyártás során most először jelent meg egy olyan formális mechanizmus a gyártási folyamatban, amely képes volt a prioritásokat kezelni egy folyamatosan változó környezetben. A rendelések határidejének tartását és a változásokkal való szinkronban tartását hívjuk prioritástervezésnek. Ez azonban nem volt elég. Egy ugyanennyire fontos feladatot még meg kellett oldani, ez pedig a kapacitás volt. A kapacitástervezés feltételei ugyanúgy megvoltak már az MRP-ben is, ahogy az előrejelzés, kereslet-menedzsment, erőforrás-analizálás és sok egyéb funkció, mely fejlesztések eredményeként született meg a zártláncú MRP (closed-loop MRP). Fontos, hogy a zártláncú MRP már nem csak az alapanyag-tervezést támogatja, hanem egy sor egyéb funkcióval is rendelkezik, mint például képes visszajelzéseket adni a gyártási funkciókkal a tervezési funkciók számára, aminek következtében szükség esetén a tervek módosíthatók, így a prioritásokat is képes a körülményekhez képest változtatni. Az 1970-es évektől beszélhetünk az MRP II.-ről, ami már mást jelent: Manufacturing Resource Planning, azaz gyártási erőforrás-tervezés. A zártláncú MRP-ből fejlődött ki, három nagy új funkcióval rendelkezik: Értékesítés és üzemeltetés tervezés Pénzügyi tervezés Szimulációk: a mi lenne, ha kérdések feltevésére kísérelt meg választ adni. A mai, modern tervező rendszerek már rendkívül hatékony és részletes szimulációkat képesek végezni.

10 Integrált vállalatirányítási rendszerek 10 Az 1990-es években érkeztünk el az Enterprise Resource Planninghez, vagyis a vállalati erőforrás-tervezéshez. Alapjai lényegében megegyeznek az MRP II.-ével, azonban az ERP egy sokkal átfogóbb rálátást biztosít az üzleti folyamatokra. Egy, az egész vállalatot átfogó, egyetlen rendszerről beszélünk, mely az értékesítési, gyártási és pénzügyi információkat valósidőben integrálja. A vásárlók és beszállítók által alkotott ellátási láncot az erőforrástervezéssel egészíti ki, ezáltal még pontosabb előrejelzésekre képes. 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 2000-es évektől kezdve beszélhetünk az ERP rendszerek második generációjáról. Ez már nem csak a vállalat belső folyamatait integrálja, hanem kibővíti azt a vevői és beszállítói oldali folyamatokkal, valamint kihasználja az internet adta lehetőségeket is Üzleti előnyök A nagy ERP rendszerek ún. standard szoftverek, vagyis készen lehet őket megvásárolni. Ez egyrészt azzal az előnnyel jár, hogy nem a vásárlónak kell őket kifejleszteni hosszas és költséges munkával nem beszélve arról, hogy mi van akkor, ha a vállalat eleve nem informatikával foglalkozik, és nincs meg sem a megfelelő tudás, sem az erőforrás egy saját rendszer kifejlesztésére. Ugyanakkor, mivel egy elképzelt vállalati modell alapján íródtak meg, nagyon sok standard funkció található benne, amiket a megrendelő számára testre kell szabni. Ma az informatika nélkülözhetetlen ahhoz, hogy egy vállalat versenyképes maradjon a folyamatosan változó piaci körülmények között. A vállalatirányítási rendszer is ennek egy eleme. Átgondoltan bevezetve és jól alkalmazva jelentős előnyökhöz juttathatja a szervezetet. Növeli a szervezet hatékonyságát. Egy ERP rendszer bevezetésekor gyakran kerül sor a vállalat üzleti folyamatainak áttekintésére, racionalizálására. Ez már magában jelentősen növelheti a hatékonyságot. Az integráció következtében a többször elvégzett feladatok (például a többszörös adatbevitel) megszűnnek, mely szintén előnyös: A redundáns adattárolás már magában veszélyforrás és hibalehetőség, 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 folyamatosan 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. 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.

11 Integrált vállalatirányítási rendszerek 11 Egy ERP rendszer bevezetése nagy változás a vállalat életében, és jelentős kockázattal is jár. A bevezetést a fejlesztő cég egy partnere végzi, mivel a vállalat nem rendelkezik a megfelelő szakemberekkel nincs is rá szüksége. A bevezető cég tanácsadóinak viszont át kell látniuk a vállalat belső folyamatait, ehhez szükség van valakire a vállalattól, aki a tanácsadókkal együttműködve tervezi meg a bevezetést. A leggyakoribb probléma egymás félreértése, ezt a lehető legalaposabb, részletekbe menő megbeszélésekkel lehet csak megelőzni.

12 SAP Business One SAP Business One 3.1. Az SAP története Az SAP-t 1972-ben alapította a németországi Waldorfban öt, korábban az IBM-nél dolgozó mérnök (Diermar Hopp, Klaus Tschira, Hans-Werner Hector, Hasso Plattner és Claus Wellenreuther). Az SAP eredetileg a Systemanalyse und Programmentwicklung (System Analysis and Program Development Rendszeranalízis és szoftverfejlesztés) kifejezés rövidítése volt, de később ezt megváltoztatták, és ma már a Systeme, Anwendungen und Produkte in der Datenverarbeitung (Systems, Applications and Products in Data Processing Rendszerek, alkalmazások és termékek az adatfeldolgozásban) kifejezést értik alatta ban készültek el az első verzióval, ez volt az R/ ben indult az R/2, majd között az R/3 számos verziója is megjelent. Az új rendszer relációs adatbázison működik, kliens-szerver architektúrát használ ban részvénytársasággá alakulnak SAP AG. néven, jelenleg a negyedik legnagyobb szoftvercég a világon. Magyarországon óta van jelen, óta 100%-osan a német anyacég tulajdonában. 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 partner van jelen, és több, mint 600 bevezetett rendszer működik. Munkám során az SAP Business One 8.82-es verzióját használtam SAP Business One 2002 márciusában az SAP felvásárolta az izraeli üzleti alkalmazásfejlesztő TopManage Financial Systems vállalatot. Alapítói, Reuven Afassi és Gadi Shamia a felvásárlást követően az SAP-nál kaptak pozíciót. A felvásárlás által az SAP előtt egy új piac nyílt meg: a kis- és középvállalkozások piaca, melyek számára ekkoriban nem nagyon volt elfogadható minőségű, elérhető árú vállalatirányítási rendszer, viszont a TopManage által fejlesztett rendszer már SAP Business One (röviden SBO) néven ideális megoldásnak bizonyult [2]. Az SAP Business One 2004 óta Magyarországon is elérhető, s 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. Az SAP Business One moduláris felépítésű. Az egyes modulok a vállalatirányítás különböző területeit fedik le, de a vállalat igényei szerint fejleszthetők speciális külső modulok is, melyeket addonoknak nevezünk.

13 SAP Business One 13 A standard modulok a következők (1. ábra): 1. ábra Adminisztráció Az adminisztráció modul tartalmazza a rendszer funkcionalitásának alapbeállításait. A modul lehetővé teszi a rendszernek a vállalat valós folyamatainak megfelelő testre szabását. Itt definiálhatók a valutaárfolyamok, a használt országkódok, periódusok, adókódok, engedélyezési és figyelmeztetési eljárások, valamint az addonok kezelése is itt található. Pénzügy A pénzügy modul kezeli a pénzügyi tranzakciókat. Itt található például a főkönyv, a számla létrehozása és karbantartása, a naplókönyvelés, a költségkeret. Ezen kívül található itt egy Költségszámítás menüpont is, melyben költséghelyeket és általánosköltség-elszámolási tényezőket lehet definiálni, valamint eredménykimutatást lehet készíteni az egyes költséghelyekhez. Üzleti lehetőségek Ezzel a modullal értékesítési adatokat vihetünk be, melyeket karbantarthatunk és elemzéseket végezhetünk vele. Elemezhetünk értékesítési lehetőségeket, szintelemzéseket, megnyert lehetőségeket és az úgynevezett lehetőség-tölcsért. Értékesítés Az értékesítés modul az értékesítési folyamatokat szolgálja. Árajánlatok létrehozása,

14 SAP Business One 14 vevői rendelések, kiszállítások, készletmérleg aktualizálása, illetve kimenő számlák kezelése a fő funkciói. Beszerzés A beszerzés modul a beszerzési folyamatokat segíti. Szállítói ajánlatok, megrendelések, árubeérkezések, valamint bejövő számlák kezelését teszi lehetővé a modul. Üzleti partnerek A partnerekkel (vevők, szállítók) kapcsolatos adatok kezelése: törzsadatok, számlaegyenlegek, kapcsolattartási adatok, kampányok. 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. 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, raktárak közötti mozgatások. Gyártás Itt található 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. A szükséglettervezés lehet fogyási vagy terv alapú. Szerviz Szolgáltatások felügyelete. Támogatja a szervizműveleteket, szervizszerződések kezeléseket, a szerviztervezést, a vevőtámogatást. Emberi erőforrások A modul feladata a 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, mint például vevői és szállítói követelések, cashflow, könyvvitel, raktári készlet, eredménykimutatás és vevői tevékenység. Egy SBO rendszer kliens- és szerveroldali komponensekből áll. A szerveroldalon szükség van egy adatbázisszerverre (MSSQL), és ehhez kapcsolódnak a felhasználók gépein futó SBO kliensek. Egy SBO kliens alapképernyőt ábrázol a 2. ábra.

15 SAP Business One ábra Baloldalt, a főmenüben láthatók az egyes modulok, amiket az imént részleteztem jelenleg csak a standard modulok vannak feltelepítve. Jobbra egy keresőmező található, fenn a menüsor és az eszköztár, alul pedig az üzenetsáv. A főmenü testre szabható. Egyrészt jogosultságok beállításával korlátozhatjuk, hogy az egyes felhasználóknak mely modulokhoz legyen jogosultsága, ezáltal csak azok a menüpontok jelennek meg neki, amikhez hozzáférhet. Másrészt ezen túl is beállíthatja a felhasználó, hogy melyeket akar látni az Űrlapbeállítások menü használatával. A jogosultságok nagyon fontos részei az ERP rendszereknek. Mivel a rendszer átfogja a vállalat teljes irányítását, veszélyes volna, ha bárki bármihez hozzányúlhatna. Jogosultságok beállításával ezt korlátozhatjuk, 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, most ezekre térnék ki Rendszerinformációk A Nézet menüben van egy Rendszerinformációk menüpont. Ezt bepipálva egy nagyon hasznos eszközt kapunk (3. ábra).

16 SAP Business One ábra A megnyitott űrlapon (formon a példában ez a Cikktörzsadatok form) az egérrel rámutatva valamelyik mezőre (nyíllal jelölve) az alsó üzenetsávon láthatjuk az adott mező jellemzőit. A példában a kiválasztott mező egy, az adatbázisban megtalálható tábla egy mezőjéhez kapcsolódik. Természetesen vannak olyan mezők, melyek nem kapcsolódnak táblához (gondoljunk csak például a mezők címkéire, vagy számított értékekre). Ezek közül hasznos tud lenni számunkra: Cikk leírása: a mező megnevezése 100 Characters: a mező mérete IBM Infoprint 1312: a mezőben lévő érték Form = 150: a form típusa, ezzel azonosíthatjuk a formot Item = 7: a mező azonosítója a formon Pane = 0: a formon melyik 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, Beszerzési adatok, 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. OITM: a kapcsolt tábla neve, ez esetben a cikkek táblája. ItemName: a mező neve a táblában, vagyis most a cikk megnevezése mező Lekérdezések Mivel egy adatbázissal dolgozunk, lehetséges lekérdezéseket is futtatni. Ezeket a lekérdezéseket az SBO-ban is megírhatjuk, elmenthetjük és futtathatjuk. Az Eszközök menüben található Lekérdezések menüpont ezt teszi lehetővé (4. ábra).

17 SAP Business One ábra A Lekérdezéskezelőben érhetjük el az elmentett lekérdezéseket. Ezek jellemzően riportok, analitikák, vagy egyéb hasznos lekérdezések, melyek a felhasználók (pénzügyesek, könyvelők, vállalati döntéshozók) munkáját segítik. A Lekérdezésgenerátor egy olyan eszköz, mellyel a (megfelelő jogosultsággal rendelkező) felhasználók egyszerűen állíthatnak össze SQL lekérdezéseket (5. ábra). 5. ábra Felhasználói mezők, felhasználói táblák A standard táblák egy sor adat eltárolását teszik lehetővé, mégis előfordulhat, hogy ez nem elég, valami mást is szeretnénk tárolni. Ezt könnyen megtehetjük: felveszünk egy felhasználói mezőt (UDF user defined field) a kívánt táblához. Vannak olyan táblák, ahol ez nem lehetséges, de a legtöbb esetében igen. A felhasználói mezők neve mindig egy U_ prefixszel kezdődik (l. 5. ábra). Felhasználói táblák (UDT user defined table) létrehozása is lehetséges, a felhasználói táblák neve egyedi kell legyen Screen Painter Grafikus felületek szerkesztésére használható a Screen Painter addon (6. ábra).

18 SAP Business One ábra A megrajzolt formot XML formátumban menti el egy.srf fájlba Addonok Mivel az alaprendszer forráskódja nem publikus, az szoftver felhasználóinak a standardtól eltérő igényeit fejlesztésekkel lehet támogatni, amelyek az alaprendszerrel együtt futtathatóak. Ezek olyan kiegészítő modulok, melyek nem szerepelnek a standard SBO rendszerben. Vannak olyan addonok, melyeket az SAP fejlesztett, a rendszer telepítéskor felajánlja ezeknek a telepítését (ilyen például a tárgyi eszköz addon, mely a nyarán érkező 9-es SBO-ban már az alaprendszer standard részekéntfog szerepelni). Léteznek viszont olyan addonok, melyeket az ügyfél kérésére a rendszert bevezető tanácsadócég fejlesztői fejlesztenek le. Az 5-7 fejezetben két ilyen fejlesztésről fogok írni, melyekben én is részt vettem, de előbb tekintsük át az addonok fejlesztéséhez használható eszközöket.

19 SAP Business One Microsoft SQL Server 2008 R2 Management Studio 7. ábra A Microsoft SQL Server 2008 R2 Management Studio) az adatbázisok menedzselését segíti (7. ábra). A baloldali, Object Explorer blokkban látjuk az adatbázisszervert (a képen ez most N02904, az én gépem). A Databases könyvtárat lenyitva láthatjuk az elérhető adatbázisokat. A jobboldali mezőbe írhatunk lekérdezéseket, melyeket a kiválasztott adatbázison futtathatunk, az eredmény alul látszik. 8. ábra

20 SAP Business One 20 Az SQL Management Studio segítségével tudunk adatbázisokat lementeni és betölteni. Az adatbázis nevén jobbgombbal kattintva feljövő menü Tasks menüpontjában található Back Up menüpontban egy.bak kiterjesztésű fájlba lementhetjük az adatbázist, a Restore Database menüpontban pedig egy ilyen.bak fájlból visszatölthetjük az adatbázist. Fejlesztések, tesztelések, hibakeresések során szükség lehet rá, hogy az ügyfél adatbázisát lementve a fejlesztő vagy tanácsadó akár a saját számítógépén vagy egy belső tesztszerveren tudjon dolgozni, mivel így ugyanazokkal a struktúrákkal és adatokkal tudja végezni a munkáját, amikkel a későbbiekben az éles rendszeren is találkozhat. Az 9. ábra egy SBO bejelentkező képernyőt ábrázol, ahol kiválaszthatjuk, melyik adatbázisba szeretnénk bejelentkezni. Ki lehet választani az adatbázisszervert (ami most is az N02904, így láthatjuk az összes olyan adatbázist, amit korábban, a 7. ábra is láttunk), majd az adatbázist, és a megfelelő felhasználónév és jelszó megadásával beléphetünk a választott adatbázisba SDK 9. ábra Az SAP Business One SDK két nagy részből áll: UI API (User Interface API) DI API (Data Interface API) A UI API a felhasználói felületek elérését teszi lehetővé, míg a DI API a háttérben lévő objektumokhoz nyújt kapcsolatot. A UI API segítségével hozhatunk létre új formokat (melyeket megrajzolhatunk a Screen Painterrel), és érhetjük el a formokon található mezőket. A DI API-val létrehozhatunk felhasználói táblákat (UDT), felhasználói mezőket (UDF), objektumokat (UDO user defined object). Ez már egy üzleti logikai réteg, ezzel tudunk üzleti logikát állítani a UI API-val létrehozott felhasználói interfész mögé, illetve kapcsolatot építeni más, külső alkalmazásokkal. Kommunikál az adatbázissal, validációkat végez, illetve alapértelmezett mezőértékeket állít be.

21 SAP Business One Fejlesztői környezet Az SBO SDK használható többféle fejlesztőrendszerrel JAVA, Visual Basic vagy a Microsoft.NET-et használjaalapú rendszerekkel egyaránt. Munkám során C#-ot használtam, ehhez két fejlesztői környezetet. Az egyik a Microsoft Visual C# 2008 Express Edition, a másik a nyílt forráskódú (opensource) SharpDevelop 4.3. Mindkettő jól használható környezet, megszokás kérdése, hogy ki mit szeret használni. Néhány projekt esetében viszont szükség volt a SharpDevelopre a Visual Studio Express Edition korlátozásainak megkerülésére.

22 Integrációs technológiák Integrációs technológiák 4.1. XML Az XML (Extensible Markup Language, kiterjeszthető jelölő nyelv) egy, a W3C (World Wide Web Consortium) által ajánlott általános leíró nyelv [3]. Szöveges adatformátum, támogatja a Unicode-ot. A motiváció egy általános, egyszerű, az interneten bárhol használható szabvány létrehozása, melynek feldolgozására könnyű legyen alkalmazásokat írni. Bár főleg dokumentumok leírására tervezték, adatstruktúrák leírásánál is használják (pl. webszolgáltatások WSDL, SOAP). Első megjelenése óta több száz XML-alapú dokumentumformátum látott napvilágot, mint például az RSS, HTML, vagy a már említett WSDL és SOAP, és nagyon sok irodai alkalmazás is használja (Microsoft Office, vagy az opensource alternatívák: LibreOffice, OpenOffice). Előnyei közé tartozik, hogy olvasható formátumról van szó: gép és (többnyire) ember által is értelmezhető dokumentumot produkál, viszont a dokumentum nagyon nagyra tud hízni a szintaxisnak köszönhetően (ezért is kezd elterjedni helyette például okostelefonoknál a json, mely egy jóval kompaktabb formátum). Egy példa XML: <?xml version="1.0" encoding="utf-8"?> <mezok> <mezo eazon="0a0001e001a"> </mezo> </mezok> Az első sor az XML deklaráció sora. Jelöli az XML verziót és a karakterkódolást. Tag -nek nevezzük a < karakterrel kezdődő és > karakterrel záródó elemeket, mint a példában látható <mezok> tag. Ebből háromféle lehet: <mezok> nyitó tag </mezok> záró tag <br/> üres tag Egy nyitó és záró tag egy elemet vagy node-ot fog össze (pl. mezok, mezo). A nyitó és záró tag közötti részt hívjuk a node tartalmának. Egy node-nak lehetnek leszármazott elemei, például a mezok elemnek a mezo. Egy nyitó vagy üres tagnek lehetnek attribútumai is, a fenti példában a mezo tagnek van egy eazon attribútuma EDI Az EDI (Electronic Data Interchange elektronikus adatcsere) szigorúan strukturált üzeneteknek számítógépek közötti, emberi közreműködés nélkül megvalósított cseréje.

23 Integrációs technológiák 23 Jellemzően nagy cégek használják elektronikus kereskedelmi célokra, mint például megrendelések küldésére, számlázásra, vagy akár szállítólevelek teljes kiváltására. Tartós kapcsolatra épül, gyakran ismétlődő automatikus dokumentumcseréről van szó. Az EDI a 70-es, 80-as évek integrációs technológiája. A 60-as években elterjedő számítógépek használatával egyre nagyobb volt az igény arra, hogy az emberi tényezőt kiiktatva tudjanak adatokat cserélni két számítógép között. Ahogy lassan megjelentek a számítógépek közötti kapcsolatok, lokális hálózatok, majd az értéknövelt hálózatok (VAN Value Added Network), megjelentek az első EDI üzenetek is. Ezek még nem voltak szabványosítva, de erre sem kellett már sokat várni. Ma már nagyon sok szabvány létezik elektronikus adatcserére, az első ilyen 1978-ban jelent meg, eredete az autóipar: ez volt a VDA, nevét létrehozójáról, a német Autóipari Szövetségről (Verband der Automobilindustrie) kapta ban jelentette meg az ENSZ az UN/EDIFACT [4] (United Nations/Electronic Data Interchange For Administration, Control and Transport) szabványt, ami a mai napig a legelterjedtebb EDI szabvány. Az EDIFACT egy leíró nyelv, iparágtól független nemzetközi szabvány, de az idők során nagyon sok iparágnak létrejött a maga specifikus változata. Néhány példa: EANCOM: Iparcikkgyártás és kereskedelem EDIFOR: Szállítmányozás EDIFURN: Bútoripar és Bútorkereskedelem EDILEKTRO: Elektromos gépipar és kereskedelem EDITRANS: Közlekedés ODETTE: Autóipar, autóipari beszállítók

24 Integrációs feladatok ismertetése Integrációs feladatok ismertetése Ebben a fejezetben ismertetem a megoldásra váró két integrációs feladatot ÁNYK adatexport Tételes belföldi összesítő jelentés Az adózás rendjéről szóló évi XCII. törvény 31/B. (Beiktatta: évi CLVI. törvény 296. (6). Hatályos: I. 1-től.) rendelkezései a következők: 31/B. (1) Az általános forgalmi adó alanya termék beszerzése, szolgáltatás igénybevétele esetén azon számlákról, amelyekben az áthárított általános forgalmi adó összege a forintot eléri vagy meghaladja, arról az adómegállapítási időszakról teljesítendő általános forgalmiadó bevallásban, amelyben az ügylet teljesítését vagy az előleg megfizetését tanúsító számla alapján adólevonási jogot gyakorol, számlánként nyilatkozni köteles: a) a terméket értékesítő, szolgáltatást nyújtó általános forgalmiadó-alany - ideértve az egyszerűsített vállalkozói adóalanyt is - adószámának, csoportos általános forgalmiadóalanyiság esetén csoportazonosító számának első nyolc számjegyéről, b) a nevére szóló számlában feltüntetett általános forgalmi adó alapjáról és áthárított általános forgalmi adó összegéről, a számla sorszámáról, valamint c) a számlában az általános forgalmi adóról szóló évi CXXVII. törvény 169. g) pontja szerint feltüntetett időpontról, ennek hiányában a számla kibocsátásának keltéről. (2) Az általános forgalmi adó alanya termék értékesítése, szolgáltatás nyújtása esetén azon számlákról, amelyekben egy másik, belföldön nyilvántartásba vett általános forgalmi adó alanyra áthárított általános forgalmi adó összege a forintot eléri vagy meghaladja, arról az adómegállapítási időszakról teljesítendő általános forgalmiadó bevallásban, amelyben az ügylet teljesítését vagy az előleg megfizetését tanúsító számlában feltüntetett adót meg kell állapítania, számlánként nyilatkozni köteles: a) a terméket beszerző, szolgáltatást igénybe vevő általános forgalmiadó-alany adószámának, csoportos általános forgalmi adóalanyiság esetén csoportazonosító számának első nyolc számjegyéről, b) a kibocsátott számlában feltüntetett általános forgalmi adó alapjáról és áthárított általános forgalmi adó összegéről, a számla sorszámáról, valamint c) a számlában az általános forgalmi adóról szóló évi CXXVII. törvény 169. g) pontja szerint feltüntetett időpontról, ennek hiányában a számla kibocsátásának keltéről. (3) Amennyiben az általános forgalmi adó alanya ugyanabban az adómegállapítási időszakban ugyanazon termékértékesítő vagy szolgáltatást nyújtó által kibocsátott több számlában - ideértve a számlával egy tekintet alá eső okiratot is - áthárított adó tekintetében gyakorol összesen forintot elérő vagy ezt meghaladó összegben adólevonási jogot, úgy az erről az adómegállapítási időszakról benyújtott általános forgalmiadó bevallásában nyilatkozik: a) a termékértékesítő vagy szolgáltatást nyújtó általános forgalmiadó-alany - ideértve az egyszerűsített vállalkozói adó alanyát is - adószámának, csoportos általános forgalmiadóalanyiság esetén csoportazonosító számának első nyolc számjegyéről, és b) ezen számlákban feltüntetett, áthárított általános forgalmi adó összegéről. (4) Számla módosítása esetén a számlát módosító okiratot kiállító és az azt befogadó általános forgalmiadó-alany abban a bevallásban, amelyben a módosítás hatását figyelembe veszi, akkor köteles a módosított számlát érintően az (1)-(2) bekezdés szerint nyilatkozni, ha a számlában áthárított általános forgalmi adó akár a módosítást megelőzően, akár azt követően vagy a módosítást megelőzően és azt követően is eléri vagy meghaladja a forintot. Ebben az esetben az általános forgalmi adó alanya nyilatkozik annak a számlának az (1)-(2) bekezdésben meghatározott adatairól, amelyet a módosítás érint, a módosítás számszaki

25 Integrációs feladatok ismertetése 25 hatásáról az általános forgalmiadó alap és áthárított általános forgalmi adó tekintetében, valamint a számlát módosító okirat sorszámáról. (5) Számla érvénytelenítése esetén a számlát érvénytelenítő okiratot kiállító és az azt befogadó általános forgalmiadó-alany, amennyiben az érvénytelenített számlában - ideértve a módosított számlát is - áthárított általános forgalmi adó összege elérte vagy meghaladta a forintot, abban a bevallásban, amelyben az érvénytelenítés hatását figyelembe veszi, köteles a számlát érintően az (1)-(2) bekezdés szerinti adatokról, valamint a számlát érvénytelenítő okirat sorszámáról nyilatkozni. (6) Az egyszerűsített vállalkozói adó alanya az általa kibocsátott számlák tekintetében a (2) és (4)-(5) bekezdésnek megfelelően, arról az adóévről benyújtott egyszerűsített vállalkozói adó bevallásban - az egyszerűsített vállalkozói adóról szóló évi XLIII. törvény 11. (5) bekezdés alkalmazása esetén a becslésre irányuló adóhatósági eljárás során - nyilatkozik, amelyben a számlát kiállította. (7) A 34. és a 172. alkalmazásában az (1)-(6) bekezdés szerinti nyilatkozatra (általános forgalmi adó összesítő jelentés) a bevallásra vonatkozó rendelkezéseket kell alkalmazni. (8) 278 A pénzforgalmi elszámolást választó általános forgalmi adó alany által kibocsátott számla esetében az (1) és (2) bekezdés szerinti nyilatkozatot csak egyszer, arról az adómegállapítási időszakról teljesítendő általános forgalmi adó bevallásban kell megtenni, amelyben ezen számla alapján az adózó első alkalommal adólevonási jogot érvényesít, adómegállapításra kötelezett. (9) 279 A pénzforgalmi elszámolást választó általános forgalmi adó alany termék beszerzése, szolgáltatás igénybevétele esetén az (1) bekezdés szerinti nyilatkozatot ugyanazon számláról csak egyszer, arról az adómegállapítási időszakról teljesítendő általános forgalmi adó bevallásban teljesíti, amelyben ezen számla alapján első alkalommal adólevonási jogot érvényesít. [5] A rendelkezés lényege, hogy január elsejétől minden, forintot elérő áfatartalmú számláról részletes adatszolgáltatást kell teljesíteni a Nemzeti Adó- és Vámhivatal (NAV) felé. A jelentést kétféle bontásban kell elkészíteni [6]: Számlaszintű jelentésben tételesen meg kell adni minden olyan számla adatait, ami eléri vagy meghaladja a forintos határt Összevont jelentésben a partnerenként összesített áfa értéket kell megadni, ha az eléri vagy meghaladja a forintos határt Helyesbített számlák esetén is figyelni kell a kétmilliós határt: ha kiállítunk egy kétmillió forintnál kevesebb áfát tartalmazó számlát, majd utólag korrigáljuk az összeget a határ fölé (vagy fordítva), akkor is szerepeltetni kell a jelentésben sőt, ez esetben a teljes számlatörténetet be kell mutatni, vagyis valamennyi módosító számla adatait fel kell tüntetni. Tehát, ha a számla áfa tartalma a módosítás előtt vagy után, eléri vagy meghaladja a forintot, akkor szerepeltetni kell a jelentésben [7] ÁNYK A NAV-nak elektronikus úton beszolgáltatott dokumentumok kitöltéséhez egy Java alapú programot, az Általános Nyomtatványkitöltő Programot (ÁNYK) használhatjuk (10. ábra).

26 Integrációs feladatok ismertetése ábra Az ÁNYK valamennyi, NAV-nak küldendő nyomtatványt kezel, a szükséges nyomtatványokat a NAV oldaláról [8] tölthetjük le. Telepítés után a nyomtatvány megtalálható a Szerviz Telepített nyomtatványok menüpontban, illetve kitölthetjük, ha elnavigálunk az Adatok Új nyomtatvány menübe. Ami számunkra most érdekesebb, az az, hogy az ÁNYK nyomtatványait nem csak kézzel tölthetjük ki. A Szerviz menüben találunk egy Egyedi importálás menüpontot (11. ábra), mely lehetővé teszi, hogy XML állományt importáljunk. 11. ábra

27 Integrációs feladatok ismertetése M nyomtatvány A tételes belföldi összesítő jelentést a 1365M nyomtatványon kell benyújtani, mely szintén a NAV oldaláról tölthető le [9], ahogy a kitöltési útmutató és a nyomtatvány leírása is [10]. A 1365 nyomtatvány két részből áll: egy 1365A és egy, vagy több 1365M nyomtatványból. A 1365A nyomtatványon csak a feltétlen szükséges adatokat töltjük ki, ezek az adózó adatai az első lapon és a további lapok fejlécein. Egy megnyitott 1365-ös nyomtatványt mutat a 12. ábra. 12. ábra A Nyomtatványok gomb melletti legördülő menüben láthatjuk a nyomtatvány alnyomtatványait. Legfelül a 1365A nyomtatvány található, alatta a 1365M nyomtatványok az adózó ügyfeleinek adataival (név és adószám). A 1365M nyomtatvány 5 lapból áll: 1365M, a főlap (13. ábra): három blokkból áll, ezek a következők: o Az adózó és a partner adatai (13. ábra) A magyar adószám három, kötőjellel elválasztott részből áll: XXXXXXXX-Y-ZZ XXXXXXXX az adózót egyértelműen azonosító törzsszám Y az ún. áfa kód (csak 2 vagy 3 áfa kódú adóalany által kibocsátott számla tartalmazhat áthárított áfát) ZZ az adózó székhelye szerint illetékes területi adóhatóság kódja

28 Integrációs feladatok ismertetése 28 o Az adózónak a teljes adószámát fel kell tüntetni, míg a partnerek esetén csak a nyolcjegyű azonosítót (tehát a magyar adószám első nyolc karakterét). Bevallási időszak rendszerint havi, negyedéves vagy éves időszakokról van szó, attól függően, hogy az adózó milyen besorolás alá tartozik 13. ábra o A kereskedelmi partnerrel bonyolított belföldi egyenes adózás alá tartozó, a partnerre vonatkozó részletező lapokon számlánként tételesen nyilatkozott és/vagy összevontan feltüntetett forgalom összesen (14. ábra): az valamint a 7. sor számított sor, a töltés során ezzel nem kell foglalkoznunk, a 01, 01-K, 02 és 02-K lapok adatai alapján automatikusan tölti a program. A képen látható példában az látszik, hogy a partnernek egy számlája van összesen, amit a nyomtatványban tételesen fel kellett tüntetni. A 6. azonban érdekesebb számunkra: A sorokban nem szereplő, értékhatár alatti beszerzési számlák összevont adó összege. Ebbe a sorba kerül azoknak a beszerzési számláknak az adóösszege, melyek adóösszege önmagukban nem éri el a Ft-ot, tehát a nyomtatvány lapjain nem kell őket tételesen szerepeltetni.

29 Integrációs feladatok ismertetése ábra 01: Partnerrel bonyolított belföldi, egyenes adózás alá tartozó termékértékesítés / szolgáltatás nyújtás tételes részletezése: azon kimenő számlák, melyek áfa összege eléri a Ft-ot (15. ábra). 15. ábra 01-K: Partnerrel bonyolított belföldi, egyenes adózás alá tartozó termékértékesítés / szolgáltatás nyújtás korrekcióinak tételes részletezése (16. ábra): módosító lap Helyesbített számlák esetén itt kell feltüntetni a módosító számlákat a kiállítás sorrendjében. Például, ahogy a 16. ábra mutatja: szerepel egyszer a 227-es eredeti számla, majd az 5-ös számú, már módosított számla, melynek előzménye a 227. A számlatípus (szla típ.) oszlopba az E, K, vagy KT értékek kerülhetnek. Ezek jelentése: o E: eredeti o K: korábbi korrekció o KT: tárgyhavi korrekció

30 Integrációs feladatok ismertetése ábra 02: Partnerrel bonyolított belföldi, egyenes adózás alá tartozó termékbeszerzés / szolgáltatás igénybevétel tételes részletezése: felépítése megegyezik a 01-es lappal, itt a bejövő számlákat soroljuk fel. 02-K: Partnerrel bonyolított belföldi, egyenes adózás alá tartozó termékbeszerzés / szolgáltatás igénybevétel korrekcióinak tételes részletezése: Módosító lap, felépítése megegyezik a 01-K lappal, itt a bejövő számlák korrekcióit soroljuk fel ÁNYK XML séma A vállalkozás méretétől függően nagyon sok (százas, de akár ezres nagyságrendű is lehet) tételről beszélünk, mindenképpen érdemes meggondolni a feladat automatizálását, melyre a már említett XML importálás jól használható megoldás. Az ÁNYK valamennyi nyomtatványához ugyanaz az XML séma tartozik, melynek leírása a NAV oldalán található [11]. Az alábbiakban egy 1365M nyomtatvány alapján bemutatom az XML sémát: <?xml version="1.0" encoding="utf-8"?> <nyomtatvanyok xmlns=" A 1365 nyomtatvány két részből áll: egy 1365A nyomtatványból, és egy vagy több 1365A nyomtatványból. Minden nyomtatvány egy-egy nyomtatvany tagen belül szerepel. <nyomtatvany> A nyomtatványinformáció blokkon belül találjuk a nyomtatvány típusát (jelen esetben 1365A illetve 1365M), az adózó nevét és adószámát, valamint a bevallási időszakot. <nyomtatvanyinformacio> <nyomtatvanyazonosito>1365a</nyomtatvanyazonosito> <adozo> <nev>demo Hungary Zrt.</nev> <adoszam> </adoszam> </adozo> <idoszak> <tol> </tol> <ig> </ig> </idoszak> </nyomtatvanyinformacio> A mezok tagen belül találhatók a nyomtatvány mezőinek értékei. Mivel egy általános XML formátumról van szó, a mezőket nem a tagekkel, hanem a mező eazon attribútumának

31 Integrációs feladatok ismertetése 31 értékeivel adjuk meg. Az eazon attribútum értékei lehetnek 11 vagy 13 karakter hosszúak, a 11 karakter hosszúak a következőképpen generálódnak: eazon= LLXXXXBMMMT (például eazon= 0A0001E001A ) LL: a lap sorszáma (0A, 0B stb.) XXXX: az adott lap hányadik dinamikus lapján szerepel a mező (0001, 0002, stb.) B: a lapon belül hányadik blokk (A, B, C, stb.) MMM: a blokkon belül hányadik mező (001, 002, stb.) T: értéke A vagy H lehet az A normál mező, a H nem szerkeszthető mező (hivatal tölti ki). Az XML készítésekor csak az A jelzésű mezőket vesszük figyelembe. A 17. ábra ezt mutatja be. Mivel a 1365A nyomtatvány első lapjának nincs dinamikus lapja, ezt itt nem jelöltem (ilyen esetben az XXXX blokk értéke 0001). 17. ábra <mezok> <mezo eazon="0a0001e001a"> </mezo> <mezo eazon="0a0001e008a">demo Hungary Zrt.</mezo> <mezo eazon="0a0001e011a">1234</mezo> <mezo eazon="0a0001e012a">budapest</mezo> <mezo eazon="0a0001e013a">kis u. 123.</mezo> <mezo eazon="0a0001e014a"></mezo> <mezo eazon="0a0001e015a"></mezo> <mezo eazon="0a0001e022a">1234</mezo> <mezo eazon="0a0001e023a">budapest</mezo> <mezo eazon="0a0001e024a">kis u. 123.</mezo> <mezo eazon="0a0001e025a"></mezo>

32 Integrációs feladatok ismertetése 32 <mezo eazon="0a0001e026a"></mezo> <mezo eazon="0a0001f001a"> </mezo> <mezo eazon="0a0001f002a"> </mezo> <mezo eazon="0a0001f005a">h</mezo> <mezo eazon="0a0001i001a">budapest</mezo> <mezo eazon="0b0001b001a"> </mezo> <mezo eazon="0b0001b003a"> </mezo> <mezo eazon="0b0001b004a"> </mezo> <mezo eazon="0b0001b005a">demo Hungary Zrt.</mezo> </mezok> </nyomtatvany> <nyomtatvany> <nyomtatvanyinformacio> A nyomtatványinformáció blokkban most is ugyanazok az adatok szerepelnek, de ezúttal a nyomtatvány azonosítója 1365M. <nyomtatvanyazonosito>1365m</nyomtatvanyazonosito> <adozo> <nev>demo Hungary Zrt.</nev> <adoszam> </adoszam> </adozo> A 1365M a 1365A nyomtatvány alnyomtatványa, ezért itt szerepel egy albizonylatazonosítás blokk is. Ebben a blokkban az ügyfél adatai (név és EU-s adószám) szerepelnek. <albizonylatazonositas> <megnevezes>alpha Hungary Kft.</megnevezes> <azonosito> </azonosito> </albizonylatazonositas> <idoszak> <tol> </tol> <ig> </ig> </idoszak> </nyomtatvanyinformacio> A mezok tagen belül ugyanúgy megtalálhatjuk az eazon attribútummal azonosított mezőket. Itt már töltünk olyan mezőket is, melyek eazon értékei 13 karakter hosszúak. Ezek a mezők táblázatban szereplő mezők, az azonosítók ilyenkor a következőképpen generálódnak: eazon= LLXXXXBSSSSOT (például eazon= 0D0002C0001AA ) LL: a lap sorszáma (0A, 0B stb.) XXXX: az adott lap hányadik dinamikus lapján szerepel a mező (0001, 0002, stb.) B: a lapon belül hányadik blokk (A, B, C, stb.) SSSS: a táblázat hányadik sora (001, 002, stb.) O: a táblázat hányadik oszlopa (A, B, C, stb.) T: értéke A vagy H lehet az A normál mező, a H nem szerkeszthető mező (hivatal tölti ki). Az XML készítésekor csak az A jelzésű mezőket vesszük figyelembe. A 18. ábra ezt ábrázolja. A 1365M nyomtatvány negyedik, vagyis D lapján állunk. Ennek a lapnak már lehetnek dinamikus lapjai, most is a második (0002) lapon állunk. A mező a C blokkban van, ami egy táblázat, annak is az első (0001) sorának első (A) oszlopában.

33 Integrációs feladatok ismertetése ábra <mezok> <mezo eazon="0a0001c001a"> </mezo> <mezo eazon="0a0001c004a">demo Hungary Zrt.</mezo> <mezo eazon="0a0001c005a"> </mezo> <mezo eazon="0a0001c007a">alpha Hungary Kft.</mezo> <mezo eazon="0a0001d001a"> </mezo> <mezo eazon="0a0001d002a"> </mezo> <mezo eazon="0b0001b001a">1</mezo> <mezo eazon="0a0001e0006da">65994</mezo> <mezo eazon="0d0001c0001aa"> B </mezo> <mezo eazon="0d0001c0001ba"> </mezo> <mezo eazon="0d0001c0001ca">28405</mezo> <mezo eazon="0d0001c0001da">7669</mezo> <mezo eazon="0d0001c0002aa"> B </mezo> <mezo eazon="0d0001c0002ba"> </mezo> <mezo eazon="0d0001c0002ca">9412</mezo> <mezo eazon="0d0001c0002da">2541</mezo> <mezo eazon="0d0002c0019aa"> B </mezo> <mezo eazon="0d0002c0019ba"> </mezo> <mezo eazon="0d0002c0019ca">16877</mezo> <mezo eazon="0d0002c0019da">4557</mezo> <mezo eazon="0d0002c0020aa"> B </mezo> <mezo eazon="0d0002c0020ba"> </mezo> <mezo eazon="0d0002c0020ca">22479</mezo> <mezo eazon="0d0002c0020da">6069</mezo> <mezo eazon="0d0002c0021aa"> B </mezo> <mezo eazon="0d0002c0021ba"> </mezo> <mezo eazon="0d0002c0021ca">17264</mezo> <mezo eazon="0d0002c0021da">4661</mezo> </mezok> </nyomtatvany> </nyomtatvanyok>

34 Integrációs feladatok ismertetése EDI alapú dokumentumcsere Partnerünk egyik ügyfele júliusától csak EDI formában benyújtva fogad el számlákat, ezért szükséges volt az EDI alapú integráció bevezetése ehhez az ügyfeléhez. Partnerünk beszállítója ennek az ügyfelének, így a következőkben beszállító és kereskedő néven fogom őket említeni. A kapott formátumleírás, ami alapján a fejlesztést el kell végeznünk, az GS1 EANCOM ajánlására épül. A GS1 Hungary által kiadott szabvány négy szabványos üzenettípust különböztet meg [12]: INVOIC (Számla) ORDERS (Megrendelés) DESADV (Szállítási értesítés) RECADV (Átvételi értesítés) A kereskedőtől kapott szegmensleírás csak az INVOIC típusra tér ki, mivel csak számlák küldéséről van szó. A szegmensleírás három szakaszból áll: Számla fejléc szakasz: a számla fejadatai Számla soros bontása: sorok Számla összesítő szakasz: összegzések, végösszeg, stb EDI szegmensek Az EDI üzenet szegmensekből áll. Több száz féle szegmens létezik, mindegyik más típusú adatot képes tárolni. Néhány, fontosabb szegmens, melyeket mi is használunk a feladat során, ahol lényeges, kiegészítve a kapott leírás pontjaival [13] [14] [15]: UNA Service String advice Ez a szegmens nem kötelező. A szegmens feladata definiálni a kommunikáció során az elválasztó karaktereket: a szegmens terminátort, az elemi adat szeparátort, az adatcsoport szeparátort és a törlő karaktert. Például egy ilyen UNA szegmens: UNA:+.? ' azt jelenti, hogy: 1. : adatcsoport szeparátor, a szegmensen belüli adatcsoportok elválasztásához 2. + elemi adat szeparátor, a szegmensen belül ezzel választjuk el az egyes elemeket 3.. decimális elválasztó 4.? törlő karakter 5. (szóköz) kötelezően szóköz 6. ' szegmens terminátor, ezzel a karakterrel zárjuk le a szegmenst

35 Integrációs feladatok ismertetése 35 EDI üzenetben nem szokás sortöréseket használni UNB Hasznos adatmennyiség fejléc szegmens, kötelező mező. Ebben a szegmensben azonosítják egymást a felek az adatcseréhez, illetve tartalmaz egy egyedi azonosítót is, mellyel az üzenetet azonosíthatjuk. A felek azonosításához GLN (Global Location Number) kódot használunk, melyet Magyarországon a GS1 Hungary adhat ki. Ebben a szegmensben jelölhetjük azt is, hogy teszt üzenetről van-e szó, vagy sem UNH Üzenet fejléc szegmens, kötelező mező. Ez a szegmens határozza meg az üzenet típusát: ez nálunk mindig INVOIC típus lesz BGM Az üzenet kezdete, kötelező mező. Meghatározza, hogy milyen számláról van szó (kereskedelmi vagy helyesbítő számla), és a számla azonosítóját DTM Dátum/idő/intervallum szegmens. Az üzenetben több DTM szegmens is szerepel, ezek: Dokumentum/üzenet dátum Szállítási dátum Adófizetési kötelezettség keletkezésének időpontja Szállítólevél dátuma Megrendelés dátuma RFF Hivatkozások szegmense. Hivatkozhatunk a következőkre: ON megrendelés száma DQ szállítólevél száma IV számlaszám (például helyesbítő számla esetén az eredeti számla száma) VA adószám (ez esetben az EU-s adószámot kell feltüntetni minden esetben, tehát a HU formájút) FTX Szabad szöveg (free text). Az FTX szegmensekbe szabad szöveget írhatunk (például általános információk, számlára írandó szövegek, stb.).

36 Integrációs feladatok ismertetése NAD Név és cím (Name and Address) szegmens. Három résztvevőnk van, melyeknek a nevét és címét fel kell tüntetni egy-egy NAD szegmensben: BY vevő DP szállító SU beszállító CUX Pénznemek szegmense. Referencia, számlázási és célpénznemeket használunk QTY Mennyiség. Jelölni kell, hogy milyen típusú mennyiségről van szó (pl. számlázott vagy leszállított mennyiség), valamint a mértékegység (a mi esetünkben ez lehet darab vagy kilogramm) MOA Pénzösszeg szegmens. Ebbe a szegmensbe írhatjuk a számlán megjelenő pénzösszegeket, például a végösszeget, adóösszeget, soronkénti összeget, stb PRI Árinformáció. Ebben a szegmensben adhatjuk meg a termékek nettó/bruttó egységárát TAX Illeték/adó/díjinformáció, az adókulcs megadására használjuk UNT Üzenet lezáró szegmens, kötelező mező. Az egyes üzenetek (dokumentumok) végét jelzi UNZ Hasznos adatmennyiség lezáró szegmens, kötelező mező. Ez a szegmens jelzi az EDIFACT csere végét Kommunikáció módja A kommunikációhoz az AS2 (Applicability Statement 2) protokollt használjuk. Az AS2 jelenleg a legnépszerűbb protokoll az interneten keresztül történő biztonságos és hiteles adatforgalmazásra [16]. A biztonságot titkosítás és digitális aláírás (privát-publikus kulcspárok) biztosítják. Az AS2 egy HTTPS és S/MIME (Secure/Multipurpose Internet Mail Extensions) alapú szabvány. Az üzeneteket egy borítékba csomagolja, majd http-n vagy https-en keresztül továbbítja a címzettnek. Az üzenetek lehetnek titkosítva és/vagy aláírva, de az AS2 egyiket

37 Integrációs feladatok ismertetése 37 sem követeli meg. Az üzenetek kérhetnek MDN-t (Message Disposition Notification visszajelzés arról, hogy az üzenet megérkezett-e/elolvasta-e a címzett, stb.), de ez szintén nem kötelező.

38 Feladat megvalósítása: ÁNYK adatexport Feladat megvalósítása: ÁNYK adatexport A feladat megvalósításának bemutatását négy részre bontottam: az első rész a felhasználói interfész, a második az adatok lekérdezése az adatbázisból, a harmadik az adatok feldolgozása, végül a negyedik az XML fájl exportálása Felhasználói interfész 19. ábra A grafikus felület nagyon egyszerű. A Pénzügy menüben elhelyeztem egy ÁNYK export menüpontot, amire kattintva megjelenik az ÁNYK export ablak (19. ábra). A periódust két legördülő menüvel lehet megadni (a könyvelési periódusok közül választhat a felhasználó). Erre azért van szükség, mert van olyan cég, ahol nem havonta, hanem negyedévente vagy évente nyújtják be az ÁFA bevallást. Ha csak egyhavi adatot szeretnénk exportálni, ugyanazt a periódust választjuk ki mindkét mezőben. Mindkét mező kitöltése kötelező, ha valamelyik hiányzik, hibaüzenetet kapunk. Az Export gombra kattintva egy fájlböngésző ablak jelenik meg, ahol megadhatjuk az exportálni kívánt fájl helyét és nevét, majd elindul az exportálás Lekérdezés Az SAP as számú note-jában közzétette az adatok lekérdezéséhez szükséges tárolt eljárásokat. Három eljárásról van szó: két kisebb segédfüggvény, valamint egy nagy eljárás (PrepareTaxReportData), ami az adatokat gyűjti össze. A PrepareTaxReportData eljárással kapott adatokon még dolgozni kellett, hogy használható adatokat kapjak, ehhez írtam egy sp_iq1_anykexport nevű tárolt eljárást, ami a következőket csinálja: Létrehoz egy ideiglenes táblát Lefuttatja a PrepareTaxReportData eljárást, az eredményét beleteszi az ideiglenes táblába Az ideiglenes táblából kinyeri a megfelelő adatokat a megfelelő struktúrában, hogy abból az addon felépíthesse a megfelelő XML struktúrát

39 Feladat megvalósítása: ÁNYK adatexport 39 A megfelelő adatok előállítása korántsem volt egyszerű feladat, mivel több ügyfelünk van, akik az addont használni akarták. Ez főleg a partnerek adószámainál okozott problémát, ugyanis kétféle adószámot is tárolhatunk a partnereknél: tárolhatjuk egyrészt a magyar adószámot, amit az as fejezetben ismertettem (8-1-2 formátumban), viszont tárolhatjuk a közösségi (EU-s) adószámot is. A Magyarországon kiadott közösségi adószám áll egy HU előtagból, és a nyolcjegyű törzsszámból. Tehát az magyar adószám EU-s megfelelője a HU Ez azért probléma, mert a 1365M nyomtatványon csak a partner nyolcjegyű adóazonosítóját kell feltüntetni, amit mindkét adószámból könnyű előállítani egy egyszerű LEFT, illetve RIGHT SQL-függvénnyel, de értelemszerűen nem mindegy, mikor melyiket használjuk. Adószámok tárolására több mezőt is használhatunk a partnerek táblájában (OCRD), sőt, a bizonylatokon (számla, helyesbítés, stb.) is fel lehet tüntetni a partner adószámát. Mi azt a megoldást választottuk, hogy nem a bizonylatról, hanem a partnertörzsből vesszük az adószámot, ehhez viszont definiálni kellett, melyik mezőben melyik adószámot tároljuk: OCRD.LicTradNum: EU-s adószám OCRD.VatIdUnCmp: magyar adószám A lekérdezést az addonból így futtatjuk: nvarchar(255) nvarchar(255) = '{PeriodStart}' = '{PeriodEnd}' 'Y' paramétereket a formról olvassuk le és adjuk át a lekérdezésnek. Az sp_iq1_anykexport utolsó paramétere egy Y vagy N karakter, azt jelölve, hogy az addon (Y) vagy nem az addon (N) futtatja-e az eljárást. Erre azért van szükség, mert az eljárást a Lekérdezéskezelőből is lehet futtatni riportként, ekkor viszont egy bővített riportot kapunk. Az eredményre egy példa (addonból való futtatás esetén): Adószám_ elsõ_8_ karaktere Bizony lat szám Szall Ref Szam ÜP név Ûrlap kód Elõzmény_ RefSzam Boro Zoltán AR Boro Zoltán AR01K 226 E Boro Zoltán AR01K 10 K Eszet Lenke AP E Eszet Lenke AP6D 251 E Korrekció_ típus

40 Feladat megvalósítása: ÁNYK adatexport 40 Alap bizonylat_ száma 226 Bizonylat dátum Adó dátum ÁFA_Alap :00: :00: :00: :00: :00: :00: Az oszlopok magyarázata: :00: :00: :00: :00: ÁFA_ összeg 2MFt_alatti _ÁFA_összeg Adószám_első_8_karaktere: a partner adószáma (nyolcjegyű törzsszám) ÜP név: a partner neve Űrlapkód: a nyomtatvány melyik lapjára kerül a bizonylat o AP6D: első lap o AR01: 01 o AR01K: 01-K o AP02: 02 o AP02K: 02-K Bizonylatszám: a bizonylat száma SzallRefSzam: szállítói referenciaszám (ha van) Előzmény_RefSzam: előzmény referenciaszáma (ha van) Korrekció_típus: ha a 01-K vagy 02-K lapra kerül a bizonylat (tehát az űrlapkód AR01K vagy AP02K), a korrekció típusa (E, K, KT) Alapbizonylat_száma: ha a 01-K vagy 02-K lapra kerül a bizonylat (tehát az űrlapkód AR01K vagy AP02K), az alapbizonylat száma Bizonylatdátum: bizonylatdátum (TaxDate) Adódátum: adódátum (VatDate) ÁFA_Alap: az áfaalap ÁFA_összeg: az áfa összege 2MFt_alatti_ÁFA_összeg: az első lapra kerülő áfaösszeg (tehát az űrlapkód AP6D) Feldolgozáskor az űrlapkódtól függően vesszük figyelembe a további mezőket. Tehát, ha az űrlapkód AP6D, vagyis a nyomtatvány legelső oldaláról van szó, ahova a kétmillió forint áfaösszeget nem meghaladó számlák összesített áfaösszege kerül, akkor nem vesszük figyelembe például a bizonylatszám és korrekciótípus mezőket.

41 Feladat megvalósítása: ÁNYK adatexport Adatfeldolgozás A lekérdezés eredményét egy RecordSetbe teszem, majd ezen végighaladva feldolgozom a kapott adatokat. Az adatokat a következő osztályok segítségével tárolom el (20. ábra): 20. ábra A Mezo osztály az egyes mezők tárolására szolgál. Az attrval változó az attribútum (vagyis az XML-ben az eazon attribútum) értékét tárolja, míg a value a mező értékét. A Nyomtatvany osztállyal a 1365A nyomtatványt kezeljük, míg az AlNyomtatvany osztállyal a 1365M-eket. Erre a leszármaztatásra azért volt szükség, mert, bár a felépítésük közel azonos, a 1365M nyomtatványokban a partner nevét és adószámát is tároljuk. A nyomtatvanyinformacio függvényt, amivel a nyomtatványinformáció node-ot állítjuk elő az XML-ben ki is egészítettem ebben az osztályban. Az adatok tárolásához listákat használok. Egy nagy Nyomtatvany listában tárolom az összes nyomtatványt, ehhez adom hozzá sorban a nyomtatványokat. A 1365M nyomtatvány öt oldalának (kétmillió forint alatti áfa összegű bizonylatok, 01, 01-K, 02 és 02-K, ahogy azt az 5.1-es fejezetben részleteztem) öt listát feleltettem meg. Ahogy végighaladok a rekordokon, az űrlapkódnak megfelelő listába teszem az értékeket. Amikor végére értem az adott partnernek, az öt kis listát hozzáadom a partner nyomtatványának mezok listájához, és továbblépek az új partnerre (mivel az eredményt partner adószámra rendezve kapom a lekérdezéstől, ez nem fog problémát okozni) XML export Elértünk hát arra a pontra, hogy van egy nagy Nyomtatvany objektumokból álló listánk. Az első eleme a 1365A, és őt követik a 1365M nyomtatványok. Most következik, hogy egy XML-t kéne belőle generálni, majd ezt elmenteni egy fájlba. Az eddigiek után ez már meglepően könnyű feladat volt. XML exportálással már találkoztam munkám során, így volt alkalmam utánanézni, milyen lehetőségeket kínál a C#. Három módszert próbáltam ki:

42 Feladat megvalósítása: ÁNYK adatexport DataSet Az XML-t leíró XSD fájl alapján felépít egy adatstruktúrát, melyet feltölthetünk adatokkal, majd ezt XML formában exportálhatjuk. Sajnos az XML exportálási képességei erősen korlátozottak: sem a node-ok sorrendjét nem lehet megváltoztatni, és az attribútumok kezelését sem sikerült megoldanom vele, így ezt a megoldást ezúttal is elvetettem XMLWriter Egy korábbi fejlesztés során nagyon jó szolgálatot tett, miután a DataSettel nem sikerült megoldani a feladatot. Lineárisan halad végig az elemeken és építi fel az XML fastruktúráját, ezáltal gyors, kis erőforrás-igényű, cserébe viszont együtt kell élnünk a linearitásból fakadó kellemetlenségekkel. Nagy mennyiségű adat feldolgozásához ezt érdemes használni. Egy példa az XMLWriter használatára: using (XmlWriter writer = XmlWriter.Create(fileName, xmlwritersettings)) { writer.writestartdocument(); writer.writestartelement("adatok"); writer.writeattributestring("xmlns", "xsi", null, " writer.writeattributestring("xmlns", "xsd", null, " writer.writestartelement("xmladatok"); writer.writeelementstring("verzio", xmladatok.verzio); writer.writestartelement("letrehozoprogram"); foreach (Node n in xmladatok.letrehozoprogram) { writer.writeelementstring(n.tag, n.value); } writer.writeendelement(); writer.writeelementstring("letrehozva", xmladatok.letrehozva);... writer.writeendelement(); writer.writeendelement(); writer.writeenddocument(); } XDocument és Linq A jó megoldás most ez volt. Az XDocument egy XML dokumentumot reprezentál. Mikor elkészült a lista, egy egyszerű Linq (Language-Integrated Query) segítségével egy XDocumentet építünk belőle: XNamespace xmlns = " document = new XDocument( new XElement(xmlns + "nyomtatvanyok", nyomtatvanyok.select(ny => new XElement(xmlns + "nyomtatvany", ny.nyomtatvanyinformacio(xmlns), new XElement(xmlns + "mezok", ny.mezok.select(x => new XElement(xmlns + "mezo", new XAttribute("eazon", x.attrval), x.value)) ))) ));

43 Feladat megvalósítása: ÁNYK adatexport 43 És ennyi, kész is vagyunk. A leszármaztatásnak köszönhetően együtt tudjuk kezelni a kétféle nyomtatványt úgy, hogy a 1365M nyomtatvány nyomtatvanyinformacio node-ja is megfelelően legenerálódik XML fájl mentése Megvan tehát az XDocumentünk, már csak ki kéne írni fájlba. A fájl neve is megvan, hiszen azt a felhasználónk megadta. A fájl írásához visszatérünk a már említett XMLWriterre, mivel nem csak kézzel tudunk vele XML fájlt írni, hanem egy kész XDocumentet is ki tud írni. XmlWriterSettings xmlwritersettings = new XmlWriterSettings(); xmlwritersettings.encoding = Encoding.UTF8; xmlwritersettings.indent = true; using (XmlWriter xmlwriter = XmlWriter.Create(fileName, xmlwritersettings)) { document.save(xmlwriter); } Az XmlWriterSettingsszel tudjuk megmondani, hogy hogyan formázza az XML-t. Az ÁNYK UTF-8 karakterkódolást igényel, és a behúzásokat is megköveteli (Indent = true).

44 Feladat megvalósítása: EDI alapú dokumentumcsere Feladat megvalósítása: EDI alapú dokumentumcsere A feladat megvalósításának bemutatását ezúttal három részre bontottam: a felhasználói interfész, az adatok lekérdezése és feldolgozása, valamint az adatok elküldése fejezetekre. A fejlesztést áprilisban kezdtük el, az éles indulás júliusban lesz. Mivel a kereskedő nagyon sok beszállítóval dolgozik, a tesztelésre szigorúan szabályozott keretek között kerül sor, pontosan betartott határidők között. Tesztelési ablakot június elejére kaptunk, ezért nem beszélhetek elkészült, ellenőrzött, tesztelt fejlesztésről, hiszen erre még nem volt lehetőségünk Felhasználói interfész Szükség van egy felhasználói felületre, ahol ellenőrizni lehet, hogy a megfelelő számlák elküldésre kerültek-e, és az elküldés sikeres volt-e. Erre legegyszerűbb megoldás, ha az Értékesítés menüben elhelyezünk egy menüpontot EDI számlaküldés névvel, amire rákattintva megjelenik egy ablak (21. ábra). 21. ábra A dátum tól-ig mezőkben, ha kiválasztunk egy érvényes intervallumot, a táblázat feltöltődik az adott intervallumban kiállított számlákkal, megjelenítve a számla adatait, köztük azt, hogy a számla el lett-e már küldve. A sorok elejére kattintva a Ctrl gombot nyomva tartva kiválaszthatjuk az újraküldeni kívánt számlákat, majd a Kijelölt számlák újraküldése gombra kattintva azokat újra elküldhetjük.