Boligdok har lige passeret sin ét års fødselsdag, og i den anledning har vi opdateret vores grafiske udtryk og fået ny hjemmeside. Vi håber du synes om det. Nyhederne blev tidligere fremsendt som pdf-dokument med mail. Fra nu af lægges de på hjemmesiden, som vi sender et link til, så ved I altid hvor de kan findes.
Der er i parantes i overskriften angivet hvem rettelsen/udvidelsen er relevant for. MG: bestiller/mæglersystem, FS: forsikringsselskab, BS: bygningssagkyndig.
Der har været en del mangler i hvad der blev parset til xml fra tilstandsrapporten. Disse mangler er blev udbedret, og der parses nu disse rapportelementer:
Punkterne 1 – 5 har altid være med, men 4 er gjort mere robust, og 5 har bl.a. fået tilføjet bygningsreference. 6 – 8 er blevet tilføjet. Data fra sektionerne opmærksomhedspunkter og tagets restlevetid er ikke med i xml-filen. Forbedring af 4 har gjort at vi nu har meget stor tillid til arealdata fra rapporten.
Vi skrev i sidste nyhedsbrev om vores bestræbelser på at få mulighed for bedre compliance-håndtering gennem indhentning af salgsstatus.
API-et for mæglersystemer er blevet udvidet med en funktion til at meddele når ejendommen er solgt eller taget ud (/api/maegler/salg/{sagsnummer}).
Bestillingsinformationerne er udvidet med felterne salgsStatus og salgsStatusDato til at indeholde statusinformationen. Salgsstatus er AKTIV indtil det er meddelt om andet. Når den er aktiv, er salgsStatusDato sagens oprettelsesdato i Boligdok.
I løbet af efteråret forventer vi at begynde at opdatere salgsStatus på baggrund af tinglysningsforespørgsler, og på længere sigt håber vi at mæglersystemerne vil implementere funktionen.
Ændring i salgsstatus vil blive meddelt gennem eventkøen, der er under lancering. Se længere nede.
Ejendomsinformationerne er udvidet med dawa id. AWS/DAWA er overgået til Dataforsyningen, så det er muligt det er en forældet betegnelse. Dermed slipper API-brugerne for at finde denne, hvis I bruger informationer derfra, som ikke leveres af Boligdok. Vi bruger en algoritme, der er ganske god til at udrede problemer med adresserne sendt fra mæglerne, men der kan i sjældne tilfælde forekomme at vi ikke kan finde det oplyste i AWS/DAWA, derfor kan I ikke være 100% sikre på at der altid er et id, men hvis det mangler, er det fordi den oplyste adresse ikke er entydig. Det vil typisk være på lejligheder, hvor etage ikke er angivet.
El-rapportens nummer samt dato er med i API ‘ets bestillingsinformationer, hvis der er en el-rapport. Vi har fundet at i visse alternative tilbudsbestillinger blev denne information ikke udtrukket og medtaget. Dette er nu rettet.
Brugermodellen i Boligdok har hidtil kun kunnet håndtere fleksibel adgang for forsikringsselskaber og bygningssagkyndige. Modellen er nu udvidet så også bestillere, som f.eks. mæglersystemleverandører, kan gives adgang. Dette giver bl.a. mulighed for at systemleverandørerne bedre kan supportere deres kunder.
Der er forsikringsselskaber, der modtager bestillinger gennem Boligdok, men som bruger et andet selskab til at levere ejerskifteforsikring. Bygningssagkyndige har efterspurgt at få information om hvem der er ejerskifteleverandør for en given bestilling. Derfor er API ‘ets bestillingsinformationer udvidet med feltet ejerskifteForsikringsselskabId. Feltet vil altid være udfyldt. Hvis selskabet ikke benytter anden leverandør, vil indholdet være det samme som i feltet forsikringsselskab.
I sidste nyhedsbrev beskrev vi vores arbejde med at introducere en kø-baseret meddelelsesstruktur. Vi er ved at have udviklet løsning klar i version 1. Vi skriver særskilt til jer om dette, når vi er klar. Vi modtager meget gerne henvendelse om forhåndsinteresse.
