Namespace alkalmazása a dokumentáció szerint hibát eredményez.

[EnokhSys]

Kedves @NTCA-supporter és @NTCA-developer!

Lehet, hogy csak én nem értek valamit a namespace-k alkalmazásával kapcsolatban, de az is lehet, hogy hibás a dokumentáció.

Az XML elején definiáltam, hogy xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base". (Teljesen mindegy, definiálhatnám akár "ns2"-nek is.) Ez így rendben is van, ha csak az adószámnál és a címnél használom, a számlafeldolgozás problémamentesen megtörténik.

Viszont, ha a számla típusánál használom így "base:invoiceCategory", vagy a teljesítés dátumnál így "base:invoiceDeliveryDate", akkor "schema violation"-nal hibára fut a feldolgozás:

XML contains on line: [51] and column: [33] error: [cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://schemas.nav.gov.hu/OSA/3.0/base":invoiceCategory}'. One of '{"http://schemas.nav.gov.hu/OSA/3.0/data":invoiceCategory}' is expected.]

Azért nem értem a dolgot, mert a dokumentációban szerepel a namespace alkalmazhatósága a számla típusnál és a teljesítés dátumnál:

ugyanúgy mint az adószámnál is, ill. a címnél is:

Na most akkor az a kérdésem, hogy a dokumentáció szerint, mikor kell használni a namespace-t és mikor nem? Remélem értitek a problémámat: mind a négy szegmens leírásában szerepel a "base:" namespace alkalmazása, viszont, ha a számla típusnál és a teljesítés dátumnál használom, akkor hibára fut.

[kabelnet2]

Az invoiceCategory az az invoiceData-ban van definiálva. Az alaptípusa, az invoiceCategoryType az valóban a base-ben van, de ezzel neked nem kell foglalkozni. A 'Simple Type' oszlopban az van, hogy a típusa hol van definiálva, de ez már meg van adva az invoiceData-ban, neked nem kell ezzel foglalkozni. Hasonlóan a supplierAddress, ami egy base-ben definiált AddressType típus. Ezért ahogy a changelog írja, a supplierAddress az az invoiceData-ban van, nem kell elé semmit tenni (ha az invoiceData az alap). Viszont amikor meg akarod adni a supplierAddress elemeit (pl. postalCode), azok már a base-ben vannak definiálva, ezért azok előtt meg kell adni a base namespace azonosítóját. Minden xml-ben van/lehet egy alap namespace, aminek nincs neve, azt nem kell (és nem is lehet megadni) azok előtt az elemek előtt, amik abbanm vannak definiálva. Minden más előtt meg kell adni azt a namespace-t, amiben definiálva vannak.

[EnokhSys]

Kedves @kabelnet2, nagyon köszönöm a felvilágosítást. Biztos én vagyok nehézfejű, de továbbra sem tiszta a kép. Azt írod, hogy:

Viszont amikor meg akarod adni a supplierAddress elemeit (pl. postalCode), azok már a base-ben vannak definiálva, ezért azok előtt meg kell adni a base namespace azonosítóját.

Ezzel szemben, elolvasva a "2.1.3.1 Egyszerű címadat" fejezetet, amely minden címadatra vonatkozik, nem a "base:", hanem a "common:" szerepel:

Minden xml-ben van/lehet egy alap namespace, aminek nincs neve, azt nem kell (és nem is lehet megadni) azok előtt az elemek előtt, amik abbanm vannak definiálva. Minden más előtt meg kell adni azt a namespace-t, amiben definiálva vannak.

Ezt én értem. De honnan tudom megállapítani a doksiból, hogy melyik az a "minden más" csoport, ahol meg kell adnom? Azt tudnod kell, hogy több száz vagy ezer fejlesztőhöz hasonlóan, én sem használok XSD-t, mert nem olyan programnyelvben / fejlesztőeszközben dolgozunk, amellyel ezt könnyen-vagy egyáltalán implementálni lehetne.

[kabelnet2]

Ez a common ügy, nyilván hiba, mert az AddressType (CountryCode,POstalCode) az az invoiceBase-ben van definiálva, míg a SimpleText típusok valóban a common-ban. Én azt javaslom, ne a doku-t olvasd (majd biztos javítják, de addig...), hanem a changelog3.0-t. Szerintem az egy jól összehozott dokumentum, megtalálható itt a github-on. Annak alapján tökéletesen le lehet generálni az xml-eket. Azt, hogy milyen namespace-eket és milyen néven használnak egy xml-ben az xml fejléce tartalmazza, azok az xmlns: kezdetű sorok. A beérkező üzenetek elemzésénél pedig mivel nem használsz xsd-t (vagyis pasert), javaslom hogy egy előtét eljárással/programmal vegyél ki minden namespace nevet az xml-ből és utána elemezd. Néhányan már javasoltak is ilyen programot/eljárást néhány nyelven a prog.hu-n.

[EnokhSys]

Én azt javaslom, ne a doku-t olvasd (majd biztos javítják, de addig...), hanem a changelog3.0-t. Szerintem az egy jól összehozott dokumentum, megtalálható itt a github-on. Annak alapján tökéletesen le lehet generálni az xml-eket.

Ez a changelog3.0 ugyanaz, mint a dokumentáció 5.4-es fejezetében található 3.0-ás veriókövetés? Mert azt már elolvastam. Egyébként hol találom itt a github-on? (Néztem a https://github.com/nav-gov-hu/Online-Invoice/tree/master/docs/API%20docs/hu alatt, de ott ugyanez a fejlesztői doksi van, mint a "https://onlineszamla.nav.gov.hu/dokumentaciok" oldalon.)

Azt, hogy milyen namespace-eket és milyen néven használnak egy xml-ben az xml fejléce tartalmazza, azok az xmlns: kezdetű sorok.

Az ég szerelmére, ezzel tisztában vagyok. Definiálhatnám "gandalf" namespacenek a "http://schemas.nav.gov.hu/OSA/3.0/base" URL-t és "voldemort"-nak a "http://schemas.nav.gov.hu/NTCA/1.0/common" URL-t. A doksi szerint az nem világos számomra, hogy mikor kell a fehér varázslót a szegmens elé tennem, és mikor a sötétet. (Még akkor sem, ha elkezdem kibontani egy adott szegmenscsoport felépítését, és a végső szegmensek a leírását nézem, mert amint jelen esetben is láttad, a postalCode nem okés ebből a szempontból.)

A beérkező üzenetek elemzésénél pedig mivel nem használsz xsd-t (vagyis pasert), javaslom hogy egy előtét eljárással/programmal vegyél ki minden namespace nevet az xml-ből és utána elemezd. Néhányan már javasoltak is ilyen programot/eljárást néhány nyelven a prog.hu-n.

Köszi, de szerencsére nincs szükség előtételjárásra, a NAV szervere a válaszában olyan namespaceket ad vissza amilyet akar, akár mindegyik szegmens elé odatehet tetszőleges namespace-t, magát az adatot így is ki tudom olvasni egy erre szolgáló függvénnyel. Tehát a bejövő oldallal szerencsére nem kell foglalkoznom, engem csak a kimenő oldal érdekel, hogy helyesen-, a leírásnak megfelelően adjam át a szegmenseket, a hozzájuk tartozó namespacekkel (tökmindegy minek nevezem el őket).

[renced42]

@EnokhSys próbáltam egy minden mezőt, choice-t felsoroló XML-t generálni (tehát ez nem XSD valid) amiben benne van, hogy melyik mezőben mint kellene használni. Meg egy XSD valid állományt. Remélem ebből sikerül kideríteni a névtér használatot :)

invoiceData.txt invoiceDataXSDValid.txt

[kabelnet2]

Nem tudom mi van a doku-ban, amikor én használtam a changelog-ot még nem volt doku (https://github.com/nav-gov-hu/Online-Invoice/blob/master/src/schemas/nav/gov/hu/OSA/CHANGELOG_3.0.md) De ha ugyan ez van a doku-ban és olvastad, akkor mi a probléma? "Három komplex adattípus esetében át kell vezetned a Base XSD namespace értékét a gyermek tagekben. Ezek a magyar adószámot leíró TaxNumberType (törzsszám, ÁFA kód, megyekód) illetve a címtípusok, függetlenül attól hogy egyszerűsített (SimpleAddressType) vagy tagolt (DetailedAddressType) címekről van-e szó. Ezt a módosítást minden olyan helyen át kell vezetned, ahol a felsorolt típusok a Data XML-ben előfordulhatnak. Figyelj rá, hogy ez nem olyan namespace módosítás mint ami az API-nál van, itt a szülő tag nem kaphat új namespace értéket! Tehát, amíg az API esetében így néz ki a helyes ns" és itt jön a példa. Kizárólag a módosítás, elmélet nélkül. Egy másik pont vagy fejezet szól az api-kban végrehajtandó változtatásról.

[EnokhSys]

@EnokhSys próbáltam egy minden mezőt, choice-t felsoroló XML-t generálni (tehát ez nem XSD valid) amiben benne van, hogy melyik mezőben mint kellene használni. Meg egy XSD valid állományt. Remélem ebből sikerül kideríteni a névtér használatot :)

invoiceData.txt invoiceDataXSDValid.txt

@renced42 Na, ez tökéletes, minden benne van, köszi szépen!! :)

