NAV online számla adatszolgáltatás - 2018

Voltam nemrég egy rendezvényen, ahol többek között szó volt az új online számla adatszolgáltatásról is.
Ott említették, hogy lesz a NAV-nak a korábban sokat hiányolt publikus teszt szolgáltatása, azaz a fejlesztők ki tudják próbálni és véleményeztethetik a kommunikációban beküldendő adatokat mielőtt élesben elindulna a rendszer.

Még néhány érdekes dolog/terv:
-megszűnik a számlázó programok bejelentési kötelezettsége
-a formátum természetesen változik a korábbi XML-hez képest :)
-mindenféleképpen utólagos lesz az adatszolgáltatás (tehát nincs tervben a pl. Csehországban működő valós idejű adatszolgáltatás)
-a tételes adatszolgáltatásnál a jelenlegi 100e Ft-os értékhatárt a jövőben csökkenteni akarják, később akár 0-ra is
-csak az adóalanyoknak kiállított számlákat érinti (azaz magánszemélyeknek kiállított számlákat nem)
-a kommunikáció "nem a publikus interneten fog történni" ??? (na ennek az értelmezésére kíváncsi leszek).

A határidők:
2017. július 1. a szabályozás kihirdetése
2018. január 1. a teszt üzem kezdete. A teszt üzem nem váltja ki a tételes adatszolgáltatást
2018. július 1. az online adatszolgáltatási rendszer éles indulásának napja.

Update:
https://www.nav.gov.hu/nav/gyik/onlineszamla

Update 2018.01.18:
Megjelent az interface specifikáció:
https://www.nav.gov.hu/nav/onlineszamla/technikaiinformaciok

Update 2018.02.01:
Megjelent a technikai vonatkozású kérdés-válasz gyűjtemény:
https://onlineszamla-test.nav.gov.hu/technikai_kerdesek_valaszok

Update 2018.06.18:
Elindult az éles rendszerbe történő regisztráció:
https://onlineszamla.nav.gov.hu

Update 2018.07.01 00:01:
Tényleg elindult az éles rendszer

Hozzászólások

Annak lenne értelme, hogy a számlázás folyamata a NAV szerverén történjen.
Fellépsz a szerverre, kapsz egy űrlapot, kitöltöd, és az eladói-vevői adószámok
alapján lekönyveli. Akinek kell kérjen róla egy kinyomtatott papírt.

Tehát pont fordítva kéne: a NAV szolgáltatna adatot a cég könyvelési rendszerének.
Hosszú távon az egész könyvelést föl lehetne tenni a NAV-hoz.

> Sol omnibus lucet.

Ezzel nem teljesen értek egyet, hiszen ahány cég, annyi rendszer - akár személyre szabva.

Viszont a számlán szereplő adatok "exportálhatók" XML (vagy egyéb) formátumban, amit tud fogadni és feldolgozni a NAV (esetleg a banki rendszer és a könyvelési rendszer is).

A számla kiállításakor automatikusan elküldi a NAV-nak az XML-t. Az tudja ellenőrözni, hogy megtörtént-e az áfa befizetés, visszaigénylés.
A könyvelési rendszer simán lekönyvelné, mind vevői mind szállítói oldalon. Gombnyomásra kerülne fizetésre bankon keresztül, és még egyszerűbb volna - manuális beavatkozás nélkül - ellenőrizni a bank jelentésből, hogy adott vevő adott összeget (esetleg adott egyedi azonosítóval) befizette-e.

Ezzel kb lehetetlenné volna téve az áfacsalás - valamint az adórevízió is egyszerűbb volna...

+1 (meditor-nak) Szerintem is: "Annak lenne értelme, hogy a számlázás folyamata a NAV szerverén történjen.
Fellépsz a szerverre, kapsz egy űrlapot, kitöltöd, és az eladói-vevői adószámok
alapján lekönyveli. Akinek kell kérjen róla egy kinyomtatott papírt."
Azzal egészítem ki, hogy VAGY KINYOMTATHATJA MAGÁNAK, továbbá, hogy nekem ne kelljen nyomtatni, ha nem akarom.
Ha viszont kinyomtatom, azt fogadják el úgy, mint ha az hagyományos számlatömb tőpéldánya lenne.
Egy cégen belül, más számlázási módokkal vegyesen lehessen alkalmazni.
Úgy gondolom, hogy nagyon sokan használnák ezt a lehetőséget. Pl. olyanok, akik számláik egy részét kiállítják és postázzák az ügyfélnek.

Egy másik topikban linkelték a következőt:
http://www.kormany.hu/download/2/1a/11000/szamla.zip#!DocumentBrowse

Idézet a kormany.hu-ról (nem, direktlinkelni nem lehet...):

Nemzetgazdasági Minisztérium, 2017. június 27.
Tervezet 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

A tervezet 2017. június 30. 14.00 óráig véleményezhető az
ffaf kukac ngm.gov.hu ; zoltan.varga2 kukac ngm.gov.hu; krisztina.magony kukac ngm.gov.hu; elektronikus elérhetőségeken.

A zipben lévő PDF fájlokból az egyikbe van egy hibás XSD behányva, amit elkértem tőlük a fenti címeken, bár ki tudja mennyire kompetensek az ügyben. (Az érintettek esetleg követhetnék ezt, hátha megérzik a helyzet súlyát.)

-a kommunikáció "nem a publikus interneten fog történni" ??? (na ennek az értelmezésére kíváncsi leszek).

Remélem nem azt akarják bevezetni, mint az online pénztárgépeknél, hogy csak a haver cégétől vett mobilinterneten keresztül működik.

-a kommunikáció "nem a publikus interneten fog történni
http://www.portfolio.hu/gazdasag/adozas/jon_a_nav-testver_megjelent_az_…
lap alja, mennyibe kerül:
"A rendszer üzemeltetését havi 3000 forintra tette a minisztérium."

Gondolom nem a szoftver bérleti díját akarták meghatározni, inkább a mobilnet lehet ez.

Az ügyfeleinknél levő szervereinkbe még csak-csak bele lehetne tenni valami 3G modemet, de mondjuk a hostingon levő gépek, vagy főleg a VPS-ben futó rendszereink esetén nem tartom egyszerűen kivitelezhetőnek a mobilnet használatát. De egyébként a mobilnetre rákérdeztünk, és tagadták. Azt mondták, hogy nem olyan rendszer lesz, mint az online pénztárgépek esetén, hanem "ésszerű időn belül" és utólag kell beküldeni az adatokat. Ebbe akár még az is beleférhet, hogy mondjuk naponta egy-két alkalommal, batchben küldjük be az adatokat...

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

Ez a 3K HUF nem tudom honnan jött, de a hatástanulmányban a következő szerepel:

II. Adminisztratív terhek:
A rendszer az automatizmusa miatt az egyszeri beruházási költségeken túl nem eredményez
adminisztratív tehernövekedést a vállalkozásnak, sőt csökkenti azt, mivel kiváltja az utólagos
számla szintű adatszolgáltatást. A rendszer bevezetésének további előnye, hogy a számlát
befogadó vállalkozás is gyakorlatilag valós időben értesülni tud a számára kiállított számla
tényéről és tartalmáról, megkönnyítve és meggyorsítva ezzel a bejövő számlákkal kapcsolatos
ügyintézést.

III. Egyéb hatások:
Egyszeri fejlesztési költség a vállalkozások számára.

A kettes pontban nálam azért a bevillannak képek a http://a.te.ervelesi.hibad.hu oldalról.

Ez ellentmond ennek:

Számlázó programmal történő számlázás esetén a számlaadatokat a számlázó programból emberi beavatkozás nélkül, nyilvános interneten keresztül azonnal, a számla elkészülése után rögtön továbbítani kell a NAV-hoz.

- https://www.nav.gov.hu/nav/onlineszamla

A tervezet 2017. június 30. 14.00 óráig véleményezhető
Vicces, hogy ők nem tettek semmit sem az asztalra az elmúlt 2 évben most meg idehánynak 110 oldal sémát pdf-ben és véleményezni lehet holnap 14 óráig.
Ha valahol találnátok valid xsd-t osszátok már meg. Nekem nem sikerült összehozni.

Én írtam a három címre ahol véleményezni lehet, hogy A) hibás ami a PDF-ben van, B) küldjék már el egy fájlban.

Ami még véleményezéssel kapcsolatban eszembe jutott az a következő:

13/B. § (1) Ha a számlázó program által előállított számla, számlával egy tekintet alá eső
okirat adatait fogadó elektronikus rendszerben üzemzavar történik, az állami adó- és
vámhatóság az üzemzavarról és az üzemzavar elhárítását követően annak kezdő és
megszűnési időpontjáról haladéktalanul közleményt tesz közzé honlapján.

Jó lenne ha ezeket a közleményeket el lehetne érni valamilyen struktúrált RSS? formátumban, hogy a számlázószoftverek automatikusan tudják a felhasználók felé reportolni az esetleges szerveroldali downtime-okat.

Én csak annyit írtam nekik, hogy plz valid séma, és hogy meglepődtem, hogy nem a 23/2014 xsd sémáját használják az adattartalomra. (ennek semmi köze hozzá)
Egy válasz már jött:
"Házon kívül vagyok július 3-ig. I'm out of office until 3rd of July."
Még jó, hogy holnap 2-ig ráérünk véleményezni. Addig simán átfutjuk az xsd -t és minden felmerülő problémát megtalálunk.

"Az adatszolgáltatás adózói regisztrációt követően kezdhető meg, amely magában foglalja az adatszolgáltató végpont és számlázó program regisztrálását is."

Mit takar ez a végpont regisztráció?

Mikor szakadunk már el ezektől az ocsmány XML-ektől? Kinek jó ez? Mintha elvárás lenne egyesektől, hogy minél nagyobb és ocsmányabb interfészeket okádjanak ki magukból. Annál komolyabbnak tűnik a munka a gondolom. Kéne tenni néha hátra két lépést és átgondolni, fejlettebb nyugaton vajon milyen _JSON_ struktúra írna le egy kurva számlát.

Nem akarom teleszemetelni a hozzászólást kóddal, de nagyon kemény dolgokat találtam 5 perc alatt ebben az XSD-ben, még jó, hogy bőven van idő véleményezni.

"Az adatszolgáltatás adózói regisztrációt követően kezdhető meg, amely magában foglalja az adatszolgáltató végpont és számlázó program regisztrálását is."

Mit takar ez a végpont regisztráció?

Ügyfélkapus regisztrációról volt szó.
Azt nem sikerült kideríteni, hogy az "adatszolgáltató végpont" alatt mi értendő, de megválaszolatlan kérdésként még IP címtől kezdve sok más elvetemült gondolat is felmerült...

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

Telkó cégeknél lesz ez érdekes, mert ugye évente Hunguardos audit, kívülről senki sem férhet hozzá a számlázórendszerhez.

Mintha valami olyat is mondtak volna, hogy a közmű cégekre nem fog vonatkozni az adatszolgáltatási kötelezettség.
Mondjuk érthető is, mert a fogadó oldal biztos csuklana egyet, amikor bekopogtat azzal a közmű szolgáltató számlázórendszere, hogy "éppen most csináltam másfél millió darab számlát, hegyezd a ceruzád, diktálom az adatait..." :D

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

Nem exportról van szó, hanem online hozzáféréshez. Sőt ha jól rémlik a gépen nem lehet semmi más szoftver, csak a számlázó program és nulla internethozzáférés, csak intranet. DB szerveren ugyanez és MSSQL management studio, vagy egyéb db módosítására alkalmas cucc sem.
De ha érdekel, el tudom küldeni a komplett dokumentációt, hogy miknek kell megfelelnie a rendszernek. Elég durva anyag.

Nem kell mindegyikre víruskergető...
:D
Természetesen nem csak M$ alapú számlázók léteznek...
Akinek a számlái linux alapú komplett VIR-ből jönnek, ott a számlázó részt nem lehet különvágni, és a Zinternet nélkül nem is lehet használni a rendszert. Pl. a napi árfolyamokat betölteni, ekáer -t online intézni!

És fejlesztői eszközök nélkül különböző lock-olásokat feloldani, DB műveleteket sem lehet a mi rendszerünkkel megtenni.

Pl. egy SLES linux esetében mi számít plusz szoftvernek?
A pbzip/lbzip / apache, tomcat, stb. is?

Vagy lesz valami egységes, új kötelező érvényű számlázó program, amit mindenkinek meg kell majd venni és használni akár két helyen történő adatrögzítéssel, raktárkészlet,stb könyveléssel?

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

És vajon ha egy cégnél fut 5 különböző számlázási rendszer 5 IP címről, akkor vajon hány accountot kell regisztrálnia az adott cégnek, hogy a 3 IP címbe beleférjen? :) És mi van akkor, ha ezek egy része dinamikus IP-s? fizetnem kell azért (is), hogy fix IP-m legyen? És ha én mobilnetet szeretnék használni az adott helyen ahol a számlázás fut? Megannyi kérdés... :)

Van már olyan akinek jóváhagyták a regisztrációját?

Szerintem 17, elcsodálkoztam rajta, hogy ilyen elől vagyok.
Igen.
Másrészről viszont az is feltöltés, hogy kitallózod az xml -t és feltöltöd, elvileg megmondja, hogy jó-e. Lehet, hogy csak összeveti az xsd-vel. Ez elvileg működik, de nem próbáltam. A tesztüzem sztem csak jan.1 -el indul. Valahol mintha ezt írták volna korábban.

Ma megújult a https://onlineszamla.nav.gov.hu portál.

Ami talán a legnagyobb változás, hogy már nem csak fix IP címmel lehet regisztrálni (bár igaz, használni továbbra is csak fix IP címmel lehet)

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

emiatt:

[meta http-equiv="refresh" content=";url=index.jsf" /]

az pedig:

$ curl -vi "https://onlineszamla.nav.gov.hu/KobakReg/faces/index.jsf"
* Trying 84.206.29.171...
* Connected to onlineszamla.nav.gov.hu (84.206.29.171) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 697 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: *.nav.gov.hu (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=HU,L=Budapest,O=Nemzeti Adó- és Vámhivatal,2.5.4.97=#0c1356415448552d31353738393933342d322d3531,CN=*.nav.gov.hu,serialNumber=1.3.6.1.4.1.21528.2.3.2.950
* start date: Mon, 05 Dec 2016 10:43:35 GMT
* expire date: Wed, 05 Dec 2018 10:43:35 GMT
* issuer: C=HU,L=Budapest,O=Microsec Ltd.,CN=e-Szigno SSL CA 2014,EMAIL=info@e-szigno.hu
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /KobakReg/faces/index.jsf HTTP/1.1
> Host: onlineszamla.nav.gov.hu
> User-Agent: curl/7.47.0
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 400 Bad Request
HTTP/1.0 400 Bad Request
< Connection: Close
Connection: Close
< Set-Cookie: BIGipServerONLINESZAMLA=1644565164.9224.0000; path=/
Set-Cookie: BIGipServerONLINESZAMLA=1644565164.9224.0000; path=/

<
400 Bad Request400 Bad RequestAn HTTP protocol violation was detected and your request was denied.SessionID: 1PfjnL03::02
Date: 2017-08-30 17:40:05
* GnuTLS recv error (-110): The TLS connection was non-properly terminated.
* Closing connection 0
curl: (56) GnuTLS recv error (-110): The TLS connection was non-properly terminated.

t

Helló! A teszt szerverrel nekem minden jól ment. Ma élesítettem volna néhány szoftvert, és ugyan ezt a protocol violation hibát kapom. Nektek végül milyen megoldást sikerült rá találni? Elég sürgős lenne, ha ma nem sikerült adatokat beküldeni, levágják a fejem. :-(

basszus... a franc gondol erre. totál összezavarja az embert, hogy a teszt környezetben ugyanez hiba nélkül átmegy. viszont ettől nálunk csak annyi változott, hogy HTTP 400 helyett mostmár 500 a visszaadott hibakód, tök ugyanazzal a hibaüzenettel. :/

a keepalive ki volt kapcsolva (ez a default).

a nav faq ezt írja erről:

Ezt az üzenetet a szerver előtt lévő hálózatvédelmi eszköz adja vissza akkor, ha a HTTP kérés nem engedélyezett endpointra érkezett. (pl. a POST után hibás vagy hiányzik az URL) Ellenőrizni kell a kimenő HTTP üzenetet!

ezt vajon úgy kell értelmezni, hogy a HTTP protokoll szabványt megerőszakolva a POST parancs után a teljes, vagyis az abszolút url-nek kéne lennie a relatív helyett? sajnos a curl-t sehogy nem tudom rávenni erre. viszont ha mondjuk van valami proxy vagy load balancer az éles rendszer előtt (ahogy utalnak is ilyesmire), ami a tesztnél nincs, az magyarázat lehet az eltérésre.

Tegnap jött az értesítés, hogy október 15-től nem kell fix IP cím a belépéshez, mert átállnak 2FA-ra, név+jelszó után emailben fog jönni egy OTP...

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

Én meg azt hittem máshogy kellene értelmezni, mint ahogy benne van. (elírtad a kérdést)

Egyszer át futottam mikor kijött és voltak benne furcsa dolgok az biztos.
Az adatszolg xml t- azt megcsináltam időben, mert láttam, hogy nagy munka lesz a címek bontása miatt. Erre a határidő előtt 3 héttel az utolsó decemberi munkahetemen kiadtak egy iránymutatást ami pont az ellenkezője volt az előzőnek a címek tekintetében. Ebből tanultam. Majd ha lesz időm, akkor foglalkozok vele egyébként meg várom a fejleményeket.

Ma jött egy frissített verzió, XSD_V14.2f.xsd néven, ami már jobban dokumentált, de októberre ígérnek még részletesebb útmutatót is. Ha regisztrálva vagy, akkor elméletileg te is megkaptad...

Ez a folyamat most lényegesen gördülékenyebbnek tűnik, mint az előző adatszolgáltatásos volt :)

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

Voltam tegnap egy előadáson a témával kapcsolatban, amelyen a NAV-ot Czöndör Szabolcs képviselte és elhangzott pár infó, ami mások számára is érdekes lehet:
- November közepe felé várható a véglegesített XSD séma, amelyet ezután nem sokkal angol nyelvre is lefordítanak majd.
- jogszabályi változás lesz a beküldéssel időpontjával kapcsolatban, mert sokan félreértelmezik a 24 órás határt. Az az elképzelés,hogy a számla kiállítást követően automatikusan beküldésre kerüljön az xml, nem pedig tömbösített formában, nap végén pl, ami még benne van a 24 órában.
- hamarosan (a végleges XSD-vel nagyjából egyidőben) elindul az OSZI (online számla interfész)
- még nincs végleges ötlet,hogy mi alapján fog történni a hitelesítés, több elképzelés is van
- a kommunikációt és infrastrúktát az EKAER rendszerhez hasonlóan képzelik el, de még mindkettő csak elméleti szinten van meg
- szintén november közepén-végén jön ki egy jogszabály tervezet, amelyet az még EU-nak jó kell hagynia (~4 hónap). Azaz végleges, hitelesített XSD és jogszabály csak április körül várható
- a tavaly bevezett xml adatexport záros határidőn belül meg fog szűnni
- az online számla adatszolgáltatás bevezetése után nem sokkal terveznek kiadni egy NAV által fejlesztett, mindenki számára ingyenes elérhető, web-es számlázó szolgáltatást.

Egyébként még rengeteg nyitott kérdés van.

szerk: még annyi, hogy 3 féle response lesz. OK, amikor minden rendben. WARN, ha struktúra ok,az xml-t befogadták, de az xml tartalmában van valami nem megfelelő. És ERROR, amikor az xml hibás és nem került befogadásra.

> az online számla adatszolgáltatás bevezetése után nem sokkal terveznek kiadni egy NAV által fejlesztett, mindenki számára ingyenes elérhető, web-es számlázó szolgáltatást.

Nem fordított sorrendben lett volna logikus ?

Először a számlázó összes funkcióval, majd online adatszolgáltatás.

Most is vannak webes számlázók ingyenes csomagokkal. Sokaknak megfelelnek ezek is, de milyen lesz a NAV -os funkcionalitása, lesz hozzá API is ?
Minek böngésszem a 180 oldalas xsd-t ha nem tudom lesz- e rá igény ?

Logika? Azt inkább ne keress benne. Minek kellett egyáltalán annyira sürgősen az adatexport,ha amúgy is megszüntetik? Ráadásul nyíltan beismerte, hogy az adatexport egy átgondolatlan döntés volt, amit olyanok hoztak, akiknek közük nincs az informatikához...

Az online számlázó célja a papír alapú számlázás kiváltása lenne, nem pedig a számlázó rendszerek leváltása, legalábbis ez volt az indok tegnap, ennyit tudok.

"- a tavaly bevezett xml adatexport záros határidőn belül meg fog szűnni"

Három hete még azt mondták, hogy nem szűnik meg, hiszen rengeteg számlát nem fog lefedni az Online adatszolgáltatás (még akkor sem, ha 0-ra leviszik az ÁFA tartalom határát, hiszen csak belföldi adóalanyokról szól az egész, EU, harmadik országbeli értékesítésről pl. nem...)

Nálunk volt a NAV ÁFA revízión (visszaigényléskor ez bevett szokásuk) és azt mondták, hogy egy konkrét időszakról e-mailben küldjünk nekik adatszolgáltatást próbaképpen.
Aztán válaszoltak, hogy milyen módosításokat kell az adatszolgáltató szoftveren elvégezni, hogy megfelelő formátumú legyen az xml. Mi azt továbbítottuk a fejlesztőnek.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

nálunk meg most a héten voltak,úgy látszik rajta vannak nagyon a témán. 2016 előtti adatokat csv, vagy xls formában kérik, csak számla fejadatok, meghatározott hónap összes számlája. azt akarják látni,hogy a számlázóprogram folyamatos számlasorszámozást használ. 2017 egy hónapjáról pedig xml adatexportot kértek. kicsit kacifántos,mivel nálunk van saját fejlesztésű számlázó és külső cég számlázója is, ráadásul a külsős számlázó pont 2016-ban lett lecserélve, így az egyik programból csak sima fejadatokat kérnek, a másikból pedig csak xml exportot. mindezt CD/DVD-n bejuttatva a központjukba. ja és az összes program teljes dokumentációját persze :)

