Online-invoice: [Q&A] Negatív elszámoló számla

[githubfelhasznalo]

Sziasztok,

az egyik ügyfelünk minden hónapban kibocsát egy számlát, majd év végén, az év utolsó számlájában kiszámlázza az utolsó havit számlát és a tényleges fogyasztás alapján az előző 11 hónap alapján egy elszámolást, így gyakran előfordul, hogy ez az utolsó havi egy negatív számla lesz.

De ez egy nagyon hibrid számla ugye: egyrészt módosító, ami módosítja az előző 11 hónap adatait, másrészt ez egyben egy normál, eredeti számla is, hiszen az utolsó havi adatok ezen vannak számlázva.

Na most itt mi lenne a megfelelő kezelés? Ha módosítónak kezelem, akkor a 12. havi adatokat hová tudom rakni? Ha viszont eredeti, akkor meg negatív lesz a vége, ami általatok nem preferált. Ilyenkor hogyan kellene eljárni?

[Amn3s1a2018]

Elsőre egyszerűnek tűnik, de ezzel kapcsolatban engem is érdekelne pár dolog ...
Ugye addig megvan, hogy kétféle számla létezik:

• számla
• számlával egy tekintet alá eső okirat

Van aki úgy mondja, hogy „kb. minden számla, a másik meg olyan bonyolult, hogy földi ember úgyse lát olyant soha”. Én inkább azt gondolom, hogy az ami az adatszolgáltatásban a számlalánc eleje az számla, minden más pedig az egytekintetes okirat, de inkább olyanokat írunk rá, hogy sztornó meg helyesbítő, így nem fárad el a vevő mire elolvassa.

• [x] Igaz
• [ ] Hamis

Szóval az elszámoló számla is csak egy helyesbítés, annyi eltéréssel, hogy nem egy számlát helyesbít, hanem többet (11). Papíron már láttunk ilyent, pl. áramszolgáltatók pont így csinálják. Ha megnézel egy ilyen számlát, szépen felsorolja, hivatkozza a részszámlákat,

• [x] vagyis hogy miket „helyesbít”
• [ ] vagy valami törvényen kívüli kapcsolat van a számlák között, mert előleg biztos nem lehet.

Végül pedig ha az eddigieket jól gondolom, akkor beküldeni a batchInvoice tag használatával tudod az ilyesmit. Ugye ez gyakorlatilag 12 számla, 11 módosító meg egy sima. A struktúra elvileg tudja, a BatchInvoiceType alá be lehet pakolni a 11 módosítót és 12.-nek a magányos decemberi részszámlát, amit már nem akarnak helyesbíteni. Amikor eljutsz eddig, légyszi kommenteld ide, hogy mi lett. Kicsit szkeptikus vagyok, hogy a MODIFY operációval beküldött batch szeretni fogja-e, hogy előzmény nélküli számla van benne. Erre a batchInvoice-ra érdemes rákeresni, ha már tényleg megnyerted a fejlesztését.
Itt pedig több helyes válasz is lehet:

• [x] hajrá batchInvoice
• [x] régen erre volt a tető-vel (^) díszített számlaszám.
• [ ] azt is lehet még használni
• [ ] vagy nem (szerintem nem)
• [ ] á dehogy, ez részszámlázás, teljesen másképp kell

[githubfelhasznalo2]

Természetesen, ez volt az első, amit próbáltunk. Ha MODIFY az operation, akkor INVOICE_REFERENCE_EXPECTED a normál számla miatt, ha CREATE, akkkor meg CREATE_WITH_BATCH_INVOICE_FOUND.

Így, hogy API szinten van az operáció, így lehetetlen beküldeni a kettőt együtt. A data részévé téve viszont kissé problematikus, hiszen ez nem egy számlaadat, így sérülne a logika, bár beküldhetővé válna.

Mindenesetre a közműszolgáltatóknál ágazatilag így van az elszámolószámla, de ezt jelenleg lényegében lehetetlen riportálni online számla tekintetében.

