NAV XML export

Közösségi kerekasztal

Üdv!
2016.01.01-től a számlázó rendszerekben már kell egy XML formátumú "számlaadat kigyűjtő" funkció (XML export).
Az XML-ben a kibocsátó címe hat részre van tagolva:
közterület neve
közterület jellege
házszám
épület
emelet
ajtó

Sok szoftverben a cím csak egy mezőben van tárolva. Ez probléma az XML export szempontjából? Vagy lehet az utolsó 5 mező üres (közterület jellege, házszám, épület, emelet, ajtó)?

  • 10275 megtekintés

( meszfer | 2016. 01. 05., k – 15:47 )

Egy kicsit el vagy maradva ezzel a kérdéssel.
Igen szükséges szétbontani.
Itt egy két kérdésre még találsz infót:
LINK

Te vagy elmaradva. :-)
A GYIK_II_vegleges.pdf szerint:

10. A címadatok között szereplő „Közterület jellege” mezőbe milyen címadat kerülhet? Kötelező a címadatokat megbontani?
Azt, hogy a közterület jelleget egy számlán milyen formában kell feltüntetni – például utca/u./u stb. – a jogszabály nem határozza meg, így kizárólag az adózó döntése. Az adatexport során az adatszolgáltatásban olyan formában kell megadni a közterület jellege adatot, ahogy az a számlán is szerepel. Így például ha a számlán a közterület jellegeként, mint utca az „utca” szó szerepel, akkor azt kell feltüntetni az adatszolgáltatásban is, de ha például az „u.” fordulat szerepel, akkor az lesz a feltüntetendő adat stb.
Az XSD sémában a 10 féle címadat közül csupán 3, azaz az irányítószám, a település és a közterület neve tartozik az ún. kötelező mezők közé. Ezeket szükséges elkülöníteni. Azonban
a közterület neve egy 1-100 karakterig terjedő szöveges mező, így például az XSD szerint elfogadható az a megoldás, ha az irányítószám és város megjelölésén kívül minden címadat ebben a mezőben szerepel, vagyis nem lesz hibás az XML állomány. Ugyanakkor az adózóknak törekedniük kell arra, hogy lehetőleg teljes körű adatszolgáltatást nyújtsanak.

GYIK_szamlazo_program(1) szerint:
Mivel a Rendelet 2-3. mellékleteinek az alkalmazása kötelező, az abban foglaltaktól nem lehet eltérni, ezért pl. a cím adatok egy mezőben történő szerepeltetése nem fogadható el.
Az XSD címadatokra vonatkozó egyes mezőinél a "minoccurs=0" kitétel azért szerepel, mert bizonyos címeknél például nem értelmezhető a Közterület jellege (pl.: helyrajzi szám esetén), vagy például nincs Házszám, Emelet, Ajtó, így ezekhez a mezőkhöz nem feltétlenül tartozik adat. Amennyiben a számlán szereplő címben nem szerepel Házszám, Emelet, Ajtó adat, akkor azt az XML adatszolgáltatásnak sem kell tartalmaznia.

Tudom, ez egy hónappal korábbi verzió, viszont ez a jogi szempont, a te idézeted technikai.
Tehát, ha g*c*zni akarnak, számon kérik rajtad, hogy miért nincs bontva. Akkor aztán mutogathatsz egy jogszabálynak nem tekinthető PDF-re...
Én ezért száműztem éppen a ClearAdmin használatát, mert ott még a lehetősége sincs meg a bontásnak, mert a fenti GYIK alapján úgy döntöttek, nem kell. Viszont az adózó, vagyis a te meg az én felelősségem, hogy az adattartalom rendben legyen. (Az egész szépsége az, hogy a felhasználón lehet számonkérni a program hibáját.)

Már meg ne haragudj, de te is arra mutogatsz...
Mitől lenne a régebbi magyarázat jogi, az újabb meg technikai? Mindkettő NAVos, és miután ellentmondanak egymásnak, az újabb az irányadó.

