B2B ERP Entegrasyonu Nasıl Çalışır?

Bir bayi sipariş verdiğinde yalnızca sepetteki ürünler hareket etmez. Stok uygunluğu, müşteriye tanımlı fiyatlar, ödeme koşulları, cari limitler ve sevkiyat bilgileri aynı sürecin parçalarıdır. Bu bilgiler farklı sistemlerde tutuluyor ve elle güncelleniyorsa satış ekranında görünen durum ile operasyonun gerçek durumu birbirinden uzaklaşabilir.

B2B ERP entegrasyonu, ticaret platformu ile kurumsal kaynak planlama sistemi arasında kontrollü veri alışverişi kurar. Amaç yalnızca siparişi ERP’ye göndermek değil; müşteriye gösterilen bilgiyle muhasebe, depo ve satış ekiplerinin kullandığı bilgiyi tutarlı hâle getirmektir. Doğru çözümü değerlendirirken hangi verinin taşındığını, hangi sistemin esas alındığını ve hata durumlarının nasıl yönetildiğini birlikte incelemek gerekir.

B2B ERP entegrasyonu nedir?

B2B ERP entegrasyonu; şirketin bayi, kurumsal müşteri veya tedarikçi platformuyla ERP yazılımının belirlenmiş kurallar üzerinden haberleşmesidir. Bu bağlantı API, olay bildirimi, dosya aktarımı veya ara katman üzerinden kurulabilir. Teknik yöntem değişse de temel ihtiyaç aynıdır: Bir sistemde oluşan iş bilgisinin diğer sistemde doğru kayda ve doğru sürece dönüşmesi.

Örneğin ERP’de açılan bir ürün, ticaret platformunda satışa sunulabilir; platformda onaylanan sipariş de ERP’de satış siparişine dönüşebilir. Ardından ERP’de oluşan sevkiyat ve fatura bilgileri müşterinin hesabına geri aktarılabilir. Bu nedenle çift yönlü veri akışı, bütün alanların iki tarafta da serbestçe değiştirilebilmesi anlamına gelmez. Her veri alanının yetkili kaynağı belirlenmelidir.

B2B yazılım ERP entegrasyonu değerlendirilirken ekran özelliklerinden önce süreç uyumu sorgulanmalıdır. Platformun ticari işlevlerine ilişkin genel çerçeve için B2B e-ticaret yazılımı rehberi incelenebilir. Entegrasyonun kapsamı ise işletmenin satış ve operasyon kuralları üzerinden ayrıca tanımlanmalıdır.

• Veri sahipliği: Hangi kaydı hangi sistem oluşturur ve günceller?
• Aktarım yönü: Bilgi ERP’den platforma mı, platformdan ERP’ye mi gider?
• Başarı ölçütü: Kaydın iletilmesi mi, iş kuralına uygun biçimde işlenmesi mi esas alınır?

Hangi veriler senkronize edilir?

Entegrasyon kapsamı bir veri listesiyle başlar, ancak liste tek başına yeterli değildir. Her alan için eşleştirme, güncelleme sıklığı, zorunluluk ve hata davranışı tanımlanmalıdır. Ürün kodu, cari kodu ve sipariş kimliği gibi anahtarlar sistemler arasında kararlı bir ilişki kurmalıdır. İsim veya açıklama üzerinden yapılan eşleştirmeler değişikliklerde sorun çıkarabilir.

• Cari: Müşteri kodu, ticari unvan, vergi bilgileri, adresler ve ödeme koşulları.
• Ürün: Stok kodu, barkod, varyant, ölçü birimi, kategori ve satışa açıklık durumu.
• Stok: Depo bazlı miktar, rezervasyon ve satışa kullanılabilir miktar.
• Fiyat: Fiyat listesi, para birimi, iskonto, vergi ve geçerlilik tarihleri.
• Sipariş: Başlık bilgileri, satırlar, teslimat adresi, ödeme yöntemi ve durum.
• Fatura: Belge numarası, belge tarihi, satır ilişkileri ve ilgili belge erişimi.
• Tahsilat: Tutar, para birimi, işlem durumu ve cariyle ilişkilendirme bilgisi.

Eşleştirme tablosu neden önemlidir?

Aynı görünen alanlar farklı anlamlar taşıyabilir. ERP’deki toplam stok ile platformdaki satılabilir stok buna örnektir. Entegrasyon dokümanında alanın adı kadar iş tanımı da bulunmalıdır. Pasife alınan ürünlerin, birleşen cari kayıtların ve değişen adreslerin nasıl ele alınacağı da baştan belirlenmelidir.

Stok ve fiyat bilgileri nasıl güncel tutulur?

Stok aktarımında temel karar, müşteriye hangi miktarın gösterileceğidir. Fiziksel stoktan ayrılmış siparişler, bloke ürünler veya güvenlik stoğu düşülebilir. Birden fazla depo varsa siparişin hangi depodan karşılanacağı ve depolar arası transferin satışa uygunluk hesabına katılıp katılmayacağı açıklığa kavuşturulmalıdır.

