B2B bayi portalı: ERP'ye sipariş yazarken kırılan yerler

Zor kısım arayüz değil

Bayi portalı projeleri genelde ekran tasarımıyla başlar: ürün listesi, sepet, sipariş geçmişi. Bu kısım iki haftada biter ve iyi görünür.

Proje, siparişin ERP’ye yazıldığı satırda kırılır. Aşağıdaki dört sorunun cevabı yanlışsa portal çalışıyor görünür ama sahada güven kaybeder:

1. Bayiye gösterilen fiyat nereden geldi?
2. “Stokta var” derken hangi stok kastedildi?
3. Bayi limitini aştığında sipariş ne oldu?
4. Bayi düğmeye iki kez bastığında kaç sipariş açıldı?

Bu yazı o dört satırı anlatıyor.

1. Fiyat: portalda hesaplanmaz, ERP’den okunur

Türkiye’de bayi fiyatı tek bir liste değildir. Üstünde şunlar durur: cariye özel fiyat, iskonto kademesi, miktar barajı, kampanya ve vade farkı. Bu kuralların hepsi ERP’de tanımlıdır ve ERP’de değişir.

Portal bu mantığı kendi içine kopyaladığında şu olur: satış müdürü ERP’den iskontoyu günceller, portal haberi olmadan eski fiyattan satmaya devam eder. Fark, faturalar kesildikten sonra fark edilir ve geriye dönük düzeltilir.

Kural: fiyat her zaman ERP’den, sipariş anında, o cari için okunur. Portal fiyatı önbelleğe alacaksa bile ömrü kısa tutulur ve sipariş yazılmadan hemen önce yeniden doğrulanır.

2. Stok: fiziksel değil serbest miktar

İkinci klasik hata, depodaki fiziksel miktarı “stokta var” diye göstermektir.

Fiziksel stok gösteren portalda aynı 40 adet, üç ayrı bayiye söz verilir. Üçü de sipariş geçer, ikisi eksik sevkiyat alır ve telefon satış ekibine gelir — portalın çözmesi gereken problem geri döner.

Serbest stok hesabı ERP’de yapılmalıdır; portal onu okur. Portalın kendi rezerv tablosunu tutması, iki sistemin birbirini tutmadığı ikinci bir gerçek yaratır.

3. Risk limiti: sipariş yazılmadan önce

Bayinin açık bakiyesi ve risk limiti ERP’de durur. Portal siparişi yazmadan önce ikisini okur ve üç sonuçtan birini üretir:

• Limit içinde → sipariş normal yazılır.
• Limit aşılıyor → sipariş kaydedilir ama onay bekliyor durumuna alınır, satış sorumlusuna düşer.
• Cari kapalı / bloke → sipariş alınmaz, sebebi bayiye açıkça yazılır.

İkinci seçenek çoğu projede atlanır ve iki uçtan biri seçilir: ya limit hiç kontrol edilmez (finans sonradan öğrenir), ya da sipariş doğrudan reddedilir (bayi portalı kullanmayı bırakır, telefona döner). Doğru davranış, siparişin alınıp sevkiyatın onaya bağlanmasıdır.

4. Çift sipariş: belge numarasıyla tekilleştirme

Bayi düğmeye bastı, ağ koptu, ekranda bir şey olmadı, tekrar bastı. Kaç sipariş açıldı?

Arayüzde düğmeyi kilitlemek bu problemi çözmez; istek zaten yola çıkmıştır. Tek gerçek çözüm tekilleştirme anahtarıdır:

• Portal her sipariş için kendi belge numarasını üretir (WEB-2026-000118 gibi).
• Sipariş ERP’ye bu numarayla yazılır.
• Aynı numarayla gelen ikinci istek yeni kayıt açmaz, mevcut kaydın durumunu döner.

Bu numara aynı zamanda destek görüşmelerinin ortak dilidir: bayi “WEB-118 ne oldu?” der, satış aynı numarayı ERP’de arar.

Siparişi ERP’ye yazmanın yolu

Yazma yolu kullandığınız ERP’ye göre değişir, ama ortak kural aynıdır: kayıt, ERP’nin kendi iş kuralları çalıştırılarak oluşturulur. Tablolara doğrudan INSERT yapılmaz — sipariş listede görünür ama stok düşmez, maliyet oluşmaz, muhasebe fişi yazılmaz.