Mellesleg a jogszabály 3. melléklete egy megadott XML sémát ír elő, amit technikai eszközzel ellenőrizni lehet. Ha ellenőrzöd és jó, akkor jó. (Az hogy alkalmatlan eszközt választottak nem én hibám.)
A 2. mellékelt meg egy magyarázat a 3.melléklethez amiben leírják pl.: hogy a rezsicsökkentés szövege milyen színű legyen. (ilyen összebaszott szart törvénynek hívni... nonszensz)

Technikai: „Azonban a közterület neve egy 1-100 karakterig terjedő szöveges mező, így például az XSD szerint elfogadható az a megoldás, ha az irányítószám és város megjelölésén kívül minden címadat ebben a mezőben szerepel, vagyis nem lesz hibás az XML állomány.”
Jogi: „Mivel a Rendelet 2-3. mellékleteinek az alkalmazása kötelező, az abban foglaltaktól nem lehet eltérni, ezért pl. a cím adatok egy mezőben történő szerepeltetése nem fogadható el.”

A kettő nem mond ellent egymásnak. A technikai azt állítja, nem lesz formai hibás az XML-ed, ha nem bontasz, a jogi azt, hogy bontanod kell.
A NAV (vagy korábbi APEH) ilyen jellegű anyagai egyébként sem minősülnek jogszabálynak, a NAV nem jogértelmezhet, arra jelenleg csak a bíróságnak van lehetősége. Egy jogszabályt pedig a jogalkotó szándékával összhangban kell értelmezni, tehát, ha a jogalkotó szerint bontani kell, akkor bontani kell.

És igen, nonszensz jogszabályaink vannak, az adókkal kapcsolatosakhoz még hozzájárul az is, hogy a NAV az ÁNYK-ban és a mögöttes feldolgozó rendszerekben jogszabályokat „értelmez”. A két évvel ezelőtti ÁNYK-ban összerakott SZJA bevallásomat visszadobta a NAV, hogy formai hibás. Egy olyan kitételre hivatkoztak, ami az ÁNYK-n átment, a saját ellenőrző rendszerükön nem, és az SZJA törvényből a kitételt a könyvelőm sem tudta levezetni. A NAV-os ügyintéző először széttárta a karját, hogy érti, hogy nonszensz, de a rendszer úgy nem fogja elfogadni, ahogy a valóságnak megfelel. FACEPALM

Az elmaradás csak a téma felvételére szólt mivel hatályos dologról beszélünk.
Köszönöm az újabb infót.
Ezt tényleg nem láttam még mivel mikor rámentem a témára még nem volt fent.
Rengeteg melóval látott el ez a téma (több programot is érintett) így nem is volt időm nézelődni.

Sajnos, szerintem is sok dolog ellentmond egymásnak a leírásokban. Sokat agyaltunk, olvastunk a szenvedő társammal ez ügyben.
De végül az alap vélemény mindig az volt, hogy ne a programozó vonja meg a lehetőséget a helyes/teljes értékű adatszolgáltatástól,
mivel akkor mi leszünk elővéve ha bármi van.
Minden esetben mi vagyunk a madzag végén.

Persze plusz infónak örülünk mindig.

( Darkfish | 2016. 01. 05., k – 16:21 )

Egyben szeretném jelezni hogy ez az egész mekkora GIGANTIKUS faszság.

Ugyanis miközben NEM KÖTELEZŐ eleme az adatszolgáltatásnak, hogy a számla milyen pénznemben van (tehát, EUR, HUF vagy dollár), ugyanakkor:
"Az összesítésbe tartozó egyes mezőket annak a pénznemnek megfelelően kell kitölteni, ahogy az adott összeg a számlán szerepel, vagyis ha külföldi fizetőeszközben van kifejezve, akkor abban."

