E-Pin Satış Yazılımı ile ERP Entegrasyonu: Muhasebecinin Sana Söylemediği, Ciroyu Değil Kârı Büyüten Sessiz Bağlantıyı Kurmanın Tam Yolu

Çoğu e-pin satıcısı ERP'yi "büyük şirket işi" sanır. Aylık iki bin siparişe kadar her şeyin bir tablo dosyasıyla döneceğine, muhasebecinin ay sonunda ekstreyi alıp işi toparlayacağına inanır. Sonra bir gün, ciro iki katına çıkmışken banka hesabındaki para bir önceki aydan az çıkar. O an akla ilk gelen şey dolandırıcılık ya da iade dalgasıdır. Oysa sorun neredeyse her zaman aynı yerdedir: satış tarafındaki e-pin scripti ile mali tarafı tutan sistem birbirinden habersiz çalışmaktadır.

Burada anlatacağım şey, kurumsal bir yazılım broşüründen alınma genel geçer bir "dijital dönüşüm" hikâyesi değil. Türkiye'de e-pin, oyun parası ve dijital kod satan işletmelerin defterinde gerçekten ne olduğunu, hangi kalemin nerede kaybolduğunu ve bir dijital ürün satış scripti ile ön muhasebe arasındaki köprünün nasıl kurulduğunu konuşacağız. Pinova'yı bu noktada bir satış sitesi gibi değil, siparişin doğduğu andan faturanın kesildiği ana kadar veriyi tek formatta taşıyan bir omurga gibi düşünmen gerekiyor.

Neden ciro büyürken kâr küçülüyor?

Cevap tedarik maliyetinin kayıt anında donmamasında saklı. Bir kod partisini bugün 100 liraya alıyorsun, iki hafta sonra kur hareketiyle aynı kodun yenilenme maliyeti 114 lira oluyor. Sitedeki fiyat listen hâlâ eski maliyete göre hesaplanmış kâr marjını taşıyorsa, her satışta farkında olmadan bir miktar sermaye eritiyorsun. Manuel çalışan işletmelerde bu fark ancak ay sonunda, toplam rakama bakıldığında görünür hale gelir ve o noktada geri dönüşü yoktur.

ERP entegrasyonunun ilk ve en somut faydası budur: satılan her kodun hangi alım partisinden geldiği, o partinin birim maliyeti ve satış anındaki gerçek marjı sipariş kaydının içine yazılır. Böylece kârlılık raporu tahmin değil muhasebe kaydı haline gelir. Bir e-pin satış yazılımı bu bağı kurmadığı sürece raporlarındaki "kâr" sütunu sadece iyimser bir temenni olarak kalır.

Entegrasyon dediğimiz şey aslında kaç ayrı akıştan oluşuyor?

Piyasada "ERP entegre" ifadesi tek bir düğme gibi pazarlanıyor ama teknik olarak birbirinden bağımsız dört ayrı hattan söz ediyoruz. Bunları ayırmadan kurulum yapmaya kalkarsan, biri bozulduğunda diğerlerinin de durduğu kırılgan bir yapı elde edersin. Ayrıştırılmış kurulumda ise fatura servisi çökse bile satış devam eder, kuyruk birikir ve servis döndüğünde geçmişe dönük işlenir.

Akışların yönü de kritiktir. Cari ve ürün tanımı ERP'den siteye doğru akar; sipariş, tahsilat ve iade siteden ERP'ye doğru. Bu yönleri karıştıran kurulumlarda aynı kaydın iki sistemde birbirini ezdiği, sonsuz güncelleme döngüleri ortaya çıkar.

Bayi cari hesabı neden en tehlikeli kalem?

Toptan çalışan bir e-pin işletmesinde en büyük risk perakende müşteri değil, bakiyeli bayidir. Bayi panelinden yapılan çekim anında düşmez de gecikmeli düşerse, aynı bayi saniyeler içinde bakiyesinin üzerinde alım yapabilir. Bu, teorik bir senaryo değil; Türkiye'de bayi ağıyla çalışan pek çok işletmenin en az bir kez yaşadığı somut zarardır.

Doğru kurulumda bakiye düşümü sipariş kaydıyla aynı işlem bloğunda gerçekleşir. ERP tarafına aktarım daha sonra, kuyruk üzerinden yapılır. Yani gerçek zamanlı olması gereken şey bakiye kontrolü, ERP senkronu değildir. Bu ayrımı yapmayan kurulumlar, ERP yavaşladığında satışı da yavaşlatır ve hem para hem müşteri kaybettirir.

Fatura tarafında en sık yapılan hata hangisi?

Faturanın sipariş oluştuğunda değil, ödeme gerçekten onaylandığında kesilmesi gerekir. Kulağa bariz geliyor ama sanal POS ve cüzdan sistemlerinin ara durumları bu ayrımı bulanıklaştırır. "Beklemede" statüsündeki bir ödemeye fatura kesip sonra iptal etmek, ay sonunda hem entegratör ücreti hem de gereksiz iptal yığını demektir.

İkinci klasik hata, dijital ürünlerde vergi kodlamasının kopyala-yapıştır yapılmasıdır. Farklı ürün ailelerinin muhasebe kodları farklı olabilir ve bu ayrımı site tarafındaki ürün kartına yazmadıysan, muhasebeci her ay elle düzeltmek zorunda kalır. Kaliteli bir epin yazılım kurulumunda vergi ve muhasebe kodu ürünün doğal bir alanıdır, sonradan eklenen bir yama değil.

Kurulum öncesi neyi kontrol etmelisin?

Entegrasyon projelerinin çoğu teknik nedenlerle değil, veri hijyeni nedeniyle uzar. Site tarafında 900 ürün varken ERP'de 640 kalem tanımlıysa, önce bu eşleşmeyi çözmen gerekir. Aşağıdaki listeyi bağlantıyı kurmadan önce tek tek işaretlemeni öneririm.

Bu yapı küçük işletme için de mantıklı mı?

Evet, ama sırayla. Günde 30 sipariş alan bir işletmenin ilk gün tam ERP bağlantısına ihtiyacı yok. İhtiyacı olan şey, ileride o bağlantıyı kuracak veri disiplinidir: her siparişin maliyetiyle birlikte kaydedilmesi, her bayinin tekil cari koduyla tanımlanması, her ürünün muhasebe koduyla eşleşmesi. Bu disiplini bugün kuran işletme, hacim büyüdüğünde entegrasyonu bir hafta içinde tamamlar; kurmayan ise veriyi baştan temizlemek için aylarca uğraşır.

Pinova'nın özellik setinde bu alanların hazır gelmesinin sebebi de bu. Sistem seni büyüdüğünde ERP'ye geçmeye zorlamaz, ama geçmek istediğinde veri zaten doğru biçimde durur. Ölçeklenme planını paket karşılaştırmasında görebilirsin.

Entegrasyonun gerçek getirisi, ay sonunda muhasebeciyle yaptığın telefon görüşmesinin kısalmasıdır. Rakamlar tartışılmaz hale geldiğinde enerjini fiyatlamaya ve tedarikçi pazarlığına ayırırsın. Bu yapının kendi ürün kataloğunda nasıl göründüğünü merak ediyorsan, sipariş ve cari ekranlarını canlı demo üzerinden kendi senaryonla deneyerek başlayabilirsin.