Smart changes

Mégiscsak szükség van a könyvelőkre? Ha csak a NAV XML alapján egy automata könyvel, akkor az éveken átívelő gazdasági eseményekről készült számlákkal gond lehet. 

Mi a megoldás? 

2020. december 17. - SDSYS

Vegyünk példának egy szolgáltatást – fűtést - amelynek időszaka 2020. december 15. és 2021 január 15. közötti. A számla 2021-ben kerül kiállításra, mondjuk 2021. január 16-án, így a számlát a 2021-es könyvelésbe tesszük be.  

Mivel ez egy folyamatos teljesítésű szolgáltatás és az számvitel, illetve az ÁFA törvény megköveteli, hogy a decemberre eső költség 2020-ra, a januárra eső költség 2021-re legyen könyvelve, így el kell határolni ezt a 2020-ra eső költséget. Ennek megoldása, hogy ahogy tetszik, lehet 2021-re, vagy 2020-ra könyvelni, és a nem releváns évhez tartozó költséget passzív, vagy aktív elhatárolással toljuk át egyik, vagy másik évre. 

Erre azért is nagy szükség van, mivel egy nagy irodánál, gyártó vállalatnál ez jelentős költséget jelent. Fontos figyelni erre, hiszen ez a költség az eredménykimutatást módosítja, ami pedig a mérleget fogja módosítani.

Ha használunk olyan digitális megoldást, mint az SDSYS automatikus számla párosítása, akkor a számla issue date szerint a 2021-es könyvelésbe kerül be, így a könyvelőnek kell fokozottan figyelni a 2020-ra eső részre. 
Az SDSYS azonban csak a kibocsátás éve számviteli egységbe (időszakba) képes elhelyezni a számlát, mert az nem megbontható, a szállító pedig meg nem fogja megbontani.

Így csak a könyvelő tudja megmondani, hogy hova akarja könyvelni, de mire megmondhatná, a NAV párosítás miatti algoritmus elhelyezte a megfelelő könyvelési időszakba. 

man-hand-counting-calculator.jpg

Ezen - ha nem is sokat - de segíthet a teljesítés időszak kezdete és vége adatok megadása, azonban ez is csak fél megoldás, mert szerepe szerint a gyűjtő számlához lett kitalálva, de ez megugorható, mert egy gyűjtő számla nem lehet egyben folyamatos teljesítésű is de a gyűjtő számlát nevesíteni kell, ha egy számla nem gyűjtő számla akkor, ha van kezdete és vége, akkor folyamatos teljesítésű a számla. Ezért javasoljuk, hogy a NAV XML-ben a szolgáltatás kezdete és vége mező is legyen kötelező mező.

Ha az információ meg van az XSD-ben és nem gyűjtőszámla, akkor a könyvelő program döntheti el, hogy melyik évben legyen a számla könyvelése.
Ha ezt a könyvelő program nem tudja eldönteni, akkor a párosítás csak nagyobb szívás, mintha az első 5 hónapban minden számlát a könyvelő ellenőriz, és csak ezt követően küldi párosításra.

Összefoglalva, amíg a papír adatokat könyveltük le - és szent volt a papírt adata - oda könyveltünk, ahova akartuk. A párosítás oda irányítja, ahova a matek mutatja. Átteni nem egyszerű, mert hiányos lesz az iktatókönyv sorszáma, amit a számviteli törvény néz görbe szemmel. Ha automaták könyvelnek akkor ezt sajnos ezt nem fogja feltárni.

 

Szükség van-e a számla képére a számla könyveléséhez, ellenőrzéshez, befogadásához és archiváláshoz?

A rövid válasz, hogy igen, igen, igen és igen. De nézzük, hogy miért!

Szükség van-e a számla képére a könyveléshez? 

Mindenképpen szükség van, hiszen ha Vevő könyvelője az XML-ből dolgozik, akkor csupán az adatokat látja – ha nem kíváncsi a tételekre, csak az áfa összesítőkre – így nem  kerül napvilágra, hogy nem a megfelelő összeg került könyvelésre. Ha nem kerül napvilágra, akkor vevő veszít akkor is ha az érték kisebb, mint a tételek összesen, vagy akkor is, amikor ez egy áfa ellenőrzéskor derül ki, hogy több adót igényelt vissza, mint az indokolt lett volna, ha az összeg nagyobb, mint a tételek összege.

