Ellenőrizd a számlázóprogramodat, hogy jogszabálykövető-e!

 ( Charybdis | 2016. június 28., kedd - 16:01 )

Használ itt valaki számlázóprogramot számlák kiállításához? Én eddig vakon megbíztam az általam használt számlázóprogramokban, de most elkezdtem vizsgálgatni, hogy tényleg jogszabálykövetőek-e, és hát találtam pár hiányosságot. Ezért javaslom, hogy aki használ számlázóprogramot magyar cégként / egyéni vállalkozóként, az ne bízzon vakon a fejlesztőkben, tesztelgesse a programot hogy tényleg jogszabálykövető-e.

Mondok pár támpontot, miket kell megnézni.

A legnagyobb szivatás a 2016. január 1-től élő NAV „adóhatósági ellenőrzési adatszolgáltatás”. Lásd 23/2014. (VI. 30.) NGM rendelet 2. melléklet: http://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A1400023.NGM

A számlázó programnak tudnia kell a fenti rendeletben meghatározott szerkezetű XML fájlt előállítania a már kiállított számlák adatai alapján. Ha nem tudja ezt a számlázó maradéktalanul megcsinálni, akkor neked kell megcsinálni kézzel, ha kéri a NAV. Márpedig kérheti.

Namost ha megnézitek az XML fájlt, elég bonyolult, sokféle mező van benne. Az a gond, hogy sok különböző információt kell saját külön mezőbe írni az XML-ben. Pl. ha a számla közvetített szolgáltatást tartalmaz, akkor ezt be kell írni a megfelelő XML mezőbe. Nade ha a számlázó programban nincs külön opció arra (pl. legördülő menü), hogy a számla közetített szolgáltatást tartalmaz, akkor már tudhatod, hogy nem implementálja megfelelően az XML formátumot.

Sok számlázóprogram van általános megjegyzés mező, ahová bármilyen adatot beírhatsz. Igen ám, de hiába írod be ide, hogy a számla közvetített szolgáltatást tartalmaz, így a számlázó program nem fogja tudni ezt az információt a kért külön XML mezőbe beilleszteni.

Ha megnézed a hivatkozott XML-t, akkor látható, hogy a jogszabálykövető számlázókban kell lennie egy csomó külön opciónak, külön mezőnek, legördülő listának, ahol az összes lehetséges opció megtalálható, amit az XML előír. Pl. ott van a sok záradék felsorolva. A számlázó programban kell lennie egy legördülő listának, ahol ki lehet választani bármely záradékot előre definiált listából, így már be tudja tenni a megfelelő XML mezőbe a program ezt az információt. Ha a számlázóprogramod ezt nem tudja, akkor az nem jó.

Ott van a másik XML is, az e-számlába (digitálisan aláírt számlába) ágyazandó XML fájl, aminek megint külön előírt szerkezete van. Ezt is nézd meg, jól csinálja-e a számlázó program: http://www.nav.gov.hu/nav/ado/afa080101_hatalyos/elektronikus_szamla.html (legalul a 3. melléklet)

Adott e-számlából pl. a pdftk parancssoros programmal lehet kinyerni a beágyazott XML-t, alábbi paranccsal:

pdftk mydoc.pdf unpack_files

Na ezek voltak a húzósabb dolgok. Amit még érdemes tudni, az a számla kötelező tartalma elemei, lásd (többek között) 2007. évi CXXVII. törvény az általános forgalmi adóról, 169-172. §.

Nézd meg a listát és azt ellenőrizd, mindet ráteszi-e a számlázóprogram a számlára (vagy te be tudod-e írni ezeket a megfelelő mezőkbe).

Vannak itt finomságok, pl:

A számlán az áthárított adót [169. § k) pontja] - a 80. § szerint meghatározott árfolyam alkalmazásával - forintban kifejezve abban az esetben is fel kell tüntetni, ha az egyéb adatok külföldi pénznemben kifejezettek.

