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. Ezt pl.: valamilyen paraméter táblában kell tárolni. A paramérer értéket a könyvelést vezető cég adja meg.
BIZSZAM mező
A könyvelési bizonylatszámot a kimenő számla számával kell feltölteni, a SUP rendszer ajánlása szerint a forintos és a devizás számlák külön sorszámon futnak, tehát külön naplókban vannak. Amennyiben az átadó rendszer nem ezt a koncepciót követi, akkor számlatípusonként (számlasorszám-tartományonként) külön naplóba kell átadni.
Tehát pl.: a küldő rendszer különböző sorszámon futó kimenő számláit semmiképpen nem célszerű ugyanabba a naplóba átadni. Összefoglalva: ahány sorszám tartomány van a feladó rendszerben, annyi naplóba célszerű átadni, hogy a számlaszámok sorfolytonossága a naplón belül biztosítva legyen.
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ű.
RENDSZAM mező
A számla eredeti sorszáma. Storno, helyesbítő, valamint előleg számlák esetén az <ElozmSzla>
adattagban lehet visszahivatkozni. A kezelési módot csak az XML formátum támogatja.
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.
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 vegyes napló, az adatrögzítési módját tekintve lehet kétoldalas, vagy egyoldalas rögzítésű. A beállítást a könyvelés paraméterezi. A bér feladásra célszerű egy külön vegyes naplót létrehozni.
Kétoldalas rögzítésű napló esetén 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. Tehát kétoldalas rögzítésű napló esetén a bizonylatonkénti kétoldalasságot a küldő rendszernek kell biztosítania.
Egyoldalas rögzítésű napló esetén a föntebb leírt tételpár képzést (és a nulla egyenleget) a rendszer biztosítja. Ebben az esetben az egyes bérelemek feladását a 471 ellenszámlával szemben egy soron kell képezni.