Integracija sa sistemom eOtpremnica (SEO): API, demo i arhitektura

Firma se integriše sa Sistemom elektronskih otpremnica tako što ERP ili skladišni sistem preko API ključa šalje eOtpremnicu u strukturiranom formatu pre početka kretanja dobara, a sistem vraća status i omogućava prijem elektronske prijemnice. Priprema ima tri koraka: prijava kvalifikovanim sertifikatom ili eID-om, generisanje API ključa i sloj u kodu koji šalje otpremnicu i beleži ishod.

Šta je Sistem elektronskih otpremnica i ko njime upravlja?

Sistem elektronskih otpremnica, skraćeno SEO, jeste informatičko-tehnološko rešenje kojim upravlja Centralni informacioni posrednik, a to je jedinica u Ministarstvu finansija. Kroz taj sistem se eOtpremnica šalje i prima u strukturiranom formatu, pa nije reč o PDF-u zakačenom uz mejl nego o dokumentu koji sistem razume, evidentira i povezuje sa elektronskom prijemnicom. Pravni okvir je Zakon o elektronskim otpremnicama, objavljen u Službenom glasniku RS pod brojevima 94/2024, 109/2025 i 80/2026.

Za tim se vezuju dva pojma koja developer mora da razlikuje. eOtpremnica je isprava koja prati dobra radi evidentiranja njihovog kretanja. Elektronska prijemnica je dokument o kvalitativnom i kvantitativnom prihvatanju dobara, koji primalac sačinjava i šalje na osnovu primljene eOtpremnice. Integracija dakle nije jednosmerna: sistem koji šaljete gradi mora da prati i tok u kome vaša firma prima robu i uzvraća prijemnicu. Objašnjenje pojma za poslovnu publiku držimo u rečniku, na strani e-otpremnica, a vezu sa svetom e-faktura na strani SEF.

Da li eOtpremnica postaje obavezna 1. oktobra 2026?

Ne. To je najčešća zabluda oko ovog propisa i vredi je razrešiti pre svakog reda koda. 1. oktobra 2026. ne stupa nikakva nova obaveza. Prekretnica za privatni sektor je 1. oktobar 2027, kada počinje obaveza slanja eOtpremnice između subjekata privatnog sektora i obaveza privatnog sektora da prima eOtpremnice. To je druga faza i ona važi za sve.

Ono što već važi počelo je 1. januara 2026. Od tada javni sektor šalje i prima eOtpremnice, privatni sektor šalje eOtpremnicu subjektu javnog sektora, a za akciznu robu privatni sektor i šalje i prima eOtpremnice kada prima akcizne proizvode. Prevoznici za ta kretanja pokazuju eOtpremnicu u inspekcijskom nadzoru. Između 1. januara 2026. i 1. januara 2027. traje period tolerancije, o kome pišemo niže. Ovu tablicu rokova stavljamo na početak svakog projekta da niko ne bi gradio na pogrešnom datumu.

Izmene 80/2026, usvojene 31. avgusta 2026. i objavljene 1. septembra 2026, uvele su nove izuzetke i produžile period tolerancije do 1. januara 2027. Izmene 109/2025 uvele su odredbu o papirnom obliku pri privremenom prekidu veze. Kontekst i kalendar obaveza vodimo i u kalendaru poreskih obaveza, a širi pregled propisa je u fiskalnom vodiču.

Kako se prijavljuje na sistem i generiše API ključ?

Prijava na sistem ide kvalifikovanim elektronskim sertifikatom, odnosno eID-om preko portala za identifikaciju, isto kao za SEF. To je važan detalj za planiranje: firma koja već radi na Sistemu e-faktura ima isti nalog i isti svet identifikacije, jer je sistem eOtpremnica povezan sa SEF okruženjem. Ako klijent nije na SEF-u, prvi korak nije kod nego administracija: neko sa ovlašćenjem mora da se prijavi sertifikatom.