Mondok még egy finomságot: idegen nyelvű számlák. A számla bármilyen élő idegen nyelven kiállítható. Igen ám, de a NAV nem beszél minden nyelven. Pl. angol, német számlát szereti, de ha pl. van egy román nyelvű számlád, akkor van egy kis bújtatott sor egyik törvényben, hogy a NAV kérheti a számla hiteles fordítását, ha olyan kedve van (azaz szakfordítóval kell lefordíttatnod a számlát saját költségeden). Ezért nem árt, ha a számlázóprogram kétnyelvű számlát is tud, tehát ha idegen nyelvű számlát készítesz, akkor még magyarul is ráír minden információt.

Szóval nézzetek kritikus szemmel a számlázóprogramra, ne higgyétek el automatikusan hogy jól működik, főleg mióta bejött ez az adóhatósági adatszolgáltatás XML dolog. Csináljatok egy ilyen próba adóhatósági XML exportot és nézzétek meg, minden benne van-e, mert bármikor kérheti a NAV.

Ha tudtok olyan számlázó programot, ami az összes előírást helyesen implementálja, akkor írjátok meg.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szerintem a billingo.hu tudja.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Leellenőrizted, különösen az XML formátumokat?

Biztos van sok olyan számlázó, amelyik helyesen implementálja ezeket, olyat viszont nem ismerek, amelyik a mostani webes/mobilappos trendeknek is megfelel (nem Windows programokat kell futtatgatni saját gépen), van modern, elérhető API-ja, amin keresztül a funkciói meghívhatók és számlakibocsátások automatizálhatók _és_ nem csak webes szolgáltatásként igényelhető, hanem saját szerveren (on-premise) is futtatható.

Egyébként én ezt használtam korábban: Billzone.eu
Ez tudja ezeket, kivéve a saját szerveres futtatást, ha írsz saját programot ami használja az API-ját, akkor máris saját szerveren vagy.
Ez amúgy úgy láttam, elég jól követi a jogszabályokat is, beleértve az XML formátumokat is.

ha írsz saját programot ami használja az API-ját, akkor máris saját szerveren vagy

attól még továbbra is az ő szervereiken lesznek a számláim és az ügyfélköröm... ezt szeretném elkerülni

Szerintem nincs rá idejük, hogy a számláidat nézegessék.

Egyrészt nem akarnék attól se függeni, hogy van-e rá idejük vagy nincs, másrészt ez egy naív és demagóg érvelés, hisz tudjuk, hogy a Facebook, a Google és az NSA sem úgy működik, hogy egyesével, ráérősen nézegetik az emberek oldalait, kereséseit, postaládáját...

A könyvelőd és a NAV mindenképp látják a számláidat.

Egyel több indok, hogy ne legyen egy harmadik fél is, aki látja és ne függjek a szerverei biztonságától, az infrastruktúrájának megbízhatóságától.

+1

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

-szamlazas/uj partnernel nem tudok szlovenia -t kivalasztani;
- szamlzas/uj termek felvitelenel nem tudok termekcsoportot hozzaadni; mutragya termeket szerettem volna felvinni, hat kenytelen voltam az "ajtok" termekcsoportba rogziteni......
- szamlazas/uj partnernel EU adoszamnak barmilyen hulyeseget elfogad....
- eu adoszamos kulfoldi partnernak rogzitettem egy termeket a szamaln, es kiszamolta a brutto arat - hozzaszamolta a 27% AFA-t... WTF?!?!?! ilyen szar programot meg eletemben nem lattam, ez igy total rossz. az afa kulcsoknal nincs EU mentes afa, igy gondoltam majd lesz olyan "okos", es a torvenyeknek megfeleloen, EU adoszamos, nem magyarorszagi partnernek automatikusan EU MENTES afa-t szamol, ahogy az torvenyileg elo van irva...
- lassu is az egesz.