"Fontos hangsúlyozni, hogy  hiba lenne a vevői oldalon kizárólag az adatszolgáltatás alapján teljes automatizmust kiépíteni az egészen az adó levonásáig. A számla az a hiteles dokumentum, amelyet az adózónak meg kell őriznie, és ez a tárgyi feltétele a levonási jog gyakorlásának. Tehát ha az adatszolgáltatás és a számla elválik egymástól, akkor a kettőt érdemes összevetni, de nem szükséges a számla rögzítését manuálisan elvégezni." - mondja a NAV szakértője.

papers-3819540_1920.jpg

Szükség van-e a számla képére a számla ellenőrzéshez?

A rövid válasz: lehet. Jobban kifejtve és támaszkodva az eddigi tapasztalatokra, sokban függ:

  • az ellenőrző személyétől,
  • a cég számviteli politikájától (pl. vannak számlák amik EDI-on keresztül érkeznek így biztosan nincs eredeti számlakép csak generált),
  • jelen törvényi lehetőségektől.


Mivel nincs széles körben elterjedt egzakt válasz, melyben mindenki egyet értene, mi azt mondjuk és tapasztaljuk, hogy a számla kép ha megvan akkor legyen elérhető, de semmiképp se csak kizárólag a NAV XML-re hagyatkozzunk, mert érhetnek meglepetések és egyszerűbb a képeket tárolni és előhívni, mint magyarázkodni. Még évek kellenek hozzá, hogy a számla a köztudatban egy XML fájl legyen analóg képi adathordozó nélkül.

Szükség van-e a számla képére a számla befogadáshoz?

Ez szintén vitás terület.
Jelenleg a könyvelők nagy része onnan tudja, hogy a számlát befogadta az ügyfele, hogy azt valamilyen csatornán megkapta. Hívjuk ezt ráutaló magatartásnak. Ha kép nélkül pl. a NAV XML-ből akar a könyvelő könyvelni, akkor ezt az aktust megelőzi, kihagyja, hisz minden elérhető számla már letöltésre kerül, mielőtt azt a cégvezető/engedélyező látta volna és tovább adta volna neki. Ha a számla kép jön a régi módon, akkor az alábbi feladatokat kell miden számlánál egyenként megcsinálni. 

A fenti folyamaton kívül további kérdés, hogy a számlák képe, ha nem is szükséges a könyvelő számára, akkor mit tesz velük, mit mond az ügyfélnek, mit csináljon vele?
Vagy épp hogyan fog alakulni a cégen belüli iktatás, hisz a számlák folyamatosan érkeznek be, azt át kell venni, iktatni kell, ki kell utalványozni engedélyezésre stb.
Igen, ez a kérdés, még több kérdést vet fel, amire igazából a gyakorlat adja meg a választ.
Mi azt javasoljuk, hogy a könyvelők használják a számla képét is.

Szükség van-e a számla képére a számla archiváláshoz? 

A NAV XML 3.0-val elérhetővé válik majd, hogy a számla kép nélkül is archiválható legyen a tömegek számára is.
Ez azt jelenti, ha a számla kibocsátó a NAV XML 3.0 használatakor kijelenti (bechekkolja az XML-ben), hogy az adott számla minden adatot tartalmaz, ami szükséges, akkor a számlához nem kell képi információ mert a NAV aláírja az XML-t. Azonban a tárolásról még mindig a feleknek kell gondoskodnia majd, tehát ez egyfajta archiválási feladat, amit így nem lehet megúszni. Persze kisebb a tárhely igénye egy XML-nek mint egy képnek, de önmagában az archiválást nem úsztuk meg.

Jelenleg az archiválási rendelet szerint kell eljárni a papír alapú számlák esetén, ebben nincs érdemi változás. Azonban a leggyakoribb kérdés, hogy a PDF számlákkal mi a helyzet (amiken nincs e aláírás és időbélyeg).

Mi azt javasoljuk tárold el és őrizd két helyen legalább, illetve egyeztess szakértővel az adatvédelmi szabályzatról, hogy ez a tárolási mód abban a dokumentumban szerepeljen.
Ami biztos, az elektronikus úton kiállított számla minden másolata eredetinek minősül. 

Azt tudtad, hogy a PDF számlaképről lehet egy egyedi és megismételhetetlen úgynevezett HASH kódot generálni? Ez biztosítja, a fenti állítást, tehát, hogy az adatok nem módosultak, vagy ha igen az azonnal kiderül a HASH visszafejtésekór. 

Ha szeretnél több hasonló cikket olvasni, akkor kövesd a blogot vagy iratkozz fel hírlevelünkre! 
www.sdsys.hu/#hirlevel
 

Ezekre a változásokra figyelj, hogy elkerüld a büntetéseket!

