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

 ( royal | 2017. június 29., csütörtök - 16:22 )

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

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

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

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.

Az nem jó, akkor nekik kellene dolgozniuk.

Pont, hogy nem. Gyakorlatilag semmi dolguk nem lesz.

> Sol omnibus lucet.

Szóval azt állítod egy országos számlázó rendszerrel nem lenne folyamatos munka? lul.

Legalább meggondolnák, hogy milyen gyakran írjanak elő változásokat a számlában és a számlázásban! :D
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

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...

De ez a NAV-os számlázó (kvázi vagy valós) szabvány lenne, így minden rendszert hozzá lehetne igazítani!
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

+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.

"kapsz egy űrlapot, kitöltöd"

Ez maximum az egyszeri számlázóknak jó. Minden másra API kell.

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

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...):

Idézet:
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.)

Idézet:
-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.

nem TORerálják a publik netet :D

-a kommunikáció "nem a publikus interneten fog történni
http://www.portfolio.hu/gazdasag/adozas/jon_a_nav-testver_megjelent_az_ngm_fontos_rendelete.12.254987.html
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

Ezt hogyan kell értelmezni? Dedikált vonalon (pl gsm)?

vpn?

Valakinek van esetleg ötlete arra nézve, hogy az ún. "publikus internet" https protokollal miért nem felel(ne) meg a célnak?

Mert abbol nincs penze a tegnap alakult NAV connect bt-nek...

Abban bízok én is, hogy a publikus netet az különbözteti meg a nem publikustól, hogy "s" betűre végződik a protokoll :)

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

:-D :-D :-D

Én sem találom martonmiklos idézetét a tervezetben és máshol sem egyenlőre.
> -a kommunikáció "nem a publikus interneten fog történni"
De, ha nem az lesz akkor mi az a 3k havi költség ?

Felmész ide:
http://www.kormany.hu/hu/dok#!DocumentSearch

Beírod a keresőbe, hogy számla.
A közlemény júni. 27-ei lesz az ahonnan idéztem. Direktlinkre én nem találtam lehetőséget.

nemlehet, hogy a kozlemenyt azota letoroltek?

Azon töprengtem, hogy ha a speckó mobilnetes megoldást alkalmaznák mint a pénztárgépeknél akkor mi lenne az online számlázókkal?
Ha oda elég lenne egy sim/előfizu akkor versenyelőnybe kerülnének.
Ha meg nem az technikailag bonyolult lenne.

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

Idézet:
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

Szerintem is a TOR lesz a megoldás

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ő:

Idézet:
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

ilyesmire gondoltál xsd helyett? http://json-schema.org/latest/json-schema-validation.html
bátorság botorság...
a tákolt kézműves json legalább ugyanannyira szar lenne mint a tákolt kézműves xsd..

Ez igaz, de nem is azt mondtam, hogy legyen tákolt json. Legyen egy normális, jól átgondolt, funkcionalitást a lehető legminimálisabban korrektül ellátó interfész. Ha az teljesülne, egy szót se szólnék az XML sémára.

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

+1, gondolom ott vannak hatékonyabb módszerek az ellenőrzésre :)

Bármelyik nosql adatbázis végez 1mp alatt a feladattal. :)

Csak a dróton nem megy át 1mp alatt.

azt, hogy exportálják a számlákat, nem hiszem, h bármi tiltaná!

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.

Nézd,tudtommal kell a gépre vírusirtó. Azt hogy' frissíted?
Ha e-számlát állítasz ki, annak hogyan intézed a hiteles aláírását és küldöd ki?

Ezek a dolgok audittól függenek, ha jól gondolom.

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

Jah, és a mobil/külső userek naponta utaznak majd pár 100km-t, hogy hozzáférjenek a szerverhez?
Esetleg újra bevezetik a gépidő bérlést is?


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

Nézd meg pl a szamlazz.hu oldalt. Bárhonnan hozzáférsz weben keresztül.
Mivel a pénztárgépnek is bárhol kell, hogy működjön az országban - ez is működik bárhol :-)

