Danske Fjernvarmeforsyningers EDB- Selskab a.m.b.a. CVR-nr.:

Transkript

1 Erklæring fra uafhængig revisor Erklæringsafgivelse i forbindelse med kontrollers udformning og implementering i relation til aftalte arbejdshandlinger for Finans- og Forbrugersystemet FOF pr. 23. juni 2016 ISAE 3000 DK Danske Fjernvarmeforsyningers EDB- Selskab a.m.b.a. CVR-nr.: Juni 2016 REVI-IT A/S statsautoriseret revisionsaktieselskab Jens Kofods Gade København K Tlf info@revi-it.dk revi-it.dk CVR-nr

2 Indholdsfortegnelse Afsnit 1: Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s ledelseserklæring... 1 Afsnit 2: Afsnit 3: Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s beskrivelse af de implementerede kontroller i relation til Finans- og Forbrugersystemet FOF... 2 Uafhængig revisors erklæring om beskrivelsen af kontroller, deres udformning og funktionalitet REVI-IT A/S

3 Afsnit 1: Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s ledelseserklæring Denne erklæring vedrører de kontroller, som vi har udformet og implementeret i Finans- og Forbrugssystemet FOF. Kontrollerne er nærmere beskrevet i det efterfølgende afsnit. Pr. dags dato bekræfter vi, at vi, efter vores opfattelse, pr. 23. juni 2016 i al væsentlighed har overholdt ovennævnte kriterier. Vi bekræfter herudover, at revisor har haft adgang til al information og materiale, som har været nødvendig for erklæringsafgivelsen. På den baggrund er det vores vurdering, at vi, i al væsentlighed, har udført en hensigtsmæssig drift og administration af Finans- og Forbrugssystemet FOF baseret på førnævnte kriterier. Kolding, 23. juni 2016 Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a. REVI-IT A/S Side 1 af 13

4 Afsnit 2: Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s beskrivelse af de implementerede kontroller i relation til Finans- og Forbrugersystemet FOF Formål Hensigten med denne kontrolbeskrivelse er at tilkendegive over for alle, som har en relation til DFF EDB, at anvendelse af informationer og informationssystemer er underkastet standarder og retningslinjer. DFF EDB ønsker at opretholde og løbende udbygge et IT-sikkerhedsniveau på højde med de krav, som skitseres i ISO Kravene skærpes på veldefinerede områder, hvor der er specielle lovkrav, aftaleretslige forhold eller evt. særlig risiko (afdækket ved en risikovurdering). Fastholdelse og udbygning af et højt sikkerhedsniveau er en væsentlig forudsætning for, at DFF EDB fremstår troværdigt. For at fastholde DFF EDB troværdighed skal det sikres, at information behandles med fornøden fortrolighed, og at der sker fuldstændig, nøjagtig og rettidig behandling af godkendte transaktioner. IT-systemer og data betragtes, næst efter medarbejderne, som DFF EDB mest kritiske ressource. Der lægges derfor vægt på driftsikkerhed, sikkerhed, høj kvalitet, overholdelse af lovgivningskrav og på at systemerne er brugervenlige, dvs. uden unødigt besværlige sikkerhedsforanstaltninger. Der skal skabes et effektivt værn mod IT-sikkerhedsmæssige trusler, således at DFF EDB image og medarbejdernes tryghed og arbejdsvilkår sikres bedst muligt. Alle personer betragtes som værende mulig årsag til brud på sikkerheden; dvs. at ingen persongruppe skal være hævet over sikkerhedsbestemmelserne. På de efterfølgende sider behandles de enkelte punkter i ISO Bemærk, at dokumentation i ISO starter med punkt 4, da punkt 1 til 3 er indledende bemærkninger. REVI-IT A/S Side 2 af 13