2020. szeptember 30-án lejárt a NAV kibővített kötelező adatszolgáltatására vonatkozó moratóriuma (ami a 2020. július 1-én bevezetett 2.0 szabályokra vonatkozott), ami azt jelenti, hogy már büntetés vár azokra, akik nem tesznek eleget a NAV 2.0 kötelező adatszolgáltatás 2020. július 1-én bevezetésre került szabályainak. Aki minden pontnak megfelelően szolgáltat adatot annak nincs mitől tartani. 

Összeszedtük a 7 legfontosabb dolgot, amit tudni kell és amelyeket be kell tartani 2020. október 1 után, hogy elkerüld a büntetéseket!

  • 2020. július 1-jétől adatot kell szolgáltatni minden olyan számláról, számlával egy tekintet alá eső okiratról, amit belföldi adóalany állít/bocsát ki, belföldön nyilvántartásba vett adóalanynak az Áfa törvény előírásai szerint belföldön teljesített ügyletről.

  • Áfaalany, így az előzőeknek megfelelő számla, számlával egy tekintet alá eső okirat kibocsátása esetén adatszolgáltatásra kötelezett az, akinek
    - az áfakódja, vagyis az adószámának a 9. számjegye 2-es,
    - az áfakódja 1-es, mert alanyi adómentes vagy kizárólag tárgyi (közérdekű vagy speciális jellege miatt) adómentes tevékenységet végez vagy kizárólag kompenzációs felárra jogosító tevékenységet végez
    -vagy az áfakódja 5-ös, azaz csoportos áfaalany.

  • Akkor is kell adatot szolgáltatni ha a számla egy másik tagállambeli cég magyar adószámára áfa felszámításával lett kiállítva, mivel ez esetben belföldi adóalanyok közötti, belföldön teljesített ügylet számlázása valósul meg.

  • Az adatszolgáltatás alól az sem mentesül, akinek azért nincs magyar adószáma, mert korábban nem teljesítette bejelentési kötelezettségét.

  • A kata szerint adózók az általuk végzett gazdasági tevékenység miatt áfaalanyok, így az adatszolgáltatási kötelezettségük akkor is fennáll, ha áfa tekintetében alanyi adómentességet választottak vagy kizárólag közérdekű vagy speciális jellegére tekintettel adómentes (tárgyi adómentes) tevékenységet végeznek.
    Adatszolgáltatási kötelezettség minden olyan számlára, módosító, érvénytelenítő számlára kiterjed, amit az Áfa tv. szerint belföldön teljesített ügyletről (ide nem értve az adómentes Közösségen belüli értékesítést), belföldön nyilvántartásba vett adóalanynak állítottak/bocsátottak ki vagy függetlenül attól, hogy a számlán, módosító, érvénytelenítő számlán szerepel-e áthárított áfa, vagy annak megállapításhoz szükséges százalékérték.

  • 2020. október 1-től már az adószámos magánszemélynek kiállított számlákról is kell adatot szolgáltatni, hiszen ő is belföldön nyilvántartásba vett adóalany.Ha a termék beszerzésekor, szolgáltatás igénybe vételekor az adószámos magánszemély adóalanyi minőségében jár el, akkor a számla részére történő kiállításhoz meg kell adnia az adószámát. 2020. július 1-jétől ugyanis a belföldi adóalany partner adószámának első nyolc számjegyét, értékhatártól és adózási módtól függetlenül, kötelezően fel kell tüntetni a számlán.

  • Már az alanyi mentes vállalkozásoknak is van adatszolgáltatási kötelezettsége mindazok, akik áfaalanyok, belföldön nyilvántartásba vett áfaalany részére, belföldön teljesítenek termékértékesítést, szolgáltatásnyújtást és erről számlát, számlával egy tekintet alá eső okiratot állítanak, bocsátanak ki.
    Az alanyi mentes adózók is áfaalanyok. A számlaadat-szolgáltatási kötelezettség pedig független a számla áfatartalmától, így áfát nem tartalmazó számla is eshet adatszolgáltatási kötelezettség alá. Tehát, ha alanyi mentes adóalany belföldön teljesített ügyletről bocsát ki számlát egy belföldön nyilvántartásba vett adóalanynak, akkor a számla adatairól adatszolgáltatást kell teljesítenie.


Ha szeretnél több hasonló cikket olvasni, akkor kövesd a blogot vagy iratkozz fel hírlevelünkre! 

www.sdsys.hu/#hirlevel
 

tyler-franta-iusj25iyu1c-unsplash_1.jpg

Miért fontos a számla képe még mindig az XML adat mellett? Esettanulmányunk megmutatja, hogy milyen egyszerű hibákat okozhat ha csak a számla XML adatából dolgozik egy könyvelő.

