Kapitel 11 Krav-nr. Kravets ordlyd KMD-note i kravspecifikation Kommentar Kapitel i systembeskrivelse

Transkript

1 Krav-nr. Kravets ordlyd KMD-note i kravspecifikation Kommentar Kapitel i systembeskrivelse 1 Generelle krav BBR skal opbygges på sådan måde, at registret og anvendelsen heraf tilgodeser både kommunale og Alle kapitler landsdækkende behov for adgang til og opdatering af BBR-data. Kapitel 7, 8 og Opbygningen af BBR skal afspejle den gældende kommunale struktur, jf. CPR s oversigt over Kapitel 7 kommunekoder pr Den kommunale struktur skal kunne ændres uden omstrukturering af BBR s database. 1.3 For den enkelte kommune skal BBR fremtræde som et lokalt register, der dækker kommunens og kommunale samarbejdspartneres behov for adgang til kommunale BBR-data samt ajourføring heraf. Dette indebærer opbygning og vedligeholdelse (af kommunen) af kommune-specifikke oplysninger, hvorved BBR kan tilpasses lokale, kommunale forhold i den enkelte kommune. Oplysningerne skal bl.a. omfatte kommunenavn og -adresser samt en række specifikke lokale, kommunale parametre, herunder lokale skærmbilleder og specifikke lokale felter. Nyt BBR bliver udstyret med en Administrationsdatabase, der indeholder kommunespecifikke oplysninger. På fanebladet Systemadministration Afsnit 4.3 er der mulighed for at lave kommunale Kapitel 8 tilpasninger af tooltips, sidehjælp, fejltekster. Angive kommunespecifikke felter og links m.m. 1.4 BBR skal endvidere kunne tilgodese adgang til landsdækkende BBR-data samt ajourføring heraf. Kapitel Der skal etableres system til system-integration mellem BBR og andre offentlige registre, der udveksler BBR-data med BBR. 1.6 BBR skal være baseret på den logiske datamodel i tillæg A til kravspecifikationen, herunder de angivne entitetstyper. System-til-system integration varetages af OIOXML snitflader. BBR-data knyttes til de databærende enheder (entiteter), der fremgår af den i tillæg A viste logiske datamodel. I forbindelse med den specifikke implementering vil datamodellen blive bearbejdet. Kapitel 6 Afsnit BBR skal indeholde samtlige datafelter, der fremgår af databeskrivelserne i tillæg A til kravspecifikationen. 1.8 BBR skal i øvrigt opfylde alle de krav, der fremgår af efterfølgende punkter i kravspecifikationen. Eventuelle forbehold skal af tilbudsgiver være tydeligt markeret med X i kolonne 2 eller 3 og suppleret med noter herom. 2 Faseopdeling af samspillet mellem nyt BBR og nuværende BBR Afsnit 7.1 Alle kapitler Juni 2010 Side 1 af 72

2 2.1 Der skal i en overgangsfase (fase 0) etableres og driftsafvikles et interface i form af en webservice og/eller vha. anvendelse af MQ mellem det nye BBR og det nuværende BBR hos KMD. Interfacet/anvendelsen skal sik-re, at eksisterende systemer, der trækker på BBR-data, uændret kan fungere via det nuværende BBR, og at registrering og ajourføring af BBR-data i det nuværende BBR hos KMD fortsat vil være mulig i en overgangs-periode. Dette indebærer følgende krav: BBR-data, der registreres og ajourføres i det nye BBR skal konverteres til det nuværende dataformat i BBR og stilles til rådighed (i form af en webservice og/eller vha. anvendelse af MQ) for det nuværende BBR hos KMD. BBR-data, der registreres og ajourføres i det nuværende BBR hos KMD, primært via ESR og KRR, skal overføres til det nye BBR og konverteres til det nye dataformat i BBR. De nødvendige ændringer i det nuværende BBR-system hos KMD forudsættes varetaget af kunden og skal ik-ke indgå i tilbuddet. Det nuværende BBR holdes tidstro synkroniseret med det nye BBR via en række webservices. Der benyttes Message Queueing (MQ) forbindelse til mainframen til aktivering af et CICS program, der selv foretager opdateringen i det nuværende BBR s DB2 database. Data der opdateret i det nuværende BBR, vil afstedkomme et kald fra nuværende BBR til nyt BBR. Der anvendes også her en Message Queueing forbindelse. Læs mere om synkronisering af de to BBR databaser i den tilbudte løsning. Kravet er ændret som beskrevet i ændringsforslag nr. 7. For dokumentation af kravene i KS kapitel 2 henviser KMD til "Kontrakt for videreførsel af KMD-BBR december 2007" og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" Kontrakt for videreførsel af KMD-BBR december 2007 og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" 2.2 Interfacet skal sikre, at databaserne i det nye BBR og det nuværende BBR synkroniseres, således at BBR-data i begge systemer opdateres tidstro. Det bemærkes, at dette forventes at stille særlige krav til den valgte teknologi. Tilbudsgiver bedes redegøre for, hvilke forudsætninger der skal være opfyldt for at gennemføre en løsning. Kravet præciseres således: Synkroniseringen mellem Nyt BBR og KMD BBR foretages med MQ (Message Queue ). Synkroniseringen foretages asynkront som sikrer at KMD BBR som oftest opdateres indenfor sekunder. Samtidig betyder asynkron opdatering via MQ at Nyt BBR ikke er afhængig af, om forbindelsen til MVS-platformen er "oppe". Hvis forbindelsen ikke er "oppe" gemmer Nyt BBR synkroniseringstransaktionerne indtil forbindelsen igen er "oppe" og transaktionerne atter kan opdateres i KMD BBR. For at gøre opdateringen af de to databaser synkron, gøres MQ linien synkron Kravet er præciseret i præciseringsnotatets punkt 8. For dokumentation af kravene i KS kapitel 2 henviser KMD til "Kontrakt for videreførsel af KMD-BBR december 2007" og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" Kontrakt for videreførsel af KMD-BBR december 2007 og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" 2.3 Udvekslingen af data mellem det nye BBR og det nuværende BBR skal være baseret på web services og/eller asynkron MQ. Kravet er ændret som beskrevet i ændringsforslag 9. For dokumentation af kravene i KS kapitel 2 henviser KMD til "Kontrakt for videreførsel af KMD-BBR december 2007" og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" Kontrakt for videreførsel af KMD-BBR december 2007 og "Notat. Synkronisering af Nyt BBR til KMD BBR v. 1.0" 2.4 I takt med at det nuværende BBR udfases, skal registrering og ajourføring af alle BBR-data overføres til det nye BBR, og BBR-data stilles til rådighed for andre systemer vha. webservices. Juni 2010 Side 2 af 72