úgyérted olyan számlázó, amit auditáltak is?! mert most olyanról van ám szó...

A számlázó programnak kompatibilisnek kell lenni - azaz tudni kell feladni a megfelelő adatokat NAV-nak. Ez jogos igény lehet.
Ha a Te programod ezt csak 2 külön példányba tudja, a Te bajod...

én kíváncsi lennék rá,ha megtennéd,hogy átküldöd :)

mit is?

rossz helyre válaszoltam,bocsi

Nem értem. A kobak rendszerhez melyik ip cím kell? A szerveremé amelyik küldi azt infot majd
vagy
az enyém, hogy hozzáférjek?

É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... :)

pedig azt hinné az ember,hogy "egy ilyen nagy horderejű,az ország versenyképességének javításában is szerepet játszó rendszer" esetében minden létező lehetőségre gondoltak :)

Az, hogy leszarják még nem jelenti azt, hogy nem gondoltak. :)

Nem hiszem el, hogy itt tart ez az ország...
2017-ben egy szolgáltatás használatához fix IP kell.

Szerintem akarják tudni ki okoz majd túlterhelést. :) Így tudnak neki szólni.

Access token...

Szégyen és gyalázat.

Sokkal szánalmasabb, hogy többek közt a kapcsolattartó adóazonosító jelét is meg kell adni...

Vajon nem-e szopás elsőként használni a rendszert, mintegy alfa teszter?

This site can’t provide a secure connection

kobak.nav.gov.hu didn’t accept your login certificate, or one may not have been provided.

Regisztráció után kapsz egy certet amit telepíteni kell a böngészőbe és utána jó lesz.

Ma megjelent a NAV oldalán a számlázásról szóló információs füzet ráncfelvarrt verziója:

http://nav.gov.hu/data/cms432556/18_A_szamla_nyugta_kibocsatasanak_alapvet__szabalyai_20170710.pdf

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

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

Igen. Múlt hét hétfőn regisztráltam és péntek reggelre lett meg. Egyébként az oldalon csak az xml-t tudod ellenőrizni amit még nem próbáltam. Valamint le lehet tölteni egy offline exe állományt is, valószínű ugyanerre a célra. Azt nem néztem.

Köszi, nem emlékszel véletlenül hanyas számot kaptál a regisztrációkor?
Tehát jól értem, hogy a feltöltéshez szükséges infrastruktúra még nem áll rendelkezésre.

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.

Melyik IP-t adtad meg?

??.???.2?3.43

Oké. Szerver, router, kliens, (azt sem tudom miben fejlesztesz)

IMHO ez most nekik ahhoz kell, hogy a kobak.nav.gov.hu-t milyen címekről lehesen elérni.
Általuk meg nyilván a kívülről látható címed kell: http://whatismyipaddress.com/

Erre tippelek én is. Megerősítést várok.

Bocsi, azt hittem a publikus ip címemre vagy kíváncsi. Gondoltam az meg minek neked.

Igen a szolgáltató által kiosztott fix IP-t adtam meg 3X, mert mind a 3 mező kötelező volt. Jeleztem nekik és megköszönték. Lehet azóta már javították.

a 127.0.0.1-et kellett volna beírni nekik ...
azzal is ellennének 1 darabig ...
:):):)
_____________________
www.pingvinpasztor.hu

A hetvenvalahányasig még biztosan nem jutottak el, mert még nem kaptam én sem visszajelzést...

Szóban is az hangzott el, hogy majd csak január 1-től fog indulni a próbaüzem.

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

Én 25-öst kaptam, és szintén nem kaptam választ.

sub

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

Nálad működik most? Nekem egy ilyet tol az arcomba:

400 Bad Request

An HTTP protocol violation was detected and your request was denied.
SessionID: 1PfjEn05::02
Date: 2017-08-30 17:03:13

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::02Date: 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

Hogy néz ez ki.. meg jsf.. meg mi ez!!
Megyek én is az országból

