Komisyon ve hak ediş hesabını Excel'den yazılıma taşımak

Komisyon ve hak ediş hesabı çoğu şirkette bir Excel dosyasıyla başlar. Başta yeterlidir: birkaç satış temsilcisi, tek bir oran, ay sonunda bir toplam. Sorun, iş büyüdükçe dosyanın sessizce karmaşıklaşmasıdır. Yeni bir oran istisnası, bir bayi için farklı maliyet, iptal edilen bir siparişin geriye dönük düşülmesi derken dosya kimsenin tam olarak açıklayamadığı bir formüller yığınına dönüşür.

Bu yazıda, bu hesabı yazılıma taşımanın ne zaman mantıklı olduğunu ve geçişte hangi kararların önemli olduğunu anlatıyoruz. Örneklerimiz kendi geliştirdiğimiz üç sistemden: harici API'den randevu verisi çekip komisyon hesaplayan Komisyon Rapor Sistemi, kurumsal satışlar için 40 günlük hak ediş süresini takip eden WooCommerce eklentisi ve 3 seviyeli komisyon dağıtımı yapan Affiliate MLM Yönetim Sistemi.

Excel ne zaman yetmez?

Excel kötü bir araç değildir; sorun, onu bir hesap motoru ve kayıt sistemi olarak kullanmaktır. Aşağıdaki işaretlerden birkaçı varsa hesap artık dosyanın taşıyabileceğinden ağırdır.

• Veri elle kopyalanıyor. Satış ya da randevu bilgisi başka bir sistemden indirilip dosyaya yapıştırılıyorsa her ay hata riski yeniden doğar.
• Oranlar kişiye, kuruma ya da ürüne göre değişiyor ve bu istisnalar formüllerin içine gömülü.
• Hak ediş bir koşula bağlı: sipariş iptal edilmemiş olmalı, belli bir süre geçmiş olmalı.
• Komisyon birden fazla kişiye, birden fazla seviyede dağıtılıyor.
• "Bu rakam nereden çıktı?" sorusunun cevabını yalnızca dosyayı hazırlayan kişi verebiliyor.
• Rapor her dönem elle biçimlendirilip PDF'e çevriliyor.

Bu işaretler yalnızca satış komisyonu için geçerli değil. Prim, bayi payı, ortaklık geliri ya da hizmet bazlı hak ediş fark etmez; ortak nokta, bir tutarın bir kurala göre hesaplanıp birine borçlanmasıdır. Kural sayısı ve kişi sayısı arttıkça hata payı da büyür. Ölçek küçükken elle kontrol mümkündür, ama aynı kişi her ay yüzlerce satırı tek tek kontrol etmeye başladığında ortada artık bir süreç değil, bir darboğaz vardır. Bir de kuruş meselesi var: yuvarlamanın satır bazında mı yoksa toplamda mı yapılacağı belirlenmemişse iki farklı dosya aynı ay için farklı sonuç verir ve kimse hangisinin doğru olduğunu söyleyemez.

Önce kuralları yazıya dökün

Yazılıma geçişin ilk adımı kod değil, kural envanteridir. Excel'deki her formülün iş dilindeki karşılığı yazılmalı: hangi satış komisyona girer, oran neye göre değişir, iptal ve iade nasıl düşülür, hangi tarih esas alınır. Bu çalışma çoğu zaman şirketin kendi kurallarında çelişkiler bulmasıyla sonuçlanır ve bu iyi bir şeydir.

Kurallar netleştikten sonra en önemli tasarım kararı, oranların koda değil veriye yazılmasıdır. Komisyon Rapor Sistemi'nde komisyon yapıları ve oranlar özelleştirilebilir; MLM sisteminde seviye oranları sistem ayarlarından değiştirilebiliyor. Oran değiştiğinde geliştirici çağırmak zorunda kalıyorsanız Excel'in esnekliğini kaybetmiş ama disiplinini kazanamamışsınız demektir.

Burada sık atlanan bir ayrıntı var: oran değiştiğinde geçmiş hesaplar değişmemeli. Her hesaplama, o an geçerli olan kuralın bir kopyasını ya da sürüm numarasını saklamalıdır.

// Basitleştirilmiş örnek: hesap, kullandığı kuralı yanında saklar
const kural = await kurallar.gecerliOlan({ kurumId, tarih: siparis.tarih })

const hesap = {
  siparisId: siparis.id,
  tutar: siparis.tutar,
  oran: kural.oran,
  kuralSurumu: kural.surum,   // oran sonradan değişse de bu kayıt değişmez
  komisyon: yuvarla(siparis.tutar * kural.oran),
  durum: 'bekleniyor'
}

Veri kaynağına doğrudan bağlanmak

Excel'den çıkmanın en büyük kazancı, elle kopyalamanın ortadan kalkmasıdır. Hesap, verinin üretildiği sistemden doğrudan beslenmelidir.

