Ana içeriğe geç

Uygunluk Kuralları — R001–R013 + R003M / R00T / R00L

Bir mahsuplaşma grubu, hesaba girmeden önce bir dizi uygunluk kuralından geçer. Bu sayfa, kural motorunun (EligibilityRuleEngine) çalıştırdığı tüm kuralları anlatır: her kuralın ne kontrol ettiğini, önem seviyesini (severity), üretebildiği sonuçları (status) ve — en önemlisi — o sonucu gördüğünüzde ne yapmanız gerektiğini (somut aksiyon).

Kural motoru POST /api/mahsuplasma/groups/{id}/evaluate ile çalışır; sonucu GET /api/mahsuplasma/groups/{id}/eligibility ile okursunuz. Sihirbazda ise 7. adım (Önizleme) uygunluk sonucunu otomatik gösterir — ayrıca bir şey çağırmanıza gerek yoktur (bkz. Grup Kurulum Sihirbazı).

Bu sayfayı nasıl okuyayım?

Önce Önem seviyeleri ve Kural durumları bölümlerini okuyun (kısa iki tablo). Sonra grubunuzda hangi kod kırmızı/sarı çıktıysa, aşağıdaki Kural kataloğu tablosundan o koda gidin ve "NE YAPMALI" satırını uygulayın. "Grubum neden geçerli değil?" tipi hızlı çözümler için SSS ve Sorun Giderme sayfası da var.

Önem seviyeleri (severity)​

Her kural bir severity taşır. Severity, bir kuralın FAIL (veya blocking için not_checked) olması durumunda grubun genel durumunu (eligibility_status) nasıl etkilediğini belirler:

SeverityAnlamıGrubu nasıl etkiler
blockingMevzuat gereği grubu geçersiz kılan ihlal (regime, abone grubu, tek tedarikçi, ana sayaç, tarife, limit)FAIL → grup blocked; not_checked → grup not_checked (asla valid olamaz)
errorVeri bütünlüğü sorunu (sayaç kanalı bilinmiyor, çakışma)FAIL → valid_with_warnings (blocking sorun yoksa)
warningYaklaşıklık / eksik beyan (çoklu bölge, kurulu güç bilinmiyor, transfer değerlendirmesi)FAIL → valid_with_warnings (blocking sorun yoksa); grubu durdurmaz
infoDoğrulama bekleyen tespit / etiketleme (özel hesap tipi, OSB/EB)Genel durumu değiştirmez
Kilit ayrım: severity, "not_checked" sonucunun anlamını değiştirir

Bir kural not_checked çıktığında ne olacağı severity'ye bağlıdır:

  • blocking bir kural not_checked ise → grup en fazla not_checked olur, asla valid olmaz (aşağıdaki "kritik ilke" kutusuna bakın).
  • warning/info bir kural not_checked ise → grubun genel durumunu etkilemez (örn. R008, R009, R011 sürekli not_checked'tir ama grubu bloklamaz, çünkü bunlar warning'dir).

Kural durumları (status)​

Her kuralın çalışması bir status üretir:

StatusAnlamıÖrnek
passKural sağlandıTüm üyeler lum_yonetmelik_26 → R001 pass
failKural ihlal edildiİki farklı abone grubu → R002 fail
not_checkedKural değerlendirilemedi (eksik veri veya ilgili faz henüz gelmedi)sktt_status beyanı yok → R008 not_checked
not_applicableKural bu gruba uygulanmadı (koşul yok)Grupta tüketim tesisi yok → R003 not_applicable
not_checked ASLA "uygun" (geçerli) sayılmaz

Bu, modülün en önemli ilkesidir. Bir blocking sınıfı kural henüz doğrulanamadığı sürece (örneğin ilgili veri kaynağı bağlanmadığı, ya da zorunlu bir beyan eksik olduğu için) grup en fazla not_checked olur — hiçbir zaman valid. "Blocking-fail olmaması" ile "anlamlı geçerlilik" aynı şey değildir. Bu yüzden üyesiz bir grup veya zorunlu verisi eksik bir grup valid damgası alamaz. Bir eksiği "kontrol edilmedi diye sorun yok" varsaymak yasaktır.

