Deniz Yolu Taşımacılığı Takip API'si: Konteyner Olayları, ETA Verileri ve Seçim Kriterleri

Bir deniz taşımacılığı takip API'si, konteyner hareketlerini, taşıma kilometre taşlarını ve ETA güncellemelerini ekibinizin yönettiği sevkiyata bağlamalıdır. Navlun komisyoncuları, ithalatçılar ve entegrasyon ekipleri için seçim ölçütü; doğru konteyner yolculuğunu güvenilir biçimde belirleyip belirleyemediği, gerçekleşen olayları tahminlerden ayırt edip edemediği ve operasyonel kararları destekleyecek yeterli bağlamı sunup sunamadığıdır. Genel bir sevkiyat durumu veya açıklanmayan bir varış tarihi, deniz taşımacılığını yönetmek için yeterli değildir.

Bu kılavuz, talep edilmesi gereken verileri, konteyner olaylarının ve varış tahminlerinin nasıl yorumlanacağını ve üretim trafiğini veya satın alma bütçesini tahsis etmeden önce bir entegrasyonun nasıl değerlendirileceğini açıklar.

Takip ekranıyla değil, sevkiyat modeliyle başlayın

Deniz taşımacılığı takibi birbiriyle ilişkili çeşitli nesneleri kapsar: ticari bir sevkiyat, taşıma belgeleri, bir veya daha fazla konteyner ve bunları taşıyan taşıma etapları. Bu ilişkiler önemlidir; çünkü tek bir rezervasyon birden fazla konteyner içerebilirken, bir konteyner birkaç gemi, terminal ve kara taşıma etabından geçebilir.

Yararlı bir entegrasyon, her şeyi tek bir duruma indirgemek yerine bu ilişkileri korumalıdır. Aynı sevkiyat altındaki iki konteyner farklı hareket ediyorsa sistem, görünüşte tamamlanmış bir sevkiyat düzeyi kilometre taşı sunmak yerine operatörün farkı görmesine olanak tanımalıdır.

Bir API'yi değerlendirmeden önce işletmenizin gerçekten aldığı referansları belirleyin:

• Konteyner numarası: Ekipmanı tanımlar; ancak konteynerler yeniden kullanıldığından ilgili sevkiyat veya yolculukla ilişkilendirilmelidir.
• Taşıyıcı rezervasyon referansı: Kaynak sistemin arama gereksinimlerine bağlı olarak takip isteğini bir rezervasyona bağlayabilir.
• Taşıma belgesi referansı: Sevkiyatı deniz taşıyıcısı düzeyinde tanımlayabilir. API'nin ekibinizde bulunan belge referanslarını kabul edip etmediğini doğrulayın.
• Dahili sevkiyat kimliği: Harici takip kayıtlarını taşıma yönetim sisteminize, ERP'nize veya forwarder yazılımınıza bağlar.

Bir forwarder tarafından düzenlenen house konşimento referansının, deniz taşıyıcısı belge referansının gerekli olduğu her yerde kullanılabileceğini varsaymayın. Rezervasyon ve belge iş akışlarınızda mevcut olan tam tanımlayıcıları test edin.

Bir API hangi konteyner olaylarını sunmalıdır?

Digital Container Shipping Association'ın Track & Trace standartları, deniz sevkiyatı verilerini tartışmak için yararlı bir referans sağlar. DCSA; sevkiyat, taşıma ve ekipman olaylarını birbirinden ayırır. Bu kategoriler idari ilerlemeyi, taşımanın hareketini ve fiziksel konteynerin elleçlenmesini ayırmaya yardımcı olur.

Bir sağlayıcının yararlı olması için tercih ettiğiniz alan adlarını kullanması şart değildir; ancak olay modelinin ihtiyaç duyduğunuz operasyonel kilometre taşlarıyla nasıl eşleştiğini açıklamalıdır.

Ekipman olayları: konteynere ne oldu

İlgili ekipman kilometre taşları arasında kapıdan giriş, yükleme, boşaltma, kapıdan çıkış ve boş konteyner hareketleri bulunabilir. Kullanılabilirlik yolculuğa, kaynağa ve ürüne bağlıdır. Her olayın her terminalde mevcut olduğunu varsaymak yerine örnek kayıtlar talep edin.