[EnokhSys]

Nem tudom mi van a doku-ban, amikor én használtam a changelog-ot még nem volt doku (https://github.com/nav-gov-hu/Online-Invoice/blob/master/src/schemas/nav/gov/hu/OSA/CHANGELOG_3.0.md) De ha ugyan ez van a doku-ban és olvastad, akkor mi a probléma?

@kabelnet2 Nem, nem ugyanez, de mindenképp köszönöm, részletesen át fogom olvasni ezt is. Az általad belinkelt dokumentum bővebb, és van benne egy "3) 3.0 átállási útmutató lépésről lépésre" nevű fejezet, ami nincs benne a dokumentáció 5.4-es fejezetében. Egyébként marha jó ez a changelog 3.0, nem is értem miért nincs fenn az onlineszamla.nav.gov.hu-n programozóbarát segédletként, hiszen nem sokan ismerik a github-ot. Itt pedig érdemes lenne a "https://github.com/nav-gov-hu/Online-Invoice/tree/master/docs/API%20docs/hu" alá is bemásolni, mert nem hiszem, hogy egy ilyen jó kis segédletet az ember a sémák alatt keresgélne.

"Három komplex adattípus esetében át kell vezetned a Base XSD namespace értékét a gyermek tagekben. Ezek a magyar adószámot leíró TaxNumberType (törzsszám, ÁFA kód, megyekód) illetve a címtípusok, függetlenül attól hogy egyszerűsített (SimpleAddressType) vagy tagolt (DetailedAddressType) címekről van-e szó. Ezt a módosítást minden olyan helyen át kell vezetned, ahol a felsorolt típusok a Data XML-ben előfordulhatnak. Figyelj rá, hogy ez nem olyan namespace módosítás mint ami az API-nál van, itt a szülő tag nem kaphat új namespace értéket! Tehát, amíg az API esetében így néz ki a helyes ns" és itt jön a példa. Kizárólag a módosítás, elmélet nélkül. Egy másik pont vagy fejezet szól az api-kban végrehajtandó változtatásról.

Ezt így biztosan nem olvastam, pedig nagy segítség lett volna. Sőt, még egy olyan topikhoz is hozzászóltam, amelynek "[Q&A] Changelog 3.0 lépésről lépésre értelmezése" a neve, csakhogy azt hittem, hogy a "changelog", a dokumentáció 5.4-es fejezetének a beceneve.

[EnokhSys]

@renced42 Jó, hogy erre jártál, mert már szerettem volna megkérdezni, hogy mostanáig kb. hány számlát töltöttek fel a V3-as tesztrendszerébe? És 2020.07.01 után az éles rendszerbe, havi átlagban hány millió számla érkezik?

[renced42]

@EnokhSys Az első kédésedre a válasz még nem sokat, de azért akad a második kérdésedre a válasz: a google a barátod :) https://ado.hu/ado/a-szazmilliomodik-online-szamla-is-megerkezett-a-nav-hoz/

