E-Ticaret Sitesi ile ERP Entegrasyonu Nasıl Yapılır?

E-ticaret sitesi ile ERP entegrasyonu ne işe yarar?

ERP entegrasyonu; e-ticaret mağazasında oluşan satış hareketleri ile işletmenin ürün, depo, cari, muhasebe ve sevkiyat kayıtlarını aynı veri modeli üzerinden buluşturur. Amaç çalışanların aynı siparişi farklı ekranlara tekrar yazması değil, hangi verinin nerede üretildiğini ve hangi sisteme ne zaman aktarılacağını netleştirmektir.

Başarılı bir entegrasyonda “iki sistem her şeyi birbirine göndersin” yaklaşımı kullanılmaz. Örneğin ürün maliyeti ve depo stoğu ERP’den, müşteri tarafından seçilen teslimat adresi e-ticaret sitesinden gelebilir. Sipariş e-ticarette açılır, ERP’de satış siparişine dönüşür; fatura numarası ve kargo bilgisi tekrar mağazaya döner.

ERP entegrasyonunda hangi veriler aktarılır?

Kapsam işletmenin satış modeline göre değişir. Bir perakende mağazasında depo ve varyant stoğu kritik olabilirken B2B satışta müşteri grubu, cari risk limiti, özel fiyat ve vadeli ödeme bilgisi öne çıkar.

Her veri için ana kaynak sistemi belirleyin

En sık yapılan hata, aynı alanı iki sistemin de sınırsız biçimde güncellemesine izin vermektir. Böyle bir yapıda ERP fiyatı 500 TL’ye çekerken e-ticaret kampanya motoru 475 TL yazabilir; sonraki senkronizasyonda değerler sürekli birbirini ezer.

SKU, barkod ve sistem kimliklerini kalıcı eşleştirin

Entegrasyon yalnızca ürün adına bakarak çalışmamalıdır. Ürün adı değişebilir, aynı adla birden fazla varyant bulunabilir. Her kayıt için e-ticaret ürün kimliği, varyant kimliği, ERP stok kodu, barkod ve gerekiyorsa depo kodu birlikte saklanmalıdır.

Sağlam eşleştirme tablosunda bulunması gereken alanlar

• Yerel ürün ve varyant kimliği
• ERP stok kartı kimliği ve stok kodu
• GTIN/barkod ve üretici kodu
• ERP depo kodu ile mağaza lokasyonu eşleşmesi
• Son başarılı senkronizasyon zamanı
• Son hata, deneme sayısı ve entegrasyon sürümü

Kimliği bulunmayan kayıt otomatik olarak “en yakın ürün” ile eşleştirilmemelidir. Yanlış eşleşme, farklı varyantın stoğunun düşmesine veya yanlış ürünün faturalanmasına yol açabilir.

Stok ve fiyat senkronizasyonu nasıl kurulmalıdır?

Stok entegrasyonu tam miktarı gönderebilir veya değişim kadar artırıp azaltabilir. Çok kanallı satışta yalnızca “stok 8” bilgisini yazmak bazen yeterli değildir; açık sipariş rezervleri, güvenlik stoğu, hasarlı ürün ve farklı depoların satılabilirliği de hesaba katılmalıdır.

Shopify’ın resmî envanter modelinde de stok seviyesi ürün envanter kalemi ile lokasyon ilişkisi üzerinden tutulur. Bu yaklaşım, tek bir toplam stok yerine depo/lokasyon bazlı tasarımın önemini gösterir. Shopify InventoryLevel belgesi bu ilişkiyi ayrıntılı açıklar.

• Satılabilir stok formülünü yazılı hâle getirin.
• Negatif stok ve güvenlik stoğu kuralını belirleyin.
• Fiyatın KDV dâhil mi hariç mi olduğunu sabitleyin.
• Para birimi ve kur kaynağını belirleyin.
• Toplu güncellemede API limitlerini dikkate alın.
• Gün sonunda tam stok mutabakatı çalıştırın.

Sipariş ERP’ye nasıl aktarılır?

Sipariş ödeme onayından sonra entegrasyon kuyruğuna alınmalıdır. Kuyruk kaydı siparişin kendisinden ayrı tutulursa ERP geçici olarak kapalı olduğunda sipariş kaybolmaz. Başarısız işlem belirli aralıklarla tekrar denenebilir ve kullanıcıya gerçek hata gösterilebilir.

