Piše: Slađana Atanasovski, IN2 Beograd
Sredinom 2025. godine u Hrvatskoj je donet Zakon o fiskalizaciji, kojim se uređuje izdavanje i fiskalizacija eRačuna. Sva pravna lica će razmenjivati račune digitalnim putem uz verifikaciju preko Poreske uprave. Fiskalizacija 2.0 donosi unapređenje i automatizaciju poslovnih procesa, čime će se poboljšati efikasnost i transparentnost finansijskih transakcija. Istovremeno, kao i svaka zakonska promena, donosi brojna pitanja prilikom realizacije.
IN2 kao regionalna kompanija, imala je iskustvo u implementaciji eRačuna u dosta zemalja, kroz svoja poslovna rešenja. Poslednjih godina, ovakva digitalna transformacije je urađena u Srbiji, gde smo sa svojim klijentima prošli kroz sve etape, ali i tehničko-poslovne izazove i pitanja koja su se javljala u tom procesu. S obzirom na to da smo se sretali sa situacijama koje se dešavaju u praksi, podelićemo neka iskustva u nastavku, te budite slobodni da nas kontaktirate za sva dodatna pitanja.
Rok za početak testiranja počinje od 01.09.2025, dok se eRačuni za sve firme u sistemu PDV-a moraju izdavati i zaprimati od 01.01.2026. godine. Da li je to dovoljno vremena za uvođenje ove izmene u softverskim rešenjima?
Rokovi su realni. Inicijalne tehničke specifikacije izrađene su u šestom mesecu, dok se do početka testiranja očekuju finalne specifikacije i sva tehnička pojašnjenja. Važno je i da proces razmene eRačuna u Hrvatskoj nije u potpunosti nov, samo što nije postojala obaveza korišćenja za korisnike privatnog sektora. Stoga, mnogi softveri već imaju rešenja prilagođena ranijim verzijama fiskalizacije. Iako nova fiskalizacija donosi određene izmene, veliki deo logike i načina rada ostaje isti.
Savetujemo svima da letnji period iskoriste za pripreme (procesno i za povezivanje svojih proizvoda i usluga sa pozicijama KPD), a da se posveti što je moguće veća pažnja periodu testiranja. Na taj način se smanjuju rizici i osigurava lakši početak primene zakonske izmene.
Koliko je zakonska izmena uvođenja Fiskalizacije 2.0 komplikovana za implementaciju iz ugla poslovnih softvera (programskih rešenja)?
Kod svake zakonske izmene treba razlikovati nužni set izmena, od dodatnih opcija i mogućnosti koje izmena pruža. Na svakom korisniku je izbor da li će se zadržati samo na nužnom setu ili očekuje i neke druge opcije koje se izmenama otvaraju.
U ovom konkretnom slučaju, nužni set izmena iz ugla poslovnog softvera obuhvata automatsko generisanje i slanje eRačuna, kao i slanje informacija o plaćanju računa. U tom delu, ne treba potceniti kompleksnost generisanja XML fajlova. Softversko rešenje mora generisati fajlove propisane strukture za svaki tip dokumenta (račun, odobrenje, avansni račun) i svaku situaciju (bilo kojih podataka i tipova redova dokumenta). Takođe, fajl mora uključiti klasifikaciju proizvoda, klasifikaciju PDV-a, ostale obavezne elemente, ali i sve specifične situacije (veza sa avansom ili dokumentom koji se stornira, na primer). Dodatno, XML fajl sadrži puno opcionih elemenata, pa treba sagledati primenu istih i potrebe kupaca u tom delu.
Mnoga softverska rešenja su podržavala proces generisanja XML fajlova po starim verzijama fiskalizacije. Novim zakonskim promenama definisane su određene izmene u strukturi fajlova, pa je neophodno implementirati te izmene (na primer, moraju se koristiti šifarnici po EU normama, kao što su vrste dokumenata, šifre valuta, jedinice mere, klasifikacije poreza,…).
Poseban izazov postoji sa implementacijom procesa slanja informacija o plaćanju računa.
Koliko će procesi obrade ulaznih i izlaznih računa korisnicima biti olakšani ili otežani nakon ove izmene? Koliko je obično trajao proces do potpunog uhodavanja svih korisnika u drugim zemljama?
Da li će proces biti olakšan ili otežan, zavisi od mnogo faktora (obima dokumenata, organizacije procesa, specifičnosti koje kompanija ima u procedurama izrade i slanja/prijema faktura, poslovnog softvera koji se koristi). Generalno, procesi će biti olakšani, jer se dokumenta dobavljača automatski učitavaju (što je mnogo brže od ručnog unosa), a izlazna dokumenta automatski šalju (i to odjednom veći broj dokumenata, za razliku od štampe, kovertiranja i fizičkog slanja ili izrade različitih mejlova).
Što se tiče procesa uhodavanja, praksa pokazuje da se korisnici brzo navikavaju na nove opcije, pod uslovom da se u toku implementacije dobro sagledaju procesi i specifičnosti. U okolnim zemljama su se dešavale situacije naknadnih promena propisanih tehničkih specifikacija (strukture XML fajlova) nakon početka primene eRačuna. Ovakve stvari otežavaju proces, jer se mnogo toga menja u hodu i često korisnici nisu sigurni da li je neki problem nastao zbog podataka ili tehničkih promena. U Hrvatskoj deluje da su svi detalji propisani dosta unapred i ovakve situacije ne bi trebalo da se dešavaju. Stoga, opet uz ogradu da se koriste kvalitetna poslovna rešenja i adekvatno implementiraju procesi i specifičnosti, očekujemo kratak period adaptacije korisnika.
Iz ugla krajnjeg korisnika, da li je za implementaciju neophodno angažovanje informacionog posrednika, uz sva prilagođavanja u softveru?
Iako se teorijski može izbeći, za proces je neophodna registrovana pristupna tačka, što su upravo informacioni posrednici. Registracija pristupne tačke je proces, pa je fokus većine na korišćenju već registrovanih posrednika. To praktično znači da je korišćenje istih neophodnost. Proces Fiskalizacije 2.0 definisan je tako da svako pravno lice ima pristupnu tačku (registrovanog informacionog posrednika) preko koga se vrši slanje i prijem eRačuna. U periodu leta 2025. godine, korisnici bi trebalo da izaberu svog posrednika.
Međutim, posrednik obrađuje informacije (elektronske odnosno XML fajlove) koje dobija od poslovnih softvera od i prema Poreskoj upravi. Međutim, poslovni softveri moraju generisati i čitati fajlove u formatu koji posrednici propisuju (poslovni softver se mora prilagoditi). Svi fajlovi za izlazne eRačune moraju biti generisani iz poslovnih softvera, uz poštovanje strukture i svih specifičnosti podataka i situacija. Poslovni softver mora osigurati KPD klasifikaciju, poreske stope, vezu ka avansu/avansnom računu ili odobrenju i sve ostale obavezne i opcione elemente i takav fajl poslati posredniku.
Takođe, poslovni softveri moraju implementirati opcije za uvoz i prepoznavanje ulaznih računa. Stoga, dosta izmena jeste na poslovnim softverima i poslovni softveri nose veliku količinu logike procesa fiskalizacije, iako samu razmenu mora uraditi posrednik.
Kakva su iskustva o slanju priloga uz eRačune?
Prilozi uz eRačun su dozvoljeni. Uz svaki eRačun može se priložiti PDF vizualizacija računa, povezani dokument (porudžbina, otpremnica, ugovor, specifikacija) ili bilo koji drugi fajl. Svakako je uvek preporuka da se stave svi relevantni dodatni dokumenti koji prate eRačun.
Svaki prilog se dodaje unutar XML fajla ili kao eksterna veza. Dodaci se ne fiskalizuju, ali mogu biti korisni za internu obradu (kupcu).
S obzirom na to da je IN2 već prošao procese uvođenja eRačuna u drugim zemljama, koji su najveći izazovi za koje se treba pripremiti?
Iskustvo drugih zemalja nas uči da, pored same tehničke podrške procesu (razvoju i testiranju neophodnih i dodatnih opcija) treba obratiti pažnju na specifičnosti korisnika i kupaca. Na primer, mnoge kompanije izrađuju izlazne račune iz specijalizovanih softvera, koji se integrišu sa centralnim poslovnim softverom (ERP). U ovim situacijama, treba pažljivo sagledati proces i specifičnosti, pa odlučiti koji softver će (i u kom trenutku) raditi Fiskalizaciju. Slična je situacija sa kompanijama koje žele da u procesu Fiskalizacije 2.0 implementiraju proces uvoza ulaznih dokumenata, a koriste neke specijalizovane softvere (na primer, DMS) za obradu ulaznih dokumenata. I u ovom slučaju treba analizirati proces i definisati kako će isti izgledati nakon Fiskalizacije 2.0.
Za firme koje ne koriste dodatne softvere, već kompletne procese sprovode kroz jedan sistem, skrećemo pažnju na aspekt opcionih podataka u XML fajlovima. Praksa nas uči da zakon propisuje osnovnu strukturu XML fajlova, sa obaveznim elementima iz ugla zakona. Struktura, sa druge strane, omogućava i dosta opcionih podataka. Kako će mnogi kupci automatski učitavati račune koje im izdate, mogu imati pitanja ili zahteve za određenim specifičnim elementima računa (kao što su napomene, šifre proizvoda kod kupaca, dodatne reference na brojeve dokumenata, broj ugovora, način prikaza popusta, EAN kodove, GLN brojeve ili bilo koji drugi specifičan podatak). Treba sagledati ove specifičnosti i iste implementirati u XML fajl.
Stoga, važno je XML fajl koji generiše poslovni softver ne posmatrati samo iz ugla zakonskog minimuma, jer to često neće biti dovoljno. Treba analizirati i dogovoriti i aspekt opcionih podataka, a posebno treba obratiti pažnju na situacije koje će važiti za sve kupce, u odnosu na situacije koje će važiti samo za generisane eRačune nekih kupaca.
Iskustveno, neki od ovih elemenata će se razrađivati i dopunjavati i tokom vremena, odnosno kroz korišćenje novog procesa, ali je poželjno analizu i pripremu osnovnih scenarija uraditi u toku uvođenje izmene.
