Online-invoice: [Q&A] Changelog 3.0 lépésről lépésre értelmezése
Mai nappal elkezdtem a 3.0 fejlesztését és hát bőven lesz kérdés e kapcsán, ami másoknak is segítség lehet.
A lépésről-lépésre átállási mutatót követem.
A 3.1.1. (Kötelező API módosítások) résznél van ez a lépés: "A header és user csomópontokban mindenhová tedd bele a common XSD-re általad definiált namespace taget (pl. common:);
Megnéztem a common.xsd-t és ott sok másik elemre is hivatkozik. Pl. funcCode, validationResultCode, message, validationErrorCode, errorCode. Ezek elé nem kell betenni a common: részletet?
nbeeps2
All 34 comments
Szia!
Szerintem az átállási útmutató elsősorban itt a beküldésre vonatkozik.
Üdv
NTCA-supporter
on 19 Oct 2020
KMGY100
on 19 Oct 2020
@NTCA-supporter igen, azt értem, viszont az én kérdésem arra vonatkozott, hogy a válasz (response) kezelésénél is számítani kell a header és a user tagokon kívül common: alkalmazására vagy az nem változik? Tehát "funcCode"-ot várjak vagy "common:funcCode"-ot?
@KMGY100 igen, láttam a példa XML-eket, de sajnos ebben nem kapok választ a feltett kérdésemre
nbeeps2
on 19 Oct 2020
- kérdés: "Ha használsz DTO generálást a projektedben, akkor az új sémákkal a projekt már nem fog fordulni. Vagy használj catalog XSD-t a common és a base sémák importálására és ezt kösd be a projekthez, vagy írd be a letöltött sémákba a schemaLocation attribútumot olyan filepath értékkel, ami neked megfelelő"
Nem használok DTO generálást, így a lépés 2. fele vonatkozik rám, csak nem világos mit kell csinálni:
a) használj catalog XSD-t a common és a base sémák importálására és ezt kösd be a projekthez (mit kötök hova? hogy?)
b) írd be a letöltött sémákba a schemaLocation attribútumot olyan filepath értékkel, ami neked megfelelő (hova írok be és mit? mi az, hogy ami nekem megfelelő?
Ez a lépés miben más, mint a 3.1.1.? "A header és user csomópontokban mindenhová (nyitó és zárótagekbe, illetve a gyermek tagekbe is) tedd bele a common XSD-re általad definiált namespace taget. Ha a példa szerinti ns-t használod, akkor ez a 'common:' lesz." Mert azt már megcsináltam. Nem értem.
nbeeps2
on 19 Oct 2020
- kérdés (szerintem ez lehet az elsőre a válasz): "Ha használsz response validációt a projektedben, akkor ha szükséges készülj fel arra, hogy az API üzleti válaszait nem minden esetben (pl token kérésnél az encodedExchangeToken, számlabeküldésnél a transactionId vagy a lekérdezéseknél a válasz adatok) a default, hanem esetlegesen más namespace alatt fogod visszakapni mint ahogy az korábban a 2.0 alatt történt. Ez a common XSD importálásának egyik következménye."
Semmilyen namespace-t namehasználtam. Kérek egy teljeskörű és konkrét felsorolást, hogy MI -> MIRE VÁLTOZOTT.
encodedExchangeToken -> common:encodedExchangeToken
transactionId -> common:transactionId
Ahhoz, hogy átírjam a programot, ahhoz tudnom kell a megváltozott mezők nevét!
nbeeps2
on 19 Oct 2020
Szia @nbeeps2 !
Küldök egy minta választ pl. queryTransactionStatus lekérdezésre.
A namespace-ek sorrendje nem garantált, tehát nem égetheted be, hogy pl. a common lesz a default namespace!
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:QueryTransactionStatusResponse xmlns="http://schemas.nav.gov.hu/NTCA/1.0/common" xmlns:ns2="http://schemas.nav.gov.hu/OSA/3.0/api" xmlns:ns3="http://schemas.nav.gov.hu/OSA/3.0/base" xmlns:ns4="http://schemas.nav.gov.hu/OSA/3.0/data">
<header>
<requestId>RID515353837223</requestId>
<timestamp>2020-10-19T10:36:12.968Z</timestamp>
<requestVersion>3.0</requestVersion>
<headerVersion>1.0</headerVersion>
</header>
<result>
<funcCode>OK</funcCode>
</result>
<ns2:software>
<ns2:softwareId>6Z1STQVJZ5MIWB3B7B</ns2:softwareId>
<ns2:softwareName>Teszt_Software</ns2:softwareName>
<ns2:softwareOperation>LOCAL_SOFTWARE</ns2:softwareOperation>
<ns2:softwareMainVersion>1.0</ns2:softwareMainVersion>
<ns2:softwareDevName>Teszt User</ns2:softwareDevName>
<ns2:softwareDevContact>[email protected]</ns2:softwareDevContact>
<ns2:softwareDevCountryCode>HU</ns2:softwareDevCountryCode>
<ns2:softwareDevTaxNumber>32914050</ns2:softwareDevTaxNumber>
</ns2:software>
<ns2:processingResults>
<ns2:processingResult>
<ns2:index>1</ns2:index>
<ns2:invoiceStatus>ABORTED</ns2:invoiceStatus>
<ns2:businessValidationMessages>
<ns2:validationResultCode>ERROR</ns2:validationResultCode>
<ns2:validationErrorCode>SUPPLIER_TAX_NUMBER_MISMATCH</ns2:validationErrorCode>
<ns2:message>Az eladó adószáma nem azonos az API XML-ben megadott, authentikált adószámmal.</ns2:message>
<ns2:pointer>
<ns2:tag>InvoiceData/invoiceMain/invoice/invoiceHead/supplierInfo/supplierTaxNumber/taxpayerId</ns2:tag>
</ns2:pointer>
</ns2:businessValidationMessages>
<ns2:compressedContentIndicator>false</ns2:compressedContentIndicator>
</ns2:processingResult>
<ns2:originalRequestVersion>3.0</ns2:originalRequestVersion>
</ns2:processingResults>
</ns2:QueryTransactionStatusResponse>
Üdv
NTCA-supporter
on 19 Oct 2020
Ha már minta file-ok: nem ártana a data példákat aktuálizálni. Nincs privatePersonIndicator és mergedItemIndicator és a namespace-ek is a V2-nek megfelelőek. Vagyis a V2 data xml példák vannak bemásolva a V3-ba.
kabelnet2
on 19 Oct 2020
@NTCA-supporter hát ezt most aztán már végképp nem értem. Hogy került a software elé ns2 ? Miközben a requestversion, miért nem common:requestversion? Eddig egyáltalán nem foglalkoztam namespace kezeléssel és több mint 2 éve kiválóan fut a program....
nbeeps2
on 19 Oct 2020
Szia, mert nézd a fejlécet: ns2 at az api xsd/namespace azonosítója, és abban van a software minden eleme.
Ugyanott a common az alap, annak nincs külön neve, vagyis ami abban van, az elé nem kell prefix-et írni.
Az, hogy 2 évig nem volt csak egy namespace, még nem jelenti, hogy ne lehetne több is. A részletek és indoklás a changelog-ban található.
kabelnet2
on 19 Oct 2020
Hát ez egy jó nagy marhaság... Ha egyedi mezőneveket használtak volna, akkor erre nem lett volt semmi szükség. Írhatom át a komplett programot...
nbeeps2
on 19 Oct 2020
@NTCA-supporter ha nem égethetem be a mező nevét, amit keresek, akkor mégis, hogy a fészkes fenébe olvassam ki az eredményből?
nbeeps2
on 19 Oct 2020
Azt, hogy marhaság, kérlek ne mondd, ez egy fontos része az XML-nek.
Nem ismerem a programodat. Ha valami parser-t használsz, annak kötelessége ezt ismerni.
Ha nem használsz parser-t, tegyél eléje egy eljárást/programot, ami leszedi az összes prefix-et (xxxx:) és utána a programodhoz hozzá se kell nyúlni. Így az sem érdekel, hogy mi a prefix, ha megváltozik, akkor is működni fog.
kabelnet2
on 19 Oct 2020
kabelnet2: igen, pontosan ezt csinálom most, át kell írjam az eljárásokat mindenhol az egész programban, hogy ne azt nézze, hogy "funcCode" (illetve az összes(!) hasonló tagot), hanem hogy bármi lehessen előtte. Ez brutál nagy módosítás. Ráadásul ha meg csak úgy eltávolítom a kettőspont előtti részt, mert nincs jelentőség, akkor végképp nem értem, hogy ez mire jó.
nbeeps2
on 19 Oct 2020
Kedves @nbeeps2, milyen nyelven írod a programod?
renced42
on 19 Oct 2020
Delphi 5 és Delphi 7, régi üzleti alkalmazások.
nbeeps2
on 19 Oct 2020
Azért ez nem olyan nagy módosítás, mert minden eljárásodban ugyan azt használhatod.
Az értelme meg az, hogy megmondja az elemző programnak, hogy hol, melyik xsd-ben található az adott elem leírása. Mint amikor egy struktúra elem előtt megadod, hogy melyik struktúrában van (nem ismerem a Delphi-t, de talán ott is így van). És azért az xml elemzésének a normál útja egy parser program használata, ezért arra van kitalálva.
kabelnet2
on 19 Oct 2020
@kabelnet , ez az XML egy rém buta dolog, nem használok hozzá parser-t, de nyilván ez az én egyéni döntésem. Úgy kell elképzelni, hogy sorról-sorra végig megyek a válaszon és értelmezem azokat, pontosan így állítom össze az XML-t is. Bazi egyszerű és bazi gyors, csak most beleköptek a levesbe :) De megoldom, csak át kell nézni az egész forrást, mert ha egy helyen kimarad ez a namespace kezelés, akkor borul a bili.
Csak egy példa, volt, ahol így kerestem: POS(_funcCode_-OK-_funcCode_,s)>0
átalakírta a fórum, de gondolom érthető
nbeeps2
on 19 Oct 2020
@nbeeps2 csak bátorítani tudlak, nekünk van egy FoxPro 9.0-n alapuló rendszer, amivel szépen haladunk a 3.0-val.
DrotosTot
on 19 Oct 2020
Kedves @nbeeps2, nem tudom, hogy szervezed a program kódod, de alapvetően szerintem nincs baj, nem kell biztosan újra írni a programodat semmi képpen.
Ettől függetlenül az eredmények kiolvasására a viszonylag egyszerűen használható Xpath lekérdezés használatát javasolnám, amivel a betöltött xmldoc-ból mindent ki tudsz olvasni szügség szerint. Ezt a Delphi illetve nagyjából minden általánosan használt programozási nyelv ismeri (még a VPF is talán). Ez viszont feltételezi, hogy az XML-t nem szövegként, hanem XML-ként kezeled.
renced42
on 19 Oct 2020
Köszönöm a javaslatokat, de sajnos nincs időm/energiám úgy technológiákat kitapasztalni, így maradok az általam használt módszernél, mert ezt átlátom. Pont ezen megfontolásból nem használtam parsert sem.
nbeeps2
on 19 Oct 2020
Ok, az 1-es és 3-as kérdés PIPA, a 2-es kérdésemre továbbra is várom a választ. Mi ott a tennivaló konkrétan?
nbeeps2
on 19 Oct 2020
- Tedd be az api-s xml elejére, hogy
[QueryInvoiceCheckRequest xmlns="http://schemas.nav.gov.hu/OSA/3.0/api"
xmlns:cns="http://schemas.nav.gov.hu/NTCA/1.0/common"]
és módosítsd a header és a user részeket, hogy az abban lévő elemek a cns namespace-ben találhatók. Pl.:
[cns:header]
[cns:requestId]....
[cns:timestamp]...
[cns:requestVersion]3.0
[cns:headerVersion]1.0
[/cns:header]
Ezt hívják ők bekötésnek.
A számlából történő xml generálásnál a data és a base namespaceket kell megadni (annulálásnál cak az annul). Hogy ott mit kell módosítani az adószámnál és a címeknél, nézd meg a changelog-ban.
(A módosítottam pár nagyobb-kisebb jelet a github miatt)
kabelnet2
on 19 Oct 2020
Magyarán a 3.1.1. negyedik lépése megegyezik "A header és user csomópontokban mindenhová (nyitó és zárótagekbe, illetve a gyermek tagekbe is) tedd bele a common XSD-re általad definiált namespace taget. Ha a példa szerinti ns-t használod, akkor ez a 'common:' lesz.") ugyanaz., mint a 3.1.2 fejezet első lépése... A számlából történő XML generálásnál még nem tartok, próbálok a leírt sorrend szerint haladni.
nbeeps2
on 19 Oct 2020
Igen, de a névtereken felül ne feledkezz meg róla, hogy a user csomópontban a titkosítás algoritmusát is jelölni kell a 3.0-ban:
DrotosTot
on 19 Oct 2020
@nbeeps2 Én is csak bátorítani tudlak, mert sajnos én sem tudok XSD-t behúzni a programomba, ezért nekem is sorról-sorra kell átírnom a response írást és request olvasást. Arról nem is beszélve, hogy minden egyes mezőt XMLInsert meg XMLGet parancsokkal kell beírnom meg kiolvasnom egy blobba, úgyhogy nem egy leányálom. :-)
EnokhSys
on 19 Oct 2020
@nbeeps2 csak bátorítani tudlak, nekünk van egy FoxPro 9.0-n alapuló rendszer, amivel szépen haladunk a 3.0-val.
@DrotosTot Szia, a Foxpro nem a FoxBase utódja?
EnokhSys
on 19 Oct 2020
@nbeeps2 csak bátorítani tudlak, nekünk van egy FoxPro 9.0-n alapuló rendszer, amivel szépen haladunk a 3.0-val.
@DrotosTot Szia, a Foxpro nem a FoxBase utódja?
De igen. 2007-ben adták ki hozzá az utolsó frissítést.
DrotosTot
on 20 Oct 2020
@DrotosTot Szia, a Foxpro nem a FoxBase utódja?
De igen. 2007-ben adták ki hozzá az utolsó frissítést.
Szerettem nagyon a DBase/Clipper/Foxbase vonalat, kifejezetten adatbáziskezelésre tervezett programnyelv volt.
EnokhSys
on 20 Oct 2020
_4. kérdés. "Figyelj rá, hogy nem egyszerűsített számla esetén (NORMAL és AGGREGATE típusokban) se számlasor, se számlaösszesítő szinten a VatRateType által leírt csomópontokban ne lehessen megadni a számlázóprogramban az egyszerűsített számlákban használt ÁFA tartalmat (vatContent), mert ez ilyen adatszolgáltatások ERROR miatt bukni fognak!"_
Kicsit nyakatekert lett az a mondat. Jól értem, hogy a lényeg az, hogy "a vatContent mezőt csak egyszerűsített száma esetén töltsem ki a VatRateType-on belül?"
nbeeps2
on 20 Oct 2020
_5. kérdés: "A commonban új típusként megjelenik az AtomicStringType, a SimpleTextNotBlank típusok ebből öröklődnek. Hasonlóan új típus a GenericDecimalType, amelyből a lebegőpontos értékek származnak."_
Ezzel van-e bármilyen teendő? A SimpleTextNotBlank típusok megmaradtak, változott esetleg valamelyik adatmezőnek a hossza?
nbeeps2
on 21 Oct 2020
_6. kérdés: "A commonban használt request struktúrákban nincsenek software adatok, mivel azok Online számlához köthető, specifikus típusok. Azonban a software adatok megadása a 3.0-ban is kötelezők, azokat az API sémaleíróban öröklődéssel a BasicOnlineInvoiceRequestType típus terjeszti ki"_
E kapcsán van-e bármilyen teendő? Szükséges-e másképp feltüntetni a software tagokat az XML-ben, mint eddig?
nbeeps2
on 21 Oct 2020
_6. kérdés: "A commonban használt request struktúrákban nincsenek software adatok, mivel azok Online számlához köthető, specifikus típusok. Azonban a software adatok megadása a 3.0-ban is kötelezők, azokat az API sémaleíróban öröklődéssel a BasicOnlineInvoiceRequestType típus terjeszti ki"_
E kapcsán van-e bármilyen teendő? Szükséges-e másképp feltüntetni a software tagokat az XML-ben, mint eddig?
Nem, a "software" szegmensek maradhatnak változatlanul, mint a v2-ben. Teszteltem a tokenrequest-et, és rendben van.
EnokhSys
on 21 Oct 2020
@DrotosTot Szia, a Foxpro nem a FoxBase utódja?
De igen. 2007-ben adták ki hozzá az utolsó frissítést.
Szerettem nagyon a DBase/Clipper/Foxbase vonalat, kifejezetten adatbáziskezelésre tervezett programnyelv volt.
Én Harbour-ban csinálom. Ez is xBase alapú és ingyenes ráadásul.
zsfoto
on 9 Nov 2020
Sziasztok!
Ez az issue zárható? Van még kérdés?
Üdv
NTCA-supporter
on 7 Dec 2020
Related issues
csaszko
·
4Comments
boriszelenyi
·
5Comments
Macskafarka
·
6Comments
Amn3s1a2018
·
5Comments
EnokhSys
·
6Comments
Most helpful comment
Én Harbour-ban csinálom. Ez is xBase alapú és ingyenes ráadásul.