Aydınlatma metni yükleniyor…
E-ticaret ve ERP entegrasyonu, iki sisteme bir bağlantı eklemekten ibaret değildir. Ürün, stok, fiyat, müşteri, sipariş, ödeme, sevkiyat, iptal ve iade verilerinin hangi sistemde doğduğunu; hangi yönde, ne zaman ve hangi hata davranışıyla taşındığını belirleyen operasyon tasarımıdır.
Sağlıklı planın ilk sorusu “API var mı?” değil, “bu alanın ana kaydı hangi sistem?” olmalıdır. Entegrasyon teklifi de yalnız uç nokta sayısıyla değil veri alanı, iş kuralı, hacim, gecikme, hata, tekrar deneme, mutabakat, test ve sahiplik üzerinden karşılaştırılmalıdır.
E-Ticaret–ERP Entegrasyonunun Sınırı Nedir?
E-ticaret platformu müşteriye ürün, fiyat, kampanya, sepet, ödeme ve hesap deneyimi sunar. ERP; ürün, satın alma, depo, muhasebe, cari hesap, fatura veya sevkiyat süreçlerinin bir bölümünde ana sistem olabilir. Kurumun PIM, WMS, CRM, ödeme, kargo ve pazar yeri sistemleri de aynı akışa katılabilir.
Bu nedenle “ERP her verinin sahibidir” veya “e-ticaret her zaman ön sistemdir” genellemesi doğru değildir. Her veri nesnesi ayrı karara ihtiyaç duyar. ERP’nin rolünü daha geniş değerlendirmek için ERP yazılımı rehberini inceleyebilirsiniz.
Kumsal Sistem Kaynağı ve Mutabakat Matrisi
Bu özgün matris, her veri nesnesini on karar alanıyla kaydeder: ana kaynak, yazma yetkisi, hedef, yön, tetikleyici/sıklık, dönüşüm, doğrulama, tekrar davranışı, mutabakat ve operasyon sahibi. Bir ürün veya mimari reçetesi değildir; farklı tekliflerin aynı veri sorumluluklarını kapsayıp kapsamadığını gösterir.
| Veri | Örnek ana kaynak kararı | Mutabakat sorusu |
|---|---|---|
| Ürün | ERP, PIM veya e-ticaret | Kod, varyant ve kanal eşleşmeyen kayıtlar nerede? |
| Stok | ERP/WMS; kanal rezervasyonu ayrı | Satılabilir miktar ile kanal toplamı neden farklı? |
| Fiyat | ERP, fiyat motoru veya kanal | Geçerlilik, vergi, para birimi ve kampanya uyuyor mu? |
| Sipariş | E-ticaret doğurur; ERP işler | Tekil sipariş ve satırlar iki sistemde aynı mı? |
| Ödeme | Ödeme sağlayıcısı sonucu; finans kaydı ERP | Tutar, durum, iade ve muhasebe kaydı eşleşiyor mu? |
| Sevkiyat | ERP/WMS/kargo | Kısmi paketler ve takip durumu kanala doğru döndü mü? |
| İptal/iade | Talep kanalda, karar operasyon sisteminde olabilir | Ürün, stok, ödeme ve belge hareketleri tamamlandı mı? |
Ürün ve Varyant Verisi Nasıl Eşlenir?
Ürün kodu, varyant, barkod, birim, paket, kategori, marka, açıklama, görsel ve kanal durumu aynı kayıtta bulunmayabilir. ERP ticari ve stok kodunu; PIM zengin içeriği; e-ticaret SEO ve vitrin alanlarını yönetebilir. Hangi alanın hangi sistemde düzenleneceği açık olmalıdır.
Eşleme tablosu iç ve kanal kodlarını, varyant ilişkisini, birim dönüşümünü ve yayından kaldırma davranışını içerir. Tanımsız ürün geldiğinde kaydı sessizce atlamak yerine karantina/hata kuyruğuna almak; düzeltme sahibini ve yeniden işleme yöntemini belirlemek gerekir.
Stok Entegrasyonunda “Stok” Hangi Miktardır?
Fiziksel mevcut miktar, ayrılmış miktar, güvenlik stoğu, hasarlı/karantina stok, yoldaki ürün ve kanala ayrılan kota farklı kavramlardır. Kanalda gösterilecek satılabilir miktarın işletme kuralı tanımlanmalıdır. Örneğin formül, kaynağa ve satış modeline göre mevcut eksi rezervasyon ve tampon olabilir; bu evrensel bir hesap değildir.
Çok depo varsa hangi bölgeye hangi deponun hizmet verdiği; kısmi sevkiyat, mağazadan teslim ve ön sipariş davranışı belirlenir. Güncelleme aralığı satış hızına ve fazla satış riskine göre seçilir. Yakın gerçek zamanlı akış bile gecikme veya kesinti yaşayabileceği için son başarılı güncelleme, kuyruk yaşı ve yeniden mutabakat görünür olmalıdır.
Fiyat, Vergi ve Kampanya Akışı
Liste fiyatı, indirim, müşteri grubu, kupon, kanal komisyonu, para birimi, vergi ve geçerlilik tarihleri ayrı alanlardır. ERP temel fiyatı üretirken kampanya e-ticarette uygulanabilir; ya da merkezi fiyat motoru bütün kanallara sonuç verebilir. Sepette kullanılan fiyatın hangi anda kilitlendiği kararlaştırılmalıdır.
Geçmiş sipariş yeni fiyatla yeniden hesaplanmamalıdır. Entegrasyon, sipariş anındaki birim fiyat, indirim, vergi ve toplamları kayıt olarak taşımalı; ERP’nin kabul/red ve yuvarlama davranışı test edilmelidir. Fark bulunduğunda siparişin otomatik mi beklemeye mi alınacağı iş kuralıdır.
Sipariş Akışı Nasıl Tasarlanır?
- E-ticaret siparişi tekil bir kimlikle oluşturur.
- Ödeme veya ödeme yöntemi sonucu uygun durumla ilişkilendirilir.
- Müşteri, adres, ürün, miktar, fiyat, vergi, indirim ve teslimat alanları doğrulanır.
- Sipariş ERP’ye iletilir; teknik teslim ile iş kabulü ayrı durumlar olarak kaydedilir.
- ERP sipariş numarası ve kabul/ret sonucu kanala döner.
- Ayırma, hazırlama, kısmi sevkiyat, fatura ve takip durumları güncellenir.
- İptal/iade, stok ve finans hareketleriyle kapatılır.
HTTP 200 veya kuyruktan çıkış, siparişin ERP’de iş kuralına uygun kabul edildiğini kanıtlamaz. Teknik başarı, iş kabulü ve finansal sonuç için ayrı durumlar gerekir. Sipariş satırlarından biri reddedildiğinde bütün sipariş, kısmi kabul veya insan incelemesi davranışı açıkça tanımlanmalıdır.
Hata, Tekrar Deneme ve Yinelenen Kayıt Nasıl Yönetilir?
Ağ zaman aşımı olduğunda gönderen sistem, hedefin işlemi yapıp yapmadığını bilemeyebilir. Aynı isteği körlemesine yinelemek iki sipariş veya iki tahsilat oluşturabilir. AWS Builders’ Library idempotent API rehberi, güvenli tekrarlar için istemci istek kimliği ve aynı niyetin tanınması gibi yaklaşımları açıklar.
Idempotency hedef sistemin uyguladığı bir davranıştır; yalnız rastgele alan eklemek yeterli değildir. Stripe idempotent request dokümanı, aynı anahtarla yapılan tekrarların bir sağlayıcı API’sinde nasıl ele alındığına dair somut bir ürün örneğidir; bu davranış bütün ERP veya ödeme sistemlerinde varsayılamaz.
Hataları en azından geçici teknik hata, kalıcı doğrulama hatası, iş kuralı reddi, yetki hatası, limit/kota ve bilinmeyen sonuç olarak ayırın. Her sınıf için tekrar sayısı/aralığı, durum sorgulama, alarm, insan kuyruğu, düzeltme ve yeniden işleme yetkisi yazılır.
Mutabakat Neden Ayrı Bir İş Akışıdır?
Olay bazlı başarılı iletim bile zaman içinde veri eşitliğini garanti etmez. Kaçırılan olay, manuel ERP düzeltmesi, ürün eşleşme hatası veya kanal kesintisi fark oluşturabilir. Bu yüzden periyodik mutabakat; sipariş sayısı/tutarı, sipariş satırları, stok, fiyat, ödeme, iade ve sevkiyat kümelerini karşılaştırır.
Mutabakat yalnız fark raporu değildir. Farkın sınıfı, iş etkisi, kaynak kayıt, düzeltme yönü, yetkili kişi ve tekrar kontrolü bulunmalıdır. Finansal veya yasal kayıtların otomatik değiştirilmesi kurumun kontrol ve uzman onayına bağlıdır.
Gerçek Zamanlı, Olay Bazlı veya Toplu Akış Nasıl Seçilir?
| Yöntem | Uygun olabilecek kullanım | Dikkat |
|---|---|---|
| Senkron API | Anlık doğrulama veya kullanıcı yanıtı | Zaman aşımı, bağımlı sistem kesintisi, gecikme |
| Olay/kuyruk | Sipariş ve durum gibi dayanıklı asenkron akış | Sıralama, yinelenen olay, gecikme, izleme |
| Toplu aktarım | Büyük katalog, periyodik fiyat veya mutabakat | Güncellik penceresi, kısmi dosya, tekrar işleme |
| Hibrit | Anlık kritik akış ile toplu doğrulama birlikte | İki yolun çelişmemesi ve ortak sahiplik |
Tek bir yöntemi tüm veriye uygulamak yerine iş etkisi, hacim, gecikme toleransı ve hedef sistem kapasitesiyle karar verin.
Loglama, İzleme ve Alarm Kapsamı
Her kayıt için korelasyon/istek kimliği, kaynak, hedef, olay zamanı, işlem türü, sonuç, hata sınıfı, deneme sayısı ve güvenli durum özeti izlenebilir olmalıdır. Hassas kimlik, ödeme veya kimlik doğrulama verisi gereksiz yere loglanmamalıdır.
OWASP Logging Cheat Sheet, güvenlik olaylarının kaydı yanında log içeriğinin korunması, izlenmesi ve hassas verilerin yönetilmesi için rehber sunar. E-ticaret–ERP projesi iş izleme ile güvenlik loglarını amaç, erişim ve saklama açısından ayırmalıdır. Belgeyi anmak güvenlik veya uygunluk kanıtı değildir.
Test Planında Hangi Senaryolar Olmalı?
- Yeni ve güncellenen ürün, varyant, birim ve eşleme
- Stok sıfır, negatif/karantina, rezervasyon ve çok depo
- Fiyat başlangıç/bitiş zamanı, vergi, kur ve yuvarlama
- Başarılı, reddedilen, yinelenen ve zaman aşımına uğrayan sipariş
- Kısmi kabul, kısmi sevkiyat ve birden fazla paket
- Başarılı/başarısız ödeme, gecikmiş geri bildirim ve iade
- İptal öncesi/sonrası stok ve finans hareketleri
- API limiti, kimlik doğrulama hatası ve sistem kesintisi
- Kuyruk birikmesi, yeniden işleme ve mutabakat farkı
- Yetkisiz erişim, log gizliliği ve operasyonel alarm
Genel veri alanı, hata ve sahiplik şablonu için web yazılım entegrasyonları planlama rehberini kullanabilirsiniz.
Teklifte Hangi Kalemler Ayrı Yazılmalı?
- Sistem ve veri envanteri, süreç analizi
- Ürün/variyant/kanal eşleme ve veri temizliği
- Her veri akışı için alan, yön, hacim ve sıklık
- API, dosya, kuyruk veya ara katman geliştirmesi
- Hata sınıfları, tekrar, idempotency ve insan kuyruğu
- Mutabakat raporları ve düzeltme yetkileri
- Test ortamları, örnek veriler ve uçtan uca kabul
- İzleme, alarm, log, pano ve olay sorumluluğu
- Canlı geçiş, geri dönüş, eğitim ve dokümantasyon
- Lisans, işlem, altyapı, bakım ve yeni geliştirme
Entegrasyon kapsamını ve e-ticaret altyapınızı birlikte değerlendirmek için Kumsal Ajans e-ticaret ekibiyle görüşebilirsiniz.
Sonuç
Başarılı e-ticaret–ERP entegrasyonu, veriyi sadece taşımak değil her alanın sahibini, zamanını, hata davranışını ve doğruluk kanıtını yönetmektir. Sistem Kaynağı ve Mutabakat Matrisi; stok, fiyat, sipariş, ödeme, sevkiyat ve iadeyi aynı operasyon kaydında birleştirir.