Fórumok
Sziasztok!
Használja még valaki az Sql-Ledger nevű számlázó progit manapság?
Azért kérdezem, mert nemrég kaptam a könyvelőmtől azt az infót, hogy jövőre csak olyan programot lehet számlázásra használni, amelyik rendelkezik „adóhatósági ellenőrzési adatszolgáltatás” elnevezésű funkcióval.
Egyelőre még nem néztem utána, hogy ez pontosan mit takar, de lassan neki kell állnom, viszont arra gondoltam, hogy hátha már más jobban utána nézett, és rendlkezik némi többlet információval, esetleg össze is tudnánk dolgozni.
Szóval ha tudtok erről bármi hasznosat, akkor ne tartsátok magatokban :)
Hozzászólások
Röviden: Minden számlázó programba, a program fejlesztőjének kötelező beépíteni (valamint az dokumentálni is) az általad is említett "adóhatósági ellenőrzési adatszolgáltatást”, elvileg akkor is, ha csak saját fejlesztésű számlázó és csak cégen belül használják. A 23/2014. (VI.30.) NGM rendelet alapján, annak mellékletében megadott formátum szerint, számlaszám, vagy időintervallum alapján egy XML fájlt kell generálni ellenőrzéskor, és minden olyan adatnak benne kell lennie az XML-ben, ami a számlán is fel van tüntetve és úgy ahogy a számlán is megjelenik.
2016.01.01-én lép életbe, úgyhogy szerintem minél hamarabb állj neki.
Hirtelen ennyi jut eszembe, a többi a munkahelyi gépen van elmentve.
Egyet pontositanek: jan1 utantol a jan1 utan kiallitott szamlakat kerhetik xmlbe.
--------------------------------
www.symbolcloud.hu
Én már végigszoptam egyszer itt vannak a releváns linkek:
http://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A1400023.NGM
http://nav.gov.hu/nav/ado/afa080101_hatalyos/A_szamlazo_programok_20151…
XSD forrása (legtöbb helyen képként van!):
http://nav.gov.hu/nav/ado/afa080101_hatalyos/23_2014___VI__30___NG20150…
Extra magyarázat a NAV-tól:
http://nav.gov.hu/data/cms382357/GYIK_szamlazo_program.pdf
Célszerű XSD-ből valami parserrel kódot generáltatni, mert rengeteg adattag van, kézzel generátort írni szerintem vérszopás.
Nem tudom a címeket milyen formátumban tároljátok, de a NAV irányítószám-utca-közterület_típusa-házszám szinten megbontva kéri be, ez tud meglepetéseket okozni.
http://hup.hu/node/143783
--
Access denied. :(
Ja, hogy ez a HVK-ban van. Csatlakozz :). Túl sok infó amúgy ott sem hangzott el, de ugyanez a téma. Az eredeti kérdezőn meg úgyse segít, ha a programja nem támogatja.
--
^ és ezért hülyeség a hvk
+1
+1
+1
nem hülyeség, csak hülyén van használva.
--
blogom
+1
a legutóbb kiadott GYIK-ben elvileg azt írták, hogy a teljes címet lehet egy node-ba írni
Erre esetleg tudnál konkrét forrást linkelni? :)
--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
bocs, butaságot írtam, GYIK-ben is egyértelműen említik, hogy nem lehet eltérni a megadott formátumtól.
Köszi az infókat, el is kezdtem utána nézni a dolgoknak.
Sajnos az XML-t és a Perl-t is csak úgy hallomásból ismerem, komolyabban még nem foglalkoztam vele.
Viszont találtam egy XML::Compile::Schema perl modult ami úgy tűnik jó lehet erre a feladatra.
Amúgy az utca-közterület_tipus-házszám egy mezőben van eltárolva, úgyhogy ezt valahogy szét kell majd szedni.
"az utca-közterület_tipus-házszám egy mezőben van eltárolva" - ez simán megérdemli a Péklapát-díj arany fokozatát. Ilyen az, amikor nincs kettő/három lépéssel előre átgondolva valami...
De legalább a fejlesztőnek is kell vele copni, nem csak a felhasználóknak, akiknek már csillióegy cím van így rögzítve, és illendően azt is _helyesen_ fel kell szabdalni három részre. Normális esetben egyik mező sem lehet null, azt meg illik DB szinten is megfogni, sőt, ha igazán szépet akar valaki, akkor a közterület típust szótározza (felületen választólista?)...
Nem igazán. A partner táblában minden mező külön van, de a számla fejlécében már nem, mivel ott már nem fog semmi sem változni. Ugyanis a partner adatai az idővel változhatnak, de a számla az nem.
Ilyen alapon lehetne egy "számla" mező, ami a számla teljes tartalmát egyben tartalmazza, mondván, hogy ott semmi sem fog változni :-P
Tévedsz. Ez egy olyan mező amit már csak kizárólag számlaképhez használ az ember, de semmi olyan adat nem kell belőle, amit a rendszer többi része használ vagy érint.
Persze meg lehetne úgyis csinálni a rendszert, hogy minden címváltozás eltárolva annak ID-jére hivatkozva képezzük a számla fejlécét, de ezt velem együtt legtöbben lustaságból nem teszik meg.
Most meg kiderül, hogy mégis szét kell szedni, ahogy eredetileg is volt :-P Nem azt mondtam, hogy a számlaképnél egy hivatkozás legyen az üf. adott időpontban érvényes címére (bár ez sem lehetetlen küldetés), hanem azt, hogy a számlára kerülő címet is címként (ország, település, irányítószám, közterület neve, közterület típusa, házszám), nem pedig n darab szövegsorként kezelve ez a probléma fel sem merülne. Papíron tényleg egy sor, logikailag meg legalább három adat...
Én első körben magát a számlázó részt/modult módosítom. Nincs ezzel baj, nem kell az exportnak visszafelé működnie. Persze a visszamenőlegesség is megoldható lenne, csak sok költséggel.
Most nézem, vazze. Ezek komolyan találtak egy olyan ábrázolási módot, ami gyakorlatilag az ÁNYK kivételével sehol nincs megvalósítva, mert nincs értelme?
"kézzel generátort írni szerintem vérszopás"
Miért? (Nekem pedig ezt hozza a Jézuska.)
Erre vannak az XSD to kód generátorok. Megmutatod neki az XSD-t majd lesz n darab classod a megfelelő hierarchiában.
Köszi. Azt hittem a felületes ismereteim elegek, de már látom, hogy nem.
Meg lehet írni kézzel is, csak szívás debugolni, meg reszelgetni.
Milyen nyelvhez kellene?
Ha Qt, C++ akkor én a KODE-t reszeltem szét, hogy megegye a NAV-os XSD-t:
https://github.com/martonmiklos/kode
php, de nem muszáj ebben megírnom.
http://www.ledger.hu/download/ledger20151130uj.pdf
Ott van a pdf-ben. Semmi közöm hozzájuk, de szerintem korrekt az ajánlat.
Jol ertelmezem a GPL licenszet abbol a szempontbol, hogy ha valaki modosit egy GPL-es programot es kiadja a publicnak, akkor a forrasat is ki kell adnia? Ergo a ledger.hu-s sracoktol elkerhetem a ledger20151130-at dijmentesen?