Taşıyıcı Takip Durumu Normalizasyonu: Taşıyıcı Olayları Tek Bir Durum Modeline Nasıl Eşlenir

Taşıyıcı takip durumu normalizasyonu, taşıyıcıya özgü tarama kodlarının ve mesajlarının, orijinal kanıtı koruyarak tutarlı bir gönderi modeline çevrilmesi anlamına gelir. Bunu güvenilir şekilde uygulamak için her olayı standart bir durum ve nedene eşleyin; ardından olay zamanlamasını, gönderi bağlamını ve açık geçiş kurallarını kullanarak gönderinin mevcut durumunu hesaplayın. Alınan en yeni mesajı otomatik olarak gönderinin mevcut durumu kabul etmeyin.

Bu kılavuz, bir sipariş yönetim sistemine, destek paneline veya müşteri bildirim iş akışına takip özelliği ekleyen geliştiriciler, lojistik operasyon ekipleri ve ürün sahipleri içindir. Aşağıdaki model, önerilen bir uygulama modelidir; resmi bir taşıyıcı standardı veya herhangi bir takip sağlayıcısının durum sınıflandırmasının aynısı değildir.

Taşıyıcı olayını gönderi durumundan ayırın

Bir takip olayı, bir gönderi hakkında bildirilen bir şeyi açıklar: etiket oluşturulmuştur, paket bir tesise ulaşmıştır veya teslimat denemesi başarısız olmuştur. Gönderi durumu, uygulamanızın belirli bir zamanda ilgili kanıtı yorumlamasıdır. Bu kavramlar ayrı ayrı saklanmalıdır.

Örneğin bir pakette, bir teslimat denemesi olayının ardından tesise varış olayı görülebilir. Varış, operasyonel geçmiş açısından yararlıdır; ancak başarısız deneme koşulunun çözüldüğü anlamına gelmez. Tersine, teslimat onayından sonra gelen gecikmiş bir tarama, paketi otomatik olarak yeniden taşıma durumuna geçirmemelidir.

Pratik bir mimarinin üç katmanı vardır:

1. Ham kanıt: Kodlar, metinler, zaman damgaları ve tanımlayıcılar dahil olmak üzere orijinal taşıyıcı veya sağlayıcı yükü.
2. Normalleştirilmiş olaylar: Sürümlendirilmiş bir eşleme kuralı kullanılarak her bir olayın yorumlanması.
3. Mevcut gönderi projeksiyonu: Olay geçmişinden seçilen durum ile etkin koşullar ve müşteri işlemleri.

Bu ayrım, orijinal kaydı silmeden eşlemeleri düzeltmenize ve gönderi durumlarını yeniden oluşturmanıza olanak tanır.

Ayrı koşullara sahip, kompakt bir durum modeli tanımlayın

Tek bir durum alanı; fiziksel hareketi, gümrük işlemlerini, teslimat sorunlarını ve iadeleri aynı anda temsil etmek zorunda kaldığında yönetilmesi güçleşir. Küçük bir yaşam döngüsü modeli kullanın ve daha özel koşullar ile nedenleri buna ekleyin.

CUSTOMS_PROCESSING, DELIVERY_ATTEMPT_FAILED, ADDRESS_ISSUE veya DELAY_REPORTED gibi koşulları birincil yaşam döngüsü alanının dışında tutun. Bir gönderi, adres sorunu ilgilenilmesi gereken bir konu olsa bile IN_TRANSIT olarak kalabilir. Kaynak bir bekletme, sorun veya gerekli işlem bildirmedikçe rutin gümrük işlemlerini istisna olarak etiketlemeyin.

Yönü journey_type gibi ayrı bir alanla temsil edin. Bir iadenin kendine ait taşıma ve teslim edildi durumları olabilir. Böylece gönderinin satıcıya geri teslim edilmesi, alıcıya başarılı teslimat olarak yorumlanmaz.

Eşleme kurallarını yazmadan önce olay kaydını oluşturun

