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
Parametry konfiguracyjne
Section titled “Parametry konfiguracyjne”| Parametr | Typ | Domyślna wartość | Opis |
|---|---|---|---|
enabled | Tekst | all | Włącza mediatora dla danego PPE dla konkretnego typu billingu: rozliczenia (settlment), prognoza (forecast) lub oba (all). |
strict_measurement_type | Boolean | false | Wymusza rygorystyczne traktowanie typu pomiaru określonego w PPE (profiowe lub godzinowe). |
zone_to_products | dict | brak | Słownik konfigurujący mediację strefy na produkt billingowy (jaka strefa na jakie produkty) |
readout_fallback_days | Integer | brak | Ilośc dni, po których zamiast danych godzinowych wykorzysta dane odczytowe do wygenerowania profili |
forecast_fallback_days | Integer | brak | Ilośc dni, po których zamiast danych godzinowych wykorzysta prognozę do wygenerowania profili |
min_quality | Decimal | ”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. |
Przykładowa konfiguracja
Section titled “Przykładowa konfiguracja”{ "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:
- Jeśli do 5 dnia kolejnego miesiąca pojawią się dane godzinowe, to zostaną one wykorzystane do wygenerowania faktury
- Jeśli po 5 dniu kolejnego miesiąca pojawią się odczyty, ale nie będzie danych godzinowych, to one zostaną wykorzystane do wygenerowania faktury
- 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ć)
- Podane ID w
zone_to_productsto identyfikatory produktów billingowych, a nie księgowych. - Jeśli założymy, że nie robiono billingu przez jakiś czas i po upłynięciu dni określonych w
readout_fallback_daysiforecast_fallback_dayspojawią się zarówno odczyty jak i dane godzinowe to mediator wykorzysta dane godzinowe, które mają zawsze priorytet