İkinci Kargo Firmasını Eklemek: Çok Taşıyıcılı Entegrasyon
Çok taşıyıcılı kargo entegrasyonu, yazılımın gönderiyi tek bir firmaya göre değil, ortak bir gönderi modeline göre üretmesi demektir. İkinci taşıyıcıyı eklemenin zor tarafı yeni bir servise bağlanmak değil; ilk entegrasyonun o firmanın alan adlarıyla, durum kodlarıyla ve barkod biçimiyle iç içe yazılmış olmasıdır.
Kargo entegrasyonunun ilk kurulumunu kargo entegrasyonu, barkod takip ve iade akışı yazısında anlatmıştık. Bu yazı, o kurulumun üstüne ikinci ve üçüncü taşıyıcının nasıl ekleneceğini anlatıyor.
Önce ortak gönderi modeli
İkinci taşıyıcıyı eklemenin ilk adımı kod yazmak değil, gönderiyi taşıyıcıdan bağımsız tanımlamaktır. Ortak modelde şu alanlar bulunur: gönderici ve alıcı bilgisi, paket sayısı, her paketin ağırlık ve ölçüsü, ödeme tipi (gönderici ya da alıcı ödemeli), teslim tipi (adrese, şubeye, kapıda ödemeli), ek hizmetler ve referans numaraları.
Bu modelin üzerine her taşıyıcı için bir uyarlayıcı konur. Uyarlayıcının tek işi ortak modeli o firmanın beklediği biçime çevirmek ve dönen cevabı tekrar ortak biçime çevirmektir. Yazılımın geri kalanı hangi firmayla çalışıldığını bilmez; sipariş ekranı, depo ekranı ve müşteri bildirimi aynı kalır.
Hangi gönderi hangi taşıyıcıyla gider?
İkinci firma eklendiğinde yeni bir karar doğar: her gönderi için taşıyıcıyı kim seçecek? Üç yaklaşım var ve çoğu işletme bunların bir karışımını kullanır.
| Yöntem | Nasıl çalışır | Ne zaman uygun |
|---|---|---|
| Elle seçim | Depo personeli listeden seçer | Gönderi sayısı az, istisna çok |
| Kural tablosu | Bölge, ağırlık, teslim tipine göre | Düzenli ve tahmin edilebilir akış |
| Müşteri seçimi | Sipariş sırasında müşteri seçer | Teslim tercihi öne çıkan satış |
Kural tablosu kurulurken dikkat edilecek nokta, kuralın sonucunun kaydedilmesidir. Gönderi oluşurken hangi kuralın hangi taşıyıcıyı seçtiği yazılmazsa, bir hafta sonra neden o firmayla gittiği sorusu cevapsız kalır. Kural tablosunun kendisi de panelden düzenlenebilir olmalı; her bölge değişikliğinde yazılım güncellemesi beklemek işi durdurur.
Durum kodları nasıl birleştirilir?
Her taşıyıcının kendi durum sözlüğü vardır ve bunlar birbirine birebir çevrilmez. Yazılımın içinde tutulması gereken şey, az sayıda ve işletmenin anladığı bir durum kümesidir: oluşturuldu, teslim alındı, yolda, şubede bekliyor, teslim edildi, teslim edilemedi, iade sürecinde, iade teslim alındı.
Her taşıyıcının kodları bu kümeye eşlenir ve eşleme tablosu kodun içinde değil veritabanında durur. Eşlenemeyen bir kod geldiğinde gönderi durumu değiştirilmez, kod ham hâliyle kaydedilip bir uyarı listesine düşer. Taşıyıcı yeni bir kod eklediğinde yazılım yanlış durum göstermek yerine susar; bu, sessiz yanlıştan iyidir.
Müşteriye gösterilen metin de bu ortak kümeden üretilir. Böylece hangi firmayla gittiğinden bağımsız olarak takip ekranı aynı dili konuşur. Bildirim altyapısının kendisini bildirim altyapısı yazısında ele almıştık; buradaki tek ek kural, bildirimin taşıyıcı koduyla değil ortak durumla tetiklenmesi.
Takip sorgusunun nasıl yapıldığı da taşıyıcıya göre değişir: bazı servisler durum değişince bildirim gönderir, bazıları yalnızca sorgulandığında cevap verir. Yazılımın bu iki yöntemi aynı yere bağlaması gerekir; yani bildirimle gelen durum da, sorguyla alınan durum da aynı güncelleme yolundan geçer. İki ayrı yol yazıldığında biri düzeltilip diğeri eski kalır ve aynı gönderi iki ekranda iki farklı durumda görünür.
Barkod, etiket ve iade
Her taşıyıcı etiketi kendi biçiminde üretir ve etiketin ölçüsü de farklı olabilir. Yazılım etiketi kendisi tasarlamaya çalışmamalı; taşıyıcıdan gelen etiket dosyasını olduğu gibi yazdırmalı. Etiket yazıcısının bağlanmasını ve ölçü ayarlarını barkod etiket yazıcısı yazısında ayrıca anlattık.
İade tarafında da iki ayrım vardır: alıcının gönderiyi kabul etmemesi ve alıcının sonradan iade etmesi. İlki taşıyıcının kendi akışıyla geri döner ve çoğunlukla aynı gönderi numarası üzerinde ilerler. İkincisi yeni bir gönderi doğurur ve iade kodu üretilmesi gerekir. Ortak modelde bu iki durumun ayrı tutulması, depo tarafında gelen paketi doğru belgeye bağlamayı kolaylaştırır.
Geçiş hangi sırayla yapılır?
İkinci taşıyıcıyı canlıya almanın güvenli sırası şöyle işler. Önce ortak model ve uyarlayıcı yazılır, mevcut firma bu modelin üzerine taşınır ve hiçbir davranış değişmediği doğrulanır. Sonra ikinci firma yalnızca test hesabıyla eklenir ve örnek gönderiler üretilir. Ardından küçük bir gönderi grubu, örneğin tek bir bölge, ikinci firmaya yönlendirilir.
Bu sırayı atlayıp iki firmayı aynı anda devreye almak, bir sorun çıktığında hangi tarafın bozulduğunu anlamayı imkânsız hâle getirir. Devreye alma ve geri dönüş planını yazılım devreye alma ve geri dönüş planı yazısında anlattığımız yapı burada da geçerlidir: kural tablosunda tek satır değiştirilerek eski firmaya dönülebiliyorsa geçiş güvenlidir.
Kısa kontrol listesi
- Gönderi, taşıyıcıdan bağımsız ortak bir modelle tutuluyor.
- Her taşıyıcı için ayrı uyarlayıcı var; iş kuralları uyarlayıcıya sızmıyor.
- Taşıyıcı seçim kuralı panelden düzenlenebiliyor ve sonucu kaydediliyor.
- Durum kodları ortak bir kümeye eşleniyor; bilinmeyen kod uyarı üretiyor.
- Etiket taşıyıcıdan geldiği gibi yazdırılıyor.
- Kabul etmeme ve sonradan iade ayrı akışlar olarak tutuluyor.
- Geri dönüş tek satır kural değişikliğiyle mümkün.
Özetle ikinci kargo firmasını eklemek bir entegrasyon işi değil, bir modelleme işidir: gönderiyi doğru tanımlayan yazılıma üçüncü taşıyıcıyı eklemek birkaç günlük iş olur. KAV Yazılım kargo entegrasyonlarını bu ortak model üzerine kuruyor; anlaşma koşulları, bölge ve ücret tabloları müşterinin kendi kargo sözleşmesinden tanım ekranına girilir.
Sık sorulan sorular
İkinci kargo firmasını eklemek mevcut entegrasyonu bozar mı?
Hangi gönderinin hangi firmayla gideceğine yazılım karar verebilir mi?
Taşıyıcıların durum kodları farklı, takip ekranı nasıl tek dil konuşur?
Kargo etiketini yazılım kendisi mi tasarlamalı?
- api entegrasyonu
- kargo entegrasyonu
- özel yazılım
- sevkiyat
