L'eOtpremnica in Serbia: collegare gestionale, WMS e TMS entro il 1° ottobre 2027

Dal 1° ottobre 2027 ogni movimentazione di merci tra due società private serbe registrate ai fini IVA richiede un documento di trasporto elettronico, l'eOtpremnica, inviato tramite il sistema del Ministero delle Finanze prima che la merce parta. La società che la riceve deve confermarne il ricevimento nello stesso sistema entro pochi giorni, e il vettore deve poter esibire il documento durante un controllo.

Questo vale per le consegne di vendita, i resi e i trasferimenti tra i vostri magazzini. Il documento di trasporto smette di essere un modulo che il vostro gestionale stampa. Diventa un file UBL che passa da un'API dello Stato, torna indietro con un identificativo e un codice QR, e poi attraversa un flusso di stati da entrambe le parti.

Chi deve leggere questo articolo

Se fatturate e spedite da Minimax, BizniSoft o Pantheon, il vostro fornitore offre già il supporto per l'eOtpremnica. Se i vostri volumi sono abbastanza bassi da poter inserire i documenti a mano nel portale web gratuito del Ministero o nella sua app mobile, va bene anche così. Leggete la sezione sui termini di ricevimento, formate il personale della banchina di carico e avete quasi finito.

Questo articolo è per l'altro gruppo: distributori, produttori, grossisti e vettori la cui spedizione e il cui ricevimento merci passano dal proprio gestionale, da un WMS personalizzato, da un TMS o dal back end di un negozio online che registra ordini B2B. Nessuno vi distribuirà un aggiornamento. L'integrazione dovete costruirla voi.

Cosa si applica già e cosa cambia

La legge sui documenti di trasporto elettronici (Zakon o elektronskim otpremnicama) risale al 2024 ed è stata modificata due volte da allora. L'ultima legge di modifica, pubblicata nello Službeni glasnik 80/2026 il 31 agosto 2026, ha mantenuto la data di ottobre 2027. Le FAQ del Ministero e il testo consolidato fissano le fasi.

Dal 1° gennaio 2026:

• Le società private inviano e ricevono l'eOtpremnica per i beni soggetti ad accisa: tabacco, prodotti a base di nicotina, caffè, bevande alcoliche e prodotti petroliferi.
• Le società private la inviano per qualsiasi merce consegnata a un ente del settore pubblico, e gli enti pubblici la inviano per le proprie movimentazioni.
• I vettori esibiscono il documento per queste movimentazioni.

Il sistema di produzione è attivo dal 30 dicembre 2025. L'ambiente demo, pensato per testare il software interno, è aperto dal 5 marzo 2025.

Dal 1° ottobre 2027:

• L'obbligo di invio quando mittente e destinatario sono entrambi soggetti del settore privato e la merce non è soggetta ad accisa.
• L'obbligo di ricezione per ogni soggetto del settore privato.
• L'esibizione del documento da parte dei vettori per queste movimentazioni.

Alcuni dettagli colgono di sorpresa. Un trasferimento tra due magazzini all'interno dello stesso complesso industriale richiede un documento interno (tipo Int nell'XML) se la merce cambia indirizzo e percorre una strada pubblica. Un'importazione richiede un documento interno dal luogo in cui avete acquisito la disponibilità della merce, o in alcuni casi dalla dogana, fino al vostro magazzino. Un'esportazione di solito ne richiede uno fino al punto in cui subentra lo spedizioniere. Le vendite al dettaglio soggette alla legge sulla fiscalizzazione sono esenti, quindi un negozio online che vende con scontrino fiscale è fuori per quegli ordini. Il suo lato all'ingrosso no.

La modifica di agosto stabilisce anche che fino al 1° gennaio 2027 gli organi di vigilanza non terranno conto degli errori nei dati dei documenti e delle ricevute inviati. Aiuta chi invia per beni in accisa e verso il settore pubblico. Per ottobre 2027 non cambia nulla.

La data potrebbe slittare? La legge è stata modificata due volte in meno di due anni, quindi altri cambiamenti sono possibili. Ma la modifica appena approvata ha mantenuto la data. Pianificate su quella.

I termini stanno nel ricevimento

Inviare è la metà facile. La legge consolidata mette i termini stringenti sul lato del destinatario.