Kérlek zárd az issuet, ha az eredeti kérdésed alapján a választ megtaláltad, köszi!

[EnokhSys]

@EnokhSys Az első kédésedre a válasz még nem sokat, de azért akad a második kérdésedre a válasz: a google a barátod :) https://ado.hu/ado/a-szazmilliomodik-online-szamla-is-megerkezett-a-nav-hoz/

Köfi! :-) Eszembe nem jutott, hogy guglizzak, hiszen azt hittem itt első kézből kapok infót. :-) Mondjuk azért arra kiváncsi lettem volna, hogy a v3-as tesztszámlák elérték-e már az ezres vagy tízezres, vagy ötvenezres számot.

Kérlek zárd az issuet, ha az eredeti kérdésed alapján a választ megtaláltad, köszi!

Köszönöm, a választ megtaláltam a segítségetekkel, ugyanakkor szeretném valamire felhívni a figyelmedet: az OnLine Számla dokumentáció hivatalos dokumentumnak számít. Az, hogy vannak benne kisebb hibák, rendben van, viszont az megint támadási felületet jelent, ha nem tisztázzátok minden új verzióban, hogy melyik szegmenscsoport és szegmens, milyen névtérbe tartozik. Ti vagytok a legjobban tisztában azzal, hogy hány ezer -vagy tízezer számlamodulból/programból kapjátok a számlákat; - kötve hiszem, hogy akár csak a harmada foglalkozna XSD-kel, akár azért mert a fejlesztőeszköz ezt nem támogatja, akár azért, mert pl. az adatmezők összeválogatása és átadása egy java-s XSD-XML generátornak macerásabb, mint direkt XML-t létrehozni a dokumentáció és a minták alapján. Számukra is (és számomra is) a NAV OnLine Számlába történő feladás csak az ügyviteli rendszer néhány százalékát teszi ki, ezért a legfontosabb, hogy átláthatóan és könnyen lehessen kezelni az új verziókat. Zártam a topikot.