Magyarán az export során az adóhatóság meg sem tudja tippelni, hogy forintban mekkora összegről beszélünk. Ergó semmilyen bevallás vagy összesítés ellenőrzésére nem alkalmas.
Az hogy a kelte szerint szűrnek, arra ki sem térek, mert a bevallásokat a teljesítés dátuma alapján kell elkészíteni...

Lehet, hogy inkább POFÁTLANSÁG? Mi van akkor, ha más szempontok sokkal fontosabbak? Ezzel az adatszolgáltatással az eladó eddig üzleti titokként kezelt adatai vándorolnak nagyjából ellenőrizetlenül ki tudja hova. Ide értem a szerződött partnerek körét, forgalmazott termékek/szolgáltatások körét, ezek megbontását térben és időben, stb. Gyakorlatilag fel lehet térképezni, hogy hol van még üres hely a piacon, illetve kitől kell tartani esetleg kinek a helyét érdemes átvenni.

majdnem. Azzal kicsit mellényúltak, mert a szolgáltatásokkal kapcsolatban nem tudtak adatot gyűjteni. Hát ki kellett találni valamit, amivel erre vonatkozóan is kémkedhetnek.
Én arra vagyok még kíváncsi, hogy vajon mennyi idő múlva fogják ismeretlenek (van egy tippem előre, kaya ibrahim & josip tot co.) "feltörni" a rendszerüket, és "ellopni" a beküldött adatokat.

2006-óta működtek elektronikus naplós pénztárgépek, azok adatait minden évben CD/DVD-re kellett írni, és az APEH-nak beküldeni. Mivel a naplók gyártónként eltérő formátumban készültek, ezért feldolgozni nem nagyon tudták, de azokban is benne volt minden. Később megszületett az elektronikus napló 2.0, új nevén adóügyi ellenőrző egység. Ez már feldolgozható formában tartalmazta, hogy melyik Tesco/Auchan/stb miből mennyit és mikor forgalmazott. Ezek az adatok jó sokat érhetnek, gondolom ezért terjesztették ki a számlázó rendszerekre is, Ide nekem, még, kolbászt! alapon.

Te valamit félreértesz. Ez egy NAV ellenőrzés esetén előkerülő adatexport. Nem tudom láttál-e már NAV ellenőrzést. Bejelentetlenül kimennek a céghez - akár fegyveresen - és szépen lementik a gépek-szerverek tartalmát és elviszik, aztán otthon kielemzik.

Ezzel az adatszolgáltatással semmivel több adat nem kerül a NAV-hoz és főleg nem realtime. Ugyanolyan esetben kerül hozzá adat (kivonulós NAV ellenőrzés) csak egy számukra jóval kényelmesebben feldolgozható formátumban kapják meg a könyvelési adatokat. Eddig a lementett image-ben kotorásztak a könyvelőprgram adataiban, most pedig kötött formátumú XML-ben kapják.

Ez teljesen alkalmatlan arra amit irsz, nem tudják vele feltérképezni a piacot, legalábbis semmivel sem jobban, mint az elmúlt 10 év gyakorlata alapján.

Amit vizionálsz, az majd akkor lesz aktuális, amikor ugyanezt a kötött XML formát be fogják rakatni a számlázóprogramokba online-ra, realtime, vagy lekérdezős alapon. Biztos vagyok benne, hogy meg fogják lépni, ugye ha mára mindenki elkészitette az export funkciót a számlázójába, onnantól nem egy nagy dolog, hogy be is küldje akár naponta az xml file-t a NAV-nak.

