{"text_format":"2","workbook":"xls","n_sheets":1,"sheets":["EConReport"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":0,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900","formulas":"cached_only"}

{"sheet":"EConReport","index":0,"n_rows":24,"n_cols":6,"rows_kept":24,"cut":false,"hidden":false,"merged":[[0,0,0,5]],"flags":["formulas_cached_only"]}
["Izvješće o provedenom savjetovanju - Savjetovanje o Pravilniku o eRačunu"]
[]
["Redni broj","Korisnik","Isječak","Komentar","Status odgovora\n","Odgovor"]
[1,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 1.","Predlažemo dodatno pojašnjenje:\n • roka čuvanja podataka,\n • tko sve osim Porezne uprave ima pristup tim podacima,\n • kako poduzetnici mogu uvidjeti što je evidentirano.\n\nTransparentnost i pravo na uvid podatke važno je jasno definirati, osobito za manje subjekte koji nisu tehnološki potkovani."]
[2,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 2.","U ovom članku navodi se kako subjekti mogu pristupiti podacima koji se evidentiraju u Sustavu za fiskalizaciju putem FiskAplikacije, bez potrebe za prethodnim zahtjevom. Iako ova intencija ide u dobrom smjeru, u tekstu nedostaju ključni elementi koji bi poduzetnicima omogućili stvarno i učinkovito korištenje tog prava"]
[3,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 3. ","U članku se predviđa da korisnici koji žele pristupiti podacima iz sustava fiskalizacije podnose zahtjev, a da će podaci biti isporučeni u formatu CSV na fizičkom mediju.\nTo tehnički zadovoljava minimum, ali u praksi bi ovakav pristup moga predstavljati izazov – posebno za poduzetnike koji već rade u digitalnim sustavima (ERP-ovi, cloud alati itd.) i očekuju brži i sigurniji prijenos podataka.\n\nPraktični primjer\n\nZamislimo firmu koja ima 3000 računa mjesečno. Želi preuzeti sve statuse fiskalizacije zbog interne kontrole, revizije ili knjigovodstva. Preuzimanje putem fizičkog medija (USB, CD) je:\n • logistički nezgodno (čeka se isporuka),\n • potencijalno nesigurno (gubitak, oštećenje, virus),\n • nekompatibilno s načinom rada većine suvremenih poslovnih softvera.\n\nU poslovnoj praksi danas svi sustavi već komuniciraju putem API-ja, portala ili online sučelja – i to bi se trebalo primijeniti i ovdje.\n\n\n\n\n⸻\n\n\n\n\nPrijedlozi za poboljšanje:\n 1. Osigurati online pristup podacima – putem portala s autentifikacijom (npr. eGrađani, poslovni certifikati).\n 2. Omogućiti preuzimanje u različitim formatima – CSV, JSON, XML – ovisno o korisničkim potrebama.\n 3. Dodati mogućnost API pristupa za veće korisnike koji žele automatizirano povlačenje podataka iz fiskalnog sustava u svoj softver.\n 4. Minimalizirati fizičku distribuciju podataka – osim ako korisnik izričito ne traži takvu opciju.\n\nZašto ovo nije tehničko pitanje nego stvar korisničkog iskustva:\nAko želimo da poduzetnici aktivno nadziru vlastito poslovanje i pravovremeno otkrivaju greške u fiskalizaciji, tada im treba omogućiti brz, pregledan i jednostavan pristup vlastitim podacima. Fizički medij za takve potrebe više nije praktičan – ni za male ni za velike korisnike."]
[4,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 4.","Što bi trebalo dodatno pojasniti:\n 1. Tko sve mora implementirati ovaj proces?\n • Mora li ga razumjeti i mikro poduzetnik koji koristi besplatni eRačun portal?\n • Ili se odnosi isključivo na informacijske posrednike i ERP integracije?\n 2. Što ako jedan od koraka zakaže?\n • Tko je odgovoran ako pristupna točka izdavatelja ne uspije kontaktirati MPS?\n • Kako se obavještava korisnik ako eRačun nije uspješno isporučen?\n 3. Kako krajnji korisnik zna da je račun zapravo zaprimljen?\n • Hoće li dobiti status u svom ERP sustavu ili e-mail obavijest?\n • Postoji li centralni sustav za praćenje statusa razmjene poruka?\n\nFunkcionalno pojašnjenje (primjer za kontekst):\nZamislimo knjigovodstveni servis koji u ime 30 klijenata šalje eRačune. Ako jedan od primatelja nije registriran ili postoji greška u identifikatoru, eRačun neće biti isporučen. Ali ako nema jasne povratne informacije – korisnik to neće znati dok klijent ne pita gdje je račun. To može uzrokovati kašnjenja, neplaćanje ili nepotrebne nesporazume.\nPrijedlozi:\n 1. Dodati dijagram razmjene eRačuna u prilogu pravilnika – kako bi korisnici i implementatori lakše razumjeli proces.\n 2. Navesti tko je odgovoran za koji dio procesa (npr. posrednik, ERP, korisnik) i kako se obavještava o neuspjehu.\n 3. Uvesti obvezu obavijesti krajnjem korisniku u slučaju greške – bilo kroz ERP ili kroz pristupnu točku.\n 4. Predvidjeti “fallback” scenarij – što se događa ako sustav ne radi (npr. održavanje, prekid veze)?\n\nZaključno:\nIako je tehnički točan, članak treba dodatne funkcionalne opise i objašnjenja da bi ga poslovna zajednica mogla pratiti i implementirati u svakodnevni rad – osobito korisnici koji ovise o vanjskim dobavljačima softvera ili koriste jednostavne portale."]
[5,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 5.","Članak 5 propisuje korištenje Obrasca razmjene (MEP) One-Way/Push, ali to može ostaviti nedoumice među krajnjim korisnicima i IT implementatorima, osobito kod složenijih sustava.\n\n\n\n\nPrijedlozi i komentari:\n 1. Predlažemo pojasniti u članku ili u prilogu:\n\n\n\n\n • što točno podrazumijeva One-Way/Push razmjena u ovom kontekstu,\n • kako se to razlikuje od drugih modela (npr. Two-Way, Pull),\n • tko je tehnički odgovoran za konfiguraciju – informacijski posrednik, ERP provider ili krajnji korisnik.\n\n\n\n\n 2. Većina mikro i malih poduzetnika koristi posredničke servise (portale) i neće sami implementirati ove protokole. No, oni i dalje trebaju razumjeti tko za njih obavlja ovu tehničku funkcionalnost i što se događa ako isporuka ne uspije.\n 3. Preporuka je dodati pojašnjenje s praktičnim primjerom razmjene – npr. što znači “pushanje” računa s ERP-a izdavatelja prema primatelju, i kako korisnik može znati da je poruka stvarno stigla (potvrda, log, email, itd.).\n 4. Za velike korisnike ili one koji koriste vlastita rješenja, bilo bi korisno objaviti službeni dokument s tehničkim specifikacijama MEP One-Way/Push obrasca, kako bi mogli pravilno konfigurirati sustave i spriječiti tehničke pogreške.\n\nCilj komentara je povećati razumijevanje i smanjiti broj implementacijskih grešaka koje bi u praksi mogle izazvati odbijanje eRačuna ili narušiti poslovne procese"]
[6,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 6.","1. Ponavljanje stavka o certifikatu od CA-a u RH u točki (3) i (7) je nepotrebno – dovoljno je zadržati samo jedan.\n 2. U stavku (4) se spominje da je korištenje novijih verzija TLS-a moguće “nakon međusobnog dogovora”. Nije jasno tko točno mora dogovoriti – korisnici, ERP dobavljači, posrednici? Također, kako se to formalizira i prati u praksi?\n 3. Korisno bi bilo objaviti referentni dokument koji opisuje koji su TLS protokoli, verzije, cipher suite-ovi i druge postavke dozvoljeni – radi interoperabilnosti među svim sudionicima.\n 4. Također predlažemo uključiti smjernice za redovito ažuriranje sigurnosnih protokola, jer zastarjele verzije TLS-a mogu u budućnosti predstavljati sigurnosni rizik.\n 5. Iako se u stavku (5) i (6) propisuje korištenje porta 443, korisnicima bi moglo biti korisno pojasniti da se taj port koristi isključivo za HTTPS konekcije, te da moraju osigurati firewall i mrežne postavke koje to podržavaju.\n\nZaključno, članak je korak u dobrom smjeru, ali bi ga trebalo dopuniti s tehničkom dokumentacijom, jasnim primjerima i operativnim uputama kako bi implementacija bila jednostavna i široko prihvatljiva u praksi."]
[7,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 7.","Članak 7 sadrži više tehničkih i pravnih nedosljednosti koje bi mogle stvoriti prepreke u praksi, a neke odredbe su potencijalno neusklađene s eIDAS uredbom.\n 1. Stavak (6), koji propisuje da digitalni certifikati moraju biti izdani isključivo od strane pružatelja usluga povjerenja u Republici Hrvatskoj, je u suprotnosti s eIDAS uredbom. Prema članku 4. eIDAS-a, države članice ne smiju ograničavati pružanje usluga povjerenja koje potječu iz druge članice EU. Uredba (EU) br. 910/2014 ima izravnu primjenu i nadređena je nacionalnim pravilnicima. Isključivanjem certifikata iz drugih država članica krši se načelo slobodnog kretanja usluga (čl. 56. UFEU) i uvodi teritorijalna diskriminacija, što može biti osnova za upravni spor ili postupak pred Europskom komisijom.\n 2. Onemogućavanje korištenja osobnih kvalificiranih certifikata ovlaštenih osoba također nije u skladu s eIDAS uredbom, točnije s njezinim recitale-om (58) koji kaže da se kvalificirani potpis ovlaštenog predstavnika treba smatrati jednakovrijednim kvalificiranom elektroničkom pečatu pravne osobe. Pravilnik koji to onemogućava krši načelo tehnološke neutralnosti i funkcionalne ekvivalencije.\n 3. Stavak (5), prema kojem Porezna uprava provjerava je li dokument potpisan od strane ovlaštene osobe, u praksi je neprovediv. Kod aplikativnih certifikata, koji su već propisani kroz Pravilnik o fiskalizaciji, ne postoji veza između OIB-a osobe i certifikata – on glasi na pravnu osobu. Uređaj, softver ili ERP aplikacija koriste certifikat automatski. Sam proces fiskalizacije ne uključuje fizički potpis osobe, već automatizirani mehanizam. Takva provjera stvara dodatno administrativno opterećenje i nije tehnički opravdana.\n\n\nZaključno:\n • Stavak (6) bi trebao biti izmijenjen kako bi omogućio priznavanje kvalificiranih certifikata iz EU članica.\n • Korištenje osobnih kvalificiranih certifikata ovlaštenih osoba treba biti omogućeno sukladno eIDAS-u.\n • Stavak (5) treba izbaciti ili redefinirati jer tehnički i operativno nije provediv u praksi.\n\n\nU protivnom, postoji rizik od pravne neprimjenjivosti i potencijalnog spora na EU razini"]
[8,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 7.","Stavak \"(6) Digitalni certifikati koji nisu izdani od strane pružatelja usluge povjerenja/pouzdanih pružatelja usluga povjerenja u Republici Hrvatskoj\" je poprilično diskriminatoran i u suprotnosti sa eIDAS uredbom. Nadalje nemogućnost korištenja osobnih certifikata ovlaštene osobe je također u suprotnosti sa eIDAS uredbom.\n\n\n1. Hijerarhija pravnih propisa – temeljno načelo\n\nU pravnom poretku Republike Hrvatske, kao države članice Europske unije, vrijedi načelo hijerarhije propisa:\n\nPravo Europske unije\n\nuredbe EU imaju izravnu primjenu\n\nimaju nadređenost nad nacionalnim pravom, uključujući zakone i podzakonske akte\n\nUstav RH\n\nZakoni\n\nPodzakonski akti (pravilnici, uredbe, naputci)\n\nIz navedenog proizlazi jasno pravilo:\n\nPodzakonski akt (pravilnik) ne može ograničiti, izmijeniti ili derogirati prava i obveze koje proizlaze iz uredbe EU.\n\nTo proizlazi iz:\n\nčlanka 288. UFEU-a\n\nustaljene prakse Suda Europske unije (npr. Costa vs. ENEL, Simmenthal)\n\n2. Pravna priroda eIDAS uredbe\n\nUredba (EU) br. 910/2014 (eIDAS):\n\nima izravnu i obvezujuću primjenu u svim državama članicama\n\nne zahtijeva prenošenje u nacionalno zakonodavstvo\n\ndržave članice ne smiju uvoditi dodatne uvjete koji:\n\nograničavaju slobodno kretanje usluga povjerenja\n\ndiskriminiraju pružatelje ili sredstva iz drugih država članica\n\nPosebno je važan članak 4. eIDAS-a:\n\nDržave članice ne smiju ograničavati pružanje usluga povjerenja koje potječu iz druge države članice.\n\n3. Diskriminatornost stavka (6) Pravilnika\n\nCitirani stavak:\n\n„(6) Digitalni certifikati koji nisu izdani od strane pružatelja usluge povjerenja/pouzdanih pružatelja usluga povjerenja u Republici Hrvatskoj…“\n\n3.1. Teritorijalna diskriminacija\n\nOvakva formulacija:\n\nuvodi teritorijalni kriterij (RH)\n\nisključuje:\n\nkvalificirane certifikate izdane u drugim državama članicama EU\n\niako su izdani od kvalificiranih pružatelja upisanih u EU Trusted List (EUTL)\n\nTo je izravno protivno eIDAS-u, jer:\n\neIDAS uvodi međusobno priznavanje kvalificiranih sredstava i certifikata\n\nnacionalni propis ne smije uvoditi dodatni kriterij „države izdavatelja“\n\n3.2. Povreda načela slobodnog kretanja usluga\n\nTakva odredba:\n\npredstavlja skrivenu trgovinsku prepreku\n\nograničava tržišno natjecanje\n\npogoduje domaćim pružateljima usluga povjerenja\n\nTo je u suprotnosti s:\n\nčlankom 56. UFEU (sloboda pružanja usluga)\n\nčlankom 4. eIDAS uredbe\n\n4. Nemogućnost korištenja osobnih certifikata ovlaštene osobe\n4.1. Izričita odredba eIDAS-a – recital (58)\n\nCitirani recital (58) jasno navodi:\n\n„Kada je za transakciju potreban kvalificirani elektronički pečat pravne osobe, kvalificirani elektronički potpis ovlaštenog predstavnika pravne osobe trebao bi biti jednako prihvatljiv.“\n\nOvo nije deklarativna, već interpretativno obvezujuća odredba koja:\n\npojašnjava namjenu i doseg uredbe\n\nobvezuje nacionalna tijela na funkcionalnu ekvivalenciju\n\n4.2. Posljedice zabrane osobnih certifikata\n\nAko pravilnik:\n\nisključuje korištenje osobnog kvalificiranog certifikata ovlaštene osobe\n\ni inzistira isključivo na:\n\naplikacijskom certifikatu ili\n\nkvalificiranom elektroničkom pečatu pravne osobe\n\ntada:\n\nneopravdano ograničava pravo izbora sredstva povjerenja\n\nkrši načelo tehnološke neutralnosti\n\nizravno krši recital (58) eIDAS uredbe\n\n5. Pravna posljedica – neprimjenjivost sporne odredbe\n\nPrema pravu EU i praksi Suda EU:\n\nnacionalna tijela moraju zanemariti nacionalnu odredbu koja je u suprotnosti s uredbom EU\n\nčak i bez formalnog ukidanja pravilnika\n\nDrugim riječima:\n\nSporni stavak pravilnika ne može se zakonito primjenjivati u dijelu u kojem ograničava priznavanje EU kvalificiranih certifikata ili isključuje osobne kvalificirane potpise ovlaštenih osoba.\n\n6. Zaključak\n\nPravilnik kao podzakonski akt nema pravnu snagu derogirati ili ograničiti primjenu eIDAS uredbe\n\nTeritorijalno ograničenje na pružatelje iz RH je:\n\ndiskriminatorno\n\nprotivno eIDAS-u i pravu EU\n\nIsključenje osobnih kvalificiranih certifikata ovlaštene osobe:\n\nizravno krši recital (58) eIDAS uredbe\n\nTakve odredbe su pravno neprimjenjive i izložene:\n\nupravnom sporu\n\npostupku povrede prava EU (infringement)"]
[9,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 7.","Porezna nema mehanizma provoditi predloženu točku 5 niti bi se trebala sa time baviti: \"(5) Porezna uprava provjerava jesu li dostavljeni podaci potpisani od strane osobe koja je ovlaštena koristiti digitalni certifikat.\"\nTvrtka kupuje \"aplikativni\" certifikat koji ste ranije propisali kroz Pravilnik o fiskalizaciji, u njemu nema OIB-a osobe nego tvrtke. Certifikat preuzima \"skrbnik\" koji ga učitava u aplikaciju ili samoposlužni uređaj. U samoposlužnom uređaju fiskalne račune potpisuje sam uređaj, odnosno konobar unosi račun u uređaj, odnosno za eRačun osoba koja ima pristup ERP-u odnosno aplikaciji izdaje račun."]
[10,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 8.","potrebno razjasniti tehničke detalje oko upotrebe certifikata u praksi i uskladiti ih s postojećim načinima rada u ERP sustavima i informacijskim posrednicima, uz poštivanje GDPR i eIDAS regulative. Također, trebalo bi dodati pojašnjenje kako se evidentira ovlaštenje pristupne točke za potpisivanje u ime poreznog obveznika."]
[11,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 8.","U odnosu na (d) izgleda da će Porezni obveznik sastaviti svoju listu konobara. Uglavnom tvrtke prrate tko im izdaje račune, nije potrebno posebno propisivati Pravilnikom."]
[12,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 9.","Ovdje se Pravilnik bavi već ranijim Zakonskim obvezama pružatelje usluga od povjerenja pogotovo pod (b) i (c) \nZakon o provedbi Uredbe (EU) 2022/2065 Europskog parlamenta i Vijeća od 19. listopada 2022. o jedinstvenom tržištu digitalnih usluga i izmjeni Direktive 2000/31/EZ (Akt o digitalnim uslugama)\nIV. PRAVA, OBVEZE I ODGOVORNOSTI POTPISNIKA, PRUŽATELJA USLUGA POVJERENJA I IMATELJA SREDSTAVA ELEKTRONIČKE IDENTIFIKACIJE\nPravilnikom se nije potrebno baviti stvarima riješenim na razini EU Direktiva i Zakona i drugih postojećih Pravilnika."]
[13,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 10.","Ovaj članak uvodi obvezu povezivanja svih roba i usluga s KPD šiframa, što predstavlja važan dio digitalne fiskalizacije, ali zahtijeva pažljivo planiranje, edukaciju i tehničku podršku kako bi implementacija bila uspješna.\n 1. Povezivanje s KPD (točka a): Obveza da svaki artikl ima šesteroznamenkastu KPD oznaku je razumljiva radi standardizacije, no u praksi može biti izrazito zahtjevna. Posebno za subjekte s velikim brojem artikala ili onih koji nude složene, nestandardizirane usluge. Nužno je omogućiti jednostavne alate za mapiranje artikala prema KPD-u – npr. integraciju u ERP sustave ili otvorene API-je za provjeru i klasifikaciju.\n 2. Korisnost KLASUS tražilice (točka b): Spominjanje tražilice KLASUS je korisno, ali bi trebalo predvidjeti tehničku podršku i mogućnost preuzimanja baze u strojno čitljivom formatu (JSON/XML) radi integracije u poslovne sustave. Web tražilica nije dovoljna za veće sustave.\n 3. Povezivanje s drugim klasifikacijama (točka d): Pozitivno je da članak ne isključuje korištenje vlastitih klasifikacija, ali nije jasno što znači “povezati ih” s KPD-om. Treba definirati je li to mapiranje jednoznačno, kako se tehnički provodi i gdje se dokumentira – npr. treba li se to prijaviti Poreznoj ili samo lokalno evidentirati.\n 4. Podaci kod odobrenja/popusta (točke 5, 6, g): Popis potrebnih podataka je detaljan, ali u praksi će njegovo prikupljanje i strukturiranje predstavljati izazov, pogotovo za one koji nemaju napredne ERP sustave. Potrebna je detaljna specifikacija s primjerima XML strukture i validacijskih pravila. Također, nije jasno što znači “ispravna oznaka vrste isprave i poslovnog procesa” – korisnici će trebati praktične primjere iz realnih situacija.\n\n\n\n\nNepoznato:\n • Nije jasno hoće li Porezna objaviti službeno “mapiranje” između često korištenih usluga i KPD šifara kao vodič.\n • Također, nije definiran prvi rok do kojeg se ovo mora implementirati i kako će se postupati s greškama kod pogrešnog označavanja.\n\n\n\n\nPreporuka:\n • Prvo razdoblje provedbe treba predvidjeti sustav “upozorenja” bez sankcija, kako bi se korisnici educirali i imali vremena ispravno klasificirati svoje proizvode i usluge.\n • Potrebna je javno dostupna tehnička dokumentacija s primjerima i alatima za validaciju eRačuna s KPD oznakama"]
[14,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 11. ","Pozdravljamo mogućnost fleksibilnosti za fiskalizaciju eRačuna u slučaju masovnog i kontinuiranog fakturiranja, no potrebno je preciznije normirati nekoliko ključnih elemenata kako bi se spriječila neujednačena primjena i potencijalni nesporazumi.\n 1. Pojam “posebnog društva” nije definiran. Preporučujemo jasno definiranje – odnosi li se to na infrastrukturne operatere, javna poduzeća, komunalne službe, telekome, energetski sektor ili bilo koju tvrtku s velikim obujmom ponavljajućih računa?\n 2. Uvođenje formalnog kriterija za korištenje ove iznimke. Primjerice, prag od 500+ računa dnevno ili obveza ponavljajuće mjesečne fakturacije prema unaprijed sklopljenim ugovorima. Time bi se osigurala transparentnost i pravedna primjena iznimke.\n 3. Obveza evidentiranja odluke o odgodi. Predlažemo da poduzetnik koji koristi ovo pravilo ima internu evidenciju razloga i obujma odgođene fiskalizacije, za eventualni inspekcijski nadzor.\n 4. Jasno definirati radi li se o tri radna dana ili kalendarska. U praksi može doći do zabune:\n • Ako je račun izdan petkom, a slijedi vikend i ponedjeljak je državni praznik, može proći i pet dana do fiskalizacije. Stoga predlažemo jasno propisivanje da se radi o radnim danima, te da se, ako zadnji dan pada na neradni dan, rok automatski pomiče na prvi sljedeći radni dan."]
[15,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 12.","za potpunu funkcionalnost u realnim uvjetima potrebno je dodatno normirati sljedeće:\n 1. Obavezna tehnička dokumentacija. Uz popis grešaka, potrebno je javno objaviti sve sheme i tehničke upute kako bi svi sustavi (posebno oni manjih ERP providera) mogli pravilno reagirati i implementirati automatsko prepoznavanje i ispravak grešaka.\n 2. Dodati primjer poruke za svaku grešku. Sam naziv greške nije dovoljan – preporučujemo da za svaku vrstu greške bude prikazan XML primjer stvarne poruke (input i output) radi brže implementacije.\n 3. Razlikovanje između kritičnih i nekritičnih grešaka. Predlaže se kategorizacija grešaka po težini (npr. warning vs error), jer neke greške možda neće spriječiti obradu računa, ali bi trebale biti označene (npr. stil ili nepotpun metapodatak).\n 4. Uvođenje sustava upozorenja. Prije prve kazne ili odbijanja računa, korisniku (ili njegovom ERP sustavu) bi se mogla dostaviti poruka upozorenja kako bi se ispravila pogreška bez posljedica, posebno u prijelaznom razdoblju ili prvoj godini primjene"]
[16,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 12.","Ovdje je Zakonodavac predvidio nekoliko mogućnosti logičke pogreške kod eRačun, u tehničkoj implementaciji će ih biti više i korisno je predati drugoj strani cjelokupni \"stack trace\" radi jednostavnije dijagnostike. Pravilnikom definirati 'troubleshooting' aplikacije bi moglo biti dosta nezahvalno, a  i pomalo neizvedivo."]
[17,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\n Članak  13.","Odredba traži od izdavatelja i primatelja eRačuna da u slučaju greške evidentiraju problem i ponovno pošalju ispravnu poruku. Međutim, u stvarnosti ovakav proces uključuje informacijskog posrednika (pristupnu točku) koji je tehnički prvi u lancu zaprimanja poruka o grešci – a ne krajnjeg korisnika.\n\n\n\n\nPrijedlozi:\n 1. Jasna obveza informacijskog posrednika: Posrednik je taj koji prima poruku o grešci i stoga mora imati obvezu:\n • da bez odgode proslijedi tu grešku korisniku,\n • i to u standardiziranom obliku, s originalnim sadržajem greške (bez interpretacije ili prevođenja).\n 2. Jedinstvena i precizna poruka: Sustav za fiskalizaciju mora vraćati jedinstvenu, strukturiranu poruku o grešci koja uključuje:\n • šifru greške,\n • opis problema,\n • uputu za ispravak.\nTakva poruka mora biti identična za sve informacijske posrednike, kako ne bi dolazilo do proizvoljnih tumačenja i konfuzije korisnika.\n 3. Evidentiranje greške treba jasno specificirati: što se smatra ispravnom evidencijom? Log zapis? Automatska notifikacija korisniku? Također, treba navesti obvezu čuvanja tih zapisa za moguće kontrole.\n 4. Od kada teče rok? Rok za ispravak greške mora početi tek nakon što krajnji korisnik zaprimi obavijest od informacijskog posrednika, ne od trenutka kada je greška nastala. U protivnom, korisnik bi mogao biti sankcioniran zbog kašnjenja koje nije mogao kontrolirati.\n 5. Uhodavanje i praksa: U prijelaznom razdoblju nužno je omogućiti sustav upozorenja bez kazni, jer ni posrednici ni korisnici neće odmah imati uhodane tehničke procese."]
[18,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 14.","Uvođenje aplikacije MIKROeRAČUN predstavlja pozitivan korak prema digitalizaciji, no trenutno je definirana preusko i isključujuće, i to bez dovoljno opravdanja. Predlažemo sljedeće izmjene i pojašnjenja:\n 1. Zašto je alat ograničen samo na određene korisnike?\nPostoji već portal za eRačune (centralna pristupna točka) – zašto tada ne bi i ova aplikacija bila dostupna širem krugu korisnika?\nOgraničavanje samo na one izvan PDV-a i izvan javne nabave može stvoriti nepotrebne prepreke za:\n • Početnike bez ERP-a i budžeta\n • Male firme koje tek ulaze u sustav PDV-a\n • Udruge i druge neprofitne subjekte koji nemaju znanja ni sredstva za napredne sustave\n 2. Ako je zakon obvezujući – država mora omogućiti besplatno osnovno sredstvo za njegovu provedbu.\nU suprotnom se trošak tehničke provedbe zakona prebacuje na poduzetnike, koji već snose mnoge druge fiskalne i administrativne obveze.\nDigitalni prijelaz mora biti jednak za sve i ne smije ovisiti o financijskoj moći, jer se time uvodi diskriminacija.\n 3. Prijedlog rješenja:\nAko aplikacija MIKROeRAČUN mora ostati ograničena zbog tehničkih ili sigurnosnih razloga – predlažemo da se:\n • Razmotri širenje uvjeta pristupa\n • Omogući jednostavna, ali ograničena verzija portala za sve koji nemaju sredstva za ERP ili informacijske posrednike\n 4. Uvođenje zakona ne smije dovesti do obveznog plaćanja trećim stranama.\nKao što zakon o fiskalizaciji nalaže obavezu razmjene i prijenosa eRačuna, tako država mora osigurati minimalne uvjete za besplatno korištenje tog sustava, bez uvjetovanja integracijama koje korisnik mora platitiI"]
[19,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 16. ","1) U tekstu se navodi:\n\n\n\n\n“Primatelj odnosno izdavatelj eRačuna dužan je pohranjivati eRačune sukladno članku 35. Zakona […]”\n\n\n\n\nPotrebno je precizirati puni naziv zakona. Trenutno je formulacija nejasna jer ne navodi kojem zakonu članak 35. pripada. Preporučuje se izrijekom navesti:\n\n\n\n\n“sukladno članku 35. Zakona o fiskalizaciji u prometu gotovinom”\nili točno navesti zakon kojem članak pripada kako bi se izbjegle pravne i tehničke nejasnoće.\n\n\n\n\n(2) Nadalje, u slučaju prestanka korištenja aplikacije, nije jasno:\n • Kako korisnik može ponovno pristupiti svojim podacima?\n • Postoji li automatizirani način preuzimanja svih podataka (npr. putem API-ja)?\n • Što ako korisnik izgubi pristup aplikaciji – postoji li mehanizam oporavka?\n • Trebalo bi jasno propisati rokove za preuzimanje dokumenata te predvidjeti sigurnosne mehanizme za takve slučajeve (npr. read-only pristup barem 30 dana nakon deaktivacije računa).\n\n\n\n\n(3) Važno je definirati:\n • Može li se XML verzija računa preuzeta iz aplikacije smatrati zakonski priznatim dokumentom za potrebe revizije, poreznog nadzora i knjigovodstva?\n • Da li arhiva unutar aplikacije zadovoljava zakonske uvjete za e-Arhivu (npr. u skladu s propisima o arhiviranju u elektroničkom obliku – Zakon o računovodstvu, pravilnici Porezne uprave, itd.)?\n • Također, korisnicima bi se trebao omogućiti alternativni način pristupa dokumentima, npr. preuzimanje u bulk formatu, e-Arhiva dostupna putem posebnog linka, mogućnost eksportiranja i pohranjivanja lokalno.\n\n\n\n\n(4) Treba razmotriti i:\n • Da li aplikacija pruža korisnicima obavijest prije prestanka čuvanja podataka?\n • Ako da, u kojem roku i na koji način? (e-mail, obavijest unutar sustava, itd.)\n • Treba jasno reći: koji su podaci izbrisivi, a koji ostaju dostupni i u kojem formatu."]
[20,"KRUNOSLAV HRNJAK","PRAVILNIK O eRAČUNU,\nČlanak 16. ","Po isteku roka čuvanja eRačuna definiranog Zakonom prestaje zakonska obveza čuvanja eRačuna pa je nejasno zašto bi se onda propisivalo preuzimanje računa. Eventualno formulirati tako da je Primatelj odnosno izdavatelj eRačuna dužan je pohranjivati eRačune sukladno članku 35. Zakona te preuzeti sve eRačune u periodu u kojem informacijski posrednik omogućava preuzimanje istih (ukoliko nije ugovorena usluge eArhive). Također bilo bi poželjno definirati određeni period u kojem je informacijski posrednik dužan omogućiti pristup eRačunu (osim trenutka inicijalnog preuzimanja)."]
[21,"ANDREJA ŠTURLAN","PRAVILNIK O eRAČUNU,\nČlanak 21.","Zahtjev u ovom obliku je zastario i nepraktičan za svakodnevnu upotrebu. Previše je birokratski i podrazumijeva ručnu obradu, čekanje i slanje dokumenta. U kontekstu digitalne fiskalizacije, ovakav način pristupa podacima nema smisla. Umjesto toga, treba omogućiti ovlaštenim korisnicima (npr. informacijskim posrednicima ili poduzetnicima putem ePorezne) automatsko generiranje i preuzimanje potrebnih podataka u strukturiranom formatu (npr. XML, CSV), uz mogućnost autentifikacije i navođenja svrhe ako je to zakonski potrebno.\n\nAko su serveri trenutno nedostupni ili sustav pod opterećenjem, mora postojati mogućnost da korisnik zatraži podatke koji se zatim pripremaju u pozadini i budu dostupni za preuzimanje čim su spremni.\nSvrha digitalizacije je brži i jednostavniji pristup podacima – ovaj zahtjev ide u suprotnom smjeru."]