Shopify ERP Entegrasyonu: Neden Basit Bir Bağlantıdan Fazlasına İhtiyacınız Var?
Shopify’ı ERP sistemine bağlamak çoğunlukla basit bir entegrasyon projesi olarak anlatılır.
Ürünler ERP’den Shopify’a, siparişler Shopify’dan ERP’ye aktarılır. Stok senkronize edilir. Entegrasyon tamamlanmış sayılır.
Gerçek e-ticaret operasyonlarında zor olan, veriyi bir API’den diğerine taşımak değildir. Asıl zorluk; her verinin hangi sisteme ait olduğunu, ne zaman aktarılacağını, hata olduğunda ne yapılacağını ve tekrarlı veya çelişkili kayıt üretmeden operasyonun nasıl toparlanacağını belirlemektir.
Doğru entegrasyon katmanı burada önem kazanır.
Entegrasyon yalnızca Shopify ile ERP arasındaki bağlantı değildir
Basit şema şöyle görünebilir:
Shopify ↔ ERP
İşletme büyüdükçe gerçek mimari çoğunlukla şuna yaklaşır:
Shopify ↔ Entegrasyon Katmanı ↔ ERP / OMS / WMS / Pazaryerleri / Lojistik
Entegrasyon katmanı sistemlerin arasında yer alır ve e-ticaret operasyonunda bilginin nasıl hareket ettiğini yönetir.
Her sistemin diğer tüm sistemlere doğrudan bağlanması yerine eşleştirme, doğrulama, senkronizasyon, hata yönetimi ve izleme için kontrollü bir nokta sağlayabilir.
Bu ayrım önemlidir; çünkü büyüyen e-ticaret operasyonları nadiren yalnızca iki sistemden oluşur.
Bir markanın Shopify, ERP, fiziksel mağazalar, birden fazla depo, pazaryerleri, kargo sağlayıcısı, muhasebe sistemleri ve başka operasyon araçları olabilir.
Net mimari olmadan her yeni bağlantı karmaşıklığı artırır.
Her veri türünün hangi sistem tarafından yönetileceğini belirleyin
API kodu yazmadan önce her önemli veri alanı için şu soru yanıtlanmalıdır:
Ana veri kaynağı hangi sistemdir?
Örneğin:
| Veri | Olası ana kaynak |
|---|---|
| Ürün kodu / SKU | ERP |
| Barkod | ERP |
| Ürün içeriği | Shopify veya PIM |
| Satış fiyatı | ERP veya ticari sistem |
| Kullanılabilir stok | ERP / WMS |
| E-ticaret siparişi | Shopify |
| Gönderi durumu | ERP / WMS / lojistik sistemi |
| Takip numarası | Lojistik veya ERP |
| Müşterinin e-ticaret verileri | Shopify |
Kesin yanıt şirketten şirkete değişir.
Önemli olan, iki sistemin tanımlı bir kural olmadan aynı alanı sürekli birbirinin üzerine yazmamasıdır.
Shopify ERP’de bir değeri güncelliyor ve ERP hemen farklı sürümü Shopify’a gönderiyorsa kontrolsüz senkronizasyon döngüsü oluşabilir.
Amaç “her yerde çift yönlü senkronizasyon” değildir.
Amaç kontrollü yönlerle net veri sorumluluğudur.
Ürün senkronizasyonu SKU eşleştirmesinden fazlasını gerektirir
SKU, Shopify ile ERP arasında sık kullanılan ortak tanımlayıcıdır.
Bu çalışabilir; ancak sistemler arasındaki tek kalıcı ilişki olarak otomatik kabul edilmemelidir.
SKU’lar değişebilir. Ürün yapıları yeniden düzenlenebilir. Varyantlar bölünebilir veya birleştirilebilir.
Olgun entegrasyon, genellikle Shopify ürün veya varyant kimliğiyle ERP’deki karşılığı arasında kalıcı eşleştirme tutar.
Böylece ticari alanlar daha sonra değişse bile sistemler aynı ürünü tanımaya devam eder.
Büyük kataloglarda ilk senkronizasyon da günlük güncellemelerden farklı ele alınmalıdır.
Shopify, her şeyi normal sayfalanmış API istekleriyle taşımak yerine büyük veri kümelerini eşzamansız işlemek için Bulk Operations sunar.
Makul bir mimari şu yapıyı kullanabilir:
İlk yükleme → Toplu işlem
Günlük değişiklikler → Artımlı senkronizasyon
Dönemsel kontrol → Tam mutabakat
Son adım özellikle önemlidir.
Güvenilir bir entegrasyon bile her artımlı olayın sonsuza kadar kusursuz işlendiğini varsaymamalıdır.
Mimari sorunların ilk görünür olduğu alan genellikle stoktur
Birden fazla depo, mağaza veya satış kanalı devreye girene kadar stok senkronizasyonu basit görünür.
Shopify stoku konuma göre modeller. Bir stok kaleminin farklı konumlarda farklı seviyeleri olabilir. Shopify; kullanılabilir, eldeki, gelen ve taahhüt edilmiş miktarlar gibi durumları ayırır.
Bu yüzden ERP entegrasyonu yalnızca şunu sormamalıdır:
“Stok kaç?”
Şunu sormalıdır:
“Hangi konumlardan, ne kadar ürün gerçekten çevrimiçi satılabilir?”
İşletmeye göre kullanılabilir e-ticaret stoku kavramsal olarak şöyle hesaplanabilir:
Fiziksel stok − Rezerve stok − Güvenlik stoku = Satılabilir stok
Kesin formül Shopify’a değil, satıcının operasyon kurallarına aittir.
Entegrasyon katmanı bu kuralları Shopify’ın satışa sunması gereken miktara çevirmelidir.
İşletmenin mağazaları ve depoları varsa ERP depo kodları ile Shopify Locations arasında açık eşleştirme gerekir.
Aksi hâlde teknik olarak başarılı stok senkronizasyonu ticari açıdan yanlış sonuç üretebilir.
Siparişler tek API olayı olarak değil, yaşam döngüsü olarak tasarlanmalıdır
Shopify siparişi ERP’ye gönderdiğinde sipariş süreci bitmez.
Gerçek yaşam döngüsü şunları içerebilir:
Sipariş oluştu → Ödeme onaylandı → ERP kaydı oluşturuldu → Depo tahsisi → Gönderi → Takip → Kısmi karşılama → İptal → İade → Para iadesi
Farklı işletmeler bu aşamaların sorumluluğunu farklı sistemlere verir.
Entegrasyon mimarisi hangi olayın hangi yönde aktarılacağını tanımlamalıdır.
Örneğin:
Shopify → ERP
- Sipariş
- Sipariş karşılama için gerekli müşteri bilgileri
- Teslimat adresi
- Ödeme durumu
- Sipariş kalemleri ve indirimler
ERP / WMS / Lojistik → Shopify
- Sipariş karşılama durumu
- Gönderilen miktarlar
- Takip numarası
- Taşıyıcı bilgisi
Shopify’ın sipariş karşılama modeli, ürünlerin ayrı veya farklı konumlardan gönderilmesi dahil aynı sipariş için birden fazla karşılama kaydını destekler.
Bu, bölünmüş gönderi kullanan markalar için önemlidir.
Her siparişin tek gönderisi olduğunu varsayan entegrasyon, basit test ortamında çalışıp gerçek depo operasyonu başladığında başarısız olabilir.
Mükerrer sipariş muhasebe değil, entegrasyon sorunudur
En ciddi entegrasyon hatalarından biri aynı işlemi birden fazla oluşturmaktır.
Sipariş ERP’ye başarıyla iletilmişken entegrasyon beklenen yanıtı alamayabilir. Aynı istek kontrolsüz tekrarlanırsa ERP’de ikinci sipariş oluşabilir.
Bu nedenle entegrasyon mimarisi idempotency ve kalıcı işlem kimliklerine ihtiyaç duyar.
Sistem şunu anlayabilmelidir:
“Bu Shopify siparişini zaten işledim.”
Böylece başarısız işlemi mükerrer kayıt oluşturmadan güvenle yeniden deneyebilir.
Shopify API’leri de güvenli yeniden denemenin önemli olduğu işlemlerde idempotency mekanizmaları kullanır.
Kullanılan ERP ne olursa olsun aynı ilke entegrasyon katmanında da bulunmalıdır.
Webhook faydalıdır; ancak tek başına entegrasyon mimarisi değildir
Shopify webhook’ları olay bazlı entegrasyonların önemli parçasıdır.
Örneğin entegrasyon Shopify’a sürekli değişiklik olup olmadığını sormak yerine sipariş oluşturulduğunda veya güncellendiğinde tepki verebilir.
Ancak webhook genellikle tüm işlem mimarisi olarak değil, bir iş yapılması gerektiğinin sinyali olarak ele alınmalıdır.
Shopify webhook isteklerinin hızla kabul edilmesini ve uzun süren işlerin istek dışına taşınmasını önerir. Başarısız webhook teslimleri yeniden denenir; ancak bu yalnızca sınırlı süre devam eder.
Daha dayanıklı akış şöyledir:
Shopify webhook → Kuyruk → Entegrasyon işleyicisi → ERP → Sonuç/kayıt
ERP geçici olarak erişilemezse olay kaybolmak yerine işlem mimarisinde kalır.
Entegrasyon daha sonra yeniden deneyebilir.
Bu, şu akıştan oldukça farklıdır:
Shopify webhook → ERP’yi doğrudan çağır → Çalışmasını um
Doğru entegrasyon katmanı hata kuyruğu gerektirir
Her entegrasyon zaman zaman hata verir.
Önemli soru hata olup olmayacağı değildir.
Şudur:
Hata olduğunda sistem ne yapar?
Olgun entegrasyon katmanı başarısız işlemleri görünür kılmalıdır.
Örneğin:
Sipariş #10582 → ERP zaman aşımı → Yeniden deneme planlandı
veya:
Varyant ABC-42 → ERP ürün eşleştirmesi eksik → Manuel inceleme gerekli
Operatör şunları anlayabilmelidir:
- Neyin başarısız olduğu,
- Ne zaman olduğu,
- Neden olduğu,
- Kaç kez yeniden denendiği,
- Sonunda başarılı olup olmadığı,
- Manuel müdahale gerekip gerekmediği.
Bu katman olmadan entegrasyon hataları çoğunlukla çok sonra operasyon şikâyetleri olarak ortaya çıkar:
“Bu sipariş neden eksik?”
“Bu ürün internette neden stokta yok?”
“Bu gönderi neden güncellenmedi?”
O sırada soruna neden olan teknik olayın üzerinden saatler veya günler geçmiş olabilir.
Yeniden deneme ve manuel senkronizasyon baştan tasarlanmalıdır
Otomatik yeniden deneme; ağ sorunları veya geçici ERP kesintisi gibi durumlarda faydalıdır.
Ancak her hata sonsuza kadar yeniden denenmemelidir.
Eksik ürün eşleştirmesi 30 API çağrısından sonra kendiliğinden düzelmez.
Entegrasyon şu ayrımı yapmalıdır:
Geçici hata → Yeniden dene
ve
Veri/yapılandırma hatası → Manuel müdahale
Ayrıca tüm kataloğu veya sipariş geçmişini yeniden işlemek zorunda kalmadan seçili kayıtların tekrar senkronize edilmesine izin vermelidir.
Pratik bir operasyon paneli şu işlemleri sunabilir:
Yeniden dene
Ürünü yeniden senkronize et
Siparişi yeniden senkronize et
Gönderilen veriyi görüntüle
Hatayı görüntüle
Amaç kullanıcılara karmaşık teknik panel vermek değildir.
Entegrasyon sorunlarını operasyonel olarak yönetilebilir kılmaktır.
Dönemsel mutabakat, gerçek zamanlı senkronizasyon kadar önemlidir
Gerçek zamanlı senkronizasyon değişiklikler hızla aktarıldığı için güven verir.
Ancak hız tutarlılığı garanti etmez.
Ürün, stok ve sipariş gibi önemli veri kümelerinde entegrasyon sistemleri dönemsel olarak karşılaştırmalıdır.
Örneğin:
ERP’de 12.452 aktif SKU
Shopify’da 12.449 eşleştirilmiş varyant
Arada üç kayıt fark vardır.
Mutabakat süreci, müşteri veya depo çalışanı fark etmeden bu kayıtları belirleyebilir.
Aynı ilke stok için de geçerlidir.
Artımlı stok güncellemeleri sürekli çalışırken zamanlanmış mutabakat, Shopify ile kaynak sistemin hâlâ aynı veriyi taşıdığını dönemsel olarak doğrular.
Bu, veri taşımak ile entegrasyon işletmek arasındaki en büyük farklardan biridir.
Entegrasyon katmanı Shopify API sınırlarına ve mimarisine uymalıdır
Profesyonel entegratör, Shopify’ın uygulamalardan platformuyla nasıl etkileşim kurmasını beklediğini de anlamalıdır.
Büyük veri kümeleri küçük tekil güncellemeler gibi ele alınmamalıdır.
Yüksek hacimli işler için toplu işlemler vardır. Webhook’lar değişiklik sinyali verebilir. Stok konum bazlıdır. Sipariş karşılamanın kendi yaşam döngüsü ve nesneleri vardır. API çağrıları da Shopify platform sınırları içinde tasarlanmalıdır.
Bu nedenle ERP bağlayıcısı, tüm mimariyi yalnızca ERP API’sinin işleyişine göre belirlememelidir.
Her iki tarafı da anlamalıdır.
ERP entegrasyonuna başlamadan önce neleri tanımlamalısınız?
Geliştirmeden önce şu soruları yanıtlamanızı öneririz:
- Ürünleri hangi sistem yönetiyor?
- Ürün içeriğini hangi sistem yönetiyor?
- Fiyatlar nerede yönetiliyor?
- Tam olarak hangi miktar satılabilir stok sayılıyor?
- ERP depoları Shopify Locations ile nasıl eşleşiyor?
- Sipariş ERP’ye ne zaman aktarılmalı?
- İptaller nasıl işleniyor?
- Kısmi gönderiler nasıl temsil ediliyor?
- Takip bilgisi nereden geliyor?
- İadeler ve para iadeleri nasıl senkronize ediliyor?
- Mükerrer işlemler nasıl önleniyor?
- Sistemlerden biri erişilemezse ne oluyor?
- Entegrasyon hatalarını kim görüyor?
- Tek kayıt manuel yeniden senkronize edilebilir mi?
- Shopify ve ERP dönemsel olarak nasıl karşılaştırılacak?
Bu kararlar net değilse önce entegrasyon ürünü seçmek temel sorunu nadiren çözer.
Entegratör yalnızca bağlayıcı değil, operasyonel katmandır
Bizim için entegratörü düşünmenin en yararlı yolu şudur:
Sistemler arasındaki akışı kontrol eder.
Verinin nereden geldiğini bilir.
Nereye gitmesi gerektiğini bilir.
Aynı işlemin iki kez işlenmesini önler.
Geçici hataları yeniden dener.
Kalıcı hataları görünür kılar.
Farklı sistemler arasındaki eşleştirmeleri tutar.
Shopify, ERP ve operasyonun geri kalanının hâlâ uyumlu olduğunu ekibin doğrulamasına yardımcı olur.
Bu, yalnızca şunu söylemekten çok farklıdır:
“Shopify ERP’ye bağlı.”
Digimaps yaklaşımı
Entegrasyon projelerinde veri sorumluluğunu, operasyonel akışları ve hata senaryolarını geliştirme başlamadan tanımlamayı tercih ederiz. Doğru soru yalnızca hangi ERP’nin Shopify’a bağlanacağı değil; veri sistemler arasında aktarıldığında veya aktarılamadığında tüm e-ticaret operasyonunun nasıl davranacağıdır.
Shopify–ERP entegrasyonu planlıyorsanız uygulamadan önce veri akışını ve operasyonel mimariyi birlikte inceleyebiliriz.