Az ismeretlen formátumú adatban kotorászás csak akkor vezet eredményre, ha nagyon ki akarják szedni belőle a dolgokat és elegendően nagy erőforrást vetnek be ennek érdekében. Ezzel szemben a kötött xml-ből nagyságrendekkel kisebb erőfeszítéssel bármit ki tudnak nyerni. Információim szerint az online összekötésre már nem kell sokat várni, annyit biztosan nem, mint erre az xml-re. Ugyanis már 2006 előtt felmerült a számlázó programok szigorú ellenőrzésének gondolata. Hasonló megoldáson törték a fejüket, mint a pénztárgépek esetében. Azóta eltelt közel 10 év, az online pénztárgépek már egy ideje működnek, naponta többször küldözgetik az xml-eket, innen már csak egy lépés a számlázó programokat is bekényszeríteni ebbe a körbe. A jelenlegi elképzelés is kvázi online működésű, mert megkeresésre bármikor elő kell tudni állítani tetszőleges intervallumra az exportot és el kell küldeni a NAV-nak.

Hogy egy későbbi időpontban előállhat olyan helyzet, meg esetleg... Pontosan erről irtam, a post pedig amire választoltam, mindezt jelen időben a nav xml export kapcsán jelentette ki, ami nem állja meg a helyét.

" A jelenlegi elképzelés is kvázi online működésű, mert megkeresésre bármikor elő kell tudni állítani tetszőleges intervallumra az exportot és el kell küldeni a NAV-nak."

Nagyon messze van az online-tól, az hogy a nav kivonul vagy "megkér". Hogy? telefonon felhiv? Ugyanmár.
Ez egyelőre csak lázálom, jelenleg semmi ilyen veszélyt nem rejt a kötelező adatexport funkció implementálása.
Hogy később mi lesz azt majd meglátjuk.

( royal v | 2016. 01. 05., k – 22:11 )

Mi úgy gondoljuk, hogy a bontás / nem bontás dolog eldöntésének a felelősségét nem szeretnénk átvállalni az adatszolgáltatótól. Azaz megcsináltuk a bontást, megcsináltuk a támogatást a tömeges bontáshoz és az egyesével való bontáshoz is, viszont nem akadályozzuk meg a felhasználót abban, hogy (egy figyelmeztetés ellenére) olyan címet használjon, amilyet csak akar.

Egyszer volt egy olyan mondat valamilyen NAV-os anyagban, hogy "felmerül az osztott felelősség lehetősége". Azaz ha a rendszer tudja, de a felhasználó nem használja, akkor az az Ő döntése. Ha a rendszer nem is biztosít lehetőséget a bontásra, akkor a felhasználó teljesen nyugodt szívvel fog a fejlesztőre mutogatni... Ki tudja, mit hoz a jövő :D

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Tényleg pusztán kíváncsiságból kérdezem: mind 40 fajta záradékot és tételsort precízen lefejlesztettétek, vagy ti is csak remélitek, hogy az ügyfél nem ad el autót, hajót, repülőt, beszállókártyát, dohányterméket, ásványolajat, CSK-kódú, TK-kódú, termikdíj köteles terméket, népegészségügyi adó alá eső terméket, energiát, árverési terméket, adó vagy tranzitzóna raktáras terméket?

Mert ezek hiányában valójában nem teljesítitek a törvényben foglalt feltételeket.

Meg ahogy nézem, szerintem SENKI nem felel ezeknek meg. Legalábbis a többség amit átnéztem biztosan nem.

+ egy idézet az állásfoglalásból:
"fontos megjegyezni, hogy az Art. 172. § (1) bekezdés h) pontja külön tényállásban rendelkezik arról, hogy az adózó mulasztási bírsággal sújtható, ha a külön jogszabályban meghatározott feltételek megsértésével állít elő és/vagy hoz forgalomba nyomtatványt, számlázó programot. Amennyiben tehát a számlázó program nem felel meg a Rendelet követelményeinek, úgy a számlázó programot előállító, forgalmazó adózó felelőssége is felmerülhet a 2016. január 1-jén, illetve azt követően értékesített számlázó programok tekintetében."

Ahogy átnéztem a NAV-féle doskit, én is valami hasonlóra gondoltam. Egyetértek, hogy ez az egész tényleg - finoman szólva - egy maflaság.
Szerintem ez az export funkció csak egy egyszerű számlaformátumra fog korlátozódni. Nem hiszem, hogy ezt a sok opciót valaki is lefejlesztette/lefejleszti a rendszerébe.