[githubfelhasznalo2]

Ja, és elvileg lehet a caret (^)-tel továbbra is küldeni, csak a partnereidet szivatod vele, mert nekik lesz szívás lekérdezni a te számláidat. Én nem láttam olyat, ami explicite tiltaná a kalapos módszert, de semmiképpen se szeretnénk abba az irányba elindulni, ezt online számla szinten (vagy jogszabályi szinten) kell véglegesen megoldani szerintem.

[githubfelhasznalo2]

@NTCA-tax ezzel kapcsolatban mikorra várhatunk visszajelzést? köszi

[Amn3s1a2018]

@githubfelhasznalo2 eddig hogyan csináltátok ezt?

• Ha előzmény nélküli negatív számlaként, akkor az nem felelt meg a jogszabályoknak már az 1.0 előtt sem. Gyanítom, hogy eddig ez lehetett a gyakorlat. Kerestem ilyen számlákat „komoly, nemzetközi háttérrel rendelkező” cégektől, hátha sikerül ellesni valamit. Az elszámoló számla nyomtatott változata kulturáltan felsorolja az előzmény időszakok számláit, de úgy tűnik ez csak megjegyzés szinten működik. (mert az adatszolgáltatásban nem találom a végszámlát csak az előzmények egy részét). Szintén csak gyanítom, hogy a NAV nem piszkálta ezzel a nagy szolgáltatókat, valószínűleg nem is tudott róla senki, hogy így csinálják. Ahogy a #137-ben leírták, az „így szoktuk” nekik sem lehet érv, nem a szabálytalan működés termékét kell valahogy betuszkolni az adatszolgáltatásba, de úgy tűnik nekem, hogy ez sem lehetetlen, hiszen a számlát befogadják, „csak” jön rá egy WARN. Javasolnám a #137 és #265 átolvasását, de gondolom ezen már túl vagy.
• Ha módosító számlaként, akkor ennek a jelentése nem új követelmény (az alapszámla lehetett jelentendő), szóval továbbra is mennie kell ugyanúgy. A CREATE_WITH_BATCH_INVOICE_FOUND -ra én technikai megoldást keresnék. A decemberi elszámolás „összekeverése” a novemberivel, vagy egy nullás technikai decemberi számla kiállítása is megteszi. ÁFA szempontból lehet érdekes a kérdés _pozitiv_ számla esetén. Ha a decembert a november helyesbítéseként értelmezed, akkor ön-ellenőrizned kell a novemberi áfát.

[githubfelhasznalo2]

@Amn3s1a2018 az elszámoló számla tartalma és formája jogszabályban meghatározott, nem tudod tetszőlegesen módosítani. Az áfatörvényben nem létezik ilyen okirat: sem számla, sem módosító számlának nem tekinthető, hanem egy hibrid, aminek a riportálása nem biztosított jelenleg az online számla rendszerben.

Hogy eddig nem teljesen helyesen riportáltak, azon lehet vitatkozni, azon viszont nem, hogy helyesen jelenleg nem lehet riportálni, és eddig sem lehetett. A technikai megoldás, workaround nem helyes, hiszen az elszámoló számla megképzésének megvannak a jogszabályban lefektetett követelményei.

[eszel]

@githubfelhasznalo:
Sziasztok! Én úgy tudom, hogy egy számlán módosíthattok egy vagy több múltbeli ügyletet (ami állhat 1/több bizonylatból már eleve), vagy kezdhettek új ügyletet. Tehát az ilyen hibrid számlát leginkább 2 számlára bontva kéri a NAV:

• 1 db kötegelt módosító a régi hónapokhoz
• 1 db új számla az év legutolsó hónapjáról
  Úgy tudom ezt a két típust nem lehet keverni, de javítsatok ki, ha igen, engem is érdekel! :)

Lásd:
https://github.com/nav-gov-hu/Online-Invoice/issues/191

[githubfelhasznalo2]