IMHO ez csak a jéghegy csúcsa, habár én a mai napig nem kaptam meg a regisztrációmat.

-

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

Azt hiszem, lassan, kényelmesen el lehet kezdeni a fejlesztést.
Van aki kész van már vele?

Már csak az a kérdés hogy kell majd beküldeni? Mert erről semmi infó nincs.

pch
--
http://sb-soft.hu
--

mennyire fognak ennek orulni az automatikus rendszerek :D

Ez szerintem még csak a fejlesztői felületre belépésről szól ahol lehet tesztelni a generált XML-eket. Kizártnak tartom, hogy a végleges megoldás 2FA-t igényeljen, bár a fix IP óta nem csodálkoznék azon sem nagyon.

Ne kiabáld el, állami szervről beszélünk :)

Végén még bejön, hogy a 2FA az lesz, hogy betelefonálsz és a SC-nek be kell diktálnod a IP-det, amiről 20 percig fog fogadni adatot :D:D:D

XSD-hez van más értelmezés is?

Ezt hogy érted?

+1

Nekem nem minden mező egyértelmű.

É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

jaja... köszi

-

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.

Köszi az infókat!

"- 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...)

-

Ez azt jelenti, hogy ami számlát megkapnak, az elektronikus számla is lesz egyben, amit a számla címzettje letölthet a NAV-tól?

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

s hány millióra büntettek meg? vagy ez már az emberarcú nav, aki először kérdez, aztán üt? :D

Még nem kötelező ez a fajta adatszolgáltatás, csak tesztüzem van.
Ők ajánlották fel, a tesztet.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Teszt üzem sosem volt a adóhatósági ellenőrzési adatszolgáltatáshoz. 2016.01.01 -től minden számlázónak tudnia kell.

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 :)

Azért mentek direkt, mert saját fejlesztésű számlázót használtok?

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.

Ha már kimennek akkor megnéznek sokmindent ja, de a motiváció lenne a kérdés :)

bár ha nem mondták meg, kb soha nem fogjátok megtudni.

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-szamla/

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

Te ezért pénzt kapsz? Te céged? Mert akkor GVH-s az eset. :)

Nem. De nyugodtan jelentheted a GVH-nak. Esetleg értelmes hozzászólás a témához?

Igen. Hülyeséget írtál a havi frissítéssel.

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.

Honnan bübánatos *#@#&@&#{}&@} veszed, ha félévig nem történik frissítés, akkor nem foglalkoztak vele?
És mi a *#@#&@&#{}&@} közöd van a changeloghoz?

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.

Hagyd nem ér annyit...

u.i.: amúgy szerintem tuti kap érte megfelelő mennyiségű papírpénzt..

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

Nem csak azzal :)
De ha megnézed a többi hasonló topikban tett ámokfutásait, akkor láthatod, hogy nincs értelme tényekkel összezavarni :)

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

+1
Rendszeresen előjön nála az aggodalom a számlázók miatt:
https://hup.hu/node/148165?comments_per_page=9999
és mindig ugyanazt a számlázót reklámozza:
https://hup.hu/node/148165?comments_per_page=9999#comment-1999466

én nem reklámozok semmit, csak leírtam, hogy én mit használok és miért.

ennyi erővel royal meg mindig az Evir.hu-t reklámozza, minden egyes hozzászólása alján reklámozza.

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.

  1. Ahogy körbenéztem, csak (!) a Billzone.eu online számlázó implementálta maradéktalanul a rendeletet.
  2. 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.
  3. A Billzone kifinomultsága legjobban idegen nyelvű, devizás számla kiállításakor látszik meg.
  4. 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.
  5. 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.
  6. 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

Ezt még korábban írtam, ma nem tudom, hogy áll a helyzet, de ma már biztos van több ilyen program.

Nem is értem ezt a kétnyelvűség dolgot, a NAV-nak megfelelő ha angol vagy német vagy francia a számla, nem kell magyarul is ott lennie a dolgoknak ezen nyelvek esetén, se hivatalos fordítás se egyéb faszság.

