ZAKON O ELEKTRONSKOM FAKTURISANJU: Primeri situacija u vezi sa korišćenjem Sistema elektronskih faktura putem API servisa i kreiranjem XML datoteka
Ograničenje broja API poziva
1. januara 2023 stupa na snagu zakonska obaveza izdavanja i čuvanja elektronske fakture u transakcijama između subjekata privatnog sektora, kao i obaveza elektronskog evidentiranja PDV-a, u skladu sa ZoEF.
Dakle, očekuje se povećanje u broju evidencija i razmene faktura na Sistemu e-Faktura, a u cilju obezbeđenja stabilnosti i zadovoljavajućih performansi sistema za sve korisnike, od 01. januara 2023 biće postavljeno ograničenje broja API poziva u jedinici vremena za svaki API ključ.
Inicijalno ograničenje će biti postavljeno na maksimalno 3 API poziva u sekundi.
Ukoliko broj API poziva bude veći od 3 poziva u sekundi, ostali će biti odbijeni i sistem će pokazati grešku: error code-om HTTP Error 429
Ukidanje opcije za automatsko slanje faktura u CRF preko API servisa
Od 16.12.2022 na Sistemu e-Faktura će biti ukinuta opcija za automatsko slanje faktura u CRF preko API servisa. Tako da je neophodno da se eksplicitno odredi da li se faktura šalje u CRF ili ne.
ERP provajder nam potražuje API ključ za integraciju sa Sistemom elektronskih faktura. Kako možemo dobiti API ključ?
Sve instrukcije u vezi sa operativnim korišćenjem SEF-a možete pročitati u okviru dokumenta “Interno tehničko uputstvo”, koje redovno ažuriramo i objavljujemo na portalu efaktura.gov.rs, u okviru sekcije “Instrukcije”. Link ka uputstvu:
API ključ na SEF-u može da generiše korisnik koji poseduje ulogu administratora. U okviru sekcije podešavanja potrebno je izabrati “API menadžment”, a zatim “Generiši ključ”. Nakon generisanja, potrebno je API status promeniti u “Aktivan”, prevlačenjem klizača u desno. Nakon ovih koraka ključ je spreman za integraciju i možete ga proslediti ERP provajderu.
Link ka detaljnom uputstvu za generisanje API ključa:
Kako se implementiraju API notifikacije?
Adrese za primanje notifikacija o izlaznim i ulaznim fakturama se takođe navode u okviru stranice “API menadžment”. Nakon unosa, potrebno je da kliknete na “Save” ili
“Sačuvaj”.
Kako biste počeli da dobijate notifikacije o izmenama statusa faktura, potrebno je najpre podesiti adrese servisa koje izlažete u API podešavanjima na eFaktura aplikaciji. Pozivom subscribe endpoint-a na javnom API servisu, pretplaćujete se da dobijate notifikacije o izmenama statusa faktura narednog dana, kao i generisani ključ koji će biti dodat na svaku notifikaciju kako biste mogli da utvrdite da poziv dolazi iz SEF-a.
Kada postoji pretplata određenog dana (odgovarajuća sabskripcija je odrađena prethodnog dana) na endpoint-e u podešavanjima Sistema e-Faktura, biće upućen POST zahtev, čija je struktura potpuno ista kao rezultat koji se dobija pozivom odgovarajućih changes endpoint-a prethodnog dana.
Ukoliko ne želite da primate obaveštenja na adresu e-pošte kompanije ili kontakt osobe, koju ste naveli u okviru stranice “Podešavanja kompanije”, možete označiti polje
“Isključi notifikacije na e-pošti”, u okviru iste stranice i sistem će prestati da Vas obaveštava.
Gde možemo videti dokumentaciju vezanu za izradu XML dokumenata?
XML datoteke se izrađuju po standardu EN 16931-1. Ažurirana specifikacija prilagođene primene tog standarda objavljena je na portalu efaktura.gov.rs, u okviru sekcije
“Instrukcije”. Direktan link ka ažuriranoj specifikaciji:
Ažurirana specifikacija prilagođene primene standarda EN 16931-1
Gde možemo videti primere XML datoteka?
Trenutno je dostupno 13 primera različitih XML datoteka i vrsta faktura. Očekujemo uskoro i primere novih. Koristimo priliku da usmerimo korisnike koji rade na integraciji internih računovodstvenih softvera sa SEF-om, da svoje XML datoteke izrađuju isključivo u skladu sa primerima i internim tehničkim uputstvom.
Preporučujemo da Vaše XML datoteke prvo testirate na demo okruženju Sistema elektronskih faktura.
Primere XML datoteka takođe objavljujemo na portalu e-Faktura, u okviru sekcije
“Instrukcije”, direktan link:
Ažurirani primeri XML datoteka po UBL 2.1 standardu
Primetili ste da je jako važno da redovno pratite portal i upoznajete se sa sadržajem koji objavljujemo, apelujemo da nastavite da posećujete portal, kako biste se u realnom vremenu upoznali sa svim novostima u vezi sa SEF-om.
Da li postoje limiti i nepoželjni karakteri prilikom kreiranja dokumenata?
Trenutni limiti su:
- Broj fakture je ograničen na 22 karaktera kada se obaveza registruje u CRF;
- Naziv kompanije je ograničen na 128 karaktera kada se obaveza registruje u CRF;
- Naziv stavke je ograničen na 1024 karaktera;
- Komentar je takođe ograničen na 1024 karaktera;
- U broju fakture nisu dozvoljeni specijalni osim karaktera koji su navedeni na slajdu “!"#$%&'()*+,./[\]^_:;<=>?`@{}|~”. Broj fakture ne može da se završava sa specijalnim karakterom;
- kada se faktura registruje u CRF nije moguće koristiti ćirilično pismo;
- sistem funkcioniše na dve decimale, sve preko se zaokružuje na toliko. Molimo vas da obratite pažnju na limite prilikom kreiranja dokumenata.
Zašto prilikom korišćenja API metode (npr. za slanje faktura), dobijamo grešku:
“401 - Unauthorized”?
U ovim situacijama je pre svega potrebno proveriti da li je status API ključa u podešavanjima promenjen u “Aktivan” prilikom generisanja. Ukoliko nije, potrebno je promeniti status.
Greška može da se pojavi i u situacijama kada implementator koristi Swagger od npr. demo okruženja, na kojem nije menjao API status, a pokušava da pošalje fakturu na produkcionom okruženju.
Takođe se dešava da, u situaciji kada implementator koristi API ključeve od više kompanija, API ključ i kompanija unutar XMLdokumenta nisu isti, tj. API ključ je od jedne kompanije, a unutar endpoint-a se nalaze podaci druge kompanije.
Ukoliko se Vaš problem nastavlja i nakon prethodno navedenih provera, potrebno je da se obratite na mejl podrške podrskaefaktura@mfin.gov.rs
Zašto prilikom slanja fakture putem API servisa dobijamo iste identifikacione brojeve?
Prilikom svakog slanja XML dokumenta potrebno je promeniti requestId. Ukoliko ste ranije slali dokument sa istim requestId, dobićete ID od prethodno poslatog dokumenta.
Zašto prilikom slanja fakture, dobijamo grešku:
“UBLOrderNumberLotNumberOrContractNumberIsRequired”?
Kada se faktura šalje budžetskom korisniku čije se obaveze registruju u CRF, u okviru XML datoteke je potrebno da popunite jedno od tri polja, tj. potrebno je da unesete broj ugovora, broj narudžbenice/broj fakture/broj ponude, kao što znate na SEF-u je ovo jedno polje, ili broj okvirnog sporazuma.
Status fakture je “SEEN” tj. “Pregledano”, a niko nije direktno pristupio fakturi?
Preuzimanje nove fakture preko purchase-invoice API servisa, menja status te fakture na
“Pregledano”. Preuzimanje fakture je ekvivalentno otvaranju iste neposrednim korišćenjem interfejsa sistema.
PartyIdentification tag?
Primetili smo da dosta korisnika u navedeno polje unosi podatke kao što su PIB ili MB u različitim formatima. Važno je znate da se u ovo polje unosi isključivo JBKJS, kada je na strani primaoca korisnik javnih sredstava. U suprotnom se ovo polje ne koristi.
Provera ovog polja će se implementirati u nekom od narednih ažuriranja sistema, pa je moguće da će doći do poteškoća prilikom uvozu XML datoteka. Pratite objave na portalu, vest o ažuriranju će biti blagovremeno objavljena.
Da li je moguće poslati konačni račun sa avansnim računom koji nije izdat posredstvom SEF?
Ova funkcionalnost je moguća. Ukoliko sistemu pristupate neposredno, potrebno je u predviđeno polje uneti broj i datum avansnog računa (obratite pažnju da već ne postoji avansni račun sa ovim brojem u sistemu). Takođe korisnik treba da unese iznos izmirenih obaveza po poreskim kategorijama.
Unutar XML dokumenta je takođe potrebno uneti ove podatke u okviru polja:
<InvoicedPrepaymentAmmount> <ID>Broj avansnog računa</ID> <-InvoicedPrepaymentAmmount> -------------------------- <BillingReference> <InvoiceDocumentReference> <ID>Broj avansnog računa</ID> <IssueDate>Datum slanja avansnog računa</IssueDate> </InvoiceDocumentReference> </BillingReference>
Ukoliko avansni račun jeste poslat posredstvom Sistema e-Faktura potrebno je da bude u statusu “Odobreno”, ukoliko se za izdavanje konačnog računa koristi interfejs SEF-a.
Opis parametra requestId i kakvog formata treba da bude?
“requestId” je jedinstveni identifikator poziva, kojim se obezbeđuje mogućnost višestrukog pozivanja iste operacije, a da pritom efekti ne budu ponovljeni. Identifikator može da bude nasumičan broj koji proizvoljno dodeljujete.
Da li je moguće učitati radnu verziju XML dokumenta, manuelno ili preko API servisa, tj. da dokument bude u statusu “Nacrt”?
Nije moguće. Kada se XML učita na bilo način, više se ne menja, takav se potpisuje i šalje se na nalog primaoca.
Da li je moguće učitati više XML datoteka odjednom?
Ovakva funkcionalnost nije moguća i trenutno nije u planu.
Na šta se odnose metode čiji je prefiks “CIR”, u odgovorima pojedinih metoda?
Ovo su metode koje se odnose na Centralni registar faktura, kroz koje je moguće sprovesti neke od akcija. Ukoliko se faktura izdaje KJS-u čije se obaveze registruju u CRF potrebno je u okviru sendToCir parametra upisati Yes.
Greška: “Receiver budget company is not active.”
Pomenuta greška je vezana za kompaniju kojoj izdajete dokument. Kompanija je budžetski korisnik i Sistem elektronskih faktura iz nadležnih institucija dobija podatak da je kompanija neaktivna. U ovoj situciji, potrebno je kontaktirati kompaniju koja se nalazi na strani primaoca i informisati je o grešci koja postoji, kako bi mogla da preduzme potrebne korake tj. da kontaktira nadležnu instituciju - u ovom slučaju Upravu za trezor.
Opisi API statusa:
New - status nova poseduju dokumenta koje su upravo primljena u Vaše prijemno sanduče. kada se pretplatite da dobijete sve promene na određeni dan, Sistem e-Faktura će automatski putem push obaveštenja slati nova dokumenta u vaš sistem
Draft - u pitanju je dokument koja nije još uvek završen
Sent - dokument je poslat kupcu
Sending Mistake - status se pojavljuje u slučaju kada dokument nema dovoljno podataka da bi bio poslat ili je slanje stopirano iz tehničkih razloga
Sending - slanje dokumenta je u toku
Deleted - pojavljuje se u slučaju brisanja dokumenta koji se prethodno nalazio u statusu
“Nacrt”, jedino tada je i moguće obrisati dokument
Approved - kada je dokument prihvaćen od strane kupca
Rejected - status koji dolazi od strane primaoca kada je dokument iz nekog razloga odbijen
Cancelled - pošiljalac je otkazao dokument, akciju je moguće izvršiti pre nego što primalac prihvati/odbije dokument
Storno - primalac je prihvatio dokument, pošiljalac je nakon toga storniraoI na kraju Mistake - u slučaju da se dokument šalje preko API servisa i iz tehničkih razloga dođe do problema.
Sve dodatne i relevantne informacije možete pronaći u Internom tehničkom uputstvu i API dokumentaciji.
Šta je IsSigned parametar?
Svaka elektronska faktura sadrži i digitalni potpis da je jedinstvena i validirana od strane centralnog informacionog posrednika, "IsSigned" tome služi. Dobićete dve notifikacije za potpis, jedna kada se faktura nađe u inbox-u primaoca, a druga kada se završi potpis elektronskim potpisivanjem.
Da li je uvek potrebno upisati “issueDate” unutar XML-a?
Da. Datum izdavanja fakture se generiše i proverava i sistemski, tako da issueDate koji upisujete u okviru XML datoteke mora biti identičan datumu slanja dokumenta kroz SEF.
Da li postoji validator gde možemo proveriti ispravnost naše XML datoteke?
Dostupan je servis za validaciju XML datoteka i njime možete proveravati sva 4 tipa dokumenta koja sistem e-Faktura podržava. Link ka servisu za validaciju:
Da li je podržana operacija slanja pojedinačne i zbirne evidencije PDV-a preko API
protokola na Sistemu e-Faktura?
Podržana je ova funkcionalnost. Metode i format u kojima se šalju pojedinačna i zbirna evidencija PDV-a preko API servisa, možete pogledati na Swagger-u. Link ka Swagger-u:
Metode:
- za slanje pojedinačne evidencije PDV-a:
/api/publicApi/vat-recording/individual - za slanje zbirne evidencije PDV-a:
/api/publicApi/vat-recording/group
Kako možemo da proverimo da li je kompanija kojoj šaljemo fakturu registrovana na sistemu e-Faktura?
Prilikom dodavanja kontakta na veb aplikaciji sistema e-Faktura možete proveriti da li je kompanija registrovana. Ukoliko se kompanija ne pojavljuje prilikom dodavanja, to znači da nije registrovana.
Putem API servisa možete iskoristiti metodu:
/api/publicApi/Company/CheckIfCompanyRegisteredOnEfaktura
Uz obavezan unos neophodnih parametara: MB/PIB/JBKJS, u zavisnosti od pravne forme kupca.
Potrebno je da implementiramo funkcionalnost izuzeća PDV-a unutar XML-a. Gde možemo da vidimo kategorije i izuzeća?
Opis dostupnih PDV kategorija u sistemu elektronskih faktura su objavljene na portalu e- Faktura u okviru sekcije Instrukcije, iz padajuće liste birate Poreske kategorije za elektronske fakture, link: Kategorije za elektronske fakture.
Pozivanjem navedene API metode:
api/publicApi/sales-invoice/getValueAddedTaxExemptionReasonList
možete dobiti sva izuzeća od PDV-a. Unutar datoteke koju dobijete, možete videti kategoriju (“Category”), šifru izuzeća (“Key”), opis šifre i ostale potrebne podatke koje možete koristiti prilikom kreiranja XML datoteka.
Koje jedinice mere su dostupne?
Dostupne jedinice mere možete pogledati na korisničkom interfejsu SEF-a, tako što ćete prilikom kreiranja fakture kliknuti na podrazumevanu jedinicu mere (osim u slučaju izdavanja avansnog računa) i na taj način će se otvoriti padajuća lista u kojoj možete videti sve raspoložive jedinice mere.
Ukoliko radite pomoću API servisa, pozivom metode api/publicApi/get-unit-measures,
možete dobiti jedinice mere sa Code podatkom koji se navodi u XML datoteci.
Da li se obaveze prilikom slanja fakture subjektima javnog sektora - tip 7 registruju u CRF?
Ukoliko je primalac fakture korisnik javnih sredstava i po klasifikaciji pripada tipu 7, obaveze se ne registruju u CRF. Znači, prilikom izdavanja dokumenta nije potrebno označiti polje “Pošalji u CRF”.
Ukoliko fakture šaljete putem API servisa, u parametar sendToCir potrebno je upisati No. Ukoliko niste sigurni da li se obaveza registruje u CRF, proveru registracije obaveze možete izvršiti na linku:
Provera registracije obaveza u CRF Minimalan set informacija
Ukoliko i nakon svih provera i dalje imate problem prilikom izdavanja dokumenata, podešavanja servisa za notifikacije, pozivanja API metoda i ostalih tehničkih problema,
potrebno je da se obratite na mejl podrške i dostavite minimalni set informacija, koji je programerima neophodan za bradu tiketa.
To su:
- Podaci kompanije: Naziv, PIB/Matični broj/JBKJS u slučaju korisnika javnih sredstava, nadležni registar;
- Kontakt telefon;
- Slika greške;
- XML datoteka koju pokušavate da učitate;
- PDF prikaz generisan na Sistemu e-Faktura.
Ove informacije su nam neophodne i kako bismo skratili vreme obrade tiketa i brže otklonili grešku ili problem, ukoliko postoji.
Izvor: Vebsajt eFaktura, 01.12.2022.Naslov: Redakcija
