Saját számlázó program írása

Internet: PHP, CGI, stb.

Sziasztok!

Vállalkozásunk saját magunk által készített PHP+MySQL alapú vállalatirányítási rendszert használ. Ebben a rendszerben vezetünk mindent (dolgozók, jelenléti ív, szerződések, ügyfelek, partnerek stb..), tehát ebben már felépítettünk egy nagyon jó adatbázist. Arra gondoltunk, ezt a rendszert kibővítenénk egy számlázó modullal, mellyel kb heti 10 számla készülne, teljesen egyszerűen, 3 példányos átutalásos vagy készpénz.

A programot kizárólag mi használnánk, tehát nem értékesítenénk tovább!

Ami érdekel ezzel kapcsolatban - és sajna nem találok ezzel kapcsolatban egyértelmű leírást:

- Kell-e, és ha igen kivel szükséges "bevizsgáltatni" a programot?
- Mire kell nagyon figyelni (a számla formátumon kívül)?
- Mehet-e a számlák tárolása a papír mellett mondjuk PDF-ben?

Meg ami még eszetekbe jut...

Köszi szépen!

  • 10319 megtekintés

( zoner | 2009. 03. 10., k – 21:17 )

APEH részéről valami nagyon szigorú engedélyeztetése van ennek. De ha sikerül találni egy olcsó, egyszerű megoldást, azt kérlek oszd meg velünk, engem pl érdekelne a dolog.

Számlázóprogramhoz semmiféle engedély nem szükséges!
A készítőnek kell egy felelősségvállalási nyilatkozatot kiállítania, mely szerint az előállított számla megfelel a törvényi előírásoknak, illetve a sorszámozás folyamatos, kihagyás nélküli. Valamint felhasználói kézikönyvet kell a programhoz biztosítani.
Ha saját magadnak írod, akkor ezt neked kell megtenned.

Ha forditva kozelited meg a dolgot akkor konnyebb a dolog. A szofver⇒penztargep irany altalaban problemas. Erdemesebb a forditott megoldast hasznalni ahol a pgep kuldi az ertekesitest a szoftver fele, igy az apeh nem problemazik es nem neked kell a program hitelesitesevel bajlodnod, hanem a penztargep forgalmazojanak kell hitelesittetnei a gepet es az illesztojet.

Hello!
Azt csak hiszed hogy nem szereti. Dehogynem,mert akkor több pénz gombolhat le rólad amiért külön a szoftveredet is engedélyeztetni kell. Meg persze csak CE engedélyes pc-t rakhatsz mellé. Ezt a módszert a szoftver készítők nem szokták inkább szeretni mert igen bonyolult és költséges egy ilyen megoldást engedélyezni. De a ma használatos összes fiscal printer ezen a megoldáson alapul.

Üdv.

( zsolt | 2009. 03. 10., k – 22:06 )

Szerintem semmiképp nem éri meg fejleszteni és folyamatosan karbantartani egy számlázó programot, mikor vehetsz ilyet készen is.

Olyat érdemes választani, aminek jól dokumentált interfésze van, esetedben lehetőleg http-n.

Ez a számlázó program pl. rendelkezik egy ilyen modullal, ami ugyan webáruházakhoz készült, de valszeg neked is jó lesz, mert lényegében ugyanarról van szó.

( mozsaf | 2009. 03. 10., k – 22:24 )

Igazából sokmindent szerintem frissíteni/fejleszteni nem kell - ha belegondolok hogy a sima kék 3 példányos számlatömböt sem kell cserélgetnem. Max ha változtatják az ÁFA kulcsot (amire most készültek Ferikéék). A számla formátuma nem nagyon változik. Vagy igen?

Ami miatt nem örülnék egy megvásárolt programnak, hogy például használhatatlanná (vagy nagyon körülményesen kapcsolható össze) válik a meglévő globális ügyfélbázis, több programot kéne futtatni stb...

A mi programunkhoz igazából elég egy böngésző a munkaállomásokon...

Ebben teljesen igazad van, de böngészőből azért még ez sem egyszerű.

Sajnos a törvényalkotónak ebben az esetben nem sok fogalma lehetett arról, amiről törvényt alkotott és persze azoknak sem, akik megszavazták.

Viszont mégis törvény, amit be kell tartani, amennyire lehet.

De volt, és meg is vannak rá a szabályozások. Nem a több első példánnyal van gond, azt fénymásolóval is készíthet az akinek van aláírási joga. Az más szinten bukik, és az a kiállító felelőssége.
A gond ott kezdődik, mikor egy első példány sem jön ki a nyomtatóból :)

"De volt, és meg is vannak rá a szabályozások."

Gyakorlatilag minden más országban azzal ír számlát az ember, amivel akar.
Akár egy egyszerű szövegszerkesztővel is.
A sorszámozás és a másolatok követése az ő felelőssége, nem a programé.

Csak a mi országunk ilyen agyonszabályozott, nézz körül.

Ilyen nekem is volt, azóta pdf-be nyomtatok mindent.
A legtöbb ügyfelemnek elküldöm a pdf-et, pecsét és aláírás már nem kötelező.
Aki ragaszkodik annak én kinyomtatom, aláírás, pecsét és mehet a postára.

