E-BUSINESS SOLUTIONS FROM CSC 6 e-tl Motor Løsningsspecifikation: e-tl motor Dokumentoplysninger Titel: Projekt: e-tl Løsningsspecifikation, Intern portal e-tl (Elektronisk Tinglysning) Placering: C:\prj\etl-doc\Documentation\TOC\06 Løsningsspecifikation e- TL motor v.0.doc Ikrafttrædelse: 24. april 2007 Forfatter: Freddie Blom Hansen Bidragydere til dokumentet: Line Palmqvist Godkendt af: Domstolsstyrelsen Fordeling: Udskrevet: e-tl projektet
E-BUSINESS SOLUTIONS FROM CSC 6 e-tl Motor Løsningsspecifikation: e-tl motor Ændringslog Version Dato Ændrede sider eller afsnit Kommentarer.0 2.05.2007 Første udgave. Endeligt godkendt af Domstolsstyrelsen. Fremsendes til Domstolsstyrelsen
E-BUSINESS SOLUTIONS FROM CSC 6 e-tl Motor Løsningsspecifikation: e-tl motor 6 e-tl Motor Indholdsfortegnelse 6 e-tl Motor... 6. Formål... 3 6.2 e-tl Motor... 3 6.2. Orkestrering... 3 6.2.2 Modtagelse af anmeldelse... 6 6.2.3 Behandling af anmeldelse...3 6.2.4 Afslutning af anmeldelse...5 6.2.5 Forespørgsler...8 6.2.6 Faste kørsler...3 6.3 e-tl akt database...32 6.3. Nøgler og Indeks...33 6.3.2 Stamdata om objekterne...33 6.3.3 Summariske rettigheder...40 6.3.4 Anmeldelser i original form...4 6.3.5 Anmeldelser i strukturel form...45 6.4 Snitflader til eksterne dataleverandører...48 6.4. Generelle principper...49 6.4.2 CPR...50 6.4.3 CVR...54 6.4.4 CRM / DMR...56 6.4.5 ESR...60 6.4.6 KMS (afklaring afventer Møde med KMS)...72
E-BUSINESS SOLUTIONS FROM CSC 6 e-tl Motor Løsningsspecifikation: e-tl motor 6.4.7 SKAT...73 6.5 Interne e-tl snitflader...79 6.5. XML repræsentation af anmeldelse og tinglysningsdokumentet...79 6.5.2 Eksempel... 05 6.6 Hæftelser... 06 6.6. Indledning... 06 6.6.2 Anmeldelse af hæftelser... 07 6.6.3 Struktur for pantebreve... 08 6.6.4 Generelle pantebrevsoplysninger... 09 6.6.5 Realkreditpantebrev... 5 6.6.6 Ejerpantebrev... 6 6.6.7 Privat pantebrev... 6 6.6.8 Skadesløsbrev... 6 6.6.9 Privat indekspantebrev... 7 6.6.0 Høstpantebrev... 7 6.7 Brugerformularer... 8 6.7. Indledning... 8 6.7.2 Model... 20 6.7.3 Brugerformular XML-dokument... 22 6.7.4 Brugerformular XML-skema... 23 6.7.5 Proces og Use-Cases... 23 6.7.6 Services... 25 6.8 Afgiftsberegning... 25 6.8. Tinglysningsafgift... 25 6.8.2 Retsafgift... 3 6.9 Status- og driftsinformation (Mangler afklaring)... 33 6.9. Driftsstatistikker... 33 6.9.2 Svartidsovervågning... 33 6.9.3 Sikkerhedsauditering... 33 6.9.4 Logning... 33 6.0 Konvertering (leveres.4.2007)... 33
6. Formål Løsningsspecifikationen for e-tl motoren beskriver, hvordan motoren håndterer anmeldelser, forespørgsler og faste kørsler. Ligeledes beskrives motorens database samt snitflader til eksterne dataleverandører. Endelig beskrives interne snitflader mellem motor og portalerne samt snitflader til processer / kontroller, der udgør tværgående funktionalitet, som understøtter såvel portalerne og motoren. 6.2 e-tl Motor Portalerne opsamler gennem trinvis dialog - data til anmeldelser og forespørgsler, som overgives til behandling i e-tl motoren: Anmeldelser behandles ved gennemløb af den tinglysningsmæssige proces modtagelse (afsnit 6.2.2 modtagelse), prøvelse (afsnit 6.2.3 - behandling) og offentliggørelse (afsnit 6.2.4 - afslutning) af tinglysningsdokumenter. Forespørgsler behandles ved at returnere summariske oplysninger om det søgte 6.2. Orkestrering Dette afsnit beskriver den overordnede orkestrering af tinglysningsprocessen i e-tl motor, der fører en anmeldelse gennem de 3 fundamentale skridt modtagelse, prøvelse og offentliggørelse. 6.2.3 Modtagelse af anmeldelse 6.2.4 Behandling af anmeldelse 6.2.5 Afslutning af anmeldelse Figur : De 3 fundamentale processer I kravbilag 2B er den overordnede proces beskrevet ved BPMN notation med fokus på centrale kontroller, der udgør processen. Fra et design- og implementeringssynspunkt udgør BPMN modellen en logisk beskrivelse af processen, der tilpasses de konkrete implementeringsmæssige forhold dog således at ånden i den oprindelige proces bevares. Løsningsspecifikation: e-tl motor, v..0 Side 3 af 35
De 3 overordnede skridt i denne opdeling af den overordnede proces svarer til de fundamentale skridt i tinglysningsprocessen modtagelse, prøvelse og offentliggørelse. Til at samle den overordnede proces har vi kontrollen TinglysAnmeld (implementeret som TinglysAnmeldService), der vil være den service system-system brugere samt portalerne tilgår ved anmeldelsen af et tinglysningsdokument. TinglysAnmeldService vil modtage et tinglysningsdokument i XML format, i henhold til XML skemaet for tinglysningsdokumentet. Figur 2: Hovedprocessen og datalag viser hovedprocessen, som den implementeres i e- tinglysning, sammen med en skitse af de datalag der indgår i processen. Den detaljerede beskrivelse af de 3 proces skridt findes i afsnit 6.2.2, 6.2.3 og 6.2.4. Kontekst Modtagelse Prøvelse Offentliggørelse Anmeldelse Stamdata Berigelse / Påtegning Summariske DOCSTORE Figur 2: Hovedprocessen og datalag I e-tinglysning findes der 3 overordnede services svarende til de 3 hovedskridt for den overordnede tinglysningsproces: ModtagelseService Indeholder de funktioner og kontroller svarende til det røde område markeret i Figur : De 3 fundamentale processer. Detaljer for servicen er beskrevet i afsnit 6.2.2. PrøvelseService Indeholder implementationen af den tinglysningsmæssige prøvelse, hvor anmeldelsen udsættes for et antal specifikke kontroller afhængig af den/de ekspeditionstyper, der indgår i anmeldelsen. Visse kontroller kalder servivemoduler som henter data fra eksterne dataleverandører som f.eks. CPR og CVR, nærmere herom i afsnit 6.4.. Servicen dækker det område, der modsvares af det gule område i Figur. Det overordnede princip for PrøvelseService er baseret på princippet beskrevet i kravbilag 2B afsnit.3 Alternativ løsningsmodel, hvor servicen baseret på konfiguration bestemmer den næste service, hvorefter den udføres. Detaljerne for PrøvelseService er beskrevet i detaljer i afsnit 6.2.3 Behandling af anmeldelse. OffentliggørService Udgør den del af den overordnede proces markeret med grønt i Figur. Den centrale del af servicen er håndtering af AktRegistrer efterfulgt af den egentlige Løsningsspecifikation: e-tl motor, v..0 Side 4 af 35
tekniske offentliggørelse. Detaljerne for OffentliggørService er beskrevet i afsnit 6.2.4 Afslutning af anmeldelse. I forhold til den oprindelige BPMN procesmodel dækker de enkelte (overordnede) services beskrevet i dette afsnit: ModtagelseService KontrolModtag Modtagelse inklusiv schema validering af det modtagne XML dokument, efterfulgt af permanent lagring af det originale XML dokument i e-tl DOCSTORE. LøbenrTildel Tildeling af dato/løbenummer for tinglysningsdokumentet. KontrolAnmeld Basale kontroller af anmeldelsen inden den godkendes til fortsætte gennem de kontroller, der udgør den egentlige tinglysningsmæssige prøvelse. Dette inkluderer de kontroller, der på overordnet niveau udgøres af KontrolAnmeld, KontrolAnmeld2, KontrolFindIdent og KontrolHæftelseKonverteret. PrøvelseService TinglysUdfør Implementeringen af udførelsen af de enkelte kontroller, der indgår i den tinglysningsmæssige prøvelse efter modellen beskrevet i kravbilag 2B, afsnit.3. KontrolAfgift En kontrol, der udføres i det omfang anmeldelsen skal indeholde afgiftspligtige elementer. Selv om kontrollen er indeholdt i det område, der udgør den tinglysningsmæssige prøvelse, er den separat beskrevet i afsnittet 6.8 Afgiftsberegning. PrøveTinglys Opsamling og returnering af resultat af prøvetinglysningen, hvis tinglysningsdokumentet er markeret som en prøvetinglysning. Resultat kan indeholde oplysning om forventet manuel behandling og årsag dertil ManuelUdtag Opsamling af information og overdragelse til BPM Workflow motoren, hvis de øvrige kontroller har markeret anmeldelsen som kandidat for manuel behandling. OffentliggørService AktRegistrer Registrerer resultatet af prøvelsen i form af statusmarkering på tinglysningsdokumentet, permanent lagring af de berigede informationer opsamlet under prøvelsen, samt registrering af den endelige påtegning. Herudover opsamles summariske informationer til e-akten for at muliggøre effektiv søgning samt dannelse af data til AktHent. TinglysMeddel Udsend meddelelser til interessenter som specificeret i anmeldelsen via meddelelses- og separatadresser. TinglysOffentliggør Udsend information til faste interessenter Beliggenhedskommune samt SKAT samt advis til abonnenter, der har registreret abonnement på konkrete tinglysningsmæssige hændelser for en eller flere af de objekter og eventuelt begrænset til type af rettighed, som anmeldelsen vedrører. De kontroller, der indgår i den overordnede proces, arbejder på forskellige data i processens forløb alt afhængig af deres rolle i processen. De forskellige typer/niveauer af data er ligeledes skitseret i 6.3.5: o DOCSTORE Her gemmes de originale dokumenter i deres oprindelige form. Således optræder dokumenterne her som en slags elektroniske originalbilag. Det elektroniske bilagsarkiv er yderligere beskrevet i afsnit 6.3.4 Anmeldelser i original form. o Anmeldelse I dette logiske datalag dannes en objektrepræsentation af anmeldelser, således at kontrollerne har en konkret objekt-orienteret repræsentation af anmeldelsen at arbejde på. Repræsentationen her udgør således en strukturel repræsentation af den XML struktur der modtages. Se yderligere beskrivelse af strukturen i 6.3.5 Anmeldelser i strukturel form. Løsningsspecifikation: e-tl motor, v..0 Side 5 af 35
o o o Stamdata Datalaget med stamdata repræsenterer de eksisterende stamdata i e-akten, således at den strukturelle information i anmeldelsen kan bindes til konkrete stamdata i form af ejendomme, personer, biler, etc. Disse stamdata udgør hovedsageligt nøglen for det element som ønskes refereret, samt enkelte data som vedligeholdes af Tinglysningsretten. Stamdata er ligeledes nøglen til opslag i eksterne registre. Berigelse/påtegning De data, der opsamles for en anmeldelse som en del af prøvelsesprocessen, opbevares i dette logiske lag. Det helt centrale element her er kontekst objektet, der medsendes til enhver kontrol i processen. Kontekst objektet er indgangsvinklen til enhver registrering af beriget information, herunder ikke mindst resultater af de enkelte kontroller, inkl. eventuelle påtegninger og/eller afvisningsårsager. Konteksten initialiseres i modtagelsesprocessen, beriges i prøvelsesprocessen, og danner grundlag for registreringen i TinglysOffentliggør processen. Konteksten er yderligere beskrevet i 6.3.5 Anmeldelser i strukturel form Summariske Oplysningerne som opbevares i de summariske oplysninger, er en opsummering af resultatet af prøvelsen, og udgør bl.a. et indeks som tillader at data i e-akten hurtigt fremfindes og der let kan dannes overblik over de mest almindeligt forekomne informationer i e-akten. Orkestreringen af den overordnede proces involverer således både den overordnede procesmæssige orkestrering, samt en beskrivelse og klassificering af de dataelementer, de forskellige kontroller i processen arbejder på. Selve orkestreringen af procesforløbet sker gennem brug af kontrolkomponenter registreret for de enkelte ekspeditionstyper i e-tinglysning. Således anvendes den såkaldte alternative implementering fra kravbilag 2B, implementeret direkte i Java kode, baseret på en parametrisering af processen gennem informationer i e-tinglysning databasen. 6.2.2 Modtagelse af anmeldelse I dette afsnit beskrives behandling, som alle modtagne anmeldelser gennemløber for at Kontrollere om anmeldelsens indhold kan læses og fortolkes, Anmeldelsen får tilknyttet identifikation, dvs. tildelt løbenummer og tidsstempel Anmeldelsen bliver ført gennem faste indledende kontroller, Der opsættes lås på objekter, som anmeldelsen vedrører Der fremsendes meddelelse til anmelder om, at anmeldelsen er modtaget. Under behandling af modtagelse af en anmeldelse vil anmeldelsen kunne blive afvist før den kommer til den egentlige prøvelsesproces. Tidlig afvisning vil typisk være forårsaget af tekniske fejl i den modtagne anmeldelse, således af den ikke kan gøres til genstand for en egentlig prøvelse. Manglende aktualitet af digital signatur medfører at anmeldelsen overgår til manuel behandling 6.2.2. Tildeling af identifikation (dato og løbenummer) Normalt vil alle anmeldelser af tinglysningsdokumenter, som modtages blive tildelt en identifikation i form af dato og løbenummer, og alle afvisninger vil indeholde denne identifikation som reference. For at sikre, at de modtagne anmeldelser bliver behandlet i rækkefølge i forhold til dato og løbenummer vil denne identifikation normalt blive tildelt samtidig med at en anmeldelse indsættes i Løsningsspecifikation: e-tl motor, v..0 Side 6 af 35
behandlingskøen. De anmeldelser, som afvises før de indsættes i behandlingskøen vil dog få tildelt dato og løbenummer uden at have været i behandlingskøen. I det tilfælde, hvor indholdet af anmeldelsen ikke kan tolkes, vil det ikke altid være muligt at tildele dato og løbenummer. Derfor vil afvisningen referere til en teknisk id. Ved modtagelse af flere anmeldelser i én kuvert, hvor indholdet ikke kan tolkes, vil det heller ikke være muligt at afvise de enkelte anmeldelser i kuverten. I disse tilfælde vil afvisningen referere til en teknisk id, og ikke til dato og løbenummer. I afsnit 5.2.5 er der yderligere beskrevet, hvordan kuvertordningen behandles. 6.2.2.2 Behandling af modtagelsen før indsættelse i kø Behandling af en anmeldelse frem til indsættelse i behandlingskøen er en synkron operation. Denne operation kan enten kaldes via system-system, eller fra portalen. Da der er tale om en synkron service, som skal melde tilbage at anmeldelsen er modtaget og placeret i behandlingskøen vil der ikke blive foretages kald af eksterne systemer ved udførsel af denne service. Det betyder at nogle af de kontroller, som i KS er før indsættelse i kø er flyttet til behandling på den anden side af køen. Rationalet bag dette er at sikre at operationen anmeld altid vil kunne gennemføres, hvis e-tl er kørende. Selvom et eller flere af de anvendte eksterne systemer ikke er kørende vil det altid være muligt at kunne foretage anmeldelser både via system-system og fra portalen.der vil, ved manglende adgang til eksterne data, blive udskrevet en fejltekst, ved hjælp af kontrollen AktHent. Følgende tabel beskriver den behandling, som foretages frem til indsættelse i behandlingskøen. Proces/Kontrol Behandling KontrolModtag Det modtagne dokument lagres i e-tl DocStore, som en leverance. Alt hvad der modtages som anmeldelser lagres som leverancer uanset indhold. Dette giver mulighed for at man altid vil kunne se hvad e-tl har modtaget, selvom det ikke kan behandles videre. Dokumentet parses nu som XML, og hvis det ikke er muligt afvises anmeldelsen. Hvis dokumentet kan parses, checkes om der er tale om en enkelt anmeldelse eller om flere anmeldelser i en kuvert. Alt efter hvilken type anmeldelse, der er tale om checkes det basale XML skema for dokumentet. Udestående: Det skal overvejes, om der skal være to forskellige WebServices en til anmeldelse af enkelt anmeldelse og en til anmeldelse af kuvert. Hvis XML dokumentet hverken er en enkelt anmeldelse eller flere anmeldelser i en kuvert eller hvis det basale XML skema ikke kan checkes afvises anmeldelsen. Hvert bilag indeholdt i en anmeldelse trækkes ud, og lagres separat i DocStore. For referencer til eksisterende bilag refereres disse. Hvis der refereres til bilag, som ikke eksisterer afvises anmeldelsen. Hver underskrift i anmeldelsen afkodes og lagres i DocStore. Datastrukturen for lagring af det modtagne og opsplitning i anmeldelser og underskrifter er beskrevet i afsnit 6.3.4 Anmeldelser i original form. Efter den basale opsplitning bliver det parsede tinglysningsdokument omdannet til en objektstruktur, som beskrevet i afsnit 6.3.5 Anmeldelser i strukturel form. Det er denne struktur, sammen med strukturen som indeholder bilag og underskrifter, som den resterende del af behandlingen benytter. Løsningsspecifikation: e-tl motor, v..0 Side 7 af 35
Proces/Kontrol LøbenrTildel Behandling Se afsnit 6.2.2. ovenfor. KontrolAnmeld Udfører KontrolAnmeld_ i alle tilfælde. KontrolAnmeld er den første af alle kontroller. KontrolAnmeld er den grundlæggende tinglysningsmæssige prøvelse, der er nødvendig for at foretage en tinglysning. Hvis nedenstående behandlinger i KontrolAnmeld ikke gennemføre, afvises anmeldelsen. Hvis KontrolAnmeld_ medfører Afvisning, vil yderligere automatisk behandling blive afbrudt her - og der springes til Afslutning af anmeldelse (jf. afsnit 6.2.4), hvor der vil blive udsendt svar med afvisningsårsag. Manuel Behandling bl.a. i KontrolEkstype (hvor visse ekspeditionstyper altid udtages til manuel behandling), vil de resterende automatiske kontroller, for den givne ekspeditionstype, fortsætte, efter at der er opsat lås på berørte objekter. Derefter springes til Afslutning af anmeldelse (jf. afsnit 6.2.4), hvor der udsendes foreløbigt svar med årsag til Manuel Behandling og anmeldelsen videresendes til sagsstyringsmodulet og den interne portal. Hvis KontrolAnmeld_ ikke medfører afvisning, udføres KontrolAnmeld_2. I KontrolAnmeld_2 og i det resterende forløb gennem kontroller, der er specifikke for Ekspeditionstypen, opsamles samtlige eventuelle årsager til afvisning eller manuel behandling. Det betyder at svar på anmeldelsen vil indeholde opsamlede årsager til afvisning eller manuel. KontrolAnmeld_ DigSigOversæt Foretager de valideringer af de digitale signaturer, som er mulige uden at kontakte eksterne systemer. De valideringer, som kræver kontakt til eksterne systemer udføres først efter udtagelse fra behandlingskøen. Dette betyder at oversættelse af PID til CPR for POCES ikke foretages før senere. Muligvis vil validering i forhold til revocation list kunne foretages her, hvis e-tl holder en lokal kopi af revocation list, som holdes opdateret af en baggrundsproces. Hvis denne validering af de digitale signaturer fejler markeres anmeldelsen som afvist. KontrolEkstype KontrolRolle Kontrollerer at den/de angivne ekspeditionstyper er valide og hvis der er angivet flere at kombinationen er valid. Hvis denne validering fejler markeres anmeldelsen som afvist. Kontrollerer at de basale informati- Løsningsspecifikation: e-tl motor, v..0 Side 8 af 35
Proces/Kontrol Behandling KontrolAnmelder KontrolAnmelderordning KontrolFuldmagtsordning KontrolCPR/CVROversæt oner om roller er til stede enten i form af ID (CPR/CVR) eller navn og adresse. Hvis der er ufuldstændig angivelse af rolleinformation afvises anmeldelsen. Kontrollerer at der er angivet en anmelder blandt rollerne. Er der ikke angivet en anmelder afvises anmeldelsen. Undersøger om anmeldelsen er foretages via anmelderordningen. Hvis det er tilfældet checkes om de regler der er i forhold til den konkrete anmelderordning er overholdt. Bl.a en kontrol af obligatorisk tekst om anvendelsen af anmelderordningen, yderligere information se Bilag 2B. Er det ikke tilfældet afvises anmeldelsen. Kontrollen undersøger om anmeldelsen er foretaget med brug af fuldmagtsordningen. Der skal være angivet en standardtekst om, at anmeldelsen sker i henhold til fuldmagtsordningen. Er det tilfældet checkes om de angivne fuldmagter allerede er registreret i e-tl eller om de forventes at blive fremsendt efterfølgende, med angivelse af forventet fuldmagt. Er det ikke tilfældet afvises anmeldelsen. Ved forventet fuldmagtangivelse, lyses med frist, hvis den ikke ses registreret som modtaget, tinglyses med frist på 6 hverdage. Der er udvalgte ekspeditionstyper der ikke kan lyses med forventet fuldmagt Udestående: Skal (dele af) denne kontrol flyttes til efter indsættelse i kø? Dels kræver den at objekt for tinglysning er præcis bestemt, og dels kunne den være en del af validering af disponenter. Denne kontrol udføres først efter anmeldelsen har været i kø, da denne kontrol kræver kald til eksterne systemer. KontrolAnmeld_2 KontrolAngivIdent Validerer identifikation af de angivne tinglysningsobjekter. Denne Løsningsspecifikation: e-tl motor, v..0 Side 9 af 35
Proces/Kontrol Kontrol- FindIdent KontrolHæftelse - Konverteret Behandling KontrolDelareal validering sikre, at de korrekte låse opnås ved indsættelse i kø. Denne kontrol beskriver specifikke regler for delarealer. Denne kontrol omsætter de angivne identifikationer til de instanser i e- TL databasen, som der foretages tinglysning på. Denne kontrol kan give anledning til kald af eksterne systemer, hvorfor denne kontrol først skal udføres efter indsættelse i kø. Dette giver sammenholdt med låsningsmekanismerne i køen at låsningen foretages på de angivne identer. Dette er en indirekte låsning på instanser i e-tl databasen. Se beskrivelsen i afsnit 6.2.2.3 Kø-funktion og låsning af tinglysningsobjekter Kontrollen checker for om der er konverteret fra et papirbaseret pantebrev til et digitalt pantebrev. Hvis det drejer sig om et realkreditpantebrev, skal pantebrevet være konverteret i forbindelse med idriftsættelse af e-tl, hvis det ikke er sket skal hæftelsen autokonverteres. Hvis hæftelsen ikke er konverteret til et digitalt dokument, kan der ikke ske tinglysning af ovennævnte ekspeditionstyper, og anmeldelsen skal derfor afvises. 6.2.2.3 Kø-funktion og låsning af tinglysningsobjekter Når den modtagelsesmæssige standardbehandling af anmeldelsen er gennemført, og såfremt anmeldelsen ikke i dette forløb er blevet afvist, skal den gives videre til prøvelse. Dette skridt betegner netop overgangen mellem de to procestrin modtagelse og prøvelse beskrevet ovenfor. Da disse to procestrin afvikles asynkront, dvs. at modtagelse af anmeldelser kan foregå i en anden takt end afviklingen af prøvelser, skal der etableres en kø-service. Derved kan den delproces, der er ansvarlig for modtagelse aflevere anmeldelsen til prøvelse og derved afgive ansvaret for at drive den videre behandlingsproces, selv om der ikke nødvendigvis er ledige ressourcer til afvikling af delprocessen prøvelse. Når der til delprocessen prøvelse igen opnås frie ressourcer, så påbegyndes en tømning af køen for anmeldelser der afventer prøvelse og delprocessen prøvelse overtager herefter ansvaret for videreførelse af behandlingsprocessen. Køen har således ansvaret for at fastholde anmeldelsen i en afventende tilstand mellem de to delprocesser. Ud over at sikre afkobling mellem modtagelse og prøvelse så tjener køen også det formål at sikre overholdelse af de grundlæggende principper for gennemførelse af prøvelser:. For at kunne påbegynde prøvelse må der ikke forefindes andre påbegyndte og endnu ikke afsluttede prøvelser af anmeldelser, der vedrører et eller flere af de tinglysningsobjekter, der indgår i den anmeldelse der ønskes behandlet. Kun i det tilfælde, hvor ingen af de tinglysningsobjekter, der indgår i anmeldelsen samtidigt indgår i en uafsluttet prøvelse af en anden anmeldelse, kan prøvelsen påbegyndes. 2. Når prøvelser skal påbegyndes, udtages de til behandling i den rækkefølge, hvormed de er registreret i henhold til det indeholdte tinglysningsdokuments dato-løbenummer. Hvis anmeldelsen med det dato-løbenummer, der indikerer den tidligste modtagelse, er blokeret for behandling i henhold til det første princip, så undersøges det næste i rækken af modtagne anmeldelser, - dog med den yderligere begrænsning, at alle de tinglysningsobjekter, der indgår i oversprungne anmeldelser, betragtes som var de under påbegyndt behandling. Denne betragtning gentages indtil der findes en anmeldelse, der kan udtages til prøvelse. Hvis ingen anmeldelse kan udtages efter dette princip, må der afventes enten afslutning af igangværende anmeldelser eller modtagelse af nye anmeldelser, før det igen undersøges om der kan udtages anmeldelser til prøvelse. Løsningsspecifikation: e-tl motor, v..0 Side 0 af 35
For at en anmeldelse kan påbegynde prøvelse kræves således:. Ingen af de tinglysningsobjekter, der indgår i prøvelsen, må indgå i andre anmeldelser under uafsluttet behandling. 2. Ingen af de tinglysningsobjekter, der indgår i prøvelsen, må indgå i andre anmeldelser, der er registreret med et lavere dato-løbenummer og endnu afventer behandling. Til at sikre respekten for disse principper anvendes en låse-mekanisme. Dette muliggør, at anmeldelser kan anmode om en lås på de tinglysningsobjekter, der indgår i behandlingen. Disse anmodninger prioriteres i rækkefølge efter anmeldelsernes dato-løbenumre, og anmeldelsen med den højeste prioritet (det laveste/ældste dato-løbenummer) tildeles eksklusiv adgang til tinglysningsobjektet og betegnes dermed som indehaver af låsen. Netop når en anmeldelse er indehaver af låsene for alle de tinglysningsobjekter, der indgår i anmeldelsen, kan det gives fri til prøvelse. Når prøvelsen af en anmeldelse er afsluttet og tinglysningsbehandlingen er gennemført, afgiver anmeldelsen sine låse. Disse kan således tildeles på ny i henhold til prioriteten på de anmeldelser, der afventer låsning på netop disse tinglysningsobjekter. Denne låse-mekanisme sikrer overholdelse af ovenstående principper da en anmeldelse kun kan blive indehaver af alle låse på de relevante tinglysningsobjekter, hvis der ikke findes anmeldelser med højere prioritet (ældre datoløbenummer), der enten afventer en af disse låse eller er under behandling og dermed indehaver af en af disse låse. De konkrete operationer for den beskrevne kø-service er defineret ved følgende interface: <<service>> PrøvelsesKøService indsæt(dokument : Tinglysningsdokument) afslut(dokument : Tinglysningsdokument) udtræk() : Tinglysningsdokument Figur 3: PrøvelsesKøService PrøvelsesKøService understøtter følgende operationer: indsæt indsætter det angivne tinglysningsdokument i kø til prøvelse. Ved denne indsættelse tildeles tinglysningsdokumentet et dato-løbenummer, der anmodes om låse på de relevante tinglysningsobjekter. Hvis tinglysningsdokumentet herefter ejer alle de anmodede låse placeres det i kø til prøvelse og markeres som frigivet og kan umiddelbart udtages til prøvelse. I modsat fald placeres det i kø til prøvelse men tilbageholdes (låses) og kan således ikke udtrækkes til prøvelse. udtræk returnerer et frigivet tinglysningsdokument fra køen hvis det forefindes. Hvis der findes flere frigivne dokumenter udtrækkes det dokument der har det ældste datoløbenummer. Dokumentet er herefter fjernet fra køen men er stadig indehaver af sine låse. afslut afslut registreringen af det angivne tinglysningsdokument. Hermed afgives låsene på de relevante tinglysningsobjekter. For hver afgiven lås fremfindes det tilbageholdte tinglysningsdokument køen i med højeste prioritet der har en afventende anmodning om låsen og dette dokument får tildelt låsen. Herefter undersøges om dokumentet herved er blevet ejer af låsene på alle sine relevante tinglysningsobjekter, og hvis dette er tilfældet markeres det som frigivet i køen og kan umiddelbart udtages til prøvelse. I modsat fald forbliver det tilbagehold i køen og afventer at samtlige dets anmodninger om låse er imødekommet. Løsningsspecifikation: e-tl motor, v..0 Side af 35
Selv om de enkelte operationer hver for sig sikrer en konsistent opdatering af anmeldelser i køen, så er det vigtigt at denne konsistens også er sikret i det tilfælde, hvor flere klienter forsøger at foretage samtidige operationer på køen. I en mere teknisk terminologi vil det sige, at disse operationer gøres atomare og sekventielle og at køen overordnet set er thread-safe. Registrering af Anmeldelser i køen og deres brug af låse i forhold til Tinglysningsobjekter er beskrevet ved følgende model: PrøvelsesKø +prøvelseskølåste 0.. 0.. +prøvelseskøfrigivne +låstedokumenter 0..n 0..n +frigivnedokumenter Tinglysningsdokument (from anmeldelse)..n +låstedokumenter +tinglysningsdokument LåseRegister +låseregister 0.. +låsteobjekter 0..n 0..n +låsningsobjekt LåsningsObjekt 0.. +låsningsobjekt..n +reference TinglysningsobjektReference (from anmeldelse) * +tinglysningsobjekter Figur 4: Model for låsning Alle Tinglysningsdokumenter, der er indsat i køen, vil enten være registreret som frigivet eller låste (afhængigt af om Tinglysningsdokumentet ejer samtlige låse på de relevante Tinglysningsobjekter eller ej). Ordningen af Tinglysningsdokumenter i de to registre er defineret gennem dato-løbenummeret på dokumenterne. Da identiteten af de refererede Tinglysningsobjekter først fastlægges som en del af selve prøvelsen og derfor ikke kendes ved selve modtagelsen så foretages låsningen gennem et LåsningsObjekt. Dette objekt repræsenterer det egentlige Tinglysningsobjekt og er afledt af de identificerende oplysninger Tinglysningsdokumentet indeholder vedrørende refererede Tinglysningsobjekter og disse referencer betegnes Tinglysningsobjekt- Referencer. Begrebet LåsningsObjekt samler således de Tinglysningsobjekt- Referencer, der indeholder identificerende oplysninger for samme egentlige Tinglysningsobjekt. Låsningsobjektet anvendes udelukkende til at sikre den ønskede låsning i køsystemet, og det indeholder ingen yderligere information om Tinglysningsobjekterne, som det repræsenterer. Alle låse er registreret i entiteten LåseRegister som samlet administrerer alle låse. En lås eksisterer så længe, der er et eller flere Tinglysningsdokumenter, der har anmodet om en lås på det Tinglysningsobjekt som låsen repræsenterer. Så snart alle anmodningerne er behandlet nedlægges låsen. Ligeledes oprettes en ny lås for et Tinglysningsobjekt, hvis en eksisterende ikke allerede kan identificeres ud fra den relevante TinglysningsobjektReference. I modellen knyttes denne information til det Tinglysningsdokument, der er formidlet i Anmeldelsen. Fra et behandlingsperspektiv er det netop Tinglysningsdokumentet, der føres gennem den tinglysningsmæssige prøvelse. Som beskrevet tidligere er der en entydig sammenhæng mellem en Anmeldelse og det Tinglysningsdokument, der er formidlet i Anmeldelsen. Løsningsspecifikation: e-tl motor, v..0 Side 2 af 35
6.2.3 Behandling af anmeldelse Efter de indholdsmæssige kontroller (KontrolModtag) og de grundlæggende prøvelser (Kontrol- Anmeld) er udført "på" anmeldelsen (tinglysningsdokumentet), skal den specifikke behandling for den konkrete ekspeditionstype nu initieres. Proces/Kontrol TinglysUdfør KontrolAfgift ManuelBehandling PrøveTinglys Behandling Den overordnede proces TinglysUdfør iværksætter sættet af specifikke kontroller, som skal udføres for den konkrete ekspeditionstype. Hvilke specifikke kontroller, der skal udføres for den konkrete ekspeditionstype, fremgår af Bilag 2C Matrix med sammenhæng mellem kontroller og ekspeditionstyper. Indtil videre er det planen, at behandle kontrollerne successivt (svarende til Bilag 2B, side 2 Alternativ løsningsmodel) men hvis det viser sig nødvendigt af hensyn til performance, udvælges enkelte kontroller til parallel behandling. For nærmere detaljer om den enkelte kontrol henvises til Appendiks B. Er eksponeret eksternt som service, så det er muligt at kalde den fra såvel motoren som fra de 3 portaler. KontrolAfgift gennemløber følgende kontroller, der tilsammen opsamler information og beregner afgift: KontrolStorkunde, KontrolFremmedValuta, Kontrol- Grundafgift, KontrolAfgiftHæftelse, Kontrol- Afløsningspantebrev, KontrolAfgiftEjerskifte, KontrolAfgiftSKATRegistrer Statuskoden Manuel behandling omfatter dels situationer, hvor KontrolEkstype har afdækket, at ekspeditionstypen altid skal behandles manuelt, er den automatiske behandling oversprunget. De specifikke kontroller har afdækket én/flere årsager til manuel behandling. I begge situationer er der noteret igangværende tinglysning og låsning af berørte objekter. Under afslutning af den automatiske behandling (jf. afsnit 6.2.5) udsendes til anmelder et foreløbigt svar, hvori der er noteret årsag til manuel behandling og anmeldelsen videresendes til sagsstyringsmodulet og den interne portal. Sagen forventes returneret til e-tl motor, når anmeldelsen er klar til automatisk færdigbehandling og frigivelse af låste objekter. For nærmere information om manuel behandling, se afsnit om intern portal Opsamler information om resultatet fra TinglysAnmeld frem til og med TinglysUdfør og KontrolAfgift og årsager til evt. Manuel behandling 6.2.3. Automatiseret prøvelse Udgangspunktet for den automatiserede prøvelse er de ekspeditionstyper, der indgår i den konkrete anmeldelse. Alle ekspeditionstyper samt tilhørende meta-data fra e-akten og indhentede data fra eksterne edb-leverandører er registreret i e-tl motorens database. Løsningsspecifikation: e-tl motor, v..0 Side 3 af 35
Anmeldelser med visse konkrete ekspeditionstyper (nævnt i systemintern tabel udledt af KontrolEkstype) udtages altid til manuel behandling. Ligeledes indeholder modellen information om ekspeditionstyper, der kan kombineres med andre ekspeditionstyper (relationen kankombineresmed). Endelig indeholder databasen en registrering af de konkrete kontroller som en given anmeldelse * +ekspeditionstyper * +kankombineresmed Ekspeditionstype nr : int +ekspeditionstype navn : String beskrivelse : String manuel : boolean +kontroller * Kontrol navn : String getbeskrivelse() : String getklassenavn() : String instans() : KontrolInterface indeholdende ekspeditionstypen skal gennemgå (kontroller relationen). Figur 5: Model for Ekspeditionstyper og Kontroller UML modellen for ekspeditionstyper er vist i figuren ovenfor. Den konkrete automatiske prøvelse udføres af servicen TinglysUdfør, der udvælger de kontroller, tinglysningsdokumentet skal gennemgå. Kontrollerne bestemmes ud fra de ekspeditionstyper, der er indeholdt i tinglysningsdokumentet. Servicen TinglysUdfør modtager et Kontekst objekt samt en konkret objektrepræsentation af tinglysningsdokumentet. Formålet med Kontekst objektet er indsamling af data på tværs af de enkelte kontroller. Disse data vil udgøre dele af berigelsen, informationer til brug for den endelige påtegning, resultater af udførelsen af de enkelte kontroller osv. Eksempel: Kontrollen benævnt KontrolNuværendeDisponentSignatur kunne resultere i: Status "afvist" såfremt der ikke i en anmeldelse OpdelingEjerlejligheder(8) findes signaturer fra alle ejere/disponenter. Dette vil blive registeret gennem kald til Kontekst objektets metode registrerafvisning(...). Status "manuel" såfremt der ikke i en anmeldelse AflysningBetingetSkøde(55) findes signaturer fra alle ejere/disponenter. Dette vil blive registreret gennem kald til Kontekst objektets metode registrermanuel(...). Objektrepræsentationen af tinglysningsdokumentet er dannet direkte fra den XML repræsentation som indsendes og behandles i ModtagService (via TinglysAnmeldService). Løsningsspecifikation: e-tl motor, v..0 Side 4 af 35
<<service>> PrøvelseMotor udførprøvelse(kontekst : Kontekst, dokument : Tinglysningsdokument) afvist : boolean manuel : boolean <<session>> Kontekst <<Interface>> KontrolInterface kontroludfør(kontekst : Kontekst, dokument : Tinglysningsdokument) registrerafvisning(kontrol : String, årsag : String) registrermanuel(kontrol : String, årsag : String) Figur 6: Prøvelsesmotorens kontekst UML modellen ovenfor viser PrøvelseMotor (TinglysUdfør) samt Kontekst objektet i den udgave der anvendes i prototypen. Ligeledes vises KontrolInterface, der repræsenterer det Java interface, alle kontroller skal implementere for at indgå i prøvelsen. 6.2.3.2 Manuel behandling En prøvelse, der skal ske som manuel behandling (enten helt eller delvis for ekspeditionstypen), vil blive beriget med information fra alle kontroller og derefter overgå til workflow styringen i den interne portal. 6.2.4 Afslutning af anmeldelse Modtagelsen og den automatiske prøvelse af anmeldelsen kan resultere i følgende statuskoder: Statuskode Afsluttende behandling Afvisning Endelig status, som betyder at der tilknyttes statuskode Afvist til det modtagne dokument. AktRegistrer overspringes dvs. der udføres ikke registerændringer. Dog vil det afviste dokument være tilgængeligt efterfølgende.de låste objekter frigives. Det registreres i akten at anmeldelsen blev afvist og årsagen dertil. TinglysMeddel udsender endeligt svar til anmelder. TinglysOffentliggør overspringes dvs. der udsender ikke information til faste abonnenter. Manuel Foreløbig status, som betyder at der tilknyttes statuskode Manuel til det modtagne dokument. AktRegistrer, der er den process der foretager registrereing af den afsluttende tinglysning i e-akten, overspringes dvs. der udføres ikke registerændringer. Først ved endeligt svar vil de låste objekter bliver frigivet. Den automatiske behandling afsluttes med TinglysMeddel, der udsender til anmelder et foreløbigt svar, hvori der er noteret årsag til manuel behandling. TinglysOffentliggør overspringes dvs. der udsender ikke information til faste abonnenter. Anmeldelsen videresendes til sagsstyringsmodulet og den interne portal. Sagen forventes returneret til e-tl motor for færdigbehandling, som kan være enten genoptagelse af prøvelsen (hvis årsager til manuel er fjernet ) eller gennemførsel af registerændringer, som er besluttet af sagsbehandler samt udsendelse af endeligt svar, hvori sagsbehandler Løsningsspecifikation: e-tl motor, v..0 Side 5 af 35
Statuskode Tinglyst Tinglyst med frist Afsluttende behandling har noteret evt. anmærkninger, meddelelser og/eller tillægstekster. Endelig status, som betyder at der tilknyttes statuskode Tinglyst til det modtagne dokument. AktRegistrer udfører de registerændringer som kontrollerne har opsamlet. De låste objekter frigives. TinglysMeddel udsender endeligt svar til anmelder og de låste objekter frigives. Svaret indeholder evt. opsamlede anmærkninger, meddelelser, tillægstekster og/eller frist og fristårsager. TinglysOffentliggør udsender information til faste abonnenter Beliggenhedskommune og SKAT. De involverede processer er følgende: Proces/Kontrol Behandling AktRegistrer Foretager den permanente registrering af tinglysningen i databasen TinglysMeddel Sender meddelelse til anmelderen om tinglysningen Tinglys- Offentliggør For nærmere detaljer henvises til Appendiks B. Sender meddelelser om tinglysningshændelser til abonnenter, herunder SKAT og Bopælskommune 6.2.4. Meddelelser til anmelder Efter tinglysning er afsluttet registreres resultatet i databasen. Ud fra denne registrering dannes en meddelelse til anmelderen med resultatet af anmeldelsen. KS side 58 indeholder en foreløbig opgørelse af de informationer, som skal tilbage til anmelderen. I e-tl dannes resultatet som et XML dokument, som for system-system, brugere returneres via en WebService som system-system brugeren har registreret i e-tl. På den eksterne portal danner dette XML dokument baggrund for en visning, enten som HTML eller PDF. Denne visning kan også blive distribueret via e-mail alt efter hvordan der kommunikeres med den aktuelle anmelder. Meddelelsen vil efterfølgende være tilgængelig via anmelderens Mine tinglysninger Strukturen af XML dokumentet for meddelelsen til anmelderen er vist på den følgende figur. Løsningsspecifikation: e-tl motor, v..0 Side 6 af 35
Svar til anmelder Ekspeditionstype Roller Anmelderinformation Tinglysningsobjekter Ideele andele Særlige vilkår Købesum Købesum sammensætning Hovedstol Rentesats Betinget skøde Dato og løbenummer Tinglysningsstatus Fristoplysninger Prioritetsplacering Anmærkninger Tinglysningsafgift (betalt) Tinglysningsafgift (beregnet) Afgiftsprøvelse Figur 7: Strukturen af XML dokumentet for meddelelsen Ovenstående figur 7 er under opdatering, yderligere præcisering kan findes I kapitel 4, systemgrænseflader. For de elementer, hvor informationen kommer direkte fra anmeldelsen, så benyttes de samme OIOXML elementer som anvendes til tinglysningsdokumentet (fx Ekspeditionstype og Roller). Disse er beskrevet i afsnit 6.5.. Ligeledes vil XML elementer fra øvrige områder blive genbrugt så vidt muligt (fx Købesum og Hovedstol). For de resterende elementer vil der blive defineret XML elementer for informationen. De enkelte elementer indeholder følgende information. Tallet i parentes angiver reference til KS side 58. Ekspeditionstype angiver ekspeditionstypen fra anmeldelsen (4). Roller indeholder roller fra anmeldelsen, informationen i rollen kreditor og meddelelseshaver vil være beriget med navn og adresse (5, 6, 8, 9, ). Anmelderinformation indeholder den anmelderinformation, som er angivet i anmeldelsen (2, 3, 0). Tinglysningsobjekter tinglysningsobjekterne fra anmeldelsen (8). Andele angivelse af andele fra anmeldelsen (20). Særlige vilkår særlige vilkår fra anmeldelsen af en hæftelse (2). Købesum købesum fra anmeldelsen af adkomst (3). Sammensætning af købesum angiver om købesummer omfatter arv eller gave (4). Hovedstol hovedstol fra anmeldelse af hæftelse (5, 6). Rentesats rentesats fra anmeldelse af hæftelse (7). Betinget skøde angiver med ja/nej om et betinget der ligger et betinget skøde bag en tinglyst hæftelse (9). Dato og løbenummer angiver den identifikation, som dokumentet er blevet tildelt i tinglysningssystemet (2). Tinglysningsstatus resultat af tinglysningen (tinglyst, tinglyst med frist eller afvist) (22). Fristoplysninger hvis Tinglysningsstatus er tinglyst med frist angives her årsag og fristdato (23, 24). Anmærkninger angivelse af de eventuelle anmærkninger som tinglysningen har fået fra prøvelsen (automatisk eller manuel) (26, 27, 28). Løsningsspecifikation: e-tl motor, v..0 Side 7 af 35
Tinglysningsafgift (betalt) den angivne tinglysningsafgift fra anmeldelsen (29). Tinglysningsafgift (beregnet) angiver den tinglysningsafgift, som tinglysningssystemet har beregnet (30). Afgiftsprøvelse angiver om tinglysningen er sendt til afgiftsprøvelse hos SKAT og årsagen til det (3, 32). Udestående Svar på anmeldelse skal endelig fastlægges i samarbejde med DST, da der i KS side 60 står Ovennævnte gennemgang af tekster til meddelelser fra e-tl til anmelderen er foreløbig og kan blive ændret. Dette punkt kræver yderligere afklaring mellem Domstolsstyrelsen og CSC 6.2.4.2 Meddelelser til øvrige myndigheder Udestående: Opsamling af data vedr. ejerskifte til beliggenhedskommune og SKAT (fx med udgangspunkt i KS side 45) skal fastlægges. 6.2.4.3 Meddelelser til abonnenter Hændelsesmodul og abonnement er beskrivet i afsnit 5.2 6.2.5 Forespørgsler Udgangspunktet for forespørgslerne er Servicen AktHent, som stilles til rådighed for den interne portal, den eksterne portal og for system-system grænsefladen. Servicen AktHent håndterer tilgangen til informationerne i e-akten ud fra brugervalgte søgekriterier eller Mine tinglysninger for brugeren, forespørger i e-akten og returnerer summariske oplysninger, de originale dokumenter, eller påtegninger til disse vedrørende Fast Ejendom, Bil, Person/Virksomhed og Andelsbolig, returnerer aktuelle oplysninger eller de historiske oplysninger der er relevante. De forskellige typer forespørgsler beskrives i afsnit 6.2.5. Bil, 6.2.5.2 Fast ejendom, 6.2.5.3 Andelsbolig, 6.2.5.4 Person/Virksomhed, og 6.2.5.5 Mine Tinglysninger Løsningsspecifikation: e-tl motor, v..0 Side 8 af 35
Forespørgsel modtaget : Timestamp afsendt : Timestamp løbnr : int forespørgerident : String forspørgelsetype : ForespørgType forespørgstelnr : String forespørgregnr : String forespørgcvr : String forespørgtingdato : Date forespørgløbnr : int forespørgfødselsdato : Date forespørgfornavn : String forespørgefternavn : String forespørgcpr : String forespørgvejnavn : String forespørgnr : int forespørgpostnr : int forespørgby : String forespørgejendomsident : String <<enum>> ForespørgType BIL = EJENDOM = 2 PERSONBOG = 3 ANDELBOLIG = 4 MINETING = 5 Figur 8: Søgekriterier vedr. forespørgsler Ved kald af AktHent vil det altid medføre at følgende attributter registreres/gemmes: modtaget som indeholder dato og tid for modtagelsen af forespørgslen forespørgselsnummer automatisk tildelt forespørgernummer som er unikt og optælles løbende. forespørgerident identifikation af forespørger, dvs. brugernavn, CPR-nr eller CVR-nr. forespørgelsetype indikerer typen af forespørgslen. Fx hvilken tingbog eller om der er tale om Mine tinglysninger. Desuden registreres attributten afsendt når et summarisk forespørgselssvar afsendes. Denne anvendes til afregninger. 6.2.5. Bil En fremsøgning på Bilbogen er baseret på et stelnummer, registreringsnummer, CVR-nr eller tinglysningsdato og løbenummer. Der kan desuden fremsøges ved hjælp af debitors CPR-nr eller fødselsdato, fornavn og efternavn. Stelnummer fremsøgning benytter attributten forespørgstelnr som indeholder bilens stelnummer. Fremsøgning via registreringsnummer sker via attributten forespørgregnr.domstolsstyrelsen har et notat under udarbejdelse. Det er mellem DSS og CSC, aftalt at det udelukkende er på den interne portal der kan søges på registreringfsnummer. Vedrørende CVR fremsøgninger benyttes attributten forespørgcvr. forespørgtingdato og forespørgløbnr attributterne benyttes til en søgning via tinglysningsdatoen og løbenr. Løsningsspecifikation: e-tl motor, v..0 Side 9 af 35
Til fremsøgning via person oplysninger anvendes forespørgfødselsdato og forespørgfornavn og forespørgefternavn attributterne. Fremsøgninger på CPR-nr sker via attributten forespørgcpr. <<enum>> ForespørgelseType BIL = EJENDOM = 2 PERSONBOG = 3 ANDELBOLIG = 4 MINETING = 5 +svarforespørgselbil <<session>> SvarForespørgselBil løbnr : int forespøgerident : String forespørgelsetype : ForespørgelseType afsendt : Timestamp +bil 0..n Bil (from bil) stelnummer : String fabrikat : String variant : String årgang : int registreringsnummer : String registreringsdato : Date udstyr : String farve : String +svarforespørgselbil +summariskhæftelse +svarforespørgselbil +tinglysningsdokument 0..n Tinglysningsdokument (from anmeldelse) modtaget : Timestamp løbenummer : int retskreds : int tinglysningsstatus : TinglysningStatus kreditkunde : boolean anmeldersagsnummer : String digesttype : DigestType digest : String getdatoløbenummer() +tinglysningsdokument..n +tinglysningsdokument SummariskHæftelse +summariskhæftelse (from summarisk)..n kreditor : String debitor : String meddelelseshaver : String hovedstolsum : int hovedstolvaluta : String rente : String anmærkning : String respekt : String dokumenttype : String tillægstekst : String meddelelser : String +svarforespørgselbil rådighedsindskrænkning : String dokumentnummer : int hæftelsesnr : int +scannedeakter 0..n +hæftelse Hæftelse (from hæftelse) tinglysningsdato : Date løbenummer : int hovedstol : BigDecimal valutakode : String kurstype : KursType kursdato : Date valutakurs : BigDecimal aflysningsdato : Date ScannedeAkter (from forespørgsel) Figur 9: UML model for svar på bil forespørgsel. Resultatet af fremsøgningen kan variere ud fra, hvor specifikke fremsøgningskriterierne er. Dvs. resultat fra AktHent kan derfor bestå af 2 typer: Resultatliste Hvis der er mere end et hit, vil fremsøgningen resultere i en liste med antal bil objekter. Listen vil indeholde følgende bil oplysninger: Registreringsnr. Stelnr. Løsningsspecifikation: e-tl motor, v..0 Side 20 af 35
Mærke Type Det vil herefter være muligt at vælge det ønsket bil objekt og få de summariske oplysninger præsenteret. Summariske oplysninger(svar). Såfremt fremsøgningen resulterede i et hit eller at der via førnævnte resultatliste er valgt en bil, præsenteres de summariske oplysninger for det pågældende objekt. De summariske oplysninger består af følgende attributter: Bil stam oplysninger Stelnr Fabrikant Model Variant Årgang Registreringsnr Registrerings dato ejerfødselsdato Hæftelses oplysninger Dokumentnr Kreditor, navn, adresse og CVR DebitorNavn Meddelelseshaver, Navn, adresse og CVR HovedstolSum HovedstolValuta Rente Anmærkning Respekt DokumentType Tillægstekster Meddelelser Rådighedsindskrænkning HæftelsesNr Der henvises i øvrigt til afsnit 0.3 i kravspecifikationen for en yderligere beskrivelse af de elementer, der skal indgå i de summariske oplysninger. Under de summariske oplysninger vil der desuden være mulighed for at se grundlaget for oplysningerne. Dvs. det originale tinglysningsdokument samt eventuelle påtegninger, der har refereret til disse dokumenter. 6.2.5.2 Fast ejendom AktHent kan udsøge fra Fast ejendom med kriterierne som f.eks adresse, ejendomsident, dato- /løbenr, matrikelnr eller ejendomstamdata for tinglyste dokumenter. Udestående: Punkt vedr. fremsøgning af umatrikulerede arealer, kræver yderligere afklaring mellem Domstolsstyrelsen og CSC. Løsningsspecifikation: e-tl motor, v..0 Side 2 af 35
Adresse fremsøgning består af følgende attributter: forespørgvejnavn forespørgnr forespørgside forespørgdør forespørgpostnr forespørgby Ejendomsident fremsøgning er baseret på forespørgejendomsident attributten. Fremsøgninger via CPR-nr baseres på attributten forespørgcpr. Fremsøgning af allerede tinglyste dokumenter sker via attributterne: forespørgtingdato er tinglysningsdatoen. forespørgløbnr indeholder dokumentets løbenr. Det er muligt for forespørgeren at konkretisere typen af oplysninger som den pågældende ønsker, så det ikke er nødvendigt først at fremfinde objektet, for dernæst at finde de ønskede oplysninger. Resultatet af fremsøgningen kan variere ud fra, hvor specifikke fremsøgningskriterierne er. Derved kan resultat fra AktHent derfor bestå af Resultatliste med flere hits eller Summariske oplysninger for ét hit. Løsningsspecifikation: e-tl motor, v..0 Side 22 af 35
Ejendom (from ejendom) ejendomstype : Ejendomstype ejendomsnummer : String ejendomsidentifikation : UUID enhedsnummer : int aktnummer : String..n +svarforespørgselejendom +ejendom +svarforespørgselejendom <<session>> SvarForespørgselEjendom løbnr : int forespørgerident : String forespørgelsetype : ForespørgelseType afsendt : Timestamp <<enum>> ForespørgelseType BIL = EJENDOM = 2 PERSONBOG = 3 ANDELBOLIG = 4 MINETING = 5 +svarforespørgselejendom +svarforespørgselejendom +summariskhæftelse 0..n SummariskHæftelse (from summarisk) kreditor : String debitor : String meddelelseshaver : String hovedstolsum : int hovedstolvaluta : String rente : String anmærkning : String respekt : String dokumenttype : String tillægstekst : String meddelelser : String rådighedsindskrænkning : String dokumentnummer : int hæftelsesnr : int +summariskadkomst +svarforespørgselejendom..n SummariskAdkomst (from summarisk) adkomsthaverfornavn : String adkomsthaverefternavn : String adkomsthavercvr_cpr : String adkomstnummer : String anmærkning : String tilføjelsesmeddelelse : String erstatningsmeddelelse : String rådighedsindskrænkning_ : String tillægstekst : String frist : String +summariskadkomst +tinglysningsdokument +tinglysningdokument..n..n +tinglysningsdokument..n..n ScannedeAkter +scannedeakter (from forespørgsel) Tinglysningsdokument (from anmeldelse) modtaget : Timestamp +tinglysningsdokument 0..n løbenummer : int +tinglysningsdokument retskreds : int tinglysningsstatus : TinglysningStatus +tinglysningsdokument kreditkunde : boolean +summariskhæftelse..n anmeldersagsnummer : String digesttype : DigestType..n digest : String +tinglysningsdokument getdatoløbenummer() +tinglysningsdokument +servitut 0..n Servitut (from servitut) servitutnr : int servituttype : String anmærkning : String frist : String fristdato : Date Meddelelser : String +hæftelse Hæftelse (from hæftelse) tinglysningsdato : Date løbenummer : int hovedstol : BigDecimal valutakode : String kurstype : KursType kursdato : Date valutakurs : BigDecimal aflysningsdato : Date +summariskservitut 0..n SummariskServitut (from summarisk) datoløbnr : String påtaleberettig : String servituttekst : String tillægstekst : String rådighedindskrænkning : String..n +summariskservitut +adkomst..n Adkomst (from adkomst) oprinddato : Timestamp oprindløbenummer : int adkomsttype : AdkomstTyp beløbløsøre : BigDecimal købesum : BigDecimal datokøbesum : Date Resultatliste Figur 0: UML model for svar på fast ejendom forespørgsel. Hvis der er mere end et hit, vil fremsøgningen resultere i en liste med et antal fast ejendom objekter. Listen vil indeholde følgende fast ejendom oplysninger: Vejnavn Husnummer Postnr. By Ejendomsident Tinglysningsdato Dokumentløbenr. I kapitel 4, afsnittet vedr. informationsservices er system-system kald nærmere beskrevet. Det vil herefter være muligt at vælge det ønskede objekt vedrørende fast ejendom og få de summariske oplysninger præsenteret. Løsningsspecifikation: e-tl motor, v..0 Side 23 af 35