ERP ve Mağaza Entegrasyonu Kontrol Listesi

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.

Ü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.

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.

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.

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.

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.

Çalışma belgesini isteyin

Bilgileriniz yalnızca bu belge talebini işlemek için kullanılır. Bülten aboneliği oluşturmaz.

Belgeyi istemek için daha sonra tekrar kontrol edin.