És amikor megyek a könyvelőhöz akkor egyszerre kinyomtatom a második példányt és kész.
Jobb esetben ezt meg a könyvelőnél teszem, szóval spórolok a papírral :))

nem cska netlockos jó, bármelyik jó ami megfelel a törvényeknek. pl. a máv-os olcsó (viszont nincsen benne alapból a böngészőkben, levelezőkben, de ettől még hivatalos).

netlocknál egy személyes fokozott biztonságú tanusitvány 5e forint egy évre.

_________________________
Hogyan?

"A gond ott kezdődik, mikor egy első példány sem jön ki a nyomtatóból :)"

Ekkor egy SQL parancsot szoktam kiadni, és mindjárt megkapom az első példányt. Persze előbb azért újrarúgom a nyomtatót. Olyan a program, hogy táblában tárolja, hogy az adott számlát már kinyomtatták-e. (ez plusz egy mező soronként az adatbázisban).

/mazursky 

Love your job but never love your company!
Because you never know when your company stops loving you!

zsolt: Van egy MySQL-ben egy egyedileg kialakított táblarendszer mely tárolja az ügyfél adatokat. Sok esélyét nem látom annak hogy ezt az adatbázist egy külső - általam megvásáolt - számlázó program használhassa.

többiek: A nyomtatási kérdés nem biztos hogy olyan kritikus. Például, a számlázó generálhat PDF-et melyet ráküldhetek bármennyi nyomtatóra. Ezek után a PDF-et törölhetem (akár programkódon belül), annak érdekében hogy nehogy ki lehessen nyomtatni többször bármelyik példányt.
Persze ez most már itt kényes epizód, de ha belegondolok, technikailag megvalósítható bármilyen programban az hogy többször kinyomtassam az első példányt többször - ami férreértés ne essék nem cél. Mert például ennyi erővel például akármelyik program nyomtatási kimenetét küldhetem PDF-be (PrimoPDF stb..), és gyakorlatilag ott vagyok mint a saját programomnál...

De továbblépek (jogi, ügyviteli háttér nélkül, csupán tapasztalat alapján), hogy én speciel kaptam már PDF-ben elektronikus számlát...

Az elektronikus számla az teljesen más tészta. Ott a gépen, elektronikus bizonylatról van szó, ami hiteles dokumentum, jó esetben élete folyamán nem kerül papírra.
A gépi számlázásnál a bizonylat viszont a papír, a kiállítása után senkit sem érdekel, hogy a gépen mi történik vele.

"Van egy MySQL-ben egy egyedileg kialakított táblarendszer mely tárolja az ügyfél adatokat. Sok esélyét nem látom annak hogy ezt az adatbázist egy külső - általam megvásáolt - számlázó program használhassa"

Igen, ezért említettem pont a fenti programot, ami HTTP protokollon keresztül egy egyszerű xml-ből veszi a számlák adatait, amit elég egyszerű egy web-re írt környezetben előállítani.

Annyi, hogy a web-es rendszerednek egy konkrét URL-en a nyomtatandó számlákat XML formátumban kell megjelenítenie, nem HTML-ben.

PDF-ben lehet számlát kiadni, de szerződnöd kell egy aláíró céggel, amik minden számládat hiteles időbélyeggel látják el (NetLock pl. ilyen).

PDF tárolásra is szerződhetsz olyan céggel, kik tudják biztosítani a millió előírást.

Arra készüljetek fel, hogy a számláról bármikor, az eredetivel tökéletesen egyező másolatot kell tudni adni. Különös tekintettel a megváltozó cégszékhelyre (akár vevő akár eladó részéről), telephelyre, levelezési címre. Bőven jó, ha PDF-et generáltok (első két vagy három példányról egyben vagy külön ízlés szerint) egy könyvtárba és egy kellően megbízható személy nyomtat, majd a publikus megosztásból elteszitek a PDF-et. Az ezen felüli másolatokat pedig már lehet simán PHP-ból on-the-fly kitolni a böngészőbe. Ha MySQL-eztek, akkor roppant hasznos olyan táblatípust választani, ami külső kulcsozik.

