EYDefterEmre Yakut
← tüm yazılar
Ölçüm · Hata avı

Tablo doğruydu, sistem yanlıştı

Nakit akış raporunu otomatikleştirirken elle tutulan hesap tablosuyla ERP tutmadı. Refleksim tabloya güvenmemekti. Satır satır bakınca varsayımım çürüdü.

Excel (elle)Netsis (sistem)Tahsilat1.284.900Tahsilat1.284.900=Ödeme911.430Ödeme911.430=Kur farkı—Kur farkı48.117≠Net373.470Net325.353≠iki taraf aynı gerçeği anlatmıyorsa, önce hangisinin yanlış olduğunu VARSAYMAEUR kalemleri TL’ye çevrilirken hangi kur? satır satır bakınca cevap ortaya çıktı.

Firmanın nakit akışı yıllardır elle tutulan bir hesap tablosunda takip ediliyordu. Amaç bunu ERP verisinden otomatik üretmek — her ay yapılan iki günlük işi ortadan kaldırmaktı.

Üretici hazır olunca ilk testi yaptım: aynı ay için tablonun ve sistemin sonuçlarını yan yana koydum. Tutmadı.

İlk refleks ve neden yanlıştı

Otomatik olan ile elle olan çeliştiğinde varsayılan tepki bellidir: elle tutulanda hata vardır. İnsan yorulur, satır atlar, formülü yanlış sürükler.

Ben de oradan başladım. Ve yanıldım.

bu bir ölçüm hatasıydı — benim

“Elle tutulan yanlıştır” bir bulgu değil, bir önyargı. Ölçüm yapmadan kabul edilen her önyargı aramayı yanlış yere yönlendirir. İki gün tabloda hata aradım; hata orada değildi.

Toplamı bırak, satırlara bak

Dönüm noktası yöntem değişikliğiydi. Toplamları karşılaştırmayı bıraktım — toplam fark tek bir sayı ve hiçbir şey söylemiyor. Bunun yerine kalemleri eşleştirdim:

kalemtablosistem
Tahsilat (TL)1.284.9001.284.900=
Ödeme (TL)911.430911.430=
Tahsilat (EUR)EUR 42.100TL 1.845.000≠
Kur farkı—48.117≠

Fark üçüncü satırda ortaya çıktı. TL kalemleri kuruşuna kadar aynıydı; ayrışma yalnız döviz kalemlerindeydi.

Hangi kur?

Mesele şuydu: bir EUR tahsilatı TL raporunda gösterilirken hangi kurla çevrilecek? Üç makul cevap var ve üçü de farklı sayı üretiyor:

  • İşlem günü kuru — para o gün girdi, o günkü karşılığı yazılır.
  • Dönem sonu kuru — ay sonunda eldeki dövizin o günkü karşılığı.
  • Ortalama kur — dönem boyunca ortalama.

Tablo birincisini kullanıyordu. Sistem ikincisini kullanıyor ve aradaki farkı ayrı bir “kur farkı” kalemine atıyordu.

İkisi de yanlış değil. Ama ikisi aynı soruyu cevaplamıyor.

Nakit akışı “bu ay kasaya ne girdi” sorusudur. Değerleme “elimdeki ne eder” sorusudur. Bir raporda ikisini karıştırırsan ortaya çıkan sayı hiçbir soruyu cevaplamaz.

Nakit akışı için doğru olan işlem günü kuruydu — yani tablo doğruydu. Sistem, muhasebe değerleme mantığını nakit akışı raporuna taşıyordu.

Düzeltme

Rapor ikiye ayrıldı. Nakit akışı kalemlerini kendi para biriminde tutuyor, TL karşılığını işlem günü kuruyla gösteriyor. Kur etkisi ayrı bir bölümde, ayrı bir soruya cevap olarak duruyor.

Ayrıca her döviz satırının yanında hangi kurun, hangi tarihle kullanıldığı yazıyor. Bu da “her alan kaynağını taşır” kuralının aynısı.

bir de binlik ayracı

Aynı turda küçük bir hata daha çıktı: bazı sayılar yerel biçimlendirme yüzünden yanlış gösteriliyordu. Bir yıl ya da bir kod alanı binlik ayraç almamalı. Sayıyı biçimlendirirken onun bir miktar mı yoksa bir tanımlayıcı mı olduğunu bilmek gerekiyor.

Ne öğrendim

İki kaynak çeliştiğinde sorulacak soru “hangisi yanlış?” değil. “İkisi aynı soruyu mu cevaplıyor?”

Çoğu mutabakat farkı bir hesap hatası değil, bir tanım farkıdır. Ve tanım farkını bulmanın tek yolu satırlara inmek; toplam asla söylemez.

Bir de şu: uzun süredir elle yapılan bir işin içinde, kimsenin yazmadığı doğru kararlar gizlidir. Otomatikleştirirken o kararları da taşımak gerekiyor — yoksa “modernleştirdim” dediğin şey bilgi kaybı olur.

ÖlçümHata avı