jó kérdés, nem tudom, ezt nem kötötték az orrunkra. ha csak az lett volna a cél,akkor gondolom a többi számlázóból nem kértek volna be adatot.
szeretnek ide jönni, van itt minden: ekáer, vámkezelés, stb... :) ha jól rémlik, idén ez volt a 3. alkalom,hogy jöttek ellenőrizni. legutóbb pl csak xml exportot kértek.

Valóban jön az adatszolgáltatási kötelezettség: https://www.billzone.eu/blog/2017/10/02/mit-akar-a-nav-online-szamla-e-…

De úgy tudom, papír alapú kézi számlatömb esetében is. Ezzel akkor vége a papír alapú kézzel írt számláknak, eddig is túl nagy macera volt, mostmár méginkább az lesz. Ill. nagyon figyelni kell, hogy az adott számlázó tényleg jól továbbítja-e az adatokat, mostmár olyan komplexek a számlázási szabályok, hogy ezeknek csak a komoly, folyamatosan fejlesztett számlázóprogramok felelnek meg.

Nem szabad elhinni adott számlázó marketing szövegének, hogy az tényleg jogszabálykövető, érdemes tisztában lenni az alapvető követelményekkel és tesztelni az adott számlázót, hogy tényleg tud-e mindent.

A főbb dolgok, amit nézni kell:
-tudja-e az elvárt XML formátumot a NAV adóhatósági ellenőrzési adatszolgáltatáshoz?
-2018. júliustól helyes formátumban továbbítja-e az adatokat a NAV-nak?
-számla kötelező tartalmi elemeit ismerni kell és meg kell nézni, tudja-e ezeket a számlázó
-ha nincs havi szinten folyamatosan frissítve az adott számlázó, akkor én elfelejteném

Nem biztos, hogy pont minden hónapban kéne, hogy frissüljön a szoftver, az a lényeg, hogy rendszeresen frissítsék. Nem használnék olyan programot, amihez fél éve hozzá se nyúltak. Szóval legyen valami changelog, ami bizonyítja, hogy frissen tartják a programot, ennyit akartam írni.

mert fél-egy évente változnak a szabályok, amit le kell követni, de közben még ugye folyamatosan bugokat is illik javítani, új funkciókat bevezetni. ha rendszeresen frissülő changelog van, az jó jel. Valami baj van a billentyűzeteddel? olyan fura karakterek jöttek ki belőle.

Mindig rendszeresen előjössz a bizone-val, ráadásul olyan módon, hogy simán perelhetne téged bármelyik online számlázó :
Olvasd már ezeket vissza és gondold át, hogy mit csinálsz valójában.

  • Ahogy körbenéztem, csak (!) a Billzone.eu online számlázó implementálta maradéktalanul a rendeletet.
  • A Billzone a legprofibb, mindig ha kijön egy jogszabályváltozás, akkor a blogjukon máris kiírják hogy verziófrissítés, és még a jogszabály hatályba lépése előtt már látod a blogjukon, hogy ilyen és ilyen jogbszabályváltozás miatt mától ez és ez változik a számlázásban, és mire életbe lép a jogszabály, már tudja a program a kért dolgokat.
  • A Billzone kifinomultsága legjobban idegen nyelvű, devizás számla kiállításakor látszik meg.
  • Billzone-nál ez úgy néz ki, hogy kétnyelvű számlákat gyárt ha idegen nyelvű számlát kérsz, tehát a hiteles fordítás ott van a számlán már eleve, ez pipa.
  • Csak a Billzone-t javasolnám online számlázók közül, ez az új NAV XML rendelet elvéreztette a többi programot és csak a Billzone maradt állva.
  • Namost ha ez így lesz, akkor egyszerűen hibás vagy hiányos adatokat fog szolgáltatni az a program, ami nem implementálta megfelelően az XML-t, ami egyébként nem olyan nehéz, hiszen a Billzone meg tudta csinálni még 2015 végén.

forrás: https://hup.hu/node/145068?comments_per_page=9999

Akkor segíts kicsit kérlek:

a https://api-test.onlineszamla.nav.gov.hu/invoiceService/tokenExchange
és a https://api.onlineszamla.nav.gov.hu/invoiceService/tokenExchange

különböző error msg-t küld vissza, holott gondolom ugyanazt kéne.
Ráadásul egyik sincs a dokumentációban...

Nyilván tőlem várna el másfajta paramétereket, mint amit a curlnak megadtam, de sok segítséget nem ad a rendszer...

Most ez azt jelenti hogy ha beküldöm a számla tartalmát az interfészen a NAV-nak, akkor onnan a vevő hitelesen le is töltheti? (Ez így túl logikus lenne, nomeg egy csomó számlaarchiváló szolgáltató kenyerét is elvenné). Csak úgy kérdem, mert ha azt jelentené, akkor megoldódna az elektronikus számlázás egy csomó rejtélye, ami ma egy kisvállalkozást esetleg elriaszt az ilyesmitől.

Valamelyik tájékoztatón mondták, hogy a jelenlegi 100.000 Ft-os ÁFA tartalmi limit folyamatosan csökkentésre kerül (valószínűleg több lépcsőben), és a hosszú távú cél az összes számla adatainak megszerzése. Ezért önkéntes alapon elméletileg már az induláskor is lesz lehetőség nem csak a 100e Ft-ÁFA tartalmat meghaladó számlák adatainak beküldésére. Viszont jelenleg is sok kivétel van: pl. csak a belföldi adóalany számára kiállított számlákat kell szerepeltetni, közmű szolgáltatóknak nem kell beküldeni, stb. Gyakorlatban még nem sikerült kipróbálni, hogy az interface mit szól a külföldi vevőnek kiállított számlához, a pár ezer Ft végösszegű számlához, a fordított áfás számlához, a közösségen belüli értékesítés keretében áthárított adó nélkül kiállított számlához, stb.

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

Nem kéne "megszerezni" a számlák adatait, ha a NAV szolgáltatóként kezelné a dolgot. Tök más kérdés, hogy milyen ellenőrzésre ad lehetőséget egy ilyen rendszer, ha egyszerűen egy központi számlatárat csinálna a NAV, szerintem lennénk páran, akik simán és örömmel térnénk át az elektronikus számlázásra. Rengeteg pénzt meg lehetne spórolni vele. Ehelyett a NAV kergetőzik az adófizetővel, az adófizető meg tehernek érzi az egészet.

Vannak akik (velem együtt) szintén egyedül illetve arra alkalmas (munka)társ híján egyedül csinálják meg az illesztést?
Lehet jó ötlet lenne ríl is kommunikálni.

$url_invoice="https://api-test.onlineszamla.nav.gov.hu/invoiceService/manageInvoice";
$invoice_ch = curl_init($url_invoice);
curl_setopt($invoice_ch, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($invoice_ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($invoice_ch, CURLOPT_POST, 1);
curl_setopt($invoice_ch, CURLOPT_HTTPHEADER, array('Content-Type: text/xml'));
curl_setopt($invoice_ch, CURLOPT_POSTFIELDS, "$xml_data_invoice");
curl_setopt($invoice_ch, CURLOPT_RETURNTRANSFER, 1);
$output_inv = curl_exec($invoice_ch);
curl_close($invoice_ch);

pch
--
SB-soft online ügyviteli rendszer
--

Nagyjabol vegig futottam a topicot es a NAV oldalat is, de nem talaltam semmi informaciot arra nezve, hogy mi van akkor ha a szamlazo program standalon gepen fut?
Nalunk a szamlazo gep nincs kiengedve a netre es ha nem muszaj nem is szeretnek ezen valtoztatni.
--
vati

A másik gépről való beküldés biztosan nem lesz NAV kompatibilis. Legalábbis eddig azt kommunikálták, hogy emberi beavatkozás nélkül, valós időben és teljesen automatikusan kell megtörténnie. Valamint arra is nemet mondtak, amikor azt kérdeztük meg, hogy lehet-e külső program, ami időnként ezt megcsinálja (aka crontab, és mondjuk óránként elküldi az abban az órában kiállított számlákat).

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

Ez érdekes, mert nekünk meg azt mondták, hogy be lehet küldeni külső program segítségével. (ráadásul pár nagyobb cég már rá is állt ilyen szoftverek készítésére, pl az EY)
És azt is mondták,hogy nem probléma, ha nem másodpercre pontosan történik a beküldés akkor, mikor a számlát kiállították.

Átböngésztem az XML specifikációt. Jól értem, hogy a számláról kötelező elemként meg kell adni:
-az eladó adatait: nevét, adószámát és címét. (azt most hagyjuk, hogy a regisztrációnál is ugyanezeket kellett megadni...)
-a számla sorszámát
-a számla ÁFA összegét forintban és az eredeti devizában.

És ennyi.
Az összes többi NEM kötelező elem. Beleértve a vevő adatait, a pontos pénznemet és az áfakulcsonkénti bontást...

Jól látom vagy csak nagyon fáradt vagyok?????

ui. helyesbítek: a "Online Számla Interfész specifikáció v1.0" szerint nem kötelező a számla nettó értéke a "invoiceApi invoiceData" szerint meg igen. Jó lesz ez...

Én ezzel a kettővel megvagyok egy deszkamodellen. Ha végleges akkor majd egyszerűen be tudom rakni. Csak ugye összeállítottam a teszt számla xml-t amit most nem tudok mindenféle adattal tesztelni. Pl van olyan cégem ahol van fordított áfás termék. Vagy hulladékkezelés ezeket jó lenne már letesztelni.

pch
--
SB-soft online ügyviteli rendszer
--

Valaki tudna segíteni abban, hogy egy XML séma szerint legenerált valid, példa .xml fáljhoz jussak (csak a még nem BASE64 kódolt, példa számlatartalmat tartalmazó xml fáljra gondolok)

Február 26-án 13:00-tól a NAV tart "Online számla fejlesztői fórum"-ot. Ez már a második, mivel az elsőre nagy túljelentkezés volt és sokan lemaradtak róla. Ha valakit érdekel, akkor a https://kobakreg.nav.gov.hu/ oldalon az "Események" menüpont alatt tud rá jelentkezni.

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

Sziasztok!

A 2018. 07.01-én hatályba lépõ online számla adatszolgáltatási kötelezettséggel kapcsolatban kérném az iránymutatásotokat.

Adott az adatexport funkció és az online számla adatszolgáltatás funkció. Ehhez a két funkcióhoz két külön XSD tartozik? Tehát az adatexport funkció által kiállított XML alapú számla, és az online küldött XML alapú számla struktúrája eltérő?

"5. adatexport: az adóalany által elektronikus adathordozón tárolt adatoknak az állami adó- és vámhatóság rendelkezésére bocsátása a 2. melléklet szerint és a 3. mellékletben meghatározott adatszerkezetben, vagy a 13/A. § (1) bekezdés szerinti közleményben meghatározott adatszerkezetben."

Ez a melléklet érvényes mindkét formátumra?

Ez azért marha vicces, szigorítottak a feltételeken,hogy ki mehet a rendezvényre.
Gondolom azért, mert voltak olyanok is, akik anélkül mentek,hogy regisztráltak volna? Ha már ennyien kíváncsiak rá, akkor nem az lenne a megfelelő módja,hogy 1: rendes tájékoztatást adnak,hogy mikor és mennyi ilyen lesz még, 2: még több előadást csinálnak?

Egyébként attól kérdezném, aki volt már ilyenen: mennyire érdemes elmenni rá?

Igen, mondták, hogy sokkal többen jöttek, mint ahányan regisztráltak (nem utcáról beeső emberek, hanem egy regisztrált cégtől több ember).
Gondolom azért is kérik most el előre a neveket, mert nagyon lassú volt a beengedés, ameddig mindenkinek kézzel felírták az adatait belépéskor. Most gondolom már csak pipálgatni fognak a kinyomtatott lista alapján.

Azt mondták, hogy ez az egy alkalom még biztosan lesz, több nem várható. Viszont a mostani alkalom után elérhetővé teszik a diákat.

Szerintem érdemes elmenni rá, sok érdekes dolog hangzott el.

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

Lehet túl egyszerű ember vagyok, de akik készítették a már meglevő dolgokat, vicces gyerekek. Csak a token esetében 3 különböző idő formátumot használnak ( ISO GMT, YmdHis GMT, ISO CET). Ráadásul ez az XML mánia... JSON + REST, csinálják úgy, mint bárki más. :) Ha "csak az XML-t kell előállítani", akkor nem sok PHP mintakód lehet :) Dobjanak fel pár valós élethez közeli XML mintát, szép sorban ( a kódokat így állítod elő, kapsz gy egy tokent, majd ilyet küldesz be a tokennel, ...) oszt' mindenkinek jobb lesz.
Azt hittem, hogy szépen megkapjuk a PHP-s classokat, amiben lesz $Invoice->addRow() vagy ilyesmi. Az, hogy PHP-ban megírják a cURL kezelést nem nagy segítség.

Sziasztok!

Egy kis segítséget szeretnék kérni. Java-ban próbálok egy tokent lekérni a NAV online rendszerétől, de nem sikerül. Még nem csináltam korábban hasonlót (REST API csatlakozás), és nem tudok átlépné ezen a problémán. A hibaüzenetem a következő.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target : sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

NetBeans-ben próbálom futtatni a következő kódot:

package httppostdata;

import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.net.HttpURLConnection;
import javax.net.ssl.HttpsURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
import java.nio.file.Files;
import java.util.Arrays;

public class NetClientPost {

public static void main(String[] args) {

try {

URL url = new URL("https://api-test.onlineszamla.nav.gov.hu/invoiceService/tokenExchange");
HttpsURLConnection uc = (HttpsURLConnection) url.openConnection();

uc.setRequestMethod("POST");
uc.setAllowUserInteraction(false);
uc.setDoOutput(true);
uc.setRequestProperty( "Content-type", "application/xml" );
uc.setRequestProperty( "Accept", "text/xml" );

File xmlFile = new File("tokenExchange.xml");
byte[] xmlData = null;
try {
xmlData = Files.readAllBytes(xmlFile.toPath());
} catch (IOException ex) {
}

String xmlDataStr = Arrays.toString(xmlData);

String[] byteValues = xmlDataStr.substring(1, xmlDataStr.length() - 1).split(",");
byte[] bytes = new byte[byteValues.length];

for (int i=0, len=bytes.length; i 'kisebb(<)' len; i++) {
bytes[i] = Byte.parseByte(byteValues[i].trim());
}

OutputStream os = uc.getOutputStream();
os.write(bytes);
os.flush();

if (uc.getResponseCode() != HttpURLConnection.HTTP_CREATED) {
throw new RuntimeException("Failed : HTTP error code : "
+ uc.getResponseCode());
}

BufferedReader br = new BufferedReader(new InputStreamReader(
(uc.getInputStream())));

String output;
System.out.println("Output from Server .... \n");
while ((output = br.readLine()) != null) {
System.out.println(output);
}

uc.disconnect();

} catch (MalformedURLException e) {

System.out.println(e.getMessage() + " : " + e.getLocalizedMessage());

} catch (IOException e) {

System.out.println(e.getMessage() + " : " + e.getLocalizedMessage());

}

}

}

Nem igazán értem ezt a leírást. A JMeter-el készített példával jönnek, amit nem tudom, hogyan kell átültetni a sima java Post metódusba. A HTTP Request Defaults elemeknek hol kellene szerepelni? Ezt minden híváskor meg kell adni? A technikai userhez van egyáltalán jelszó? Vagy oda a belépéshez szükséges jelszót kell használni. Ezt sem értem. A NAV oldalán belépve, most az user list üres. Az előbb még ott volt a tesztuser és a technikai user is. Bevallom nem tiszta még ez a dolog. Van akinek már működik legalább ez a /tokenExchange metódus?