Így van. Csak annyi a kikötés, hogy ha a NAV nem tudja értelmezni az idegen nyelven kiállított bizonylatot, akkor nem a NAV-nak, hanem a kiállítónak kötelessége gondoskodni a fordításról.

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

Szerintem royalnál egyértelmű a móka => ővé a cég.
De nálad kispajtás?

Valami tuti van, normalis ember ennyire nem reklamoz valamit ok nelkul - sokszor lehuzva az egyebkent bizonyitottan jol mukodo konkurens szamlazokat...

NAV egész jó összeszedte a tudnivalókat:

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

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

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

Lassan tényleg el lehet kezdeni érdemben foglalkozni a megvalósítással :)

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

Hát betartott xd

Nem lesz egyszerű.
Mondjuk a teszt oldal még nem működik...

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

Csak hogy jól értelmezem-e. Minden kéréssel kell:
- Username / jelszó hash (?!) párost küldeni
ÉS
- Kérést aláírni (gyakorlatilag HMAC)
ÉS
- Egyszer használatos tokeneket kérni / küldeni (ami valamiért AES-sel kódolva utazik)

Ez komoly?

Én csak arra lennék kíváncsi mivel tudnak még tartalomjegyzék nélküli PDF-et generálni?

sub

Én már beküldtem a tesztszámlát.
Csak mivel nincs további teszt lehetőség így nem tudok haladni.

pch
--
PSB-soft online ügyviteli rendszer
--

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...

Bocs most láttam.
Nem tudok privátot küldeni.
Adsz elérhetőséget küldök mintát.

pch
--
SB-soft online ügyviteli 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.

Biztosan nem. Kezdetnek nem kerül be minden számla.

Hát, én erősen tartok attól, hogy ha az ügyviteli programnak nálunk lesz interfésze a NAV felé, akkor minden számla bemehet rajta. Ha nem lesz, akkor meg egy sem.

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.

Én egyedül dolgozok.

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

Szintúgy. PHP.

Igen

Én is.

Én is

A rendszerem webes php-ban készült, de a "konnektor" nem biztos, hogy abban csinálom, de nagyon esélyes.
Ha másnak is, akkor lennének olyan részek, amelyeket szerintem a github-ra kirakhatunk.

Én már beküldtem a teszt számlát.
cURL-t használok.
Ha kell segítség szólj.

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

Köszönöm. Még a doksival sem végeztem. (ma kezdtem neki)

Szia! Én megköszönném, ha a működő curl opciókat megadnád, mert mind a teszt, mind az éles oldal hibát dob (ráadásul különbözőt, olyat ami a doksiban sincs.)

+1

$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
--

Kösz. A sajátomban elgépeltem a Content-Type-ot. :-)
Még napokig ellettem volna vele...

Köszi. Sok időt spóroltál nekem, mert még nem használtam sohasem a curl-t.

Kis segítség a csatlakozáshoz (PHP): https://github.com/pzs/nav-online-invoice

Megelőztél, bár én nem csináltam meg ilyen szépen :)

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

+1

köszi!!!

sub

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

100k ÁFA tartalomig nem kell beküldeni számlát.
Afelett viszont kötelező, szóval ki kell rakni netre, nem választás kérdése.

Koszonom! Akkor ez lesz. Kicsit ezzel van bajom, hogy nem valasztas kerdese... Mondjuk online penztargepeknel ugyanez volt. Ott sem volt valasztas... :)
Nyilvan visszafele nem fejlodunk kezzel nem fogunk szamlazni.
--
vati

Átküldöd egy másik gépre a kész XML-t és beküldöd onnan.

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.

Nem a másodperc a lényeg, hanem hogy teljesen, 100%-ig automatikusnak kell lennie, nem szabad, hogy szükséges legyen emberi beavatkozás

És az miért zárja ki a másik gépről küldést?

bedobja a queueba aztan majd a masik komponens kihalassza...
\

Pedig nekem is ez jutott eszembe, hogy egy küldő alkalmazás kell, hogy a user ne várjon.

akkor kézzel kell írni a számlát amit 5 napon belül kell lejelenteni :)))

Á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...

Tegnap este megjelent a technikai vonatkozású kérdés-válasz gyűjtemény:

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

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

Ok.
Az a baj, hogy még csak ennyi működik:
- /tokenExchange
- /manageInvoice

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

Akkor érdemes nekikezdeni?

Mivel mindenféleképpen meg kell csinálni, lassan már érdemes belevágni. Túl sok meglepetés már csak nem lesz :)

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

Ez igaz, de azért ijesztő, hogy még nincs kész.

É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)

Küld emailt

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

Köszönöm a segítségedet!

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

reggel próbáltam jelentkezni, már ez is betelt.

Nekem még sikerült, vissza is igazolták a regisztrációt...

Majd jegyzetelek és összefoglalom az elhangzottakat :)

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

Nagyon izgalmas előadás volt, bár kicsit aggasztó volt hogy sehol se tart a NAV fejlesztés:)
úgy izgalmas a fejlesztés, hogy azt se tudják hogy fog működni:)

+1

Amin viszont meglepődtem: 40++ korosztály. Úgy látszik a fiataloknak eszükbe sem jut ilyesmi. :)

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?

Teljesen független egymástól a két funkció, nem azonos az XML/XSD.

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

Megnyílt a regisztráció a jövő hét hétfői NAV fejlesztői fórumra a https://kobakreg.nav.gov.hu/ oldalon. Még tutira vannak szabad helyek... :)

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

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á?

Ez a legjobb:
Hozza magával a kinyomtatott emailt...

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

hát igen, szánalmas. a felületet láttad?

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

köszi az infot

Nincs mit :)
Még annyit tudok tenni ha szeretnéd, hogy átküldöm azt, amit magamnak jegyzeteltem. Bár az szerintem kb. azt írtam le, amit el lehet majd érni dián is ha közzéteszik.

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

Kérhetnék én is a jegyzetekből? PHP-vel kell megcsinálnom a dolgot, a Token kérés már megvan, a többibe a napokban kezdenék bele. Előre is köszönöm. :)

Lesz mintakód kirakva. php is.

Akkor tök feleslegesen szórakoztam vele :) , még jó hogy a számla beküldés/módosítás részét még nem csináltam meg.

Azt mondták, ha lemennek az előadások akkor kirakják a diákat. Azon pedig C#, Java, PHP, Curl mintakód is van a beküldésre. Csak az XML-t kell megcsinálni.

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.

most láttam csak,hogy írtál. köszi, de nem szükséges, elvileg hétfőn megyünk mi is.

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 lehet, hogy "csak" az a baj, hogy nem valid a NAV teszt rendszer certje?

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

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?

A technikai userhez van jelszó, az elsődleges felhasználó szokta megadni amikor létrehozza.

A felhasználói listában most én sem látom a technikai useremet, helyette a "USERS_LIST.ENUM.EMP..." szerepel a Típus és a Státusz oszlopban is :)

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

Helló!

Abban a sorban ahol a "uc.setRequestProperty( "Accept", "text/xml" );" van, ott "application/xml" kell, hogy legyen. Tudom apróság, de a speckó szerint az kell, hogy szerepeljen.

sub

Nálam már sikerült a token exchange, talán tudnék segíteni. Most hol tartasz, milyen hibákat kapsz?

+1

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
--

Nálatok javult valamit tegnap óta a helyzet? Kaptál választ?

Nem, de jött tájékoztatás, hogy a hiba a NAV rendszerében van...

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

Igen. Emailba jött.
Hát nem lesz semmi.. Most oké még teszt van, de ha élesbe lesz ilyen...
Tiszta szopás.. Magyarázhatsz az ügyfélnek... :/

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

Hát igen... Pedig mennyire mondták a fejlesztői fórumon, hogy nem lesz hiba a NAV-os rendszer elérésben :) (airween kollega pont ezt feszegette a hibakódokkal)

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

