Vakıf ERP · Muhasebe

Vakıf ERP — Muhasebe Boyut Prototipi

Bu prototip üretim için değil. Şimdiye kadar verilen kararların muhasebe sonuçlarını bir arada görmek ve farklı senaryolarda veri tabanını nasıl etkilediğini deneyimlemek için yapıldı. Hangi karara dayanan hangi davranışı sergilediği amber kutularda gösterilir.

Yedi boyut bir arada. Bağış girdiğinizde veya bir senaryoyu çalıştırdığınızda aynı tek yevmiye fişi yedi farklı kuralı aynı anda taşır. Sayfalar her boyutu ayrı bir mercekten gösterir; alttaki yevmiye satırları (defter) hepsinin tek kaynağıdır.

1 · Çift kayıt

defter mekaniği

Her işlem ≥2 satırlık dengeli yevmiye. Σ borç = Σ alacak. Kullanıcı tek tarafı (ne oldu) girer, kontrayı sistem üretir; borç/alacak/hesap kodu hiç gösterilmez.

Karar: cift-kayit-tercihi/decision-cift-kayit.md

2 · 12 iç hesap tipi

kapalı küme

İç motorda TDHP yok; 12 tip: kasa, banka, varlık, cari-bağışçı, cari-tedarikçi, cari-şube, fon-pozisyon, öz-kaynak, gelir, gider, kambiyo, olağandışı. Yalnız kasa+banka kullanıcı-görünür; diğer 10 tipi sistem otomatik açar.

Karar: cift-kayit-tercihi/decision-ic-hesap-plani.md

3 · Fon × Bölge (kompozit)

çift eksenli kısıt

Her yevmiye satırı (fon_id, bolge_id) taşır. Fiş hem org geneli hem her (fon, bölge) bucket'ı için dengelidir. Bucket'lar arası hareket için sistem otomatik interbucket düzeltici çift üretir.

Karar: cift-kayit-tercihi/decision-fon-temsil-modeli.md

4 · Şube = ayrı defter

inter-entity

Şube resmiyette ayrı tüzel kişilik. Her şube kendi defterine yarısını yazar; aradaki bakiye gerçek borç/alacak (cari-şube). Mutabakat ≠ fiili transfer: borç bakiyesi mutabakatı, ayrı kasa hareketi fiili transferi gösterir.

Karar: decision-fon-temsil-modeli.md §1.2

5 · Kayıt katmanı (Taslak/Kesin)

ertelemeli kayıt

Her kayıtta kayitDurumu ∈ {Taslak, Kesinleşmiş}. Varsayılan filtre yalnız Kesin'i gösterir. Tam görünüm tek toggle. Banka satırı daima Kesin doğar. Geri (Kesin→Taslak) yasaktır.

Karar: kayit-katmani/decision-kayit-katmani.md

6 · Cariler (arka plan)

sistem-oto

Bağışçı/tedarikçi/şube ilk kullanılınca cari hesabı sistem açar. Bakiyesi sadece o varlığa ait satırların toplamıdır. Kullanıcı "Murat'tan 1.000 aldım" der; sistem cari-bağışçı(Murat)'a alacak yazar.

Karar: decision-ic-hesap-plani.md §1.1 (4-6)

7 · Vakıf payı = gelir anında ayrıştırma

domain kuralı

Bağış kasaya girdiği anda iki bucket'a bölünür: net → (kısıtlı fon, bağışın bölgesi), pay → her zaman (Genel, Hür). Pay gider değildir; idari giderlerin kaynağıdır. Pay satırı bölgesizdir (rebind-region tetiklemesin diye).

Karar: decision-fon-butce-vakif-payi.md
Nasıl gezilir: Soldaki menüden "Senaryolar" sayfasına git, "1 · Basit bağış" ile başla. Her senaryo bir tıklama ile state'i doldurur; ardından "Yevmiye Defteri", "Kasalar", "Fon×Bölge Bilançosu", "Şube Mutabakatı" sayfalarında etkilerini gör. Sağ üstteki görünüm seçicisi (Tam / YalnızKesin) kayıt katmanı boyutunu dener.

Bağış Girişi (canlı)

Form doldurup "Kaydet" deyince sağ panelde hangi yevmiye satırlarının oluştuğunu ve neden o satırların gerektiğini göreceksin. Bu form tüm boyutları aynı anda tetikler.

Bağış

Banka kaynaklı → katman Kesinleşmiş zorlanır.
Yasal tavan %30. 0 = pay alma (hibe/kısıtlı kural).
Toplayandan farklıysa şubeler-arası cari (mutabakat) oluşur.

Son işlem · etkiler

Kasalar ve Bankalar

Kullanıcı-görünür hesaplar. Bakiyeler defterden canlı türetilir, kaydedilmiş bir alan değil. Görünüm filtresi aynı agregayı iki kez çalıştırır (Kesin / Tam).

Kayıt katmanı boyutu burada hissedilir: Görünüm Kesin iken sadece Kesinleşmiş satırlar toplanır. Tam iken Taslak satırlar da gelir. Banka satırı her durumda Kesin'de görünür (banka izi ertelenemez).

Fon × Bölge Bilançosu

