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

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.

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

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

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.

http://www.nav.gov.hu/data/cms439105/OnlineSzamlaKozlemeny.pdf

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

sub

-

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

-

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.

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

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

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

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.

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.

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

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

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)

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?

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());

}

}

}

subs
--
♙♘♗♖♕♔

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);
}

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)

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.

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

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?

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.

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

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

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?

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.

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.

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?

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?

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.

https://github.com/pzs/nav-online-invoice

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

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"

http://www.atv.hu/belfold/20180630-bejelentest-tett-a-penzugyminiszter-…

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

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!