Kargo Etiketi, Takip Numarası ve Sevkiyat Süreci Nasıl Yönetilir?
Ders 6 / 10 · 30 dakika okuma · İleri
Gönderi kaydı oluşturma, etiket ve takip numarasını fiziksel paketle eşleştirme, taşıyıcıya devir ve takip olaylarını sipariş sistemine güvenilir biçimde aktarma sürecini öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Sipariş ile shipment/gönderi kaydını birbirinden ayırmak
- ✓Etiket ve takip numarasının yaşam döngüsünü yönetmek
- ✓Tek siparişte birden fazla paket/gönderi modellemek
- ✓Etiket oluşturma ile fiziksel taşıyıcı devrini ayırmak
- ✓Manifest ve devir kontrolleriyle eksik paket riskini azaltmak
- ✓Taşıyıcı takip olaylarını normalize etmek
- ✓Takip verisindeki gecikme ve istisnaları operasyon kuyruğuna dönüştürmek
Sipariş sistemindeki ticari kayıt ile taşıyıcının taşıdığı fiziksel gönderi aynı nesne değildir. Bir sipariş tek pakette çıkabileceği gibi iki farklı depodan veya iki ayrı kolide de gönderilebilir. Bu nedenle shipment/gönderi katmanı ayrı modellenmelidir.
1. Order, shipment ve package kavramlarını ayırın
| Nesne | Ne temsil eder? | Örnek |
|---|---|---|
| Order/Sipariş | Müşterinin ticari satın alma kaydı | 3 ürünlü sipariş |
| Shipment/Gönderi | Bir sevkiyat operasyonu | A ve B ürünü bugün |
| Package/Paket | Taşıyıcının fiziksel taşıma birimi | 2 koli |
| Tracking | Taşıyıcı takip kimliği | Her paket veya gönderiye bağlı referans |
2. Shipment kaydını sevke hazır ürünlerle ilişkilendirin
Gönderi kaydı hangi sipariş satırlarının hangi miktarını içerdiğini bilmelidir. Parçalı sevkiyatta aynı sipariş satırının bir kısmı farklı shipment'larda bulunabilir.
Örnek — Parçalı sevkiyat
3. Gönderi oluşturmayı idempotent tasarlayın
Taşıyıcı API'sine gönderi oluşturma isteği timeout olduğunda aynı sipariş için kontrolsüz ikinci istek iki ayrı gönderi veya etiket oluşturabilir. İç shipment ID veya benzersiz referans üzerinden önce mevcut sonuç sorgulanmalıdır.
Uyarı — Timeout başarısızlık demek değildir
4. Etiket yaşam döngüsünü kaydedin
- Shipment oluşturulur.
- Taşıyıcı/hizmet seçilir.
- Gönderi sağlayıcıda oluşturulur.
- Takip numarası alınır.
- Etiket üretilir.
- Etiket doğru fiziksel pakete uygulanır.
- Paket sevkiyat alanına alınır.
- Fiziksel taşıyıcı devri doğrulanır.
- Takip olayları izlenir.
5. Etiket yeniden basımını yeni gönderi saymayın
Yazıcı problemi nedeniyle aynı etiket tekrar basılabilir. Reprint olayı yeni takip numarası üretmemeli ve aynı shipment kaydıyla ilişkili kalmalıdır. Yeni etiket/gönderi ancak iş kuralı gerçekten yeni taşıyıcı kaydı gerektiriyorsa oluşturulmalıdır.
6. Etiket iptalini fiziksel duruma göre yönetin
Paket henüz taşıyıcıya verilmediyse sağlayıcı destekliyorsa gönderi kaydı iptal edilebilir. Fiziksel devirden sonra aynı işlem artık yalnız 'etiketi iptal et' problemi değildir; taşıyıcının geri çağırma veya iade süreci gerekebilir.
7. Manifest/devir kontrolü oluşturun
Günün sonunda sistemde sevke hazır görünen paketler ile taşıyıcıya fiziksel olarak verilen paketler karşılaştırılmalıdır. Manifest, scan veya teslim tutanağı benzeri kayıtlar işletmenin kullandığı taşıyıcı modeline göre fiziksel devri destekleyebilir.
| Kontrol | Beklenen | Fark varsa |
|---|---|---|
| Sevke hazır paket | Manifest/devir listesinde | Depoda unutulan paket incelemesi |
| Manifest paketi | Sistemde shipment mevcut | Yetkisiz/yanlış paket incelemesi |
| Takip numarası | Tek doğru paketle eşleşiyor | Etiket karışıklığı |
| Paket adedi | Shipment beklentisiyle aynı | Eksik/fazla koli kontrolü |
8. 'Kargoya verildi' olayını fiziksel kanıta bağlayın
Etiket üretim zamanı, manifest zamanı, pickup zamanı ve ilk taşıyıcı taraması farklı olabilir. İşletme müşteriye 'kargoya verildi' bilgisini hangi güvenilir olayda göstereceğini açıkça belirlemelidir.
Örnek — Sahte hız metriği
9. Taşıyıcı durumlarını ortak statülere normalize edin
Farklı taşıyıcılar aynı olayı farklı kodlarla adlandırabilir. İşletme taşıyıcıya özgü ham olayları korurken raporlama ve müşteri deneyimi için ortak bir durum sözlüğüne eşleyebilir.
| Ortak durum | Taşıyıcı olay örnekleri |
|---|---|
| Gönderi oluşturuldu | Label created / shipment registered |
| Taşıyıcı kabul etti | Picked up / accepted |
| Transferde | In transit / hub transfer |
| Dağıtımda | Out for delivery |
| Teslim edildi | Delivered |
| Teslimat istisnası | Address issue / recipient unavailable / damaged |
| İade dönüşü | Return to sender / returning |
10. Ham taşıyıcı olayını da saklayın
Normalize durum operasyonu sadeleştirir ancak ayrıntıyı kaybetmemek için taşıyıcının ham event kodu, açıklaması ve event zamanı da saklanmalıdır. Böylece uyuşmazlık veya destek vakasında gerçek kaynak olaya dönülebilir.
11. Event zamanı ile sisteme geliş zamanını ayırın
Taşıyıcı bir olayın 14.05'te gerçekleştiğini ancak webhook'u 14.20'de göndermiş olabilir. Operasyon analizi için event_at ve received_at benzeri iki zamanın ayrılması veri gecikmesini ölçmeye yardımcı olur.
12. Takip olaylarını idempotent işleyin
Aynı takip olayı birden fazla kez gelebilir. Event ID veya taşıyıcı + takip numarası + olay kodu + olay zamanı gibi güvenilir bileşimlerle duplicate işleme engellenmelidir.
13. Sırasız gelen olaylara hazırlıklı olun
Entegrasyon gecikmeleri nedeniyle 'dağıtımda' olayı sisteme 'transferde' olayından önce ulaşabilir. Sistem yalnız geliş sırasına bakarak gönderiyi geriye taşımamalı; taşıyıcının olay zamanı ve durum geçiş kuralları dikkate alınmalıdır.
Uyarı — Teslim edildi durumunu körlemesine geri çevirmeyin
14. İlk hareket gecikmesini izleyin
Taşıyıcıya verildiği düşünülen pakette belirli süre içinde ilk kabul/hareket olayı oluşmuyorsa paket depoda kalmış, taranmamış veya entegrasyon olayı gecikmiş olabilir. Bu durum proaktif istisna kuyruğuna alınabilir.
| İstisna | Kontrol | Aksiyon |
|---|---|---|
| Etiket var, devir yok | Depo/manifest | Paketi bul |
| Devir var, ilk scan yok | Taşıyıcı teyidi | Pickup kaydını doğrula |
| Takip uzun süre hareketsiz | Son hub/event | Taşıyıcı vakası aç |
| Delivered event şüpheli | Teslim kanıtı | Müşteri/taşıyıcı incelemesi |
15. Sevkiyat KPI'larını gerçek olaylardan üretin
| KPI | Başlangıç | Bitiş |
|---|---|---|
| Pack-to-handover | Paket hazır | Fiziksel taşıyıcı devir |
| Handover-to-first-scan | Fiziksel devir | İlk taşıyıcı kabul/hareket |
| Transit time | Taşıyıcı kabul | Teslim |
| Tracking latency | Taşıyıcı event zamanı | Sisteme geliş zamanı |
| No-first-scan oranı | Devir yapılmış paketler | Belirlenen sürede scan olmayanlar |
Şimdi Uygulayın
Uygulama Görevi — Shipment ve Takip Akışı Tasarlayın
Tek paketli, iki paketli ve parçalı sevkiyatlı üç sipariş senaryosu oluşturun. Her senaryoda order, shipment, package ve tracking ilişkisini; etiket oluşturma, fiziksel devir ve taşıyıcı event'lerinin hangi durumları değiştirdiğini yazın.
| Olay | Kaynak | İç durum | Müşteri görünümü | İstisna kuralı |
|---|---|---|---|---|
| Etiket oluşturuldu | … | … | … | … |
| Taşıyıcı kabul etti | … | … | … | … |
| Transferde | … | … | … | … |
| Dağıtımda | … | … | … | … |
| Teslim | … | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Kargo etiketi ve takip numarası siparişin fiziksel sevkiyat kimliğidir; ancak etiket oluşturulması paketin gerçekten taşıyıcıya verildiğini kanıtlamaz.
- ✓Sipariş altında bir veya daha fazla gönderi kaydı tutulmalı, her gönderinin paketleri ve ürünleri doğru takip numarasıyla eşleştirilmeli, fiziksel devir doğrulanmalı ve taşıyıcı takip olayları ortak operasyon durumlarına dönüştürülmelidir.