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

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.

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

Tartalomjegyzék

3

Tartalomjegyzék Nyilatkozat ................................................................................................................................. 2 Tartalomjegyzék ......................................................................................................................... 3 Tartalmi összefoglaló ................................................................................................................. 5 Abstract ...................................................................................................................................... 6 1.

Bevezetés ............................................................................................................................ 7

2.

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

3.

4.

5.

6.

7.

2.1.

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

2.2.

Üzleti előnyök .......................................................................................................... 10

SAP Business One ............................................................................................................ 12 3.1.

Az SAP története ...................................................................................................... 12

3.2.

SAP Business One .................................................................................................... 12

3.3.

Addonok ................................................................................................................... 18

Integrációs technológiák ................................................................................................... 22 4.1.

XML ......................................................................................................................... 22

4.2.

EDI ........................................................................................................................... 22

Integrációs feladatok ismertetése...................................................................................... 24 5.1.

ÁNYK adatexport ..................................................................................................... 24

5.2.

EDI alapú dokumentumcsere.................................................................................... 34

Feladat megvalósítása: ÁNYK adatexport ....................................................................... 38 6.1.

Felhasználói interfész ............................................................................................... 38

6.2.

Lekérdezés ................................................................................................................ 38

6.3.

Adatfeldolgozás ........................................................................................................ 41

6.4.

XML export .............................................................................................................. 41

6.5.

XML fájl mentése ..................................................................................................... 43

Feladat megvalósítása: EDI alapú dokumentumcsere ...................................................... 44 7.1.

Felhasználói interfész ............................................................................................... 44

7.2.

Adatok lekérdezése és feldolgozása ......................................................................... 45

7.3.

Számlák elküldése .................................................................................................... 46

Tartalomjegyzék

4

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

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 e-mailcí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.

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

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.

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.

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

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

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.

2.2. Ü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

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.

SAP Business One

12

3. 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. 1973-ban készültek el az első verzióval, ez volt az R/1. 1979-ben indult az R/2, majd 1992-95 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. 1988-ban részvénytársasággá alakulnak SAP AG. néven, jelenleg a negyedik legnagyobb szoftvercég a világon. Magyarországon 1989. óta van jelen, 1998. ó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.

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

SAP Business One

13

1. ábra