Cégünk az SDSYS Zrt. vásárolt monitorokat egy Kft-től.
Mivel mi már kihasználjuk a kötelező adatszolgáltatás előnyeit számláink képi állományát az SDSYS Ügyfélkapuján keresztül a NAV-tól lekért XML adattal együtt párosítva küldjük könyvelése.
A párosítás dolga, hogy a PDF ismeretében keresse meg a hozzátartozó NAV Online XML-t, így teljesen megszabadulunk a manuális rögzítéstől, keresgéléstől.
Három számlát kaptunk Szállítótól, azaz a Kft-től. A párosítás hibátlanul sikeres volt mindhárom esetben, valami mégis elromlott, derült ki az ellenőrzéskor.

A párosítást a számla adatok feldolgozása, ellenőrzése követi, ami nem a párosítás feladata. Az első két számlát Könyvelő tételesen kapta meg, azon szerepelt az összes beszerzés. Az ERP rendszer sok mindenre fel van készítve arra is, hogy Könyvelő megmondhatja, tételesen akarja a számlát megkapni, vagy neki elég az áfa gyűjtőre könyvelés. Az alapbeállítás a tételes adatfeldolgozás, de Könyvelőnek ez nem tetszett, és kérte az átállítását áfa gyűjtőre. A harmadik számla ezek után hibás adatokkal érkezett meg, a könyvelőből jogos reklamációt kiváltva.

Természetesen kivizsgáltuk a helyzetet és a következőre találtunk. A NAV XML-ben a tételek helyes nettó, és bruttó értékekkel szerepeltek, de az XML áfa összesítő részébe már hibásan az utolsó tétel nettó és bruttó értéke került bele. Az eredmény pedig így az lett, hogy a NAV XML-ből kiolvasott adat nem egyezett meg a könyvelőnél lévő a számla képével.
Ilyen esetek miatt mondja az SDSYS a kötelező adatszolgáltatás bevezetése óta, hogy  a számla képére minden esetben szükség van, akkor is ha csak NAV XML adatunk van, mert egy elektronikus számlát kaptunk.

Ha Vevő könyvelője az XML-ből csupán az adatokat látja – ha nem kíváncsi a tételekre, csak az áfa összesítőkre – akkor mikor kerül napvilágra, hogy nem a megfelelő összeg került könyvelésre? Mi ennek az adóvonzata?


red-2708362_1920.jpg
Ha nem kerül napvilágra, akkor vevő veszít akkor is ha az érték kisebb, mint a tételek összesen, vagy akkor is -, amikor ez egy áfa ellenőrzéskor derül ki, hogy több adót igényelt vissza, mint az indokolt lett volna, ha az összeg nagyobb, mint a tételek összege.

Nézzük meg, hogy mi van abban az esetben ha a tételekben van a hiba, és nem az összesítésben és az ERP a tételek alapján könyvel.
Vajon vevő pénzügyi részlege milyen összeget fog elutalni a megvásárolt termékek után? Ha nem a számlának megfelelő összeget, akkor ez a hiba mikor derül ki? Sok esetben az év végi folyószámla kipontozáskor, amikor a felek azt keresik, hogy hol van a hiba, hiszen- egyik helyen minden rendben van, de a másiknál hiány keletkezett vagy többlet mutatkozik, ha a pénzügy is csak a NAV XML-t látja.

Két esetben derülhet ki egy ilyen jellegű hiba. Vagy a könyvelő gyanakszik és megnézi a számla képét (PDF-et) és megkeresi a hibát, vagy az M-lap NAV összeolvasása derít ki ellentmondást és elkezdődik egy ellenőrzés.

Mi ilyen esetek miatt is gondoljuk azt, hogy a számlák képének továbbra is fontos szerepe van és ez még sokáig így is marad.


Ha szeretnél több hasonló cikket olvasni, akkor kövesd a blogot vagy iratkozz fel hírlevelünkre! 

www.sdsys.hu/#hirlevel

Miben változik a NAV 2021.01.01-én bevezetésre kerülő 3.0 a korábbi verziókhoz képest?

Az SDSYS szakértői összeszedték ezeket a legfontosabb változásokat és segítenek értelmezni azokat.

1. A 3.0  a szerkezet teljesen új és a NAV későbbi felhasználásra (sejtésünk szerint, akár a SAFT-T-hez) lett „kiképezve”. Ki vannak emelve (common basic) „névterek”.
Ez egy olyan állományt jelent, amely szabályokat ír le az XML egy elemére. Ezek elsősorban az ellenőrzésben nyújtanak majd a NAV-nak nagy segítséget.

