SAP, Logo ve Mikro ERP Entegre B2B Bayi Sipariş Portalı Kurulum Rehberi

SAP, Logo veya Mikro ERP kullanan üretici, distribütör ve toptancı şirketlerde bayi siparişleri yalnızca bir satış kanalı değildir. Cari hesap, ürün, fiyat, iskonto, stok, sipariş, sevkiyat, fatura ve tahsilat verilerinin aynı süreçte buluştuğu kritik bir operasyon alanıdır. Telefon, e-posta ve elektronik tablo üzerinden yürütülen siparişler büyüdükçe mükerrer kayıt, yanlış fiyat, güncel olmayan stok bilgisi ve geciken durum bildirimi gibi sorunlar ortaya çıkabilir. ERP entegre B2B bayi sipariş portalı, bu dağınık akışı güvenli ve yönetilebilir bir dijital sürece dönüştürmeyi amaçlar.

Başarılı bir portal kurulumu, hazır bir arayüzü ERP’ye bağlamaktan ibaret değildir. Önce kurumun gerçek çalışma biçimi, veri sahipliği, kullanıcı rolleri, ticari kuralları ve istisnaları anlaşılmalıdır. Ardından portal ile ERP arasındaki veri akışları, hata yönetimi ve izlenebilirlik gereksinimleri tasarlanmalıdır. Bu rehber, SAP, Logo ve Mikro için ürüne veya sürüme özel doğrulanmamış özellik vaatleri vermeden, proje kapsamının nasıl kurulacağını adım adım açıklar.

ERP entegre B2B bayi portalı nedir?

ERP entegre bayi portalı; yetkili bayilerin kendilerine açılan ürünleri, fiyatları ve stok bilgilerini görüntüleyebildiği, sipariş oluşturabildiği ve sipariş sonrasındaki süreci takip edebildiği web tabanlı bir iş uygulamasıdır. Portal kullanıcı deneyimini yönetirken ERP çoğu senaryoda cari, ürün, fiyat, stok ve ticari belge kayıtlarının ana kaynağı olmayı sürdürür. Hangi sistemin hangi veride ana kaynak olduğu ise proje başında açıkça belirlenmelidir.

Entegrasyon yöntemi kullanılan ERP ürününe, sürüme, lisansa ve kurulum modeline göre değişir. Örneğin SAP Business One Service Layer, iş nesnelerini HTTP ve OData üzerinden sunan bir entegrasyon katmanıdır. SAP’nin resmi dokümanında OData v4 için Service Layer API referansı yayımlanır. Mikro da ERP entegrasyonları için uç noktaları açıklayan MikroAPI dokümantasyonu sunar. Logo tarafında kullanılabilecek yöntem ise kurulu ürün ve sürüm üzerinde lisans, servis ve destek koşulları doğrulanarak seçilmelidir. Dolayısıyla mimari kararı yalnızca ERP markasına bakarak vermek doğru değildir.

Kurulumdan önce kapsam nasıl çıkarılır?

İlk çalışma, ekran listesi hazırlamak değil süreç keşfi yapmaktır. Satış, finans, lojistik, bayi operasyonları ve BT ekipleri aynı masada mevcut sipariş yaşam döngüsünü çıkarmalıdır. Bayi kim tarafından açılıyor, hangi ürünleri görebiliyor, fiyat hangi koşullarda değişiyor, sipariş ne zaman bağlayıcı hale geliyor ve sevkiyat bilgisi nereden geliyor gibi sorular yanıtlanmalıdır.

İş hedeflerini ve başarı ölçütlerini belirleyin

“Bayi portalı kurmak” tek başına ölçülebilir bir hedef değildir. Manuel sipariş giriş süresini azaltmak, hatalı ürün kodlarını önlemek, fiyat uyuşmazlıklarını düşürmek veya bayinin destek ekibine başvurmadan belgesine ulaşmasını sağlamak gibi somut hedefler tanımlanmalıdır. Başarı ölçütleri; portal üzerinden alınan sipariş oranı, ERP’ye hatasız aktarılan kayıt sayısı, ortalama işlem süresi ve entegrasyon hata çözüm süresi gibi göstergelerle izlenebilir.