Jött új verzió.
Természetesen ami eddig jó volt most nem megy.
Most vagy én vagyok hülye vagy olyan is változott ami nincs dokumentálva vagy a navnál van valami mert nem jön vissza semmilyen válasz :(
Számla se megy be.

pch
--
SB-soft online ügyviteli rendszer
--

Sziasztok!

Kaptam vissza a "NAV developer helpdesk-től" (nevezzük így), kódot C# nyelven, ami az AES128 dekódolást valósítja meg. Tudom, van akinek itt sikerült (szinte mindenkinek), és azt hogy a C# nem is igazi prognyelv, de gondolom van akinek majd segíteni fog. Kipróbáltam, működik.

//AES128 Rijndael managed osztály megvalósítása
RijndaelManaged GetRijndaelManaged(String secretKey)
{
var keyBytes = new byte[16];
byte[] secretKeyBytes = Encoding.UTF8.GetBytes(secretKey);
Array.Copy(secretKeyBytes, keyBytes, Math.Min(keyBytes.Length, secretKeyBytes.Length));

return new RijndaelManaged
{
Mode = CipherMode.ECB,
Padding = PaddingMode.PKCS7,
KeySize = 128,
BlockSize = 128,
Key = keyBytes,
IV = keyBytes
};
}

//AES128 enkódolás string inputtal
String Aes128Decrypt(String encryptedText, String key)
{
var encryptedBytes = Convert.FromBase64String(encryptedText);
return Encoding.UTF8.GetString(Decrypt(encryptedBytes, GetRijndaelManaged(key)));
}

//AES128 dekódolás byte inputtal
byte[] Decrypt(byte[] encryptedData, RijndaelManaged rijndaelManaged)
{
return rijndaelManaged.CreateDecryptor()
.TransformFinalBlock(encryptedData, 0, encryptedData.Length);
}

Ez. :D
Egyébként az ő általuk kiadott "onlineinvoicetool_v1.0.jar", és a szintén általuk javasolt "https://www.base64encode.org/" oldal nem adja ugyanazt az eredményt. Erre még nem válaszoltak...

UPDATE

Ugyanazt adja ki mind a kettő, csak nem a "tartalomra" kell kiszámolni (mint ahogy a dokumentációban az le van írva), hanem magára az XML állományra.

Itt egy másik verzió, amit én csináltam, hátha segít valakinek:

//Programkód elején hozzáadni:
using System.Security.Cryptography;

//Maga a szubrutin
public string tokenkikodolas(string token, string cserekulcs)
{
//Tokenkikódolás

string IV = "zasdzhjbilasertg";
string kikodolttoken = "";

byte[] encryptedbytes = Convert.FromBase64String(token);
AesCryptoServiceProvider aes = new AesCryptoServiceProvider();
aes.BlockSize = 128;
aes.KeySize = 128;
aes.Key = UTF8Encoding.UTF8.GetBytes(cserekulcs);
aes.IV = UTF8Encoding.UTF8.GetBytes(IV);
aes.Padding = PaddingMode.PKCS7;
aes.Mode = CipherMode.ECB;
ICryptoTransform crypto = aes.CreateDecryptor(aes.Key, aes.IV);
byte[] secret = crypto.TransformFinalBlock(encryptedbytes, 0, encryptedbytes.Length);
crypto.Dispose();
kikodolttoken = UTF8Encoding.UTF8.GetString(secret);

return kikodolttoken;
}

Base64 kódolásokhoz szubrutin c#-ban:

public string Base64kikodolas(string kikodolnivalo)
{
//Base64 szöveg kikódolása

string kikodoltszoveg = "";

byte[] encryptedbytes = Convert.FromBase64String(kikodolnivalo);
kikodoltszoveg = UTF8Encoding.UTF8.GetString(encryptedbytes);

return kikodoltszoveg;
}

public string Base64bekodolas(string bekodolnivalo)
{
//szöveg bekódolása Base64 kódolással

string bekodoltszoveg = "";

byte[] bytes = Encoding.UTF8.GetBytes(bekodolnivalo);
bekodoltszoveg = Convert.ToBase64String(bytes);

return bekodoltszoveg;
}

SHA512 kódoláshoz szubrutin c#-ban:

public static string SHA512kodolas(string p)
{
//SHA512 kódolás

string Hashed = BitConverter.ToString(((System.Security.Cryptography.SHA512)new System.Security.Cryptography.SHA512Managed()).ComputeHash(System.Text.Encoding.ASCII.GetBytes(p))).Replace("-", "");
return Hashed;

}

Időről időre ránézek erre a dilettáns baromságra, hogy ha majd foglalkozni kellene vele, akkor képben legyek.

Mi a véleményetek a következő kérdésekről?

1) Batch beküldés: ki erőltet még ilyet 2018-ban, mi szükség van egyáltalán egy ilyen implementálására, és miért ebben az elbaszott formában? Ha van valamilyen performance bottleneck, akkor miért jelenik meg a public API-ban, ha valamelyik "nagybeküldő" lobbizta ki, akkor miért tehetett ilyet; ha nincs is performance bottleneck, csak a tervező túltolt valami anyagot, akkor miért tehette? Könyörgöm, nem 1994-ben vagyunk a zöld karakteres konzol előtt a serial vonalon.

2) A feldolgozás aszinkron történik, a beküldött adatokra rá kell kérdezni 3-5 perccel később (most ennyit írnak, aztán majd meglátjuk. Idézek:
az adatszolgáltatási kötelezettség elmulasztása, késedelmes, hiányos, hibás vagy valótlan adattartalmú teljesítése esetén a kiszabható mulasztási bírság felső határa az érintett számlák, illetve számlával egy tekintet alá eső okiratok számának és az általános bírságszabály szerinti bírság adózóra egyébként vonatkozó legmagasabb mértékének szorzata. A Rendelet tervezett módosítása alapján az adatszolgáltatás akkor történik meg, amikor a sikeres feldolgozást a rendszer visszaigazolta. Mivel a visszaigazolás a /queryInvoiceStatus operációval történik meg, ameddig nem valósul meg a státusz lekérdezése, nem történik meg „jogszabályilag” az adatszolgáltatás. Mindezekre tekintettel a státusz lekérdezésének elhúzódása, elmaradása esetén mulasztási bírság megállapításának lehet helye. Természetesen a bírság összegének megállapításakor az adóhatóságnak a mulasztás súlyát, körülményeit, stb. mérlegelni kell.

Hát ez CLAP CLAP CLAP
(emoji levágva)

Szerintem csak opcionális a batch küldés, nyugodtan lehet egyesével is küldözgetni. Biztos van olyan eset, amikor kliens oldalon segítség lehet, ha megvan a lehetősége a nem egyesével való kommunikációnak (pl. több kliens gép készíti a számlákat, de csak egy központi végzi a kommunikációs folyamatot,

Az aszinkronnal mi a baj? Ahol sok számla készül szerintem sokkal jobb, ha a gép akkor kérdezi le ezredmásodpercek alatt az eredményt amikor éppen szabad kapacitása van, nem pedig akár csak pár másodpercre (üzleti validáció idejére) nyitva kell tartania akár sokezer socketet...

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

Információs rendszerek és termékek gazdaságtanán volt erről már szó nálunk, ez egy ökölszabály: Mindig mindenből vagy az első, vagy a szar terjed el a legjobban. Ha valami egyszerre első egy adott területen ÉS szar, akkor pedig tuti sikeres lesz. Ha információs terméknek veszünk mást is, pl filmeket, könyveket, akkor ez további dolgokat magyaráz meg. Szóval amiről te beszélsz, az engem is bosszant, de "annyira" nem lep meg.

Engem inkább az a visszatérő jelenség zavar, hogy a korábban megvalósított funkciók egyszer csak gondolnak egyet, és nem működnek többé... Üzemszünetről, speckó változásról meg nuku infó.

A /queryInvoiceStatus operáció még mindig nem működik? Tudni szeretném, hogy az én készülékemben van-e a hiba... Speckóban kerestem erre utaló információt, de lehet rosszul kerestem, mert nem találtam.

UPDATE: Már megy, de az előbb (pár órája) még nem működött (eskü)

Az adatszolgáltatás utáni lekérdezés, amitől az egész művelet "DONE" státuszba kerül, az sikerült már valakinek? A /queryInvoiceStatus operációval próbálkozom, de esete válogatja, hogy 500-as hibát kapok, vagy "RECEIVED" státuszt válaszként.

Én még nem tartok ott, de van egy csomó más kérdés, ami elég aggasztó.

Néhány konkrét eset, amiket már megírtam a megadott címre, de még nem kaptam rá választ:

  • volt egy hibám, én szúrtam el, nem vettem észre. 2-3 óra szopódás után írtam, hogy segítsenek, aztán hazamentem. Közben kiszellőzött a fejem, és este 10p alatt megtaláltam, mit rontottam el. Kijavítottam, és azóta az működik. Rá két napra megjött a válasz, hogy a tűzfal megfogott bizonyos kéréseket, emiatt nem megy a lekérdezésem... Írtam nekik, hogy nem az volt a hiba, erre még nem jött válasz...
  • Volt egy typo-m, az egyik XML tag-ből kimaradt egy betü. Ilyenkor ez a válasz érkezik:
    HTTP/1.1 500 Internal Server Error
    Date: Mon, 26 Mar 2018 18:28:37 GMT
    Content-Type: application/xml
    Content-Length: 24
    Connection: close
    Set-Cookie: BIGipServer~ESZAMLA~EDU_k8s=!....ag==; path=/

    Feldolgozás sikertelen!


    Vagyis a Content-Type fixen application/xml mindig, ha a válasz plain/text, akkor is.
  • Tegnap óta ez a válasz jön a /queryInvoiceData kérésre:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?><QueryTaxpayerResponse xmlns="http://schemas.nav.gov.hu/OSA/1.0/api" xmlns:ns2="http://schemas.nav.gov.hu/OSA/1.0/data"><header><requestId>RID1522...</requestId><timestamp>2018-03-26T18:43:03Z</timestamp><requestVersion>1.0</requestVersion><headerVersion>1.0</headerVersion></header><result><funcCode>OK</funcCode><message>The request is valid, but the endpoint is currently down. It will soon serve requests in the close future.</message></result></QueryTaxpayerResponse>
    Ennek nyomát sem találom a dokumentációban. Az is érdekes, hogy az üzenetek egy része magyar, más része angol.

Jól látom, hogy ezt a rendszert most fejlesztik, kvázi velünk párhuzamosan?

Igen, ezt velünk párhuzamosan fejlesztik. Annak idején az EKÁER projekt ebből a szempontból azért volt jobb mert ott oké, hogy sok verzió jött ki, de legalább kaptunk egy kész platformot, amin lehetett tesztelni.

Amúgy nálam van előrehaladás, "DONE" státuszba úgy kerül a számla ha ki van töltve az "invoiceCategory" tag a számlafejben, (én közvetlenül a számla sorszáma után nyomtam be). Ebben a tekintetben hibás az XSD, mert abban úgy van feltüntetve, hogy ez egy nem kötelező elem.

Ezt amúgy az "ismert hibák" szekcióban találtam:
https://onlineszamla-test.nav.gov.hu/informatikai_valtozasok

Érdemes a dokumentációkat, sémadefiníciókat meg API leírásokat ismét megnézegetni, mert 13-tól változások lépnek majd életbe.

Tudom. Július előtt meg lesz csinálva amit addig összegereblyéznek.
Viszont annak se látom értelmét, hogy minden update után előröl kezdjem a fejlesztést.
Eddig megvolt a beküldés, a storno beküldés, a lekérés, a token.
Azóta volt egyszer egy xml séma változás. Jó beleírtam
13.-án jön megint egy változás. Hát nem.
Majd előtte egy hónappal megnézem mit kell, hogy küldeni és azt fogom leprogramozni.
Gondolom addig csak kitisztul az xml. Azt meg ha már megvan a többi csak megoldom :)

(ha meg csúszok lekorlátozom az áfatartalmi limitre /csak poén/)

pch
--
SB-soft online ügyviteli rendszer
--

Megjelent május 9-én a specifikáció 0.12-es verziója, amiben már szerepel, hogy másodlagos felhasználót is lehet létrehozni. Gondoltam kipróbálom, működött is, viszont van egy kis érdekesség a jogok kiosztásánál:

Jogosultságok beállítása

Online Számla adatkezelő

[ ] Bejelentkezés
[ ] Számlák lekérdezése
[ ] Számlák exportálása
[ ] Adóalany lekérdezése
[ ] Számlák ellenőrzése

Online Számlázó Program

[ ] Belépés
[ ] Számlakiállítás
[ ] Számlatömb megtekintése
[ ] Számlatömb módosítása
[ ] Adatok megtekintése
[ ] Adatok módosítása

Eddig nem nem mondták egyértelműen, hogy lesz "nemzeti számlázóprogram", bár az is igaz, hogy konkrét rákérdezéskor tagadás helyett csak kitérő válaszok voltak.

Remélem lesz hozzá API :D Látnék benne fantáziát, hogy a NAV rendszerében készítem el magát a számlát a saját rendszerben levő adatok alapján, és én csak az adatait tárolom, dolgozom fel :)

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

Ha tényleg online számlázó program lesz, akkor kizárt dolognak tartom, hogy ne lehessen bárkinek bármilyen számlát kiállítani benne. Teljesen logikátlan lenne. Már csak azért is, mert pl. az ÁFA bevallás kiajánlásához minden számlára szükség van, nem csak az adószámos vásárlók részére kiállított számlákra, és ugye távlati célként emlegették ezt is...

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

Sztem se túl logikus, hogy ha már egyszer megcsinálják, akkor a számla címzettje csak adószámmal rendelkező legyen. Ez a megkülönböztetés tkp. csak szivatás lenne.

A valódi kérdés a felhasználók túlnyomó része számára a tárolás és a hozzáférés módja. Ha ezt megcsinálják úgy, hogy az átadott számlatartalom a vevő számára a NAV-nál elérhető és az onnan letöltött elektronikus számla könyvelhető, akkor sztem nagyjából mindenki ezt fogja használni ahelyett, hogy postára adná a papírszámlát vagy fizetős e-számla szolgáltatót venne igénybe.

Az online számlázó nyilván a vállalkozásoknak azt a részét érinti, amelyik ma kézzel irogat számlát és a könyvelőnek papirkupacokat ad át. Ha ezt is jól megcsinálnák, mindent sokkal könnyebb lenne ellenőrizni.

Kérdés persze, hogy a NAV-nál van-e valaki, aki az adófizetők érdekeltségét ebben az ügyben számításba veszi - vagy egyszerűbb a NAV-os közhivatalnokok számára beszorítani az adózókat, kényszeríteni és büntetni. Megintcsak nem számítástechnikai kérdésről van szó.

Megjelent a 0.14-es verzió, ha valakinek nem megy a számla beküldés (de korábban működött), akkor valószínűleg azért, mert kimaradt az időközben kötelezővé vált "compressedContent" tag az API xml-ben.

Sziasztok,

Sikeresen küldöm be a számlákat... viszont egy érdekes vita..
Termék kód kötelező vagy nem? Gondolok itt a VTSZ/SZJ társai feltüntetésre. AZ XSD megköveteli, de az áfa törvény meg nem....
NAV álláspontja a következő amin sikerült egy jót röhögni....
„4/A. Számlázó programok adatszolgáltatása

13/A. § (1) A számlázó programnak a gép-gép interfész használatához szükséges azonosító adatok megküldése mellett a kiállított számla, számlával egy tekintet alá eső okirat legalább Áfa tv. szerinti kötelező adattartalmát a számla, számlával egy tekintet alá eső okirat kiállításakor azonnal, XML-formátumban, az állami adó- és vámhatóság közleményében meghatározott módon és adatszerkezetben, elektronikus úton továbbítania kell az állami adó- és vámhatóság részére.

Navos jogásszal beszéltem aki elmondta hogy az áfatörvényen kívül.... "az állami adó- és vámhatóság közleményében meghatározott módon és adatszerkezetben", viszont ezek a közlemények még nem léteznek...

kinek mi a véleménye?

Ki kell várni a végét. Biztos emlékszel rá mikor mindenki a címet bontotta mint az őrült(utca, közterjelleg, épület, stb), mert azt kérte a NAV adatszolgáltatás xml. Majd dec 20. -a körül mikor már sokan kész voltak vele kijött egy állásfoglalás, hogy törekedni kell rá, de ne nem lesz akasztás, ha egybe lesz beírva valamelyik mezőbe. Most meg az online számla xml-ben van simle_address_type vagy valami hasonló.

FONTOS:
Sémaleírás alapján az "invoiceDeliveryDate" nem kötelező (a letölthető java-s ellenőrző program "OK"-ot ír ki), ugyanakkor a szerver "MANDATORY_CONTENT_MISSING" hibaüzenetet ad vissza ha az nincs meg.

Szia!

Gyűjtőszámla esetén a tételsorokon kell megadni a teljesítési dátumot, ezért van az, hogy a invoiceDeliveryDate opcionális. "Normál" számla esetén viszont törvény szerint kötelező.
Mivel a séma több fajta számla beküldését támogatja, ezért vannak olyan mezők, amelyek egyes esetekben kötelezőek, de a sémában nem azok, mert hibát okoznának az olyan esetekben, amikor törvény szerint nem kötelező / értelmezhető az adat.

Tesztek alapján vevő adataira semmi szükség nincs, úgy is elfogadja a rendszer...
Kíváncsi vagyok így mennyire szabályos, hisz a NAV befogadja. Utólag mondhatja, hogy szabálytalan?

A séma szerint nem kötelező.
A NAV nem törvényalkotó szerv és azért az érdekes helyzet lenne, ha a számla export adatainak helyessége egy szoftver dokumentációjából következne, nem pedig egy egzaktul ellenőrizhető sémából...
Persze Magyarországon vagyunk, bármi lehetséges.

Június 1.-vel, 30 nappal az indulás előtt az alábbi kormányhatározat jelent meg:

2. § (1) A Rendelet 8. § (1) bekezdése a következő d) ponttal egészül ki:
[A számlázó programmal szemben követelmény, hogy]
„d) biztosítsa a  kiállított számla, valamint számlával egy tekintet alá eső okirat legalább Áfa tv. szerinti kötelező
adattartalmának az  állami adó- és vámhatóság részére történő, 13/A–13/B.  § szerinti elektronikus úton történő
továbbítását.”

Magyarán ettől kezdve az XML séma kötelező/nem kötelező jelölései semmit nem érnek, mert nem az az irányadó hanem az ÁFA tv.
Magyarország én így szeretlek!!!

Ez a d) pontos kiegészítés hirtelen nagyon durva lett, még ha ha nem is tűnik annak első ránézésre :)

Sokan mondták azt, hogy használják a régi, már nem fejlesztett számlázó-készletnyilvántartó programjukat, és legrosszabb esetben azt az évente 0-5 db olyan számlát, ami adatszolgáltatásra kötelezett lenne, azt kézi számlatömbbe írják és manuálisan bevallják. Eddig erre minden helyen azt mondták a NAV képviseletében levők, hogy ugyan nem ez az elvárt módszer, de törvényes és csinálhatják. Most viszont a közlönyben kihirdetett d) pont miatt nem használhatják tovább a régi számlázóprogramot, mert az nem tudja teljesíteni az elektronikus úton történő adatszolgáltatást, így nem felel meg a számlázóprogramokkal szemben támasztott követelményeknek.... Most az is rohangálhat új számlázóprogramot venni, aki soha nem készít 370.370,- + 27% ÁFA összeget meghaladó számlát, vagy soha nem számláz cégnek, stb, stb.

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

Én tudom, egy évvel ezelőtt a nyitó postban is már ugyanezt írtam :) Sőt, nekünk csak jól jön ez a szigorítás, mert olyan új előfizetők is jönnek, akikre nem is gondoltunk :)

De akkor sem tartom jó dolognak, hogy aki eddig nyugodt volt, mert rá nem vonatkozik a dolog, most tudtán kívül az is bajba kerülhet. Miért olvasgatná mondjuk egy AAM EV akár a közlönyt, vagy bármi más helyen a számlázóprogramokkal kapcsolatos elvárásokat, ha egyszer a csapból is az jön, hogy csak 100e Ft ÁFA tartalmat meghaladó számlákat kell kommunikálni, neki pedig 0 Ft az ÁFA a számláin, azaz rá nem vonatkozik a változás és használhatja tovább a régi programját ami nem tud küldeni....

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

Én pár hete, pusztán "poénból" kipróbáltam, hogy beküldtem egy számlát, majd beküldtem a két héttel korábban kiállított, előző sorszámú számlát (ennek a közlése még nem történt meg előtte).

A rendszer simán befogadta mindkettőt.

Nem igazán hagyott békén a dolog, ezért írtam a supportnak, és ezt a választ kaptam:

"Tájékoztatjuk, hogy csak a helyes sorrendben beküldött számlák fogadhatóak el, de a rendszer még nem vizsgálja a beérkezett számlák sorrendjét."

Hát hello.

Szóval a "tesztek alapján" én nem fogadnék el semmit, inkább kérdezd meg.

Szerintem ebben semmi rossz nincs.

Teljesen életszerű lehet az az eset, hogy pl. netszolgáltatás kimaradása esetén nem szigorúan számlaszám és dátum sorrendben esnek be oda a számlák, hanem a legutoljára kiállítottat azonnal küldi a rendszer, az előtte levőket meg mondjuk óránként próbálja ismételten elküldeni. Ha jól emlékszem, akkor a fejlesztői fórumon is volt szó erről, hogy ezt engedni fogják.