Bu ayrımların pratik sonuçları vardır. Geminin varışı, belirli bir konteynerin boşaltıldığını kanıtlamaz. Boşaltma, konteynerin serbest bırakıldığını veya teslim alınmaya hazır olduğunu kanıtlamaz. Kapıdan çıkış kaydı da konum ve bağlam gerektirir: bir aktarma tesisinden kapıdan çıkış, son ithalat terminalinden teslim alma ile aynı ticari sonuç değildir.

Taşıma olayları: geminin veya taşıma etabının durumu

Varış ve kalkış olayları taşıma faaliyetini açıklar. Bunları yorumlamak için sisteminizin ilgili konuma, taşıma moduna ve etaba ihtiyacı vardır. Mevcut olduğunda gemi ve sefer tanımlayıcıları, aynı limanlara hizmet veren başka bir hareketten hedeflenen seferi ayırt etmeye yardımcı olur.

Aktarmalı yükler için ara durakları koruyun. Güzergâhı başlangıç ve varış noktalarına indirgemek, kaçırılmış bir bağlantıyı veya güzergâh değişikliğini gizleyebilir. Operasyonel zaman çizelgesi, hangi etabın tamamlandığını ve hangisinin hâlâ tahmini olduğunu göstermelidir.

Sevkiyat olayları: idari ilerleme fiziksel hareket değildir

Belge ve sevkiyat işleme olayları forwarding iş akışları için yararlı olabilir; ancak konteyner hareketinden ayırt edilebilir kalmalıdır. Bir belge kilometre taşı, yükün fiziksel olarak hareket ettiğini göstermez; bir hareket olayı da tüm ticari veya düzenleyici gerekliliklerin karşılandığını göstermez.

Her olay için olay türünü, ilgili nesneyi, konumu, olay zaman damgasını, saat dilimi bilgisini, kaynağı ve olayın planlanmış, tahmini veya gerçekleşmiş olup olmadığını belirten bilgiyi talep edin. Ayrıca yinelenen güncellemelerin yinelenen kilometre taşları oluşturmaması için sabit bir olay kimliği ve düzeltme davranışı isteyin.

ETA verilerinin bir varış noktasına, anlama ve geçmişe ihtiyacı vardır

ETA, belirli bir noktaya tahmini varış zamanıdır. Yükün teslim alınmaya hazır olacağına dair kendiliğinden bir taahhüt değildir. Bir deniz taşımacılığı takip API'si, yalnızca eta olarak etiketlenmiş belirsiz bir alan döndürmek yerine varış kilometre taşını açıkça belirtmelidir.

Örneğin bir varış tahmini, bir liman uğrağına, terminale, kara tesisine veya tanımlanmış başka bir varış noktasına ilişkin olabilir. Kamyon planlamak veya stok kullanılabilirliği sözü vermek için kullanmadan önce bu zaman damgasının tam olarak neyi temsil ettiğini belirleyin.

Tahminin kaynağını durumundan ayırın

Taşıyıcı tarafından sağlanan tahmin ile sağlayıcı tarafından oluşturulan tahmin farklı veri ürünleridir. Hiçbiri gerçekleşmiş varış olarak sunulmamalıdır. Yanıtın tahminin kaynağını, hesaplanma veya yayımlanma zamanını ve tahmin ettiği konum veya olayı belirleyip belirlemediğini sorun.

Bir sağlayıcı tahmine dayalı ETA sunuyorsa yöntemini ve doğrulama yaklaşımını talep edin. Yararlı sorular arasında hangi kilometre taşının tahmin edildiği, varıştan ne kadar önce performansın ölçüldüğü ve sonuçların kullandığınız rotalara göre farklılaşıp farklılaşmadığı bulunur. Hedef olay ve ölçüm aralığı belirtilmediğinde geniş bir doğruluk iddiasını uygulamak zordur.

ETA revizyonlarını üzerine yazmak yerine koruyun

En güncel ETA bugünün planlamasını destekler; revizyon geçmişi neyin değiştiğini açıklar. Önceki tahmini, yeni tahmini, ilişkili kilometre taşını, kaynağı ve sisteminizin değişikliği aldığı zamanı saklayın.

