Számlázóprogram interfésszel

Iroda

üdv,

tud valaki olyan (apeh engedélyes) számlázóprogramról, ami valamilyen módon tud külsö adatokból számlákat csinálni? CSV vagy más file beolvasása, esetleg import interfésszel bővíthető is jó (pl. a progi kapcsolódik valami WEB service-hez és úgy veszi a szla adatait).

  • 3790 megtekintés

( arpi_esp v | 2006. 07. 04., k – 08:49 )

Sajnos nem tudok, de nekem is nagyon kene... ha talalsz valamit, szolj!

A'rpi

( btami v | 2006. 07. 04., k – 10:42 )

Többször volt már róla szó, hogy egy számlázóprogramhoz _nem kell_ apeh engedély.

Jaja, egy nyilatkozat kell a program készítőtől/eladótól, hogy megfelel az apeh előírásainak.

A Számadó free verziója eléggé átlátható db-vel rendelkezik, szerintem lehet hozzá hackolni importot, de az már szerintem nem lesz megfelelő az apeh előírásainak, ne tudjon róla... :D

( pete | 2006. 07. 04., k – 20:04 )

udv, es kosz a hozzaszolasokat. A lenyege a dolognak annyi, hogy keszitek egy szoftvert, aminek kereskedelmi funkcioja van, es egy rendeleshez kell szamlat gyartani.

Ertem, tudom hogy nem kell a szla-hoz apeh engedely, de a szamlakeszito programnak sok feltetelnek kell megfelelni es folyamatosan kovetni kell a jogszabaly valtozasait, ami nem fer bele ebbe a projektbe. Ezert keresek kulso megoldast.

A szamla elkeszitesen tul meg szempont az is, hogy amennyire lehet, automatikus legyen a kommunikacio a szamlakeszito rendszer es a masik kozott. A kommunikacionak valahogy igy kell kineznie, ebbol a leheto legtobb fazisnak kellene automatikusnak lennie:

* a kereskedelmi program (K) elkuldi a szla programnak (S) egy rendeles tetelenkenti adatait (termeknev, azonositasi adatok, netto ar, afakulcs)

* S visszajelez, hogy megvan az adat, szerinte helyes, szla kiallitasra felvette, a szla azonositoja X.

* S visszajelez, hogy stornoztak egy adott rendeles szamlajat.

Az aruforgalmi program megrendelesre keszul, nem szabad szoftver, de az erte kapott penzbol rendszeresen jut free projektekre is (Tegla, HUP vas, SFD, stb.)

Ha jól sejtem, akkor számvitelileg hibás az elképzelésed, pontosabban beleütközhetsz egy-két nagyon durva problémába, tehát figyelj a következőre:

(K) egy ügyviteli program, (S) viszont meg kell hogy feleljen a hatályos számviteli- és adótörvényeknek, -rendeleteknek, ezért:

Szla. létrehozása:
- (K) megkéri (S)-t, hogy hozzon létre egy új számlát
(S) visszaad egy ideiglenes azonosítót (nem generálhatod azonnal a számlasorszámot!)
- (K) egyesével átadja a tételeket. A tételes adatok között a következőknek kell szerepelnie (és lehetőleg másnak nem): VTSZ/SZJ-kód, megnevezés (annyi megjegyzéssel és egyébbel, amennyit csak akarsz), mennyiségi egység, mennyiség, nettó egységár
- (S) egyetlen dolgot tud ellenőrizni: a kapott VTSZ/SZJ kód szerepel-e az adatbázisában. Ha nem, akkor a tétel hibás.
- (K) Valamilyen módon átadja (S)-nek a vevő adatait. (ez a lépés elvileg bármikor megléphető)

Szla. kiállítása:
- (K) vagy (S) utasítja (S)-t, hogy nyomtassa ki a számlát. (az ideiglenes azonosító alapján)
- (S) kiszámítja az áfákat (VTSZ/SZJ alapján), a számla végösszegét, generál egy számlasorszámot, majd kinyomtatja a számlát. (Fontos: le _kell_ tárolni a kiszámított sorokat, egy számla utólagos lekérdezésekor már semilyen számítás nem végezhető rajta!)

