Online-invoice: INCORRECT_LINE_DATA_UOM Warn

[sysati]

Mi értelme van az INCORRECT_LINE_DATA_UOM warnnak?
Miért kell az türelmi időszak lejárta előtt 1 héttel bekapcsolni egy olyan warnt, aminek szerintem egyáltalán nincs létjogosultsága?
Az éles rendszerbe is bekerül a mai karbantartás során?
Ha igen akkor holnap sok-sok program felhasználói tízezrével kapják majd a figyelmeztetéseket!

[lukacsb]

igen, köszönjük a NAV-nak ezt a szép ajándékot

[omachtandras]

Nálunk is tesztelték a kollégák, szintén érintettek vagyunk.
A fix megvan rá, de lehetetlenség egy nap alatt szétteríteni azt az ügyfélkörön.
Emlékeink szerint a dokumentációban korábban nem szerepelt, hogy ilyen esetben nem kerülhet töltésre ez az adat, így mi is azt gondoltuk, hogy plusz információ a befogadó/feldolgozó oldalnak, ha látja azt az adatot is, ami a számlaképen szerepel, így mindig töltöttük a UNIT_OF_MEASURE-t.

[DrotosTot]

Nekünk a többi, új WARN-hoz is kellene némi magyarázat, hogy legalább az összefüggést megértsük.
API doksi régi, itt a Github-on pedig 404 az aktuális verzió.

[NTCA-supporter]

Sziasztok!

Az interfész dokumentáció elérhető https://onlineszamla.nav.gov.hu/api/files/container/download/Online_Szamla_interfesz%20specifikacio_HU_v3.0.pdf
és
https://github.com/nav-gov-hu/Online-Invoice/blob/master/docs/API%20docs/hu/Online_Szamla_interfesz%20specifikacio_HU_v3.0.pdf
helyeken is.
A WARN indokoltságáról @NTCA-tax nyilatkozik szakmai oldalról.
Üdv

[omachtandras]

@NTCA-supporter : a dokumentáció részben ok, én a következő warnokról nem találtam benne leírás (kettőről említés sincs, a többi olyan szinten van megemlítve, hogy a 3.0-ban jelent meg, de nincs kifejtve, hogy miről szól):
INCORRECT_HEAD_DATA_SUPPLIER_GROUPMEMBER_TAXPAYERID
INCORRECT_LINE_DATA_VAT_OUT_OF_SCOPE_NORMAL
INCORRECT_LINE_DATA_VAT_EXEMPTION_NORMAL
INCORRECT_LINE_DATA_VAT_DOMESTIC_REVERSE_CHARGE_NORMAL
INCORRECT_LINE_DATA_VAT_DOMESTIC_REVERSE_CHARGE
INCORRECT_LINE_DATA_MARGIN_SCHEME_INDICATOR_NORMAL
INCORRECT_SUMMARY_DATA_VAT_DOMESTIC_REVERSE_CHARGE_NORMAL
INCORRECT_SUMMARY_CALCULATION_VAT_MARGIN_SCHEME_INDICATOR_SUMMARY_SIMPLIFIED
INCORRECT_SUMMARY_CALCULATION_VAT_AMOUNT_MISMATCH_SUMMARY_SIMPLIFIED

[sysati]

A WARN indokoltságáról @NTCA-tax nyilatkozik szakmai oldalról.
Üdv

Nagyon kíváncsi vagyok mivel lehet megindokolni egy totálisan indokolatlan warnt!
A dokumentációban most is benne van, hogy amikor be lett vezetve a unitOfMeasure egységesítése, akkor nem tilos a saját mennyiségi egység feltüntetése OWN-tól eltérő esetben sem (5.2. 7)).
Több fejlesztővel is egyeztetve, semmi okát nem látjuk annak, hogy erre figyelmeztetést kellene adni!

[renced42]

Nagyon kíváncsi vagyok mivel lehet megindokolni egy totálisan indokolatlan warnt!

Kedves @sysati

Ha valamivel nem értesz egyet akkor kérlek, hogy jelezd kifejtve a véleményed.
Elolvassuk megnézzük és megvitatjuk, közösen, de az hogy valamiről kijelented, hogy totálisan értelmetlen az kevés,