Bu geçmiş, operasyon ekibinin önemli bir gecikmeyi biçimlendirme düzeltmesinden veya ilgisiz bir liman uğrağındaki değişiklikten ayırt etmesini sağlar. Ayrıca yolculuğun daha erken bir aşamasında nihai tahminin bilindiği izlenimini vermeden geriye dönük değerlendirmeyi destekler.

Saat dilimleri açıkça test edilmelidir. Sağlandığında kaynak zaman damgasını ve farkını koruyun, hesaplama için zaman damgalarını normalleştirin ve uygun olduğunda yerel operasyonel zamanı gösterin. Kaynak yalnızca bir tarih sağlıyorsa bunu sessizce kesin bir gece yarısı varış taahhüdüne dönüştürmeyin.

Kapsamı olay düzeyinde değerlendirin

Bir taşıyıcının kapsam listesinde yer alması, tek başına her konteyner kilometre taşının mevcut olduğunu göstermez. Kapsam; işletmeniz için önemli olan taşıyıcılara, rotalara, sevkiyat referanslarına ve operasyonel olaylara göre test edilmelidir.

Gerçek gereksinimlerinizle bir değerlendirme matrisi oluşturun. Her temsili sevkiyat için API'nin referansı çözümleyip çözümleyemediğini, doğru güzergâhı döndürüp döndürmediğini, ihtiyaç duyduğunuz kilometre taşlarını sunup sunmadığını ve yönettiğiniz yolculuk bölümü boyunca güncellemeleri sürdürebilip sürdüremediğini kontrol edin.

• Doğrudan deniz hareketleri: Başlangıç kalkışını, varış noktası varışını ve ilgili konteyner elleçleme olaylarını belirleyebiliyor musunuz?
• Aktarmalı hareketler: Ara etaplar görünür mü ve ayrı hareket eden konteynerler birbirinden ayırt edilebilir mi?
• Kara etapları: Hizmetiniz bunları içeriyorsa API ilgili demir yolu, mavna veya kamyon kilometre taşlarını sağlıyor mu, yoksa görünürlük limanda mı sona eriyor?
• İstisnalar: Eksik olaylar, değişen güzergâhlar, eşleşmeyen referanslar ve kaynak kesintileri nasıl gösteriliyor?
• Tamamlanan sevkiyatlar: Ekibiniz bir müşteri anlaşmazlığını araştırmak veya operasyonel bir kaydı mutabık hale getirmek için yeterli geçmiş veriyi alabiliyor mu?

Mevcut olmayan verileri negatif olaylardan ayrı tutun. Boşaltma kaydının olmaması, boşaltmanın gerçekleşmediğini kanıtlamaz. Yararlı bir entegrasyon, açık bir operasyonel durumu görünürlükteki bir boşluktan ayırır.

API davranışı, olay listesi kadar önemlidir

Zengin bir olay akışı bile teslimat davranışı belirsizse işletilmesi zor hale gelebilir. Uygulamanızın güncellemeleri nasıl aldığını, düzeltmeleri nasıl işlediğini ve kesinti sonrasında nasıl toparlandığını değerlendirin.

Yoklama, web kancaları ve kurtarma

Yoklama, uygulamanızın güncellemeleri kendi programına göre istemesine olanak tanır. Web kancaları, sağlayıcının güncellemeleri yönettiğiniz bir uç noktaya göndermesini sağlar. Hiçbir mekanizma tek başına güncelliği garanti etmez: hemen teslim edilen bir web kancası bile kaynaktan geç alınmış bir olay içerebilir.

Mevcut olduğunda kaynak olay zamanı, sağlayıcının alma zamanı ve bildirim zamanı için ayrı tanımlar isteyin. Web kancaları için kimlik doğrulamayı veya imza doğrulamasını, yeniden denemeleri, yinelenen teslimat davranışını ve başarısız bildirimlerin yeniden oynatılıp oynatılamayacağını doğrulayın. Yoklama için sayfalandırmayı, hız sınırlarını, artımlı alımı ve geçmiş düzeltmelerin nasıl işlendiğini kontrol edin.

Kanıtı kaybetmeden normalleştirme

