Nalog za prijevoz: što je, što sadrži i kako njime upravljati

Ukratko

U svakodnevnoj praksi mnoge tvrtke nazivaju nalogom za prijevoz obrazac kojim se organizira vožnja: klijent, mjesto preuzimanja, odredište, datum, roba, reference, dogovorena cijena i operativne upute. To je vrlo koristan alat, ali treba izbjeći jednu zabunu: operativni nalog ne podudara se automatski s ugovorom o prijevozu uređenim zakonom.

Za MSP je najčvršće rješenje tretirati nalog kao jedini operativni izvor za pojedinačnu misiju i povezati ga, kad postoji, s ugovorom ili komercijalnim sporazumom koji uređuje odnos s klijentom. Tako osoba koja planira zna što treba izvršiti, dok uprava i administracija mogu rekonstruirati gospodarski i ugovorni sporazum na kojem se usluga temelji.

Operativni nalog i ugovor nisu ista stvar

Ugovor o prijevozu pravni je odnos kojim prijevoznik preuzima obvezu premještanja robe s jednog mjesta na drugo uz naknadu. Nalog je često dokument kojim se taj odnos konkretizira u određenoj aktivnosti: „preuzmi sutra u 08:00 u Bergamu, isporuči u Veronu, 12 paleta, referenca klijenta X”.

U trajnim odnosima može postojati okvirni ugovor i deseci ili stotine provedbenih naloga. U drugim slučajevima prihvaćena ponuda, e-pošta, nalog i dogovoreni uvjeti mogu zajedno dokumentirati odnos. Zato nije razborito odlučiti da „nalog je dovoljan” ili, obratno, da „nalog nema nikakvu vrijednost”: treba promatrati sadržaj, oblik i kontekst odnosa.

Operativno je preporučljivo razlikovati najmanje tri razine:

1. komercijalni sporazum/ugovor, koji uređuje gospodarske uvjete i odgovornosti;
2. nalog za prijevoz, koji opisuje pojedinačnu uslugu;
3. dokumenti izvršenja i dokaza, kao što su DDT, CMR, POD i drugi relevantni dokumenti.

Što kaže Zakonodavni dekret 286/2005

Središnja talijanska referenca za ugovor o cestovnom prijevozu robe za račun trećih osoba je Zakonodavni dekret br. 286 od 21. studenoga 2005. Članak 6. u pravilu predviđa pisani oblik i sigurni datum radi promicanja korektnosti i transparentnosti u odnosima među strankama. Norma također utvrđuje bitne elemente ugovora sklopljenih u pisanom obliku.

Među elementima koje propis zahtijeva ili razmatra u ugovoru jesu identifikacija prijevoznika i nalogodavca, eventualni utovarivač, broj upisa prijevoznika u Albo, vrsta i količina robe, mjesta preuzimanja i ponovne predaje te gospodarski elementi predviđeni važećim tekstom. Propis je više puta mijenjan: prije korištenja standardnog ugovornog predloška preporučljivo je stoga provjeriti ažurirani tekst i dati ga na potvrdu stručnjaku.

Za MSP praktična poanta nije pretvoriti svakog dispečera u odvjetnika. Riječ je o stvaranju toka u kojem bitne informacije ne ostaju raspršene između telefonskog poziva i chata. Dobro strukturiran nalog ne zamjenjuje ugovor, ali smanjuje operativne nejasnoće i olakšava dokazivanje onoga što je zatraženo i onoga što se promijenilo.

Koje je podatke korisno prikupiti

Obrazac naloga trebao bi sadržavati najmanje:

• jedinstveni broj ili referencu naloga;
• klijenta/nalogodavca i operativni kontakt;
• eventualnog utovarivača različitog od nalogodavca;
• mjesto, datum i vremenski prozor preuzimanja;
• mjesto, datum i vremenski prozor isporuke;
• opis robe;
• količinu, težinu, pakete ili palete kada je to relevantno;
• eventualna obilježja koja utječu na potrebno vozilo;
• cijenu ili referencu na cjenik/ugovor, ako to organizacija poduzeća predviđa;
• bilješke i upute primljene od klijenta;
• povezane dokumente;
• dodijeljenog vozača i vozilo;
• status aktivnosti;
• povijest relevantnih izmjena.

Za opasnu robu, otpad, hranu, izvanredne prijevoze ili druge posebne kategorije mogu biti potrebne dodatne informacije i dokumenti. Standardni nalog stoga se ne smije upotrebljavati kao univerzalni kontrolni popis usklađenosti.

Kako upravljati izmjenama i verzijama

Pravi problem počinje kada se nalog promijeni. Ako klijent pomakne preuzimanje s 08:00 na 11:00 ili promijeni adresu isporuke, novi podatak mora odmah postati trenutačna operativna verzija. Istodobno ostavljanje stare e-pošte, Excel tablice i WhatsApp poruke stvara tri različite „istine”.

Dobro unutarnje pravilo glasi: samo jedan obrazac predstavlja trenutačno stanje naloga, dok važne promjene ostaju evidentirane u povijesti. Nije potrebno čuvati svaku sitnu ispravku, ali mora biti moguće razumjeti tko je promijenio bitnu informaciju i kada.

Praktični primjer

Klijent e-poštom šalje zahtjev za 18 paleta iz Brescie u Bolognu. Dispečer evidentira nalog i dodjeljuje vozilo i vozača. Poslijepodne klijent priopćava da isporuka više neće biti u gradu Bologni, nego u skladištu u Interportu.

Ako promjena ostane samo u chatu dispečera, vozač može krenuti s pogrešnom adresom. Ako se, naprotiv, izmjenom ažurira operativni nalog, novo odredište postaje referenca za sve. Povijest čuva trag izmjene, a tvrtka može rekonstruirati događaj u slučaju spora.

Operativni kontrolni popis

• Ima li svaki nalog jedinstveni identifikator?
• Jesu li klijent, preuzimanje i isporuka uvijek popunjeni?
• Bilježe li se težina i količina kada utječu na vozilo i dokumentaciju?
• Jesu li posebne upute vidljive osobama koje ih moraju izvršiti?
• Bilježe li se važne izmjene i priopćavaju li se vozaču?
• Može li se pronaći odgovarajući ugovor/cjenik?
• Jesu li DDT, CMR ili drugi dokumenti povezani s istim nalogom kada postoje?

Česte pogreške

Korištenje WhatsAppa kao arhive naloga. Chat je odličan za komunikaciju, ali slab kao jedini izvor operativnih informacija.

Miješanje naloga i ugovora. Potpun nalog pomaže izvršenju, ali sam po sebi ne jamči da su ispunjeni svi pravni zahtjevi pisanog ugovora.

Prepisivanje izmjene bez traga. Ako se odredište ili vrijeme promijene, može biti važno znati kada i zašto.

Unos samo onoga što treba dispečeru. Nalog bi trebao biti čitljiv i administraciji i vozaču, uz pristupe usklađene s ulogom.