2. Programozás szempontjából biztos lesz munka a 3.0 bevezetésével is, de nem drámai a változás a funkcionalitásban. Kérdéses, hogy kik tudják megugrani a következő pár hónapban ezeknek a fejlesztéseket. Az biztos, hogy 2.0-ban még 2021 március végéig fel lehet majd tölteni.

3. A kötelező mezők bár úgy tűnik bővültek, de ez sem teljesen van így.
Nézzük például a “termékkód típusa” mezőt. Ha az ügyletben elő van írva jogszabályijáig, hogy kötelező a termékkód megjelölés, akkor a termékkód is köteles információ. Viszont ha egy ügyletnél nem kell feltüntetni az XML-ben, akkor ezt a mezőt nem szabad kitölteni.
Ezzel biztosan kell foglalkozni a fejlesztéseknél és nem csak az XML-ben, hisz jelölni kell a számlákban és a törzsadatokban is, ha egy ügyletben ez kötelező elem vagy sem, függően attól, hogy az adott kötelező/nem kötelező elemet a cikk, a vevő, az ügylet módja (pl termékdíj, paritás, 3. ország stb.) vezérli -e?

4. Az XML továbbra sem tartalmaz képet.


cat-214701_1920.jpg5. Van joghatás (completnessIndicator + electronicInvoiceHash) mivel elektronikus számlaként értelmezhető a HASH-el ellátott XML.
Itt kérdés, hogy a befogadó oldal hogyan fogadja be a számlát?
Mi lesz az ilyen típusú számlák befogadási/visszautasítási gyakorlata?
Gondoljunk csak bele, hogy mi van olyan esetben ha valaki csak a NAV XML-ből szed le a számlát, de vissza kell küldenie módosításra?
A NAV-on keresztül vissza tudja küldeni? A NAV-nál ezt, mint áfa levonási jogosultsággal rendelkező személy ezt nem lehet jelenteni vagy visszaküldeni, hiszen a NAV rendszere egy egyirányú csatorna. Minden esetben ezt a szállítónál kell megtenni és kérni a számla módosítását. (invoicereferencenumber)
Ez a számla archiválást megoldhatja és az ellenőrzést is sokban támogatja, azonban az üzleti folyamatokat főleg ERP-t használók körében érdemes megvizsgálni.


Az egyes pontokat, felmerülő kérdéseket a itt a blogon elkezdjük feszegetni, kitárgyalni. Nektek mi a legnagyobb prioritású kérdés a témában?

NAV adatok nyomában - Hogyan működik most az adatok lekérése?

Az SDSYS hónapok óta azon dolgozik, hogy a NAV-tól kapott XML adatokat ne csak lekérje, hanem az adatok segítségével olyan plusz funkciókkal lásson el könyvelő programok és ERP rendszereket, amelyektől a könyvelés folyamata gyorsabb, hatékonyabb és pontosabb lesz. 

De nézzük meg, hogy hol állunk most 2020. augusztus 1-én, a kötelező adatszolgáltatás tesztidőszakának első hófordulóján. 

sdsys-e-szamla_tukrozve.png

Egy számlát a NAV rendszeréből úgy kell letölteni, hogy előbb le kell kérni számlakivonatot egy adott időszakra.
Itt két féle időszak adható meg az egyik a számla kiállítás dátuma szerint, a másik a számla feltöltésének dátuma szerint időszakra lekérhető kivonat. A tapasztalat sajnos az, hogy a kivonat lekérdezés a számla kiállítás dátumra folyamatosan jól működik, ezzel szemben a feltöltés dátuma szerinti dátumra a kérések 2020.06.30-ig rendben vannak, de 07.01 után hol jó, hol nem jó. Tesztet végeztünk, és napokra kértük le 2020.07.01 - 2020.07.28-ig. Ezt többször megtettük, és mindig ugyan arra a napra 404-es hibával tért vissza. A jelenséget megírtuk a helpdesk-nek. Jelenleg arról van tudomásunk, hogy nem a mi bejelentésünk az egyedüli ebben a tárgyban - mondja Csiba András, az SDSYS vezérigazgatója és szakmai vezetője.

Beszéltünk fejlesztő partnereinkkel, akik használják a modellt, de csak az issue date alapján kérnek le és mindig utólag a teljes hónapot. Így jól működik a rendszer és biztosan nem marad ki semmi. Ennek a módszernek sok hátránya van, de működik.