Veri sahipliğini netleştirin

Her veri alanı için ana kaynak, aktarım yönü, güncelleme sıklığı ve hata halinde uygulanacak davranış belirlenmelidir. Cari kart ve risk limiti ERP’den portala gelirken teslimat adresi değişikliği onaya düşebilir. Sipariş portalda oluşturulup ERP’ye aktarılabilir; ERP belge numarası ve kabul sonucu yeniden portala dönebilir. Portalın ERP yerine ikinci bir fiyat veya stok gerçeği üretmesi, zaman içinde ciddi tutarsızlıklara yol açar.

• Müşteri, bayi ve teslimat adreslerinin sahibi hangi sistemdir?
• Ürün, birim, koli ve varyant kodları nasıl eşleştirilecektir?
• Fiyat, iskonto, vergi ve para birimi hangi anda hesaplanacaktır?
• Stok bilgisi fiziksel, kullanılabilir veya satılabilir miktarlardan hangisini gösterecektir?
• Sipariş, sevkiyat ve faturanın portal durumları hangi ERP kayıtlarından üretilecektir?

SAP, Logo ve Mikro entegrasyon mimarisi nasıl seçilir?

Kurumsal entegrasyonda portalın doğrudan ERP veritabanına kontrolsüz biçimde yazması yerine üreticinin desteklediği servisler, iş nesneleri veya onaylı entegrasyon katmanları değerlendirilmelidir. Ancak “tek doğru teknoloji” yoktur. SAP ürünü ve sürümü, Logo ailesindeki kurulum, Mikro sürümü, şirketin altyapısı ve ihtiyaç duyulan işlemler birlikte incelenmelidir. Kumsal Ajans’ın SAP danışmanlığı yaklaşımı, teknik bağlantının yanında iş süreçlerini ve kurumsal gereksinimleri birlikte ele almayı hedefler.

Entegrasyon katmanı ERP’ye erişimi portal arayüzünden ayırmalıdır. Böylece kimlik doğrulama, alan eşleştirme, kuyruk yönetimi, yeniden deneme, günlükleme ve sürüm değişiklikleri merkezi olarak yönetilebilir. Gerçek zamanlı sorgu gereken fiyat doğrulama gibi işlemler senkron yürütülebilir; büyük ürün katalogları veya belge aktarımı ise zamanlanmış ya da kuyruk tabanlı çalışabilir. Her çağrıyı gerçek zamanlı yapmak performans ve erişilebilirlik riski yaratabileceği gibi her veriyi toplu aktarmak da güncellik sorununa neden olabilir.

Dayanıklı veri akışının temel kuralları

Sipariş aktarımında her işleme benzersiz bir istek anahtarı verilmesi, aynı talebin bağlantı sorunu nedeniyle iki kez ERP’ye yazılmasını önlemeye yardımcı olur. Başarısız işlemler kaybolmamalı; hata kuyruğuna alınmalı, teknik ve iş kaynaklı hatalar ayrıştırılmalı ve yetkili ekip yeniden deneyebilmelidir. Portal kullanıcıya yalnızca “hata oluştu” demek yerine siparişin alındığını, doğrulama beklediğini veya müdahale gerektiğini anlaşılır biçimde göstermelidir.

Alan eşleştirme belgesi de yaşayan bir proje çıktısıdır. Portal alanı, ERP alanı, veri tipi, zorunluluk, dönüşüm kuralı ve örnek değer aynı tabloda tutulmalıdır. Ürün kodundaki baştaki sıfırlar, farklı ölçü birimleri, döviz hassasiyeti ve firma-dönem ayrımları test edilmediğinde küçük görünen farklılıklar sipariş reddine dönüşebilir.

