eRačuni 🔔
Tko i od kada točno ima obvezu slanja eRačuna?
Obveza se uvodi fazno, a ključno je razlikovati obvezu primanja od obveze slanja eRačuna.
Obveza PRIMANJA eRačuna
Od 1. siječnja 2026.: Obvezu zaprimanja eRačuna i provedbu fiskalizacije zaprimljenih eRačuna imaju svi primatelji eRačuna definirani Zakonom. To uključuje sve porezne obveznike (i one u sustavu PDV-a i one izvan njega) te tijela javne vlasti.
Obveza SLANJA eRačuna
Obveza slanja eRačuna uvodi se u dvije faze:
Od 1. siječnja 2026.: Obvezu slanja eRačuna imaju porezni obveznici sa sjedištem, prebivalištem ili uobičajenim boravištem u tuzemstvu koji su upisani u registar obveznika PDV-a.
Od 1. siječnja 2027.: Obveza slanja eRačuna proširuje se i na preostale skupine poreznih obveznika koji nisu upisani u registar obveznika PDV-a.
Kada moram izdati eRačun (F2.0), a kada primijeniti fiskalizaciju u krajnjoj potrošnji (F1.0)? Koji sustav koristiti ovisno o kupcu (B2B ili B2C) i načinu plaćanja (gotovina, kartica, transakcijsko)?
Primjena sustava ovisi o tome tko je kupac (B2C ili B2B) te, u B2B segmentu, o načinu plaćanja.
A. Fiskalizacija u krajnjoj potrošnji (F1.0) - B2C
Ovo je sustav namijenjen poslovanju s građanima (potrošačima).
Obveza: Primjenjuje se kada obveznik fiskalizacije (obveznik poreza na dohodak od samostalne djelatnosti ili poreza na dobit) izdaje račun građaninu u prometu u krajnjoj potrošnji.
Način plaćanja: Od 1. siječnja 2026. obveza F1.0 vrijedi za sve načine plaćanja, uključujući gotovinu, kartice, transakcijski račun i ostalo.
B. Izdavanje i fiskalizacija eRačuna (F2.0) - B2B i B2G
Ovo je sustav namijenjen poslovanju između poreznih obveznika (B2B) i s tijelima javne vlasti (B2G).
Obveza: Primjenjuje se za tuzemne transakcije kada je primatelj računa drugi porezni obveznik (bez obzira je li u sustavu PDV-a ili ne) ili tijelo javne vlasti.
Napomena o uvođenju: Obveza slanja eRačuna za obveznike upisane u registar PDV-a kreće 1. siječnja 2026.. Za obveznike koji nisu upisani u registar PDV-a (obveznici poreza na dohodak/dobit) te za tijela javne vlasti izvan sustava PDV-a, obveza slanja kreće 1. siječnja 2027..
Način plaćanja: Ovo je obvezan sustav za B2B transakcije koje se plaćaju transakcijski (virmanski).
C. Iznimka: Primjena F1.0 u B2B poslovanju
Zakon definira iznimku kada se B2B transakcija ne mora provesti kroz F2.0 (eRačun), već se umjesto toga primjenjuje F1.0.
Uvjet: Transakcija se mora plaćati gotovinom ili karticom.
Postupak: U tom slučaju, izdavatelj je dužan provesti postupak fiskalizacije u krajnjoj potrošnji (F1.0). Pritom mora u sustav za fiskalizaciju dostaviti i OIB primatelja računa.
Važno: Ako se primijeni ovaj postupak (F1.0), za tu transakciju ne može se izdati i fiskalizirati eRačun (F2.0).
👉 Primjena u Luceedu
Za račune iz modula Veleprodaja, bit će omogućeno da se prema tipu komitenta (partnera) automatski određuje je li kupcu potrebno poslati eRačun, odnosno primjenjuje li se F1.0 ili F2.0 postupak fiskalizacije.
Za račune iz modula Maloprodaja, bit će omogućeno da izdavatelj, u slučaju plaćanja gotovinom ili karticom, odabere postupak koji će se provesti (slanje i fiskalizacija eRačuna (F2.0) ili fiskalizacija računa u krajnjoj potrošnji (F1.0)), dok je u slučaju transakcijskog plaćanja obvezno slanje eRačuna.
Moraju li B2C (F1.0) računi i B2B (F2.0) eRačuni imati odvojenu slijednost brojeva?
Koristimo Luceed ERP i izdajemo račune za krajnju potrošnju (B2C) koje fiskaliziramo prema F1.0 pravilima, ali i eRačune poslovnim partnerima (B2B) koje ćemo trebati fiskalizirati prema F2.0 pravilima. Moramo li zbog toga definirati dva odvojena naplatna uređaja i imati dvije odvojene slijednosti brojeva?
Ne, odvojena slijednost nije obavezna. Možete koristiti jedinstvenu slijednost brojeva za obje vrste računa, za jedan naplatni uređaj.
To je potvrdila i Porezna uprava (u službenom odgovoru na Pitanje br. 27), koja je navela da iako se radi o dva različita procesa:
Ukoliko se na tržištu razvije rješenje koje će u jednom postupku imati ta dva različita programska rješenja, teoretski slijednost računa bi mogla biti ista, uz uvjet da je navedeno propisano internim aktom.
Luceed ERP je upravo takvo rješenje. Sustav prepoznaje o kojoj se vrsti računa radi (B2C ili B2B) te automatski primjenjuje ispravan postupak (slanje JIR-a za F1.0 ili slanje eRačuna za F2.0), sve unutar jednog naplatnog uređaja i jedinstvene slijednosti brojeva.
Važno je samo da u svom internom aktu propišete da koristite jedinstvenu slijednost na tom naplatnom uređaju, oslanjajući se na mogućnosti svog ERP sustava.
Službeni odgovor PU (br. 27.):

