Kötelezőség kérdése és Főkönyvi / Kifizetési adatok

[githubbarbara]

Üdvözletem,

A specifikációban áll egy ilyen mondat:
"A struktúrában megtalálhatók kötelező és nem kötelező elemek. Amennyiben egy elem kötelező, akkor annak mindenképpen kell tartalmaznia a SAFT fájlban értéket. Amennyiben egy elem nem kötelező, azonban a társaság által használt ügyviteli rendszer tartalmazza, akkor kötelezően kell szerepeltetni benne. Vannak olyan elemek, melyek csak azért nem kötelezőek, mivel nem minden gazdasági esemény típusnál található adat. Amennyiben az adott gazdasági eseménynél az elem releváns, akkor alapvető elvárás, hogy az ügyviteli rendszer is tárolja az adott elemet."

Rendszerfejlesztőként ez egy nehezen értelmezhető elvárás. Pontosan mi kötelező? Amennyiben egy adat bármilyen szinten rendelkezésre áll a rendszerben és azt valamilyen formában előírja a SAF-T, akkor azt mindenképpen SAF-T kompatibilis formára kell hozni, még akkor is, ha az alapvető tárolási logika messze áll az elvárt riportálási logikától, mélységtől?
Az Online számla adatszolgáltatásban egyetlen modult kellett addig fejleszteni, míg megfelelt az elvárásoknak. Sok szempontból már ez is egy óriási feladat volt, mert az adatok sokszor nem megfelelő logikában, vagy mélységben voltak tárolva. Továbbá egy fejlesztő cégnek adott esetben egy rendszer 4-5 párhuzamos verzióját kell fejleszteni, amiben az adatok tárolási logikája eltér egymástól. Most ugyanez az elvárás jelenik meg az összes modult tekintve. Mi az a mértékű fejlesztés, ami elvárható a fejlesztő cégektől, és a felhasználók is hajlandók/képesek kifizetni? Mennyiben van ez összhangban a Költség-haszon összevetésének alapelvével?

A főkönyvi fileokat tekintve lenne pár még konkrétabb kérdésünk:

1. Analysis blokk
   Amennyiben egy főkönyvi rendszerben dimenzionális bontást használunk a főkönyvi számok mellett, akkor ezt a részletezettséget, tehát a kontrolling teljes hátterét szerepeltetni kell a SAF-T-ban? Tekintve, hogy az eltérő főkönyvi számok esetében eltérő dimenziókat használunk, ez meglehetősen összetett feladat.

2. TaxInformation blokk
   A TaxInformation blokk főkönyvi tranzakció sor szinten szerepel, mint elem. A rendszerünkben nem minden verzióban áll rendelkezésre sor szintű összerendelés a főkönyvi tranzakciók és áfa analitikus tranzakciók között. Sok esetben az azonos főkönyvi számra történő könyvelések összevonásra kerülnek egy bizonylaton belül, még akkor is, ha mögöttük több analitikus tranzakció áll.
   Akkor ezt most hogy kell értelmezzük? Kötelező vagy nem? Rendelkezésre áll a rendszerben a fentiek szerint, vagy nem? Kell fejlesztenünk, vagy hagyjuk ki ezt a blokkot?
   Ugyancsak kérdés számomra, hogy mondjuk egy USD tranzakció, EUR könyvelés esetén, ha a főkönyvben nem áll rendelkezésre HUF információ, akkor csak az áfa miatt szerepeltetni kell-e?

3. A Proportional blokknak nem szerepel leírása, az XSD-ben, szeretném kérdezni, hogy mit jelent.

A Payment fileokkal kapcsolatban az alábbi kérdéseink lennének:
A specifikáció alapján: "A fizetések közé tartoznak a beszámítások, cégcsoporton belüli elszámolások akkor is, ha tényleges pénzmozgással nem jár. A fizetések rész tehát minden olyan elszámolást tartalmaz, mely a társaság pénzeszközeihez kapcsolódó mozgást jelent."

1. Ezek az információk számos eltérő helyen állnak rendelkezésre a rendszerben, melyek egységes szerkezetre hozása nem egyszerű, illetve ha a rendszerben nem végeznek konszolidációt, akkor az adatok nem is állnak megfelelő mélységben rendelkezésre:

• banki tranzakciók
• pénztári tranzakciók
• kompenzálások főkönyvi naplókban
• intercompany számlázások a vevő/szállító számlázási modulokban
• egyéb konszolidációval kapcsolatos rendező tételek speciális főkönyvi naplókban

A kérdés, hogy valóban minden ilyen tétel szerepeltetése kötelező-e a Payments file-ban. Megintcsak az a kérdés, hogy mekkora erőfeszítéssel hozhatók közös nevezőre ezek az egymástól teljesen eltérő szerkezetű tételek, vagy ha ezt vevő/szállító tételekből szeretném kinyerni, akkor hány könyvelési folyamatba kell beleprogramozni, hogy a vállalatköziség ténye letárolásra kerüljön és automatikusan rendelkezésre álljon.
2. Hasonlómód kérdés számomra, hogy a kifizetési file-ban a főkönyvi számlaszám melyik oldalt érinti (a vevő/szállító) vagy a bank/pénztár/egyéb elszámolási számlát?
3. A Settlement blokkban az árfolyamkülönbözet tételeket is szerepeltetni kell, vagy csak a konkrét kiegyenlítési tételeket? Mi a célja ennek a blokknak?

