Fiskalizacija 2.0: kako povezati postojeći ERP ili web shop s hrvatskim sustavom eRačuna

Nacionalna pravila nadograđuju se na europsku normu EN 16931, a ne zamjenjuju je: nacionalna specifikacija primjene osnovnog računa plus hrvatska proširenja. Usklađen račun nosi CustomizationID u ovom obliku, kao jedan neprekinuti niz:

urn:cen.eu:en16931:2017#compliant#urn:mfin.gov.hr:cius-2025:1.0#conformant#urn:mfin.gov.hr:ext-2025:1.0

Nemojte ga hard-kodirati prema tekstu s bloga. Usporedite ga s verzijom specifikacije prema kojoj gradite.

Na strani razmjene profil pristupne točke je eRačun-AS4, koji slijedi CEF eDelivery AS4 Profile v1.15 i sužava atribute koje CEF profil ostavlja otvorenima. Uz njega idu i usluga imenika, koja utvrđuje tko zaprima račune za pojedinog poreznog obveznika, te usluga metapodataka.

Četiri načina da ispunite obvezu izdavanja

MIKROeRAČUN preko ePorezne

Kada odgovara: Vrlo mali obujam, računi se ionako pišu ručno. Prvo provjerite uvjete i ograničenja. Što vas košta: Ništa se ne gradi. Gdje boli: Ručno prepisivanje. Vaš vlastiti sustav nikad ne sazna da je račun otišao.

SaaS za fakturiranje kao glavna evidencija

Kada odgovara: Vaš sadašnji sustav ionako nije mjesto na kojem računi zapravo nastaju. Što vas košta: Pretplata i migracija. Gdje boli: Dva kataloga proizvoda koja treba držati usklađena, a SaaS drži vaše podatke o računima.

Povezivanje vašeg sustava s informacijskim posrednikom

Kada odgovara: Račune generira softver o kojem već ovisite. Što vas košta: Integracijski projekt, plus ono što posrednik naplaćuje. Gdje boli: Mapiranje polja i obrada grešaka ostaju na vama.

Vlastita pristupna točka

Kada odgovara: Platforma ste koja izdaje račune u ime mnogo tvrtki. Što vas košta: Implementacija AS4 profila i praćenje svake izmjene. Gdje boli: Usklađenost sa specifikacijom postaje dio vašeg proizvoda.

Za većinu tvrtki s ERP-om ili web shopom koji radi, treći redak je pošten odgovor. Zamjena sustava koji funkcionira samo da biste zadovoljili XML format skup je način rješavanja problema mapiranja. Napominjemo da Zakon ne traži da usluga posrednika bude naplatna, nego samo da odnos bude uređen ugovorom, pa usporedite uvjete umjesto da pretpostavljate jedinstvenu tržišnu cijenu.

Što nedostaje vašem modelu podataka

To je ono što dvotjednu integraciju pretvori u dvomjesečnu. Format je dokumentiran. Vaši podaci nisu oblikovani za njega.

Praznine su gotovo uvijek iste:

• Identifikacija kupca. Strukturirani račun traži kupca razriješenog do identifikatora, a ne naziv tvrtke koji je prodavač utipkao u slobodno polje. Ako vaša tablica kupaca ima jedan tekstualni blok s adresom i nema stupac za OIB, to je posao na shemi prije nego što uopće postane posao oko XML-a.
• Klasifikacija stavki. Svaka stavka treba svoju KPD 2025 oznaku: najmanje šest znamenaka, pisanih s točkama, primjerice 47.82.20. Klasifikacija je usklađena s europskom CPA 2.2, a oznake se pretražuju kroz aplikaciju KLASUS Državnog zavoda za statistiku. Oznake se primjenjuju na eRačune, ne na B2C fiskalne račune. Mapiranje postojećeg kataloga je podatkovni projekt i ne da se paralelizirati, jer svaku odluku mora donijeti netko tko poznaje proizvode.
• Zaokruživanje i ukupni iznosi. Vaš sustav vjerojatno zaokružuje negdje gdje norma to ne očekuje. Iznosi stavki koji se ne slažu s ukupnim iznosima računa padaju na poslovnim pravilima EN 16931, poput BR-CO-10 i BR-CO-13, već na pristupnoj točki, prije nego što kupac uopće vidi dokument.
• Odobrenja i ispravci. Timovi izgrade put za račun, puste ga u rad, a onda otkriju da put za ispravak traži vlastitu vrstu dokumenta i referencu na izvorni račun.
• Dokumenti koji nisu računi. Predujmovi i naknadna odobrenja imaju vlastita pravila. Rano odlučite koji su vaši dokumenti u opsegu.

Izvor za klasifikaciju: Porezna uprava, Klasifikacija roba i usluga u eRačunu.

Što puca nakon puštanja u rad

eRačun je poruka sustavu koji je može odbiti. Tu leži operativni dio posla.

Gradite za odbijanje od prvog commita. Račun koji padne na validaciji otišao je iz vašeg sustava, ali za kupca ne postoji, dok ga vaše knjigovodstvo veselo prikazuje kao izdanog. Zapis o računu treba status koji odražava ono što je mreža rekla, a ne ono što je vaše sučelje pretpostavilo.

Odlučite unaprijed koji vam je ključ idempotentnosti i tu odluku zapišite. UBL ID računa i identifikator fiskalizacijske poruke nisu isti ključ i nemaju istu semantiku. Ponovno slanje mora koristiti isti ključ, a ne generirati novi, inače vam ponovni pokušaj postane duplirani račun.

Čuvajte XML, a ne njegov PDF prikaz, kroz zakonski rok čuvanja, zajedno s potpisom i potvrdom o zaprimanju. XML je račun. PDF ne dokazuje ništa o tome što je mreža primila.

I pobrinite se da netko to primijeti. Red čekanja koji tiho stane kvar je koji stvarno košta, jer nitko ne sazna dok kupac ne pita gdje mu je račun. Dnevno usklađivanje između računa izdanih u vašem sustavu i računa koje je mreža potvrdila pretvara tromjesečni problem u jednodnevni.

Kako to radimo

Ovo tretiramo kao integraciju, ne kao zamjenu. Račun ostaje ondje gdje nastaje. Između vašeg sustava i posrednika stoji sloj za automatizaciju procesa: mapira vaša polja na specifikaciju, validira prije slanja, zapisuje potvrdu natrag na zapis o računu, ponavlja slanje na dogovorenom ključu i podiže iznimku za čovjeka kad se dokument ne može mapirati. Taj sloj vrtimo self-hosted u EU ili na vašim vlastitim poslužiteljima, tako da račun dobije posrednik, a nitko drugi ne drži kopiju vaših knjiga.

Isti obrazac koristimo i za ostale poslove , a eRačun je dobar prvi slučaj, jer ispravan izlaz definira netko drugi pa ga je lako testirati.

Pošaljite nam kratak opis sustava iz kojeg danas izdajete račune i reći ćemo vam koji bismo od četiri puta odabrali i zašto.