Azt nem fogják engedni, hogy a számlaszám és a számlához tartozó dátum ne mutasson szigorú monoton növekedést, azaz egy későbbi számlaszámhoz nem tartozhat korábbi kiállítás dátuma.

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

Teljesen életszerű lehet az az eset, hogy pl. netszolgáltatás kimaradása esetén nem szigorúan számlaszám és dátum sorrendben esnek be oda a számlák, hanem a legutoljára kiállítottat azonnal küldi a rendszer,

Ez ok, de erre írták a választ, hogy ezt nem lehet.

Azt nem fogják engedni, hogy a számlaszám és a számlához tartozó dátum ne mutasson szigorú monoton növekedést, azaz egy későbbi számlaszámhoz nem tartozhat korábbi kiállítás dátuma.
Ilyet én nem írtam.

Szerintem a válaszukat lehet úgy (is) értelmezni, hogy a "helyes sorrendben" az azt jelenti, hogy a számlaszámok és a dátumok sorrendben vannak náluk az adatbázisban, azaz nem tartozik későbbi számlaszámhoz korábbi dátum. Ez szerintem teljesen egyértelmű, de vagy azon a fórumon amelyiken te is ott voltál, vagy az előzőn elég heves vita volt abból, hogy a számla elkészítése (ami csak a rajta szereplő adatok összeszedését jelenti) kiállítása (azaz a számla tényleges elkészítése) és kibocsájtása (azaz a számla kinyomtatása / időbélyegzése) többeknél nem egyetlen lépést jelent, hanem időben eltolódó folyamatot. Mondjuk csütörtökön elkészítik a tömeges számlázáshoz a számlákat (amik akkor már megkapják a számlaszámot) de csak hétfőn fogják kiállítani és kibocsájtani (azaz hétfői dátummal), viszont pénteken ettől függetlenül kibocsájtanak egy másik számlát pénteki dátummal. Ekkor előáll az a helyzet, hogy a nagyobb számlaszámnak korábbi a kibocsájtási dátuma, mint a kisebb számlaszámoknak. Erre mondták azt, hogy nem fogják támogatni.
Azaz nem konkrétan magára a beküldési folyamatra vonatkozik a helyes sorrend, hanem a beérkezett számlákra.

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

Egyéb olyanokat is lehetett hallani a fejlesztői fórumon, hogy csak csodálkoztam rajta. Nem tudtam eldönteni, hogy a kérdező ennyire nem ért hozzá, nagyon bátor vagy szimplán csak vakmerő :D

Könyvelői előadáson mondtak erre a dátum-mizériára konkrét példát: nagy cég, sokezer számla, nyomdával állíttatják elő és küldetik ki a számlákat. A számla elkészítésének dátuma az az, amikor az adattartalmat előállították, viszont a kibocsátás dátuma az az, amikor a nyomda kinyomtatta az átküldött adatok alapján a számlát. A kettő között napok is eltelhetnek. Az ÁFA törvény a kibocsátás keltét írja elő kötelező adattartalomnak, ez pedig elméletileg nem az adattartalom összeállítása, hanem a számla fizikai létrejötte, ezért szokták előre dátumozni. Az, hogy ez így helyes-e, azt nem az én tisztem eldönteni, de így működik. Én nem érzem nagy gondnak ezt az előre dátumozást, de ettől még lehet, hogy jogilag problémás. Nálunk nem lehet a dátummal és a sorszámmal variálni, így ilyen probléma nem fordul elő szerencsére :)

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

a "helyes sorrendben" az azt jelenti, hogy a számlaszámok és a dátumok sorrendben vannak náluk az adatbázisban, azaz nem tartozik későbbi számlaszámhoz korábbi dátum.
Szerintem is. A levélben, amiben a kérdést feltettem, írtam konkrét példát:

pl 6-os számla, kiállítás dátuma 2018.04.20.

Miután erről megkaptam a visszaigazolást, hogy minden ok, beküldtem az 5-ös számlát, 2018.04.09-i dátummal.

Erre írtam a kérdést, hogy ezek szerint tök mindegy, hogy hogy küldöm be? Szerintem ez a sorrend így nem helyes (ill. ha jól értelmezem a hozzászólásodat, szerintem sem helyes :)).

És erre írták, hogy még nincs kész az a funkció. :)

A beküldés és a számla dátuma ill. sorszáma között nincs kapcsolat. Ha a rendszer, amelyik a számlát elkészíti, nem tudja azt garantálni, hogy egy számlasorozatban időbelileg növekedjenek a számlák sorszámai, az a rendszer sztem eddig sem volt szabályosan használható. Az kuka. Hogy a számlát mikor küldöd be, az itt nem játszik, az a lényeg, hogy amikor a számla sorszámot kap, akkor a sorszám nagyobb legyen, mint az előtte ugyanabban a számlasorozatban kiállított utolsó számla. Ez sztem teljesen normális és indokolt kikötés.

Azért is valószínűbb, hogy mégis helyes, hogy párhuzamosan is be lehet küldeni többet is, aminél a sorrendiség nem játszik.

Párhuzamos beküldési lehetőség is adott, akár ugyanazzal a technikai felhasználóval
Beküldés intenzitására, mennyiségére, párhuzamos szálakra nincs korlátozás
--
Ickenham template engine

Elindult az éles rendszerbe történő regisztráció a https://onlineszamla.nav.gov.hu címen.
Adatot szolgáltatni még nem lehet, de tokenkéréssel lehet tesztelni a kommunikáció működőképességét a programokból.

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

Működik az, csak várd ki a választ. Az a néhány HTTP 502 meg most miért zavar?

:)

ps: a számla állapotának lekérdezésénél (QueryInvoiceStatusRequest) módosították a válasz fejlécet, "Content-Type: application/xml" helyett már "Content-Type: application/xml;charset=utf8" van. De még mindig csak ennél a válasznál adnak meg charset-et.

ebben a szent minutumban invalid req. signature hibát ad vissza. én vagyok hülye, vagy ez így nap bégére megdöglik mert gizi kihúzza a netkábelt?

Nekünk úgy 18 óra körül volt egy sikeres adatszolgáltatás a teszt rendszerbe, de utána már csak ugyanaz, ami neked is. De legalább tudtuk tesztelni a kód azon részét is, aminek ezt a helyzetet kell kezelnie :D

Talán jó lenne, ha lenne legalább valami status oldal a NAV részéről, ahol lehetne látni a működőképességi állapotot, mert arra nem igazán lehet alapozni, hogy időben kiírják az onlineszámla portálra a fennakadást...

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


Soron kívüli verzióváltás 2018-06-19 23:28
Az elmúlt napokban jelentősen megnőtt a teszt rendszer forgalma, ezért a fokozottabb terhelés kiszolgálása és a feldolgozás gyorsítása érdekében üzemeltetési intézkedések végrehajtása és a 0.16-os verzió bizonyos elemeinek előrehozott telepítése szükséges. A telepítés leállással, 2018.06.20-án délután fog megtörténni. A leállás tervezett időtartama 5 óra, a pontos kezdési időpontról frissítést teszünk közzé.

Vajon mekkora terhelésnövekedés lesz július 1 után?
Azt hiszem a beküldő modulunk két legfontosabb funkciója lesz az időben történő sikertelen beküldés dokumentálása, majd a csúcsidőn kívüli újraküldés :D

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

Jó neked, hogy már éjfél előtt megkaptad az értesítést... :) Nekem 12:02-kor esett be a mail, kollégám még nem kapta meg.

Az üzemszünetek alatt még mindig nincs kint a ma délutáni (5 órásra tervezett) leállás.

Én szinte naponta találok benne hibákat, amiket próbálok bejelenteni - de már automata válasz sem jön :), érdemi válasz meg pláne.

Az értesítés az nekem is csak nemrég (Wed, 20 Jun 2018 12:02:31) esett be, csak mivel nagyon nem akart működni a dolog, éjfél fele ránéztem a teszt nyitóoldalára és ott virított a hírek között...

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

Sziasztok,

Az a kerdesem,aki foglalkozik ezzel, hogy az online adatszolgaltaskor a source/szamla kiallitasanak ip cimet is eltarolja a NAV? Elkuldesre kerul?
Nem a regisztraciokor, hanem minden egyes szamlanal.

+1
Tényleg miért fontos? Szerintem biztos-ami-biztos alapon elrakják. Én elraknám. Ha másért nem, felismerni bizonyos "mintákat": beküldés gyakoriság, hibák, stb.
GDPR szerint is tárolható, szvsz.

Mi az óvatosság oka? (Ha ilyen óvatos vagy, akkor nekünk úgysem fogod elárulni).

Nem hit kérdése. A NAV működését is alapvetően jogszabályok szabályozzák.

Szóval, ha teszem azt valaki a NAV-nál csinál egy internetes nyereményjátékot a "Legszebb Gyöngybetűkkel Kitöltött 17SZJA nyomtatvány" címen, ahova fel kell töltened az adataid, arra ugyanúgy vonatkozna a GDPR és ugyanúgy célja kell, hogy legyen az adatkezelésnek.

NAV esetén persze vannak extra előírások.

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

Szerintem őket kellene megkérdezni. Bocs ha ezt már megtetted, vagy ha ez nem opció...

Szóval vagy igen vagy nem.
Ha igen, akkor vagy bevallják, vagy nem.
Ha nem, akkor vagy bevallják hogy nem, vagy félrevezetnek és azt mondják, hogy igen.
Számításaim szerint 25% az esély arra, hogy eltárolják ÉS ezt be is vallják neked.

UI: Igen, tudom...

Én kaptam róla levelet:

"Az elmúlt napokban jelentősen megnőtt a teszt rendszer forgalma, ezért a fokozottabb terhelés kiszolgálása és a feldolgozás gyorsítása érdekében üzemeltetési intézkedések végrehajtása és a 0.16-os verzió bizonyos elemeinek előrehozott telepítése szükséges. A telepítés leállással, 2018.06.20-án délután fog megtörténni. A leállás tervezett időtartama 5 óra, a pontos kezdési időpontról frissítést teszünk közzé."

HP belső info (nem szuper titkos, csak nem írják ki): épp most szállítanak le 30db új szervert a számlaadatok feldolgozásához. Ez azért már bírni fogja :)

Külföldi ip-ről el lehet érni?

Szerintem semmilyen földrajzi korlátozás nincs. Kipróbáltam az előbb németországi és amerikai gépekről, bejön a kezdőoldal.

Sőt, felhívták a figyelmet arra is, hogy az adatszolgáltatás magyar idő szerint 07.01 00:00-kor kezdődik, azaz előfordulhat, hogy helyi idő szerint június 30-án készült számláról is adatot kell már szolgáltatni.

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

A teszt rendszerben korábban "queryInvoiceStatus"-ra belátható időn belül kaptam DONE (vagy hiba miatt amit kellett) státuszt. Tegnap délután (2018.06.25 17:00) óta viszont a beküldött számlák PROCESSING státuszal jönnek vissza.
Nektek mi a tapasztalatotok? Valami beragadhatott náluk? Csak engem tisztelnek meg vele vagy másnál is ez a helyzet?

És még nem is tud tesztelni minden cég...
Nem bírja a 30 új microserver? :-) Vagy AMD procisokat vettek az intel para miatt?
Tegnap 15 óra után már nekem is az ígért 10 helyett kb. 30 perc volt egy feldolgozás.
Volt is miatta Blokkoló hibám, mert a hivatkozott számlát még nem dolgozták fel...
Remek lesz,ha napi 1 számla lesz a feldolgozás sebessége.
Én mondtam már a főnöknek, hogy hó elején (a közepéig) tegyen le a számlázásról...

De nyugodjunk meg, ők mindenre felkészültek...

Szerk: Nekem a tegnap, 14:51-kor beküldött számlámat sem dolgozták még fel ma 08:09 -ig.

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

Nem én fejlesztek, én csupán tesztelném a fejlesztést (végfelhasználóként), és egyeztetnék a fejlesztőkkel, csak ha nem dolgozzák fel a számlákat, akkor nehéz őket pl. lesztornózni.
Az éles rendszernél meg még nehezebb lesz 1-2 napot várni, amíg egy hibás számlát ki lehet javítani.

Az e-mail cím helyett a https://hup.hu/node/154252#comment-2243703 -ben lévő helyen kell állítólag hibát jelenteni (ezt a 1819 -en mondták).

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

Hiba bejelentése:

https://onlineszamla-test.nav.gov.hu/ oldalon a lap alján a jobb alsó sarokban. A telefonszámot (1819) kár hívni felesleges 5*5 perc, és szutyok zene van csak...

http://nav.gov.hu/nav/e-ugyfsz/levelkuldes
Kategória: Számla adatszolgáltatás, informatikai problémák

Itt mind a 20 mezőt ha kitöltöd, akkor megy el az üzenet.

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

Regisztráltam, mint adózó, a https://onlineszamla.nav.gov.hu/ honlapon, a regisztráció rendben is ment, csakhogy nem tudok belépni. A https://onlineszamla.nav.gov.hu/login oldalon próbálok bejelentkezni, mint regisztrált adózó, de ezt írja:

Technikai hiba! Kérjük, próbálkozzon később! Érvénytelen kérés!

Én rontok el valamit, vagy más sem tud bejelentkezni? Egyébként a regisztráció folyamata nem nehéz annak, aki használt már ügyfélkaput, és ért a számítógéphez legalább alapszinten, de nem vagyok benne biztos, hogy segítség nélkül minden adózó végre tudja hajtani ezt a regisztrációt, legalábbis a userekkel történő személyes tapasztalatomból kiindulva sok embernek az is gondot okoz, hogy kap egy emailt, amiben van egy aktiváló link, arra kattintva létre kell hozni a felhasználónevét és meg kell változtatni a kezdeti jelszót. Szóval elég sok embernek egy ilyen egyszerű művelet is gondot okoz, akkor viszont sokan nem fognak tudni ide regisztrálni segítség nélkül.

A mai nap folyamán legalább egy tucat embernek segítettem telefonon a regisztráció elvégzésében, és mindegyiküknek sikerült eljutni odáig, hogy a számlázóprogram az éles online számla rendszerből sikeresen lekérte a tokent a frissen létrehozott technikai user adataival.

Cserélj böngészőt, próbáld meg inkognitó módban, kapcsold ki a reklámblokkolót, engedélyezd a tűzfalon a szükséges kapcsolatokat, tiltsd le a víruskeresőt, vagy csináld mobiltelefonról és mobilneten, mert működik.

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

Basszus, megvan a hiba oka, ilyet még soha életemben nem láttam. Ha jelszókezelővel töltöm ki automatikusan a felhasználónevet, jelszót, akkor jön ez a technikai hiba üzenet. A jelszó mezőbe bemásolni nem lehet semmit. Csak akkor működik a belépés, ha beillesztem a felhasználónevet, a jelszót pedig szigorúan kézzel bepötyögöm, így be tudok lépni. Minden egyéb esetben hibaüzenet jön.

pedig kitölti a jelszókezelő mindkét mezőt, de mégis hibaüzenet jön a belépés után. Kézzel kell beírni a jelszót.

Na ilyet még soha sehol nem láttam, tényleg egyedülálló fejlesztés ez a NAV online számla. Azért jó, mert így erős, hosszú jelszót nem érdemes megadni, hacsak nem akar valaki percekig pötyögni belépéskor. Mekkora szívás, ezzel szívok napok óta. Ki gondolta volna, hogy az a megoldás, hogy kézzel kell beírni a jelszót, nem jelszókezelővel.

Kicsit lejjebb, épp neked válaszolták ezt korábban:

Nem csak a plusz regisztráció felesleges, hanem az is egy nagy baromság, hogy nem lehet beilleszteni pl. KeePass-ban generált 25 karakteres jelszót, hanem be kell gépelni. Naná, hogy így a lehető legegyszerűbb jelszava lesz mindenkinek...
--
Ickenham template engine

Én is észrevettem, hogy vágólapról nem lehet beilleszteni, de nekem a jelszókezelő bemásolja automatikusan, tehát kitölti a jelszó mezőt a megfelelő jelszóval, nem a vágólapról másolja be, de mégis jön ez a technikai hiba üzenet. Ez zavart meg, gondoltam ha már ki van töltve a jelszó mező, akkor az jó úgy, de sikerült úgy megcsinálniuk, hogy ezt sem fogadja el.

Az kedves, tényleg akkor inkább ez lehet. Mert nekem 15 karakternél hosszabb volt a jelszó.
Viszont a jelszó beállításnál nem írja, hogy 15 karakternél nem lehet hosszabb a jelszó. De miért pont 15 karakter? Az elég rövid egy jelszónál. Ha már ilyen rövid jelszót lehet csak megadni, ezt egyértelműen jelezniük kéne a mező mellett.

Nem jelenthető ki, hogy teljes mértékben felhasználóbarát lenne a regisztráció :)

hidd el ez már fényévekkel jobb mint a korábbi volt. amikor maga regisztráció folyamata hetekig elhúzódott mert olyan problémákat nem jelzett a felület, hogy ha nem csupa nagybetűvel írod be a helység nevet akkor nem fogadja el, de csak valami olyat írt ki, hogy az adatok nem megfelelőek(?). azt már találd ki magad, hogy miért nem.
kedves üf regisztrációja jó sok idő volt.

A Technikai hiba! Kérjük, próbálkozzon később! mondatok és az Érvénytelen kérés! mondat eléggé ellentmondásos, de hát nekünk ez jutott :).

Én rontok el valamit, vagy más sem tud bejelentkezni? - az élesre nincs acc-om, de könnyen lehet, hogy tényleg nem megy. Tegnap este a teszt rendszer nem volt elérhető (mármint a böngésző felület, az API működött).

Szóval elég sok embernek egy ilyen egyszerű művelet is gondot okoz, akkor viszont sokan nem fognak tudni ide regisztrálni segítség nélkül. - ez amúgy egy érdekes téma, és szerintem kilép a NAV adatszolgáltatás témakörből, de ezzel mit lehet csinálni? Mennyire kell leegyszerüsíteni egy oldal működését, hogy tényleg mindenki tudja használni? (Amúgy a gov.hu-s oldalaknál van néhány f@...ág, ami ki tud akasztani, és egy "átlagos" felhasználót tényleg megállít...)

[off]
Az alapvetően nem egyszerű dolgokat nem lehet leegyszerűsíteni.
Nem véletlenül lett képezve ennyi könyvtáros informatikus, és nem véletlenül volt/van annyi ECDL tanfolyam is.
A technika ma már megkerülhetetlen, "aki nem ért hozzá, az álljon inkább félre" elv van...
Senkit sem érdekel, hogy mennyire ki van babrálva az átlag emberekkel a folyamatos agyament fejlesztés és követelmény az újabbnál újabb baromságok bevezetése miatt.
Nincs már és nem is lesz egyszerű rendszer.
A mai oktatásban semmi sem hajaz arra, hogy akinek van bárminemű informatikai tanulmánya, az legalább konyítson is a témához. (ld.: ált. iskolában sem az elvet tanítják, hanem konkrét baromságokat). Kétségtelen, hogy akár egy telefon felépítése is nagyban megváltozott az elmúlt 10-15 évben, ám még sokan azt sem értik, hogy hogyan tudnak telefonálni (valami varázslatnak képzelik, de nem is érdekli őket). Az viszont már annál inkább, hogy miért nincs térerő, amikor kéne...

Piacgazdasági oka pedig:
Minek vennél újabb eszközt, ha a régin is elfutna minden, amit használni szeretnél (esetleg szimplán a a hibák javításával)?
Inkább húzzunk be ezer helyről ezeregy szutykot, terheljük túl baromságokkal az eszközöket, és vegyél újabbat, gyorsabbat, (szoftveresen) x@rabbat, hogy gyorsabban lefusson a programozó végtelen ciklusa is.
:D
[/off]

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