Kiegészítő kérdésem lenne még, hogy várható-e részletesebb specifikáció? Mert azt gondolom, hogy a jelenlegi specifikáció, pontosabban az egyes elemek magyarázata messze nem elégséges a pontos töltéshez.

Válaszaikat, észrevételeiket előre is köszönöm. Részünkről várhatók még kérdések a különböző file-okkal kapcsolatban. A fenti kérdéseket egyúttal kérem kezeljék úgy is, mint véleményezési észrevételt, jelzett nehézséget.
Köszönettel, Barbara

[NTCA-tax]

Kedves @githubbarbara!

Köszönjük a felvetéseket, észrevételeket. A SAF-T esetében jó érzi, hogy az ERP rendszerrel való összemappelés a legnagyobb feladat. Ez sokkal bonyolultabb, mint az Online Számla, mivel egy ügyviteli rendszernek számos modulját érinti. Ugyanakkor a SAF-T-ben megfogalmazott adatok azok, amelyet az ellenőrök jellemzően kérni szoktak, az adatok mélységénél pedig próbáltuk azt az egyensúlyt megtalálni, hogy ne legyen feleslegesen bonyolult, ugyanakkor az adóellenőrök számára olyan adatállomány legyen, amelynél többet nem kérnek az érintett adatkör vonatkozásában. Ezzel párhuzamosan bizonyos ellenőrzések automatizálását akarjuk megvalósítani, melyből egy részt ki is szeretnénk ajánlani az ügyfeleknek. Vannak olyan mezők, amelyeknek a szerepeltetése mellett akár nagyon hosszú vita is volt. Néhány mező esetében több órás (vagy most már talán több napos) egyeztetések vannak mögöttünk. Tehát adóhivatal oldaláról már a jelenleg feltöltött verzió mögött is számos megfontolás, és piaci szereplőkkel folytattunk egyeztetéseket.

Az adatok kötelezőségének megállapítása azért nehezebb feladat, mivel sokszor nem egyértelmű jogszabályi rendelkezéseken alapulnak, hanem inkább számviteli elveken, jellemző gyakorlaton, vagy logikai kapcsolatokon. Ugyanakkor nagyon sokfajta ügyviteli szoftver működik, így nagyon nehéz megtalálni azt, hogy pontosan mely elemek mikor lehetnek kötelezőek.

A konkrét felvetések kapcsán:

• Az Analysis blokk éppen a több dimenziós lehetősége miatt lett többszörözhető. Összegszinten éppen ezért nem elvárás, hogy az adott főkönyvi tételsor összegét kiadja.

• A Taxinformation opcionális elem. Akkor kötelező kitölteni, amennyiben a főkönyvi rendszer az adott főkönyvi tételhez letárolja az adózási információkat. Vannak olyan ügyviteli rendszerek, amelyek a főkönyvből állítják elő az áfa analitikát, ezért szerepel benne a forint összeg is. A felvetésben az összevont könyvelés is felmerül. Ez olyan gyakorlat, amely ellenőrzés oldaláról is számos problémát okoz. Ezért vezettük be a GroupinLedger riportot, hogy lássuk, miből áll össze az összevont könyvelési tétel.

• A Proportional elemnek (és sajnos az alattuk lévőknek) nincs annotációja. Ezt a következő verzióban mindenképp javítani fogjuk. Ez a levonási hányadot takarja egyébként.

• A Payment esetén (mint ahogy a többi csomópont esetén is) meg lehet tenni, hogy több XML készüljön. Tehát ha túlzottan bonyolult lenne, akkor nem feltétlenül szükséges például a bankszámla adatoknak és a pénztár adatoknak egyetlen XML riportba kerülniük. Az adatstruktúra a közös, nem pedig az a cél, hogy a teljes SAF-T egyetlen nagy XML legyen.

• A főkönyvi számlaszám kérdés jogos. Ezt dokumentációban kell rendeznünk. Itt a bank/pénztár stb. számlákra gondoltunk, de ez ténylegesen hiányzik a dokumentációból.

• A Settlement-nek csak a kiegyenlítési, beszámítási tételeket kell tartalmaznia. A Settlement résznél szerintem még adósak vagyunk egy pontosabb dokumentációval...

A séma a projekt végéig változhat, mint ahogy a dokumentáció is. A dokumentáció fejlődését alapvetően a feltett kérdések is befolyásolják. Ezért fontos számunkra minden olyan kérdés, amely a dokumentáció és séma alapján nem érthető, mivel azt részletesen kell akkor megmagyaráznunk.