Fiyat tarafında ise tek bir ürün fiyatını taşımak çoğu zaman yeterli olmaz. Bayiye özel fiyat listeleri, miktar kademeleri, sözleşme koşulları ve vade farkları sonucu değiştirebilir. Verginin fiyata dâhil olup olmadığı, iskonto sırası ve yuvarlama kuralları iki sistemde aynı sonucu üretmelidir. Dövizli satışlarda kullanılacak kurun kaynağı ve geçerlilik zamanı da tanımlanmalıdır.

Güncelleme sıklığı işin gereksinimine göre seçilir. Hızlı değişen stoklar daha sık, açıklama gibi daha durağan bilgiler daha seyrek aktarılabilir. Ancak ekranda güncel görünen bilgi, sipariş tamamlanana kadar değişebilir. Bu yüzden sipariş onayında stok ve fiyatın yeniden doğrulanması değerlendirilmelidir. Bağlantı kesildiğinde satışın durdurulacağı, beklemeye alınacağı veya kontrollü devam edeceği açık bir karar olmalıdır.

Sipariş aktarımı ve fatura akışı nasıl işler?

Sipariş akışı, müşterinin işlemi tamamlamasıyla başlayabilir; ancak bazı işletmelerde önce satış temsilcisi veya finans onayı gerekir. ERP’ye aktarımın hangi aşamada yapılacağı buna göre belirlenir. Sipariş başlığıyla birlikte ürün satırları, birimler, iskontolar, vergi bilgileri, teslimat adresi ve müşteri referansı taşınmalıdır.

ERP siparişi kabul ettiğinde kendi kayıt numarasını platforma döndürmelidir. Böylece iki sistemdeki kayıtlar izlenebilir biçimde ilişkilendirilir. İletişim zaman aşımına uğradığında aynı siparişin tekrar gönderilmesi mükerrer kayıt oluşturmamalıdır. Bunun için benzersiz işlem anahtarıyla tekrarların güvenli işlenmesi, yani idempotency, tasarıma dâhil edilmelidir.

Sevkiyat ve fatura genellikle siparişten sonra oluşan ayrı olaylardır. Tek siparişin parçalı sevk edilmesi veya birden fazla faturaya dönüşmesi mümkündür. Platform bu ilişkileri doğru göstermelidir. Fatura verisinin aktarılması, elektronik belgenin mevzuata uygun düzenlenmesi ve iletilmesi süreçleriyle aynı işlem olarak değerlendirilmemelidir.

• İptal ve değişikliklerin ERP kaydından önce ve sonra nasıl uygulanacağını belirleyin.
• Kısmi sevkiyat, iade ve eksik karşılanan satırlar için durum eşleştirmesi hazırlayın.
• Müşteriye siparişin alındığını bildirmekle ERP tarafından kabul edildiğini bildirmeyi ayırın.

Cari ve tahsilat süreçleri nasıl bağlanır?

Bayi sistemi ERP entegrasyonu projelerinde cari eşleştirme kritik bir başlangıç noktasıdır. Aynı işletmenin şubeleri, farklı teslimat adresleri ve birden fazla platform kullanıcısı bulunabilir. Kullanıcı hesabı ile muhasebe cari hesabı aynı kavram değildir. Hangi kullanıcının hangi cari adına işlem yapabildiği ve hangi finansal bilgileri görebildiği açıkça tanımlanmalıdır.

Cari bakiye, açık hesap limiti ve vadesi geçmiş borç bilgileri sipariş kararında kullanılabilir. Ancak kontrolün hangi anda yapıldığı önemlidir. Sepet oluşturulurken uygun olan limit, eş zamanlı başka siparişlerle değişebilir. Limit aşımında siparişin reddedilmesi, onaya düşmesi veya farklı ödeme yöntemi istenmesi işletmenin politikasına bağlanmalıdır.

Tahsilat tarafında ödeme bildirimi, doğrulanmış ödeme sonucu ve muhasebeleştirilmiş tahsilat birbirinden ayrılmalıdır. Kullanıcının ödeme ekranından dönmesi tek başına başarı kanıtı sayılmamalıdır. Ödeme sağlayıcısının doğrulanmış işlem bilgisi esas alınmalı; işlem referansı, tutar ve para birimi ERP kaydıyla eşleştirilmelidir. İade, iptal ve kısmi tahsilat senaryoları da mutabakat kapsamına alınmalıdır. Böylece finans ekipleri yalnızca toplam tutarı değil, farklılığın kaynağını da inceleyebilir.

Entegrasyon mimarisi nasıl seçilir?

Mimari seçiminde ERP’nin sunduğu erişim yöntemleri, işlem hacmi, güncellik ihtiyacı ve bakım sorumlulukları birlikte değerlendirilir. Her projede tüm verileri anlık taşımak gerekli değildir. Doğrudan bağlantı daha az bileşen içerebilir; ara katman ise dönüşüm, kuyruklama ve izleme işlerini merkezi olarak yönetmeye yardımcı olabilir.

