Kādu laiku atpakaļ es uzsāku meklējumus, lai noskaidrotu, vai pastāv vienots transporta API/EDI standarts, ko izmanto vairāki loģistikas uzņēmumi. Šajā laikmetā noteikti kaut kam tādam vajadzētu eksistēt, vai ne? Universāls piegādes API formāts?

Nu, īsumā sakot, tāda nav.

Vistuvāk tam var tikt ar kādu API nodrošinātāju, kurš ir izveidojis daudz pārvadātāju API savienojumu un tad piedāvā savu API galapunktu, lai piekļūtu dažādiem transporta pakalpojumu sniedzējiem.

Šajā rakstā es aplūkošu dažādus pārvadātāju API, īsi aprakstīšu to iespējas un apspriedīšu veidus, kā tos ieviest.

NB! Ja jūs vienkārši meklējat universālu transporta API protokolu, šeit ir saite, kur varat rezervēt īsu zvanu ar mani.

Katrā ziņā, sāksim ar…

Vispirms definēsim mērķi.

Apskatīsim vidēju ražotāju ar gan vietējiem, gan starptautiskiem klientiem un piegādātājiem. Preces jāsavāc no piegādātājiem un jāpiegādā uz ražošanas vietu, savukārt gatavie produkti jānosūta klientiem.

Lai izveidotu uzticamu piegādes ķēdi, jūsu tipiskajam vidēja lieluma ražotājam būtu nepieciešami 10-20 transporta partneri:

Visu šo attiecību pārvaldīšana jau ir pietiekami sarežģīta. Bet īstā jautrība sākas, kad jūs mēģināt integrēt viņu IT sistēmas! (jo nav vienota kravas API protokola)

Otrkārt, mums jāvienojas par apjomu.

Ne visi loģistikas uzņēmumi piedāvā vienādu pakalpojumu līmeni. Dažiem ir ļoti sarežģīti API, kas nodrošina tūlītēju kravas cenu noteikšanu, rezervēšanu, etiķetes, izsekošanu, kurjeru pieprasījumus utt., kamēr citiem var būt tikai portāls, kur varat pierakstīties un iesniegt rezervāciju. Dažiem vispār nav IT sistēmu — tikai e-pasts. Mūsu mērķa scenārijam saglabāsim vienkāršību un vienkārši centīsimies:

Izklausās pietiekami vienkārši, vai ne? Ak, ja vien tā būtu...

Manuālais veids, kā rīkoties, kas šķiet nozares standarts lielākajai daļai uzņēmumu, ietver pārvadātāju portālu izmantošanu, kur vien iespējams, un saziņu pa e-pastu ar pārējiem transporta partneriem. Mūsu piemērā mēs pieņemam, ka transporta cenu saraksti, grafiki, piegādes laiki un rēķinu apstrāde tiek pārvaldīti atsevišķi. Rezervāciju iesniegšanai mēs cenšamies izveidot API savienojumu no mūsu ERP sistēmas.

Pieņemsim, ka esam izvēlējušies šādu transporta uzņēmumu sarakstu un mums nepieciešams izveidot tiešu API savienojumu ar to sistēmām no mūsu ERP programmatūras. Šī atlase ir nejauša un aptver tikai daļu no dažādajiem pārvadātāju API, kas ir pieejami.

DHL Express – izmanto portālu, ko sauc par MyDHL, kam arī ir API iespējas. Tomēr tas izmanto dažādus API Freight, Express un Global Forwarding nodaļām, un dažādas API pieejas dažādos reģionos. Piekļuve tīmekļa pakalpojumam prasa SOAP protokolu, RESTful pakalpojumus vai vienkāršu XML, un izstrādātājiem vajadzētu būt pazīstamiem ar XML/JSON un būt pamata izpratnei par tīmekļa pakalpojumiem. API specifikācija vien ir 457 lappuses gara. Tā ir pamatīga, bet jūsu izstrādātājs jums prasīs samaksu par stundām, kas pavadītas tikai to lasot. Pēc ieviešanas jums būtu jāveic vidēji 5-12 pieprasījumi katram sūtījumam, sākot no autentifikācijas līdz adrešu validācijām, pieejamības pārbaudēm un etiķešu pieprasījumiem.