Komisyon Rapor Sistemi'nde kaynak, harici bir randevu sisteminin API'siydi. Uygulama randevu verilerini API üzerinden çekiyor, çeşitli kriterlere göre komisyon algoritmalarını uyguluyor ve sonucu filtrelenebilir bir yönetim panelinde gösteriyor. WooCommerce hak ediş eklentisinde ise kaynak mağazanın kendisi: siparişler doğrudan WooCommerce'ten okunuyor ve eklenti, WooCommerce'in yüksek performanslı sipariş depolama altyapısı HPOS ile uyumlu çalışıyor. Bu ayrıntı önemli, çünkü sipariş tablolarına doğrudan sorgu atan eklentiler bu altyapıya geçildiğinde bozulabiliyor.

API'den beslenen bir sistemde dikkat edilecek nokta, kaynak verinin değişebileceğidir. İptal edilen bir randevu ya da iade edilen bir sipariş, daha önce hesaplanmış bir komisyonu etkiler. Bu yüzden hesaplama tek seferlik bir dışa aktarma değil, kaynakla eşitlenen bir süreç olarak tasarlanmalı.

Hak ediş: komisyonun ne zaman kesinleştiği

Komisyon hesaplamak ile komisyonu ödenebilir saymak farklı şeylerdir. WooCommerce eklentisinde bu ayrımı açıkça kurduk: "Hazırlanıyor" veya "Tamamlandı" durumundaki kurumsal siparişler için 40 günlük bir hak ediş sayacı başlıyor. Her sipariş Uygun, Bekleniyor veya İptal olarak sınıflanıyor; süre dolmadan ya da sipariş iptal edilmişse komisyon ödenebilir sayılmıyor.

Aynı eklentide kuruma özel maliyet, internet satış fiyatı ve komisyon hesapları ayrı ayrı tanımlanabiliyor. Bayi, uygun hale gelen tutar için ön yüzden "Talep Gönder" ile ödeme talebi oluşturabiliyor; bu istekler nonce doğrulamasıyla korunuyor. Böylece bayi ile muhasebe arasında e-posta ve tablo trafiği yerine kayıt altına alınan bir talep akışı oluşuyor.

Çok seviyeli dağıtım ve raporlama

Tek bir satıştan birden fazla kişiye pay dağıtılıyorsa Excel'de en hızlı bozulan kısım burasıdır. Affiliate MLM Yönetim Sistemi'nde her satış ve üyelik için komisyon 3 seviyeye (X, Y, Z) otomatik dağıtılıyor. Referans kodlarıyla kurulan üyelik ağacı veritabanında tutulduğu için kimin kimin altında olduğu tartışma konusu olmuyor. Aynı sistemde aylık aidat takibi, gecikme uyarıları ve rol tabanlı yetkilendirme de var; her kullanıcı yalnızca görmesi gereken veriyi görüyor.

Raporlama ise hesabın görünür yüzüdür. Üç sistemde de rapor elle hazırlanmıyor: Komisyon Rapor Sistemi grafikli PDF raporlar ve farklı formatlarda dışa aktarma sunuyor, WooCommerce eklentisi TCPDF ile marka logolu ve ayrıntılı finansal tablolar içeren PDF'i tek tıkla üretiyor, MLM sistemi tarih aralığına göre filtrelenen Excel ve PDF çıktıları veriyor. Excel'den çıkmak Excel'i yasaklamak demek değil; dosya artık hesabın kaynağı değil, sistemin çıktısı oluyor.

İtiraz, denetim izi ve geçiş planı

İyi bir komisyon sistemi, itiraz geldiğinde rakamın nereden çıktığını adım adım gösterebilmelidir: hangi sipariş, hangi oran, hangi kural sürümü, hangi tarihte hangi durumda. WooCommerce eklentisindeki kilitli aktivasyon mekanizması, Aktivasyon Guard, bu ihtiyacın bir örneği: geçmiş verilerin sonradan yapılan bir aktivasyon işlemiyle ezilmesini engelliyor. Geçmiş kayıtlar değiştirilemiyorsa itirazlar tartışma değil, kontrol olur.

Geçiş için önerdiğimiz sıra şöyle:

1. Mevcut Excel'deki tüm kuralları ve istisnaları yazılı hale getirin; çelişkileri iş tarafıyla çözün.
2. Veri kaynağını belirleyin: API, WooCommerce ya da başka bir sistem. Elle veri girişini mümkün olduğunca kaldırın.
3. Oranları ve dağıtım seviyelerini yönetim panelinden değiştirilebilir, sürümlü veri olarak tasarlayın.
4. Hak ediş koşullarını (süre, sipariş durumu, iptal) ayrı bir durum alanı olarak modelleyin.
5. En az bir, tercihen iki dönem boyunca Excel ve yeni sistemi paralel çalıştırın; farkları satır satır inceleyin.
6. Farklar açıklanabilir hale geldiğinde Excel'i kaynak olmaktan çıkarın, yalnızca rapor çıktısı olarak bırakın.

Paralel çalışma dönemi atlanmamalı. Yeni sistemin Excel'le aynı sonucu vermediği her durumda ya sistemde bir hata vardır ya da Excel'in yıllardır kimsenin fark etmediği bir hatası. İkisi de geçişten önce bilinmesi gereken şeylerdir.

• #komisyon
• #hak ediş
• #raporlama
• #woocommerce