No B/L līdz dīkstāves rēķinam: kur pazūd dienas

Konosaments (B/L) un dīkstāves (D&D) rēķins izskatās kā divi pilnīgi atšķirīgi dokumenti — viens tiek izsniegts kravas iekraušanas brīdī, otrs parādās nedēļas vēlāk, kad konteiners jau sen izkrauts. Patiesībā tas ir tas pats ceļš, tikai redzams caur diviem dažādiem dokumentiem. Un tieši starp tiem, punktos, ko neviens no dokumentiem atsevišķi neparāda, visbiežāk pazūd dienas, par kurām vēlāk parādās rēķins.

Konteinera ceļš četros punktos

B/L tiek izsniegts iekraušanas ostā — tajā norādīts paredzamais ierašanās laiks (ETA), pārvadātājs un maršruts. Šis ir pirmais punkts, kurā varētu sākt sekot laikam, bet parasti to nedara neviens, jo šajā posmā B/L tiek izmantots tikai kā īpašumtiesību un pārvadājuma dokuments, nevis kā laika atskaites sākums.

Otrais punkts — faktiskā izkraušana galamērķa ostā. Tieši no šī datuma (nevis no ETA, kas bieži atšķiras no realitātes par vairākām dienām) lielākā daļa pārvadātāju sāk skaitīt līgumisko brīvo laiku. Ja uzņēmums šo datumu neuzskaita nekavējoties, bet uzzina par to tikai saņemot rēķinu, tas jau ir zaudējis iespēju pārbaudīt, vai aprēķins sācies pareizajā brīdī.

Trešais punkts — konteinera saņemšana no termināļa (gate-out). Starp izkraušanu un saņemšanu bieži paiet dienas — termināļa noslodzes, muitas procedūru vai vienkārši loģistikas plānošanas dēļ — bet brīvā laika skaitītājs jau tobrīd darbojas, neatkarīgi no iemesla.

Ceturtais punkts — tukšā konteinera atgriešana. Tieši šis datums, salīdzinot ar izkraušanas datumu, kļūst par D&D rēķina pamatu. Un tieši šeit visbiežāk rodas neatbilstība: rēķinā norādītais atgriešanas datums var atšķirties no reālā, jo termināļa reģistrācijas sistēma un pārvadātāja uzskaites sistēma ne vienmēr ir sinhronizētas.

Kāpēc šie četri punkti reti tiek redzēti kopā

Problēma nav tā, ka šie dati neeksistē — tie ir izkaisīti starp B/L, termināļa gate-ierakstiem un pārvadātāja rēķinu, parasti dažādos formātos, dažādās sistēmās, dažkārt pat dažādās vienas un tās pašas uzņēmuma nodaļās. Kamēr kāds manuāli nesaliek visus četrus datumus vienā rindā, neatbilstība starp tiem paliek nepamanīta — rēķins vienkārši tiek apmaksāts, jo tā pārbaude prasītu vairāk laika, nekā tā ir vērta.

Kur satiekas abi datu avoti

Cargo Intelligence Jūras modulis automātiski iegūst konteinera numuru, pārvadātāju, maršrutu un paredzamo ierašanās datumu no B/L dokumenta iekraušanas brīdī. D&D audits pārbauda, vai vēlāk saņemtais dīkstāves rēķins atbilst līguma nosacījumiem un reālajiem termināļa datiem. Kad abas šīs datu plūsmas satiekas — B/L dati no sākuma, rēķina pārbaude no beigām — rodas iespēja redzēt visu konteinera ceļu vienuviet, nevis cerēt, ka kāds manuāli saliks četrus atsevišķus punktus vienā līnijā.

Tas neatceļ nepieciešamību pēc reāliem termināļa gate-in/gate-out datiem — tādu B/L dokumentam pašam par sevi nav. Bet tas nozīmē, ka puse ceļa jau ir veikta automātiski, vēl pirms rēķins vispār pastāv.