BIZTOS vagyok benne, hogy a fordított áfá -t sem kezeli jól, ugyanis a törzsadatokban a FORDÍTOTT "kulcs" mindössze annyi, hogy 0%-kal fel van viszve egy ilyen nevű kulcs.
nos, a fordított áfa az NEM 0% ÁFA, hanem fordított áfa - más teljesen az egész, a számlán is vannak plusz kötelező elemek, illetve követelmények, továbbá könyveléstechnikailag sem egyenlő a 0%-os áfakulccsal.
99% biztos vagoyk benne, hogy aaz EU MENTES értékesítésre sem tud szabályos számlát kiállítani, ugyanis a törzsadatok között nem is lehet felvinni ilyet, legfeljebb nulla kulccsal egy EU MENTES áfá -t. ami ugye a fordított áfához hasonlóan szintén nem ilyen egyszerű.

tovabb nem probaltam, egy rakat szar az egész. a használhatósága, s az UI pedig a hígfos kategória.

Szerintem itt kicsit szigorú vagy, az EU adószámokat lehetne ellenőrizni, de elég bonyolult, sokféle eset van. Neked kell ellenőrizned a lekérdező oldalon, hogy érvényes-e egyáltalán az EU-s adószám, ne írj be hülyeséget, ennyi.

Szerintem az áfa kulcs lehet 0% mindig, amikor tényleg nincs áfa. A számla kötelező tartalmi eleme ilyenkor jogszabályra hivatkozás vagy egyéb egyértelmű szöveges leírás, ami megmagyarázza, miért adómentes a számla. Tehát ha az áfa kulcs 0%, és oda van írva, hogy fordított adózás, az teljesen jó.

"az EU adószámokat lehetne ellenőrizni"

Persze, VIES-ből automatizáltan is lehet. 2016-ot írunk....

"de elég bonyolult, sokféle eset van."

Dehogyis. Egyféle eset van. érvénes vagy nem az adott pillanatban.

"Neked kell ellenőrizned a lekérdező oldalon, hogy érvényes-e egyáltalán az EU-s adószám, ne írj be hülyeséget, ennyi."

Nem (csak) a hülyeség beírásán van a hangsúly, hanem az EU adószám érvényességét minden egyes EU MENTES számla kiállításakor le kell kérdezni. Ha nem teszed meg, s közben törölték/felfüggesztették, fizetheted be az ÁFÁ-t és a jogkövetkezményeket. SOHA ne használj olyan számlázóprogramot, ami EU MENTES számla kiállításakor nem ellenőrzi le az adószám érvényességét!!!!

"Szerintem az áfa kulcs lehet 0% mindig, amikor tényleg nincs áfa."

Szerinted. Valójában ez nem ilyen egyszerű.
A fordított áfá -nál nem is szabad azt a számlára írni, hogy 0% áfa, hiszen NEM 0% az ÁFA kulcs, hanem fordított áfás a számla!!! Hatalmas különbség!!! A helyes megjelölés: "FA", "FAD" vagy "fordított áfa", és fel kell tüntetni a jogszabályban előírt szöveget is.
Az áfa részletező részben is "fordított áfa" nem pedig "0%" kell szerepeljen!

"A fordított adózású számla alapkövetelményei:

a vevő adószámának szerepeltetése,
a számlán nem szerepelhet ÁFA-tartalom,
a számlán fel kell tüntetni, hogy a számla a fordított adózás hatálya alá esik és az ÁFA-t a vevőnek kell megfizetnie."

Emellett a fordított áfa esetében mindig kötelező feltüntetni a vevő adószámát, értékhatártól függetlenül, ellenkező esetben nem szabályos a számla, s fizetheted be az ÁFÁ-t. A programnak erre is figyelnie kell.
A fordított áfás számlákat amúgy adóbevalláskor tételesen, listában jelenteni is kell - ez nyílván a könyvelő dolga, de persze nem ártana, ha tudna a fordított áfás számlákról listát készíteni a program.
Ja, és természetesen a programnak ellenőrizni KELL az adószám alapján, hogy a vevő áfakörös-e, hiszen fordított áfás számla csak ilyennek állítható ki!