Schenker – izmanto dažādus API/EDI risinājumus dažādos reģionos. Visbiežāk tas izmanto SOAP protokolu ar XML formātu. Pati ziņa ir vienkārša, ja vien visas iespējamās kļūdas tiek pareizi apstrādātas. Izstrādātājiem nepieciešama personalizēta piekļuve, lai ieviestu API. Atkarībā no jūsu atrašanās vietas, jums var lūgt ieviest EDIFACT risinājumu, ko es aplūkošu vēlāk.

DSV – nesen ir pārgājis uz savu API-spējīgu portālu, ko sauc par MyDSV. Ņemot vērā, ka API ir diezgan jauns, tas izmanto dažas no jaunākajām un modernākajām pieejām API pasaulē. Neskatoties uz sarežģītību autentifikācijā un navigācijā viņu produktu katalogā, pieeja ir vienkārša. Atkal, atkarībā no jūsu atrašanās vietas, var dot priekšroku EDIFACT.

FedEx un TNT – tas var būt jautri. Vispirms jums jānosaka, vai izmantojat TNT vai FedEx pakalpojumus. Lai gan tiem jau vairākus gadus vajadzētu būt vienam un tam pašam uzņēmumam, migrācija joprojām nav pabeigta. Ja jūsu līgums ir ar TNT, visticamāk, jums lūgs ieviest TNT Express Connect API. Pati ieviešana ir vidēji sarežģīta. Trūkums ir tas, ka šis API tiek uzskatīts par novecojušu un galu galā tiks slēgts. FedEx API, no otras puses, ir sarežģītāks un piedāvā vairākas iespējas atkarībā no reģiona, kurā atrodaties. Cargoson mēs esam ieviesuši FedEx Compatible API, kas nodrošina dažas ļoti glītas papildu funkcijas, bet ir pieejams tikai FedEx Compatible partneriem.

UPS – izmanto JSON balstītu API un OAuth autentifikācijai, kas nozīmē, ka jums būtu jāveic diezgan daudz pieprasījumu, pirms jūs saņemat savu rezervāciju un etiķetes atpakaļ.

Tālāk mums ir EDIFACT, ko izmanto daudzi transporta uzņēmumi, piemēram, DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics utt. Tas ir ļoti vecs standarts, un pat ja varētu šķist, ka jūs varētu iztikt ar vienu API integrāciju vairākiem loģistikas uzņēmumiem, padomājiet vēlreiz. Lielākais trūkums ir tas, ka tas ir uz failu apmaiņu balstīts savienojums, kas nozīmē, ka jums būtu jāģenerē faktisks, fizisks fails, tad jāpārsūta tas pa FTP un burtiski jācer, ka viss ir kārtībā, jo ir ļoti apgrūtinoša atgriezeniskā saite par kļūdām un brīdinājumiem.

Līdzīgs EDIFACT ir FORTRAS, uz failu balstīts savienojums ar tādiem pašiem trūkumiem. To vairāk izmanto Vācijā un kaimiņvalstīs. Ne tikai failu apmaiņa ir izaicinoša, bet arī pats faila formāts ir grūti lasāms un tāpēc ļoti laikietilpīgs kļūdu atkļūdošanai. Daži pazīstami uzņēmumi, kas to izmanto, ir Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss utt.

Pat pēc visu iepriekš minēto integrāciju ieviešanas paliek jautājums:

Ko darīt ar pārvadātāju uzņēmumiem, kuriem nav nekādas IT sistēmas vai portāla, nemaz nerunājot par API transporta pasūtījumu pieņemšanai?

Vienkāršākais risinājums ir nosūtīt vienkāršu e-pastu. Lai gan tas var šķist vienkārši, iedziļināsimies sīkāk. Tehniskā savienojuma iestatīšana ar jūsu pasta serveri ir viena lieta, bet kā ar kontaktiem? Parasti dažādus virzienus apkalpo dažādas kontaktpersonas, un cilvēki maina amatus. Tādējādi jums būtu jāizveido diezgan visaptveroša kontaktu matrica savā ERP.

