nav-gov-hu / online-invoice Goto Github PK

A manageAnnulment leválasztásának leírását rövidebbre lehetne venne. A külön URL miatt technikailag nem lehetséges az ANNUL operációt keveredése a többivel, ezt ennél bővebben kifejteni felesleges.

A leírásból (számomra) nem világos, hogy a többi operáció (pl. CREATE és STORNO egyszerre) szerepelhet-e közös manageInvoice kérésben. A számlaláncok kezelésének új verziója elméletileg megengedné, hogy egy számlalánc több elemét egyszerre adjuk fel. Életszerűbb eset, ha egymástól független, de eltérő operációk egyszerre keletkeznek. Ezeket a jövőben lehetne küldeni egy tokennel?

#9

Az igény összefoglalása / Summary of the request
Az Online számla interfész rengeteg típusú WARN/ERROR üzenetet küldhet vissza. Az ügyfeleink döntő hányada ha egy ilyen választ lát, gyakorlatilag pánikolva hívja az support-ot, hogy gond van az interfésszel és azonnal megoldást várnak a problémára. Ez a pánikhangulat legtöbbször pillanatok alatt orvosolható, ha megadják számunkra a kapott figyelmeztetés és/vagy hiba kódját, amelyre a dokumentációban rákeresve részletesebb információt tudunk bizotsítani számukra, hogy az ő konkrét esetükben ez mit jelent. Lassan 1 év után se sikerült még rászoktatni az ügyfeleket arra, hogy a NAV hivatalos dokumentációját megnyissák és a részletesebb magyarázat, teendők segítségével maguk is feltárják a WARN/ERROR üzenetek jelentését, arról nem is beszélve, hogy ezek folyamatosan változ(hat)nak, ahogy egyik-másik megszűnik, miközben újabbak kerülnek bevezetésre.
Sokat javíthatna/gyorsíthatna az ügyfeleknél történő problémakezelésben, ha a rövid leírás mellett
az API a válaszában visszaadná a Működés/Teendő mezőben leírtakat is.

Példa: 530-as azonosítójú WARN üzenet (pdf 129. oldal)
Ezt kapjuk vissza az interfészen keresztül:
Kód: INCORRECT_HEAD_DATA_FISCALREPRESENTATIVE
Szöveg: Hibás pénzügyi képviselő adat.

Viszont ebből szerencsétlen könyvelő nem fogja tudni, hogy azért hibás, mert a megyekód nem 51, ugyanis ez a kiegészítő információ már csak a Működés részben van megadva.

Az előzőhöz hasonlóan a Technikai hibakódok, a Validációs hibakódok esetén is hasznos lenne a részletes leírás, teendők visszaadása.

Az általam javasolt megoldás / The solution I propose
Olyan dokumentációs felület kialakítása a jelenlegi pdf helyett, ahol egy egyszerű GET paraméterrel megadható a tag-ben érkező azonosító. Így egyszerűen összeállítható egy link, amivel egyből a dokumentáció megfelelő részére ugorhatnánk.

Elfogadható alternatívák / Acceptable alternatives
A businessValidationMessages, technicalValidationMessages, errorCode stb. részben visszaküldésre kerülne vagy a teljes link, amely a dokumentáció megfelelő helyére mutatna; vagy a jelenleg a pdf-ben megtalálható Működés/Teendő mező tartalmát adná vissza az interfész.

#7

Hello,
As developer I received the credentials from the client and tried to make a request to https://api-test.onlineszamla.nav.gov.hu/invoiceService/tokenExchange using following xml structure:

<?xml version="1.0" encoding="UTF-8"?>
<TokenExchangeRequest xmlns="http://schemas.nav.gov.hu/OSA/1.0/api">
    <header>
        <requestId>RID027473100156208548513577</requestId>
        <timestamp>2019-07-02T16:38:05.275Z</timestamp>
        <requestVersion>1.1</requestVersion>
        <headerVersion>1.0</headerVersion>
    </header>
    <user>
        <login>************</login>
        <passwordHash>*******</passwordHash>
        <taxNumber>*******</taxNumber>
        <requestSignature>*******</requestSignature>
    </user>
</TokenExchangeRequest>

