# Kişisel ve kurumsal finansın aynı veri modelinde durması

> Çok hesaplı gelir-gider takibini tek modelde toplayan finans çekirdeği; web + iOS + Android'de çalışan Parantaj'a dönüştü.

- Şu an ne yapıyor: Tek hesap/işlem modeli çoklu hesap yönetimini, bütçeyi, hedefleri ve raporlamayı aynı çekirdekte taşıyor; web, iOS ve Android istemcileri yayında. Kişisel ve kurumsal finansını tek yerden takip etmek isteyen kullanabilir.
- Tür: Açık kaynak, Web uygulaması, Mobil uygulama
- Durum: Ürün oldu
- Odak: Otomasyon & veri işleme
- Başlangıç: 2024-03-01
- Labs’tan çıkış: 2024-10-18
- Teknolojiler: PHP, Laravel, Go, PostgreSQL, Redis, RabbitMQ, React Native
- Etiketler: #finans, #saas, #mobil
- Kaynak kodu: https://github.com/Parantaj
- Web sitesi: https://parantaj.com
- App Store: https://apps.apple.com/us/app/parantaj/id6758751358
- Google Play: https://play.google.com/store/apps/details?id=com.parantaj.mobile
- Bu iş ürüne dönüştü: Parantaj (https://www.muhammetsafak.com.tr/portfolyo/parantaj/)
- Kaynak: https://www.muhammetsafak.com.tr/labs/parantaj-lab/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Banka hesabı, kredi kartı ve kasa — üçü de aynı kişinin parası, üçünün takibi
ayrı araçta. Kişisel ile kurumsalı ayrı ürüne bölmek bu dağınıklığı çözmüyor,
ikiye katlıyor.

## Aynı para, üç ayrı araç

Denenen şey, kişisel kullanımla kurumsal kullanımı ayrı ürünlere bölmeden tek
bir hesap/işlem modelinde toplamaktı; üzerine yinelenen ve zamanlanmış
işlemler.

## Tek çekirdek, üç istemci

Model tuttu: çoklu hesap yönetimi, bütçe planlama, hedefler ve raporlama aynı
çekirdek üzerinde yürüdü. Yük arttıkça olay temelli parçalar (Redis, RabbitMQ)
devreye girdi; istemci tarafı web'in yanına React Native ile iOS ve Android
olarak açıldı.

## Kişisel ile kurumsalı bölmemek

Kişisel finans ile kurumsal finansı iki ayrı ürün yapmak sektörde alışılmış
yol ve tek bir gerekçesi var: kurumsal tarafın ekip, rol ve yetki ihtiyacı
kişisel tarafta yok.

O ayrımın bedeli veri modelinde ödeniyor. Aynı kişinin şahsi hesabı ile
şirketinin hesabı iki ayrı üründe durursa nakit akışı hiçbir ekranda bir arada
görünmüyor — oysa parayı taşıyan kişi aynı. İki ürün iki şema, iki raporlama
katmanı ve aynı işlemin iki kez girilmesi demek.

Seçilen yol tek hesap/işlem modeli oldu; kurumsal fark yalnız bir yerde duruyor,
rol tabanlı yetkide. Bir hesaba takım üyesi eklemek modeli değiştirmiyor, o
hesabın üzerine bir yetki katmanı koyuyor. Karşılığında kurumsal tarafa özel
akışlar (muhasebe entegrasyonu gibi) çekirdekte değil, üstte durmak zorunda
kaldı — kabul edilen bedel bu.

## Yinelenen işlem sonradan eklenmedi

İkinci karar zamanlama tarafında. Kira, abonelik, maaş, taksit — kişisel
bütçenin de kurumsal nakit akışının da çoğu düzenli tekrar eden işlemden
oluşuyor.

Bunu bir "hatırlatma" özelliği olarak üste koymak kolay yoldu: kullanıcı
işlemi elle girer, sistem zamanı gelince dürter. O tasarımda gelecek hiçbir
zaman raporda görünmüyor — bütçe yalnız olmuş bitmiş işlemleri biliyor, oysa
sorunun kendisi gelecekle ilgili.

Yinelenen ve zamanlanmış işlem bu yüzden çekirdeğin bir parçası: işlem
modelinin kendisi tekrar kuralını taşıyor, raporlama da planlanmış olanı
gerçekleşmiş olanla birlikte okuyabiliyor.

Olay temelli parçalar (Redis, RabbitMQ) ise baştan değil, yük arttıkça girdi.
Sıralama bilinçli — kuyruk erken eklenirse çözdüğü bir problem olmadan bakım
maliyeti getiriyor.

## SaaS'a giden yol

Çekirdek bir SaaS ürününe döndü; abonelik, mobil uygulamalar ve kurumsal
özellikler ürün tarafında yaşıyor. Ayrıntısı portfolyoda.