Online-invoice: [Q&A] ConventionalInvoiceInfo használata

[alaplap]

A kérdés, amire választ szeretnék kapni / The question I would like to be answered
A https://onlineszamla.nav.gov.hu/fejlesztoi_naplo oldalon a _"2020/2 Egyezményes adatmodell kialakítása opcionális adatokra (2020.01.22)"_ című bejegyzésben leírt problémafelvetésre a conventionalInvoiceInfo nyújt megoldást számla és tétel szinten, ami a korábbi lehetőségekhez képest jobb megoldást kínálhat arra, _"hogy a számlák automatikus feldolgozása minél univerzálisabb lehessen" (Changelog 3.0)_ .

Az alábbi adatok sorolhatók fel a conventionalInvoiceInfo-ban (ConventionalInvoiceInfoType):

• Megrendelésszám(ok) (orderNumbers )
• Szállítólevél szám(ok) (deliveryNotes)
• Szállítási dátum(ok) (shippingDates)
• Szerződésszám(ok) (contractNumbers)
• Az eladó vállalati kódja(i) (supplierCompanyCodes)
• A vevő vállalati kódja(i) (customerCompanyCodes)
• Beszállító kód(ok) (dealerCodes)
• Költséghely(ek) (costCenters)
• Projektszám(ok) (projectNumbers)
• Főkönyvi számlaszám(ok) (generalLedgerInvoiceNumbers)
• Globális helyazonosító szám(ok) (glnNumbers)
• Anyagszám(ok) (materialNumbers)
• EKÁER azonosító(k) (ekaerIds)

Továbbá továbbra is megmarad az additionalInvoiceData számla szinten és az additionalLineData tétel szinten.

Az egyik kérdésem az lenne, hogy a conventionalInvoiceInfo-ra is igaz lesz-e az az állítás, ami a 2.0-s interfész specifikációban az additionalInvoiceData/additionalLineData adatoknál szerepel, miszerint "a számlaadat-szolgáltatásban csak olyan extra adatokat szabad szerepeltetni, amelyek a számlán is szerepelnek"?

A másik kérdésem pedig az, hogy ez a lista bővíthető-e még? Ugyanis az említett fejlesztői naplós bejegyzésben és a 2.0-s interfész specifikációban az additionalInvoiceData/additionalLineData adatoknál is említésre került a cikkszám, mint extra adat, viszont a ConventionalInvoiceInfoType nem tartalmaz cikkszám típust.
Ha nem bővíthető a lista, akkor gondolom a fejlesztői naplós bejegyzésben említettek szerint egy "wiki"-t lenne érdemes létrehozni, ahol meg kellene beszélnie a fejlesztőknek egyezményes "dataName" azonosítókat az AdditionalDataType használatához?

[kabelnet2]

Én azt tippeltem - lehet, hogy rosszul - hogy az ő szóhasználatukban az anyagszám a cikkszám.

[NTCA-developer]

Sziasztok!

Egyeztetést követően felvettük a cikkszámot a csomópont adatai közé. Mindjárt adok fel pullt. Azt remélem hogy ez már így elég, mert a szakma többet is iterált a témán, amíg megszületett a végleges lista. Azt nyilván nem szeretnénk, ha minden ilyen fogalmat nekünk kellene definiálni, de a cikkszámot még validnak éreztük.

Köszi hogy jeleztétek!

[NTCA-developer]

Az első kérdésedre @NTCA-tax fog tudni válaszolni, én ugyanis nem emlékszem olyan kijelentésre, amit te írsz. Nem tudom, additionalként miért ne írhatnék az adatszolgáltatásba olyat is, ami a feldolgozást segíti. És ez ugyan úgy igaz a conventional adatokra is.

[kabelnet2]

Nekem azért még lenne tippem a bővítésre - de máshogy is megoldható. Van olyan eset, amikor az eladott termék nem bármihez, csak egy bizonyos termékhez használható, így azt a terméket is meg kell nevezni a számlán. Ez egyedi azonosítóval (sorozatszám) történik. Vagyis két egyedi azonosító van egy sorban: a terméké és azé, amelyikhez tartozik.
Ilyen pl. az utólag vásárolt garancia kiterjesztés, vagy garanciális javításra speciális feltételekkel eladott alkatrész, stb. Persze mindez a szállítón is szerepel, de néha sok évig kell megmaradni az adatnak ezért a számlán is feltüntetjük. Jelenleg additional-ként, tőlem maradhat így is.

[fenyvessy]

Az első kérdésedre @NTCA-tax fog tudni válaszolni, én ugyanis nem emlékszem olyan kijelentésre, amit te írsz.

Pedig szerintem is volt ilyen kijelentés, a NAV Informatikai Intézet előadójában hangzott el még az 1.0 indulása előtti fórumok valamelyikén, hogy az adatszolgáltatásban kizárólag olyan adatok szerepelhetnek, amelyek a számlán is fel lettek tüntetve. Emiatt okozott nekünk is fejtörést, amikor az ügyfél a számla egyedi nyomtatási képét úgy akarja átalakítani, hogy lehagyna róla olyan adatokat, amelyek törvény/jogszabály alapján nem kötelezőek, de a rendszer beküldené adatszolgáltatásként (pl. a fent hivatkozott cikkszám is lehet ilyen)

[alaplap]

szerintem is volt ilyen kijelentés

Nem csak kijelentés történt, le is van írva: API dokumentáció: Online Számla 2.0 rendszer interfész specifikáció, _2.1.5 Előre nem nevesített adatok szerepeltetése_ fejezet (78. oldal teteje). _"A számlaadat-szolgáltatásban csak olyan extra adatokat szabad szerepeltetni, amelyek a számlán is szerepelnek."_

[NTCA-tax]

Ténylegesen így szerepel a specifikációban. Adóhivatali oldalon abból indultunk ki, hogy ha az adatszolgáltatásba bekerül egy plusz információ, annak a gazdasági esemény mindkét szereplőjénél ellenőrizhető módon kell szerepelnie, amelyre utólag is könnyen ellenőrizhető módon lehet folyamatokat építeni. Az adatszolgáltatást ezért nem láttuk indokoltnak olyan adatokkal bővíteni, amelyek nem jelennek meg a számlán. Minden esetben a számlát kell hiteles bizonylatnak tekintetni, az adatszolgáltatás annak egyfajta standardizált lenyomata. A ConvenctionalInvoiceInfoType esetében is abból indultunk ki, amely adatok szokásosan szerepelnek a számlán, és a vevő használja a számla feldolgozási folyamatában.

[alaplap]

@NTCA-tax kár, hogy az új specifikáció 2.1.6 pontjába nem került bele a 2.1.5 pontban is szereplő "A számlaadat-szolgáltatásban csak olyan extra adatokat szabad szerepeltetni, amelyek a számlán is szerepelnek." állítás. Ettől eltekintve a válaszomat megkaptam, a 2.1.6 pontban kifejtett conventionalInvoiceInfo és conventionalLineInfo elemek csak olyan adatokat szerepeltethetnek, amik a számlán is szerepelnek. Köszönöm a válaszokat.

[ballonyi]

Ha esetleg bővíthető még a lista, akkor gépjármű rendszámot, és alvázszámot szeretném javasolni.