Online-invoice: Könyvelő szemmel 2.0

[bartanorbi]

Sziasztok,

A 308-as hozzászólásomban az alábbi problémákat vetettem fel:
-a számla fizetés módja és fizetés határideje nem kötelező adat (naplók, analitika stb probléma)
Válaszotokban leírtátok, hogy a fenti adatokat a jogszabály nem követeli meg. Kérdésem az lenne, hogy jeleztétek-e a jogalkotónak az érintett jogszabály megváltoztatása iránti igényt?
-felvásárlási jegy hiány
Válaszként írtátok, „Nem várhatjuk mindenre ez a rendelet szállítsa a megoldást, erre szerintem nem lesz más válasz, csak az hogy a felvásárlási jegy nem számla ..
A felvásárlási jegy tartalmazhat áfát. Ha a NAV nem akarja látni, akkor hogyan akarja elkészíteni az áfabevallást? Itt had kérdezzem meg, hogy ki találta ki az e-áfa projektet? S ezt a projektötletet miért nem látták szakemberek? Ki hagyta jóvá? Bármelyik szakember (NAV, könyvvizsgáló, adótanácsadó stb) elmondja, hogy ennek a fejlesztésnek nincs értelme, felesleges erre fecsérelni az erőforrásokat. Amúgy van egy telefonszám, ahol nagyon kedves emberek adnak tanácsot. Használata: 1819-es szám tárcsázása, majd az 1-es, utána a 4-es gombot megnyomni, és várni. Ott is el fogják mondani, hogy az e-áfa projekt –finoman szólva- butaság.
-pénztárgéppel kiállított számlák hiánya (ezeket valahogy be kellene dolgozni az online számlába)
Válaszként írtátok, hogy „erre a szándék már megvan”. Csak az a baj, hogy sokszor a szándék nem elég, meg is kellene valósítani. Ez nagy segítség lenne.
Kérlek, nézzétek meg, hogyan néz ki egy áfa bevallás, főleg az M-es lapokat. Itt megint lenne egy kérdésem: Ki volt az név szerint, akinek köszönhetük az M-es lap ezen változtatásait.
-szürkeszámlák problémája (nem a cég által szerzett, de a cég nevére szóló számlák)
Írtátok, hogy nálatok ezek a "Metro" számlák. A legszebb az, hogy ezek a számlák a NAV által előállított áfa bevallásban is benne lesznek...
-Lekérdezés max 100 számla (ez vicc, ha egy napra szűröm, és meghaladja a 100 db-ot akkor a többit honnan) Könyvelőprogramok már tudják kezelni… de a NAV online számlával ennél nagyobb bajok is vannak.
Az a baj, hogy még mindig azt gondolom, hogy a NAV online számla akár számunkra is egyszer hasznos lehet. De egyelőre nagyon rossz, a belőle kinyert számlaadatok rendkívül hiányosak, így az egész használhatatlan, s megbízhatatlan. NAV honlapján megjelent, hogy nem fognak szankcionálni március 31-ig. Azt ugye mindenki tudja, hogy Miattatok kell tolni az XML 3.0-nak a bevezetését. Továbbá 2020. harmadik negyedévére ígértétek a pénztárgép zárások letölthetőségét is, az sem sikerült elkészíteni (a covidra fogtátok, de csak halkan jegyzem meg, hogy ez nem olyan vírus, ami a számítógépeket támadja meg.) Egyáltalán akkor mit csináltok?
Mert az, hogy az eddigi fejlesztésekkel nekem több munkát adtok, abban biztos vagyok.

[nbeeps2]

bartanorbi, akkor ezek szerint gondolom Te könyvelő vagy, nem fejlesztő. Bizonyos dolgokat csak akkor fogsz megérteni, ha fejlesztőként gondolkodsz. A NAV Online számla rendszer nem old meg mindent egy csapásra, leginkább ez a NAV-nak jó, hogy könnyebben lássa kik csalnak. Nekünk fejlesztőknél senkinek nem okozott ez több plusz munkát. A könyvelő viszont profitálhat belőle, ha a könyvelő programja kezeli ezt, mert az adatrögzítést jelentősen felgyorsítja azzal, hogy nem kell kézzel begépelni a számlák (kimenő/bejövő) adatait. Persze a könyvelő program nem fogja neked automatán lekönyvelni a dolgokat, továbbra is dolgozni kell. Igen, sok minden nincs benne a rendszerben, nem csak a felvásárlási jegyek, nem csak a pénztárgépes számlák, hanem a külföldi partnerek által kiállított számlák sem (nem is lesznek soha). A számla emberi szemmel történő szemrevételezését semmi nem helyettesíti! Az nem fog menni, hogy te nyomsz egy gombot a könyvelő programodban, hátradőlsz és minden letöltődik és lekönyvelődik. Ilyet nem lehet, mert nincs bent a rendszerben annyi információ, ami alapján ez felelősen és 100%-osan megtehető. Viszont rengeteg időt spórolhatsz azzal, hogy nem kézzel rögzíted a számlák alapadatait, nektek könyvelőknek tehát csak ennyi pluszt jelent ez a rendszer.