Próbáltam megváltoztatni a jelszót, hátha nem jó jelszót írok be, viszont a jelszóváltoztató oldalon is ezt írja: Érvénytelen kérés! Pedig biztos jó jelszót írok be, nem túl hosszú és alfanumerikus.

Egyébként az egész online számla regisztráció felesleges, mert olyan információkat kellett megadnom, melyek már eleve rendelkezésre állnak a cégjegyzékben és az ügyfélkapuban, tehát elég lett volna generálni automatikusan minden cégnek egy API kulcsot, melyet megadok a számlázó programomban, engedélyezem az adott számlázóprogram hozzáférését az ügyélkapun, kész. Az online számlázáshoz külön regisztráció, felhasználónév, jelszó teljesen felesleges.

https://hup.hu/node/154252#comment-2243703
Itt jelentsd be a hibát, hátha...

Nem csak a plusz regisztráció felesleges, hanem az is egy nagy baromság, hogy nem lehet beilleszteni pl. KeePass-ban generált 25 karakteres jelszót, hanem be kell gépelni.
Naná, hogy így a lehető legegyszerűbb jelszava lesz mindenkinek...

Az online számlázáshoz külön regisztráció, felhasználónév, jelszó, XML kulcsok azért kellenek, hogy elméletileg más ne küldhessen be számlát és meg tudják különböztetni a cégenként/telephelyenként használt programokat.

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

De az ügyfélkapu már eleve védett jelszóval, ott lenne az API kulcs, azt be kéne másolni a számlázó programba, aztán az ügyfélkapun még külön engedélyezni lehetne, hogy melyik programok küldhetnek be számlát. Így hiába kerül ki az API kulcs (ha egyáltalán kikerül), ha nincs engedélyezve az adott program az ügyélkapun, akkor nem küldhet be számlát. Szóval felesleges így szerintem külön online számla fiók, ha már van ügyfélkapu.

Bonyolult dolgokat is le lehet egyszerűsíteni, csupán azzal, hogy olyan egyszerű lépések sorozatára bontod le (és megmutatod több valódi userednek, hogy oktatás nélkül mire vegy vele, mielőtt élesbe kiteszed), amit már lehet követni. Ehhez a felületet úgy alakítod ki, hogy az egyértelmű legyen, a súgó szövegeket nem kormányzati bikkfanyelven fogalmazod meg, hanem magyarul. Nem csinlsz olyat mint itt az online számla felületen, hogy egy fontos funkcióhoz az adószámodat tartalmazó narancssárga/piros? téglalapra kell kattintani, mert honnan a vakerből találnám ki, hogy az egy gomb? Olyat meg végképp nem csinálunk, hogy erre a gombra kattintva (amihez bejelentkeztem már!) elvisszük a usert az ügyfélkapura és úja bejelentkeztetjük, majd ügyesen visszairányítjuk egy olyan oldalra ami kísértetiesen hasonlít az első bejelentkezés előtti oldalra, csak most FELÜL az oldalon nem BELÉPÉS és REGISZTRÁCIÓ gombok vannak hanem egy belépve doboz és a szürke alapon szürke menü tartalma megváltozik. Alapvetően szerintem ez az api kulcs kérés tök egyszerű lett volna, de sikerült túlbonyolítani.

(Van ugye ügyfélkapu, meg cégkapu, meg most már onlineszámla accountom is, ahelyett, hogy lenne egy ügyfélkapum ahol vannak a privát dolgaim és a céges ügyeim, azon belül online számla, online pénztárgép, útnyilvántartás, bevallások stb. mondjuk cégenként csoportosítva, aztán minden kormányzati szolgáltatás ide oauthentikál, urambocsá még azt is láthatnám, hogy ehhez az accountomhoz ki mindenki fér hozzá és le is tilthatnám azokat akiket akarok, viselve ennek következményeit, dehát ez a űrtechnika)

--
openSUSE - KDE user

Igen, a legegyszerűbb egy hozzáférés lett volna, értelmes, színes gombokkal.
Nálunk senki sem olvas sem hibaüzenetet, sem súgószöveget, sem semmilyen doksit/leírást...

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

Kérte a számlázóprogramom a két XML kulcsot, meg is találtam ezt a két mezőt a NAV online számla fiókban, csak ugye az a fő felhasználóhoz tartozik, és ezt a két mező üres volt. Kerestem a generáló gombot, nem volt. Ezen a ponton muszáj volt kicsit beleolvasnom a súgóba, akkor derül ki, hogy létre kell hozni egy technikai felhasználót, aminek a fő felhasználóhoz képest lesz egy külön felhasználóneve, jelszava. Ugye a kettő felhasználónak (fő felhasználó és technikai felhasználó) nem szerencsés, ha ugyanaz a jelszava, szóval két jelszót kell alapból megjegyezni, de ugye a jelszókezelőt direkt tiltja az oldal, vagy legalábbis nehézzé teszi a használatát.

Szóval létrehozom a technikai felhasználót, de ha nem pipálom be a két jelölőnégyzetet, amivel megadom a megfelelő jogosultságokat a technikai felhasználónak, akkor nem fog működni.

Aztán a technikai felhasználóra kell váltani, és ott már ott lesz a két XML kulcs, amit be kell másolni a számlázó programba, de figyelni kell rá, hogy a számlázó programnak ne a fő felhasználó adatait adjuk meg, hanem a technikai felhasználó adatait.

Naszóval átlag felhasználó garantált, hogy ezt nem fogja tudni megcsinálni,és valamelyik ponton elakad. Túl bonyolult lett ez.

Szerintem egy átlag felhasználónak nem kell értenie ahhoz, hogy mit és hogyan kell csinálnia. Ha megfelelően intelligens akkor megnézi és megérti egy súgóból, ha nem, akkor megfizeti céget aki az IT rendszereit karbantartja.
Szüleim vállalkozásában bátyám simán kinézte egy súgóból a folyamatot és megcsinálta egymaga. Nekem csak annyit kellett segítenem, hogy az éles rendszer még visszautasítja a számlaadatok beküldését, regisztráljon a teszt rendszerben is. Az egyik ügyfelemnél viszont végig kellett őt vezetni a folyamaton.
Talán annyit lehetne egyszerűsíteni, hogy az api használata kulcs alapú azonosítással működhetne. Akkor meg a kulcspár generálásában kellene segíteni az átlag felhasználónak.

Igen, de nem mindenki informatikus. Annak is regisztrálnia kell, aki örül, ha el tud küldeni egy emailt. Én csak azt mondom, hogy nem hiszem, hogy ez az online számla regisztráció mindenkinek sikerülni fog, mert átlag felhasználóhoz képest túl bonyolult, és lehetett volna egyszerűbb.

Erről én is olvastam, bár nem sok infót találtam róla, akkor most a NAV fejlesztett egy teljes értékű online számlázó programot? Akkor így kinyírja a már meglévő számlázó programokat, vagy mi lesz? Bár egyáltalán nem biztos, hogy mindenki használja fogja, hacsak nem teszik kötelezővé...

Igen végülis konkurencia lett.
De megnéztem mit tud és mégse.
Csak egyszerű kimenő oldali számlákat tud, de abból is csak épp annyit, hogy egy kézi számlatömböt kiváltson.
Bár az online számlázóknak tuti konkurencia lesz...

pch
--
SB-soft online ügyviteli rendszer
--

Ez tuti nagy segítség lesz, egy perce teker az oldal és már be is töltött a page title a tab fülén az oldal meg üres.

