Hírlevél 2018. június

 

Tartalomjegyzék:

1. NAV online számla XML fejlesztés állása

2. Számla készítést érintő változások

3. Mi a teendő, ha nem készíthető el a számla XML jelentés.

4. Beérkező számlák 12 pozíciónál hosszabb számlaszáma.

5. Devizaszámlán FIFO számítás javítása.

6. Áfa megosztás kontírozása

 

1. NAV online számla XML fejlesztés állása

 

E témában már kettő Hírlevél készült, 2018.04. és 2014.05. dátummal. Az első levél főleg a regisztrációval, a második levél a működéshez szükséges (törzs)adat kiegészítéssel foglalkozik. Az érdeklődök a Megastar honlapon megtalálják az előző leírásokat is.

A 2018. július 1-jétől hatályos jogszabályok szerinti, a Megastar programokkal készült számlák adatszolgáltatási kötelezettségéhez készülő fejlesztésével június közepén az alábbi fejlesztési szinten tartunk. Mielőtt a részletekbe belemennénk, pár szót kell mondani az adatszolgáltatás környezetéről.

Jelenleg a fejlesztés a NAV által biztosított egy „teszt” környezetben történik, a fejlesztés és a próbák ebben a környezetben folynak. Ha a felhasználóknak rendelkezésére fog állni a próbálás lehetősége, akkor nekik is ebben a környezetben kell, kellene dolgozni. Az „éles”, a valós feldolgozás, az adatszolgáltatás egy „másik” környezetben fog működni. Tehát van egy „teszt” és egy „valós” feldolgozási környezet, amelyek teljesen elkülönülnek egymástól. Az „éles” környezetben a korábban elkészült regisztrációkat meg kell ismételni, a programoknak „ott is” rendelkezésre kell állniuk és a számla készítéskor a felhasználónak el kell döntenie, hogy teszt vagy valós számlát fog-e készíteni. Jelenleg a valós környezet létrehozásának a NAV felületeken nem találjuk nyomát. Feltehető, hogy a felhasználók többsége nem akar a teszt környezetben dolgozni, hanem azonnal az éles, valós környezetet akarja használni.

A továbbiakban fontos lesz a „kézi adatszolgáltatás” lehetősége. Jelenleg ennek a felületnek, a kézi bevitel leírásának sem látjuk a nyomát a NAV illető honlapjain. (Ez azért is fontos lenne, mert a kézi bevitel adatainak értelmezése, a képernyő kitöltési szabályainak ismerete bizonyosan segítené az XML képző program készítését.) A témában feltettünk kérdést a NAV felé, választ nem kaptunk eddig.

A teszt környezetben elkészült:

-       Az adatszolgáltatás igényeinek megfelelő adat kiegészítések, mind a törzs (tartós) és a forgalmi (változó) adatokhoz.

-       XML képző program.

-       Az elküldést vezérlő és nyilvántartó program.

-       Az elküldött XML adatok státuszát lekérdező és nyilvántartó program.

-       Jelenleg folyamatosan próbáljuk a számla készítést és a beküldést (a teszt környezetben.)

-       Elkészült egy több funkciós felület a kezelők számára. Indításhoz itt szükséges a Megastar programok számára „áthozni” a regisztrációs folyamatban a felhasználó által a NAV számára megadott adatokat (azonosító, jelszó, jogosultság, stb.). Ezeknek az adatoknak ismeretében tud a gépi adatszolgáltatás automatikusan működni. További lehetőség, hogy biztosítva van az XML adatképzés kezelők általi figyelemmel kísérése. A kezelő az adatszolgáltatásra kötelezett számlák állapotát, történetét figyelemmel tudja kísérni. Többek között e felületen tudja a kezelő (manuálisan is) lekérni az egyes számlák NAV státuszát, és indítani ismételt beküldést, stb.

A fejlesztői csapat folyamatosan figyelemmel kíséri a NAV megnyíló lehetőségeit, valamint a szinte menetrendszerűen 8 – 10 naponként érkező változásokat.

 

2. Számla készítést érintő változások

 