3 2.5 Tilbudsgiver bedes fremkomme med forslag til opdeling af udviklingen og implementeringen af BBR i delfaser, herunder en vurdering af de systemmæssige og driftsmæssige konsekvenser. Leverandøren arbejder med en fase 0, en overgangsfase og den endelige fase som skitseret i udbudsmaterialet. Fase 0 og overgangsfasen er beskrevet i den tilbudte løsning. For dokumentation af kravene i KS Kontrakt for kapitel 2 henviser KMD til "Kontrakt for videreførsel af videreførsel af KMD-BBR december KMD-BBR 2007" december Reg. af BBR-data i BBR Reg. Bygværker o.l BBR-data vedrørende bygværker under opførelse og færdige bygværker skal registreres i BBR på Kapitel 7 følgende niveauer (entiteter), jf. tillæg A til kravspecifikationen: 1. Bygning, betegnet BYG 2. Teknisk anlæg (frivillig), betegnet TEK 3. Bolig-/erhvervsenhed, betegnet ENH 4. Brugsenhed (frivillig), betegnet BRU 5. Adgangsadresse, betegnet AAD 6. Enhedsadresse, betegnet EAD 7. Opgang/indgang, betegnet OPG 8. Etage, betegnet ETA 9. Rum (frivillig), betegnet RUM 10. Grund, betegnet GRU Der skal sondres mellem sagsdata og stamdata ved hjælp af en statuskode i felterne BYG.100, TEK.100, ENH.100, BRU.100, OPG.100, ETA.100, RUM.100, og GRU.100. Statuskoden kan antage følgende kodeværdier: Statuskode 1: Stamdata Statuskode 2: Udgået Statuskode 3 Sagsdata Statuskode 4: Afsluttet sag Byggesager, som henlægges, slettes ikke, men tildeles statuskode 4. Det skal være muligt at oprette stamdata direkte, dvs. med statuskode 1 uden forudgående oprettelse af sagsdata. Statuskoderne for de enkelte entiteter skal afspejle strukturen i den logiske datamodel Ved afslutning af et byggeri opdateres stamdata med sagsdata, og statuskoden for byggesagen ændres til afsluttet byggesag (statuskode 4). Sagsdata slettes ikke Sagsnummer (journalnummer og/eller link til sagsdokumenter (ESDH)) og initialer skal fremgå af sagsdata på alle entiteter, herunder adresser Der skal være mulighed for at indberette fritekst i 99 fritekstfelter i de enkelte entiteter (notatlinjer). Notatlinjerne skal være nummererede. Notatlinjerne skal kunne fremtages ved opslag i BBR på de enkelte entiteter. I forbindelse med udskrift af BBR-Meddelelser skal det være muligt at definere (vha. systemparameter), hvilke notatlinjer der skal udskrives på BBR-Meddelelsen, og hvilke der kun er til internt brug i kommunen og derfor ikke skal fremtræde eksternt. Kravet er ændret som beskrevet i ændringsforslag 10. Kapitel 7 Kapitel 7 Kapitel 7 Afsnit Kapitel Alle registreringer af BBR-data skal på felt-niveau indeholde tidsstempling og kildeko-de (brugerid) fra seneste registre-ring/ajourføring. Afsnit 8.1 Juni 2010 Side 3 af 72

4 3.1.7 Ved opslag i BBR, fx i forbindelse med ajourføring af BBR-data, skal det være muligt at se tidsstempling og kildekode på de enkelte felter (ved mouse-over ). For hvert felt i databasen påhæftes et tooltip. Som udgangspunkt vises disse tooltip indehold tags for ændringsdato og kildekode. Afsnit Der skal for de enkelte kommuner være mulighed for at oprette frivillige felter i hver entitet, fx for at kunne registrere lokale, administrative forhold i BBR. Den enkelte kommune gives mulighed for at oprette et antal frivillige felter som angivet i leverancekontraktens bilag 2, tillæg A (beskrivelse af entiteter i det nyt BBR). Afsnit Afsnit Registrering af adresser BBR-data vedrørende adresser under behandling og fastsatte/ godkendte adresser skal kunne Afsnit registreres (dvs. oprettes og opdateres) selvstændigt i BBR på følgende niveauer (entiteter), jf. tillæg A Afsnit til kravspecifikationen: Afsnit Adgangsadresse, betegnet AAD Afsnit Enhedsadresse, betegnet EAD. Afsnit Afsnit BBR skal håndtere adgangsadresser (AAD), således at vejkode og husnummer udgør egenskabsdata (attributter), som kan ændres uden at berøre adresseforekomstens liv. Tilsvarende gælder for enhedsadresser (EAD) mht. etage og dørbetegnelse For adresser skal der efter samme principper og med samme kodeværdier som i krav sondres mellem adresser/adresseoplysninger under sagsbehandling o.l. og gældende adresser mv. ved hjælp af en statuskode i ADD.100, EAD.100. En adressesag, som henlægges, tildeles statuskode Ved afslutning af en adressesag, dvs. ved registreringen eller opdateringen af en gældende adresse, opdateres adressens stamdata med sagsdata, og statuskoden ændres til afsluttet (statuskode 4). Sagsdata slettes ikke BBR skal som sagsdata kunne registrere adressedata fra andre kilder end kommunen selv med følgende kildekoder: Kildekode 1: Oprettet af kommunen iht. adressecirkulære Kildekode 2: Oplysning fra ejer Kildekode 3: Oplysning fra teknisk kort Kildekode 4: Oplysning fra KRR (manuelle adresser) Kildekode 5: Oplysning fra KRR (administrative adresser) Kildekode 6: Oplysning fra ESR Kildekode 7: Oplysning fra CPR Kildekode 8: Oplysning fra CVR Kildekode 9: Oplysning fra post Kildekode 10: Oplysning fra 112 o.l. Kildekode 11: Oplysning fra anden kilde. 4 Opdatering af BBR-data i BBR Byggesagsbehandling og løbende ændringer - Afsnit Afsnit Afsnit 7.2 Afsnit Afsnit Afsnit Afsnit 7.2 Afsnit Afsnit Afsnit Afsnit 7.2 Afsnit Afsnit Juni 2010 Side 4 af 72

