Finance & Irrigation
Bu sayfa, Cınga backend içinde iş uygulaması katmanında yer alan finans ve sulama oturumu tablolarını detaylı biçimde açıklar.
Bu katman telemetry çekirdeğinin parçası değildir; ancak cihazların ve saha varlıklarının iş tarafında nasıl anlam kazandığını gösterir. Yani burada ölçüm değil, ölçümün operasyonel ve finansal sonucu modellenir.
Katmanın Amacı
Bu katman iki ana problemi çözer:
-
Finansal olaylar
- belirli cihaz veya saha ile ilişkili gelir/gider kayıtları
- kullanıcıya özel veya sistem geneli finans kategorileri
-
Sulama yaşam döngüsü
- hangi cihaz/pompa/parsel ilişkisinde sulama oturumu başladığı
- ne zaman başladığı, bittiği ve nasıl tetiklendiği
1. finance_details
finance_details, finans kayıtlarında kullanılacak detay/kategori sözlüğünü tutar.
Neden vardır?
Finans hareketlerinin açıklama metni serbest bırakıldığında raporlama ve filtreleme zorlaşır. Bu nedenle gelir/gider kalemleri için tekrar kullanılabilir bir kategori katmanı gerekir.
Bu tablo iki seviyede çalışabilir:
- sistem geneli ortak kategoriler
- kullanıcıya özel kategoriler
Kolonlar
| Kolon | Tip | Null | Anlamı |
|---|---|---|---|
id | int | hayır | Kategori anahtarı |
user_id | int | evet | Kategori kullanıcıya özelse ilgili kullanıcı |
name | varchar(150) | hayır | Kategori adı |
description | varchar(255) | evet | Açıklama |
is_active | boolean | hayır | Aktiflik |
update_time | timestamp | hayır | Güncelleme |
create_time | timestamp | hayır | Oluşturma |
Neden user_id nullable?
Çünkü bazı kategoriler sistem geneli tekrar kullanılabilir; bazıları yalnız belirli kullanıcıya aittir. Bu sayede hem ortak sözlük hem kullanıcıya özel kategori ihtiyacı aynı model içinde çözülür.
Örnek kayıtlar
Sistem geneli kategori:
{
"id": 1,
"user_id": null,
"name": "Elektrik Geliri",
"description": "Enerji üretim veya tasarruf kaynaklı gelir kaydı",
"is_active": true
}
Kullanıcıya özel kategori:
{
"id": 3,
"user_id": 1,
"name": "Mazot",
"description": "Kullanıcıya özel yakıt gider kategorisi",
"is_active": true
}
2. finances
finances, gerçek finansal hareketleri taşır.
Neden vardır?
Cihazın ya da sahadaki ekipmanın yalnız teknik değil, ekonomik etkisi de vardır. Bakım gideri, enerji geliri, işçilik, yakıt gibi hareketler cihaz bağlamında tutulduğunda teknik veri ile iş sonucu ilişkilendirilebilir.
Kolonlar
| Kolon | Tip | Null | Anlamı |
|---|---|---|---|
id | int | hayır | Finans kaydı anahtarı |
device_id | varchar(21) | hayır | Hareketin ilişkilendirildiği cihaz |
detail_id | int | hayır | Finans kategori/detayı |
transaction_type | enum | hayır | income / expense |
transaction_time | timestamp | hayır | Finans olay zamanı |
currency_code | varchar(10) | hayır | Para birimi |
note | varchar(255) | evet | Kısa not |
amount | decimal(14,2) | hayır | Tutar |
created_by | int | evet | Oluşturan kullanıcı |
updated_by | int | evet | Son güncelleyen |
is_active | boolean | hayır | Soft aktiflik |
update_time | timestamp | hayır | Güncelleme |
create_time | timestamp | hayır | Oluşturma |
Neden device_id ile bağlı?
Bu modelde finans kaydı cihaz bağlamlı tutulur. Böylece:
- bakım gideri ilgili cihazla ilişkilendirilir
- gelir/gider geçmişi cihaz yaşam döngüsüne bağlanır
- raporlama cihaz veya saha bazında yapılabilir
Örnek kayıt
{
"id": 2,
"device_id": "46000000C47CA670",
"detail_id": 2,
"transaction_type": "expense",
"transaction_time": "2026-04-02T09:30:00Z",
"currency_code": "TRY",
"note": "Pompa bakım gideri",
"amount": 850.00,
"created_by": 1,
"updated_by": 1,
"is_active": true
}
Tasarım notu
İleride ihtiyaç büyürse finans kayıtları yalnız device_id ile değil; land_plot_id, pump_id veya bağımsız maliyet merkezi ile de ilişkilendirilebilir. Mevcut modelde cihaz ana bağlamdır.
3. irrigations
irrigations, sulama oturumunu temsil eder.
Neden vardır?
Enerji tarafında pompa çalışması görülebilir; fakat iş açısından önemli olan soru genellikle şudur:
Ne zaman sulama başladı, ne zaman bitti ve hangi bağlamda gerçekleşti?
Bu tablo, telemetry verisini operasyonel oturuma dönüştürür.
Kolonlar
| Kolon | Tip | Null | Anlamı |
|---|---|---|---|
id | int | hayır | Sulama oturumu anahtarı |
device_id | varchar(21) | hayır | Oturumu başlatan/izleyen cihaz |
pump_id | int | evet | İlgili pompa |
land_plot_id | int | evet | İlgili parsel |
start_stream_id | int | evet | Başlangıcı doğrulayan stream |
end_stream_id | int | evet | Bitişi doğrulayan stream |
start_time | timestamp | hayır | Oturum başlangıcı |
end_time | timestamp | evet | Oturum bitişi |
duration_sec | int | evet | Süre |
is_active | boolean | hayır | Oturum halen açık mı |
trigger_source | enum | evet | register_bit / manual / rule / api |
create_time | timestamp | hayır | Oluşturma |
update_time | timestamp | hayır | Güncelleme |
Neden start_stream_id ve end_stream_id var?
Çünkü sulama oturumu yalnız takvimsel bir olay değil; telemetry tarafından doğrulanabilen bir operasyonel süreçtir. Başlangıç ve bitişi belirleyen accepted stream’ler tutulursa oturumun veri temeli geriye dönük izlenebilir olur.
trigger_source neden önemli?
Aynı sulama oturumu farklı yollardan başlayabilir:
- cihaz register bit’i ile otomatik algılanmış olabilir
- kullanıcı manuel başlatmış olabilir
- bir rule engine aksiyonu tetiklemiş olabilir
- API çağrısı üzerinden açılmış olabilir
Bu ayrım operasyon ve raporlama açısından önemlidir.
Örnek kayıt
{
"id": 1,
"device_id": "46000000C47CA670",
"pump_id": 1,
"land_plot_id": 1,
"start_stream_id": 5001,
"end_stream_id": null,
"start_time": "2026-04-03T10:29:50Z",
"end_time": null,
"duration_sec": null,
"is_active": true,
"trigger_source": "register_bit"
}
Finans ve Sulama Katmanının Telemetry ile İlişkisi
Bu katman telemetry çekirdeğini tekrar etmez; onun üzerine iş anlamı ekler.
financesteknik verinin ekonomik etkisini taşırirrigationsteknik olayın operasyonel oturum halini taşır
Bu yüzden bu tablolar telemetry tablolarının alternatifi değil; onlardan türeyen iş bağlamı katmanıdır.
Temel Tasarım Kararları
Finans kategorisi ile finans hareketi ayrıdır
finance_details→ sözlükfinances→ gerçek hareket
Sulama oturumu measurement değildir
irrigations, tek tek akım/gerilim kayıtlarını değil, bunlardan türeyen iş olayını taşır.
Stream referansı operasyonu veriyle bağlar
start_stream_id ve end_stream_id sayesinde sulama oturumları salt kullanıcı işlemi değil, telemetry ile ilişkilendirilmiş nesneye dönüşür.
Sonuç
Finance & Irrigation modeli, Cınga backend’in yalnız teknik bir ölçüm sistemi olmadığını; aynı zamanda saha operasyonu ve ekonomik sonuç üreten bir iş platformu olmasını sağlar. Bu katmanda cihaz verisi doğrudan saklanmaz; onun iş bağlamındaki etkisi modellenir.