Skip to content

Rozliczenie energii elektrycznej - Mediator Godzinowy

Mediator zwracający dane do wyceny w rozdzielczości godzinowej.

Mediator ten będzie próbował zwrócić zużycie za okres do daty bilingu i jeśli nie będzie to możliwe, to nie zwróci nic. Analizuje dane i w zależności od ustawień będize wykorzystywał dane godzinowe, dane z odczytów lub prognozę. Jeśli korzysta z danych godzinowych, to dane te muszą być dostępne w całym mediowanym okresie i z określoną minimalną jakością. Jeśli korzysta z danych odczytowych, to wynik będzie miał okresy pośrednie zgodne z odczytami wewnątrz okresu mediowanego. Jeśli korzysta z prognozy, to zachowuje się podobnie do użycia danych godzinowych, jedynie mamy wtedy pewność, że dane istnieją, bo będą wygenerowane z profilu i założonego zużycia rocznego.

Decyzja, z których danych krzysta jest podejmowana na podstawie parametrów readout_fallback_days - po ilu dniach czekania ma korzystać z rozprofilowanych odczytów oraz forecast_fallback_days - po ilu dniach czekania ma korzystać z prognozy. Dni “czekania” to dni od kolejnego cyklu billingowego do daty billingu. Te parametry nie będą działały w przypadku wybrania cyklu “zgodnie z odczytami”. Nie zadziałają również w przypadku wybrania strict_measurement_type na true - wtedy mediator ten korzysta wyłącznie z danych określonych w parametrach PPE (dane godzinowe lub profilowe).

  • Nazwa wyświetlana: Rozliczenie energii elektrycznej - Mediator Godzinowy.
  • Dokładna klasa: energycore.mediators.electricity.PPEDetailedMediator
ParametrTypDomyślna wartośćOpis
enabledTekstallWłącza mediatora dla danego PPE dla konkretnego typu billingu: rozliczenia (settlment), prognoza (forecast) lub oba (all).
strict_measurement_typeBooleanfalseWymusza rygorystyczne traktowanie typu pomiaru określonego w PPE (profiowe lub godzinowe).
zone_to_productsdictbrakSłownik konfigurujący mediację strefy na produkt billingowy (jaka strefa na jakie produkty)
readout_fallback_daysIntegerbrakIlośc dni, po których zamiast danych godzinowych wykorzysta dane odczytowe do wygenerowania profili
forecast_fallback_daysIntegerbrakIlośc dni, po których zamiast danych godzinowych wykorzysta prognozę do wygenerowania profili
min_qualityDecimal”1”Minimalna jakość danych godzinowych. Jeśli choć jedna wartość ma mniejszą jakość, okres rozpatrywany zostanie uznany za niekompletny i nie zostanie wygenerowany billing na podstawie danych godzinowych.
{
"zone_to_products":{
"all":[1],
"rest":[2],
"offpeak":[3],
"peak":[4],
"evening_peak":[5],
"night":[6],
"morning_peak":[7],
"day":[8],
"low":[9]
},
"strict_measurement_type": true,
"enabled": "settlement",
"readout_fallback_days": 5,
"forecast_fallback_days": 10,
"min_quality": 1
}

Powyższa konfiguracja spowoduje, że np. jeśli dany PPE jest billingowany w cyklu “początek miesiąca” to wtedy:

  1. Jeśli do 5 dnia kolejnego miesiąca pojawią się dane godzinowe, to zostaną one wykorzystane do wygenerowania faktury
  2. Jeśli po 5 dniu kolejnego miesiąca pojawią się odczyty, ale nie będzie danych godzinowych, to one zostaną wykorzystane do wygenerowania faktury
  3. Jeśli po 10 dniu kolejnego miesiąca nie będzie ani odczytów, ani godzinówek, to zwrócona zostanie prognoza (którą zapewne trzeba będzie skorygować lub rozliczyć)
  1. Podane ID w zone_to_products to identyfikatory produktów billingowych, a nie księgowych.
  2. Jeśli założymy, że nie robiono billingu przez jakiś czas i po upłynięciu dni określonych w readout_fallback_days i forecast_fallback_days pojawią się zarówno odczyty jak i dane godzinowe to mediator wykorzysta dane godzinowe, które mają zawsze priorytet