Her hücre bir bucket'tır — kendi bilançosu olan mini-defter. Hücrede org geneli (tüm şubeler birleşik) net pozisyon görünür. Yeşil = pozitif (fon var), gri = boş, kırmızı = negatif (anomali).

Kompozit denge invariant'ı: Tabloya bakarken her hücrenin bağımsız bilançolu olduğunu hatırla. Bir bağış (Aş Evi, Filistin)'e gelirse bu hücreye değer ekler; sistem aynı fişe (Genel, Hür)'i ilgilendiren payı yazarken aralarına otomatik interbucket düzeltici çift atar. Yoksa fiş tek başına dengeli olsa bile bucket bazında dengesiz olurdu.
Fon \ Bölge Toplam
Toplam

Bucket dengesini nasıl okurum

Hücredeki sayı, o (fon, bölge) bucket'ına ait fon-pozisyon ailesi hesabının net bakiyesidir. Pozitif = bağışçıdan gelmiş, henüz harcanmamış (kullanım için bekliyor). Negatif = harcama girişi var ama fon yetmedi (anomali; bütçeden over-commit). Sıfır = ya hiç hareket yok ya gelir-gider eşitlenmiş.

Bölgeler-arası "rebind-region"

Bucket'lar arası rutin (vakıf payı, fon rebalancing) hareket bölge değişmediği sürece otomatiktir. Bölge değişiyorsa (örneğin Filistin → Afrika) bağışçı kısıtı ihlal edildiği için rebind-region özel işlemi gerekir (onay + log). Bu prototipte rebind-region tetiklenmiyor; mimaride açık.

Şubeler-Arası Mutabakat (Cari-Şube)

Şube = ayrı defter, ayrı tüzel kişilik. Şubeler-arası işlem her iki defterde ayrı yarısı ile yazılır. Aralarındaki net bakiye gerçek borç/alacak (mutabakat). Fiili para hareketi ayrı yevmiye.

Mutabakat ≠ fiili transfer: Aşağıdaki tablo "kim kime borçlu" durumunu gösterir; bu rakamlar sadece şube havalesi yapıldığında kapanır. Senaryo 2'de İstanbul Diyarbakır'a 95K borçlanır; bu satır Senaryo 3'te fiili transferle kapanır.

Cari-şube bakiyeleri

Defter (Şube)Karşı tarafBakiye (TL)Yorum

Fiili transfer (havale) eylemi

Mutabakatı kapatmak için bir şubeden diğerine banka havalesi yap. Bu, ayrı bir yevmiye olarak yazılır; iki defterde de bir kasa/banka satırı + cari-şube satırı oluşturur.

Şubeden şubeye tutar

Yevmiye Defteri (tüm satırlar)

Sistemdeki tek "ground truth". Tüm bakiyeler, fon pozisyonları, cari hesaplar bu tabloda group-by ile türetilir. Sistemin tek satırını dahi tutmaması bilinçli (snapshot şu an yok — YAGNI).

Tarih Fiş Şube Açıklama Hesap Tip Fon Bölge Borç Alacak Katman
Mor arka plan = sistem otomatik satırı (interbucket düzeltici, kontra üretimi). Kullanıcı bunları girmez, görmez; prototipte ayırt edebilmek için işaretli.
Veri tabanı şeması (özet) 
JournalEntry {
  id, number, date, branchId, description, layer ∈ {Taslak, Kesinlesmis},
  scenarioRef? (audit)
}

JournalLine {
  id, entryId (→ JournalEntry),
  branchId,                         // şube defteri (entry.branchId ile aynı)
  accountId (→ Account),
  debit decimal, credit decimal,    // sadece biri > 0
  fundId (→ Fund),                  // ZORUNLU
  regionId (→ Region),              // ZORUNLU, NULL değil (Hür = özel id)
  currency = 'TRY',                 // çok-PB için Odoo modeli; bu prototipte tek
  layer ∈ {Taslak, Kesinlesmis},    // entry.layer ile cascade
  systemGenerated bool,             // interbucket/kontra otomatik satırı
  parentLineId? (audit)
}

Account {
  id, branchId, type ∈ {kasa, banka, varlık,
    cari-bağışçı, cari-tedarikçi, cari-şube,
    fon-pozisyon, öz-kaynak, gelir, gider,
    kambiyo, olağandışı},
  name, userVisible bool (sadece kasa/banka true),
  // cariler için ek: subjectId (bağışçı/tedarikçi/şube)
}

INVARIANT 1: ∀ entry: Σ(debit)=Σ(credit)
INVARIANT 2: ∀ entry, ∀ (fund, region) bucket: Σ(debit)=Σ(credit)
INVARIANT 3: layer geriye sayılmaz (Kesin→Taslak yasak; düzeltme = ters fiş)

Hazır Senaryolar

Sırayla çalıştır. Her senaryo daha öncekilerin üstüne yazar (state birikir). Bir senaryoyu çalıştırınca Bağış Girişi sayfasındaki son işlem paneli güncellenir; Kasalar, Fon×Bölge, Şube Mutabakatı, Yevmiye sayfalarında etkiyi görebilirsin.

Çalıştırılmış senaryolar (kronolojik)