E-Ticaret Siparişini ERP'ye Aktarmak: Mimari Kararlar ve Tipik Hatalar

Giriş: Sipariş Geldi, ERP'ye Düşmedi — Tanıdık Senaryo

Pazar günü saat 22:00. Müşteriniz tişört siparişi verdi, ödeme aldı, kargoyu bekliyor. Pazartesi sabah ofise geldiniz, ERP'de sipariş yok. Aynı ürün hem web sitenizde hem de Trendyol'da satılmış, stoğunuz 1 adetti. İki müşteriye aynı ürünü sattınız. İptal etmek zorundasınız, ceza puanı alacaksınız.

Bu senaryo, e-ticaret ERP entegrasyonu kurarken mimari kararlar yanlış alındığında yaşanır. Entegrasyon sadece "sipariş geldi, ERP'ye aktar" mantığı değil. Hangi sistemin neyi yöneteceği, veri senkronizasyonunun yönü, ağ kesintilerinde bütünlük koruması, iptal-iade akışı gibi kararlar işinizi ya rahatlatır ya felç eder.

Bu yazı, kodda değil stratejide yapılan hataları teknik ama anlaşılır bir dille anlatıyor. Eğer WooCommerce, Ticimax, N11 veya Hepsiburada gibi kanallarınız varsa ve Logo Tiger, Mikro, Netsis gibi bir ERP kullanıyorsanız, bu rehber size zaman kazandıracak.

Tek Doğruluk Noktası: Stok Bakiyesi Nerede Durmalı?

E-ticaret ERP entegrasyonunda en kritik mimari karar: stok bakiyesinin hangi sistemde tutulacağı. Çoğu proje burada yanılıyor.

Senaryo 1: ERP Master, E-Ticaret Slave

Üretim yapıyorsanız, depoya mal girişi ERP üzerinden oluyorsa, muhasebeniz ERP'de tutuluyorsa — stok gerçeği ERP'de olmalı. E-ticaret siteniz her gece (veya her saat) ERP'den stok çeker, kendi veritabanını günceller. Satış olunca sipariş ERP'ye düşer, ERP stoktan düşüm yapar.

Avantajı: Deponuzdaki fiziksel gerçekle uyumlusunuz. Faturalaşma doğru çalışır.

Dezavantajı: ERP kapalıysa veya güncellemesi gecikmişse, sitede yanlış stok gösterebilirsiniz. Bunu kuyruk mimarisiyle (aşağıda anlatacağız) çözersiniz.

Senaryo 2: E-Ticaret Master, ERP Raporlama Amaçlı

Dropshipping veya sanal mağaza modelindeyseniz, stoğunuz tedarikçinizin API'sinden geliyorsa — e-ticaret platformu master olabilir. ERP sadece faturalaşma ve raporlama için sipariş kaydeder.

Bu modelde stok senkronizasyonu tersine döner: tedarikçi API'si → e-ticaret → ERP. Ama dikkat: aynı ürünü birden fazla kanalda satıyorsanız (web + Trendyol + Hepsiburada), stok rezervasyonu merkezi bir servis olmalı. Aksi halde yine aşırı satış riski var.

Pratik Karar: Fiziksel Stok Varsa ERP Master

Kendi deposu olan firmalarda ERP master seçimi genellikle daha az soruna yol açar. Stok senkronizasyonu her 15 dakikada bir ERP'den e-ticarete doğru olur. Sipariş aktarımı ise tersine: e-ticaret → kuyruk → ERP.

Stok Senkronizasyonu: Sıklık ve Yön Stratejisi

Stok senkronizasyonunda iki soru önemli: ne sıklıkla ve hangi yöne.

Anlık mı, Batch mi?

Çoğu e-ticaret sitesi "her 30 dakikada stok güncelle" mantığıyla çalışır. Bu çoğu sektor için yeterli. Ama yüksek cirolu, düşük stoğu olan sektörlerde (elektronik aksesuar, kampanyalı ürünler) 30 dakika bile tehlikelidir.

Burada webhook bazlı anlık senkronizasyon düşünülebilir: ERP'de stok değiştiğinde (satış, iade, depo girişi), ERP bir sinyal gönderir, e-ticaret anında günceller. Ama dikkat: her ERP bunu desteklemez. Ürününüzün değişiklik bildirimi gönderip gönderemediği kurulumda teyit edilir. Bildirim yoksa çözüm, belirli aralıklarla okuma yapmaktır.

Çift Yönlü Senkronizasyon Tuzağı

