XML és EDI alapú integrációs kapcsolat kialakítása SAP Business …users.itk.ppke.hu/~buzan/szakdolgozat_msc/buzsaky_andrea... · 2013-05-16 · XML és EDI alapú integrációs

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

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

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

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

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

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

3.3. Addonok ................................................................................................................... 18

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

4.1. XML ......................................................................................................................... 22

4.2. EDI ........................................................................................................................... 22

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

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

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

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

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

tervezésnek (röviden MRP) nevezzük. Célja az alapanyagok megrendelésének felügyelete


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.


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ás-

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


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:

<?xml version="1.0" encoding="UTF-8"?>

<mezok>

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

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


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ő áfa-

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


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


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


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.


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ó


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:

<?xml version="1.0" encoding="utf-8"?>

<nyomtatvanyok xmlns="http://www.apeh.hu/abev/nyomtatvanyok/2005/01">

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>12345678901</adoszam>

</adozo>

<idoszak>

<tol>20130101</tol>

<ig>20130331</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


é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="0A0001E008A">Demo Hungary Zrt.</mezo>


<mezo eazon="0A0001E012A">Budapest</mezo>

<mezo eazon="0A0001E013A">Kis u. 123.</mezo>

<mezo eazon="0A0001E014A"></mezo>



<mezo eazon="0A0001E023A">Budapest</mezo>

<mezo eazon="0A0001E024A">Kis u. 123.</mezo>




<mezo eazon="0A0001F001A">20130101</mezo>

<mezo eazon="0A0001F002A">20130331</mezo>

<mezo eazon="0A0001F005A">H</mezo>

<mezo eazon="0A0001I001A">Budapest</mezo>

<mezo eazon="0B0001B001A">12345678901</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>12345678901</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>87654321</azonosito>

</albizonylatazonositas>

<idoszak>

<tol>20130101</tol>

<ig>20130331</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.


18. ábra

<mezok>

<mezo eazon="0A0001C001A">12345678901</mezo>

<mezo eazon="0A0001C004A">Demo Hungary Zrt.</mezo>

<mezo eazon="0A0001C005A">87654321</mezo>

<mezo eazon="0A0001C007A">Alpha Hungary Kft.</mezo>

<mezo eazon="0A0001D001A">20130101</mezo>

<mezo eazon="0A0001D002A">20130331</mezo>


…

<mezo eazon="0A0001E0006DA">65994</mezo>

<mezo eazon="0D0001C0001AA">61008048 B13-008048</mezo>

<mezo eazon="0D0001C0001BA">20130102</mezo>

<mezo eazon="0D0001C0001CA">28405</mezo>

<mezo eazon="0D0001C0001DA">7669</mezo>





…













</mezok>

</nyomtatvany>

…

</nyomtatvanyok>


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


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


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


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


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 nvarchar(255)

,@PeriodEnd 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 ÜP név

Ûrlap

kód

Bizony

lat

szám

Szall

Ref

Szam

Elõzmény_

RefSzam

Korrekció_

típus

12101517

Boro

Zoltán AR01 226

12101517

Boro

Zoltán AR01K 226

E

12101517

Boro

Zoltán AR01K 10

K

23460900

Eszet

Lenke AP02 252

E

23460900

Eszet

Lenke AP6D 251

E


Alap

bizonylat_

száma

Bizonylat

dátum Adó dátum ÁFA_Alap

ÁFA_

összeg

2MFt_alatti

_ÁFA_összeg

2013-01-28

00:00:00.0

00

2013-01-28

00:00:00.00

0

8000.0000

0000000

2160.0000

0000000 0.000000

2013-01-28

00:00:00.0

00

2013-01-28

00:00:00.00

0

8000.0000

0000000

2160.0000

0000000 0.000000

226

2013-02-01

00:00:00.0

00

2013-02-01

00:00:00.00

0

-

8000.0000

0000000

-

2160.0000

0000000 0.000000

2013-01-28

00:00:00.0

00

2013-01-28

00:00:00.00

0

12000.000

00000000

3240.0000

0000000 1080.000000

2013-01-28

00:00:00.0

00

2013-01-28

00:00:00.00

0

4000.0000

0000000

1080.0000

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.


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:


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

)))

));


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

bpo.hu/fajlok/hirlevel/ADO%202013_%20AFA%20ART%20Helyi%20adok.pdf.


[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 1-

jé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-e-

business-uncefact/outputs/standards/unedifact/tradeedifactrules/part-4-edifact-rules-for-

electronic-data-interchange-for-administration-commerce-and-transport/part-4-un.


[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/types-

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


[21] GXS Ltd., „AS2 Basics,” [Online]. Available: http://www.as2basics.co.uk. [Hozzáférés


Documents

XML és EDI alapú integrációs kapcsolat kialakítása SAP Business …users.itk.ppke.hu/~buzan/szakdolgozat_msc/buzsaky_andrea... · 2013-05-16 · XML és EDI alapú integrációs