Pazaryeri entegrasyonunda en zor kısım neden ürün eşleme?

Pazaryeri entegrasyonunun en zor kısmı veri göndermek değil, kendi ürün modelinizi pazaryerinin ürün modeline eşlemek. Bunun nedeni basit: iki model birebir aynı değil ve hiçbir zaman olmayacak. Bu yüzden iş kod yazmakla değil, hangi alanın neye karşılık geldiğini satır satır yazan bir alan eşleme tablosuyla başlıyor.

Pazaryeri entegrasyonu nelerden oluşuyor

Teknik olarak dört ayrı akış var ve her biri kendi kurallarıyla çalışıyor:

• Ürün ve fiyat gönderimi: kataloğun pazaryerine açılması ve güncel tutulması.
• Stok eşitleme: satılan ürünün adedinin iki tarafta da düşmesi.
• Sipariş çekme: pazaryerinde oluşan siparişin kendi sisteminize kaydedilmesi.
• Durum güncellemesi: kargoya verildi, teslim edildi, iptal edildi gibi bilgilerin pazaryerine geri bildirilmesi.

Bu dördünden ilki tek seferlik bir iş gibi görünüyor ama değil. Katalog her yeni ürün, her fiyat değişikliği ve her kategori düzenlemesinde yeniden gönderilmek zorunda. Eşleme yapısı sağlam kurulmamışsa bu iş her seferinde elle müdahale gerektiriyor ve entegrasyonun amacı ortadan kalkıyor.

Alan eşleme tablosu: işin asıl gövdesi

Eşleme tablosu, kendi veri modelinizdeki her alanın pazaryerindeki karşılığını ve dönüşüm kuralını yazan belgedir. Birkaç örnek üzerinden nasıl göründüğü:

Tablodaki en çok zorlanan satır sondan ikincisi. Pazaryerleri kategori başına farklı zorunlu nitelik isteyebiliyor; sizin kataloğunuzda o nitelik hiç tutulmuyor olabiliyor. Bu durumda yapılacak iş entegrasyonu zorlamak değil, kendi veri modelinize o alanı eklemek. Eksik niteliği boş ya da uydurma bir değerle göndermek, ürünü listeden düşüren ya da yanlış kategoride gösteren bir sonuç veriyor.

Tek ürün, farklı kimlikler

Entegrasyonun kalbinde bir soru var: iki taraf aynı ürünün aynı ürün olduğunu nereden biliyor? Cevap, baştan belirlenmiş tek bir eşleşme anahtarı olmak zorunda. Pratikte satıcı ürün kodu bu işi görüyor; barkod ise pazaryerinin ürünü kendi kataloğunda tanıması için gerekiyor.

Burada iki yaygın hata var. Birincisi, eşleşmeyi ürün adı üzerinden kurmak: ad değiştiği gün bağ kopuyor ve aynı ürün ikinci kez yükleniyor. İkincisi, pazaryerinin verdiği kendi numarasını hiç saklamamak: güncelleme gönderirken hangi kaydın güncellendiği belirsiz kalıyor. Doğru kurulum üçünü birden tutmak: kendi kodunuz, barkod ve pazaryerinin ürün numarası aynı satırda durur.

Fiyat ve stok: hangi sayı kimin doğrusu

Her entegrasyonda cevaplanması gereken soru şu: çakışma olduğunda hangi taraf haklı? Fiyat ve stok için cevabımız net — doğrunun kaynağı kendi sisteminiz, pazaryeri onun bir yansıması. Pazaryeri panelinden elle yapılan değişiklik bir sonraki gönderimde geri alınıyor; bunu baştan söylemek, sonradan kaybolan indirim tartışmasını önlüyor.

Stok tarafında ikinci bir karar gerekiyor: pazaryerine stoğun tamamı mı yoksa bir kısmı mı açılacak? Tamamını açmak, aynı ürünün aynı anda iki kanalda satılması riskini getiriyor. Bu yüzden kanal başına ayrılmış stok ya da emniyet payı tanımlanabiliyor. Bu bir teknik ayrıntı değil, ticari bir karar ve veri modelinde karşılığının olması gerekiyor.

Fiyat tarafında da vergi, kur ve yuvarlama kurallarının yazılı olması şart. Vergi hariç dolar fiyatından çalışan bir katalogda pazaryerine giden sayı üç dönüşümden geçiyor; bu üç adımın hangisinin hangi sırada uygulandığı belirsizse kuruş farkları birikiyor ve mutabakat tutmuyor.

Sipariş çekme, durum ve iade

Sipariş akışında dikkat edilen üç nokta var. Birincisi, aynı siparişin iki kez kaydedilmemesi: her sipariş pazaryeri numarasıyla tekilleştiriliyor. İkincisi, pazaryerinden gelen müşteri ve adres bilgisinin kendi müşteri yapınıza oturması. Üçüncüsü, durum eşlemesi: sizin sistemdeki durum adları ile pazaryerinin beklediği durumlar birebir aynı olmadığı için bu da bir eşleme tablosu gerektiriyor.

İptal ve iade akışı da baştan tanımlanmalı, çünkü stok iade geldiğinde geri eklenmek zorunda. Sessizce atlanan iade akışı, zamanla gerçek stokla sistem stoğu arasında açıklanamayan bir fark üretiyor.

Siparişin kendi sisteminize düşmesi ile pazaryerine durum bildirilmesi arasındaki süre de bir karar konusu. Anlık tetikleme hızlı ama karşı sistem cevap vermediğinde kayba açık; zamanlanmış çalışma güvenli ama gecikmeli. Uyguladığımız düzen ikisini birleştiriyor: olay anında denenir, başarısız olan kayıt kuyruğa alınıp belirli aralıklarla yeniden denenir ve aynı kaydın iki kez işlenmesi engellenir.

Kısa kontrol listesi

• Alan eşleme tablosu yazılı mı ve her satırda dönüşüm kuralı var mı?
• Eşleşme anahtarı belirlendi mi; kendi kodunuz, barkod ve pazaryeri numarası birlikte mi saklanıyor?
• Pazaryerinin kategori başına istediği zorunlu nitelikler kataloğunuzda tutuluyor mu?
• Çakışmada hangi tarafın doğru olduğu yazılı mı?
• Kanal başına stok ayrımı ya da emniyet payı tanımlı mı?
• Vergi, kur ve yuvarlama sırası yazılı mı?
• İptal ve iade akışında stok geri ekleniyor mu?
• Başarısız çağrılar bir listeye düşüyor mu, yoksa sessizce kayboluyor mu?

KAV Yazılım entegrasyonlarda bu belgeyi işin çıktısı sayıyor: alan eşleme tablosu ve devir belgesi teslimin parçası olarak veriliyor.