Güvenli Silme ve Denetim İzi: Yıl Sonu Raporlama İçin Neden Kritik?

Bir sakin geliyor, “Ekim 2024 doğalgaz faturamı tekrar görmek istiyorum, denetçi soruyor” diyor. Yönetimin elinde rapor var mı? Sayaç bu sırada değişti mi? Eski okumalar silinmiş mi? Cevaplar yoksa, yönetim için ciddi sorun.

Bu yazıda güvenli silme (soft delete) ve denetim izi (audit log) mekanizmalarını, neden geçmiş raporlar için kritik olduklarını ve mReader’ın bu süreci nasıl yönettiğini açıklıyoruz.

Hard delete vs soft delete

İki farklı silme yöntemi:

Hard delete (gerçek silme)

Kayıt veritabanından fiziksel olarak kaldırılır. Disk üzerinde de kaybolur (yazılım seviyesinde). Geri getirilemez.

Sorun: bu kayda referans veren her şey de bozulur.

Örnek senaryo:

Sayaç A/3-Doğalgaz, 2024 boyunca kayıtlı
2025 Şubat’ta sayaç değişir, eski sayaç hard delete
Sakin Aralık 2025’te “geçen Ekim faturamı gösterir misin?” der
Ekim 2024 raporu üretiliyor, ama o sayaç artık yok → rapor yarım, hesap bozuk

Soft delete (güvenli silme)

Kayıt veritabanından silinmez, sadece “silinmiş” olarak işaretlenir. Aktif sorgularda görünmez ama tarihsel raporlar üretilirken erişilebilir.

Aynı senaryo soft delete ile:

Sayaç A/3-Doğalgaz, 2024 boyunca kayıtlı
2025 Şubat’ta sayaç değişir, eski sayaç arşive geçer (deleted_at = '2025-02-15')
Sakin Ekim 2024 raporu ister
mReader rapor üretirken o tarihte aktif olan kayıtları kullanır → eski sayaç görünür → rapor doğru

Denetim izi (audit log)

Soft delete’i tamamlayan ikinci mekanizma: audit log. Veritabanında her değişikliğin kaydı:

Hangi kullanıcı yaptı?
Hangi kayıt etkilendi?
Eski değer ne, yeni değer ne?
Ne zaman yapıldı?
Hangi IP’den / hangi makineden?

mReader’ın denetim izi örneği:

TARİH       | KULLANICI | İŞLEM | KAYIT          | DETAY
10.05 14:22 | elif.s    | edit  | okuma#19420    | 142.3 → 142.5
10.05 13:08 | mehmet.k  | delete| sayaç 87399-A  | arşivlendi (soft)
10.05 09:55 | elif.s    | create| daire B/D14    | 95 m²
10.05 00:01 | system    | read  | 1024 sayaç     | plan tamamlandı

Her satır cevap verir: kim, ne zaman, ne yaptı.

Neden bu iki mekanizma birlikte çalışmalı?

Soft delete tek başına yeterli değil — silinen kaydın kim silindiğini bilmek gerekir. Audit log tek başına yeterli değil — kaydın silinen değil sadece güncellenen olduğunu fark etmek için soft delete bayrağı şart.

Birlikte çalıştığında:

Şeffaflık: hiçbir şey kayıp değil, her şeyin neden değiştiğinin gerekçesi var
Geri alınabilirlik: yanlış silinen kayıt geri yükleniyor (soft delete olduğu için fiziksel silme olmamış)
Kanıt: sakin tartışmasında “Mart raporunda neden değişti?” sorusu cevaplanabilir
Denetim hazırlığı: yıl sonu denetim, müteahhit geçişi, sakin değişimi gibi durumlarda kanıt zinciri tamamlandı

Yıl sonu raporlama senaryoları

Pratikte audit log + soft delete’in işe yaradığı senaryolar:

1. Sakin değişikliği

Daire satıldı. Yeni sahip “geçen yıl ne tüketti?” diye sorabilir. Eski sakin de aynı bilgiyi isteyebilir.

mReader bu durumda her iki tarafa da kendi dönemine ait raporu üretebilir. Tarihsel kesinlik korunur.

2. Yönetim devri

