Sql-Ledger vs. 2016

Ledger szabad ügyviteli szoftver

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 :)

  • 2487 megtekintés

( nydn | 2015. 12. 01., k – 20:36 )

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.

( martonmiklos v | 2015. 12. 01., k – 23:12 )

É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.

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?)...

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...