Kada je firma na portalu, API ključ se generiše u odeljku Podešavanja, pa API podešavanja. Ključ je tajna kojom vaš serverski kod dokazuje da sme da šalje otpremnice u ime firme. On nije za pregledač i nije za repozitorijum, o čemu pišemo u odeljku o arhitekturi. Ceo prijem robe i tok e-fakture i otpremnice pokrivamo i na strani fakture, SEF i otpremnice.

Ekran API podešavanja je mesto na kome se ključ generiše; demo i produkciju držimo kao odvojena okruženja sa odvojenim ključevima.

Kako izgleda referentna arhitektura integracije ERP-a sa SEO-om?

Slanje otpremnice ne sme da bude poziv iz korisničkog interfejsa magacionera niti deo transakcije koja štampa nalog za otpremu. Mora da bude zaseban sloj, iz istog razloga iz kog to važi i za fiskalizaciju: dokument koji nastane u sistemu je zvaničan, a zakon vezuje trenutak slanja za fizički događaj, početak kretanja dobara. Zato između ERP-a ili WMS-a i sistema stoji sloj za slanje, koji pretvara nalog za otpremu u strukturiranu eOtpremnicu, šalje je, čita status i vraća ga nazad u ERP.

Nalog za otpremu ide odozgo nadole kroz sloj za slanje do sistema, a status i elektronska prijemnica se vraćaju nazad u ERP.

Odgovornosti slojeva delimo ovako, i po tome pišemo testove i predaju klijentu.

Kako izgleda poziv ka javnom API-ju sistema?

Tačne putanje endpointa, imena polja i naziv zaglavlja za API ključ nalaze se u tehničkom uputstvu na eotpremnica.efaktura.gov.rs i u javnom Swagger opisu demo okruženja. Zato ih ovde ne prepisujemo, nego prikazujemo oblik poziva sa placeholderima koje vaš tim popuni iz uputstva. Načelo je isto kao za svaki potpisani REST API: telo u strukturiranom formatu, ključ u zaglavlju, referenca za idempotentnost.

POST {SEO_URL}/{putanja-za-slanje-otpremnice}
Content-Type: application/json
# naziv zaglavlja za API kljuc uzmite iz tehnickog uputstva na eotpremnica.efaktura.gov.rs
ApiKey: {VAS_API_KLJUC}

{
  "referencaPosiljaoca": "OTP-2026-001042",   // vasa interna sifra naloga, kljuc idempotentnosti
  "posiljalac": { "pib": "100000000" },
  "primalac":   { "pib": "200000000" },
  "prevoznik":  { "naziv": "..." },
  "datumPocetkaKretanja": "2026-09-23T09:30:00",
  "stavke": [
    { "naziv": "...", "sifra": "...", "kolicina": 10, "jedinica": "kom" }
  ]
}

Odgovor sistema, prema uputstvu, nosi identifikator dokumenta u sistemu, status i podatke za QR kod. Taj identifikator i status upisujete uz svoj nalog za otpremu, jer su oni veza između vaše evidencije i sistema. Kada firmi treba stanje ranije poslate otpremnice ili elektronska prijemnica koja je stigla, sloj čita odgovarajuću putanju iz uputstva i osvežava status u ERP-u. Uporedni pogled na to kako isti princip radi za e-fakture na SEF-u dajemo u tekstu e-fakture i SEF.

Kako se grade red čekanja i idempotentnost pri slanju?

Dve stvari mogu da pođu naopako i obe se rešavaju na strani sloja za slanje. Prva je da veza sa sistemom trenutno ne radi ili vraća privremenu grešku, a roba mora da krene. Druga je da isti nalog bude poslat dvaput, jer je magacioner dva puta kliknuo ili je zadatak ponovljen. Odgovor na obe je red čekanja sa jedinstvenom referencom pošiljaoca i grananjem po odgovoru.

