Interfész specifikáció 2.0-ás verzióhoz

[NTCA-tax]

Kedves Fejlesztők!

A 2.0-ás XSD-hez az interfész specifikációt publikáltuk a következő oldalon: https://github.com/nav-gov-hu/eVAT/tree/master/docs/spec. A specifikáció a korábbihoz képest részletes adószakmai magyarázatokat is tartalmaz, amely az eddiginél jobban támogatja az implementációt. Az új adattartalom jelentős része az áfaanalitika adattartalmához kapcsolódik, de más részt is kiegészítettünk részletesebb magyarázatokkal.

Az interfész specifikációban a következő változások várhatóak még:

• A validációk vonatkozásában bár jelöltük a változások egy részét, azonban ebben még további változások várhatóak. A változásoknak a fő célja a 2.0-ás adatstruktúrához igazított működés biztosításán túlmenően számos új warning alkalmazása. Az eÁFA M2M rendszer egyik legnagyobb előnyét ugyanis a validációk mennyisége és ügyféli értéke jelenti. Erről a következő hetekben még fogunk hírt adni. Mindezek a validációs kiegészítések az alapműködést nem befolyásolják (azokat jeleztük a most publikált specifikációban), inkább az ellentmondásokra hívják fel az adózók figyelmét.
• Az A60 adattartalma jelenleg nem része a jelenlegi interfész specifikációnak. Az A60 azonban nem lesz része az áfaanalitikának, önálló operációként fog megjelenni az eÁFA M2M rendszerben. Ugyanakkor a kommunikációs alapok megegyeznek, ezért fogjuk az eÁFA M2M interfész specifikáció részévé tenni.

Az interfész specifikáció publikálása mellett az adatstruktúrát néhány elemnél pontosítottuk. Mindezek a jelzéseitek alapján történtek, valamint az általunk érzékelt hibák javítását jelentik. A pontosított XSD-ket is publikáltuk: https://github.com/nav-gov-hu/eVAT/tree/master/src/schemas/hu/gov/nav/vdr

Az XSD változások a következők:

• A customsTariffNumber értéklistája kapcsán elfogadtuk, hogy ne szöveges értéklista legyen, hanem VTSZ kódok. Az értéklista így módosítottuk, így talán valamennyivel egyszerűbb lesz a fejlesztés. Az értéklista elemeit kérlek nézzétek meg, mivel szerepel benne szöveges tartalom is, nem kizárólag VTSZ szám!
• Az allowanceBase és allowanceAmount opcionális lesz, mivel nem feltétlenül kell minden esetben értéket tartalmazniuk. Mivel a nulla is egy értéket jelent, ezért amennyiben az adott mezőbe nem kerülhet érték, akkor annak üresen kell maradnia.
• A taxTypeDeclarationRowNumber értéklistája kiegészül '8' értékkel, amely sajnos eddig nem került bele az értéklistába. A belső elemzéseinknél derült csak ki ez az értéklista hiba, amelyet ezzel korrigáltunk.
• A declarationType értéklistájából a "PAUSING" törlésre kerül, mivel nem kerülhet beadásra olyan áfabevallás, amelynél ezzel az értékkel ellátott. A logikai ellentmondást az értéklistából való törléssel korrigáltuk.
• A Namespace 2.0 verzió lesz, amellyel egyértelműbbé válik az XSD-k kezelése. Köszönjük az ezzel kapcsolatos jelzést, amelyet elfogadtunk és az XSD-t már így publikáltuk.

Amennyiben a publikált interfész specifikációval kapcsolatban bármilyen kérdésetek felmerülne, akkor feltehetitek a szokásos módon a GitHub felületén. A jogértelmezési kérdésekkel kapcsolatban a következő elérhetőségen „az eÁFA felület használatával kapcsolatos jogi kérdések” tárgy kiválasztásával tudtok kérdést feltenni: https://nav.gov.hu/ugyfeliranytu/keressen_minket/levelkuldes

[susanahu2-pzsu]

16. oldalon: "A requestVersion [...] Jelenleg elfogadott egyetlen érték: 3.0" - ez az OSZ speciből lett így másolva? Ott valóban 3.0, az eÁfában pénteken még 1.0 működött. Nem 2.0 lesz majd a címben szereplő 2.0-ás verzió életbe lépésekor?

[NTCA-tax]

Köszönjük a jelzésedet, ez sajnos ténylegesen elírás a részünkről. A requestVersion értéke 1.0 és ez nem is fog változni.

[susanahu2-pzsu]

Arra vonatkozóan van elvárás, hogy a softwareId azonos legyen az OSZ által már aktívan használttal? (Nem a mostani ajánlás szerint lett képezve.)

[susanahu2-pzsu]

