Forbedringssaker i backlog

Sist oppdatert 2020-11-18 19:06

30 saker - sist oppdatert 18.11.2020


ElhubIDOppsummeringPrioritetStatusBeskrivelse
EI-308Utvide reverseringsprosesser for å håndtere de vanligste feilene som håndteres manuelt2Ready for workVurdere å utvide eksisterende BRS'er for å korrigere/reversere vanlige feil i kontrakter. Målet er å avhjelpe det som i dag gjøres manuelt.
EI-462Forbedre BRS-NO-601 basert på erfaringer siden Go Live3Ready for workDet har kommet opp flere forbedringsforslag relatert til BRS-NO-601 etter Go Live. En analyse bør gjøres for å se på alle forslag i sin helhet og for å finne de mest hensiktsmessige endringene.

Endringsønsker som er registrert:
# Mulighet for nettselskap til å initiere forespørsel til kraftleverandør
# Legg til informasjon om motpart i BRS-NO-601
# Mulighet for å svare flere ganger i en BRS-NO-601
# Mulighet for å koble BRS-NO-601 til flere målepunkter, eller til ingen målepunkt
EI-600Purringer på timesavregna målepunkter ved endring avregningsform3Ready for workVed opprettelse av nytt timesavregna målepunkt purres det ikke på timeverdier før første timeverdi er sendt inn. (Prinsippet er at man lar måleverdiinnsending definere oppstart, framfor innmeldt oppstart.)

Ved endring avregningsform til timesavregna, vil denne funksjonaliteten føre til at vi kan få hull i timeverdier, da det ikke purres fra første bruksdøgn målepunktet er timesavregna, selv om det har profilavregnede timeverdier fra før. 

Dette er uheldig, da vi ikke har noen mekanisme for å oppdage disse utover at kraftleverandør (først og fremst) melder inn manglende timeverdier til Elhub.

Foreslår at ved endring avregningsform, så settes channel milestone på 1.3-kanalen. Da vil det bli purringer, og hvis datoen for endring viser seg å ikke stemme, kan nettselskapet endre dette tilbake i tid.   

Nett skal enten sende inn måleverdier eller fikse tidspunkt for endring av avregningsform. Purringer kan bidra til at nett fikser det i begge tilfellet. 
EI-331Innføring av kryptering i supportkommunikasjon mellom Elhub og aktørene3Ready for workDagens epost-kommunikasjon mellom aktørene og Elhub er ikke kryptert. Innholdet i sakene kan inneholde personopplysninger og skal ikke komme på avveie. Vi ønsker å gjøre bruk av TLS obligatorisk i mailkommunikasjon mot Elhub. Ingen hadde innvendinger mot dette i BF 14.08.2019 og Elhub vil gå videre med dette.

 ** Innføring av en saksbehandlingsportal vil løse denne utfordringen og er veldig ønskelig.
EI-658Revidere retningslinjer for håndtering av dødsbo3Ready for workI 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-581Sende oppdaterte måleverdier for produksjon til NECS3Ready for workElhub sender produksjonsmåleverdier til NECS D+14, det vil si at sertifikatberettiget aktør er avhengig av at nettselskapet rapporterer korrekte produksjonsmåleverdier til Elhub innen D+13 for å få utstedt korrekt antall elsertifikater. Det er ikke alltid tilfellet at produksjonsmåleverdiene er korrekte innen D+13. Dette fanger Elhub opp i avviksoppgjøret, men oppdaterte måleverdier re-rapporteres ikke til NECS. Sertifikatberettiget aktør kan påklage volum rapportert til NECS direkte til NECS, men det mange mindre volum som ikke oppdages og dermed ikke påklages.

Endringen medfører at alle endringer i produksjonsmåleverdier som fanges opp i avviksoppgjøret i Elhub sendes til NECS.
EI-712Etablere mulighet for systemleverandørtesting i Exa23Ready for workFor å redusere kompleksitet og kostnader skal systemleverandørtesting kunne utføres i Exa2. I situasjoner der systemleverandører har behov for å teste mot miljøer som er på en nyere versjon enn Exa2, for eksempel ved innføring av 15 minutters avregning, etableres dedikerte testmiljøer for dette.

Systemleverandører vil få egne fiktive datasett i Exa2 som er isolert fra aktørenes datasett og det vil ikke være mulig å kjøre markedsprosesser på tvers av disse datasettene.
EI-730Forenkle tilgang til data for porteføljen for tjenesteleverandører3Ready for workFor noen tjenesteleverandører vil det være nyttig med ulike rapporter som gir oversikt over flere av eller alle sine kunder samtidig.