5 4.1.1 Følgende BBR-data skal registreres og opdateres (ajourføres) i BBR: Alle byggesagsdata vedrørende bygninger under opførelse eller ændring Alle stamdata i klasse 0 og 1 samt data i klasse 2 og 3, som kommunen har valgt at registrere i BBR (se kravspecifikationens punkt 10.2 vedrørende klassifikation af data) Registrering og opdatering af BBR-data skal kunne ske: Ved onlineoverførsel af data fra lokale kommunale systemer (herunder systemer til byggesagsbehandling, GIS-systemer med bygningsgeonøgle (koordinater)) via webservice i OIOXMLformat (BBR-kommuneklient). Manuelt vha. af en browserbaseret brugergrænseflade (BBR-brugerklient). Registrering og opdatering af BBR-data skal kunne ske: Manuelt vha. af en browserbaseret brugergrænseflade (BBR-brugerklient). Registrering og opdatering af BBR-data skal kunne ske: Ved onlineoverførsel af data fra lokale kommunale systemer (herunder systemer til byggesagsbehandling, GIS-systemer med bygningsgeonøgle (koordinater)) via webservice i OIOXMLformat (BBR-kommuneklient). Registrering og opdatering af BBR-data skal kunne ske: Ved onlineoverførsel af data fra lokale kommunale systemer (herunder systemer til byggesagsbehandling, GIS-systemer med bygningsgeonøgle (koordinater)) via webservice i OIOXMLformat (BBR-kommuneklient) Det skal være muligt for en ejer/bygherre at indberette BBR-data via et elektronisk indberetningsskema til godkendelse af den kommunale sagsbehandler. Der skal være validering og logiske kontroller af BBR-data forud for fremsendelse til kommunen Meddelelse om indflytning skal ikke afslutte byggesagen. Skal overføre enheden til stamdata, men bevare bygningen som sagsdata Det skal være muligt at registrere forventet påbegyndelse og afslutning af byggeri som en klasse 2- oplysning med tilhørende parameterstyring af, hvorvidt BBR skal ajourføres ved hjælp heraf. Se bilag 17 for beskrivelse af Borgerindberetningsoptionen. Kapitel 3 Kapitel 4 Kapitel 2 Afsnit 3.2 Kapitel 4 Afsnit 6.2 Afsnit 9.1 Afsnit 9.2 Kapitel 2 Afsnit 3.2 Kapitel 4 Afsnit 6.2 Afsnit 9.1 Afsnit 9.2 Kapitel 2 Afsnit 3.2 Afsnit 6.2 Afsnit 9.1 Afsnit 9.2 Kapitel 2 Afsnit 3.2 Afsnit 6.2 Afsnit 9.1 Afsnit 9.2 Option ikke valgt og derfor ikke beskrevet. Afsnit Ved registrering af bygninger (BYG) og tekniske anlæg (TEK) skal der fremkomme en oversigt over, hvilke bygningsnumre der hidtil er anvendt på det pågældende ejendomsnummer samt et forslag til bygningsnummer eller anlægsnummer Fejlagtige data skal kunne slettes af den kommunale bruger (med rettighed hertil). Kapitel 4 Juni 2010 Side 5 af 72

6 4.1.8 Det skal være muligt at flytte en bygning, herunder en husbåd, til en anden kommune alene ved at ændre adressedata i BBR. Kravet er præciseret som beskrevet i præciseringsnotatet punkt 21: Kravet omkring flytning af en bygning skal forstås således, at krav kun gælder administrativ eller fysisk flytning af en bygning ad gangen. Hvis en administrativ flytning består af flere flytninger af bygninger, en ad gangen, vil det dog være omfattet. Kommunernes nuværende arbejdsgang, hvor en bygning manuelt nedlægges og oprettes i en ny kommune fastholdes, og der skal derfor ikke udfærdiges en teknisk løsning. Flytninger af husbåde håndteres ligeledes manuelt. Det sikkerhedsmæssige ligger i at en sagsbehandler i en kommune ikke må oprette eller flytte noget i en anden kommune uden at registerføreren er bekendt hermed. Flere kommuner har desuden en beslutning om, at de ikke vil tillade husbåde i havnene. Hertil kommer at opførsel af husbåde kræver byggetilladelse i den nye kommune. I forbindelse med byggetilladelsen tildeles vand, varme mv. og husbåden gives en adresse. Dette er nødvendigvis en manuel proces. Samlet giver de sikkerhedsmæssige problemstillinger og kravet om byggesagsbehandling at der ikke kan ske en maskinel flytning i BBR. En flytning af en husbåd skal således ske ved at den nedlægges i den ene kommune og oprettes i den nye kommune Der skal kunne etableres links til andre relevante registre, fx Stamdataregister for vindmøller. Leverandøren forudsætter, at det relevante register definerer og gør link tilgængelig. Afhængig af linket og fællesskab i identifikationer kan der linkes til øverste niveau eller ned på enkelt entiteter Afsnit Afsnit Det skal ved ændringer af BBR-data være muligt for en kommunal bruger at vælge, hvorvidt ændringen skal slå igennem på alle underliggende niveauer i datamodellen. Kravet er præciseret i præciseringsnotatets punkt 13. Kravet er præciseret således: En adresseændring foretaget i adressedelen, skal slå igennem på alle adresser med samme adressebetegnelse. Øvrige identændringer skal slå igennem på relevante niveauer ift. datamodellen Ved overskridelse af tidsfrister for midlertidige tilladelser skal der være mulighed for en påmindelse. Afsnit Opdatering af BBR skal være underkastet validering og kvalitetssikring af de aktuelle BBR-data (se kravspecifikationens punkt 11). Afsnit Afsnit Afsnit Afsnit Registrering og opdatering af adresser og adressedata Følgende BBR-adressedata skal registreres og opdateres (ajourføres) i BBR: Kapitel 3 Alle sagsdata for adresser, som er under sagsbehandling Kapitel 7 Alle stamdata i klasse 0 og 1 samt data i klasse 2 og 3, som kommunen har valgt at registrere i BBR Afsnit Afsnit (se kravspecifikationens punkt 10.2) Juni 2010 Side 6 af 72

7 4.2.2 BBR s funktioner for registrering og opdatering af adressedata skal være udformet fleksibelt, således at de ikke er fast bundet til BBR s registrerings- og opdateringsfunktioner for byggesager eller bygværker Inddatering af adressedata skal kunne ske ved en webservicebaseret overførsel af data fra kommunale opgavesystemer i OIOXML-format (BBR-kommuneklient) eller af en browserbaseret brugergrænseflade (BBR-brugerklient) BBR s registrering og opdatering af data for adressepunkter (geografiske adressekoordinater) skal kunne ske på baggrund af et digitalt grundkort ved webservicebaseret overførsel fra et eksternt GIS eller kortsystem i OIOXML-format Den i krav nævnte BBR-brugerklient skal inkludere funktionalitet, som muliggør en simpel placering og editering af adressepunkter (geografiske adressekoordinater) på baggrund af et eller flere digitale kortlag efter WMS-standarden Opdatering af BBR s adressedata skal være underkastet validering og kvalitetssikring af de aktuelle BBR-data (jf. kravspecifikationens punkt 11). Se bilag 17 for beskrivelse af WMS adresse optionen. 4.3 Enkeltopdateringer Ejeres indberetning af specifikke BBR-data til godkendelse i kommunen skal kunne ske via opkobling Leverandøren forudsætter, at der med til Den Offentlige Informationsserver (OIS), hvor der foretages adgangskontrol eller en anden opkobling til OIS menes at ejeren benytter tilsvarende tjeneste med en standardiseret snitflade. den facilitet i OIS, der i dag giver mulighed Efter godkendelse i kommunen skal BBR-data kunne overføres direkte til BBR og opdatere BBR. for at sende besked om BBR-ændringer til BBR. Endvidere forudsættes, at denne løsning ændres så der for fremtiden foretages kald til det nye BBR, via de snitflader nyt BBR stiller til rådighed i forbindelse med modtageboksen. Kapitel 4 Kapitel 2 Afsnit 3.2 Afsnit 6.2 Afsnit 9.1 Afsnit Option ikke valgt og derfor ikke beskrevet. Afsnit Afsnit Afsnit Afsnit Der skal etableres en kommunal modtageboks for indberetning af ændringer, der modtages via en standardiseret snitflade. Alle indberetninger skal kunne gemmes Kommunen skal have mulighed for at videresende oplysningerne til en anden afdeling i kommunen, inden der foretages opdatering i BBR. Sagsbehandleren sender en mail til øvrige i kommunen med oplysninger fra indberetningen. Mailafsendelse håndteres via forretningslogikkens Meddelelses-system. Afsnit Indberetning af specifikke BBR-data, der modtages fra ejere via OIS, skal underkastes maskinel validering inden forelæggelse for kommunen (jf. kravspecifikationens punkt 11). Ved fejl fremsendes en til den pågældende ejer. Juni 2010 Side 7 af 72