Azért valamiben egyetértünk: Az M-es nyomtatványt megszüntetném, az e-áFA projekt egy mission impossible.

[omachtandras]

@nbeeps2 : "Nekünk fejlesztőknél senkinek nem okozott ez több plusz munkát. "
Azért ezzel vitatkoznék. Nem tudom, hogy ki az, akinek semmi fejlesztést nem kellett ezzel kapcsolatban végeznie, de kétlem, hogy lenne olyan, akinek pont ilyen struktúrában már éppen előállt egy ilyen adatszolgáltatás a rendszeréből még az előtt, hogy a NAV ezt az egészet kitalálta.

[connorhu]

Mint fejlesztő mondom, hogy okozott plusz munkát az adatátadás, viszont a számla séma átgondoltsága az messze az iparágban tapasztalható átlagon felüli. Nem kevés számlázó és könyvelő programot tudnék felsorolni ahol szakmai szemmel borzalmas kókányolás történt és történik. Kezdve az xls alapú "adatátadáson" át a borzalmas és hiányos dokumentáción, befejezve következetlen nevezéktannal létrehozott kommunikációs "sémán".
Szóval azért a mit adtak nekünk a rómaiak kérdéskör messze nem egyoldalú.

[bartanorbi]

Köszi a választ.. Megjegyzéseidre pár gondolat

1. akkor ezek szerint gondolom Te könyvelő vagy, nem fejlesztő.
   Igen, könyvelő vagyok, de még anno fejlesztő cégnél is dolgoztam, igaz csak koordinátorként,
2. Bizonyos dolgokat csak akkor fogsz megérteni, ha fejlesztőként gondolkodsz. A NAV Online számla rendszer nem old meg mindent egy csapásra, leginkább ez a NAV-nak jó, hogy könnyebben lássa kik csalnak.
   Ez egyértelmű, ahogy Ti Fejlesztők is sok mindent nem értetek, hogy nekünk mi kellene.
3. A könyvelő viszont profitálhat belőle, ha a könyvelő programja kezeli ezt, mert az adatrögzítést jelentősen felgyorsítja azzal, hogy nem kell kézzel begépelni a számlák (kimenő/bejövő) adatait.
   Éppen ez a lényeg!!! Profitálhatnánk belőle, ha kapnánk egy normális, teljeskörű adatbázist. De jelenleg nincs! S tavaly azt gondoltam, hogy július 1-től már tudom használni, de akkor derült ki, hogy rengeteg adat nincs benne, ezért írtam meg akkor a hozzászólásomat problémákról.
4. Persze a könyvelő program nem fogja neked automatán lekönyvelni a dolgokat, továbbra is dolgozni kell.
   De ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni. pl egy adott cég által kiállított számlán, az adott tétel megnevezése alapján automatikusan kontírozza ki a szoftver.
5. Igen, sok minden nincs benne a rendszerben, nem csak a felvásárlási jegyek, nem csak a pénztárgépes számlák, hanem a külföldi partnerek által kiállított számlák sem (nem is lesznek soha).
   Felvásárlási jegyek nélkül nincs e-áfa. Első körben a –ahogy megígérték- a pénztárgépes számlákat kellene migrálni. Ez már segítség lenne. Külföldi partnert meg azért nem írtam le, mert arra nincs ráhatása a NAV-nak.