update:
Most már megy, de inkább ne menne. :(
A tételeknél nem lehet kedvezményt jelölni, és konkrétan semmit sem ami kötelező. pl: közvetített szolgáltatás vagy adómentesség oka, stb...
A számla kerekítés mizériáját is rövidre zárták. Konkrétan nincs.
Hibás adószámot segítőkészen jelöli: "Hibás kitöltés" de hogy melyik adat hibás az nincs jelölve.

Én 3 számla után zártam be, ez még egy darabig biztos nem veszi el egy fejlesztő kenyerét sem.
Csak az furcsa, hogy gyakorlatilag nem lehet vele olyan számlát kiállítani ami megfelel a jogszabályoknak. Gondolok itt az olyan alapvető dolgokra mint pl. a tétel közvetített szolgáltatás-e , esetleg előleg tétel vagy az adómentességére amire ezt írja üzenetnek:
"A kiválasztott kód mellett szereplő adómentességi okot vagy az adó nélküli számlázásra okot adó egyéb körülményt szíveskedjék a megfelelő szöveggel a megjegyzésbe beírni! Kérjük figyeljen azok pontos feltüntetésére!"
MEGJEGYZÉSBE ???
Számla módosításánál pl nem dobja fel az előző tételeket és nekem kell megjelölni egy checkbox-al, hogy be lett-e már küldve. Honnan tudja azt a felhasználó, nem a programnak kelne tudnia mit csinált ?

Azért az valahol nagyon-nagy gáz, hogy a NAV sem képes olyan programot írni, ami megfelelne a saját szabályainak...
És most hagyjuk, hogy az azonnali adatbeküldésre alkalmas-e mert így szemre nem működik ez a funkció.
De az adatexport része biztosan kamu ,mert semmilyen olyan adatot nem kérdez meg, ami a termékdíjhoz vagy egyéb kötelező adatszolgáltatás alá eső adatokhoz kellene. Márpedig ha nem kérdezi meg, akkor adatot sem tud szolgáltatni róla. Ebben az esetben meg biztosan szabálytalan az adatexport, tehát számlázásra ALKALMATLAN a rendszer...

Eddig a kézi számlatömbbel bármit le lehetett számlázni. Ezzel meg nem lehet közvetített szolgáltatást, előleget meg még kitudja mit leszámlázni. Illetve lehet, csak a beküldött adat nem felel meg a törvényi előírásoknak ugyanis nincs rá felkészítve a felület.

Na már szerintük sem kezelnek mindent:

"Az Online Számlázó elsősorban a mikro és kisvállalkozások általános számlázási igényeinek felel meg. A számlázó programmal a következő számlákat nem lehet előállítani:

Áfacsoport által kiállított számla
Különbözet szerinti (árrés) adózás alá tartozó négyféle ügyletről kiállított számla
Gyűjtőszámla
Egyszerűsített adattartalmú számla
Meghatalmazotti (ideértve az önszámlázást is) keretében kiállított számla"

Ma délig jó volt. Azóta szinte minden PROCESSING

Kikészíti a cégeket az online számlázás:
https://index.hu/gazdasag/ado_es_koltsegvetes/2018/06/29/online_szamlaz…

A kisvállalkozások közül sok egész egyszerűen nem is foglalkozik a dologgal, a külföldi cégeknél pedig az okozhat nehézséget, hogy a komplex vállalatirányítási szisztémájukba kell beépíteniük az a NAV szoftverét, ami nem biztos, hogy illeszkedik az üzleti folyamataikba, ráadásul a rendszerük módosítását az anyacéggel is össze kell hangolniuk.

lehet én vagyok funkcionális analfabéta, de nekem nem egyértelmű, hogy az "adatszolgáltatásra kötelezett adózói regisztráció" során én most a szervezetet regisztrálom, vagy egy usert, akit majd később hozzárendelek egy/több céghez.

Meg kell adni egy usernevet, de el akarom kerülni, hogy ha "személyként" regisztrálok, akkor "BétaGammaMintaKft" legyek, mert ha más céghez is hozzárendelem magamat, akkor az "hülyén" néz ki. De az sem jó, ha GipszGábor névhez rendelem hozzá pl a könyvelőt.
Igazából ha végigmegyek a regisztráción, kiderül a végére az igazság, csak nem tudom azt sem, hogy 1 személy/adószám regisztrálhat-e többszörösen.

Aki már túl van rajta, megköszönném, segítene a fenti kérdéskörben.

--
"The only valid measurement of code quality: WTFs/min"

"Szombat délutántól megkezdi a hivatal az Online Számla rendszer éles indításának végső fázisát. Emiatt a rendszer 2018. június 30. napján 16:00-tól 24:00-ig nem lesz elérhető sem a teszt, sem az éles környezetben. A vasárnapi éles indulás előtt hétvégén is üzemel a NAV telefonos ügyfélszolgálata."

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

https://www.napi.hu/magyar_gazdasag/nagy_valtozas_jon_vasarnaptol_minde…

"A zökkenőmentes átállás érdekében azt kérte a Nemzeti Adó- és Vámhivataltól, hogy ha az adatok július 31-ig beérkeznek, akkor a hivatal az érintett vállalkozókkal szemben semmilyen szankciót ne alkalmazzon. Előfordulhat ugyanis, hogy egy vállalkozás nem áll készen július 1-én az adatszolgáltatásra annak ellenére, hogy megkezdte a felkészülést.

NAV: szombaton órákig nem lesz elérhető az online számlarendszer
A számlázó program működési problémáit nem értékelheti a vállalkozók terhére az adóhivatal, ez nemcsak az ügyfél-centrikussággal, de az online számla egyik fő céljával, az adminisztráció-csökkentéssel is ellentétes lenne. A NAV tehát július 31-ig nem bírságolja a mulasztást, ha a vállalkozás már regisztrált az Online Számla rendszerben és a számlaadatok az időszak végéig, utólag megérkeznek az adóhivatalhoz - jelentette ki Varga Mihály."

És természetesen a fejlesztőkre kenték ezt is, holott ők nem voltak kész. Mondom úgy, hogy lassan a v0.15 óta küldöm be a számlákat DONE-val, de mindezt úgy, hogy szinte csak az megy be ami nagyon fontos.
PL.: VTSZ még OWN-al is hibát ad, vagy a kedvezmény se jó. Illetve vegyes adótartalmú számláknál az összesítő nem jó a nav oldalon...
Szóval köszi..

pch
--
SB-soft online ügyviteli rendszer
--

> holott ők nem voltak kész

A legszebb az egeszben, hogy volt "felkeszulesi" idoszak tobb mint fel ev az adozok szamara.

A valosag ezzel szemben az, hogy mar amikor elesbe menne, is dugig van buggal.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azért ezzel vigyázzon mindenki...
"Ha egy vállalkozás számlázó programja július elsejétől még nem képes az új szabályok szerinti számlaadat-szolgáltatásra..."
Vagyis, akkor lehet méltányosságra számítani, ha a számlázó nem tudja. Nem tartom elképzelhetetlennek, hogy egy ellenőrzéskor ezt bizonyítani kell tudni.
Az már biztos (ott ültem, amikor mondták a vezetők), hogy jogkövető magatartásnak azt tekinti a NAV, ha a gazdasági társaság július 1. előtt regisztrált az éles rendszerbe, és érvényes szerződése van a számlázó programjait szállító vállalkozással a megoldásra, csak az nem készült el.
Vagyis, szerintem egy igazolás legalább kell a számlázót írótól, hogy igen, ő igazolja, hogy nem működött a megoldása eddig és eddig...

szamlazz.hu-val probalt mar valaki bekuldeni elesbe? mukodik? lassan ki kene tolnom par nagyobb szamlat...

"megszűnik a számlázó programok bejelentési kötelezettsége" erről lehet olvasni hivatalosat is?

mi olyan összetevő van a request signature-ben ami miatt délután 3 után INVALID_REQUEST_SIGNATURE hibát ad vissza? milliószor átnéztem már a kódom, de vagy nem látom a fától az erdőt vagy a hiba nem nálam van.
dátumok rendben vannak, időbélyegek pontosak, formátumok az előírtnak megfelelőek.

szerk: jaja. az időbélyegek rendben vannak csak a formátum nem. oh you idiot!

Kapott már valaki email értesítést a NAV-tól sikertelen adatszolgáltatás miatt?

(vagy csak én kapcsoltam be kíváncsiságból az ügyfél adatainál az "Email értesítést kérek sikertelen adatszolgáltatás esetén" opciót?)

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

Igen, én kaptam... így néz ki: (szenzitív részek XXX-elve)

noreply_onlineszamla@nav.gov.hu
8:20 (5 órája)
címzett: én

Tisztelt XXX KORL.FEL.TÁRS.!

Ezúton tájékoztatjuk, hogy az alábbi számláról küldött adatszolgáltatás befogadása sikertelen volt:

Tranzakció azonosító: 27ZO2VXXXXXX

Feldolgozva: 2018-07-09 08:20:46

A feldolgozás részleteinek megtekintéséhez kérjük jelentkezzen be az Online Számla Rendszer felületére:

https://onlineszamla.nav.gov.hu

Tisztelettel: Nemzeti Adó- és Vámhivatal

Ha a cégem nevében hosszú ő van az okozhat gondot a rendszernek? Ma küldtem volna az első éles számlát be és customerinfo mezőre hivatkozik, hogy nem jó és elutasítja.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Szerintem igen. Hiaba utf8 konvertalni kell html.

https://onlineszamla-test.nav.gov.hu/technikai_kerdesek_valaszok

II.17. kérdés: Az XML kitöltésénél használható-e ![CDATA[, hogy a rendszert ne akassza meg, ha a felhasználó speciális karaktert használna?
Az XML adat összeállítás szempontjából nem okoz problémát a CDATA használata, azonban a biztonságos hibamentes feldolgozás miatt javasoljuk a replace használatát az alábbi speciális karakterek esetén:


"&" => "& amp;"

"<" => "& lt;"

">" => "& gt;"

"'" =>  "& apos;"

"\"" => "& quot;"

A customerInfo az több adatot is tartalmaz, ezek közül csak az egyik a cégnév, ráadásul a vevőre vonatkozik, ott nem a saját cégnévvel lesz baja.
Javaslom nézd meg, hogy a beküldött xml megfelel-e a közzétett xsd-nek (pl. a Notepad++ is tartalmaz validátort, igaz külön kell telepíteni).
Az utf-8 "ő" betű nem okozhat hibát.
Árpi

Sziasztok, ti a kerekítési korrekciót hol tüntetitek fel? Elég megjegyzésben, nem? Az végül is nem egy tétel. Csak egy infó ami szerepel a számlán.

A volt munkahelyemről van szó, jelenleg 3 személyes cég, ebből 1 a főnökasszony aki eléggé nehezen érhető el.
Már több mint 8 éve fut a számlázójuk amit annó én írtam.
Most kevés pénzért meg jófejségből megcsinálom nekik. A kollégákkal nagyon jóban vagyok.

Szóval sajnos nincs rendesen üzleti oldal a cégben ahogy kéne, az infókat sok esetben nekünk kell összeszedni. Könyvelő van, nem tudom tud e segíteni, majd ráuszítom az egyik kollégát, hogy kérdezzen tőle.

> Tehát fel kéne vinni egy 2 Ft-os tételt 0% áfával vagy mi ?
Gondolom az 5 Ft-ra kerekítésre gondolsz. Másképp hogy jön neked ki 2 Ft kerekítés ?
Az 5 Ft ra kerekítés az szerintem nem része a számlának. Írom ezt úgy, hogy egyszer néztem meg az online számla xml-t és nem foglalkoztam vele. Tehát nem vagyok benne a témában.

5-ra kerekítesz, de a különbségről beszélek, egy 302 Ft-os számlánál 300 Ft lesz a végösszeg. Tehát 2 Ft-ot kéne jóváírni a számlán.

Az a lényeg, hogy a számlán van pl 3 tétel. Összeadva őket az eredmény 302 Ft

Van egy teljes fizetendő rész is amire már 300 Ft-ot írok.
Így a NAV látni fogja, hogy 2 Ft-os diffi van a tételek és a fizetendő között. A doksi szerint ezt nem fogja engedni mert csak 0.5Ft-os eltérést enged.
Hacsak nincs beleprogramozva nekik, hogy KP-s számlánál elnézi. Ezt persze max csak kipróbálni lehet. Lehet KP-ra engedi, utalásnál meg nem.

A számlán a tételek alatt úgy lett feltüntetve annó, hogy:

Számlaérték: 302,00 HUF
Áfa: 100 HUF (hasra csapva)
Kerekítés: -2 HUF
Fizetendő: 300 HUF

Tehát azt mondod, hogy a számlaérték az ami érdekli a NAV-ot? Végül is logikus, ez lényegében egyezik azzal amit te is írsz.

Nah, beszéltek a kollégák a könyvelővel. Ő azon az állásponton van, hogy a beküldendő xml-ben vegyünk fel egy kerekítés tételt aminek az értéke a fenti esetben bruttó 2 Ft. Ugyan a számlaérték más, de a fizetendő fontos, mert eltérés lesz a pénztárban ami a NAV-ot is érdekli.
Úgyhogy ennyi, így lesz. Ezt a döntést hozta az üzlet, nekem jó így.

Én csak developer vagyok, a felelősség nem az enyém. Ha megbaxák a céget, akkor majd a könyvelő viseli a következményeket.
Egyébként én is a áfa kulccsal érveltem, de igazából feltehetsz egy számlára "kedvezményt" 2 Ft-ról vagy plusz terhet 2 Ft-al, 27% áfával (vagyis az aktuálissal)

Az más kérdés, hogy a pdf-en nem tételként szerepel, hanem csak egy sorként a fizetendő felett.

Közben kipróbáltam a szamlazz.hu demo oldalát. Csináltam egy KP-s számlát 169Ft -ról. Nem kerekített meg semmi. Még csak rá se írta, hogy mennyi lenne a kerekített összeg.

Azt amúgy ki fogom próbálni, hogy a nav-nak be fogok küldeni egy KP-s számlát ahol a tételek összege 302 Ft de a fizetendő csak 300, és ugyanezt utalásossal is. Lehet, hogy a KP esetén tolerálni fogja a 2 Ft különbözetet. Bár nem valószínű, ha fel van tüntetve, hogy 0.5Ft az amit elnéznek.

Még egyszer: a számla nem pénztárbizonylat. A számla kiállításakor semmit nem tudsz a kiegyenlítés módjáról, nagyjából lényegtelen, hogy milyen fizetési módot írsz rá. Egy rakás esetben készpénzes fizetés szerepel rajta, aztán a pénztárnál benyögöd, hogy kártyával fizetnél. Akkor mi lesz? Átírják a számlát?

"egy KP-s számlát ahol a tételek összege 302 Ft de a fizetendő csak 300"
Ez a mostani xml nekem teljesen kimaradt, hál'Istennek már nem ügy-/számvitelezek, de elég fura lenne, ha ezt megengedné, főleg, mert ha 302 a vége, akkor annyi a fizetendő is, az egy más problémakör, hogy a forgalomban lévő fizetőeszközökből kifolyólag kerekíteni kell.
Vonatkozó NAV tájékoztató: http://nav.gov.hu/nav/archiv/hirek_sajto/hirek/kerekites_1_2.html

Azért nem véletlenül mondják, hogy előre jelezzed ha kártyával fizetsz és nem KP-val. Ha KP-val fizetsz, akkor megy a pénztárba, ha kártyával, akkor a számlára lesz ráutalva. Az egyik esetben SZERINTEM többlet, a másikban hiány lesz, nem lesz jól lekönyvelve. Ezt abból gondolom, mert párom is meséli mindig, hogy melóhelyén van, hogy valami kis adminisztrációt elszúrnak a pénztárban és máris hatalmas hiány keletkezik a könyvelésben, mikor a pénz megvan. Olyankor pedig meg kell oldani.
De ez csak a személyes véleményem. Én fejlesztő vagyok, nem könyvelő, nem adójogász.

A logikus az lenne ha a NAV-nak ha beküldöm a 302Ft-ot KP-s számlaként, akkor automatikusan tudná a rendszerük, hogy ott csak 300Ft fog beesni a kasszába.

Nem találtam sehol erre leírást, hogy ki miként oldotta meg. Én akér igazat adok neked is, de nem tudom megállapítani. Ha a saját cégemről lenne szó, akkor megkeresnék egy adószakértőt.

Itt jelen esetben majd eldönti a tulaj.

No, ha fejlesztő vagy: a számlázás, a pénztár és a fizikai fizetőeszköz három különböző típus, és addig jó, amíg egyik típusnak nem kell tudnia a másik esetleges anomáliáiról. Az, hogy hogyan kell kezelni az esetleges pénztárbeli eltérést a számlázás szerinti végeredménytől, az az üzleti logika dolga (amelyet a könyvelés osztályban implementál valaki, a megkapott _mindkét_ végösszeg alapján), nem a számlázás típusé.

érvényes a számla, ha a fizetési mód készpénz, de nem 0-ra vagy 5-re végződik. Nem kell kerekíteni a számla végösszegét, ha készpénzes. De nyilván a pénztárban kerekíteni kell, tehát 169 Ft értékű készpénzes számla helyes, de 170 Ft-ot kell érte fizetni készpénzben.
A fizetési mód nem kötelező eleme a számlának, ezért helyes a 169 Ft értékű készpénzes számla, mert az is lehet, hogy mégis inkább bankkártyával fizeti meg a vevő, és akkor ugye 169 Ft-ot fizet bankkártyával, vagy fizetheti készpénzben is 170 Ft-ot.

Ezt az infót honnan szedted ? Ezzel egy csapásra megoldódna minden kerekítési probléma. Mikor kipróbáltam a NAV számlázóját ott mindent 2 tizedesjegy pontossággal szerepelt. A számla végösszege, az áfa és a nettó összeg is. Ez is jó mert így sincs kerekítési probléma. De amikor a tételek 2 tizedesjeggyel vannak a végösszeg nettó és az áfa meg forintra kerekítve, az már problémás.

Mi is tizedeseket szerepeltettünk, de problémáink lettek a beküldéssel, mert hibát adott a NAV-os rendszer, akkor néztünk jobban utána.
Egész pontosan a jogszabály csak annyit ír elő, hogy a számlán szereplő áfa értékeket egész Ft-ra kell kerekíteni.
Így mi is áttértünk arra, hogy nem csak az ÁFA-kat, hanem a tétel összegeket is forintra kerekítjük.
Így dolgozik a szamlazz.hu is.

--
Ickenham template engine

> a jogszabály csak annyit ír elő, hogy a számlán szereplő áfa értékeket egész Ft-ra kell kerekíteni
Melyik jogszabály? Mindenki ezt mondja, de én még sosem láttam. Kezdek attól tartani, hogy ezt az egészet csak a könyvelők találták ki, mert ők nem tudják hova rakni a filléreket a számlák feldolgozásánál.

Arra meg, hogy a szamlazz.hu mit csinál csak azt tudom mondani, hogy a NAV hivatalos számlázója (ami egy vicc, de akkor is a NAV csinálta) a teszt időszakban 2 tizedesre kerekített mindent. Azt nem tudom, hogy most mit csinál, de gondolom nem váltogatják a kerekítési szabályaikat hetente.

Ezzel kapcsolatban egyszer voltam bent a NAV ügyfélszolgálatán. Átirányítottak egy másikhoz, utána megint egy másikhoz. Végül az lett belőle hogy írásbeli állásfoglalást kértem, amit 1 hónap múlva küldtek meg. Az alábbiakban leírom amit kihámoztam belőle. Ezt nem kell készpénznek venni, mert nem most kaptam az állásfoglalást, nem biztos hogy mindent jól értettem meg belőle. De kb. ez a helyzet:

* A számla tételeknél a mennyiségre és az egységárra nincs megkötés. Bármennyi tizedesjegyet kiírhatsz. De általában nem szoktak többet mint 2.
* Van egyszerűsített számla, amiben az árak bruttóban vannak feltüntetve. Vannak normál számlák, amiben nettóban.
* Normál számlánál a számla formai követelményeiben szerepel az, hogy tételenként föl kell tüntetni a nettó egységárat, a mennyiséget és a nettó értéket, ÁFA kulcsot. A követelmények között nem szerepel a tételenkénti ÁFA érték és bruttó érték feltüntetése. Bár ezeket rá szokták írni. De mivel nem követelmény a megjelenítése, ezért nyugodtan veheted úgy, hogy az csak egy tájékoztató jellegű adat, amiből semmit nem kell kiszámolni.
* Az egyszerűsített számláról nem tudok nyilatkozni, olyat én nem csinálok, és annak nem néztem nagyon utána. De az a sejtésem, hogy mivel ott a formai követelményben a bruttó árak feltüntetése a kötelező, ezért ott a végösszeg számítását a bruttó összegből kiindulva kell elvégezni, és nem a nettóból.
* Az egységárat nem kell kifizetni. A tételenkénti nettó értéket sem. Ezért ezek lehetnek tört számok. Tételenként nem kötelező kerekíteni. Ugyanakkor nincs megtiltva sem.
* A kerekítési szabályok nincsenek konkrét törvénybe foglalva. Ellenőrzés során a revizor dönti el, hogy jól csináltad-e vagy nem. Nem valószínű, hogy 1 forint eltérés miatt bárki bármit is szólna.

Van egy túlhatározott feltételrendszer, az alábbiak szerint:

- egységár * mennyiség = nettó érték (tételnél)
- nettó értékek összege = számla nettó összege
- áfa kulcsonként csoportosítva a nettó értékek összege = a számla nettó összege
- nettó érték kulcsonként csoportosítva * áfa kulcs = áfa érték arra a csoportra
- áfa csoportok értékeinek összege = számla végösszegének áfa tartalma
- nettó végösszeg + áfa tartalom = bruttó végösszeg

Ezen felül még lehetne sorolni... A fenti műveletek nagy részében elkerülhetetlen a kerekítés, mert a konkrétan fizetendő dolgokat csak törvényes fizetőeszközben lehet feltüntetni, és a fillér az nem törvényes. A fenti feltételrendszer azért túlhatározott, mert ha van kerekítés (márpedig az van), akkor nem lehet az összes elvárásnak egyszerre megfelelni. A törvény konkrétan nem írja le azt, hogy hol kell kerekíteni, mit kell kerekíteni, és milyen sorrendben kell számítani a dolgokat. Viszont arra is van törvény, hogy amire nincs törvény, azt nem kérhetik rajtad számon.

Én az alábbi számítást követem:

- a tételek nettó értéke = mennyiség * egységár. Itt egész forintra kerekítek. A tökéletes megtámadhatatlan megoldás az lenne, ha itt egyáltalán nem kerekítenél. Ennek kivitelezése cég függő - ha sódert árulsz és két darab 2 tizedes jegyes számot szorzol össze, akkor a tétel nettó értéke 4 tizedes jegyes lehet, ami hülyén néz ki egy számlán. De ha pl. bútort árulsz, és nem lehet belőle fél darabot venni, akkor nincs ilyen probléma. Az egészre kerekítés miatt az utóbbi 10 évben még soha senki nem büntetett, pedig túl vagyunk néhány ellenőrzésen.

- ezután áfa kulcsonként csoportosítom a tételeket, és a tétel nettó értékeket összegzem. Itt kerekítési hibának nincs helye.
- ezután ezekből az ÁFA kulccsal számítom ki az ÁFA értéket, külön minden ÁFA kulcs csoportra. Itt is egészre kerekítek.
- ezután ezekből bruttó = nettó + áfa módon számítom a bruttó értékeket minden csoportra. Ebből származnak a bruttó értékek áfa kulcsonként
- a számla nettó végösszege, áfa tartalma és bruttó végösszege a csoportonkénti összegek összege

Ez a legutolsó számítás például simán azt eredményezi néha, hogy a számla végösszegére nem igaz a nettó * áfakulcs = bruttó képlet. Még kerekítéssel sem. Néha 2-3 forint eltérés is lesz.

Devizás számlánál még kacifántosabb a helyzet. Ott tételenként devizában számolsz. ÁFA kulcsonként is devizában. A végösszegnél a végén kijöntt devizás ÁFA értéket váltod át forintra, kerekíted, és azt írod rá. (Az ÁFA-t kötelező forintban kiírni akkor is, ha devizás a számla. Sőt akkor az árfolyamot is kötelező.)

Amikor tizenvalahány éve bejött az első nyomda ügyfelünk, ahol 5 tizedes pontosságú egységárak voltak és százezres nagyságrendű mennyiségek, akkor egyszer megcsináltuk normálisan ezeknek a kezelését. Ez azt jelentette, hogy pénznemenként külön-külön be lehet állítani a következőket:

Legkisebb egység: Az adott pénznemben használható legkisebb egység, HUF esetén 0.01
Legkisebb fizetési egység: A bizonylatok végösszege erre lesz kerekítve, HUF esetén 1.00
Legkisebb készpénz egység: KP fizetési módhoz beállíthatja, hogy a számlán a fizetendőt erre kerekítve is tüntesse fel pluszban a végösszegen felül, HUF esetén 5.00
Nyomtatási egység: A bizonylatok tételsorainak összege erre lesz kerekítve, HUF esetén 0.01
Legkisebb egységár egysége: Az egységár kerekítése, HUF esetén 0.01000

Ezeknek a megfelelő beállításával a rendszer bármelyik fajta kerekítési működést tudja kezelni, akár egységár, akár tételsor, akár bizonylat szinten, szóval tényleg csak a felhasználón múlik, hogy hogyan szeretné :) Ezen felül be lehet állítani, hogy feltüntesse-e a pénzügyi korrekció mértékét.
ÁFA számolásilag a tételek nettó összértéke alapján számoljuk ki az ÁFA összegét, majd az ÁFA összegét kerekítjük, és az így kapott kerek összeg alapján állítjuk be a szükséges pénzügyi korrekció mértékét és jön ki a nettó-áfa-bruttó szentháromság olyan módon, hogy matematikailag garantáltan stimmel :)

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

MNB-SZEMLE • 2009. JÚLIUS

https://www.mnb.hu/letoltes/leszko.pdf

"4 A Magyar Nemzeti Bank a 2 és 5 filléres érméket 1992. szeptember 30-i, a 10 és 20 filléres érméket 1996. október 1-jei, az 50 filléres érméket pedig 1999. október 1-jei
határnappal vonta be a forgalomból [2/1992. (MK 30.), 2/1996. (MK 22) és 1/1999. (MK 23.) MNB hirdetmény]. A filléres érmék bevonása nem érintette a fillér mint elszámolási
egység létét: a 9000/1946. (VII. 28.) ME rendelet – amely kimondja, hogy a magyar törvényes pénznem a forint, valamint azt, hogy a forint 100 fillérre oszlik
– nem került módosításra, így továbbra is megmaradt a fillérrel történõ kalkulálás lehetõsége."

9000/1946. (VII. 28.) ME rendelet
a forintérték megállapitásáról és az ezzel összefüggő rendelkezésekről
http://net.jogtar.hu/jogszabaly?docid=94609000.MEC

"(2) A forint 100 fillérre oszlik."

Azt hiszem itt most összekevertem dolgokat.
Eddig mi is két tizedesre kerekítettünk, de egy számla kapcsán felmerült a megbízó részéről, hogy jobb volna egészre kerekíteni.
Tehát nem az online számla kapcsán, hanem a számlázót használó ügyfél kapcsán merült fel.
Mondtuk, hogy rendben, de kérjenek a NAV-tól állásfoglalást.
Pontosan nem tudom, hogy mi lett a vége, délután tudok majd bővebbet írni.

Utánanéztem a jogszabályban, és az valóban nem ír elő kerekítést ilyen esetben.

--
Ickenham template engine

Közben megnéztem a szamlazz.hu -n még egyszer, ott van lehetőség a navos xml letöltésére is. Abban is csak a 169-et küldi be.
Viszont érdekes, mert nem egyezik szerintem azzal amit nemrég letöltöttem a nav példából. Lehet még régi verzió van kint náluk a demo alatt. Szóval ez se lehet teljes kiindulási alap.

Feldobtam a labdát még egyszer a kollégáknak. Majd eldöntik ők a főnökkel karöltve.

Hátha valaki tudja a választ erre a kérdésre. A NAV -nak írtam már kb. 2 hete nem válaszolnak. Lejelentettem egy számlát. Ezután le akartam jelenteni a sztornóját, és hibát kaptam.

Konkrétumok:

* Az eredeti számlábanInvoiceNumber element-ben "2018-GH-000530" érték lett megadva. Ez az eredeti számla sorszáma.
* A stornóban erre a következő módon hivatkoztam:


<data:invoiceReference><data:originalInvoiceNumber>2018-GH-000530</data:originalInvoiceNumber>< data:modificationIssueDate>2018-07-08</data:modificationIssueDate><data:modificationTimestamp>2018-07-08T09:38:34.124Z</data:modificationTimestamp><data:modifyWithoutMaster>false</data:modifyWithoutMaster></data:invoiceReference>

A stornó számlának és az eredetinek is egyetlen egy tétele volt. A stornóban a számla sorban szerepelt a lineModificationReference elem is az alábbiak szerint:

<data:lineModificationReference><data:lineNumberReference>1</data:lineNumberReference><data:lineOperation>MODIFY</data:lineOperation></data:lineModificationReference>

A szerver válasza INVALID_INVOICE_REFERENCE - A módosítás vagy érvénytelenítés olyan okiratra hivatkozik, amire vonatkozóan nem történt adatszolgáltatás.

Amennyire én látom, az eredeti számla be lett küldve, a stornó számla a megfelelő sorszámra hivatkozik, és a számla sorok is tartalmazzák a hivatkozásokat a módosított számla sorokra. Mégis azt a hibát kapom, hogy az eredeti számlára nem történt adatszolgáltatás.

Ha valaki küldött már be stornó számlát, akkor nagyon hálás lennék ha megmondná, hogy mit rontottam el.

Nemsokára itt a július vége, és a NAV-tól még nem kaptam választ. :-(

Köszönöm!

Ha "ABORTED" lett az eredeti számla státusza, akkor az nem számít adatszolgáltatásnak, tehát nem tudod úgy beküldeni,ahogy próbáltad, nem lehet a "modifyWithoutMaster" érték false. Esetleg ez is lehet gond.

Egyébként nekem teszt rendszerben volt,hogy egy módosító számlát nem bírtam beküldeni és ugyanez az üzenet jött vissza,mint nálad, pedig a "modifyWithoutMaster"-nál true volt az érték, azaz az eredeti számlával nem is kellett volna foglalkoznia. Próbából megnöveltem a számlaszámot (invoiceData/invoiceNumber) eggyel és minden mást ugyanúgy hagyva beküldtem újra, azt meg már elfogadta gond nélkül. Mivel a teszt környezetben volt így nem foglalkoztam vele bővebben, de azért érdekes.

(Ha gondolod dobd át nekem is mindkét számlát, hátha látok valamit)

Ha az eredeti számlát már sikerült beküldeni, meg kell várni, amíg a NAV feldolgozza, (te pedig le is kérdezed) addig nem tudod beküldeni a Storno-t hozzá, mert addig nem találja az eredeti számla számát.
Ha az eredeti számla státusza lekérdezett, akkor utána újból be kell küldeni a Storno számla készítésekor keletkezett XML-t, és akkor máris helyreáll a dolog.
Érdemes minden alkalommal a storno előtt megvárni, amíg a NAV jól feldolgozza az eredeti számlát, majd csak a feldolgozás és lekérdezés után szabad stornozni!!!
Azaz nem szabad kapkodni, ha eltoltál valamit a számlán; már úgyis mindegy, ha egyszer bekerült a NAV-hoz...

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

Köszi, egy kicsit nekem is hasznos volt a hozzászólásod, éreztem, hogy rá kell néznem amikor a storno-ig eljutok.

Elsőnek az volt a baj, hogy panaszkodott a tétel referencia hiányára. Kissé marhaságnak érzem, de azért ezt még meg is értem, mondjam meg, hogy az adott tétel a régi számláról melyik tételt sztornózza. Oké. De utána is panaszkodott, hogy nem teljes az adat. Igen, láttam a doksiban, hogy a lineOperation egy kötelező elem, de nem értettem. Vagy CREATE vagy MODIFY lehet az értéke.
Ez szerintem nem logikus. Hisz nem az eredeti számlát módosítom, hanem készítek belőle egy mínuszosat. Főleg, hogy van olyan rész ahol lehet az adatszolgáltatás requestet utólag módosítani (ha informatikai para történt).

Nah mind1, nálam is zöld már a storno, éljen... Még meg kell csinálnom az ejrós és usd-s számlákat és kész is vagyok heh...

Igen, láttam a doksiban, hogy a lineOperation egy kötelező elem, de nem értettem. Vagy CREATE vagy MODIFY lehet az értéke. Ez szerintem nem logikus. Hisz nem az eredeti számlát módosítom, hanem készítek belőle egy mínuszosat.

Ha nem az eredeti számla sorát módosítod, hanem egy új sort adsz hozzá, ami módosítja az eredeti számlát akkor ilyen esetekben oda CREATE kell nem MODIFY.
Ha pl. van egy 4 db csavart tartalmazó sor a számlán és a módosítódon lesz egy -4db csavaros sor és egy 1 db csavaros sor, akkor mind a kettő CREATE-es.

Javaslom tanulmányozásra az Online számla interfész specifikáció doksit (innen letölthető), különös tekintettel a "Adatszolgáltatás számla érvénytelenítéséről", "Adatszolgáltatás számla módosításáról", "Módosuló adatok a tételsorokban" és "Értelmezést segítő példák" fejezeteket.
--
Ickenham template engine

"lineModificationReference elemet kizárólag módosításról történő adatszolgáltatás esetén lehet és
kell szerepeltetni. Ha a lineOperation elem értéke „CREATE”, akkor a lineNumberReference elem az
eredeti számla és az összes korábbi módosítás eredményeként előálló sorszámozás folytatása. Ha a
lineOperation elem értéke „MODIFY”, akkor a lineNumberReference elem azon eredeti számlán
szereplő tétel sorszámát (lineNumber), vagy korábbi módosító okiraton létrehozott új tétel sorszámát
(a korábbi módosító okiraton lineNumberReference) tartalmazza, amire a módosítás vonatkozik."

Ha neked ennyire logikus, el tudod magyarázni, hogy storno esetében miért sorszámozás folytatásról beszélünk ha egyszer az adott tétel a régi számla tételéhez kapcsolódik?

Megnéztem közben az egyik példa pdf-üket meg a hozzátartozó xml-t.
Az alapján valóban a CREATE-t várhatja és azt, hogy a lineNumberReference ne mutasson sehova hanem egy új értéket vegyen fel mint create.

Tehát ebben lehet igazad van, illetve ezt nem is vitatom, inkább azt, hogy ez marhára nem értelmes megoldás. Milyen esetben kell akkor MODIFY STORNO számlánál?

De a tételnél kell megmondani, hogy create vagy modify :)
Tehát egyszer megmondtam már, hogy ez egy STORNO számla, utána ha akarom, egyik tétel modify, a másik create.
A leírás alapján a modify egy adott tételre vonatkozik és azt módosítja. A másik esetben a create-nél pedig folytatja a tétel sorszámozást, tehát elvileg hozzáfűzi.

Az a helyzet hogy amiket szinte mindenki kérdez, azok üzleti szabályok és constraint-ek. A NAV dokumentációjában meg van egy copy/paste formális leírás (amit tök fölösleges volt betördelve berakni egy pdf-be, mert nincs élő ember aki ezt így használni tudná). Ami ezen felül van az a jogszabály szövege. A kettő között meg van egy óriási szakadék, mert se a formális szintaktikai leíráshoz nincs szemantikai/értelmezési rész, se a jogszabályhoz. Inkább ilyeneket kellett volna beleírni, nem teleb@*#*szni XML sémákkal. (Ez egyébként minden más kormányzati rendszer doksijában így van, és semmi értelme.) Ha pedig kérdezel valamit ami értelmezésre vonatkozik, akkor általában vagy egy szintaxissal válaszolnak, vagy egy jogszabály hivatkozással. Szerintem az a fő gond hogy nincsenek ott kompetens supportosok, akik fejből vágják hogy mit hogy kellene értelmezni.

Van valakinek tapasztalata termékdíjas ügyben?

A számlán van 6 tétel, amiből 5 tételhez tartozik 5 csomagoló doboz, 1 tételhez semmi, de az egész fel van rakva 1 raklapra. Az előírásoknak megfelelően ezek mind fel is vannak tüntetve a számlán, de az online izébe nem tudom normálisan berakni. Úgy tűnik, hogy ha egy tételnél az obligatedForProductFee == true, akkor mindegyiknél az kell legyen, így a 6. tételhez is kellene valamit tenni, ami nincs csomagolva. A raklapot meg hova kell tenni? Ha nincs sehol, csak az összesítőben, akkor azért sírdogál, hogy eltérés van, ha szétosztom a 6 tételre, akkor meg a 0.166667 DARAB raklap lesz elég fura.

Kap valaki választ ha a nav-inites email címre ír?

Pár perccel ezelőtt jött válasz egy július 2-án küldött kérdésre... Egy bő hónappal ezelőtt még releváns is lett volna a válasz, de ennyi idő elteltével már teljesen feleslegesen pazarolták az erőforrásaikat a válasz megírásába...

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

Sziasztok!

A queryInvoiceData operáció csak a DONE státuszú számlákat adja vissza?
Tehát ha visszaadja a számlát, akkor azt a számlát a NAV rendben befogadta és a számlával minden rendben van? Nem fordulhat elő elviekben, hogy ad vissza találatot és a számlával mégis van valami galiba?

Sziasztok! Aki a teszt interfészen szeretné kipróbálni a jóváíró-módosító logikát az figyeljen arra, hogy a "ModifyWithoutMaster" értéke true legyen! További szép és eredményekkel teli napot kívánok mindenkinek!

Már nem tudom, én mikor csináltam meg a módosító számlák beküldését, de nekem semmi ilyen problémám nem volt, és a jelzett attributumot megfelelően be kellett állítani. (Bár csak olyan számlával tudtam tesztelni, ami be lett küldve, így az értéke mindig "false" volt...)

Eksön lesz megint:
https://www.rsm.hu/blog/2019/03/nav-online-szamla-egybol-a-kettore

A lényeg:

  • 2019. áprilisában várható a 2.0 online számla verzió tervezetének publikálása
  • A 2.0. online számla tervezetet egy hónapig lehet majd véleményezni
  • 2019. július elején teszik közzé a 2.0. online számla végleges formáját
  • 2020. január elején, mintegy hat hónapnyi felkészülési időt követően élesedik az új formában az adatszolgáltatás, adatfogadás.

--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

Köszi, ezt jó tudni.

Az online számla adatszolgáltatás elindulásától 2019 márciusáig beérkezett, közel 34 millió adatszolgáltatásból majd 16 millió feldolgozhatatlan volt az adóhatóság szerint. Vagyis majdnem minden második adatszolgáltatás hibás volt, részben vagy teljesen alkalmatlan a további felhasználásra. - ezen azért elgondolkodnék a a tervezők helyében...

Hogy a "népszerű" riporter hölgyet idézzem: és ezt így hogy?

Készítek egy API-t, ellenőrzök minden beérkező adatot, és mégis a fele használhatatlan...?

szerk: ja hogy az nem egy aláírás a komment végén! :D
És ezzel egyébként pénzügyi szempontból mi a gond? A NAV-nak nem "csak" az összegek a fontosak?

Valaki tudna adni egy linket, ahol pontosan le van írva hogy, az egyes interfészverziók mikor kerülnek bevezetésre illetve kivezetésre az éles rendszerben?

Jelenleg használható párhuzamosan az 1.0 és az 1.1-is:

Az 1.0 április 30-án használható utoljára és május 1-től már csak az 1.1-el lehet adatot szolgáltatni?

Más is tapasztal olyat, hogy a SSL/TLS csatorna kiépítése nem működik?
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

TLS 1.2 interfész (API) átállás befejezve (2019-04-29 12:15)

Tájékoztatjuk, hogy az Online Számla éles környezet interfészének (API) TLS 1.2 átállása befejeződött. Az átállást követően az api.onlineszamla.nav.gov.hu, kizárólag TLS 1.2-es verzióval érhető el.

Részletek: https://onlineszamla.nav.gov.hu/

Én is benyaltam a tls1.2 re váltást. Konkrétan a régebbi windowsos Qt rendszerem nem támogatja a protokollt. Az újabbakon meg nincs támogatva a WebView ezért nem szeretem őket, de ettől függetlenül ott is letérdel az SSL handshake.
Úgyhogy most én is boldog vagyok :-)
Hihetetlen hogy ezzel a hülye nav interfésszel állandóan cumizni kell valamit...