Az olyan záradékokat, amelyek előfordulnak ügyfeleinknél (pl. csomagolószer termékdíj, termékdíj átvállalás, NETA, különbözeti adózás, stb.) azokat mind lefejlesztettük. Amit viszont nem támogatunk (pl. dohánytermék, vizi/légi/szárazföldi közlekedési eszközök, adóraktár, árverési termék, stb.) azok egyértelműen fel vannak sorolva a dokumentációban kivételként, hogy ezen termékek/szolgáltatások bizonylatolására az eVIR nem használható.

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( STP | 2016. 01. 05., k – 22:56 )

Szerintem nem kell XML, amennyiben PDF-ben van tárolva a számla.

„19. § Adóhatósági ellenőrzés céljából az adóalany az xml formátumban megőrzött számla adatait a 2. melléklet szerint és a 3. mellékletben meghatározott adatszerkezetben, az egyéb elektronikus formában megőrzött számla esetében a 2. melléklet szerint és a 3. mellékletben meghatározott adatszerkezetben, vagy pdf formátumban köteles rendelkezésre bocsátani.”

23/2014. (VI. 30.) NGM rendelet
9. Számla és nyugta ellenőrzése
19. §

( herka v | 2016. 01. 06., sze – 12:23 )

Hali!

Az a 6 felé tagolás jó lesz 10-nek is a cím esetében :) ! (ti: Irányítószám, Település , Kerület , Közterület neve , Közterület jellege, Házszám , Épület, Lépcsőház, Szint, Ajtó )

A GYIK 2 -ben sehol sincs arról szó, hogy a GYIK 1 érvénytelen lenne.

Az érdekes dolgok ott kezdődnek, ahol egy mezőben 2 féle adatot is fel kellene tüntetni pl. hrsz + utcanév is.
És pl. a külföldi címekről ne is beszéljünk...

A címeket daraboló algoritmust azért megnézném, hogy mikor mit miért és hova vág...

Nem csak az M$ számol furán... A Zinternet lenne ilyen gyors?
65% [62 Sources 1528 kB/6239 kB 24%] 3062 PB/s 0s

( enpassant v | 2016. 01. 06., sze – 17:35 )

A törvényben sajnos az xsd képként szerepel és sajnos sehol sem találtam meg szöveges állományként.
A jogszabály word állományos verziója volt még a legjobb forrás, mert ott szövegesen volt az xsd, de azt is a képből OCR-ezhették, mert teli volt felismerési hibákkal.
Ezeket javítottam és most közkinccsé teszem.
Arra, hogy teljesen megegyezik a törvényben szereplővel, garanciát nem tudok vállalni!

Itt az XSD segítségével validálhatjuk számla exportunkat

( pappe v | 2016. 01. 06., sze – 19:57 )

A NAV 2015.11.17-én kiadott 1. állásfoglalása: http://hirlevel.nav.gov.hu/data/cms382428/Egyeztetett_Adozasi_kerdes___…

21. Milyen adatszerkezetben kell a számlán szereplő „cím” adatokat átadni? Amennyiben „cím” adatok között a közterület neve, jellege, házszáma nem választható szét a számlázó programban, elegendő-e egy cellában szerepeltetni ezeket?
A Rendelet 2. melléklet szerint mind a számlakibocsátó, mind a számlabefogadó cím adatait az alábbi bontásban kell tartalmaznia az adatszolgáltatásnak.
Iranyitoszam, Település, Kerület, Közterület neve, Közterület jellege, Házszám, Épület, Lépcsőház, Szint, Ajtó

Mivel a Rendelet 2-3. mellékleteinek az alkalmazása kötelező, az abban foglaltaktól nem lehet eltérni, ezért pl. a cím adatok egy mezőben történő szerepeltetése nem fogadható el.