sourceDocumentId: ezzel kapcsolatban a pénztárgépre vonatkozóan szeretném tisztázni, hogy ha a webes eÁfa felületen Nyugtaként látok napi 1 dokumentumot az AP számmal azonosítva, a számviteli rendszerben pedig ehhez több belső bizonylat is kapcsolódik (konkrét vásárlásonként 1 belső bizonylat), akkor az M2M kapcsolatban melyiket kell szerepeltetni? Az ERP-nk jelenleg az AP számot nem tartalmazza, de ha szükséges, akkor hozzáadjuk.

[MZSBO]

Erre jó lenne, ha lenne valamilyen válasz. Egyelőre ez a terület elég ködös. Ti jutottatok valamire? Nálunk is jellemzően ez a helyzet az erp-ben, hogy bizonylatonként szerepelnek a nyugták, tehát összesíteni kéne, de az AP szám nincs nyilvántartva.

[susanahu2-pzsu]

Én arra jutottam, hogy mivel van RECEIPT típus, azzal fogom beküldeni, sourcedocumentid pedig a belső bizonylatszám lesz. Mivel ha AP-ra összesítve küldeném be, akkor ha abban csak a nyugtások vannak, akkor az OP adattal nem fog stimmelni, ha meg az egészet beküldöm, akkor abban a készpénzzel kifizetett normál számlák is benne lesznek, tehát egy része duplán kerülne be.

[MZSBO]

Köszi a választ.

Nálunk jellemzően el van különítve az erp-ben a kp-s számlás és a kp-s nyugtás bizonylat (számkörben). Előbbiről az erp-ből kell adatot szolgáltatni a NAV felé (és ez csak PÉNZ BE funkció a pénztárgépen, ÁFA regisztert nem érintő tranzakció), utóbbiról meg a pénztárgépből. Szóval elvileg ezeket tudjuk külön kezelni, így akár a nyugtásakat összesíteni is napi szintre. De vajon gond, ha tételenként küldjük be? Hiányozni fog neki az AP szám?

[susanahu2-pzsu]

Hát ez sajnos csak az élesben fog kiderülni, hiszen a NAV Tesztben nincs OP adat, ami alapján hiányolhatná. De az még odébb lesz, egyelőre Request rejected a ManageDeclarationPartition :(

[Szildiko]

Most jutottam a 2.0 leírásnak az átolvasásához:

Az azonban elvárt, hogy például belföldi partner adatai esetében több adatelemet szükséges megadni az áfaanalitikában, azonban magánszemély adatok az Online Számla rendszerhez hasonlóan itt sem szerepelhetnek.

Ez az éles kiadott verzióhoz képest ha jól látom változás?
Nem biztos, hogy jól informálódtam, az éles verziónak ez a doksija: eÁFA_M2M_rendszer_interfesz_specifikacio_v0.9.pdf ebben még nem volt szó erről.

Szóval a lényeg, hogy a státusz magánszemély, akkor se név se cím, semmit nem szabad bele tenni?

[NagyFer]

@Szildiko Most én sem találom a korábbi specifikációban, viszont ennek a dokumentumnak https://github.com/nav-gov-hu/eVAT/blob/master/eVAT-M2M/sample%20xml/e%C3%81FA_M2M%20XML%20bemutatasa.pdf a 7. oldalán eddig is benne volt, szóval az 1.0-ban sem szabad küldeni.

[Szildiko]

2.0 doksi, ami már összeszedettebb viszont nem írja, hogy not_available-nél sem szabad szerepeltetni a nevet, amit linkeltél pedig igen.
Erről az extra pdf-ről el is feledkeztem, minden dolgot úgy kellett összevadászni, ehhez már a végén elfelejtettem visszatérni....
Osánál olyan szépen tudtak ellenőrzéseket tenni ezekre, itt meg nem :(

[Macskafarka]

A partnerInfo adatokon belül elég a partnerStatus, ha annak tartalma NOT_AVAILABLE.

[NTCA-KJ]

Tisztelt Ügyfelünk!

A két rendszer közötti kötelező azonosítási egyezésre vonatkozó üzleti szabály nincs a specifikációban.

A sourceDocumentId mezőben főszabály szerint az eredeti forrásbizonylat sorszámát kell megadni. Egyedi nyugta beküldésekor tehát a nyugta eredeti sorszáma szükséges.

Lehetőség van emellett a DAILY_SUMMARY típus alatt a pénztárgép napi zárásához kapcsolódó dokumentum szerepeltetésére is. Ekkor a sourceDocumentId-ban a napi zárás sorszámát és a pénztárgép AP számát szükséges feltüntetni.

PRIVATE_PERSON esetén a magánszemély partner neve, címe és adóazonosító adatai nem továbbíthatók (hasonlóan az Online Számlához); a partnerInfo csomóponton belül a partnerStatus megadása elegendő.

NOT_AVAILABLE akkor alkalmazható, ha a nyilvántartás nem tartalmazza a partner státuszára vonatkozó adatot, vagy az adott tételnél partner nem értelmezhető. Ennél az értéknél is elegendő kizárólag a partnerStatus megadása.