@eszel az elszámoló számla egy darab számla, egy darab számlaszámmal, ami egyrészt egy csoportos módosító, ami módosít 11 korábbi hónapot és 1 új számla kvázi, ami az utolsó havi új adatokat tartalmazza.

Közműszolgáltatók esetén egyértelműen meg van határozva, hogy hogy kell kinéznie egy ilyen elszámoló számlának, de kb. még a betűtípus is. Szóval ezért nem lehet ketté bontani, és ezért nem tudjuk, hogy ezt hogy lehetne beriportálni, számunkra úgy tűnik, hogy egyelőre sehogy, ezért is várnám @NTCA-tax válaszát, hátha tud valami támpontot adni.

[eszel]

@githubfelhasznalo2 Megértettem! :) Láttam már olyat, hogy technikailag minden mínuszos tételt virtuálisan külön számlaként alsorszámosan küldtek be, amikor még nem volt erre technikai megoldás, a tömeges/batch módosítás lehetősége. Ötletem így egy alábontás: SORSZAM/1 és SORSZAM/2 alsorszámozással kettő darab számlaként riportoljátok be.. ahol a SORSZAM az eredeti elszámolón is megjelenített sorszám.

[githubfelhasznalo2]

@eszel SORSZAM/1 és SORSZAM/2 az két különböző számlaszám. Az én számlaszámom meg egy harmadik. Itt nem az a probléma, hogy ne tudnánk workaroundokat találni, hanem, hogy nem akarunk.

[Amn3s1a2018]

A /1 /2 megoldás nyilván elfogad6atlan. Ahogy annó a ^ is csak azért volt jó, mert ez volt a hivatalos álláspont. Egyébként azzal még lehetett volna ilyen hibrid számlát feladni Az a megoldás, hogy a CREATEes részét a számlának ne tegyük bele külön, hanem „szétkenjük” a többi számlán miért nem jó? Az egyik korábbi issue csavaros példája szerintem elfogadható ebben az esetben is. Mivel az utolsó hónap „negatív fogyasztása” fizikailag nem lehet más mint az, hogy a korábbi hónapokban többet számláztunk, plusz nem tudjuk, hogy mikor mennyivel, teljesen jó ha elindulunk előről vagy hátulról, mindent meghelyesbítve max 0ra, amíg a negatívság el nem fogyott. A 12. részlet, ami a create lenne egy teljesen virtuális dolog. A szupertörvényes papír számlán se nagyon tudod megmutatni, hogy mi is tartozik ide, de ha mégis, akkor is jobb megoldás csak ezt rápakolni az előző hónapra (csak annyi hónapra, ami kell, nem az összes 11re), mint nem jelenteni, vagy külön számlaként kezelni az egészet (ami amúgy technikailag szintén valid, csak jön rá a warning)

Erről már van egy ilyen is:
https://nav.gov.hu/data/cms387018/Tajekoztato___Idoszakos_elszamolasu_ugyletekre_vonatkozo_szabalyozas_valtozasa.pdf

[NTCA-tax]

A közüzemi elszámoló számla megoldását a 3.0 tartalmazza. Ezzel kapcsolatban a changelog-ban a következőt találjátok:

"A közszolgáltatói elszámolószámlákra vonatkozó speciális szabályok miatt a sémába bekerült egy új, utilitySettlementIndicator nevű jelölő. Ha a tag értéke true, akkor az előzmény nélküli módosítások (a modifyWithoutMaster tag értéke true) feldolgozása akkor is megtörténik, ha egyébként a hivatkozott alapszámla a rendszerben már létezik."

[jozanesz]

"A közszolgáltatói elszámolószámlákra vonatkozó speciális szabályok miatt a sémába bekerült egy új, utilitySettlementIndicator nevű jelölő. Ha a tag értéke true, akkor az előzmény nélküli módosítások (a modifyWithoutMaster tag értéke true) feldolgozása akkor is megtörténik, ha egyébként a hivatkozott alapszámla a rendszerben már létezik."