Ürün, fiyat ve stok deneyimi nasıl tasarlanır?

Bayi yalnızca yetkili olduğu ürün grubunu, satış organizasyonunu veya markayı görmelidir. Ürün kartında ticari ad, bayi ürün kodu, satış birimi, koli içeriği, minimum miktar ve gerekli teknik belgeler sunulabilir. Geniş kataloglarda arama, filtre, favoriler ve önceki siparişten tekrar ekleme işlevleri sipariş süresini kısaltır.

Fiyat alanında liste fiyatı göstermek çoğu B2B senaryosu için yeterli değildir. Bayi, sözleşme, miktar basamağı, kampanya, para birimi, ödeme koşulu ve manuel yetki bir araya gelebilir. Öncelik sırası ve çakışma davranışı açıklanabilir olmalıdır. Bu konunun ayrıntıları bayi portalında özel fiyat ve iskonto kuralları rehberindeki gibi ayrı bir kural modeliyle ele alınabilir. Sepette gösterilen tutar ile ERP’nin kabul ettiği tutar farklıysa sipariş sessizce değiştirilmemeli; fark kullanıcıya veya onay yetkilisine bildirilmelidir.

Stok etiketi de kapsamlı tanımlanmalıdır. “Stokta var” ifadesinin hangi depo, rezervasyon ve bekleyen sipariş koşuluna göre üretildiği bilinmelidir. Kesin miktar göstermek ticari açıdan uygun değilse uygun, sınırlı veya termin sorunuz gibi kontrollü seviyeler kullanılabilir. ERP erişilemediğinde son güncelleme zamanı gösterilmeli ve eski veri yeniymiş gibi sunulmamalıdır.

Hızlı sipariş, toplu yükleme ve onay akışları

Sık sipariş veren bayiler için katalog gezintisinin yanında ürün kodu ve miktarla hızlı giriş sunulmalıdır. Çok satırlı siparişlerde Excel veya CSV yükleme; dosya şablonu, sütun eşleme, satır bazlı doğrulama ve gönderim önizlemesiyle tasarlanmalıdır. Hatalı bir satır yüzünden tüm dosyanın belirsiz biçimde reddedilmesi yerine sorunlu ürün kodu, miktar veya birim kullanıcıya açıkça gösterilmelidir. Ayrıntılı tasarım için B2B toplu sipariş rehberi dikkate alınabilir.

Her sipariş doğrudan ERP’ye kesin kayıt olarak gönderilmek zorunda değildir. Bayi kullanıcısının yetkisi, sipariş tutarı, vade, risk limiti, iskonto oranı veya istisnalı ürünler bir onay süreci başlatabilir. Talep eden, onaylayan ve ERP’ye gönderen roller ayrılmalı; vekâlet, ret gerekçesi ve süre aşımı kuralları tanımlanmalıdır. Onay geçmişi sonradan değiştirilemeyen bir denetim iziyle saklanmalıdır.

Siparişten teslimata görünürlük

Portalın değeri sipariş ERP’ye aktarıldığında sona ermez. Bayi; siparişin alındığını, onaylandığını, kısmen hazırlandığını, sevk edildiğini veya kapandığını görebilmelidir. Portal durumları ERP ve lojistikteki teknik kodların doğrudan kopyası değil, bayi için anlaşılır bir durum sözlüğü olmalıdır.

Kısmi sevkiyatlarda sipariş başlığı yerine satır ve miktar düzeyinde görünürlük gerekir. İrsaliye, fatura ve ilgili belgeler yetkiye bağlı olarak indirilebilir; her belge doğru cari ve siparişle ilişkilendirilmelidir. Taşıyıcı entegrasyonu varsa takip numarası ve teslim bilgisi ayrıca gösterilebilir. Bu yaşam döngüsünün ayrıntıları B2B sipariş takip portalı planlama rehberinde ele alınır.

Roller, yetkiler ve veri güvenliği