1. Prima che la merce si muova, il mittente invia il documento. Finché il destinatario non conferma il ricevimento fisico, il mittente può annullarlo, indicandone il motivo.
2. Il ricevimento fisico va confermato il giorno in cui la merce viene presa in consegna, o al più tardi tre giorni lavorativi dopo l'inizio del ricevimento.
3. Entro otto giorni da quella conferma, il destinatario accetta o rifiuta la consegna, in tutto o in parte, inviando una ePrijemnica (ricevuta elettronica).
4. Un destinatario del settore privato che non invia nulla entro otto giorni si considera aver rifiutato per intero la consegna. Per un destinatario del settore pubblico vale il contrario: il silenzio vale come accettazione.
5. In caso di accettazione parziale, il mittente ha 30 giorni dall'arrivo della ricevuta elettronica per accettare le differenze. Altrimenti si considera che abbia rifiutato per intero la ricevuta.
6. Un documento senza conferma del ricevimento fisico perde validità 30 giorni dopo l'inizio della movimentazione.

Quando entrambe le parti concordano, i documenti raggiungono lo stato Usaglašeno (Fulfilled nell'API) e da lì non si può più modificare nulla.

Mancare il termine per il ricevimento fisico è un illecito previsto dalla legge: da 200.000 a 2.000.000 di dinari per la società e da 50.000 a 150.000 dinari per il responsabile. La stessa forbice si applica a chi non invia affatto il documento.

La conclusione pratica: il ricevimento fisico va registrato in banchina, nel WMS, nel momento in cui la merce viene caricata a magazzino. Se aspetta qualcuno che riconcilia a fine mese, il termine è già scaduto.

Cosa costruire sull'API del Ministero

La documentazione tecnica descrive un'API REST che scambia XML UBL 2.1. L'eOtpremnica è un DespatchAdvice, l'ePrijemnica un ReceiptAdvice, e ogni altro passaggio (annullamento, inizio del trasporto, cambio di veicolo, ricevimento fisico, accettazione o rifiuto di una ricevuta elettronica) è un ApplicationResponse con un codice numerico. Il 5 dicembre 2025 il Ministero ha tenuto un workshop per il settore IT su tipi di documento, estensioni XML, invio e webhook.

Invio

Ogni documento va a un unico endpoint, POST /public/documents/requests, con un vostro ID di richiesta univoco. L'elaborazione è asincrona. Il risultato arriva dopo, tramite webhook o interrogando /public/documents/requests/changes, che riporta ogni richiesta come in attesa, riuscita o fallita, con gli errori di business allegati.

Quindi il vostro gestionale ha bisogno di una coda in uscita: un record per documento, una macchina a stati e un percorso di nuovo tentativo che non crei duplicati. Il sistema rifiuta un numero di documento già esistente per la vostra società, il che aiuta, ma solo se la vostra numerazione resta stabile tra un tentativo e l'altro.

L'elenco degli errori nelle FAQ sull'API del Ministero mostra dove sta il lavoro sui dati:

• La data di emissione deve essere quella di oggi, nell'ora serba. Niente retrodatazioni, e niente documenti di ieri tenuti in coda durante la notte.
• Ogni indirizzo (il vostro, quello del cliente, quello del vettore, i luoghi di carico e scarico) richiede via e città.
• Per il trasporto in proprio, con un vettore o a cura del destinatario, sono obbligatori vettore, targa del veicolo e mezzo di trasporto. Il trasporto in proprio richiede anche di attivare lo stato di vettore per la vostra società.
• Le quantità portano un codice di unità di misura. Le righe sono numerate da 1. Un GTIN, se indicato, contiene solo cifre.
• Il destinatario deve essere registrato e attivo. GET /public/companies/status verifica un PIB prima dell'invio.

Le anagrafiche di solito sono un lavoro più grosso dell'XML. Un endpoint di validazione vi permette di testare i documenti prima dell'invio, e va inserito nella vostra suite di test.

Ricezione e magazzino

I documenti in arrivo passano da /public/documents/customers/changes, interrogato per data a 1.000 modifiche per pagina, oppure tramite webhook. La sottoscrizione ai webhook è giornaliera: una chiamata a /public/webhook-notifications/subscribe copre il giorno successivo. Eseguitela come job pianificato, fate scattare un avviso quando fallisce, e tenete l'endpoint di interrogazione come riconciliazione notturna, così un push mancato non diventa un termine mancato.

Ogni documento in arrivo dovrebbe finire nel WMS come ricevimento atteso, con i codici articolo del fornitore mappati sui vostri. Quando la merce viene caricata a magazzino, il WMS invia l'azione di ricevimento fisico. Dopo i controlli di quantità e qualità invia l'ePrijemnica: per ogni riga, la quantità arrivata e quella rifiutata e rimandata indietro sullo stesso veicolo. Il sistema non accetta una quantità rifiutata superiore a quella ricevuta.

Il modello di ruoli del Ministero è un modello utile. Il suo ruolo di magazzino può elencare e scaricare i documenti in arrivo e confermare il ricevimento fisico. È la forma giusta anche per un permesso nel WMS.

Come mittente ricevete anche la ricevuta elettronica dell'altra parte e dovete accettarla o rifiutarla. Seguite la finestra di 30 giorni per l'accordo nel gestionale, non nella casella di posta di qualcuno.

Il collegamento con le fatture elettroniche SEF

Collegare un documento di trasporto a una fattura elettronica in SEF è facoltativo. Una volta inviato il documento e superato l'orario effettivo di spedizione, SEF può collegare uno o più documenti a una fattura elettronica, e la fattura non deve aspettare la fine del flusso di ricevimento. Se il vostro abbinamento a tre vie tra ordine, consegna e fattura gira già nel gestionale, il collegamento dà alla contabilità fornitori del vostro cliente la stessa prova. Il nostro lavoro di integrazione della fatturazione elettronica copre il lato SEF.

Vettori e strada

L'autista può mostrare il documento dall'app del Ministero per i vettori. Se il vettore non è un utente del sistema, il mittente stampa il documento, il vettore lo firma prima della partenza e il mittente carica la copia firmata prima che la merce si muova. Dalla modifica di agosto, un vettore che non può usare il sistema può invece mostrare il codice QR generato all'invio del documento; il mittente allega poi la versione stampabile prima della partenza. Il vostro TMS deve produrre quella tra queste soluzioni che usano i vostri vettori, e l'API restituisce il codice QR anche da solo, per le etichette.

In caso di interruzione del servizio esiste una procedura cartacea: tre copie stampate con bollini olografici di sicurezza della zecca di Topčider della Banca nazionale di Serbia, registrate nel sistema entro il giorno lavorativo successivo. Comprate i bollini prima che vi servano.

Come funziona la chiave API

Il legale rappresentante registra la società accedendo tramite il portale statale dell'identità elettronica. Le chiavi si creano poi nell'interfaccia web (Impostazioni, impostazioni API, modulo Admin, chiavi API). Demo e produzione sono ambienti separati, quindi prevedete chiavi in entrambi.

La chiave identifica la società. Le FAQ sull'API sono nette: non potete inviare documenti per conto di un'altra società, e il sistema riconosce la società dalla chiave API che presenta. In pratica:

• Un gruppo con cinque persone giuridiche ha bisogno di cinque chiavi e di un instradatore che scelga quella giusta in base al PIB.
• Un centro servizi condiviso o una software house non può far passare tutti i clienti da una sola chiave.
• Le chiavi vanno in un archivio di segreti, con un responsabile e una procedura di rotazione, non in un file di configurazione sul server del gestionale.

Un piano di 12 mesi

Siamo a ottobre 2026. A ritroso dal 1° ottobre 2027:

Da ottobre a dicembre 2026: inventario e accessi.

• Elencate ogni tipo di movimentazione: vendite, resi, trasferimenti tra magazzini, importazioni, esportazioni, flotta propria, vettori terzi, ritiro da parte del cliente.
• Registrate la società in produzione e ottenete le chiavi API per la demo.
• Iniziate a ripulire le anagrafiche: indirizzi, PIB e numeri di registrazione dei partner, vettori, veicoli, unità di misura.

Da gennaio a marzo 2027: il percorso di invio.

• Generazione del DespatchAdvice dalle spedizioni, con la coda in uscita, il monitoraggio asincrono degli stati e la gestione degli errori.
• Job giornaliero di sottoscrizione ai webhook più riconciliazione per interrogazione.
• Il validatore gira nella CI contro l'ambiente demo.

Da aprile a giugno 2027: ricezione e ricevimento.

• Documenti in arrivo nel WMS come ricevimenti attesi.
• Ricevimento fisico in banchina, ePrijemnica dopo i controlli, avvisi al secondo giorno su tre e al sesto giorno su otto.
• Gestione di accettazione e rifiuto delle ricevute elettroniche che ricevete come mittenti. Collegamento a SEF, se lo volete.

Da luglio a settembre 2027: la strada e il pilota.

• Flusso dei vettori, stampa e QR, la procedura offline con i bollini già in sede.
• Documenti reali in produzione con i partner già registrati; le società private possono già usare il sistema su base volontaria.
• Formazione di magazzinieri e autisti. Congelamento delle modifiche a settembre.

Dodici mesi sono comodi per una sola persona giuridica con dati puliti. Sono stretti per un gruppo con più società, più magazzini e anagrafiche che nessuno tocca da anni.

Dove trovare aiuto

C9 Group ha un ufficio a Novi Sad, quindi per noi le regole serbe sono di casa. Costruiamo l'integrazione vera e propria: generazione dell'UBL, client dell'API, gestione dei webhook e flusso di ricevimento a magazzino dentro il vostro gestionale, WMS o back end di e-commerce esistente. Vedete il nostro servizio di modernizzazione dei gestionali, oppure scrivete a office@c9group.dev.