Tātad, kādas ir alternatīvas cīņai ar dažādiem pārvadātāju API un EDI protokoliem?

Viena no iespējām, ko var apsvērt, ir vairāku pārvadātāju API. Būtībā tas ir pakalpojumu sniedzējs, kas ir izveidojis visus pārvadātāju savienojumus, vai tie būtu moderni API, veci EDIFACT vai FORTRAS balstīti EDI protokoli vai e-pasta integrācijas, un padarījis tos pieejamus caur savu standartizētu piegādes API. Tā vietā, lai ieviestu dažādus pārvadātāju API un uzturētu tos aktuālus, jūs varat ieviest tikai vienu vairāku pārvadātāju API standartu un veikt visus savus transporta pasūtījumus caur to.

Bet mēs esam gājuši vēl tālāk.

Dažādi loģistikas uzņēmumi piedāvā atšķirīgus pakalpojumu līmeņus. Daži nodrošina rezervēšanas API, kamēr citiem tā nav; daži piedāvā izsekošanas iespējas, kamēr citiem šīs funkcijas trūkst. Cargoson mēs esam ieviesuši visas funkcijas, kas aizpilda robus katram transporta uzņēmumam.

Piemēram, ja pārvadātājs nepiedāvā tiešsaistes rezervēšanu, mēs nodrošinām portālu tam. Ja viņiem trūkst izsekošanas, mēs to pievienojam. Mums ir sistēmas piegādes apliecinājuma (POD) un citu dokumentu augšupielādei, pilnībā funkcionāls vairāku pārvadātāju API, ETA aprēķini, transporta cenu aprēķini, veiktspējas statistika un pat transporta CO2 emisiju rādītāji. Būtībā, ko vien pārvadātājam trūkst, mēs esam to uzbūvējuši, lai jums nebūtu jāuztraucas par IT vai pakalpojumu līmeņa atšķirībām starp jūsu pārvadātājiem.

Uzziniet, kā Cargoson uzlabo jūsu esošos pārvadātājus

Lūk, reāls piemērs: Lieli spēlētāji kā FedEx, TNT un DHL Express piedāvā cenu noteikšanas API. Tas nozīmē, ka, kad jūs veicat cenas pieprasījumu no Cargoson, cenas tiek tieši iegūtas no pārvadātāja sistēmas. Tomēr gadījumos, kad uzņēmums kā DSV nepiedāvā cenu noteikšanas API, DSV sniegtā Excel vai PDF cenu lapa tiek augšupielādēta Cargoson, un cenas aprēķins tiek veikts mūsu sistēmā. Mums ir jaudīgs kravas cenu augšupielādes un aprēķināšanas dzinējs tam. To pašu pieeju var piemērot visiem citiem transporta uzņēmumiem, un tā ir piemērojama arī citām funkcijām.

Mūsu mērķis ir vienkāršs: sniegt jums konsekventu, augstas kvalitātes pieredzi ar visiem pārvadātājiem, pat ja tie visi nesāk ar vienādām iespējām. De facto universāls pārvadātāju API standarts un vairāku pārvadātāju platforma vienā.

Ja jūs meklējat labāku veidu, kā pārvaldīt savas pārvadātāju integrācijas, Cargoson var palīdzēt. Mūsu platforma nodrošina vienu, standartizētu transporta API, kas savieno jūs ar visiem jūsu pārvadātājiem, neatkarīgi no to individuālajām iespējām. Tas nozīmē, ka jūs varat piekļūt visiem saviem piegādes pakalpojumiem caur vienu vienotu saskarni, neuztraucoties par pamatā esošajām tehniskajām atšķirībām.

Vēlaties redzēt, kā tas varētu darboties jūsu uzņēmumā? Piedalieties īsā zvana laikā, lai apspriestu jūsu pašreizējo iestatījumu un konkrētās integrācijas problēmas. Mēs varam izskatīt dažus reālās dzīves piemērus par to, kā Cargoson ir palīdzējis uzņēmumiem līdzīgos gadījumos kā jūsējais:

Ieplānojiet bezmaksas 30 minūšu konsultāciju