// pseudokod radnika iz reda cekanja (server)
const RAZMACI = [30, 120, 600, 1800, 3600]; // sekunde

function obradi(zadatak) {
  const nalog = ucitajNalog(zadatak.referenca);
  const odgovor = posaljiOtpremnicu(nalog); // POST ka sistemu, ista referencaPosiljaoca

  if (odgovor.uspeh) {
    upisiStatus(nalog, odgovor.idDokumenta, odgovor.status);
    return zavrsi(zadatak);
  }
  if (odgovor.vecPostoji) {         // sistem prepoznao istu referencu
    upisiStatus(nalog, odgovor.idDokumenta, "vec_poslato");
    return zavrsi(zadatak);
  }
  if (odgovor.trajnaGreska) {       // lose telo, neispravan primalac, istekao kljuc
    return naCoveka(zadatak, odgovor.opis);
  }
  // privremeni zastoj: ponovi sa rastucim razmakom, u medjuvremenu papirni oblik
  return ponovi(zadatak, RAZMACI[Math.min(zadatak.pokusaji, RAZMACI.length - 1)]);
}

Ključna je referenca pošiljaoca. Ako uz svaki nalog šaljete istu internu šifru kao referencu, ponovljeno slanje je bezopasno: ili sistem prepozna da dokument već postoji, ili vi pre slanja proverite da za tu šifru već imate identifikator. Trajne greške, kao neispravno telo ili istekao ključ, idu čoveku, jer se ponavljanjem ne popravljaju. Privremeni zastoji se ponavljaju sa rastućim razmakom. Za slučaj privremenog prekida veze zakon je, izmenama 109/2025, dozvolio papirni oblik dok veza ne proradi, pa roba ne mora da čeka sistem. Isti obrazac reda čekanja i idempotentnosti razrađujemo za fiskalizaciju u tekstu headless shop na Next.js sa fiskalizacijom.

Tajne se čuvaju kao i svaka druga tajna serverskog koda. U repozitorijumu je samo primer promenljivih okruženja, bez vrednosti. Demo i produkcioni ključ žive u različitim okruženjima hostinga, jer su okruženja u sistemu odvojena. Pre puštanja u rad automatski proveravamo da ključ nije završio u delu koda koji se isporučuje pregledaču. Kako postavljamo odvojena okruženja i predaju klijentu opisali smo u tekstu sandbox za fiskalizaciju.

Kako rade QR kod za prevoznika i papirni oblik pri prekidu veze?

Pri slanju eOtpremnice sistem kreira QR kod, dvodimenzionalni bar-kod koji sadrži hiperlink ka sistemu. Prevoznik preuzima eOtpremnicu preko sistema ili je, ako nije korisnik sistema, drži u posedu tokom kretanja, a dužan je da je pokaže u inspekcijskom nadzoru. U nadzoru prevoznik može da pokaže QR kod umesto samog dokumenta, jer QR vodi inspektora nazad u sistem. Za integraciju to znači da vaš sloj treba da sačuva podatke za QR kod iz odgovora sistema i da ih učini dostupnim onome ko priprema transport, na primer kao ispis uz otpremni list.

Otpremnica ide pre kretanja robe, sistem vraća status i QR kod, a primalac po fizičkom prijemu šalje elektronsku prijemnicu u roku od 8 dana.

Rokovi su ovde tvrdi i ugrađuju se u logiku. Pošiljalac šalje eOtpremnicu najkasnije pre početka kretanja dobara, po članu 7 stav 1 zakona. Primalac šalje elektronsku prijemnicu u roku od 8 dana od dana potvrde fizičkog prijema dobara, po članu 8 stav 1. Za integraciju to znači dve provere: da otprema ne može da se obeleži kao krenula dok status otpremnice nije potvrđen, i da sistem podseti operatera kada se približava rok od 8 dana za prijemnicu na strani prijema.

Kako iskoristiti period tolerancije do 1. januara 2027. za testiranje?