Yeni yönetim kurulu seçildi. “Önceki yönetim şu daireden 50.000 ₺ alacak demiş, kayıtta ne var?” sorusu.

Audit log gösterir: ne zaman, kim, hangi kayıtla bu alacağı belirledi. Yönetim devri şeffaf yapılabilir.

3. Yargı süreci

Sakin gider hesabını mahkemeye götürdü. Mahkeme kanıt isteyecek. mReader’ın PDF rapor + audit log özeti çıktısı kanıt olarak sunulabilir.

4. KVK Kurumu denetimi

Sakin KVK Kurumu’na şikayet etti, “verim izinsiz değiştirilmiş” iddiası. Audit log ile gerçek değişiklik kaydı sunulur — şikayet asılsızsa belge.

5. Vergi denetimi

Yönetim şirketinin maliye denetimi. Ödeme tahsilatı geçmişini sayaçlardan baştan üretmek gerekir → soft delete sayesinde 5 yıl önceki kayıtlar erişilebilir.

mReader implementasyonu

mReader’ın veritabanı şemasında her kayıt için iki standart alan vardır:

deleted_at  TIMESTAMP NULL  -- soft delete bayrağı
deleted_by  TEXT NULL       -- silen kullanıcı

Aktif sorgular: WHERE deleted_at IS NULL
Tarihsel raporlar: zaman damgasını esas alır → WHERE created_at <= rapor_tarihi AND (deleted_at IS NULL OR deleted_at > rapor_tarihi)

Audit log ayrı tabloda saklanır:

audit_log
  id          PRIMARY KEY
  timestamp   TIMESTAMP
  user_id     TEXT
  action      ENUM('create', 'update', 'delete', 'read')
  table_name  TEXT
  record_id   TEXT
  old_value   JSON
  new_value   JSON
  source_ip   TEXT

Her CRUD işlemi otomatik olarak buraya yazılır; uygulama tarafında bunu unutmak imkansız.

Veritabanı boyutu sorunu

Soft delete + audit log → veritabanı zamanla büyür. Bu sorun mu?

mReader’ın test ettiği bir kurulumda:

384 sayaç, 5 yıl, günlük okuma
Veri satır sayısı: ~700.000
Audit log satır sayısı: ~1.5 milyon
SQLite dosya boyutu: ~150 MB

150 MB modern bilgisayar için hiç sorun değil. SQLite indeksli sorgularda 1 milyon satırı 50 ms’de tarar. 5+ yıllık archive sorunsuz çalışır.

KVKK uyumu açısından

Soft delete bir avantajdır ama KVKK saklama süresi kuralı da uygulanmalı. Sonsuza kadar saklamak hukuka aykırı.

mReader’da:

Aktif veri: 5 yıl (gider paylaşımı, denetim, vergi mevzuatı)
5 yıl sonrası: kayıt gerçekten silinir (hard delete) veya anonimleştirilir (sayaç seri numarası kaldırılır, sadece kümeli istatistik kalır)

Saklama süresi yönetim kurulu kararıyla site bazında ayarlanabilir.

Geri alınamayan işlemler

Bazı işlemler tasarımı gereği geri alınamamalı:

Kapanmış aylar: rapor üretildikten sonra geçmiş ay datası kilitlenir. Sakine gönderilmiş bir rapor bilgisi sonradan değişemez (denetim için).
Onaylanmış faturalar: yönetim kurulu onaylayıp imzaladıktan sonra fatura kalemi düzeltilemez; düzeltme gerekirse yeni bir kalem eklenir (negatif düzeltme).

Bu kilit mekanizması mReader’ın audit log altyapısında “immutable” işaretiyle kurulur.

Sonuç

Soft delete + denetim izi, profesyonel bir bina yönetim sisteminin olmazsa olmaz iki bileşeni. Geçmiş raporların tutarlılığı, sakin tartışmalarında kanıt, yargı/denetim süreçlerinde belge — hepsi bu iki mekanizmaya dayanır.

mReader bu özellikleri varsayılan olarak sunar; ek modül veya yapılandırma gerekmez. Özelliklerimiz sayfasında “Denetim İzi ve Güvenli Silme” başlığında detaylar mevcut.

Yönetiminizde tarihsel kanıt zinciri kurmak istiyorsanız, iletişim formundan ulaşın.