Normalleştirilmiş kayıt, eşlemeyi açıklamak ve sonucu yeniden üretmek için yeterli bağlamı taşımalıdır. Yararlı bir başlangıç şeması şunları içerir:

• Kimlik: Dahili gönderi kimliği, taşıyıcı tanımlayıcısı, takip numarası, kaynak ve gönderi ayağı.
• Orijinal kanıt: Ham olay kodu, ham açıklama, sağlanmışsa kaynak olay kimliği ve orijinal yüke referans.
• Zamanlama: Olayın gerçekleşme zamanı, saat dilimi bilgisi, alınma zamanı ve zaman damgası kesinliği.
• Yorum: Standart durum, koşul, neden kodu, yolculuk türü ve işlem gereksinimi.
• İzlenebilirlik: Eşleme kuralı kimliği, eşleme sürümü ve güven kategorisi.

Olayın gerçekleşme zamanını, sisteminizin güncellemeyi aldığı zamandan ayrı tutun. Öğleden sonra alınan bir webhook, sabah gerçekleşmiş bir taramayı açıklıyor olabilir. Bir yoklama yanıtı da tek bir yeni olay yerine birkaç geçmiş olay içerebilir.

Zaman ve zaman farkı biliniyorsa RFC 3339 gibi belgelenmiş bir zaman damgası biçimi kullanın. Kaynak, güvenilir bir fark olmadan yerel saat sağlıyorsa bu sınırlamayı koruyun; yanlış bir UTC tanımı eklemeyin. Yalnızca tarih içeren olayları, kesin bir tarama zamanı uydurmak yerine yalnızca tarih içeren kanıt olarak saklayın.

Ham yükleri uygun erişim kontrolleri ve saklama kuralları altında depolayın. Bunlar, alıcı bilgileri veya geniş erişimli bir analiz tablosunda bulunmaması gereken başka bilgiler içerebilir.

Önce taşıyıcı kodlarını eşleyin, ardından metni dikkatle kullanın

Belirli bir kaynak ve taşıyıcıyla sınırlı kurallarla başlayın. 01 gibi bir kodun belgelenmiş bağlamı dışında güvenilir bir anlamı yoktur. Bir kaynak hizmetleri, bölgeleri veya ayakları birbirinden ayırıyorsa ve bunlar yorumu etkiliyorsa bu boyutları da dahil edin.

Bir uygulama varsayılanı olarak şu eşleme sırasını kullanın:

1. Belgelenmiş yapılandırılmış olay kodu ve gerekli niteleyicilerle eşleştirin.
2. İşlenen olayı açıkça tanımladığında belgelenmiş kaynak durumunu veya alt durumunu kullanın.
3. Yeterli yapılandırılmış alanı olmayan bilinen mesajlar için dar kapsamlı metin kuralları uygulayın.
4. Çözümlenemeyen olayları eşlenmemiş bırakın ve tekrarlanan durumları incelemeye gönderin.

Öncelikle bir sağlayıcının durum alanının tek bir olayı mı yoksa gönderinin mevcut özetini mi açıkladığını belirleyin. Gönderi düzeyindeki bir özeti her geçmiş olaya kopyalamak, önceki taramaların teslimat onayı gibi görünmesine neden olabilir.

“delivered içeriyor” gibi genel anahtar kelime kurallarından kaçının. “not delivered” ifadesi de eşleşebilir; aynı şekilde bir lojistik ortağına teslimatı açıklayan bir mesaj da eşleşebilir. Metin kuralları olumsuzluk işleme, dil bağlamı ve hariç tutmalar gerektirir. Makine çevirisi, bir inceleyicinin mesajı anlamasına yardımcı olabilir; ancak çevrilmiş ifade sessizce yetkili olay tanımı haline gelmemelidir.

Örnek eşlemeler ve sınırları

Aşağıdaki örneklerde kural tasarımını göstermek için uydurma mesajlar kullanılmıştır. Bunlar doğrulanmış taşıyıcı kodları veya belirli bir taşıyıcıdan alınmış tam mesajlar değildir.