A NAV ide vonatkozó rendelkezései, értelmezései miatt szükségessé vált a számlázó programunk módosítása, az új igényeknek megfeleltetése. Emiatt némely régi funkciók megszűnnek, mások megváltoznak, és új funkciók is beépítésre kerülnek. A legfontosabb változás a számla életút nyilvántartása, a vonatkozó rendelkezés szerint ugyanis egy gazdasági eseményről kiállított számla a számla, minden egyéb módosulás módosító okmányként értelmezendő. Így tehát egy számla sztornózása után, ha szükséges új számla kiállítása, ez az eredeti számla módosító okmányaként tehető meg.

A számla életút nyomon követéséhez minden módosítás csak kiválasztással lehet érvényes. Mivel a rendelkezés számláról és számlát módosító okiratról tesz említést, a jelenleg használt helyesbítő és jóváíró ágak megszűnnek, a sztornó és rontó átalakul, módosító okmány készítése, mint új elem belép a rendszerbe.

 

A továbbiakban tehát sztornó (érvénytelenítő), rontó (érvénytelenítő) és módosító számlák készíthetőek.

Számla érvénytelenítésére több okból is sor kerülhet. Ilyenkor, ha a gazdasági esemény nem valósult meg, vagy nem a felek között valósult meg, érvénytelenítést követően létrejön egy sztornó számla, de nem keletkezik újabb bizonylat az eseményről.

1, Tévesen, teljesítés hiánya miatt válhat szükségessé a számla érvénytelenítése (Áfa tv. 55. § (2)).

2, Rossz vevőnek állítottam ki a számlát. Ilyenkor szintén nem fog már ehhez az ügylethez kapcsolódóan új számla keletkezni, nem kell megtartani a számlák módosítási „láncolatát”.

3, Még számla kiküldése előtt rájövünk, hogy adattartalmában helytelen a számla.

Ezekben az esetekben a Csak stornó gombot kell választanunk. (Rontózás esetén pedig a Csak rontó gombot kell választanunk.)

Abban az esetben pedig, ha a gazdasági esemény megvalósult ugyan a felek között, de a kiállított számla valamilyen adatában hibás, az érvénytelenítést követően a sztornó számla mellett keletkeztetünk az eredeti számlához kapcsolódóan egy új bizonylatot is az adott ügyletről, hogy a módosítási láncolatot megtartsuk. Ebben az esetben érvénytelenítéskor az Új számla gombot kell választatunk.

Sztornózás esetén:

 

Rontózás esetén:

 

A sztornót és rontót érintő további változás, hogy nem a kiválasztott bizonylatot egy az egyben képzi le ellenkező előjellel, hanem az eredeti számla és ennek összes módosító okiratának eredményét képzi ellenkező előjellel. Itt ezentúl lehetőség lesz kérni a programtól, hogy módosítható (nem elkészült) állapotban generálja le ismét a számlát és módosításait, hogy ebben javítva számlát módosító okiratot hozhassunk létre, mely az eredetileg kiállított számla életútját folytatja. (Fenti képernyő Új számla gomb)

Amennyiben a sztornó után egyidejűleg új bizonylat (nem elkészült) is keletkezik, úgy mind a számlán, mind az arról készült adatszolgáltatásban is hivatkozás lesz az eredeti számlára.

Számla módosítása

Lehetőség van a számlát érintően csak egyes tételekről módosító okiratot képezni. Itt ki kell jelölni a módosítani kívánt tételsorokat, és ezekről a program megképzi a negatív mennyiségű eredeti sorokat, és a pozitív előjelű módosító sorokat. Az eredeti sorokhoz nem nyúlhatunk hozzá, a módosító sorokat viszont tetszés szerint módosíthatjuk. Cikkszám csere esetén törölhetjük, és az új cikket, mint új sort vihetjük fel a módosító okmányra. Tehát a módosító okirat hasonló módon működik majd, mint a régi helyesbítő számla, csak nem a számla egészét „mínuszolja-plusszolja”, hanem a felhasználó által kiválasztott tételsorokat. (A sorok végén lévő kis négyzetben kell jelölni pipával, hogy mely sorok kerüljenek módosításra, ezután meg kell nyomni a Képzés gombot.)

Mivel az életút szempontjából szigorítani kellett, hogy csak kiválasztással keletkezhet módosító okirat, így a program lehetőséget biztosít arra, hogy előző évből válasszunk ki számlát módosításra, érvénytelenítésre. Az újonnan keletkező módosító okmány azonban mindig a tárgyévben fog keletkezni.

