ERP ile e-ticaret sitesini bağlamak, iki sistem arasında veri gönderilmesini sağlamaktır; doğru entegrasyon ise bu verinin hangi kuralla işleneceğini de tanımlar. Stok, fiyat ve sipariş alanlarının kaynağı belli değilse bağlantı çalışsa bile yanlış ürün satılabilir veya aynı sipariş iki kez açılabilir.
Proje öncesinde “API var mı?” sorusunun yanında “Hangi verinin doğru kabul edilen kaydı nerede?” sorusunu sorun. Entegrasyonun sınırlarını belirleyen temel karar budur. RESTful API rehberi, veri alışverişinin teknik temelini açıklarken iş kurallarının neden ayrı hazırlanması gerektiğini anlamanıza yardımcı olur.
Her veri için yetkili kaynağı belirleyin
Ürün açıklamaları e-ticaret panelinde, fiziksel stok ERP'de, kampanya fiyatı başka bir uygulamada yönetiliyor olabilir. Bu düzen mümkündür; fakat alan bazında sorumluluk açık olmalıdır. “Ürünler ERP'den gelir” ifadesi bütün alanların aynı kaynaktan yönetildiğini açıklamaz.
| Veri | Kararlaştırılacak konu |
|---|---|
| Ürün kimliği | İki sistemde aynı ürünü hangi kalıcı anahtar eşleştirecek? |
| Stok | Hangi depo ve rezervasyonlar satışa uygun miktarı oluşturacak? |
| Fiyat | Hangi liste, para birimi ve vergi temeli kullanılacak? |
| Sipariş | Hangi aşamada aktarılacak, tekrarlar nasıl tanınacak? |
| İptal ve iade | Hangi durum hangi kaydı ve stoğu güncelleyecek? |
| Müşteri | Mükerrer kayıtlar nasıl ayırt edilecek? |
Bu tabloyu satış, operasyon, muhasebe ve yazılım ekipleri birlikte onaylamalıdır. Aynı kavramın farklı ekiplerde farklı anlam taşıması, teknik geliştirme tamamlandıktan sonra ortaya çıkmamalıdır.
Fiziksel stok ile satılabilir stok aynı mı?
Depoda görünen bütün ürünler satışa açık olmayabilir. Rezerve siparişler, hasarlı ürünler, mağazaya ayrılan miktar ve başka kanallardaki satışlar dikkate alınabilir. Kullanılacak hesap işletmenin stok politikasına göre tanımlanmalıdır.
Varsayımsal bir örnekte depoda 100 adet ürün bulunurken 20 adet açık siparişe, 5 adet mağaza kullanımına ayrılmış olabilir. Diğer koşullar yoksa e-ticarete ayrılan miktar 75 olur. Ancak bu örneği her işletmeye sabit formül olarak uygulamayın; rezervasyonun ne zaman oluştuğu ve ne zaman kaldırıldığı da önemlidir.
100 depodaki ürün (varsayımsal örnek)
25 açık siparişe (20) ve mağaza kullanımına (5) ayrılan
75 e-ticarete ayrılan satılabilir stok
ERP sistemleri üzerinden yürütülen stok hareketlerinin mağazaya hangi sıklıkta yansıyacağını belirleyin. “Anlık” ifadesinin teknik karşılığını sorun. Veri gönderme, işleme ve ekranda görünme zamanları arasında fark bulunabilir.
Fiyat güncellemeleri nasıl çakışmadan çalışmalı?
Liste fiyatı ile kampanyalı fiyat aynı alanmış gibi taşınmamalıdır. Para birimi, vergi dahil veya hariç oluşu, geçerlilik tarihi ve müşteri grubu açık olmalıdır. Yuvarlama kuralları da iki sistemde tutarlı uygulanmalıdır.
E-ticaret panelinde elle değiştirilen bir fiyat, sonraki ERP güncellemesinde üzerine yazılabilir. Bu davranışın hata mı beklenen sonuç mu olduğu önceden kararlaştırılmalıdır. Geçici fiyat istisnası gerekiyorsa süresi ve sorumlusu tanımlanmalıdır.
Dikkat: Güncelleme sırasında boş alanın ne anlama geldiğini de belirleyin. “Değiştirme”, “sil” ve “sıfırla” farklı işlemlerdir. Boş fiyatı sıfır fiyat olarak yorumlayan bir aktarım ticari zarar doğurabilir.
Tekrarlanan mesajlar aynı siparişi yeniden açmamalı
Bağlantı kesintisi veya yanıt gecikmesi nedeniyle aynı kayıt yeniden gönderilebilir. Sistem, işlemi tekrar aldığında daha önce tamamlandığını anlayabilmelidir. Aynı işlemin tekrarıyla ek etki oluşmamasına idempotent çalışma denir.
Shopify'ın webhook belgeleri, tekrar teslimlerin mümkün olduğunu ve işleyicilerin buna göre tasarlanması gerektiğini açıklar. [1] Bu, bütün platformların aynı teknik davranışı gösterdiği anlamına gelmez; kullanılan sistemin yeniden deneme ve bildirim koşulları ayrıca incelenmelidir.
İpucu: Sipariş kimliğini sistemler arasında kaydedin ve aktarım sonucunu izlenebilir tutun. Başarısız kaydı yeniden denemek ile yeni sipariş oluşturmak aynı işlem olmamalıdır. Hata bildiriminde hangi kaydın etkilendiği anlaşılmalıdır.
İptal, iade ve kısmi işlemleri baştan planlayın
Siparişin ilk oluşturulması kadar sonradan değişmesi de entegrasyonun parçasıdır. Kısmi iptal, kısmi sevk ve ürün bazlı iade durumlarında bütün siparişi tek durumla kapatmak yetersiz olabilir. Satır ve miktar düzeyindeki ilişki korunmalıdır.
Pazaryeri kayıtlarında da satış, iade ve düzeltme türleri ayrı izlenebilir. Trendyol'un cari hesap entegrasyonu belgelerinde farklı hareket türlerinin tanımlanması, finansal kayıtların tek bir satış toplamından ibaret olmadığını gösterir. [2] Ticari sipariş durumu ile finansal hareketleri aynı alan gibi kullanmayın.
XML ve Excel aktarım araçları belirli veri güncellemelerini kolaylaştırabilir. Ancak dosya aktarımı kullanılması, sipariş ve hata yönetiminin otomatik olarak tamamlandığı anlamına gelmez; kapsam ayrı belirlenmelidir.
Canlıya geçmeden hangi testler yapılmalı?
Normal siparişin yanında tekrar gönderim, eksik ürün eşlemesi, sıfır stok, fiyat değişikliği, kısmi iade ve bağlantı kesintisi senaryolarını deneyin. Her testte iki sistemde beklenen kaydı yazın. Sonrasında düzenli karşılaştırmayla kaçırılan veya farklılaşan kayıtları bulacak bir kontrol planlayın.
Canlıya geçiş test listesi
- Aynı sipariş tekrar gönderildiğinde ikinci bir kayıt açılmıyor.
- Eşlemesi eksik ürün hata kaydına düşüyor ve sorumlusu görüyor.
- Sıfır stok ve fiyat değişikliği sitede doğru görünüyor.
- Kısmi iade satır ve miktar düzeyinde işleniyor.
- Bağlantı kesildiğinde bekleyen kayıtlar kaybolmuyor.
WebAction'ın özel yazılım geliştirme hizmeti için ERP adını, e-ticaret altyapısını, bağlanacak veri türlerini ve mevcut sorun örneklerini paylaşabilirsiniz. Bu bilgiler, bağlantı teklifini gerçek operasyon kapsamına dönüştürür.
Sık sorulan sorular
API bulunması bütün entegrasyon ihtiyaçlarını karşılar mı?
Hayır. Gerekli alanların, işlemlerin ve erişim izinlerinin API'de desteklenmesi gerekir. İş kuralları ve hata yönetimi de ayrıca tasarlanır.
Stok her saniye güncellenmeli mi?
Güncelleme ihtiyacı satış hızına, kanal sayısına ve sistem olanaklarına bağlıdır. Kritik konu yalnız sıklık değil, rezervasyonların ve başarısız güncellemelerin doğru yönetilmesidir.
Aynı sipariş tekrar gelirse ne olmalı?
Entegrasyon daha önce işlenen kaydı tanımalı ve aynı ticari işlemi yeniden oluşturmamalıdır. Gerekirse mevcut kayıt güncellenir; bu davranış işlem türüne göre tanımlanır.
Entegrasyon tamamlandıktan sonra takip gerekir mi?
Evet. Başarısız kayıtlar, veri farkları ve sistem değişiklikleri izlenmelidir. Çalışan bağlantının zaman içinde aynı kapsamda sorunsuz kalacağı varsayılmamalıdır.
Kaynaklar
- Shopify geliştirici belgeleri — Webhook doğrulama ve tekrarlar (17.10.2026)
- Trendyol — Cari hesap kayıtları entegrasyonu (17.10.2026)
