Kapcsolódó információk:
› Paraméterezési útmutatók
Korábbi változatok
Qsboxmegjegyz |
---|
Ugyanez angolul megtalálható a Format for Entries Booked to the Ledger c. fejezetben. |
Az SUP® Integrált Számviteli Rendszerbe az adatokat nem csak billentyűzetről, hanem számítástechnikai úton, ún. adatátadással is be lehet vinni. A rendszer szempontjából indifferens, hogy az adatok milyen alrendszerből származnak (pénzügy, számlázás, tárgyi eszköz, készlet nyilvántartás, bér, stb.). Lényeges viszont, hogy az alrendszerek által átadott adatok megfeleljenek bizonyos követelményeknek. A különböző alrendszerek mindegyike (számlázás, készlet, bér, stb.) számára egy közös adatformátum van, csupán az adatok kitöltési szabályai változnak.
Qsboxmegjegyz |
---|
Ugyanez angolul megtalálható a Format for Entries Booked to the Ledger c. fejezetben. |
- Az adatállomány formátuma
A később ismertetésre kerülő adatstruktúrának megfelelő XML, dBase típusú (DBF), vagy CSV text, vagy XLS Excel (97-2003) fizikai formátumú állomány.
Az adatok sorrendje: naplószám - bizonylatszám - bizonylat tételsorszám..
Qsboxmegjegyz |
---|
Az elvárt XML struktúra részletes leírása a Főkönyvi feladás adatállomány XML formátuma útmutatóban olvasható. |
Qsboxmegjegyz | ||||||
---|---|---|---|---|---|---|
|
- Az adatállomány helye
Az átadás adatállományát a rendszerparaméterekkel beállított nevű alkönyvtárba kell elhelyezni.
Az adatállomány neve
Rendszerben
Az átadás adatállomány neve: ATADAS.DBF , ill. ATADAS.CSV . Lehetőség van a hosszú file-nevek használatára, így pl. egy havi rendszerességű feladás esetén a hónap számát is bele lehet kombinálni a file nevébe. Pl.: ATADAS_02.CSV
Amennyiben az "Átadás file neve cégkóddal" nevű rendszerparaméter Igen értékre van állítva, a file nevének kötelezően tartalmaznia kell a SUP®rendszerben nyilvántartott cégkódot. Pl.: ATADAS_XCEG.CSV
Qsboxfigyelem A file nevében a cégkódot pontosan a SUP® rendszerben tárolt módon, azaz csupa NAGYBETŰVEL kell megadni.
- Az adatállomány kódlapja
A Win1250 vagy az OEM-852 (DOS) kódlap. Mivel a leggyakoribb eset kimenő/beérkező számlák főkönyvi feladása, ezért az „Egyéb információ” mezőben ehhez lehet további információkat találni.
Az adatállomány szerkezete
...
Qsboxmegjegyz |
---|
A dBase formátum esetén a nem kötelező mezők üresen hagyhatóak. CSV formátum esetén a nem kötelezőnek megjelölt mezőket is létre kell hozni az átadás file-ban. Ez azt jelenti, hogy a CSV header-ben szerepelnie kell a mezőnévnek, ill. a rekordokban üres mezőként át kell adni. ( ” ”, ) |
Sr. | Mezőnév | Típ. | Hossz. | Tz. | Magyarázat / Egyéb információ |
---|---|---|---|---|---|
1. | NAPLOSZ | C | 3 |
A könyvelési napló azonosító kódja igazodva a felhasználó által meghatározott naplószámokhoz (kötelező, teljes hosszban kitöltendő) |
Ahány sorszám-tartományon megy a kiszámlázás a számlázó rendszerben, annyi külön naplóban kell átadni a SUP-nak. | |||||
2. | KDATUM | C | 10 |
A bizonylat számviteli időszaka (kötelező, éééé.hh.nn formátumban) |
Számlák esetén a számla teljesítési időpontja szerinti hónap utolsó napja. | |||||
3. | AFADATUM | C | 10 |
A bizonylat ÁFA időszaka (Az ÁFA kigyűjtés alapja) speciális, a mező opcionális - minden más mező esetén az üres adatmezőket is létre kell hozni. Ha nincs ilyen mező, akkor a KDATUM kerül bele automatikusan. (éééé.hh.nn formátumban) |
Számlák esetén a számla teljesítési időpontja szerinti hónap utolsó napja. Egyéb bizonylat esetén megegyezik a KDATUM tartalmával. | |||||
4. | BIZSZAM | C | 12 |
A könyvelési bizonylat száma (balra igazítva, naplónként egyedi) (kötelező) |
Kimenő számlák esetén a számla sorszáma, beérkező számlák esetén évente újrainduló folyamatos sorszám előnullázva az éves összes várható beérkező számlaszámhoz igazodva. | |||||
5. | BIZSOR | C |
4 | Egy bizonylaton belüli tételsorszám (előnullázott) (kötelező, teljes hosszban kitöltendő) |
Az azonos kimenő számlához tartozó összevont kontírsorok sorszáma előnullázva. Pl.: 001, 002, 003, stb. | |||||
6. | KELT | C | 10 |
A bizonylat kelte (kötelező, éééé.hh.nn formátumban) |
7. | TELJIDO | C | 10 |
Teljesítés időpontja (nem kötelező, éééé.hh.nn formátumban) |
8. | HATIDO | C | 10 |
Fizetési határidő (nem kötelező, számláknál kell megadni éééé.hh.nn formátumban) |
9. | FOKSZLA | C | 10 |
Főkönyvi szám (kötelező, balra igazítva) |
Kimenő számlák esetén az árbevétel oldal (pl.: 911) Beérkező számlák esetén a költség oldal (pl.: 511) | |||||
10. | FOLYSZLA | C | 11 |
Folyószámla szám (nem kötelező) |
Kimenő és beérkező számlák esetén ÜRES. A folyószámlaszámot (partnerkódot) NEM itt kell megadni. Kivétel amennyiben vegyes tételként kerül feladásra részletező számla . | |||||
11. | SZLAMEGN | C |
50 | A főkönyvi szám megnevezése (nem kötelező) |
Számlák feladásánál üres | |||||
12. | TKJELLEG | C | 1 |
Tartozik / Követel jelleg a FOKSZLA mező adattartalmára vonatkoztatva (nagy T/K betű) (kötelező) |
Kimenő számla esetén: „K”. Jóváíró vagy helyesbítő számla esetén: „T” A negatív számla kontírozása pozitív értékkel ( ERTEK mező) és mindig a TKJELLEG mező T/K értékének cseréjével történik. | |||||
13. | ESEMENY | C |
60 | A könyvelési esemény szöveges leírása (nem kötelező, de nem illik üresen hagyni) |
Az adott cég határozza meg, mit szeretne itt látni. | |||||
14. | ERTEK | N | 13 | 2 | A bizonylat tételsorának nettó forint értéke (kötelező, csak pozitív szám lehet) |
15. | AFAKOD | C | 4 |
Az ÁFA kulcs kódja (ÁFÁ-t tartalmazó tétel esetén kötelező, kódolás a fogadó adatbázisban meghatározott kódoknak megfelelően). A szokásos kódolás: 0 - 5 % 1 - |
18% 2 - |
27% 5 - ÁFA mentes |
Számlák esetén meg kell adni az adott cég által a SUP-ban beállított kódok szerint. | |||||
16. | AFAFOKSZ | C | 10 |
Az ÁFA főkönyvi szám (csak akkor kötelező, ha az ÁFA kód ki van töltve, balra igazítva) |
Számlák esetén kötelező. | |||||
17. | AFAERTEK | N | 13 | 2 | A bizonylat tételsorának ÁFA értéke (az érték, és az ÁFA kód alapján) (nem kötelező, csak pozitív szám lehet) |
18. | ERT2 | N | 13 | 2 | A bizonylat bruttó értéke devizában (nem kötelező, csak pozitív szám lehet) |
19. | ERT2KOD | C | 3 |
A bizonylat devizanem kódja (devizás tételek esetén kötelező, a devizanemek ISO kódolása szerint) |
20. | RENDSZAM | C |
30 | Rendezési szám (a folyószámla rendezés erre párosít) (nem kötelező, számláknál a számlaszám, balra igazítva) |
. Storno, helyesbítő, valamint előleg számlák esetén csak az XML formátum használatával lehet visszahivatkozni. | |||||
Kimenő és beérkező számlák esetén az elkészült/kapott számla sorszáma (számlaszám). Tehát kimenő számlák esetén azonos a BIZSZAM mezővel. | |||||
21 | FIZMOD | C | 1 |
Fizetési mód (nem kötelező, a rendszer belső kódolásának megfelelően) 0 – Készpénz 4 – Átutalás |
22. | FOKESZLA | C | 10 |
A megadott főkönyvi szám ellenszámlája (balra igazítva) |
Kimenő számlák esetén a folyószámlás oldal (pl.: 3111 Beérkező számlák esetén a folyószámlás oldal (pl.: 4541) | |||||
23. | FOLYESZ | C | 11 |
A megadott főkönyvi ellenszámlaszám folyószámla ellenszámlája (nem kötelező, balra igazítva) |
Kimenő és beérkező számlák folyószámlaszámát (partnerkódját) itt kell megadni. A feladáshoz célszerű a küldő ás fogadó rendszerben ugyanazt a partnerkód kiosztást használni. | |||||
24. | ELLMEGN | C |
50 | Az főkönyvi ellenszámla, vagy folyószámla ellenszámla megnevezése (nem kötelező, csak ha folyószámla ellenszámla is meg van adva) |
Kimenő és beérkező számlák esetén be kell írni a partner nevét, hogy a rendszer az új partnereket meg tudja nyitni. Alapesetben az ismeretlen partnerkódok alapján új partnertörzs rekord kerül felvételre. Ez a lehetőség kikapcsolható a Szerviz | Technikai funkciók | Rendszerinformációk | Általános beállítások menüpontban. | |||||
25. | ANCSOP1 | C | 4 |
1. gyűjtőcsoport kódja (nem kötelező) |
Amennyiben költséghely, munkaszám, vagy egyéb gyűjtési szempontokat is szerepeltetni kell a feladásban, az ANCSOPx mező(ke)t a fogadó rendszerben beállított konstans értékkel, az ANALITx mező(ke)t az adott költséghely, munkaszám, stb. kódjával, az ANxNEV mezőket pedig az adott költséghely, munkaszám, stb. nevével kell feltölteni. A gyűjtő csoportok és gyűjtő azonosítók megadásánál a könyvelt cég által használt adatokat kell átadni a SUP-ba. | |||||
26. | ANCSOP2 | C | 4 |
2. gyűjtőcsoport kódja (nem kötelező) |
27. | ANCSOP3 | C | 4 |
3. gyűjtőcsoport kódja (nem kötelező) |
28. | ANCSOP4 | C | 4 |
4. gyűjtőcsoport kódja (nem kötelező) |
29. | ANALIT1 | C | 12 |
1. gyűjtő azonosító (nem kötelező) |
30. | ANALIT2 | C | 12 |
2. gyűjtő azonosító (nem kötelező) |
31. | ANALIT3 | C | 12 |
3. gyűjtő azonosító (nem kötelező) |
32. | ANALIT4 | C | 12 |
4. gyűjtő azonosító (nem kötelező) |
33. | AN1ERT2 | N | 13 | 2 | 1. gyűjtő azonosító második értéke (nem használt, kompatibilitási okok miatt fenntartva) |
34. | AN2ERT2 | N | 13 | 2 | 2. gyűjtő azonosító második értéke (nem használt, kompatibilitási okok miatt fenntartva) |
35. | AN3ERT2 | N | 13 | 2 | 3. gyűjtő azonosító második értéke (nem használt, kompatibilitási okok miatt fenntartva) |
36. | AN4ERT2 | N | 13 | 2 | 4. gyűjtő azonosító második értéke (nem használt, kompatibilitási okok miatt fenntartva) |
37. | AN1KOD2 | C | 2 |
1. gyűjtő második értékének kódja (nem használt, kompatibilitási okok miatt fenntartva) |
38. | AN2KOD2 | C | 2 |
2. gyűjtő második értékének kódja (nem használt, kompatibilitási okok miatt fenntartva) |
39. | AN3KOD2 | C | 2 |
3. gyűjtő második értékének kódja (nem használt, kompatibilitási okok miatt fenntartva) |
40. | AN4KOD2 | C | 2 |
4. gyűjtő második értékének kódja (nem használt, kompatibilitási okok miatt fenntartva) |
41. | AN1NEV | C |
40 | 1. gyűjtő azonosító megnevezése (nem kötelező) |
42. | AN2NEV | C |
40 | 2. gyűjtő azonosító megnevezése (nem kötelező) |
43. | AN3NEV | C |
40 | 3. gyűjtő azonosító megnevezése (nem kötelező) |
44. | AN4NEV | C |
40 | 4. gyűjtő azonosító megnevezése (nem kötelező) |
Oldal szerepeltetése |
---|
...
|
Főkönyvi feladás megvalósítása számlázási alrendszer esetén
A főkönyvi feladást leggyakrabban valamilyen speciális igények szerint kialakított számlázási rendszerből kell megvalósítani, tehát az értékesítéssel vagy szolgáltatással kapcsolatos vevői számlák elkészülnek egy számlázó rendszerben, és ezek feladásra kerülnek a kapcsolódó SUP® Integrált Számviteli Rendszer (továbbiakban SUP) felé.
Lényeges információ, hogy a számlázási feladás esetén nem kell ún. kétoldalas könyvelési bizonylatokat képezni. A kétoldalasságot a rendszer automatikusan biztosítja.
A feladással (fogadhatósággal) kapcsolatos jellemző problémák, követelmények
NAPLOSZ mező (könyvelési napló)
Három jegyű azonosító kód, mely a számviteli rendszerben a bizonylatok csoportosítására szolgál. Számlatípusonként (számlasorszám-tartományonként) külön naplót kell használni.
Célszerű egy ún. .INI paramétert létrehozni rá.
KDATUM és AFADATUM mező (könyvelési és ÁFA időszakok)
Normál esetben a számla teljesítési időpontja szerinti hónap utolsó napja. A két időszak használatával (az ÁFA időszak opcionális) külön lehet választani a az eltérő számviteli ill ÁFA időszakba könyvelendő tételeket.
Figyelni kell azonban arra, hogy egyik sem mehet ki az adott üzleti évből. Az év végi számlázásnál, ha a teljesítés már a következő üzleti évre vonatkozik, akkor az adott üzleti év utolsó napját kell beletenni. Az éve eleji kibocsájtású, még az előző üzleti évre vonatkozó teljesítésű számlák esetén a kibocsájtás dátuma szerinti üzleti év első napját kell beletenni.
FOKSZLA mező (főkönyvi szám)
Az árbevétel főkönyvi számot(-okat) tartalmazza. Az árbevétel-számlák a cég által támasztott információs igényektől függnek. Leggyakrabban bizonyos cikkcsoportosítással függenek össze.
Külföldre irányuló számlázás esetén gondoskodni kell arról, hogy a belföldi és külföldi értékesítések külön árbevétel-számlára kerüljenek. Bizonyos cégeknél pedig az EU-n belüli, ill. kívüli árbevételek is külön főkönyvi számra kell, hogy kerüljenek.
Jellemzően a cikket, vagy cikkcsoportot kell ellátni legalább egy árbevétel főkönyvi szám paraméterrel. Nagyon egyszerű könyvelést végző cég esetén minden értékesítés egy árbevétel számlára megy. Ez esetben .INI paraméterként is implementálható.
Az előlegszámlákat speciálisan kell kezelni, erről külön egyeztetés szükséges.
FOKESZLA mező (főkönyvi ellenszámla)
Itt az ún. folyószámlás oldalt kell meghatározni.(311)
Általában számlatípusonként (számlasorszám-tartományonként) külön folyószámlás főkönyvi számot szokás használni. A devizás értékesítést szintén külön főkönyvi számra kell tenni.
FOLYESZ mező (partnerkód)
Az adatkapcsolat kialakíthatósága szempontjából az egyik legjelentősebb probléma a partnertörzs kezelés (partnerkódok) szinkronizálása. Ugyan a SUP-ban lehetőség van ún. külső rendszerben tárolt partnerkódok kezelésére és automatikus transzformációjára is, de a legcélszerűbb mégis a két rendszer partnerkódjainak „közös kódra hozása”. Ez a SUP-ban utólagosan is megtehető, mivel a partnerkódok utólagosan is módosíthatóak, tehát „rá lehet állni” a küldő rendszerben használt kódokra. A küldő rendszernek a partnerkód mellett át kell adnia a partner nevét (ELLMEGN mező), mivel az új vevők alapvetően a számlázási rendszerben keletkeznek.
Az ún. készpénzes számlákat elvileg kétféle módszerrel is át lehet adni, az ajánlott módszer az átutalásos számlákkal meggyező ún. folyószámlás kezelési mód. Ettől eltérni csak különösen nagy tömegű készpénzes számla esetén célszerű.
Költséghelyek, munkaszámok és egyéb gyűjtők
A cég információs igényeitől függően szokták használni. (Ilyenek pl. költséghely, dolgozó, üzletkötő, munkaszám, kötésszám, termékkód, stb.) A SUP-ban a főkönyvi számnál beállított dimenzió határozza meg a használni kívánt gyűjtő indexét (ANALCSx mező). Amennyiben erre szükség van, külön egyeztetés szükséges.
Kerekítési problémák
A többféle ÁFA kulcsot ill. többféle főkönyvi számot tartalmazó bizonylatokat annyi tételsorban kell feladni, ahányféle ÁFA kulcsot ill. főkönyvi számot tartalmaznak. Tehát pl.: egy olyan 20 tételsoros számla, mely egy ÁFA kódot és két árbevétel számlát vonz, akkor azt két tételsorban kell feladni. Ebben az esetben vigyázni kell arra, hogy a tételsorok összege feltétlenül adja ki a számla összegét (kerekítési probléma).
A számlák könyvelésénél, mint ahogy ez a fogadó fájl formátumából is következik, a számlatételeket főkönyvi számonként és ÁFA-kódonként (és esetleg gyűjtőnként) össze kell vonni.
Egy tételsor tartalmazza többek között az árbevételi főkönyvi számlaszámot, nettó értéket, ÁFA főkönyvi számlaszámot, ÁFA értéket, ÁFA kódot, vevő főkönyvi számlaszámot, partnerkódot, partner rövid nevét, gyűjtőket (költséghelyet, munkaszámot, termékkódot, stb.) A feladott tételsorok összegének egyezni kell, mind a számlán szereplő ÁFA összesítéssel, mind a vevő által fizetendő bruttó értékkel. A kerekítés problémát az szokta okozni, hogy (az előző példánál maradva) a számla feladott tételsorainak az összege (mind az adóalap, mind az ÁFA) nem adja ki pontosan a kinyomtatott számlán szereplő értékeket.
Pl.: egy olyan sok tételsoros számla esetén, mely tizedeseket is tartalmaz két főkönyvi számra összevonva szinte bizonyosan nem adja ki pontosan a kinyomtatott számla végösszegét.
Mivel ez az eltérés általában kisebb, mint egy forint, a kerekítés miatti eltérés kiküszöbölésére a legegyszerűbb módszer az, hogy az eltérés összegét hozzáadjuk (vagy levonjuk) ahhoz a főkönyvi szám sorhoz, mely érték szerint a legnagyobb.
Qsboxmegjegyz |
---|
A paraméterek a cégek könyvelési sajátosságai szerint változhatnak, amelyeket a SUP felhasználó állít be. A többsége .INI, vagy törzsadat-paraméterként realizálható. |
Főkönyvi feladás megvalósítása vegyes feladás esetén
A főkönyvi feladás másik gyakori esete, amikor ún. vegyes könyvelési tételeket kell feladni. Jellemzően ilyen a bérfeladás. A legfontosabb, hogy a vegyes könyvelési bizonylatok betöltésekor csak akkor lesz helyes a feladás, ha a bizonylat T/K oldalak egyenlege nulla. Ezt legegyszerűbb esetben a bizonylat tételsoronkénti „ráfordított” tételek képzésével lehet elérni. Ekkor minden bizonylat tételsort követ a megfelelő „ráfordított” tétel (T/K jelleg ill. fők.szám – ellenszámla megfordítása). Lehetőség van arra is, hogy ún. több tartozik sor, egy követel sor (vagy fordítva) könyvelési modell alapján képződjön a könyvelési feladás. Ebben az esetben csupán arra kell figyelni, hogy az egy bizonylaton belüli tételsorok T/K helyesen képzett összege (egyenlege) nulla legyen. Összefoglalva, vegyes bizonylatok feladása esetén a bizonylatonkénti kétoldalasságot a küldő rendszernek kell biztosítania.