Átadás készlet felé

A számlák könyvelésbe feladását nem érinti ez a fejlesztés, ám a készlet rendszerbe átadást igen. Mint az a fentiekből látszik, innentől nem egy az egyben kapcsolat lehetséges csak a számlák és a készlet értékesítések között. Például, ha érvénytelenítünk egy számlát, aminek volt már módosító okirata, akkor az a készletben már eleve két bizonylat, és mind a kettőt érvényteleníteni kell.  Illetve ha a módosító okirat nem érinti a számla minden tételsorát, nem lehet egy ez egyben stornózni a készletben sem. Ezért a sztornó ág továbbra is sztornó típusú készletnövelést végez, csak egyszerre több készletcsökkentést is beállít sztornózottnak – ha szükséges, másrész a módosító okirat nem sztornó típusú készletnöveléssel kerül át, hanem normál típusú visszáru eseményként (mint régen a jóváíró számla, és az előző évi helyesbítő számla tette). A program elkészült készletbizonylatokat képez, amennyiben értékhelyesbítés szükséges, azt a szokásos értékmódosítást lehetővé tevő menüpontban elvégezhetjük. 

 

3. Mi a teendő, ha nem készíthető el a számla XML jelentés?

 

A 2018. július 1-jétől hatályos, pénzügyminiszter 2/2018. (VI. 1.) PM rendelete (a számla és a nyugta adóigazgatási azonosításáról, valamint az elektronikus formában megőrzött számlák adóhatósági ellenőrzéséről szóló 23/2014. (VI. 30.) NGM rendelet módosításáról) szabályok 13/A. § és a 13/B. § paragrafusok részletesen szabályozzák, hogy mi a teendő, ha az adóalany rendszerének működési hibájából nem sikerül az előírt időben adatszolgáltatást teljesítenie. A 13/B. § szerint:

(5) A (4) bekezdéstől eltérően az adatszolgáltatásra kötelezett adóalany rendszerének 48 órát meghaladó üzemzavara vagy az internet szolgáltatás elégtelensége esetén ezt a tényt az adatszolgáltatásra kötelezett adóalanynak az állami adó- és vámhatóság rendszerében legkésőbb a 48 órás időtartam leteltekor jeleznie kell és az adatszolgáltatást ezen időtartam leteltétől számított 24 órán belül az állami adó- és vámhatóság rendszerében a kiállított számla, számlával egy tekintet alá eső okirat legalább Áfa tv. szerinti kötelező adattartalmának manuális rögzítésével köteles teljesíteni. Amennyiben ezen 24 órás időkeret alatt az üzemzavar vagy az internet szolgáltatás elégtelensége nem hárul el, az időkeret az állami adó- és vámhatóság rendszerében tett ismételt bejelentéssel újabb 24 órával meghosszabbítandó mindaddig míg az üzemzavar, internet szolgáltatás elégtelensége fennáll.”

A program felhasználója számára a programok nem megfelelő működése olyan „üzemzavar” amely elhárítása külső szakemberek feladata. Értelemszerű, hogy a szolgáltató a programot szállító-üzemeltető szervezet felé azonnal jelezni kell a problémát, amely szállító haladéktalanul neki lát a probléma, az akadály elhárításának.

A Megastar mind a SaaS használati ÁSZF (5.4.), mind a saját szervert használó ügyfelek szerződései tartalmazzák „A felhasználó kármegelőző kötelezettségei” feltételeit. Ez szerint a felhasználó köteles a programok működését figyelemmel kísérni és a felmerülő problémát haladéktalanul jelezni a program szállítója felé. Értelem szerű, hogy a 24 illetve 48 órás határidejű feladatokat azonnal, illetve pár órán belül kell jelezni a szállító felé. Mivel ez a NAV adatszolgáltatási rendszer olyan hatalmas, bonyolult (a leírása több száz oldal) és a hibátlan működés nagyon sok feltételtől függ, ezért bizonyosan – főleg az első időszakban – lesz olyan, a programok működésével összefüggő probléma, amelyet nem sikerül a program szállítónak 24 illetve 48 óra alatt elhárítani. Az ilyen eset a program használat szempontjából „vis maior”, amelyet a szállító visszajelez a felhasználónak. Ekkor a felhasználó, saját jól felfogott érdekében is, köteles a fenti 13/B. § (5) pont alapján az illető számláról az adatszolgáltatást manuális rögzítéssel teljesíteni.