Az XSD címadatokra vonatkozó egyes mezőinél a "minoccurs=0" kitétel azért szerepel, mert bizonyos címeknél például nem értelmezhető a Közterület jellege (pl.: helyrajzi szám esetén), vagy például nincs Házszám, Emelet, Ajtó, így ezekhez a mezőkhöz nem feltétlenül tartozik adat. Amennyiben a számlán szereplő címben nem szerepel Házszám, Emelet, Ajtó adat, akkor azt az XML adatszolgáltatásnak sem kell tartalmaznia.

A NAV 2015.12. 21-én kiadott 2. állásfoglalása: http://hirlevel.nav.gov.hu/data/cms387074/GYIK_II_vegleges.pdf

10. A címadatok között szereplő „Közterület jellege” mezőbe milyen címadat kerülhet? Kötelező a címadatokat megbontani? Azt, hogy a közterület jelleget egy számlán milyen formában kell feltüntetni – például utca/u./u stb. – a jogszabály nem határozza meg, így kizárólag az adózó döntése. Az adatexport során az adatszolgáltatásban olyan formában kell megadni a közterület jellege adatot, ahogy az a számlán is szerepel. Így például ha a számlán a közterület jellegeként, mint utca az „utca” szó szerepel, akkor azt kell feltüntetni az adatszolgáltatásban is, de ha például az „u.” fordulat szerepel, akkor az lesz a feltüntetendő adat stb. Az XSD sémában a 10 féle címadat közül csupán 3, azaz az irányítószám, a település és a közterület neve tartozik az ún. kötelező mezők közé. Ezeket szükséges elkülöníteni. Azonban a közterület neve egy 1-100 karakterig terjedő szöveges mező, így például az XSD szerint elfogadható az a megoldás, ha az irányítószám és város megjelölésén kívül minden címadat ebben a mezőben szerepel, vagyis nem lesz hibás az XML állomány. Ugyanakkor az adózóknak törekedniük kell arra, hogy lehetőleg teljes körű adatszolgáltatást nyújtsanak.

Az új állásfoglalás enyhített az előző állásfoglalásban szereplő vevő cím megadáson. A kötelező helyett "Törekedni kell" megfogalmazást használ!

Nem azt mondom, hogy egyáltalán nem tudják, hanem hogy nem tudják a megfelelő információkat rendesen szétbontani a kért XML mezőkbe. Ellenőrizd le, hogy rendesen működik-e a számlázódban, hasonlítsd össze a kimenetet a NAV által elvárt XML formátummal, de azt is nézd meg, hogy adott információ a megfelelő XML mezőbe kerül-e, és minden kért információ a számlákról bekerül-e az XML-be. A NAV bármikor kérheti tőled az XML-t (azonnal szolgáltatni kell), és téged büntetnek meg, ha nem jó, nem a számlázó fejlesztőjét.

Sajnos egy megfelemlitett vilagban elunk. Nem tudod elkepzelni hogy:
- navos emberke nem ávós, nem harap azonnal?
- buntetes nem csodolteti be a ceged
- informaciohoz akarnak jutni, nem rogton buntetni
- szamla xml csak egy resze az adohatosagi vizsgalatnak

A 10. xml bekuldes utan beszeljuk meg ujra...

--------------------------------
www.symbolcloud.hu