Üçünde de okuma tarafı daha esnektir: stok, fiyat ve bakiye sorguları için veritabanı okuma yolları kullanılabilir. Yazma tarafı ise resmi arayüzden geçer.

Kesintiye dayanıklılık: araya kuyruk

ERP sunucusu bakımdayken, yeniden başlatılırken veya ağ koptuğunda portal ayakta kalmalıdır. Bunun yolu, portal ile ERP arasına kuyruk koymaktır:

Kuyruksuz kurulumlarda kesinti anındaki siparişler sessizce kaybolur — ve kaybolduğu, bayi arayana kadar anlaşılmaz.

ERP’de kalması gereken işler

Portal her şeyi devralmaz. Aşağıdakiler ERP’de kalır:

• e-Fatura ve e-İrsaliye. Mevzuata bağlıdır; üretici mevzuat değişince güncellemeyi kendisi yapar. Portal yalnızca belge durumunu okuyup gösterir.
• Muhasebe ve cari kayıt. Portal bakiyeyi okur, oluşturmaz.
• Maliyet. Sipariş ERP’de oluştuğu için maliyet zinciri kendiliğinden işler.

Bu ayrımın gerekçesini ayrıntısıyla “ERP’yi özelleştirmeyin diyenler haklı — ama hangi durumda?” yazısında anlattık.

Neden ERP’ye bayi kullanıcısı açılmıyor

Bu projenin ticari gerekçesi çoğu zaman teknik gerekçesinden önce gelir: paket ERP’ler kullanıcı başına ücretlendirilir.

Elli bayiye ERP oturumu açmak elli ek kullanıcı demektir ve bu ücret her yıl tekrar eder. Portal ise ERP’ye tek bir servis hesabıyla bağlanır; bayi sayısı beşe de çıksa beş yüze de çıksa ERP lisansı değişmez.

Ayrıca ERP oturumu bayiye şirket içi verinin tamamına kapı açar. Portal, bayinin yalnızca kendi cari hesabını görmesini sağlar — yetki sınırı uygulamada tanımlıdır, ERP’de değil.

Devreye alma sırası

1. Okuma önce. Bayi kendi bakiyesini, ekstresini ve serbest stoğu görsün. Sipariş henüz yok. Bu aşama tek başına telefon trafiğini azaltır ve veri eşlemesini doğrular.
2. Sipariş, onaylı modda. Siparişler portalda toplanır, satış sorumlusu ERP’ye yazılmadan önce onaylar. İlk hafta böyle çalışın; alan eşlemesindeki hatalar burada yakalanır.
3. Doğrudan yazma. Onay adımı kaldırılır, sipariş doğrudan ERP’ye gider. Limit aşan siparişler onayda kalmaya devam eder.

Bu sıra, canlıya alma riskini üç parçaya böler. Tek seferde açılan portallarda ilk hafta yanlış fiyattan geçen siparişler geri alınmak zorunda kalır.

Kabul testinde şunu bir kez çalıştırın

Uçtan uca tek bir zincir: bayi sipariş geçer → ERP’de sipariş fişi oluşur → irsaliye kesilir → fatura kesilir. Sonra tutarları ERP ekranından okuyup portalın gösterdiğiyle karşılaştırın.

Kuruş farkı çıkarsa sebebi neredeyse her zaman iskonto sırası veya KDV yuvarlama kuralıdır. Bu farkı canlıda düzeltmek, testte düzeltmekten çok daha pahalıdır.

---

Kendi ERP’nizin üzerine bayi portalı kurmayı konuşmak için sürecinizi anlatın. İlk görüşme 30 dakika ve ücretsizdir; fiyat bantlarını önceden görebilirsiniz.

---

İlgili Depo Rehberleri ve Hesaplayıcılar

• Sevkiyat Hatası ve İade Maliyeti Hesaplayıcı — Deponuzdaki yanlış ürün gönderimlerinin yıllık çift kargo maliyetini hesaplayın.
• En İyi WMS ve Barkodlu Depo Yönetim Programları — Logo, Mikro, Nebim, DİA ve özel WMS sistemleri karşılaştırması.
• Depo Sevkiyat ve Barkod Kontrol Fiyatları — Paketleme masası ve doğrulama istasyonu bütçe rehberi.
• WMS Depo Yazılımı Fiyatları 2026 — Depo otomasyonu ve adresli raf yönetimi maliyetleri.