A standard modulok a következők (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,

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.

SAP Business One

15

2. á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.

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

SAP Business One

16

3. á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ő

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

SAP Business One

17

4. á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

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

3.2.4. Screen Painter Grafikus felületek szerkesztésére használható a Screen Painter addon (6. ábra).

SAP Business One

18

6. ábra

A megrajzolt formot XML formátumban menti el egy .srf fájlba.

3.3. 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 2013. 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.

SAP Business One

19

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

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.

9. ábra

3.3.2. SDK 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.

SAP Business One

21

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

Integrációs technológiák

22

4. 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: <mezok> <mezo eazon="0A0001E001A">12345678901

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



záró tag



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

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

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

Integrációs feladatok ismertetése

24

5. Integrációs feladatok ismertetése Ebben a fejezetben ismertetem a megoldásra váró két integrációs feladatot.

5.1. ÁNYK adatexport 5.1.1. Tételes belföldi összesítő jelentés Az adózás rendjéről szóló 2003. évi XCII. törvény 31/B. § (Beiktatta: 2011. évi CLVI. törvény 296. § (6). Hatályos: 2013. 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 2 000 000 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ó 2007. é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 2 000 000 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ó 2007. é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 2 000 000 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 2 000 000 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

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 2 000 000 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ó 2002. é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 2013. január elsejétől minden, 2 000 000 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 2 000 000 forintos határt



Összevont jelentésben a partnerenként összesített áfa értéket kell megadni, ha az eléri vagy meghaladja a 2 000 000 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 2 000 000 forintot, akkor szerepeltetni kell a jelentésben [7].

5.1.2. Á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

10. á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

5.1.3. 1365M 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

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

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 1.-5. 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 04-05. 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 2 000 000 Ft-ot, tehát a nyomtatvány lapjain nem kell őket tételesen szerepeltetni.


29

14. á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 2 000 000 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

16. á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.

5.1.4. Á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:

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.

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. 1365A Demo Hungary Zrt. 12345678901 20130101 20130331

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

é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 <mezo <mezo <mezo <mezo <mezo <mezo <mezo <mezo <mezo <mezo

eazon="0A0001E001A">12345678901 eazon="0A0001E008A">Demo Hungary Zrt. eazon="0A0001E011A">1234 eazon="0A0001E012A">Budapest eazon="0A0001E013A">Kis u. 123. eazon="0A0001E014A"> eazon="0A0001E015A"> eazon="0A0001E022A">1234 eazon="0A0001E023A">Budapest eazon="0A0001E024A">Kis u. 123. eazon="0A0001E025A">


32

<mezo eazon="0A0001E026A"> <mezo eazon="0A0001F001A">20130101 <mezo eazon="0A0001F002A">20130331 <mezo eazon="0A0001F005A">H <mezo eazon="0A0001I001A">Budapest <mezo eazon="0B0001B001A">12345678901 <mezo eazon="0B0001B003A">20130101 <mezo eazon="0B0001B004A">20130331 <mezo eazon="0B0001B005A">Demo Hungary Zrt. … …

A nyomtatványinformáció blokkban most is ugyanazok az adatok szerepelnek, de ezúttal a nyomtatvány azonosítója 1365M. 1365M Demo Hungary Zrt. 12345678901

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. <megnevezes>Alpha Hungary Kft. 87654321 20130101 20130331

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

18. ábra <mezok> <mezo eazon="0A0001C001A">12345678901 <mezo eazon="0A0001C004A">Demo Hungary Zrt. <mezo eazon="0A0001C005A">87654321 <mezo eazon="0A0001C007A">Alpha Hungary Kft. <mezo eazon="0A0001D001A">20130101 <mezo eazon="0A0001D002A">20130331 <mezo eazon="0B0001B001A">1 … <mezo eazon="0A0001E0006DA">65994 <mezo eazon="0D0001C0001AA">61008048 B13-008048 <mezo eazon="0D0001C0001BA">20130102 <mezo eazon="0D0001C0001CA">28405 <mezo eazon="0D0001C0001DA">7669 <mezo eazon="0D0001C0002AA">61008254 B13-008254 <mezo eazon="0D0001C0002BA">20130103 <mezo eazon="0D0001C0002CA">9412 <mezo eazon="0D0001C0002DA">2541 … <mezo eazon="0D0002C0019AA">61025989 B13-025989 <mezo eazon="0D0002C0019BA">20130328 <mezo eazon="0D0002C0019CA">16877 <mezo eazon="0D0002C0019DA">4557 <mezo eazon="0D0002C0020AA">61025993 B13-025993 <mezo eazon="0D0002C0020BA">20130329 <mezo eazon="0D0002C0020CA">22479 <mezo eazon="0D0002C0020DA">6069 <mezo eazon="0D0002C0021AA">961015524 B13-015524 <mezo eazon="0D0002C0021BA">20130215 <mezo eazon="0D0002C0021CA">17264 <mezo eazon="0D0002C0021DA">4661 …


34

5.2. EDI alapú dokumentumcsere Partnerünk egyik ügyfele 2013. 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.

5.2.1. 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]: 5.2.1.1. 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

EDI üzenetben nem szokás sortöréseket használni. 5.2.1.2. 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. 5.2.1.3. 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. 5.2.1.4. 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. 5.2.1.5. 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 5.2.1.6. 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 HU12345678 formájút) 5.2.1.7. 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

5.2.1.8. 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ó 5.2.1.9. CUX

Pénznemek szegmense. Referencia, számlázási és célpénznemeket használunk. 5.2.1.10.

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

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

PRI

Árinformáció. Ebben a szegmensben adhatjuk meg a termékek nettó/bruttó egységárát. 5.2.1.13.

TAX

Illeték/adó/díjinformáció, az adókulcs megadására használjuk. 5.2.1.14.

UNT

Üzenet lezáró szegmens, kötelező mező. Az egyes üzenetek (dokumentumok) végét jelzi. 5.2.1.15.

UNZ

Hasznos adatmennyiség lezáró szegmens, kötelező mező. Ez a szegmens jelzi az EDIFACT csere végét.

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

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

