Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Environment

URL

Beta

https://beta.etinglysing.no/ws/Oppdrag?wsdl=OppdragWs.wsdl

Production

https://www.etinglysing.no/ws/Oppdrag?wsdl=OppdragWs.wsdl

Create/Update assignment

The action will put relevant information over This method is used to transfer broker data to www.etinglysing.no, easing the process of document creation, signing an tinglysing. The response is a unique id representing the oppdrag/assignment. This can be used for creating the correct URL to go directly to the Oppdrag in etinglysing.no. Consecutive calls with the same information will update the Oppdrag. The unique key for the oppdrag is oppdragsnr (the number used by the broker to identify a assignment)

Oppdrag model

Example:

...

and tinglysing.

Oppdrag model

Example:

Code Block
<opp:dokumentGrunnlag oppdragsnr="123654poi123lkj">  
  <dok:panteopplysninger>  
    <dok:fullsignert>true</dok:fullsignert>  
    <dok:pantebeloep valuta="NOK" verdi="100000"/></dok:panteopplysninger>  
    <dok:omsetningsopplysninger>  
      <dok:omsetningsnr>00003-00</dok:omsetningsnr>  
      <dok:omsetningsType>FRITT\_SALG</dok:omsetningsType>  
      <dok:utlystTilSalgPaaDetFrieMarked>true</dok:utlystTilSalgPaaDetFrieMarked>  
      <dok:kjoepesum>150000</dok:kjoepesum>               
      <dok:avgiftsgrunnlag>0</dok:avgiftsgrunnlag>  
      <dok:aarsak>HOVEDREGEL</dok:aarsak>  
    </dok:omsetningsopplysninger>  
    <dok:borettsandel orgnr="932305364" andelsnr="9" borettslagnavn="BAS">  
      <dok:selgere>  
        <dok:hjemmelshaver teller="1" nevner="1">  
            <ret:person id="12345678901">  
              <ret:fornavn>Thomas</ret:fornavn>  
              <ret:etternavn>Normann</ret:etternavn>  
              <ret:epost>test@example.com</ret:epost>  
            </ret:person>  
        </dok:hjemmelshaver>  
      </dok:selgere>  
      <dok:kjoepere>  
        <dok:kjoeper teller="1" nevner="1">  
          <ret:person id="1245678901">  
            <ret:fornavn>Kai</ret:fornavn>  
            <ret:etternavn>Normann</ret:etternavn>  
          </ret:person>  
        </dok:kjoeper>  
      </dok:kjoepere>  
    </dok:borettsandel>  
  </opp:dokumentGrunnlag>

Sellers

The element <dok:selgere>` is a wrapper element for different kind of sellers in an assignment. If the seller is the registered owner in the Land Register, use the element type dok:hjemmelshaver as shown above.

If the seller legally owns the property, but the previous transaction was not registered (tinglyst), the previous owner must also sign the new deed as he/she is still registered as owner in the Land Register. When transferring data for the assignment in this scenario, use the element dok:selgerTresidigSkjoete as shown in the below example. The previous owner should be transferred as dok:hjemmelshaver as well to reduce the amount of data the broker must type manually when creating the deed.The response contains oppdragsId that is a unique id representing the oppdrag/assignment. This can be used for creating the correct URL to go directly to the Oppdrag in http://etinglysing.no (read more about makeTokenUrls at Single Sign On (SSO) ). Consecutive calls with the same assignment number will update the assignment. oppdragsNr is unique within a department and should identify be the broker’s assignment in the core system.

Example response:

Code Block
languagexml
<dok<soap:selgerTresidigSkjoeteEnvelope teller="1" nevner="2xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <ret<soap:person id="02020254321">Body>
     <ret:fornavn>Fornavn02</ret:fornavn>
    <ret:etternavn>Etternavn02</ret:etternavn>
    <ret:epost>epost@post.no</ret:epost>
    <ret:mobil>41414141</ret:mobil>
  </ret:person>
</dok:selgerTresidigSkjoete>
<dok:selgerTresidigSkjoete teller="1" nevner="2">
  <ret:organisasjon id="918465731" navn="HJELP KATTEN">
    <ret:signaturBerettiget id="030303999999"><ns3:leggTilDokumentGrunnlagResponse xmlns="http://ws.etinglysing.no/oppdrag/dokumentgrunnlag/" xmlns:ns2="http://ws.etinglysing.no/oppdrag/dokumentgrunnlag/rettsubjekter" xmlns:ns3="http://ws.etinglysing.no/oppdrag">
      <ns3:return>
        <ret:fornavn>Ola</ret:fornavn><oppdragsNr>123654poi123lkj</oppdragsNr>
      <ret:etternavn>Normann</ret:etternavn>  <oppdragsId>609540</oppdragsId>
    <ret:epost>ola.normann@post.com</ret:epost>       <ret:mobil>55555555</ret:mobil><oppdatert>2024-07-02T11:08:16.545+02:00</oppdatert>
     </ret:signaturBerettiget>   </ret:organisasjon>
</dok:selgerTresidigSkjoete>

...

<opprettet>2024-07-02T11:08:16.545+02:00</opprettet>
      </ns3:return>
    </ns3:leggTilDokumentGrunnlagResponse>
  </soap:Body>
</soap:Envelope>

Sellers

The element <dok:selgere>` is a wrapper element for different kind of sellers in an assignment. If the seller is the registered owner in the Land Register, use the element type dok:hjemmelshaver as shown above.