On test environment (https://api-test.onlineszamla.nav.gov.hu/invoiceService/tokenExchange) response is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralErrorResponse xmlns="http://schemas.nav.gov.hu/OSA/1.0/api" xmlns:ns2="http://schemas.nav.gov.hu/OSA/1.0/data">
    <header>
        <requestId>RID027473100156208548513577</requestId>
        <timestamp>2019-07-02T16:38:05.275Z</timestamp>
        <requestVersion>1.1</requestVersion>
        <headerVersion>1.0</headerVersion>
    </header>
    <result>
        <funcCode>ERROR</funcCode>
        <errorCode>INVALID_SECURITY_USER</errorCode>
        <message>Helytelen authentikációs adatok!</message>
    </result>
</GeneralErrorResponse>

On live environment (https://api.onlineszamla.nav.gov.hu/invoiceService/tokenExchange) response is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TokenExchangeResponse xmlns="http://schemas.nav.gov.hu/OSA/1.0/api" xmlns:ns2="http://schemas.nav.gov.hu/OSA/1.0/data">
    <header>
        <requestId>RID027473100156208548513577</requestId>
        <timestamp>2019-07-02T16:38:05.275Z</timestamp>
        <requestVersion>1.1</requestVersion>
        <headerVersion>1.0</headerVersion>
    </header>
    <result>
        <funcCode>OK</funcCode>
    </result>
    <encodedExchangeToken>***********</encodedExchangeToken>
    <tokenValidityFrom>2019-07-02T18:39:53.475+02:00</tokenValidityFrom>
    <tokenValidityTo>2019-07-02T18:44:53.475+02:00</tokenValidityTo>
</TokenExchangeResponse>

Am I missing something? Because in this point cannot proceed to send invoice on live environment without proper testing, which fails as I described above.

#13

A módosító számlák kezelése átalakul a data sémaleíróban ….Új elemként megjelenik a modificationIndex, amelyben a kliens oldalnak kell a módosítás sorrendiségét jelezni. A tag értéke 1-től kezdődik, logikailag az első módosító vagy stornó számlának kell az 1-es értéket kapnia. A szerver oldalon az egyediség vizsgálatra biztosan ERROR kerül bevezetésre, a sorfolytonosság ellenőrzésének lehetőségét még vizsgáljuk.

Ez könnyen problémát okozhat azon módosító és stornó számlák esetén, melyek eredeti számláját egy másik számlázó rendszerben állították ki. Az aktuális számlázó rendszernek ugyanis nincs információja, történt-e és hány módosító vagy stornó számla kiállítás az eredeti számlát kiállító rendszerben, emiatt nem tud jó modificationindex értéket adni. Erre ajánlja megoldásként a NAV: A modificationIndex a /queryInvoiceDigest válaszában visszaadásra kerül arra az esetre, ha az alapbizonylatra több módosító okiratot állítottak volna ki eltérő számlázó rendszerekből, és a módosításkor nem ismert a helyes következő érték. Ehhez intelligens beküldést kellene megvalósítani, ami a válaszul kapott hibát elemezve előbb lekérdezi az utolsó modificationIndex-et a NAV-tól, beleírja helyes értéket az aktuális módosító számlába és újra beküldi a számlát.

Erősen strukturált rendszerek esetén egy ilyen intelligens kezelés kialakítása helyett javasolt alternatíva: az előzmény nélküli módosító számla létrehozásakor a számlázó rendszerben manuálisan kellene rögzíteni a NAV-tól (manuálisan) lekérdezett utolsó modificationIndex-et.

#36

#23

Az igény összefoglalása / Summary of the request
XSD1.1-be bekerült a unitOfMeasure. Fájóan hiányzik belőle egy pár érték, pl. négyzetméter, négyzetkilométer, négyszögöl, hektár, illetve a gramm.

Az általam javasolt megoldás / The solution I propose
Javaslom a UnitOfMeasureType lista bővítését a fentiekkel.

Elfogadható alternatívák / Acceptable alternatives

Egyéb tartalom / Additional content
Köszönöm.

Az igény összefoglalása / Summary of the request
Bejövő számláknak adószámra (is) történő lekérdezésekor legyen lehetőség nagyobb időintervallum megadására.

Az általam javasolt megoldás / The solution I propose
A jelenlegi 35 nap helyett fogadja el a rendszer egy adott napot megelőző év január 1. és az adott nap közötti időszakot: WHERE ... YEAR(időszak_kezdete) >= YEAR(időszak_vége) - 1. Ezt csak akkor engedje meg a rendszer, ha az adószámot (is) megadjuk lekérdezési paraméterként, más esetekben (tehát ha az adószámot nem adtuk meg) maradhat a 35 napos intervallum.

Elfogadható alternatívák / Acceptable alternatives
Ha az intervallum megnövelése túl sok vizsgálatot eredményez abban az esetben, ha az adószám mellett másra is keresünk, akkor elfogadható a megoldás úgy is, ha a rendszer csak akkor engedi a nagyobb intervallum megadását, ha kizárólag az adószámot adjuk meg keresési feltételként.

Egyéb tartalom / Additional content
Egy rendkívül hasznos funkció lenne egy partner bejövő számláinak lekérdezésekor, ha nemcsak 35 napot lehetne lekérdezni, hanem hosszabb időszakot. Mivel a cégek éves bevallása nem azonos időszakra esik (január 1., május 31.), ezért javaslom azt, hogy a lekérdezéskor a fenti időszakra lehessen lekérdezni. Ez mind könyvelői oldalról, mind felhasználói oldalról nagyon hasznos lenne. Jelenleg, ha le szeretném kérdezni egy konkrét partner számláit, akkor ezt csak 35 napos bontásban tehetem meg.

Könyvelési szempontból a teljesítési dátumnak van jelentősége, így ennél a mezőnél mindenképp javaslom a fenti módosítást. Ha a rendszer rugalmas működése megengedi, akkor ezen kívül mind a kiállítási dátumnál, mind a fizetési határidőnél javaslom a bevezetését.

#15

#3

#23

Az igény összefoglalása / Summary of the request
A bejövő számlák lekérdezésekor legyen lehetőség a lekérdezésre a számlakibocsátó nevének részlete alapján.

Az általam javasolt megoldás / The solution I propose
Az AdditionalQueryParamsType típus kiegészítése egy "supplierName" (vagy hasonló) mezővel. A rendszer a válasz üzenetben adja vissza az összes olyan számlát, ahol a számlakibocsátó neve tartalmazza a megadott értéket (... WHERE nev LIKE "%supplierName%"). A vizsgálatot csak akkor hajtsa végre, ha legalább [n] karaktert megadtunk a mezőben. [n] értékét úgy kellene meghatározni, hogy a rövid nevű cégek esetén is adjon vissza találatot (pl. n>=5).

Elfogadható alternatívák / Acceptable alternatives
Ha a rendszert túlságosan leterhelné a részleges névegyezőség vizsgálata és ez alapján az eredményhalmaz visszaadása, akkor elfogadható lenne az is, ha csak a név elejét vizsgálná az egyezés szempontjából (... WHERE nev LIKE "supplierName%").

Egyéb tartalom / Additional content
Jelenleg csak adószám alapján lehet beazonosítani az egy konkrét partner által kibocsátott számlákat. Ez abban az esetben jó megoldás, ha ismerjük a partner adószámát. Ha a partner már partnerünk (a rendszerünkben tároltuk az adószámát), akkor ez a lehetőség működik. Ha viszont még nem partnerünk, akkor először meg kellene keresni valamilyen rendszerben az ő adószámát, majd erre rákeresni.

Ha valaki olyan rendszert fejleszt, ahol nem kívánja tárolni a bejövő számlákat (mert a NAV-nál úgyis megvan), akkor bármilyen bejövő számla kereséses esetén először meg kell keresnie valahol a számlakibocsátó adószámát, majd erre tud rákeresni. A konkrét partnerre történő keresés ilyen esetben tehát nagyon sokáig tart.

A fenti működést mindenképpen javasolt megvalósítani az online számlázó felületen is, hiszen ott sincs lehetőség a számlakibocsátó nevére keresni, csak az eladó adószámára lehet.

A NAV részéről érthető, hogy az adószámot veszi alapul (az a "kulcs" mező), de a felhasználók szempontjából mindenképpen előnyös és hasznos funkció lenne, ha az adószám mellett a névre történő keresés lehetősége is meglenne. Főleg akkor, amikor a jövőben már minden számláról történik majd kötelező jelleggel adatszolgáltatás, ÁFA értéktől függetlenül. De mivel már most is vannak cégek, amelyek ezt választják, a funkciót érdemes lenne a 2.0 indulására beépíteni.

#9

#31

A CRC32 ellenőrző algoritmust le kell váltani egy kritográfiai hash függvénnyel, ami a teljes üzleti tartalmat védi.

Ugyan mitől védi, amitől a TLS és az üzemeltetési körülmények nem? Kérek rá életszerű példát.
A felesleges integritási tákolást és redundáns kriptográfiai bonyolításokat meg kellene szüntetni. A TLS gondoskodik az integritásról, titkosításról, és szerencsésebb lenne az azonosítást (autentikációt) is azzal megoldani. Ehhez szabványos megoldások, alaposan tesztelt programkönyvtárak, keretrendszerek léteznek.
A jelenlegi (1.x) interfésznél is problémás, hogy a base64Binary típusú invoice JAXB objektum kódolt tartalmához hozzá kellene férni marshalling, kódolás előtt a CRC számításához. Jó esetben pontosan elő tudjuk állítani a JAXB-ével pontosan megegyező Base64 kódolást külön menetben is, de ez nem triviális.

Javasolt megoldás:
Egyszer használatos tokenek, lenyomatok, aláírások eltávolítása az XML-rétegből, és ezek helyettesítése szabályos TLS-hitelesítéssel, kliens-tanúsítvánnyal.

Vannak szolgáltatások (pl. kiterjesztett garancia), amit egy időszakban folyamatosan teljesít az eladó. Ennek megadása az xsd-ben a számlafejben van. Ez rendben is van, ha végfelhasználónak számlázunk. De mi mint disztributor, egy számlázási periódusban akár 100 ilyet is eladunk egy dealernek. Természetesen mindegyik más-más autóra vonatkozik, így más a kezdő és végdátum is. Ezért a gyűjtőszámlán a számlasorokban adjuk meg ezeket az adatokat. Ezek továbbítása az online rendszerbe additionalData-ként történik jelenleg.

Ha a NAV-nak lényeges ezen adatok ismerete és feldolgozása, akkor lehetővé kellene tenni line szinten is a megadást. Nekünk megfelel a jelenlegi megoldás is, de az nyilván nem dolgozható fel a NAV oldalán. 3 adatot adunk meg plusszban: mire vonatkozik (alvázszám), mikortól, meddig.

A V2-ben lehetőség lesz a beérkező (vevői) számlák lekérdezésére.
Az ehhez ügyfél oldalon szükséges programokat is ki kell fejleszteni és le kell tesztelni.
A kérdés az, hogy milyen adatbázissal? A jelenlegi tesz környezet egy adott ügyfélnél nem biztos, hogy tartalmaz bejövő számlákat, mert a partnerek fejlesztői más ügyféllel is tesztelhettek. Ezért elképzelhető, hogy nincs, vagy csak nagyon szűk lehetőség van a tesztelésre a jelenlegi teszt adatokkal.
Megoldási javaslatom igazán nincs, csak azt tudom elképzelni, hogy a teszteléshez valamilyen módon az éles rendszer adatbázisát lehetne használni.

A számlatétel advanceIndicator mezője a jelenlegi Boolean helyett legyen Enumeration típusú, az alábbi jelentésekkel:

• nem előleg
• előleg vagy ügylet meghiúsulása miatti előleg sztornó
• végszámlában beszámított (korábban számlázott) előleg

A dokumentációban található, hogy a PROCESSING és a DONE státusz között meg fog jelenni a SAVED státusz is, mely esetben már lekérdezhetőek a számla adatai, arra módosító vagy stornó adatszolgáltatás küldhető. Ezt követően lesz a státusz DONE vagy ABORTED.

Módosító számlák esetében a modifyWithoutMaster elemet is szükséges küldeni.
Amennyiben olyan alapszámlára hivatkozunk, mely már be lett küldve, de még SAVED státuszban van, akkor a modifyWithoutMaster elem false értéke elfogadásra kerül?
Gondolok itt arra, hogy SAVED után még ABORTED is lehet a számla..
Jelenleg az INVALID_INVOICE_REFERENCE error kerül visszaadásra, ha a módosítás vagy érvénytelenítés által hivatkozott számla nem található meg az adózó számlái között a rendszerben, és a kérésben nem jelölték, hogy a módosításhoz nem tartozik korábbi adatszolgáltatás.

Van-e mód arra, hogy lekérdezhetővé válljon a csoportazonosító, illetve a /queryTaxpayer válaszban esetleg megkapjuk a csoportazonosítót is?

Mi gyűjtőszámlákat használunk, ezért ebből (és csak ebből) a szempontból néztem az invoiceData xsd-t.
Kiemelték a legfelső szintre az invoice numbert és a invoice date-et, de csak ezeket.
Módosító gyűjtőszámla esetén ez alá jönnek a batchInvoice-ok (honnan ez a név?), amik az egyes módosított számlák adatai. Ezek mind invoice típusuak, vagyis mindnek van invoicehead, stb. része.
Ez nem felel meg a valóságnak, egy számlánál csak egy vevő, eladó, stb. van, vagyis ezeknek az adatoknak szerintem szintén a számlaszámmal és dátummal együtt a kiemeltek között kellene lenni.

Mivel az egész módosító gyűjtőszámla egy invoiceData-ben van, nem hiszem, hogy gondot okozna a feldolgozásnál, ha több olyan adat lenne, ami mindegyik módosított számlára közös. A batchInvoce-ban az invoice helyett meg lehetne invoceReference-t, az invoiceLines,stb használni. A batchInvoice meg lehetne inkább modifyInvoce vagy hasonló :).

Ha így marad, akkor ez nem lesz megoldás pl. a e-434690(75) promlémámra sem, ami "észrevételét továbbítjuk a fejlesztők felé" állapotban van. Ez a teljesítés dátuma probléma: egy módosító gyűjtőszámlának egy teljesítési dátuma van, nem szabadna rész-számlánként nézni azt, ahogy jelenleg teszik , és ahogy ezzel a xsd-vel is lesz. Mármint szerintem.

#13

Az igény összefoglalása / Summary of the request
Az adózó telephely adatainak lekérdezése a queryTaxpayer operáció meghívásával.

Az általam javasolt megoldás / The solution I propose
A TaxpayerDataType típus bővítése a taxpayerSitesAddress elemmel, melynek típusa data:DetailedAddressType elemből álló tömb lenne (minOccurs="0"), mivel egy adózónak több telephelye is lehet.

Egyéb tartalom / Additional content
A partnerek részéről felmerült jogos igény, hogy az adószám lekérdezésekor az adózó székhely címe mellett lekérdezhető legyen a telephelyek címe is, mivel sok esetben nem a székhely nevére kell kiállítani a számlákat. A NAV weboldalán jelenleg van lehetőség egy adózó telephely címeinek lekérdezésére, így az információ a NAV rendszerében rendelkezésre kell, hogy álljon. A https://nav.gov.hu/nav/adatbazisok/adatbleker/afaalanyok/afaalanyok_egyszeru oldalon rákeresve az adószámra, majd a találatok közül kiválasztva a megfelelőt, a következő oldalon megjelenik az adózó telephelyeinek listája.

A queryTaxpayer operáció meghívását követően a program felajánlaná a székhely mellett a telephelyek címét is, így a felhasználó ki tudná azt választani egy listából.

Ennek előnye többek között az lenne, hogy már a kiállításkor ellenőrizni lehetne, hogy valóban a megfelelő címre történik-e meg a számla kiállítása. Adott esetben visszafelé is jótékony hatása lenne: ha a vevő olyan címre kéri a számlát, ami nem szerepel a telephelyek között, akkor jelezni lehet a vevőnek, hogy a NAV felé jelentse be a telephelyet, ha esetleg elfelejtette volna. (Nyilván a számla kiállítását ez nem akadályozná, mert olyan eset is lehet, hogy a NAV még nem vett nyilvántartásba egy címet.)

Az invoiceReference csomópontból törlésre kerül a modificationIssueDate, a modificationTimestamp és a lastModificationReference. A törlendők közül a modificationIssueDate fogalmilag összevonásra kerül az invoiceIssueDate taggel, így az a 2.0-tól a számla VAGY a módosító okirat kiállítását jelenti. A többi törölt taget a 2.0-ban nem kell küldeni. Új elemként megjelenik a modificationIndex, amelyben a kliens oldalnak kell a módosítás sorrendiségét jelezni. A tag értéke 1-től kezdődik, logikailag az első módosító vagy stornó számlának kell az 1-es értéket kapnia. A szerver oldalon az egyediség vizsgálatra biztosan ERROR kerül bevezetésre, a sorfolytonosság ellenőrzésének lehetőségét még vizsgáljuk. Amennyiben megvalósításra kerül a sorfolytonosság ellenőrzése is, úgy elképzelhető, hogy a szerver oldali feldolgozásba késleltetés kerül be, ekkor - feltéve, hogy az alapszámla már beérkezett a rendszerbe-, adott időkeret állna rendelkezésre az egyes módosító okirat adatszolgáltatására, és a sorfolytonosság csak a késleltetési idő leteltét követően kerülne vizsgálatra. A modificationIndex a /queryInvoiceDigest válaszában visszaadásra kerül arra az esetre, ha az alapbizonylatra több módosító okiratot állítottak volna ki eltérő számlázó rendszerekből, és a módosításkor nem ismert a helyes következő érték.”

Ezzel a változással a tétel szintű /invoiceLines/line/lineModificationReference/lineNumberReference is értelmét veszti? Vagy ezt továbbra is tölteni kell sorfolytonosan a módosító számlákban?

A lekérdezésekkel kapcsolatban megint a saját szempontjaimat fogom kifejteni, mások szempontjait majd ti figyelembe veszitek.

A lekérdezési lehetőségek közül az használja a rendszerünk, amely egy adott számlaszámra kérdez rá. Minden módosító számla feladása előtt ellenőrzi, hogy megvannak-e a hivazkozott számlák. Ehhez viszont nincs szükség arra, hogy visszakapjuk magát a számlát (base64-ben), azt mi is ismerjük, csak a státusza (van/nincs) érdekel. Az adatátvitel nagyobb része viszont éppen a számla.
Tehát lehetne egy olyan kapcsoló a lekérdezésben, hogy kérem a számla részletes adatait vagy sem. (Ugyan ez vonatkozik a módosítókra is ilyenkor). Kis változtatás lenne a programban de nagy az adatátvitel mennyiségében. Én úgy gondolom, hogy sokan használják erre a célra ezt a lekérdezést.

A rendszer bevezetése óta várunk a vevői számlák lekérdezhetőségére. Igazából feltehetőleg minden számla érdekel majd bennünket, főleg amelyeknél sikerül megoldani az elektronikus bevételezést (a többinél elég lesz, ami a digest-ben jön).
Viszont a lekérdezéshez lenne egy ötletem. A jelenlegi lekérdezési lehetőségek (számla kiállítási dátum, teljesítés dátum) mellett kellene egy olyan, hogy a 'DONE-ba menetel dátuma (és ideje)'. Az előző lekérdezéseknél ugyanis lehet olyan számla, ami utólag érkezik (mert pl. hibás és csak a következő napon javítják), így viszont mindig egy jó nagy adagot kell lekérdezni visszamenőleg is, hogy ne maradjon ki számla, azután jöhet az ellenőrzés, hogy ez már megvan ez meg feldolgozandó.
Egy ilyen DONE-os dátum lehetőség esetén (főleg ha még időpont is megadható lenne) minimalizálni lehetne a lekérezett adatok mennyiségét és a feldolgozást: az előző lekérdezés adatait megadva éppen a jó adatok jönnének.

Szia!
Tudom nem a V2-höz kapcsolódik, de az online-szamla felület nagyon idegesítő hibáit is jó lenne ha kijavítaná valaki, mert nálunk csapódik le és nagyon fárasztó ezzel foglalkozni sok ügyfélnél. Remélem eljut az illetékesekhez:

1. A felület a technikai felhasználónál elfogad közepes, vagy gyenge jelszót. DE utána a feltöltés nem megy, mert csak Erős jelszóval működik az adatfogadás. Jó lenne, ha már az API nem fogad csak erős jelszót, akkor a felület sem engedne nem erős jelszót megadni. Elég fárasztó ilyenkor átvergődni ezen az ügyféllel, amikor sokszor a könyvelője csinálta a regisztrációt is és az ügyfél be sem tud lépni a online számla felületére. (Rengetegszer ez volt - van!)

2. A technikai felhasználó jogosultságainál van egy "Összerendelések" gomb, ami nem egyértelműen látható, hogy mire való lenne. Kiderítettük, ha ide ír valaki valamilyen adószámot, akkor csak azokat fogadja el az API. Na ennek nem sok értelme van mert a számlázóban veszik fel a vevőt és utána senki nem jön ide is még beírni az adószámát a vevőnek. Viszont ha van itt valami, akkor onnantól más adószámokat nem fogad az API rendszerük. Az egyik ügyfelünk tévedésből ide beírta a saját adószámát és utána egy darab számlája sem ment fel a rendszerbe, mert visszautasította a szerver.

3. Nem értjük azt sem, hogy a technikai felhasználónak miért nincs alapban kikapcsolhatatlan "Számlák kezelése", "Számlák lekérdezése" vagy legalább a sajátoké. Ez is állandó probléma forrás, hogy nem adnak semmi jogot, vagy a lekérdezést nem adják meg a technikai felhasználónak. Mivel a rendszerük asszinkron feldolgozású ezért feltöltés után tudnunk kell, hogy felment-e a számla, mielőtt pl. egy sztornót, módosítót küldünk rá. Mert ha még nem dolgozták fel és nincs DONE státuszban, akkor jön a hiba, hogy nincs előzmény bizonylat.
   Ha valaki kiállít egy számlát és rögtön sztornózza is, mert elrontotta, akkor nem küldhetjük fel (talonban tartjuk), amíg az eredeti számla a rendszerükben történt befogadásáról lekérdezéssel nem győződtünk meg. Tehát a két jog szétválasztása csak problémákat szül a gyakorlatban és amúgy sem látszik értelme technikai felhasználó esetén. Az első előadásukon azt is mondták, hogy figyelik majd, hogy a szoftverek visszakérdezik-e a feltöltés eredményét -> Egy ilyen beállítással nem igazán megy az sem.

4. A kimenő számlák listájában megjelenik a nettó, bruttó összeg normál számlák esetén. Viszont ha egyszerűsített számláról van szó, akkor a nettó és bruttó oszlopban sincs adat.

5. A XML 1.1-ben bevezetett egységeknél sokszor kell használni az OWN jelzést és utána megadni, hogy mi az. PL négyzetméternél. A felületükön ha valaki megnéz egy ilyen számlát azt látja, az egységeknél, hogy Saját, viszont ide kiírhatnák mögé, hogy mi az, ha már mi megadjuk. Mert azért elég furcsán néz ki például az, hogy: mennyiségi egység meghatározható-e: Igen és után ez jön Burkolólap 5 Saját 5000 27% 25000

Az igény összefoglalása / Summary of the request
Az adózó rövid nevének lekérdezése a queryTaxpayer operáció meghívásával.

Az általam javasolt megoldás / The solution I propose
A TaxpayerDataType típus bővítése a taxpayerShortName elemmel, melynek típusa data:SimpleText512NotBlankType lenne, és az adózó rövid nevét tartalmazná.

Egyéb tartalom / Additional content
A partnerek részéről felmerült jogos igény, hogy az adószám lekérdezésekor az adózó teljes neve mellett a rövid nevét is le tudjuk kérdezni. A számlákon sok esetben az adózó rövid nevét tüntetik fel. A teljes név lekérdezése segíti ugyan a kitöltést, de ebbe az esetek nagy többségében "bele kell nyúlni". A számlázó programok segíthetik a felhasználót azzal, hogy a cégformákat automatikusan rövidítik (pl.: korlátolt felelősségű társaság --> kft.), de a név sok esetben még így is hosszú. Ha a TaxpayerDataType típus tartalmazná az adózó rövid nevét is, akkor a queryTaxpayer operáció meghívását követően a felhasználó ki tudná választani, hogy a rövid vagy hosszú nevet szeretné a számlán megjeleníteni.

Az igény összefoglalása / Summary of the request
.NET környezetben az "xs:dateTime" típusnál nem lehet garantálni a megadott 3 jegyű ezredmásodperc formátumot. Emiatt mindig át kell írni az XSD-ben "xs:string" a típust.

Az általam javasolt megoldás / The solution I propose
Elfogadhatná a 0-3 jegyű ezredmásodperc értékek bármelyikét.

Az igény összefoglalása / Summary of the request
When modifying an invoice, we have to transmit the line number in sequence added to the original invoice lines. Example: Invoice with 3 line items has the lines 1,2 and 3. The update would have the lines 4 (reference item 1), 5 (reference item 2) and 6 (reference item 3). This is a huge challenge for most of the ERP systems to provide

Az általam javasolt megoldás / The solution I propose
My proposal would be, to transmit the modify document with the reference to the original document (what is already implemented) and an own sequence. Example: Invoice with 3 line items 1, 2 and 3. The modify document would have the line items 1 (reference item 1), 2 (reference item 2), and 3 (reference item 3). This would make it much easier to modify a document.

Elfogadható alternatívák / Acceptable alternatives
The alternative would be to cancel the initial invoice and submit a new one.

Egyéb tartalom / Additional content
This has been a pain point in most of the projects in the past. It would be a pleasure to have a new technique in future releases.

Az igény összefoglalása / Summary of the request
A krasa-jaxb-tools-t használom objektum generálásra, és nem szereti a "0.00"-t, viszont a "0"-val működik.

Az általam javasolt megoldás / The solution I propose
Az invoiceData.xsd-ben az ExchangeRateType.restriction.minExclusive jelenleg "0.00". Helyette lehetne "0"?

Elfogadható alternatívák / Acceptable alternatives
A probléma nem kritikus, könnyű az xsd-t javítani, de ha nem jelent lényegi változást a "0", akkor jó lenen ha gyári xsd-ből tudnánk generálni és nem kellene kézzel szerkeszteni.

A hibás dokumentum neve / Document name containing the error
https://onlineszamla.nav.gov.hu/api/files/container/download/Data%20sample%20XML.zip

A dokumentációs hiba leírása / Description of the documentation error
Nem kifejezetten hiba, de az 1.1-hez megjelent dokumentációk és a példák eléggé homályban hagytak, hogyan is kéne ezt használni.
Az egy szem példában amit találtam, a következő szerepel:

<unitOfMeasure>PACK</unitOfMeasure>
<unitOfMeasureOwn>doboz</unitOfMeasureOwn>

Az sem világos, hogy miért tér el pont ez a sor a többitől, ahol darab és kilogramm van? Ez alapján nem kéne oda is kg?

Ezzel a „sorok közt” azt javasoljátok, hogy az összes hasonló esetet (mint dózis, üveg, adag) mint PACK adjuk fel, a saját kiírt egységgel kiegészítve?

Mi a helyzet azokkal ahol nincs ilyen megfeleltethetőség, mint a gramm a tonna? Ezeknél lehetne használni a unitOfMeasure OWN-t, de erre egy példa sincs.

#10

#16

Hello,
i am Product Manager for eInvoicing, eTax and PEPPOL at SEEBURGER.
SEEBURGER is worldwide locted and Provider for Solutions like NAV to our customer. What i am missing and would be very helpful is a test system similar like FatturaPA Italy (SDI) or MTDfB / HMRC in UK. What means we can send any "test Invoices" to this testsystem and would get a Response from NAV as well before we implement our solution to all our customer straight in a productive landscape.
Is there a plan in the nearest future to get a test System?

Thanks
Best Regards

Andreas Killinger

Az igény összefoglalása / Summary of the request
Nem igazán volt jó ötlet UTC-ben megadni az időbélyegzőket.
Például így összeférhetetlenség van a TimeStampType és a DateType között.
Időzónától függően napváltás körül, a módosító számla kelte és a módosítás időpontja nem ugyanarra a napra fog esni.

Az általam javasolt megoldás / The solution I propose
Helyi idő + időzóna használatának lehetősége TimeStampType esetén. Így nem veszik el az az információ, hogy melyik időzónából történt a feladás, és az UTC idő is könnyedén kinyerhető lenne, és még az időbélyeg és a dátum se veszne össze.

Elfogadható alternatívák / Acceptable alternatives
Időzóna jelölése valahol a HEADER környékén, és WARN mentesítés az ilyen esetekre.

Érdeklődnék, hogy akkor most mi a helyzet ezzel a fórummal és a V2-vel?
Két hét óta a NAV részéről nincs hozzászólás.
Lejárt a V2 véleményezésére adott határidő, de számos kérdés van függőben. Vagyis még el sem indult a V2, de már csúszásban van. Lesz egyáltalán? Valamikor?

Sziasztok!

Nem feltétlen ehhez a repohoz tartozik, de a dokumentációban található hibák jelzésére is lehetne valami módot találni és ha már elkezdtetek itt felületet kialakítani, akkor lehetne ennek is helyet teremteni.

Pl: lineExpressionIndicator kötelző, de a táblázatban 67. oldalon nem kötelező.

Lehetne a Word doc-ból generált PDF vonatkozó részeit közvetlenül az XSD-ből összeállítani (mert ott jól van).

#3

ProductCodeCategoryType új enum értéket kap (TESZOR), az új pattern hossz 5-ről 6-ra nő

ez továbbra is opcionális, vagy be kell vezetni, hogy a számlázó rendszerek ezt is továbbítsák?

#34

Az igény összefoglalása / Summary of the request
Deklaráltan két cél van a NAV részéről az OSZ megszületésénerk : #1 ellenőrzés, #2 jövőben bevallás készítése a NAV oldalon. Ezek egyikse sem indokolja hogy ennyi kötelező adatot kelljen beküldeni.

Az általam javasolt megoldás / The solution I propose
Csak a fenti két célt szolgáló adatok töltése legyen kötelező.

Elfogadható alternatívák / Acceptable alternatives
Opcionálisan egy base64 mezőbe betölthető adat ami a vevő publikus kulcsával került titkosításra még a feladó oldalán, így a vevő a számla letöltésnél támogatást kap a számlaadatok beemelésére a saját ERP rendszerébe., viszont a NAV így nem látna rá olyan adatokra ami nem tartozik rá, csak a vevőre és a szállítóra.

Üdv!
Megnéztem az új (várható) XSD-t, és reménykedtem, hogy a digest-re felkerül a fizetési határidő mint információ.

Nagyon sok olyan eset van, amikor ez az információ fontos, sőt, a mi szoftverünkben szinte mindig. És ha a digest-en meglenne, 100-ból 95 alkalommal el sem kellene mennünk egy újabb lekérdezéssel a részletes számla adatokért, mert minden meglenne. Most az esetek nagy részében csak amiatt intézünk újabb request-et a részletes számla adatok lekérdezésére, mert ez az infó kell.
Ha a 2 másik fontos dátum rajta van, akkor harmadikként ezt a dátumot nem lehetne még odaszorítani?
:)

Azt már csak úgy félve kérdezem-javaslom, hogy a query paraméterekbe is szerintem hasznos lenne (digest-ek lekérdezésénél), valószínűleg nem mi lennénk az egyetlenek, akik szeretnének úgy szűrni, hogy a fizetési határidőt (intervallumot) megadják.

Tényleg fontos dátum, azt is meg merem kockáztatni hogy fontosabb mint az invoiceDelivery dátum.

Szerintem az ügyfél oldalon egyszerüsítené a munkát, ha nem kellene operation + base64 stringet képezni az SHA3 előtt. Az operation mehetne a request signature-be magába a base64 SHA3-a elé.
Persze a tervezetben leírtak szerint is meg lehet csinálni.

Szia,

Vevő oldali számlalekérdés esetén, terveztetek-e bármi értesítést küldeni egy új számla feltöltéséről, ha igen akkor hogyan?

Javasolt lenne egy kliens oldalról állítható változó létrehozása, valamint erre API-n keresztűl szűrési lehetőség is, az új beérkezett számlákkal kapcsolatban. pl isDownloaded true/false