Alt Bayi Komisyon Sistemi E-Pin Scriptinde Nasıl Çalışır?

Bir e-pin satış sitesine ilk bayiyi eklemek kolaydır; zor olan, o bayinin altına kendi müşterilerini getiren ikinci, üçüncü bir bayi katmanı açıldığında sistemin hâlâ doğru hesap yapmasıdır. Kim, hangi üründen, hangi yüzdeyle kazanacak? Bu hesap elle yapılmaya başladığı an, ya bayiler kazancından şüphelenmeye başlar ya da işletme sahibi her ay saatlerini tablo karşılaştırmaya harcar. Bu yazıda alt bayi komisyon mantığının bir e-pin scriptinde teknik olarak nasıl işlediğini, hangi noktalarda hata payının en yüksek olduğunu ve Pinova'nın bu süreci nasıl otomatik hale getirdiğini anlatıyoruz.

Çok Seviyeli Bayilik Gerçekte Ne Anlama Gelir?

"Alt bayi" kavramı çoğu zaman yanlış anlaşılır: sanki ana bayinin cirosundan pay veren ayrı bir sistemmiş gibi düşünülür. Oysa doğru kurulmuş bir çok seviyeli bayilik yapısında her seviye, bir üsttekinin belirlediği fiyat üzerinden kendi kâr marjını ekleyerek satış yapar — cironun bölünmesi değil, fiyatlandırmanın katmanlanmasıdır.

Pratikte yapı genelde şöyle işler:

• Ana bayi (site sahibi): Tedarikçiden (Turkpin, Pinabi gibi API'ler) ürünü toptan fiyattan alır.
• 1. seviye bayi: Ana bayinin belirlediği bayi fiyatından ürünü çeker, kendi müşterisine satar.
• 2. seviye (alt) bayi: 1. seviye bayinin açtığı kendi paneli üzerinden, ona tanımlanan fiyat üzerinden satış yapar.

Her katman kendi kâr farkını korur; sistem sadece bu farkı doğru hesaplayıp doğru cüzdana yazmakla yükümlüdür. Sorun, çoğu hazır script veya elle yönetilen sitede bu zincirin sadece iki seviyeyle sınırlı kalması ya da üçüncü seviyeden itibaren manuel takibe dönmesidir.

Komisyon Yüzdelerini Kim, Nasıl Belirler?

Komisyon, sabit bir yüzde değil; çoğu zaman ürün kategorisine, bayi seviyesine ve hatta kampanya dönemine göre değişen dinamik bir değerdir. Bir e-pin scriptinde bu yapı iki katmanlı çalışmalıdır:

• Genel bayi kademesi indirimi: Bayi hangi gruba dahilse (Bronz/Gümüş/Altın gibi), o grubun ürün geneline uygulanan yüzde iskonto.
• Ürün bazlı özel fiyat: Belirli bir oyun kodunda tedarikçi marjı düşükse, o üründe kademe yüzdesinin ezilmesi veya sabit fiyat tanımlanması.

Pinova'da bu, bayi grubu + ürün eşleşmesi üzerinden çalışan bir fiyat matrisi ile çözülür. Yönetici bir kademeye "%8 iskonto" tanımladığında bu otomatik olarak o kademedeki tüm bayilerin gördüğü fiyata yansır; istisna gereken ürünlerde ise elle geçersiz kılma (override) yapılabilir. Alt bayi açıldığında, üst bayi kendi gördüğü fiyat üzerinden yeni bir kademe belirler — sistem alt kademenin üst kademeden daha ucuz satamayacağını otomatik kontrol eder, aksi halde negatif kâr oluşabilir.

Her Bayi Aynı Fiyatı mı Görür?

Hayır — ve asıl karmaşa burada başlar. Aynı ürün, panelde oturum açan bayiye göre farklı bir fiyatla görünmelidir. Bu, ürün başına sabit fiyat tutan basit scriptlerde mümkün değildir; sistemin her istek anında "bu kullanıcı hangi kademede, bu ürüne o kademede tanımlı fiyat ne" sorgusunu gerçek zamanlı çalıştırması gerekir.

Aşağıdaki tablo, bu hesaplamanın elle mi yoksa otomatik mi yapıldığında ne fark yarattığını gösteriyor:

Kazanç Bayiye Tam Olarak Ne Zaman Yansır?

Komisyonun doğru hesaplanması yetmez; kazancın ne zaman ve nasıl bayiye ulaştığı da ayrı bir tasarım kararıdır. İki yaygın model vardır:

• Anlık cüzdan yansıması: Alt bayi satış yaptığı an, üst bayinin cüzdanına fark otomatik işlenir. Bu, Pinova'nın site cüzdanı/bakiye altyapısında tercih edilen yöntemdir çünkü nakit akışı gecikmesiz, şeffaf ve tartışmasızdır.
• Dönemsel hakediş (mutabakat): Kazanç biriktirilir, belirli aralıkla (haftalık/aylık) toplu olarak ödenir. Daha çok yüksek hacimli, kurumsal bayilik ilişkilerinde tercih edilir.

Anlık modelde teknik olarak kritik nokta, işlemin atomik olmasıdır: bir e-pin teslimatı gerçekleşirken hem stok düşülmeli hem üst bayinin bakiyesine kâr farkı eklenmeli hem de alt bayinin bakiyesinden tutar çekilmeli — bu üç işlem tek bir veritabanı transaction'ı içinde yapılmazsa, sunucu hatası anında bakiyeler tutarsız kalabilir. Pinova bu üç adımı tek işlemde kilitleyerek, yarım kalan satışların bakiye tutarsızlığına yol açmasını engeller.

Excel ile Alt Bayi Takibi Neden Er Geç Patlar?

Küçük ölçekte — 2-3 bayiyle — elle takip idare eder. Ancak alt bayi sayısı arttıkça üç sorun kaçınılmaz hale gelir:

• Fiyat senkron hatası: Ana fiyat listesi güncellenince her bayinin tablosunun ayrı ayrı güncellenmesi unutulur, bayiler eski fiyattan satış yapmaya devam eder.
• Gecikmeli mutabakat anlaşmazlığı: Bayi "ben daha fazla sattım" der, işletme sahibi elindeki tabloyla karşılaştırır; ikisi de farklı kaynaktan geldiği için güven sorunu doğar.
• Ölçeklenemeyen büyüme: 5 alt bayiden 50'ye çıkıldığında, elle yönetim tamamen imkânsız hale gelir — büyüme bir noktada durur çünkü operasyon yükü satıştan hızlı büyür.

Bu üç sorun da aslında tek bir kök nedene iniyor: kazanç ve fiyat bilgisinin tek, otomatik, herkesin aynı anda gördüğü bir kaynaktan gelmemesi. Script tabanlı bir çözümde bu kaynak veritabanıdır; panelde görünen her rakam aynı sorgudan gelir, dolayısıyla bayi ile işletme sahibi farklı sayılar görmez.

Alt Bayiler Kazancını Nasıl Görür, Suistimal Nasıl Önlenir?

Şeffaflık, bayilik ilişkisinin sürdürülebilirliğinin temelidir. Her bayi kendi panelinde şunları görebilmelidir:

• Güncel bakiyesi ve son işlem geçmişi
• Kendi altındaki alt bayilerin (varsa) satış hacmi ve kendisine yansıyan kâr farkı
• Ürün bazlı güncel fiyat listesi ve kademesine özel iskontolar

Suistimal riski genelde iki noktada ortaya çıkar: bir bayinin kendi hesabına sahte sipariş oluşturup stok/bakiye manipüle etmesi, ya da fiyat matrisindeki bir açıktan yararlanarak üst kademeden ucuza mal çekmesi. Bunu önlemek için sistemde işlem loglarının değiştirilemez (immutable) tutulması, her fiyat değişikliğinin kim tarafından ne zaman yapıldığının kaydedilmesi ve şüpheli hızlı-ardışık işlemlerde otomatik uyarı mekanizması bulunması gerekir. Pinova'da admin paneli, tüm bayi hareketlerini ve fiyat geçmişini geriye dönük filtrelenebilir şekilde tutar — bir anlaşmazlık çıktığında "kim ne zaman ne satın aldı" sorusu saniyeler içinde cevaplanır.