Mikro ve Logo'ya E-Pin Satışını Elle Girenlerin Fark Etmediği Sessiz Kayıp: Muhasebe Aktarımını Tek Seferde Çözen Script Mimarisi

E-pin satışını muhasebeye aktarma konusunu çoğu işletme sahibi “ay sonunda bir Excel gönderirim, gerisi muhasebecinin işi” diye düşünür. İlk aylarda bu gerçekten işler. Sonra günlük sipariş sayın 30'u, 100'ü geçer; Excel 4.000 satıra çıkar; muhasebeci sana “bu satırların hangi ürün, hangi POS, hangi komisyon olduğunu anlamıyorum” diye yazar. O andan itibaren her ay birkaç gününü mutabakata harcamaya başlarsın. Kayıp para değil, dikkat; ve dikkat kaybı bu işte paradan pahalıdır.

İkinci yanılgı daha teknik: “Mikro da Logo da muhasebe programı, ikisi için aynı aktarımı yazarım.” Hayır. Bu iki ekosistem farklı veri modelleri, farklı bağlantı yöntemleri ve farklı kart mantıklarıyla çalışır. Birine yazdığın aktarım, diğerinde tek satır bile geçmez. Doğru yaklaşım, e-pin satış scriptinin tarafında sağlayıcıdan bağımsız tek bir “muhasebe hareketi” yapısı üretmek, sonra bunu hedef programın beklediği biçime çeviren ince bir katman yazmaktır. Bu yazıda o mimariyi, hesap planı eşlemesini, stok kartı kararını ve aylık mutabakatı sırayla kuruyoruz.

Neden hâlâ binlerce satırı elle giriyorsun?

Elle giriş bir tercih değil, genelde bir erteleme sonucudur: entegrasyon karmaşık görünür, o yüzden “şimdilik böyle devam” denir. Ama elle girişin üç somut maliyeti var. Birincisi zaman; 4.000 satırlık bir dönemi tasnif etmek, kalem kalem girmek ve kontrol etmek birkaç iş günü demektir. İkincisi hata; tek bir hesap kodu yanlış girildiğinde hatayı fark etmek değil, nerede olduğunu bulmak zaman alır. Üçüncüsü gecikme; ayın 20'sinde hâlâ önceki ayın kaydı bitmemişse kârlılığını gerçek zamanlı bilmiyorsun demektir.

Kârlılığı bilmemek bu sektörde doğrudan fiyatlama hatasına dönüşür. Komisyonlar, iadeler, kur farkları ve tedarikçi maliyeti kayıtlara düzgün geçmediğinde ürün başına gerçek marjın ne olduğunu göremezsin. Sonuç: zararına satılan bir kategori aylarca fark edilmeden döner. Otomatik aktarım aslında bir muhasebe konforu değil, bir karar verme aracıdır; asıl kazancı ay sonunda değil, fiyat listesini güncellerken alırsın.

Mikro ve Logo aynı şey değil: iki farklı kapı

Mikro tarafında (Mikro Fly, Mikro Run ve türevleri) veri katmanı geleneksel olarak SQL Server üzerindedir ve pratikte iki yol kullanılır: programın kendi içe aktarma arayüzüne uygun dosya üretmek ya da yetkili bir ara tablo üzerinden veri bırakıp programın bunu okumasını sağlamak. Doğrudan canlı tablolara yazmak teknik olarak mümkün görünse de risklidir; sürüm değişiminde veri bütünlüğünü bozabilir ve destek kapsamı dışına çıkarsın. Mikro'da kritik nokta, kod alanlarının (cari kod, stok kodu) birebir uyuşmasıdır; tek karakter farkı kaydı reddettirir.

Logo tarafında (Tiger, GO serisi) ise nesne tabanlı bir yaklaşım vardır; entegrasyon genellikle Logo'nun sunduğu nesne/servis katmanı ya da veri aktarım aracı üzerinden yapılır ve fiş tipleri, işlem türleri daha katı tanımlıdır. Logo'da hata mesajları daha açıklayıcıdır ama şema beklentisi de daha sıkıdır: eksik bir işlem türü ya da tanımsız bir ödeme tipi fişin tamamını geri çevirir. Bu yüzden iki sistem için tek bir kod yazmaya çalışmak yerine, scriptinde ortak bir hareket modeli tutup her programa ayrı dönüştürücü yazmak hem daha hızlı hem de bakımı kolay bir çözümdür.

Hangi aktarım yolu senin hacmine uygun?

Aktarım yolunu hacme göre seçmek gerekir, hevese göre değil. Aylık 300 siparişe kadar dönemsel dosya aktarımı fazlasıyla yeterlidir: script gün sonunda ya da ay sonunda uygun formatta bir dosya üretir, muhasebe onu programa alır. 300-3.000 bandında ise günlük otomatik aktarım gerekir; çünkü haftalar biriktiğinde hata bulmak imkânsızlaşır. 3.000 üstü hacimde ise gerçek zamanlıya yakın, kuyruk tabanlı bir akış kurmak zorunludur.