Most már megy 1.1-es verzióval is.
És megy a számla lekérdezés is.

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

Java security prompt visszaállítása nélkül ment volna amúgy is....

A https://onlineszamla-test.nav.gov.hu/dokumentaciok oldalra felkerült a fejlesztői fórum anyaga.

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

Úgy látom frissítették a https://onlineszamla-test.nav.gov.hu/kerdesek_es_valaszok és https://onlineszamla-test.nav.gov.hu/technikai_kerdesek_valaszok oldalakat a fórumon elhangzott kérdések alapján.

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs 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);
}

Key = keyBytes
IV = keyBytes

Tényleg? Ez a példakód?

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ü)

Én addig nem foglalkozok vele míg érdembe nem lehet mit csinálni.
Ez a "teszt" egy nagy kalap fosh.

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

Hát tudjátok biztosan van a "fejlesztői" rendszer ez meg a "staging" :D aki használja az meg az alpha tester :D

Én nem tudom, de ez finoman szólva is érdekes, hogy egyik órában még megy, a másikban meg cseszik működni.
Majd az lesz kemény ha élesben is ilyen lesz, aztán majd jön a bünti az esetleges elmaradt bejelentések miatt. :D

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.

SZVSZ még mindig várnék. Legalábbis nekem nincs már annyi kapacitásom feleslegesen, hogy az összes faszságukat lekövessem.
Majd ha kész a végleses teszt rendszer rávetem magam. Addig leszarom kategória..

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

Bocsánat a cinikus megjegyzésért, de szerintem végleges verzió nem lesz idén :). Viszont július 1-től indul a rendszer.

Csak szólok :)

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

szerintem az a számlatömbösöknek lesz.

Ez vajon valóban elektronikus számlatár is lesz? Mondjuk logikus lenne, azonnal hazavághatná az összes elektronikus számla szolgáltatót. Akinek ilyen szolgáltatója van, annak ráadásul megérné a váltás, ha ingyenes.

Majdnem. Jelenleg csak akkor fogadja be a rendszer a számlát, ha adószámmal rendelkezik a vásárló.
Akkor tudja majd helyettesíteni az eSzámlát, ha nem lesz ez a kitétel.

Nekem ez már megérné. Akinek B2C forgalma van, úgyis zömében készpénzes, kasszagép, ilyesmik. Ha a B2B-re teljeskörűen alkalmas lesz, azzal egy vállalkozás egy valag pénzt meg tud takarítani az e-számlával.

"azzal egy vállalkozás egy valag pénzt meg tud takarítani az e-számlával."

meg is indokoltad, miért nem lesz :)

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ó.

ugyan már, ugyan már kit állított meg az h valami logikus avagy sem. :) székházat eladni-visszabérelni stb. Inkább támpont az, hogy ha valami nagy baromságnak tűnik arra lehet építeni és legalább tudod hogy a logikus választás na az tuti nem fog nyerni.

Nem lesz API. Elmondták többször, hogy ez egy ék egyszerű számlázó lesz, amit a számlatömbösök használhatnak. Nem lesz sem adat exportra, sem importra lehetőség.

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.

mert kimaradt az időközben kötelezővé vált "compressedContent" tag az API xml-ben.

Gyönyörű. :)

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ó.

Igaz a címekkel is sikerült jól be****ni.....
viszont a leírás kimondja abban az esetben ha nem áll rendelkezésre a detialAddress akkor simpleAddress..

mi dönti el?? :)
eddigi tapasztalataim azok hogy ez 1-jén életképtelen lesz..

Tapasztalatom szerint detailedAddress-t csak akkor tudsz átadni, ha a streetName és a publicPlaceCategory tag-eknek tudsz értéket adni. Ha nem, akkor a simpleAddress-t kell használnod.

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?

nem attól lesz szabályos, hogy befogadja az adatokat.

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

Középtávon minden számlára akarják ezt az elektronikus beküldés dolgot, a 0 áfa tartalmunka is.

É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

nem is neki kell olvasnia, hanem a könyvelőjének.

