online számlázás
Sziasztok!
Egy internetes oktatási honlapot fejlesztek, amit előfizetési díj ellenében lehet majd látogatni. A számlázási rendszer kialakítása során merültek fel az alábbi problémák:
1. Számlák nyomtatása böngészőből
Ilyen ugyebár nem lehetséges. A vonatkozó PM rendelet szerint a számlákkal nem csak sorszám, de példányszám szerint is el kell számolni, márpedig azt nem lehet ellenőrizni, hogy az ügyfél hányszor kattint a böngészőben/pdf-olvasóban a „Nyomtatás” gombra. Tehát a számlát a honlapot üzemeltető cég irodájában ki kell nyomtatni, majd elpostázni Lajosmizsére, Bolíviába, a Marshall-szigetekre… Természetesen a postán érkező számláról az ügyfél annyi fénymásolatot készít, ahányat akar, és annyit tesz be a könyvelésébe, ahányat mer. Az egésznek nincs hatása az adózási fegyelemre, csupán arra jó, hogy ne lehessen az adminisztrációt automatizálni.
2. Elektronikus hitelesítés
Elképzelhető, hogy bennem van a hiba, de nem értem. Tételezzük fel, hogy kiállítok egy digitális hitelesítéssel ellátott számlát Gipsz Jakab részére. És ő mit kezd vele? Ki nem nyomtathatja, CD-re ki nem írhatja, mert az már nem eredeti, hanem másolat. Hogyan fog ez a hitelesített számla eljutni Gipsz könyvelőjéhez? Hogyan fogja bevinni az APEH-hez, ha adóellenőrzés van a cégénél? Mi történik, ha e-mailben küldöm el neki a számlát, és ő történetesen nem a saját irodai gépére tölti le, hanem a sógoráéra? Oké, továbbküldi az irodai gépre – de akkor most melyik az eredeti példány, a sógor gépén lévő, vagy az, ami végül megérkezett hozzá? Ugyanott vagyunk, ahonnan elindultunk. By the way, ha számlázásra nem jó a digitális hitelesítés, akkor mire való?
3. Ügyfél kötelező azonosítása
Ha jól olvasom a rendeletet, akkor ma Magyarországon anonim módon csak készpénzzel, üzletben lehet vásárolni, ahol van pénztárgép. Egyéb esetben számlát kell kiállítani, aminek kötelező tartozéka a vevő/ügyfél neve és címe – akkor is, ha ő nem kéri az áfás számlát. Ez e-kereskedelmi rendszereknél általában nem probléma, hiszen a megvásárolt terméket úgyis ki kell valamilyen címre szállítani, de online szolgáltatás esetén teljesen felesleges zaklatás. Jelenleg nem lehet olyan rendszert kialakítani, ahol meghagyjuk a vevőnek a jogot, hogy ne azonosítsa magát. Szerintem teljesen elégséges lenne a számlán feltüntethetni a felhasználó-azonosítót, és kiikszelni a vevő neve és címe mezőket.
4. Szemetes adatbázis
Bár nálunk általában az a jellemző, hogy mindenki mindenről áfás számlát kér, azért nem lehet kizárni, hogy akad olyan felhasználó, aki nem kéri a számlát és zokon veszi, hogy az adatait kérjük. Ilyenkor tág tere nyílik a kreativitásnak, például „Az Ön neve: Miközöd Hozzá” (és ez még egy szolidabb példa). Az ilyen jellegű szabotázst semmiféle validálással nem lehet kiszűrni. A jogszabály gyakorlatilag rákényszerít bennünket egy szemetes adatbázis fenntartására.
Csak érdekességképpen egy jogelméleti kérdés:
Ha az ügyfél nem akarja megadni az adatait, megtehetjük, hogy nem szolgáljuk ki. De mi van akkor, ha hamis adatokat ad meg (lásd fent)? A jogszabály szerint a számla adatainak valódiságáért a kiállító felel. Kinek a felelőssége, ha a vevő neve és címe nyilvánvalóan valótlan?
5. Bankkártyás fizetés
Épeszű ember ugye ilyet nem csinál a saját honlapján, hanem erre szakosodott külső céget vesz igénybe (WorldPay, Moneybookers). Ez a gyakorlatban azt jelenti, hogy adott napon kiszámlázunk mondjuk 10 db előfizetést egyenként 5000 Ft-ért – de nem 10 db jóváírás érkezik a számlánkra, hanem csak egy, és csak a lebonyolító honlapján lévő számlatörténet alapján tudjuk beazonosítani, hogy mely felhasználóktól jött a pénz. Mit szól ehhez az APEH? Ráadásul nem 50000 Ft jön be a számlára, hanem csak 48000, a többi a lebonyolító cég jutaléka, amiről jellemzően nem állít ki számlát, tehát nem tudjuk költségként leírni.
6. ÁFA kiszámlázása
Ez termék-értékesítés esetén is komplikált, szolgáltatás esetén meg teljesen áttekinthetetlen. Ha jól értem, akkor a „teljesítés helye” a mérvadó – egyes esetekben ki kell számlázni, más esetekben nem. De hogyan állapítjuk meg a teljesítés helyét? A honlapot üzemeltető cég székhelye? A felhasználó tartózkodási helye? A szerver földrajzi elhelyezkedése? Mi van akkor, ha a szerver Amerikában van (mondjuk, mert olcsóbb, vagy mert közelebb van a célpiachoz)? Mi van akkor, ha szerte a világon több szerverünk is van?
Általánosítva a fentieket: az a véleményem, hogy a jogszabályi környezet kialakítása még sehol nem tart. Ez nyilván nem is fog magától megtörténni, és mindaddig nem fog semmi változni, amíg egy jól szerevezett lobbi el nem kezdi követelni. Kíváncsi lennék, hogy milyen tapasztalataitok vannak e-szolgáltatás témában, és láttok-e lehetőséget valamilyen együttes nyomásgyakorlásra…
Edit
■ Egy internetes oktatási honlapot fejlesztek, amit előfizetési díj ellenében lehet majd látogatni. A számlázási rendszer kialakítása során merültek fel az alábbi problémák:
1. Számlák nyomtatása böngészőből
Ilyen ugyebár nem lehetséges. A vonatkozó PM rendelet szerint a számlákkal nem csak sorszám, de példányszám szerint is el kell számolni, márpedig azt nem lehet ellenőrizni, hogy az ügyfél hányszor kattint a böngészőben/pdf-olvasóban a „Nyomtatás” gombra. Tehát a számlát a honlapot üzemeltető cég irodájában ki kell nyomtatni, majd elpostázni Lajosmizsére, Bolíviába, a Marshall-szigetekre… Természetesen a postán érkező számláról az ügyfél annyi fénymásolatot készít, ahányat akar, és annyit tesz be a könyvelésébe, ahányat mer. Az egésznek nincs hatása az adózási fegyelemre, csupán arra jó, hogy ne lehessen az adminisztrációt automatizálni.
2. Elektronikus hitelesítés
Elképzelhető, hogy bennem van a hiba, de nem értem. Tételezzük fel, hogy kiállítok egy digitális hitelesítéssel ellátott számlát Gipsz Jakab részére. És ő mit kezd vele? Ki nem nyomtathatja, CD-re ki nem írhatja, mert az már nem eredeti, hanem másolat. Hogyan fog ez a hitelesített számla eljutni Gipsz könyvelőjéhez? Hogyan fogja bevinni az APEH-hez, ha adóellenőrzés van a cégénél? Mi történik, ha e-mailben küldöm el neki a számlát, és ő történetesen nem a saját irodai gépére tölti le, hanem a sógoráéra? Oké, továbbküldi az irodai gépre – de akkor most melyik az eredeti példány, a sógor gépén lévő, vagy az, ami végül megérkezett hozzá? Ugyanott vagyunk, ahonnan elindultunk. By the way, ha számlázásra nem jó a digitális hitelesítés, akkor mire való?
3. Ügyfél kötelező azonosítása
Ha jól olvasom a rendeletet, akkor ma Magyarországon anonim módon csak készpénzzel, üzletben lehet vásárolni, ahol van pénztárgép. Egyéb esetben számlát kell kiállítani, aminek kötelező tartozéka a vevő/ügyfél neve és címe – akkor is, ha ő nem kéri az áfás számlát. Ez e-kereskedelmi rendszereknél általában nem probléma, hiszen a megvásárolt terméket úgyis ki kell valamilyen címre szállítani, de online szolgáltatás esetén teljesen felesleges zaklatás. Jelenleg nem lehet olyan rendszert kialakítani, ahol meghagyjuk a vevőnek a jogot, hogy ne azonosítsa magát. Szerintem teljesen elégséges lenne a számlán feltüntethetni a felhasználó-azonosítót, és kiikszelni a vevő neve és címe mezőket.
4. Szemetes adatbázis
Bár nálunk általában az a jellemző, hogy mindenki mindenről áfás számlát kér, azért nem lehet kizárni, hogy akad olyan felhasználó, aki nem kéri a számlát és zokon veszi, hogy az adatait kérjük. Ilyenkor tág tere nyílik a kreativitásnak, például „Az Ön neve: Miközöd Hozzá” (és ez még egy szolidabb példa). Az ilyen jellegű szabotázst semmiféle validálással nem lehet kiszűrni. A jogszabály gyakorlatilag rákényszerít bennünket egy szemetes adatbázis fenntartására.
Csak érdekességképpen egy jogelméleti kérdés:
Ha az ügyfél nem akarja megadni az adatait, megtehetjük, hogy nem szolgáljuk ki. De mi van akkor, ha hamis adatokat ad meg (lásd fent)? A jogszabály szerint a számla adatainak valódiságáért a kiállító felel. Kinek a felelőssége, ha a vevő neve és címe nyilvánvalóan valótlan?
5. Bankkártyás fizetés
Épeszű ember ugye ilyet nem csinál a saját honlapján, hanem erre szakosodott külső céget vesz igénybe (WorldPay, Moneybookers). Ez a gyakorlatban azt jelenti, hogy adott napon kiszámlázunk mondjuk 10 db előfizetést egyenként 5000 Ft-ért – de nem 10 db jóváírás érkezik a számlánkra, hanem csak egy, és csak a lebonyolító honlapján lévő számlatörténet alapján tudjuk beazonosítani, hogy mely felhasználóktól jött a pénz. Mit szól ehhez az APEH? Ráadásul nem 50000 Ft jön be a számlára, hanem csak 48000, a többi a lebonyolító cég jutaléka, amiről jellemzően nem állít ki számlát, tehát nem tudjuk költségként leírni.
6. ÁFA kiszámlázása
Ez termék-értékesítés esetén is komplikált, szolgáltatás esetén meg teljesen áttekinthetetlen. Ha jól értem, akkor a „teljesítés helye” a mérvadó – egyes esetekben ki kell számlázni, más esetekben nem. De hogyan állapítjuk meg a teljesítés helyét? A honlapot üzemeltető cég székhelye? A felhasználó tartózkodási helye? A szerver földrajzi elhelyezkedése? Mi van akkor, ha a szerver Amerikában van (mondjuk, mert olcsóbb, vagy mert közelebb van a célpiachoz)? Mi van akkor, ha szerte a világon több szerverünk is van?
Általánosítva a fentieket: az a véleményem, hogy a jogszabályi környezet kialakítása még sehol nem tart. Ez nyilván nem is fog magától megtörténni, és mindaddig nem fog semmi változni, amíg egy jól szerevezett lobbi el nem kezdi követelni. Kíváncsi lennék, hogy milyen tapasztalataitok vannak e-szolgáltatás témában, és láttok-e lehetőséget valamilyen együttes nyomásgyakorlásra…
Edit
pontasan milyen rendeletekről/törvényekről van szó?
1. Nem hinném, hogy valaki több számlát tesz be mint amennyit én küldök. (persze lehet, hogy naiv vagyok) ugyanis a számlát a kiállító és a számlaszám egyértelműen azonosítja, így elvileg többször nem tudja betenni a könyvelésébe senki.
2. A digitális aláírás arra jó, hogy azonosítja a számla kiállítóját.
Egy elektrónikus adathalmazt bárki előállíthat és azt ír bele amit akar. Amennyiben ez az adathalmaz digitálisan alá van írva akkor azt "biztosan" a számla kiállítója készítette. A "biztosan" a kérdés itt. Egy digitális aláírás attól hiteles, hogy egy hitelesítő intézmény hitelesíti azt. Vagyis a nyilvános kulcsot (amivel ellenőrizni lehet, hogy hiteles-e az eláírás) a kulcs birtokosához rendeli. Egy hitelesítő intézmény attól hiteles, hogy sokan hisznek benne. ;) Amennyiben lesz államilag elfogadott hitelesítő intézmény (van már?) és fel lesz rá készítve az intézmény, akkor az Apeh által elfogadott lesz a digitálisan kiállított számla bármilyen adathordozón juttatják el hozzá(e-mail, cd, stb)
3. De lehetséges szolgáltatás közvetítő cégeken keresztül. Lásd mobilos fizetés, ami a neten fellelhető adatok alapján kicsit borsosnak tűnik nekem(60% sáp). Az ügyfél a mobil szolgáltatóval áll kapcsolatban és Te is.
4. Semmi. Apeh szempontjából van neked egy bevételes számlád(tehát amin elismersz egy bevételt, amivel növeled az adóalapodat) aztán ez a számla nem jeleneik meg senkinél mint kiadásos számla(tehát amivel adóalapot lehet csökkenteni). Apeh szempontjából az a gáz, hogy ha csak kiadásos számla jelenik meg a rendszerében, hisz ilyenkor valahol csökken az adóalap, ami sehol nem nő -> államnak ekkor vesztesége van. (na de ezt majd most jól megkérdezem a könyvelőmtöl is)
5. Szerintem egy magyar bankkal kötött szerződés esetén a számlatörténet alapján elég jól nyomonkövethető az egész.(a számlakivonatodon ott lesz a vevő/átutaló neve.) Külföldi bank esetén is követhetőnek kéne lennie...ergó ne használd ezen cégek szolgáltatásait, ha nem tudják neked biztosítani ezeket a bizonylatokat.
6. erre valószínűleg meg fog jelenni nemsokára egy rendelet. (pl. a cég helye)
Szeretném felajánlani az NJSZT WFSZ ( http://wfsz.njszt.hu ) segítségét egy ilyen "lobbi" létrehozására, ha még nem létezik ilyen.
pp
<Nincs cím>
1. Természetesen én nem amiatt aggódom, hogy valaki az én fénymásolt számláimmal tömi ki a könyvelését. Csak próbálom megkeresni a logikát a rendeletben, és szerintem erre gondolhatott a jogszabály alkotója. Elvileg meg lehet csinálni, hogy ha van havonta 500 bejövő számlád, akkor nem tűnik fel az APEH-nek, hogy egy-két kisebb összeget többször is lekönyvelsz a másolatok segítségével. De aki ilyen módon akarja manipulálni a könyvelését, annak ott a fénymásoló. A rendelet nem akadályozza meg az ilyen kisstílű csalást, viszont lehetetlenné teszi, hogy interneten keresztül küldjük az ügyfélnek a számlát, pl. emailhez csatolt pdf mellékletként, vagy mondjuk úgy, hogy feljön a honlapra, és ott megtekintheti, kinyomtathatja a számára addig kiállított számlákat.
2. Az világos, hogy a digitális aláírás mit csinál - a probléma az, hogy a kötelező példánysorszámozás miatt ez számlázáshoz praktice nem használható. A kinyomtatott, adathordozóra kiírt, stb. példány már nem eredeti, hanem másolat. Hiába igazolja a hitelesítés, hogy én állítottam ki, a lényeg a példányszám. Csak 1 db eredeti példányt lehet kibocsátani - minden további csak másolat, amit az ügyfél nem használhat fel pl. ÁFA visszaigénylésre.
3. Nem tudom, hogy működik ez a mobil fizetés. Tud valaki erre vonatkozó jogszabályról? Mert amit én olvastam (24/1995, 34/1999) az egyértelműen előírja, hogy a számlának kötelezően tartalmaznia kell a vevő nevét és címét. Lásd pl. http://www.apeh.hu/megyek/heves/allasfogl.htm - decemberi állásfoglalás valahol a lap közepén.
4. A Paypal-szerű külső fizetés-lebonyolítókkal az a gond, hogy csak internetes felületen keresztül érintkeznek az ügyféllel. Tehát nincs tételes papír alapú bankszámlakivonat, ami mutatná, hogy melyik ügyféltől jött a pénz. Ez talán még nem probléma, bár az APEH biztos rácsodálkozik majd, amikor először lát ilyet, és hát tudjuk, hogy az ilyen rácsodálkozás elég kellemetlen tud lenni, még ha a végén el
is fogadják a dolgot. Nagyobb probléma ennél, hogy a Paypal-jellegű költséget nem fogjuk tudni leírni.
5. Van olyan magyar bank, amelyik bankkártyás fizetések lebonyolítását vállalja? Én nem tudok ilyenről, de lehet, hogy le vagyok maradva. Szerintem egyelőre csak külföldiek vannak (és azok közül is néhány - pl. a Paypal - nem szerződik magyar cégekkel).
6. És mi van, ha én nem "nemsokára" akarok internetes bizniszt indítani, hanem holnap reggel?....:-)
NJSZT - pontosan erre gondoltam. Szerintem a lobbizást úgy lehetne elindítani, hogy valami jól csengő nevű szervezet (NJSZT) ír egy hivatalos levelet a pénzügyminiszternek, hogy ilyen és ilyen problémák akadályozzák az internetes üzleti tevékenységet, stb. Aztán ha nincs válasz, akkor ki lehet adni egy sajtóközleményt, médiában megjelenni, stb. Szerintem egyébként a T-Online és a többi nagy szolgáltató is utálja, hogy havonta egymillió számlát kell kipostáznia, mikor minden ügyfele interneten elérhető, és lehetne pl. email mellékletként küldeni a számlákat.
E.
<Nincs cím>
Van egy pár WEB-Bolt ahol úgy fizetsz hogy átirányítanak az OTP oldalára, ott adod meg a kártya adatait, és ha rendben van a fizetés visszadob arra az oldalra ahonnan jöttél.
Amúgy pedig van egy ilyen oldal hogy : www.tavszamla.hu
Itt a T-com csoport számláit lehet Online megkapni. (nem kapsz papír számlát)
Tehát ők is megoldották ezt úgy hogy a jogszabályoknak megfeleljen.
elektronikus számla
Mi is elektronikus számlázást probálunk megvalositani Interneten keresztül ráadásul bankkártyás fizetéshez kapcsolódóan. User kiválasztja a terméket, fizet kártyával és azonnal látja a számlát a böngészőjében és letöltheti az elektronikus számlát is azonnal.
Amit hozzáfüznék a csevegéshez: Nemigen értem miért fontos a számlamásolás tiltása. Ugyanis számlasorszám csak egyetlen lehetséges, igy nem értem hogyan lehet visszaélni az eredeti számla másolásával - akár a könyvelő, akár ÁFA visszaigénylés szempontjábol.
Más: Bankkártyás Internetes elfogadóhely létezik. Cégem is csinál ilyet hazai bankkal együttmüködve - egyáltalán nem ujdonság.
Mobil fizetéssel is foglalkozunk, tudunk egyet-smást rola.
Amugy komoly értelme lenne eSzamlaval kapcsolatos ötleteket, tapasztalatokat közvetlenül is kicserélni.
DA
Én se...
Gondolom itt nem egyszerű PDF-ről beszélsz, hanem fokozott biztonságú elektronikus aláírással és időbélyegzővel ellátott dokumentumról.
Hát ezzel nem vagy egyedül, vagyunk még vagy 10 millióan...:)
Természetesen létezik. Kérdés, hogy az ügyfeleid hajlandók-e megadni a kártyaszámukat egy magyar banknak. Sokan nem adják meg - ebből élnek a fizetés-lebonyolító cégek (PayPal).
Igen, jó lenne tudni, hogy valaki beleszaladt-e már ebbe a problémába az APEH-nél. Azt hiszem, egy "normál" cégnél, csomagküldőnél rá se kérdeznek, hiszen ott feltételezhető, hogy a számla papíron jut el a vevőhöz. De ahol nincs árumozgás, ott esetleg elkezdhetik firtatni. Tény, hogy a böngészőn keresztül küldött számla nem felel meg a szigorú számadás követelményeinek, és ezért formailag nem helyes. A PM-nek írt levelemre eddig nem kaptam választ.
Lehet a kapcsolatküldő lapon keresztül email-t küldeni.
Edit
eredeti nyomtatása kliens oldalon
Kis probléma, hogy instabil az egész, néha nem nyom semmit, csak egy vb hibaüzenet jön fel, továbbá csak az alapértelemezett nyomtatóra megy.
és az IE-n kívüli világ?
nem gond
A belső használatú rendszereknél pedig megengedett policy az, hogy meghatározzák a használatos böngészőt.
Gyulus
<Nincs cím>
E.
Számlázás
Szerintem nem a programnak kell megoldania, hogy technikailag ne lehessen semmiképp se több példányt előállítani, hanem a felhasználó lesz lecsukva, ha többet fog csinálni, és lebukik.
-boogie-
A program nem állíthat elő több példányt
Az áfa tv. 13. § (1) bek. 16. pontja szerint a számla olyan adóigazgatási azonosításra alkalmas bármely bizonylat lehet, mely legalább a következő adatokat tartalmazza:
Plusz:
24/1995. (XI.22.) PM rendelet 1 par. 6. bekezdés, valamint a 34/1999. (XII.26.) PM rendelet 1. par. alapján megfogalmazott előírások:
Kérdezném, hogy ezekben a törvényekben hol van benne az, hogy mit kell megakadályoznia a programnak? Hol van benne az, hogy a programnak kell ellenőriznie, hogy egy számlából csak egy példány készül? Ésatöbbi.
-boogie-
Kiegészítés
24/1995. (XI. 22.) PM rendelet a számla, egyszerűsített számla és nyugta adóigazgatási azonosításáról, valamint a nyugta adását biztosító pénztárgép és taxaméter alkalmazásáról
Az adózás rendjéről szóló 1990. évi XCI. törvény (a továbbiakban: Art.) 96. §-ának (3) bekezdésében, valamint az általános forgalmi adóról szóló 1992. évi LXXIV. törvény (a továbbiakban: Áfa-tv.) 71. §-ának (3) bekezdésében kapott felhatalmazás alapján a következőket rendelem el:
Adóigazgatási azonosításra alkalmas bizonylatok
1. § (1) Az Áfa-tv. 13. § (1) bekezdésének 16-17. és 20. pontjaiban megjelölt bizonylatok [számla, egyszerűsített számla (a továbbiakban: számla), nyugta] akkor minősülnek adóigazgatási azonosításra alkalmasnak, ha azok beszerzéséről a kibocsátó a (2) bekezdés szerinti részletességű számlával rendelkezik, és a bizonylatot kibocsátó az (5) bekezdés szerinti szigorú számadású nyomtatványként kezeli. Adóigazgatási azonosításra - a (6) bekezdés szerinti bizonylatok kivételével - csak a nyomtatott, folyamatos sorszámozással ellátott bizonylatok alkalmasak.
(2) A nyomtatványt értékesítő forgalmazó az értékesítésről kiállított számlán köteles feltüntetni
a) az értékesített nyomtatványok (számlatömbök, nyugtatömbök) megnevezését,
b) a nyomtatvány sorszámát (tól-ig),
c) a vevő nevét és címét (székhelyét, telephelyét),
d) a vevő adóazonosító számát.
(3) Amennyiben a vevő a (2) bekezdés c) és d) pontjaiban előírt adatokat hitelt érdemlően (pl. személyi igazolvány, meghatalmazás, bélyegző, aláírási címpéldány, cégbírósági végzés stb.) nem tudja igazolni, részére nyomtatványt a forgalmazó nem értékesíthet.
(4) A nyomtatványt forgalmazó köteles e tevékenységét az adóhatóságnak bejelenteni, az általa értékesített nyomtatványt a kibocsátott számla tőpéldánya alapján sorszám szerint nyilvántartani.
(5) A bizonylatot kibocsátónak az (1) bekezdésben meghatározott nyomtatványokat szigorú számadás alá kell vonnia. A szigorú számadás alá tartozó nyomtatványokról a kibocsátónak nyilvántartást kell vezetni, amelynek fajtánként külön-külön tartalmaznia kell az alábbi adatokat:
a) a nyomtatvány jele és számjele,
b) a beszerzést igazoló számla száma és a számlán feltüntetett teljesítés kelte,
c) a tömbök sorszáma (tól-ig),
d) a használatbavétel kelte,
e) a kiselejtezés kelte.
(6) Az (1) bekezdésben megjelölt bizonylatokon kívül más módon előállított bizonylatok a következők lehetnek:
a) nyomdai úton előállított számla, nyugta (jegy, blokk stb.), amennyiben a kibocsátó gondoskodik a kibocsátás és elszámolás során a (5) bekezdésben foglaltak szerint a szigorú számadásról és - a készpénzzel azonos elszámolás alá tartozó, meghatározott értékű bizonylatok kivételével - a másolattal vagy tőpéldánnyal történő hiánytalan elszámolásról;
b) számítógéppel előállított számla, amelynek szigorú számadás alá vonása az (5) bekezdés szerint megvalósul oly módon, hogy a program - beleértve az alaki hibás, vagy tartalmilag rontott, illetve megsemmisült vagy elveszett számla esetét is - kihagyás és ismétlés nélkül biztosítja a sorszámozást, és a másolatok alapján a hiánytalan elszámolás biztosított. Ez utóbbi feltétel teljesüléséhez a számla összes példányának egymás utáni nyomtatással történő előállítása esetében a gépi programnak biztosítania kell a példányok sorszámozását, több példányos összeszerelt, előnyomás nélküli számla esetén pedig fel kell tüntetnie azt, hogy a számla hány példányban készült;
c) a pénztárgép, taxaméter által kibocsátott nyugta, számla a 2. §-ban foglalt követelmények teljesülése esetén.
(7) Gépi számlázás esetén a számla kibocsátójának rendelkeznie kell a számlázási programra vonatkozó olyan dokumentációval, amely biztosítja a program működésének ellenőrizhetőségét. A dokumentációnak tartalmaznia kell részletes leírást a program működésére, felhasználására vonatkozóan, valamint a készítő nyilatkozatát a használó részére, mely szerint a program megfelel az adójogszabályokban előírt kötelezettségeknek.
-boogie-
<Nincs cím>
"a számítógéppel előállított számla összes példányait sorszámozni kell az egymás után történő nyomtatás esetén, illetve fel kell tüntetni azt, hogy a számla hány példányban készült"
Hogyan tünteted fel azt, hogy a számla hány példányban készült, ha a felhasználó nyomtat, akárhány példányban. Lásd pl. az alábbi APEH iránymutatást:
1999/151. APEH iránymutatás
a számítógéppel előállított bizonylatok adattartalma
[Áfa-törvény 13. § (1) bekezdés 16. pont]
A számlák kötelező adattartalmát az Áfa-törvény 13. § (1) bekezdés 16. pontja, valamint a pénzügyminiszter 24/1995. (XI. 22.) PM rendelete határozza meg. Ez utóbbi rendelkezés 1. § (5) bekezdés b) pontja szerint a számítógéppel előállított bizonylat abban az esetben alkalmas adóigazgatási azonosításra, ha a gépi program kihagyás vagy ismétlés nélkül biztosítja a sorszámozást és a másolatok alapján a hiánytalan elszámolást. Ebből következően a másolatok alapján történő hiánytalan elszámolás feltétele, hogy a bizonylat példánysorszámát a számítógépes bizonylatokon - hasonlóan a számlasorszámhoz - gépi program biztosítsa. Amennyiben a számítógépes számla nem tartalmazza a példány sorszáma nem tekinthető adóigazgatási azonosításra alkalmasnak.
(APEH Adónemek főosztálya 1222496420/1999.; AEÉ 1999/12.)
Magyar fordítás: ha nem tudsz a kinyomtatott példányokkal (eredeti + másolatok) elszámolni, akkor a rendszered nem felel meg az előírásoknak. Bírság a fejlesztőnek, plusz az ügyfelek nem tudják a számlán szereplő összeget elszámolni költségként ill. visszaigényelni az ÁFÁ-t.
Közben találtam még egy jogszabályt, e szerint a számla CSAK ALÁÍRÁSSAL EGYÜTT érvényes:
2001. január 1-jétől hatályos 2000. évi C. törvény (a továbbiakban: számviteli törvény) 167. §-ának (3) bekezdése új előírásként megköveteli a számla, az egyszerűsített számla, a számlát helyettesítő okmány alaki és tartalmi hitelességének, megbízhatóságának biztosítására a gazdálkodó képviseletére jogosult személy vagy az általa a bizonylat aláírására feljogosított személy (ideértve a Ptk. szerint vélelmezett képviseletet is) aláírását.
Ez alól csak a zárt rendszerben, emberi beavatkozás nélkül, nagy tömegben előállított számlák jelentenek kivételt - jellemzően bankok, szolgáltatók. A "nagy tömeg" kritériumnak egy kezdő vállalkozás semmiképpen nem tud megfelelni.
E.
Én másként olvasom
Van az, hogy a számla hány példányban készült, és az, hogy hány példányban lett kinyomtatva. Ha PDF-et készítesz, akkor 1 eredeti, és pár másolt példányban fogod elkészíteni. Ezután ha a felhasználó több példányban nyomtatja ki, akkor az az ő baja, mert okirathamisítást végez. Ha a program dokumentációjában leírod, hogy hogyan kell használni a programot, és hogy mikor mire kell kattintani, s a törvény csak egy példány nyomtatását engedélyezi, akkor ez szerintem pipa.
Magyar fordítás: a program biztosítja, a program használata viszont a felhasználón múlik. Nem neked, hanem a felhasználónak kell elszámolni a számlákkal, ahogyan ez amúgyis így van a "normál" számlák esetén.
Ami az aláírással együtt érvényes számlát illeti, a jogszabály azóta megváltozott, és már Aláírás nélkül is érvényes a számla.
-boogie-
<Nincs cím>
A rendszernek alapesetben úgy kell működnie, hogy a számlák kibocsátójának el kell számolnia a példányokkal. Természetesen mindent meg lehet babrálni - ez nem a fejlesztő felelőssége - de ha alapkialakításban lyukas a rendszer, azt szerintem nem lehet elintézni egy felhasználónak küldött figyelmeztetéssel, hogy "csak egy példányban nyomtass, különben okirathamisítást követsz el". Egyébként én is szeretném, ha ez ilyen egyszerű lenne...:-)
Az legalább jó hír, hogy nem kell az aláírás. Úgy látszik, kifogtam valami lejárt szavatosságú honlapot.
Jövő héten megkérdezek egy könyvvizsgálót, és bejelentkezem ide a szakvéleménnyel.
E.
Hasznos
-boogie-
amit én tudok a témáról.
A dolog lényege, hogy az apehnek vannak formai követelményei, ha azokat betartod, akkor semmi gond. Ne lehessen ugyanolyan sorszámú számlát nyomtatni és kész. Kell egy eredeti számla és utánna, hogy mennyi másolat van, senkit nem érdekel, mert azon ott van, hogy 1. másolta, 2, másolat stb.
Apeh igazolás sem kell, hogy a szoftver megfelel a követelményeknek, csak a program készítőjének kell vállalnia a felelőséget, mert ha szar a progi akkor az ő hátán verik el a port.
A számla elektronikus uton való eljutatása az ügyfélhez már macerásabb dolog. Igaz, kicsit túlbonyolítjátok a kérdést, mert téges számla kibocsátót csak az érint, hogy a számla ellenértéke beérkezzen a számládra, mert ha nem jön meg, akkor 2 dolgot tehetsz. Sztornó vagy befizeted utána az adót. Ha sztornó akkor a veszély ott van, ha egyszer befizetik a számládat, mert az adó csalás. Hogy az emberünk hány másolatot készít a számláról, már senkit nem érdekel.
Sokkal nagyobb probléma a céges pecsét és az aláírás ami nélkül nem érvényes a számla. És ez egyenlőre megoldhatatlan probléma.
Külföldre pedig még számla sem kell. Küldhetsz, de megnézik és kidobják. Kint nem tudnak semmit kezdeni a te áfás számládal. Ennyi.
Azonban hallotam valamit az elektronikus számláról, amit jövőre vezetnek be és azt remélik, hogy ezzel egyszerűsödik az adózás valamint a vállalkozók megspórolják a nyomtatás költségét és a postázásét. De hogy hogyan működik arról fogalmam sincs.
De az is csak akkor ér valamit, ha a másik fél is elfogadja.
Alairas es pecset
Tovabba szerintem a szamlat leginkabb a vevonek kell alairni, hogy atvette, az elado oldalarol alairni leginkabb azert szoktak (lasd kisbetus szovegek), hogy ezzel elismeri az aru kiadasat.
Balazs
5. Bankkártyás fizetés
Ha bankkártyás fizetést is akarsz, akkor magyar bankkal is szerződhetsz (OTP, K&H, IEB, a lista nem biztos, hogy teljes).
Külföldi cégekkel is szerződhetsz, lényegesen egyszerűbb az adminisztráció, és a költségek is alacsonyabbak.
A külföldiektől is kapsz _tételes_ kimutatást, hogy mikor kitől mennyi érkezett, és a jutalékról is. Persze ehhez általában business account kell (értelemszerűen).
Általában:
Ha ennyi gondod van a belföldi szabályozással, csinálj egy offshore céget. 500-2000 USD között van az ára, általában bankszámlával és bankkártyával együtt. Lényegesen egyszerűbbek a számlázási, nyilvántartási, és nem utolsósorban az adózási szabályok is.
<Nincs cím>
Itt nem az a kérdés, hogy én kivel akarok szerződni, hanem az, hogy a potenciális ügyfél kinek hajlandó megadni a bankkártyaszámát. Te megadnád a kártyaszámodat egy ismeretlen litván banknak?
Ha ennyi gond van ezzel az országgal, akár el is költözhetnénk innen....:-)
néhány dolog
a) mysql-hez innodb-van, tranzakciókezelés ezerrel, plusz rekordonként checksum, plusz adatok redundánsan vannak tárolva (azaz a számla táblában nem csak a ceg_id szerepel, hanem az összes adata, ami a számlára kerül), ugyanis az egy nagyon fontos kritérium, hogy a számlát ugyanazokkal az adatokkal tudd reprodukálni, azaz a másolatban szereplő cég cím nem térhet el az eredetitől
b) minden számla véglegesítése előtt van egy nyomtatási kép pdf-ben, amin van egy piros kereszt, meghogy számlázásra nem használható, de amúgy megegyezik a leendő számlával, tehát a számlát kinyomtató tudja ellenőrizni az adatokat
c) a számla kiállításakor meg kell adni a példányt, mert úgy van a számlán, hogy eredeti 4/1. példány 3/1.oldal, eredeti 4/1. példány 3/2. oldal stb., amennyi kell (exportra akár 11 példány az eredetiből, mert egy marad a határon, három megy a vámra, és ki tudja még mennyi kell az ügyfélnek, és csak az eredeti a jó). ha ez lekérésre került, akkor ha másolatot akar valaki, azon már rajta lesz, hogy 1. másolat 4/1. példány 3/1. oldal, 1. másolat 4/1. példány 3/1. oldal stb. ebből következik, hogy amikor legenerálom a pdf-et, abban benne van, hogy ez az eredeti, és hány példányban készült, és ugyanez van a másolatban is. és a pdf annyi oldalas, ahány példány x ahány oldal. a szerveren, egy jól elzárt helyen, minden számla vagy másolat generálás tárolásra kerül, ezért ha tényleg begyűrődik a papír, vagy a 60 oldalas számla felénél kifogy a tinta, akkor van lehetőség a számla újbóli nyomtatására, de ehhez a számlázás bonyolító főnöknek van csak joga (még egyszer kiemelem, csak munkatársak állítanak ki számlát, tehát a felelősségük, hogy egy számla csak egyszer jusson el az ügyfélhez)
d) minden számlát lepecsételnek, aláírnak, és postán juttatják el az ügyfélnek. külföldre is. ha menet közben kiderül, hogy sztornózni kell, akkor megkérik, hogy küldje vissza a hibás számlát. nem tudom, hogy mekkora postaköltséggel kell számoljál, de szerintem eleinte olcsóbb lesz
e) a számlának van egy csomó idióta kelléke, mint például az összeg betűvel kiírása, euró alapú számlánál is, eurocentek is betűvel, illetve kétnyelvű számlánál minden adatnak szerepelnie kell két nyelven plusz egy vámtarifaszám, plusz kell egy vámügyintéző, aki megcsinálja a származási országbontást, stb (ha kézzel fogható terméket értékesítesz), szóval nagyon meg kell gondolni, hogy mit akarsz exportálni
f) a számlán rajta kell lennie, hogy milyen szoftver állította ki a számlát
g) és akkor, amikor a pénzed kezd el befolyni, akkor elkezdhetsz megküzdeni a különböző árfolyamokkal, az árfolyamkülönbözet lekönyvelésével, az eurós számlák forintosításának polémiájával... de szerintem nagyon fontos, hogy a költségeid el tudd számolni, ezért ne kezdj olyan céggel, aki levon tőled lóvét, és nem ad róla számlát
nem a kedved akarom elvenni, csak jól körbe kell járni a témát, esetleg nem is itthon kellene céget alapítani, ha annyira nemzetközi akarsz lenni
hirtelen ennyi jutott eszembe
sotetbarna
egy példány
-boogie-
most miért gondoljuk azt Gizikéről, hogy hekkeli a rencert?
szerintem nem kell eltúlozni a feladatot, minden munkának van anyagi vonzata. nem biztos, hogy egy cégnek ki kell fejlesztenie/fejlesztetnie egy atombiztos rendszert. lehet, hogy abból a pénzből, amit fejlesztésre költene, az egyik titkárnő napi feladatai között simán elvégzi, és nem kerül annyiba az arra az időszakra eső munkabére meg a postaköltség, mint az elektronikus számlázás kifejlesztésének a költsége.
most nem a programozók ellen akarok beszélni, de nincs értelme olyanba belevágni, ami nem térül meg belátható időn belül.
sotetbarna
<Nincs cím>
Majd ezután minden egyes tranzakcióról számlát kell kibocsátania, és elpostázni Zanzibárra. Szabvány levél külföldre 20 grammig, nem elsőbbségi: 180 forint.
Nyilvánvaló, hogy egy ilyen üzleti modell Magyarországon nem életképes.
<Nincs cím>
<Nincs cím>
de a nyitóban azt írtad, hogy oktatási oldalt szeretnél. egy tanfolyam általában nagyságrendekkel nagyobb összeg, mint 200 forint.
nem akarok kötözködni, csak egyre több olyan projektről hallok, ahol a nagy álmokat drága pénzen megvalósítják, de a megtérülést rosszul tervezik meg, ezért az ügyfélnek rövid időn belül megkeseredik a szája íze (tipikus dotkom bukta), és egy idő után nem használja a rendszert. ez ugye senkinek sem jó.
Másképp fogalmazok
-boogie-
igazad van, de ...
mi a lap előállításának a menetére koncentráltunk, nem pedig nyomtatásra. mint írtam, és mások is megjegyzeték már, minden nyomtatást lehet duplikálni
ha ilyen történik, ledarálják a számlát, ennyi
egyébként nem is böngészőben nyílik a pdf, hanem az acrobat readerben (cég szinten minden ie és acrobat úgy van beállítva, hogy külön nyíljon meg), mert együtt a kettő elég instabil. ebből kifolyólag akárhányszor kinyomtathatná a számlázó személy a számlát. de mit érne el vele?
<Nincs cím>
Az én díjszabásomba belefér a postaköltség, de minek postázzak, ha nem muszáj (vagy ha egy kis lobbizással el lehet érni, hogy ne legyen muszáj). És ha valaki ezután 200 forintos tartalom-szolgáltatást akar indítani, neki már könnyebb lesz. Én is sokat profitálok mások munkájából - pl. Weblabor blogmarkok...
megkérdeztem
nem az a lényeg, hogy ugyanazt a számlát ugyanazzal a vevővel hányszor nyomtatod ki, tehát a 001-es számlát, amin Kis Pista a vevő. így nem lehet csalni.
az az adócsalás, amikor a 001-es számlát kiállítod Kis Pistának, majd aztán a 001-es számlát Kovács Bélának, meg Gipsz Jakabnak és így tovább. azaz számlagyárat üzemeltetsz, amit csak keresztellenőrzéssel fedezhet fel az APEH (tehát egymás után leellenőrzi Kis Pistát és Gipsz Jakabot, és kiszúrja, hogy ugyanazon sorszámú számlád két vevőnek is kiadtad)
a számlákat szépen befizetik az ügyfeleid, mert nem tudják, hogy ugyanazon sorszámú számlát kétszer adtad ki. de Te csak egy számla után fizetsz adót, tehát adócsalsz
na ez a lényeg, hogy ezt ne lehessen megcsinálni a programmal. az, hogy a számlát ugyanazokkal az adatokkal hányszor nyomod ki, kutyát sem érdekel.
nem akarlak kiábrándítani a tökéletes számlaprogramba vetett hitedből, de a számlázó progit másfél éve használja a cég, a céget pedig az APEHtől fél évente könyvvizsgálók ellenőrzik (azaz két ellenőrzésen már átment, most gyúrják a harmadikat). nem hiszem, hogy ne szóltak volna már, hogy ez így nem jó.
<Nincs cím>
Még egyszer megnéztem az APEH oldalán a közleményt az elektronikus számlázásról: http://www.apeh.hu/informacio/afa_eszamla.htm. Azt írja, hogy "Az elektronikus úton kibocsátott számláknak is meg kell felelniük a számlákra vonatkozó általános követelményeknek." Majd ezután az áfa-törvényt kezdi részletezni, tehát a szövegösszefüggésből úgy tűnik, hogy nem a nekünk gondot okozó 24/1995PM-re gondol. De ehhez nagyítóval át kell bogarászni az eredeti jogszabályt (20/2004PM), az ilyen közleményekért az APEH nem vállal felelősséget (nem vicc).
A legnagyobb gond az elektronikus számlázással a kibocsátott számlák lekönyvelése, mindkét oldalon. A könyvelési információkat egy mellékletben az eredeti számlához külön csatolva, elektronikus formában kell szerepeltetni. A csatolásra vonatkozó követelmények: egyértelmű hozzárendeléssel, elválaszthatatlan módon, az utólagos módosítás lehetőségét kizárva történik. Hogyan lehet egy elektronikus dokumentumhoz (pl. txt, xml fájl) úgy mellékletet csatolni, hogy megfeleljünk a fenti feltételeknek?
Megnéztem a www.tavszamla.hu-t (T-Com csoport elektronikus számlázás). PDF formátumot használnak, felhívják az ügyfél figyelmét, hogy ne nyomtassa ki, csak elektronikus formátumban érvényes. Lehet, hogy hülyeséget kérdezek: a PDF nem tartalmaz véletlenül formázási információkat? Mert jelenleg csak formázatlan fájlokat fogad el az APEH:
A 20/2004 (IV. 21.) PM rendeletben hivatkozott, az állami adóhatóság által elfogadott fájlformátumok a következők:
1. .txt formátum (text fájl)
2. bármilyen más olyan ún. print fájl formátum, mely nem formázott szöveget, illetve karaktereket tartalmaz, továbbá nem találhatók a fájlban - a soremelésen és az oldalkezdet jelzésén kívül - utasítások, és a fájl tartalma (a fájlban szereplő szöveg, illetve karakterek) egyértelműen megfeleltethető a kinyomtatott adatoknak (a fájlban szereplő karakterek sorozata, tulajdonsága a papírra történő kinyomtatással sem változik).
3. .xml fájlformátum, a jelen közlemény 3. számú mellékletében részletezett fájlstruktúra szerint.
eddig jutottam
1. ÁFA számlázása
Magyar magánszemélynek: 25%
Magyar cégnek: 25%
Külföldi magánszemélynek: 25%
Külföldi cégnek: 0%
Jellemzően egy árat adunk meg a honlapon, a külföldi céges ügyfelek után járó ÁFÁ-t lenyelhetjük. Ha az ügyfél nyilvánvalóan fiktív nevet adott meg, akkor biztos ami biztos, be kell fizetni az ÁFÁ-t. Hogy mi a nyilvánvalóan fiktív, arról el lehet vitatkozgatni a revizorral.
2. Számla ügyfél általi nyomtatása böngészőből, pdf-olvasóból, email programból, stb.
Nem lehetséges! A számla szigorú számadású nyomtatvány, lásd a korábbi hozzászólásokat (24/1995 PM rendelet a gépi számlázásról).
3. Elektronikus számla
Az ide vonatkozó törvény: 20/2004 (IV.21). A jelek szerint itt megszűnt a példány-mizéria, az elektronikus dokumentumot szabadon lehet pl. CD-re kiírni - helyette viszont bevezeti a jogszabály a fokozott biztonságú digitális aláírás és az időbélyegzés kötelezettségét. A legnagyobb probléma a fogadó oldalon van: hogyan fogja a felhasználó a digitálisan hitelesített számlát megtekinteni, kinyomtatni, lekönyvelni? Erre van egy kész infrastruktúra - az Adobe Reader. Szinte minden internetező gépén fent van, tudja kezelni a digitális aláírásokat és az időbélyeget is, a Verisign ingyenesen letölthető bővítményével pedig még aláírni is lehet. Egy gond van vele: az APEH nem fogadja el a PDF formátumot. Adóellenőrzés céljára a számlát át kell tudni konvertálni txt, xml, vagy valamilyen csupasz print formátumba.
A szabályos elektronikus számlázási rendszerre példa a T-Csoport által működtetett www.tavszamla.hu. A letöltött fájl kicsomagolásához és megtekintéséhez az ügyfeleknek még külön le kell tölteniük egy MultiSigno Viewer nevű programot is a Kopint-Datorg honlapjáról. Nem látok bele a rendszerbe, de a jelek szerint ez valahogy így működik: T-Cég kiállítja a számlát valamilyen előírásos formátumban (pl. xml), majd a MultiSigno programmal aláírja és lebélyegezteti. Az ügyfél az így keletkező .mssign fájlt letölti és megnyitja a MultiSigno Viewer-ben, ami egyrészt készít neki egy nagymama-kompatibilis PDF-et, másrészt alkalmas a digitális hitelesítés ellenőrzésére. Újra aláírni már nem lehet vele, tehát ha az ügyfél ezt a számlát le akarja könyveltetni, akkor a könyvelőnek is meg kell vennie a MultiSigno dobozos változatát. ("A befogadónak... a könyvelésre vonatkozó információkat egy csatolt "mellékleten", azaz az eredeti számlához külön csatolva, elektronikus formában szerepeltetni abban az esetben, ha ez a csatolás egyértelmű hozzárendeléssel, elválaszthatatlan módon, az utólagos módosítás lehetőségét kizárva történik.")
Akkor most képzeljük el azt a külföldi netezőt, aki betéved egy kis magyar cég honlapjára, úgy dönt, hogy megveszi a tartalmat - majd ezek után letöltetünk vele egy programot, amit semmi másra nem fog tudni használni, csak arra, hogy a mi számláinkat megtekintse vele... Egyértelmű hogy ha egy hazai tartalom-szolgáltató nem tud, vagy nem akar papíralapon számlázni, akkor jelenleg csak az offshore megoldás marad a számára.
Mit lehet tenni?
Elméletileg a következő lehetőségek vannak:
1. Számla kivétele a szigorú számadású nyomtatványok közül (PM rendelet módosítása)
Ez lenne a leginkább vállalkozó-barát megoldás - lényegében ugyanazzal a feltételekkel működhetnénk, mint a külföldiek.
2. PDF engedélyezése
Ez is jó megoldás lenne, de szerintem a jogszabály szerzője pontosan tudta, hogy mit csinál, amikor kivette a PDF-et az elfogadott formátumok közül: piacot teremtett néhány jól pozicionált informatikai cégnek. A Magyar Elektronikus Aláírás Szövetség (www.melasz.hu) a napokban készül kiadni egy közös állásfoglalást az elektronikus számlázással kapcsolatban, őszintén meg lennék lepve, ha a közjó érdekében elfűrészelnék maguk alatt a fát.
3. Valamilyen meglévő, .txt és .xml fájlok kezelésére alkalmas nyílt forráskódú program kiegészítése digitális aláírás-kezelő szolgáltatással. A kézenfekvő jelölt az OpenOffice. Az OpenDocument formátumot egyébként az Európai Bizottság direktívája is "kötelezően ajánlott" jelleggel vezette be. Az OpenOffice már rendelkezik alapszintű aláírási szolgáltatással, de ez csak az OpenDocument fájlok esetén működik (.sxw, stb). Gondolom, megoldható lenne a program bővítése. A következő feltételeknek kellene megfelelni:
- digitális aláírás készítése
- aláírások hitelességének ellenőrzése
- aláírt dokumentumok visszafejtése és megjelenítése
- időbélyeg-kérelem összeállítása, elküldése
- több állomány szétválaszthatatlan összecsatolása (számla+könyvelési információk)
- állományok többszöri aláírása
Ez lényegében egy új alkalmazást jelentene a meglévő Writer, Calc, Base, stb. mellé. További hasznos szolgáltatás lenne nagyszámú dokumentum (mondjuk egy mappa tartalma) együttes aláírásának lehetősége - egy ilyen alkalmazás már a napi több száz számlát kiállító közepes cégek számára is megoldást jelenthet, átmenetet képezve a teljes szerver oldali automatizálás felé.
A rendszer tehát a következő képpen nézne ki:
1. Generálunk két xml fált azonos adattartalommal.
2. Az egyiket digitális aláírással és időbélyegzővel látjuk el.
3. A másikat tájékoztatási céllal bemutatjuk az ügyfélnek a böngészőben, és felkínálunk egy letöltő-gombot, amin keresztül az aláírt, hiteles példányt letöltheti.
4. Az ügyfél, vagy könyvelője a hiteles példányt az OpenOffice-ban megnyithatja, az aláírást és az időbélyeget ellenőrizheti, csatolhatja a könyvelési információkat, az összekapcsolt állományokat újra aláírhatja.
A fenti megoldás előnye, hogy azt az ügyfelet, akinek tele a merevlemeze, vagy lassú az internetkapcsolata, vagy bizalmatlan, nem kényszerítjük semmilyen program letöltésére. A könyvelőkre meg az ember jó lelkiismerettel erőlteti rá az OpenOffice-t.
Ezek után már csak egy probléma maradt: az APEH által megadott XML DTD címkéi. Ezek ugyanis magyar nyelvűek:
<elado>...</elado>
<vevo>...</vevo>
Addig is, amíg a világ könyvelői megtanulnak magyarul, nem ártana, ha a címkékben angol megnevezéseket (is) használnánk.
Edit
EU szabályok nyújtják a megoldást...
Szerintem a megoldást az EU szabályozás adja - pl. én német számlát egyszerű e-mail szövegeként kapok. Azaz az EU adóügyi biztosánál (ciki, épp a magyar Kovács László) lehetne a diszkriminatív magyar szabályozás miatt eljárást kezdeményezni. (Tudomásom szerint pont az EU miatt nem köteleő aláírni már a számlát)
Nem tudom találkoztál-e más EU-s tagállamokból származó számlákkal (német; angol), de közük sincs a magyar előírásokhoz, ergo az EU előírás nem tartalmazza azokat a kötelezettségeket, amit a magyar... szerencsére, ma már nem kell megállni kishazánk hatóságainál ilyen esetben.
Van olyan angol site http://www.accountis.com, ahol kis cégeknek is kínálnak megoldást (ebPrinter - http://www.accountis.com/accountis/sbhow.html). Ami nem más, mint egy ingyenes "PDF-printer", ami digitálisan aláírja az állományt, s már küldheted is e-mailben (az APEH hülyét kapna, hogy PDF-be nyomtatsz...)
XML számla formátum...
Az is tipikusan magyar, hogy az APEH XML DTD-nek köze sincs a világhoz. Ugyanis az OASIS, mint "szabványalkotó" szervezet már kidolgozta az UBL-t (Universal Business Language), ami a szokásos üzleti kapcsolatokban felmerülő ígényekre ad megoldást.
Természetesen más EU országok (Finnország; Dánia) erre építik a saját rendszereiket.
S végezetül egy idézet az Accountis oldaláról: The Accountis system is compliant with the EU VAT Directive (2001/115/EC).
Becsuletes megoldas-e?
Becsuletes megoldas-e az ha tobb ceg alapit egy olcso kulfoldi ceget es a Magyarorszagon online ertekesitett termekeit, a kulfoldi cegen keresztul szamlazza ki az otani enyhebb torvenyek betartasa mellett.
Magyarul a kulfoldi ceg adja a szamlat.
1. Vagy atszamlazassal (mint viszontelado)
fizeti ki?
2. Vagy pedig ev vegen a nyereseget osztalekkent kifizeti?
Mindegyik megoldás legalis?
Igen
Én egyébként azt választottam, hogy email mellékletként PDF formátumban számlázok. Tudom, hogy nem szabályos, de a jogszabály teljesen életszerűtlen. Egyelőre elindítom a projektet így, mindent bevallok az utolsó centig, aztán ha az APEH megbírságol a PDF miatt, még aznap megyek offshore.
e.
Egyszerű húzás
Elkészítem a számlát hagyományos szabályos programmal szükségesetén. Az oldalakat (példányokat) pdf-ben legyártom. Ezt a fájlt-küldöm, engedem letölteni. Ha a vevő többször tölti le akkor is ugyanazt kapja. Ha többször nyomtat akkor is ugyanaz az eredmény.
Ennyi...
pofon egyszerű
Az APEH is PGP-t használ
Ugye itt meglódul a fantázia... hogy illeszkedik be a PGP (vagy esetleg a GPG) a magyar törvényekbe? Ha már az APEH is használhatja, akkor valahogy be kell férnie.
blinksale
online számlázás, bár nem próbáltam még ki.
Létezik egy ingyenes magyar online számlázó
létezik?
A www.szamlazorendszer.hu-hoz nincs API, és egyébként is megkövetelik az Internet Explorer használatát (nyilvánvalóan azért, mert csak ezzel tudják figyelni, hogy az ügyfél mit és hányszor küld ki a nyomtatóra), amit én pl. nem várhatok el az ügyfeleimtől.
Ami érdekes, az a www.tavszamla.hu, ahol úgy látom, már nem kell letölteni a "nézőkét", a számla lényegében egy elektronikusan aláírt PDF. Annak ellenére, hogy az APEH honlapján még mindig fent a szöveg:
A 20/2004 (IV. 21.) PM rendeletben hivatkozott, az állami adóhatóság által elfogadott fájlformátumok a következők:
1. .txt formátum (text fájl)
2. bármilyen más olyan ún. print fájl formátum, mely nem formázott szöveget, illetve karaktereket tartalmaz, továbbá nem találhatók a fájlban - a soremelésen és az oldalkezdet jelzésén kívül - utasítások, és a fájl tartalma (a fájlban szereplő szöveg, illetve karakterek) egyértelműen megfeleltethető a kinyomtatott adatoknak (a fájlban szereplő karakterek sorozata, tulajdonsága a papírra történő kinyomtatással sem változik).
3. .xml fájlformátum, a jelen közlemény 3. számú mellékletében részletezett fájlstruktúra szerint.
Konferencia a témáról
Két egésznapos szakmai rendezvényt is csináltunk már az elektronikus számlázás témájáról, az elsőt 2006. áprilisában, a másodikat most nemrég 2007. március 7-én dmslabor.hu A felkészülés, és a tematika feltárása miatt már többször is végigolvastam a bejegyzéseket, örülök, hogy egy év kihagyás után van friss, új tartalom.
A két rendezvényen összesen több mint kétszáz emberrel néztem farkasszemet, levezető elnökként fogadtam a kérdéseket, segítettem az előadók válaszait.
Sajnos azt kell, hogy mondjam, hogy most már nem technikai/technológiai/jogi a probléma, hanem egyszerűen emberi. Már tavaly is csak egymásra mutogattunk ki lesz az első (pedig akkor már volt "első" a Wizzair), idén pedig a Malév mesélhette el, hogyan élik meg az emberek az elektronikus számla "fogadását". A lobbiszervezetek is csak tovább bővültek, megalakult az "Elektronikus Számlakibocsátók Egyesülete", érdemes utána nézni mi a különbség a MELASZ-hoz képest.
Idén mind a PM-ből, mind a GKM-ből kaptunk előadást, a felkészülés során egyértelműen éreztették velem az előadók, hogy "igazán nem rajtuk múlik". Az APEH-ban is jártam, ott is inkább az már a hangulat, hogy aki akarja csinálja, rajtuk nem múlik, így senki ne fogja magát vissza e-számlázó progi írásában :-)
Ami nagyon gáz volt, a rendezvény végén megkérdeztem, hogy akkor a mai nap "fáradalmai" alapján kik döntenének úgy, hogy holnaptól megpróbálkoznak elektronikus számla kibocsátásával, a több mint 80 résztvevő közül senki nem emelte fel a kezét. Pedig isten bizony a lelkünket kiadtuk a szakmai programért... Kicsit borzoltam a szemöldököm, amely hatására két-három kéz emelkedett, mindegyikőjüket személyesen ismerem.
Számomra komoly tapasztalat volt mindkét rendezvényt végigcsinálni, szívesen segítek a benyomásaim, tapasztalataim megosztásával.
Üdv, mindenkinek:
dr. Haraszti Miklós
DMS Labor
mi van a nézőkével?
Én továbbra is ott látom az APEH honlapján, hogy számlát csak TXT, formázási információt nem tartalmazó nyomtatási vagy XML formátumban fogadnak el. Ha egy ilyen fájlt elektronikusan hitelesítek (elektronikus aláírás, időbélyeg), akkor rántotta lesz belőle, amit az ügyfél nem fog tudni megnyitni, csak külön "nézőke" programmal. Úgy látom, néhányan elkezdtek PDF számlákat kibocsátani, amit az ügyfél meg tud nyitni - a PDF olvasókban többnyire van visszafejtő-ellenőrző algoritmus - de ez nem felel meg az APEH előírásainak, mivel sem nem TXT, sem nem XML, és nyilvánvalóan tartalmaz formázási információkat. Ha a vonatkozó APEH előírást időközben hatályon kívül helyezték, akkor valaki legyen szíves linkelje be az erről szóló jogszabályt/utasítást.
Ami a fenti reklámcélú hozzászólást illeti, egyes üzleti vállalkozások rendkívül agresszíven nyomulnak ezen az új piacon, és megpróbálják berántani a tájékozatlan ügyfeleket az elektronikus számlázásba anélkül, hogy az ügyfél pontosan tisztában lenne a helyzetével. Még egyszer (és részemről utoljára): jelenleg Magyarországon kétféle módon lehet elektronikusan számlázni - az egyik módszer abszurd, a másik jogszabály-ellenes.
1. A jogszabályokkal összhangban számlázunk, ekkor le kell töltetni a vásárlóval a "nézőke" programot (valamint a vásárló könyvelőjének meg kell vennie a nézőke üzleti verzióját ahhoz, hogy a számlát a könyvelésbe beállíthassa).
2. PDF-ben számlázunk, amit az ügyfél meg tud nyitni, a digitális hitelesítést ellenőrizni tudja, viszonylag egyszerűen lekönyvelheti - de a PDF-et az APEH hivatalosan nem fogadja el (hogy gyakorlatban mennyire rugalmasak, azzal kapcsolatban nincs tapasztalatom).
Mindenkitől, aki mást mond, tessék kérni azt a hivatalos dokumentumot, amelyben az APEH visszavonja a honlapján jelenleg is olvasható fájlformátum-specifikációt. Ha az illető nem tud ilyet produkálni, akkor az üzleti ajánlata legalábbis egészséges gyanakvással kezelendő.
"reklámcélú hozzászólás"
Tőled is, és a többiektől is elnézést kérek, ha a bejegyzésem reklámcélúnak minősül. Természetesen semmi értelme konferenciákra járni, és a szünetekben személyesen beszélgetni az előadókkal, pl. dr. Kovács Ferenccel, aki az APEH részéről tartotta meg előadását, vagy értelmetlen megkérdezni szintén személyesen dr. Boros Richárdtól, hogy a Kiemelt Adózók Igazgatóságán hogyan ellenőrzik az ügyfelek elektronikus számlázási megoldásait. Igen, ehhez reklám kell.
Egy e-mailben küldött információ, ha kéretlen akkor reklám, ha feliratkoztál, akkor tájékoztatás? Ha reklámnak minősül egy konferencia témájának az ismertetése, akkor hogyan jutassuk el az "információt" a leendő hallgatósághoz?
De hagyjuk.
Inkább segítek, hiszen te írtál a legtöbbet, te is indítottad ezt a dialógust. A többiek is segítő szándékkal tettek javaslatokat, de olyan mintha csak a gátló tényezőket keresnéd. Úgy nem is fog menni.
Igen, igazad van most is formázatlan TXT van az ajánlásban, nem módosították. Igen mindkét 20/2004 PM szerinti megoldás baromság. Igen. A baj csak az, hogy a 195-ös EU direktívának való megfelelés jogharmonizációjában keletkezett, és megegyezik az EUs direktíva szövegével, vagyis a többi tagállamban is ilyen végrehajthatatlan környezetben kell e-számlázni. Azt hogyan tudod értelmezni, hogy a másik tagállam számlakibocsátója egyszerűen nem is tesz rá időbélyegzőt? Pedig neki is kötelező lenne. Vagyis mi úgy látjuk, hogy nem az APEH csinálja, hanem azok akik valóban számlát bocsátanak ki, és majd megváltoztatja az APEH az ajánlását, ha látja, hogy a többség PDF számlákat gyárt. Tudom, hogy a jog az fekete vagy fehér. Így kezdtük mi is a konferenciát, aztán meglepő módon épp azok a szervek színesítik és teszik "rugalmassá" a kereteket, akikre a leginkább hivatkozol. Igazad van, ez elriasztja a vevőket, és tényleg az a sok "nyomulós" cég meg butítja őket. Igen. Meg akarnak élni. Eladnak. E-számlázó rendszert, megoldást, vagy bármit, ami jó lehet az ügyfélnek.
Ne haragúdj, hogy erre az oldalra tévedtem, igyekszem nem megsértődni, és megnézem ír-e még valaki a régiek közül, mert egymásnak esni, a másikat döngölni a semmibe nem illendő, és tisztelem a Weblabort annyira, hogy ilyen felületen konstruktívnak és nyitottnak kell lenni. Haladjunk előre.
Ha ellenséget csinálsz az APEH-ból, akkor az is lesz. Ha belépsz az ajtaján, ott is embereket fogsz találni, akik hétköznapi, munkaköri gondjaikról fognak beszámolni. Most éppen néhány millió elektronikus bevallásról, vagy a házipénztár állomány ellenőrízhetőségéről, stb. Némi kutakodás után tudsz olyannal beszélni, aki már látta a 20-as PM rendeletet közelről.
Többféle megoldást is látunk a problémádra, csak dönteni kell, hogy milyen stratégia mentén lépsz tovább. Lehet a kockázatot minimalizálni, a költségeket leszorítani, a vevői elégedettséget maximalizálni, de dönteni kell az irányról.
Legutóbb tettünk egy kísérletet. Kinyomtattuk a számlát a számlázó programmal, és aláírva pecséttel (ugye már nem kötelelző!) visszaszkenneltük. 100 ügyfélre vetítve 60% előre elutalta, és postán várta a papír számlát, nem is kérte az elektronikus másolatot. 15% kérte a másolatot, és utalt amint látta a szkennelt példányt és később megkapta papíron is. 25% csak a papír átvétele után utalt.
3% nem vette át a számlát a rendezvényen...
Segítő szándékom továbbra is fenntartom, üdvözlettel:
Miklós
Felmerul bennem par kerdes a temaval kapcsolatban
Az sms-es megoldas kezenfekvo.
Vizsgaljuk a bankkartyas, vagy atutalasos fizetes lehetoseget.
Ugye ebben az esetben szamlat kell kiallitanom a bevetelemrol a felhasznalo reszere. Mi tortenik, ha a felhasznalo nem kivanja megadni az adatait? Ahogyan a boltban sem kersz a kenyerert afa-s szamlat. Letezik valamilyen "on-line blokk"? Ez a legkenyesebb resz.
Ha ker szamlat, akkor ertelemszeruen megadja az adatait. Felajanlom neki az online szamla lehetoseget. Elfogadja, orulok.
Tegyuk fel, hogy nem fogadja el, en pedig nem szeretnek magamnak veszteseget termelni. Etikus-e atharitani a postakoltseget a felhasznalora?
nyugta
Persze a felhasználónév/email megoldás sem teljesen szabályos, mert a számlának az előírások szerint tartalmaznia kell a vevő nevét és címét. Egyébként dereng, hogy hasonló témából már volt adatvédelmi ügy, hogy miért kötelező egyes vásárlásoknál megadni a személyes adatainkat. Mintha valami jövedéki téma lett volna - ha x forintnál nagyobb összegben alkoholt vásárolsz, akkor a boltos nem nyugtát, hanem kötelező jelleggel számlát állít ki, neked pedig meg kell adnod az adataidat. Nem emlékszem, mi lett az ügy vége.
es akiknek nincs penztargepuk?
Letezik nyugta azok szamara, akik nem penztargeppel dolgoznak. Lehet irni nyugtat bankkartyas fizetesnel is?
automata üzlet
b) szórakoztató játékautomaták terme;
c) automata üzlet (ahol nincs kezelő személyzet);
d) csomagküldő szolgálat, kivéve annak nyílt árusítást végző üzletét, bemutatótermét;
e) az üzletek működéséről szóló jogszabály alapján kereskedelmi működési engedély megszerzése alól mentesülő, ipari - kivéve élelmiszer-ipari - tevékenységet folytató egyéni vállalkozó, ha termelő és értékesítő tevékenységét ugyanabban a helyiségben folytatja;
f) az üzletek működéséről szóló, külön jogszabály vonatkozó mellékletében szereplő termelői borkimérés;
g) utazási iroda, utazási ügynökség, idegenforgalmi szolgáltató iroda utazási szolgáltatásai tekintetében;
h) azok az adóalanyok, akiknek a nyugtaadás alól az áfatörvény értelmében az adóhatóság felmentést adott.
Szerintem a c) pont vonatkozhat online szolgáltatásokra is, a h) pont alá sorolt eseteket meg külön meg kellene nézni, ha valakinek van rá ideje... Viszont a papírnyugtára vonatkozó szabályokat itt is be kell tartani (nyugtatömb, szigorú számadás, stb.), tehát semmivel nem vagy előrébb, mint a papíralapú ÁFÁ-s számla esetén.
de elorebb vagyok
"emberi" probléma
Onnan indultunk el, hogy az online számlázás beindítása már csak "emberi" probléma - ehhez képest most kiderül, hogy akkor mégiscsak érvényes az APEH előírása a fájlformátumokról. Megjegyezném: nem "ajánlás", hanem előírás.
Az EU-ban én konkrétan csak a brit szabályozást ismerem, ott tetszőleges fájlformátumban - így PDF-ben is - lehet számlát kiállítani, csak előzetesen be kell jelenteni a pénzügyőrségnek (Her Majesty's Custom and Excise).
Oké, ez is egy hozzáállás, semmi gond vele, csak akkor tegyél egy jókora címkét a projektedre, amiben erről tájékoztatod a potenciális ügyfeleket.
Konkrétan? Írásba is adták a "keretek rugalmasítását"?
Azt hagy döntse már el az ügyfél, hogy neki mi a jó. És ahhoz, hogy ezt eldönthesse, elengedhetetlen a korrekt tájékoztatás. Az, hogy te ebből akarsz megélni nem elég ok arra, hogy fontos tényezőket (APEH előírások) elhallgatsz vagy megpróbálsz bagatellizálni.
Végül számomra visszatetsző, hogy miközben érdemi információkat nem adsz sem a konferenciáról, sem az általatok kínált megoldások jogi és technikai hátteréről, közben folyton "segítő" szándékodat hangsúlyozod. Hol itt a segítség? Ha írsz egy részletes beszámolót arról, hogy a konferenciátokon mit mondtak az APEH főemberek, az segítség. Ha írsz egy, a jogszabályokkal összhangban működő online számlázórendszert és közzéteszed GPL licenc alatt, az még nagyobb segítség. Ha viszont csak a saját fizetős projektjeidet akarod népszerűsíteni, akkor azt megteheted a saját honlapodon.
brit szabályozás
Provided that the relevant invoice messages used contain the required data (see paragraph 3.1) we will accept a wide variety of electronic invoice message formats. Examples include:
* established EDI standards such as UN/EDIFACT, ODETTE and TRADACOMS;
* web-based standards such as XML and its derivatives (for example, XSL); and
* comma-delimited ASCII, PDF.
(Kiemelés tőlem.)
Forrás:
Electronic Invoicing HMRC Reference:Notice 700/63 (December 2003)
ezt nagyon benezted...
Nem tudom megnezted-e a weboldalukat, de ok (Hírközlési és Informatikai Tudományos Egyesület (HTE) Dokumentum-Technológiai Szakosztálya) nem ceg, es nem is kinalnak semmilyen megoldast...
non-profit?
Nekem külön tetszik a "kockázatot minimalizálni" kifejezés, magyarán ők is elismerik, hogy ha egy vevőbarát, alacsony költségű rendszert fejlesztesz, akkor kockáztatod az APEH bírságot - és ha nem akarsz kockáztatni, akkor fizess és kényszerítsd a vevőidet egy barátságtalan megoldás használatára (gyakorlatilag csak nagy cégek - monopóliumok - számára járható út).
E-számla megoldás
Ahogy látom ez a topic már meglehetősen elhagyatott, ugyanakkor sokan tévednek erre elektronikus számlázással kapcsolatban, úgyhogy (bár nyílván reklámcélú a dolog) gondoltam leírok ide pár dolgot.
Az utolsó néhány postot végigolvasva azért annyit mindenképpen ki kell emelni, hogy tavaly sem volt semmi baj a jogszabályokkal, illetve most sincsen. A baj csak az volt, hogy nem létezett olyan megoldás, mely eredményeképpen előállt e-számla:
1. Megfelelt a jogszabályoknak
2. Felhasználóbarát volt
3. Az automatikus feldolgozása megoldott lett volna.
Ezen felbuzdulva készítettünk egy megoldást, pely PDF alapú (tehát nem kell külön olvasó szoftver a megnyitáshoz), de közben eleget tesz minden jogszabályi követelménynek is! Részletekért nézzétek meg az E-számla megoldást bemutató oldalunkat.
Ha esetleg valaki nem akarna vesződni a jogszabályok értelmezésével, annak összeállítottunk egy anyagot ez elektronikus számla törvényi hátteréről.
üdv,
SzabóZ
Aha, tehát aláírt, időbélyeges PDF, mely XML mellékletkén
nem kell nézőke?
PayPal lekönyvelése
Tegyük fel, hogy én a sima papírra nyomtatott számlázóprogram számláját fogom, és berakom a borítékba/dobozba/kartonba/stb, és az áruval együtt küldöm a vásárlónak, aki előzőleg kifizette PayPalon az áru ellenértékét.
A pénzt ugye pedig ha lekérem a céges számlára, nem tételesen érkezik meg, hogy ettől és ettől, ennyi és ennyi, hanem a PayPal Inc.-től jön egy összegben.
Erre a könyvelőm azt mondja, hogy nem tudja lekönyvelni a bejövő pénzt (azaz a fent említett számla ellenértékének befizetését).
Van-e és ha van, akkor milyen megoldás erre?
Havi lekérdezés van paypalnél, de csak qif, iif és vessző, valamint pontosvesszős határolós fájlok formátumában. Ezt sem a könyvelő, sem én nem tudom hasznosítani.
Esetleg hagyjam a paypalt, és csak money ordert (átutalást) fogadjak el? És ha kényes témájú a vásárlás, és ez megakadályozza a vásárlót, hogy bemenjen a bankba, és kitöltse az utalós papírt?
megoldás
Ennyi...
vevő általi nyomtatás