8 4.3.5 Efter kommunens godkendelse eller afvisning af de indberettede BBR-data fremsendes en til ejeren herom. Hvis kommunen godkender de indberettede BBR-data, vedhæftes en ny BBRmeddelelse med ændringsmarkering. Kravet er præciseret således: Som svar på sagsbehandleren accepterede opdateringen eller ej, eftersender sagsbehandleren en mail med oplysninger. Dette forudsætter at ejeren, via OIS, har leveret en valid adresse. Kravet er præciseret i præciseringsnotatets punkt 15. Afsnit Efter kommunens godkendelse eller afvisning af de indberettede BBR-data fremsendes en til afsenderen. Hvis kommunen godkender de indberettede data, vedhæftes en ny BBR-Meddelelse til denne mail. Derudover kan kommunen afgøre, om ejeren (hhv. administratoren) af ejendommen skal få en BBR- Meddelelse ved næste central udskrivning af BBR-Meddelelser. Denne BBR-Meddelelse vil indeholde en markering af de felter, som blev ændret siden sidste gang ejeren (hhv. administratoren) modtog en BBR-Meddelelse. (se også præcisering af krav 7.12) 4.4 Systematisk opdatering Det skal være muligt at foretage systematisk opdatering af BBR-data ved onlinefiloverførsel af data i Kapitel 9.1 OIOXML-format. Der skal med henblik herpå etableres særlige skærmbilleder med adgangskontrol (OCES) Følgende BBR-data skal kunne opdateres systematisk: Alle stamdata i klasse 0 og 1 samt data i klasse 2 og 3, som kommunen har valgt at registrere i BBR Kommunen skal kunne tildele eksterne parter rettighed til at indberette og ajourføre specifikke BBRdata (felter) Modtagne BBR-data skal underkastes maskinel validering og kvalitetssikring (jf. kravspecifikationens punkt 11). Hvis der konstateres fejl eller mangler, skal dette resultere i fejlmeddelelser, der sendes til afsender via . Der oprettes et virkefelt bestående af disse felter i kommunens eget regi, og dette virkefelt tildeles sammen med rollen ekstern bruger til den eksterne part. Det forudsættes, at BBR har modtaget valid adresse på den eksterne part. Kapitel 7 Afsnit BBR-data, der indberettes systematisk i BBR, skal forsynes med kildekode samt dato ved opdatering Kapitel 3 af BBR Systematisk opdatering af BBR skal ikke automatisk medføre udskrivning af BBR-Meddelelser. Afsnit Masseopdatering - NB til 4.5 Kravene omkring masseopdatering (kravene i afsnit 4.5) forstås således, at masseopdatering kan Præciseringsnotatet punkt 1. være landsdækkende. Det er den eneste forskel i forhold til kravene i afsnit 4.4 om systematisk Desuden kan det tillige her påpeges, opdatering. at de enkelte kommuner også kan Denne præcisering sker under forudsætning af at de underliggende krav ikke tilsidesættes. foretage masseopdatering. Kapitel 9 Kapitel 3 Kapitel 6 Kapitel Det skal være muligt at foretage masseopdatering af BBR-data i OIOXML-format ved onlinefiloverførsel. Der skal med henblik herpå etableres særlige skærmbilleder med adgangskontrol (OCES). Det forventes, at masseopdateringer vil ske i batch-vinduer, således at svartiderne ikke belastes i den almindelige arbejdstid. Kapitel 6 Juni 2010 Side 8 af 72

9 4.5.2 Følgende felter skal som minimum kunne masseopdateres: Felter, der vedrører data om husleje/udlejningsforhold fra ejerne. Masseindberetning af data om husleje/udlejningsforhold er fastsat ved administrative regler (evt. i form af en særlig tabel i databasen). Felter, der vedrører varmeinstallation, opvarmningsmiddel og supplerende varme. Felter, der vedrører fredningsforhold og bevaringsværdige bygninger. Felter, der vedrører adgangsadresse. Kapitel Det skal også være muligt at masseopdatere øvrige BBR-data i klasse 1 og 2 Kapitel Modtagne BBR-data skal underkastes maskinel validering og kvalitetssikring (jf. kravspecifikationens punkt 11). Hvis der konstateres fejl eller mangler, skal dette resultere i fejlmeddelelser, der sendes til afsender via . Det forudsættes, at BBR har modtaget valid adresse på den eksterne part BBR-data, der indberettes ved masseopdatering i BBR, skal forsynes med kildekode samt dato ved Kapitel 3 opdatering af BBR Masseopdatering af BBR skal ikke automatisk medføre udskrivning af BBR-Meddelelser. Afsnit Samordning med andre data i andre offentlige registre Jvf. "Allonge 1" hvor der bl.a. står: Det forudsættes i kontraktens bilag 2 (Kravspecifikation), navnlig i afsnit 5.1, at KMS stiller landsejerlavskode og matrikelbetegnelse samt matrikelkoordinater til rådighed for BBR online i form af web services baseret på en OIOXML-snitflade. I en overgangsfase vil ovenstående data i stedet hentes fra ESR via tillæg til den ovenstående tilvejebragte snitflade. 5.1 Samordning matrikel og ESR Jvf. "Allonge 1" hvor der bl.a. står: Det forudsættes i kontraktens bilag 2 (Kravspecifikation), navnlig i afsnit 5.1, at KMS stiller landsejerlavskode og matrikel betegnelse samt matrikelkoordinater til rådighed for BBR online i form af web services baseret på en OIOXML-snitflade. I en overgangsfase vil ovenstående data i stedet hentes fra ESR via tillæg til den ovenstående tilvejebragte snitflade. Landsejerlavskode, matrikelbetegnelser og matrikelkoordianter hentes via webservices fra KMS (pånær København og Frederiksberg hvor der er særskilte webservices) Kapitel 3 Kapitel Ved registrering af BBR-stamdata, BBR-sagsdata samt ændring og opdatering heraf skal der ved opslag i MATR og ESR tilknyttes en korrekt landsejerlavskode og matrikelnummer samt ejendomsnummer. Endvidere skal nøglerne registreres i BBR Ved opslag med et matrikelnummer i BBR skal det tilhørende landsejerlavsnavn være tilgængeligt i BBR BBR s registreringer af matrikelbetegnelser og matrikulære data skal ske på basis af web services med OIOXML-format, som stilles til rådighed af KMS-matriklen (MATR). Som eneste undtagelse herfra gælder ma-trikulære data for Frederiksberg og Københavns kommuner, for disse hentes oplysningerne fra ESR. Leverandøren forudsætter, at der er faciliteter til rådighed, som kan sikre opdaterede landsejerlavsnavne i BBR. Kravet er ændret som beskrevet i ændringsforslag 32. Afsnit Kapitel 6 Kapitel 6 Juni 2010 Side 9 af 72