Genel durum (aggregate_status) mantığı​

Grubun genel eligibility_status'u kural sonuçlarından türetilir. Öncelik sırası: blocked > not_checked > valid_with_warnings > valid.

Grup valid (geçerli / yeşil) SADECE şu üç koşulun HEPSİ sağlanınca atanır:

  1. Hiç blocking-fail yok, VE
  2. Hiç blocking-not_checked yok, VE
  3. En az bir anlamlı (substantif) blocking kural fiilen pass/fail olarak değerlendirildi.

Diğer durumlar:

  • blocked (kırmızı) — en az bir blocking kural fail. (Bu, olası bir eksikten daha kesin bir engeldir; bu yüzden not_checked'ten önce gelir.)
  • not_checked (gri) — bir blocking kural not_checked, VEYA hiçbir anlamlı blocking kural değerlendirilemedi (örn. üyesiz grup: tüm blocking'ler not_applicable). Bu durum asla valid sayılmaz.
  • valid_with_warnings (amber) — blocking sorun yok ama warning/error sınıfı bir fail var (örn. çoklu bölge). Hesap koşar; sonuç "yaklaşık/uyarılı"dır.
"Anlamlı blocking" neden önemli? (3. koşul)

Yalnızca R013 (aşağıya bakın) türev/agregat bir kuraldır — kendi başına gerçek bir koşul doğrulamaz, sadece diğer blocking kuralların sonucunu toplar. Bu yüzden R013'ün pass olması "anlamlı geçerlilik" saymaz. Somut örnek: üyesi olmayan bir grupta bütün gerçek kurallar not_applicable döner, R013 ise pass olur; buna rağmen grup valid yapılmaz, not_checked kalır. "Önce bir üye ve zorunlu beyanları ekle, sonra geçerlilikten söz edelim" mantığı.

Karar akışını görselleştirirsek:

blocked bile olsa hesap koşar (bedelsiz senaryo)

Bir grup blocked olsa dahi, saatlik hesap motoru hesabı durdurmaz: grup koşulları sağlanmıyorsa (R013 — Md.6(4)/9(6)(10)) grubun tüm üretimi bedelsiz sanal sayaca yazılır (invalid_group_bedelsiz senaryosu). Yani blocked "hiç hesaplanmaz" demek değil, "bedelli mahsuplaşmaya konu edilemez, bedelsiz riski var" demektir. Bu risk (TL) ilgili dashboard widget'ında gösterilir. Amaç: hatayı görünür kılmak ve gelir kaybını sessizce oluşturmamak.

Kural kataloğu — hızlı referans​

Aşağıdaki tablo tüm kuralları, önem seviyelerini, üretebildikleri status'ları ve bu sürümdeki gerçek davranışlarını özetler. Her kodun ayrıntısı ve NE YAPMALI adımları takip eden bölümlerdedir.

KodSeverityNe kontrol eder?Üretebildiği status'larBu sürüm
R001blockingTüm üyeler lum_yonetmelik_26 kapsamında mı? (Md.26)pass / fail / not_applicable✅ Aktif
R002blockingTüketim tesisleri aynı abone grubunda mı? (Md.5(3))pass / fail / not_checked / not_applicable✅ Aktif
R003blockingÇoklu tüketimde tek tedarikçi (Md.5(5); OSB/EB + DUY 17/2 istisnası)pass / fail / not_checked / not_applicable✅ Aktif
R003MblockingAna üretim sayacı (main_production) atanmış mı?pass / fail / not_applicable✅ Aktif
R004warningTesisler tek dağıtım bölgesinde mi? (çoklu-bölge yaklaşıklığı)pass / fail / not_checked / not_applicable✅ Aktif
R005infoÖzel hesap tipi tespiti (5.1.ç / 5.1.d)pass / not_applicable✅ Aktif (tespit)
R006blocking5.1.ç ilişkilendirme matrisi statik ihlalleri (Md.6(3)c/(9))pass / fail / not_applicable✅ Aktif (statik)
R007blockingMesken-dışı grupta her tüketim tesisi için bedelli limit hesabı var mı? (Md.7(1))pass / fail / not_applicable✅ Aktif (PR-4)
R008warningSKTT durumu beyan edildi mi?pass / not_checked / not_applicable🔜 not_checked (tam hesap PR-8)
R009warningÜretim kurulu güç beyanı var mı? (Md.5(8) saatlik tavan)not_checked🔜 not_checked (saatlik kontrol PR-5)
R010warningLimit hesabı başka grup(lar)ca da kullanılmış mı? (transfer; Md.5(4)+28/7)pass / fail / not_applicable✅ Aktif (PR-6)
R011warningTesis devredilmiş mi? (Md.5(10)(11))not_checked🔜 not_checked (ileri PR)
R012infoOSB/EB senaryosu var mı? (Md.9(8)(9))pass / not_applicable✅ Aktif (tespit)
R013blockingAgregat türev: önceki blocking-fail varsa bedelsiz riski (Md.6(4)/9(6)(10))pass / fail✅ Aktif (türev)
R00TblockingCari dönem için onaylı regüle tarife seti + abone grubu eşleşmesi var mı? (Md.11)pass / fail / not_checked / not_applicable✅ Aktif (PR-6)
R00LblockingBedelli limit hesabı yok (R007 ile eş alt-kod)— (R007 kapsar)✅ R007 üzerinden (PR-4)
Faz etiketleri güncellendi

Eski dokümanlarda R00T "PR-8", R010 ise "not_checked" olarak geçiyordu. İkisi de PR-6 ile canlıdır: R00T bloklayıcı olarak fail/pass üretir (onaylı dönem tarife seti yoksa fail), R010 ise uyarı olarak pass/fail üretir (limit başka grupta kullanılmışsa fail). Kaynak: eligibility.py + services/groups.py (değerlendirme girdisi bu iki alanı fiilen dolduruyor).

Blocking kurallar (grubu geçersiz kılabilir) — ayrıntı​

Blocking bir kural fail olursa grup blocked olur; not_checked olursa grup not_checked olur (asla valid). Aşağıda her biri için ne zaman hangi sonucun çıktığı ve ne yapmanız gerektiği verilmiştir.

R001 — Tüm üyeler LÜM/Yönetmelik-26 kapsamında mı?​

  • Kontrol: Grubun her üye tesisinin mahsuplasma_regime alanı lum_yonetmelik_26 mı? (Md.26). Mahsuplaşma hesabı yalnızca bu kapsamdaki tesislerle yapılabilir.
  • Ne zaman ne çıkar: Grupta üye yoksa not_applicable; bir/daha fazla üye 26 dışı bir regime taşıyorsa fail (evidence.violations içinde tesis id + regime listelenir); hepsi 26 ise pass. Bu kural not_checked üretmez — regime alanı her zaman bir değer (en kötü unknown) taşır ve unknown da 26 dışı sayılıp fail verir.
  • FAIL görürsen NE YAPMALI: evidence'taki kapsam-dışı tesisleri gruptan çıkarın, ya da yanlış beyan edildiyse rejimi düzeltin (sihirbaz → 4. adım Özel Kurallar → Mahsuplaşma rejimi alanı; değeri çağrı mektubu / lisans belgesinden doğrulayın). 26 dışı (örn. excluded_yonetmelik_23, licensed, unknown) bir tesis mahsuplaşma grubunda yer alamaz.

R002 — Tüketim tesisleri aynı abone grubunda mı? (Md.5(3))​

  • Kontrol: Tüketim/karma rollü üyelerin abone_grubu değerleri (mesken, ticarethane, sanayi, tarımsal sulama, aydınlatma, diğer) tek bir grupta mı?
  • Ne zaman ne çıkar: Tüketim/karma tesis yoksa not_applicable; bir tüketim tesisinin abone_grubu beyanı eksikse not_checked (blocking → grup valid olamaz); birden fazla farklı abone grubu varsa fail; hepsi aynıysa pass.
  • not_checked görürsen NE YAPMALI: Eksik tesislerin abone grubunu doldurun (4. adım Özel Kurallar → Abone grubu). Değeri elektrik faturanızdaki "abone grubu" satırından okuyun.
  • FAIL görürsen NE YAPMALI: Farklı abone gruplarındaki tüketim tesislerini ayrı gruplara bölün, ya da yanlış beyanı düzeltin. Aynı mahsuplaşma grubundaki tüm tüketim tesisleri aynı abone grubunda olmak zorundadır.

R003 — Çoklu tüketimde tek tedarikçi (Md.5(5))​

  • Kontrol: Grupta birden fazla tüketim tesisi varsa hepsi aynı tedarikçiden mi alım yapıyor? (supplier_id).
  • İstisna (kural uygulanmaz): Grup OSB/EB üzerinden beslenen tesis var işaretliyse veya bir tesis OSB/EB'ye bağlıysa kural not_applicable döner (Md.5(5) + DUY 17/2 istisnası).
  • Ne zaman ne çıkar: Tüketim tesisi ≤1 veya OSB/EB istisnası → not_applicable; tüketim tesisinin tedarikçi beyanı eksik → not_checked; farklı tedarikçiler → fail; tek tedarikçi → pass.
  • not_checked görürsen NE YAPMALI: R003, her tüketim tesisinin tedarikçi kurumu bağlantısına (supplier_id — görünür resmî tedarikçi kurumu) bakar; bu bağlantı eksikse not_checked çıkar. Dikkat: Sihirbazın Ek-1 adımındaki serbest-metin Tedarikçi adı (supplier_name) alanı yalnızca bilgi amaçlıdır ve tek başına bu kuralı karşılamaz — kural tedarikçi kurumunu (supplier_id) arar. Bu bağlantı bu sürümde sihirbazda ayrı bir alan olarak sunulmaz; tesis kaydında supplier_id doldurulduğunda (API: PATCH /api/mahsuplasma/facilities/{id}) R003 artık değerlendirilebilir ve eksik-beyan not_checked durumu kalkar. Tedarikçi adını elektrik faturanızdan bulabilirsiniz.
  • FAIL görürsen NE YAPMALI: Tüm tüketim tesislerini tek tedarikçide toplayın. Gerçekten OSB/EB üzerinden besleniyorsanız, 4. adım Özel Kurallar → OSB/EB üzerinden beslenen tesis var kutusunu işaretleyin; kural o zaman istisna kapsamına girer.

R003M — Ana üretim sayacı atanmış mı?​

  • Kontrol: Grubun alt bölgelerinde main_production (ana üretim) ölçüm rolü atanmış bir sayaç var mı? Mahsuplaşma hesabı, ana üretim ölçümü olmadan yapılamaz.
  • Ne zaman ne çıkar: Grupta üye yoksa not_applicable; main_production rolü atanmamışsa fail; atanmışsa pass (varsa ana tüketim sayacı da mesajda belirtilir).
  • FAIL görürsen NE YAPMALI: Bir cihaza ana üretim sayacı rolü atayın. Sihirbazın 5. adımı (Sayaç + ESS) veya Sayaç Atama ve Kanal Eşleme sihirbazından Ölçüm rolü = main_production seçin. (API: POST /api/mahsuplasma/meters/assign.)

R006 — 5.1.ç ilişkilendirme matrisi (statik ihlaller)​

  • Kontrol: Grupta bir 5.1.ç (öz-tüketim) üretim tesisi varken, statik/kesin mevzuat ihlalleri var mı? İki ihlal aranır:
    • Md.6(9): 5.1.ç yalnız 5.1.h üretim tesisleriyle ilişkilenebilir — grupta 5.1.ç ile birlikte 5.1.h dışı başka bir üretim tipi (5.1.c/f/g...) varsa ihlal.
    • Md.6(3)c: 5.1.ç grubuna müstakil (aynı ölçüm noktası dışı) tüketim tesisi eklenemez.
  • Ne zaman ne çıkar: Grupta 5.1.ç üretim tesisi yoksa not_applicable; yukarıdaki statik ihlaller varsa fail (evidence.violations); statik kurallar sağlanıyorsa pass. Belirsiz/veri-bağımlı kısımlar (5.1.d çağrı tarihi vb.) burada değerlendirilmez.
  • FAIL görürsen NE YAPMALI: evidence'taki uyumsuz üye kombinasyonunu düzeltin — 5.1.ç ile birlikte 5.1.h dışı üretim tipini gruptan çıkarın, veya müstakil tüketim tesisini gruptan çıkarıp aynı ölçüm noktasıyla ilişkilendirin.

R007 — Bedelli limit hesabı var mı? (Md.7(1))​

  • Kontrol: Mesken-dışı bir grupta, her tüketim/karma tesis için ilgili yıla (fatura_donemi_baslangic.year) ait bir bedelli limit hesabı var mı?
  • Ne zaman ne çıkar: Grup mesken grubuysa (is_mesken_group=true) veya hiç tüketim tesisi yoksa not_applicable; en az bir tüketim tesisinin limit hesabı eksikse fail (evidence.missing_facilities); hepsi varsa pass.
  • FAIL görürsen NE YAPMALI: Eksik tesisler için limit hesabı açın. Sihirbazın 6. adımı (Limit) veya Limit Hesapları ekranından girin (API: POST /api/mahsuplasma/limits/accounts). Başlangıç limitini LÜM resmî limitinden ya da müşteri beyanından alın.
R007, PR-4 ile aktifleşti

Mesken grupları (is_mesken_group=true) Md.7(4) gereği bu kuralın dışındadır (aylık hesap, limit sınırlaması yok) ve R007 bu durumda not_applicable döner. Mesken-dışı gruplarda ise en az bir eksik limit hesabı grubu blocked yapar. Ayrıntı: Limit Hesapları.

R00T — Cari dönem için onaylı regüle tarife seti var mı? (Md.11)​

R00T artık canlı (PR-6) — eskiden "PR-8" yazıyordu

R00T, PR-6 ile aktif bir bloklayıcı kuraldır. Kod, değerlendirme anında cari dönemin onaylı tarife setini fiilen sorgular (services/groups.py → approved_set_exists), dolayısıyla gerçek pass/fail üretir — "ileride gelecek" değildir.

  • Kontrol: İki şey birden aranır (Md.11 tutar motorunun girdisi):
    1. Cari fatura dönemi (değerlendirme anındaki takvim ayı başı) için approved (onaylı) bir regüle tarife seti var mı?
    2. Grubun tüketim tesislerinin her abone grubu için o sette mahsuplasma_related_tariff amaçlı bir fiyat satırı tanımlı mı?
  • Ne zaman ne çıkar:
    • Tüketim/karma tesis yoksa → not_applicable.
    • Onaylı set yoksa → fail.
    • Set var ama bazı abone grupları için ilgili tarife fiyatı yoksa → fail (evidence.missing_abone_groups).
    • Bir tüketim tesisinin abone_grubu beyanı eksikse → not_checked (eşleşme doğrulanamaz; blocking → grup valid olamaz).
    • Set var + tüm tüketici abone grupları tanımlı → pass.
  • FAIL / not_checked görürsen NE YAPMALI:
    • Onaylı set yok: Bir superadmin, Regüle Tarifeler ekranından (/console/regulated-tariffs) ilgili dönemin fiyat setini içe aktarıp onaylasın (draft → approved). Fiyatları EPDK'nın yayımladığı tarife tablosundan alın.
    • Eksik abone grubu: Aynı ekrandan, eksik abone gruplarının mahsuplasma_related_tariff fiyat satırlarını ekleyin.
    • not_checked (abone grubu eksik): Önce tesislerin abone_grubu alanını doldurun (bkz. R002), sonra yeniden değerlendirin.

R00L — Bedelli limit hesabı yok (R007 ile eş alt-kod)​

  • Kontrol: R00L, "limit hesabı yok" durumunun eş bir bloklayıcı alt kodudur (PR-4). Motor ayrı bir R00L sonucu üretmez; bu koşul R007 tarafından değerlendirilir. R00L yalnızca severity haritasında tanımlıdır (bloklayıcı sınıflandırması için).
  • NE YAPMALI: Grubunuzda limit eksikliği bir sorunsa R007'yi giderin (yukarıya bakın). Ayrı bir R00L aksiyonu yoktur.

R013 — Grup koşulları sağlanmıyorsa bedelsiz riski (agregat türev)​

  • Kontrol: R013 türev bir kuraldır — kendinden önceki tüm kuralların blocking-fail'lerini toplar (Md.6(4)/9(6)(10)). En az bir blocking-fail varsa "bedelsiz riski" bulgusu üretir.
  • Ne zaman ne çıkar: Önceki kurallarda blocking-fail varsa fail (evidence.triggering_rules = tetikleyen kod listesi); yoksa pass.
  • FAIL görürsen NE YAPMALI: R013'ü doğrudan düzeltemezsiniz — bu bir sonuçtur. evidence.triggering_rules içindeki blocking kuralları (R001, R002, R003, R003M, R006, R007, R00T...) tek tek giderin; hepsi geçtiğinde R013 de kendiliğinden pass olur. R013 fail ise grubun tüm üretimi bedelsiz sanal sayaca yazılır (yukarıdaki bedelsiz senaryo kutusu).

Uyarı (warning) kuralları — ayrıntı​

Warning bir kural fail olursa grup valid_with_warnings olur; hesap koşar, sonuç "yaklaşık/uyarılı"dır. Warning kuralların not_checked olması grubu bloklamaz (yalnızca blocking not_checked bloklar).

R004 — Tesisler tek dağıtım bölgesinde mi? (çoklu-bölge)​

  • Kontrol: Grup tesisleri tek bir dağıtım bölgesinde mi? Farklı bölgeler hesabı "yaklaşık" hale getirir (Md.6(7)(8) + plan §4.2 Açık Konu #15).
  • Ne zaman ne çıkar: Üye yoksa not_applicable; hiçbir tesiste bölge beyanı yoksa not_checked (warning — bloklamaz); birden fazla bölge varsa fail (yaklaşık hesap uyarısı); tek bölge ise pass.
  • NE YAPMALI: Zorunlu değil. Çoklu bölge grubu, LÜM pratiğinde teyit edilene kadar yaklaşık hesaplanır; olduğu gibi bırakabilirsiniz. Belirsizliği azaltmak isterseniz tesislerin dağıtım bölgesi beyanını (distribution_region) doldurabilirsiniz. Bu beyan, Ek-1'deki Dağıtım şirketi (distribution_company_id) seçiminden ayrı bir tesis-kaydı alanıdır — R004 yalnızca distribution_region değerine bakar, dağıtım şirketi seçimi bu kuralı etkilemez. Bu sürümde sihirbazda ayrı bir alan olarak sunulmaz; tesis kaydından ayarlanır (API: PATCH /api/mahsuplasma/facilities/{id}).

R008 — SKTT durumu beyan edildi mi?​

  • Kontrol: Tesislerin sktt_status (Serbest Tüketici / SKTT durumu) beyanı var mı?
  • Ne zaman ne çıkar: Beyan eksikse not_checked; grupta üye yoksa not_applicable; hepsinde beyan varsa pass. Bu sürümde çoğunlukla not_checked'tir (tam SKTT hesabı PR-8).
  • NE YAPMALI: Şu an bir aksiyon gerekmez. SKTT durumu beyanı (sktt_status) için bu sürümde henüz bir arayüz alanı yoktur; R008 uyarı (warning) severity'sinde olduğu için not_checked kalması grubu engellemez. Tam SKTT değerlendirmesi ve beyan alanı ileri fazda (PR-8) gelecektir.

R009 — Üretim kurulu güç beyanı (Md.5(8) saatlik tavan)​

  • Kontrol: Üretim tesislerinde kurulu güç beyanı (installed_power_kw / lum_installed_power_kw) var mı? Saatlik tavan karşılaştırması ileri fazda yapılır.
  • Ne zaman ne çıkar: Bu sürümde her zaman not_checked döner — beyan eksikse "kurulu güç bilinmiyor", beyan varsa "statik kontrol geçti, saatlik tavan PR-5'te". Warning severity olduğu için grubu bloklamaz.
  • NE YAPMALI: Kurulu güç beyanını girin (Ek-1 adımı → Kurulu güç; değeri proje/lisans/çağrı mektubundan). Saatlik tavan kontrolü PR-5 resolver'da aktifleşecektir.

R010 — Limit hesabı başka grup(lar)ca da kullanılmış mı? (transfer)​

R010 artık canlı (PR-6) — eskiden "not_checked" yazıyordu

R010, PR-6 tam kalibrasyonu ile gerçek sonuç üretir: services/groups.py değerlendirme girdisinde, tüketim tesisinin limit hesabında bu grup dışında kullanım hareketi olup olmadığını fiilen sorgular. Dolayısıyla pass/fail üretir (not_checked değildir).

  • Kontrol: Grubun bir tüketim tesisinin bedelli limit hesabı, başka grup(lar) tarafından da kullanılmış mı? (Md.5(4) + Yönetmelik 28/7 kalan-limit transferi değerlendirmesi).
  • Ne zaman ne çıkar: Tüketim/karma tesis yoksa not_applicable; bir tesisin limiti başka grupta kullanılmışsa fail (evidence.facilities_with_cross_group_usage); başka-grup kullanımı yoksa pass.
  • FAIL görürsen NE YAPMALI: Uyarı niteliğindedir, hesabı durdurmaz. Tesis grup değiştirmiş olabilir; kalan limitin bu gruba transferini POST /api/mahsuplasma/limits/transfer ile değerlendirin. Sözleşme gücü ön koşulu beyanı transfer isteğinde taşınır (Zeus'ta sözleşme gücü verisi otomatik doğrulanmaz; bu yüzden kural bloklayıcı değil, uyarıdır).

R011 — Tesis devredilmiş mi? (Md.5(10)(11))​

  • Kontrol: Bir üye tesis devredilmiş mi? Devredilen tesiste yeni bedelli limit, devir tarihinden itibaren aylık hesaplanır.
  • Ne zaman ne çıkar: Bu sürümde her zaman not_checked — tesis sahiplik değişikliği veri modeli henüz yok. Warning severity → grubu bloklamaz.
  • NE YAPMALI: Şu an bir aksiyon yok; devir kontrolü ileri PR'da aktifleşecektir.

Bilgi (info) kuralları — ayrıntı​

Info kurallar yalnızca tespit/etiketleme yapar; grubun genel durumunu değiştirmez. Aksiyon gerektirmezler, ilgili özel hesap dalını bilgilendirirler.

R005 — Özel hesap tipi tespiti (5.1.ç / 5.1.d)​

  • Kontrol: Grupta 5.1.ç (öz-tüketim) veya 5.1.d (kojenerasyon) tipli üretim tesisi var mı? (Md.9(4)/(5)).
  • Ne zaman ne çıkar: Özel tip yoksa not_applicable; varsa tesis başına pass (bilgi — facility_id doldurulur).
  • NE YAPMALI: Bilgi amaçlıdır, aksiyon gerekmez. Özel hesap dalı ileri fazda (PR-5+) uygulanır.

R012 — OSB/EB senaryosu var mı? (Md.9(8)(9))​

  • Kontrol: Grup OSB/EB üzerinden beslenen tesis var işaretli mi veya bir tesis OSB/EB'ye bağlı mı? OSB/EB özel çekiş/verisi hesap dalı gerektirir.
  • Ne zaman ne çıkar: OSB/EB senaryosu yoksa not_applicable; varsa pass (bilgi). Bu tespit ayrıca R003'ün tek-tedarikçi istisnasını da tetikler.
  • NE YAPMALI: Bilgi amaçlıdır. OSB/EB hesap dalı PR-5+ resolver'da uygulanır; ana sayaç bilgisi eksikse sonuç yaklaşık olabilir.

Bulunca ne yapmalı — özet karar tablosu​

Değerlendirme sonucunda grubunuz aşağıdaki genel durumlardan birinde olur:

Genel durumRenkAnlamıİlk adımınız
valid🟢 yeşilTüm blocking kurallar geçtiHesaba hazır — bir şey yapmanıza gerek yok
valid_with_warnings🟡 amberBlocking sorun yok, ama warning fail var (örn. çoklu bölge)Uyarıları gözden geçirin; hesap koşar, sonuç yaklaşıktır
not_checked⚪ griBir blocking kural doğrulanamadı (eksik beyan/veri) veya hiç anlamlı blocking değerlendirilmediEksik beyanı tamamlayın (abone grubu, tedarikçi, tarife...) ve yeniden değerlendirin
blocked🔴 kırmızıEn az bir blocking kural failKırmızı kod(lar)ın "NE YAPMALI" adımını uygulayın; sonra yeniden değerlendirin

Yeniden değerlendirmek için: sihirbazda 7. adıma (Önizleme) dönün ya da POST /api/mahsuplasma/groups/{id}/evaluate çağırın. Her düzeltmeden sonra sonuç anında güncellenir.

Bent tipleri (facility_type_code) hatırlatma​

R005/R006 kuralları tesis bent tiplerine bakar. Kısaca:

KodBentAnlamı
m5_1_c5.1.cKlasik çağrı-mektuplu YEK (≤1 MW); kurulu güç ≤ tüketim sözleşme gücü
m5_1_cedilla5.1.çÖz-tüketim: üretim+tüketim aynı ölçüm noktasında; şebekeye verilen → bedelsiz
m5_1_d5.1.dBakanlık verimlilik kategorisinde kojenerasyon; şebekeye verilen → bedelsiz
m5_1_h5.1.hAynı/farklı ölçüm noktalı YEK; kurulum bölgesizliği olan tek tip
m5_1_f / m5_1_g / m5_1_g_breve / m5_1_i_dotless / m5_1_i5.1.f/g/ğ/ı/iBelediye/DSİ/sulama birliği vb. özel tesisler
m11_1 / m11_3md.11/1, md.11/3≤25 kW tip proje / çatı-cephe (10-yıl kapsamına dahil)

R006 statik ihlalleri (blocking):

  • 5.1.ç yalnız 5.1.h ile ilişkilenebilir (Md.6(9)) — grupta 5.1.ç ile birlikte 5.1.h dışı başka bir üretim tipi varsa ihlal.
  • 5.1.ç grubuna müstakil tüketim tesisi eklenemez (Md.6(3)c) — aynı ölçüm noktası dışı bağımsız tüketim tesisi varsa ihlal.

İlgili sayfalar​