Forbedringssaker under arbeid

Sist oppdatert 2021-04-21 15:54

27 saker - sist oppdatert 21.04.2021


ElhubIDTypeOppsummeringPrioritetStatusBeskrivelse
EI-383ImprovementForbedre prosess for innflytting i inaktivt målepunkt1In implementationNår et målepunkt er frakoblet grunnet manglende kunde og registrert inaktivt i Elhub må innflytting registreres gjennom _BRS-NO-102 - Oppstart kraftleveranse - innflytting frem i tid_. Tidsfristene i denne BRSen er de samme uavhengig om målepunktet er aktivt eller inaktivt, dvs. når kraftleverandør sender melding må de oppgi en oppstartsdato frem i tid. Sluttbruker melder sjelden om innflytting frem i tid og kan da ende opp med å ta over en bolig uten strøm. I disse tilfellene ønsker de naturlig strømmen koblet til umiddelbart, noe kraftleverandør ikke kan oppgi i BRS-NO-102. Dette resulterer i at enten kraftleverandør eller sluttbruker må kontakte nettselskapet utenom normale markedsprosesser. Det kan også resultere i at prosesser må reverseres for at korrekt innflyttingsdato skal bli registrert.
EI-703InitiativeForbedringer i flytteprosessen2In progressFlytteprosessen har av flere aktører i markedet blitt trukket frem som et problemområde. Elhub har sammen med aktørene kartlagt de største utfordringene og satt i gang flere tiltak. Noen av tiltakene innebærer endringer i Elhubs markedsprosesser.
EI-357ImprovementLegge til et tidsstempel i utgående BRS-NO-313 og BRS-NO-3152In MTElhub endret fra å bruke registration date i innkommende BRS-NO-313 og BRS-NO-315 og insert time i utgående BRS-NO-313 og BRS-NO-315, til å bruke registration date i både innkommende og utgående BRS-NO-313 og BRS-NO-315.

Dette for å unngå å sende duplikate tidsstempel i to ulike versjoner av måleverdiene. Det som tapes er 100 % klar identifikasjon av hvilke versjoner av måleverdiene som har vært brukt i balanseavregningsgrunnlaget og avviksoppgjøret. For å unngå duplikate tidsstempel og ivareta transparens trengs to tidsstempel i utgående BRS-NO-313 og BRS-NO-315, registration date og insert time.
EI-252ImprovementHåndtering av innflytting tilbake i tid over hendelser2Ready for planningI Elhub er det flere begrensninger for å gjennomføre innflytting tilbake i tid som krysser en hendelse på målepunktet eller i nettområdet.

Det skjer at det er registrert et opphør av kraftleveranse eller et leverandørskifte for gammel sluttbruker på et målepunkt hvor en ny sluttbruker allerede har flyttet inn. I Elhub vil innflytting bli avvist fordi det ikke er lov å gjennomføre en oppstart tilbake i tid forbi en annen kontraktsstart. Situasjonene som er meldt:
# Kraftleverandør har meldt opphør av kraftleveranse gjennom BRS-NO-202 selv om sluttbruker har flyttet ut. Dette kan skje fordi de ikke får tak i sluttbruker og ikke får krevd inn utestående faktura. Opphør av kraftleveranse resulterer i kontraktsstart med leveringspliktig kraftleverandør.
# Kraftleverandør melder leverandørskifte gjennom BRS-NO-101 selv om sluttbruker har flyttet ut. Dette kan skje fordi sluttbruker tegnet ny kontrakt for lenge siden og har deretter glemt å si opp.
# Porteføljeflytt blir gjennomført selv om sluttbruker har flyttet ut.

Hvis ny sluttbruker ikke melder innflytting før en av de tre situasjonene oppstår vil ny kraftleverandør ikke kunne melde innflytting på korrekt dato.