Köszi!

[EPluribusUnum]

@NTCA-supporter , @NTCA-tax , @renced42, nem a WARN-ok létjogosultság probléma, hanem az hogyha ezek mind kikerülnek a ma este tervezet éles frissítéssel. 1 napos határidő az tiszta őrület. Van elképzelésetek arról hogy ez milyen support-ot von maga után egy kvázi azonnali változtatás? Hol marad az idő a felkészülésre?

[sysati]

Nagyon kíváncsi vagyok mivel lehet megindokolni egy totálisan indokolatlan warnt!

Kedves @sysati

Ha valamivel nem értesz egyet akkor kérlek, hogy jelezd kifejtve a véleményed.
Elolvassuk megnézzük és megvitatjuk, közösen, de az hogy valamiről kijelented, hogy totálisan értelmetlen az kevés,

Köszi!

Fordítsunk meg a kérdést. Miért van ez a warn?

[omachtandras]

@renced42 : annyit vegyetek figyelembe, hogy a mi ügyfélkörünkben pl. ez a warn gyakorlatilag minden beküldött számlán megjelenik holnaptól, ahol a mértékegység be van sorolva NAV-os kóddal. Márpedig 99%ban be van. De gyanítom, hogy aki itt jelezte, hogy ez probléma, annál mind ez az arány, hiszen Ti is azt kommunikáltátok anno, hogy az enumban megadott mértékegységek gyakorlatilag lefedik a beküldött adatokat, ezért is így határoztátok meg őket.

Mi minden warnról értesítjük az ügyfelet. Holnap reggel azzal fognak szembesülni, hogy minden kiállított számla után jön az értesítés, hogy "gond van" az adatszolgáltatással. Hiába készül már a levél, amiben megpróbáljuk felkészíteni őket, amiben az elkészült patch telepítésére biztatjuk őket, ezt a levelet egy részük nem fogja holnap reggelig olvasni, másik részük nem fogja tudni elvégezni a patch telepítést számtalan okból kifolyólag és mindennek az lesz a következménye, hogy az ügyfélszolgálatot fogják bombázni telefonokkal, hogy most mi van, "elromlott a program"?

[rgform]

Ez az utolsó érvényes dokumentációbol van kiollózva:

NAV Online Számla rendszer 186. oldal
7) A számlasorban bevezetésre került egy saját mennyiségi egység típus. Ezt akkor szükséges használni, ha a számlán szereplő mennyiségi egység nem sorolható be a unitOfMeasure elem értéklistájában szereplő mennyiségi egységek egyikébe sem, így a unitOfMeasure elemben "OWN" érték szerepel. Ha a kanonikus mennyiségi egység értéke OWN, és a saját mennyiségi egység nincs megadva, akkor a rendszer egy WARN-üzenetet ad vissza. Nem tilos a saját mennyiségi egység feltüntetése akkor sem, ha a unitOfMeasure elemben "OWN"-tól különböző érték szerepel.

[renced42]

Kedves @omachtandras, @EPluribusUnum, @sysati

Köszönjük a jelzést és a kifejtést, megvizsgáljuk a problémát.

[nbeeps2]

renced42: Én is kérlek benneteked, hogy ezt a WARN-t semmiképpen ne telepítsétek az éles rendszerbe, mert az összes(!) ügyfelünk, összes(!) számláját érinti. A program a dokumentációnak megfelelően működik, vagyis: " Nem tilos a saját
mennyiségi egység feltüntetése akkor sem, ha a unitOfMeasure elemben "OWN"-tól
különböző érték szerepel."

A WARN tehát ez esetben egyértelműen BUG a részetekről és sürgős megoldást várunk!

[nbeeps2]

A mező lényegege ugyanis pont az volt, hogy ne veszítsük el a számlán lévő eredeti mennyiségi egységet és ez bekerüljön az adatszolgáltatásba és ne vesszen el a DARAB=PIECE konvertálás közben, így lehet tudni, hogy db, darab, pc, piece vagy bármi más volt eredetileg. Ez FONTOS!!!

[NTCA-supporter]