• “Shipment details submitted”: Kaynak tanımı yalnızca elektronik bilgileri gösteriyorsa PRE_TRANSIT olarak eşleyin.
• “Accepted at origin facility”: Olay fiziksel kabulü doğruluyorsa IN_TRANSIT olarak eşleyin.
• “Recipient unavailable; attempt unsuccessful”: DELIVERY_ATTEMPT_FAILED kaydedin ve yaşam döngüsünü çevredeki kanıtlara göre değerlendirin. Teslim almanın mümkün olduğunu varsaymayın.
• “Available for collection”: Kaynak, alıcının teslim almaya hazır olduğunu doğruluyorsa READY_FOR_PICKUP olarak eşleyin.
• “Transferred to delivery partner”: Bir devir kaydedin ve alıcıya teslimatı tamamlanmış olarak işaretlemek yerine uygun bir taşıma durumunu koruyun.

Her kuralın kısa bir gerekçesi ve sahibi olmalıdır. Bir operasyon uzmanı bir eşlemeye itiraz ettiğinde ekip, müşteriyle paylaşılan bir etiketi geriye dönük analiz etmek yerine tam olarak hangi kuralı belirleyebilmelidir.

Mevcut durumu deterministik bir azaltıcıyla hesaplayın

Azaltıcı, normalleştirilmiş olayları değerlendirip mevcut gönderi projeksiyonunu üreten işlevdir. Aynı kanıt ve kural sürümü için, girdi kaç kez yeniden oynatılırsa oynatılsın aynı sonucu döndürmelidir.

Anlamlı taramaları silmeden yinelenenleri kaldırın

Varsa kararlı bir kaynak olay tanımlayıcısını tercih edin. Aksi takdirde gönderi kimliği, taşıyıcı, kod, gerçekleşme zamanı ve konum gibi mevcut özniteliklerden bir yinelenen kaldırma anahtarı oluşturun. Zaman damgası kesinliğini ve kaynak davranışını hesaba katın. Açıklamaları aynı olan iki tarama, özellikle paket bir tesisi tekrar ziyaret ediyorsa, mutlaka yinelenen değildir.

Kusursuz saatleri varsaymadan olayları sıralayın

Güvenilir gerçekleşme zamanlarını ve mevcutsa belgelenmiş sıra bilgilerini kullanın. Alınma zamanı eşitlikleri çözmeye yardımcı olabilir; ancak rutin olarak daha erken gerçekleşme zamanının önüne geçmemelidir. Zaman damgaları çelişiyorsa veya güvenilir biçimde karşılaştırılamıyorsa kesinlik uydurmak yerine belirsizliği koruyun.

Evrensel bir sıra atamak yerine geçişleri doğrulayın

Durumların basit bir sayısal sıralaması her gönderi yolculuğunu temsil edemez. Bir paket, başarısız bir denemenin ardından teslimat için yola çıkmış durumdan tekrar taşımaya dönebilir. Teslim alma kullanılabilirliği sona erebilir. Açık bir düzeltme, teslimat onayını geçersiz kılabilir.

İzin verilen geçişleri ve her birinin gerektirdiği kanıtı tanımlayın. Teslim edildi durumunu normal eski taramalara karşı korumalı kabul edin; ancak belgelenmiş bir düzeltmeye veya yetkili bir operasyonel geçersiz kılmaya izin verin. Her geçersiz kılmanın nedenini ve kaynağını kaydedin.

Etkin koşulları bağımsız olarak takip edin

Daha sonraki bir hareket taraması ilerleme gösterebilir; ancak bir ödeme veya adres sorununun çözüldüğünü kanıtlamaz. Koşula özel temizleme kuralları tanımlayın: açık çözüm, mantıksal olarak çözen bir olay veya yetkili bir manuel işlem. Başka bir olay geldi diye her koşulu temizlemeyin.