Hensikten er at tjenesteleverandøren ikke behøver å logge på Elhubportalen for hver enkelt av aktørene den selger tjenester til for å kontrollere ulike statuser.
EI-508Sammenligne aktuell kjøring med historisk gjennomsnitt for å finne avvik i balanseavregningen - endring i Daglige måleverdier liste3Ready for workNettselskapene 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-186Tillate innflytting av samme sluttbruker på utflyttingsdato3Ready for workDer er en del tilfeller der ute hvor sluttbruker blir feilaktig flyttet ut. Når ny kraftleverandør eller nettselskapet prøver å flytte inn sluttbruker på utflyttingsdato blir prosess avvist fordi sluttbruker allerede er registrert på målepunktet på den datoen. Det er designet slik fordi i dette tilfelle skal heller utflyttingen bli reversert. Det kan dog være vanskelig for ny kraftleverandør eller nettselskapet og få gammel kraftleverandør til å gjøre dette. Burde det heller vært mulig å kjøre BRS-NO-103 og 123 på utflyttingsdato med samme sluttbruker?
EI-370Utvide portalversjon av BRS-NO-303 med historikk3Ready for workSiden flere selskap ønsker å bruke porteføljesjekk for å - nettopp - sjekke porteføljen i Elhub mot egne data - er det viktig å få fram historikk og ikke bare vise aktuell versjon av kontrakt, sluttbruker, avregningsform o.a. når man spør etter sin portefølje.

Videre er det ofte en kombinasjon av disse elementene som ønskes historikk på, i da har vi enten grunndata målepunkt eller grunndata sluttbruker.

Vi må ha et tredje søk som viser kombinasjonen av målepunkt grunndata målepunkt, sluttbruker, og kontrakt, samt fra- og tildatoer i CET/CEST. Dette vil bistå til aktørene kan ta ut rapporter over de dataene de har lov å se og sammenstille meg egne systemer slik rapporten er tenkt i utgangspunktet.
EI-526Avviksoppgjørsida i portalen - konsistens mellom web-deler4Ready for workPå sida som viser avviksoppgjørdetaljer er det laget et avhukingsfelt "Vis alle" hvor man kan velge om man vil inkludere annulerte avviksoppgjør i visninga. 

Denne påvirker ikke den nederste grafen/tabellen, påvirker ikke valget denne, som gjør web-delen lite brukbar.

To muligheter: 
1) La avhukingsfeltet påvirke hele sida
2) Lage tilsvarende avhukingsfelt for den nederste grafen. (lurest)
EI-381Definere kjøreregler for hvordan kraftleverandør kan informere nettselskap om kontaktinformasjon for varsling gjennom Elhub4Ready for workKraftleverandø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-317Markedsmelding til tredjepart når tilgang trekkes tilbake4Ready for workTredjepartene savner en melding som sier når en tredjepartskontrakt er opphørt. De ønsker også årsak for opphør, som utflytting, oppsigelse av kontrakt.
EI-349Utvid BlockedForSwitching til å også stoppe innflytting4Ready for workDet er spesielle prosedyrer for å flytte inn ny sluttbruker på produksjonsmålepunkt, på samme måte som det er spesielle prosedyrer for å gjøre leverandørskifte. BlockedForSwitching burde dermed blokkere også for innflytting (BRS-NO-102, 103, 123). Behovet må analyseres nærmere.
EI-352Innfør validering av næringskode og forbrukskode4Ready for workElhub har ingen validering av næringskode og forbrukskode med unntak av maks lengde på 10 tegn. For å unngå problemer med statistikk og at kraftleverandør får ukjente koder bør Elhub validere at kodene som mottas er gyldige. Elhub kan enten innføre validering av næringskode og forbrukskode opp mot en liste med godkjente verdier, eller bare sjekke at format er korrekt. Det er uklart om dette er et omfattende problem. Saken må analyseres videre.
EI-232Ikke tillat nåværende kraftleverandør å kjøre BRS-NO-301 hvis der er registrert et fremtidig leverandørskifte4Ready for workEtter at kanselleringsfrist er passert for BRS-NO-101 registreres ny kraftleverandørs sluttbrukerinformasjon i Elhub. Etter dette tidspunktet bør nåværende kraftleverandør ikke lenger har mulighet å endre sluttbrukerinformasjonen siden det påvirker ny kraftleverandør. I dag kan de oppdatere sluttbrukerinformasjon helt frem til dato for leverandørskifte og dermed skrive over det ny kraftleverandør sendte inn i BRS-NO-101. Etter Go Live skapet dette en del problemer. Mange av de var sannsynligvis grunnet feil i markedets systemer. Behovet for denne endringen bør vurderes på nytt.
EI-302Løsning for å holde BRS-NO-611 tilgjengelig selv om Elhub er nede4Ready for workVi har fått kritikk fra markedsaktører for at BRS-NO-611 tjenesten tas ned for ofte i forbindelse med planlagt vedlikehold. Videre er det en risiko for at uventet stor bruk av 611, som det er vanskelig for oss å begrense, går ut over ytelsen for andre tjenester. 611-spørring bør i større grad være tilgjengelig selv om resten av Elhub er nede.
EI-205Mulighet for å endre sluttbrukers organisasjonsnummer gjennom markedsprosess4Ready for workPer nå er det mulig å endre sluttbrukers organisasjonsnummer i BRS-NO-301 men nettselskapene klarer ikke alltid å håndtere dette i sine systemer. Grunnet dette har vi kommunisert til markedet at det ikke er lov. Bør BRSene tilpasses for å tillate endring av sluttbrukers organisasjonsnummer? Hvis ikke bør det blokkeres i BRS-NO-301.
EI-698Laste ned måleverdier for målepunkt lengre enn én måned av gangen og samtidig velge versjon4Ready for workHvis vi eller aktører skal laste ned måleverdier for et målepunkt fra portalen kan det kun lastes ned én måned av gangen. 