Elhub vil også avvise innflytting tilbake i tid som krysser endring i leveringspliktig kraftleverandør i nettområdet i de tilfeller hvor sluttbruker skal bli lagt på leveringsplikt. Dette kan skje hvis kraftleverandør melder innflytting mer enn 30 virkedager tilbake i tid eller om nettselskapet melder innflytting.
EI-837BugUtvidet lagring av måleverdier skal ikke oppdateres i forbindelse med leverandørskifte2In implementationDet er ikke mulig for en kraftleverandør å vite om en sluttbruker har valgt utvidet lagring av måleverdier når de gjennomfører et leverandørskifte. Per i dag overskrives verdien i Elhub av det kraftleverandører oppgir i markedsprosessen. Utvidet lagring bør ikke oppdateres i disse tilfeller. Løsningsforslag er at Elhub ignorerer denne verdien i BRS-NO-101 og 104.
EI-658ImprovementRevidere retningslinjer for håndtering av dødsbo3Analysis in progressI dag er det definert hvordan dødsbo skal håndteres i spørsmål og svar dele på elhub.no: [https://elhub.no/sporsmal-og-svar/elhubs-funksjon/#hvordan-vil-elhub-handtere-dodsbo]

Fungerer disse retningslinjene eller bør de revideres?
EI-270ImprovementBransjestandard for utregning av estimert årsforbruk, ansvaret flyttes til Elhub3Analysis in progressMarkedet behøver forventet årsforbruk også for timeavregnede målepunkt, dette er ikke eksplisitt krevet i Elhub.

Elhub vil løse dette som en del av 15-minutter prosjektet, ved å regne ut EAC for alle målepunkt i Elhub, og sende dette ut som BRS-NO-317. Netteier vil fortsatt være ansvarlig for å sende inn et antatt årsforbruk ved opprettelse av nye forbrukspunkter, og både netteier og kraftleverandør vil kunne overskrive det estimerte årsforbruket i Elhub ved større endringer på målepunktet. 

Fordelen med at Elhub regner ut det estimerte årsforbruket for alle målepunkter er at det da blir likt for hele bransjen og alle vil følge samme standard. 
EI-494ImprovementTilpasse valideringsregler til ny nettapsberegningsmetode3Analysis in progressDet nye regimet for nettapsberegning gjør at valideringsreglene for balanseavregning er tildels utdaterte. 

To av reglene vil nå ikke lenger slå til og en av reglene er egentlig ikke en balanseavregningsvalidering, men en test. Disse bør fjernes. 

Samtidig bør det vurderes nye regler

F.eks. Når nettapsberegningsmetode velges automatisk, må alle nett ha nettapsparametre. Vi bør ha en regel som gjør at nettområder stoppes hvis de beregnes med profilmetode men ikke har nettapsparametre for det gjeldende bruksdøgnet. "Nettapsparametre finnes". 
EI-680ImprovementForenkling av prosess for å gi tilgang ved tredjepartsforespørsler for privatpersoner3Analysis in progressInnspill fra tredjepartene tilsier at det kan være vanskelig å få tilgangene som må gis før tredjepartene kan yte sine tjenester til private sluttbrukere. Det bør utredes om det finnes enklere måter å få den eksplisitte tilgangen gitt.
Per nå er vi i kontakt med Altinn for å høre hvilke tjenester de kan tilby. Det å gi eksplisitt tilgang er ikke en unik handling for Elhub, ergo kan vi lete etter eksisterende offisielle tjenester for implementering i Elhub.

Utredning bør også omhandle organisasjoner og tilgang, da det kan være Altinns egne grensesnitt går mindre i time-out når de brukes direkte.
EI-821ImprovementMer fleksibel løsning for å gjennomføre leverandørskifte på store mengder målepunkter3Analysis in progressI forbindelse med porteføljeovertagelser kan det i enkelte tilfeller være ønskelig at Elhub skal gjennomføre porteføljeovertagelsen der ikke alle målepunkter skal overføres til ny kraftleverandør. Dette kan forekomme hvis det er en delvis flytt av porteføljen, eksempler på det kan være at et kraftselskap ønsker å dele opp virksomheten i privat- og bedriftskunder eller at produksjonsmålepunkter skal beholdes ved selskapsskille.

Elhub har i dag ingen støtte for å gjennomføre delvis porteføljeovertagelse, i disse tilfellene må aktør massekjøre leverandørbytter (BRS_NO-101) 

Et forslag er å opprette muligheten for å kjøre porteføljeovertagelsen på et bestemte målepunkter. 
EI-470ImprovementForbedre kapasitet på meldingsmottak i Elhub3Analysis in progressMed bakgrunn i blant annet tidligere diskusjoner om Kommunesammenslåingen og erfaringer med BRS-NO-611 i tiden etter Go Live har flere markedsaktører uttrykt en økt bekymring for kapasiteten til Elhub. Vi ser også behov for ytelse i Elhub knyttet til grunndataoppdateringer 301, 302 og 402, og flere aktører ønsker å gjennomføre porteføljeovertagelser med BRS-NO-101. 

Det legges ekstra arbeid, kostnader og ansvar på aktørene og systemleverandørene for å regulere trafikken inn til Elhub. Eksempler på dette er pålagte justeringer i forhold til bruk av BRS-NO-611, BRS-NO-317 og valget av å gjennomføre kommunenummeroppdateringen uten meldingsutveksling. Å gjøre oppdateringer uten meldingsutveksling gir stor risiko for mismatch i data.

Det vil komme situasjoner i fremtiden der det er påkrevd at alle aktører i markedet må oppdatere gjennom meldingsutveksling innenfor et kort tidsrom. Det oppstår også jevnlig situasjoner der en aktør må sende store mengder data i løpet av kort tid.

For å sikre effektiv ressursutnyttelse og høy datakvalitet som er synkron på tvers av aktørene, så må det være en ambisjon for Elhub at løsningen skal ha grunnleggende god ytelse samt ha muligheten til å skalere ved behov. Det er viktig at Elhub, og markedet, i forkant er rigget for å håndtere disse situasjonene

Elhub bør i første omgang levere en aksjonsplan for forbedring av kapasiteten til Elhub, gjerne i form av et roadmap, med leveringsdatoer.
# EI-784 Første steg bør være å utarbeide en analyse av hvilken kapasitet Elhub har i dag. Basert på erfaringer fra drift har vi sett at ytelsen Elhub er testet for i mange tilfeller er vesentlig lavere enn ytelsen vi har sett at Elhub faktisk tåler. Vi ønsker en oversikt over kapasiteten i prosessering av antall meldinger per minutt, time, dag på maksimum. BRSene som til nå har vært brukt i større volum er 611, 317, 302 og 101. Vi ønsker at man plukker ut enkelte bruksdøgn med høyt volum og analyserer disse. For 101 må man analysere både innsending og oppvåkning da denne BRSen har ventesteg.
EI-486ImprovementKartlegge gjenstående operasjonelle utfordinger med markedsprosesser og måleverdiinnsending på profilavregnede målepunkter3Analysis in progressI runden rundt bordet i BF 22.01.2020 var det svært mange aktører som fortsatt rapporterer om utfordringer med profilavregnede anlegg. Brukerforum ønsker at det utarbeides en totaloversikt over de problemene markedet nå har med markedsprosesser og måleverdiinnsending på profilavregnede målepunkter, med indikasjon på hvor rotårsaken til problemet ligger.
EI-460ImprovementInkludere totalt profilert forbruk og mer informasjon om nettap i BRS-NO-3213Analysis in progressBRS-NO-321 inneholder totalt timesavregna forbruk men ikke totalt profilavregna forbruk. Dette fordi det finnes målepunkter uten kontrakt. Disse er en del av JIP, men ikke en del av profilavregna forbruk. Dette gjør det også umulig for netteierene å regne ut de forskjellige komponentene i nettapet.

Vi vil endre BRS-NO-321 slik at det inneholder de samme feltene man kan finne i aktørportalen. Dette krever noen nye business types.
EI-889ImprovementFornyet aktørtilgang for vask mot Folkeregisteret3Analysis in progressAktørenes tilgang til vask mot DSF i forbindelse med migrering utløper i løpet av 2021 og må fornyes. Grensesnittet må også endres da Evrys rolle som distributør fases ut og aktørene kan koble seg direkte mot Skatteetatens API. 

Videre må det avklares hvilken rettighetspakke bransjen kan få:
* Rettighetspakke privat: Må ha korrekt navn, i kombinasjon med noe annet som adresse eller fødselsnr
* Rettighetspakke offentlig og privat: Skal utføre en offentlig oppgave, muliggjør treff på fødselsnr alene, evt navn alene

I forbindelse med dette er det behov for å kartlegge hvordan aktørene gjennomfører oppslag mot folkeregisteret i dag og hvilken input det er realistisk å forvente at de har når de gjør et oppslag.
EI-339ImprovementImplementere valideringsregler for postadresser til sluttbruker3Ready for planningDet har vært jobbet med å forbedre datakvaliteten i markedet ved operasjonell oppfølging av markedsaktørene. Det er nå et ønske om at Elhub analyserer og implementere hensiktsmessige formatvalideringer relatert til:
* Sluttbrukers kontaktinformasjon ((ikke inkludert i denne saken))
* Sluttbrukers post- og fakturaadresse
* Anleggsadresse (ikke inkludert i denne saken)

Grunnet begrensninger i forskrift vil denne saken være begrenset til valideringsregler for Sluttbrukers post- og fakturaadresse.
EI-59ImprovementMulighet for nettselskap å avvise en innflytting i inaktivt målepunkt3In implementationOm en innflytting i inaktivt målepunkt ikke kan fullføres må prosessen ligge på vent i to uker før den blir avvist. Det burde finnes noen mulighet for å avvise disse prosessene tidligere hvis noen aktør vet at den ikke kan fullføres.
EI-840ImprovementVurdere utvidet funksjonalitet for innsyn i og sletting av forespørsler i BRS-NO-6013Analysis in progressI BRS-NO-601 kan det forekomme kommunikasjon av persondata, f.eks. som beskrevet i Prosedyre for utflytting hvor ny sluttbruker ikke er kjent. Innebærer dette at Elhub bør tilby markedsaktørene funksjonalitet for innsyn i og sletting av denne typen meldinger og tilhørende informasjon som lagres i Elhub?
EI-823BugPeriodevolum estimert av Elhub skal ikke være gyldig måleravlesning til leverandørskifte3Analysis in progressDet skal være registrert i Elhub en avlesning nyere enn tre måneder før markedsaktør initierer en oppstartsprosess. Om dette ikke foreligger skal Elhub avvise prosessen. Per i dag vil valideringen slippe igjennom oppstartsprosesser selv om der kun ligger en avlesning estimert av Elhub som resultat av en hendelse på målepunktet. Dette er ikke riktig og skal rettes opp.
EI-717InitiativeDistribusjon av nettariff3In progressRME jobber med endringer i regelverket rundt nettleie. Nettselskapene vil være ansvarlige for å tilgjengeliggjøre tariffen og sluttbrukerne skal i større grad få tilgang til prissignaler som de kan agere på. For at informasjon om nettariff skal kunne distribueres kostnadseffektivt og for at sluttbrukere og andre aktører skal kunne operere nasjonalt bør bransjen bli enige om en standard.
EI-381ImprovementDefinere kjøreregler for hvordan kraftleverandør kan informere nettselskap om kontaktinformasjon for varsling gjennom Elhub3Analysis in progressElhub legger til rette for at kraftleverandører kan registrere kontaktinformasjon for varsling og tilsyn i Elhub.

Kraftleverandører skal registrere kontaktinformasjon om sine sluttbrukere i Elhub. Men de er ikke forpliktet til å innhente kontaktinformasjon som skal brukes til varsling eller andre oppgaver som nettselskapet ivaretar. Vi bør se på hvordan kraftleverandører kan formidle dette til nettselskapet hvis sluttbruker ønsker det. Det må løses på en måte som gjør at nettselskapet kan behandle dette riktig i sine systemer.

Foreslått løsning i første omgang er å bruker Description feltet i Communication Channels for å definere et set roller som er entydig forstått i markedet.
EI-508ImprovementSammenligne aktuell kjøring med historisk gjennomsnitt for å finne avvik i balanseavregningen - endring i Daglige måleverdier liste3In implementationNettselskapene har behov for verktøy som kan anvendes for feilsøking og analyse av måledata rapportert til Elhub. Det har kommet flere konkrete forslag, de fleste av disse forslagene er dekket av EI-264.

I dag kan en:
* På aggregert nivå i balanseavregningen så sammenligner vi en kjøring med samme kjøring 7 dager før
* På overordnet nivå i måleverdimottaket så sammenligner vi antall innkommende verdier med gjennomsnitt de siste x (7?) dagene

Elhub har forslag til ytterlige forbedringer:
* Forslag til endring i Daglige måleverdier liste:
** Legge til en kolonne med gjennomsnitt de siste 7 dager + % avvik
** Legge til en kolonne med tall for bruksdøgnet for 7 dager siden + % avvik
** Det bør være mulighet for sortering med høyest og lavest % avvik

Dette kan være til stor hjelp for å finne ut hvor en eventuell feil i innsendte måleverdier ligger

OBS: Daglige måleverdier liste har en historie. Må være obs på tabellene når en endrer. Ingvar/Frode har trolig info
EI-888ImprovementForbedre nøyaktigheten av kompletthet måleverdier (landingssida i portalen)3Analysis in progressPer i dag oppdateres telleren i brøken gjennom hele døgnet, mens nevneren oppdateres kun med status klokka 24:00. 

Gjennom døgnet endres målepunkter med virkning inkludert inneværende døgn, derfor vil teller og nevner ha forskjellig grunnlag - og målet for tallet er ikke 100 %. 

Det kunne vært en fordel å også oppdatere nevneren flere ganger i løpet av døgnet, men kjøretid per uttrekk gjør at det bør begrenses til en gang i timen (maksimalt). Det er likevel en betydelig forbedring fra hva man har i dag. 

Tallet benyttes når nettselskaper og systemleverandører vil ha et raskt overblikk over status. Dager hvor det er mange endringer gir brøken feil bilde. Ene eventuell endring må ta hensyn til at det i fremtiden vil være en blanding av målepunkt som rapporteres på 15- og 60-minutters intervaller.
EI-617ImprovementStatistikk fra månedsrapporten per markedsaktør4Analysis in progressEndringsønske hvor en markedsaktør skal kunne logge inn i Elhub Aktørportal og se relevant statistikk fra månedsrapporten for sin organisasjon. Eksisterende rapport for Markedsendringer er vanskelig å tolke riktig.
EI-825ImprovementFjerne paginering for målepunktsoversikten4Analysis in progressSøkesiden på målepunktsoversiden er ikke hensiktsmessig slik den er nå, og ifm endring i pagineringsoppgaven (EI-636) så ønsker vi å fjerne paginering på denne siden (MP-2.0.0). Vi ønsker også at man fjerner det initielle resultatet i det siden lastes, da det egentlig ikke har noen verdi.

Når analysen er gjort for denne siden, ser vi også for oss å kunne gjenbruke funnene siden Sluttbrukersøk.

Det er ikke nødvendig med exporteringsmuligheter - verken på målepunkts- eller sluttbrukersøkesiden da dette allerede er dekket i OBIEE.
EI-253ImprovementForbedre prosess for bytte av sluttbruker ID4Ready for planningEndre prosess for endring av sluttbruker ID, fremst for privatpersoner, slik at den ikke blir benyttet til å bytte kunde uhensiktsmessig. Gjelder både privatpersoner og bedrifter. Nåværende løsning kan bl.a. føre til at feil sluttbruker får tilgang til målepunktinformasjon. Vurdere ny BRS eller modifisering av eksisterende. En mulig løsning er at både gammel og ny sluttbruker ID må oppgis for å sikre at endring skjer for riktig sluttbruker.

Det har vært gjort flere operasjonelle tiltak på dette området så behov for endring i markedsprosessene må vurderes.
EI-695ImprovementStoppe mulighet for å endre organisasjonsnummer i BRS-NO-3014Ready for planningDet er ikke lov å endre organisasjonsnummer på sluttbrukere men det er fortsatt mulig å gjøre det gjennom BRS-NO-301. Det bør legges inn en valideringsregel for å stoppe dette.
EI-819ImprovementInkludere nabonettets utvekslingsmålepunkt i Daglig måleverdier (liste)4In implementationØnsker at utvekslingspunkt til nabonettet også er inkludert i Daglig måleverdier (liste).

Nå får de kun sine egne utvekslingspunkt.