Szerbia eOtpremnica rendszere: az ERP, a WMS és a TMS bekötése 2027. október 1-jéig

2027. október 1-jétől Szerbiában két áfaregisztrált magáncég közötti minden áruszállításhoz elektronikus szállítólevél, eOtpremnica kell, amelyet a Pénzügyminisztérium rendszerén keresztül kell elküldeni, mielőtt az áru elindul. Az átvevő cégnek ugyanabban a rendszerben, napokon belül vissza kell igazolnia az átvételt, a fuvarozónak pedig ellenőrzéskor fel kell tudnia mutatni a szállítólevelet.

Ez lefedi az értékesítési szállításokat, a visszárukat és a saját raktárai közötti átszállításokat. A szállítólevél megszűnik az ERP által nyomtatott űrlap lenni. UBL-fájl lesz belőle, amely egy állami API-n megy keresztül, azonosítóval és QR-kóddal tér vissza, majd mindkét oldalon egy státuszfolyamaton halad végig.

Kinek kell elolvasnia

Ha Minimaxból, BizniSoftból vagy Pantheonból számláz és szállít, a szoftverszállítója már szállítja az eOtpremnica-támogatást. Ha a volumene elég alacsony ahhoz, hogy a szállítóleveleket a minisztérium ingyenes webportálján vagy mobilalkalmazásában gépelje be, az is működik. Olvassa el az átvételi határidőkről szóló részt, képezze ki a rakodónál dolgozókat, és nagyjából végzett is.

Ez a cikk a másik csoportnak szól: azoknak a forgalmazóknak, gyártóknak, nagykereskedőknek és fuvarozóknak, amelyeknél a kiszállítás és az áruátvétel saját ERP-n, testre szabott WMS-en, TMS-en vagy B2B-rendeléseket rögzítő webáruház-háttérrendszeren fut. Senki nem fog Önnek frissítést szállítani. Az integrációt meg kell építenie.

Mi érvényes már, és mi változik

Az elektronikus szállítólevelekről szóló törvény (Zakon o elektronskim otpremnicama) 2024-ből származik, és azóta kétszer módosították. A legutóbbi módosító törvény, amely a Službeni glasnik 80/2026. számában jelent meg 2026. augusztus 31-én, megtartotta a 2027. októberi dátumot. A minisztérium GYIK-ja és az egységes szerkezetbe foglalt szöveg rögzíti a szakaszokat.

2026. január 1. óta:

• A magáncégek jövedéki termékekre küldenek és fogadnak eOtpremnicát: dohányra, nikotintermékekre, kávéra, alkoholos italokra és kőolajtermékekre.
• A magáncégek minden, közszférabeli szervezetnek szállított áruhoz küldenek eOtpremnicát, a közszférabeli szervezetek pedig a saját áruszállításaikhoz.
• A fuvarozók ezeknél a szállításoknál felmutatják a szállítólevelet.

Az éles rendszer 2025. december 30. óta működik. A belső szoftverek tesztelésére szolgáló demókörnyezet 2025. március 5. óta érhető el.

2027. október 1-jétől:

• A küldési kötelezettség, ha a küldő és a címzett is magánszektorbeli szervezet, és az áru nem jövedéki termék.
• Minden magánszektorbeli szervezet fogadási kötelezettsége.
• A fuvarozók ezeknél a szállításoknál is felmutatják a szállítólevelet.

Néhány részlet meglepi az embereket. Ugyanazon gyártelepen belül két raktár közötti átszállításhoz belső szállítólevél kell (az XML-ben Int típus), ha az áru címet vált, és közúton halad. Importnál belső szállítólevél kell attól a helytől, ahol a rendelkezési jogot megszerezte, vagy bizonyos esetekben a vámhivataltól, a raktáráig. Exportnál általában addig a pontig kell egy, ahol a szállítmányozó átveszi az árut. A pénztárgépes nyugtaadási (fiskalizációs) törvény alá tartozó kiskereskedelmi értékesítés mentes, így az a webáruház, amely fiskális nyugtával értékesít, ezeknél a rendeléseknél kívül esik a hatályon. A nagykereskedelmi oldala viszont nem.

Az augusztusi módosítás azt is kimondja, hogy 2027. január 1-jéig a felügyeleti szervek nem veszik figyelembe az elküldött szállítólevelekben és átvételi elismervényekben lévő adathibákat. Ez a jövedéki termékeket és a közszférát kiszolgáló küldőknek segít. A 2027. októberi dátumon semmit nem változtat.

Elmozdulhat a dátum? A törvényt két éven belül kétszer módosították, így további változás lehetséges. Az imént elfogadott módosítás viszont megtartotta a dátumot. Tervezzen vele.

A határidők az átvételi lépésnél vannak

A küldés a könnyebbik fele. Az egységes szerkezetű törvény a kemény határidőket az átvevő oldalra helyezi.

1. Mielőtt az áru elindul, a küldő elküldi a szállítólevelet. Amíg a címzett nem igazolja vissza a fizikai átvételt, a küldő indoklással visszavonhatja.
2. A fizikai átvételt azon a napon kell visszaigazolni, amikor az árut átveszik, de legkésőbb az átvétel megkezdését követő három munkanapon belül.
3. E visszaigazolástól számított nyolc napon belül a címzett egészben vagy részben elfogadja vagy elutasítja a szállítást, egy ePrijemnica (elektronikus átvételi elismervény) elküldésével.
4. Az a magánszektorbeli címzett, amely nyolc napon belül semmit nem küld, úgy tekintendő, mint aki a szállítást teljes egészében elutasította. Közszférabeli címzettnél ennek az ellenkezője igaz: a hallgatás elfogadást jelent.
5. Részleges elfogadásnál a küldőnek az elektronikus átvételi elismervény beérkezésétől számítva 30 napja van, hogy elfogadja az eltéréseket. Ellenkező esetben úgy kell tekinteni, mint aki az elismervényt teljes egészében elutasította.
6. A fizikai átvétel visszaigazolása nélküli szállítólevél a szállítás megkezdése után 30 nappal érvényét veszti.

Amikor mindkét fél egyetért, a dokumentumok Usaglašeno státuszba kerülnek (az API-ban Fulfilled), és ezután semmi nem módosítható.

A fizikai átvételi határidő elmulasztása nevesített szabálysértés: a cégre 200 000 és 2 000 000 dinár közötti, a felelős személyre 50 000 és 150 000 dinár közötti bírság szabható ki. Ugyanez a sáv vonatkozik arra, ha egyáltalán nem küldenek szállítólevelet.

A gyakorlati következtetés: a fizikai átvétel a rakodóhoz tartozik, a WMS-be, abba a pillanatba, amikor az árut bevételezik. Ha valakinek a hó végi egyeztetésére vár, a határidő már lejárt.

Mit kell megépíteni a minisztérium API-jához

A műszaki dokumentáció egy UBL 2.1 XML-t cserélő REST API-t ír le. Az eOtpremnica egy DespatchAdvice, az ePrijemnica egy ReceiptAdvice, és minden más lépés (visszavonás, a szállítás megkezdése, járműcsere, fizikai átvétel, egy elektronikus átvételi elismervény elfogadása vagy elutasítása) egy numerikus kóddal ellátott ApplicationResponse. A minisztérium 2025. december 5-én workshopot tartott az informatikai szektornak a dokumentumtípusokról, az XML-bővítményekről, a beküldésről és a webhookokról.

Küldés

Minden dokumentum egyetlen végpontra megy, a POST /public/documents/requests címre, egy saját, egyedi kérésazonosítóval. A feldolgozás aszinkron. Az eredmény később érkezik, webhookon keresztül, vagy a /public/documents/requests/changes lekérdezésével, amely minden kérést függőben lévőként, sikeresként vagy sikertelenként jelent, a csatolt üzleti hibákkal együtt.

Az ERP-nek tehát kimenő sor (outbox) kell: szállítólevelenként egy rekord, egy állapotgép, és egy újrapróbálkozási útvonal, amely nem hoz létre duplikátumokat. A rendszer elutasítja azt a dokumentumszámot, amely a cégénél már létezik, ami segít, de csak akkor, ha a számozása az újrapróbálkozások során stabil marad.