Pokazno, demo okruženje sistema je na adresi demoeotpremnica.mfin.gov.rs i dostupno je i preko demo SEF-a. Javni Swagger opis API-ja je na istoj adresi, u odeljku swagger, pa developer može da vidi oblike zahteva i odgovora pre nego što napiše prvi red integracije. U demo okruženju se generiše zaseban API ključ i dokumenti tamo nisu zvanični, što ga čini pravim mestom za razvoj i automatske testove.

Period tolerancije grešaka, koji posle izmena 80/2026 traje do 1. januara 2027, dodatni je prozor. U tom periodu se u nadzoru ne uzimaju u obzir greške pri iskazivanju podataka u poslatim eOtpremnicama i elektronskim prijemnicama. Za firmu koja je u prvoj fazi obveznik, to znači da može da pusti integraciju u produkciju i da doradi detalje mapiranja bez straha od kazne zbog greške u podacima, dok traje tolerancija. Za firmu koja u prvu fazu ne spada, taj period je vreme da mirno izgradi i istestira vezu pre nego što obaveza počne 1. oktobra 2027. Naš redosled je uvek isti: prvo demo i Swagger, pa produkcija u periodu tolerancije, pa produkcija bez tolerancije.

Prekršajne odredbe zakona vredi imati na umu kao motiv da se posao završi na vreme, ne kao pretnju. Za pravno lice kazna je od 200.000 do 2.000.000 RSD, za odgovorno lice u pravnom licu od 50.000 do 150.000 RSD, a za preduzetnika od 50.000 do 500.000 RSD. Upravo zato je testiranje u demo okruženju i u periodu tolerancije toliko vredno: obaveza se dočeka spremno.

Šta nudimo kao pripremu za eOtpremnicu ključ u ruke?

Go Simple radi pripremu za eOtpremnicu ključ u ruke: prijavu i generisanje ključa uz firmu, sloj za slanje otpremnica u vašem ERP-u ili WMS-u, red čekanja sa idempotentnošću, prijem elektronske prijemnice i vraćanje statusa nazad u vaše evidencije, ispis QR koda uz otpremni list i automatske testove nad demo okruženjem. Klijent dobija vezu koja je istestirana u demo okruženju i puštena u produkciju u periodu tolerancije, sa dokumentacijom za svoj tim. Cenu rada dogovaramo po obimu, pa je ovde ne navodimo. Pregled onoga što radimo za firme i agencije je na strani fiskalna kasa za klijente agencije, a tehnički opis veze ka kasi na strani API za fiskalizaciju.

Manjoj firmi kojoj ne treba integracija sopstvenog ERP-a, gotova polazna tačka je Tezga eKasa. Paket Biznis, po ceni od 2.390 RSD mesečno neto, uz e-fakture na SEF i SEF radar, ima i eOtpremnice, spremne za novu obavezu, i tok porudžbina, otpremnica, račun, SEF i naplata sa istim šifarnikom i istim kupcima za kasu i za fakture. Naglašavamo šta ovde tvrdimo, a šta ne: opisujemo javni API samog sistema kojim upravlja Centralni informacioni posrednik i ne tvrdimo da Tezga API automatski šalje eOtpremnice. Kada je funkcija potrebna manjoj firmi bez svog razvoja, Tezga je jednostavniji put od integracije od nule.

Izvori: Zakon o elektronskim otpremnicama (Sl. glasnik RS 94/2024, 109/2025, 80/2026), članovi 2, 3, 7, 8, 13, 14 i 16; portal i tehničko uputstvo na eotpremnica.efaktura.gov.rs; demo okruženje i javni Swagger na demoeotpremnica.mfin.gov.rs; Sistem e-faktura na efaktura.mfin.gov.rs; prečišćen tekst propisa na paragraf.rs. Tekst nije pravni savet; obaveze i rokove za konkretnu firmu proverite sa knjigovođom i u važećem tekstu zakona.