10 5.1.4 BBR skal have funktionalitet, som muliggør udnyttelsen af en webservice, hvormed BBR på basis af en matrikelbetegnelse rekvirerer de gældende matrikelkoordinater til adgangsadresse (AAD) og bygning (BYG) eller på basis af adresse- eller bygningskoordinater, rekvirerer den gældende matrikelbetegnelse til brug for adgangsadresse (AAD) og bygning (BYG) Der skal i BBR etableres relationer til ESR for entiteterne Bygning (BYG), Enhed (ENH), adgangsadresse (AAD) og Grund (GRU) Ændringer af ejendomsnummer i ESR skal kunne overføres til BBR. Der foretages ikke identændringer i ESR. Nyt BBR vil derfor stille services til rådighed, der kan modtage gammel og nyt ejendomsnummer Via ESR hentes ved ejerlejligheder både artskode og ejerlejlighedsnummer. Det forudsættes, at ESR stiller en webservice til rådighed, der kan levere disse oplysninger Ved registrering af adgangsadresse (AAD) eller ændringer heraf i BBR skal der ske onlineoverførsel af adgangsadressedata til MATR og ESR. Dette kan ske i form af webservices baseret på en OIOXMLsnitflade. Det forudsættes, at servicen er til rådighed i MATR og ESR Adresser for ubebyggede grunde skal overføres automatisk til ESR efter validering i BBR. Det forudsættes, at ESR stiller en webservice til rådighed, der kan levere disse oplysninger Ved bygninger på lejet grund hentes ejendomsdata via ESR og overføres til BBR. Det forudsættes, at servicen er til rådighed i MATR og ESR. 5.2 Dataudveksling mellem BBR og CPR Kravet er ændret med ændringsforslag 29. Afsnit Kapitel 7 Kapitel 6 Kapitel 6 Afsnit Kapitel 6 Kapitel 6 Krav til dataudveksling med CPR jf. kontraktens bilag 2 (Kravspecifikation), af-snit 5.2, er ændrede som angivet i Allonge 1 appendiks 3 - Dvs. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". Juni 2010 Side 10 af 72

11 5.2.1 Ved inddatering af BBR-data, som indgår i entiteterne AAD/EAD, skal tilhørende adressedata vedrørende: vejnavn postnummer postdistrikt lokalitet bynavn være tilgængelige i BBR (herunder synlige og søgbare). Disse data hentes fra CPR s vejregister eller en kopi heraf. Kopien opdateres dagligt. Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR", hvor det fremgår: 3.2 Data fra CPRs vejregister (krav 5.2.1) Ved oprettelse af adresser i Nyt BBR skal adressedata fra CPR s vejregister være til rådighed: Vejnavn Postnummer Postdistrikt Lokalitet Bynavn Til dette formål har CPR-kontoret tilbudt at stille en kopi af vejregistret til rådighed for Nyt BBR, herunder feltet lokalitet (der ikke knytter sig til en vej, men en adresse udtrykt ved et bygningsnavn, et gårdnavn o.l.). Endvidere vil CPR-kontoret stille en kopi med daglige ændringer i vejregistret til rådighed for BBR med henblik på opdateringer Registrering eller opdatering af et eller flere datafelter, der indgår i BBR/CPR-standardtransaktion, skal resultere i dannelse af en BBR/CPR-standardtransaktion med tilhørende transaktionskode, jf. kravspecifikationens punkt BBR/CPR-standardtransaktioner opsamles i BBR og overføres til CPR i form af en samlet fil. Endvidere skal BBR fra CPR kunne modtage en samlet fil med BBR/CPR-standardtransaktioner. Filoverførsler finder sted én gang i døgnet på hverdage mandag til fredag. Krav bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". Krav bortfalder (lige som hele afsnit i kravspecifikationen) jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR" BBR/CPR-standardtransaktioner, der modtages fra CPR, skal behandles iht. transaktionskoderne i kravspecifikationens punkt Krav bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". Juni 2010 Side 11 af 72

12 5.2.5 Boligtypekoderne 1-5 skal dannes maskinelt i BBR på grundlag af oplysninger om beboelsesareal og erhvervsareal, anvendelse og køkkenforhold, jf. beregningsregler i tabel med boligtypekoder. Boligtypekoden skal opdateres maskinelt, hvis der sker ændringer af enhedsarealer, anvendelse eller køkkenforhold, herunder i forbindelse med færdigmelding af byggeri (statuskode BBR-felt ENH.100 ændres til 1). Boligtypekoden skal efter maskinel opdatering i BBR resultere i en BBR/CPR-standardtransaktion. Boligtypekoden, enhedsarealer og antal værelser skal kunne rekvireres af CPR ved en BBR/CPRstandardtransaktion med transaktionskode R. Krav bortfalder (hvad angår rekvisition af boligtypekoden) jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR" Det skal være muligt at foretage manuel inddatering af boligtypekoden i byggesagsdata (Statuskode BBR-felt ENH.100 = 3). Dette skal ikke medføre oprettelse af en BBR/CPR-standardtransaktion. Kapitel Der skal fremstilles en fil i OIOXML-format med en liste over boligenheder i hver kommune med *- markering i BBR-felt ENH.40 med tilhørende adresser. Filen skal kunne rekvireres og udskrives af BBR-myndigheden i kommunen. Afsnit 10.6 Kravet er løst i XML Afsnit 10.6 Kravet løses i OIOXML Det skal ved periodevis afstemning (mindst én gang om året) sikres, at alle data, der er fælles i BBR og CPR, er konsistente. Der skal fremstilles en fil i OIOXML-format med afvigelser. Filen skal kunne rekvireres og udskrives af BBR-myndigheden i kommunen, således at der kan ske tilretning i BBR eller CPR. Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR" hvor det fremgår: Der skal ved periodevis afstemning (mindst én gang om året) foretages samkørsel af Nyt BBR og CPR med henblik på at sikre overensstemmelse af adressedata i de to registre. Afvigelser registreres i en fil i OIOXML-format og således, at den enkelte kommune kan rekvirere filen med henblik på tilretning i BBR eller CPR. Afsnit 10.1 Afsnit 10.4 Kravet er løst i XML Afsnit 10.1 Afsnit 10.4 Kravet løses i OIOXML Alle adressedata i BBR, herunder adresser fra andre kilder, jf. kildekoden i AAD/EAD, skal kunne overføres til CPR. Det forudsættes, at servicen er til rådighed i MATR og ESR. Krav bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". Juni 2010 Side 12 af 72

13 Såfremt der foretages sammenlægninger af kommuner, skal det være muligt at foretage samlet opdatering af ændringer af adressedata samt øvrige data i BBR, hvori kommunenummeret indgår. Kravet er ændret som beskrevet i ændringsforslag 41. I ændringsforslag 41 er følgende tilføjet til kravet: KMD skal inden for et rimeligt tidsinterval kunne opfylde krav i tilfælde af en lovændring af administra-tive grænser (kommunegrænser) fx i form af en kommunesammenlægning. Nyt BBR skal være opbygget således at: Nyt BBR s datamodel er passende normaliseret, således at der ikke forefindes redundante forekomster af kommunenummer. Nyt BBR s data kan læses og opdateres via SQL-scripts i forbindelse med batch-opdateringer. Eventuelle implementerede forretningsregler relateret til kommunetilhørsforhold kan disables i forbindelse med batchopdateringer. Det skal fremgå af systemdesignet hvordan disse forretningsregler er implementeret. Eventuelle implementerede forretningsregler relateret til kommunetilhørsforhold kan enten aktiveres eksplicit i forbindelse med batchopdateringer, eller nemt kan implementeres via SQL-scripts Data, som udveksles, skal underkastes validering og kvalitetssikring (jf. kravspecifikationens punkt 11). Hvis data ikke kan godkendes af det modtagende system (CPR eller BBR), skal dette resultere i en fejlmeddelelse, som overføres til det afsendende system. Kravet er præciseret således: Når der modtages data fra ESR og CPR, betragtes det som en fejl, hvis data ikke kan falde på plads i NYT BBR. Fejlen logges i NYT BBR og afsender-systemer modtager ikke besked. Ved kommunikation med webservices sker denne tilbagemelding til det afsendende system. Ved modtagelse af udtræk fra CPR og ESR, hvor Nyt BBR modtager data, opfattes fejl i valideringer som fejl i Nyt BBR (da CPR og ESR er master for disse data) og det afsendende system modtager ikke besked herom. Kravet er præciseret i præciseringsnotatets punkt 2. Afsnit Afsnit Ved kommunikation med webservices sker denne tilbagemelding til det afsendende system. Krav 5.3 er ændret jf. Allonge 1, appendiks 3: "Ændringer i dataudvekslingen mellem NYT BBR og CPR" - Juni 2010 Side 13 af 72

14 5.3.1 Koden Udlejningsforhold 2 i BBR skal dannes maskinelt på landsplan og ad hoc efter kommunalt behov, på grundlag af oplysninger i BBR, CPR og ESR: Persontilmeldinger i CPR Data om ejers adresse fra ESR Enhedsdata fra BBR. Ved samkøring af de tre registre sammenholdes de ejendomme, der i BBR er registreret med boligenheder, med de tilsvarende ejendomme i ESR. For disse ejendomme med boligenheder undersøges, om ejerens personnummer svarer til nummeret for én af de personer, som i CPR er tilmeldt boligenhedens adresse. På grundlag heraf dannes en kodeværdi jf. nedenfor, der indsættes i BBR-felt Udlejningsforhold 2. Koden skal efter samkøringen ikke kunne henføres til nogen person. Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR" hvor det fremgår: Koden dannes maskinelt ved periodevis samkørsel (to gange om året) af BBR, ESR og CPR, hvor det undersøges, om ejerens personnummer svarer til nummeret for én eller flere af de personer, der er tilmeldt på boligenhedens adresse. Afsnit Der skal anvendes følgende kodeværdier: 1. Udlejet 2. Benyttet af ejer 3. Ikke benyttet Bilag C - Koden Udlejningsforhold 2 (ENH.45) Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR" Opdatering af koden Udlejningsforhold 2 skal være underkastet validering og kvalitetssikring. Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR" Kapitel 3, bilag C Afsnit Samordning af ejerforholdskoden og overførsel af tinglyst areal Ved indberetning af ejerforholdskoden i BBR skal det være muligt at hente koden i ESR på grundlag af Leverandøren forudsætter, at ESR stiller en Kapitel 6 oplysninger om: webservice til rådighed, der kan levere Ejendomsnummer ejerforholdskoden. Matrikelnummer Ejerforholdskoden registreres som udgangspunkt i BBR på entiteten Grund (GRU). Herudover gælder følgende regler: Ved en moderejendom for ejerlejligheder skal ejerforholdet registreres på de enkelte enheder (ENH) eller eventuelt bygninger (BYG). Ved en bygning på lejet grund skal ejerforholdskoden registreres på bygningen Indberetning af ejerforholdskoder eller ændringer heraf skal udveksles online med ESR og medføre opdatering i BBR. BBR s ejerforholdskode skal også opdateres i sagsdata. Leverandøren forudsætter, at ESR stiller en webservice til rådighed, der kan levere ejerforholdskoden Opdatering af ejerforholdskoden skal være underkastet validering og kvalitetssikring Tinglyst areal for ejerlejligheder registreres i ESR og skal - efter kommunens eget valg - kunne Kapitel 6 overføres fra ESR til BBR (parameterstyret). 6 Udtræk samt overførsel af enkelte datafelter Den Offentlige Informationsserver Der skal dagligt foretages onlineoverførsel af replikerede, landsdækkende BBR-data til OIS omfattende alle BBR-data i klasse 0, 1 og Onlineoverførsel af BBR-data skal ske ved filoverførsel i OIOXML-format, jf. tillæg C til kravspecifikationen. Der foretages overførsel af ændrede BBRdata. Der vil blive afleveret efter det i bilag 2, tillæg C viste format. Afsnit Kapitel 3 Kapitel 6 Kapitel 6 beskrives senere beskrives senere Juni 2010 Side 14 af 72