A minisztérium API-felhasználóknak szóló GYIK-jában szereplő hibalista megmutatja, hol van az adatmunka:

• A kiállítás dátumának a mai napnak kell lennie, szerbiai idő szerint. Nincs visszadátumozás, és a tegnapi szállítóleveleket sem lehet éjszakára sorban tartani.
• Minden címhez (a sajátjához, az ügyféléhez, a fuvarozóéhoz, a fel- és lerakodási helyekhez) utca és település kell.
• Saját szállításnál, fuvarozónál vagy a címzett általi szállításnál a fuvarozó, a jármű rendszáma és a szállítóeszköz kötelező. Saját szállításhoz a cégénél be kell kapcsolni a fuvarozói státuszt is.
• A mennyiségekhez mértékegységkód tartozik. A sorokat 1-től számozzák. A GTIN, ha megadják, csak számjegyekből állhat.
• A címzettnek regisztráltnak és aktívnak kell lennie. A GET /public/companies/status küldés előtt ellenőrzi a PIB-et.

A törzsadatok általában nagyobb feladatot jelentenek, mint az XML. Egy validátor végponttal a beküldés előtt tesztelheti a dokumentumokat, és ennek a tesztcsomagjában a helye.

Fogadás és a raktár

A beérkező szállítólevelek a /public/documents/customers/changes végponton keresztül érkeznek, dátumonként lekérdezve, oldalanként 1000 változással, vagy webhookon. A webhook-előfizetés napra szól: a /public/webhook-notifications/subscribe hívása a következő napot fedi le. Futtassa ütemezett feladatként, riasszon, ha meghiúsul, és tartsa meg a lekérdező végpontot éjszakai egyeztetésre, hogy egy elmaradt push értesítésből ne legyen elmulasztott határidő.

Minden beérkező szállítólevél várt bevételezésként kerüljön a WMS-be, a szállító cikkszámait a sajátjaira leképezve. Amikor az árut bevételezik, a WMS elküldi a fizikai átvétel műveletét. A mennyiségi és minőségi ellenőrzés után elküldi az ePrijemnicát: soronként a beérkezett mennyiséget, valamint az elutasított és ugyanazzal a járművel visszaküldött mennyiséget. A rendszer nem fogad el a beérkezettnél nagyobb elutasított mennyiséget.

A minisztérium saját szerepkörmodellje hasznos sablon. A raktári szerepkör listázhatja és letöltheti a beérkező szállítóleveleket, és visszaigazolhatja a fizikai átvételt. Egy WMS-jogosultságnak is ez a megfelelő formája.

Küldőként Ön is megkapja a másik fél elektronikus átvételi elismervényét, és el kell fogadnia vagy el kell utasítania. A 30 napos egyeztetési időszakot az ERP-ben kövesse, ne valakinek a postafiókjában.

Összekapcsolás a SEF e-számlákkal

A szállítólevél összekapcsolása egy SEF-beli e-számlával nem kötelező. Amint egy szállítólevelet elküldtek, és a tényleges kiszállítás időpontja elmúlt, a SEF egy vagy több szállítólevelet összekapcsolhat egy e-számlával, és a számlának nem kell megvárnia, hogy az átvételi folyamat lezáruljon. Ha a rendelés, a szállítás és a számla háromutas egyeztetése már az ERP-ben fut, az összekapcsolás ugyanazt a bizonyítékot adja az ügyfele szállítói könyvelésének. Az e-számlázási integrációs munkánk lefedi a SEF oldalát.

Fuvarozók és az út

A sofőr a minisztérium fuvarozói alkalmazásából mutathatja fel a szállítólevelet. Ha a fuvarozó nem felhasználója a rendszernek, a küldő kinyomtatja a szállítólevelet, a fuvarozó indulás előtt aláírja, a küldő pedig az áru elindulása előtt feltölti az aláírt példányt. Az augusztusi módosítás óta az a fuvarozó, amely nem tudja használni a rendszert, ehelyett a szállítólevél elküldésekor generált QR-kódot is felmutathatja; a küldő ilyenkor indulás előtt csatolja a nyomtatható nézetet. A TMS-nek ezek közül azt kell előállítania, amelyiket a fuvarozói használják, az API pedig a QR-kódot külön is visszaadja a címkékhez.

