Her veri alanı için tek yetkili kaynak belirleyin
CRM ve e-ticaret entegrasyonu planında olduğu gibi ERP bağlantısında da veri yönü alan düzeyinde yazılmalıdır. Ürün metni mağazada yönetilirken stok ERP’den, müşteri görüşme bilgisi CRM’den gelebilir. Bütün bağlantıları çift yönlü ilan etmek anlaşmazlığı çözmez; aynı alanın iki yerde değişmesi çakışma yaratabilir.
Örnek olarak mağazada yapılan kampanya fiyatının sonraki ERP güncellemesinde silinmesi bir yazılım hatası veya tanımsız sahiplik olabilir. Kaynak fiyat, satış fiyatı ve kampanya kuralının ayrı anlamlarını belirleyin. Bir güncelleme diğer sistemde aynı olayı tekrar başlatıyor mu da kontrol edilmelidir.
Teslim belgesinde nesne, alan, yön, güncelleme koşulu ve sahibi yer alsın. Kaynak sistemin değiştiği durumda bu karar yeniden gözden geçirilir. “ERP ana sistem” ifadesi bütün alanların nasıl çalışacağını açıklamak için tek başına yeterli değildir.
Alan matrisi
Stok, fiyat, ürün metni, müşteri kimliği ve sipariş durumu için yetkili kaynak yazın. Diğer sistemin hangi amaçla okuyacağını belirtin.
Çakışma kararı
İki yerde düzenleme yapılırsa hangi veri kazanacak? Sessizce üstüne yazmak yerine onaylı kural kullanın.
Döngü kontrolü
Bir güncellemenin kendi kendini iki sistem arasında yeniden üretmediğini örnek işlemle gösterin. Kaynak işlem izi korunmalı.
Kod ve müşteri eşleşmesini gerçek örneklerle kanıtlayın
Ürün verisi kontrol listesi stok kodu, barkod ve varyant kimliğinin aynı kavram olmadığını görünür kılar. ERP’de ürünün farklı satış birimleri varsa mağaza kaydının hangi birime bağlandığını belirtin. Kod alanındaki boşluk veya baştaki sıfır bile yanlış eşleşmeye yol açabilir.
Örnek bir toptancı bir kutuda birden fazla parça satabilir. Mağazada iki kutu alan müşterinin ERP’de iki parça olarak kaydedilmesi kabul edilemez. Birim dönüşümü, paket miktarı ve fiyatın hangi birime ait olduğu operasyonla birlikte doğrulanır.
Müşterilerde yalnızca benzer ad veya aynı telefonla otomatik birleştirme yapmayın. Misafir siparişi, şirket hesabı ve farklı teslimat adresleri ayrı senaryolardır. Gerekli kimlik anahtarı ve inceleme süreci yazılır; testlerde kişisel veri için uygun örnek veya maskelenmiş kayıt tercih edilir.
Ürün eşleme
Kaynak kod, hedef kimlik, birim ve varyant ilişkisinin örneğini saklayın. Bulunamayan kod için açık hata üretin.
Müşteri eşleme
Yeni, mevcut ve belirsiz müşteri durumlarını ayırın. Otomatik eşleşmenin güvenli olmadığı kayıt insan incelemesine düşsün.
OKUMADAN SONRAKİ ADIMA
ERP bağlantınızın hata senaryosunu da birlikte görelim
Kaynak sistemleri, stok sahibini ve örnek sipariş akışını paylaşın. Entegrasyon kabulü ile işletim desteğini somut teslimlere ayıralım.
Fiziksel stok ile satışa açık miktarı karıştırmayın
Mağaza operasyon yönetimi stok kararının işletme tarafındaki sahibini belirlemelidir. Depoda bulunan miktar, rezerve edilmiş miktar ve satılabilir miktar farklı olabilir. Kullanılacak hesabın kuralı işletmenin gerçek depo ve satış sürecine göre onaylanır.
Birden fazla depo veya kanal varsa hangi konumun hangi mağazaya satış vereceğini yazın. Stok güncelleme sıklığı satış hızına ve bağlantı kapasitesine göre değerlendirilir. “Anlık” etiketi yerine olayın oluşması ile mağazada görünmesi arasındaki gecikmeyi örnek kayıtla ölçmek daha açıklayıcıdır.
Örnek senaryoda aynı ürün web mağazasında ve pazaryerinde kısa aralıkla satılır. Rezervasyonun hangi sistemde yapıldığı ve yetersiz stok durumunun nasıl çözüldüğü kontrol edilir. İade talebi açıldığında ürün fiziksel incelemeden geçmeden satış stokuna eklenip eklenmeyeceği ayrıca tanımlanır.
Sipariş durumları, iptal ve iade etkisini eşleyin
Backend entegrasyon geliştirme sipariş yaşam döngüsünü iki sistemde aynı anlamla kurmayı gerektirir. Ödeme alındı, ERP kabul etti, sevkiyata hazır ve teslim edildi durumları birbirinin yerine kullanılmamalıdır. Mağazada görünen durumun hangi kayıtla kanıtlandığı bilinmelidir.
Örnek bir kısmi teslimatta siparişin tamamı sevk edilmiş sayılmamalıdır. Kısmi iade, para iadesi ve fiziksel stok geri girişi de farklı işlerdir. Finans ve depo ekipleri kendi adımlarının ne zaman tamamlandığını onaylar; tek “iade edildi” etiketi bütün sonuçları gizlememelidir.
İptal isteği ERP’ye giderken sipariş hazırlanmış olabilir. Bu durumda otomatik işlem yerine görev veya istisna akışı gerekebilir. Onaylı durum eşleştirme tablosu, hangi geçişin mümkün olduğunu ve hangi değişiklikte insan kararının gerektiğini açıklamalıdır.
Kabul kaydı
Kaynak siparişle ERP sipariş kimliğini ilişkilendirin. Gönderim yanıtı ile iş kaydının kabulünü ayrı kontrol edin.
Ters akış
İptal ve iadenin ödeme, sevkiyat ve stok etkisini ayrı test edin. Her sistemde tek bir genel etikete güvenmeyin.
İstisna kararı
İşlenmiş sipariş değişikliği için yetkili ekibe görev oluşturun. Eski duruma zorla dönmek yerine gerçek işlem izini koruyun.
Tekrar, gecikme ve kesinti davranışını sınayın
DevOps ve işletim kurulumu entegrasyonun hatalarını görünür kılacak izleme ve kurtarma düzenini kapsamalıdır. Bir olayın iki kez gelmesi, hedefin geç yanıt vermesi ve yanıt alınmadan işlemin tamamlanması farklı koşullardır. Her birinde ikinci sipariş oluşup oluşmadığını kontrol edin.
Tekrar işleme için sabit kaynak işlem kimliği ve hedef kayıt ilişkisi kullanılabilir; yöntemin gerçek hedef API ile doğrulanması gerekir. Her hata otomatik tekrar için uygun değildir. Geçersiz ürün kodunu sürekli yeniden göndermek çözüm oluşturmaz; veri düzeltme görevi gerekir.
Hata kuyruğunda işlem türü, anlaşılır neden, son deneme ve sorumlu ekip bulunmalıdır. Gereksiz kişisel veri veya sırlar günlükte tutulmaz. Kurtarma yapan kişinin hangi işlemi yeniden başlatabileceği yetkiyle sınırlandırılır. Uyarının gönderilmesi değil, doğru kişinin çözüm yolunu bilmesi kabulün parçasıdır.
Mutabakat raporu ve işletim devriyle yayına geçin
CI/CD ve işletim süreci yayınlanan bağlantı sürümünü ve değişiklik kaydını izlenebilir tutar. Yeni alan veya sağlayıcı sürümü eklendiğinde hangi testlerin yeniden çalışacağı belirlenir. Kimlik bilgisi değişimi, erişim kaldırma ve kesinti iletişimi için görev sahibi bulunmalıdır.
Düzenli mutabakat kaynak ile hedefin aynı işi tamamladığını kontrol eder. Sipariş sayısı, gerekli toplamlar ve kayıt durumları uygun zaman aralığında karşılaştırılır. Fark raporu körlemesine her şeyi otomatik düzeltmek yerine incelenecek kayıtları açıklamalıdır. İşletme kuralını bozan toplu düzeltme ayrı bir risk oluşturur.
İlk yayın küçük ve temsilî bir akışla sınanabilir. Teslim paketi alan haritası, durum sözlüğü, örnek başarı/hata kayıtları, mutabakat yöntemi ve işletim sorumlularını içerir. Prix Studio ile değerlendirmede bu kanıtlar bağlantı işini devam eden destekten ayırmayı sağlar.
Mutabakat sahibi
Fark raporunu kimin hangi sıklıkta inceleyeceğini yazın. Görülen fark için düzeltme ve kapanış kanıtı bulunsun.
İşletim kılavuzu
Kesinti, erişim değişimi ve güvenli tekrar işleme adımlarını kısa görevler halinde teslim edin. Destek kişisi gerçek kullanım senaryosunu prova etsin.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Entegrasyon her zaman çift yönlü mü olmalı?
Hayır. Yön her nesne ve alan için belirlenir. İki tarafta aynı alanın bağımsız değişmesi çakışma veya döngü üretebilir; gereksinim kanıtlanmadan çift yön tercih edilmemelidir.
Stok mutlaka anlık mı güncellenmeli?
İşletmenin satış hızı, rezervasyon modeli ve API kapasitesi değerlendirilir. Kabul edilebilir gecikme açıkça tanımlanmalı ve ölçülmelidir. “Anlık” sözü tek başına işletim kalitesini göstermez.
Aynı sipariş iki kez gelirse ne olmalı?
Hedefte ikinci bağımsız sipariş oluşturmadan aynı işlemi tanıyan bir yöntem gerekir. Seçilen kimlik ve tekrar kuralı gerçek API üzerinde test edilir; yalnızca bağlantı sağlayıcısının genel sözüne dayanılmaz.
İade açılınca stok hemen artırılmalı mı?
Bu işletmenin onaylı depo sürecine bağlıdır. Talep, fiziksel kabul, finansal iade ve yeniden satışa uygunluk ayrı olaylar olabilir. Liste teknik uygulamanın bu kararla uyuşmasını kontrol eder.
Hata kuyruğu yeterli mi?
Kuyruğun okunabilir nedeni, sorumlusu ve güvenli düzeltme yolu olmalıdır. Düzenli mutabakatla hiç kuyruğa düşmeyen eksik işlemler de aranır. Uyarı sayısı tek başına çözüm değildir.
ERP ve mağaza bağlantısının teslimi neyi içerir?
Alan ve durum haritası, kimlik eşleme, seçilmiş başarı/hata testleri, tekrar engelleme kanıtı, mutabakat yöntemi ve işletim kılavuzu. İlk başarılı sipariş tüm kapsamın kabulü sayılmaz.
KAPSAMI BİRLİKTE BELİRLEYELİM
ERP bağlantınızın hata senaryosunu da birlikte görelim
Kaynak sistemleri, stok sahibini ve örnek sipariş akışını paylaşın. Entegrasyon kabulü ile işletim desteğini somut teslimlere ayıralım.
Entegrasyon kontrolünü görüşün