Bazı yazılımcılar "hem ERP'den stok gelsin, hem e-ticaretten ERP'ye stok yazılsın" mantığı kurar. Bu sonsuz döngü tuzağıdır. ERP stoğu 10'a çeker, e-ticaret 8 yazar, ERP tekrar okur, döngü başlar. Mutlaka tek yön olmalı.

Bizim önerimiz:

• Stok okuma: ERP → E-ticaret (scheduled, her 15-60 dakika)
• Sipariş yazma: E-ticaret → ERP (event-based, sipariş onaylanınca)

Sipariş Aktarımında Mükerrer Kayıt Sorunu ve Idempotent Yazma

E-ticaret sitenizden sipariş geldi, ERP'ye aktarmak için API çağrısı yaptınız. Ağ kesildi, timeout aldınız. Sipariş ERP'de oluştu mu, oluşmadı mı bilmiyorsunuz. Tekrar gönderirseniz iki sipariş kaydı mı oluşur?

Bu senaryo teorik değil — gerçek hayatta sık yaşanır. Çözümü idempotent yazma:

Unique Key ile Koruma

Her siparişe e-ticaret tarafında benzersiz bir kimlik verin. Entegrasyon katmanı, ERP'ye gönderdiği her siparişi bu kimlikle kendi tablosuna kaydeder. Aynı kimlikle ikinci bir istek geldiğinde ERP'ye yeniden yazmaz, daha önce oluşan kaydın numarasını döner.

Örnek akış:

1. Sipariş #12345, unique_id: "WT-2025-12345"
2. ERP'ye gönder → timeout
3. Tekrar gönder → entegrasyon katmanı kendi kaydına bakar: "WT-2025-12345 zaten işlendi, fiş numarası 88776"
4. E-ticaret fişNo'yu kaydeder, mükerrer oluşmaz

Kuyruk Sistemi ile Retry Mekanizması

ERP kapalı olabilir, bakımda olabilir, lisans sorunu yaşayabilir. O an sipariş aktarılamazsa ne olacak? İki seçenek:

Kötü yöntem: Sipariş e-ticaret veritabanında "beklemede" kalır, manuel müdahale gerekir.

Doğru yöntem: Sipariş bir kuyruk sistemine (RabbitMQ, Redis Queue, AWS SQS) gönderilir. Kuyruk işleyicisi ERP'ye yazmayı dener, başarısız olursa 5 dakika sonra tekrar dener. Başarılı olana kadar (veya maksimum deneme sayısına ulaşana kadar) devam eder.

Böylece pazar günü gece gelen sipariş, pazartesi sabah ERP açıldığında otomatik aktarılır. Siz müdahale etmezsiniz.

Stok Kodu Eşlemesi: Kodda Gömülü Değil, Yönetilebilir Tablo

E-ticaret sitenizdeki ürün kodu "TSR-001", ERP'deki stok kodu "TS.KIRMIZI.M". Bu eşleşmeyi nasıl yöneteceksiniz?

Yanlış Yöntem: Kodda Sabit Tanımlama

if ($urunKodu == 'TSR-001') {
    $erpKodu = 'TS.KIRMIZI.M';
}

Yeni ürün eklediğinizde yazılımcı çağırırsınız. Maliyet artar, esneklik kaybolur.

Doğru Yöntem: Mapping Tablosu

Veritabanında product_mapping tablosu:

ecommerce_sku	erp_sku	active
TSR-001	TS.KIRMIZI.M	1
TSR-002	TS.MAVI.L	1

Yeni ürün eklediğinizde admin panelinden eşleştirme yaparsınız. Geliştirici gerekmez. ERP'den ürün listesi çekilip açılır listeden seçtirilirse eşleştirme daha da kolaylaşır.

Bu tablo aynı zamanda çoklu kanal senaryosunda hayat kurtarır. Trendyol, Hepsiburada, N11 — her birinin kendi ürün kodu var, hepsi aynı ERP koduna eşleniyor.

İptal ve İade Akışı: En Sık Atlanan Tasarım

E-ticaret ERP entegrasyonu kurarken herkes sipariş aktarımını düşünür. Ama iptal ve iade akışını tasarlayanlar azınlıkta. Sonra bu senaryolar elle çözülür, hata oranı artar.

İptal Senaryoları

1. Müşteri sipariş verdikten 10 dakika sonra iptal etti: Sipariş henüz ERP'ye düşmemişse kolay — e-ticaret veritabanında "cancelled" işaretle, ERP'ye gönderme. Ama zaten gönderildiyse? ERP'de de iptal fişi mi kesilmeli, yoksa orijinal fiş silinmeli mi? Bu kararı baştan almalısınız.