Sziasztok!

Egyeztettünk, kikapcsoljuk ezt a WARN-t. Amíg ez kikerül teszt környezetig, addig nem élesítjük a 3.5 verziót.
Ez várhatóan jövő hét elején történik meg, így az élesítés is jövő hétre tolódik (a már kikapcsolt állapottal).

Amiket @omachtandras említett hiányos warn leírásokat, valóban pótolandó, ezt ma/holnap megtesszük.

Köszönjük a megértést.
Amíg teszt rendszeren ez az állapot van, addig maradjon nyitva az issue, hogy emiatt senki ne nyisson újat.

Üdv

[DrotosTot]

@NTCA-supporter : köszönöm az ügyfeleink nevében is!

[bcdel]

Azért az a kérdés felmerül, hogy

A következő frissítésben "még kikapcsoljuk" ezt a WARN-t, de hosszutávon ez az irányvonal, és csak haladékot kaptunk 1 nap helyett ($nextversion) nap lesz. Tehát mehet a fejlesztés és frissítés...

VAGY

Megszületett a döntés, hogy kivezetésre kerül ez a WARN és érvényben marad a dokumentáció azon pontja, hogy meg szabad adni a számlán lévő saját mennyiségi egységet is nem OWN esetben. És nem kell ehhez hozzányúlni.

VAGY

még ez sem tiszta...

[NTCA-supporter]

Jogos, engedd meg, hogy tőled idézzek :)
Megszületett a döntés, hogy kivezetésre kerül ez a WARN és érvényben marad a dokumentáció azon pontja, hogy meg szabad adni a számlán lévő saját mennyiségi egységet is nem OWN esetben.
A WARN-t kiszedjük a dokumentációból is hamarosan.
Üdv

[nbeeps2]

NTCA-supporter köszönjük.

A fejlesztői naplóban 2019/6 A fejlesztő válaszol vol 2. (2019.02.06) annak idején volt erről egy részletes post, mert a unitOfMeasure törzsesítése akkor nagy port kavart az 1.1-ben. Ezért is volt meglepő ez a WARN, mert ezt már tisztáztuk akkor, hogy a unitOfMeasureOwn mire is való.

"1) Kezdem a legforróbb témával: átbeszéltük és megvitattuk a mennyiség egységek kezelésének lehetőségeit. Figyelemmel arra, hogy látunk olyan megoldást, amely mindkét oldal megelégedésére szolgálhat, úgy döntöttünk hogy adunk ki rendkívüli verziót, amelyben eltöröljük a unitOfMeasureOwn tag megadhatóságát szabályozó INVALID_UNIT_OF_MEASURE_OWN validációt. Mindez azt jelenti, hogy a verzióváltást követően a unitOfMeasure tag kitöltése továbbra is kötelező marad lineExpressionIndicator = true esetében, azonban tetszőlegesen eldönthető lesz, hogy a unitOfMeasureOwn ez mellett megadásra kerül-e, a kettő közötti XOR megszűnik. Ennek megfelelően a unitOfMeasure átalakul egyfajta kanonikus mennyiségi egységgé, míg a unitOfMeasureOwn megtartható egy literális mennyiségi egységnek. A unitOfMeasureOwn tagban megadható az a mennyiségi egység olyan alakban, ami és ahogy a kiállított számlán szerepel. A validáció eltörlésével párhuzamosan behozunk egy új WARN üzenetet (INCORRECT_LINE_DATA_UOM_INCOMPLETE), ami unitOfMeasure = OWN esetén figyelmeztet, ha a unitOfMeasureOwn tag nincs megadva."

Köszönjük a gyors belátásokat és hogy nem kerül ki a WARN az élesbe!

[NTCA-supporter]

@omachtandras frissítettem a dokumentációt mindenhol.
Üdv

[omachtandras]

@omachtandras frissítettem a dokumentációt mindenhol.
Üdv

Szuper, köszönjük, nézzük!

[NTCA-supporter]

Sziasztok!
A INCORRECT_LINE_DATA_UOM WARN kikapcsolás kikerült teszt környezetre.
Kérlek zárjátok az issuet, ha nincs több kérdés.
Üdv