Ezzel most mit akarsz mondani, hogy nem fontos, tudja-e a számlázó a rendeletben előírt helyes XML exportot, mert úgysem büntet érte a NAV? Lehet, hogy nem, de büntethet, ha akar. A maximális büntetés egyéni vállalkozásnál 200 ezer Ft, cégnél 500 ezer Ft (lásd https://www.nav.gov.hu/data/cms387074/GYIK_II_vegleges.pdf 6. pont). Ennél lehet kevesebb is vagy nulla.

Inkább én nem reménykednék abban, hogy nem lesz büntetés, hanem előre ellenőrizni kell az XML-t, csinálni kell próba exportot a számlázóprogram felhasználójának és megnézni, minden helyesen működik-e.

Gondolom ebben az is szerepet játszik, hogy a NAV nem kéri. Tudomásom szerint több ügyfelünknél is volt már idén NAV ellenőrzés, de egyetlen alkalommal sem kérték az XML exportot...

Valaki látott már olyan embert, aki hallott olyanról, akinek az ismerősénél volt NAV ellenőrzés és elvitték az XML-be kiexportált adatokat? :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

És még eszembe jutott, hogy 2016. január 1. után kiállított számlákra már tudni kell XML lekérdezést indítani. De ha nem bontja már most szét a számlázó a megfelelő XML mezőkbe a bevitt adatokat, akkor ha később kérik majd az XML-t, akkor hogyan fogja a számlázó előállítani a megfelelő formátumot?

Ezeket a köröket úgy 8-10 hónapja lefutottuk már itt is egy másik topicban, nekem olyannak tűnik, mintha onnan idézgetnél véletlenszerűen hozzászólásokat :) Szerintem olvass vissza, és minden ilyen kérdésedre megtalálod ott a választ, illetve a PH-n volt még egy népszerű thread erről.

De ha nem akarsz sokat keresgélni, akkor a lényeg kb. az volt, hogy a szabályozás valamint a NAV által kiadott értelmező PDF-ek nem teljesen konzisztensek, ezért mindenki úgy csinálja/csinálta meg, ahogy szerinte helyes, és majd az első NAV ellenőrzések után kiderül, hogy melyik értelmezés volt a nyerő.

Most már egy teljes félév eltelt a bevezetés óta, és ez alatt nem derült ki semmi új, nem büntettek/dicsértek meg emiatt senkit tehát nem lettünk okosabbak :) Emiatt viszonylag minimális az esély arra, hogy ugyanazokra a kérdésekre most bárki is megmondja a tutit :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

De mi itt a kérdés? Ott van a rendeletben az XSD, azt kell implementálni. Most hogy szét kell-e bontani a címet különböző mezőkre, vagy nem, az már részletkérdés. Egyébként a számlázó program adja meg a lehetőséget a szétbontásra, aztán majd a user eldönti, él-e vele.

Az általam korábban használt számlázó szó szerint megvalósította a kért XSD-t, tehát minden kért XML mezőre külön opció van a számlázóban, tehát ha az adott opciókat beállítja a user a számlán, akkor a megfelelő XML mezőbe kerülnek az adatok, pl. a lehetséges záradékokat legördülő listából lehet kiválasztani.

Ha ezt nem tudja már most a számlázó, abból nagy baj lesz később, ha kérik majd az adatokat a megfelelő XML mezőkbe szétbontva.

Tehát akkor még egyszer: igen, volt már, hogy kopogott a NAV és kérte, hogy akkor most adjunk nekik egy XML export kimenetet, mert leellenőrizték. Majd, miután sikerült nekik ezt a bitkupacot prezentálni, azt ellenőrizték valami saját szoftverrel, majd megköszönték és néhány egyéb standard kérdés után távoztak.

Az, hogy tőletek nem kérték, az egy dolog. Tőlünk már kérték. Szóval arra apellálni, hogy "úgysekérik", több, mint balga hozzáállás.