Feladat megvalósítása: ÁNYK adatexport

38

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

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

6.2. Lekérdezés Az SAP 1814330-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

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 5.1.3-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 12345678-1-12 magyar adószám EU-s megfelelője a HU12345678. 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: DECLARE @PeriodStart ,@PeriodEnd

nvarchar(255) nvarchar(255)

SET @PeriodStart = '{PeriodStart}' SET @PeriodEnd = '{PeriodEnd}' exec [dbo].[sp_iq1_anykexport]

@PeriodStart, @PeriodEnd, 'Y'

A @PeriodStart és @PeriodEnd 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 12101517 12101517 12101517 23460900 23460900

ÜP név Boro Zoltán Boro Zoltán Boro Zoltán Eszet Lenke Eszet Lenke

Ûrlap kód

Bizony lat szám

Szall Ref Szam

Elõzmény_ Korrekció_ RefSzam típus

AR01

226

AR01K

226

E

AR01K

10

K

AP02

252

E

AP6D

251

E

Feladat megvalósítása: ÁNYK adatexport Alap bizonylat_ száma

226

Bizonylat dátum 2013-01-28 00:00:00.0 00 2013-01-28 00:00:00.0 00 2013-02-01 00:00:00.0 00 2013-01-28 00:00:00.0 00 2013-01-28 00:00:00.0 00

Adó dátum 2013-01-28 00:00:00.00 0 2013-01-28 00:00:00.00 0 2013-02-01 00:00:00.00 0 2013-01-28 00:00:00.00 0 2013-01-28 00:00:00.00 0

40

ÁFA_Alap

ÁFA_ összeg

2MFt_alatti _ÁFA_összeg

8000.0000 2160.0000 0000000 0000000 0.000000 8000.0000 0000000 8000.0000 0000000

2160.0000 0000000 0.000000 2160.0000 0000000 0.000000

12000.000 3240.0000 00000000 0000000 1080.000000 4000.0000 1080.0000 0000000 0000000 1080.000000

Az oszlopok magyarázata: 

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

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

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

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

6.4.2. 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, "http://www.w3.org/2001/XMLSchema-instance"); writer.WriteAttributeString("xmlns", "xsd", null, "http://www.w3.org/2001/XMLSchema"); 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(); }

6.4.3. 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 = "http://www.apeh.hu/abev/nyomtatvanyok/2005/01"; 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

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

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

Feladat megvalósítása: EDI alapú dokumentumcsere

44

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

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

Feladat megvalósítása: EDI alapú dokumentumcsere

45

7.2. Adatok lekérdezése és feldolgozása Az EDI-hoz szükséges adatok tárolásához szükség volt egy új tábla létrehozására, amiben a partnerhez kapcsolva eltárolhatjuk őket. A tábla a következőképpen néz ki: Tábla neve: [@IQ1EDIBP] Mező neve

Típus

Leírás

U_CardCode

NVARCHAR(15)

Partner kódja (OCRD.CardCode)

U_GLN

NVARCHAR(35)

Partner GLN kódja

U_OwnGLN

NVARCHAR(35)

Saját GLN kódunk

U_ShipGLN

NVARCHAR(35)

Szállító GLN kódja

U_Comments

NVARCHAR(254)

Számlára írt információ