Mogu li izdati eRačun u tekućem mjesecu, a da obveza PDV-a pripada prethodnom mjesecu?
U poslovanju se često događa da se oporezivi događaj (isporuka dobara, obavljanje usluge ili primitak uplate predujma) dogodi u jednom obračunskom razdoblju, dok se račun za tu transakciju izdaje u sljedećem razdoblju.
Prema Zakonu o PDV-u, ključan podatak za ispravan obračun PDV-a je datum isporuke dobara ili obavljenih usluga (ili datum primitka predujma). PDV prijava popunjava se isključivo prema datumu nastanka oporezivog događaja.
Budući da računi s transakcijskim plaćanjem (B2B segment) do sada nisu podlijegali fiskalizaciji, u nekim se slučajevima prakticiralo se ručno mijenjanje datuma nastanka porezne obveze (u Luceedu polje Datum) na datum iz prethodnog mjeseca, iako je sam račun kreiran u tekućem mjesecu. Iako sistemski datum i vrijeme kreiranja dokumenta (polje Kreiran) nisu bili promjenjivi, ovaj ključni datum za PDV jest.
S uvođenjem Fiskalizacije 2.0, svaki izdani eRačun bit će fiskaliziran, čime Datum postaje nepromjenjiv. To znači da nakon što je račun jednom izdan i poslan (pri tome fiskaliziran), više neće biti moguće mijenjati datum nastanka porezne obveze. Time dosadašnja praksa naknadne izmjene tog datuma više nije moguća.
Pitanje: Kako, unutar novih pravila, izdati ispravan i zakonski usklađen eRačun u tekućem mjesecu, a da se obveza PDV-a nedvojbeno odnosi na prethodno razdoblje?
👉 Primjena u Luceedu
Ispravan i zakonski usklađen eRačun u ovakvoj situaciji izdaje se primjenom standardiziranog principa razdvajanja datuma izdavanja od datuma nastanka porezne obveze. Sustav eRačuna i Fiskalizacije 2.0 zapravo samo formalizira princip koji Luceed već primjenjuje.
Ključno je razumjeti i ispravno koristiti dva datuma na računu:
Datum i vrijeme IZDAVANJA: Ovo je stvarni, sistemski zabilježen i nepromjenjiv trenutak kada je račun kreiran u Luceedu (podatak iz polja Kreiran). S uvođenjem Fiskalizacije 2.0, ovaj podatak postaje službeni datum i vrijeme izdavanja računa koji se šalje Poreznoj upravi.
Datum nastanka OBVEZE PDV-a: Ovo je datum isporuke, obavljene usluge ili primitka predujma. To je datum iz polja Datum na računu i on određuje u koje obračunsko razdoblje ulazi obveza PDV-a.
Nakon slanja eRačuna, datum nastanka obveze PDV-a (polje Datum) neće biti moguće mijenjati. Zato je važno odabrati ispravan proces u Luceedu prije izdavanja računa.
Mogućnost unosa datuma nastanka porezne obveze ovisi o poslovnom procesu. Primjerice, prilikom generiranja računa iz jedne ili više otpremnica, Luceed vam omogućuje odabir datuma u polju Datum. S druge strane, kod snimanja isporuke direktno računom (npr. iz naloga prodaje) to nije moguće jer se podrazumijeva da je isporuka nastala na dan kreiranja računa.
Neovisno o poslovnom procesu, kada je zaprimljena avansna uplata u jednom obračunskom razdoblju, a isporuka i konačni račun slijede u idućem, ispravno i zakonski obvezujuće rješenje je izdavanje računa za predujam. Račun za predujam se izdaje s datumom primitka uplate, čime se obveza PDV-a ispravno evidentira u pripadajućem mjesecu.
Kako bi se izbjeglo ručno kreiranje računa za predujam, Luceed nudi i automatizirano rješenje kroz opciju Povezivanje uplata s dokumentima. Ovaj proces, ovisno o postavkama, može automatski kreirati račun za predujam na datum uplate, a prilikom izrade konačnog računa automatski će izvršiti i njegovo storniranje. Time se osigurava potpuna usklađenost uz minimalan napor.
Važna napomena
Svjesni smo da će nemogućnost naknadne izmjene podataka na poslanim eRačunima utjecati na dosadašnje radne procese. Stoga u Tomsoftu analiziramo mogućnost uvođenja opcije odgođenog slanja (i fiskalizacije) eRačuna.
Takva bi funkcionalnost, unutar zakonski propisanih rokova, osigurala vremenski period za provjeru i eventualne ispravke podataka na računu, uključujući i datum nastanka porezne obveze (polje Datum), prije nego što se račun fiskalizira i postane nepromjenjiv.
O svim budućim opcijama bit ćete pravovremeno obaviješteni. Preporučujemo da pratite naše objave i dokumentaciju.
S početkom primjene obveznog slanja eRačuna, što da radim ako pošaljem eRačun koji kupac odbije (npr. zbog pogrešnog podatka)? Morat ću stornirati taj račun. Hoće li se time automatski stornirati i otpremnica, iako je roba ispravno isporučena?
U sklopu usklađenja s Fiskalizacijom 2.0, unaprijeđen je način storniranja veleprodajnih računa u Luceedu. Do sada je kod storniranja računa koji je automatski kreirao otpremnicu, sustav automatski stornirao i vezanu otpremnicu. To je u praksi otežavalo ispravke, osobito kada je eRačun odbijen od strane primatelja – korisnik je morao ponovno kreirati i otpremnicu i račun za ponovno slanje.
Sada je moguće stornirati veleprodajni račun bez storniranja postojeće otpremnice.
Na taj način, nakon odbijanja eRačuna, možete ispraviti podatke i ponovno izdati račun iz postojeće otpremnice, bez utjecaja na skladišne evidencije, datum isporuke i WMS pozicije.
Detaljan opis novog načina rada pronaći ćete u korisničkoj uputi:
📄 Storniranje veleprodajnog računa bez storniranja otpremnice
Gdje će u Luceedu biti moguće odabrati poslovni proces P99 i unijeti oznaku koju definira kupac?
U nadolazećoj verziji Luceeda bit će moguće odabrati poslovni proces P99 – “Poslovni proces koji definira kupac” na kartici Dodatni podaci, u polju Poslovni proces na svim veleprodajnim dokumentima i računima.
Kada se u polju Poslovni proces odabere
P99, sustav će automatski prikazati novo polje za slobodan unos: Oznaka kupca.U to ćete polje unositi točnu oznaku koju je kupac dostavio.
Polje za unos oznake kupca će biti obavezno ako je odabran
P99.Ako se odabere bilo koji drugi proces (
P1–P12), dodatno polje neće biti prikazano - ponašanje ostaje kao i dosad.
P99 se uvodi jer dio kupaca zahtijeva slanje vlastite oznake procesa u eRačunu, što je predviđeno novim specifikacijama koje stupaju na snagu 1.1.2026.
Hoće li biti omogućeno preuzimanje eRačuna direktno u knjigu URA u Luceedu?
Da. Preuzimanje eRačuna odvija se putem naše platforme Interconnect, koja komunicira s odabranim informacijskim posrednikom. Ovisno o tome koristite li naše DMS rješenje, proces se razlikuje u jednom koraku:
Korisnici bez Luceed DMS-a: Sustav će vam omogućuti da iz samog Luceeda pokrenete preuzimanje eRačuna s Interconnecta direktno u knjigu URA.
Korisnici s Luceed DMS-om: eRačuni s Interconnecta prvo dolaze u DMS na pregled i odobravanje (knjiženje, raspodjelu po mjestima troška, …). Nakon što su digitalno odobreni, sustav će ih automatizmom knjiži u URA-u unutar Luceeda, bez potrebe za ručnim preuzimanjem.
Mogu li putem Luceed API-ja preuzeti izlazne račune u UBL formatu?
Iako Luceed API nudi metode za dohvat podataka o računu (u standardnom JSON formatu) ili samog dokumenta u PDF-u, direktan dohvat računa u UBL formatu putem Luceed API-ja nije podržan.
Međutim, to ne znači da ne možete doći do željenih podataka. Za razmjenu i dohvat standardiziranih elektroničkih dokumenata (u UBL formatu) koristimo naše specijalizirano rješenje – Interconnect.
Što trebate učiniti?
Za postojeće Luceed korisnike: Ako želite preuzimati UBL datoteke (npr. za potrebe DMS sustava), potrebno je aktivirati odgovarajuću Interconnect uslugu. Slobodno nas kontaktirajte kako bismo vas uputili u proces aktivacije.
Za integratore (developere trećih strana): Ako razvijate rješenje koje treba dohvaćati UBL račune iz Luceeda, integraciju je potrebno napraviti s Interconnect API-jem, a ne direktno s Luceed API-jem. Sva potrebna tehnička dokumentacija za integraciju dostupna je na našem Documentation HUB-u.
Hoće li se u EDI razmjeni dokumenata (npr. s trgovačkim lancima) omogućiti slanje novih fiskalizacijskih podataka (KPD šifra, oznaka operatera, tip poslovnog procesa)?
Potrebno je razlikovati zakonski eRačun od komercijalne EDI razmjene.
Podaci kao što su Identifikator klasifikacije artikla - KPD (BT-158) , Oznaka operatera (HR-BT-4) i Tip poslovnog procesa (BT-23) su obvezni elementi propisani tehničkom specifikacijom uporabe eRačuna. Naš sustav će osigurati da su ti podaci uredno sadržani u eRačunu koji se šalje vašem kupcu kao službeni, zakonski valjan dokument, te iz kojeg se provodi fiskalizacija premu sustavu Porezne uprave.
Što se tiče samog EDI kanala (postojeći formati za razmjenu narudžbi, otpremnica i sl.), navedeni podaci nisu dio standardne strukture niti su nužni za komercijalnu i logističku obradu dokumenata u tom formatu. Budući da su ti podaci vezani isključivo uz porezni nadzor, oni će biti sadržani u XML-u eRačuna, dok se standardni EDI format u ovom trenutku neće proširivati tim specifičnim fiskalizacijskim elementima.
Ukratko: Zakonska usklađenost bit će osigurana kroz XML eRačun, dok EDI razmjena nastavlja funkcionirati prema dosadašnjim logističkim standardima.
Kako će se prilikom zaprimanja ulaznog eRačuna u URA znati u koju knjigu (roba, troškovi, osnovna sredstva) treba smjestiti taj račun?
Važno je naglasiti da eRačun ne sadrži sustavnu oznaku kojom bi se automatski moglo prepoznati radi li se o računu za osnovno sredstvo, robu, trošak ili neku drugu namjenu. Takva informacija nije standardizirani dio eRačuna i nije dostupna za automatsku obradu.
Zbog toga Luceed razvrstava ulazne eRačune isključivo prema tipu eRačuna i postavkama u šifrarniku Tipovi knjiga – URA. Sustav koristi sljedeći redoslijed:
Ako postoji korisnički definirana knjiga s postavljenim Tipom eRačuna, taj tip eRačuna smjestit će se u tu knjigu.
Ako takva knjiga ne postoji, primjenjuje se osnovno pravilo sustava:
380 – Račun, 381 – Odobrenje, 383 – Terećenje → Dobra i usluge u tuzemstvu
386 – Račun predujma → Dani predujmovi
Korisnici mogu prema potrebi dodati vlastite tipove knjiga i povezati ih s određenim tipovima eRačuna, čime se automatizira razvrstavanje prema poslovnim potrebama.
Više informacija dostupno je u korisničkoj dokumentaciji:
Luceed DMS (opcionalno)
Za korisnike koji budu koristili Luceed DMS (kada bude dostupan), bit će moguće dodatno definirati u koju knjigu URA se račun smješta, i to prema dodatnim kriterijima, primjerice prema dobavljaču ili putem ručnog odabira knjige prilikom obrade računa u DMS-u. Na taj način korisnici dobivaju potpunu kontrolu nad razvrstavanjem ulaznih računa, što nije moguće postići isključivo automatskim prepoznavanjem iz sadržaja eRačuna.
Luceed DMS je opcionalan za korištenje, a njegovo puštanje u produkciju planirano je početkom iduće godine.
Podržava li Luceed proces samoizdavanja računa u sustavu Fiskalizacije 2.0?
Ne, Luceed trenutno ne podržava automatizirani proces samoizdavanja računa (proces P12 u sustavu eRačuna).
S obzirom na visoku tehničku složenost implementacije ovog specifičnog procesa i relativno malu učestalost korištenja među našim korisnicima, odlučili smo da ovu funkcionalnost nećemo ugrađivati u sustav u ovoj fazi.
Što to znači za vas? Ako ste do sada koristili model samoizdavanja (bilo da ste vi izdavali račune u ime dobavljača ili je kupac izdavao račune u vaše ime), molimo vas da od 1. siječnja 2026. sa svojim poslovnim partnerima dogovorite prelazak na standardni način izdavanja računa.
To u praksi znači:
Ako ste vi dobavljač (npr. komitent): Vi morate kreirati i fiskalizirati izlazni račun prema kupcu kroz Luceed i poslati ga njemu, umjesto da on kreira račun u vaše ime.
Ako ste vi kupac (npr. komisionar): Umjesto da vi kreirate račun u ime dobavljača, zatražite od dobavljača da vam ispostavi standardni eRačun za isporučenu robu ili uslugu.
Šalju li se GLN kodovi na eRačunu istovremeno s OIB-om kupca i koja je njihova funkcija?
Da, OIB i GLN se šalju istovremeno, ali se unose u zasebna polja unutar XML strukture eRačuna. Ova dva identifikatora se međusobno ne isključuju jer služe različitim svrhama:
OIB (porezna identifikacija): Obvezan je podatak za proces fiskalizacije i služi za nedvojbenu pravnu identifikaciju primatelja računa u sustavu Porezne uprave.
GLN (logistička identifikacija): Služi za precizno definiranje mjesta isporuke, poslovnice ili specifičnog odjela unutar sustava kupca, što olakšava automatsku obradu računa.
Pravila unosa i hijerarhija u sustavu (Luceed)
Kako bi se osigurala točnost podataka, sustav primjenjuje automatiziranu hijerarhiju pri povlačenju GLN koda:
Razina korisnika: Ako je na računu odabran partner u polju Korisnik (lokacija ili poslovnica isporuke), sustav primarno povlači GLN iz matičnih podataka tog partnera.
Razina partnera: Ako na partneru unijetom u polje Korisnik GLN nije definiran, sustav će povući glavni GLN iz partnera postavljenog u polju Partner.
Gdje unijeti podatke?
Matični podaci > Partneri: Polje GLN u osnovnim podacima partnera.
Mogu li koristiti više informacijskih posrednika za eRačune u Fiskalizaciji 2.0?
Ako zbog specifičnosti poslovanja koristite više softverskih rješenja i aplikacija za različite dijelove poslovanja (npr. jedno rješenje za maloprodaju, a drugo za veleprodaju), moguće je koristiti i više informacijskih posrednika. Pritom je ključno razlikovati dva procesa:
odabir posrednika za zaprimanje eRačuna
davanje ovlaštenja posrednicima za slanje podataka
Zaprimanje eRačuna – odabir jednog posrednika
Za zaprimanje eRačuna od svojih dobavljača možete imati potvrđenu samo jednu adresu (pristupnu točku) u sustavu Porezne uprave. To znači da u FiskAplikaciji (ePorezna) birate isključivo jednog posrednika preko kojeg ćete zaprimati sve ulazne eRačune.
Slanje eRačuna i eIzvještavanja – davanje ovlaštenja
Za fiskalizaciju eRačuna možete dati neograničen broj ovlaštenja, ovisno o tome koliko različitih aplikacija i posrednika koristite. Za svakog posrednika koji u vaše ime šalje podatke prema Poreznoj upravi potrebno je:
dodati zasebno ovlaštenje u FiskAplikaciji
navesti OIB tog posrednika
definirati datum početka važenja ovlaštenja
Ako koristite više aplikacija koje rade preko različitih posrednika, ovlaštenje morate dati za svakog od njih pojedinačno.
Važna napomena: Ako za nekog posrednika nije definirano odgovarajuće ovlaštenje, svi računi ili izvještaji poslani iz tog sustava neće biti ispravno zaprimljeni u Poreznoj upravi i smatrat će se tehnički nevažećima u procesu fiskalizacije.
Hoće li i dalje biti moguć ispis računa koji se šalju kao eRačun?
Trenutačno u Luceedu ne uvodimo nikakve promjene vezane uz mogućnost ispisa računa. Za sada će sve raditi kao i prije uvođenja Fiskalizacije 2.0.
Tko fiskalizira zaprimljene eRačune i postoji li rok za knjiženje u URA?
🔔 Objavljeno: 7.1.2026.
U narednom razdoblju omogućit ćemo zaprimanje eRačuna kroz Interconnect i njihovo preuzimanje u Luceed. Kako su se istovremeno pojavila pitanja o roku od 5 dana za fiskalizaciju ulaznih računa, važno je pojasniti da taj rok ne predstavlja prekršaj za korisnika, jer potvrdu zaprimanja u tom dijelu procesa odrađuje informacijski posrednik.
Proces zaprimanja eRačuna sastoji se od dva dijela koja je važno razlikovati:
1. Fiskalizacija zaprimanja (prema Poreznoj upravi)
Ovu obvezu automatizmom odrađuje vaš informacijski posrednik u trenutku kada račun stigne u njegov sustav. Na taj način se Porezna uprava obavještava da vam je račun dostavljen i rok od 5 dana za fiskalizaciju je ispunjen.
2. Knjiženje u Knjigu URA (vaše knjigovodstvo)
Preuzimanje računa iz Interconnecta u Luceed radi knjiženja je interna računovodstvena aktivnost. Zakon o fiskalizaciji ne propisuje rok u kojem taj dokument morate proknjižiti. Rok se odnosi samo na potvrdu primitka, koju u procesu već odrađuje informacijski posrednik.
👉 Ukratko: Vaši računi čekaju u Interconnectu sigurni i, što je najvažnije, već su fiskalizirani kao zaprimljeni. Slobodno nastavite s radom, a preuzimanje u Luceed ćete obaviti naknadno čim funkcionalnost bude aktivna.
Kako u Luceedu možemo ograničiti pristup korisniku samo na jednu firmu u Interconnectu?
🔔 Objavljeno: 20.1.2026.
U Luceedu i na Interconnectu imamo više firmi. Nakon slanja pozivnice korisnik u Interconnectu vidi sve firme. Kako mu možemo ograničiti pristup samo na jednu firmu u Interconnectu?
Multi-Company način rada omogućuje rad s više firmi unutar jedne Luceed licence. Ovaj način rada posebno je namijenjen knjigovodstvenim servisima i korisnicima koji upravljaju s više pravnih subjekata, a omogućuje centraliziran pristup podacima i funkcionalnostima Interconnecta za sve povezane firme.
Korisnička prava u Multi-Company načinu rada dodjeljuju se na razini licence, što znači da korisnik, ovisno o dodijeljenim pravima, može pristupati jednoj ili više firmi povezanih s istom Luceed licencom.
Kako funkcionira slanje pozivnica?
Prilikom slanja pozivnice za Interconnect, Tomsoftov centralni identifikacijski sustav automatski kreira korisnički profil s unaprijed definiranom grupom prava za pristup Interconnectu. Pozivnica se šalje iz Luceeda, a korisnik je time automatski povezan s Luceed licencom s koje je pozivnica poslana. Upute za slanje pozivnice možete pronaći ovdje.
Koja prava korisnik dobiva?
Grupa prava koja se dodjeljuje korisničkom profilu omogućuje pregled podataka svih firmi koje su vezane uz istu Luceed licencu.
Što to znači u praksi?
Primjer: Knjigovodstveni servis u Luceedu ima više komitenata (firmi) za koje vodi računovodstvo. Dio tih firmi obveznici su Fiskalizacije 2.0, odnosno imaju obvezu slanja i/ili zaprimanja eRačuna. Sve firme koje su obveznici Fiskalizacije 2.0 automatski se kreiraju i na Interconnect licenci tog korisnika.
Kada se novom korisniku pošalje pozivnica za Interconnect, dodjeljuje mu se grupa prava koja omogućuje odabir bilo koje firme povezane s licencom knjigovodstvenog servisa.
Može li se korisniku dati pristup samo jednoj firmi?
Trenutno nije dostupna opcija kojom bi se korisniku mogla dodijeliti prava isključivo za jednu firmu. Ova funkcionalnost je u razvoju, a obavijest o dostupnosti bit će poslana putem Luceed newslettera.
Hoće li biti moguće dodijeliti pristup za više od jedne firme?
Da. Nova opcija omogućit će da se korisniku dodijeli pristup jednoj ili više odabranih firmi, prema potrebi.
Zašto se u Interconnectu PDF ne prikazuje za sve račune i je li to greška?
🔔 Objavljeno: 20.1.2026.
Kada u Interconnectu otvorim detalje računa, na nekim dokumentima vidim PDF prikaz, a na nekima ne. Radi se o računima zaprimljenima putem eRačuna. Možete li mi reći zašto se PDF ne prikazuje za sve račune i je li to greška u Interconnectu?
Prilikom pregleda detalja računa u Interconnectu, sustav prikazuje vizualni prikaz računa (PDF) samo ako je on sastavni dio XML poruke eRačuna. Interconnect ne generira PDF samostalno, već prikazuje vizualni prikaz koji je pošiljatelj računa priložio unutar XML poruke eRačuna. Ako pošiljatelj nije priložio PDF uz XML poruku, Interconnect neće moći prikazati vizualni prikaz tog računa.
Što ako mi je vizualni prikaz računa neophodan?
U tom slučaju potrebno je zatražiti PDF račun izravno od dobavljača koji je poslao eRačun.
Planirane funkcionalnosti:
U planu je dodavanje funkcionalnosti kojom će Interconnect, za račune zaprimljene bez priloženog vizualnog prikaza, automatski generirati vizualizaciju računa te korisnicima omogućiti:
pregled PDF-a računa
preuzimanje PDF-a računa
O dostupnosti ove opcije korisnici će biti pravovremeno obaviješteni.