Ønsker mulighet for å velge perioden som skal lastes ned.

Ønsker også å velge om alle versjoner av måleverdiene skal med eller om kun de gjeldene måleverdiene skal bli med. 

Boks for å velge de to alternativene nevnt over.

Ønsker gjelder for både portal og Plug-In.
EI-683Superbrukere mottar svært mange epost når brukerroller er i ferd med å utløpe4Ready for workEn superbruker mottar i dag en epost per bruker per brukerrolle når brukerens roller nærmer seg utløp. For en superbruker som har mange brukere i ulike roller i mange organisasjoner, som eksempelvis hos tjenestetilbyderne, så kan rekken med eposter blir svært overveldende. Dette fyller unødig opp innboksen og kan medføre at superbrukeren ikke rekker oppfatte alle utgående brukere.

Vi foreslår nå en forenkling, for eksempel ved at man sender epost for flere brukere og brukerroller i flere organisasjoner i en samlet bulk-epost. Dette forutsetter samtidig at man øker perioden man ser på for å kunne slå sammen til en epost.

Utformingen må vi bli enige om og på hvilket oppdelingsnivå som er hensiktsmessig.
EI-668Flerselskapoversikt i portalen for tjenestetilbydere på vegne av netteier4Ready for workSom tjenestetilbyder med forretningsrollen DDE ønsker man at man har muligheten til å se alle nettselskap jeg utfører tjenester på vegne av når man logger inn i portalen. På denne måten slipper man å logge inn og ut for å få hele oversikten. Noen av tjenestetilbyderne det dreier seg om har inntil 40 nettselskap de skal overvåke og tilsvarende antall endringer innlogginger for å se hvert selskap.
EI-653Send de riktige målingsoppsettene også på ikke-avregnede VMPer4Ready for workFlagget "Send to market party" på målingsoppsettet endres ikke for ikke avregnede VMPer. Det betyr at aktørene (bare DDM i dagens løsning) ikke får måleverdier ut fra beregningen. Det er få av disse VMPene i dag.

Midlertidig workaround er for aktør å hente måleverdiene i Elhub aktørportal.
EI-369Forbedre informasjonen på fakturaen fra avviksoppgjøret4Ready for work

Vi har fått inn en del ønsker på å forbedre fakturaen som kommer fra avviksoppgjøret. Mer informasjon gjør fakturaen lettere å behandle for aktøren.


Forslag:
* Periode fakturaen gjelder for
* Rolle, BSL/SLR
* Skille mellom ATAM produksjon og ATAM forbruk

EI-771Endre VMP delt produksjon til å ikke oppdatere Anleggsbeskrivelse-feltet4Ready for workEtter at Elhub nå sender aggregert produksjon til eSett er det ikke lengre nødvendig å bruke dette feltet. Slik det er nå, så overskriver Elhub navnet nettselskapet har lagt inn.
EI-787Vise årstall i fane for periodevolum4Ready for workDersom det et målepunkt med et periodevolum som er lengre enn ett år, vil en i Måleverdier > Periodevolum ha problem med å se når starttidspunktet til periodevolumet er siden årstall ikke vises. Det gjør at en ikke ser om det er et stort hull eller om det er et periodevolum som dekker et langt tidsintervall.

Foreslått fiks: Legge til år i datofeltet
EI-470Forbedre kapasitet på meldingsmottak i Elhub4Ready for workMed 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-379Forbedret feilkode for ExtendedStorageMeteringValues i BRS-NO-6225Ready for workI Prosesspesifikke meldingsvalideringer finnes følgende validering:
|ExtendedStorageMeteringValues skal ikke være oppgitt i melding hvis UpdateIndicator = Delete|EH032|

Denne feilkoden tilsier at dato er feil, noe som er misvisende. Dette bør endres. Kanskje trengs en ny feilkode.
EI-176Legge til sorteringsmuligheter på måleverdier under Søk etter volum5Ready for workElhub sorterer måleverdier i tabeller motsatt vei av det som er vanlig i markedet. Om brukeren selv kunne velge hvilken vei døgnet sorteres kan det i noen tilfeller øke lesbarheten under "Søk etter volum".

EI-481Utvikle en webservice som kommuniserer nedetid i Elhub5Ready for workDet er ønske om mulighet for å hente informasjon om Elhubs tilstand i strukturert form over et teknisk grensesnitt. Dette vil gjøre det mulig for markedsaktørene og styre meldingsinnsending utfra om Elhub er oppe eller nede. Grensesnittet kunne også kommuniser planer for nedetid, men det kan være tilstrekkelig at dette kommuniseres ustrukturert gjennom eksisterende kanaler.