eVIR tudásbázis

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
====== Előszó ======

Ez a dokumentáció, az onlineszámla adatszolgáltatás API-nak való megfelelőséggel kapcsolatos információkat tartalmaz. 

Ez az onlineszamla adatszolgáltatás V2.0 verziójának megfelelően dokumentál.

A dokumentációban FIXME tagekkel felhívom a figyelmet azokra a pontokra ahol az implementáció a lehetséges legbővebb változathoz képest kevesebbet nyújt. Erre természetesen meg van a lehetőség, hiszen a NAV által felkínált lehetőségek közül számos nem kötelező.

Indoklásképpen a következő fő változatok lehetségesek

  * O: Nem kötelező implementálni
    * O1: Az eVir-ben az adott feature nincs biztosítva, így a(z adat)szolgáltatás során nem merül fel a használata
    * O2: Nem élünk a(z adat)szolgáltatás lehetőségével
    * O3: Az implementáció időzítése alapján nem fejeződött be. (bármit is jelentsen ez :)

====== 1. Bevezető ======

  * [ ] Implementálandó v. Implementálható
  * [.] Implementálás alatt
  * [t] Implementált, de tesztelni kell FIXME
  * [X] Implementált, tesztelt


  * [t] manageAnnulment
  * [t] manageInvoice
    * [.] [[nav_onlineszamla_data]]
  * [ ] queryInvoiceChainDigest
  * [X] queryInvoiceCheck
  * [X] queryInvoiceData
  * [ ] queryInvoiceDigest
  * [ ] queryTransactionList
  * [t] queryTransactionStatus
  * [X] queryTaxpayer
  * [X] tokenExchange

===== 1.1 folyamat =====

A rendszer egy technikai azonosítóval dolgozik.

A tokent a számla küldésének kötelezettségekor közvetlenül megigényli, A megigényelt tokent azonnal megpróbálja felhasználni, nem él az 5 perces limittel.

A jövőben lehetséges implementáció, hogy
tömeges számlázáskor egy tokent igényel az egyszerre kiállított számlákhoz (trigger) ezért a [[tomeges_szamla|tömeges számlázás]]nál nem emelhető meg 100 fölé az egyszerre kiállított számlák száma.

Pillanatnyilag a tömeges számlázáskor egyesével igényelt tokenekkel küldi be a számlákat.

Ha a számlák ismételt beküldése esetén (átmeneti technikai sikertelenség esetén) az újraküldésekhez már számlánként egyenként igényel tokent.

===== 1.3.1. request =====

basic.pm

  * 1) ''requestId'' az ''onlineszamla_request_log'' tábla ''request_id''-jéből jön. Fejlesztői környezetben kaphat prefixet az unicitás biztosítása céljából.
  * 2) ''timestamp'': ''onlineszamla_request_log.request_timestamp''
  * 3) ''requestVersion'': ''general_data->work_version'' alapján
  * 4) ''headerVersion'': nem kötelező de megadjuk

===== 1.3.2. user =====

Kötelezően implementálva

===== 1.3.3. software =====

Kötelezően implementálva

''$general_data->{software}''

===== 1.4. response =====

''onlineszamla->''

  * ''handle_response'' minden valaszt feldolgoz
  * ''process_result'' ertelmezi HTTP es hibakod szinten FIXME
  * ''process_response_xml'' csak parsol 

===== 1.4.1. result =====

  * 1) nem használtuk FIXME
  * 2) ''errorCode'' FIXME ujrairni amit kell
  * 3) message behozása a hibakezelésbe FIXME

===== 1.5.1 requestSignature számolás manageInvoice és  manageAnnulment =====

Új kötelező implementáció

  * manageInvoice tesztelve, működik
  * manageAnnulment Opcionális FIXME O3

===== 1.5.2. requestSignature számolás egyébként =====

Kötelezően implementálva

===== 1.5.3 UTC =====

SQL-ből megoldva (UTC-ben is generáljuk, tároljuk)

===== 1.6. A szolgáltatás technikai leírása =====

===== 1.6.1. általános adatok =====

FIXME context root verzio nélkül???


===== 1.6.2. =====

Mint 1. pontban

===== 1.6.3. http header =====

''onlineszamla->calc_header''

===== 1.6.4. http statusok =====

lásd 1.4 ...

===== 1.6.5. tömörítés =====

Opcionális. Nem tömörítünk.

===== 1.6.6. timeout =====

''onlineszamla->http_ua_request'' 

setup-ban allithato az interaktiv es a batch timeout kulon kulon is.

default 5 sec.

timeout eseten sajat response kodunk van:

504 Client-side timeout FIXME átvezetni a többi mellé a doksiban

===== 1.6.7. szerveridő, NTP =====

nem kötelező; oprendszer szintű megoldást itt nem dokumentálok.
(Elvileg mindenhol NTP van)

===== 1.6.8. karbantartási mód =====

FIXME ezt implementalni kellhet

===== 1.6.9. verziókezelés =====

logikus

===== 1.7. req resp elementek =====

1.4. szerint

===== 1.8.1. manageAnnulment =====

Implementálva FIXME Tesztelni kell majd

===== 1.8.2. manageInvoice =====


Tömörítést nem használunk

Implementált FIXME tesztelés alatt

A beküldött számla adattartalmára vonatkozó információk a [[nav_onlineszamla_data]] oldalon találhatóak.

===== 1.8.3. queryInvoiceChainDigest =====

FIXME 2020-02 új

===== 1.8.4. queryInvoiceCheck =====

Implementálva Tesztelve

FIXME batch feldolgozás és vevő oldali lekérdezés nélkül

FIXME használja-e valaki (close_trigger pl?) lásd: invoice_data FIXME !!!
===== 1.8.5. queryInvoiceData =====

Implementálva. Tesztelve

FIXME Használata még változás alatt van

FIXME batch feldolgozás és vevő oldali lekérdezés nélkül

===== 1.8.6. queryInvoiceDigest =====

FIXME Implementálandó

Adatszolgáltatási kötelezettség teljesítését nem akadályozza

===== 1.8.7. queryTransactionList =====

FIXME 2020-02 új

===== 1.8.8. queryTransactionStatus =====

Implementálva, close_trigger hívja, mikor kell. Elvileg tesztelve, és működik

===== 1.8.9. queryTaxPayer =====

Implementálva, tesztelve

Implementált 2.0-s változások: V2-20-20

  * cím adatok kinyerése HQ-ra partnerek modulban
  * Ez tesztelve is van v_2 esetére

----

További 2.0-s változások (nem implementálva) FIXME

  * taxpayerShortName
  * vatGroupMembership

címadatokon belül új mezők:

  * region
  * lotNumber

Különösen nincsenek implementálva FIXME

===== 1.8.10. tokenExchange =====

Implementálva Tesztelve