Szla. sztornózása:
- Csak olyan számlát törölhetsz nyomtalanul, ami még nem lett kinyomtatva. Minden egyéb esetben sztornószámlát kell a rendszernek kiállítania, az eredeti számla "negálásával".

És hogy miért is ez a követendő módszer:
- Ha előbb generálsz számlasorszámot, mint nyomtatod, akkor előfordulhat, hogy a sorszámok nem időrendben követik egymást.
- Ha (S) kezeli az áfakulcsokat, akkor rengeteg (K)-t írhatsz, anélkül, hogy áfakulcs-módosításkor mindegyik adatbázisát javítanod kéne. (Magyarán: felvállalható az ügyfél felé az áfakulcsok karbantartása csak (S) módosításával.)

Végül: nem tárolhatod több számlakibocsátó számláit egy táblában (sőt, lehet, hogy egy adatbázisban sem). (Most meg nem mondom, hogy ez hol van törvényileg szabályozva.)

Ezt a sok dolgot, honnan vetted?

"- (K) egyesével átadja a tételeket. A tételes adatok között a következőknek kell szerepelnie (és lehetőleg másnak nem): VTSZ/SZJ-kód, megnevezés (annyi megjegyzéssel és egyébbel, amennyit csak akarsz), mennyiségi egység, mennyiség, nettó egységár"
Az Áfakulcs kimaradt, egyébként pedig a számlán bármi szerepelhet, csak minimum megkötés van.

"(Fontos: le _kell_ tárolni a kiszámított sorokat, egy számla utólagos lekérdezésekor már semilyen számítás nem végezhető rajta!)"
Ezt ki mondja, az 1 + 1 holnap is 2 lesz. Lehet nem célszerű, nem hatékony, de nem előírás.

"És hogy miért is ez a követendő módszer:
- Ha előbb generálsz számlasorszámot, mint nyomtatod, akkor előfordulhat, hogy a sorszámok nem időrendben követik egymást."
Ez így nem igaz, a lényeg, hogy a számlát kiállító által beállított számla kelt és számla sorszám alapján folytonos legyen (nem a nyomtatás dátuma a lényeg (egyáltalán mi a nyomtatási idő, a helyi idő?), hanem a számlán szereplő kelt)

"Végül: nem tárolhatod több számlakibocsátó számláit egy táblában (sőt, lehet, hogy egy adatbázisban sem). (Most meg nem mondom, hogy ez hol van törvényileg szabályozva.)"
Ez végképen nem igaz, egy vállalatirányítási szoftverben elég csúnya lenne, ha nem tudna egyszerre több céget kezelni.

Egyébként az általad leírt dolgok többsége technikai probléma, az APEH-et nem érdekli, hogy hogyan oldod meg az általa előírtakat, a lényeg hogy azoknak megfeleljen a számla.
A technikai problémára megoldást jelenthet (adatbázis tervezés, primary key, foreign key, tranzakció kezelés, generatorok, ...)

( pentike | 2006. 07. 04., k – 22:55 )

Nem pont ez, de végülis kapcsolódik hozzá:

Hol lehet megtudni, hogy milyen feltételeket kell teljesíteni? Mármint egy számlázó programnak.

1) termékeket, vevőket, rendeléseket lekéri a webáruházból, tehát a számlázóba ezeket az adatokat nem kell felvinnem (joomla virtuemart és/vagy drupal übercart)
2) böngészőben futtatható (legalább távoli asztalon, vnc)
3) linux alapú (legalább wine alatt fut)
4) ingyenes
(5) nyílt forrású?)

Huh, akkor valamit benéztem, mégegyszer nekifutok a weboldalnak, de minta csak egy exe telepítőt láttam volna.

Az rendben, hogy a kliens böngészőben dolgozik, de az adatbázis, szerveralkalmazás, amihez a kliens kapcsolódik az hol fut?

Szerk: A FAQ alapján az jött le, hogy teljesen windows alapú a szerver rész :(

( MGy v | 2009. 01. 15., cs – 15:44 )

A CobraConto+ tud ilyet, de minden más informatikai (a könyvelési szempontokat nem ismerem) szempontból borzalom.