Finansal Sistemler Kurmak İçin Mühendislik İlkeleri
(substack.wasteman.codes)- Muhasebe, son birkaç yüz yılda büyük ölçüde değişmedi
- Buna rağmen, finansal sistemler için yazılımı doğru şekilde nasıl inşa etmek gerektiği konusunda büyük bir kafa karışıklığı var
- Bu yazı, büyük şirketlerde finansal sistemler kurma deneyimlerinden çıkarılan dersleri paylaşıyor
- Odak noktası muhasebe sistemleri olacak, ancak bu ilkeler daha genel finansal sistemler için de geçerli
Temel finans terimlerinin tanımları
- Genel muhasebe defteri (General Ledger, GL): Belirli bir dönem boyunca tüm finansal işlemleri özetleyen şirketin ana muhasebe kaydı. İlgili alt defterlerin toplamı olarak düşünülebilir
- Alt defter (Sub-ledger): Belirli bir GL ile ilişkili tüm tekil işlemlere dair ayrıntıları içerir. Alt defter kayıtları, genel muhasebe defterine göre çok daha ayrıntılı veri içerir (ör. belirli bir müşteri, bir siparişin belirli bir kalemi vb.). Alt defter ile GL arasındaki veri farkı, iş modeline ve üzerinde çalışılan veri hacmine göre değişir. Bazı küçük işletmeler alt defter olmadan çalışabilir, ancak bu kadar küçük ölçekte özel yazılım gereksinimi de pek olası değildir
- Finansal kayıt (Financial Record): Genel muhasebe defteri ve alt defterler için toplu ifade
- Önemlilik (Material): Finansal tablolardaki bir bilgi çarpıtmasının makul bir paydaşın kararını etkileyip etkilemeyeceğini ifade eder. Bu tanım bilinçli olarak biraz muğlaktır, çünkü farklı şirketlerin farklı önemlilik eşikleri vardır. Örneğin yıllık geliri 250 bin dolar olan bir şirket için önemli olan bir şey, yıllık geliri 1 milyar dolar olan bir şirket için önemli olmayabilir. Tasarım açısından bu kavramın temel değeri, farklı finansal veri kategorilerini sınıflandırmaktır
High Level Data Flow
Business System --(Financial Events)--> Sub Ledger(s) --(Summarized Accounting Entries)--> General Ledger
Muhasebe sistemlerinin üç temel hedefi
- Doğruluk (Accurate): Finansal kayıtlar, işletmenin bilinen durumunu yansıtmalıdır
- Örnek: 9,99 dolarlık bir üründen 10 adet satıldıysa, ilgili finansal kaydın toplamı 99,90 dolar olmalıdır
- Bu açık görünebilir, ancak binlerce ya da milyonlarca işlemi toplulaştırırken sistemler arası basit toplama veya yuvarlama hataları ciddi yanlışlıklara yol açabilir
-
Wasteman’in notu
- İnsanlar adlandırmanın bilgisayar bilimindeki en zor problem olduğunu söyler, ama bence toplama işlemi ondan sonra gelir
- Son birkaç yılda büyük ölçekli finansal sistemlerde çalışırken, küçücük hataların veride büyük farklar yarattığını sayısız kez gördüm
floatile toplam almaktan hiç bahsetmeyelim. Neden her zaman tamsayı kullanmanız gerektiğini zor yoldan öğrendim
- Finansal kayıtlar eksiksiz (complete) olmalıdır
- Daha somut olarak, alt defterler ve genel muhasebe defteri belirli bir ana kadar gerçekleşen tüm iş faaliyetlerini eksiksiz biçimde temsil etmelidir
- Gerçekleşmiş ama finansal kayıtlarda yer almayan olaylar varsa, sistem eksiksiz değildir
- Bu, eventual consistency'ye asla izin verilmeyeceği anlamına gelmez
- Verinin ne zaman eksiksiz hale geleceğini bilmelisiniz ki paydaşlara verinin kesinleştiğini söyleyebilesiniz
-
Wasteman’in notu
- Eksiksizliği garanti etmek de şaşırtıcı derecede zor bir problemdir
- Sistem büyüdükçe veri birden fazla sistemden geçerken yanlışlıkla değişebilir ya da kaybolabilir
- Denetlenebilirlik (Auditable): Paydaşların hataları tespit edebilmesi ve iş performansını doğru ölçebilmesi için finansal kayıtlar kolayca denetlenebilir olmalıdır
- Zamanlılık (Timely): Muhasebe sistemi, işletmenin belirli ihtiyaçlarını karşılamalıdır
- Küçük işletmeler için ay sonunda tüm sayıları dökmek yeterli olabilir, ancak büyük şirketler genellikle gerçek zamana yakın sistemler ister
- Bu sayede ay boyunca finansal durumu izleyebilir, finansal verilere dayalı kararları daha hızlı alabilir ve ay/çeyrek başındaki kapanış baskısını azaltabilirler
- İhtiyaç ne olursa olsun, muhasebe sistemimiz işletmenin gereksinimlerini karşılamalı ve onlar için zamanlı olan neyse onu sağlamalıdır
-
Wasteman’in notu
- İnsanlar zamanlılık konusunda batch ve streaming sistemler tartışmasında kaybolma eğiliminde
- Bence çoğu sistem için bu önemli bir ayrım değil
- Saniyelerden dakikalara uzanan çok kısa gecikme süreleri sizin için önemliyse, o zaman önemlidir
- Ama kullanıcıların günde birkaç kereden daha sık güncelleme görmesine gerek yokken, insanların hangi yaklaşımın seçilmesi gerektiğini tartıştığını şaşırtıcı derecede sık duyuyorum
- Bir şey istenmiş olması, gerçekten gerekli olduğu anlamına gelmez
Muhasebe sistemlerinin uyması gereken üç temel mühendislik ilkesi
- Verinin değişmezliği (Immutability) ve kalıcılığı (Durability)
- Denetlenebilirlik sağlar; bu da hata ayıklama ve doğruluğa yardımcı olur
- Veri değişmez olduğunda, sistemin durumunu herhangi bir anda kaydedebilirsiniz
- Bu, sistemi geçmiş bir durumdan yeniden hesaplamayı son derece kolaylaştırır. Çünkü hiçbir durum kaybolmaz
- Finansal kayıtlara bir kez yazılan veri silinemez
- Sistemdeki tüm düzeltmeler yeni finansal işlemler olarak gösterilmelidir
- Örnek: Sistemde bir hata varsa ve 900 dolar olması gereken bir hizmet yanlışlıkla 1000 dolara satılmış gibi raporlandıysa
- Bu hatayı düzeltmek için önce hatalı kayda karşılık gelen muhasebe girdisini ters çevirmeli, ardından doğru tutarla muhasebe girdisini yeniden yazmalısınız
- Veri en küçük ayrıntı düzeyinde tutulmalıdır (Data recorded at the smallest grain)
- Yukarıdaki ilkeye benzer şekilde, bu da net bir denetim izi oluşturmak için son derece önemlidir
- Finansal raporlar ve genel muhasebe defteri özetlenmiş olsa da, daha ayrıntılı olaylardan hesaplanırlar
- Veri anlaşılmadığında, sorunun ne olduğunu hata ayıklamak için en ayrıntılı veriye ihtiyaç duyarsınız
- Veriyi en düşük ayrıntı seviyesinde saklamak, o veri kümesinden türetilen verileri düzeltmeyi de çok kolaylaştırır
- Tek bir değişmez veri kümesi, o verinin tüm görünümleri için asıl doğruluk kaynağıysa,
- Bir görünümü düzeltmek için veriyi düzeltip ardından o görünümü üreten pipeline'ı yeniden çalıştırmanız yeterlidir
- Benzer şekilde, muhasebeciler defterleri kapatmaya hazırlanırken,
- Defterlerin doğru olduğunu doğrulamak için gerçekleşen tüm işlemleri ve hesap bakiyelerini mutabık hale getirirler
- Bir uyumsuzluk bulunursa, soruna yol açan tam işlemi derinlemesine inceleyebilirler
- İdempotent olmalıdır
- Her finansal olay yalnızca bir kez işlenebilmelidir; finansal kayıtlardaki tekrarlar bariz yanlışlıklara yol açar
- Bu nedenle finansal kayıt üreten tüm kod idempotent olmalıdır
- İdempotent, bir işlemi birden çok kez uygulasanız bile sonucun değişmemesi özelliğidir
- Yani bir finansal olayı birden fazla kez işleseniz bile sonuç ilk işlemeyle aynı olmalıdır
En iyi uygulamalar
- Finansal tutarları temsil etmek için tamsayıları tercih edin: Aritmetik işlemler çok daha kolay olur.
floatkullanmaktan kaçının - Para birimi dönüşümünde hassasiyet kaybını en aza indirmek için finansal tutarlar için yeterli ayrıntı düzeyini destekleyin
- Yalnızca dolar ile çalışıyorsanız sent cinsinden ifade etmek yeterli olabilir
- Küresel işletmeler için mikro birimleri veya
DECIMAL(19, 4)gibi ondalık türleri tercih edin - Finansal sistemlerde ondalık kullanımı yaygın olsa da, reklam finans sistemlerinde mikro birimler standarttır
- Tutarlı bir yuvarlama yöntemi kullanın: Yuvarlama yöntemi, beklenen tutar ile önemli farklar yaratabilir
- 5 ve üzerini bir sonraki anlamlı haneye yuvarlamak, 4 ve altını aşağı yuvarlamak
- Her zaman yukarı yuvarlamak gibi yöntemler
- Önemli olan, her yerde tutarlılığı korumaktır (işlem başına 1 sent fark varsa, 10 milyon işlemde bu 100 bin dolar fark eder)
- Mümkün olduğunca para birimi dönüşümünü geciktirin: Para birimini erken dönüştürmek hassasiyet kaybına yol açabilir
- Para birimi dönüşümünü, yerel para biriminde toplulaştırma tamamlanana kadar erteleyin
- Zamanın tamsayı gösterimini kullanın: Biraz tartışmalı olabilir ama güçlü biçimde tavsiye edilir
- Timestamp'leri nesne olarak parse eden farklı kütüphaneler bunları farklı biçimde işler
- Bu baş ağrılarını önlemek için tamsayı kullanmak daha iyidir
- Unix timestamp ya da UTC tabanlı tamsayı datetime gösterimleri gayet iyi çalışır
- Sistemler arasında ne kadar az veri dönüşümü olursa o kadar iyidir
-
Wasteman’in notu
- Yaz saati uygulamasıyla ilgili hatalardan hiç bahsetmedim bile. Artan tamsayılar kullanırsanız bunlardan tamamen kaçınabilirsiniz
datetimekullanmakta ısrarcıysanız, en azından UTC kullanın. Çok büyük şirketlerin bile UTC olmayan timestamp'ler kullanması şaşırtıcı derecede yaygın
2 yorum
Bu gerçekten çok faydalı. Tip dönüşümünü (
decimal,float,double) ve yuvarlamayı hiç düşünmeden, sahadaki iş tartışmaları yapılmadan öylece uygulamak büyük sorunlara yol açabilir.Hacker News görüşü
Tutarlı bir yuvarlama metodolojisi kullanmanın önemi vurgulanıyor
Zamanı tamsayı olarak ifade etme yöntemi öneriliyor
Muhasebe sistemlerinde ilişkisel veritabanı kullanımı öneriliyor
Muhasebe sistemlerinin temel hedeflerinin doğruluk, denetlenebilirlik ve zamanındalık olduğu belirtiliyor
Muhasebe sistemlerinin bütünlüğüne dair görüş
Küresel işletmeler için en az 8 ondalık basamak kullanımı öneriliyor
Kullanıcı arayüzünün (UI) önemi belirtiliyor
Batch processing ile streaming processing arasındaki fark açıklanıyor
TypeScript ile bir fatura sistemi kurma deneyimi paylaşılıyor
Standart kütüphane sınıflarının kullanımı öneriliyor
Yuvarlama ve veri paylaşımındaki zorluklar açıklanıyor
ABD'deki en büyük 10 bankanın API'leriyle çalışma deneyimi paylaşılıyor
Martin Fowler'ın "Accounting Patterns" öneriliyor