UPS Tracking API ve OMS Entegrasyonu: Hangisini Seçmelisiniz?
Yalnızca gönderi durumuna ihtiyacınız varsa bir UPS takip API'si seçin. Siparişleri, envanteri, sipariş karşılamayı, yönlendirmeyi, iptalleri ve iadeleri birden fazla kanal üzerinden koordine etmeniz gerekiyorsa bir OMS entegrasyonu seçin. Birçok e-ticaret operasyonunda pratik yanıt ya o ya da bu değildir: OMS sipariş yaşam döngüsünü yönetirken, bir taşıyıcı veya çoklu taşıyıcı takip API'si teslimat olaylarını sağlar.
Doğru karar, ekibinizin gerçekleştirmesi gereken eyleme bağlıdır. Bir takip sayfası geliştiren geliştiricinin gereksinimi; bir pazaryerini, depoyu, 3PL'yi ve müşteri hizmetleri sistemini birbirine bağlayan operasyon ekibinin gereksiniminden farklıdır. Bir UPS takip API'sini ve OMS'yi birbirinin yerine kullanılabilir olarak değerlendirmek gereksiz geliştirme çalışmalarına yol açabilir veya önemli operasyonel boşluklar oluşturabilir.
Fark tek cümleyle
UPS takip API'si, taşıyıcı verilerine bağlantıdır. OMS entegrasyonu ise sipariş iş akışına bağlantıdır.
Bir takip API'si genellikle bir uygulamanın takip numarasıyla ilişkili gönderi bilgilerini almasına veya görüntülemesine yardımcı olur. Bu bilgiler müşteri bildirimlerini, markalı bir takip sayfasını, şirket içi gönderi izlemeyi veya istisna yönetimini destekleyebilir. Kapsam öncelikle gönderi görünürlüğüdür.
Bir sipariş yönetim sistemi daha geniş bir süreç katmanında yer alır. Birden fazla satış kanalından gelen siparişleri koordine edebilir, envanter tahsisi yapabilir, sipariş karşılama noktalarıyla iletişim kurabilir, siparişleri depolara veya 3PL'lere gönderebilir ve durumu mağazalara veya pazaryerlerine geri senkronize edebilir. Kesin özellik seti OMS'ye göre değişir; bu nedenle yetenekler yalnızca ürün etiketinden varsayılmamalı, ürün belgelerinde doğrulanmalıdır.
UPS takip API'sinin daha iyi seçim olduğu durumlar
Temel iş sorunu UPS gönderilerinin nerede olduğunu bilmek ve bu bilgiyi başka bir uygulamada kullanılabilir hâle getirmekse doğrudan bir UPS takip entegrasyonu seçin.
- Müşteriye yönelik takip: Web siteniz veya uygulamanız, müşterilerin deneyimden ayrılmasını gerektirmeden gönderi ilerlemesini göstermelidir.
- Destek iş akışları: Temsilcilerin yardım masası, CRM veya sipariş ekranı içinde güncel takip olaylarına ihtiyacı vardır.
- Teslimat bildirimleri: Sisteminizin e-posta, SMS veya diğer müşteri iletişimleri için girdi olarak gönderi olaylarına ihtiyacı vardır.
- İstisna izleme: Operasyon personelinin gecikmeleri, teslimat girişimlerini veya takip gerektiren diğer olayları belirlemesi gerekir.
- Tek taşıyıcılı operasyon: UPS, ilgili gönderilerin çoğunu veya tamamını taşıdığı için taşıyıcıya özel bir entegrasyon operasyonel açıdan makuldür.
Bu yaklaşım genellikle kapsamı belirleme açısından tam kapsamlı bir OMS projesinden daha dar ve kolaydır. Ekip gerekli takip numarası biçimlerini, olay alanlarını, kimlik doğrulama yöntemini, yenileme davranışını, hata yönetimini ve müşteriye gösterilecek durum dilini tanımlayabilir. İşletmenin sipariş tahsisi veya envanter süreçlerini yeniden tasarlamasını gerektirmez.
Ancak bir takip API'si sipariş yönetim sistemi olarak değerlendirilmemelidir. Takip verileri bir gönderiye ne olduğunu gösterebilir; ancak tek başına hangi deponun siparişi karşılayacağına karar veremez, stok ayıramaz, siparişi bölemez, iptali onaylayamaz veya iade iş akışı oluşturamaz.
OMS entegrasyonunun daha iyi seçim olduğu durumlar
Sorun gönderi oluşturulmadan önce başlıyor veya taşıyıcı görünürlüğünün ötesine geçiyorsa bir OMS entegrasyonu seçin.
Bir işletmenin aşağıdakilerden birkaçını koordine etmesi gerekiyorsa OMS daha uygundur:
- Birden fazla mağaza, pazaryeri veya satış kanalından gelen siparişler
- Mağazalar, depolar ve sipariş karşılama ortakları arasındaki envanter kullanılabilirliği
- Konuma, stoğa, hizmet seviyesine veya operasyonel kurallara dayalı sipariş yönlendirme
- Kısmi gönderiler, bekleyen siparişler, iptaller ve sipariş değişiklikleri
- Depolara veya 3PL sistemlerine gönderilen sipariş karşılama talimatları
- OMS ile satış kanalları arasındaki durum senkronizasyonu
- Taşıyıcı durumundan daha fazlasını içeren iadeler, geri ödemeler veya satın alma sonrası iş akışları
Bu modelde UPS, daha büyük bir süreç içindeki olası taşıyıcı bağlantılarından biridir. OMS sipariş karşılama kayıtlarını oluşturabilir veya alabilirken, taşıyıcı entegrasyonu taşıma ayrıntılarını sağlar. OMS daha sonra sipariş yaşam döngüsünü güncellemek için gönderi kilometre taşlarını kullanabilir; ancak kesin davranış, ilgili sistemlere ve eşleme kurallarına bağlıdır.
Bu nedenle OMS entegrasyonu daha kapsamlı bir uygulama kararıdır. Veri sahipliği, envanter senkronizasyonu, sipariş durumu tanımları, depo süreçleri, istisna kuyrukları ve mutabakat gibi konuları içerebilir. Bir işletme yalnızca daha iyi bir takip sayfası istediği için OMS bağlantısı satın almamalı veya geliştirmemelidir.
UPS takip API'si ve OMS entegrasyonu
| Karar alanı | UPS takip API'si | OMS entegrasyonu |
|---|---|---|
| Temel amaç | UPS gönderi durumunu sunmak veya işlemek | Sipariş yaşam döngüsünü ve sipariş karşılama operasyonlarını koordine etmek |
| Ana veri nesnesi | Takip numarası, paket, gönderi olayları | Sipariş, satır öğeleri, envanter, sipariş karşılama, gönderi ve muhtemel iadeler |
| En uygun sahip | Ürün mühendisliği, müşteri deneyimi veya destek sistemleri | E-ticaret operasyonları, sipariş karşılama, kurumsal mimari ve mühendislik |
| Tipik kapsam | Tek taşıyıcı veya takip hizmeti | Birden fazla kanal, tesis, sistem ve sipariş karşılama ortağı |
| Otomatik olarak çözmediği konu | Envanter tahsisi, yönlendirme veya sipariş orkestrasyonu | Entegrasyon sağlamadığı sürece taşıyıcı olaylarının doğru şekilde normalleştirilmesi |
| Uygulama riski | Alan eşleme, kimlik doğrulama, yoklama veya olay yönetimi ve durumların yorumlanması | Veri sahipliği, durum senkronizasyonu, envanter doğruluğu ve sistemler arası mutabakat |
Bu tablo, her tedarikçi için garanti vermek yerine genel mimari ayrımı açıklar. Bazı platformlar sipariş yönetimi ile gönderi görünürlüğünü birleştirirken bazı takip sağlayıcıları birden fazla taşıyıcıyı destekler. Bir entegrasyon modeli seçmeden önce özel belgeleri doğrulayın.
Büyüyen birçok işletmenin ihtiyaç duyduğu seçenek: OMS ve çoklu taşıyıcı takibi
UPS'yi diğer taşıyıcılarla birlikte kullanan işletmelerin çoğu zaman yalnızca UPS bağlantısından daha kapsamlı bir takip katmanına ihtiyacı vardır. Çoklu taşıyıcı takip hizmeti, taşıyıcılar arasındaki gönderi olaylarını normalleştirebilir; OMS ise sipariş ve sipariş karşılama süreçlerinden sorumlu olmaya devam eder.
17TRACK, programatik takip entegrasyonuna ihtiyaç duyan işletmeler için bir takip API'si sunar ve geliştirici belgeleri yayımlar. Bu, gereksinimin yalnızca UPS ile ilgili bir iş akışından ziyade taşıyıcılar arasında gönderi görünürlüğü olduğu durumlarda önemlidir. Belirli bir proje için mevcut API kapsamını, desteklenen işlemleri, kimlik doğrulama gereksinimlerini ve uygulama ayrıntılarını doğrulamak üzere resmi belgeler kullanılmalıdır.
Bu mimari, birkaç sipariş karşılama ortağı bulunan bir perakendeci veya son kilometre taşıyıcısının varış noktasına göre değiştiği sınır ötesi bir operasyon için yararlı olabilir. OMS sipariş ve sipariş karşılama durumunu tutabilir; takip katmanı ise müşteriye yönelik veya şirket içi uygulamalara gönderi güncellemeleri sağlayabilir. Yine de iki sistemin net sahiplik kuralları olmalıdır. Örneğin sipariş durumu için hangi sistemin yetkili olduğunu, taşıyıcı olayları için hangi sistemin yetkili olduğunu ve çakışan güncellemelerin nasıl çözüleceğini tanımlayın.
Basit, yalnızca UPS kullanan bir mağaza için hem OMS hem de çoklu taşıyıcı takip hizmeti eklemek gereksiz olabilir. Birden fazla taşıyıcı ve kanala sahip bir işletme için ise normalleştirilmiş bir takip katmanından kaçınmak; ayrı entegrasyonlara, tutarsız durum etiketlerine ve daha fazla bakıma yol açabilir.
Aşırı geliştirme yapmadan nasıl seçim yapılır?
1. İş olayıyla başlayın
Eylemi tetiklemesi gereken olayı yazın. “Sipariş sayfasında en son UPS durumunu göster” ifadesi bir takip API'sine işaret eder. “Ödenen her siparişi en uygun sipariş karşılama konumuna gönder ve envanteri senkronize tut” ifadesi OMS'ye işaret eder. “Bir paket 3PL'den ayrıldıktan sonra müşteriyi güncelle” ise her ikisini de gerektirebilir.
2. Verilerin hâlihazırda sahibi olan sistemleri eşleyin
Mağazayı, pazaryerini, ERP'yi, depo yönetim sistemini, 3PL'yi, müşteri hizmetleri platformunu, OMS'yi ve taşıyıcı bağlantılarını listeleyin. Her biri için siparişleri, envanteri, sipariş karşılama kayıtlarını ve takip olaylarını oluşturup oluşturmadığını, değiştirdiğini veya yalnızca okuduğunu belirleyin. Bu, yeni bir entegrasyonun birbiriyle yarışan iki doğruluk kaynağı oluşturmasını önler.
3. Taşıyıcı çeşitliliğini ve coğrafyayı kontrol edin
Kapsamdaki tek taşıyıcı UPS ise doğrudan UPS bağlantısı yeterli olabilir. Operasyon birden fazla taşıyıcı, posta operatörü veya varış noktasına özel son kilometre ortağı kullanıyorsa daha kapsamlı bir takip API'sinin ayrı entegrasyonları azaltıp azaltamayacağını değerlendirin. Bir sağlayıcının her taşıyıcıyı, ülkeyi veya olay türünü desteklediğini varsaymayın; gönderi profiliniz için ilgili kapsamı doğrulayın.
4. Minimum durum modelini tanımlayın
Taşıyıcı olayları genellikle müşterilere gösterilen durumlardan daha ayrıntılıdır. Geliştirmeden önce ham olayları etiket oluşturuldu, taşıma hâlinde, dağıtıma çıktı, teslim edildi, istisna ve iade edildi gibi iş durumlarına eşleyin. Bir olay geciktiğinde, yinelendiğinde, eksik olduğunda veya sırası dışında alındığında ne olacağını belirleyin. Veriler doğrudan UPS'ten veya bir takip platformu üzerinden gelse de bu çalışma gereklidir.
5. Operasyonel istisnaları test edin
Başarılı bir demo genellikle normal bir teslimatı izler. Yararlı bir kavram kanıtı; geçersiz bir takip numarasını, hiç olayı olmayan bir gönderiyi, gecikmiş taramayı, teslimat istisnasını, kısmi gönderiyi, değiştirme siparişini ve iadeyi de test etmelidir. OMS projesi için bölünmüş siparişleri, envanter eksikliklerini, iptal girişimlerini ve yinelenen sipariş mesajlarını da ekleyin.
6. Toplam işletim çabasını karşılaştırın
Yalnızca ilk entegrasyon çabasını karşılaştırmayın. İzleme, API değişiklikleri, destek araçları, mutabakat, taşıyıcı ekleme, veri saklama, erişim denetimi ve hata kurtarmayı da dahil edin. Dar bir API, dar bir sorun için en düşük riskli seçim olabilir. İşletmenin zaten birden fazla taşıyıcısı ve sipariş karşılama sistemi varsa daha kapsamlı bir platformun bakımı daha kolay olabilir.
Pratik bir karar kuralı
İstenen sonuç, mevcut bir uygulamada güvenilir UPS gönderi görünürlüğü ise UPS takip API'si kullanın. İstenen sonuç, kanallar veya konumlar arasında koordineli sipariş ve sipariş karşılama yürütmesi ise OMS entegrasyonu kullanın. OMS'nin siparişleri yönetmesi ve ayrı bir takip katmanının müşteri hizmetleri veya satın alma sonrası deneyimleri için gönderi olaylarını birleştirmesi gerekiyorsa her ikisini de kullanın.
Seçenekleri değerlendiren bir işletme için sonraki adım kapsamlı bir teknik taahhüt yerine küçük ve belgelenmiş bir entegrasyon testi olmalıdır. Temsili siparişleri seçin, beklenen alanları ve durumları tanımlayın, normal ve istisna durumlarını test edin ve her karardan hangi sistemin sorumlu olduğunu kaydedin. Proje daha sonra ek taşıyıcılara genişlerse, bağımsız taşıyıcı bağlantılarını tek tek eklemek yerine çoklu taşıyıcı takip API'sinin daha uygun olup olmadığını yeniden değerlendirin.
En güçlü seçim, bir sonraki olası gereksinimi engellemeden mevcut operasyonel sorunu çözen en küçük mimaridir. Bir takip API'si OMS olarak pazarlanmamalı ve yalnızca bir takip sayfası görüntülemek için OMS kullanılmamalıdır.
SSS
UPS takip API'si OMS ile aynı mıdır?
Hayır. UPS takip API'si UPS gönderi bilgilerine odaklanır. OMS; envanter, yönlendirme, sipariş karşılama, iptaller ve iadeleri içerebilen daha kapsamlı sipariş ve sipariş karşılama süreçlerini koordine eder. Bir işletme OMS merkezli bir mimaride takip API'si kullanabilir.
OMS, UPS gönderilerini takip edebilir mi?
OMS'nin UPS entegrasyonu varsa veya ayrı bir takip hizmetine bağlanıyorsa bunu yapabilir. Bu özellik ürüne özeldir ve OMS belgelerinde doğrulanmalıdır. Yalnızca OMS etiketi, gerekli UPS olaylarını veya iş akışlarını desteklediğini kanıtlamaz.
Markalı bir takip sayfası oluşturmak için OMS'ye ihtiyacım var mı?
Genellikle hayır. Markalı bir takip sayfası genellikle gönderi verilerini alabilen ve müşteriye sunabilen bir uygulamaya veya takip hizmetine ihtiyaç duyar. OMS sipariş bağlamı sağlayabilir; ancak sayfanın kendisi için otomatik olarak gerekli değildir.
Ne zaman çoklu taşıyıcı takip API'si kullanmalıyım?
Gönderiler birden fazla taşıyıcı kullanıyorsa ve uygulamalarınız teslimat olaylarını almak veya görüntülemek için tutarlı bir yönteme ihtiyaç duyuyorsa böyle bir API'yi değerlendirin. Gerçekte işlettiğiniz güzergâhlar için sağlayıcının taşıyıcı kapsamını, olay modelini, belgelerini, hizmet limitlerini ve istisnaları ele alma biçimini doğrulayın.
Geliştiriciler entegrasyondan önce neleri netleştirmelidir?
Kimlik doğrulamayı, istek ve yanıt alanlarını, durum tanımlarını, güncelleme sıklığını, hata yönetimini, yinelenen olayları, takip numarası doğrulamasını, saklama süresini, güvenliği ve sistem sahipliğini netleştirin. Ayrıca bir takip olayının müşteriye gösterilen sipariş durumunu nasıl değiştirdiğini belgeleyin.
Kaynaklar
- UPS Developer Portal — UPS API'leri ve entegrasyon kaynakları için resmi geliştirici giriş noktası.
- 17TRACK Tracking API — programatik takip entegrasyonu için resmi ürün sayfası.
- 17TRACK API Documentation — uygulama referansı için resmi geliştirici belgeleri.