A szállító, üzemeltető Megastar a NAV online adatszolgáltatás program – átmeneti – akadálya esetén, a felhasználó manuális adatszolgáltatásának elmulasztásának kárát, az ezért kirótt büntetést nem vállalja át. Természetesen a Megastar – a szerződésnek megfelelően – igyekezik haladéktalanul javítani, módosítani a programot, hogy a felhasználó normál üzemmenete az automatikus adatszolgáltatás, XML küldés legyen. 

 

4. Beérkező számlák 12 pozíciónál hosszabb számlaszáma

 

Az ÁFA időszakos jelentése és egyéb nyilvántartási szempontok miatt szükség lehet az ügyfelektől beérkező számlák számlaszámának teljes megjelenítésére. A Megastar programok első közelítésben, csak 12 pozíciós számlaszámokat kezelnek. (Ez bőven elég az azonosításhoz. A probléma abból ered, ha a számlaszámba különböző kódolási szempontokat is szerepeltetni akarnak. Év, szervezeti kód, termék típus, stb.) Ilyenek pl. a közüzemi számlák, amelyben a számla kibocsájtója egész kódrendszert szerepeltet akár 18 – 20 pozíció hosszan. A problémára, a kód bevitelére, tárolására és megjelenítésére a Megastar rendszerben is van megoldás, anélkül, hogy a korábbi működést és a kiírások helyfoglalási formáját megbontanánk. 

A főkönyvi bevitelben szerepel egy adat, „Azonosító ügyfélnél” 24 pozíciós alfanumerikus adat, amelybe be lehet írni, azaz a programmal be lehet másoltatni, az ilyen extra hosszú számla számokat. Van egy paraméter, a 1145 számú, REND_AZON_BOV nevű. Ha ez IGEN-re van állítva, akkor a BIZ_SZAM adatba bevitt karakter sor lehet hosszabb (24 pozícióig). A Könyvelés – Pénzügy adat beviteli program az ide beírt adatot átteszi az Azonosító ügyfélnél adatba, de az eredeti helyén, a BIZ_SZAM adatba csak 12 pozícióig tárolja, levágja a végét. A hosszú számlaszám kinyerésének lehetőségét adja, hogy néhány kimutatásban opcionális, hogy a BIZ_SZAM mi legyen.

Az ÁFA bevalláskészítésénél, ahol tételesen szerepelhetnek a beérkező számlák, itt opcionális, hogy a jelentésbe, listába mit tegyen a „Számla sorszáma” adatban. Lehet kérni az „Azonosító ügyfélnél” adat szerepeletetését. A fenti működés esetén mindenképpen van valami ebben az adatban, amely így a számla kibocsájtó Számla száma.. Vagy a 12-nél nem hosszabb számla szám, vagy a hosszabban megadott számla szám.

Tehát a jövőben ajánlatos beállítani a fenti paramétert, és az adatbevitelnél ily módon tölteni az „Azonosító ügyfélnél” adatot IS. Így ahol szükséges, például az ÁFA bevallásban, ezt kell szerepeltetni.

 

5. Devizaszámlán FIFO számíítás javítása

 

Devizaszámla nyilvántartásról akkor beszélünk, ha a bankszámla devizakódja eltér a könyvelési deviza kódjától. Ilyen esetben a Napló törzsadatnál ezt jelezni kell, meg kell adni az illető deviza kódját.

Az ilyen „tükörnaplón” a devizaszámla forgalom rögzítésének szigorúbb a technikája, mint a normál banki, főkönyvi forgalomé. Az egyes banki események szigorú időrendjét be kell tartani ahhoz, hogy a kiadásokhoz mindig kellő mennyiségű deviza álljon rendelkezésre. Tehát a valóságban is fennálló feltételt biztosítani kell, hogy csak olyan pénzt vehetünk ki, amely a bankban bent van.  A számláról történő fogyasztás ún. FIFO (first in first out) módszerrel történik, ezért fontos a bizonylatok rögzítésének sorrendje. A devizaszámla állományát növelő (bevét) bizonylatok rögzítésekor a program a bizonylat dátumára korábban berögzített árfolyam és a bevételezett deviza összege alapján számolja ki a könyvvezetési deviza és a forint összegét. A kiadási bizonylatokon forint összegek az iktatás/könyvelés alkalmával kerülnek a megfelelő értékmezőkbe a korábbi bevételek rekordjaiból.