EU MENTES esetben is vannak finomságok, amire nem elég a "0%" kulcs szerepeltetése, pl. "Csak akkor számlázhat ÁFA felszámítása nélkül EU-s ügyfélnek, ha Ön is és a vevő is rendelkezik érvényes közösségi adószámmal! Ilyen számla esetén a számlán kötelező feltüntetni, az eladó és a vevő közösségi adószámát, az ÁFA értékét forintban átszámolva (akkor is, ha az 0 Ft), illetve az átszámításhoz alkalmazott árfolyamot. Amennyiben a külföldi vevő nem rendelkezik közösségi adószámmal, úgy az ÁFA-t mindenképp fel kell neki számítani, nem mentség az, hogy a vevő EU-s országba tartozik."

Többi felvetésem ezeken kívül is áll, és még át se néztem a programot, csak kettő darab számlát akartam kiálíltani......
Amúgyis, ez a program csak bizonyos, rém egyszerű esetekben tud szabályos számlát kiállítani, bár a számlaképet nem tudtam megnézni, mert a demo nem volt hajlandó megmutatnia nyomtatási képet, hiába kattintottam rá.
Ugye nincs benne példányszámozás?!?!?! ("Számla példányok: 2010.04.01-től a számlát nem kell példányszámozni, 2010.09.27-től pedig nem kell megkülönböztetni a számla eredeti- és másolati példányát. Számláin tehát NE tüntessen fel se példányszámozást, se a számla példányait megkülönböztető feliratokat! FIGYELEM! Az Interneten rengeteg elavult - nem a mai jogszabályok szerint működő - számlázó program lelhető fel még ma is!")

Szerintem nem lenne helyes, ha nem engedne érvénytelen EU-s adószámot beírni. Pl. mi van akkor, ha épp nem elérhető a VIES adatbázis vmi technikai hiba miatt? Max. figyelmeztessen, ha érvénytelen az eu-s adószám, de engedje ráírni.

Nem kell, hogy a számla kiállításakor érvényes legyen az EU-s adószám. Pl. ha érvénytelenítő számlát állítasz ki, akkor lehet, hogy az érvénytelenített számlán a kiállításkor még érvényes volt a vevő EU-s adószáma, de az érvénytelenítő (sztornó) számla kiállításakor már nem az. Tehát mégis csak szabályos, ha érvénytelen EU-s adószám van a számlán.

De mondok más esetet is. Kiállítod a számlát, ráírod a vevő érvényes EU-s adószámát. Elviszed a könyvelőnek a számlákat. Szól a könyvelő, hogy rossz a számla, lemaradt róla valami, sztornózni kell és kiállítani újra, teljesítés dátuma az eredeti számla teljesítési dátuma. Igen ám, de pont mikor újra kiállítod a számlát, már nem érvényes a vevő EU-s adószáma. De mivel a teljesítés az eredeti számla teljesítése, akkor még érvényes volt az EU-s adószám, tehát nyugodtan kiállíthatod ezt a számlát. De a számlázó program nem tudja, hogy a teljesítés dátumán még érvényes volt az EU-s adószám. Megint egy olyan eset, hogy ráírhatsz érvénytelen EU-s adószámot a számlára.

Egyébként úgy tudom, a VIES-ben nincs benne minden EU-s adószám. Ez pl. egy érvényes EU-s adószám: EU826017969. Ez a Hostgator amerikai cég EU-s adószáma, ugyanis nemcsak EU tagországnak lehet ilyen száma. De ezt nem tudod lekérdezni a VIES-ben.

Ha 0% az áfa, az azt jelenti, hogy nem szerepl a számlán áfa-tartalom. A magyarázó szövegnek kell megmagyaráznia, miért 0%, lehet az fordított adózás, export értékesítés, EU-n belül mentes stb.