1. Sipariş ve ödeme durumu doğrulanır.
2. Müşteri/cari kartı bulunur veya kurala göre oluşturulur.
3. Adres, vergi ve teslimat alanları doğrulanır.
4. Ürün satırları ERP stok kodlarıyla eşleştirilir.
5. Satış siparişi tekil entegrasyon anahtarıyla oluşturulur.
6. ERP belge numarası yerel siparişe kaydedilir.
7. Fatura, sevkiyat ve kargo sonuçları geri alınır.

Ağ hatasında aynı isteğin yeniden gönderilmesi mükerrer sipariş oluşturabilir. Bu nedenle her aktarım için sipariş numarasından türetilen tekil anahtar ve sistem tarafında mükerrerlik kontrolü kullanılmalıdır. Stripe’ın resmî API belgesi, idempotency anahtarıyla bağlantı hatası sonrası aynı işlemin güvenle tekrar denenmesi ilkesini açıklar. Idempotent requests belgesi bu tasarım prensibi için iyi bir örnektir.

API, webhook, kuyruk ve periyodik mutabakat birlikte kullanılmalıdır

API ile anlık veri okunup yazılabilir. Webhook ise kaynak sistemde değişiklik olduğunda entegrasyonun haberdar olmasını sağlar. Ancak yalnızca webhook’a güvenmek doğru değildir; geçici bağlantı hataları veya abonelik sorunları nedeniyle kaçan kayıtları bulmak için periyodik mutabakat gerekir.

Microsoft Dynamics 365 Business Central, değişen varlıklar için webhook bildirimleri ve abonelik yenileme yapısı sunar. Resmî belgede bildirimlerin birden fazla değişikliği içerebilmesi, abonelik süresi ve başarısız teslimat tekrarları açıklanır. Business Central webhook belgesi entegrasyonların neden abonelik takibi ve tekrar deneme kaydı tutması gerektiğini gösterir.

Hata yönetimi ve güvenlik nasıl olmalıdır?

• API anahtarlarını HTML veya tarayıcı JavaScript’i içinde tutmayın.
• Yetkileri yalnızca gerekli müşteri, ürün, stok ve sipariş kaynaklarıyla sınırlayın.
• Kişisel verileri hata kayıtlarında gereksiz biçimde çoğaltmayın.
• Her istekte kaynak sistem, işlem kimliği, süre, cevap kodu ve hata mesajını kaydedin.
• 429 ve geçici 5xx hatalarında artan bekleme süresiyle tekrar deneyin.
• Kalıcı doğrulama hatalarını otomatik tekrar döngüsüne sokmayın; kullanıcı müdahalesi isteyin.

Canlıya geçiş planı

Önce sınırlı ürün ve tek depo ile pilot çalışma yapılmalıdır. Sipariş, iptal, kısmi sevkiyat, iade, fiyat değişimi ve stok tükenmesi ayrı senaryolarla test edilmelidir. Canlı geçiş saatinde eski entegrasyon durdurulmalı, son değişiklik zamanı kaydedilmeli ve yeni sistem başlangıç noktasını bu zamandan almalıdır.

Yaygın sorunlar ve çözüm yönü

Ne zaman teknik destek gerekir?

ERP’nin API belgeleri yoksa, kayıtlar doğrudan veritabanından okunacaksa, birden fazla depo veya şirket bulunuyorsa, fiyat kuralları müşteri bazlıysa ya da entegrasyon mükerrer sipariş üretiyorsa özel analiz gerekir. Teknik ekipten önce veri akış şeması, örnek ürün/sipariş kayıtları ve zorunlu alan listesi hazırlanmalıdır.

Sık sorulan sorular

ERP entegrasyonu gerçek zamanlı olmak zorunda mı?

Hayır. Sipariş ve kritik stok hareketleri anlık, büyük ürün katalogları ise kuyruklu veya zamanlanmış çalışabilir. Gereken hız, satış hacmi ve API limitlerine göre belirlenir.

ERP kapalıyken sipariş kaybolur mu?

Doğru kuyruk yapısında kaybolmaz. Sipariş yerel olarak saklanır, işlem beklemeye alınır ve ERP tekrar erişilebilir olduğunda kontrollü biçimde yeniden denenir.

Entegrasyon doğrudan ERP veritabanına bağlanabilir mi?

Teknik olarak mümkün olabilir ancak üretici API’si veya desteklenen servis tercih edilmelidir. Doğrudan veritabanı bağlantısı sürüm değişikliklerinde kırılabilir ve veri bütünlüğü riskini artırabilir.