B2B portalında bayi şirketi, şube, kullanıcı ve rol birbirinden ayrılmalıdır. Satın almacı sipariş oluştururken yönetici onay verebilir; finans kullanıcısı bakiye ve faturaları görebilir fakat fiyat değiştiremez. İç ekiplerde destek kullanıcısı bayi adına işlem yapacaksa bu işlem açıkça etiketlenmeli ve kim tarafından yapıldığı kaydedilmelidir.

Güvenlik yalnızca giriş ekranına parola koymak değildir. Çok faktörlü kimlik doğrulama, güçlü oturum yönetimi, en az yetki ilkesi, aktarım sırasında şifreleme, gizli anahtarların güvenli saklanması ve düzenli yedekleme değerlendirilmelidir. Portal ile ERP arasındaki servis hesabına yalnızca gerekli işlemler için izin verilmelidir. Kişisel ve ticari veriler için saklama süreleri, erişim kayıtları ve olay müdahale sorumlulukları tanımlanmalıdır.

Test, pilot ve canlıya geçiş planı

Testler yalnızca başarılı bir sipariş örneğini kapsamamalıdır. Geçersiz ürün, kapanmış cari, yetersiz stok, fiyat değişimi, bağlantı kesintisi, mükerrer gönderim, kısmi sevkiyat ve belge yetkisi gibi senaryolar denenmelidir. ERP’nin test ortamı yoksa canlı veriyi riske atmayan kontrollü bir doğrulama yöntemi oluşturulmalıdır.

• Birim ve alan eşleştirmeleri örnek gerçek verilerle doğrulanmalıdır.
• Yetki matrisi her rol için olumlu ve olumsuz senaryolarla test edilmelidir.
• Yoğun katalog, toplu sipariş ve eş zamanlı kullanıcı yükü ölçülmelidir.
• ERP kesintisi ve yeniden bağlantı sonrasında kuyruk davranışı sınanmalıdır.
• Finans, satış ve lojistik ekiplerinden kullanıcı kabul onayı alınmalıdır.

Canlıya geçişte sınırlı sayıda bayiyle pilot uygulama yapmak, gerçek kullanım sorunlarını kontrollü biçimde görmeyi sağlar. Pilot boyunca destek kanalı, hata öncelikleri ve geri dönüş süreleri belirlenmelidir. Yayın sonrasında entegrasyon başarı oranı, kuyruk uzunluğu, geciken işlemler ve API yanıt süreleri izlenmeli; sürüm güncellemeleri için regresyon testleri planlanmalıdır.

Sürdürülebilir bir B2B portalı için proje yaklaşımı

ERP entegre portal, bir defalık teslim edilen sabit bir site değil, iş kuralları değiştikçe gelişen kurumsal bir uygulamadır. Yeni bayi tipleri, depolar, fiyat modelleri ve onay gereksinimleri mimarinin genişleyebilmesini gerektirir. Bu nedenle kapsam dokümanı, veri sözlüğü, entegrasyon sözleşmeleri, yetki matrisi ve işletim prosedürleri yazılım kadar önemlidir.

Kumsal Ajans, İstanbul merkezli bir dijital ajans olarak iş süreçleri, kullanıcı rolleri, veri ve entegrasyon ihtiyaçlarına göre projeye özel web yazılımları geliştirir. ERP ve SAP danışmanlığını web yazılım, mobil uygulama, e-ticaret ve kurumsal kaynak planlaması yetkinlikleriyle birlikte ele alır. Amaç tek tip bir ürün dayatmak değil; kurumun gerçek işleyişine uyarlanan, güvenli, güçlü altyapıya sahip ve sürdürülebilir bir bayi portalı mimarisi kurmaktır.

SAP, Logo veya Mikro ERP’nize bağlı bayi sipariş portalının kapsamını, entegrasyon akışlarını ve kullanıcı rollerini Kumsal Ajans ile planlamak için iletişime geçin.