> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/reporting-embedded-power-bi.md).
# Rapportering (innebygd Power BI)
## Rapportering (innebygd Power BI)
Den **Rapportering** modulen i CERRIX viser Power BI-rapporter innebygd direkte i applikasjonen. Disse standardrapportene — som Kontroll & Risiko-rapporten — kombinerer data fra CERRIX-miljøet ditt til interaktive visualiseringer med tellere, tabeller og filtre, slik at du kan presentere statusen for ditt Risiko- og Kontrollrammeverk uten å forlate CERRIX.
### Tilgjengelighet og lisensiering
Den innebygde Reporting-modulen er en **separat kjøpt tjeneste** og er ikke en del av standardpakken til CERRIX. Dette har en direkte, synlig konsekvens i applikasjonen:
* Hvis modulen ikke er en del av kontrakten din, er Reports-siden enten tom eller viser meldingen **"forbudt å utføre handling"** — for hver bruker, uavhengig av rolle.
* Ingen rolle eller rollegruppe i CERRIX kan gi tilgang til Reporting-modulen. Hvis du ser denne meldingen for alle roller, er det ikke et problem med rettighetskonfigurasjonen; modulen er ganske enkelt ikke aktivert for ditt miljø.
Grunnen til at modulen er deaktivert som standard, er at de innebygde rapportene er **ikke generiske**. Hver rapport er spesifikt konfigurert for databasen og datamodellen til din Organisasjon for å vise meningsfulle resultater. Uten den konfigurasjonen ville modulen ikke vise noen data og bare skape forvirring for sluttbrukerne.
{% hint style="info" %}
Ser du "forbudt å utføre handling" på Reports-siden? Sjekk med din interne CERRIX-administrator om Reporting-modulen er en del av kontrakten din før du feilsøker roller og rettigheter.
{% endhint %}
### Hvem bygger og vedlikeholder rapportene
Innebygde Power BI-rapporter er **bygget og vedlikeholdt utelukkende av CERRIX-konsulenter**. Det er for øyeblikket ikke mulig for dine egne dataingeniører eller rapportbyggere å opprette eller redigere rapporter i den innebygde Reporting-modulen — alle rapportforespørsler håndteres av CERRIX som en tjenesteforespørsel.
Dette gjelder også endringer i eksisterende rapporter, for eksempel:
* Å legge nylig opprettede Kontroll-elementer eller Organisasjon-strukturer til en rapports omfang.
* Å legge til en ekstra tabell eller en bryter i en rapport for å vise flere data.
Rapportendringer kan først publiseres til akseptansesmiljøet ditt (ACC), slik at du kan gjennomgå dem før de tas i bruk i produksjon (PRD). Hver standardrapport innebærer en engangskonfigurasjon og løpende vedlikehold for å holde den i takt med fremtidige CERRIX-utgivelser; dette er fakturerbart konsulentarbeid.
Hvis du foretrekker å bygge og vedlikeholde rapporter selv, bruk **CERRIX API-er** for å hente ut dataene dine til ditt eget BI-verktøy eller datalager. Se Hvordan CERRIX API-er passer inn i GRC-arkitekturen din for den tilnærmingen.
### Slik aktiverer du modulen
For å aktivere Reporting-modulen, kontakt din **CERRIX Customer Success Manager**. Sammen finner dere ut hvilke standardrapporter du trenger, og om de først skal aktiveres i akseptansesmiljøet ditt eller direkte i produksjon. Customer Success Manageren din kan informere deg om de gjeldende tjeneste- og vedlikeholdsbetingelsene.
### Hvilke data standardrapportene bruker
Den standard **Kontroll & Risiko-rapporten** er bygget på forholdet **Risiko → tilknyttede Kontroller**. Dette har en viktig konsekvens for det du ser:
* **Bare Kontroller som er koblet til minst én Risiko vises i rapporten.** Kontroller uten en koblet Risiko utelates fra datasettet, så antallet Kontroller i rapporten kan være lavere enn antallet du ser i Controls-modulen med det samme filteret.
* Hvis du legger til nye Kontroller i rammeverket ditt, vises de i rapporten når de er koblet til en Risiko.
Hvis du vil ha innsikt i Kontroller (eller Risikoer) som ikke har noen kobling, kan en CERRIX-konsulent utvide rapporten din — for eksempel med en ekstra tabell eller en bryter som viser de ukoblede elementene.
### Filtrering av rapportene
De innebygde rapportene inkluderer filtre som **organisasjon**, **Forretningsdimensjon**, **Rammeverksdimensjon**, og **år**, med tellere som viser hvor mange elementer som samsvarer med det gjeldende valget.
Fordi rapportdatasettet er risikobasert, kan filtre evaluere den tilknyttede Risikoen i stedet for bare selve Kontrollen. Hvis et filtrert antall i en rapport avviker fra det samme filteret i en Workspace for modulen, er dette dataspekteret vanligvis forklaringen. Rapportene konfigureres per miljø, så hvis et antall fortsatt ser feil ut etter å ha tatt hensyn til omfanget, kontakt CERRIX-support.
### Hvordan Periode-scorene beregnes
Standardrapportene tildeler resultater fra kontrolltesting til Perioder (for eksempel kvartaler) basert på **datoen for testgjennomføringen** — datoen testen faktisk ble utført, ikke perioden Testplanen var planlagt for. Dette forklarer to situasjoner som ofte forveksles med rapportfeil:
* **En test som utføres sent, gir poeng i en annen Periode enn planlagt.** Hvis for eksempel alle testene fra en Testplan for 2024 utføres i april 2025, får Kontrollen grønt i Q2 2025 — ikke i kvartalene i 2024 som de var planlagt for.
* **En Kontroll kan vises som grønn for en Periode mens andre tester fortsatt er åpne.** Periodescoren gjenspeiler testene som ble utført i den Perioden; åpne tester fra andre Testplan-perioder endrer den ikke.
Skjermbildene i Controls-modulen grupperer resultater etter testplanperiode, og derfor kan rapporten og modulen legitimt vise forskjellige farger for samme Kontroll og kvartal.
{% hint style="info" %}
Hvis en score i en innebygd rapport fortsatt virker inkonsistent med testresultatene dine etter at du har sjekket gjennomføringsdatoene, kontakt CERRIX-support og oppgi Kontroll-Identifieren og den aktuelle Perioden.
{% endhint %}
### Holde rapportene oppdaterte
Innebygde rapporter holder seg oppdaterte ved å lese CERRIX-dataene dine gjennom API-et. To vedlikeholdspunkter sørger for at dette fungerer smidig.
#### Forny rapportens API-legitimasjon årlig
Hver innebygd rapport kobler seg til miljøet ditt med API-legitimasjon som er **gyldig i ett år**. Når legitimasjonen utløper, fortsetter rapporten å vise dataene den sist hentet, men slutter å plukke opp nye resultater — et typisk symptom er en graf som ikke lenger oppdateres når tester eller Kontroller som er fullført i et nytt år, legges til.
Hvis rapporten din har sluttet å vise nylige data, kontakt CERRIX-support via servicedesken: når du fornyer API-legitimasjonen på rapporten, gjenopprettes oppdateringen. Siden ettårsgyldigheten er forutsigbar, lønner det seg å planlegge et årlig fornyelsestidspunkt — for eksempel ved starten av rapporteringsåret ditt.
#### Overgang til en ny testperiode
Rapporter som viser kontrolltesting per Periode kan konfigureres til å **bytte til den gjeldende Perioden automatisk**, basert på dagens dato og startdatoene for testperiodene dine. Del startdatoene for testperiodene dine med CERRIX, så kan en konsulent sette dette opp for rapporten din; rapporten filtrerer deretter til Testplanene for den pågående Perioden uten at du trenger å gjøre noe ved hvert periodeskifte.
Mens den automatiske periodinnstillingen konfigureres, kan du justere filtrene i rapportens filterrute manuelt for å vise den gjeldende Perioden.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/module-overview/reporting-embedded-power-bi.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
