Krav-nr. KMD-note i kravspecifikation Kommentar Kapitel i systembeskrivelse 1 Generelle krav - 1.1 BBR skal opbygges på sådan måde, at registret og anvendelsen heraf tilgodeser både kommunale og landsdækkende behov for adgang til og opdatering af BBR-data. 1.2 Opbygningen af BBR skal afspejle den gældende kommunale struktur, jf. CPR s oversigt over kommunekoder pr. 1.1. 2007. 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. Alle kapitler, 8 og 9 På fanebladet Afsnit 4.3 Systemadministration er Kapitel 8 der mulighed for at lave kommunale 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. 1.5 Der skal etableres system til system-integration mellem BBR og andre offentlige registre, der udveksler BBR-data med BBR. System-til-system integration varetages af OIOXML snitflader. Kapitel 9 Kapitel 6 1.6 BBR skal være baseret på den logiske datamodel i tillæg A til kravspecifikationen, herunder de angivne entitetstyper. 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. Afsnit 7.1 1.7 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 Godkendt nov 2009 i kolonne 2 eller 3 og suppleret med noter herom. Afsnit 7.1 Alle kapitler 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 1
2 Faseopdeling af samspillet mellem nyt BBR og nuværende BBR 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" 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 2
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. 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. Kapitel 6 afsnittet omkring OIOXML-snitflader For dokumentation af Kontrakt for videreførsel af KMD-BBR december kravene i KS kapitel 2 2007 henviser KMD til "Kontrakt for videreførsel af KMD- BBR december 2007" 3 Reg. af BBR-data i BBR - 3.1 Reg. Bygværker o.l. - 3.1.1 BBR-data vedrørende bygværker under opførelse og færdige bygværker skal registreres i BBR på 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. 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 3
3.1.2 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. 3.1.3 Ved afslutning af et byggeri opdateres stamdata med sagsdata, og statuskoden for byggesagen ændres til afsluttet byggesag (statuskode 4). Sagsdata slettes ikke. 3.1.4 Sagsnummer (journalnummer og/eller link til sagsdokumenter (ESDH)) og initialer skal fremgå af sagsdata på alle entiteter, herunder adresser. 3.1.5 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. Afsnit 4.3.1 3.1.6 Alle registreringer af BBR-data skal på felt-niveau indeholde tidsstempling og kildeko-de (brugerid) fra seneste registre-ring/ajourføring. 3.1.7 Ved opslag i BBR, fgodkendt nov 2009 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 ). 3.1.8 Der skal for de enkelte kommuner være mulighed for at oprette frivillige felter i hver entitet, fgodkendt nov 2009 for at kunne registrere lokale, administrative forhold i BBR. For hvert felt i databasen påhæftes et tooltip. Som udgangspunkt vises disse tooltip indehold tags for ændringsdato og kildekode. 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 8.1 Afsnit 8.1 Afsnit 4.3.8 Afsnit 8.1 3.2 Registrering af adresser - 3.2.1 BBR-data vedrørende adresser under behandling og fastsatte/ godkendte adresser skal kunne registreres (dvs. oprettes og opdateres) selvstændigt i BBR på følgende niveauer (entiteter), jf. tillæg A til kravspecifikationen: Adgangsadresse, betegnet AAD Enhedsadresse, betegnet EAD. Afsnit 3.1.2 Afsnit 4.3.1.4 Afsnit 4.3.3 Afsnit 7.1.5 Afsnit 7.1.6 Afsnit 7.2 3.2.2 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. Afsnit 3.1.2 Afsnit 4.3.3 Afsnit 7.2 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 4
3.2.3 For adresser skal der efter samme principper og med samme kodeværdier som i krav 3.1.2 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 4 3.2.4 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. 3.2.5 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. Afsnit 3.1.2 Afsnit 7.1.5 Afsnit 7.1.6 Afsnit 7.2 Afsnit 3.1.2 Afsnit 7.1.5 Afsnit 7.1.6 Afsnit 7.2 Afsnit 7.1.5 Afsnit 7.1.6 4 Opdatering af BBR-data i BBR - 4.1 Byggesagsbehandling og løbende ændringer - 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). Kapitel 3 Kapitel 4 4.1.2 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 OIOXML-format (BBR-kommuneklient). Manuelt vha. af en browserbaseret brugergrænseflade (BBR-brugerklient). 4.1.3 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. Se bilag 17 for beskrivelse af Borgerindberetningsoptionen. Kapitel 2 Afsnit 3.2 Kapitel 4 Afsnit 6.2 Afsnit 9.1 Afsnit 9.2 Option ikke valgt og derfor ikke beskrevet. 4.1.4 Meddelelse om indflytning skal ikke afslutte byggesagen. Skal overføre enheden til stamdata, men bevare bygningen som sagsdata. 4.1.5 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. 4.1.6 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. Jf. ÆF 71 bortfalder kravet om parameterstyring af kl.asse 2-oplysninger. Afsnit 4.3.1.1 4.1.7 Fejlagtige data skal kunne slettes af den kommunale bruger (med rettighed hertil). Kapitel 4 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 5
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 4.1.8 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. I forbindelse med senere drøftelser af modtageboks-funktionalitet skal det analyseres hvorledes en løsning, hvor kommunen benytter modtagerboksen for at sende bygningens eller husbådens oplysninger til den nye kommune, kan implementeres, således at det udelukkende vil være tildeling af adresse, vand, varme mv. som sagsbehandleren i tilflytter-kommunen skal tage stilling til. Hertil kommer at problematik omkring historik skal vurderes. 4.1.9 Der skal kunne etableres links til andre relevante registre, fgodkendt nov 2009 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 4.1.1.3 Afsnit 4.3.9 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 6
4.1.10 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 således: Kravet er præciseret i præciseringsnotatets punkt 13. 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. 4.1.11 Ved overskridelse af tidsfrister for midlertidige tilladelser skal der være mulighed for en påmindelse. 4.1.12 Opdatering af BBR skal være underkastet validering og kvalitetssikring af de aktuelle BBRdata (se kravspecifikationens punkt 11). 4.2 Registrering og opdatering af adresser og adressedata - 4.2.1 Følgende BBR-adressedata skal registreres og opdateres (ajourføres) i BBR: Alle sagsdata for adresser, som er under sagsbehandling 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). AAD.99 og EAD.99 udgår. Dette krav blev godkendt november 2009 med forbehold for udeståendet omkring klassifikation. Dette forhold er nu bragt i orden (jf. ÆF 55) og kravet bør derfor kunne lukkes. Afsnit 6.5.7.2 Afsnit 3.3.1 Afsnit 3.3.2 Afsnit 3.3.3 Afsnit 3.3.4 Bilag A, B, C og D til kapitel 3 Kapitel 3 Afsnit 4.3.3 Afsnit 4.3.1.4 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. 4.2.3 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). 4.2.4 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. 4.2.5 Den i krav 4.2.3 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. 4.2.6 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. Option ikke valgt og derfor ikke beskrevet. 4.3 Enkeltopdateringer - Kapitel 4 Kapitel 2 Afsnit 3.2 Afsnit 6.2 Afsnit 9.1 Afsnit 6.5.8 - Afsnit 3.3.1 Afsnit 3.3.2 Afsnit 3.3.3 Afsnit 3.3.4 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 7
4.3.1 Ejeres indberetning af specifikke BBR-data til godkendelse i kommunen skal kunne ske via opkobling til Den Offentlige Informationsserver (OIS), hvor der foretages adgangskontrol eller en anden tilsvarende tjeneste med en standardiseret snitflade. Efter godkendelse i kommunen skal BBR-data kunne overføres direkte til BBR og opdatere BBR. Leverandøren forudsætter, at der med opkobling til OIS menes at ejeren benytter den facilitet i OIS, der i dag giver mulighed 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. Jf. ændringsforslag 57 bortfalder dette krav. 4.3.2 Der skal etableres en kommunal modtageboks for indberetning af ændringer, der modtages via en standardiseret snitflade. Alle indberetninger skal kunne gemmes. 4.3.3 Kommunen skal have mulighed for at videresende oplysningerne til en anden afdeling i kommunen, inden der foretages opdatering i BBR. 4.3.4 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 e-mail til den pågældende ejer. Sagsbehandleren sender en mail til øvrige i kommunen med oplysninger fra indberetningen. Mailafsendelse håndteres via forretningslogikkens Meddelelses-system. Jf. ændringsforslag 68 erstattes dette krav (krav 4.3.2.) af kravspecifikationen i ændringsforslag 68. Jf. ændringsforslag 68 erstattes dette krav (krav 4.3.3.) af kravspecifikationen i ændringsforslag 68. Jf. ændringsforslag 57 bortfalder dette krav. - - 4.3.5 Efter kommunens godkendelse eller afvisning af de indberettede BBR-data fremsendes en e- mail til ejeren herom. Hvis kommunen godkender de indberettede BBR-data, vedhæftes en ny BBR-meddelelse med ændringsmarkering. Kravet er præciseret således: Efter kommunens godkendelse eller afvisning af de indberettede BBR-data fremsendes en e- mail 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) 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 e-mail adresse. Jf. ændringsforslag 57 bortfalder dette krav. Kravet er præciseret i præciseringsnotatets punkt 15. (Præcisering nr. 15 udgår jf. Ændringsforslag 57.) Afsnit 4.3.4 4.4 Systematisk opdatering - 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 8
4.4.1 Det skal være muligt at foretage systematisk opdatering af BBR-data ved onlinefiloverførsel af data i OIOXML-format. Der skal med henblik herpå etableres særlige skærmbilleder med adgangskontrol (OCES). Kravet er præciseret jv. præcisering nr. 28. Kapitel 9.1 Kravet er præciseret således: Der etableres ikke skærmbilleder, da opdateringen sker via OIO-XML-snitfladerne. Adgangen til disse snitflader (webservices) sker via roller som den enkelte kommune administrerer vha. fanebladet Brugeradministration i BBR-Kommune. 4.4.2 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. 4.4.3 Kommunen skal kunne tildele eksterne parter rettighed til at indberette og ajourføre specifikke BBR-data (felter). 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. Afsnit 9.1 Kapitel 9 4.4.4 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 e-mail. Det forudsættes, at BBR har modtaget valid e-mail adresse på den eksterne part. Kravet er præciseret jv. præcisering nr. 26. Kapitel 3 Kapitel 6 Kravet er præciseret således: Der sendes ikke nogen e-mail, da der sendes online besked. Det er en gængs fremgangsmåde, når der benyttes webservices. 4.4.5 BBR-data, der indberettes systematisk i BBR, skal forsynes med kildekode samt dato ved Kapitel 3 opdatering af BBR. 4.4.6 Systematisk opdatering af BBR skal ikke automatisk medføre udskrivning af BBR- Afsnit 5.6.3 Meddelelser. 4.5 Masseopdatering - NB til 4.5 Kravene omkring masseopdatering (kravene i afsnit 4.5) forstås således, at masseopdatering kan være landsdækkende. Det er den eneste forskel i forhold til kravene i afsnit 4.4 om systematisk opdatering. Denne præcisering sker under forudsætning af at de underliggende krav ikke tilsidesættes. Denne række er en præcisering til hele afsnit 4.5. Præciseringsnotatet punkt 1. Desuden kan det tillige her påpeges, at de enkelte kommuner også kan foretage masseopdatering. 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 9
4.5.1 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). Kravet er præciseret således: Det forventes, at masseopdateringer vil ske i batch-vinduer, således at svartiderne ikke belastes i den almindelige arbejdstid. Kravet er præciseret jv. præcisering nr. 27. Kapitel 6 Der etableres ikke skærmbilleder, da opdateringen sker via OIOXML-snitfladerne. Adgangen til disse snitflader (webservices) sker via roller som den enkelte kommune administrerer vha. fanebladet Brugeradministration i BBR-Kommune. 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 6 4.5.3 Det skal også være muligt at masseopdatere øvrige BBR-data i klasse 1 og 2 Kapitel 6 4.5.4 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 e-mail. Det forudsættes, at BBR har modtaget valid e-mail adresse på den eksterne part. Kravet er præciseret jf. præcisering nr. 25. Kapitel 3 Kapitel 6 Kravet er præciseret således: Der sendes ikke nogen e-mail, da der sendes online besked. Det er en gængs fremgangsmåde, når der nyttes webservices. 4.5.5 BBR-data, der indberettes ved masseopdatering i BBR, skal forsynes med kildekode samt Kapitel 3 dato ved opdatering af BBR. 4.5.6 Masseopdatering af BBR skal ikke automatisk medføre udskrivning af BBR-Meddelelser. Afsnit 5.6.1 5 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. Landsejerlavskode, - matrikelbetegnelser og matrikelkoordianter hentes via webservices fra KMS (pånær København og Frederiksberg hvor der er særskilte webservices) 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. 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 10
5.1.1 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. 5.1.2 Ved opslag med et matrikelnummer i BBR skal det tilhørende landsejerlavsnavn være tilgængeligt i BBR. Leverandøren forudsætter, at der er faciliteter til rådighed, som kan sikre opdaterede landsejerlavsnavne i BBR. Afsnit 6.5.3 Kapitel 6 5.1.3 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. 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). Kravet er ændret som beskrevet i ændringsforslag 32. Kapitel 6 Afsnit 6.5.2 5.1.5 Der skal i BBR etableres relationer til ESR for entiteterne Bygning (BYG), Enhed (ENH), adgangsadresse (AAD) og Grund (GRU). 5.1.6 Æ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. 5.1.7 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 Kravet er ændret med ændringsforslag 29. Kapitel 6 5.1.8 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 OIOXML-snitflade. Det forudsættes, at servicen er til rådighed i MATR og ESR. 5.1.9 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 Kapitel 6 Kapitel 6 5.1.10 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. Kapitel 6 5.2 Dataudveksling mellem BBR og CPR 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". 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 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 CPRkontoret 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 CPRkontoret stille en kopi med daglige ændringer i vejregistret til rådighed for BBR med henblik på opdateringer. 5.2.2 Registrering eller opdatering af et eller flere datafelter, der indgår i BBR/CPRstandardtransaktion, skal resultere i dannelse af en BBR/CPR-standardtransaktion med tilhørende transaktionskode, jf. kravspecifikationens punkt 5.2.3. Krav 5.2.2 bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". - 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 12
5.2.3 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/CPRstandardtransaktioner. Filoverførsler finder sted én gang i døgnet på hverdage mandag til fredag. Krav 5.2.3 bortfalder (lige som hele afsnit 5.2.3 i kravspecifikationen) jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". - 5.2.4 BBR/CPR-standardtransaktioner, der modtages fra CPR, skal behandles iht. transaktionskoderne i kravspecifikationens punkt 5.2.3. Krav 5.2.4 bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". - 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/CPRstandardtransaktion. Boligtypekoden, enhedsarealer og antal værelser skal kunne rekvireres af CPR ved en BBR/CPR-standardtransaktion med transaktionskode R. Krav 5.2.5 bortfalder (hvad angår rekvisition af boligtypekoden) jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". 5.2.6 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/CPRstandardtransaktion. 5.2.7 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. Sætningen omkring standardtransaktioner bortfalder jv. notatet "ændringer i dataudvekslingen mellem NYT BBR og CPR." Her står nævnt at de krav ene omkring standardtransaktionerne bortfalder. Kapitel 3 Bilag D Afsnit 10.6 Kravet er løst i XML Afsnit 10.6 Kravet løses i OIOXML 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 13
5.2.8 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. Kravet er præciseret således: Krav 5.2.8 er løst med to faste rapporter, som er en del af de 10 faste rapporter, der blev leveret til idriftsættelse d. 1.12.2009. Derfor blev krav 8.2 ved overtagelsesprøven i november godkendt med forbehold for, at der leveres yderligere 2 faste rapporter for at opfylde kravet om 10 faste rapporter. Disse rapporter bliver Bestandsoptælling og Brugeradministration, som beskrives i særskilt løsningsbeskrivelse. Kravet er præciseret i præcisering nr. 29. Se desuden 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 5.2.9 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 5.2.9 bortfalder jf. notatet "Ændringer i dataudvekslingen mellem NYT BBR og CPR". - 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 14
5.2.10 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 5.2.10 i tilfælde af en lovændring af administra-tive grænser (kommunegrænser) fgodkendt nov 2009 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 forekom-ster af kommunenummer. Nyt BBR s data kan læses og opdateres via SQL-scripts i forbindelse med batchopdateringer. Eventuelle implementerede forretningsregler relateret til kommunetilhørsforhold kan disables i forbin-delse 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 SQLscripts. 5.2.11 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 3.3.2 Afsnit 4.5 5.3 Samkøring af CPR, ESR og BBR vedrørende koden 'Udlejningsforhold 2' Krav 5.3 er ændret jf. Allonge 1, appendiks 3: "Ændringer i dataudvekslingen mellem NYT BBR og CPR" - 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 15
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 6.5.5 pkt. 3 5.3.2 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". Kapitel 3, bilag C Afsnit 7.1.3 5.3.3 Opdatering af koden Udlejningsforhold 2 skal være underkastet validering og kvalitetssikring. Se notat "Ændringer i dataudvekslingen mellem NYT BBR og CPR" Afsnit 7.1.3 5.4 Samordning af ejerforholdskoden og overførsel af tinglyst areal - 5.4.1 Ved indberetning af ejerforholdskoden i BBR skal det være muligt at hente koden i ESR på grundlag af oplysninger om: Ejendomsnummer Matrikelnummer. 5.4.2 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. 5.4.3 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. 5.4.4 Opdatering af ejerforholdskoden skal være underkastet validering og kvalitetssikring. 5.4.5 Tinglyst areal for ejerlejligheder registreres i ESR og skal - efter kommunens eget valg - kunne overføres fra ESR til BBR (parameterstyret). Leverandøren forudsætter, at ESR stiller en webservice til rådighed, der kan levere ejerforholdskoden. Leverandøren forudsætter, at ESR stiller en webservice til rådighed, der kan levere ejerforholdskoden. Kapitel 6 Kapitel 3 Kapitel 6 Kapitel 6 Kapitel 6 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 16
6 Udtræk samt overførsel af enkelte datafelter - 6.1 Den Offentlige Informationsserver - 6.1.1 Der skal dagligt foretages onlineoverførsel af replikerede, landsdækkende BBR-data til OIS omfattende alle BBR-data i klasse 0, 1 og 2. 6.1.2 Online overførsel af BBR-data skal ske ved filoverførsel, som beskrevet i snitfladebeskrivelsen for OIS datavært (OIS_Dbvaert_Godkendt juni 2010 ML_Snitflade_v_121.doc). Der foretages overførsel af ændrede BBR-data. Der vil blive afleveret efter det i bilag 2, tillæg C viste format. Jf. ændringsforslag 56 er dette krav ændret. Kapitel 6 afsnittet omkring udtræk 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" (jf. appendiks 3 i allonge 1 i leverance-kontrakten.). - 6.2.1 Onlineenkeltopslag og overførsel af enkelte datafelter - 6.2.1.1 Det skal for brugere med adgangsrettighed hertil være muligt at foretage enkeltopslag i BBRdata ved hjælp af gængse internet-browsere. Afsnit 9.2 Adgangskontrollen skal være baseret på digital signatur. 6.2.1.2 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 senere skal der være mulighed for en OIOGodkendt juni 2010 ML-fil. Kravet er præciseret således: Medarbejderne hos Skat skal have læseadgang til www.bbr-kommune.dk 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 Dette krav blev godkendt i november 2009 med forbehold for OIOGodkendt juni 2010 ML-snitfladerne. Afsnit 7.2 6.2.1.3 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 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. Kravet ændret jf. præcisering nr. 3 Dette krav er ændret Jf. ændringsforslag 68. Kapitel 9 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 17
6.2.1.4 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 7 Dette krav blev godkendt i november 2009 med forbehold for OIOXMLsnitfladerne. 6.2.1.5 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. Der stilles et næsten tidstro datawarehouse til rådighed, som indeholder de reelle entiteter og cuber, der benyttes til udtræk og rapporter Kapitel 10 6.2.1.6 Søgning på BBR-data skal kunne ske med ejendomsnummer, matrikelbetegnelse, adgangseller enhedsadres-se, bygnings- eller anlægsnummer samt rumnummer. 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. 30. Kapitel 4 6.2.1.7 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). Jf. ændringsforslag 58 bortfalder dette krav. 6.2.2 Masseudtræk - 6.2.2.1 Det skal være muligt at fremstille komplette kopier af BBR samt at overføre disse elektronisk Kravet er præciseret jf. til myndigheder m.fl. både i OIOXML-format og i andre gængse formater, der aftales særskilt præcisering nr. 24. med modtagerne. Kravet er præciseret således: Med udtrykket gængse formater menes der CSV og XML. 6.2.2.2 Skat skal mindst én gang årligt (p.t. 1.10.) online have overført en totalkopi af landsdækkende BBR-data (stamdata). P.t. sker dette i form af en flad fil, men senere skal der være mulighed for en OIOXML-fil. 6.2.2.3 Der skal hvert år afleveres en komplet kopi af landsdækkende BBR-data (stamdata). 6.2.2.4 Formatet skal overholde krav fra Statens Arkiver. 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 18
6.2.2.5 Danmarks Statistik skal kunne foretage onlineudtræk af landsdækkende BBR-data (såvel stamdata som sagsdata) med statuskode 1, 2, 3 og 4 som beskrevet i ÆF 70. (Se den samlede kravspecifkation i ÆF 70). Det forudsættes, at der med Ifølge mail fra den 6. maj Afsnit 4.3.1.5 foretage online udtræk forstås, 2010 har EBST/Danmarks at rekvirering af udtræk kan foretages online. Der stilles et skærmbillede til rådighed, hvor Statistik accepteret at der ikke er behov for et bestillingsskærmbillede. 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. 6.2.2.6 EBST skal månedligt samt ad hoc efter rekvisition online modtage en totalkopi af landsdækkende BBR-data (stamdata og sagsdata). Dette skal ske i form af en flad fil, fx i EBCDIC-format, men senere skal der være mulighed for en OIOXML-fil. Udtræk vil kunne ske i form at flade filer, f.eks. i csv-format, men ikke i mainframe baserede EBCDIC-format. 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 19
7 Krav til udskrift af BBR-data (BBR-Meddelelser) Jvf. Allonge 1: Krav til landsdækkende udskrift af BBRmeddelelser 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. 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. Kapitel 5 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 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 20
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. Det forudsættes, at ESR stiller en service til rådighed, der kan levere disse data online. Afsnit 6.5.3 - snitflade 10 Se notat "Ændringer af dataudveksling mellem NYT BBR og CPR". 7.3 Kommunen skal kunne fravælge en totaludskrift ved afslutningen af en byggesag. Afsnit 5.3 7.4 Der skal kunne udskrives BBR-andelsboligmeddelelser efter rekvisition fra lejere og andelshavere. 7.5 Udskrivning af BBR-meddelelser og BBR-andelsboligmeddelelser skal desuden kunne ske efter anmodning fra kommunen med individuelt tilpassede årsagskoder 7.6 Sagsbehandleren skal kunne fremfinde information om hvornår seneste BBR-Meddelelse er udskrevet, samt årsag til udskrivning. Kravet er blevet ændret som beskrevet i ændringsforslag 19. Kravet er blevet ændret som beskrevet i ændringsforslag 19. Kravet er ændret som beskrevet i ændringsforslag 20. Afsnit 5.4 Afsnit 5.4 Afsnit 10.3.1 Rapport 2 7.7 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 5.12 7.8 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 5.5 7.9 Alle ændringer siden sidste udskrift skal vises med kursiv på BBR-Meddelelsen. Kravet er ændret som beskrevet i ændringsforslag 22. 7.10 Masseudskrivning af BBR-Meddelelser skal kunne ske for bygninger med bestemte karakteristika, fgodkendt nov 2009 styret af anvendelseskoden (BYG.22). 7.11 Der skal udskrives BBR-Meddelelser for: En vurderingsejendom En grund (matrikulær ejendom) En enhed/ejerlejlighed/andelsbolig Bygning. Afsnit 5.12 Afsnit 5.4.2 Afsnit 5.4.1 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 21
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 5.12 7.13 BBR-Meddelelse eller BBR-Andelsboligmeddelelsee skal kunne udsendes via e-mail eller E- boks i PDF-format med et følgebrev (kommunespecifikt bilag) og kunne kobles til Skattemappen. Et kommunespecifikt bilag som skal vedhæftes BBR-Meddelelsen indsendes til KMD Service, som sørger for at det bliver videregivet og klargjort til såvel centralt print, e-boks og forsendelse pr. mail. Det kommunespecifikke bilag vedhæftes derefter som standard alle udskrevne BBR- Meddelelser, uanset om der er tale om centralt print, forsendelse med mail eller e-boks. Ved mail påhæftes det kommunespecifikke bilag automatisk, men via et flueben kan sagsbehandleren fjerne det så det ikke kommer med i mailen. Afsnit 5.4.3.4 Kravet er ændret jf. ÆF 60. Dette krav blev godkendt november 2009 med forbehold for kobling til Skattemappen. Det skal afklares hvad der skal forstås ved følgebrev. 7.14 Modtagere af BBR-Meddelelser/ BBR-andelsboligmeddelelser skal have mulighed for at indberette rettelser i en PDF-blanket vedhæftet BBR-ejermeddelelelsen/BBR-andelsboligmeddelelsen og at returnere blanketten elektronisk til kommunen (SOA-baseret). Kravet er præciseret således: I forlængelse af Ændringsforslag 57 har modtagere af BBR-Meddelelser ikke mulighed for at indberette rettelser i en PDF-blanket vedhæftet BBR-Meddelelser. Sådanne rettelser kan indberettes via de generelle OIOXML-snitflader. 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. Kravet er præciseret i præciseringsnotatets punkt 23. 7.15 BBR-Meddelelser/BBR-andelsboligmeddelelser skal kunne udskrives decentralt i kommunen på en printer, der stilles til rådighed af kommunen. 7.16 Uanset datoer registreres i BBR i formatet ååååmmdd, skal datoer på BBR-meddelelser mv. fremtræde som dd-mm-åååå. Afsnit 5.1.2 Afsnit 5.12 11 - Overensstemmelsesmatrix krav systembeskrivelse - v 7.0_06122010.xlsx 22