5 4 - Risikovurdering og -håndtering DFF EDB har en procedure for løbende risikovurderinger udviklingen og vedligeholdelsen af FOF. Dermed kan DFF EDB sikre, at de risici, som er forbundet med udvikling og vedligeholdelsen af FOF, er minimeret til et acceptabelt niveau. Risikovurdering opdateres årligt i april måned, samt når der foretages større ændringer i udviklingen eller vedligeholdelsen, som vurderes relevante til at revurdere den generelle risikovurdering. Alle risici bliver inddelt i kategorierne Grøn, Gul og Rød. Alle Gul og Rød risici bliver behandlet af den samlede ledergruppe i DFF EDB. Udviklingschefen har det overordnede ansvar for implementering af korrigerende handlinger for at minimere de identificerede risici. 5 - Sikkerhedspolitik IT-Sikkerhedspolitikken gennemgås en gang årligt i april måned. Denne gennemgang ligger som en fast opgave i Outlook hos udviklingschefen. 6 - Organisering af informationssikkerhed Det er kun ansatte i udviklingsafdelingen, der har adgang til vores kildekode i Subversion. Opsætning og administration af test maskiner, build-servere administreres ligeledes af udviklingsafdelingen. Den enkelte udvikler har ikke direkte adgang til produktionsserverne, fra en udvikler PC. Er det nødvendigt at tilgå værkernes data, for at yde support eller fejlfinde. Sker dette igennem Citrix, hvor der er sporbarhed af hvem der logger på. Det bevirker også, at der ikke ved et uheld kommer til at ændres i produktionsdata, fra en udvikler PC. Da DFF EDB ikke er omfattet af Persondataloven eller reglerne hos BFIH, er der ikke yderlig intern sikring af data. Mod eksterne kilder er data afskærmet, sådan kunder kun kan få adgang til egne data. Denne sikring sker ved brugernavn og password til alle kundedata. Al adgang til data sker desuden via en SSL eller VPN forbindelse. 8 - Styring af aktiver Alla data i Hosting-miljøet er klassificeret som fortrolige kundedata. Alle medier indeholdende kundedata, skal behandles med største omhu. Det bliver registreret, hvilket databærende udstyr en medarbejder får udleveret, og ved ophør af ansættelsesforholdet bliver alt udstyr inddraget. Ligesom med systemdata, opererer DFF EDB med systemejere, der er ansvarlig for forskellige aktiver. Herigennem sikrer vi individuel fokus på sikkerheden i alle delelementer. Al kildekode og programmer, der udvikles, ejes af DFF EDB, og må ikke kopiers eller sælges til 3. part. 9 Adgangskontrol Det er kun Teknisk Afdeling i DFF EDB, der har adgang til at oprette nye brugere og alle medarbejderne her er instrueret i håndtering af kunder brugernavn og kodeord. Det er kun Teknisk Afdeling i DFF EDB, der har adgang til at oprette nye brugere og roller i databaserne, samt ændre passwords. REVI-IT A/S Side 3 af 13

6 Oprettelse og lukning af brugere sker udelukkende via skriftlig henvendelse, og efter at identitet er blevet bekræftet. Alle brugere oprettes med et stærkt kodeord, der skal skiftes hver 3. måned. Der er yderligere sikring af kunders data, ved at en konto automatisk bliver spærret ved tre på hinanden følgende fejl i indtastning af kodeord. Dette er for at forhindrer, at man kan sidde og gætte sig frem til et kodeord. Der er også sat flere interne kontroller op til at registrere eventuelt misbrug af rettigheder i Hosting miljøet. Bemærk at DFF EDB af support årsager har rettigheder til at logge på alle systemer. Det er ikke muligt for kunderne selv at lave ændringer i Hosting. Det er kun udviklingsafdelingen, der har adgang til at oprette brugere i Subversion Kryptografi Al adgang til Hosting miljøet sker via en SSL eller VPN forbindelse. DFF EDB anvender et SHA-256 krypteret system til opbevaring af administrative kodeord Change management Beskriver forløbet fra et ønske til opgave, godkendelse, udvikling og idriftsættelse, med de steps og personer der er involveret i processen. Der benyttes en pragmatisk tilgang i virksomheden ifm. produktudviklingen, derfor er visse processer illustreret som flere steps, men foregår på ét møde hvor der træffes de nødvendige beslutninger. Bl.a. sker step 5-7 på samme prioriteringsmøde, dette møde foregår hver 14. dag, og et møde bestående af folk fra både forretnings- og udviklingssiden, med de fornødne beslutningskompetencer og tekniske viden. Change management for FOF hos DFF-EDB Support Bruger 1. Forretningsønske 2. Opretter opgave Nej Tilfreds bruger Ja 11. Opgaven godkendes Udvikling Nej Afvist 9. Udvikler opgaven 10. Opgaven testes Produkt ansvarlig 3. Gennemgår opgaven og beskrivelse 4. Opgave klar 7. Godkend/afvis Godkendt 8. Prioritere hvornår opgaven kan udvikles Ja Prioriteringsgruppen 5. Vurderer opgaven 6. Anbefaler opgaven REVI-IT A/S Side 4 af 13

7 1. Der opstår et ønske, om en ændring eller forbedring til FOF fra vores bruger eller support afdelingen. Ønskes overdrages til en person i support afdelingen, enten på mail, telefon eller ved personlig henvendelse. 2. Opgaven oprettes i YouTrack, der er DFF-EDB opgavestyringssystem, hvori alle ønsker og forbedringer til FOF bliver registreret. Normalt vil det være en person i support afdelingen, der opretter opgaven heri, dog kan en bruger også selv oprette et ønske direkte i YouTrack. Det kræver dog, at værket er oprettet som bruger i YouTrack. Der benyttes rettighedsstyring i YouTrack, således eksterne bruger kun kan oprette opgaver og se status på dem, men ikke ændringer i prioritet eller status på en allerede oprettet opgave. 3. Den produktansvarlige på FOF, her Peter A. Carstensen (PAC), gennemgår jævnligt indkomne ønsker i YouTrack. Er ønsket beskreven i manglende kvalitet sendes ønsket tilbage til opgave stilleren, for yderligere information. Her sørges der for at ønskes er i tilstrækkelige kvalitet til at diskutere, på et prioriteringsmøde. 4. Klargjorde ønsker bliver medtaget til kommende prioriteringsmøde. Ved manglende beskrivelse eller forståelse af opgaven sendes opgaven tilbage til opgavestiller/ejer, for yderligere information. 5. Hver 14. dag, afholdes et prioriteringsmøde. På mødet deltager den produkt ansvarlige, samt 2-4 forretningserfarne personer. Derudover deltager mindst en person fra udviklingsafdelingen, der har den fornødne viden og beslutningskompetence i forhold til de pågældende opgaver der skal diskuteres. På mødet diskuteres den forretningsmæssige værdi af opgaven, og hvad den berør af områder, hvordan den evt. skal udvikles. Ligeledes vendes om det er en opgave, som alle vores brugere vil få gavn af, eller det kun giver værdi et enkelt værk. Dette gøres fordi der kun udvikles løsninger der er til gavn for hele fællesskabet og ikke kun giver værdi for et enkelt værk, derfor laves der heller ikke specialløsninger i FOF. Den tekniske person der er med til prioriteringsmødet, giver et estimat på opgaven. Inden mødet har den tekniske person, der deltager på møde, vendt løsningen og estimatet med andre i udviklingsafdelingen. Dette møde afholdes typisk hver 14. dag, og gennemgår alle indkomne opgaver i siden sidste møde. 6. Her bliver det vurderet af support gruppen, og PAC i sidste ende der har den endelige beslutningskompetence, om opgaven skal løses eller ej. Dette afhænger af værdien af opgaven, hvor lang tid det tager at løse opgaven samt hvor mange værker der vil have glæde af løsningen. 7. Bliver opgaven godkendt, til at skulle udvikles, sættes typen til fejl/forbedring og tilstanden til åben i YouTrack. Prioritet sættes til 1-3, afhængig af hvornår opgaven ønskes løst. Bliver opgaven afvist, sættes type til ide eller afvist afhængig af begrundelse. Der kommer samtidig en begrundelse for beslutningen. 8. Alle godkendte opgaver ligger prioriteret i YouTrack, klar til udvikling. Udviklingsafdelingen udvikler opgaverne ud fra højest prioritet. Hver torsdag morgen, gennemgår og koordiner udviklingsteamet på en agil projekt tavle, de igangværende opgaver og projekter, samt koordinere kommende release af FOF og øvrige opviklingsopgaver. Dette gør hele udviklingsafdelingen er informeret omkring hvad der sker, og alle kan bidrage med viden og input. 9. Opgaven udvikles i udviklingsafdelingen, i henhold til aftalte udviklingsprocesser omkring kvalitetssikring og versionsstyring i et repository. Der benyttes en pragmatisk og agil tilgang til udviklingsprocessen, hvor der registres timer på udviklingsopgaven. Denne proces, er beskreven under udviklingspipeline afsnittet. 10. Den pågældende udvikler der påtager sig udviklingsopgaven, går ind i YouTrack og sætter sit navn på opgaven og sætter opgaven til under udvikling. Når opgaven er færdigudviklet sættes opgaven i YouTrack til klar til test. 11. Test afdelingen bestående af Lars Lilleør (LL) og Kasper Kastaniegaard (KAK), kigger løbende i YouTrack på opgaver der ligger klar til test. Disse gennemtestes både manuel og automatisk. Bliver opgaven godkendt, sættes status til færdigtestet, skal opgaven tilbage til udvikling igen, sættes status i YouTrack til Åben igen, med en beskrivelse af, hvorfor opgaven ikke blev godkendt i test. 12. Færdig testet opgaver bliver godkendt af opgave stilleren, og bliver kommunikeret tilbage til brugerne når, den endelige løsning er rullet ud og i drift. Se i afsnittet omkring udviklingspipeline, hvordan det tekniske forløb er. REVI-IT A/S Side 5 af 13

8 Rollback/Kritiske fejl Skulle det ske der bliver deployet en FOF udgave indeholdende en kritisk fejl, rettes den straks og en ny udgave sendes ud til brugerne hurtigst muligt. Der bliver meget sjælden lavet DB ændringer, der ikke er bagud kompatibel. Grundet dette, vil der heller ikke være brug for en rollback, med at rette databaseændringer tilbage. Afhængig af fejlens størrelse og tid det tager at løses den, bliver enten seneste udgave rullet ud til brugerne igen. Er det en mindre fejl der hurtigt kan løses, rettes den og der bygges en ny FOF udgave og rulles ud til brugerne. Alle fejl, også kritiske fejl, oprettes altid i YouTrack, og der benyttes samme proces til test og godkendelse til at deploye FOF med. Udviklings pipeline Beskriver hvilke steps udviklingsprocessen består af, samt hvem gør hvilke aktiviteter og hvad der sker undervejs. FOF udviklingspipeline 1 3 Checkout 4 5 SVN Checkout 2 Commit SVN Kode ændringer Udviklere Tester (KAK/LL) TestComplete Færdig test Kode Commites Udruller FOF Bygger exekverbar fil SVN CAH CAH 1. Subversion (SVN) benyttes som repository for alt kildekode der udvikles i afdelingen. SVN virker både som, version styring, historik og beskrivelse af de ændringer der sker med kodebasen. Det er kun udvikler i DFF-EDB der har adgang til SVN. Der bliver benyttet en trunk tilgang til at kørende kildekode, hvor tag af HEAD revision ifm. med en release, benyttes. Mere herom senere. I fremtiden ønsker der at kigge på en mere release baserede approach, i brugen af et repository fremover. 2. Før en udvikler, starter på en udviklingsopgave i YouTrack, tjekkes den nyeste kode ud fra SVN. Herefter sætter udvikleren opgaven i YouTrack til under udvikling, og færdigudvikler opgaven. Er der brug for mere viden omkring opgaven, tages den med opgavestillen/ejer. Når opgaven er færdig udviklet, sættes opgaven i YouTrack, klar til test. REVI-IT A/S Side 6 af 13

9 3. Herefter committes kodeændringer til SVN, der benyttes en template til beskrivelse af de ændringer der er blevet foretaget. Dette er for at sikre sporbarhed, omkring hvad der er sket af ændringer i kodebasen, samt hvem har ændret det, og hvilken betydning har det. Følgende skal beskrives ved et commit: a. Der skal være et YouTrackId på den opgave/fejl der er blevet udviklet b. Det skal fremgå hvem udvikleren er c. Der skal være en teknisk beskrivelse af ændringen d. Der skal være en kundevendt beskrivelse, denne beskrivelse vises i FOF til vores brugere e. Ved et commit giver SVN selv et unikid, på det repository som kildekoden tilhører 4. I Youtrack fremgår de opgaver, der ligger klar til test. KK/LL følger løbende op på disse opgaver og tjekker den pågældende kode ud, dette ud fra revisionsnummer og YouTrackId. Der bliver herefter lavet et ny build, på baggrund af seneste checkout fra SVN, denne build proces foregår på en udvikler maskine og skaber en eksekverbar fil. Denne fil afvikles på en test maskine, og giver en kørende version af FOF. Nu testes manuelt de opgaver/fejl der ligger i YouTrack og som er klar til test. Her kan ske to ting, forløber den manuelle test ok, sættes opgaven i YouTrack til færdig testet. Giver testen en fejl, sættes opgaven i YouTrack klar til udvikling, med en kommentar omkring problemet og en begrundelse herom. 5. Alle automatiske test, afvikles igennem TestComplete. Se gennemgang i kontrolbeskrivelse af TestComplete Er alle automatiske test positive, committes koden til SVN, der bliver ikke lavet en release af FOF, før alle automatiske test er kørt succesful igennem. Herefter bliver der lavet et tag i SVN, med næste release nr. i rækken. 6. Der bliver bygget en deploybar exe fil. Et batchjob bygger denne fil, ud fra Head revision nr. på release branchen. Batch jobbet bliver startet af Christer A. Have (CAH), og kan modtage forskellige parameter afhængig af behov. Under denne bygge proces, bliver kundehenvendte kommentar i SVN trukket ud i TXT filer, og gjort synlig i FOF. Således bruger af FOF, kan se hvad der er sket af ændringer, i den pågældende version af FOF. Ligeledes bliver FOF også tagget, med release nr. fra SVN, således der er sammenhæng imellem release version af FOF og SVN branchen. Det giver en sporbarhed i forbindelse med fejlretninger og videreudvikling. 7. Den færdige eksekverbare fil, bliver sent til Blæksprutten og service programmet. Herfra bliver den rullet ud på Citrix miljø, af DFF-EDB interne teknikker. Dette sker den pågældende aften efter kl , således vi er sikre på brugere af FOF ikke bliver logget ud. De værker der selv hoster deres egen version af FOF, får besked omkring der er kommet en ny version af FOF igennem service programmet, og kan hente den i service programmet, og selv installere den nye FOF udgave i deres eget miljø. Diagrammet viser hvorledes FOF bliver udrullet. REVI-IT A/S Side 7 af 13

10 TestComplete Udgangspunktet for test og kvalitetssikring i DFF-EDB er at alle moduler, forbedringer og fejl, som bliver udviklet også bliver testet enten manuelt eller via automatiske tests inden de bliver committed og frigivet til en ny release af Finans- & Forbrugersystemet (FOF). Vi anvender TestComplete til udvikling af vores automatiserede tests. De automatiserede tests udvikles og renoveres løbende i TestComplete. TestComplete kører hver nat en automatisk test på den version af FOF, som ligger i trunk i subversion. Er der fejl i de afviklede tests, undersøger Kasper Kastaniegaard (KAK) årsagen og tager fat i den rette udvikler for at finde en løsning. Alt efter årsagens betydning for FOF kan løsningen enten være at tilrette kode til FOF eller tilrette kode til TestComplete pga. implementering af ny funktionalitet. Der udgives ikke en release af FOF før der er fundet en løsning på fejlen i fejlloggen. Loggen af den automatiserede test kan ses her: Testresultat Proceduren er følgende inden frigivelse til en ny release af FOF: I. En udvikler giver KAK besked om at teste til en bestemt revision af FOF II. KAK kører en automatisk test på ovenstående revision af FOF, som tages fra trunk. III. KAK giver Lars Lilleør (LL) en status på testresultatet samt en årsag til evt. fejl i fejlloggen IV. LL og KAK vurderer fejlen(e)s betydning for FOF. V. Løsningen kan enten være at tilrette kode til FOF eller tilrette kode til TestComplete pga. implementering af ny funktionalitet VI. Ved fejl tilrettes kode i FOF/TestComplete og punkt II - VI gentages indtil den automatiserede test viser grønt. Der er udarbejdet dokumentation til betjening og kørsel af automatiserede tests, så øvrige i udviklingsafdeling også kan køre proceduren ved ferie eller sygdom. Beskrivelsen er i YouTrack REVI-IT A/S Side 8 af 13

11 Vi anvender YouTrack (YT) til dokumentation af vores testcases til FOF. I nedenstående kontrolbeskrivelser vil der være henvisning til YT for en mere detaljeret beskrivelse af de enkelte testcases. Typen markeret med Testcase i YT beskriver de automatiserede testcases der er implementeret for at teste FOF. Der er implementeret en række testcases i TestComplete for at lave regressionstest i forbindelse med videreudvikling af FOF, såvel moduler som forbedringer, for at sikre at den eksisterende funktionalitet bibeholdes. Andre issues beskriver de konkrete testcases, hvad der testes og hvilke subrutiner der er implementeret. Testruns er i høj grad struktureret så de kan køres individuelt for at teste enkelte funktionalitet(er). I TestComplete implementeringen er testruns struktureret i samme projekt, men i individuelle undermapper, navngivet med deres testrun navn. I hvert testrun issue er det ligeledes også beskrevet hvilke features der ikke er testet, og hvilke åbne spørgsmål der måtte være. Målet for denne række testruns er at der trinvis implementeres automatiserede test af FOF. De forskellige dele af FOF bliver prioriteret med henblik på at få implementeret automatiseret test ved de mest kritiske testcases først. De implementerede testcases kan bruges til regressionstest, for at sikre sig at funktionaliteten ikke ændrer sig ved ny implementering og fejlrettelser. TestComplete afvikler følgende Test runs af FOF: A1 Opsætning og Login FOF-1425 A2 Login procedure FOF-1427 A3 Adgang til hovedkartotekerne FOF-1428 A4 Finanskladde FOF-1430 A5 Acontokladde FOF-1434 A6 Flytteprocedure FOF-1437 A7 Betalingsfil til NETS FOF-1450 A8 OIOUBL og OIOXML til Nemhandel FOF-1453 A9 Fakturaflow FOF-1457 B10 Tilbudskladde FOF-1441 B12 Restancekladde FOF-1619 Tests skrevet med FED er beskrevet efterfølgende, da de indeholder bogføring og input/output i FOF. A4: Finanskladde Denne testkørsel gennemgår Finanskladden og sørger for at alle controls er på formen og at funktionaliteten er bibeholdt i forhold til tidligere versioner, ved forskellige linjetyper. Ligeledes går den igennem menuen Funktioner og afprøver de forskellige muligheder. Igennem disse testcases bliver der lavet flere gennemløb af funktionen Finansbogføring (Stored Procedure), der til sammen bredt dækker denne/disse funktioner. På issue FOF-1430 er vedhæftet det input som indtastes i finanskladden. Ved bogføring bliver der testet om det falder korrekt på plads i de respektive tabeller i FOF. REVI-IT A/S Side 9 af 13

12 A5: Acontokladde Dette testrun gennemgår funktionaliteten af Acontokladden. Herunder bogføring på forskellige forbrugere med forskellig art og med forskellige finansgrupper. Arterne indeholder både betalinger og påligninger. Et bredt udsnit af arterne er taget med. På issue FOF-1434 er vedhæftet det input som indlæses i acontokladden. Ved bogføring bliver der testet om det falder korrekt på plads i de respektive tabeller i FOF. A6: Flytteprocedure Dette testrun har til opgave at gennemløbe Flyttewizarden med udgangspunkt i kvikflyt. Wizarden bliver gennemløbet med forskellige forbruger, der alle har forskellige forudsætninger i forhold til aflæsninger, opgørelser med videre. Nogle testcases har et navn der slutter på et forbrugernummer. Forbrugernummeret identificerer sig med en kolonne i det tilknyttede Excel ark, dette ark beskriver hvilke specielle forløb der bliver testet af den konkrete testcase. A7: Betalingsfil til NETS Formålet med denne testkørsel er at teste dannelsen af en PBS betalingsfil til NETS, at sikre konsistensen for denne. Udgangspunktet er en betalingsfil til rate betalinger uden bilag. For alle testcases gennemføres wizarden, med forskellige tilvalg/fravalg og intervaller. Til sidst i de enkelte testcases sammenlignes den dannede fil med en reference fra da testen blev oprettet, denne danner basis for en succes eller fejl. A8: OIOUBL og OIOXML til Nemhandel Dette testrun kører på genereringen af nemhandelsdokumenter. Der lægges vægt på det der er specielt for nemhandelsdokumenter, herunder format og det nødvendige indhold i dokumenterne/filerne. Da der er værker med forbrugere der modtager i OIOXML medtages denne på lige fod med OIOUBL. Denne test har samme omfang som test A7. I A7 er filerne rettet mod NETS/PBS, hvorimod filerne i A8 bliver sendt direkte til den forbruger som skal betale, og de skal selv sørge for at overføre/betale pengene. Denne test benytter Testdata01 databasen. Dataene er modificeret for at give et mere varieret datasæt. A9: Fakturaflow Denne testcase gennemløber mulighederne i Fakturaflow og sikre at brugerbegrænsninger, status for fordelte og godkendte faktura bibeholdes, at såvel som korrekte og ukorrekte OIO filer kan indlæses og at data bliver håndteret korrekt, såvel som flere andre funktionaliteter. Skærmbilleder der indgår i denne test dækker over Fakturaflow, EDH, Brugeropsætning, Kreditorvedligeholdelse (fanen posteringer). B10: Tilbudskladde Tilbudskladden er introduceret som en ekstra feature i forhold til finanskladderne. Den lægger i forlængelse af frifaktura kladden og giver værket mulighed for at oprette linjer til Tilbud, udskrive, arkivere og vente på kundernes accept, hvorefter de kan bogføres igennem kladde 50 uden at brugeren får det at se. Dette testrun vil koncentrere sig om at teste de tilføjede felter i finanskladden, finanskladden, system miljøet og i forhold til EDH arkivering på forbrugeren. Hertil vil også funktionaliteten med at udskrive, arkivere og bogføre tilbud blive testet. REVI-IT A/S Side 10 af 13

13 B12: Restancekladde Formålet med denne testcase er at teste restancekladden. Herunder med fokus på at restance listen Genereres/genberegnes konsistent, at skrivelser fra denne vises konsistent og at acontoposter bogføres til den korrekte forbruger. Der følges op på at det er muligt at taste i felterne som Begrundelse, lukningsdato og at de andre felter er lukket for ændringer, og at disse felter er persistente når det vælges at genberegne restancelisten. Komplementerende kontroller DFF EDB s kunder er, medmindre andet er aftalt, ansvarlige for at etablere og vedligeholde internet forbindelse til DFF EDB s servere. Herudover er DFF EDB s kunder, mindre andet er aftalt, ansvarlige for: At det aftalte niveau for backup dækker kundens behov Periodisk gennemgang af kundens egne brugere og meddele lukning af bruger At kundes brugere ikke lagere ulovligt materiale på DFF-EDB s servere. REVI-IT A/S Side 11 af 13

14 Afsnit 3: Uafhængig revisors erklæring om beskrivelsen af kontroller, deres udformning og funktionalitet Til Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s ledelse, selskabets kunder og disses revisorer Vi har efter aftale undersøgt Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s implementerede kontroller i relation til Finans- og Forbrugersystem FOF, pr. 23. juni Vores konklusion udtrykkes med høj grad af sikkerhed. Erklæringen er alene udarbejdet til brug for Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a.s ledelse, selskabets kunder og disses revisorer til vurdering af de tilrettelagte forretningsgange, og kan ikke anvendes til andre formål. Ledelsens ansvar Ledelsen i Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a. har ansvaret for at implementere og sikre opretholdelsen af forretningsgange i forbindelse med udvikling og vedligeholdelse af Finans- og Forbrugersystemet FOF. Revisors ansvar Det er vores ansvar, på grundlag af det udførte arbejde, at udtrykke en konklusion om, hvorvidt selskabet overholder de kontroller der er implementeret i forbindelse med udviklingen og vedligeholdelsen af Finans- og Forbrugersystemet FOF. Vi har udført vores arbejde i overensstemmelse med ISAE 3000, Andre erklæringsopgaver med sikkerhed end revision eller review af historiske finansielle oplysninger og yderligere krav ifølge dansk revisorlovgivning med henblik på at opnå høj grad af sikkerhed for vores konklusion. REVI-IT A/S er underlagt international standard om kvalitetsstyring, ISQC 1, og anvender således et omfattende kvalitetsstyringssystem, herunder dokumenterede politikker og procedurer vedrørende overholdelse af etiske krav, faglige standarder og gældende krav i lov og øvrig regulering. Vi har overholdt kravene til uafhængighed og andre etiske krav i FSR danske revisorers retningslinjer for revisors etiske adfærd (Etiske regler for revisorer), der bygger på de grundlæggende principper om integritet, objektivitet, faglig kompetence og fornøden omhu, fortrolighed og professionel adfærd. Vores arbejde har omfattet forespørgsler, observationer samt vurdering og stikprøvevis undersøgelse af den information, vi har modtaget. På grund af begrænsninger i ethvert kontrolsystem kan der opstå fejl eller besvigelser, som ikke afdækkes af vort arbejde. Endvidere vil en anvendelse af vor konklusion på efterfølgende perioders transaktioner være undergivet en risiko for, at der foretages ændringer af systemer eller kontroller, ændring i kravene til behandling af oplysninger eller i selskabets overholdelse af de beskrevne politikker og procedurer, hvorved vores konklusion eventuelt ikke længere vil være gældende. REVI-IT A/S Side 12 af 13

15 Konklusion Denne konklusion er udformet på grundlag af forståelsen af de kriterier, som der er redegjort for i erklæringens indledende afsnit og virksomhedens egen beskrivelse i afsnit 2 i relation til af Finans- og Forbrugersystemet FOF. Det er vores opfattelse, at Danske Fjernvarmeforsyningers EDB-Selskab a.m.b.a., i alle væsentlige henseender, lever op til ovennævnte kriterier pr. 23. juni København, 23. juni 2016 REVI-IT A/S Statsautoriseret revisionsaktieselskab Henrik Paaske Statsautoriseret revisor Martin Brogaard Nielsen It-revisor, CISA, CRISC, adm. direktør REVI-IT A/S Side 13 af 13