Kurulum Akışı — Uçtan Uca İlk Kurulum

Bu sayfa, bir müşteri için mahsuplaşmayı sıfırdan kurmanın adımlarını API düzeyinde sırasıyla anlatır (otomasyon / entegrasyon / ileri düzey referans). Aynı kurulum ekran üzerinden Grup Kurulum Sihirbazı ile (7 adım; PR-7b) yapılır — çoğu kullanıcı için önerilen yol sihirbazdır; bu sayfadaki API çağrıları sihirbazın arka planda kullandığı endpoint'lerdir.

Çoğu kullanıcı bu sayfayı OKUMASA da olur — sihirbazı kullanın

Elinizle API çağrısı yapmayacaksanız (script / entegrasyon / toplu içe aktarma yoksa), kurulumu ekran üzerinden yapmanız yeterlidir: Grup Kurulum Sihirbazı →. Sihirbaz aynı 7 adımı (Kapsam → Tesisler → Ek-1 → Özel Kurallar → Sayaç + ESS → Limit → Önizleme) sizin için sırasıyla yürütür ve her alanı formda açıklar. Bu sayfa, sihirbazın arkasındaki API'yi merak edenler ve otomasyon yazanlar içindir.

Hangi alana hangi değeri yazacağınızı ve o değeri nereden bulacağınızı (kurulu güç, başlangıç limiti, harici referans, alt bölge…) hem burada hem sihirbaz sayfasında bulacaksınız.

Sıralama önemlidir

Adımlar birbirine dayanır: sayaç eşlemesi için önce tesis, grup uygunluğu için önce üye ve sayaç, R007'nin geçmesi için önce limit hesabı gerekir. Aşağıdaki sırayı izleyin.

Tüm mutasyon (yazma) işlemleri manage:netting iznini (admin) gerektirir; listeleme/okuma read:netting yeterlidir.

Adım 1 — Kapsam (scope) tanımı ve beyan

Kapsam, müşterinin VKN'siz resmî mahsuplaşma kapsamını temsil eder. Gerçek VKN Zeus'ta tutulmaz (veri minimizasyonu); name alanı Zeus içi bir alias'tır.

POST /api/mahsuplasma/scopes
{ "name": "Müşteri A — Ana Kapsam", "external_party_ref": "LUM-2026-...", "notes": "..." }

Alanları nereden bulurum?