Ayrıca taşıyıcının bildirdiği gecikmeyi kendi hareketsizlik uyarınızdan ayırın. Yeni taramaların bulunmaması veri güncelliğiyle ilgili bir gözlemdir; paketin kaybolduğunun kanıtı değildir.

Taşıyıcı devirlerini ve iadeleri bağlantılı yolculuklar olarak ele alın

Sınır ötesi takip birden fazla taşıyıcı ve tanımlayıcı içerebilir. Dahili bir gönderi kimliğini koruyun ve taşıyıcıya özgü takip referanslarını ilgili ayaklara ekleyin. Referansları yalnızca benzer varış noktalarına veya yakın zaman damgalarına göre değil, kaynak tarafından sağlanan ilişkiler veya doğrulanmış operasyonel veriler kullanarak bağlayın.

Ayağa ait bir teslimat olayı bağlam içinde yorumlanmalıdır. Bir konsolidasyon tesisine veya ortak ağına teslimat o ayağı tamamlayabilir; ancak alıcının teslimatını tamamlamayabilir. Gönderi projeksiyonunuz, olayın hangi varış noktasını temsil ettiğini bilmelidir.

Aynı şekilde “return requested”, “return movement started” ve “returned to sender” ifadelerini birbirinden ayırın. Bunlar farklı kilometre taşlarını açıklar. İade talebi, paketin fiziksel olarak geri hareket ettiğini kanıtlamaz; ters yolculuğun teslimat onayı da iade varış noktasını belirtmelidir.

İş kurallarınızdan vazgeçmeden bir takip API'si kullanın

Çok taşıyıcılı bir entegrasyon ortak bir veri alma noktası sağlayabilir; ancak paylaşılan yanıt biçimi, açık bir dahili sözleşme ihtiyacını ortadan kaldırmaz. 17TRACK Tracking API değerlendirilirken, uygulamanızla ilgili alanların ve arayüzlerin anlamını kontrol etmek için resmi belgeleri kullanın. Bu kılavuzda önerilen durumların API'nin yerel sınıflandırmasıyla aynı olduğunu varsaymayın.

Herhangi bir API'yi müşteri bildirimlerine veya operasyonel otomasyona bağlamadan önce şunları belirleyin:

• Hangi alanların tek tek olayları, hangilerinin mevcut gönderi özetini açıkladığı.
• Hangi orijinal taşıyıcı ayrıntılarının sunulduğu ve saklanabileceği.
• Zaman damgalarının, eksik değerlerin, düzeltmelerin ve tekrarlanan güncellemelerin nasıl temsil edildiği.
• İade yolculuklarının ve ara ortaklara teslimatın nasıl ayırt edileceği.
• Entegrasyonunuzun bilinmeyen kodlara veya gelecekteki şema değişikliklerine nasıl yanıt vereceği.

Dış yanıt ile standart modeliniz arasında ince bir adaptör bulundurun. Böylece uygulamanızın geri kalanı, her üst akış alanı adına bağlı kalmadan tek bir takip durumu sözleşmesi kullanabilir. Bildirim kurallarını da başka bir katman olarak ele alın: yeni bir normalleştirilmiş olay otomatik olarak müşteri mesajını tetiklememelidir.

Yalnızca tek tek eşlemeleri değil, olay geçmişlerini de test edin

Bir eşleme tek başına doğru olabilir, ancak yine de yanlış gönderi durumuna yol açabilir. Güncellemelerin gerçekleşme zamanlarından farklı bir sırada ulaştığı durumlar dahil olmak üzere eksiksiz geçmişleri test edin.