6. Az nem fog menni, hogy te nyomsz egy gombot a könyvelő programodban, hátradőlsz és minden letöltődik és lekönyvelődik. Ilyet nem lehet, mert nincs bent a rendszerben annyi információ, ami alapján ez felelősen és 100%-osan megtehető. Viszont rengeteg időt spórolhatsz azzal, hogy nem kézzel rögzíted a számlák alapadatait, nektek könyvelőknek tehát csak ennyi pluszt jelent ez a rendszer.
   Nincs benne annyi információ? Ezért írom a hozzászólásomat, hogy legyen benne. Egy normális adatbázis után már lehetne a könyvelőprogramot fejlesztőkkel beszélni, hogyan lehetne egyszerűsíteni a munkánkat. Ahogy már most is – amit lehet – automatikusan kontíroz. Rengeteg időt spórolhatnék? Igen, ha az adatbázis teljes lenne…..
   Kicsit kifejtve:
   Ha lekérjük a jelenlegi adatbázist:
   Lekérjük a számlákat a NAV online számlából, és a hiányzó adatokkal (fizetés határideje, fizetés módja) kiegészítjük az adatbázist. (ehhez az kell, hogy elővegyük a számlákat, sorba rakjuk stb.) A két adat minden! számlánál kötelezően benne lenne, akkor pl már a számlák naplókba való elhelyezésével már nem kellene foglalkozni.
   A letöltött bizonylatok kikontírozzuk. (itt az a probléma, hogy a legtöbb program előre kéri azt, hogy tételszinten vagy áfa összesen szerint szeretnénk könyvelni. S ezzel az a baj, hogy csak a számla látta után tudom megmondani, hogy hogyan szeretném.
   A NAV online számlából lekérhető bizonylatok lekönyvelésre kerültek. Most össze kell vetnünk, hogy melyek azok a bizonylatok, amelyek itt vannak, viszont a NAV online számlában nincsenek. Összevetés után manuálisan lekönyveljük. Azokról a számlákról, melyek úgy tűnnek, hogy nem pénztárgéppel állítottak ki, és nem volt benne a NAV online rendszerben, azt félretesszük, és jelezzük az ügyfélnek, hogy az adott számla elméletileg nincs lejelentve, ezért nézzen utána, hogy mi legyen vele.
   Persze az egyéb problémákat nem hozom fel, pl a Metro számlákat problémáját, mert arról a NAV online számla nem tehet….
   Összegezve, ha kapnánk egy normális adatbázist, az jelentősen pontosabbá és könnyebbé tenné munkánkat.

[omachtandras]

@bartanorbi : "De ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni. pl egy adott cég által kiállított számlán, az adott tétel megnevezése alapján automatikusan kontírozza ki a szoftver."
Ez működhet egy jó szoftverrel. Nem tudom, hogy más hogy áll a feldolgozással, mi rengeteg energiát tettünk bele, és most már van olyan cégünk, ahol 95%os az automata feldolgozási arány pusztán a NAV-tól kapott adatokra és a szoftver betanítására építve.
És a feldolgozás könyvelést + ÁFA bevallást (M lappal együtt) jelent.

[nbeeps2]

@omachtandras , @connorhu : úgy látom mindketten félreértettétek, amit írtam: ""Nekünk fejlesztőknél senkinek nem okozott ez több plusz munkát. " -> Jelentése: senki másnál nem okozott ez több munkát/fejfájást, mint nekünk fejlesztőknek. Magyarán a fejlesztőket érintette ez legjobban, ők dolgoztak vele a legtöbbet. Remélem így már világos a mondat ;)

[nbeeps2]

@bartanorbi
_"Ez egyértelmű, ahogy Ti Fejlesztők is sok mindent nem értetek, hogy nekünk mi kellene."_
Ó dehogynem értjük, csak a felhasználói oldal sokszor nincs tisztában a lehetőségekkel, csak a vágyálmok jönnek, de azt már nem látják át, hogy mit-miért nem lehet megvalósítani. Értem mit akarsz, letölteni a számlákat és azokat automatán kézi beavatkozás nélkül lekönyvelni, de ez fizikai képtelenség. Nem tudod kivenni az emberi tényezőt, vagy ha kiveszed, akkor a jó kis automatizmus, majd szépen félrekönyveli a dolgokat...

_"De ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni. pl egy adott cég által kiállított számlán, az adott tétel megnevezése alapján automatikusan kontírozza ki a szoftver."_
És azt ki fogja felparaméterezni, hogy melyik megnevezést hová kell könyvelni? Te! Tehát ugyanúgy elvégzed a munkát és az egész egyáltalán nem lesz tévedhetetlen. A számla megnevezésére nem vagy kihatással. A számla kiállító bárhogy fogalmazhatott, tehetett bele dátumokat (pl. "2021. január bérleti díj" <>"bérleti díj" <> "Ez nem egy bérleti díj" <> "Bérleti díjnak nem minősül"), bármit. Arról már nem is beszélve, hogy a számlán sok helyen lehetne megjegyzések. Ezért írtam, hogy a számla szemrevételezét kizárva orosz rulett/vágyálom könyvelni.

_"Nincs benne annyi információ? Ezért írom a hozzászólásomat, hogy legyen benne"_
Én itt arra gondoltam, hogy nincs benne főkönyvi szám és nem is lesz várhatóan, mint ahogy a legtöbb számlázó programban nincs is főkönyvi szám, de ha lenne sem releváns a befogadó számlatükrével... Ennek ismeretében pedig nincs más lehetőség, mint áttekinteni a számla tételeit, értelmezni, hogy ott milyen gazdasági esemény történt és az alapján kontírozni.

[nbeeps2]

@omachtandras : _"Ez működhet egy jó szoftverrel. Nem tudom, hogy más hogy áll a feldolgozással, mi rengeteg energiát tettünk bele, és most már van olyan cégünk, ahol 95%os az automata feldolgozási arány pusztán a NAV-tól kapott adatokra és a szoftver betanítására építve.
És a feldolgozás könyvelést + ÁFA bevallást (M lappal együtt) jelent."_

Igen, ez a nagyon max, ami kihozható belőle, a félautomata működés. Ha egy új ügyfél kezdi el használni a szoftvereteket és megnyomná a letöltést, tehetetlen a Ti szoftveretek is. Fel kell programozni/paraméterezni. Teljesen automatán úgy, ahogy a könyvelők képzelik el nem lehet megcsinálni. Még ezzel a módszerrel is lesz utána munka, mert ha jön egy új bejövő számla egy olyan partnertnől, akitől még nem jött vagy más témában, mint eddig, azzal megint nem fog tudni mit kezdeni a rendszer. Automata rendszer tehát nem létezik.

[jozanesz]

-a számla fizetés módja és fizetés határideje nem kötelező adat (naplók, analitika stb probléma)
Válaszotokban leírtátok, hogy a fenti adatokat a jogszabály nem követeli meg. Kérdésem az lenne, hogy jeleztétek-e a jogalkotónak az érintett jogszabály megváltoztatása iránti igényt?

Ezzel igen sok ember életét megkeserítenéd, ha a fizetés módját számlaadattá tennéd. (Vagy hamis és értelmetlen adatot követelnél.) Hadd fizessenek már úgy, ahogy akarnak. Nagyon helyesen még azt sem kell tudni az adatszolgáltatáskor, hogy e-számla lesz-e belőle. A fizetés meg még sokkal messzebb van.

[nbeeps2]

@jozanesz: Igen, arról nem is beszélve, hogy a számlán lévő fizetési mód még nem kötelezi a vevőt, hogy valóban azzal fizessen. Tehát egy átutalásos számla is fizethető készpénzzel és a számlát nem kell stornózni/módosítani.

[omachtandras]

@nbeeps2 : én még nem találkoztam olyan könyvelővel, aki ne akart volna ránézni és egy teljesen automata működést akart volna. De adatot rögzíteni talán a többség nem akar, ha megoldható, hogy azt a gép tegye, még ha meg is kell rá tanítani egyszer.

Abban egyetértek @bartanorbi -val, hogy bőven lennének olyan pontok, ahol változtatni kellene.

Azt várom, hogy a NAV is rá fog jönni, hogy a számla adatszolgáltatás jelenlegi szintjéből nem fog tudni még egy használható beajánlást sem tenni a vállalkozások 99%ának, de ezt már korábban más issue-ban leírtam.

Nálunk a kollégák elég szép listát írtak arról, hogy milyen információkkal nem rendelkezik a NAV és erősen készülünk rá, hogy az ügyfélszolgálat miként tudja majd elmagyarázni az érdeklődőknek, hogy miért nem egyezik a programunk által készített ÁFA bevallás a NAV által beajánlottal, milyen pontokon kereshetik az eltéréseket... Augusztusban a szabadságolások idején nagyszerű móka lesz...

[bartanorbi]

@bartanorbi : "De ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni. pl egy adott cég által kiállított számlán, az adott tétel megnevezése alapján automatikusan kontírozza ki a szoftver."
Ez működhet egy jó szoftverrel. Nem tudom, hogy más hogy áll a feldolgozással, mi rengeteg energiát tettünk bele, és most már van olyan cégünk, ahol 95%os az automata feldolgozási arány pusztán a NAV-tól kapott adatokra és a szoftver betanítására építve.
És a feldolgozás könyvelést + ÁFA bevallást (M lappal együtt) jelent.

Igen, én is ezt szeretném, a teljes automatizáció kimenő számlákkal már most is működik, bejövő számlák esetén csak azoknál lehet, akik önszorgalomból küldik a két adatot (fizetés módja, fizetés határideje)

[bartanorbi]

@omachtandras , @connorhu : úgy látom mindketten félreértettétek, amit írtam: ""Nekünk fejlesztőknél senkinek nem okozott ez több plusz munkát. " -> Jelentése: senki másnál nem okozott ez több munkát/fejfájást, mint nekünk fejlesztőknek. Magyarán a fejlesztőket érintette ez legjobban, ők dolgoztak vele a legtöbbet. Remélem így már világos a mondat ;)

Igen ezzel részben egyetértek, Ti megszívtátok nagyon, de mi is könyvelők,,, NAV online számlával...

[bartanorbi]

@bartanorbi
_"Ez egyértelmű, ahogy Ti Fejlesztők is sok mindent nem értetek, hogy nekünk mi kellene."_
Ó dehogynem értjük, csak a felhasználói oldal sokszor nincs tisztában a lehetőségekkel, csak a vágyálmok jönnek, de azt már nem látják át, hogy mit-miért nem lehet megvalósítani. Értem mit akarsz, letölteni a számlákat és azokat automatán kézi beavatkozás nélkül lekönyvelni, de ez fizikai képtelenség. Nem tudod kivenni az emberi tényezőt, vagy ha kiveszed, akkor a jó kis automatizmus, majd szépen félrekönyveli a dolgokat...

_"De ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni. pl egy adott cég által kiállított számlán, az adott tétel megnevezése alapján automatikusan kontírozza ki a szoftver."_
És azt ki fogja felparaméterezni, hogy melyik megnevezést hová kell könyvelni? Te! Tehát ugyanúgy elvégzed a munkát és az egész egyáltalán nem lesz tévedhetetlen. A számla megnevezésére nem vagy kihatással. A számla kiállító bárhogy fogalmazhatott, tehetett bele dátumokat (pl. "2021. január bérleti díj" <>"bérleti díj" <> "Ez nem egy bérleti díj" <> "Bérleti díjnak nem minősül"), bármit. Arról már nem is beszélve, hogy a számlán sok helyen lehetne megjegyzések. Ezért írtam, hogy a számla szemrevételezét kizárva orosz rulett/vágyálom könyvelni.

_"Nincs benne annyi információ? Ezért írom a hozzászólásomat, hogy legyen benne"_
Én itt arra gondoltam, hogy nincs benne főkönyvi szám és nem is lesz várhatóan, mint ahogy a legtöbb számlázó programban nincs is főkönyvi szám, de ha lenne sem releváns a befogadó számlatükrével... Ennek ismeretében pedig nincs más lehetőség, mint áttekinteni a számla tételeit, értelmezni, hogy ott milyen gazdasági esemény történt és az alapján kontírozni.

Vannak könyvelési programok, ahol ezek működnek. Amúgy a banki kivonatoknál az automatikus kontírt is mi paraméterezzük.
Az információs válaszodat nem értem.. két számla adatról volt szó, az egyik a fizetés módja és a fizetés határideje, amivel a jelenlegi adatokat kötelezően ki kellene egészíteni. Van aki küldi, van aki nem,,,, Nem értem, hogy itt milyen főkönyvi számokról beszélsz....

[bartanorbi]

-a számla fizetés módja és fizetés határideje nem kötelező adat (naplók, analitika stb probléma)
Válaszotokban leírtátok, hogy a fenti adatokat a jogszabály nem követeli meg. Kérdésem az lenne, hogy jeleztétek-e a jogalkotónak az érintett jogszabály megváltoztatása iránti igényt?

Ezzel igen sok ember életét megkeserítenéd, ha a fizetés módját számlaadattá tennéd. (Vagy hamis és értelmetlen adatot követelnél.) Hadd fizessenek már úgy, ahogy akarnak. Nagyon helyesen még azt sem kell tudni az adatszolgáltatáskor, hogy e-számla lesz-e belőle. A fizetés meg még sokkal messzebb van.

A számla fizetés módja és a határideje már most is számlaadat, csak nem kötelező.. Nézd meg bármelyik szoftverrel kiállított számlát. Ha egy készpénzfizetési számlatömb számláját nézed, akkor az nem ér... :-)