Az EDI üzenet előállításához szükség volt egy keretrendszerre. Ezt nem én készítettem, az én feladatom az volt, hogy ennek a felhasználásával állítsam elő az elküldhető dokumentumot. Amikor a keretrendszernek az EDI INVOIC dokumentumot reprezentáló részét megkaptam, nekiláthattam a szükséges adatok összegyűjtéséhez. Az osztály neve Invoic, ezért így fogok majd rá hivatkozni. Az adatok összegyűjtése nem volt egyszerű feladat, mivel nagyon sokféle adatról van szó, és a kapott szegmensleírás sem volt mindenhol egyértelmű. Ugyan még mindig maradt néhány kérdéses pont, az osztály és a keretrendszer tesztelését így is meg tudtam kezdeni. Mivel az Invoic osztály változóinak elnevezése a szegmensleíráshoz igazodik, hogy a dolgomat megkönnyítsem, első lépésben létrehoztam egy osztályt, amiben a változók neve az általuk tárolt adatról árulkodik. Például abból, hogy ez most egy DTM szegmens, csak annyit tudok meg, hogy valamiféle dátumot kell neki megadnom. Viszont, ha azt mondom, hogy ez például egy bizonylatdátum, akkor tudom, hogy itt a számlára vonatkozó TaxDate-nek kell benne lennie. Ebbe az objektumba le tudom kérdezni az adatbázisból a szükséges adatokat, hogy majd ezekkel az adatokkal töltsem fel az Invoic objektumot. Az SBO-ban a számlák fejadatait az OINV tábla tartalmazza, míg a soradatokat az INV1 táblában találjuk. A két táblát a DocEntry mező alapján kapcsolhatjuk össze, így az adatok lekérdezéséhez két SQL lekérdezést írtam: 

Az első lekérdezi az adatbázisból azoknak a számláknak a szükséges fejadatait, amik még nem voltak sikeresen elküldve.



A második az adott számlának lekérdezi a szükséges soradatait.

46 Az első lekérdezést lefuttatva végigmegyek annak az eredményén, feldolgozom a fejadatait, majd lekérdezem a hozzá tartozó sorokat. Így feltöltöm az INVOIC objektumot a kívánt adatokkal, amiből ezután legenerálhatom.

7.3. Számlák elküldése A számlák elküldése és a válasz feldolgozása az utolsó lépés a feladat megvalósításában. Ennek a pontnak az elkészítése még folyamatban van. A kommunikációhoz az AS2 protokollt használjuk, az üzenetküldő modulhoz egy online tutorial [17] segítségét vettem igénybe. A tutorial (és kiegészítése, egy AS2 fogadó modul [18]) segítségével már sikerült célba juttatni AS2 üzeneteket, egyelőre titkosítás nélkül. A példakód az X.509-es szabványú tanúsítvánnyal történő aláírást használja, ezt én most kihagytam, mivel nem ezt fogjuk használni. Az X.509 szabvány a 80-as évekből származik, melyben nevekhez rendelünk nyilvános kulcsokat [19]. Nekem a titkosításhoz a 3DES algoritmust kell majd használnom, illetve aláíráshoz az SHA-1-et. A 3DES (Triple DES) a DES (Data Encryption Standard) algoritmust alkalmazza az egyes adatblokkokon, csak háromszor. A DES 56 bites kulcsokat használ, mely a 70-es években még elegendőnek bizonyult, azonban a számítógépek fejlődésével a brute-force feltörhetővé vált. Ezt küszöböli ki a 3DES, mely a DES háromszori alkalmazásával ezt megnehezíti. Az SHA-1 egy hashelési algoritmus, az SHA (secure hash algorithm) függvények egyike. 1995. óta használják, de ma már inkább az SHA-2, SHA-3 algoritmusokat ajánlják helyette. A .NET 4.5-ben a System.Security.Cryptography namespace-ben találunk osztályt mind a 3DES (TripleDES), mind az SHA-1 (SHA1) algoritmusok megvalósítására. A továbbiakban ezzel az üzenetküldő kóddal fogok majd dolgozni, cél a titkosítás megvalósítása, végül a két rész összeillesztése.

Összefoglalás és kitekintés

47

Összefoglalás és kitekintés Munkám első fejezeteiben bemutattam az integrált vállalatirányítási rendszereket, kiemelve közülük is az SAP Business One-t, és a fejlesztői eszközöket. Ezután a használt integrációs eszközöket mutattam be, két széles körben használt eszközt: az XML-t és az EDI-t, azon belül is az EDIFACT EANCOM INVOIC dokumentumtípust. Ezeket követően részleteztem a két megvalósításra váró addont, az ÁNYK XML exportot, mely egy, az ÁNYK-ba importálható 1365M nyomtatványt hoz létre XML fájlként, valamint az EDI alapú adatcserét. Végül bemutattam a megvalósítás sarkalatos pontjait és az elkészült pontokat. Az ÁNYK export addon február óta működik az ügyfeleknél. Folyamatosan karbantartjuk, figyelve és ellenőrizve mind a NAV által kiadott ÁNYK és 1365 nyomtatvány frissítéseket, mind az SAP által kiadott note-okat. Az EDI integráció fejlesztése most is folyik. Mivel a kereskedőtől kapott tesztelési időszakunk június elejére esik, ekkorra kell elkészülnie a kommunikáció egy tesztelhető verziójának, és július elsejével éles indulás lesz, tehát eddigre hiba nélkül kell működnie.