Normalleştirilmiş durumlar, taşıyıcılar arası iş akışlarını kolaylaştırır; ancak aşırı basitleştirme yararlı bağlamı ortadan kaldırır. Mevcut olduğunda normalleştirilmiş olayı özgün kaynak açıklaması veya koduyla birlikte saklamanıza izin veren bir modeli tercih edin.

Ham gelen kayıtları, bunları gösterge paneli durumlarına dönüştüren iş kurallarından ayrı saklayın. Böylece özgün kanıtı kaybetmeden eşlemeyi değiştirebilirsiniz. Ayrıca müşteri tarafından görülen bir durumun operasyon ekibinin yorumundan farklı olduğu durumlarda araştırmayı kolaylaştırır.

Ticari ve yönetişim kontrolleri

Faturalandırma biriminin yazılı açıklamasını isteyin. Abonelik, takip edilen sevkiyat, konteyner, API isteği ve bildirim birbirinin yerine kullanılabilecek ölçüler değildir. Belirli bir fiyatlandırma modelini varsaymak yerine yeniden denemelerin, yinelenen kayıtların, geçmiş sorgularının ve yeniden etkinleştirilen sevkiyatların ücretleri nasıl etkilediğini netleştirin.

Ayrıca veri saklama, erişim kontrolleri, kimlik bilgisi yenileme, izin verilen alt kullanım, destek eskalasyonu ve hizmet taahhütlerini inceleyin. Sözleşmeye dayalı garantileri ürün tanıtımlarından ve pazarlama ifadelerinden ayrı değerlendirin.

Genel bir takip API'sinin deniz taşımacılığı gereksinimlerini karşıladığını varsaymayın

Bir takip API'si kategori etiketine göre değil, doğrulanmış veri modeline göre seçilmelidir. Her ikisi de sevkiyat takibi olarak tanımlansa bile paket teslimat güncellemeleri ve deniz konteyneri görünürlüğü farklı iş akışlarına hizmet edebilir.

17TRACK zaten entegrasyon kısa listenizdeyse gereksinim kontrolü için resmî Tracking API sayfasını ve API belgelerini başlangıç noktası olarak kullanın. Herhangi bir genel takip entegrasyonunu deniz taşımacılığı çözümü olarak değerlendirmeden önce uygulamanızın ihtiyaç duyduğu kesin deniz referanslarını, konteyner olaylarını, taşıma etaplarını ve ETA alanlarını doğrulayın. Bu kılavuz, 17TRACK için denize özgü bu yetenekleri ortaya koymaz.

Aynı kabul standardı her aday için geçerli olmalıdır: gerekli verileri temsili sevkiyatlarla gösterin ve sınırlamalarını açıklayın. Daha geniş bir taşıyıcı takip iş akışı, özel bir konteyner olay akışının yerini almadan tedarik zincirinizin başka bir bölümünde yararlı olabilir.

Operasyonel kararlar etrafında bir kavram kanıtı çalışması yürütün

En güçlü kavram kanıtı, gösterge paneli tanıtımıyla değil, ekibinizin vermesi gereken kararlarla başlar. Kendi operasyonunuzdan, basit seferleri ve manuel iş oluşturan zor durumları içeren temsili sevkiyatlar seçin.

1. Kabul kriterlerini tanımlayın. Testten önce gerekli referansları, olayları, konumları, zaman damgası anlamlarını ve eksik verilerin kabul edilebilir işlenişini belirtin.
2. Kimliği doğrulayın. Her sonucun amaçlanan sevkiyata ve konteyner yolculuğuna ait olduğunu doğrulayın. Uygun olduğunda yeniden kullanılan ekipmanı ve çok konteynerli rezervasyonları dahil edin.
3. Kaynak kayıtlarla karşılaştırın. Güncelleme zamanlarındaki farklılıkları dikkate alarak döndürülen kilometre taşlarını erişilebilir taşıyıcı veya terminal kayıtlarıyla karşılaştırın.
4. Revizyonları ve hataları test edin. Yinelenen bildirimleri, sıra dışı olayları, düzeltilmiş zaman damgalarını, kullanılamayan kaynakları ve uç nokta kesintilerini deneyin.
5. Bir iş akışını yeniden oynatın. Verilerin gecikmiş bir bağlantıyı incelemek veya gelen stok tahminini güncellemek gibi amaçlanan eylemi destekleyip desteklemediğini doğrulayın.
6. Çözülmemiş boşlukları inceleyin. Her boşluğun temel kaynaktan mı, sağlayıcının işlemesinden mi yoksa entegrasyonunuzdan mı kaynaklandığını kaydedin. Kullanımı genişletmeden önce düzeltme konusunda anlaşın.