[bartanorbi]

@jozanesz: Igen, arról nem is beszélve, hogy a számlán lévő fizetési mód még nem kötelezi a vevőt, hogy valóban azzal fizessen. Tehát egy átutalásos számla is fizethető készpénzzel és a számlát nem kell stornózni/módosítani.

Ez így van, de ez hogy jött ide????

[nbeeps2]

@bartanorbi : "Ez így van, de ez hogy jött ide????" : annak kapcsán írtam, hogy hiába kapod meg a fizetési módot, mint adat, azzal nem tudsz feltétlen könyvelni, mert a fizetési mód<>a valós fizetési móddal.

A főkönyvi számokat meg azért írtam, mert az lenne az a konkrét adat, ami jelölné (a terméknévtől függetlenül), hogy az adott számlasor hová könyvelendő, minek számít. A termék nevéből ugyanis nem tudsz kiindulni a program szempontjából, mert az lehet bármi. Erre hoztam feljebb példákat is.

Elég csak belegondolni, miként történik egy bejövő számla könyvelése. Kezembe veszem a számlát, megnézem, hogy miről állították ki. Ez alapján eldöntöm, hogy ez milyen gazdasági esemény és az adott cég tevékenységét miként érinti és az alapján könyvelem. Nos, ez programmal automatán megoldhatatlan. Aminek örülni kell, így szükség van/lesz továbbra is a könyvelőkre :)