15 6.2 Andre relevante administrative systemer Krav 6.2 er ændret idet der fremover ønskes adgang til en generel webservice i NYT BBR jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR" Onlineenkeltopslag og overførsel af enkelte datafelter Det skal for brugere med adgangsrettighed hertil være muligt at foretage enkeltopslag i BBR-data ved Afsnit 9.2 hjælp af gængse internet-browsere. Adgangskontrollen skal være baseret på digital signatur Skat skal have mulighed for at foretage online udtræk af forud fastlagte BBR-data vedrørende en enkelt ejendom. Pt. sker dette i form af en flad fil, men se-nere skal der være mulighed for en OIOXML-fil. Kravet er præciseret således: Medarbejderne hos Skat skal have læseadgang til og der skal være udviklet generelle webservice, der returnerer alle registrerede data ved kald på en ejendom. Kravet ændret jf. præcisering nr. 19 Afsnit Skat skal endvidere have mulighed for indberetning af ændringer af BBR-data. Der skal etableres en kommunal modtageboks for indberetning af ændringer, der modtages fra Skat. Alle indberetninger skal kunne gemmes, og alle ændringer skal godkendes af kommunen, inden BBR ajourføres. Der skal være mulighed for link til ESDH. Kravet ændret jf. præcisering nr. 3 Kapitel 9 Kravet er præciseret således: Muligheden for at etablere link til lokale journalsystemer (ESDH) består i, at der kan opsættes links til at kunne sendes parametre fra Nyt BBR til kommunens ESDH-system. Her benyttes de parameterstyrede URL-links (dvs. de såkaldte Kommunespecifikke links ). De parametre som kan benyttes vil fremgå af brugervejledningen KMD stiller en webservice til rådighed således at koden for Offentlig støtte på længere sigt kan overføres til Nyt BBR fra BOSSINF-STB. På kort sigt skal brugeren selv indtaste feltet i Nyt BBR. Kravet er ændret som beskrevet i ændringsforslag 43. Kapitel 3, 6 og EBST skal have mulighed for at foretage parameterstyret udtræk af BBR-data ved direkte opkobling til BBR. Leverandøren forudsætter, at det aftales hvilke typer udtræk, der skal kunne trækkes så svartider ikke belastes unødvendigt. Kapitel Søgning på BBR-data skal kunne ske med ejendomsnummer, matrikelbetegnelse, adgangs- eller enhedsadres-se, bygnings- eller anlægsnummer samt rumnummer Afhængigt af adgangsrettigheden skal antallet af enkeltopslag registreres og tilknyttes en klikafgift, der er specifikt knyttet til brugerrettigheden (dette gælder ikke kommunale brugere). De enkelte klikafgifter skal kunne reguleres af den systemansvarlige myndighed (KH). Der stilles et næsten tidstro datawarehouse til rådighed, som indeholder de reelle entiteter og cuber, der benyttes til udtræk og rapporter. Kravet er ændret med ændringsforslag nr Masseudtræk - Kapitel 4 Afsnit Juni 2010 Side 15 af 72

16 Det skal være muligt at fremstille komplette kopier af BBR samt at overføre disse elektronisk til myndigheder m.fl. både i OIOXML-format og i andre gængse formater, der aftales særskilt med modtagerne Skat skal mindst én gang årligt (p.t ) online have overført en totalkopi af landsdækkende BBRdata (stamdata). P.t. sker dette i form af en flad fil, men senere skal der være mulighed for en OIOXML-fil Der skal hvert år afleveres en komplet kopi af landsdækkende BBR-data (stamdata) Formatet skal overholde krav fra Statens Arkiver Danmarks Statistik skal kunne foretage onlineudtræk af landsdækkende BBR-data (såvel stamdata som sagsdata) med statuskode 1, 2, 3 og 4 dels i form af en totalkopi, dels som OIOXML-udtræk. P.t. sker dette i form af en flad fil, men senere skal der være mulighed for en OIOXML-fil. Det forudsættes, at der med foretage online udtræk forstås, at rekvirering af udtræk kan foretages online. Der stilles et skærmbillede til rådighed, hvor disse bestillinger kan foretages. Det skal under systembeskrivelsesfasen fastlægges, hvorledes skærmbillede skal se ud og udtrækket efterfølgende skal leveres til Danmarks Statistik. Afsnit EBST skal månedligt samt ad hoc efter rekvisition online modtage en totalkopi af landsdækkende BBRdata (stamdata og sagsdata). f.eks. i csv-format, men ikke i mainframe Udtræk vil kunne ske i form at flade filer, Dette skal ske i form af en flad fil, fx i EBCDIC-format, men senere skal der være mulighed for en baserede EBCDIC-format. OIOXML-fil. Juni 2010 Side 16 af 72

17 7 Krav til udskrift af BBR-data (BBR-Meddelelser) Jvf. Allonge 1: Krav til landsdækkende udskrift af BBR-meddelelser jf. kontraktens bilag 2 (Kravspecifikation) frafaldes. Desuden ændres krav 7.2, så ejers navn og adresse hentes fra OIS, hvis de ikke har navnebeskyttelse, og fra CPR, hvis de har navnebeskyttelse i stedet for som angivet i kravet fra ESR. Kapitel 5 Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR", hvor det fremgår: Det har vist sig, at ESR alene indeholder CPR/CVR-nr., men ikke adresser. Adresserne vil kunne hentes ved opslag i CPR hhv. CVR. Men da OIS allerede indeholder ejeradresser (jf. OIS-tabel CO11700T), finder EBST, at adresserne mest hensigtsmæssigt hentes i OIS via en webservice. Hermed vurderes det, at behovet for adgang til KMDs P- hhv. V- dataregister bortfalder. 7.1 Fra BBR skal der automatisk (parameterstyret) kunne udskrives BBR-Meddelelser ved ejerskifte, indflytning eller ved ændringer af BBR-data. BBR-ejermeddelsen skal medtage oplysning om de på ejendommen godkendte adresser (stamdata) samt eventuelle sagsdata, der knytter sig til byggesagsdata. Kravet er præciseres således: I en dialog med kommunerne er man kommet frem til en liste af 12 årsagskoder, som benyttes ved udskrivning af BBR Meddelelser. En er dem er årsagskode 70 Denne BBR-Meddelelse er udskrevet på grund af matrikulære ændringer. Matrikulære ændringer som skal udløse en BBR-Meddelese er Opret og slet af matrikler med artskode 00 og 01 (ESR hændelser). Kravet er præciseret i præciseringsnotatets punkt 12. Afsnit 5.3 Afsnit 5.5 Afsnit 5.12 Juni 2010 Side 17 af 72