Korrekt esetben van egy termékazonosító, hozzá egy nettó listaár, hozzá egy áfaazonosító (amihez tartozik egy áfa-szorzó), egy kedvezményazonosító, (amihez tartozik egy kedvezmény szorzó), aztán ha ÁFA-változás van, csak egyhelyütt kell matatni, egy táblában. (A számlára a nettó listaár szorozva a kedvezményszorzóval, szorozva az ügyfélhez tartozó szorzóval kerül nettó eladási árként, onnan meg az áfa-szorzóval számolod az áfaértéket, illetve a bruttó árat. Vagy nem így csinálod?

Nemegészen.
Mivel minden program így müködik, de ez nem felelt meg az egyik partnernak.
Nála:

beszerár (nettó)
egyéni ár (nettó beszár+z% amit magad vevőnként külön)
kisker ár (nettó beszár+x% amit megad)
nagyker ár (nettó beszár+y% amit megad)
bolti ár (bruttó ár, külön megadja kézzel, vagy kiszámolja a kisker ár+áfa%)

kedvezmény:
a fentiekből kerül levonásra
egyéni (vevőként megadható %)
cikk (ha be van állítva akkor felülírja az egyénit. pl.: egy cikk akciózása miatt)
cikkcsoport (vevőként külön. ha be van állítva akkor felülírja az egyénit de ezt is felülírja a cikk kedvezmény)

árlistánál a bolti bruttót látja (ezért kell átárazni áfa váltáskor)

Tudom nem szokványos, de így mindenfajta ár beállítható vevőre/cikkre

pch

--
http://www.buster.hu
--

Gyakorlatilag picit több a szorzó nálad. A bruttót mindenképp a nettó (kerekítve) plusz a számított áfa (kerekítve) összegeként illik számítani, nem? Adott termék esetén az áfa-besorolás nem, csak az áfa mértéke változik normális esetben, ergo a termékhez egy áfa-besorolást megadva az áfakulcsos táblázatot kell csak matatni, a bruttó bolti ár meg simán lehet egy jól irányzott view a megfelelő táblákra, akáőr a készlet figyelembe vételével együtt.

Elolvastam, persze. Azonban az, hogy valaminek "csak úgy" tekerünk a bruttó árán, az nem biztos, hogy teljesen korrekt, hiszen lesz egy nettó ár, meg egy másik, ami nem lesz egyenlő a nettó ár+ÁFA összeggel... Ezt korrekten a nettóra alkalmazott (termékre és/vagy vásárlóra vonatkozó) engedményszorzóval kéne beállítani szerintem... Jogilag, ha jól tudom, a bruttó eladási ár a nettóból számított érték, de majd okosabbak kijavítanak, ha nem így van.

El kell dönteni, hogy mi a "kályha", azaz mi a termék alapára. Ez lehet a beker. ár, lehet egy beker. ár alapján "kockás papíron" számolt ár, lehet a beszállító lábmérete szorozva a lábszaggal, akármi, a lényeg, hogy egy fixponthoz képest, átlátható módon történjen az árképzés (ez elsősorban fogyasztóvédelmi kérdés, nem is annyira adózási...)

( asci v | 2009. 03. 10., k – 23:12 )

Engem is érdekel a dolog és ahogy látom másokat is.
Szerintem fogjunk neki és készítsünk egyet. A dinamikus adatokból számla kinézetű pdf készítését elvállalom.

( aperger | 2009. 03. 10., k – 23:54 )

Azt nem állítanám, hogy minden kérdésben profi vagyok, de van működő Linux alatt is futtatható számlázó rendszerem. A program "túl van" néhány APEH ellenőrzésen is. Egyedül a nyilatkozatra van szükség. Értelem szerűen a sorszámozásnak folyamatosnak kell lennie, amit a felhasználó nem befolyásolhat. A számla formátuma azért fontos!!! Vannak megkötések. Az APEH nem fogja megnézni milyen programmal készíti a számlát a tisztelt felhasználó, ha ezeket rendben találja.
Mindenki ezen az 1x lehet kinyomtatni témán lovagol, holott vannak ennél sokkal lényegesebb kérdések is, ráadásul ezekről a törvény sem tisztán egyértelmű. Az 1x kinyomtatás szerintem annyi, hogy a számla kinyomtatása után a felhasználó egy kérdésre válaszol (akár példányonként is) hogy sikeres volt-e a nyomtatás? Ha igen, utána csak a stornó áll a tisztelt felhasználó rendelkezésére. Hogy védekezzen az ember (pláne egy olcsó számlázóprogram keretein belül) az ellen, hogy a tisztelt felhasználó "PDF nyomtatóra" nyomtat -> annyi első példány lesz belőle amennyit csinál... Ez ellen nem lehet védekezni. Ez nem is a készítő felelőssége, és az sem hogy a korábban említett kérdésre helyesen válaszol-e!?
Apróságok amik nekem okoztak fejtörést, átalakítást:
- számla formátuma,
- EU-s számlázási formai követelményei,
- kétnyelvű számla, majd már lehet csak idegen nyelvű is,
- fordított adózás formátuma
- folyamatos teljesítés esetén a számla kiállítási, teljesítési és fizetési határideje,
- készülő számla folytatása később hálózatos, többfelhasználós módban is,
- Sztornó vagy érvénytelenítő számla esetén lehet e a felirat sztornó, mi a módosító számla, (máig nem tiszta, ezért csak a "sztornó támogatott nálam)
- mi legyen a számla 2. oldalán, ha az nem egy oldalas
- megjegyzések a tételekhez, számlához,
- hivatkozási számok a projektekhez, partnerekhez,
- nyomtatási kép rögzítés előtt (hogy a főnök jóváhagyhassa, bizonyos érték felett nem árt :-))
- stb...

Nem olyan egyszerű megírni

Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"

aperger: köszi, erre így egyben voltam kiváncsi. Szerintem mire bereszelek egy vásárolt programot hogy kommunikáljon normálisan a adatbázisunkal, annyi idő alatt megírom azt a számlázó modult, mert technikailag nem bonyolult (addig a szintig amire nekünk szükségünk van)...
De ezek az általad írt apróságok között azért van érdekes...
A programot tehát nem kell elküldeni az APEH-nek hogy vizsgálják be stb., mert azért az picit vicces lett volna. És ha jól értelmezem a példányokat is tárolhatja a szerver PDF-ben, csak ne legyen a programból lehetőség arra hogy újból kinyomtatás.

Egy ilyen nyilatkozatra viszont kiváncsi lennék, ha valaki tud, küldjön egy mintát. (mozsaf kukac impressive pont hu). Köszi

Ha az ügyfélnek digitális formában adod oda a számlát akkor kell rá digitális aláírás, hogy a program PDF-ben, XML-ben, SQL adatbázisban, TXT fájlban tárolja a számlát senkit nem érdekel.

Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"

Az első, de inkább eredeti, példányos egyszer nyomtatást pl. távközlésben nem tudom hogy eröltetik, ahol minden épkézláb számlázó cucc PDF-et generál minden számlapéldányból. Nem is opció sokszor az hogy, rögtön nyomtatni kelljen, mert akkora számlamennyiségről beszélünk (már 100 ügyfélnél is lazán 1000-1500 oldal lehet a 3 számlapéldány), amit egy menetben nem is érdemes kinyomni. Nagyobb mennyiségnél pedig egyértelműen nem a "megvesszükaszineslézert és toljuk" működik, hanem digitális nyomdának leadják és az kitolja, akár rögtön borítékban, a számlákat.

Arra a triviális esetre is gondolni kell, hogy korunk technikai fejlettségén egy szines vagy akár sima fekete fehér lézeres multifunkciós eszközzel a tényleges eredetivel teljesen összetéveszthető másolat készíthető, persze a géppel készült nyomtatott verzióból. A számlatömbözés külön műfaj.

Azt egyébként logikailag nem értem hogy mondjuk 3 darab első példány kit zavar. A számla kibocsátó a másolat (akár digitális) alapján lekönyveli a számlát és keletkezik fizetendő áfája. A befogadó pedig az első példány alapján könyveli ugye és áfa visszaigénylése keletkezik. Mivel mindkét fél baromira egyértelműen szerepel a számlán, ezért több eset nem fordulhat elő, mint a fenti. Manapság teljesen bugyuta az eredeti példány elnevezés, hacsaknem számlatömbözik az ember, mert ott tényleg van eredeti és általában két másolati példány (másolat és tőpéldány nevű).

A gépi számlánál az eredeti példánynak az adatbázisban (xml, sql akármilyen legelső forma amiben létrejött) formát kellene tekinteni szerintem. Ehhez képest minden további csak egy másolata a digitális ereditnek.

:) Idéznék a T-Mobile számlám aljáról:

"Jelen számlát a XEROX Magyarország Kft., mint titoktartásra kötelezett adatfeldolgozó nyomtatta és borítékolta az adatvédelmi törvényben előírt feltéletek szigorú betartása mellett."

Az ÁSZF-ben jó eséllyel van külön passzus erre, illetve hogy adott esetben alvállalkozónak odaadhatja (lásd még helyhez kötött szolgáltatások alvállalkozó általi telepítése).

A számlák elkészítésére gyakorlatilag a legtöbb nagy szolgáltató erre specializálódott alvállalkozót vesz igénybe, akivel megfelelő módon körülbástyázott szerződést köt, illetve a szolgáltatási szerződésbe belefoglalja ezt a kiszervezéses dolgot. Sőt, van olyan cég is, aki még a számlázást sem maga végzi, hanem kiadja gebinbe...

Számla fejlécére nem vagy köteles kiirni hogy storno vagy helyesbítő, mivel az a tartamából kiderül.

(én csak annyit írok rá, hogy számla)

bizományos számlánál is kell figyelni a dátumokra!
A számla 2. oldalán elegendő feltüntetni hogy mely számla második oldala és hogy hány oldal összesen.
pl.: xy/2008/001 2/5

De kétség kívül, elég sokmindenre oda kell figyelni..

pch

( penztar v | 2009. 03. 11., sze – 10:42 )

