A NAV online számla rendszer lehetővé teszi a szállítói számlák letöltését. Ahhoz, hogy az Infotéka Kontír.NET programban ezt meg lehessen valósítani, szükség van egy olyan technikai felhasználó felvételére, amelyiknek csak letöltési jogosultságot biztosít az a partnerünk, akinek a könyvelését végezzük. Így gyakorlatilag meghatalmaz minket ennek a feladatnak az elvégzésére. Azt célszerű megvizsgálni, hogy a GDPR szempontjai alapján a szerződésben kell-e emiatt módosítást végrehajtani.
Elsőként adjuk meg annak a technikai felhasználónak az adatait a NAV online számla fülön, akinek biztosította a partnerünk a számlák letöltésére vonatkozó jogosultságot. Ne felejtse el a rögzített adatok tárolását és a kapcsolat tesztet. Amennyiben ez nem sikeres, akkor a megadott azonosítók nem lettek helyesen kitöltve vagy a letöltéshez való jogosultság nincs engedélyezve. A technikai felhasználó adatait célszerű másolni és beilleszteni, gépelésnél elég nagy a hibázás lehetősége.
Fontos, hogy a létrehozott technikai felhasználó a következő jogosultsággal rendelkezzen:
A partnerek által feltöltött számlák a mindig aktuális séma szerinti adatokat tartalmazzák. Ezekből az adatokból kell és lehet eldönteni, hogy a bizonylat milyen módon kerüljön a könyvelésbe, hogy azzal a további feladat minél kevesebb legyen.
•Az első vizsgálat alapján eldöntjük, hogy a pénztár vagy szállító naplóba tartozik-e. Ez a fizetési mód alapján történik. A fizetési módokat a NAV a számla sémában megadta, így a CASH értékűeket tekinti az alkalmazás készpénzesnek, minden további típust utalásnak.
•A devizanem alapján tovább bonthatjuk a pénztári tételeket forint illetve valutapénztába.
•A szállító naplóban pedig ugyanezen tulajdonság alapján belföldi forint, illetve devizás szállító. Itt még egy fontos vizsgálat történik arra vonatkozóan, hogy a bizonylat, illetve annak tételei fordított áfásak-e.
•Ellenszámlának olyan főkönyvi számot célszerű majd választani, ami a cég tevékenységére leginkább jellemző. A bizonylat tételei rendelkeznek olyan tulajdonsággal, ami meghatározza, hogy előleg megfizetése vagy annak figyelembevétele történt. Ekkor az ellenszámla az előlegként megadott főkönyvi szám lesz.
•Az áfa főkönyvi szám szintén paraméterként megadható, de pénzforgalmi áfás szállító esetében az ahhoz rendelt főkönyvi szám felülbírálhatja azokban az esetekben, amikor a bizonylat nem azonnali pénzmozgásra vonatkozik. Ilyen az előleget tartalmazó vagy a készpénzes számla.
•Az adó mértéke a bizonylat xml állományának összesítő részében megtalálható, így a bizonylat kontírozásainak a számát ebben az elemben található adó mértékek száma határozza meg, amit még az előleg tételek növelnek.
•A gyűjtőkód megadása során figyelembe vesszük, hogy a szállító partner bizonylata tartalmaz-e kisadózói jelölést, vannak-e előleg, illetve előleg visszavételre vonatkozó információk. Ezek hiányában az általános gyűjtőkódot használjuk.
És mindez a gyakorlatban
Főkönyvi számok
Az ellenszámla meghatározásánál választhatja azt, hogy az itt beállított főkönyvi szám legyen vagy vizsgálja meg a program, hogy a partnerhez a bizonylat dátumát megelőző két évben melyik volt a legtöbbet használt főkönyvi szám és az ahhoz rendelt megjegyzés illetve áfa gyűjtőkód:
A tapasztalatok alapján nagy pontossággal kerül meghatározásra mind az ellenszámla, mind pedig a megjegyzés és áfa gyűjtőkód. Javasoljuk ennek használatát!
A nem százalékos adómérték esetében az egyes típusokhoz konkrét értéket választhat a törzsadatok áfa típusokban megadottak közül.
El kell még dönteni, hogy a könyvelés dátuma a generálás során a számla áfa teljesítésének dátuma, vagy a számla kiállításának dátuma legyen, illetve a készpénzes típusú bizonylatokat fel akarja-e dolgozni. Ha a vállalkozás házipénztárt vezet és ott akár a kontírozás, majd könyvelés felé való feladás is megtörténik, akkor ezt nem célszerű bejelölni.
Egyéb
Szintén tapasztalati érték, hogy a feltöltött számla xml állományok kb. 10 %-a nem tartalmazzák a bizonylat bruttó összegét. Tény, hogy ez az xsd állományban úgy van meghatározva, hogy nem kötelező, de mivel az adott környezetben értelmezhető (minden számla tartalmazza a bruttó összesent), emiatt azt gondoljuk, hogy ez hiba az előállító részéről. Ha jelöli, hogy ebben az esetben a könyvelés adja össze a az alap és áfa értékét és tekintse azt a bizonylat bruttó összegének, akkor ez a probléma megoldásra kerülhet.
További tapasztalat, hogy a feltöltött állományok egy része század fillér pontossággal határozza meg a bruttó összesen és áfa összesítő értékeket is. Utalásra és készpénzes kifizetésre sem fog csak egész érték kerülni. Ha kéri az egészre kerekítés funkciót, akkor a bizonylat bruttó összegét (akár tartalmazza az xml, akár az előző pont szerinti összeadásból származik) a matematika szabályai szerint az alkalmazás kerekíti.
Részben a kerekítés, de találkozhatunk olyan esetekkel is, amikor kerekítés nélkül is igaz, hogy az áfa mérték szerinti összesítés és a számla alap és áfa értéke között különbség van. Erre szolgál ez az opció, hogy ennek jelölésével a következő két főkönyvi számra (attól függően, hogy nyereség vagy veszteség) a különbözet könyvelésre kerül.
Végül a leginkább problémás eset, hogy a feltöltött számla xml állományok mintegy 20 %-a nem tartalmazza a fizetés módját. Ez véleményünk szerint szintén hiba, hiszen az adott környezetben értelmezhető (kevés olyan számlával találkozni, ami nem tartalmazza ezt az információt. Így ezeknek a bizonylatoknak a naplóba sorolása sem egyértelmű, ezért kérjük, hogy döntsék el, ezek a számlák melyik naplóba kerüljenek. Ha nem jelölik ezt az opciót, akkor a szállítói naplóba, ha jelölik, akkor a pénztár naplóba fognak kerülni. Keressük a még használható megoldásokat ennek a problémának az áthidalására.
Ha ezeket a beállításokat elvégezte, és a kapcsolódás teszt is sikeres, a szállítói számlák letöltésének technikai akadálya nincs. A letöltésről a következő fejezetben olvashat: NAV online szállítói számlák letöltése