• API tabanlı bağlantı: Sistemlerin tanımlı servisler üzerinden veri alışverişi yapmasını sağlar; sürüm ve erişim sınırları incelenmelidir.
• Olay tabanlı akış: Değişiklik oluştuğunda bildirim gönderir; kayıp, tekrar ve sıralama durumları yönetilmelidir.
• Zamanlanmış aktarım: Verileri belirli aralıklarla toplar; kabul edilebilir gecikme ve eksik kayıt kontrolü tanımlanmalıdır.
• Dosya tabanlı aktarım: Servis erişiminin sınırlı olduğu durumlarda değerlendirilebilir; dosya doğrulama ve işlenme takibi gerekir.

Güvenlik ve hata yönetimi

Servis hesaplarına yalnızca gerekli yetkiler verilmeli, aktarım şifrelenmeli ve erişim bilgileri güvenli saklanmalıdır. Hatalar izlenebilir kayıtlara dönüştürülmeli; geçici bağlantı sorunlarıyla hatalı veri ayrı ele alınmalıdır. Otomatik yeniden deneme, uyarı ve yetkili kullanıcı müdahalesi birlikte tasarlanmalıdır.

Proje nasıl uygulanır ve test edilir?

Uygulamaya mevcut süreçlerin haritalanmasıyla başlanmalıdır. Satış, finans, depo ve bilgi teknolojileri ekipleri aynı veri sözlüğü üzerinde anlaşmalıdır. İlk aktarımda geçmiş verinin kapsamı belirlenmeli; sonraki güncellemeler için değişikliklerin nasıl yakalanacağı açıklanmalıdır. Canlıya geçiş sırasında eski ve yeni süreçlerin çakışması da önlenmelidir.

• Analiz: Veri kaynaklarını, alan eşleştirmelerini ve iş kurallarını belgeleyin.
• Prototip: Temsili cari, ürün ve siparişlerle uçtan uca akışı doğrulayın.
• Test: Kesinti, tekrar gönderim, stok tükenmesi, fiyat değişimi ve kısmi iade senaryolarını çalıştırın.
• Geçiş: Veri aktarımı, kullanıcı bilgilendirmesi ve geri dönüş planını hazırlayın.
• İzleme: Aktarılmayan kayıtları, bekleyen işlemleri ve mutabakat farklarını takip edin.

Kabul kriterlerini iş sonucuna bağlayın

Bir servisin başarılı yanıt vermesi tek başına yeterli değildir. Doğru cariye, doğru satırlarla ve doğru tutarla işlenen sipariş esas alınmalıdır. Kabul testlerinde sistem kayıtları karşılaştırılmalı ve iş birimlerinin onayı alınmalıdır. Bu yaklaşım, teknik olarak çalışan fakat operasyonel olarak eksik kalan bağlantıların önüne geçmeye yardımcı olur.

Çözüm seçerken hangi sorular sorulmalı?

Teklifleri yalnızca “ERP bağlantısı var” ifadesi üzerinden karşılaştırmayın. Desteklenen ERP sürümü, aktarılacak nesneler, özelleştirme sınırları ve bakım sorumluluğu yazılı kapsamda bulunmalıdır. ERP güncellendiğinde uyumluluk testini kimin yapacağı, hataları kimin izleyeceği ve yeni iş kurallarının nasıl devreye alınacağı netleştirilmelidir.

KMK’nın Kuruma Özel Ticaret Sistemleri çözümü, standart paketlere sığmayan satış, satın alma, bayi ve tedarikçi süreçleri için KMK Core üzerinde geliştirilen bir ticaret sistemidir. Böyle bir yaklaşımı değerlendirirken ERP bağlantısının kapsamı, veri sahipliği ve işletmeye özgü onay akışları proje özelinde doğrulanmalıdır; belirli bir ERP uyumluluğu varsayılmamalıdır.

• Hazır bağlantının kapsadığı işlemler ile ek geliştirme gerektiren alanları ayırın.
• Kesinti ve mükerrer kayıt senaryolarının nasıl yönetileceğini sorun.
• Dokümantasyon, test ortamı, izleme ve destek sorumluluklarını netleştirin.
• Yeni depo, bayi grubu veya şirket eklenmesinin etkisini değerlendirin.

Başarılı B2B ERP entegrasyonu, veri taşıyan bir bağlantıdan fazlasıdır. Cari, stok, fiyat, sipariş, fatura ve tahsilat süreçlerinin ortak kurallarla çalışmasını gerektirir. Çözüm seçiminde veri sahipliğini, hata yönetimini ve kabul kriterlerini baştan netleştirmek; hem günlük operasyonu hem de ileride yapılacak değişiklikleri daha yönetilebilir hâle getirir.

Sık Sorulan Sorular