sERPa súgó

Az Elektronikus Közúti Áruforgalmi Ellenőrző Rendszer ( EKAER / EKÁER ) előírása szerinti árukövetés a sERPa programban az alábbi módon került lekövetésre:

Jogszabályi háttér

A jogszabályi háttérről a kormányzati portálon ( https://ekaer.nav.gov.hu/ ) tájékozódhatunk.

Röviden fogalmazva az EKÁER segítségével nyomon követhetővé válik az áruk tényleges útja, hiszen a szállítással kapcsolatos adatokat (áru megnevezése, mennyisége, címzett, feladó adatai, szállító jármű rendszáma stb.) egy központi elektronikus rendszerben még a fuvarozás előtt kell rögzíteni. Ezen adatok egy része (termék tömege, értéke, a szállító gépjármű rendszáma) a szállítmány megérkezéséig módosítható, és az átvételi (kirakodási) helyre érkezés időpontját követő munkanapon is elegendő rögzíteni. A gépjármű rendszámának megadása nem feltétele az EKÁER szám megállapításának, azonban a fuvarozás megkezdéséig ezt az adatot is rögzíteni kell. Jogszabályi háttér értelmezése

PROGEN Nyilatkozat

A sERPa EKÁER modul a elősegíti a Elektronikus Közúti Áruforgalom Ellenőrző Rendszerbe való bejelentési kötelezettség teljesítését a NAV által biztosított interfészen keresztül.

A közvetlenül az EKÁER rendszerbe rögzített adatok automatikusan nem kerülnek vissza a sERPába, így előfordulhat, hogy a két helyen eltérő az adattartalom. A szinkronizálásra van lehetőség művelettel az EKÁER bevitelben.

A következő sERPa bevitelekben a felhasználó kezdeményezheti művelettel az EKÁER szám kérést a NAV rendszere felé:

-        Átadás

-        Szállítmány

-        Túraterv

-        Szállítólevél

-        Vevőrendelés

-        Szállítórendelés

-        EKÁER bizonylat

A visszakapott EKÁER szám megjelenik a fenti bevitelekben a képernyőn és a kinyomtatott bizonylatokon.

Az említett bevitelekben a sERPa által igényelt, érvényes EKÁER számra művelettel fejléc módosítási, tétel módosítási, törlési és véglegesítési kérést is indíthat a felhasználó a NAV rendszere irányába.

A sERPában a Kérés naplóban rögzítésre kerül az XML kérés, valamint a NAV által arra visszaküldött ellenőrző XML és a hibajelzés.

Regisztrálási, felhasználási információk és tapasztalatok

Regisztrálni kell a cég elsődleges felhasználóját, aki majd regisztrálhatja a másodlagos felhasználókat.

A honlapon történő regisztrációt követően a regisztrált user e-mailt kap a EKÁER-től, amelyben lévő linkre klikkelve be kell jelentkeznie az EKÁER-be: ezzel a bejelentkezéssel megtörténik a user aktiválása. Regisztrálásnál érdekes, hogy:

- a felhasználó név case sensitive (kisbetű-nagybetű érzékeny)

- a teszt rendszerhez külön regisztráció kell

- a teszt regisztrálásnál opcionális az adószám, de ha mégis megadjuk, akkor csak azzal lehet majd bejelentkezni.

 

Az EKÁER számkérés a szállítmány adatainak a megadásával 3 módon történhet (a portál tájékoztatása szerint) .

- WEB-es felület GUI-ján (Grafikus felületén) keresztül (Kézi tételes adatfelvétel.)

- WEB-en XML file feltöltéssel (Kézi XML file feltöltés, amely tartalmazza az adatokat.)

- Gép-gép kommunikációt támogató szolgáltatáson keresztül (Automatikus adatcsere ERP < -> EKÁER között)

 

A NAV által közétett kockázati besorolások az adatbázisban dbo.EKAERTarifa táblában találhatók, ahol a vámtarifaszám mellett a kockázati besorolás:

0 - normál

1 - egyéb kockázatos termékek

2 - élelmiszer kockázatos termékek

2022. január 1.-i változás: EKÁER szempontből kettő fajta vámtarifa van, a bejelentésköteles és nem köteles, dbo.EKAERTarifa tába a bejelentésköteles vámtarifaszámokat tartalmazza.

sERPa folyamatok

A sERPában az EKÁER számhoz szükséges adatokat

- Magyarország területéről az Európai Unió más tagállamába irányuló termékértékesítést vagy egyéb célú kivitelt, valamint belföldi forgalomban nem végfelhasználó részére történő első adóköteles termékértékesítést esetén import és  belföldi vevőrendelésből, vagy külföldi és belföldi értékesítés szállítólevélből,

- az Európai Unió más tagállamából Magyarország területére irányuló termékbeszerzést vagy egyéb célú behozatal esetén pedig import szállítórendelésből vagy külföldi beszerzés szállítólevélből (akár előfeldolgozottból is)

gyűjti össze.

Speciális eset a címzetti jelentés (1.7-es verziótól). Erre akkor van lehetőség, ha a szállításról a címzett, azaz a vevő gondoskodik, és nem a feladó. Ilyen esetben a címzettnek kell a bejelentést tennie, amit jelezni kell (az isSellerDelivery mezőben). Belföldi beszerzés esetén is van lehetőség rá az EKÁER jelentésre (a sERPa felhasználó a vevő / címzett), ebben az esetben ez címzetti bejelentésként küldjük a NAV felé.

A törvény csak a kockázatos termékeknél írja elő az érték-adatszolgáltatás jelentési kötelezettségét, így a nem kockázatos termékek - amennyiben EKÁER köteles - érték nélküli átadása is beállítható az EKÁER paraméterben. a sERPa alapértelmezésben minden értéket átad a NAV felé.

 

Súly és érték határokat a program kockázati kategóriánként összesítve vizsgál meg, EKÁER számonként.

Devizában nyilvántartott beszerzéseket és áru szállításokat az előző év december 31-i Magyar nemzeti Bank által közétett középárfolyamon Forintosítjuk. Értékszámításnál belekalkuláljuk az EKÁER paraméterben megadott érték tűrés százalékot is.

A tömeg meghatározásának algoritmusa

- bruttó tömeg

- nettó tömeg

- mennyiségegység, ha ISO kódja KGM

- mennyiségegység, ha az ISO kódja tömeg és abból visszaszámoljuk kilogrammra.

- hosszászámoljuk az EKÁER paraméterben megadott tömeg tűrés százalékot

 

EKÁER szám köteles:

- bejelentésköteles termék esetén, ha a bruttótömeg meghaladja az 500 kg-ot VAGY a nettó érték az 1 millió Ft-ot (érvényes: 2021. január 1-től)

- kockázatos termék esetén ha a bruttótömeg meghaladja az 500 kg-ot VAGY a nettó érték az 1 millió Ft-ot (érvényes: 2020. december 31-ig)

- nem kockázatos termék esetén ha a bruttótömeg meghaladja az 2500 kg-ot VAGY a nettó érték az 5 millió Ft-ot (érvényes: 2020. december 31-ig)

- 2016. augusztus 1-jétől nem kockázatos termék nem útdíjköteles gépjárművel való szállítása esetén ha az össztömeg meghaladja a 3500 kg-ot, ugyanúgy kell vizsgálni a súly és érték határokat, mint ha a gépjármű útdíjköteles volna. (érvényes: 2020. december 31-ig)

 

Export esetén (1.9-es verziótól) csak az első kirakodási címet lehet bejelenteni. EKÁER bizonylat generálás és egyben EKÁER számkérés esetén az első telephelyet jelenti be. Ha a felhasználó mindenképp meg akarja adni az első kirakodási címet, akkor három lépésben kell megtenni: EKÁER bizonylat generálás - a generált, előkészített EKÁER bizonylatban az első cím megadása - EKÁER szám kérés.

 

A sERPa  a következő szállítólevelekre és rendelésekre generál EKÁER bizonylatot:

- import és belföldi vevőrendelés

- belföldi értékesítési normál szállítólevél

- külföldi értékesítési (export) normál szállítólevél, ha a saját raktár címe magyarországi

- külföldi beszerzési (import) normál és előfeldolgozott szállítólevél

- import szállítórendelés

- raktárközi szállítólevél abban az esetben, ha a forrásraktár vagy a célraktár címe külföldi címmel rendelkező ügyfél (az iránynak megfelelően a típus "I" - import vagy "E" - export, az érték pedig a feltüntetett érték vagy annak hiányában a nyilvántartási érték)

- speciális eset - címzetti jelentés: belföldi beszerzés normál és előfeldolgozott szállítólevél

Amennyiben az EKÁER alapja a vevő- vagy szállítórendelés, a kérés és a kapott EKÁER szám

- kötelező visszaigazolás típusú rendelések esetén az adott pillanatban visszaigazolt állapotban lévő mennyiségekre,

- nincs vagy használható visszaigazolás típusúak esetén pedig a összes tételének rendelt és visszaigazolt mennyiségére

vonatkozik.

Ha egy vevő vagy szállítórendelésnek van EKÁER száma, a rendelést teljesítő szállítólevél automatikusan megkapja az EKÁER számot,  viszont a visszáru szállítólevél már nem.

 

Kettő fajta EKÁER kérést (create) különböztetünk meg

- manuális kérés művelettel: Szállítólevél, Átadás, Szállítmány, Túraterv, Szállítórendelés, Vevőrendelés és EKÁER bizonylat generálás bevitelekben a művelet generálja az EKÁER bizonylatot és/vagy elküldi a kérést

- automatikus kérés: az EKÁER paraméter bevitelben megjelölt műveletnél és bevitelekben a sERPA automatikusan legenerálja az EKÁER bizonylatot és elküldi a kérést.

A kérés aszinkron módon működik.

EKÁER verziók

 

1.8 verzió - sERPa 57-estől

- 2015. június 1-től egy bejelentésben több fel- és kirakodás cím megadása lehetséges az 1.8 interfész verzióban. Ennek módja, hogy egy EKÁER számhoz tetszőleges számú „menetlevelet” lehet rögzíteni. A menetlevél tartalmaz 1 felrakodási és egy lerakodási címet. Minden menetlevélhez tetszőleges számú árutételt lehet rögzíteni. Belföldről az Európai Unió más tagállamában található kirakodási (átvételi) címre történő közúti fuvarozás esetén kizárólag a sorban első kirakodási (átvételi) címet kell bejelenteni,

- sERPában az 57-es verziótól az 1.7 - 1.8 interfész konvertálás után azokat az EKÁER számokat nem lehet módosítani (modify), amely még az 1.7 interfészben készült, csak a NAV webes felületén.

 

1.9 verzió - sERPa 57-estől

- A rendszámokhoz felsorolt értékeket adtak meg a felségjelekre, ezeket beleépítettük az országtörzsbe (az ország bevitelben csak 58-as verziótól lesz látható).

- Súlyadatokat mostantól kezdve három tizedesjegy pontosságig adjuk át.

- Export esetén 1.9-es verziótól csak az első kirakodási címet lehet bejelenteni. EKÁER bizonylat generálás és egyben EKÁER számkérés esetén az első telephelyet jelenti be. Amennyiben ez nem megfelelő (máshol tárolnak ki a először), az EKÁER bizonylatban átírhatja, és elküldheti az EKÁER módosítási kérést. Ha a felhasználó mindenképp meg akarja adni az első kirakodási címet, akkor három lépésben kell megtenni: EKÁER bizonylat generálás - a generált EKÁER bizonylatban az első cím megadása - EKÁER szám kérés.

 

2.0 verzió

A 2.0-ás verzió élesítését követően életbe lép egy szigorítás a requestVersion értékét illetően, amely meggátolja, hogy alacsonyabb verzióval módosítsanak egy bejelentést, mint amilyennel létrehozták.

 

4.2.6.1 RequestVersion kötelezőség

A verzióban kötelezővé vált a header requestVersion eleme, továbbá a default 1.0 kezelés is megszűnik. (ha a tag üresen érkezett, 1.0-ként volt értelmezve)

 

4.2.6.2 Fuvar oka mező új validáció

Új validációt vezettek be a fuvar oka (tradeReason) mezőben: Az új, vagy meglévő belföld-belföld (tradeType = "D") irányú bejelentésekben az itemek tradeReasonje csak "Termék értékesítés / beszerzés" ("S") lehet.

 

4.2.6.3 NAVValidations válaszelem

A manageTradeCardsResponse-ban új válaszelem, a NAVValidations elem érkezhet, ha a bejelentés megfelel valamely erre vonatkozó feltételnek

Fontos, hogy a NAVValidations-t töltő validációk akkor is lefutnak, ha a requestVersion 2.0-nál alacsonyabb, de ebben az esetben a bejelentő nem értesül az eredményről!

 

4.2.6.4 Warnings válaszelem

A manageTradeCardsResponse-ban új válaszelem, a Warnings elem érkezhet, ha a bejelentés megfelel valamely erre vonatkozó feltételnek.

 

4.2.6.5 Külföldi adószám-validációk

- ha tradeType = 'E', akkor a destinationVatNumber tagban szereplő adószámot a destinationVatNumber első két betűje szerinti ország szabályával,

- ha tradeType = 'I', akkor a sellerVatNumber tagban szereplő adószámot a sellerVatNumber első két betűje szerinti ország szabályával

validálja a rendszer. Az engedélyezett országkódok azonosak a 2.3.2.6 pontban leírtakkal, azzal az eltéréssel, hogy görög adószám GR és EL prefixekkel is elfogadott, és mindkettő görög CDV szabályok szerint validálódik.

Ha a külföldi adószám CDV ellenőrzése szerint az adószám nem helyes, vagy ha a külföldi adószámban található országkód (első két betű) és a hozzá tartozó sellerCountry vagy destinationCountry tag értéke eltér, a rendszer 1.9-es requestVersion esetén INVALID_INPUT válaszüzenetet, 2.0-tól pedig a megfelelő VAT_NUMBER reasonCode-os választ küld.

Az adószám érvényességét a http://ec.europa.eu/taxation_customs/vies/ oldalon keresztül lehet ellenőrizni.

 

4.2.6.6 Súly- és értékvalidációk

A rendszer a bejelentésben megadott rendszámok, illetve az árutételek összesített nettó értékei és súlyai alapján a NAVValidations válaszelemben jelzi, ha a bejelentés az általánosan megszokott értékektől eltérő adatokat tartalmaz. Jelenleg az alacsony és magas nettó érték, illetve az alacsony és magas súly vizsgált.

 

4.2.6.7 Belföldi irányítószám-validáció

A magyar fel-és lerakodási címekben használható településneveket az irányítószámhoz tartozó, alábbi linken található “irányítószám törzsadatok” alapján kell kiválasztani:

https://ekaer.nav.gov.hu/faq/?page_id=9

Amennyiben ettől eltérő irányítószám + településnév kerül megküldésre, és a requestVersion legalább 2.0-ás, a rendszer a TC_WRONG_ZIP_CITY_WARN hibakódot küldi a NAVValidation válaszelemben.

Amennyiben a településnévben szóköz vagy zárójel szerepel, a validációhoz a rendszer az első szóközig vagy nyitó zárójelig veszi a megadott adatokat figyelembe. Így ahol az irányítószám zárójeles településnevet tartalmaz, ott elégséges csak a zárójel nélküli adatot küldeni. (Pl. a “Gárdony (Agárd)” település beküldésekor „Gárdony” kerül validálásra)

Amennyiben a bejelentés több fel-és lerakodási címet is tartalmaz, a NAVValidation message-ben visszaadásra kerülnek a helytelen település és irányítószám párok.

 

4.2.6.8 loadDate és arrivalDate mezőkkel kapcsolatos változások

• Export esetén amennyiben a felrakodás időpontja (loadDate) mező nem kerül kitöltésre, a warnings válaszelemben egy erre utaló warning fog érkezni (ez nem befolyásolja a működést, csupán tájékoztató jellegű).

• Import vagy belföldi (domestic) bejelentés létrehozása esetén, ha a lerakodás időpontja (arrivalDate) mezőt kitöltjük, akkor TC_ARRIVALDATE_TIME_ERROR hibát kapunk a válaszban.

Tehát bejelentés létrehozásakor NEM adható meg a lerakodás időpontja, azonban a bejelentés lezárása előtt kötelező megadni.

FONTOS: 2.0 requestVersion-től bejelentés módosításakor SEM adható meg az arrivalDate, amelyre szintén a TC_ARRIVALDATE_TIME_ERROR hibakódot kapunk a válaszban.

FONTOS! A loadDate és az arrivalDate elem együttes használata a vonatkozó jogszabályban foglaltak alapján nem indokolt. Kérjük, hogy a kéréseikben mindig csak az adott szállítási viszonylatnak megfelelő elemet szerepeltessék.

• A loadDate/loadDateOnly elemet csak és kizárólag Export irányú bejelentés esetében töltsék ki.

• Az arrivalDate/arrivalDateOnly elemet csak és kizárólag Import és Belföld-belföld irányúbejelentés esetében töltsék ki.

Azokat a 2.0-ás kérés verzióval beküldött bejelentéseket, amelyekben a loadDate/loadDateOnly, illetve az arrivalDate/arrivalDateOnly rovat együttesen szerepel, az EKÁER nem fogja feldolgozni.

 

4.2.6.9 Egyebek

• QueryParams bővülése: sellerVatNumber, destinationVatNumber (opcionális szűrőmezők).

• A manageTradeCardsResponse item szinten új válaszelemmel (productVtszGroupName) bővült, mely a VTSZ-számhoz tartozó VTSZ csoport nevét tartalmazza.

• A tagállami irányítószám mezők maximálisan megengedett hossza 7 karakterről 10-re növekedett.

 

4.2.6.10 Új reasonCode-ok 2.0-ás verziótól

TC_DESTINATION_VAT_NUMBER_CDV_ERROR – Címzett külföldi adószáma hibás, ld: 4.2.6.5

TC_SELLER_VAT_NUMBER_CDV_ERROR – Feladó külföldi adószáma hibás, ld: 4.2.6.5

TC_FOREIGN_VAT_NUMBER_COUNTRY_CODE_MISMATCH – Külföldi adószám és a feladó/címzett országkódja eltér, ld: 4.2.6.5

TC_LOW_TOTAL_VALUE_WARN – alacsony nettó érték esetén küldött validációs üzenet

TC_HIGH_TOTAL_VALUE_WARN – magas nettó érték esetén küldött validációs üzenet

TC_LOW_TOTAL_WEIGHT_WARN – alacsony nettó súly esetén küldött validációs üzenet

TC_HIGH_TOTAL_WEIGHT_WARN – magas nettó súly esetén küldött validációs üzenet

TC_WRONG_ZIP_CITY_WARN – irányítószámhoz nem megfelelő település küldése belföldi címeknél

TC_LOAD_LOCATION_ERROR - A menetlevélhez tartozó felrakodási cím rossz!

TC_UNLOAD_LOCATION_ERROR - A menetlevélhez tartozó lerakodási cím rossz!

TC_LOAD_AND_UNLOAD_LOCATION_ERROR - A menetlevélhez tartozó lerakodási és felrakodási cím rossz!

TC_LOADDATE_TIME_WARN - felrakodás ideje nem definiált

TC_ARRIVALDATE_TIME_ERROR - A Kirakodás időpontja nem lehet adott létrehozásnál!

TC_CARRIER_HIBERNATED - A Carrier törlés alatt van

TC_CUSTOMER_HIBERNATE_DENIED – Nem lehet hibernálni

INVALID_REASON_WITH_TRADE_TYPE - A fuvar okok a tételnél a fuvar irányultságtól függően meghatározottak lehetnek csak

TC_INVALID_COUNTRY_CODE – Inaktív, vagy nem létező országkód fel- vagy kirakodási címben való használatakor érkezik ez a hiba.

TC_INVALID_VAT_NUMBER_COUNTRY_CODE – Inaktív, vagy nem létező országkód adószámban való használatakor érkezik ez a hiba.

TC_FINALIZED_MOD_NOT_ALLOWED - A bejelentés utólagos módosítása (correction operation) nem engedélyezett.

TC_FINALIZED_CARRIER_MOD_NOT_ALLOWED – A bejelentés utólagos módosítása (correction operation) szállítmányozónak nem engedélyezett.

TC_FINALIZED_EXPORT_MOD_NOT_ALLOWED - Export bejelentések nem módosíthatók (correction operation-nel) lezárást követően.

TC_FINALIZED_NO_MORE_MOD_ATTEMPTS - A bejelentés több alkalommal nem módosítható(correction operation esetén).

TC_FINALIZED_MOD_INVALID_DATA_CHANGE - Csak a vonatkozó rendeletben meghatározott adatok módosíthatók (correction operation-nel).

TC_FINALIZED_ITEM_DELETE_NOT_ALLOWED - A bejelentésben szereplő termékek nem törölhetők(correction operation-nel).

TC_FINALIZED_ITEM_CREATE_NOT_ALLOWED - A bejelentéshez nem adható hozzá új termék (correction operation-nel).

TC_FINALIZED_MOD_NO_DATA_CHANGE - A módosítás nem tartalmaz adatváltozást!

TC_VAT_NUMBER_WARN - Feladó/Címzett adószáma "HU" országkóddal való beküldése esetén érkező validációs üzenet!

TC_VAT_NUMBER_ERROR - A feladó és címzett adószáma nem egyezhet meg!

 

4.2.6.11 XSD validáció szigorítás

A 2.0 verziótól kezdve az XML üzenetek XSD szerinti validációja szigorúbbá válik az újabb technológiai elvárásoknak köszönhetően. Például az elementek nem megfelelő sorrendje, illetve az XSD névterek helytelen használata már hibát fog okozni 2.0, vagy magasabb kérések esetén.

 

4.2.6.12 Inaktív országkódok tiltása bejelentés létrehozásakor

Új bejelentés létrehozásakor az alább felsorolt, országkódot tartalmazó mezőknek azon túl, hogy értékét csak az 2.3.2.6 pontban leírt országok közül választhatja, az adott országnak aktív státuszban is kell lennie (azaz Európai Uniós tagállam).

Érintett mezők:

• Fel- és kirakodás országa – hiba esetén 2.0 verziótól TC_INVALID_COUNTRY_CODE, alacsonyabb verziójú kérés esetén INVALID_INPUT.

• Adószámokban az országkód prefix – hiba esetén 2.0 verziótól TC_INVALID_VAT_NUMBER_COUNTRY_CODE, alacsonyabb verziójú kérés esetén INVALID_INPUT.

 

4.2.6.13 Fel- és kirakodás dátumának és időpontjának szétválasztása

A fel- és kirakodás mező pontossága a 2.0 verziótól kezdve a felhasználóra van bízva. Ez azt jelenti, hogy választható nap pontosságú (xsd:date), illetve (az 1.9-es és korábbi működés szerinti) időpont pontosságú (xsd:dateTime) formátum.

A korábbi loadDate és arrivalDate mezők helyére választható (xsd:choice) elemek kerültek. Ezek:

• Választható loadDate (felrakodás időpontja, xsd:dateTime), vagy loadDateOnly (felrakodás dátuma, xsd:date).

• Választható arrivalDate (lerakodás időpontja, xsd:dateTime), vagy arrivalDateOnly (lerakodás dátuma, xsd:date).

 

4.2.6.14 Bejelentés véglegesítésében (finalize) történt változások

A lerakodás dátumát, vagy időpontját (arrivalDate/arrivalDateOnly) a 2.0 verziótól sem bejelentés létrehozáskor, sem módosításkor nem lehet megadni. Ezen esetekben az 2.0-ás verzióban bevezetett TC_ARRIVALDATE_TIME_ERROR hibakód fog érkezni új szövegezéssel: „A Kirakodás időpontja csak a megérkezés bejelentésekor, az EKÁER-szám lezáráskor adható meg!”.

A bejelentés véglegesítése (finalize) műveletben viszont kötelezően küldeni kell a lerakodás dátumát, vagy időpontját (arrivalDate vagy arrivalDateOnly adattag).

FONTOS: A 2.0 requestVersion alatti verzióval küldött lezárási kérések esetében az arrivalDate megadása nem lesz kötelező. Amennyiben a felhasználó rendszere még nem képes a 2.0 verzió változásait támogatni, úgy a bejelentés lezárásának folyamata a megszokott módon történik. Azaz modify üzenettel meg kell adni az arrivalDate-et és egy finalize üzenettel le kell azt zárni (arrivalDate küldése nélkül!).

 

4.2.6.15 Lezárt bejelentés módosítása

A rendszer a 2.0 XML verziótól kezdve lehetőséget biztosít lezárt bejelentések utólagos módosítására.

Ehhez egy új tradeCardOperaion-t vezetünk be, correction néven.

A művelet használata 2.0-ás requestVersion-től lehetséges. 1.9 vagy az alatti kérések esetén INVALID_INPUT hibakód fog érkezni a következő üzenettel: "A correction operáció csak 2.0 requestVersion-től küldhető!".

 

2.1 verzió

 

vatRateAssuranceExemption bevezetése

A 2.1-es requestVersion-nel küldött kérésekben az új vatRateAssuranceExemption elem is szerepelhet, korábbi requestVersion-nel beküldött kérésekben viszont nem. Az új elem a tradeCardItem adatai közé kerül.

A rendszer az adott tradeCardItem productVtsz elemében található VTSZ alapján ellenőrzi, hogy a jelölő küldhető-e „true” értékkel, ami az 5 százalékos áfamérték miatti biztosítékmentességet jelöli.

• Ha a felhasználó nyilatkozhat az adott termék biztosítékmentességéről, akkor a rendszer elfogadja a „true” értékkel küldött jelölőt, és az adott termékre nem köt le kockázati biztosítékot.

• Ha a felhasználó nem nyilatkozhatna az adott termék biztosítékmentességéről, de a jelölőt mégis „true” értékkel küldi be, akkor a rendszer a kérést a TCI_INVALID_ASSURANCE_STATEMENT hibaüzenettel elutasítja.

• Ha a kérésben nem szerepel az új jelölő, akkor azt a rendszer alapértelmezetten „false”-ként kezeli.

 

4.2.7.1 Új reasonCode-ok a 2.1-es verziótól

TCI_INVALID_ASSURANCE_STATEMENT – az adott VTSZ-nél nem lehet az 5 százalékos áfamértékmiatti biztosítékmentességről vatRateAssuranceExemption = true értékkel nyilatkozni.

 

EKÁER beállítások

1.  Kapcsolat létesítése a NAV EKÁER rendszerével

A B2B partner funkcióban adjuk meg a NAV felületen kapott felhasználó nevet, jelszót és XML titkosítási kulcsot. A Típus legyen Szolgáltató, pipáljuk ki az EKÁER pipát, és állítsuk be a Szerver típusát.

Mindig csak egy EKÁER B2BPartner sor legyen Használható, a többiről vegyük ki ezt a pipát.

FONTOS: az éles és a teszt rendszerhez külön regisztrálni kell, az éles bejelentkezési adatokkal a teszt szerverhez nem tudunk csatlakozni, és fordítva sem.

 

2.  EKÁER paraméter beállítása

Az EKÁER bejelentéshez szükséges paramétereket állítsuk be az EKÁER paraméter bevitelben.

- Manuális kérés esetén az Automatikus EKÁER szám kérés értékét Nincsre állítsuk be, automatikus kérés esetén (FEJLESZTÉS ALATT) pedig meg kell adnunk a kérést indító műveletet (bizonylat mentés vagy nyomtatás) és a bevitelt.

- sERPa az EKÁER bizonylattételben terméket ad át az interfésznek a leírás szerint, de amennyiben termék név helyett VTSZ megnevezését szeretnénk látni a NAV rendszerében, pipáljuk ki a Jelentés VTSZ megnevezéssel pipát.

- Alapértelmezésben a sERPa minden értékesítést első adókötelesnek, minden import, export és belföldi mozgást, minden vevő rendelést és import szállítórendelést EKÁER kötelesnek tekint. Ha szűkíteni akarjuk a kört, megadhatjuk az első adóköteles termékkategóriát, a jelentésköteles mozgásnem és rendelés sorozat kódképletét, ebben az esetben csak ezeknél a mozgásoknál, rendeléseknél, és ennél a termékkategóriánál generálunk EKÁER bizonylatot.

 

 

3. Manuális EKÁER szám kérés, módosítás

EKÁER számot kérni, valamint meglévő EKÁER számhoz tartozó adatokat módosítani a következő bevitelekből lehet:

- EKÁER bizonylat generálás

- EKÁER módosítás

- Szállítólevél funkció, Vevő rendelés funkció, Szállító rendelés funkció, Szállítmány funkció, Átadás funkció, Túraterv funkció bevitelekből művelettel.

Ha vevőrendelésből vagy szállítórendelésből kérünk EKÁER számot, az az egész rendelésre vonatkozik. Ha részteljesítésre szeretnénk EKÁER számot kérni, létre kell hozni egy szállítólevelet (ami lehet előfeldolgozott is) és arra kérjünk EKÁER számot.

Ha több szállítólevélre vagy több rendelésre szeretnénk egyszerre kérni EKÁER számot, az említett bizonylatokat gyűjtsük össze Szállítmányban, esetleg Átadásban (csak egy ügyfélnek való értékesítések) vagy Túratervben, és az gyűjtő bizonylatban generálunk EKÁER bizonylatot.

A EKÁER jelentési kötelességi vizsgálatnál figyelembe vesszük a gépjárművet (útdíjköteles vagy nem), a súlyhatárt (fixen be van programozva), az értékhatárt (fixen be van programozva), az első adóköteles termékkategóriát (ha meg van adva), a mozgásnemet és rendelés sorozatokat (ha meg van adva) és a kockázatos besorolást (NAV honlapjáról letöltött, nem módosítható adatok).

Az EKÁER bizonylat minden tételénél látszik az EKÁER jelentési kötelezettség:

 

Hibakeresés

Nincs kapcsolat a NAV szerverrel

- EKÁER kérés a naplóban időtúllépés hibaüzenet: nincs internet kapcsolat, nem elérhető a NAV szerver

- EKÁER kérés a naplóban autentikációs hibaüzenet: hibás néven és jelszón túl a titkos XML kulcs is lehet hibás, vagy egyáltalán nincs megadva a NAV felületen

 

Autentikációs hiba

Általános hiba, hogy az éles adatokkal próbálnak NAV TESZT szerverre bejelentkezni vagy fordítva.

 

EKÁER bizonylat nem frissül

Ha egy EKÁER bizonylat alapbizonylataiban módosítunk adatokat, jelenleg nincs lehetőség arra, hogy azokat érvényesítsük az EKÁER bizonylatban. Ebben az esetben ha még nincs EKÁER szám, akkor EKÁER bizonylat törlés és újragenerálás a megoldás.

 

EKÁER bizonylat nem generálódik

- a bizonylat nem felel meg az EKÁER paraméterben megadott szűréseknek

- a mozgásnem nem tartozik az következők közé: belföldi értékesítés, külföldi értékesítés, külföldi beszerzés

- szállítórendelés és belföldi a reláció

- vevő vagy szállítórendelés esetén ha rendelés-visszaigazolás kötelező vagy használható és nincs visszaigazolva

- a terméknek nincs VTSZ száma, bruttó súlya

 

EKÁER bizonylat elkészült, de számot nem kapunk és nincs hibaüzenet

A bizonylatban egy tétel sem EKÁER köteles, erről az EKÁER bizonylat tétel fülön lévő utolsó oszlopban találunk információt.

 

EKÁER bizonylat elkészült, de számot nem kapunk és hibaüzenet: Hiba történt az adatfeldolgozás során

Elméletileg csak a NAV Teszt rendszerre adhat ilyen hibát, később próbálkozzunk!

 

EKÁER bizonylat elkészült, de számot nem kapunk és hibaüzenet: Címadat hiba

Ellenőrizzük a címadatok kitöltöttségén túl:

- van házszám?

- általános a közterület megnevezése?

- régi  2015.03.03 előtti verziókban (interfész verzió: 1.5) kötelező a közterület

A cím ellenőrzés algoritmusa a következő:

- ha van helyrajzi szám, akkor azt jelentjük

- ha találunk a címben közterületet, csak akkor érvényes a cím, ha van házszám is

- ha nem találunk a címben közterületet, ha van házszám akkor közterület nélküli címet adjuk fel (2015.03.03 utáni 55-os és 56-os verziókban, interfész verzió: 1.6), ha házszám sincs, akkor az egész szöveget a helyrajzi számként.

 

EKÁER bizonylat elkészült, de számot nem kapunk és hibaüzenet: Ismeretlen hiba ?

Ellenőrizzük:

- minden rendszámhoz van felségjel?

- ha van gépjármű törzsünk, ott is vannak felségjelek?

 

EKÁER szám véglegesítésnél hiba: Érkezési dátum üres!

A véglegesítés műveletnél a NAV felé nem lehet megadni az érkezési dátumot, így véglegesítés művelet előtt egy módosítási művelettel meg kell adni azt.

 

 

Érintett funkciók