A számlapéldányokkal pedig én úgy tudom, hogyha rajta van, hogy 1. példány, 2. példány, 3. példány, az teljesen mindegy, ugyanúgy érvényes lesz. Ha nincs rajta a példányszámra utalás, az is érvényes, ha rajta van, az is jó. Ha veszel számlatömböt, ott a mai napig rajta van, hogy 1. példány, 2. példány.

"Ha 0% az áfa, az azt jelenti, hogy nem szerepl a számlán áfa-tartalom. A magyarázó szövegnek kell megmagyaráznia, miért 0%, lehet az fordított adózás, export értékesítés, EU-n belül mentes stb."
Nem.
Pl. a fordított áfa != 0% áfa. Olvasd el amit fentebb írtam.

"Ha veszel számlatömböt, ott a mai napig rajta van, hogy 1. példány, 2. példány."
Az nem gépi számla....

Te adod hozzá az országokat a Törzsadatok alatt.

De ezekről passz, API-n használom, ahol a számlázóprogram készen megkap mindent és kiállítja a számlát.

itt jártam

--
Vortex Rikers NC114-85EKLS

sub

Tényleg nagyon sok buktatója lehet a kimenő számla jogszabályi megfelelőségének de én nem így állnék a dologhoz.
Hiszen felhasználó megveszi a programot fizet azért hogy jogszabályoknak megfelelő működésű terméket használ, és fizet is a követésért (jó esetben)
Ebben az esetben jogosan várhatja el hogy a fejlesztő ad egy nyilatkozatot céges aláírással hogy a termék mindenben megfelel a jogszabályi előírásoknak (persze kisbetűs részben szépen részletezve hogy visszafejtés, adatbázis jogosulatlan hozzáférés esetén mégsem :) ha a ilyen kezében van felhasználónak akkor szerintem nem a felhasználó céget fogják megbüntetni ha valami nem úgy működik ahogy kéne. (de erről okosabbat kéne megkérdeni hogy hogy van...)
Ráadásul külön NAV formanyomtatványon kell bejelenteni már jó ideje a kimenő számlázó program nevét, verziószámát gyártó cég nevét, használat kezdetét végét, szóval nincs itt susmus...

Szerintem nagyon ritka esetben van olyan tudása a kimenő számla felhasználónak hogy minden törvényi előírást ismerjen amit ellenőrizni kellene (ha megvan akkor nem azt fogja ellenőrizgetni, vagy akkor már fizetnek neki érte....)

"Sima" számláknál is annyi speciális eset lehetséges amihez már komoly számviteli/adóügyi tudás kell, külföldi/közösségen belüli/kívüli partnerek, levonható/nem levonható áfa stb stb stb. Számlakép kötelező elemei magyarországon, de EU ban is külön szabályozott...

Elektronikus számlázás az meg külön történet (beágyazott XML-t sima acrobat readerrel is meg lehet nezni)
időbélyeg,fokozott biztonságú tanúsítvány. De pl. van egy olyan hogy a könyvelési kontir tetelt a bizonylattal logikailag osszekapcsolhato modon kell rogziteni. (vagy vlmi hasonlo) Ez regen ugyvolt hogy bizonylatra kell rairni a kontir tetelt, szoval regebben egy TXT fajlba beletoltuk a szamlahoz kapcsolodo konyvelesi tetelt is.

Ha megnezi valaki azt az xml leirast (nem az elektronikusat, hanem az adohatosagi ellenorzesi...) akkor abbol egyertelmu hogy ha olyan szamlazo programot akar irni valaki aki MINDEN esetet lekezel akkor olyan mennyisegu adatot kell pluszban bekerni/specko programot fejleszteni ami a felhasznalok 99%-a nem fog hasznalni.

(külön xml típus van a rezsicsökkentésre ! de a tranzit raktárakra meg minden szarra amit csak speciális területeketn használnak...)