Az a bajom vele, hogy windows-ra nem elérhető csak Visual Studióval. A legújabb verziókban már a mingwin LGPL -es környezethez nem elérhető/nem támogatott.
Én meg pont azt használtam/használnám.
Valahol valami olyasmit olvastam, hogy a WebEngine a Chrome kódbázisára épül aminek a kódjaiban valami Visual Studió specifikus kód van, bár ezt kicsit furcsállom, mivel linuxra is van Chromium.
De ha valaki tud olyan módszert amivel viszonylag fájdalommentesen a mingwin alapú Qt hez hozzá lehet heggeszteni a WebEngine-t annak örülnék, de én nem találtam.

Szerk:
Megtaláltam, itt írják:
https://doc.qt.io/qt-5/qtwebengine-platform-notes.html
"On Windows, Visual Studio 2017 and Windows 10 SDK are required."

Ha esetleg még valaki nem lenne kész az 1.1-re való átállással, akkor most már ne kapkodjon, csúszik egy hónapot az új verzió kötelező használata:

A Nemzeti Adó-és Vámhivatal 2019. január végén publikálta a számlák adatszolgáltatásához kapcsolódó új verziót, az 1.1-es specifikációt és XSD sémát, melyet eredeti tervek szerint 2019. május 2-án tett volna kötelezővé. A határidő közeledtével azonban számos, az átállásra való felkészülési folyamat elhúzódását jelző ügyféli jelzés érkezett, melyet figyelembe véve az adóhivatal egy hónap haladékot biztosít. 2019. június 4-én 0:00 órától már csak az új formátumban fogadja a számlák adatait az adóhivatal, 1.0 verzióval érvényes adatszolgáltatás már nem teljesíthető.

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

tegnap délután óta folyamatosan timeout-ol a live api 10-20 percekre. a hivatalos oldalon nincs kint semmilyen infó, bár ez nem meglepő, mert általában csak utólag szokták kirakni a problémákat.
ti is tapasztaltátok esetleg a kimaradásokat?

Ma megjött a végleges 2.0-ás verzió. Elvileg innentől számítva fél évünk van felkészülni a január 1-i indulásig. Ha valakinek kijön a matek, akkor ossza meg, nekem sehogy sem sikerült.

?? butaság:
a navnak az a célja, hogy minél több pénzt begyűjtsön. "sok kicsi sokra megy"; hidd el, hogy pont azért csinál ilyen online rendszert, hogy a kicsiktől is legyen módja beszedni..
A változtatások sora pedig azért szükségszerű, mert gondolom ők is rájönnek a saját elkövetett hibáikra, pl:
- fölösleges / nem begyűjtött (rész) információ
- átalakított belső folyamat
- stbstbstb.

hint: a fentiek csak lövések a sötétbe, de multiknál is előfordul, hogy 2-3 hónap alatt k*180°-ot fordulnak a saját igényeikkel.. most egy hivatal mivel lenne jobb :D .. esetenként hasonló méretű bürökrácia-szervezettel a tetején..

ohh hat hogyne mar. Egy kollega anno elvitte a kabelt az LDAP es a router kozul mert szep szines volt be is szakadt anno az internet fel magyarorszagon mivel a mi usereink szepen alltak emiatt sorban az akkor meg MATAV core auth routere elott ami a DSL loginokat dobalta a szolgaltatok fele ha visszakapta ,hogy oke akkor mehettek pornot nezni :D. Mivel ez nem tortent meg a 6xxx cisco szepen leterdelt magaval rantva az osszes DSL szolgaltatot...

Mondjuk ezt jo volt anno elesben nezni masodmagammal mert mindenre gondoltunk csak arra nem ,hogy fizikailag hianyzik az osszekottetes :D

> A változtatások sora pedig azért szükségszerű,

Most kapaszkodj meg:) Lehet am olyat is, hogy kiadsz valamit, majd 2 evig nem modositod, addig atgondolod, hogyan kellene jobban.
Majd 2 ev mulva kiadod a kovetkezot, ami tarzalmazza a 2 ev tapasztalatait. Es ahhoz 2 evig megint nem nyulsz.

Vagy lehet azt is, hogy naponta uj verziot adsz ki, kb. minden git commitrol, mert az a trendy.

Egy folyamatosan valtozo kod, vesszofutas
mindenki mas reszerol, hogy a te szerencsetlenkedesedet napi szinten lekovesse.

Ez neked baromi kenyelmes, mert nem kell atgondolni, rakeszulni, hanem csak tolod ki a lyukon. Akinek meg nincs eleg eroforrasa, az meg lemorzsolodik.
Igy a vegen, ha ezt is netalantan einstandolni kene, sokkal.egyszerubb 10 piaci szereplot, mint 1000-et.

Csak az nem lat ebbe szandekossagot, aki nem akar...

Mondjuk egy olyan orszagban ahol uaz. a torveny ev kozben tobbszor modosul.... Ahelyett, hogy mondananak valamit, es ahhoz tartanak.magukat 4-5 evig. Sokkal kiszamithatobb torvenyi kornyezet lenne.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"A 2.0-ás interfész kötelező átállásának határideje ennek megfelelően 2020 első negyedévére módosul annak érdekében, hogy az átálláshoz szükséges felkészülési és tesztelési idő kliens oldalon biztosítva legyen." forrás
szóval nem január 1, felesleges uszítani az embereket :)

+1 kifejezetten előremutatónak tűnik az első körös (még nem online) formátum és jelentés-tartalom háborúk után, hogy végső soron akár 1-1 konkrét dologról githubon is lehet diskurzust folytatni..
[off]
főleg ha ha időben odajut az ember és nem a kretén megrendelő határidő után beeső igényére kell valamit szuszakolni :)..
[/off]

Van egyszer a kommunikáció => ehhez vannak megoldások a neten és a NAV is ad tippeket.
Aztán van maga az XML ami a számla, na ezt mindenki saját magának készíti el, ugyanis ennél nem az a kaland, hogy legyen egy XML output, hanem az, hogy legyen törvényeknek és az alkalmazásnak megfelelő output. Vélelmezem kevés olyan számlázó van ami minden szakág minden területén használható. Egy-egy iparág specifikus biztosan nem ilyen.

Tegnap estétől már a 2.1 a "Jelenlegi funkcionális verzió", jelentsen ez bármit is :)

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

A v2.0-ban már kötelezően kitöltendők a "software" tagben lévő adatok megadása. Ott van egy olyan rész, hogy "softwareID". Van valakinek sejtése arról, hogy ez mi lehet? A dokumentációkból számomra csak annyi derül ki, hogy egy 18 karakter hosszú string.
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

SHA3-512 algoritmust sikerült már valakinek implementálnia? Rákerestem már meglévő megoldásokra (CodeProject, www.java2s.com, csharp.hotexamples.com), de azok VAGY a 4.7-es .Net frameworkért cirkuszolnak és tele vannak mindenféle felesleges override sealed class readonly baromsággal, VAGY megközelítőleg sem adják vissza azokat az eredményeket mint ez:
https://emn178.github.io/online-tools/sha3_512.html

Ha esetleg valakinek a szakmai erkölcsi érzéseit megsértettem volna, akkor remélem még időben közlöm, hogy nem a copy+pésztelhető class-t várom amit nekem már csak példányosítanom kell és meghívni benne a "ComputeHash" metódust.
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

Szerkesztve: 2019. 11. 13., sze – 13:57

Ezen írás szerint a NAV 2020. júliustól tervezi megszüntetni a 100e Ft-os áfahatárt.

Az biztos(nak tűnik), hogy a magánszemély adatait nem lesz szabad beküldeni, ezért valószínűsítem, hogy lesz majd egy speciális partner egy hozzá tartozó kamu adószámmal amit elfogad az interface, és az összes magánszemélynek kiállított számlát ilyen módon anonimizálva kell majd beküldeni. 

De mintha úgy olvastam volna, hogy január 1-től csak az adatszolgáltatási értékhatár megy le 0-ra, a magánszemélyes dolog majd csak július 1-től lesz.

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

Addig még a jogszabályi környezetet is módosíthatják (és kell is), hogy a magánszemélyek számláit is be kelljen küldeni.

Beszéltek róla, hogy a változtatás miatt 3.0-ás apira is szükség lesz, mivel az adatküldéskor jelezni kell majd valahogy, hogy magánszemély vagy sem.

https://github.com/nav-gov-hu/Online-Invoice/issues/85#issuecomment-553347348

Query invoice check request másnál is dobott 503-as hibakódot? Csak mert a dokumentációnak megfelelően nálam a password hash SHA 512-vel történik, a request signature pedig SHA3 512-vel aminek a bemenete a RequestID + Timestamp + XMLKEY.

NAV-nak már kétszer írtam, semmi válasz, és kijött egy segédprogram most kilencedikén, ezt is próbáltam már segítségre használni, de nálam ez a program el se indul, és olyan nem lekezelt kivételeket dob olyan egyszerű dolgoknál is mint pl egy nyomoroc mappa kiválasztása.

> Tehát, ha az egészségügyben a bérek nem csökkentek, az a fent említettekhez képest relatív béremelés.

KV miatt kicsit kitolódik a 2.0-ra átállás kötelezősége és április 1. után is használható marad a 1.1 API: forrás

No, kinek mi a tapasztalata az első szigorúbb napon? Nekem máris nem fogad el egy brit adószámot, az jön vissza a navtól, hogy a partner adószáma érvénytelen. Holott természetesen nem, a partner adószáma érvényes. Vagy közösségen belüli számlát be sem kéne küldeni? Mi ezzel a helyzet? Nem szeretnék az első nap egyből kapni egy félmilliós bírságot :D

Szeptemberig türelem van, nem fogsz kapni :-)

Nekem ellenben az a furcsa élményem támadt, hogy a NAV saját rendszere által kiállított e-számla *szerintem* bitangul nincs elektronikusan aláírva.

Jav: most Acrobat-tal is megnézve, alá van írva, de legalább nem megbízható tanúsítványként tekint rá a céges rendszerben :-)

(Jó ez a GOVCA, de lassan időszerű lenne legalább az elterjedtebb szoftverekhez valahogy eljuttatni így sok év után a hírét a létezésének.)

Szeptemberig türelem van, nem fogsz kapni :-)

Szeptemberig olyan türelem van, hogy ha nem regisztráltad magad és nem is állítottál még ki számlát a mai napon és a mai naptól, akkor nem büntetnek.

De ha számlát állítottál ki és még nem regisztráltad magad és ez kiderül, akkor bizony jönnek és ledobják eléd a szappant.

Aláírják, de nem kell meglepődni, ha olyat kapsz ami nincs aláírva:

https://www.nav.gov.hu/nav/ado/afa/Az_elektronikus_szaml20200416.html?query=%22elektronikus+sz%C3%A1mla%22