[bartanorbi]

@bartanorbi : "Ez így van, de ez hogy jött ide????" : annak kapcsán írtam, hogy hiába kapod meg a fizetési módot, mint adat, azzal nem tudsz feltétlen könyvelni, mert a fizetési mód<>a valós fizetési móddal.

A főkönyvi számokat meg azért írtam, mert az lenne az a konkrét adat, ami jelölné (a terméknévtől függetlenül), hogy az adott számlasor hová könyvelendő, minek számít. A termék nevéből ugyanis nem tudsz kiindulni a program szempontjából, mert az lehet bármi. Erre hoztam feljebb példákat is.

Elég csak belegondolni, miként történik egy bejövő számla könyvelése. Kezembe veszem a számlát, megnézem, hogy miről állították ki. Ez alapján eldöntöm, hogy ez milyen gazdasági esemény és az adott cég tevékenységét miként érinti és az alapján könyvelem. Nos, ez programmal automatán megoldhatatlan. Aminek örülni kell, így szükség van/lesz továbbra is a könyvelőkre :)

paymentMethod xs:string Nem Fizetés módja
paymentDate xs:date Nem Fizetési határidő
Erről a két adatról beszéltem, hogy ezeket kellene kötelezővé tenni (ehhez kellene jogszabály változtatása), így a letöltött számlák automatikusan az érintett könyvelési naplóba (pénztár, szállító (ha átutalás/transfer akkor pl a szállító naplóba) kerülhetnének. Ez működik a Novitax-nál is és a Magnumnál is, de sajnos nem megbízható, mert a számlák egy része tartalmazza az adatokat másik része nem, hiszen nem kötelező. (pl: Számlázz.hu küldi, a Spar meg nem küldi) Tehát az egész adatbázis ezért megbízhatatlan. NAVnak jelezni akartam, hogy ezek a mezők nagyon kellenének.
Nézegetve a specifikációt, úgy tűnik, hogy az alábbi adatok sem kötelezően küldendő… bár lehet, hogy rosszul értelmezem, mert láttam már olyan letöltött számlát, ahol ezek az adatok lejöttek…bár ha ez sem kötelező, tehát nem mindenki küldi, akkor az egész adatbázis ebből a szempontból sem megbízható. S ezek az adatok ahhoz kellenének, hogy pl a KAtások 3 milláját figyelni lehessen. Persze manuálisan is be lehet állítani az adózási módot a partnernél, de mi van akkor, ha év közben megváltozik… ezt folyamatosan minden partnernél figyelni képtelenség… pénzforgalmi elszámolás meg ugye egyértelmű…
smallBusinessIndicator xs:boolean Nem Kisadózó jelzése
cashAccountingIndicator xs:boolean Nem Pénzforgalmi elszámolás

„ez lenne a cél, hogy a visszatérő gazdasági eseményeket automatikusan le lehessen könyvelni” én ennyit írtam, semmilyen hiányzó adatként főkönyvi számot nem jelöltem meg, mert hatalmas hülyeség lenne. A visszatérő számlák esetén, tehát van pl egy könyvelői számla, amit letöltök, a korábban hiányolt adatokkal együtt, Amikor először foglalkozom a számlával, akkor eldöntöm, hogy érdemes-e ahhoz a szállítónak az adott számlatételéhez főkönyvi számot rendelni. Könyvelői számla esetén igen, hiszen minden hónapban visszatérő gazdasági eseményről van szó, és ugye minden hónapban ugyanarra a főkönyvi számra könyveled, tehát erre érdemes létrehozni egy automatikus kontírt. Ha esetleg a könyvelő a számlatételbe beleírja pl a hónap nevét, akkor az automatikus kontírt úgy állítom be, hogy a tétel bizonyos részét figyelje… pl tartalmazza a „könyvelési” szövegrészt. Természetesen ezt még lehetne fokozni, hogy minél felhasználóbarátabb legyen, de sajnos nagyon úgy tűnik, hogy ez még várat magára, hiszen először egy megbízható adatbázis kellene a NAV-nak létrehoznia, amibe benne vannak a korábban említett adatok, mint pl a pénztárgéppel kiállított számlák. Egyértelmű az automatikus kontír a pénztárgép zárások esetében, ott csak az adott pénztárgépszámhoz hozzárendelek pl egy főkönyvi számot, és annyi, de azért biztonság kedvéért a lekönyvelt tételeket ellenőrzöm, pl a GT-vel.

Ahogy júliusban is írtam, jó lenne a rendszer, és lelkes is voltam nagyon, de amit a NAV megígért, sajnos abból semmi nem valósult meg, amivel esetleg könnyebbé tenné a dolgomat. Egyelőre ugyanúgy könyvelünk, mint 1 évvel ezelőtt, csak a szívás van a megváltozott áfa bevallással, a korrekciós cuccokkal, stb
Álláspontom az, hogy először ki kellene valahogy a NAV*-tól kényszeríteni egy normális adatbázist, utána meg jöhettek Ti, Fejlesztők, hogy programozzátok le úgy, hogy nekünk könnyebb legyen. S az a fejlesztő cég, akinek ez a legjobban sikerül, annál leszek én jövőre… :-)