Köszönetnyilvánítás

48

Köszönetnyilvánítás Köszönöm a sok segítséget a T-Systems SBO-s csapatának: Balázs Andrásnak, Tóth Ádámnak, Pribék Ádámnak, Madarász Ákosnak, Hamarák Istvánnak, Karner Zoltánnak, de leginkább konzulensemnek, Hernádi Bálintnak. Köszönöm Vető Istvánnak a belső konzulensi szerep elvállalását, valamint Kiss Tímeának és Kurczina Gergőnek a támogatást és bíztatást, akik nélkül ez a dolgozat soha nem készült volna el.

Rövidítések jegyzéke

49

Rövidítések jegyzéke NAV: Nemzeti Adó- és Vámhivatal ÁNYK: Általános Nyomtatványkitöltő Program ÁFA: Általános Forgalmi Adó SBO: SAP Business One EDI: Electronic Data Interchange UN/EDIFACT: United Nations/Electronic Data Interchange For Administration, Control and Transport XML: Extensible Markup Language W3C: World Wide Web Consortium ERP: Enterprise Resource Planning (vállalati erőforrás-tervezés), magyarul integrált vállalatirányítási rendszernek nevezzük MRP I.: Material Requirements Planning, anyagszükséglet-tervezés MRP II.: Manufacturing Resource Planning, gyártási erőforrás-tervezés SDK: Software Development Kit, szoftverfejlesztő készlet SQL: Structured Query Language UID: Unique ID, egyedi azonosító API: Application Programming Interface, alkalmazás-fejlesztési interfész UI API: User Interface API, felhasználói interfész API DI API: Data Interface API, adat interfész API UDT: User Defined Table, felhasználó-definiált tábla UDO: User Defined Object, felhasználó-definiált objektum UDF: User Defined Field, felhasználó-definiált mező SCN: SAP Community Network DES: Data Encryption Standard SHA: secure hash algorithm

Irodalomjegyzék

50

Irodalomjegyzék

[1] T. F. Wallace és M. M. Kremzar, ERP: Making It Happen – The Implementers’ Guide to Success with Enterprise Resource Planning, New York: John Wiley & Sons, Inc., 2001. [2] J. Hetyei, ERP rendszerek Magyarországon a 21. században, 2. kiadás, Budapest: ComputerBooks, 2009. [3] W3C, „Extensible Markup Language (XML) 1.0 (Fifth Edition),” 7. február 2013.. [Online]. Available: http://www.w3.org/TR/REC-xml/. [Hozzáférés dátuma: 11. május 2013.]. [4] United Nations Economic Commission for Europe (UNECE), „Introducing UN/EDIFACT,” [Online]. Available: http://www.unece.org/cefact/edifact/welcome.html. [Hozzáférés dátuma: 11. május 2013.]. [5] Nemzeti Adó- és Vámhivatal, „2003. évi XCII. törvény az adózás rendjéről,” 14. szeptember 2003.. [Online]. Available: net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A0300092.TV. [Hozzáférés dátuma: 1. május 2013.]. [6] Jogi Fórum / MTI , „Tételes belföldi összesítő nyilatkozat - Január 1-től jelentősen megnövekedett az áfabevallások adattartalma,” 19. február 2013.. [Online]. Available: http://www.jogiforum.hu/hirek/29064. [Hozzáférés dátuma: 1. május 2013.]. [7] Á. Kása-Forgács, „ÁFA, ART, Helyi adók,” 17. december 2012.. [Online]. Available: http://www.mgibpo.hu/fajlok/hirlevel/ADO%202013_%20AFA%20ART%20Helyi%20adok.pdf. [Hozzáférés dátuma: 1. május 2013.]. [8] Nemzeti Adó- és Vámhivatal, „Nemzeti Adó- és Vámhivatal,” 2013.. [Online]. Available: http://nav.gov.hu. [Hozzáférés dátuma: 14. május 2013.]. [9] Nemzeti Adó- és Vámhivatal, „NAV – 1365,” 12. április 2013.. [Online]. Available: http://www.nav.gov.hu/nav/letoltesek/nyomtatvanykitolto_programok/nyomtatvanykitolt o_programok_nav/bevallasok/1365.html. [Hozzáférés dátuma: 28. április 2013.]. [10] Nemzeti Adó- és Vámhivatal, „Tételes belföldi ÁFA összesítő jelentés 2013. január 1jétől – 1365M nyomtatványrész (és kapcsolódó 1365A lapok) tervezete közös azonosítókkal és kitöltési útmutató tervezet,” 28. szeptember 2012.. [Online]. Available: http://www.nav.gov.hu/nav/letoltesek_egyeb/nyomtatvanytervezetek_2013/1365_nyomta