Mivel az Áfa tv. felsorolása nem taxatív, megfelelőek lehetnek azoktól eltérő, az eredet hitelességét és az adattartalom sértetlenségét biztosító megoldások is,  így például az, ami a digitális archiválás szabályairól szóló 1/2018. (VI. 29.) ITM rendelet (továbbiakban: ITM rendelet) 7. §-ában szerepel. E megoldás alkalmazásának feltétele, hogy a számlakibocsátó adóalany az online számlaadat-szolgáltatása során az Online Számla rendszerbe továbbítsa az elektronikus számla hash kódját. Ebben az esetben az adatszolgáltatást és az elektronikus számla dokumentumot (például PDF állományt) azonos időpontban szükséges létrehozni, és a számlaadat-szolgáltatásban a PDF állomány hash kódja szerepeltetendő. Fontos követelmény, hogy az adatszolgáltatás a NAV által befogadott (feldolgozott) legyen, valamint, hogy az elektronikus számla dokumentum és a hash kód együttes megőrzése valósuljon meg. Ha a NAV által befogadott (feldolgozott) online számlaadat-szolgáltatásban megfelelő hash kód szerepelt, akkor ezt a megoldást a számlakibocsátó és a számlabefogadó is alkalmazhatja

Erre utaltam egy másik topicban, hogy ha jövőre már tényleg (majdnem) minden számlának szerepelnie kell az adatszolgáltatásban, akkor végre meg lehetne csinálni rendesen, hogy befogadói oldalon is automatizálva lehessen ellenőrizni az e-számlák hitelességét, ne kelljen hozzá egy Windows+Adobe reader+Gizike. Mondjuk szerintem ennek az elterjedése elég alaposan fel fogja kavarni az elektronikus aláírás + időbélyeg szolgáltatók piacát, hiszen ha elég a NAV-hoz beküldött hash, akkor miért venne drága pénzért időbélyeget és aláírást...

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

Van jopar kliens bugjuk amikkel mikor meguntam egyutt elni(szoltam, nem foglalkoznak vele) csinaltam inkabb sajatot es bedudalom az apin keresztul. Csak az meg hol megy hol nem.. javult az uptime amugy, de en en ahhoz vagyok szokva, hogy a) bejelentett karbantartas idoaablak vagy b) valami status monitoring page alapjan egyertelmu ha kimaradas van. Naluk egyik sincs.(vagy legalabbis en nem talaltam) Ha epp nem megy valami, vedd észre abbol hogy megdoglik a hivas :-).

Több jellemző probléma van ügyfeleknél, de ezek szinte mind humán oldaliak:

  • 0% ÁFA: eddig csak legyintettek, amikor szóltunk, hogy nincs olyan, hogy 0% ÁFA, de van ilyen-olyan mentes, meg ÁFA törvény területi hatályán kívüli, meg ilyesmik. Most meg megy a pánik, hogy hibás az adatszolgáltatás. Aztán a következő pánik, amikor a stornója is hibára fut. 
  • felviszik a természetes személyt cégként, majd amikor a rendszer közli, hogy kötelező lett az adószám, akkor beírják az adóazonosító jelet, amire persze kapják az érvénytelen adószám hibaüzenetet
  • Eddig is úgy lehetett helyesbítő számlát csinálni, hogy ki kellett választani a helyesbítendő számlát, és azon a megfelelő tételeket korrigálni. Ezt az igen bonyolult folyamatot néhányan "leegyszerűsítették" azzal, hogy simán csináltak egy negatív végösszegű számlát tetszőleges szolgáltatással. Eddig csak a leltárfelvételi íveknél voltak csodálkozások, most viszont ezek a negatív számlák sem tudnak bemenni hiba nélkül. 

De ezektől eltekintve viszonylag problémamentes, pedig az elmúlt pár napban levő kommunikációs akadozások alapján rosszabbra számítottam. :)

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

hogyhogy nem omlott ossze az egesz ma? gondolom az eddiginel 2-3 nagysagrenddel tobb bekuldes lesz. vagy senki se mert ma szamlazni? :)

A'rpi

Konkrétan tegnap 16-tól 24-ig tervezett karbantartás volt, aztán éjfél után pár perccel ment, de valamikor 1/4 1 környékén belehalt egy műveletnél és fél egyig vissza se jött. Itt abbahagytam, aztán reggel 7 környékén megint nekiugrottam és tulajdonképp pöccre ment. Utána már nem érdekelt a dolog, de a lényeg:

volt aki ma számlázott :-)

Megzavarodtam.

Hogyan lehet hitelt érdemlően lecsekkolni, hogy valaki belföldi adóalany e vagy sem?

Elvileg csak belföldi adóalanynak kiállított számlát szabad beküldeni, de attól hogy valakinek van adószáma nem biztos, hogy adóalany. Gondolom a 'taxpayerData/vatGroupMembership' tartalmazná ha küldené az igentiszteltnav.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Köszi, de ez nem ilyen egyszerű. Pl. Költségvetési szervek, civil szervezetek, egyházak rendelkeznek ilyen adószámmal, de közel sem biztos, hogy adóalanyok. Az Online számla FAQ-jában olvastam, hogy kizárólag belföldi adóalanyoknak kiállított számla beküldése megengedett.

Egyelőre megkapnak minden adószámos számlát, aztán csináljanak vele amit akarnak.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Nekem is, visszakapom az adózó adatait. Viszint attól, hogy egy adószám valaid, még nem jelenti azt, hogy adóalany.

Itt a második pont bizonytalanított el:

https://onlineszamla.nav.gov.hu/kerdesek_es_valaszok

Aztán utána olvasgattam és nagyon sok olyan szituáció van amikor van valakinek adószáma, de nem adóalany. Pl az összes civil szervezet ilyen, aki csak adományból / tagdíjból tartja fenn magát és nem végez gazdasági tevékenységet. A FAQ szerint a nem adóalanyt nem szabad beküldeni. Na de honnan derítsem ki, hogy ki adóalany?

Neked a NAV API válaszban jön 'taxpayerData/vatGroupMembership' tag és abban tartalom? Nekem nem.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Szerintem a civil szervezetek adóalanyok. Adószámmal rendelkeznek, adóbevallást készitenek stb. Teljesen életszerű, hogy egy ilyennek kiállított számlát be kell küldeni. De tegyük fel nem kellene, mert nem végeznek gazdasági tevékenységet. Akkor mi van? Semmi. Egyébként is a beküldő cég szerepeltetné a bevételei között, a civil szervezet elszámolja a z adóbevallásában stb. Szerintem annyit tehetsz ésszerűen, hogy levizsgálod az adószámot, hogy megfelelő-e. ha igen akkor bemegy, ha nem, akkor javítsák ki stb. Ha meg a nav visszadobja akkor már tudod is, hogy ennek nem kell küldeni. De mi van ha fél év múlva mégis elkezd a szervezet gazdasági tevékenységet folytatni, akkor mit csinálsz? Ökölszabály, van érvényes adószám beküldeni azt kész.

Ha belföldi magánszemélynek állítok ki számlát, akinek nincsen adószáma, akkor jól tudom hogy ilyen számlákat nem kell beküldeni? Hanem majd csak 2021. januártól kell mindent küldeni?

Van olyan publikus, lehetoleg ingyenes API amin adoszamokat lehet lekerdezni, ellenorizni?

(fizetoseket talaltam de eleg horror aron)

koszi. nem astam bele magam az onlineszamla api-ba, mivel a szamlazas nem az en gondom :)  csak regisztraciokor le kene ellenorizni, hogy a megadott adoszam jo-e, meg ha mar, akkor a cegnevet/cimet automatikusan kitolteni. ehhez keresek valami egyszerut es olcsot :)

az onlineszamla api-hoz gondolom kell ceges api kulcs is?

csak regisztraciokor le kene ellenorizni, hogy a megadott adoszam jo-e

Szerintem az kevés, ezt inkább minden számla beküldésekor meg kellene csinálni - mi van, ha közben megszűnt a cég (bár nyilván arról tud a könyvelő/pénzügyes)? Vagy Észak-Pestről átmentek Dél-Budára (adószám változás...)

meg ha mar, akkor a cegnevet/cimet automatikusan kitolteni

Igen, ezt amúgy a NAV saját számlázója is így csinálja.

az onlineszamla api-hoz gondolom kell ceges api kulcs is?

Írták már, de igen, kell. Viszont van külön teszt rendszer, ahol kvázi büntetlenül küldhetsz be mindent - mármint amit elfogad a rendszer. És amúgy ettől függetlenül ingyenes.

"Szerintem az kevés, ezt inkább minden számla beküldésekor meg kellene csinálni"

Igen is meg nem is. Teljesen érvényes adatküldés az, amikor a cég megszűnt/adószám megváltozott, de a teljesítéskor még létezett. Ekkor beküldés után WARN-t fogsz kapni.

Az a gond, hogy jelenleg a belső infrájuk és egyéb függőségeik miatt nem lehet historikusan kiadni a queryTaxpayer eredményeit. Volt már erről issue a githubon, körbejártuk a témát.

Eddig nem volt szükség rá, de implementálni kell a /queryInvoiceDigest operációt.

A küldött xml:

<QueryInvoiceDigestRequest xmlns="http://schemas.nav.gov.hu/OSA/2.0/api">
    <header>
        <requestId>...</requestId>
        <timestamp>2020-07-22T17:11:03.978Z</timestamp>
        <requestVersion>2.0</requestVersion>
        <headerVersion>1.0</headerVersion>
    </header>
    <user>
        <login>....</login>
        <passwordHash>....</passwordHash>
        <taxNumber>....</taxNumber>
        <requestSignature>....</requestSignature>
    </user>
    <software>
        ...
    </software>
    <page>1</page>
    <invoiceDirection>OUTBOUND</invoiceDirection>
    <invoiceQueryParams>
        <mandatoryQueryParams>
            <invoiceIssueDate>
                <dateFrom>2020-07-01</dateFrom>
                <dateTo>2020-07-25</dateTo>
            </invoiceIssueDate>
        </mandatoryQueryParams>
    </invoiceQueryParams>
</QueryInvoiceDigestRequest>

A kapott válasz:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralExceptionResponse
    xmlns="http://schemas.nav.gov.hu/OSA/2.0/api"
    xmlns:ns2="http://schemas.nav.gov.hu/OSA/2.0/data">
    <funcCode>ERROR</funcCode>
    <errorCode>INVALID_REQUEST</errorCode>
    <message>Érvénytelen kérés!</message>
</GeneralExceptionResponse>

A teszt rendszerben pedig a következő üzenetet kapom erre az operációra:
 

400 Bad Request

An HTTP protocol violation was detected and your request was denied.
SessionID: bJqopjRd::02
Date: 2020-07...

Ugyan az a kód végzi minden operáció küldését de ez valamiért nem megy. Valaki találkozott már ezzel a problémával?

Igen, ide. Ekkor kapom a GeneralExceptionResponse választ.

Mikor a 

https://api-test.onlineszamla.nav.gov.hu/invoiceService/v2/queryInvoiceDigest

teszt rendszerbe küldöm akkor pedig a 400 Bad Request An HTTP protocol violation was detected and your request was denied üzenetet.

Akkor passz, mi nem használjuk ezt a funkciót és még nem volt ilyen hibánk, így csak sötétben tapogatózok. De az mondjuk érdekes,ha minden más meg működik, eléggé azt súgja, hogy NAV oldali gond. Esetleg, ha számlaláncot próbálsz lekérdezni, intervallum helyett?

27-én elküldtem a nav.gov.hu oldalon lévő üzenetküldés felületen a hibajelenséget nekik a teljes xml kéréssel és válasszal, de még nem kaptam csak egy autómat visszaigazoló e-mailt, hogy megkapták. Lehet ha ma sem kapok rá választ akkor készítek rá egy github issue-t, hátha ott gyorsabban eljut az illetékesekhez.

Ami elsőre feltűnő:

  • ( bodnarj | 2020. 07. 28., k - 15:10 )

  • <timestamp>2020-07-22T17:11:03.978Z</timestamp>

  • <dateFrom>2020-07-01</dateFrom>
    <dateTo>2020-07-25</dateTo>

Szóval csak azt akarom kérdezni, hogy mikor történt pontosan a kérés? Valóban 22-én? És a záródátum júli 25? (ezt amúgy elfogadja a NAV)

Bocs, itt én voltam dinnye. Kiszedtem a valós adatokat a user, header, software részekből és utólag visszatettem a timestamp rész, hogy lássátok milyen formátumban küldöm és elírtam a dátumot. Egyébként a kérés 2020-07-25 napon lett küldve.

Erre egyébként én is gondoltam, de ha mondjuk 07-25-én kérek le 07-01 - 07-10 közötti intervallumot ugyan az a hibajelenség.

Ok, ez így akkor tiszta. Annyi rémlik, de a pontos szabályt nem tudom, hogy a timestamp mezőben nem lehet X óránál régebbi időpont.

 

Ami még fura (eleve az fura), hogy a PROD és a DEV ugyanarra a kérésre - ha tényleg ua... más választ ad. Mondjuk a DEV kicsit bőbeszédűbb:
 

400 Bad Request

An HTTP protocol violation was detected and your request was denied.
SessionID: bJqopjRd::02
Date: 2020-07...

ez alapján szerintem valami a HTTP layer környékén van, ami nem tetszik nekik. Pl valami extra fejléc?

Nekem amúgy működik ez a kérés, én rendszeresen használom (ill használtatom :)), és a választ is feldolgozom, így van infónk az általunk beküldött, és a nyilvántartott adatokról.

ha tényleg ua...

Eltekintve attól, hogy ugye a DEV és PROD rendszerben másak a technikai userek, a kulcsok, jelszók és emiatt a header és user rész sosem lesz ugyan az, a két kérés egyforma. 

A DEV rendszer által visszaadott hibára az online számla oldalának technikai kérdések és válaszok részében van egy leírás:

II.13. kérdés: A beküldött kérésemre a következő hibaüzenetet kapom vissza: „An HTTP protocol violation was detected and your request was denied.” Mi a teendő?
Ezt az üzenetet a szerver előtt lévő hálózatvédelmi eszköz adja vissza akkor, ha a HTTP kérés nem engedélyezett endpointra érkezett. (pl. a POST után hibás vagy hiányzik az URL) Ellenőrizni kell a kimenő HTTP üzenetet!

De ezt már olyan szinten kipróbáltam, hogy ugyanabból a GlassFish példányból let beküldve a kérés a PROD és DEV rendszerbe is ugyan azokkal az adatokkal (persze itt is a technikai userek miatt pontosan mégsem ugyan azokkal).

Tehát mind a Java mind a GlassFish ugyan az. Ugyanazok a libek is vannak alatta, akkor miért lenne más a 2 kérés?

Ha meg valahol a header vagy user résszel lenne baja akkor ott meg minden operációnál hibásnak kellene lennie mert ugyan az a kód generálja ezeket függetlenül attól melyik operációt hívom meg.

Már azt is kipróbáltam hogy szándékosan elrontom az endpoint-ot /queryInvoiceDigest helyett mondjuk /queryInvoiceDigestABC-t írok, akkor arra azt hiszem 404-es hibát kapok és nem ezt amit most próbálok kideríteni.

a két kérés egyforma. 

ok, nyilván a széndék az, hogy egyforma legyen, de lehet valami nem kíván hiba. Amúgy nem feltételezem, hogy más a két kérés, pont ezért tartom furának, hogy a két válasz nem egyforma.

Ezt az üzenetet a szerver előtt lévő hálózatvédelmi eszköz adja vissza akkor,

igen, ezt próbálom erőltetni, hogy valszeg valami HTTP protokollbeli hiba lesz. Nem lehet pl az endpoint végén egy plusz szóköz? Vagy valami ilyesmi...

akkor miért lenne más a 2 kérés?

nálunk is ua a kód, de pl más a konfig (ahogy nálad is). És ha pl a konfigban nem csak a user és a jelszó van tárolva, hanem pl más viselkedési paraméter is (pl. a DEV-ből nem mehet ki e-mail csak bizonyos domainekre), akkor az okozhatna ilyet. De ez tényleg csak egy elméleti felvetés, lépjünk túl :).

szándékosan elrontom az endpoint-ot

ez is ok - de pl ha olyan karakter van az URL-ben, ami el sem jut az API-ig, akkor az más hiba. Ilyen pl egy nem odavaló szóköz, más whitespace, két slash, egyéb karakter.... ami csak itt jön elő, ennél a kérésnél.

Nem tudom, mit használsz a kérések felépítéséhez, én curl-t, ott ki lehet dumpolni a teljes kérést - ilyenre van lehetőséged?

A  Java EE 7 javax.ws.rs -t használok.

Az IntelliJ IDEA-ban van egy curl-hez hasonló eszköz, mot megpróbáltam onnan elküldeni a kérést DEV környezetbe és voálá, kapok vissza rendes választ ...

A URL-t amit megadtam az IntelliJ-ben azt az alkalmazást debugolva, breakpointtal megállítva és onnan kimásolva adtam meg, hogy ugyan az legyen mint amit az alkalmazás is használ... látszólag nincs benne semmilyen whitespace és hasonló felesleges karakter. 

Az az elküldött XML szintén így lett kinyerve.

Tehát az alkalmazás által előállított XML jó. És akkor most már csak arra kellene rájönni, hogy mi a búbánat lehet rossz a küldésben. :)

Megvan a hiba oka. Valami a GlassFish-ben zavarodott össze.  

Deployáltam másik alkalmazás szerver alá az alkalmazást és ott szépen ment, viszont a fejlesztői környezetben nem. 

Itt már kezdtem gyanítani, hogy a fejlesztő GF példánnyal lesz valami. Töröltem a generated és osig-cache könyvtárakat és onnantól kezdve megy a fejlesztői rendszeren is. Valószínűleg nem frissítette deployáláskor valamelyik osztályt és egy régebbi állapot maradt meg benne, így mehetett rossz kérés a nav rendszere felé, ami jogosan dobta a hibát.

Az xsd szerint TimestampType típusú a dateTimeFrom és dateTimeTo, amiek az alapja a standard xs:dateTime és fix pattern van rátéve ami megmondja hogy milyen string formában kell lennie : xs:pattern value="\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(.\d{1,3})?Z"

forrás: prog.hu

NAV-os online számlázó esetén tudtok megoldást arra, hogy alapértelmezetten készpénzes számlát állítson ki? Tehát a legördülő menüben ne átutalásos legyen az alapértelmezett. Ha valami böngésző oldali addonnal lehetne elérni az is jó lenne (Linux/Firefox)

Köszi szépen!

Kedves Mindenki!

Elérhető az Enliven Systems (https://enliven.systems) által fejlesztett Scala (JVM) interfész szabad használatra (MIT license). [1]

Mindenkit örömmel látunk, aki szeretne csatlakozni a projekthez. Java nyelvben is használható, de a kényelmesebb felhasználáshoz szívesen írunk egy Java csomagoló interfészt. További részletek az alábbi linken.

[1] https://github.com/enlivensystems/invoicing-hungarian

Üdv,
Z

Székhely változás esetén (a cég címe és az adószám utolsó 2 karaktere változik a neve nem), ha javítani kell egy számlát ami még a székhely változás előtt került kiállításra, az új számlával egy tekintet alá eső bizonylatot az új adatokkal vagy a régivel kell kiállítani? És ezt az interfész hogy kezeli?

Ha a szállító adataira vonatkozik a kérdés, akkor természetesen az új számlát az új adatokkal kell kiállítani attól a naptól kezdve, amikor a cégbírósági nyilvántartásban megjelent az új adat. Az adószámnak csak az első 8 karaktere (törzsszám) ami számít, az ÁFA és megye kód nem.

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

Röviden: ugyan úgy kell eljárni.

Hosszabban: nincs olyan, hogy stornó meg helyesbítő meg hasonló számla. Van a számla, és van a számlával egy tekintet alá eső dokumentum, ami a számlán kívül kb. minden más számlának látszó cucc, ami a számlára hivatkozik. Bármilyen számlán vagy számlával egy tekintet alá eső dokumentumon a kiállításkor aktuális szállítói adatoknak kell szerepelnie.

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