Bir de dolaylı yol var ve çok az konuşulur: faturayı zaten bir entegratör üzerinden kesiyorsan, muhasebe programın çoğu zaman bu belgeleri doğrudan içeri alabilir. Yani satış kaydını iki kez taşımak yerine fatura akışını tek kaynak yaparsın. Bu yaklaşım, özellikle bireysel müşteriye satış yapan dijital ürün satış yazılımı kullanıcıları için en az bakım gerektiren çözümdür; ancak POS komisyonu ve cüzdan yüklemeleri gibi fatura dışı hareketleri ayrıca aktarman gerekir. Hangi yöntemi seçersen seç, tek şart değişmez: aktarım tekrarlanabilir ve idempotent olmalı.

Hesap planı eşlemesini kim yapacak?

Bu sorunun cevabı çoğu projede boşta kalır: yazılımcı muhasebe bilmediği için tahmin eder, muhasebeci yazılım bilmediği için sonucu düzeltir. Doğrusu, eşlemeyi mali müşavirin bir kez tanımlaması ve scriptin bunu ayar olarak tutmasıdır. Tipik bir kurulumda satış hasılatı, tahsil edilen KDV, banka/POS hesabı, POS komisyon gideri, tedarikçiden alınan e-pin maliyeti ve iade hesabı ayrı ayrı tanımlanır. Kodları buraya yazmak yerine müşavirinden alacağın tabloyu panele girmen en sağlıklısı; çünkü hesap planı işletmeden işletmeye değişir.

Eşlemenin ayar olarak durmasının bir faydası daha var: kategori bazlı ayrım yapabilirsin. Oyun kodları, yazılım lisansları ve hediye kartlarını farklı hasılat alt hesaplarına yazdığında, dönem sonunda hangi kategorinin ne kadar kâr bıraktığını muhasebe raporundan doğrudan okursun. Bunu tek bir hasılat hesabına toplayan işletmeler, kategori kârlılığını görebilmek için ayrıca rapor yazmak zorunda kalır. Kurulumda beş dakika süren bu karar, bir yıl sonra en çok işine yarayacak şey olur. Modüllerin bu ayrıntıda ayar tutup tutmadığını özellikler sayfasından kontrol et.

Stok kartı mı hizmet kartı mı? E-pin muhasebede nereye oturur?

Bu, entegrasyon projelerinde en çok tartışılan ve en çok yanlış kurulan karardır. E-pin fiziksel bir mal değildir ama tedarikçiden alınıp satılan, adet bazlı ve maliyeti olan bir kalemdir. İki yaklaşım var. Birincisi stok kartı olarak tanımlamak: her ürün için kart açılır, alış ve satış adetleri izlenir, dönem sonunda elde kalan kod adedi stok olarak görünür. Bu yöntem maliyet takibini netleştirir ama kart sayısı hızla büyür ve her yeni ürün için muhasebede tanım gerektirir.

İkincisi hizmet kartı olarak tanımlamak: satış tek bir hizmet kalemi üzerinden yazılır, maliyet doğrudan gider olarak işlenir. Kurulumu kolaydır ama ürün bazlı marj takibini muhasebe tarafında kaybedersin. Pratikte en dengeli çözüm melez modeldir: muhasebeye kategori bazında sınırlı sayıda kart açılır (örneğin oyun kodu, hediye kartı, lisans), detaylı ürün bazlı takip ise epin yazılım tarafındaki raporlarda tutulur. Böylece muhasebe sade kalır, sen yine ürün kırılımını görürsün. Kararı vermeden önce mutlaka müşavirine sor; çünkü stok değerlemesi vergi tarafını da etkiler.

Mutabakat: ay sonunda tek rakama bakmak

İyi kurulmuş bir aktarımın testi tek cümleyle yapılır: ay sonunda scriptin satış raporundaki toplam ile muhasebedeki hasılat toplamı arasındaki fark sıfır mı? Sıfır değilse farkın kaynağı neredeyse her zaman şu dört kalemden biridir: aktarılmamış iadeler, brütten düşülmüş POS komisyonu, kuyrukta kalmış başarısız aktarımlar ya da kur çevrimi yapılan siparişler. Bu yüzden scriptin bir “aktarım durumu” ekranı olmalı: gönderildi, hata aldı, tekrar denendi, atlandı.

Bunun üstüne bir de günlük kontrol alışkanlığı kur. Her sabah iki sayıya bak: dün kapanan sipariş sayısı ve dün başarıyla aktarılan hareket sayısı. Eşit değilse sorunu 24 saat içinde çözersin; ay sonunu beklersen 30 günlük karmaşayı çözmek zorunda kalırsın. Otomasyonun amacı muhasebeyi görünmez kılmak değil, hatayı küçükken yakalamaktır. Bu düzeni kurmak için hangi paketin uygun olduğunu fiyat karşılaştırmasında görebilir, kurulum adımına geçebilirsin.

Muhasebe aktarımı, kurulduğu gün hiç heyecan vermeyen ama altı ay sonra en çok değer üreten yatırımdır: hem müşavirinle aranı düzeltir hem de hangi kategoride gerçekten para kazandığını sana rakamla söyler. Kurmadan önce mimarinin nasıl göründüğünü incelemek istersen canlı demo üzerinden sipariş, tahsilat ve komisyon kayıtlarının nasıl ayrı ayrı tutulduğuna bak; sonra müşavirinden hesap kodlarını isteyip aynı hafta eşlemeyi tamamlayabilirsin.