ERP ile e-ticaret platformunu aynı veri akışında buluşturmak, yalnızca teknik bir bağlantı kurmak anlamına gelmez. Asıl amaç; siparişlerin gecikmeden ERP'ye düşmesi, stokların kanal bazında tutarlı görünmesi, fiyatların her mağazada aynı kuralla güncellenmesi ve ekiplerin Excel üzerinde manuel düzeltme yapmak zorunda kalmamasıdır. İyi kurgulanmış bir erp e ticaret entegrasyonu, operasyonu hızlandırır, hata oranını düşürür ve büyüme dönemlerinde sistemi daha öngörülebilir kılar.
Pratikte en sık karşılaşılan sorunlar üç başlıkta toplanır: sipariş senkronizasyonu, stok doğruluğu ve fiyat yönetimi. Bir mağazada satılan ürünün diğer kanalda hâlâ stokta görünmesi, ERP'deki kampanya fiyatının pazaryerine geç yansıması ya da iade edilen siparişin finans tarafında kapanmaması, kısa sürede müşteri deneyimini olumsuz etkiler. Bu rehberde entegrasyonun nasıl kurulacağını, hangi veri modelinin seçileceğini, API ve kuyruk mantığını, test sürecini ve canlıya geçişte dikkat edilmesi gereken detayları adım adım ele alıyoruz.
ERP e-ticaret entegrasyonu tam olarak neyi kapsar?
Temel seviyede entegrasyon denince akla önce sipariş aktarımı gelir. Oysa kapsam bundan daha geniştir. En az 5 veri alanı birlikte ele alınmalıdır: ürün kartları, fiyatlar, stoklar, siparişler ve müşteri verisi. Pek çok projede buna fatura, kargo bilgisi, iade ve muhasebe hareketleri de eklenir.
Örnek bir senaryo düşünelim: Shopify veya WooCommerce üzerinden gelen sipariş, en fazla 30-60 saniye içinde ERP'ye düşer. ERP siparişi onaylar, stok rezervasyonu açar, fatura numarası üretir. Ardından kargo kodu yeniden e-ticaret sistemine yazılır. Müşteri paneli ve e-posta akışı da aynı bilgiyle güncellenir. Entegrasyonun başarılı sayılabilmesi için bu döngünün tek yönlü değil, çift yönlü işlemesi gerekir.
En çok senkronize edilen veri kümeleri
- Ürün ana verisi: SKU, barkod, varyant, kategori, vergi oranı
- Stok: depo bazlı adet, rezerve stok, kritik eşik
- Fiyat: liste fiyatı, kampanya fiyatı, bayi fiyatı, para birimi
- Sipariş: satır detayları, ödeme durumu, teslimat adresi
- İade ve iptal: ters stok hareketi, iade nedeni, finans kapanışı
Buradaki kritik karar, hangi sistemin “master” olacağıdır. Çoğu B2B ve çok depolu yapıda ürün, stok ve fiyat için ana sistem ERP'dir. Kampanya içerikleri, vitrin düzeni ve bazı müşteri deneyimi alanları ise e-ticaret tarafında yönetilir.
Entegrasyon öncesi veri ve süreç analizi nasıl yapılır?
Canlı bağlantı kurulmadan önce en az 1 veri eşleştirme dokümanı hazırlanmalıdır. Bu dokümanda ERP alanları ile e-ticaret alanları bire bir yazılır. Örneğin ERP'deki product_code alanı, e-ticaret tarafında sku ile mi eşlenecek? Barkod tekil mi? Varyantlar ERP'de renk-beden matrisi olarak mı tutuluyor, yoksa ayrı ürün kartları mı var? Bu sorular ilk haftada netleşmezse proje uzar.
İkinci adım süreç haritasıdır. Sipariş oluşturulduğunda kim ne yapıyor? Ödeme başarısız olursa ERP'ye kayıt açılacak mı? Kısmi sevkiyat mümkün mü? 2 depodan ürün çıkıyorsa e-ticaret tarafında tek sipariş nasıl bölünecek? Bu tür akışlar yazılmadan kodlamaya geçmek, ileride çok sayıda istisna doğurur.
Analiz aşamasında kontrol edilmesi gereken somut başlıklar
- Tekil kimlikler: SKU, ürün ID, müşteri ID, sipariş numarası çakışıyor mu?
- Zamanlama: Veriler anlık mı akacak, yoksa 5 dakikalık batch yeterli mi?
- Vergi ve para birimi: KDV dahil-hariç mantığı bütün sistemlerde aynı mı?
- Stok kuralı: Eksi stok açılacak mı, rezervasyon hangi adımda düşecek?
- İade akışı: İade kabulü, yeniden stoğa giriş ve finans kaydı eşleşiyor mu?
Buradaki amaç kusursuz bir teori üretmek değil, ilk sürümün kapsamını kontrollü biçimde belirlemektir. Birçok işletme için faz 1'de sipariş + stok + fiyat entegrasyonu yeterlidir. Sadakat puanı, bayi iskonto matrisi veya çapraz depo optimizasyonu ise ikinci faza bırakılabilir.
Doğru entegrasyon mimarisi nasıl seçilir?
Tek bir yöntem her işletmeye uymaz. Küçük hacimli yapılarda doğrudan API entegrasyonu yeterli olabilir. Günlük 50-100 sipariş alan bir mağaza ile günde 5.000 sipariş işleyen bir yapı aynı mimariyle yönetilmemelidir. İş yükü arttıkça hata toleransı, kuyruk yapısı ve izlenebilirlik daha kritik hale gelir.
1) Doğrudan API entegrasyonu
ERP ve e-ticaret sistemi birbirinin API'sine doğrudan çağrı yapar. Kurulumu görece hızlıdır. Basit akışlar için uygundur. Dezavantajı ise taraflardan biri yavaşladığında diğerinin de etkilenmesidir.
2) Middleware veya iPaaS katmanı
Araya bir entegrasyon servisi girer. Dönüşüm, loglama, hata yönetimi ve yeniden deneme burada yürütülür. Farklı pazaryerleri, web sitesi ve ERP aynı merkezde toplanacaksa bu model daha sağlıklı olur.
3) Mesaj kuyruğu destekli olay mimarisi
Sipariş oluştuğunda bir olay yayınlanır. ERP, WMS, fatura servisi ve bildirim sistemi bu olayı kendi akışında tüketir. Özellikle pik saatlerde avantaj sağlar. Örneğin saat 20:00-21:00 arasında 800 sipariş geldiğinde sistemin tek seferde kilitlenmesi yerine, işlerin kuyrukta sıraya alınması mümkün olur.
Teknik tarafta sık kullanılan yaklaşım, API + kuyruk hibritidir. Sipariş kabulü anlık yapılır, daha ağır işlemler arka planda işlenir. Aşağıdaki örnek, oldukça sade bir sipariş olayını gösterir:
{
"event": "order.created",
"orderNo": "ET-2026-10452",
"channel": "website",
"items": [
{"sku": "TSHIRT-BLK-M", "qty": 2, "price": 499.90}
],
"customerId": "CUST-8841",
"createdAt": "2026-07-19T10:45:00Z"
}Bu yapıda sipariş numarasının tekilliği, tekrar eden çağrıların nasıl ele alınacağı ve başarısız durumlarda yeniden işleme kuralları en baştan tanımlanmalıdır.
Sipariş, stok ve fiyat akışları nasıl kurgulanır?
Entegrasyonun kalbi bu üç akıştır. Her biri için zamanlama, kaynak sistem ve hata davranışı açık biçimde tanımlanmalıdır.
Sipariş akışı
İdeal akışta e-ticaret sistemi siparişi oluşturur, ödemeyi doğrular ve ERP'ye iletir. ERP siparişi kabul ettikten sonra bir referans numarası döner. Eğer aynı sipariş ikinci kez gönderilirse sistem yeni kayıt açmamalıdır. Bu noktada idempotency kuralı kritik hale gelir. Aynı orderNo için ikinci çağrı geldiğinde kayıt güncellenmeli ya da güvenli biçimde reddedilmelidir.
Stok akışı
Stok her zaman en hassas konudur. Özellikle 2 veya daha fazla satış kanalı varsa, stok güncelleme sıklığı iş sonucunu doğrudan etkiler. Düşük hacimli yapılarda 5 dakikalık senkron kabul edilebilir. Hızlı dönen ürünlerde ise olay bazlı güncelleme tercih edilir. Depo bazlı stok tutuluyorsa, e-ticaret tarafında hangi deponun satışa açık olduğu da net olmalıdır.
Fiyat akışı
Fiyat yönetimi yalnızca tutar alanı taşımaktan ibaret değildir. Geçerlilik tarihi, müşteri grubu, kanal indirimi ve KDV gösterimi de işin parçasıdır. ERP'de gece 00:00'da başlayacak kampanyanın web sitesine 00:17'de yansıması sorun yaratır. Bu yüzden zamanlanmış fiyat yayınları için job planlaması ve geri alma senaryosu önceden tanımlanmalıdır.
Gerçek bir örnek üzerinden gidelim: ERP'de 12.000 SKU bulunan bir yapı düşünün. Bunların yalnızca 1.800 adedi online satışa açık olabilir. Entegrasyon katmanı tüm ürünleri körlemesine göndermek yerine, “yayında” işaretli ürünleri ve değişen kayıtları taşımalıdır. Bu yaklaşım veri trafiğini azaltır, senkron süresini de kısaltır.
Teknik kurulumda güvenlik, loglama ve hata yönetimi neden kritik?
Entegrasyon projeleri çoğu zaman ilk günlerde çalışıyor gibi görünür. Sorunlar genellikle 3. hafta civarında, istisnalar çoğaldığında ortaya çıkar. API time-out, eksik alan, iptal edilen sipariş, mükerrer webhook, bağlantı kopması. Bunların her biri için ölçülebilir bir operasyon modeli gerekir.
Minimum teknik kontrol listesi
- Kimlik doğrulama: API key, OAuth2 veya imzalı istekler
- Loglama: Her istek için zaman damgası, payload özeti, yanıt kodu
- Yeniden deneme: 3 deneme, artan bekleme süresi gibi net kural
- Alarm: 15 dakika boyunca sipariş akmıyorsa bildirim üretme
- Versiyonlama: API değişikliklerinde v1, v2 ayrımı
Özellikle kişisel veri işleniyorsa log içine kart bilgisi veya gereksiz müşteri verisi yazılmamalıdır. KVKK uyumu burada operasyonel bir detay değil, bir tasarım kriteridir. Sipariş payload'ında yalnızca gerekli alanları taşımak daha güvenli bir yaklaşımdır.
Ayrıca test ortamı ile canlı ortamın ayrılması gerekir. Sandbox olmadan yapılan entegrasyonlar, yanlış stok düşümü veya test siparişlerinin muhasebeye gitmesi gibi problemlere yol açabilir. En az 10-15 uç durum senaryosu için test verisi hazırlanması faydalıdır: kısmi iptal, eksik adres, tükenen ürün, fiyat değişimi sırasında sipariş, başarısız webhook gibi.
Canlıya geçiş planı ve başarı ölçümü nasıl yapılmalı?
Başarılı bir entegrasyon, kodun deploy edilmesiyle değil; operasyonun sorunsuz akmasıyla ölçülür. Bu nedenle canlıya geçişin tek adımda yapılması gerekmez. Önce sınırlı SKU grubu, tek depo veya tek satış kanalı ile başlamak çoğu durumda daha güvenlidir.
Önerilen geçiş sırası
- Ürün ve stok senkronunu test ortamında doğrula
- Sipariş akışını sahte ödeme ile dene
- Canlıda 20-50 ürünle pilot yayın aç
- İlk 7 gün boyunca log ve hata oranını günlük izle
- Ardından tüm katalog ve kanallar için kapsamı genişlet
Başarıyı ölçmek için bir gösterge seti belirlemek gerekir. Örneğin siparişin ERP'ye düşme süresi, stok güncelleme gecikmesi, başarısız API çağrı oranı, manuel müdahale gerektiren kayıt sayısı gibi metrikler takip edilebilir. Buradaki amaç etkileyici rakamlar üretmek değil, iyileştirme alanlarını görünür hale getirmektir.
İyi tasarlanmış bir erp e ticaret entegrasyonu, ekiplerin işini sadeleştirir. Siparişler tek ekranda izlenir, stok gerçeğe daha yakın görünür, fiyat yönetimi dağınık tablolardan çıkar. Teknik seçimler kadar süreç disiplini de sonucu belirler. Analiz dokümanı, veri eşleştirme, hata yönetimi ve kademeli canlıya geçiş, projenin sağlam zeminini oluşturur. Entegrasyonun amacı daha fazla araç kullanmak değil; daha az manuel iş ve daha tutarlı veri üretmektir.