• Gecikmiş geçmiş: Teslimat onayı, daha eski bir taşıma taramasından önce gelir. Gönderi teslim edilmiş olarak kalır.
• Tekrarlanan veri alımı: Aynı olay yeniden işlenir. Yinelenen müşteri bildirimi gönderilmez.
• Başarısız deneme: Başarısız bir deneme, teslimat için yola çıkmış durumun ardından gelir. Projeksiyon, destekleyici kanıt olmadan etkin bir teslimat turu vadetmez.
• Teslim almaya hazır olma: Paket, kullanılabilirlik doğrulanmadan önce bir teslim alma tesisine ulaşır. Erken teslim alma talimatı verilmez.
• Bilinmeyen olay: Yeni bir kod ortaya çıkar. Ham kayıt korunur ve daha önce oluşturulmuş gönderi durumu otomatik olarak bilinmeyen durumla değiştirilmez.
• İade hareketi: Ters yolculuk göndericide sona erer. İlk alıcıya teslimat başarılı olarak işaretlenmez.
• Düzeltme: Açık bir kaynak düzeltmesi, denetlenebilir bir geçiş aracılığıyla sonucu değiştirir.

Taşıyıcı ve kaynağa göre eşlenmemiş olayları, metin geri dönüş kullanımını, geçersiz geçişleri ve yinelenen bildirim denemelerini izleyin. Eşleme kapsamını eşleme doğruluğundan ayırın: her kodu tanımak, yorum yanlışsa yararlı değildir.

Bir eşleme değişikliğini kullanıma sunmadan önce temsili geçmişleri yeniden oynatın ve eski ile yeni projeksiyonları karşılaştırın. Teslimat onayını, teslim alma talimatlarını, iadenin tamamlanmasını veya müşteri işlemlerini etkileyen farkları inceleyin. Kuralları sürümlendirin; böylece bir destek temsilcisi sistemin belirli bir sonucu neden ürettiğini açıklayabilir.

SSS

Her takip olayının tam olarak bir durumu olmalı mı?

Her olayın birincil normalleştirilmiş yorumu olabilir; ancak bir koşula, nedene ve yolculuk bağlamına da ihtiyaç duyabilir. Tüm anlamları tek ve düz bir durum listesine zorlamak modeli kullanmayı ve sürdürmeyi zorlaştırır.

Bilinmeyen bir olay mevcut gönderi durumunun yerini almalı mı?

Genellikle hayır. Son desteklenen gönderi durumunu korurken olayın eşlemesini çözümlenmemiş olarak tutun. Kullanıcıların eski ve doğrulanmış bir durumu yeni bir güncellemeyle karıştırmaması için veri güncelliğini ayrı olarak gösterin.

Teslim edilmiş bir gönderi tekrar taşımada durumuna geçebilir mi?

Daha eski bir taşıma taraması bu değişikliğe neden olmamalıdır. Doğrulanmış bir düzeltme bunu haklı çıkarabilir; yeni başlatılmış bir iade yolculuğu ise normalde ayrı temsil edilmelidir. Geçiş yalnızca daha geç bir alınma zamanına değil, açık bir nedene dayanmalıdır.

Eksik takip güncellemeleri nasıl temsil edilmelidir?

Dahili bir güncellik göstergesi veya hareketsizlik uyarısı kullanın. Bunu taşıyıcının bildirdiği gecikme, kayıp veya istisna durumlarından ayrı tutun. Her yükseltme eşiği evrensel bir varsayım yerine hizmet taahhütlerinizi ve işletim politikanızı yansıtmalıdır.

Eşleme değişikliklerini kim onaylamalıdır?

Mühendislik uygulama ve yeniden oynatma testlerinden sorumlu olmalı; lojistik operasyonları gönderi anlamını doğrulamalı; müşteri deneyimi sahibi ise mesajlaşma sonuçlarını onaylamalıdır. Belirsiz olayların süresiz olarak çözümlenmeden kalmaması için adı belirli bir karar sahibi atayın.

Kaynaklar

• RFC 3339: Date and Time on the Internet: Timestamps — zaman damgası gösterimi ve sayısal zaman farkları için referans.
• 17TRACK Tracking API — yukarıda açıklanan takip API'si entegrasyonu için resmi giriş noktası.
• 17TRACK API documentation — sağlayıcının sözleşmesini kontrol etmek için uygulama referansı; bu makaledeki standart model ve eşleme örnekleri sağlayıcıya özgü tanımlar değil, önerilen tasarım modelleridir.