Sıkça sorulan sorular

B2B bayi portalı nedir?

Bayilerin kendi cari hesap bakiyesini, kendilerine özel fiyat listesini ve güncel stok durumunu görüp sipariş geçtiği web uygulamasıdır. Sipariş, telefon veya e-posta yerine doğrudan ERP'ye yazılır. Bayiye ERP kullanıcısı açılmadığı için ek kullanıcı lisansı doğmaz; portal ERP'ye tek bir servis hesabıyla bağlanır.

Bayi portalında fiyat nereden gelmeli?

Her zaman ERP'den okunmalıdır, portalda hesaplanmamalıdır. Cari özel fiyat, iskonto kademesi, kampanya ve vade farkı kuralları ERP'de tanımlıdır ve orada değişir. Fiyat mantığı portala kopyalandığında, ERP'de iskonto güncellenir güncellenmez portal eski fiyattan satmaya devam eder ve fark aylar sonra faturada görülür.

Bayiye hangi stok gösterilmeli?

Fiziksel stok değil, serbest stok gösterilmelidir: depodaki miktardan açık siparişlerle rezerve edilmiş miktar düşülür. Fiziksel stok gösteren portallarda aynı ürün birden fazla bayiye söz verilir ve eksik sevkiyat telefonu kaçınılmaz olur. Serbest stok hesabı ERP'de yapılmalı, portal onu okumalıdır.

Bayi kredi limitini aşan sipariş geçerse ne olur?

Kontrol sipariş ERP'ye yazılmadan önce yapılmalıdır. Portal, cari risk limitini ve açık bakiyeyi ERP'den okur; limit aşılıyorsa sipariş kaydedilir ama onay bekler duruma alınır ve satış sorumlusuna düşer. Böylece bayi sipariş geçebildiğini görür, sevkiyat ise finans onayına bağlı kalır.

Bayi portalı siparişi ERP'ye nasıl yazar?

Yol ERP'ye göre değişir. Logo tarafında REST servisi veya Logo Objects, Netsis tarafında REST API veya NetOpenX, Mikro tarafında resmi Mikro API kullanılır. Ortak kural şudur: kayıt ERP'nin kendi iş kuralları çalıştırılarak oluşturulmalı, tablolara doğrudan INSERT yapılmamalıdır. Aksi hâlde sipariş görünür ama stok, maliyet ve muhasebe zinciri oluşmaz.

İnternet veya ERP kesintisinde sipariş kaybolur mu?

Doğru kurulmuş portalda kaybolmaz. Portal ile ERP arasına kuyruk konur: ERP erişilemezken siparişler kuyrukta bekler, bağlantı geldiğinde sırayla işlenir. Bayi ekranında sipariş 'alındı, işleniyor' olarak görünür. Kuyruk yoksa ERP'nin bakım veya yeniden başlatma anında geçilen siparişler sessizce kaybolur.

Aynı sipariş iki kez yazılmasın diye ne yapılır?

Her siparişe portal tarafında üretilen bir belge numarası verilir ve ERP'ye bu numarayla yazılır. Ağ koptuğunda istemci isteği tekrarlarsa, aynı belge numarasıyla gelen ikinci istek yeni kayıt açmaz, mevcut kaydın durumunu döner. Çift sipariş probleminin tek gerçek çözümü budur; kullanıcı arayüzünde düğmeyi kilitlemek yeterli değildir.

e-Fatura ve e-İrsaliye portalda mı kesilir?

Hayır, ERP'de kalır. e-Belge süreçleri mevzuata bağlıdır ve üretici mevzuat değiştiğinde güncellemeyi kendisi yapar. Portal yalnızca belgenin durumunu ve numarasını okuyup bayiye gösterir. Bu işi portala taşımak, mevzuat takibini kendi üzerinize almak anlamına gelir.

Bayi portalı için ERP kullanıcı lisansı almak gerekir mi?

Hayır, projenin ticari mantığı zaten budur. Paket ERP'ler kullanıcı başına ücretlendirilir; elli bayiye ERP oturumu açmak elli ek kullanıcı demektir ve bu ücret her yıl tekrar eder. Portal ERP'ye tek bir servis hesabıyla bağlanır, bayi sayısı ERP lisansını etkilemez.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti