Fiskalizacija 2.0 - odgoda, fijasko ili sposobnost bez premca

Uvođenje Fiskalizacije 2.0, koja podrazumijeva obvezno slanje B2G i B2B računa u XML formatu kroz sustave posrednika i Porezne uprave, predstavlja golem tehnički i operativni skok. S obzirom na to da su zadani izrazito ambiciozni rokovi, a sustav kompleksan uz primjenu na bazi od nekoliko stotina tisuća pretežito mikro poslovnih subjekata, koji u pravilu nemaju IT podršku, nekoliko je ključnih točaka koje mogu postati kritične:

1. Uska grla kod proizvođača softvera (ERP-ova)

Većina poslovnih subjekata u Hrvatskoj ovisi o vanjskim developerima poslovnih sustava.

• Problem: Zbog kratkih rokova, programeri moraju u isto vrijeme nadograditi sustave za tisuće klijenata.
• Posljedica: Softverska rješenja mogu biti "izbačena" na tržište bez dovoljno testiranja, što dovodi do bugova u produkciji, krivog izračuna poreza, upitne klasifikacije poreznih osnovica, poslovnih procesa, KPD oznaka, neuspješnog slanja računa ili kao nedavno nemogućnosti predaje PDV obračuna radi izostanka nadogradnje sustava Porezne uprave na nove šifre djelatnosti.

2. Tehnička nestabilnost sustava (Padovi servera)

Fiskalizacija 2.0 drastično povećava broj transakcija koje sustav Porezne uprave i posrednika mora obraditi u sekundi.

• Problem: Ako centralni sustav nije spreman na "peak" opterećenja (npr. oko 10. u mjesecu kada se šalje najviše računa), može doći do zagušenja.
• Posljedica: Nemogućnost slanja računa u realnom vremenu, što izravno zaustavlja poslovanje, pogotovo u segmentu veleprodaje i logistike. Neke tvrtke osiguravaju sredstva za plaće bez akumulacije rezervi od mjeseca do mjeseca, a izostanak pravovremenog slanja i naplate računa, može dovesti do nemogućnosti isplate plaća.

3. Problemi s digitalnim certifikatima i potpisima

Sustav se oslanja na stroge sigurnosne protokole.

• Problem: Kratki rokovi ne ostavljaju dovoljno vremena korisnicima da nabave adekvatne certifikate ili da ih podrška ispravno integrira u softver.
• Posljedica: Računi koji su "tehnički ispravni", ali ih sustav odbija jer potpis nije validan, što stvara pravni vakuum (je li račun u prometu ili nije?).

4. Operativni kaos u računovodstvu

Fiskalizacija 2.0 uvodi nove KPD šifre, kao i nove statuse poslovnih procesa i računa.

• Problem: Korisnici koji rade s računima nisu prošli obuku za nove procese u vezi izdavanja i razmjene računa, a računovodstveni servisi su zatrpani upitima.
• Posljedica: Pogrešan unos podataka, npr. kriva šifra oslobođenja od PDV-a ili pogrešna KPD šifra, koji se automatski bilježe u sustavu Porezne uprave, što povećava rizik od kazni ili poreznog nadzora.

5. Problem s "odbijenim" računima i likvidnošću

U starom sustavu, ako ste pogriješili na PDF računu, mogli ste ga poništiti i poslati novi uz dogovor s partnerom.

• Problem: U XML svijetu, ako sustav odbije račun zbog tehničke pogreške, on pravno ne postoji, iako nije storniran, ukoliko tehnički proces koji vraća informaciju izdavatelju ne funkcionira za taj scenario. 
• Posljedica: Kupac ne može platiti račun koji nije prošao sustav, a prodavatelj ne može naplatiti svoja potraživanja, a niti ponoviti slanje dok se tehnički problem ne riješi, što izravno ugrožava likvidnost tvrtke.

6. Nedostatak vremena za "Sandboxing" (Testnu fazu)

Svaka velika IT implementacija zahtijeva barem 3-6 mjeseci testne faze u realnim uvjetima. EU za projekt ovakvih razmjera predviđa min. 18 mjeseci za implementaciju, a ne 6 mj. što se pokušava provesti u RH.

• Problem: Zbog kratkih rokova, testna faza se preskače ili skraćuje.
• Posljedica: Sve greške koje su trebale biti otkrivene u testiranju postaju "live" problemi koji se rješavaju dok tvrtka pokušava raditi. Poduzetnici pomoć traže od knjigovodstva ili ERP isporučitelja, koji nisu projektirali sustav niti radili workflow.

7. Ovisnost o informacijskim posrednicima

Mnogi subjekti koriste posrednike za slanje eRačuna.

• Problem: Ako posrednik ima tehnički problem, tisuće tvrtki ostaju blokirane.
• Posljedica: Centralizacija rizika – kvar kod jednog posrednika znači prestanak rada za ogroman broj poslovnih subjekata.

Izgleda li niži graf kao scenarij koji je moguće razviti i implementirati u 6 mj. uz sinkronizaciju svih subjekata koji međusobno trebaju surađivati na tehničkoj razini?