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 šķiet kā divi pilnīgi atsevišķi dokumenti — viens izsniegts kravas iekraušanas laikā, otrs parādās vairākas nedēļas vēlāk, kad konteiners jau sen izkrauts. Patiesībā tas ir tas pats ceļš, tikai redzams no divām dažādām dokumentu perspektīvām. Un tieši starp tiem, punktos, kurus neviens dokuments 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 datums (ETA), pārvadātājs un maršruts. Tas ir pirmais punkts, kurā var sākt sekot laikam, bet parasti to neviens nedara, jo B/L tolaik tiek izmantots tikai kā īpašumtiesību un pārvadāšanas 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īgumā noteikto brīvo laiku. Ja uzņēmums šo datumu nefiksē uzreiz, bet uzzina par to tikai saņemot rēķinu, tas jau ir zaudējis iespēju pārbaudīt, vai aprēķins sākās pareizajā brīdī.

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

Ceturtais punkts — tukšā konteinera atgriešana. Tieši šis datums, salīdzinot ar izkraušanas datumu, kļūst par pamatu D&D rēķinam. 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, visbiežāk dažādos formātos, dažādās sistēmās, dažreiz pat dažādās viena un tā paša 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ārbaudīšanai būtu nepieciešams vairāk laika, nekā tas ir vērts.

Kur savienojas 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 laikā. 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 savienojas — 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 neaizstāj nepieciešamību pēc reāliem termināļa gate-in/gate-out datiem — B/L dokumentam tādu nav. Bet tas nozīmē, ka puse ceļa jau ir veikta automātiski, vēl pirms parādās pats rēķins.