The API provides document creation of the above mentioned types, on the format generate<TYPE>. Calling any generate operation will return this structure:
Status | id, status code and when it was created |
|---|---|
status | the unique id of the document, created date and state |
document | base64 encoded BIDXML, type corresponds with the created document, format and type |
warnings | warnings (if any) from validation received from Kartverket |
version | KARTVERKET (historically it could have been EDOK) |
dokumentMessages | A list of documentMessage that contain all error or information messages for the tinglysing operation on a specific document. It might be returned from the tinglys or the getStatus operation. |
Example:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:generatePantedokumentResponse xmlns:ns2="http://dokument.ws7.etinglysing.no/">
<return>
<status>
<created>2018-09-06T14:09:34.710+02:00</created>
<id>15742141</id>
<statusCode>OPPRETTET</statusCode>
</status>
<documentHolder>
<content>PEJhbmtJRFhNT...</content>
<format>BIDXML</format>
<type>PANTEDOKUMENT</type>
</documentHolder>
<documentVersion>KARTVERKET</documentVersion>
</return>
</ns2:generatePantedokumentResponse>
</soap:Body>
</soap:Envelope>
Generate pantedokument
The integrator initiates the process by sending a data structure (as described in the WSDL) to the web service. Etinglysing will return an object containing the document itself, a reference to the document in etinglysing and some key information about it.
Normal flow
Example request:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dok="http://dokument.ws7.etinglysing.no/">
<soapenv:Header/>
<soapenv:Body>
<dok:generatePantedokument>
<pantedokument referanse="Example">
<panteobjekter>
<panteobjekt>
<matrikkel
kommunenummer="1234"
gaardsnummer="1"
bruksnummer="1"
festenummer="0"
seksjonsnummer="0"
eiendomsnivaa="G"/>
<hjemmelshavere>
<hjemmelshaver>
<organisasjon id="123456789">
<navn>Organization name</navn>
<!--Optional, not needed for production-->
<!--Will be validated towards Enhetsregisteret if present-->
<signaturberettigede>
<signaturberettigede id="12345678901">
<fornavn>First Name</fornavn>
<etternavn>Surname</etternavn>
<epost>person@example.com</epost>
</signaturberettigede>
</signaturberettigede>
</organisasjon>
<broek teller="1" nevner="1"/>
</hjemmelshaver>
</hjemmelshavere>
</panteobjekt>
</panteobjekter>
<pantebeloeper>
<pantebeloep valuta="NOK" verdi="100000"/>
</pantebeloeper>
<panthavere>
<panthaverId>123456789</panthaverId>
</panthavere>
<dokumentflyt>DOKUMENT_TIL_TINGLYSING</dokumentflyt>
<refinansiering>false</refinansiering>
</pantedokument>
<options>
<returnPdf>false</returnPdf>
</options>
</dok:generatePantedokument>
</soapenv:Body>
</soapenv:Envelope>
Example response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:generatePantedokumentResponse xmlns:ns2="http://dokument.ws7.etinglysing.no/">
<return>
<status>
<created>2018-09-06T14:09:34.710+02:00</created>
<id>15742141</id>
<statusCode>OPPRETTET</statusCode>
</status>
<documentHolder>
<content>PEJhbmtJRFhNT...</content>
<format>BIDXML</format>
<type>PANTEDOKUMENT</type>
</documentHolder>
<documentVersion>KARTVERKET</documentVersion>
</return>
</ns2:generatePantedokumentResponse>
</soap:Body>
</soap:Envelope>
Validation & error handling
Example response:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Ugyldig personnr eller organisasjonsnr: 123456789</faultstring>
<detail>
<ns2:FellesDokumentException xmlns:ns2="http://dokument.ws7.etinglysing.no/">
<exceptionId>1536235901863</exceptionId>
<documentMessages>
<documentMessage>
<errorGroup>VALIDERINGSFEIL</errorGroup>
<message>Ugyldig personnr eller organisasjonsnr: 123456789</message>
<errorCode>9014</errorCode>
</documentMessage>
</documentMessages>
</ns2:FellesDokumentException>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
If an error is detected, the document is not produced and an error response is returned to with detailed information. The integrator can correct the error and try again.
Information messages
In some cases informational messages are returned alongside the document. These messages do not prevent the document from being generated, but imply that the integrator need to ensure/think of how to process the document further.
How to set document flow
When generating a mortgage you may have two scenarios:
Send the document to the Land Registry
Send the document to a broker
This you can control by setting the flow. The possible flows are:
DOKUMENT_TIL_TINGLYSING
Document to be sent directly to LR
This is equivalent to eiendomsoverdragelse=false.DOKUMENT_TIL_OPPGJOER
Document to be sent to broker.
This is equivalent to `eiendomsoverdragelse=true and would produce a document even if there is no electronic settlement matching the document. This flow should be used to send to brokers, through any channel.DOKUMENT_TIL_EKSISTERENDE_OPPGJOER
Document to be sent to broker through the Ambita service; Electronic Property Settlement (EPS). This flow prevents the document from being generated if there is no relevant settlement in the service.
How to migrating to version 7
Compared to V5/V6 there has been som small changes to tidy the model and remove a known bug. In previous, when a organization was the owner, the signaturberettigede had to be populated to make it work. This was unintentional and is fixed in V7.
How to set the property
Previously each property was modelled as either borett or matrikkel:
<eiendommer>
<matrikkel kommunenr="1234"
gaardsnr="1"
bruksnr="1"
festenr="0"
seksjonsnr="0"
eiendomsnivaa="G">
</matrikkel>
</eiendommer>
From V7 the property contains a matrikkel or borett
<panteobjekter>
<panteobjekt>
<matrikkel kommunenummer="1234"
gaardsnummer="1"
bruksnummer="1"
festenummer="0"
seksjonsnummer="0"
eiendomsnivaa="G"/>
</panteobjekt>
</panteobjekter>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:dok="http://dokument.ws7.etinglysing.no/">
<soapenv:Header/>
<soapenv:Body>
<dok:generatePantedokument>
<pantedokument referanse="Example">
<panteobjekter>
<panteobjekt>
<matrikkel
kommunenummer="1234"
gaardsnummer="1"
bruksnummer="1"
festenummer="0"
seksjonsnummer="0"
eiendomsnivaa="G"/>
<hjemmelshavere>
<hjemmelshaver>
<organisasjon id="123456789">
<navn>Organization name</navn>
<!--Optional, not needed for production-->
<!--Will be validated towards Enhetsregisteret if present-->
<signaturberettigede>
<signaturberettigede id="12345678901">
<fornavn>First Name</fornavn>
<etternavn>Surname</etternavn>
<epost>person@example.com</epost>
</signaturberettigede>
</signaturberettigede>
</organisasjon>
<broek teller="1" nevner="1"/>
</hjemmelshaver>
</hjemmelshavere>
</panteobjekt>
</panteobjekter>
<pantebeloeper>
<pantebeloep valuta="NOK" verdi="100000"/>
</pantebeloeper>
<panthavere>
<panthaverId>123456789</panthaverId>
</panthavere>
<dokumentflyt>DOKUMENT_TIL_TINGLYSING</dokumentflyt>
<refinansiering>false</refinansiering>
</pantedokument>
<options>
<returnPdf>false</returnPdf>
</options>
</dok:generatePantedokument>
</soapenv:Body>
</soapenv:Envelope>
How to handle additional signatures
For some cases it is not enough that the owners sign the document. This typically means that there are “rettighetshavere” that needs to be taken into account. If not taken into account the service will respond with validation errors on generate (and that could be valuable and correct). If the case is, however, that you intend to get these signatures, the signature role must be applied. This tells the service that “I’ve got it!”.
There are four types of roles:
Role | Description |
|---|---|
BORTFESTER | The land owner that lease out land |
RETTIGHETSHAVER_I_URAADIGHET | A legal person is blocking registration |
UTSTEDER | The seller is not the land owner |
PANTSETTER | The legal person if not equal to the land owner |
In V7 this is put outside the property, hence yields the whole document (across all properties)
<pantedokument referanse="Demo">
<!--Optional:-->
<signatarroller>
<!--Zero or more repetitions:-->
<signatarrolle>
<!--1 or more repetitions:-->
<signatarrolleTyper></signatarrolleTyper>
<organisasjon id="?">
<navn>?</navn>
<!--Optional:-->
<signaturberettigede>
<!--Zero or more repetitions:-->
<signaturberettigede id="?">
<fornavn>?</fornavn>
<etternavn>?</etternavn>
<!--Optional:-->
<epost>?</epost>
</signaturberettigede>
</signaturberettigede>
</organisasjon>
<person id="?">
<fornavn>?</fornavn>
<etternavn>?</etternavn>
<!--Optional:-->
<epost>?</epost>
</person>
</signatarrolle>
</signatarroller>
</pantedokument>
How to handle fractions
If you do not have the individual fraction owned by each person (“idell andel”) you may set the total fraction per property instead..
We have added two optional attributes to the WSDL on the Eiendom node (Matrikkel or Borett).
There are:
Totalteller (Total nominator)
Totalnevner (Total denominator)
Once these are given, the teller and nevner applied to the individual hjemmelshaver are ignored and correct values are loaded from Grunnboken. This will not work for documents used in transfer of ownership (skjøte), as the future fractions are not known.
Example:
Figure 4: Example total fractions
The picture shows how the borettsandel has added the two new attributes. The teller/nevner shown in the example are not used, and can therefore contain any value.
Validation. Using total fractions will check if the total fraction equals the summed fractions, fetched from Grunnboken, of the hjemmelshaver-list. Also, if owners (hjemmelshaver) do not match the Grunnbok, exceptions will be thrown.
How to handle roles
This feature enables the integrator to generate documents on behalf of another organization. Once added into the request, the document will be generated accordingly unless the validation fails to validate that the respective organisation is defined as rekvirent or panthaver (dokumenteier) in the user profile.
Figure 5Example rekvirent & panthaver