Az issue date csak napra keres, tehát ha délben töltenek le egy napot, akkor amit ezután töltenek fel a következő napon kimarad, de a napra kérés miatt legfeljebb az előző napot szabad lekérni. Még így is lehet benne kimaradt számla. Legyen egy számla kibocsátás dátuma 3-a feltöltés 5-én. Ha minden nap lekérjük az előző napot, akkor 4.-én kérjük a 3-át, nincs ott. 5-én kérjük a 4-ét nincs ott, még nincs is feltöltve. 6-án kérjük le az 5-ét, de issue szerint az 3-án van. Ha meg mindig teljes előző hosszú időszakot töltünk le, akkor meg egy rakás számlát sokszor fog a rendszer letölteni.
Ezért csináltuk meg úgy az SDSYS rendszerét eredetileg úgy, hogy upload dátumra - az percre, másodpercre működjön - mert ez a megoldás nagyon "energia" takarékos, hiszen minden xml-t csak egyszer tölt le, és nem tud kihagyni egyet sem.

A szolgáltatásaink természetesen most már mindkét módon lekérik az adatokat, de amint a NAV oldalon ki lesz javítva az upload date mód onnantól kezdve az SDSYS rendszerei elkezdhetik 100%-ban használni a sokkal pontosabban működő feltöltés dátum alapú adatlekérést. Ezzel a pontos rendszerrel automatizáljuk a számla feldolgozást, aminek segítségével hatékonyabb és gördülékenyebb lesz az SDSYS rendszert használó könyvelők munkája. 

Hogyan segíthet a számlák feldolgozásban a NAV kötelező adatszolgáltatása 2020. július 1. után?

Nézzük, hogy mi változik július 1. után?

Minden belföldi adóalanynak által kiállított számlát összeghatár nélkül kötelező lesz feltölteni a NAV-ba áfa értéktől függetlenül – így az áfamenteseket is (természetesen lesz pár kivétel, mint mindig). 

Emellett a kézi számla adatait is fel kell tölteni a NAV rendszerébe, amire a kiállítást követően 4 nap áll rendelkezésre. Megváltoznak az ellenőrzési algoritmusok is és ezért is fontos, hogy a számla adatai felkerüljenek.

A NAV is szolgáltat adatot visszafelé a vállalkozások felé, így a cégek részére kiállított szállítói számlák kép nélkül gyorsan elérhetővé válnak. Ezek az XML-ek nem tartalmaznak majd minden adatot, bár lesznek olyanok, amelyekhez a számlák képére is szükségünk lesz.

Hogy tudjuk ezt előnyünkre fordítani?

Július 1. után a szállítói számlák tételes adatrögzítését a NAV adat szinten a rendelkezésünkre bocsátja, de ekkor még szükségünk lesz a számla képi adatára is. Ez egy jó ellenőrzési pont, hogy eldöntsük, hogy:
Befogadható-e a számla?

Tartozik hozzá megrendelő?
Valóban cégünk vásárolta az adott terméket, szolgáltatást?

Ha az adat és kép egyszerre rendelkezésünkre áll akkor lehetünk képesek a szállítói számlák teljesen automatikus rögzítésére és könyvelésére.

De hogyan?


Ha kiállítanak cégünk részére egy számlát, akkor azt egyből fel kell tölteni a NAV-hoz. Ezeknek a szállítói számláknak az adatait könyvelésünk le tudja kérni manuálisan, de a számla képek mozgatása, manuális összekapcsolása, számlánként még mindig időigényes és embert kívánó feladat marad.

Az SDSYS NAVCOM 2.0 rendszere ezzel szemben kiváltja a manuális letöltés folyamatát és a számlakép feltöltését követően egyből összekapcsolja a képet és a NAV-tól kapott XML adatott. Így a belföldi szállítói számlák adatrögzítése megszűnik.

Ezzel a megoldással 99,99% pontosságot érhetünk el, ami sokkal nagyobb, mint amit az OCR feldolgozók tudnak biztosítani.

Költséget tudunk vele megtakarítani, hiszen nincs szükség új szoftverekre és munkaidőt is spórolunk vele. Így nem jár bevezetési kellemetlenség, hiszen ez egy háttér rendszer, ami bármely rendszerrel képes együttműködni, így minden a megszokott rendszerekben zajlik tovább. 

Ha többet szeretnél megtudni az SDSYS megoldásáról látogass el oldalunkra: www.navcom.hu

Az élet nélküled - óda az irodai nyomtatóhoz

2020.01.01.
A nap, ami az SDSYS életében komoly mérföldkő. Kihúztuk a nyomtatót.
Téged, te mindig halkan zümmögő, tökéletesen láthatatlan lézer fénnyel, digitális térben létező science fiction-öket kézzelfogható, kissé langyos és kellemesen szagos valódi dokumentumokká varázsoló gépszörnyeteget. 