(És nem biztos, hogy jó ajánlólevél ezzel a felelőtlen hozzáállással reklámozni egy ügyviteli rendszert.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( Charybdis | 2016. 07. 04., h – 17:22 )

Az lesz érdekes, hogy a NAV ~6 évre visszamenőleg kérheti a bizonylatokat, akkor gondolom az XML exportot is. De ha ezen ~6 év alatt adott cég használt mondjuk több számlázóprogramot, de a több évvel ezelőtt kiállított számlákhoz már nincs meg a számlázó programja, mert pl. átváltott másikra vagy egyszerűen megszűnt az adott számlázóprogram, viszont elfelejtette lementeni az XML exportot. Ebben az esetben csak kézzel lehet már létrehozni a kért XML-t.

Tanulság: ha számlázóprogramot váltasz, előtte mentsd le a korábbi programmal készült összes számlához tartozó XML-t.

Nem. XML exportot „valós időben” kér, tehát ha már nem használod az adott számlázóprogramot, akkor nem kérheti. (Ezért kell lejelenteni azt is, ha nem használod tovább.)
Elég érdekes lenne pl. egy vállalkozás megszüntetése után megkövetelni, hogy rendelkezz egy számlázóprogrammal, vagy akár számítógéppel.

Ez eddig is ismert volt. A jelenlegi XML export formátumában kell majd feladni http/https-en a számlákat (ha adótartalma 100-200e Ft-ot meghaladja) a kiállítás után adott időn belül. Így "sajnos" nem lehet visszakeltezni számlákat. Nem mintha a kelt számítana egy rendes cégnél.

Eddig is "illett" tv-ből, mosógépből, kocsiból, számlázóprogramból, kalapból minőségi, nem gagyi/tákolt változatot választani. Látom már a decemberben induló gerilla-marketinget az alábbi mondattal "Az Ön programja nem biztos, hogy tud XML-t feladni, váltson xy termékre!" Ettől lesz hangos a könyvelőszakma :)

Azokat sem, mert ezentúl írnak két számlát az egy helyett, amin 50e Ft-t az áfa, és ezzel kezelték is a problémát. Következő az lesz, hogy limitálni fogják a naponta kiadható számlák darabszámát? Egyszerűbb lenne kitenni a határra egy "vállalkozni tilos" táblát, és kész.

Nem a tényleges információkkal van a baj, hanem a túlzott kontroll-lal. Mit szólnál, ha reggel egy rendszerbe kellene tenned, hogy milyen helyekre mész ma és este jelezni, hogy ott voltál-e? Mindezt mondjuk azzal indokolva, hogy a terrorveszély miatt (ne nyissuk ki a politikai csakrát, de ez jutott eszembe) kell az info, védelmi célból. Majd ráépítenek egy járdaadó rendszert, ami alól már nem tudsz kibújni. Ez ellen az emberek hőbörögnek, de "majd hazamennek a tüntetők".
És az élet halad, néha elfelejted bejelenteni a dolgot, de egyik kontroll sem 100%-os. Mindenki hozzászokott...

Három év múlva egy számlatartozást szeretne behajtani rajtad a telko cég. Kicsit ellenállsz, de eléd rakják az aktádat, amiben benne van, hogy "ni-ni itt egy 3 éve volt mozgás eltitkolás", pont mint a Matrix című filmben NEO aktája.

Ha erre jó a maximális kontroll. Mert számomra semmi előnnyel nem jár. Megcsinálják az ÁFA bevallásomat vagy mi?

Sose tudhatod, mikor kell egy nagyobb összegű számlát kiállítani. Meg aztán kitalálják hirtelen, hogy alacsonyabb áfa esetén is küldeni kell.

Amúgy valami olyasmit hallottam, hogy kézi számlákról is kell majd elektronikusan jelentést küldeni. Akkor viszont már tényleg nem fogja megérni a papír számlatömbbel szórakozni. Eddig sem volt ajánlott, mert pl. ha elveszted a számlatömböt, ami ugye megeshet, akkor nagyon vaskos bírságot lehet kapni. PDF számlákat azért nehezebb véglegesen elveszteni.

Tehát szerintem örülhetnek a számlázóprogram fejlesztők, mert jönni fognak új ügyfelek, akik eddig papír számlatömböt használtak.

( zeller | 2017. 06. 29., cs – 15:19 )

Aki a "cím"-et egy mezőbe ömlesztve tárolja, az más galádságokra is képes.