Modüller neden yevmiyeye doğrudan yazmıyor?
Bir mimari karar kaydı: modüller ile defter arasına yerleştirilen katmanın gerekçesi ve maliyeti.
Tokuva'da satış, satınalma, üretim, bordro ve amortisman gibi olaylar yevmiye defterine doğrudan yazmaz. Her olay önce dengeli bir yevmiye taslağı üretir; taslak muhasebeci tarafından incelenip onaylandıktan sonra deftere düşer. Bu, yanlış hesap eşlemesinin defteri bozmasını engeller ve her kaydın kaynağını izlenebilir kılar.
Bu yazı bir ürün tanıtımı değil, bir mimari kararın gerekçesi. Karar şu: hiçbir modül yevmiye defterine doğrudan yazmaz.
Klasik yaklaşım ve sorunu
Çoğu ERP'de satış faturası kesildiğinde muhasebe fişi de aynı işlemde oluşur. Fatura kaydedilir, arka planda 120 borç, 600 alacak, 391 alacak satırları yazılır ve iş biter.
Hızlıdır ve çalışır — hesap eşlemesi doğru olduğu sürece.
Eşleme yanlış olduğunda ise sorun defterde ortaya çıkar. Örneğin ihracat faturaları yanlışlıkla yurt içi satış hesabına yazılmışsa, bunu fark ettiğinizde defterde onlarca hatalı kayıt vardır. Düzeltme yolu ters kayıt atmaktır: her hatalı fiş için bir iptal, bir de doğru fiş. Defter şişer, mizan okunmaz hale gelir, denetimde açıklama gerekir.
Araya bir katman
Tokuva'da fatura kesildiğinde muhasebe fişi oluşmaz. Bunun yerine bir yevmiye taslağı üretilir. Taslak dengelidir — borç ve alacak eşit olmadan kaydedilemez — ama henüz deftere düşmemiştir.
Muhasebeci Yevmiye Taslakları ekranında bekleyen taslakları görür. İnceleyip onaylarsa deftere düşer; reddederse düşmez ve ilgili modüle geri bildirim gider.
Bu kararın üç sonucu
Yanlış eşleme deftere ulaşmaz. Hatalı hesap eşlemesi taslakta görünür ve orada düzeltilir. Defter temiz kalır, ters kayıt gerekmez.
Kaynak izlenebilir. Her yevmiye satırı hangi belgeden doğduğunu ve hangi olay tipinden geldiğini taşır. "Bu 15.000 ₺'lik kayıt nereden geldi" sorusunun cevabı tek tıkla görünür.
Görev ayrılığı mümkün olur. Taslağı üreten sistem, onaylayan insandır. Kritik kayıtlarda dört göz kuralı uygulanabilir: oluşturan kişi onaylayamaz.
Bedeli ne oldu?
Dürüst olalım: bu tasarımın bir bedeli var.
Ek bir adım. Fatura kesip işi bitmiş saymak yerine, birinin taslakları onaylaması gerekiyor. Günde beş fatura kesen bir işletmede bu sürtünmedir.
Kavramsal yük. "Faturayı kestim ama muhasebede görünmüyor" durumu, yeni kullanıcı için kafa karıştırıcıdır. Eğitim kapsamına açıklanması gereken bir kavram eklenmiş olur.
Birikme riski. Onaylanmayan taslaklar birikirse dönem sonunda toplu onay baskısı oluşur ve bu, tek tek incelemeden onaylamaya yol açar — ki tasarımın amacını boşa çıkarır.
Son risk, yüksek hacimli ve düşük riskli olay tipleri için otomatik onay tanımlanabilmesiyle azaltılır. Kritik olan, otomatik onayın varsayılan değil bilinçli bir tercih olmasıdır.
Ne zaman doğru karar değil
Tek kullanıcılı, günde birkaç belge kesen küçük bir işletmede bu katman gereksiz sürtünmedir. Bu tasarım, muhasebenin ayrı bir işlev olduğu ölçekte anlam kazanır: faturayı kesen ile muhasebeleştiren farklı kişilerse, aradaki kapı değerlidir.
Mimari kararlar ölçekten bağımsız doğru olmaz. Bu karar, hedeflediğimiz ölçek için doğru.