Hangi veri hangi sistemde doğar, stok neden olay tabanlı akmalı, SKU eşleştirmesi neden projeyi uzatır ve mutabakat neden tek gerçek kanıttır?
ERP entegrasyonu, e-ticaret sitesi ve pazaryerlerindeki ürün, stok, sipariş, cari ve fatura verisinin muhasebe/kaynak planlama yazılımınızla otomatik eşitlenmesi. Bu yazıda hangi verinin hangi yöne akması gerektiğini, eşleştirme sorununu, hata yönetimini ve projeyi doğru sırayla nasıl yürüteceğinizi anlatıyoruz.
ERP entegrasyonu talebi genelde şu cümleyle geliyor: "Aynı veriyi üç yere giriyoruz." Doğru teşhis ama eksik. Asıl sorun tekrar eden veri girişi değil, üç yerdeki verinin birbirini tutmaması — ve hangisinin doğru olduğunun bilinmemesi.
Önce karar: tek doğruluk kaynağı hangisi
Entegrasyon projelerinin başarısını belirleyen ilk karar bu. Her veri türü için tek bir sistem "doğrunun sahibi" olmalı:
| Veri | Tipik sahibi | Neden |
|---|---|---|
| Ürün kartı ve özellikleri | ERP ya da PIM | Tek yerde tanımlanıp her kanala dağıtılmalı |
| Stok | ERP / depo | Fiziksel gerçeği bilen sistem |
| Fiyat | ERP (kanal kuralıyla) | Maliyet ve marj orada; kanal farkı kuralla uygulanır |
| Sipariş | Satış kanalı | Sipariş orada doğuyor |
| Cari ve fatura | ERP | Muhasebe kaydının kaynağı |
Bu tablo yazılı hale getirilmediğinde, her sistem her veriyi güncellemeye çalışıyor ve çakışmalar başlıyor: pazaryerinde elle değiştirilen fiyat, bir sonraki senkronizasyonda geri alınıyor; ERP'de düzeltilen stok, siteden gelen eski değerle eziliyor.
Veri yönü ve sıklığı
Her akış için üç soruya cevap verilmeli: hangi yöne, ne sıklıkla, hangi tetikleyiciyle.
| Akış | Yön | Sıklık |
|---|---|---|
| Ürün ve özellikler | ERP → kanallar | Değişimde ya da günlük |
| Stok | ERP → kanallar | Anlık (olay tabanlı) |
| Fiyat | ERP → kanallar | Değişimde |
| Sipariş | Kanallar → ERP | Anlık ya da birkaç dakikada bir |
| Sipariş durumu / kargo | ERP → kanallar | Değişimde |
| Fatura | ERP → kanal / müşteri | Sipariş onayında |
Stok akışı neden özel: gecikmesi doğrudan stoksuz satışa dönüşüyor ve pazaryerlerinde satıcı puanını düşürüyor. Bu yüzden stok, periyodik sorgu değil olay tabanlı çalışmalı — ayrıntısını çok kanallı stok senkronizasyonu yazımızda anlattık.
Eşleştirme: projenin en çok zaman alan kısmı
Teknik entegrasyon genellikle tahmin edilen sürede bitiyor; proje eşleştirme yüzünden uzuyor. Üç tipik sorun:
- SKU tutarsızlığı. ERP'de
URN-001, sitedeurn001, pazaryerinde barkod. Ortak bir anahtar yoksa entegrasyon kurulamaz. Projenin ilk işi tek bir eşleştirme anahtarı belirlemek olmalı. - Varyant yapısı. ERP'de her renk-beden ayrı bir stok kartıysa ama sitede tek ürün altında varyantsa, iki tarafın eşlenmesi kural gerektiriyor.
- Kategori ağacı. ERP kategorileri muhasebe mantığıyla, kanal kategorileri arama mantığıyla kurulmuş oluyor; birebir karşılık gelmiyor.
Bu üç konu projeye başlamadan önce netleştirilmezse, geliştirme sırasında sürekli karar bekleyen bir iş haline geliyor.
Hata yönetimi ve tekrar denemeler
Entegrasyon canlı bir sistem: kanal API'si yanıt vermeyebilir, ERP bakımda olabilir, veri beklenmedik bir formatta gelebilir. Kurulması gerekenler:
- Tekrar deneme (retry) mantığı. Geçici hatalar artan aralıklarla tekrar denenmeli.
- Mükerrer işlem koruması. Aynı siparişin iki kez ERP'ye yazılmasını engelleyen bir kimlik kullanılmalı.
- Kuyruk. Hedef sistem erişilemezken işlemler kaybolmamalı, sıraya girmeli.
- Alarm. Sessiz durma en tehlikeli senaryo; entegrasyon durduğunda haber verilmeli.
- Mutabakat. Günlük olarak iki taraftaki sipariş ve stok sayıları karşılaştırılmalı. Fark varsa entegrasyon "çalışıyor görünüp" çalışmıyordur.
Mutabakat adımı en çok atlanan kısım ve en çok işe yarayan güvenlik ağı. Entegrasyonun çalıştığını kanıtlayan tek şey, iki sistemdeki rakamların tutması.
Doğrudan entegrasyon mu, ara katman mı
| Doğrudan (nokta-nokta) | Ara katman | |
|---|---|---|
| Uygun olduğu durum | 1–2 kanal, basit veri | 3+ kanal, kural gerektiren akışlar |
| Kurulum süresi | Kısa | Daha uzun |
| Kanal eklemek | Her kanal için yeni geliştirme | Yeni bağlayıcı yazmak yeterli |
| Hata görünürlüğü | Dağınık | Tek yerden izlenebilir |
Pratik kural: iki kanala kadar doğrudan entegrasyon yeterli. Üçüncü kanalda bağlantı sayısı (ve dolayısıyla bakım yükü) hızla artmaya başlıyor; o noktada ara katman hem daha ucuz hem daha yönetilebilir oluyor.
Proje sırası
- Veri sahipliği tablosunu yazın. Hangi veri hangi sistemde doğar, kim günceller.
- Eşleştirme anahtarını belirleyin ve verileri temizleyin. Bu adım atlanırsa proje sonradan durur.
- Tek bir akışla başlayın. Genelde stok ya da sipariş; en yüksek etkiyi en hızlı veren akış.
- Hata senaryolarını ve alarmları kurun. Mutlu senaryo çalışmadan sonraki akışa geçmeyin.
- Mutabakat raporunu kurun. Günlük karşılaştırma.
- Sonraki akışları ekleyin. Fiyat, ürün, fatura, kargo durumu.
Sık yapılan hatalar
- Veri sahipliğini tanımlamadan başlamak. Çakışan güncellemeler kaçınılmaz hale gelir.
- Tüm akışları aynı anda devreye almak. Sorun çıktığında hangi akıştan geldiği bulunamaz.
- Eşleştirme verisini temizlemeden geliştirmeye başlamak. Proje en pahalı şekilde tıkanır.
- Alarm ve mutabakat kurmamak. Entegrasyonun durduğu, iptal edilen siparişten öğrenilir.
- Kanal başına özel kural mantığını koda gömmek. Kurallar yapılandırılabilir olmalı; her değişiklik geliştirme gerektirmemeli.
Sonuç
ERP entegrasyonu bir yazılım projesinden çok bir veri yönetimi projesi. Teknik kısım öngörülebilir; belirleyici olan, hangi verinin nerede doğduğuna dair kararların baştan verilmesi ve hata senaryolarının ciddiye alınması. Bu ikisi yapıldığında entegrasyon, kanal eklemeyi maliyet olmaktan çıkarıp rutin bir işe dönüştürüyor.
Fatura ve kargo tarafı için kargo ve e-fatura entegrasyonu, hazır çözüm–özel geliştirme kararı için hazır paket mi özel yazılım mı yazımıza bakabilirsiniz.
Commerslab olarak ERP, e-ticaret ve pazaryeri arasındaki veri akışını kuruyor, mutabakat ve alarm katmanıyla birlikte teslim ediyoruz. Sistem entegrasyonları hizmetimizi inceleyin veya mevcut yapınız için bize yazın.