[omachtandras]

@bartanorbi ahogy a kollégák írták, a fizetési mód az nagyon nem egyértelmű. Mi lesz pl. akkor, ha a vásárlás során a felét kártyával fizetjük ki, a másik fele meg mehet utalással?

Véleményem szerint a könyvelő szoftver oldaláról kellene elgondolkodni ezen a merevnek tűnő napló dolgon és találni valami olyan megoldást, amivel kezelhető a fizetési mód nem megléte, vagy az 1:1 kapcsolatnál bonyolultabb esetek is (és ott van még az, amit @jozanesz említett, simán lehet, hogy egy utalásos számlát mégis befizetnek a pénztárba, mert úgy egyszerűbb/célravezetőbb).

(Csak csendben jegyzem meg, hogy csodálkozom, hogy az nem merült még fel Nálatok problémaként, hogy a határozott időszaki számlák időszak vége dátumát rengeteg szoftver nem adja át, pedig arra aztán tényleg szükség lenne, nem csak könyvelési oldalon... Nálunk van olyan ügyfél, ahol szinte csak ezért kell hozzányúlni a számlákhoz és a feldolgozást kiegészíteni...)

[bartanorbi]

@bartanorbi ahogy a kollégák írták, a fizetési mód az nagyon nem egyértelmű. Mi lesz pl. akkor, ha a vásárlás során a felét kártyával fizetjük ki, a másik fele meg mehet utalással?

