Vaka: Satış Raporundaki Yinelenen Satırlar ve Yanlış Toplamlar – Bir Perakende Şirketinde JOIN Hatasının İzini Sürmek

Vaka: Haftalık Ciro Raporu Muhasebeden Neden Yüksek Çıkıyor?

Bu vaka kurgusal ama gerçekçidir. Türkiye'de birden çok mağazası olan orta ölçekli bir giyim perakendecisinde veri analisti olarak çalıştığınızı düşünün. Her pazartesi sabahı yönetime haftalık ciro raporu gönderiyorsunuz. Bu hafta rapordaki toplam, muhasebenin kapattığı rakamdan belirgin biçimde yüksek çıkıyor. Fark küçük bir yuvarlama hatası gibi durmuyor.

Şirketin veri yapısı (örnek)

Şüpheyle başlayan adımlar

Adım 1: Rakamın neden şüpheli olduğunu söyleyin. Rapor ile muhasebe toplamı arasında fark var. Hangisinin doğru olduğunu henüz bilmiyorsunuz. İlk varsayımınız "muhasebe yanlış" olmamalı. Önce kendi sorgunuzu sorgulayın.

Adım 2: Sorguyu parçalara ayırın. Tek bir büyük sorgu yerine en sade halinden başlayın. Önce yalnızca siparişler tablosunda kontrol yapın:

• SELECT COUNT(*), SUM(tutar) FROM siparisler WHERE tarih BETWEEN ... ; Bu sonuç, muhasebeyle karşılaştırılacak ilk referanstır.
• Bu sayı muhasebeye yakınsa sorun siparişlerde değil, sonradan eklenen JOIN'lerdedir.

Adım 3: Her JOIN'den sonra satır sayısını kıyaslayın. Sorguya tabloları tek tek ekleyin ve her eklemeden sonra COUNT(*) değerine bakın:

Kök neden: bire-çok ilişkide çoğalan satırlar

Bir sipariş iki ödeme kaydına sahipse JOIN sonrası o sipariş iki satır olarak görünür. Sipariş tutarı her satırda tekrar ettiği için SUM(tutar) aynı tutarı iki kez toplar. Aynı sipariş iki kargoya da bölündüyse ödeme ve kargo kombinasyonları çarpılır ve sipariş daha da fazla kez toplanır.

Küçük örnek senaryo: 1000 TL'lik tek bir sipariş, 2 ödeme kaydı ve 2 kargo kaydı içeriyor. JOIN sonrası bu sipariş 4 satır olur ve rapora 4000 TL olarak girer. Bu mantık, gerçek verinizde hangi oranda sapma çıkacağını önceden söylemez. Sapma, çok parçalı siparişlerin sıklığına göre değişir.

Alınan kararlar

• Önce sipariş düzeyine indirin, sonra birleştirin. Ödemeleri ve kargoları ayrı ara sorgularda sipariş bazında özetleyin, ardından ana tabloyla birleştirin.
• Tutarı ana tablodan toplayın. Ödeme veya kargo bilgisi gerekiyorsa tutar sütununu çoğalan satırlardan toplamayın.
• Raporu mutabakata bağlayın. Her rapor, muhasebe toplamıyla karşılaştırılan bir kontrol satırı içersin.
• Yöneticiye düzeltme notuyla sunun. Hatayı gizlemeyin, açıkça yazın.

Kullanılabilir şablon: düzeltilmiş sorgu iskeleti

WITH odeme_ozet AS (SELECT siparis_id, SUM(odenen_tutar) AS odenen, COUNT(*) AS odeme_adedi FROM odemeler GROUP BY siparis_id), kargo_ozet AS (SELECT siparis_id, COUNT(*) AS kargo_adedi FROM kargolar GROUP BY siparis_id) SELECT m.ad, SUM(s.tutar) AS ciro FROM siparisler s JOIN magazalar m ON m.id = s.magaza_id LEFT JOIN odeme_ozet o ON o.siparis_id = s.id LEFT JOIN kargo_ozet k ON k.siparis_id = s.id GROUP BY m.ad;

Burada ara sorgular her siparişi en fazla bir satıra indirdiği için JOIN satır çoğaltmaz. Sütun adları örnektir, kendi şemanıza uyarlayın.

Yöneticiye düzeltme notu şablonu

• Ne oldu: "Önceki haftalık ciro raporu, sorgudaki birleştirme nedeniyle bazı siparişleri birden fazla kez saymıştır."
• Etki: "Ciro olduğundan yüksek görünmüştür. Düzeltilmiş rakam ekte, muhasebe toplamıyla mutabıktır."
• Neden oldu: "Bir siparişin birden fazla ödeme ve kargo kaydı olabiliyor."
• Önlem: "Her rapora satır sayısı ve mutabakat kontrolü eklendi."

Çıkarılan dersler

• JOIN öncesi ve sonrası satır sayısını kıyaslayın. Beklenmedik artış alarm işaretidir.
• Yayımlamadan bağımsız bir toplamla doğrulayın. Muhasebe, ana tablo toplamı veya başka bir kaynak olabilir.
• Hatayı saklamayın. Erken ve açık paylaşım güveni korur, geç fark edilen hata ise güveni zedeler.

Tartışma soruları

• Kendi işinizde hangi rakam "bir kez daha kontrol edilmeden" yöneticiye gidiyor?
• Hata fark edilen raporu daha önce paylaşmış olsaydınız nasıl bir iletişim izlerdiniz?
• Mutabakat kontrolünü hangi sıklıkla ve kim yapmalı?