Ez pontosan hogy oldja meg a problémát? Mi köze egyáltalán a modifyWithoutMasternek ahhoz, hogy egy elszámoló számla az 0 vagy 1 CREATE és 0 vagy több MODIFY invoice összessége? Akkor most utilitySettlementIndicator true legyen, akár volt részszámla előzmény, akár nem? És mi legyen a "hivatkozott alapszámla", főleg, ha ez az első számlája az ügyfélnek?

[NTCA-tax]

A kérdésed jogos, a specifikációban adunk rá egyértelmű útmutatást, hogyan kell az elszámoló számláról adatszolgáltatást adni. A changelog-ban ez nem került túl mélyen kifejtésre, de ezt a specifikációban pótolni fogjuk.

[jozanesz]

A changelog-ban ez nem került túl mélyen kifejtésre, de ezt a specifikációban pótolni fogjuk.

Ezzel csak az a gond, hogy talán késő lesz már véleményezni.

1. "Úgy becsüljük, hogy a 3.0-ás XML API-t tartalmazó fejlesztés szeptember végére lesz elérhető a teszt környezeten, a hozzá kapcsolódó magyar nyelvű interfész dokumentációval együtt."
2. "A séma véleményezésére, XML API-val kapcsolatos javaslatok adására érdemben a NAV oldali fejlesztés ideje alatt van lehetőség, utána már (szeptember végén elindul a műszaki notifikáció) csak korlátozottan, ezért ha van még nem kezelt eset vagy fejlesztési kérés, akkor kérjük azokat mielőbb tudassátok velünk"

[NTCA-tax]

Ez valid felvetés, így kifejtem részletesebben:

A közmű elszámoló számla specialitása, hogy egyszerre számla és számlával egy tekintet alá eső okirat. Ezt a hibrid bizonylatot Modify-ként kell beküldeni az Online Számla rendszerbe. Ilyen hibrid bizonylatról a 3.0-ban a következő módon kell majd adatot szolgáltatni:
Az adott időszaki teljesítés (ez jellemzően az alapdíj) az adatszolgáltatásban a következőképp kell jelölni:

• originalInvoiceNumber az elszámoló számla sorszáma
• modifyWithoutMaster értéke tetszőleges
• modificationIndex=1
• utilitySettlementIndicator=true
  Az elszámoló számla korábbi időszakot módosító tételeinek a riportolását a következőképp kell megtenni:
• originalInvoiceNumber hivatkozott részszámla sorszáma
• modifyWithoutMaster amennyiben a részszámlára történt adatszolgáltatás, értéke false, amennyiben nem, akkor true
• modificationIndex értelemszerűen kell kitölteni
• utilitySettlementIndicator=false

A fenti információ alapján remélhetőleg tudod véleményezni a megoldást és így a changelog-ban leírtak is érthetővé válnak.

[jozanesz]

Köszönöm. Sajnos még így sem teljesen világos, és nagyon tákoltnak is tűnik. Ha jól értem, akkor ez egy _batchInvoice_, amelyet _MODIFY_ _ManageInvoiceOperationType_-pal kell beküldeni. Mint említettem, "egy elszámoló számla az 0 vagy 1 CREATE és 0 vagy több MODIFY invoice összessége". Ha csak egy CREATE, azaz nincs részszámla-jóváírás (pl. ez az ügyfél első számlája), akkor ugyanúgy kellene beküldeni, mint bármely más normál számlát, tehát nem a fent leírtak szerint?

Én teljesen másképp modellezném: ezt a számomra megfoghatatlan jelentésű (és érthetetlen módon kötelezővé tett) utilitySettlementIndicatort nem használnám (erre), hanem egy új _ManageInvoiceOperationType_-ot vezetnék be (pl. _HYBRID_ vagy _COMPOUND_). Ez egy olyan BatchInvoiceType típúsú ötvözet lenne, amely akár 1 számlából vagy okiratból is állhatna, de többnyire több okirat (jóváírt résszámlák) és egy számla (mért vagy szerencsétlen esetben becsült fogyasztás) összessége. A fenti leírástól eltérően egyáltalán nem használnám a terhelő (alias _CREATE_ vagy "számla") részben az *invoiceReference-t: ez önmagában jelezné, hogy ez a terhelés, míg a jóváíró (alias _MODIFY_) részekben igen.