Irodalomjegyzék

51

tvanytervezet.html. [Hozzáférés dátuma: 27. április 2013.]. [11] Nemzeti Adó- és Vámhivatal, „A járulékbevallások XML formátuma,” 12. június 2009.. [Online]. Available: http://www.nav.gov.hu/data/cms9161/ABEV_XML_leiras__v9.0.pdf. [Hozzáférés dátuma: 28. április 2013.]. [12] GS1 Hungary, „EDI üzenetek,” 31. október 2011.. [Online]. Available: http://www.gs1hu.org/tudastar/questions/66/EDI+%C3%BCzenetek. [Hozzáférés dátuma: 12. május 2013.]. [13] United Nations Economic Commission for Europe (UNECE), „Part 4. UN/EDIFACT Rules - Chapter 2.2 Syntax Rules - Annex B,” [Online]. Available: http://www.unece.org/tradewelcome/areas-of-work/un-centre-for-trade-facilitation-and-ebusiness-uncefact/outputs/standards/unedifact/tradeedifactrules/part-4-edifact-rules-forelectronic-data-interchange-for-administration-commerce-and-transport/part-4-un. [Hozzáférés dátuma: 13. május 2013.]. [14] EDI Services, „List of Commonly Used EDI Segments,” 2007.. [Online]. Available: http://www.edi-services.com/commonly-used-edi-segments.htm. [Hozzáférés dátuma: 13. május 2013.]. [15] Sage Ltd., „EDIFACT Invoice ASCII File Layout Segments,” 2012.. [Online]. Available: http://www.sage.co.uk/sage1000v2_1/form_help/workingw/subfiles/edifact_invoice_seg ments.htm. [Hozzáférés dátuma: 13. május 2013.]. [16] GXS Ltd., „EDI AS2-ön keresztül,” [Online]. Available: http://www.edibasics.hu/typesof-edi/edi-via-as2.htm. [Hozzáférés dátuma: 13. május 2013.]. [17] M. Frear, „Send an AS2 message with .NET,” 13. július 2010.. [Online]. Available: http://mattfrear.com/2010/07/13/send-as2-with-dotnet/. [Hozzáférés dátuma: 13. május 2013.]. [18] M. Frear, „Receiving AS2 messages with .NET,” 3. január 2011.. [Online]. Available: http://mattfrear.com/2011/01/03/receiving-as2-messages-with-net/. [Hozzáférés dátuma: 13. május 2013.]. [19] M. Pásztor, „Kulcs-kérdések a digitális aláírásban,” 19. április 2001.. [Online]. Available: http://deneb.iszt.hu/~pasztor/kulcsk.html. [Hozzáférés dátuma: 13. május 2013.]. [20] GS1 Hungary, „Elektronikus kereskedelem,” 31. október 2011.. [Online]. Available:

Irodalomjegyzék

52

http://www.gs1hu.org/tudastar/questions/65/Elektronikus+kereskedelem. [Hozzáférés dátuma: 12. május 2013.]. [21] GXS Ltd., „AS2 Basics,” [Online]. Available: http://www.as2basics.co.uk. [Hozzáférés dátuma: 13. május 2013.].

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

Recommend Documents