2. Kargo iade geldi: ERP'de iade fişi oluşturulmalı, stok tekrar artmalı, fatura iptal/iade faturası kesilmeli. Bunu otomatikleştirmezseniz muhasebe-depo uyumsuzluğu yaşarsınız.

Mimari Öneri: Durum Senkronizasyonu

Sipariş aktarımı tek yönlü değil, durum güncellemesi çift yönlü olmalı:

• E-ticaret → ERP: "Sipariş iptal edildi" (API call veya kuyruk)
• ERP → E-ticaret: "Fatura kesildi", "Kargoya verildi" (webhook veya scheduled check)

Böylece her iki sistem de güncel kalır. Müşteri admin panelinde "ERP Fiş No: 12345, Durum: Fatura Kesildi" görür.

Kargo ve Fatura Zinciri: ERP ile E-Ticaret Uyumu

Sipariş aktarıldı, ERP'de fiş oluştu. Sırada ne var?

Fatura Entegrasyonu

Eğer e-Arşiv/e-Fatura kesiyorsanız, genelde ERP üzerinden kesilir. ERP fatura kestikten sonra:

• Fatura numarası e-ticarete dönmeli
• Müşteriye mail gönderilmeli (ERP'den veya e-ticaretten — kararlaştırın)
• E-ticaret admin panelinde "Fatura: Kesildi (No: 2025000123)" görünmeli

Kargo Entegrasyonu

Kargo şirketi entegrasyonu (MNG, Aras, Yurtiçi) genelde e-ticaret tarafında. Ama bazı firmalar ERP'den de kargo oluşturuyor. İkisini birden kullanıyorsanız, kargo takip numarası her iki tarafa da yazılmalı.

Örneğin:

1. E-ticaret kargo talebi oluşturur → MNG API → takip no: 123456789
2. Bu numara ERP'deki sipariş fişine de yazılır
3. ERP'den sevkiyat raporu çekildiğinde kargo no görülür

Bu detay gibi görünür ama operasyonel sıkıntılarda devreye girer.

Kuyruk Mimarisi: ERP Kapalıyken Satış Durmasın

ERP lisans sorunu yaşadı, sunucu bakımda, veritabanı yavaş — ne olursa olsun, e-ticaret sitesi satış yapmaya devam etmeli.

Asenkron Mimari

Sipariş onaylandığında hemen ERP'ye yazmaya çalışmayın. Şu akışı kurun:

1. Sipariş onaylandı → e-ticaret veritabanına "pending_erp" durumunda kaydet
2. Kuyruk sistemine mesaj gönder: {order_id: 12345, action: 'create'}
3. Arka planda çalışan worker servisi kuyruğu okur, ERP'ye aktarmayı dener
4. Başarısız olursa exponential backoff ile tekrar dener (5 dk, 15 dk, 1 saat...)
5. Başarılı olunca durumu "synced_erp" yapar, fiş numarasını kaydeder

Hangi Kuyruk Teknolojisi?

• Redis Queue: Basit, hızlı, orta ölçek için ideal
• RabbitMQ: Daha kompleks, yüksek hacim ve hata toleransı gerekiyorsa
• AWS SQS: Cloud tabanlı, ölçeklenebilir, sunucu yönetimi gerektirmez

Orta ölçekli projelerde Redis Queue çoğu zaman yeterlidir; kurulumu kolaydır ve yaygın web altyapılarıyla uyumludur.

Performans ve Ölçeklenebilirlik Notları

Batch İşlemler

Günde 500+ sipariş alıyorsanız, her siparişi tek tek ERP API'sine göndermek yerine batch (toplu) gönderim düşünün. Örneğin her 5 dakikada bir 20 siparişi tek API call'da gönderin. ERP yükü azalır.

Ama dikkat: batch içinde bir sipariş hata verirse, tamamı mı reddedilecek yoksa kısmi başarı mı kabul edilecek? Bunu baştan tasarlayın.

Loglama ve İzleme

Entegrasyon sorunlarını tespit etmek için detaylı log şart:

• Hangi sipariş ne zaman kuyruğa eklendi
• ERP'ye gönderim denemeleri (request/response)
• Hata mesajları ve stack trace
• Başarılı aktarımda fiş numarası

Bunu Elasticsearch, Grafana veya basit dosya log ile yapabilirsiniz. Önemli olan aranabilir ve tarih filtrelenebilir olması.

Sıkça Sorulan Sorular

ERP entegrasyonu ne kadar sürer?

Proje kapsamına göre değişir. Süreyi en çok şunlar belirler: hangi ERP ve hangi arayüz, arayüz erişiminin ve lisansın açılma süresi, kaç satış kanalı olduğu, iptal ve iade akışının kapsamı. Özel raporlama, çoklu depo ve pazaryeri eklendikçe süre uzar. Ücretsiz keşif görüşmesinden sonra yazılı takvim veriyoruz.

Hangi ERP sistemleriyle çalışabiliyorsunuz?

Logo, Netsis, Mikro, Zirve, ETA, Wolvox, Nebim, Luca, DİA, Paraşüt, SAP Business One ve Dynamics 365 Business Central için entegrasyon geliştiriyoruz. Hiçbirinin bayisi değiliz. Yöntem, ürünün sunduğu arayüze göre belirlenir; sipariş gibi kayıtları doğrudan veritabanına değil, ürünün resmi arayüzünden yazıyoruz. Sektöre özel bir program kullanıyorsanız önce arayüzünü birlikte inceliyoruz.

Mevcut entegrasyonumuz sorunlu, sıfırdan mı yazmak gerek?

Çoğu durumda sıfırdan yazmaya gerek yok. Önce mimari analiz yapıyoruz: hangi katman sorunlu (stok senkronizasyonu mu, sipariş aktarımı mı, kuyruk yapısı mı), sonra o bölümü refactor ediyoruz. Bazen sadece idempotent yazma eklemek veya mapping tablosu kurmak sorunu çözüyor. Detaylı inceleme sonrası önerimizi sunuyoruz.

Entegrasyon sonrası bakım gerekir mi?

ERP versiyonu güncellendiğinde veya yeni satış kanalı (pazaryeri) eklendiğinde uyarlama gerekebilir. Ayrıca yeni ürün kategorileri, özel kampanya mantıkları, kargo firma değişikliği gibi durumlarda küçük geliştirmeler yapılır. Teslim sonrası 15 gün ücretsiz hata düzeltme kapsamdadır. Sonrası için isteğe bağlı bakım sözleşmesi yapılabilir.

Fiyat nasıl belirleniyor?

Sabit fiyat, sözleşmede yazılı şekilde çalışıyoruz. Fiyat şu değişkenlere göre oluşuyor: kaç satış kanalı, hangi ERP, özel raporlama var mı, mevcut altyapı ne durumda, iptal/iade akışı otomatik mi. Ücretsiz keşif görüşmesinde ihtiyacınızı dinliyor, teknik analiz yapıyor ve net fiyat teklifi sunuyoruz. Gizli masraf veya ek ücret yok.

Canlıya geçerken satışlar durur mu?

Hayır. Entegrasyonu test ortamında kurup onaylatıyoruz. Canlıya alırken "shadow mode" kullanıyoruz: sipariş hem eski yöntemle hem yeni entegrasyonla işleniyor, ama ERP'ye sadece yeni sistem yazıyor. 24-48 saat sorunsuz çalıştığını görünce eski sistemi kapatıyoruz. Müşterileriniz etkilenmiyor.

Sonuç: Entegrasyon Mimari Karar Meselesi

E-ticaret ERP entegrasyonu sadece API çağrısı değil, mimari kararlar zinciri. Hangi sistem master, stok senkronizasyonu hangi yönde, mükerrer kayıt nasıl engellenecek, iptal-iade akışı nasıl tasarlanacak, ERP kapalıyken ne olacak — bunlar baştan doğru alınmazsa operasyonel kaosa yol açıyor.

D'Cloud Software, Mersin merkezli bağımsız bir yazılım firmasıdır. Entegrasyonu şu ilkelerle kuruyoruz: stok kodu eşlemesi yönetilebilir bir tabloda tutulur, kuyruk sayesinde ERP kapalıyken satış durmaz, idempotent yazma mükerrer kaydı önler.

Eğer siparişleriniz ERP'ye düşmüyor, stok uyumsuzluğu yaşıyor veya iptal-iade akışı elle yönetiliyorsa — sorun entegrasyon kodunda değil, mimari kararlarda. İsterseniz mevcut sisteminizi ücretsiz analiz edelim, neyin yanlış olduğunu gösterelim. Sabit fiyat teklifi veriyor, sözleşmeye yazıyoruz. İlk 15 gün ücretsiz hata düzeltme garantimiz var.

Ücretsiz keşif görüşmesi için bize ulaşabilirsiniz — WhatsApp veya web sitemizdeki iletişim formundan randevu alabilirsiniz. Doğru mimariye geçmek, size hem zaman hem de müşteri memnuniyeti kazandıracak.