Véleményem szerint a könyvelő szoftver oldaláról kellene elgondolkodni ezen a merevnek tűnő napló dolgon és találni valami olyan megoldást, amivel kezelhető a fizetési mód nem megléte, vagy az 1:1 kapcsolatnál bonyolultabb esetek is (és ott van még az, amit @jozanesz említett, simán lehet, hogy egy utalásos számlát mégis befizetnek a pénztárba, mert úgy egyszerűbb/célravezetőbb).

(Csak csendben jegyzem meg, hogy csodálkozom, hogy az nem merült még fel Nálatok problémaként, hogy a határozott időszaki számlák időszak vége dátumát rengeteg szoftver nem adja át, pedig arra aztán tényleg szükség lenne, nem csak könyvelési oldalon... Nálunk van olyan ügyfél, ahol szinte csak ezért kell hozzányúlni a számlákhoz és a feldolgozást kiegészíteni...)

Fizetési mód egyértelmű, a specifikációban is benne (transfer, cash stb) ezt kértem kötelezővé tenni.
Ha egy utalásos számlát pl a szállító naplóba raksz, utána a számla kifizetése bármivel történhet, (bankon keresztül, vagy csekk formájában, vagy ezek kombinációja igazándiból mindegy, ezt kezeli bármelyik könyvelő program) tehát ez nem probléma.

A csendes megjegyzésedet igazán nem értem. Milyen szoftvernek kellene mit átadnia? Én a NAV online számlából lekérdezendő számlák adattartalmáról írtam. Időszaki elszámolás ügyleteknél a könyvelőprogramunk tartalmaz egy áfa dátuma mezőt, mely alapjáraton a számla teljesítés dátumát hozza, ha esetleg az érintett számla más áfa bevallási időszakot érint, akkor azt a dátumot kell beírni. Amúgy sok adat még jó lenne, ha benne lenne. pl az elszámolási időszak kezdete, vége, ami pl jól jönne az elhatárolásoknál :-) De hát azért mindent nem akarjunk :-))))

[omachtandras]

@bartanorbi : milyen naplóba teszed még a NAVtól letöltött szállítói számlákat, ha nem a szállító naplóba?