A képzeletet váltottad valósággá. 

Irodánk működése radikálisan megváltozott, amikor a nyomtatót nem csak kihúztuk, de költözéskor nem is vittük magunkkal. A home office-ra való átállásig  eltelt 2 hónapban, és azóta is büszkén mondhatjuk, túléltünk. Túlélték a kollégák, és csodák csodájára, túlélte a cég is. Mégis hogyan?

printers-344016_1920.jpg

Nehezen. Nem miattunk, inkább a minket körülvevő világ miatt. Hiszen az SDSYS abszolút digitális, érintésmentes, tiszta adat-adat kommunikációt valósít meg - mint szolgáltatás. De mi történik, ha a vizes ballonos rendelést csak papíron aláírt szerződéssel lehet leadni? Hogy lesz kávéfőzőnk, ha a licensz szerződést csak eredeti, aláírt pecsételt dokumentumként fogadja be a distributor? Hogyan kezeljük, hogy a .pdf aláírást még a saját kollégáink közül sem látja mindenki, mert Adobe Reader kéne hozzá…. ?

Megállapodtunk a partnerekkel és beszállítókkal, amennyiben semmiképp nem fogadják be az amúgy teljes értékű, 100%-ban jogilag elfogadott és hiteles digitális aláírást, legyenek kedvesek kinyomtatni, elhozni személyesen az irodánkba, ott megvárni míg aláírjuk és beszkenneljük, és elvihetik az eredeti papírt. Így ugyan keletkezett papír, de legalább csak 1 példány. 

Valamint természetesen kerestük a megoldásokat. Folyton és fáradhatatlanul. Így találtunk rá a TrustChain -re, ahol dokumentumokat és szerződéseket telefonon írhatunk alá minősített e-aláírásunkkal, ami a saját kezű aláírással azonos joghatású. Pár kattintás, és június végéig még ingyenes is. Milyen kényelmes megoldás volt a karantén idején, amikor nem csak a partnereink nem jöttek az irodánkba, de még mi sem… Show must go on! És így mehet is, mi folytatjuk ezt az utat, a gyors, egyszerű, digitális megoldásokkal. Bízunk a technológiában.

Te drága, kedves, színesben aláírást és színházjegyeket nyomtató gyönyörűség. Meg kell válnunk, és hiányod -fájdalom- elhanyagolható. Szomorúan kellett ráeszmélnünk, a szkenner sokkal jobb barátunk. Pedig ő is nélkülözhető.

Ti hogy oldottátok meg az aláírásokat?

 

Hiteles E-számlának tekinthető-e a PDF formátumú számla? 

Mit tehet egy cég ha szeretné a számláit 100%-os elektronikusan kezelni? Milyen feltételeknek kell megfelelni, hogy hiteles és törvényes is legyen?

Mit is jelent az, hogy E-számla?
Elektronikus számlának tekinthető egy számla (számviteli dokumentum) ha elektronikusan lett kiállítva, elektronikusan lett továbbítva és elektronikusan lett befogadva. Azaz a pdf formátumba konvertált számla nem feltétlenül minősül E-számlának, azt papír-alapú számlának kell tekinteni. Ha nem lesz belőle E-számla, akkor minden esetben szükséges a nyomtatása. Csak ebben az esetben alkalmas a számla adóigazgatási eljárásban részt venni, valamint a számlát a törvényben meghatározott ideig papír számlaként kell őrizni. 

De akkor hogyan valósulhat meg a teljesen elektronikus számlázás?

accounting-761599_1920.jpg
Ma 2020-ban már mindenhol teret hódít a digitalizáció, de néha jogszabályi vagy egyéb buktatók is állhatnak a modern és egyszerű megoldások útjába. Az elmúlt pár hónapokban a fennálló járványügyi helyzet miatt kifejezetten előtérbe kerültek ezek a hatékony és biztonságos megoldások. 

Hiszen ezek már régóta elérhetőek, méghozzá egyszerűbben, mint az sokan elképzelik. 

Létezik egy zárt rendszer, amely lehetővé teszi, hogy bármely számlázó program/ERP program tudjon elektronikus számlát készíteni és továbbítani. Ennek használatával számlázáskor - ami a szokásos ERP vagy számlázóba történik - a számla papír alapú nyomtatása helyett automatikusan egy PDF-be ágyazott, NAV által előírt formátumú XML fájl jön létre. A számla adattartalmát tartalmazó XML azonban nem kötelező eleme az elektronikus számlának, ez is elhagyható. Ezt a fájlt az E-számla szolgáltatója elektronikus úton fogadja és digitális aláírással és időbélyeggel hitelesíti. Ezt követően a vevő által előzetesen meghatározott e-mail címre kerül kiküldésre egy hivatkozás, melyen keresztül letölthető az elektronikus számla.