If the seller legally owns the property, but the previous transaction was not registered (tinglyst), the previous owner must also sign the new deed as he/she is still registered as owner in the Land Register. When transferring data for the assignment in this scenario, use the element dok:selgerTresidigSkjoete for the current seller as shown in the below example. The previous owner should be transferred as dok:hjemmelshaver as well to reduce the amount of data the broker must type manually when creating the deed.

Code Block
languagexml
<dok:selgerTresidigSkjoete teller="1" nevner="2">
  <ret:person id="02020254321">
    <ret:fornavn>Fornavn02</ret:fornavn>
    <ret:etternavn>Etternavn02</ret:etternavn>
    <ret:epost>epost@post.no</ret:epost>
    <ret:mobil>41414141</ret:mobil>
  </ret:person>
</dok:selgerTresidigSkjoete>
<dok:selgerTresidigSkjoete teller="1" nevner="2">
  <ret:organisasjon id="918465731" navn="HJELP KATTEN">
    <ret:signaturBerettiget id="030303999999">
      <ret:fornavn>Ola</ret:fornavn>
      <ret:etternavn>Normann</ret:etternavn>
      <ret:epost>ola.normann@post.com</ret:epost>
      <ret:mobil>55555555</ret:mobil>
    </ret:signaturBerettiget>
  </ret:organisasjon>
</dok:selgerTresidigSkjoete>

The seller can be a person or an organization. Both must have specified the owning fraction, and may have email and mobile phone number. An organization can have a list of signatories. A person should not have a declaration of marital status.

...

Code Block
languagexml
<!--Optional:-->
<dok:vedleggsliste>
   <!--Zero or more repetitions:-->
   <dok:vedlegg>
      <dok:eksternId>?</dok:eksternId>
      <dok:type>?</dok:type>
      <dok:dataBase64>?</dok:dataBase64>
      <!--Optional:-->
      <dok:filnavn>?</dok:filnavn>
   </dok:vedlegg>
</dok:vedleggsliste>

The following applies:

...

eksternId must uniquely identify the document in the broker’s system

...

Only PDF documents can be sent to Kartverket.

...

</dok:vedleggsliste>

The following applies:

  • eksternId: Must uniquely identify the document in the broker’s system

  • type: Type of attachment (vedlegg). Se table below for supported types.

  • dataBase64: The document itself is base64 encoded. Only PDF documents can be sent to Kartverket.

  • filnavn: Files should have a filename (without path) so the broker can se the difference when there are two or more attachments of the same type. The element filnavn is optional in order to be backward compatible

  • The files do not have to be sent on every request (as the other data).

    • If the list is empty, we will not do anything to previous transferred files on that assignment

  • If an attachment is added and the assignment has an attachment with the given eksternId, this is interpreted as a changed file and we will overwrite the existing one.

  • Files should have a filename (without path) so the broker can se the difference when there are two or more attachments of the same type. The element filnavn is optional in order to be backward compatible

  • Valid vedlegg we will overwrite the existing one.

  • Valid attachment types:

Vedlegg type

Beskrivelse

SKIFTEATTEST_USKIFTEATTEST

Skifteattest, uskifteattest og bostyrerattest ved dødsboskifte

SKIFTEFULLMAKT

Skiftefullmakt

TESTAMENT

Testament og ektepakt ved dødsboskifte

BEGRUNNELSE_DOKUMENTAVGIFT

Begrunnelse for dokumentavgift

FULLMAKT_SELGER

Salgsfullmakt

FULLMAKT_KJOEPER

Kjøpsfullmakt

GJENSIDIG_TESTAMENT

Gjensidig testament

Heirs

From Etinglysing 51.62 (early July 2023) it It is possible to transfer information about heirs using the new, optional element arvinger that can hold zero to many arving. Example below is the minimum data to transfer for a heir (person).

...

When using the appropriate attachment, a person or organization can be given the authority to sign on behalf of another part. From Etinglysing 51.62 (early July 2023) it is possible to transfer information about these signatories (fullmektiger)be given the authority to sign on behalf of another part. Transferring these signatories, and for whom the can sign, will aid the broker when creating documents in the UI. In order to be backward compatible, the existence of this element is not required.

...

Using the assignment type DOEDSBO you mark the assignment as a “dødsbo”. You use this when you want to generate a “Hjemmelserklæring”. In a “dødsbo” the seller is deceased and you want to transfer the property over to the heirs. You do not have to add fraction/brøk (teller and nevner (brøk) for the deceased seller, we will add the correct brøk fraction for the seller if not provided.

Using the assignment type STANDARD you need to provide a teller and nevner (brøk) fraction for the seller. We validate the brøkfraction.

Example of an assignment for use when you want to generate a Hjemmelserklæring:

Code Block
languagexml
<opp:dokumentGrunnlag oppdragsnr="123654poi123lkj">
  <dok:oppdragType>STANDARD</dok:oppdragType>
    <dok:oppdragType>DOEDSBO</dok:oppdragType>
 
  <dok:omsetningsopplysninger>
 
    <dok:omsetningsnr>1234</dok:omsetningsnr>
 
    <dok:omsetningsType>SKIFTEOPPGJOER</dok:omsetningsType>
 
    <dok:utlystTilSalgPaaDetFrieMarked>false</dok:utlystTilSalgPaaDetFrieMarked>

     <dok:kjoepesum>0</dok:kjoepesum>
      <dok:avgiftsgrunnlag>0</dok:avgiftsgrunnlag>

     <dok:aarsak>SKIFTEOPPGJOER</dok:aarsak>
    </dok:omsetningsopplysninger>
    <dok  <dok:borettsandel orgnr="932305364" andelsnr="9" borettslagnavn="BAS">  
 
    <dok:selgere>  

       <dok:hjemmelshaver>
                <ret:person id="12345678901">
                <ret      <ret:fornavn>Thomas</ret:fornavn>
                      <ret:etternavn>Normann</ret:etternavn>
                      <ret:epost>test@example.com</ret:epost>  
   
        </ret:person>  
        </dok:hjemmelshaver>  
 
    </dok:selgere>
       <dok:brukAvBolig>BOLIGEIENDOM</dok:brukAvBolig>

     <dok:typeBolig>FRITTLIGGENDE_ENEBOLIG</dok:typeBolig>
       <dok   <dok:arvinger>
            <dok:arving teller="1" nevner="1">
   
        <ret:person id="07070712345">
  
           <ret:fornavn>Person Heir</ret:fornavn>
              <ret:etternavn>With Fraction</ret:etternavn>
 
            <ret:epost>person.heir@arving.no</ret:epost>
   
          <ret:mobil>12345678</ret:mobil>

           </ret:person>
   
      </dok:arving>
       <   </dok:arvinger>
      <</dok:borettsandel>
 
  <</opp:dokumentGrunnlag>