Hello!
Szerintem ezt a számla nyomtatási dolgot egy kicsit mindenki félre értelemezi. számla újbóli nyomtatása nem tiltott sőt. Arról van szó ,hogy eredeti példányban csak egyszer lehet nyomtatni. Minden újbóli nyomtatásnál fel kell tüntetni rajta ,hogy az eredetivel megegyező másolatról van szó. Szerintem ezt viszonylag egyszerűen lehet kezelni pl. egy jelzőbit segítségével. Az összes számlát meg szerintem fölösleges pdf-ben tárolni. Elég ha csak egy adatbázisba egy egy számla adatai megvannak és ezekből az adatokból rekonstruálható legyen a számla.Persze az elektronikus számlánál más a helyzet én elsősorban a papír alapú dolgokról beszélek.A bizonylatok sorszámozása meg minden típusú bizonylatnál kötelező külön-külön sorszámmal ellátni.Ja és még egy dolog. Én úgy tudom,hogy a program minden indításakor meg kell győzödni,hogy a bizonylatok sorszámozása folyamatos és ugrás nélküli. Ha nem így van akkor a programmal nem lehet számlázni amíg az adatbázis nincs megjavítva.
A pénztárgéppel való összekötést meg mindenki túl szokta egy kicsit misztifikálni.Ha a pc vezérli a számlázást akkor a pénztárgépet és a szoftvert is egy egységként kell az adóhivatalnál engedélyezni és továbbiakban csak abban a kiépítésben lehet használni.
Viszont ha az eladási folyamatot a pénztárgépen kezdjük és fejezzük be akkor a számlázó vagy készletező programot nem kell engedélyeztetni.A pénztárgépnek meg alapból kell apeh engedély hogy nyugta adásra lehessen használni.
Üdv.

( szekeresa | 2009. 03. 11., sze – 12:15 )

Nem reklamkent, de mi az ACTUAL ugyviteli rendszert hasznaljuk...

Kepes arra, hogy egy webes - vagy egyeb mas - rendszerbol XML formatumban atvegyen szamlazando teteleket. Igaz, hogy kezzel kell betolteni a fajlt, de igy tomegesen is keszitheto szamla, pontosan olyan tetelekkel, mint amit a kulso rendszer generalt.

A partnereket automatikusan is fel tudja venni a torzsbe az XML-bol, vagy akar frissiti is, ha ugy kerjuk. Egyszeruen lehet tomegesen nyomtatni, akar .pdf-be is, amit aztan elektronikusan is ala lehet irni.

Mi elektronikusan is szamlazunk, es ehhez viszont szukseges meg a szamla adatait tartalmazo XML fajl eloallitasa is, amit viszont sajnos nativan nem tamogat (meg). Ezt most ugy oldjuk meg, hogy kozvetlenul az ACTUAL rendszer adatait tarolo MS SQL adatbazishoz csatlakozunk, es abbol gyujtjuk le a szamla adatait. Ebbol keszitunk XML fajlt, amit a .pdf szamla melle "csomagolunk", es egyutt elektronikusan alairjuk, idobelyeggel pecseteljuk, es a weboldalunkon letolthetove tesszuk ugyfeleinknek.

1-1.5 havonta van szoftver frissites, mindenre nyitottak, nagyon keszsegesek.

Az alairast, idopecsetelest, es a .pdf-hez egyeb adatok csatolasat a Microsec Kft altal biztositott e-Szignó program segitsegevel valositjuk meg.
Van windows-os e-Szignó, es van linuxos automata alairo is. Mi a linuxos automata alirot hasznaljuk.
Ez jol parameterezheto parancssorbol. Tovabbi info itt.

Nezegettem a demo szamlakat, es a leirast is, de ahogy nezem, a demo szamlak ugyan pdf-ben vannak, de az alairas es az xml nem.

Szoval a kerdes az, hogy olyat tud, hogy az xml es az alairas konkretan a pdf formatumon belul van, es egyszaru adobe readerrel ellenorizheto is az alairas, es kinyerheto belole az xml?

(remelem sikerult ertelmesen megfogalmazni amit akarok :))

Jol latod, az e-Szigno altal generalt fajl egy .es3 kiterjesztesu fajl, ami valojaban belul egy XML fajl. Ezt beolvasva az e-szignoba, latszodik benne a .pdf, .xml fajl es az alairas. Termeszetesen nem csak ilyen tipusu allomanyokat lehet belerakni, es nem csak e-szamlazashoz lehet hasznalni, hanem barmilyen egyeb dokumentum (szerzodes, visszaigazolas, megrendeles) alairasara, idobelyegzesere is.

Visszaterve a kerdesedre, lattam mar olyan .pdf fajlt, amiben benne volt egyeb dokumentum is, es ala is volt irva. Viszont ehhez egy megfelelo verzioszamu Adobe reader is kellett (klon .pdf olvasok nem jok), hogy az alairast ellenorizni lehessen, es a csatolt dokumentumot is kinyerhetoek legyenek.

Hogy a NetLock pdfsigno-ja tudja-e az .xml fajl hozzacsatolasat, nem tudom...

Pedig remeltem hogy ez tud ilyet, valahogy egyszerubbnek tunik azt mondani vevonek, hogy friss adobereaderrel megnezheti, mint azt hogy e-signoval tudja megnezni.

Egyebkent cegeknek szoktatok e-szamlazni? Mert itt az irodaba pont azt beszelgettuk a tobbiekkel, hogy a befogadas eleg maceras lehet a cegeknek a nem fix formatum miatt, ezert inkabb csak maganszemelyeknek lehet jo az e-szamla.
Mi errol a tapasztalatotok?

Lehet, hogy egyszerubb, de nem tudod automatizalni a folyamatot... Legalabbis a jelenlegi ismereteim szerint..
Az e-szignoval viszont igen.