ETA testi için her tahmini geldiği şekliyle saklayın ve aynı kilometre taşı için nihai gerçekleşen olayla karşılaştırın. Bir liman varış tahminini depo teslimiyle değerlendirmeyin veya çok farklı ön sürelerde yapılan tahminleri açıklanmayan tek bir puanda birleştirmeyin.

Seçim kuralı basittir: gerekli kararlarınızı izlenebilir olaylar, anlaşılır tahminler ve kurtarılabilir teslimat davranışıyla açıkça destekleyen entegrasyonu seçin. Teslim alma planlaması terminal kullanılabilirliği, serbest bırakma durumu veya randevuları da gerektiriyorsa, bunları gemi varışından çıkarım yapmak yerine ayrı ayrı doğrulayın.

SSS

Bir deniz sevkiyatını yalnızca konteyner numarasıyla takip edebilir miyim?

Bu, veri kaynağına ve API'ye bağlıdır. Bazı iş akışları ayrıca taşıyıcı tanımlayıcısı, rezervasyon referansı veya taşıma belgesi referansı gerektirebilir. Ekipman yeniden kullanıldığından, yalnızca konteyner numarasına güvenmek yerine döndürülen olayların amaçlanan yolculuğunuza ait olduğunu doğrulayın.

Geminin gerçekleşen varışı, konteynerimin teslim alınmaya hazır olduğu anlamına mı gelir?

Hayır. Geminin varışı, konteynerin boşaltılması, yükün kullanılabilirliği ve teslim alma izni ayrı operasyonel gerçeklerdir. Sevkiyata bağlı olarak teslim alma ayrıca serbest bırakma bilgisi ve terminal randevusu gerektirebilir. İlgili koşulları bunlardan sorumlu taraflarla doğrulayın.

AIS gemi takibi konteyner takibinin yerini alır mı?

Hayır. AIS, gemi kimliği ve hareket bilgileriyle ilgilidir; tek başına belirli bir konteynerin yüklenme, boşaltma, serbest bırakılma veya kapıdan çıkış durumunu göstermez. Gemi hareketi bağlam sağlayabilir; ancak konteynerin seferle ilişkisi yine de doğrulanmalıdır.

Bir deniz taşımacılığı takip API'si ne sıklıkta güncellenmelidir?

Her iş akışı için geçerli tek bir yararlı aralık yoktur. Gereksinimleri, ilgili kaynak bilgisi kullanılabilir hale geldikten sonra ekibinizin ne kadar hızlı harekete geçmesi gerektiğine göre belirleyin. Kaynak gecikmesini API teslimat gecikmesinden ayrı ölçün ve kaynak yeni bir olay yayımlamadığında ne olduğunu doğrulayın.

Takip olayları demuraj veya detention ücretlerini hesaplayabilir mi?

Olaylar zaman çizelgesini destekleyebilir; ancak eksiksiz bir ücret hesaplaması oluşturmaz. Ayrıca geçerli sözleşme koşullarına, serbest süre kurallarına, takvim uygulamasına ve yetkili başlangıç ve bitiş koşullarına ihtiyacınız vardır. Ödenecek tutarları yalnızca genel kilometre taşlarından türetmeyin.

Kaynaklar

• DCSA: Track & Trace standartları — Konteyner taşımacılığındaki sevkiyat, taşıma ve ekipman olayları için referans çerçevesi.
• DCSA: OpenAPI spesifikasyonları deposu — DCSA API tanımları ve olay yapıları için teknik referans. Entegrasyon tasarlarken geçerli spesifikasyon sürümünü kontrol edin.
• International Maritime Organization: Automatic Identification Systems — AIS ve sağladığı gemi bilgileri hakkında arka plan.
• 17TRACK: Tracking API ve resmî API belgeleri — Ürün uygunluğunu doğrulamak için başlangıç noktalarıdır; burada deniz konteyneri olayları veya tahmine dayalı ETA desteğine ilişkin kanıt olarak sunulmamaktadır.