A számla képe és az adatai is titkosításra kerültek a rendszerben és csak a címzett tudja elolvasni. A címzett e-mailben és/vagy portálon keresztül letöltheti a számla kepét és annak XML adatait és a letöltés tényét is időbélyeggel látja el a rendszer. 

A folyamatnak köszönhetően az E-számla gyors, biztonságos, visszaigazolható és visszakereshető formában kerül  címzetthez, vagy címzettekhez. 

Az E-számla hitelesítő elektronikus aláírást tartalmaz, így nincs szükség a nyomtatására, így csökkennek a nyomtatási, papír és postai költségek és felszabadul a számlák nyomtatására, borítékolására, levelek feladására fordított munkaidő is. Fizikai tárolóterületre sem lesz szükség, hiszen az E-számlák tárolása és megőrzése elektronikusan történik. 

A megoldás nem csupán az elektronikus számlázást teszi lehetővé, hanem az így kiállított számlák a fogadó oldalon azonnal feldolgozhatóvá válnak, és nincs szükség a számlaképről történő manuális adatrögzítésre.

Reméljük, hogy a járvány elmúltával ez a folyamat nem áll meg és egyre több cég él a lehetőséggel, beépíti és fejleszti majd az elektronikus számla megoldásokat.

Ha érdeklődsz e-számla megoldásunk iránt akkor kattints ide.

A Home Office nem digitális transzformáció

Az üzleti világ fele egyik pillanatról a másikra home office munkavégzésre váltott. Pénteken még az irodában nyakkendőben, hétfőn már az otthoni “sufnituning” íróasztalnál donáldkacsázva vezette le a cégvezető a szokásos hétindító megbeszélést. A már korábban is -többnyire kényszerből és esetlenül- használt digitális platformokat mindenki beizzította, elővette a Teamst, a Hangoutsot, a Zoomot, vagy talán még a Skype-ot is a csapat. A cégben asztali gépről dolgozók most hirtelen az otthoni laptopon lépnek be a levelező rendszerbe, és próbálják figyelmen kívül hagyni a browser Minecraft és Netflix könyvjelzőit.

És ezzel elindult a digitális transzformáció. 

img_6590.PNG

Hiszen tény, hogy alapjaiban változik meg a napi működés. Elvégre milyen fura, hogy nem egy stilizált szobában ülünk egy monitor előtt, hanem a kanapén ülünk a monitor előtt. 

Hiszen tény, hogy a technológia magasabb szintű használata lesz a jellemző, már nem csak  a londoni / chicagói / pekingi kollégákat hívjuk be a szokásos heti retrospektívbe, hanem a csepeli és kalászi kollégák is hangoutson csatlakoznak.

Hiszen tény, hogy már nem csak edm-ekre, hanem facebook kampányokra is költünk.

Vagy várjunk csak? Mi is változott?

Attól, hogy otthonról dolgozunk, még nem történt meg a digitális átállás. Viszont kezd fájni, ahol eddig nem fájt.

Hogyan éljünk nyomtató nélkül? Kimehet egy ajánlat, ha a team vezető nem írta alá? Most hogy írná alá? Hisz vírus van, megérti mindenki. Mindenki ezzel szembesül.

Vagy mégsem? A digitális térben történő üzletelés már sokaknak nem újdonság, és egyáltalán nem kihívás. Az aláírások kezelése, a digitális adatkezelés mindenki számára elérhető technológiák. A videochat etikettje, a meetingek online térbe helyezése és azok külön szabályai megismerhető és elsajátítható skillek.

Akik most rálépnek a digitális gondolkodás útjára, már nem fognak letérni róla. A helyhez kötött, fizikai valóhoz (pecsét, aláírás) ragaszkodó üzletelés többé nem létszükséglet - és talán már nem is igény. A személyes találkozás formálódik, a networking és emberi kapcsolat kialakítása felértékelődik. 

Itt az idő, hogy digitálisan gondolkodjunk. Ha egy millanial kézbe vesz egy Nokia 3410-et, felkiált: “Jé, gombok!”.
Itt az idő, hogy 2021 januárjában mi kiáltsunk fel egy ‘oldschool’ irodában: “Jé, nyomtató!”

süti beállítások módosítása