Hesap Çekirdeği — Saatlik Mahsuplaşma Hesabı
Bu sayfa, Zeus'un mahsuplaşma gruplarınız için saatlik yerel mahsuplaşma hesabını nasıl ürettiğini anlatır: hesap akışı, "run" (hesap koşumu) kavramı, zamanlanmış görev (beat) kadansı, hangi senaryonun seçildiği, bedelli üretim limiti dağıtımı, sanal sayaçlar, tutar satırları, düzeltme (correction) akışı ve eksik veri davranışı.
Zeus resmî mahsuplaşmayı yapan kurum değildir. Bu sayfada anlatılan tüm
sonuçlar (saatlik satırlar, sanal sayaçlar, tutarlar) Zeus yerel tahminidir
(source = zeus_local) — resmî mahsuplaşma sonucu değildir. Resmî sonuç LÜM/GTŞ
verisiyle mutabakat fazında (PR-8) ayrı kaynak olarak eklenecektir.
Hesap sonuçları arayüzde grup detay sayfasının sekmelerinden izlenir:
Saatlik Hesap, Sanal Sayaçlar, Tutarlar ve Koşumlar
(bkz. Web Arayüzü). Hesaplar otomatik zamanlanmış
görevlerle arka planda üretilir; aynı sonuçlara API üzerinden de erişilir
(API Referansı → "PR-6 — Hesap Çekirdeği").
Görüntüleme için read:netting, manuel hesap/düzeltme tetiklemek için
manage:netting yetkisi gerekir.
Bir bakışta — saatlik hesap akışı (8 aşama)
Aşağıdaki diyagram, bir mahsuplaşma grubunun tek bir saatlik diliminin hesaplanırken geçtiği 8 aşamayı özetler. Sonraki bölümde her aşama tek tek açıklanır.
Hesap akışı — 8 aşama (ayrıntı)
Bir mahsuplaşma grubunun bir saatlik dilimi şu aşamalardan geçer:
- Saatlik enerji verisi okunur — Grubun üyesi tesislerin
saatlik enerji fact'leri okunur. Aynı
saat/tesis için birden çok kaynak varsa (örn. OSOS + Zeus) satır bazında en
öncelikli kaynak seçilir (resmî kaynak her zaman Zeus tahmininin önündedir;
missingen sondadır — gerçek veri her zaman kazanır). - Grup kilitlenir, pencere belirlenir — Aynı grup üzerindeki eşzamanlı
hesaplar sıraya girer; hesap penceresi saat sınırlarına kırpılır, fatura
dönemi (ay) sınırlarına bölünür ve geleceğe taşmaz (şu anki saatten
ilerisi hiç işlenmez — gelecek saatler için sahte
missing_datasatırı üretilmez). - Senaryo seçilir — Grubun bayraklarına göre hesap varyantı belirlenir: standart saatlik (Md.9(2)), mesken aylık (Md.7(4)), yalnız-üretim (Md.9(10)), bedelsiz (grup uygunsuzsa) veya özel hesap tipleri (M5.1-ç / M5.1-d / OSB-EB — bu sürümde iskelet). Seçim mantığı bir sonraki bölümde diyagramla anlatılır.
- Saatlik eşleşme hesabı — O saatin üretimi ve tüketimi eşleştirilir: mahsuplaşan tüketim = min(üretim, tüketim); şebekeden alınan = tüketimin üretimi aşan kısmı; ihtiyaç fazlası = üretimin tüketimi aşan kısmı.
- Limit dağıtımı — İhtiyaç fazlası, kalan bedelli üretim limitine göre
bedelli / SKB ödemeli olarak ayrılır; kullanım
limit hesaplarının hareket defterine (ledger)
otomatik işlenir (hareket tipleri
mahsuplasan_consumption+bedelli_ihtiyac_fazlasi). - Sanal sayaç satırları — Saatin bedelli / SKB / bedelsiz kWh'i sanal sayaç satırlarına yazılır (aşağıda "Sanal sayaç tipleri").
- Tutar satırları — Regüle tarife fiyatlarıyla saatlik tutar satırları üretilir (tedarikçiye ödenecek, üreticiye ödenecek, sistem kullanım bedeli, SKTT, bedelsiz-risk TL vb.). Sistem kullanım bedeli (SKB) fiyatı üretici lisanssız-üretici tarife grubundan çözülür (aşağıda SKB fiyat tabanı). Onaylı fiyat yoksa miktar yine üretilir, tutar boş kalır (Regüle Tarifeler).
- Koşum kapanır — Hesap koşumu (run)
successveyapartialolarak kapanır; ay sonunda aylık özet üretilir.
Hangi senaryo seçilir? — karar ağacı
- aşamada Zeus, grubun durumuna göre beş hesap senaryosundan birini seçer. Sıra önemlidir: önce özel tip, sonra uygunluk, sonra mesken, sonra veri durumu kontrol edilir.
| Senaryo (teknik) | Ne zaman seçilir | Sonuç |
|---|---|---|
skeleton | Grupta özel hesap bayrağı var (M5.1-ç, M5.1-d, OSB-EB) | Run partial kapanır, special_calc_not_implemented uyarısı — sanal sayaç/limit/tutar üretilmez (yanlış sonuç yerine "henüz hesaplanmıyor") |
invalid_group_bedelsiz | Grubun uygunluk durumu blocked | Tüm üretim bedelsiz sayaca; ayrıca "bedelsiz risk TL" tutar satırı |
mesken_informational | Grup mesken abone grubunda | Saatlik satırlar yalnız bilgilendirme; resmî nitelikli sonuç aylık kapanışta |
production_only | Pencerede hiç tüketim verisi yok (tüketim tesisi yok veya veri gelmemiş) | Üretim bedelsiz sayaca, limit tüketilmez; veri gelince backfill/düzeltme standarda döndürür |
standard | Yukarıdakilerin hiçbiri değilse (normal işleyiş) | Md.9(2) standart saatlik mahsuplaşma |
Emin olunmayan her durumda Zeus veri uydurmak yerine üretimi bedelsiz sayar veya "henüz hesaplanmıyor" der. Sonradan gerçek veri geldiğinde geri-doldurma ve düzeltme zinciri saati/dönemi standart sonuca kendiliğinden çevirir — kayıp geri kazanılır.
"Run" (hesap koşumu) kavramı ve yaşam döngüsü
Her hesap bir run kaydı açar. Run; hangi grubun, hangi dönemin, hangi
tetikleyiciyle (triggered_by) ve hangi girdi verisiyle hesaplandığını izlenebilir
kılar. Tüm sonuç satırları (saatlik hesap, sanal sayaç, tutar) kendisini üreten
run'a bağlıdır.
Zaman içinde aynı saat için birden çok run oluşur; yalnız en güncel run'ın
satırları "current"tır (geçerli sonuç). Eski satırlar silinmez —
include_history=true ile geçmiş (superseded) satırlar da okunabilir
(denetim/karşılaştırma).
Run tetikleyicileri (triggered_by)
| Tetikleyici (teknik) | Kim başlatır | Anlamı |
|---|---|---|
beat | Zamanlanmış görev (Celery beat) | Otomatik saatlik/günlük/aylık hesaplar — arka planda, elle müdahale gerekmez |
manual | Kullanıcı (manage:netting) | Bir grup/dönem için elle tetiklenen hesap veya manuel düzeltme |
correction_cascade | Düzeltme motoru | Bir düzeltmenin ardından zincirleme yeniden hesaplanan takip dönemleri (aşağıda "Düzeltme akışı") |
Zamanlanmış görev (beat) kadansı
Aşağıdaki diyagram, hesabı besleyen iki katmanı gösterir: önce ham saatlik
enerji verisi (facility_hourly_energy) tazelenir, hemen ardından mahsuplaşma
hesabı o veriyle koşar. Saatler Türkiye yerel saatiyle okunur.
Tipik yaşam döngüsü tabloyla:
| Aşama | Ne zaman? (TR yerel) | Ne yapar? |
|---|---|---|
| Enerji fact tazeleme | Her saat :10 | Önceki saatin ham enerji verisini facility_hourly_energy'ye idempotent yazar (hesabın girdisi) |
| Ön hesap (preliminary) | Her saat :15 | Önceki saatin ilk mahsuplaşma hesabı (fact :10'da tazelendiği için taze girdi) |
| Geç-veri hesabı (corrected) | Her saat :45 | Aynı saati geç gelen veriyle yeniden dener; girdi değişmediyse (input_hash aynı) yeni run açılmaz (no-op) |
| Günlük fact geri-doldurma | Her gün 02:30 | Son 72 saatin enerji fact'lerini yeniden üretir (geç gelen OSOS/CAGG verisi) |
| Günlük hesap geri-doldurma | Her gün 03:10 | Son 7 günü yeniden hesaplar (geç gelen veri sonuca kendiliğinden yansır) |
| Uygunluk yeniden değerlendirme | 6 saatte bir | Aktif grupların uygunluğunu (R001–R013 + R00T) tazeler |
| Aylık ön-kapanış (monthly_close) | Ayın 1'i 01:30 | Geçen ayın aylık özeti — mesken grubunda resmî nitelikli aylık sonuç, diğer gruplarda bilgilendirme özeti |
| Tarife eksik taraması | Her gün 07:00 | Aktif/yaklaşan dönem için eksik tarife fiyatı taraması (eksik varsa operatör uyarısı; tutar satırları fiyatsız kalabilir) |
| Düzeltme (correction) | Manuel / üyelik değişikliği | Bir dönemi düzeltir ve takip eden dönemleri zincirleme günceller (aşağıda) |
Hesap görevleri, kendilerini besleyen fact görevlerinin hemen ardından
planlanmıştır: :15 hesap :10 fact'ten sonra, 03:10 hesap geri-doldurması
02:30 fact geri-doldurmasından sonra koşar. Böylece hesap her zaman en taze
enerji verisiyle çalışır.
Md.7(5) — limit bitse de mahsuplaşma durmaz
Bedelli üretim limitiyle ilgili en çok karıştırılan kural şudur:
Limit bitse de, tüketiminizle eşleşen üretim mahsuplaşmaya devam eder. Limit; eşleşen tüketimi asla kırpmaz. Limitin belirlediği tek şey, ihtiyaç fazlası (tüketimi aşan) üretimin akıbetidir: kalan limite sığan kısım bedelli satılır, sığmayan kısım SKB'ye (sistem kullanım bedeli karşılığı) döner.
Yani limitiniz tükendiğinde faturanızdaki mahsuplaşma faydası kaybolmaz;
yalnızca ihtiyaç fazlası üretiminiz artık bedelli satış yerine SKB kapsamına
girer. Zeus bu geçişi saatlik satırlarda limit bitti — SKB'ye düştü uyarısıyla
işaretler.
SKB fiyat tabanı — üretici veriş yönlü dağıtım bedeli
SKB (sistem kullanım bedeli) tutarının fiyat tabanı, üretim tesisinin
veriş yönlü dağıtım bedelidir — yani şebekeye verdiği enerji için ödediği
lisanssız-üretici dağıtım bedeli (Md.4-l). Bu, tüketicinin abone grubu fiyatı
değildir. Fiyat, Regüle Tarifeler
deposundaki system_usage kaleminin üretici grubu satırından gelir:
- LÜ2 (
lisanssiz_uretici_2) — güneş (GES) tesisleri (5346 sayılı Kanun'a ekli I Sayılı Cetvel'in (e) bendi). - LÜ1 (
lisanssiz_uretici_1) — güneş dışı yenilenebilir (rüzgâr, hidro, biyokütle, jeotermal).
Daha önce SKB tutarı, tüketicinin abone grubu system_usage fiyatından
yaklaşık çözülüyordu (geçici bir yaklaştırma). Artık doğru mevzuat tabanı
olan üretici LÜ grubu fiyatı kullanılır. Bu, yalnızca SKB'nin fiyatını
etkiler; SKB miktarı (kWh), bölge dağıtımı ve diğer tüm hesap adımları
değişmemiştir.
Bir tesisin LÜ grubu nasıl belirlenir? (hibrit + denetlenebilir)
Zeus, üretim tesisinin hangi LÜ grubuna düştüğünü üç öncelikli kuralla çözer:
| Öncelik | Kaynak | Sonuç |
|---|---|---|
| 1 | Açık override — tesis formundaki "Üretici tarife grubu" (producer_tariff_group) alanı doluysa | Seçilen grup aynen kullanılır (operatörün bilinçli, denetlenebilir seçimi; uyarı üretmez) |
| 2 | Kaynak türünden türev — override boşsa tesisin kaynak türü (source_type) | solar → LÜ2; wind/hydro/biomass/geothermal → LÜ1. Türev kullanıldı uyarısı üretir |
| 3 | Güneş-baskın varsayılan — override boş ve kaynak türü ayırt edilemez (hybrid/unknown/boş) | LÜ2 (güneş-baskın portföy varsayımı) + inceleme uyarısı |
Kaynak türü net değilse (ör. hybrid veya unknown) ya da bir güneş dışı
tesiste türevden emin olmak istiyorsanız, tesis formundaki "Üretici tarife
grubu" alanını açıkça LÜ1 veya LÜ2 seçerek doldurun. Bu alan doluyken
türev/varsayılan devreye girmez ve SKB fiyat tabanı sizin seçiminizle sabitlenir.
Alanı boş bırakırsanız Zeus kaynak türünden türetir (yukarıdaki tablo).
Aynı bölgede birden çok üretici grubu varsa (karma bölge)
Bir şebeke işletmecisi bölgesinde farklı LÜ gruplarına düşen üretim tesisleri birlikteyse (ör. hem güneş hem rüzgâr), o bölgenin SKB fiyatı üretim-miktarı (kWh) ağırlıklı ortalama olarak hesaplanır; satırın fiyat kaynağı (provenance) o bölgede en çok üreten grubun tarife satırıdır. Bölge başına yine tek SKB satırı yazılır (yapı değişmez).
SKB fiyat tabanı uyarıları (warning_codes)
Hesap yanıtındaki warnings/warning_codes alanlarında SKB fiyat tabanıyla
ilgili şu kodları görebilirsiniz (hepsi bilgilendirme; hesap durmaz):
| Kod | Ne anlama gelir? | Ne yapmalı? |
|---|---|---|
SKB_LU_GROUP_MIXED | Bölgede karma LÜ grubu var; SKB fiyatı üretim-kWh ağırlıklı ortalama alındı | Genellikle aksiyon gerekmez; ağırlıklı fiyat doğru sonuçtur |
SKB_LU_GROUP_DERIVED | LÜ grubu açık override yerine kaynak türünden türetildi | Türev doğruysa aksiyon yok; emin değilseniz "Üretici tarife grubu" alanını doldurun |
SKB_LU_GROUP_UNKNOWN_DEFAULT | LÜ grubu belirlenemedi; güneş-baskın varsayılan (LÜ2) kullanıldı | Kaynak türünü (source_type) girin veya "Üretici tarife grubu"nu açıkça seçin |
SKB_PRICE_UNRESOLVED_QUANTITY_ONLY | İlgili LÜ grubunun system_usage fiyatı dönem için yok | Superadmin dönem için LÜ1/LÜ2 system_usage satırını girsin (Regüle Tarifeler) |
warning_codes[i], insan-okur warnings[i] metniyle birebir aynı sıradadır.
Kodlar sabittir (arayüz çevirisi bu kodlara bağlanır); bilinmeyen bir kod
görürseniz istemci ham uyarı metnini gösterir. Tam liste:
API Referansı — warning_codes.
Sanal sayaç tipleri (Md.10)
Zeus, her saatin üretimini üç "sanal sayaç"a dağıtır. Bunlar fiziksel sayaç değildir — mevzuatın öngördüğü muhasebe kırılımlarıdır:
| Tip (teknik) | Anlamı | Ne zaman oluşur? |
|---|---|---|
| bedelli | Mahsuplaşan (eşleşen) üretim + kalan limite sığan ihtiyaç fazlası | Normal işleyişte her saat |
| skb_odemeli | Limiti aşan ihtiyaç fazlası — sistem kullanım bedeli kapsamında | Limit tükendiğinde |
| bedelsiz | Karşılıksız sayılan üretim | Özel durumlarda (aşağıda "bedelsiz risk") |
Satırlar grup × şebeke işletmecisi × kaynak türü kırılımında toplanır; her
satır bir neden kodu (reason) taşır — hangi kuralın uygulandığı her satırda
izlenebilir. Sık görülen neden kodları:
| Neden kodu (teknik) | Yazıldığı sayaç | Anlamı |
|---|---|---|
standard_matched | bedelli | O saatte üretimin tüketimle eşleşen (mahsuplaşan) kısmı |
standard_bedelli_surplus | bedelli | İhtiyaç fazlasının kalan bedelli limite sığan kısmı |
limit_exceeded | skb_odemeli | İhtiyaç fazlasının kalan limiti aşan kısmı |
limit_exhausted_skb | (saat uyarı bayrağı) | Neden kodu değildir: bedelli limit tamamen tükendikten sonra ihtiyaç fazlasının SKB'ye düştüğünü belirten saatlik uyarı bayrağıdır (warning_flag). Bu durumda skb_odemeli sanal sayaç satırının neden kodu yine limit_exceeded'dır — sanal sayaçları neden koduna göre sorgularken limit_exhausted_skb değil limit_exceeded kullanın |
group_conditions_not_met | bedelsiz | Grup uygunsuz (blocked) — tüm üretim bedelsiz (Md.6/4, 9/6) |
missing_consumption_data | bedelsiz | Tüketim verisi yok (yalnız-üretim, Md.9/10) — üretim bedelsiz, limit tüketilmez |
missing_data | (saat işareti) | O saatte üretim veya tüketim verisi eksik; katkı 0 sayılır, saat missing_data bayrağı taşır |
Limit dağıtımı — birden çok tüketim tesisi varsa
Grupta birden çok tüketim tesisi (dolayısıyla birden çok limit hesabı) varsa, saatlik limit kullanımı hesaplara oransal dağıtılır:
- Varsayılan (
remaining): her hesabın payı, kalan limitine oranlıdır (kalanı çok olan hesaptan daha çok düşülür). - Grup bazlı seçenek (
initial): pay, başlangıç limitine oranlanır (LÜM kalibrasyonu ile uyum gerektiğinde grup ayarından seçilir).
Grupta bu ayar yapılmadıysa remaining geçerlidir. Dağıtılan kullanım,
Limit Hesapları hareket defterine hesap bazında işlenir;
defter toplamı hesap sonuçlarıyla birebir eşittir (yuvarlama farkı biriktirilmez).
Düzeltme (correction) akışı — Md.15
Geçmiş bir fatura dönemi için veri/üyelik değişikliği olduğunda dönem düzeltilebilir. Aşağıdaki diyagram düzeltmenin nasıl zincirleme ilerlediğini gösterir:
Adım adım:
- Düzeltilecek dönem yeniden hesaplanır (yeni run; eski satırlar geçmişe düşer — superseded).
- Limit defteri geriye dönük tutarlı kalır: eski run'ın limit etkisi tek
ters kayıtla (
correction_reversal) geri alınır, yeni kullanım (correction_reapply) yeniden işlenir — kalan limit hiçbir ara adımda kaybolmaz/çift sayılmaz. - Zincirleme (cascade, Md.15(4)): düzeltilen dönemden sonra Zeus'ta
hesaplanmış tüm dönemler kronolojik sırayla otomatik yeniden hesaplanır
(
triggered_by = correction_cascade, yıl sınırında durmaz) — çünkü limit kullanımı dönemler arasında birbirine bağlıdır. - Zincir ortada kesilirse yanıt bunu açıkça bildirir (
cascade_incomplete+ hangi dönemde kaldığı); aynı düzeltme isteği tekrar çalıştırıldığında kaldığı yerden devam eder (tamamlanan dönemler tekrar hesaplansa da sonuç değişmez — güvenle yeniden denenebilir/idempotent).
Resmî düzeltme, bugünden geriye en fazla 12 ay önceki döneme yapılabilir. Zeus daha eski bir dönem için düzeltmeyi engellemez (Zeus-içi analiz/manuel düzeltme serbesttir) ancak yanıtta "bu dönem için resmî düzeltme yapılamaz" uyarısı döner.
Ayrıca: bir grup üyeliğinin bitiş tarihi (valid_to) geçmişe çekilirse
Zeus etkilenen dönemden itibaren düzeltme zincirini kendiliğinden başlatır
ve oluşan uyarıları aynı yanıtta (warnings) bildirir.
Bedelsiz risk senaryosu — grup uygunsuzsa
Grup, uygunluk değerlendirmesinde bloklu (blocked) ise — örneğin
uygunluk kurallarından bir engelleyici (blocking) kural
başarısızsa veya dönem için onaylı tarife fiyatı yoksa (R00T, bu sürümde
aktif) — hesap durmaz; bunun yerine mevzuat gereği o dönemin tüm üretimi
bedelsiz sayılır (Md.6(4)/9(6)). Bu, hesap çekirdeğinde
invalid_group_bedelsiz senaryosuyla işlenir:
- Üretim
bedelsizsanal sayaca yazılır (neden:group_conditions_not_met), - Kaybın büyüklüğünü görünür kılmak için "bedelsiz risk TL" tutar satırı üretilir (tahmini kayıp — uygunluk sorunu giderilirse düzeltme akışıyla geri kazanılır),
- Limit hesaplarına dokunulmaz (bedelsiz üretim limit tüketmez).
Bu tasarımın amacı görünürlüktür: grup uygunsuz kaldığı her saat, potansiyel bedelli gelirinizin bedelsize dönüştüğünü TL cinsinden görürsünüz. Grup detay sayfasının Tutarlar sekmesinde "bedelsiz risk TL" satırı artıyorsa, önce Uygunluk Kuralları sekmesindeki blocking bulguları (veya eksik tarifeyi) giderin; sonra düzeltme zinciri kaybı geri kazanır.
Eksik veri davranışı — veri asla uydurulmaz
- Grupta hiç tüketim verisi yoksa (yalnız-üretim, Md.9(10) —
production_onlysenaryosu): üretim bedelsiz sanal sayaca yazılır (neden:missing_consumption_data); limit tüketilmez. Tüketim verisi sonradan gelirse geri-doldurma/düzeltme zinciri saati standart hesaba kendiliğinden döndürür. - Tek bir saatte veri eksikse: eksik katkı 0 kabul edilir, saat
missing_dataişaretlenir ve uyarı bayrağı taşır — tahmini değer üretilmez. Geç gelen veri, gece geri-doldurmasıyla saati düzeltir. - Pencerenin sonundaki "henüz veri gelmemiş" saatler hiç yazılmaz (boş satır kirliliği yerine bir sonraki otomatik hesap gerçek veriyle işler).
Mesken grupları — saatlik satırlar bilgilendirmedir
Mesken abone grubundaki gruplarda limit uygulanmaz (Md.7(4)) ve resmî
nitelikli sonuç aylıktır: ay boyunca üretim/tüketim toplanır, eşleşen kısım
ve ihtiyaç fazlası ay bazında hesaplanır. Saatlik satırlar mesken grubunda
yalnız bilgilendirme amaçlıdır (her satır mesken_informational bayrağı
taşır); esas sonuç ayın 1'inde üretilen aylık özettir (monthly_close).
Özel hesap tipleri — bu sürümde iskelet
M5.1-ç (kendi tüketim tesisi özel hesabı), M5.1-d (aynı ölçüm noktası
önceliği) ve OSB-EB senaryoları bu sürümde hesap üretmez (skeleton
senaryosu / iskelet): bu bayrakları taşıyan grupların koşumu partial durumuyla
kapanır ve special_calc_not_implemented uyarısı döner — yanlış sonuç üretmek
yerine açıkça "henüz hesaplanmıyor" denir. Bu tipler için sanal sayaç, limit
hareketi ve tutar satırı üretilmez. İlerleyen sürümlerde etkinleştirilecektir.
İlgili sayfalar
- Limit Hesapları — bedelli limit ledger; hesap
çekirdeği artık bu deftere otomatik hareket yazar
(
mahsuplasan_consumption,bedelli_ihtiyac_fazlasi,correction_reversal,correction_reapply). - Uygunluk Kuralları —
blockedgrubun bedelsiz senaryoya düşme koşulları; R00T (tarife) ve R010 (limit transferi) bu sürümde aktifleşti. - Sayaç Atama ve Kanal Eşleme — hesap çekirdeğinin okuduğu saatlik enerji verisinin üretimi.
- Regüle Tarifeler — tutar satırlarının fiyat kaynağı; onaylı fiyat yoksa tutarlar boş kalır (miktar yine üretilir).
- Web Arayüzü — grup detay sayfasının sekmeleri (Saatlik Hesap, Sanal Sayaçlar, Tutarlar, Koşumlar).
- Teknik: Mahsuplaşma Mimarisi · Veri Modeli
- API Referansı — PR-6 endpoint'leri