Cegeknek is szamlazunk, bar eloszor nehany elhuzta a szajat, de hat nalunk ez van, es elfogadtak...
A fix formatumra, mint .xml-re gondoltal? Ez akkor erdekes, - vevokent - hogy ha egy ugyviteli rendszerbe szeretned beolvasni a szamlat, es ott tarolni, mint szallitoi szamla. Egyeb esaetben figyelmen kivul hagyhatod a .pdf melle csomagolt .xml-t.

Mi ilyet irunk az e-szamla megjegyzes soraba, mint tajekoztato szoveg:

----------------------------------------------
Felhívjuk figyelmét, hogy ha ezt az elektronikus számlát kinyomtatja, akkor az csak a számla MÁSOLATA lesz! A kinyomtatott másolat segítségével lekönyvelhető/kontírozható a számla, de ez a számla csak elektronikus formában alkalmas adóigazgatási azonosításra! A digitálisan aláírt számlát, illetve az .es3-as fájlt (melyet weboldalunkról tölthet le) az elévülési idő végéig elektronikus formában szíveskedjen megőrizni (pl.:CD/DVD-re írva).

A digitális aláírás ellenőrzéséhez az ingyenesen letölthető "e-szigno" programot ajánljuk, melyet a www.e-szigno.hu oldalon tölthet le. Az elektronikus aláírás jogi és technikai hátteréről a http://srv.e-szigno.hu/menu/index.php?lap=eszamlazas címen tájékozódhat.
Tisztelt könyvelő, ha nem kapta volna meg az eredeti digitálisan aláírt számlát(.es3-as fájl), kérje el attól, akitől kapta ezt a kinyomtatott elektronikus számla másolatot!
----------------------------------------------

Tehat a gyakorlatban ez azt jelenti, hogy el kell tarolni a fajlt CD/DVD-n, es ki lehet nyomtatni a konyvelonek papir alapon a masolatot(!). Abbol konyvelhet, meg amit akar. Viszont ha APEH ellenorzes van, akkor elo lehet venni a papir alapu masolat alapjan a fajlt, es meg lehet mutatni, hogy itt van a hiteles szamla, le lehet ellenorizni.

"Lehet, hogy egyszerubb, de nem tudod automatizalni a folyamatot... Legalabbis a jelenlegi ismereteim szerint..
Az e-szignoval viszont igen."

Mar talaltam egy javas programot ami tud pdf alairast csinalni, igy az automatizalhato szerintem. Az xml pdf-hez csatolasat meg csak meg lehet valahogy oldani (vagy lehet hogy tul optimista vagyok? :))

"Felhívjuk figyelmét, hogy ha ezt az elektronikus számlát kinyomtatja, akkor az csak a számla MÁSOLATA lesz! A kinyomtatott másolat segítségével lekönyvelhető/kontírozható a számla, de ez a számla csak elektronikus formában alkalmas adóigazgatási azonosításra!"

Ennek a valosagtartalmaban mennyire vagy biztos? Mert amit eddig olvastam a temaban az alapjan a e-szamlat csak elektronikusan lehet kontirozni, de lehet hogy ezt felreertettem. Mert ugy ha nem igy lenne, akkor nem kellene miert huzza a szajat a befogado, mert akkor tokmindegy neki, de szerintem emiatt pont nem jo a dolog.

Ha van, akkor OK. Csak ha nem tudsz melle .xml-t adni, akkor feleslegesen dolgozol vele...

Ez az infom van a befogadasrol:

Az elektronikus számla befogadójának feladatai

  • Ha a számla befogadója nem köteles megőrizni a számlát (pl. magánszemély), akkor semmilyen teendője nincs az elektronikus számlával.
  • Ha a számla befogadója számlamegőrzésre kötelezett, akkor az alábbiakban leírtak szerint kell megőriznie a számlát. Az elektronikus számlához kapcsolódó kontíradatokat az APEH közlemény szerint egyértelmű hozzárendeléssel, elválaszthatatlan módon, az utólagos módosítás lehetőségét kizárva kell csatolni a számlához. A közlemény szerint a csatolás részletes technikai kérdéseit (azon belül is kiemelten a hitelesség és a felelősség kérdését) a gazdálkodónak kell szabályoznia, a belső működési rendjében. Egyes vélekedések szerint ezt legalább fokozott biztonságú elektronikus aláírással és minősített időbélyegzővel kell teljesíteni, de feltehetően más elfogadható megoldások is léteznek.

Ami az erdekes azok az utolso mondatok..
"A gazdálkodónak kell szabályoznia, a belső működési rendjében", hogy hogyan keruljon konyvelesre.
Mi egy olyan szabalyozast alkalmazunk, hogy a papir alapu masolatot hasznaljuk fel a kontirozasra, es ha szukseges az eredeti szamla, akkor ott a fajl. Ez le van papirozva a belso mukodesi rendunkben, es ennyi. A torveny sem irja le, hogy mi a technikai megvalositas folyamata...

Meg valami..