18 7.2 Ejers navn og adresse hentes via ESR. Jvf. Allonge 1 ændres krav 7.2, så ejers navn og adresse hentes fra OIS, hvis de ikke har navnebeskyttelse, og fra CPR, hvis de har navnebeskyttelse i stedet for som angivet i kravet fra ESR. Se notat "Ændringer af dataudveksling mellem NYT BBR og CPR". Det forudsættes, at ESR stiller en service til rådighed, der kan levere disse data online. Afsnit snitflade Kommunen skal kunne fravælge en totaludskrift ved afslutningen af en byggesag. Afsnit Der skal kunne udskrives BBR-andelsboligmeddelelser efter rekvisition fra lejere og andelshavere. Kravet er blevet ændret som Afsnit 5.4 beskrevet i ændringsforslag Udskrivning af BBR-meddelelser og BBR-andelsboligmeddelelser skal desuden kunne ske efter anmodning fra kommunen med individuelt tilpassede årsagskoder Kravet er blevet ændret som beskrevet i ændringsforslag 19. Afsnit Sagsbehandleren skal kunne fremfinde information om hvornår seneste BBR-Meddelelse er udskrevet, samt årsag til udskrivning. Kravet er ændret som beskrevet i ændringsforslag 20. Afsnit Rapport Byggesagsoplysningerne: bygningsnummer, sagstype, sagsnummer, byggetilladelsesdato (eller den dato der passer til sagstypen) skal vises på BBR-Meddelelserne. Byggesagsoplysningerne vises for alle entiteter som har en byggesag. Dette gælder både automatiske udskrifter og online bestillinger. Kravet er ændret som beskrevet i ændringsforslag 21. Afsnit Der skal være parameterstyring af de ændringer, som skal resultere i udskrift af BBR- Meddelelser/BBR-andelsboligmeddelelser. Kravet er blevet ændret som beskrevet i ændringsforlsag 19. Afsnit 5.3 Afsnit Alle ændringer siden sidste udskrift skal vises med kursiv på BBR-Meddelelsen. Kravet er ændret som beskrevet i ændringsforslag Masseudskrivning af BBR-Meddelelser skal kunne ske for bygninger med bestemte karakteristika, fx styret af anvendelseskoden (BYG.22) Der skal udskrives BBR-Meddelelser for: En vurderingsejendom En grund (matrikulær ejendom) En enhed/ejerlejlighed/andelsbolig Bygning. Afsnit 5.12 Afsnit Afsnit Juni 2010 Side 18 af 72

19 7.12 BBR-Meddelelse skal kunne udskrives for en ejendom med markering af de BBR-data, der er blevet ændret. Kravet er præciseret således: En BBR-Meddelelse, som udskrives til ejeren(hhv. administratoren) for en ejendom udskrives med markering af de BBR-data, der er blevet ændret siden sidste gang den pågældende ejer (hhv. administrator) modtog en BBR-Meddelelse. BBR-Meddelelser, som udskrives til andre modtagere end ejeren (hhv. administratoren) indeholder ingen ændringsmarkering, idet det er umuligt at vide, hvilke data der er blevet ændret siden sidst. Den første BBR-Meddelelse, som en ejer (hhv. administrator) modtager efter idriftsættelse af systemet, vil have markeret de felter, som er blevet ændret siden idriftsættelsestidpunktet. Kravet er præciseret i præciseringsnotatets punkt 16. De ændrede felter fremgår med kursiv. Afsnit 5.7 Afsnit BBR-Meddelelser/BBR-andelsboligmeddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev og kunne kobles til Skattemappen. BBR-Meddelelser/BBR-andelsboligmeddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev (EBST) og kunne kobles til Skattemappen. BBR-Meddelelser/BBR-andelsboligmeddelelser skal kunne udsendes via eller E-boks i PDFformat med et følgebrev (kommunespecifikke bilag) og kunne kobles til Skattemappen. Afsnit Meddelelserne kan udsendes via e- Afsnit mail (decentral udskrift) eller til e-boks (via den centrale udskrift). Kravet er ændret som beskrevet i ændringsforslag 19. Afsnit 5.1 Afsnit Modtagere af BBR-Meddelelser/ BBR-andelsboligmeddelelser skal have mulighed for at indberette rettelser i en PDF-blanket vedhæftet BBR-ejermeddelelelsen/BBR-andels-boligmeddelelsen og at returnere blanketten elektronisk til kommunen (SOA-baseret). Via PDF-blanketter er der ikke mulighed for, at verificere at data kommer fra ejeren. Det vil være op til sagsbehandleren at verificere data efterfølgende. For at sikre at data bliver valideret, inden de når sagsbehandleren, foreslås det at sådanne data indberettes via OIS eller anden 3. parts løsning, der benytter webservices, hvor data lander i kommunens modtageboks BBR-Meddelelser/BBR-andelsboligmeddelelser skal kunne udskrives decentralt i kommunen på en printer, der stilles til rådighed af kommunen Uanset datoer registreres i BBR i formatet ååååmmdd, skal datoer på BBR-meddelelser mv. fremtræde som dd-mm-åååå. Afsnit Afsnit 5.12 Juni 2010 Side 19 af 72

20 7.17 Layout af BBR-Meddelelser/BBR-andelsboligmeddelelser udarbejdes af leverandøren i samarbejde med de kommunale parter. Kravet er præciseret således: Muligheden for at til- og fravælge kommunespecifikke felter på meddelelserne fjernes. Kommunespecifikke felter udskrives ikke på meddelelser af typen BBR-Meddelelse og typen BBR- Andelsboligudskrift, men udskrives på meddelelser af typen BBR-Registerudskrift. Bemærk: Der er her tale om kommunespecifikke felter, IKKE om notatlinier, som fortsat vil kunne tilog fravælges at blive vist på BBR meddelelserne. Det betyder: BBR-Registerudskrift: Både kommunale felter og notatlinjer udskrives. BBR-Andelsboligudskrift: Hverken notatlinjer eller kommunale udskrives. BBR-Meddelelse: Kommunale felter udskrives ikke, notatlinjer til- og fravælges af kommunen. Leverandøren forudsætter, at Kommune Holding stiller kommunale repræsentanter til rådighed. Kravet er præciseret i præciseringsnotatets punkt 6. Afsnit Rapporter, statistikker mv Systemet skal være forsynet med en rapportgenerator, som gør det nemt og ukompliceret for brugerne (med rettighed hertil) i eget regi at fremstille rapporter, statistikker og andre former for udtræk af BBRdata. Der skal leveres en detaljeret vejledning hertil med beskrivelse af, hvilke datafelter der kan udtrækkes i rapporter, statistikker mv. Som rapportgenerator tilbydes standardsystemet SQL Server Reporting Services fra Microsoft. De brugere, som skal udarbejde rapporter, skal have adgang til en pc med Windows XP med Microsoft.Net 2.0 Framework installeret samt adgang til Nyt BBR. Rapporterne laves via Report Builder, der er en del af nyt BBR.Se mere om rapportmulighederne i den tilbudte løsning, afsnit 1.9. Afsnit 10.6 Afsnit Systemet skal leveres med 10 faste rapporter, hvis indhold fastlægges nærmere i forbindelse med systemudviklingen. 8.3 Alle rapporter skal kunne overføres til brugeren som en fil i valgfrit format (PDF, Word, Excel). Output fra rapporterne kan leveres i flere formater, herunder Excel, PDF, HTML og Word. 8.4 Uanset at datoer registreres i BBR i formatet ååååmmdd, skal datoer på rapporter fremtræde som ddmm-åååå. Kapitel 10 9 Dataudveksling, systemer til byggesagsbehandling og andre kommunale systemer - Kapitel 10 Juni 2010 Side 20 af 72