A struktúra tartalmazza a határozott időszaki számlák esetén az időszak kezdete és vége dátumot. A számlán szerepel, mégis nagyon sok számlázó nem adja át az adatot, annak ellenére, hogy a számlán szerepel. Ezt írtam. Azok a mezők sem kötelezőek a struktúrában, és - szerintem - sajnos nincs kikényszerítve, hogy az időszak vége dátum megadása kötelező legyen, ha egyébként jelöli az adatátadó, hogy egy egy ilyen számla... Ezt én sokkal-de sokkal fájóbb pontnak látom könyvelés és ÁFA bevallás szempontjából, mint a fizetési módot.

[EPluribusUnum]

@bartanorbi , sok cég meg még ennyi adatot sem küldene be NAVnak, és erősen vitatható hogy minek kell most is néhány adatot kötelezően beküldeni. Ne kényszerítsd arra az országot hogy adatot szolgáltatsson NAV felé ami nem is tartozik rá!
Ha teljes automatizmusra vágysz, akkor direkt be kösd össze a számla kiállító szoftvert a számla befogadó befogadó szoftverrel, ne legye köztes szereplő is a folyamatban. A struktúra lehet a NAV-os xml, és talán a feladó oldal is szívesebben tölt ki extra adatokat, ha nem kell a NAVhoz beküldeni.

[bartanorbi]

@bartanorbi : milyen naplóba teszed még a NAVtól letöltött szállítói számlákat, ha nem a szállító naplóba?

A struktúra tartalmazza a határozott időszaki számlák esetén az időszak kezdete és vége dátumot. A számlán szerepel, mégis nagyon sok számlázó nem adja át az adatot, annak ellenére, hogy a számlán szerepel. Ezt írtam. Azok a mezők sem kötelezőek a struktúrában, és - szerintem - sajnos nincs kikényszerítve, hogy az időszak vége dátum megadása kötelező legyen, ha egyébként jelöli az adatátadó, hogy egy egy ilyen számla... Ezt én sokkal-de sokkal fájóbb pontnak látom könyvelés és ÁFA bevallás szempontjából, mint a fizetési módot.

Navtól letöltött szállítói számlákat, ha készpénzes, akkor a pénztár naplóba, ha nem, akkor a szállító naplóba.

[bartanorbi]

@bartanorbi , sok cég meg még ennyi adatot sem küldene be NAVnak, és erősen vitatható hogy minek kell most is néhány adatot kötelezően beküldeni. Ne kényszerítsd arra az országot hogy adatot szolgáltatsson NAV felé ami nem is tartozik rá!
Ha teljes automatizmusra vágysz, akkor direkt be kösd össze a számla kiállító szoftvert a számla befogadó befogadó szoftverrel, ne legye köztes szereplő is a folyamatban. A struktúra lehet a NAV-os xml, és talán a feladó oldal is szívesebben tölt ki extra adatokat, ha nem kell a NAVhoz beküldeni.

1. a kért adatokat pl. a számlázz.hu küldi...
2. a probléma a bejövő számlák esetén van, a kimenő számlák esetén már régóta a nav.xml-ből adjuk fel az adatokat...

[EnokhSys]

@bartanorbi Értem én a problémádat, hogy mit szeretnél. A nagykereskedők és áruházláncok világában létezik az EDI és ott eleve az EDIFACT szabvány alapján küldik a rendeléseket, számlákat. Ennél az a lényeg, hogy a küldő és fogadó szerződést kell kössön egymással és például kiköthetik, hogy a számlakibocsátó köteles szerepeltetni a fizetési módot, a rendelésszámot, a szállító kódját a vevő rendszeréből vagy a vevői cikkszámot stb.

Amióta a NAV OnLine Számlába bekerült az a lehetőség, hogy a beküldött adat lehet maga az elektronikus számla, lehetőség van arra, hogy a fentiekhez hasonló kitételeket rögzítsék a számlakibocsátó és számlabefogadó közötti megállapodásban. Ugyanis mindenképp szükség van megállapodásra elektronikus számlázás esetén.

Persze, ha az elektronikus számla nem maga a NAV adatszolgáltatás, hanem pl. PKI számla, akkor más a helyzet, de itt is van némi lehetőséged. Értem én, hogy azt szeretnéd, hogy törvényi kötelező erővel legyen ez szabályozva, de ez nem lehetséges. Azt viszont megteheted, hogy számlabefogadóként, kikötöd minden olyan számlakibocsátónak akivel kapcsolatban állsz, hogy csak akkor fogadsz be tőle elektronikus számlát, ha a NAV adatszolgáltatásban is szerepelteti a PKI számlán szereplő adatokat, és akár nevesítheted ezeket. Tehát mindkettőtöknek jogában áll a számla törvényben előírt kötelező adattartalmi elemein túlmenően további adatokat kötelezővé tenni, de csak akkor, ha ebben megállapodtok.