Çift taraflı muhasebeyi yönlü grafik olarak ifade etmek
(matheusportela.com)- Muhasebe terimlerine aşina olmasanız bile, hesap ve bakiyeyi zaman içinde izlenen bir yapı olarak görürseniz çift taraflı muhasebeyi bir para akışı modeli olarak anlayabilirsiniz
- Yalnızca mevcut bakiyeyi üzerine yazarak güncelleyen tablolar değişim sürecini kaybeder; buna karşılık defter, her işlem oluştuğunda yeni bir satır ekleyerek geçmişi ve düzeltme izlerini korur
- Tek taraflı kayıt, hesap bazındaki değişimleri kaydetmek için yeterli olabilir; ancak birden çok hesap birlikte hareket ettiğinde, kaynak ve hedefi göstermek için ilgili kalemleri bir işlem altında toplamak gerekir
- Çift taraflı muhasebede her işlemde çıkan tutar ile giren tutar eşit olmalıdır; bu denge koşulu, elle tutulan muhasebede bir checksum gibi hata yakalamaya yardımcı olur
- Hesapları ve işlemleri düğüm, borç/alacak kalemlerini ise yönlü kenarlar olarak görürseniz, defter zamanla büyüyen bir yönlü grafik haline gelir ve finansal tablolar da bunun görselleştirmesi olarak görülebilir
Yalnızca bakiyeyi kaydederken kaybolan bilgi
- Muhasebe, zaman içinde sayılabilen varlıkları izleme işidir; burada odak para akışıdır
- Örnekte başlangıç durumu, 1 Ocak 2024'te Alice'in $100, Bob'un ise $50'a sahip olmasıdır
- Alice Bob'a bir kitap için $20 ödediğinde, Alice'in bakiyesi $80'e, Bob'un bakiyesi ise $70'e düşer/yükselir
- Burada hesap(account), paranın tutulduğu yerdir; bakiye(balance) ise belirli bir anda hesapta bulunan para miktarıdır
- Yalnızca güncel bakiyeyi üzerine yazarak saklarsanız, Alice'in neden $80'e sahip olduğunu anlamak zorlaşır
- Başlangıçta $0'dan $80 mi aldı
- Yoksa $10.000'dan $9.920 mi harcadı, ayırt edilemez
- Sadece bakiye anlık görüntülerini bırakan yaklaşım, değişimin nasıl gerçekleştiğine dair süreci siler
Tek taraflı kayıt defteri ve değiştirilemez kayıt
- Değişim geçmişini korumak için, her işlem gerçekleştiğinde mevcut değeri değiştirmek yerine yeni bir satır eklemek gerekir
- Defter kalemlerinde genellikle şu bilgiler bulunur
- Description: İşlem açıklaması, ödeme yapılan taraf, referans numarası gibi insan tarafından okunabilir bilgiler
- Date: İşlemin gerçekleştiği tarih; aylık raporlama gibi dönemsel gruplamalar için de kullanılabilir
- Balance: İşlem sonrası hesap bakiyesi; tekrarlı bilgi olsa da veriyi gözden geçirmek için faydalıdır
- Her satır bir kayıt(entry), tek bir hesaba ait kayıtların toplamı ise bir **defter(ledger)**dir
- Alice'in defterinde 1 Ocak 2024 opening balance $100, 1 Şubat 2024 bought book -$20 olarak yer alır
- Bob'un defterinde ise opening balance $50, sold book $20 bulunur
- Bu yaklaşım bir tek taraflı kayıt (single-entry bookkeeping) sistemidir
- Her hesabın kendi defteri vardır
- Bir seferde tek bir hesabı etkileyen kayıtlar tutulur
- Küçük işletmeler veya kişisel finans için uygun olabilir
Defter, event sourcing gibi çalışır
- Defterin önemli özelliklerinden biri, verinin değiştirilemez (immutable) olmasıdır
- Bir kayıt yazıldıktan sonra, tüm geçmişi korumak için değiştirilmez
- Kitap fiyatı yanlışlıkla $20 yazılmış ama gerçek fiyat $30 ise, mevcut satırı değiştirmeniz durumunda ilk tutarı ve düzeltme gerçeğini kaybedersiniz
- Daha iyi yaklaşım, mevcut kaydı dengeleyen yeni bir kayıt eklemek ve ardından doğru kaydı yeniden girmektir
- -$20 kaydı +$20 ile iptal edilir
- Ardından yeni bir -$30 kaydı yazılır
- Son bakiye yine $70 olur, ancak hata ve düzeltme nedeni korunur
- Bu yaklaşım, bilgisayar bilimindeki event sourcing ile benzerdir
- Sistemde meydana gelen olaylar saklanır
- Olaylar yeniden oynatılarak güncel durum hesaplanır
- Belirli bir andaki durum yeniden üretilebilir
Çift taraflı muhasebenin gerekli olduğu an
- Birden çok hesabın birlikte hareket ettiği işlemlerde, yalnızca tek taraflı kayıt ile ilişkiyi açık biçimde görmek zordur
- Alice'in -$20'si ile Bob'un +$20'si aynı paradır; ancak yalnızca yalın defterlere bakıldığında Bob'un parayı Charlie'den almış olma ihtimaliyle ayırt edilemez
- İlgili kayıtları bir işlem(transaction) altında toplarsanız, bunların aynı olaya ait olduğunu açıkça belirtebilirsiniz
- Transaction 1: Alice'in opening balance'i
- Transaction 2: Bob'un opening balance'i
- Transaction 3: Alice'in Bob'dan kitap satın alması
- İşlem, farklı hesapları etkileyen ilişkili kayıtların bir araya gelmiş halidir
- Çift taraflı muhasebe, hesaplar arasındaki para akışını görebilmek için ilgili kayıtları işlem düzeyinde birbirine bağlar
Borç, alacak ve denge koşulu
- Geleneksel muhasebe, para akışını iki sütunla ifade eder: debit ve credit
- Credit: hesaptan çıkan para kaydı
- Debit: hesaba giren para kaydı
- Alice Bob'a $20 ödediğinde, Alice hesabında $20 credit, Bob hesabında $20 debit olarak kaydedilir
- Banka kartlarındaki credit/debit terimleri ile muhasebedeki debit/credit terimleri farklı şekilde kullanılır
- Kâğıt defterlerde, sol tarafın debit, sağ tarafın credit olduğu T-account biçimi kullanılırdı
- Bilgisayar sistemlerinde bu iki sütunu aynen korumak zorunda değilsiniz
Typesütununa Debit veya Credit koyupAmountalanını ayrı tutabilirsiniz- Ya da credit'i negatif, debit'i pozitif olarak tanımlayan tek bir tutar sütunu kullanabilirsiniz
- Geleneksel terimlere kıyasla incoming money ve outgoing money, daha az kafa karıştırıcı ifadeler olabilir
İşlemler iki kayıtla sınırlı değildir
- Çift taraflı muhasebenin temel ilkesi, her işlemden sonra sistemdeki toplam para miktarının değişmemesidir
- Belirli bir hesabın bakiyesi artabilir ya da azalabilir, ancak tüm hesap bakiyelerinin toplamı sabit kalmalıdır
- Opening balance kayıtlarının da dengeli olabilmesi için, paranın bir yerden gelmesi gerekir
- Örnekte bunun için bir Bank hesabı eklenir ve Alice'in $100'ü ile Bob'un $50'si Bank'tan çıkmış gibi kaydedilir
- Bu Bank hesabı, kurala uymayı sağlayan bir tür geçici hesaptır; muhasebe terimiyle contra account olarak düşünülebilir
- Tüm işlemlerde çıkan para ile giren para eşit olmalıdır; bu, elle tutulan muhasebede hataları yakalayan bir checksum gibi çalışır
- Daha karmaşık işlemler de aynı ilkeyle modellenebilir
- Alice Bob'a $20 öder ve kredi kartı şirketine $2 döviz kuru/işlem ücreti öder
- Bob Alice'ten $20 alır ve vergi otoritesine $2 satış vergisi, kredi kartı şirketine ise $1 ücret öder
- Kredi kartı şirketi Alice'ten $2, Bob'dan $1 alır
- Vergi otoritesi Bob'dan $2 alır
- Bu durumda tek bir Transaction 3 içinde tam olarak 8 kayıt bulunur
- “Double-entry”, bir işlemin yalnızca iki kaydı olduğu anlamına gelmez; paranın çıkan tarafı ve giren tarafı olmak üzere iki yüzü olduğu anlamına gelir
Defteri yönlü grafik olarak görmek
- Çift taraflı muhasebe, para akışının yönlü grafik olarak modellenmesi şeklinde görülebilir
- Grafikteki karşılıklar şöyledir
- Hesaplar grafiğin düğümleridir
- İşlemler de ayrı düğümlerdir
- Credit kayıtları, hesaptan işleme giden çıkan kenarlardır
- Debit kayıtları, işlemden hesaba giden giren kenarlardır
- Kayıt tutarı, kenarın değeridir
- Hesap bakiyesi, giren kenarların toplamından çıkan kenarların toplamı çıkarılarak bulunur
- Transaction 1, Bank'tan Alice'e $100 aktarır
- Transaction 2, Bank'tan Bob'a $50 aktarır
- Transaction 3, Alice'ten Bob'a $20 aktarır
- Bu gösterimde Alice'in bakiyesi $80, Bob'un bakiyesi $70 olur
Karmaşık işlemleri bölmek bir modelleme tercihidir
- Ücretleri ve vergileri tek bir işleme koyarsanız, Transaction 3'ün kenar sayısı artar ve yapı karmaşıklaşır
- Aynı para akışını daha küçük işlemlere bölmek de mümkündür
- Alice hesabından $22 çıkar
- Bob $19 alır
- Kalan $3 kredi kartı şirketine gider
- Bob'un $2 satış vergisi ayrı bir Transaction 4 olarak işlenir
- İşlemleri ve kayıtları nasıl gruplarsanız gruplayın, nihai hesap bakiyeleri aynı kalabilir
- Alice: $78
- Bob: $67
- Tax authority: $2
- Credit card company: $3
- Muhasebe sistemleri, farklı gereksinimleri karşılayacak kadar esnektir; işlem ve kayıtların nasıl gruplandırılacağı işe uygun biçimde belirlenmelidir
Finansal tablolar grafiğin görselleştirmesidir
- Yeni işlemler eklendikçe grafik zaman içinde büyür
- Grafiğin temel özellikleri ise değişmeden kalır
- Hesaplar düğüm olarak kalır
- İşlemler, para akışını zorunlu kılan düğümler olarak kalır
- Her işlemde çıkan tutarların toplamı ile giren tutarların toplamı eşit olmalıdır
- Balance sheet, income statement, cash flow statement bu grafiğin görselleştirmeleri olarak görülebilir
- Assets, liabilities, equity, income, expenses gibi sınıflandırmalar, grafikteki düğüm grupları olarak düşünülebilir
- Grafik bakış açısıyla, credit ve debit'in her sınıflandırmanın bakiyesini nasıl artırıp azalttığını daha sezgisel biçimde anlamak mümkündür
1 yorum
Hacker News yorumları
Çift taraflı defter tutmayı “bir Alice kalemi, bir Bob kalemi” diye açıklamak tuhaf bir tercih gibi görünüyor
İşlemin iki tarafı varsa iki yerde kaydedilebileceği zaten açık; ama asıl nokta, işlemin her bir tarafı için iki kalem gerekmesidir. Alice Bob’dan bir kitap satın alırsa dört kalem oluşur
Eğitim amaçlı basitleştirme olduğunu anlıyorum, ama bunun özü çıkarıp atan aşırı bir basitleştirme olduğunu düşünüyorum
Örneğin nakitle borçlar ödendiğinde Accounts Payable aktörüne ve Cash aktörüne aynı anda mesaj gönderilir; her aktör de bu olayı kendi karakterine uygun şekilde borç/alacak olarak çevirip bakiyesini korur. Bu açıdan çift taraflı defter tutma, her olayın çift sayıda aktör tarafından tam olarak birer kez soğurulması gerektiği anlamına daha yakındır
Bir ödeme hattı kuruyorsanız, olayın kendisi de işlem niyetini izleyen bir meta olaydan türetilmiş bir çift olaydan biri olabilir. Muhasebede grafın kenarı diye söz edilen şeyi para değil, türetilmiş olay hiyerarşisi içindeki veri olarak görmek daha kullanışlıdır
Yine de özgün metin bu benzetmenin ne işe yaradığını netleştirememiş; kafa karışıklığını azaltmak yerine artırmasından endişeleniyorum
Bob’un muhasebe defteriyle ilgilenmiyorum; yalnızca kendi defterimi izlemek istiyorum. Bir kitap satın aldıysam, kendi muhasebe defterimde bu işlemi çift taraflı defter tutma ile nasıl kaydetmem gerektiğini merak ederim
Üstelik Bob defter tutmuyor, kitap satıyor ;-)
Bu yazıyı “double” kısmını doğru açıklayacak şekilde düzeltmek gerekse nasıl yapılmalı? Yalnızca Bob’un ya da Alice’in bakış açısından yapmak mümkün mü?
Örneğin banka, kredimi geri ödeyemeyeceğime karar verip defterlerinde bunu 0’a düşürebilir. Ben ödemeyi düşündüğüm için kendi defterimde borcu hâlâ bırakabilirim. Banka kendi sisteminde ilgili kalemleri oluşturur ve borç/alacak tutar; ben hiçbir şey yapmasam da kendi defterim dengede kalır
Çift taraflı defter tutma başka aktörlerden bağımsızdır; yalnızca kişinin kendi defteriyle ilgilidir
Muhasebenin güzelliği ve etkisi bence hafife alınıyor
Çok az sayıda formülle, yani muhasebe özdeşliği ve gelir tablosu ile finansal durum tablosu gibi finansal tablolarla, herhangi bir organizasyonda olup bitenleri kabaca karşılaştırılabilir biçimde ifade etmek mümkün. Kalkülüsün temel teoremi ya da biyolojinin merkezi dogması gibi bir his de veriyor
Muhasebe, matematiğin ve yazılı dilin de kökenlerinden biridir. Antik Mezopotamya uygarlıkları başlangıçta malları izlemek için nesnelerin biçimini taklit eden “muhasebe jetonları” kullandı; bunun da yazılı dile, örneğin hiyerogliflere, evrildiği düşünülebilir
Daha sonra Al-Khwarizmi, İslam miras hukukunu çözmek için Al-Jabr’ı, yani cebiri geliştirdi; miras paylaşım kuralları denklemlere dönüşünce bunları hızlı ve doğru çözme ihtiyacı doğdu. Al-Khwarizmi’nin ikinci derece denklem çözümü, “algorithm” adının kökeni oldu
https://en.wikipedia.org/wiki/Accounting_identity
https://en.wikipedia.org/wiki/History_of_accounting
https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
https://en.wikipedia.org/wiki/Al-Jabr
https://en.wikipedia.org/wiki/Al-Khwarizmi
Negatif sayılar ilk olarak Çin’de 3. yüzyıl civarında kullanıldı; Avrupa’da ise 16. yüzyıla kadar yaygın kullanılmadı. Modern çift taraflı defter tutma 14. yüzyıl Avrupa’sında ortaya çıktı
Bu yüzden borç sütunu ile alacak sütununu ayrı tutan ve tanımı biraz tuhaf görünen geleneksel yöntem, sistemi yalnızca pozitif sayılarla çalıştırmanın en iyi yoluydu
Organizasyon tasarımının önemli yönleri arasında finansal tablolarla yalnızca gevşek ilişkili olan pek çok şey var
Defter tutma toplumun tüm katmanlarına kök saldıktan sonra negatif sayılar da pozitif sayılar kadar gerçek kabul edilmeye başlandı
Çift taraflı muhasebe, gülünç “credit” ve “debit” terimleri bir kenara bırakılınca çok kolay anlaşılır
İşin özü, muhasebe denkleminin her zaman doğru kalmasını sağlamaktır. Temel denklem Equity = Assets - Liabilities’tir; kâr da nihayetinde özkaynağa girdiği için Equity + Income - Expenses = Assets - Liabilities olur. Negatifleri ortadan kaldıracak şekilde düzenlersek Equity + Income + Liabilities = Assets + Expenses olur
Bu denklemin her zaman doğru olması gerekir; aksi halde para yoktan var olmuş ya da yok olmuş sayılır. Bu yüzden denklemin sol tarafındaki bir hesaba para eklerseniz, karşı taraftaki bir hesaba da aynı tutarı eklemeli ya da aynı taraftan aynı tutarı çıkarmalısınız
Örneğin 5 dolara limonata satarsanız Sales(Income) hesabına 5 dolar eklersiniz, Current Account(Assets) hesabına da 5 dolar eklersiniz
“credit” ve “debit”in gülünç olmasının nedeni, tanımlarının hesap türüne göre tersine dönmesidir; insanların kafasını karıştıran başlıca neden de bu saçma dil kullanımıdır
100 seviyesindeki muhasebe dersinin hocası bunu oldukça özlü söylemişti. Debit sol sütundaki kalemdir, Credit sağ sütundaki kalemdir. O işlemin işletme açısından ne anlama geldiği hesaba bağlıdır
Muhasebe öğrenmemiş biri için bu terimlerin kullanımı inanılmaz derecede kafa karıştırıcı; kafası karışan kişiye verilen birçok yanıt teknik olarak doğru olsa da aynı zamanda pek yardımcı olmuyor. Çünkü zaten terimleri bildiğiniz varsayımına dayanıyorlar
“Bakiye artmışken banka hesabı neden debited ediliyor? Debit negatif değil mi? Nakit bakiyesi negatif mi gösteriliyor?” sorusu gerçekten iyi bir soru. Sezgisel olarak direct debit paranın çıkmasıdır, debit card ile para harcarsınız, debit de debt gibi duyulur; bu yüzden debit’in her zaman negatif olduğunu düşünürsünüz
Aynı kelime üzerinden sanki farklı diller konuşuyormuş gibi yaşanan bu ayrışma hem ilginç hem de sinir bozucu. Bazen de küçük bir ifadeye takılıp kişinin haklı olduğunu göstermeye çalışmasına dönüşüyor
Çünkü limonataya 5 dolar harcayan kişi açısından kendi Sales kalemine 5 dolar koymak diye bir şey söz konusu değil. Bu yazı ve yorumlarda sözü edilen kafa karışıklığının tam olarak ne olduğunu hâlâ bütünüyle anlayabilmiş değilim
credit kaynak, debit varış yeri demektir
Bir müşteriye 10.000 euro fatura keserseniz, güncel kurla 11.000 dolarlık bir taahhüt oluşur. Bu durumda kaynak olan “Income: Customer A” hesabına 11.000 dolar credit girer, “Assets: Accounts Receivable” hesabına 11.000 dolar debit girersiniz
Daha sonra müşteri ödeme yaptığında kur değişmiş ve yalnızca 10.500 dolar almışsanız, aslen 11.000 dolar olarak kaydettiğiniz taahhüt kaynak olduğu için Accounts Receivable hesabına 11.000 dolar credit girersiniz. 10.500 dolar nakit aldığınız için cash hesabına 10.500 dolar debit girer, borç ve alacağı dengelemek için de “Expenses: Loss on Foreign Exchange” hesabına 500 dolar debit girersiniz
Şirketi genellikle her iş gününde tasfiye etmiyoruz; öyleyse neden o 500 doları varsayımsal bir anlık tasfiye senaryosuna zorla sığdırmaya çalışalım? Bunu sadece credit ve debit dengesiyle kaydetmek yeterli
Bağımsız değişkenin Y eksenine konduğu çok fazla grafik vardı
“Credit hesaptan para çıkan kalemdir, Debit hesaba para giren kalemdir” doğru değil
debit ve credit’in anlamı hesap türüne göre değişir: https://en.wikipedia.org/wiki/Debits_and_credits
CPA olmak için birden fazla ders gerekmesinin bir nedeni olabilir: https://www.accounting.com/careers/cpa/how-to-become/
Bana, kalemleri insanların girip hesaplamaları insanların yaptığı dönemde belirli hataları yakalamak için işi iki katına çıkaran bir yöntem gibi görünüyor. Kendi içinde mantıklı
Ama tüm hesaplamaları bilgisayarların yaptığı bir dünyada büyüdüğüm için, aynı işi tekrarlamama ilkesini ihlal ediyor gibi geliyor. Aynı şeyi iki yere yazarsanız ikisinden biri eninde sonunda yanlış olur
Muhasebe modern dönemde tasarlansaydı böyle yapılmazdı diye düşünüyorum. Muhasebeci olmamam ve bunu anlamamam sistemin yanlış olduğu anlamına gelmez; ama “credit bir varlık hesabını azaltır” ifadesinde hissettiğim kafa karışıklığı, bir şeylerin temelde ters olduğuna dair bir işaret gibi geliyor
CR kalemi, şirketin borçlu olduğu şeyin, yani alacaklılara veya hissedarlara karşı yükümlülüğünün arttığı anlamına gelir; DR kalemi ise şirketin sahip olduğu şeyin arttığı anlamına gelir
Muhasebe denklemiyle ilişkisi için buraya bakın: https://news.ycombinator.com/item?id=32501707
credit/debit terimleri konusunda epey kafa karışıklığı görüyorum
Modern bir bakışla daha basit düşünmek için, muhasebenin negatif sayıların yaygın kullanımından çok daha eski olduğunu hatırlamak yeterli. Muhasebe bugün icat edilseydi, debit/credit hesapları yerine pozitif/negatif hesaplar kullanılmış olması kuvvetle muhtemeldi
Toplama üzerindeki cebir bugün bize doğal geliyor, ama 1604’te sıradan bir tüccar için apaçık değildi; negatif sayılar da o dönemde pek iyi karşılanmıyordu
Önemli olan, işlemlerin her zaman iki yüzü olması ve bunların birbirinin ters işlemi olması. credit ve debit nihayetinde sayılar üzerindeki ters işlemler
Bu yüzden credit = debit ise işlemin dengede olduğu kuralı konabilir. Modern biçimde debit + credit = 0 diye de görülebilir, ama bu sistem ortaya çıktığında negatif sayılar sevilmediği için bu, hedeften çok her zaman gerçekleşen hoş bir tesadüfe daha yakın
Eldeki nakdi en pozitif, yani debit karakterli hesap olarak görüp tersinden düşünmek mantıklı. Bir gideri kaydetmek için nakit hesabını ters yönde işlemelisin, bu yüzden credit edilir; paranın gittiği yere de karşı kalem olarak debit yapılır. Dolayısıyla gider hesapları genellikle debit bakiyesi taşır
Nakit nereden geldi? Gelirden geldi; nakdi debit benzeri yapmak istiyorsan, işlemin dengesini bozmaması için kaynağın credit benzeri olması gerekir. Bu yüzden gelir hesapları genellikle credit hesabıdır; yani çoğunlukla negatif bakiye ya da “credit normal” taşır
Bu sistemin güzel yanı, gündelik tüm işlemlerin dengeli işlemlere indirgenmesi ve olası hesapların her birinin genellikle credit ya da debit olan tutarlı bir bakiye karakterine sahip olması. Gerçekten zarif
Bunu ve muhasebe denklemini ezberlersen, kalan tüm hesap türlerinin normal bakiyesini çıkarabilirsin
Yaklaşık bir ay önce PTA subreddit’inde PTA söz dizimini daha sezgisel hale getirme üzerine bir tartışma başlatmıştım; biri “from”, yani credit/negatif hesabı ve “to”, yani debit/pozitif hesabı oklarla göstermeyi önermişti. Sayılarda işaret yok ve “credit” ile “debit” terimleri de kullanılmıyor; bu yüzden çok daha sezgisel geliyor
https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
Negatif sayılarla ilgili arka plan ilginç
Hâlâ fazla karmaşık. “Tabloya Transaction sütunu ekleyelim” noktasından itibaren yanlış yola sapıyor
Hesap verisini saklamamalı, işlemleri saklamalısın. Hesaplar buradan hesaplanmalı. “Transactions” tablosunda Date, Amount, SourceAccount, TargetAccount, Description alanları olsa yeter
Bana göre güzelleştiği nokta burası. Banka ekstrelerinden tanıdık geldiği için hesap merkezli düşünme alışkanlığını bırakıp nakit akışı olarak düşünmek gerekiyor
Elbette vergi amaçları için fazla basit. Bir işlemin birden çok kaynağı ya da birden çok hedefi olabileceği için yukarıdaki şemanın ayarlanması gerekir. Yine de asıl nokta, düşünme biçiminin farklı olması gerektiği
Bu, programcının akıllılık yapmaya çalışıp kaynak işlemlerden hesaplamak yerine kümülatif toplam tutmaya çalıştığının işareti. Orada ejderhalar var
Daha iyi tasarım, bir header ve bir detail tablosu kullanmaktır
Header: TransactionID, Date, Description, posting status ya da reconciliation status gibi gerekli alanlar
Detail: TransactionID, LineNumber, Account, Amount, Description, subledger referans numarası gibi gerekli alanlar
Böylece tek bir işlem keyfi sayıda hesabı etkileyebilir. Sonuçta işlem, birden çok hesabı etkileyebilen bir iş işlemini yansıtır
Ayrıntıda, her transfer çıktısının kaynak adresini içermesi gerekmesi gibi biraz daha karmaşık noktalar var; ama fikir aynı. Bu başlığın başka yerlerinde de söylendiği gibi, her işlem birden çok girdi ve birden çok çıktı gerektirir
Tüm işlemler düz metin dosyasında duruyor; değerlendirme gerektiğinde de buradan tüm defter anında oluşturuluyor
Muhasebeci değilim ama eskiden çift taraflı kayıt ve temel muhasebe çalışmaya karar vermiştim; HN’deki iyi bir başlık da dahil olmak üzere pek çok yerden çok şey öğrendim.
Bu yazıda çift taraflı kaydın nasıl çalıştığını ve bunun bir yönlü graf olduğunu fark etme sürecimi anlatıyorum. HN’de çok sayıda muhasebe meraklısı var; yanlış bir yer varsa eleştiri ya da düzeltme önerisi rica ederim.
https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
Keşke controller’larım satış performansını böyle grafik akışlar hâline getirse. Belli bir ölçeğe gelince muhasebe epey zorlaşıyor; muhasebe politikaları ekibinde profesör seviyesinde insanlara ihtiyaç duyulacak noktaya geliyor.
İstatistikten öğrendiğim şey, grafiklerin önemli olduğuydu. Uygun soyutlamayı kullanırsanız herhangi bir sayıyı bileşenlerinin grafı olarak gösterebilirsiniz. Bir anda anlayışım tamamen açıldı.
Bir tarafta içeri giren ya da dışarı çıkan para, diğer tarafta ürün ya da hizmet vardır. Muhasebedeki çift taraflı kayıt budur. Açık ve basit görünebilir ama benim alanımda bunu anlayan pek kişi yok.
İyi yazılmış bir yazı, ancak genel kabul görmüş anlamı olan terimleri yeniden tanımlarken dikkatli olmak gerekir.
Debit/Credit’i Incoming/Outgoing olarak değiştirmek başka bir jargon gibi görünüyor ve kafa karışıklığı yaratabilir. Herhangi bir bookkeeper “credit cash” ve “debit expense”in ne olduğunu anlar.
Bunu incoming/outgoing olarak değiştirmek, işi fiilen yapan kişiye ya da o işi açıklamak zorunda olan kişiye yardımcı olmaz. Yüzlerce yıldır işe yarayan adlandırmayı öğrenmek, benzetmelere yaslanmaktan daha değerlidir.
HN’de böyle bir tartışma açıldığında hep biri “çok basit, credit sadece…” der; hemen ardından da “ters biliyorsun, basit, credit…” diye bir yanıt gelir.
Ben o terimlerin sonsuza kadar terk edilmesini hiç umursamam.
Para credited edildiğinde ya da credit card kullandığınızda para bir yerden ortaya çıkmış gibi hissettirir ve iyi gelir; debit ise debt gibi duyulur ve paranız azalıyormuş gibi kötü hissettirir.
Aslında isimlerin bir nedeni olduğunu biliyorum ama dışarıdan bakan birinin karşılaştığı tüm kullanımlarla çelişen, sezgisel olmayan jargonda ısrar eden bir alansa daha az çakışan başka ifadeler kullanmak makul görünüyor.
Doğru jargonu yerli yerinde kullanarak konuşabiliyorsanız güvenilirliğiniz ciddi ölçüde artar.
Muhasebe jargonu olan debit/credit’i sıradan insanların diliyle açıklamanın neden jargon gibi göründüğünü pek anlamıyorum. Belki de sıradan biri olduğum içindir.
Muhasebe geçmişi olmayan birine credit/debt’i “para giriyor, para çıkıyor” diye açıklamak bu yazının bağlamında gayet uygun görünüyor. Burada credit/debit’in “gerçek” tanımı anlamlı biçimde farklı mı işliyor?
David P. Ellerman, kendi Pacioli group adını verdiği yapıya dayalı olarak muhasebeye matematiksel bir yaklaşım sunuyor.
Pacioli group’un geçici elemanı x//y gibi görünür; x ve y negatif olmayan tam sayılardır. x//y ile u//v, çapraz toplamlar x+v ve y+u eşitse eşdeğer kabul edilir.
Grup işlemi x//y + u//v = (x+u)//(y+v) şeklindedir; x//y’nin tersi y//x, birim eleman ise 0//0’dır. Ayrıntılar için örneğin şu belgeye bakılabilir: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...
Burada bir şeyi kaçırıyor gibiyim. İşlem geçmişini yönlü graf olarak görmek neye yarıyor?
Yüzlerce yıllık çift taraflı kayıt pratiğine göre geliştirilmiş yanı ne?
Birkaç işlemden oluşan oyuncak örnekte ancak çalışıyor gibi görünüyor; ama düğüm çiftleri arasında onlarca, yüzlerce kenar oluştuğunda grafın nasıl görüneceğini hayal etmek yeterli. Genel graf algoritmalarının nerede işe yarayacağını da bilmiyorum.
Penseyi çekiç gibi kullanmak gibi. Elbette yapılabilir ama neden yapalım?
Birincisi, kavramı anlamanın başka bir yolu. Çoğu durumda ilgisiz olabilir; ama zor bir muhasebe probleminin graf teorisi uygulanarak çözülüp çözülemeyeceğini ya da tersine, muhasebeden bir graf teorisi probleminin çözülüp çözülemeyeceğini kim bilebilir?
İkincisi, akışları görselleştirmenin başka bir yolu. Herkesin finansal okuryazarlığı ya da sayı sezgisi güçlü değil; bu yüzden sayı sütunları olan bir tablo verip akışı sayılardan çıkarmalarını istemek yerine bunu mekânsal olarak ifade edebilirsiniz. Her araç sadece uzmanlar için değildir.
Tüm birikimli geçmişi tek bir graf olarak görmek fazla olabilir; ancak sadece işlem tarihi filtresi eklemek bile başka görselleştirmelerin kaçırdığı içgörüler sağlayabilir. Konum gibi başka bilgilerle çapraz referanslandığında daha da faydalı olabilir.
Gerekçelendirmeyi kuramıyor; yazarın bu görselleştirmenin daha net bir anlayışa yardımcı olduğu yönündeki sözü de çift taraflı kaydı en baştan geek usulü açıklama sürecinde ortaya çıkan kategori hatası yüzünden zayıflıyor.
Üstelik sadece çok basit tek bir işlemi göstermiş. Vergisel amortisman ile muhasebesel amortismanın farklı olduğu durumlar, kur farkı kâr/zarar düzeltmeleri, franked dividends dağıtımı, PAYG, başkaları adına tutulan tutarlar, ertelenmiş gelirin kısmen muhasebeleştirilmesi gibi daha soyut şeylerin graf tabanlı görselleştirmeyle nasıl elde edileceğini bilmiyorum.
Mühendislerin, başka alanlarda zaten yerleşik olan temel ilkeleri, yazılım o alanı kopyalamaya başladıkça geç fark etmesi gibi.