Rendszerkiesés esetére van papíralapú tartalék megoldás: három nyomtatott példány a Szerb Nemzeti Bank Topčider pénzverdéjéből származó biztonsági hologramos matricákkal, amelyeket a következő munkanapig rögzíteni kell a rendszerben. A matricákat vásárolja meg, mielőtt szüksége lenne rájuk.

Hogyan működik az API-kulcs

A törvényes képviselő regisztrálja a céget, az állami eID-portálon keresztül bejelentkezve. A kulcsokat ezután a webes felületen hozzák létre (Settings, API settings, Admin module, API keys). A demó- és az éles környezet külön van, így mindkettőhöz kulcsokkal kell számolnia.

A kulcs a céget azonosítja. Az API-s GYIK egyenesen fogalmaz: nem küldhet dokumentumokat egy másik cég nevében, és a rendszer a bemutatott API-kulcs alapján ismeri fel a céget. A gyakorlatban:

• Egy öt jogi személyből álló csoportnak öt kulcs kell, és egy útválasztó, amely a PIB alapján választja ki a megfelelőt.
• Egy megosztott szolgáltató központ vagy egy szoftverház nem küldheti át minden ügyfelét egyetlen kulccsal.
• A kulcsok titokkezelőbe valók, gazdával és rotációs eljárással, nem az ERP-szerver egyik konfigurációs fájljába.

12 hónapos terv

2026 októberét írjuk. 2027. október 1-jétől visszafelé számolva:

2026. október és december között: leltár és hozzáférés.

• Vegye számba az összes szállítástípust: értékesítés, visszárú, raktárak közötti átszállítás, import, export, saját flotta, külső fuvarozók, ügyfél általi elszállítás.
• Regisztrálja a céget az éles rendszerben, és szerezzen demó API-kulcsokat.
• Kezdje el a törzsadatok tisztítását: címek, a partnerek PIB-je és cégjegyzékszáma, fuvarozók, járművek, mértékegységek.

2027. január és március között: a küldési útvonal.

• A DespatchAdvice előállítása a kiszállításokból, a kimenő sorral, az aszinkron státuszkövetéssel és a hibakezeléssel.
• Napi webhook-előfizetési feladat, plusz lekérdezéses egyeztetés.
• A validátor a CI-ban fut a demókörnyezettel szemben.

2027. április és június között: fogadás és átvétel.

• A beérkező szállítólevelek várt bevételezésként a WMS-be.
• Fizikai átvétel a rakodónál, ePrijemnica az ellenőrzések után, riasztás a háromból a második napon és a nyolcból a hatodik napon.
• A küldőként kapott elektronikus átvételi elismervények elfogadásának és elutasításának kezelése. SEF-összekapcsolás, ha szeretné.

2027. július és szeptember között: az út és a pilot.

• Fuvarozói folyamat, nyomtatás és QR, az offline eljárás a helyszínen tartott matricákkal.
• Futtasson valódi szállítóleveleket éles környezetben azokkal a partnerekkel, akik már regisztráltak; a magáncégek már most is használhatják önkéntesen a rendszert.
• Képezze ki a raktári dolgozókat és a sofőröket. Szeptemberben fagyassza be a változtatásokat.

Tizenkét hónap kényelmes egyetlen, tiszta adatokkal rendelkező jogi személynek. Szoros annak a csoportnak, amelynek több jogi személye, több raktára és évek óta érintetlen törzsadatai vannak.

Hol kaphat segítséget

A C9 Groupnak irodája van Újvidéken (Novi Sad), így a szerb szabályok hazai terepnek számítanak nálunk. Magát az integrációt építjük meg: az UBL-előállítást, az API-klienst, a webhookok kezelését és a raktári átvételi folyamatot a meglévő ERP-jében, WMS-ében vagy webáruház-háttérrendszerében. Nézze meg az ERP-modernizációs szolgáltatásunkat, vagy írjon az office@c9group.dev címre.