Amennyiben a devizaszámla forgalmának iktatás/könyvelése után derül ki, hogy hiba van a bevitt adatokban, például hiányzik adat, vagy rossz az összeg, vagy az árfolyam, vagy mondjuk, márciusban derül ki, hogy nem vitték be az év elejei nyitott, stb., ekkor a program új lehetőséget biztosít a javításra. Szinte függetlenül a hiba jellegétől az adott naplóhoz tartozó forgalmat csak egyben (első bizonylattól az utolsóig) lehet/kell kezelni. Azaz az egész évi forgalmat, mint egy – javításra felhozott forgalmat – kell kezelni. Mivel ez a forgalom már könyvelt bizonylatokat tartalmaz, amik alapesetben nem módosíthatók, be kell állítani egy kezelő paramétert (2300), ami – egy alkalommal - engedélyezi a már könyvelt devizaszámlás bizonylatok módosításhoz vagy törléshez történő visszaiktatásnál az adatállomány változtatását. Az egész évi forgalmat a program – a korábbi tételeket letörölve – év elejétől a forgalmi területen lévő tételekkel, dátum sorrendben újraszámolt FIFO értékekkel könyveli le. Tehát az adott naplón csak az egész évi forgalmat lehet javítani, módosítani.

 

Fontos, hogy a forgalom rögzítésénél kellő körültekintéssel járjanak el, hogy javításhoz csak indokolt esetben kelljen folyamodni!

 

 

A gyakorlatban előfordulnak olyan számlák, melyek ÁFA tartalma csak részben igényelhető vissza. Ebben az esetben a levonásba helyezhető ÁFA összege nem azonos a befogadott számla teljes ÁFA összegével.

Ha azonban az eredeti számla ÁFA összege meghaladja az összesítő jelentés határát, akkor ebben a jelentésben a tényleges visszaigényléstől függetlenül a teljes alap – ÁFA összeget kell szerepeltetni. Ahhoz, hogy ezt a program kigyűjtése korrekt módon tegye, az alábbi könyvelési eljárást kell alkalmazni:

Két ÁFA kódpár létrehozása szükséges: az egyik a tényleges visszaigénylést könyveli az ÁFA számlára (pl. 48-49, a főkönyvi szám 466), a másik esetében a megjelölt főkönyvi szám nem ÁFA számla, hanem az eredeti költségszámla (pl. 50-51, a főkönyvi szám 5-ös).

A 48–49 páros alkalmazandó a számla azon részénél, amelyből az ÁFA visszaigényelhető. Ezt eddig is így könyvelte mindenki. Az a része a számlának, melyből az ÁFA nem kérhető vissza, eddig egy 450 (vagy hasonló) kóddal egy összegben került könyvelésre. Ehhez a továbbiakban az 50 – 51 kódpár alkalmazandó. Felosztja tehát ezt a részt is alapra, ÁFÁ-ra, de mindkét összeget az általunk megjelölt költségszámlára könyveli. A tétel rögzítésekor hibaüzenetet ír ugyan (ÁFA kód mellett NEM ÁFA számla szerepel), de engedi lekönyvelni a tételt.

Ebből az is következik, hogy ha több költségszámlát érintő, de hasonló módon kezelendő számlánk is van (távközlés, üzemanyag), akkor több ilyen ÁFA kódpárt kell létrehozni (ahány költségszámlát érintenek a számlák).

Amennyiben ez több költségszámlát is érint, és ez sok ÁFA kódpár létrehozását kívánná, akkor ezt egyszerűsíthetjük: egy kódpárt hozunk létre, amelyben egy átvezetési számlát jelölünk meg. Így azonban további könyvelési lépés szükséges: az átvezetési számláról át kell könyvelni az összegeket a megfelelő költségszámlára