(A 2.0-ban volt ilyen korlátozás: "A rendszernek egy adatszolgáltatási kérés során csak egyetlen batchInvoice csomópontot tartalmazó kérés adható át." Ennek azért van jelentősége, mert ha így marad, jelentősen nőni fog a kérések száma: rengeteg magánszemély rengeteg elszámoló számlája egyesével lesz beküldve.)

"A közszolgáltatói elszámolószámlákra vonatkozó speciális szabályok miatt a sémába bekerült egy új, utilitySettlementIndicator nevű jelölő. Ha a tag értéke true, akkor az előzmény nélküli módosítások (a modifyWithoutMaster tag értéke true) feldolgozása akkor is megtörténik, ha egyébként a hivatkozott alapszámla a rendszerben már létezik."

Az új információk alapján ez továbbra sem érthető: utilitySettlementIndicator=true csak a "számla" részben lesz, amikor "originalInvoiceNumber az [aktuálisan beküldött] elszámoló számla sorszáma", így hogyan fordulhatna elő, hogy "a hivatkozott alapszámla a rendszerben már létezik"? És milyen "előzmény nélküli módosítások", amikor ez pont nem a módosító részben fordul elő.

---

* A közüzemi számlákhoz tartozik az az eset is, amikor egy lakóközösség közös mérőjének a fogyasztásából levonják a lakók fogyasztásának az összegét. Mivel általában lehetetlen az összes mérőt egy időben és helyesen, pontatlanság nélkül leolvasni, és még az emberi hibák sem ritkák, előfordul, hogy egy-egy időszakban több a levonás, mint a közös mérőn mért fogyasztás. Ez jelenleg ugyanúgy INCORRECT_SUMMARY_DATA_INVOICE_NET_AMOUNT figyelmeztetést eredményez, mint a negatív egyenlegű elszámoló számlák. Az ilyen számlát is elfogadhatná el a NAV figyelmeztetés nélkül egy opcionális indicator tag alapján. Ez lehetne pl. a _utilitySettlementIndicator_, csak ne legyen kötelező elem.

[jozanesz]

Sajnos a ma megjelent specifikációtól sem lett jobb a helyzet. Kár, hogy nem jött egyeztetni, aki ezt a katyvaszt kitalálta. Kellene egy számlakép-jogalkotó és egy NAV-képviselő a problémák tisztázásához, és lehetőleg egy jóval észszerűbb megoldás megalkotásához.

[Zdad2020]

Sziasztok,

INCORRECT_SUMMARY_DATA_INVOICE_NET_AMOUNT

Esetunkben 2 szamlakiallitas miatt van a fenti hibakod.

1. Nagykereskedelemben eseti vagy szerzodeses alapu ertekesites osztonzo bonuszokat adunk, mennyiseg vagy ertek fuggvenyeben, adott honapban vagy mas periodusokra meghatarozva. Ezt pl "Q2 forgalmi bonusz" negativ erteku szamlaval.

2. "Garancialis jovairasi ertek", negativ szamlaval, mert nem a termeket stornozzuk, es nem is vesszuk vissza, nem csereljuk. Egy viszontelado aki tobb szazat vasarol valamibol, negativ erteku szamlaval kapja vissza az adott termeken megmarad "ertek" jovairasat.
   Pl. Gumiabroncs: futofelulet hasznalat utan elkopik 60% ra es gyari hibaja lesz vasarlasi ertek 60%-ban kap "Garancialis Jovairast". Amennyibe ujat vasarol ennyivel kevesebbet fizet, ha meg nem az ertek visszautalodik a viszoneteladonak o meg a vegfelhasznalonak adja tovabb ugyanazt a szazalekos erteket.

Elore is koszonom ha van barmi megoldasotok.
Udv