Gondolom nem hallottad még azt a szlogent, amivel minden könyvelői fórum tele van, mely szerint "KATA-snak nem kell könyvelő" :)

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

Hát figy, ez olyan mint gondolom az auto szerelő. Nem kötelező ott szereltetned a kocsidat, de ha akkor magadnak kell utána nézni, megtanulni.

Szerintem hagyjuk, mert úgy látom nem sikerült megértened a problémát... :)

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

Nem nagyon értem igen. Nem kötelező könyvelőt használni, valóban, de ekkor az embernek magának kell up-to-date-n tartania az információit. Vagy megfizetsz egy könyvelőt aki megcsinálja helyetted.

É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

Elvileg ezt nem is tudja az áfa törvény nem? Ez a tipikus visszaszámlázás. Amely számlázókkal találkoztam edigg, ott a számla dátum és a sorszám kapás összefüggöt, amig nincs dátum nincs sorszám, és fordítva.

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ó. :)

Szerintem ezt engedni kellene. Simán előfordulhat, hogy valami gáz van a korábbi számlával és csak később tudod beküldeni.

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

"A vállalkozások jelentős többsége még mindig kézi számlát használ. Nekik is segít a NAV ingyenes online számlázó programja, amely a számlatömb mellett a manuális adatszolgáltatást is kiváltja."
https://www.portfolio.hu/gazdasag/adozas/itt-az-uj-fegyver-adocsalas-ellen.288028.html

Erről tud valaki valami konkrétumot?
--
♙♘♗♖♕♔

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

Csak a teszt áll tegnap 16 óta.

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

Ne legyél telhetetlen, nem működhet minden egyszerre :D

--
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.

MA reggel az éles rendszer alá beraktam a teszt beküldést. Bementem korán, hogy nézzem mi történik ma. Csalódott voltam! :)

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?

HTTP/1.1 500 Internal Server Error
Date: Mon, 18 Jun 2018 19:04:36 GMT
Content-Type: application/xml;charset=UTF-8

és hát OPERATION_FAILED.

Délután fél óra alatt nem tudtak feldolgozni egy beküldött számlát (ez közben elkészült).

Tájékoztatás semmi.

Gratulálok.

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

megjavult magától. öngyógyulás, csoda! leborulok!

https://i.imgur.com/s6Cnfof.jpg (feliratot lehetne módosítani, hogy NAV adatszolgáltatás fejlesztő minden request előtt)


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.

Nem kerül küldésre az xml-be. De attól még tárhatja...

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

Honnan lehetne kideriteni, hogy tarolja-e?

olvasd el az GDPR-es adatekzelesi tajekoztatojukat, benne kell legyen milyen adatokat mi celbol es meddig tarolnak :)))

Megkérdezed őket?

duplicate

Szia,

Az a kerdesem, hogy ez miert fontos? :D
Egyebkent a szamla kiallitasanak nincs IP cime. A szamla nem egy adott "IP cimen" keszul.

+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).

Nemhiszem, hogy a NAV annyira foglalkozna a gdpr-ral. De mondjuk egy birosag altal ez kikerheto adat, ami bizonyito ereju lehet egy ugyben?

Hogy jön ide a GDPR?
Mit akarsz bizonyítani egy NAV-nál tárolt / nem tárolt IP címmel?

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™

Elsőre elég értelmetlen kérdésnek tűnt (amúgy én leírnám az adatkezelési szabályzatban, hogy tárolom, és tárolnám), aztán eszembe jutott egy olyan, hogy a vitatott eseteket könnyebb így tisztázni... :)

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...

Azert eddig mi is eljutottunk :-)

amugy nektek megy most az oldal? nekem erre ures lap jon be:
https://onlineszamla.nav.gov.hu/

nem error, mert a forrasban vannak css includeok, csak content nincs.

É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é."

Update: a karbantartás 18:00 - 23:00 között fog zajlani.
--
Ickenham template engine

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 :)

Kicsit alulméretezték?

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

El.

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