Alan	Ne?	Zorunlu?	Ne yazacağım?	Nereden bulunur?	Boş / yanlış olursa?
`name`	Kapsamın Zeus içi takma adı (alias). Gerçek VKN DEĞİL	✅ Evet (≤120 karakter)	Sizin belirlediğiniz serbest bir ad — ör. "Müşteri A — Ana Kapsam"	Kendiniz uydurursunuz; müşteri/proje adından türetin. VKN İSTENMEZ (KVKK / veri minimizasyonu — gerçek VKN Zeus'ta tutulmaz)	Boş bırakılamaz → 422. Yanlış ad sadece görünürlüğü zorlaştırır, hesabı bozmaz (sonradan `PATCH` ile düzeltilir)
`external_party_ref`	Müşterinin kendi kayıt sistemindeki referans / LÜM rapor alias'ı	❌ Hayır (≤80 karakter)	Müşterinin iç dosya/başvuru numarası — ör. `LUM-2026-00123`	Müşterinin kendi kayıt sistemi (LÜM başvuru/rapor numarası, iç proje kodu). Zeus üretmez, siz bilmiyorsanız müşteriden istersiniz	Boş kalması sorun değildir — yalnızca ileride LÜM raporlarını eşleştirmeyi kolaylaştıran bir etikettir
`notes`	Serbest açıklama notu	❌ Hayır	İstediğiniz açıklama	—	Etkisi yok

external_party_ref neden var?

İleride LÜM (Lisanssız Üretim Modülü) resmî raporlarını Zeus kapsamlarıyla eşleştirirken bu referans "hangi Zeus kapsamı hangi LÜM kaydına ait?" sorusunu hızlı yanıtlar. Zorunlu değildir; elinizde bir LÜM/başvuru numarası yoksa boş bırakın, sonradan PATCH /api/mahsuplasma/scopes/{id} ile eklersiniz.

Kapsam oluşturulduğunda beyan alanları yazılamaz — kapsam declaration_source = 'not_checked' ile doğar. "Tesisler aynı gerçek/tüzel kişiye (VKN) aittir" beyanı ayrı bir action ile kaydedilir:

POST /api/mahsuplasma/scopes/{id}/declare-same-official-party
{ "declaration_source": "official_document" }

Bu çağrıda:

same_official_party_declared = true yazılır,
confirmed_by_user_id her zaman token'daki kullanıcıdır (gövdeden alınmaz — beyan kimliği spoof koruması),
confirmed_at sunucu saati (UTC) ile damgalanır.

Provenance kuralı — güçlü kaynak zayıfla EZİLMEZ

Beyan kaynağı bir güçlülük sıralaması taşır:

customer_declaration < official_document < lum_report / gts_report (son ikisi eş düzey)

Kapsam zaten daha güçlü bir kaynakla beyan edilmişse, daha zayıf bir kaynakla yeniden beyan 409 ile reddedilir (regülasyon provenance'ı sessizce zayıflatılamaz). Aynı veya daha güçlü kaynakla yeniden beyan serbesttir (idempotent yeniden-teyit + yükseltme — confirmed_by/confirmed_at tazelenir).

declaration_source seçenekleri (teknik değer → ne zaman seçilir):

Değer	Anlamı (TR)	Ne zaman seç — elinde hangi belge olmalı
`customer_declaration`	Müşteri beyanı	Elinizde yalnız müşterinin kendi beyanı / imzalı taahhüt formu varken (en zayıf kaynak)
`official_document`	Resmî belge	Kurum yazısı / noter onaylı belge gibi resmî bir dayanak varken
`lum_report`	LÜM (Lisanssız Üretim Modülü) raporu	LÜM'ün yayımladığı resmî rapor elinizdeyken (en güçlü kaynak)
`gts_report`	GTŞ (Görevli Tedarik Şirketi) raporu	GTŞ raporu elinizdeyken (en güçlü kaynak; `lum_report` ile eş düzey)

Sıralama (soldan sağa güç artar): customer_declaration < official_document < lum_report / gts_report. Elinizdeki en güçlü belgenin kaynağını seçin — daha güçlü bir kaynakla beyanlı kapsamı sonradan daha zayıf bir kaynağa düşüremezsiniz (yukarıdaki 409 kuralı). not_checked bir beyan kaynağı değildir (kapsamın henüz beyan edilmemiş başlangıç durumudur); declare-same-official-party çağrısında gönderilirse 422 ile reddedilir.

Adım 2 — Resmî tesis kaydı

Her üretim ve tüketim tesisi ayrı bir resmî tesis kaydıdır. Bu kayıt, mahsuplaşmanın regülasyon bilgilerini taşır.

POST /api/mahsuplasma/facilities
{
  "scope_id": "...",
  "subregion_id": "...",            // Zeus operasyonel saha bağlantısı (opsiyonel)
  "name": "Çatı GES 1",
  "facility_role": "production",    // production | consumption | mixed
  "mahsuplasma_regime": "lum_yonetmelik_26",
  "facility_type_code": "m5_1_h",   // Yönetmelik md.5/1 bent tipi
  "abone_grubu": "sanayi",
  "distribution_region": "...",
  "installed_power_kw": 250.0
  // ... (kurum FK'ları, ESS meta, sözleşme gücü vb.)
}

Sık sorulan iki alan — nereden bulurum?

Alan	Ne?	Zorunlu?	Ne yazacağım?	Nereden bulunur?	Boş / yanlış olursa?
`subregion_id`	Tesisin bağlandığı Zeus operasyonel saha (alt bölge) — cihazlarınızın gruplandığı fiziksel/mantıksal saha	❌ Hayır	Zeus'taki saha listesinden ilgili alt bölgenin kimliği (UUID)	Zeus saha yapısı (Bölgeler / Sahalar menüsü). Sayaç–cihaz eşlemesi yapacağınız alt bölge ile aynı olmalı; hangi cihazın hangi sahada olduğunu Cihazlar sayfasından görürsünüz	Boş bırakılabilir; ama boşsa Adım 3'te cihaz→ölçüm rolü ataması bu tesisle otomatik ilişkilenmez (atamayı yine alt bölge üzerinden yaparsınız). Yanlış alt bölge → cihazlarınız listede çıkmaz
`installed_power_kw`	Tesisin kurulu (AC) gücü, kW	❌ Hayır (0'dan büyük/eşit, 3 ondalık)	Datasheet'teki toplam AC gücü — ör. `250.0`	Proje dosyası / üretim lisansı / çağrı mektubu (kurulu güç satırı). GES için invertörlerin toplam AC gücü; şüphedeyseniz çağrı mektubundaki resmî değeri esas alın	Boş kalması hesabı durdurmaz ama R009 (üretim kurulu güç beyanı, Md.5/8) uyarısı üretir; ayrıca Ek-1 bütünlüğü için istenir. Yanlış değer uygunluk uyarılarını ve raporları yanıltır

installed_power_kw (kurulu güç) ile contract_power_kw (sözleşme gücü) karıştırılmasın

Kurulu güç = tesiste fiilen kurulu üretim gücü (datasheet / lisans / çağrı mektubu). GES tarafında invertörlerin toplam AC gücü.
Sözleşme gücü = dağıtım şirketiyle yapılan bağlantı anlaşmasındaki güç; elektrik faturasındaki "sözleşme gücü" satırından okunur.

İkisi farklı belgelerden gelir ve aynı değer olmak zorunda değildir. Yanlış alana yazmak Ek-1 ve uygunluk kontrollerini yanıltır.

Önemli noktalar:

facility_role: üretim / tüketim / karma.
facility_type_code: yönetmelik bent tipi (m5_1_c, m5_1_cedilla, m5_1_d, m5_1_h, m5_1_f, m5_1_g, m5_1_g_breve, m5_1_i_dotless, m5_1_i, ayrıca m11_1 / m11_3). Bent tiplerinin ne anlama geldiği için bkz. Uygunluk Kuralları — bent tipleri.
mahsuplasma_regime: tesisin mevzuat sınıflandırması (lum_yonetmelik_26, excluded_yonetmelik_23, excluded_support_period_completed, excluded_yonetmelik_30_8, excluded_mixed_23_26, licensed, unknown). Kaynağı çağrı mektubu / lisans belgesidir (tesisin hangi mevzuat kapsamında olduğu); belirsizse şebeke işletmecinize sorun. Mahsuplaşma için tüm üyeler lum_yonetmelik_26 olmalı — aksi hâlde R001 bloklayıcı. Seçeneklerin tamamı ve "ne zaman hangisi" için bkz. Uygunluk Kuralları ve Grup Kurulum Sihirbazı — Özel Kurallar adımı.
abone_grubu: tüketim tesisinin abone (tarife) grubu (mesken, ticarethane, sanayi, tarimsal_sulama, aydinlatma, other). Kaynağı elektrik faturasındaki "abone grubu" satırıdır. Grup içindeki tüketim tesisleri aynı abone grubunda olmalı — aksi hâlde R002 bloklayıcı (bkz. Uygunluk Kuralları).
Kurum FK'ları (şebeke işletmecisi, dağıtım şirketi, OSB/EB, sayaç okuyan kurum, tedarikçi) görünür bir kuruma işaret etmelidir — kendi tenant'ınız veya sistem-geneli katalog. Kurumları POST /api/mahsuplasma/organizations ile önce oluşturursunuz.
ESS (batarya) meta alanları tutarlı olmalıdır: has_ess=false iken ess_* alanları boş kalmalı; ess_min_soc_pct < ess_max_soc_pct. İhlal → 422.
valid_from gönderilmezse DB TR-yerel bugünü yazar.

inverter_type (grid vs ESS)

Tesise ait invertör cihazları için Device.inverter_type alanı (grid_inverter | ess_inverter) ölçüm semantiğini etkiler. Bu alan otomatik doldurulmaz (yanlış-sınıflama riski). Zeus, cihaz template adından bir öneri üretir (SOFAR+HYD → ess_inverter; SUN2000/KTLX/grid-tie → grid_inverter; belirsiz → öneri yok) ve siz açıkça uygularsınız:

GET  /api/mahsuplasma/inverter-type/suggestions    // öneri listesi (uygulamaz)
POST /api/mahsuplasma/inverter-type/apply
{ "items": [ { "device_id": "...", "inverter_type": "ess_inverter" } ] }   // 1–500 öğe

apply atomiktir: listedeki tek bir geçersiz/cross-tenant cihaz tüm işlemi durdurur (kısmi uygulama yok); yanıt eksik id'leri listeler. Aynı istekte tekrar eden device_id → 422 (çelişen atama). device_role != 'inverter' olan cihaza atama → 422.

Tesis silme

Yalnız superadmin; kalıcı (hard-delete).

Yanlışlıkla veya test amaçlı oluşturulmuş bir tesis kaydı kalıcı olarak silinebilir. Bu işlem yalnızca süper yöneticiye (superadmin) açıktır; normal manage:netting yetkisi yetmez. Frontend'de, tesis detay sayfasında (/mahsuplasma/facilities/{id}) yalnız superadmin'e görünen "Tesisi Sil" butonu bulunur; buton bir onay dialogu açar ve onaylandığında kayıt kalıcı silinir.

DELETE /api/mahsuplasma/facilities/{facility_id}     // superadmin; 204 No Content

Hard-delete — GERİ ALINAMAZ

Silme işlemi bir arşivleme değildir: satır tamamen kaldırılır (valid_to ile dönem kapatma değil). Geri alınamaz. Bir tesisi tarihçesiyle korumak istiyorsanız silmek yerine dönemini kapatmanız (ileride gelecek düzeltme akışı ile) tercih edilir — dönem-kapatma/düzeltme semantiği ayrı bir sürümde (CorrectionEngine) ele alınmaktadır.

Bağımlılık kuralı — bağlı kayıt varsa silme reddedilir (409)

Bir tesis yalnızca tamamen bağımsızsa silinebilir. Tesise bağlı en az bir alt kayıt varsa silme 409 ile reddedilir (yetim veri / sessiz kayıp olmaması için). Yanıt, engelleyen bağımlılıkların sayısını gösterir:

Bağımlılık	Ne demek?
`metering_points`	Tesise bağlı ölçüm noktaları
`subregion_meter_assignments`	Cihaz → ölçüm rolü atamaları
`facility_hourly_energy`	Saatlik enerji fact kayıtları
`mahsuplasma_group_members`	Grup üyelikleri
`bedelli_limit_accounts`	Bedelli limit hesapları

Çözüm: önce sayısı > 0 olan bağımlılıkları kaldırın (ör. ölçüm noktalarını, sayaç atamalarını sonlandırın/silin; grup üyeliğini kaldırın; limit hesabını kaldırın), sonra tesisi silin. Silme başka bir tenant'ın tesisi için de yapılabilir (superadmin global'dir — örnek-veri temizliği).

Adım 3 — Sayaç eşleme (ölçüm noktası + rol ataması)

Sayaç eşleme iki parçadan oluşur.

3a — Ölçüm noktası (metering point)

Bir tesise bağlı resmî/mantıksal sayaç okuma noktası:

POST /api/mahsuplasma/facilities/{facility_id}/meters
{
  "name": "PCC Sayaç",
  "metering_point_code": "...",
  "connection_level": "distribution",   // transmission | distribution | osb_eb | unknown
  "osos_installation_id": "..."         // OSOS köprüsü (opsiyonel — resmî-yakın veri)
}

Ölçüm noktası tarihçelidir (aynı kod farklı dönem versiyonları ayrı satırlar). facility_id path'ten alınır; valid_from gönderilmezse DB NOW() yazar.

3b — Cihaz → ölçüm rolü ataması

Bir Subregion içindeki fiziksel cihazı bir ölçüm rolüne bağlar. Bu, hesap motorunun girdi rollerini (ana üretim / ana tüketim / PCC / OSB-EB / alt-sayaçlar) tanımlar:

POST /api/mahsuplasma/meters/assign
{
  "subregion_id": "...",
  "device_id": "...",
  "meter_role": "main_production",   // 9 rol; ilk 4'ü ANA rol
  "valid_from": "2026-07-01T00:00:00Z",
  "energy_semantics": "cumulative_counter"
}

meter_role değerleri:

Rol	Açıklama	ANA rol mü?
`main_production`	Ana üretim sayacı	✅
`main_consumption`	Ana tüketim sayacı	✅
`pcc_import_export`	Bağlantı noktası (import/export)	✅
`osb_eb_consumption`	OSB/EB çekiş sayacı	✅
`same_measurement_point`	Aynı ölçüm noktası (5.1.ç/d)	—
`sub_production` / `sub_consumption`	Alt üretim/tüketim	—
`auxiliary` / `internal`	Yardımcı / iç tüketim	—

Ana rol dönem-çakışma kuralı

valid_from zorunludur (billing dönemi = iş kararı; sessiz NOW() mahsuplaşma hesabını bozar). Aynı alt bölgede (subregion) aynı ANA ölçüm rolü için dönemler çakışamaz — çakışan bir dönem denenirse 409 (dönem çakışması) döner (EXCLUDE ex_sma_no_overlap_main_meter).

Bu kural yalnız 4 ANA rolü tekilleştirir; alt/yardımcı roller bilinçli olarak çakışabilir (bir cihaz birden fazla alt-rolde olabilir). Bir atamayı sonlandırmak için PATCH .../meters/assignments/{id} ile valid_to gönderin (subregion_id/device_id değiştirilemez).

Adım 4 — Grup kurma ve üye ekleme

4a — Grup oluştur

POST /api/mahsuplasma/groups
{
  "name": "2026 Temmuz Grubu",
  "scope_id": "...",
  "fatura_donemi_baslangic": "2026-07-01",
  "is_mesken_group": false,
  "responsible_supplier_id": "..."   // görünür kurum (opsiyonel)
}

Grup uygunluk alanları (eligibility_status/eligibility_notes) bu endpoint'ten yazılamaz — not_checked ile doğar; uygunluk ayrı bir evaluate action'ıyla hesaplanır (Adım 5).

group_status bir state-machine ile korunur — yalnız ileri-akış veya inactive yönünde değişebilir:

customer_defined → ek1_submitted → grid_operator_confirmed → lum_reported
(her durumdan → inactive)

Geri düşme/atlama denemesi → 409 (state-machine).

4b — Üye ekle

POST /api/mahsuplasma/groups/{group_id}/members
{
  "facility_id": "...",
  "member_role": "production",       // production | consumption | mixed
  "relationship_type": "standard",
  "valid_from": "2026-07-01"
}

declared_by_user_id her zaman token kullanıcısıdır (beyan kimliği spoof koruması).
Bir tesis aynı dönemde YALNIZ bir grupta yer alabilir. Aynı tesisi çakışan bir dönemde ikinci gruba eklemeye çalışmak → 409 (tek-grup EXCLUDE). Önce mevcut üyeliğin valid_to'sunu kapatın, sonra yeni gruba ekleyin.

Md.6(2) — geçmiş döneme üyelik YASAK

valid_from, grubun fatura döneminden veya içinde bulunulan fatura döneminden (hangisi erkense) öncesine set edilemez (Yönetmelik Md.6(2) geriye-dönük değişiklik yasağı) → 422. Maddi-hata düzeltmesi için ayrı admin akışı ileride eklenecektir.

Üyeliği kaldırmak için hard delete (DELETE) yerine PATCH .../members/{id} ile valid_to göndererek dönemi kapatmanız önerilir (tarihçe korunur).

Adım 5 — Uygunluk değerlendirmesi (evaluate)

Grup üyeleri ve sayaç eşlemeleri hazır olunca uygunluk motorunu çalıştırırsınız:

POST /api/mahsuplasma/groups/{group_id}/evaluate

Bu yazma işlemidir: grup satırı FOR UPDATE ile kilitlenir, R001–R013 kural sonuçları salt-append log'a tek transaction'da yazılır ve grubun eligibility_status'u güncellenir. Sonucu daha sonra okumak için:

GET /api/mahsuplasma/groups/{group_id}/eligibility

Yanıttaki status şu değerlerden biridir:

Durum	Anlamı	Ne yapmalı
`valid`	Tüm blocking kurallar sağlandı	Devam edin
`valid_with_warnings`	Blocking sorun yok ama uyarı/hata var	Uyarıları gözden geçirin
`blocked`	En az bir blocking kural FAIL	İhlali giderin (evidence'a bakın)
`not_checked`	Bir blocking kural henüz doğrulanamadı	Eksik veriyi/hesabı tamamlayın

Kuralların tam listesi ve not_checked'in neden asla valid sayılmadığı için bkz. Uygunluk Kuralları.

Adım 6 — Bedelli limit hesabı açma

Mesken dışı gruplarda her tüketim tesisi için ilgili yıla ait bir bedelli limit hesabı zorunludur (Md.7(1)). Bu hesap R007 uygunluk kuralının geçmesinin ön koşuludur (PR-4'te aktifleşti).

POST /api/mahsuplasma/limits/accounts
{
  "facility_id": "...",
  "year": 2026,
  "initial_limit_kwh": 120000.0,
  "current_official_limit_kwh": 120000.0,   // opsiyonel — boşsa initial kabul edilir
  "limit_source": "customer_declared",       // opsiyonel — boşsa 'manual'
  "source_ref": "Müşteri beyanı 2026-07"     // opsiyonel — belge no / açıklama
}

Alanları nereden bulurum? (initial_limit_kwh en kritik alandır)

Alan	Ne?	Zorunlu?	Ne yazacağım?	Nereden bulunur?	Boş / yanlış olursa?
`year`	Limitin ait olduğu yıl	✅ Evet (2000–2100)	Fatura döneminin yılı — ör. `2026`	Fatura dönemi tarihinden	Yanlış yıl → limit yanlış döneme yazılır; hesap o yıl için R007'yi geçmez
`initial_limit_kwh`	Tesisin o yıla ait bedelli ihtiyaç fazlası limiti (kWh) — kalan limit defterinin başlangıç bakiyesi	✅ Evet (≥0, 3 ondalık)	Resmî yıllık kWh limiti — ör. `120000.0`	1. tercih: LÜM (Lisanssız Üretim Modülü) resmî limiti. 2. tercih (LÜM verisi henüz yoksa): müşteri beyanı ya da dağıtım şirketinin bildirdiği limit. LÜM entegrasyonu gelene kadar müşteri beyanı esas alınır	Boş bırakılamaz (zorunlu). Yanlış/eksik değer tüm mahsuplaşma hesabını etkiler: kalan limit yanlış olur, "bedelli ihtiyaç fazlası" ve "bedelsiz üretim" tutarları kayar
`current_official_limit_kwh`	Güncel resmî limit (LÜM raporundan)	❌ Hayır	LÜM raporundaki güncel değer	LÜM raporu (varsa). Gönderilmezse sistem `initial_limit_kwh` değerini kabul eder	Boşsa `initial_limit_kwh` kullanılır — sorun değil
`limit_source`	Bu limitin kaynağı (kanıt tipi)	❌ Hayır	Aşağıdaki 5 seçenekten biri; boşsa `manual`	Elinizdeki belge tipine göre seçin (aşağıdaki tablo)	Boşsa `manual` sayılır; yanlış kaynak yalnız izlenebilirliği zayıflatır, hesabı bozmaz
`source_ref`	Kaynak belgenin numarası / kısa açıklaması	❌ Hayır (≤120 karakter)	Belge no ya da "Müşteri beyanı 2026-07" gibi	Kaynak belgeden	Etkisi yok — sadece iz kaydı
`notes`	Serbest not	❌ Hayır	İstediğiniz açıklama	—	Etkisi yok

limit_source seçenekleri (teknik değer → ne zaman seçilir):

Değer	Anlamı	Ne zaman seç
`manual`	Elle girildi (varsayılan)	Kaynağı ayrıca belgelendirmeyeceksen
`customer_declared`	Müşteri beyanı	LÜM resmî verisi henüz yokken müşterinin bildirdiği limiti girerken (şu an en sık kullanılan)
`lum_report`	LÜM resmî raporu	Elinde LÜM'ün yayımladığı resmî limit raporu varken (en güçlü kaynak)
`grid_operator`	Dağıtım/şebeke işletmecisi bildirimi	Limit doğrudan dağıtım şirketinden geldiyse
`calculated`	Hesaplanmış	Limit başka verilerden türetildiyse

initial_limit_kwh — kurulumun EN KRİTİK alanı

Bu değer, mesken-dışı bir tüketim tesisi için bedelli ihtiyaç fazlası hesabının başlangıç bakiyesidir. Kalan limit her hesap koşusunda kalan = initial_limit_kwh + hareketler olarak canlı hesaplanır; bu yüzden yanlış bir başlangıç değeri tüm dönem boyunca yanlış tutarlar üretir.

Elinizde resmî LÜM limiti yoksa: müşterinin beyan ettiği limiti girin ve limit_source alanını customer_declared yapın (izlenebilirlik için). LÜM verisi geldiğinde current_official_limit_kwh'ı lum_report kaynağıyla güncelleyebilir veya bir düzeltme hareketi ekleyebilirsiniz — bkz. Limit Hesapları.

Bu alan boşsa hesap oluşturulamaz (zorunlu). Mesken gruplarında ise limit hesabı hiç açılmaz (bu adım tamamen atlanır) — çünkü bu adım yalnızca mesken dışı gruplardaki tüketim tesisleri için gereklidir (Md.7(1)).

Hesap satırı + bir başlangıç hareketi (initial, amount=0 audit marker) tek transaction'da yazılır (yarım/hareketsiz hesap yasak).
Tesis × yıl tekildir — aynı tesis + aynı yıl için ikinci hesap → 409.

Limit hesabının nasıl çalıştığı, hareket defteri ve transfer için bkz. Limit Hesapları.

Sonraki adımlar

Kurulum tamamlandığında:

Uygunluğu evaluate ile doğrulayın, blocked/not_checked durumları giderin.
Bedelli limit hesaplarını açın; R007'nin geçtiğini teyit edin.
Saatlik hesap ve tutar (Md.9/Md.11) PR-6 ile canlıdır — sonuçları grup detayındaki sekmelerden veya API'den izleyin (bkz. Hesap Çekirdeği).

Sorun yaşarsanız SSS ve Sorun Giderme sayfasına bakın.

Adım 1 — Kapsam (scope) tanımı ve beyan​

Adım 2 — Resmî tesis kaydı​

Tesis silme​

Adım 3 — Sayaç eşleme (ölçüm noktası + rol ataması)​

3a — Ölçüm noktası (metering point)​

3b — Cihaz → ölçüm rolü ataması​

Adım 4 — Grup kurma ve üye ekleme​

4a — Grup oluştur​

4b — Üye ekle​

Adım 5 — Uygunluk değerlendirmesi (evaluate)​

Adım 6 — Bedelli limit hesabı açma​

Sonraki adımlar​