Igaz, hogy ekkor nem valosul meg az igazi elektronikus megoldas elonye, hiszen a papir alapu masolatot is tarolni kell, de ahol meg nincs lehetoseg a kontir informacio elektronikus csatolasara, ott ez a papir alapu is bevalhat. Persze erre nem vallalunk felelosseget, de nem kaptunk vissza panaszt a partnerektol, akik az e-szamlanka befogadtak, es APEH ellenorzesen is atesetek... Szoval a mi megoldasunk nem szentiras, mi ezt igy ertelmeztuk a torveny szovegebol...

Aki esetleg "Távszámlázik" az nézze meg a t-mobile új elektronikus számláját.
Egy sima pdf nincs benne semmilyen csatolmány, hanem maga a pdf van aláírva, mert hogy a pdf már rég óta tud ilyet. Bal oldalon egy toll meg egy kis papír ikon jelenik meg ilyenkor, és rábökve közli, hogy ez egy hiteles dokumentum, és xy írta alá digitálisan.
Ezt meg is találtam az Adobe oldalán egy doksiban, lehet fejlesztőkörnyezetet is letölteni..stb..
De tegnap találtam egy ilyet is, hátha ez jobb, vagy egyszerűbb, én még nem néztem meg közelebbről:
http://itextpdf.sourceforge.net/

Az apeh-os xml-es aláírás csak egy ajánlás, egy módja a megvalósításnak, a lényeg, hogy digitálisan kell oly módon aláírni a dokumentumot, hogy azt később ne lehessen megváltoztatni.
Én az ilyen különféle speciálsi programokkal megvalósított megoldásokat nem kedvelem, mert akkor még magyarázgassam az ügyfeleknek, hogy a számlát meg akarja nézni, akkor telepítsen mindenféle windóózos trutyit, hát nem túl életszerű.
Acrobat Reader minden gépen, és oprenceren van, a pdf a legszimpatikusabb, és ha abban van az aláírás, és ennek ellenőrzését maga a reader végzi.

szia, van rá megoldás:

hitelesítés: pdfsigno (van linux parancssori verziója, tud batch feldolgozást is)
pdf generálás: PDFlib (http://www.pdflib.com)

folyamat:

számlaadatok alapján legenerálod a pdf fájlt, majd csatolod hozzá az apeh xml-t, ami így "csatolt fájlként" bekerül a pdf-be (readerben baloldalt alul a gemkapocs ikonra kattintva jelenik meg, PDFlib tud ilyet, ld. lejjebb). Ezután elküldöd hitelesítésre és időbélyegzésre a pdfsignonak és mivel az apeh-nek ellenőrzéskor az xml fog kelleni, annak sérthetetlensége így biztosítva van, mivel ilyenkor már beágyaztad a pdf-be.

az 1.3-as pdf referenciában a 8.4 Annotations fejezet szól a fájl csatolásról, a PDFlib doksijában a "create annotation" -re kell keresni. lényeg, hogy fájl típusú annotation-t kell csatolni a pdf-hez, valahogy így:

$p->create_annotation(20, 10, 30, 25, "FileAttachment", "contents={APEH XML séma} filename={apeh.xml} mimetype=text/xml iconname=paperclip annotcolor={rgb 0 0 0} display=noprint opacity=1 subject={APEH XML séma} title={APEH XML séma} readonly=true locked=true");

ahol $p a pdflib objektum.

a fenti hívás a lap bal alsó sarkába (a koordinátákból látszik) rak egy ikont, ami nyomtatáskor nem látszik (noprint)

kb ennyi. ja igen a pdflib-nek van free változata, ami egy csomó jó dolgot nem tud a fizetőshöz képest, de szerencsére a create_annotation benne van. viszont a licence-t meg kell nézned mert azzal lehetnek gubancok, egyébként a pdf "Producer" property-jébe belerakja a free version feliratot (ezt a property-t csak a fizetős változattal lehet módosítani), igaz, a pdfsigno ezt felülírja.

még valami: adobe reader 8-9-es verziója biztosan jól kezeli a csatolt fájlt és a hitelesítő infókat, de úgy rémlik, a 7-es is megmutatta. ezt azért meg lehet követelni az ügyféltől.

remélem tudtam segíteni valamennyit.

üdv

( penztar v | 2009. 03. 11., sze – 16:56 )

Hello akik a pc-t össze akarják kötni a pénztárgéppel azoknak ajánlom a figyelmébe különösen a 3.3 pontot . De van egy másik megoldás amikor nem kell a programot külön engedélyeztetni.Ilyenkor a dolog röviden úgy működik ,hogy a pénztárgépet használó beviszi az áru cikkszámát vagy vonalkódját a pénztárgépbe.Ezután a pénztárgép lekérdezi a cikkszám v. vonalkód alapján a pc-n futó program adatbázisából a termék árát,nevét,áfa kulcsát majd visszalöki a pénztárgépnek. Ezután a használó vagy újjabb tételt visz fel vagy lefizetteti a nyugtát.Ezt a módszert az én szakmámban hívtuk úgy hogy on-line kapcsolat. A régi megoldás volt az off-line ,mert ott annyi történt hogy a számlázó programmal az ember előállította a számlát és csak át lökte a tételsorokat és kész volt a nyugta. Ennél a módnál kell mindent le engedélyezni és utána csak abban a kiépítésben szabad használni.
Van néhány szoftver ami az első megoldást használja és korrektül működik,viszont jóval kevesebb pénztárgép van ami ezt a fajta kapcsolatot ismeri. Azon kívül a második módot ismerő gépek túlnyomó része már kezd kikopni a forgalomból és manapság újként nem nagyon szokta az adóhivatal szeretni ezt kommunikációs megoldást,mert nem titkolt célja bár nincs kimondva ,hogy a jövőben szeretnék a számítógép alapú pénztárgépeket előnybe részesíteni. Már csak azért sem mert az engedélyező bizottságban csupa olyan személy ül akik valamelyik nagy magyar informatikai vállalathoz "közel" állnak és szakértenek ebben a kérdésben.
Ha esetleg evvel kapcsolatban érdekelnek valakit infók szívesen segítek ,mert kb. 10 évig ezt csináltam.
Üdv.

Erre az online kapcsolatra tudsz esetleg engedélyezett pénztárgép-típust?

Régebben lett volna egy projektünk ilyen témában, de ezt a módot az APEH-nél meg sem említették, így aztán dobtuk az egészet.
A másik elv, ahol együtt kell az egészet engedélyeztetni, egy totál zsákutca. Még egy javítást sem lehet engedély nélkül használni, nemhogy fejleszteni a programot.

Erre az online kapcsolatra tudsz esetleg engedélyezett pénztárgép-típust?
Hello!

Hát persze ,hogy tudok. Sam4s-420M . Ez a gép még ha jól tudom engedélyes és elvileg elég jól használható ilyen célokra,mert több számlázó program készítő cég is használja. De ha ez nem tetszik akkor a Fasy gépcsalád is tud ilyen módom kommunikálni,de ezeket meg kell nézni pontosan mert valamelyik már új gépként nem kapható.
Üdv.

( Kayapo | 2009. 03. 12., cs – 10:27 )

Mivel aszisztáltam már ilyen program választásánál ezért van néhány tapasztalatom, a következők:
1. Kérd ki adó szakértő véleményét!!!
2. Kérd ki adó szakértő véleményét!!!

3. Az APEH általi "bevizsgálás" certific -álás igen sok pénzbe kerül ~500-700 kFt, és olyan feltételeket követel amit nagyon kevesen akarnak/tudnak biztosítani. Lényegében azt írja elő, hogy az adatokhoz, semmilyen software -es, vagy hardware -es úton ne lehessen hozzáférni (titkosított adattárolás, plombával védett disk és ház) meg hasonló ökörségek (ezek természetesen a hardware, ill. software környezet karbantartását is kizárják).
4. Ahogy azt más is írta előttem, ez nem kötelező, elegendő, ha a program az adó törvény(ek)ben előírtakat szolgáltatja. A számlának az adattartalma szintén megfelel az adótörvény(ek)nek és ezt a program készítője (készítői) írásos nyilatkozatban rögzítik. (Érdemes ezt a nyilatkozatot valamelyík tulajdonosnak tennie és papíron neki kell lennie - értelem szerint - a program készítőjének.
5. A programnak biztosítania kell, hogy a számla első kinyomtatásakor elkészüljön a szükséges példányszámban a számla, ezután csak számla másolat készülhessen, melyen fel van tüntetve, hogy másolat. A számláknak valamilyen logika szerint folyamatos sorszámozásúnak kell lennie és sorszám nem ismétlődhet.
6. Lehessen számlát sztornírozni (visszavonni), de a visszavont számla száma újra nem kerülhet kiadásra.
7. Minden nyomtatott dokumentumnak (bevételi számla, szállítólevél, raktár bevételi, kiadási bizonylat, készpénz fizetési, vagy átutalásos számla, visszavonó (storno) számla) egyedi számlaszámmal készüljön, melyek nem ismétlődhetnek
8. Mindenképpen el kell készíteni a program felhasználói dokumentációját (ezt is ellenőrzi az APEH ellenőrzés alkalmával), ezt szintén érdemes adószakértővel véleményeztetni (mivel ez alapján APEH ellenőrzés alkalmával, fog az ellenőrzést végző vizsgálódni)
9. A papír alapú számlát feltétlen meg kell őrizni (sajnos)

Nagyjábol ennyi, ha még valami eszembe jut ide írom

----
Nyicc-egy-csört?

( mozsaf | 2009. 03. 28., szo – 18:49 )

Valaki küld nekem egy ilyen APEh -os nyilatkozatot? Köszi

( lorinczi v | 2009. 05. 20., sze – 12:19 )

Nincs semmiféle bevizsgálás,(csak a saját cégem használja, nincs eladva) már 8 éve használják a programomat, tucatnyi APEH ellenőrzés volt a cégnél. Ha valami balhé van akkor vizsgálják meg (gondolom szakértőkkel) a szigorú számozást, egyébként a papír kinyomtatott forma a szent számukra, a pdf nagyon jó, mert számlamásolatot bárki, bármikor kérhet.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.