Çoğu işletme sahibi raporun tek bir gerçeği gösterdiğini sanır. Panelde "bugün 184 satış" yazıyorsa, bugün 184 satış olmuştur. Oysa rapor bir gerçek değil, bir tanımdır: hangi siparişin sayıldığı, hangi saat diliminde gruplandığı, iadeli kaydın düşülüp düşülmediği ve tutarın KDV'li mi KDV'siz mi alındığı sorularının verdiğin cevaptır. Tanımı değiştirdiğinde sayı da değişir ve hiçbir tarafta hata olmaz.
İşte bu yüzden "rapor sayıları tutmuyor" cümlesi neredeyse her zaman yanlış teşhistir. Doğru teşhis şudur: iki rapor farklı soruları cevaplıyor ve sen ikisini aynı soru sanıyorsun. Aşağıda o farkların altı somut kaynağını, hangi sırayla kontrol edeceğini ve kalıcı olarak nasıl kapatacağını anlatıyorum. Sonunda elinde tek bir kanonik gelir tanımı olacak.
Hangi sipariş "satış" sayılıyor?
Bir siparişin yaşam döngüsü uzundur: oluşturuldu, ödeme bekleniyor, ödendi, teslim edildi, kısmi teslim, iptal, iade. Ana sayfa özeti genelde "oluşturulan" siparişi sayar, muhasebe raporu "ödenen" siparişi, teslimat raporu ise "teslim edilen" siparişi. Üç rakam da doğrudur ve üçü de birbirinden farklıdır. Aradaki boşluk, ödemesi tamamlanmamış veya teslimi bekleyen kayıtlardır.
Yapılması gereken şey basit ama disiplin ister: tek bir kanonik gelir durumu seç ve tüm raporlarda o durumu kullan. Genellikle doğru seçim "ödemesi onaylanmış ve iptal edilmemiş" kümesidir. Diğer sayımları tamamen kaldırmak zorunda değilsin, ama başlıklarını değiştir: "sipariş adedi" ile "ciro" aynı kutuda yan yana durmamalı. İyi bir dijital ürün satış yazılımı bu ayrımı arayüzde de görünür kılar.
Saat dilimi farkı raporu nasıl kaydırır?
Kayıtlar veritabanına çoğunlukla UTC olarak yazılır, rapor ise yerel saate göre gruplanır. Arada üç saat varsa gece 00:00 ile 03:00 arasındaki satışlar bir önceki güne ya da bir sonraki güne düşer. Günlük rapor bu yüzden ödeme geçidinin günlük ekstresiyle asla birebir tutmaz; çünkü geçit kendi saat dilimini kullanır.
Bunu çözmenin tek sağlıklı yolu, raporlamada kullanılan saat dilimini tek bir yerde tanımlamak ve tüm sorguların o tanımı kullanmasını sağlamaktır. Ek olarak aylık kapanışları gün sınırına değil, geniş aralıklara yaslamak farkı anlamsız hale getirir. Günlük karşılaştırma yapacaksan her iki tarafta da aynı saat dilimini seçmen şarttır; aksi halde sonsuza kadar üç saatlik hayaletleri kovalarsın.
| Fark Kaynağı | Tipik Sapma | Nasıl Anlaşılır | Kalıcı Çözüm |
|---|---|---|---|
| Sipariş durumu tanımı | Orta-yüksek | Adet tutmuyor, ciro daha da farklı | Tek kanonik gelir durumu |
| Saat dilimi | Günlükte yüksek, aylıkta düşük | Fark sadece gün sınırında | Merkezi saat dilimi tanımı |
| İade ve iptal | Ay sonunda belirgin | Geçmiş gün rakamı sonradan değişiyor | İade tarihini ayrı kolona yaz |
| KDV dahil/hariç | Sabit oranlı | Fark her zaman aynı yüzde | Raporda iki kolon birlikte |
| Çift sayım | Yüksek | Ciro adetten mantıksız büyük | Kalem tablosundan toplama |
| Test siparişleri | Düşük ama süreklidir | Aynı müşteride tekrarlayan kayıt | Test bayrağı ve rapor dışı bırakma |
Çift sayım nasıl oluşur ve neden fark edilmez?
Bu, teknik olarak en tehlikeli olanıdır çünkü ciroyu şişirir ve kimse şişen ciroya şüpheyle bakmaz. Sebep genelde tablo birleştirmedir: sipariş tablosu ile kalem tablosunu birleştirip sipariş toplamını topladığında, üç kalemli bir sipariş üç kez sayılır. Sonuç, gerçek cironun iki üç katı olabilir.
Kuralı ezberle: sipariş toplamı sipariş tablosundan, kalem detayı kalem tablosundan toplanır; ikisi asla aynı sorguda birleştirilip toplanmaz. Kategori bazlı ciro istiyorsan kalem tutarlarını kullan, sipariş toplamını değil. Bu ayrımı yapmayan bir e-pin satış scripti ile büyüdüğünde, yıl sonunda gerçekle arasında kapatılamaz bir uçurum bulursun.
Rapor Farklarının Kaynak Dağılımı
- Durum ve tanım farkı 35%
- Zaman dilimi ve gün sınırı 25%
- İade, iptal ve KDV 22%
- Çift sayım ve test kaydı 18%
İade ve iptal geçmiş raporu neden değiştirir?
Dün 100 bin TL gösteren rapor bugün 92 bin TL gösteriyorsa, muhtemelen dünkü bir sipariş bugün iade edildi ve iade, siparişin oluşturulma tarihine geri yazıldı. Bu yaklaşım muhasebe açısından tutarlı olabilir ama operasyon açısından kafa karıştırıcıdır; çünkü kapanmış bir günün rakamı asla değişmemelidir.
Doğru kurulum, iadeyi ayrı bir hareket olarak kendi tarihiyle kaydetmektir. Böylece brüt satış, iade ve net satış üç ayrı kolonda durur; hiçbir geçmiş gün oynamaz ve iade oranını da ayrıca ölçebilirsin. Kısmi iade söz konusuysa kalem bazlı iade tutarı tutmak zorunludur; yoksa net ciro hiçbir zaman doğru hesaplanmaz.
KDV, komisyon ve kur: hangi tutarı rapor ediyorsun?
Dijital ürün satışında aynı sipariş için en az dört farklı tutar vardır: müşterinin ödediği brüt tutar, KDV hariç matrah, ödeme geçidi komisyonu düşülmüş net tahsilat ve tedarikçi maliyeti çıkarılmış brüt kâr. Panelde "ciro" yazan kutu bunlardan hangisiyse, banka hesabındaki para başka bir tanesidir. Fark hata değil, komisyondur.
Yabancı para birimiyle tedarik yapıyorsan bir katman daha eklenir: kur. Siparişin oluştuğu andaki kur ile ödemenin hesabına geçtiği andaki kur farklıdır. Bu yüzden maliyet tarafını sipariş anındaki kurla dondurup kaydetmek gerekir; sonradan güncel kurla hesaplarsan geçmiş kârlılık raporların her gün değişir. Sağlam bir epin yazılım kurgusunda sipariş kaydı, o günün kurunu da içinde taşır. Raporlama modülünü incelerken bu alanın var olup olmadığını sor.
Özet tabloları ve önbellek: rakam neden bir süre sonra düzeliyor?
Büyüyen sistemlerde raporlar her seferinde ham veriden hesaplanmaz; gece çalışan bir iş özet tablosunu doldurur ve panel o tabloyu okur. Bu hız için harikadır ama gün içinde özet ile ham veri arasında fark oluşur. Kullanıcı sabah rapor açar, akşam tekrar açar, sayı değişmiştir ve sen "rapor tutarsız" sanırsın.
Bu durumu şeffaflaştırmak yeterlidir: her rapor kutusuna "son güncelleme saati" yaz. Kullanıcı rakamın hangi ana ait olduğunu bildiğinde güven kaybı olmaz. Gerçek zamanlı ihtiyaç varsa sadece küçük pencereleri canlı hesapla, tarihsel dönemleri özetten oku. Bu hibrit yaklaşım, hem performansı hem güveni korur.
| Adım | Kontrol | Doğrulama Yöntemi | Beklenen |
|---|---|---|---|
| 1 | Kanonik durum | Raporun hangi sipariş durumunu saydığını yaz | Tüm raporlarda aynı küme |
| 2 | Saat dilimi | Aynı günü iki dilimle sorgula | Fark yalnızca gün sınırında |
| 3 | Çift sayım | Ciroyu sipariş ve kalem tablosundan ayrı hesapla | İki sonuç eşit olmalı |
| 4 | İade ayrımı | Brüt, iade ve net kolonlarını karşılaştır | Geçmiş gün değişmemeli |
| 5 | KDV tabanı | Matrah ve brüt tutarı yan yana getir | Oran sabit çıkmalı |
| 6 | Test kayıtları | Test bayrağı olanları hariç tut | Fark küçük ama açıklanabilir |
| 7 | Özet tablosu | Son güncelleme saatini oku | Canlı veriyle tutarlı |
Ciro, sipariş adedi, net tahsilat ve kâr için birer cümlelik tanım yaz ve panelin yanına as. Fark tartışmalarının çoğu, yazılı tanım olmadığı için çıkar; belge çıktığı gün tartışma biter.
Rapora güvenmeyi nasıl yeniden kazanırsın?
Güven, mutlak doğrulukla değil tekrarlanabilirlikle gelir. Aynı tarih aralığını iki farklı günde sorguladığında aynı sonucu alıyorsan rapor güvenilirdir; küçük tanım farkları kabul edilebilir. Bu yüzden önce tekrarlanabilirliği sağla: geçmişi değiştiren hareketleri kendi tarihine yaz, özet tablosu saatini göster, test kayıtlarını işaretle.
Ardından ayda bir kez tek bir mutabakat ritüeli kur: ödeme geçidi ekstresi, panel net satış raporu ve muhasebe kaydını aynı masaya koy, farkı kalem kalem açıkla. İlk ayda birkaç saat sürer, üçüncü ayda yarım saate iner ve o noktadan sonra rakamlarını gerçekten yönetmeye başlarsın. Yatırım kararını verirken raporlamayı bir süs değil, karar altyapısı olarak değerlendir.
Rakamlarına güvenerek büyümek istiyorsan
Pinova; kanonik sipariş durumu, kalem bazlı iade, KDV ayrımı ve kur dondurma mantığıyla raporu tek doğruya bağlar. Ay sonu mutabakatı saatler değil dakikalar sürer.
Panel cirosu ödeme geçidiyle neden hiç birebir tutmuyor?
Çünkü geçit komisyon düşülmüş net tahsilatı, panel ise brüt satışı gösterir. Ayrıca iki tarafın saat dilimi farklıysa gün sınırındaki işlemler kayar.
Geçmiş günün rapor rakamı neden sonradan değişiyor?
İade veya iptal, siparişin oluşturulma tarihine geri yazıldığı için. İade hareketini kendi tarihiyle ayrı kaydettiğinizde geçmiş günler sabitlenir.
Ciro adet ile mantıksız oranda büyük çıkıyorsa sebebi ne olabilir?
Büyük olasılıkla çift sayım. Sipariş tablosu ile kalem tablosu birleştirilip sipariş toplamı toplandığında her kalem için tekrar sayılır.
Kârlılık raporum her gün değişiyor, nasıl sabitlerim?
Tedarik maliyetini ve kuru sipariş anında dondurup kayda yazmanız gerekir. Güncel kurla geriye dönük hesaplama yapıldığında geçmiş kâr sürekli oynar.
Rapor tutmuyorsa panik yapma; tanımlarını yaz. Kanonik durumu seç, saat dilimini merkezîleştir, iadeyi kendi tarihine al, KDV ve komisyonu ayrı kolonlara böl, çift sayımı kapat. Bu beş hamle farkların neredeyse tamamını açıklar. Brüt satış, iade, net tahsilat ve kâr kolonlarının aynı ekranda nasıl tutarlı durabildiğini görmek istersen canlı demo üzerinden birkaç test siparişi oluşturup raporun her adımda nasıl davrandığını izle.