Régebben volt, hogy kellett jogszabály megfelelőségi nyilatkozat, már nem kell ilyen. Már csak dokumentációt kell biztosítani a számlázó fejlesztőjének, a használónak meg be kell jelenteni a NAV felé a használt program adatait.

A program használóját büntetik, ha nem jó a számla, nem lehet behajtani a számlázó fejlesztőjén, ezért kell nagyon körültekintőnek lenni. Pont ezt írtam a bejegyzésben, hogy ne higgy a fejlesztőnek, ellenőrizd, hogy tényleg jók-e a számlák és a funkciók jól működnek-e.

Igen, ahogy írod, elég bonyolult az adóhatósági ellenőrzés XML, de ezt írja elő a rendelet, ennek kell megfelelni. Annak nem tudom mi értelme van, hogy kell külön XML az e-számlába , és van külön adóhatósági ellenőrzés XML is, ráadásul nem pont ugyanazokat kell beleírni.

Igen, jelenleg csak a bonyolult, sok funkciót tartalmazó programot lehetnek jogszabálykövetőek, a bonyolult szabályok miatt.

Ez amúgy tényleg kemény, ezen nekem is megakadt a szemem. A hivatkozott rendeletben ami leírja az XML sémát:


Rezsicsökkentés számlázása: A rezsicsökkentés eredményeként jelentkező megtakarítás összegét jól láthatóan, színes mezőben kiemelve kell feltüntetni a számlán és a rezsicsokkentes XML mezőben.


Tehát nem elég, hogy rá kell írni a számlára, még külön XML mezőt is kapott.

[troll]ráadásul színesnek kell lenni neki az xmlben is [/troll]

"ha a ilyen kezében van felhasználónak akkor szerintem nem a felhasználó céget fogják megbüntetni ha valami nem úgy működik ahogy kéne. "

szerinted.
naívak vagytok.

Ez régebben úgy működött, hogy nyilatkoznia kellett a szoftver készítőjének, hogy az jogszabálykövető, a support meg küldte a frissítéseket jó pénzért.

Már nem kell nyilatkozni, de hiába nyilatkozza, hogy jogszabálykövető, ha valójában nem az. Ezért kell vizsgálnod, hogy tényleg jól működik-e a számlázó.

jövő ilyenkorra már majdnem kiderül,hogy jó e a program vagy sem :)
ha jól emlékszem 2017.06.30-ra tervezik a számlázó programok online bekötését

Számlázz.hu. 30.000 légy nem tévedhet ;-)

szarra mennek? (Bocs, nem hagyhattam ki :D)

Demo verziót néztem. Az ugyanolyan, mint az éles rendszer?

Mert akkor mi van az első felvetésemmel, hogy van ez a bonyolult adóhatósági ellenőrzés XML fájl, amiben van jó sokfajta mező. Ezeket a mezőket hogyan tudja kitölteni helyesen a szamlazz.hu, ha a számlakiállítás felületen nincsenek ezekhez az XML mezőkhöz külön mezők? Pl. beírom a tétel megjegyzésbe vagy számla megjegyzésbe, hogy a számla közvetített szolgáltatást tartalmaz. Ekkor nem fog bekerülni ez az információ a megfelelő XML mezőbe, pedig az adóhatósági ellenőrzés XML séma elvárja, hogyha a számla közvetített szolgáltatást tartalmaz, akkor ez az információ kerüljön be külön kijelölt XML mezőbe.

Ill. én magyar, angol, német, francia nyelveken kívül egyéb nyelveken nem mernék kiállítani így számlát, mert egynyelvű számla keletkezik, magyarul nincsenek rajta az információk, pedig:

Az az általános forgalmi adóról szóló 2007. évi CXXVII.
törvény 178. § (2)-(3) bekezdése:

"(2) Számla magyar nyelven vagy élő idegen nyelven egyaránt
kiállítható. E rendelkezés alkalmazásától az (1) bekezdésben
említett esetben sem lehet eltérni.
(3) Idegen nyelven kiállított számla esetében az adóigazgatási
eljárás keretében lefolytatott ellenőrzés során a számla
kibocsátójától megkövetelhető, hogy saját költségére
gondoskodjon a hiteles magyar nyelvű fordításról, feltéve, hogy a
tényállás tisztázása másként nem lehetséges."

Ehhez jön még az adózás rendjéről szóló 2003. évi XCII.
törvény 95. § (2) bekezdés:

"Amennyiben az ellenőrzés lefolytatásához szükséges számla
(egyszerűsített számla), illetőleg bizonylat, továbbá a
számlában (egyszerűsített számlában) vagy bizonylaton szereplő
gazdasági eseményt alátámasztó szerződés vagy más dokumentum
idegen nyelven - ide nem értve az angol, német és francia nyelvű
iratokat - áll rendelkezésre, és az adójogi tényállás
tisztázása másként nem lehetséges, az adózó köteles
felhívásra annak a számla (egyszerűsített számla), illetve
bizonylat hiteles magyar nyelvű fordítását, a számlában vagy
bizonylaton szereplő gazdasági eseményt alátámasztó szerződés
vagy más dokumentum szakfordítását az adóhatóság részére
átadni."

Még valami eszembe jutott. Az angol nyelvű számlán ilyen formátumban van a dátum:

01/07/2016

Ez azért nem teljesen jó így, mert egyes angol nyelvű országokban nap-hónap-év a dátumformátum, de más angol nyelvű országokban viszont hónap-nap-év. Nálunk meg év-hónap-nap.

Ugyanaz a baj ezzel, mint az élelmiszerek lejárati dátumánál, hogy nem egyértelmű, nem véletlenül hozott erre az EU egy szabályt, hogy egységes formátumban kell kiírni a lejárati dátumot.

Ha nem egyértelmű a dátum, akkor félreértheti a vevő, könyvelő, NAV, egy sor bonyodalom származhat belőle.

01/07/2016 lehet 2016. július 1, vagy 2016. január 7., ugye egyáltalán nem mindegy. E-számla időpecsétje sem mindig tudja eldönteni a kérdést, pl. ha a kiállítás dátuma 01/01/2016, az időbélyeg szerint 2016. január 1-jén lett kiállítva a számla, ezzel nem lettünk okosabbak, hogy melyik nap és hónap, mert ezek utána ha a teljesítés és fizetési határidő 12/01/2016, akkor az már megint lehet 2016. január 12, vagy 2016. december 1. Ha nincs egyéb más számla, amiből lehetne következtetni a dátumformátumra (pl. angol nyelvű számlából adott időszakban pont olyan számlák vannak, ahol pont mindig kétértelmű a dátum), akkor sehogyan sem lehet megtudni a számla valódi dátumait.

Így lenne jó a dátum: 2016. Jul 1. (pl.)

disclaimer: baromira nem értek hozzá... de szerintem az van, hogy ha te úgyse akarsz olyan számlát kibocsáltani, ami mondjuk "közvetített szolgáltatást tartalmaz", akkor nincs azzal baj, hogy ezek ezt nem tudják kezelni. És gyanús, hogy van egy csomó olyan cucc, amit az ilyesmik célközönsége nem nagyon használna (mert pl mittomén villanyszerelő, odamegy, megcsinálja, kb munkadíjat meg esetleg anyagot fog továbbszámlázni). Ettől az eredeti felvetés, hogy nézd meg, mit tud jogos, csak nem vagyok benne biztos, hogy ha valami nem tudja az összes ilyen szart, akkor már egyáltalán nem jó.

Hát talán annyiban baj van, hogy nem tüntetik fel nagybetűkkel (még kicsivel sem láttam) mikor előfizetsz, hogy ez nem teljes értékű számlázó...

Nagy Péter
www.ddo.hu