developers.valex.com.au - Valex Developer Documentation

Are you doing the RelatedPartySegment of a valuation request? A little confused by the XSD?

Parsing RelatedParty phones

For instance, a HomePhone is a collection of Phones, with a PreferredContactMethod attribute.

But when you look further down the tree, you can see that the Mobile and Fax nodes also have a PreferredContactMethod attribute. Further, FixedPhone doesn't. So which do you use?

Valex will by default assume that WorkPhone is the most important contact information. It will first look for HomePhone information, then override it with WorkPhone information. It will ignore any PreferredContactMethod attributes applied to a WorkPhone or HomePhone node.

Valex will honor the PreferredContactMethod on the individual phone items (Fax, Mobile) and add those into the notes for that particular contact.

For reference, here's an example RelatedPartySegment

  <RelatedPartySegment>
    <RelatedParty RelPartyType="Lender">
      <Identifier Type="LenderAssigned" UniqueID="RelatedParty-Lender"/>
      <PersonName>
        <FirstName>Job</FirstName>
        <Surname>Orderer</Surname>
      </PersonName>
      <WorkPhone PreferredContactMethod="Yes">
        <Phone>
	  <!-- The '03' can also be put in the AreaCode attribute, but should be excluded from the Phone number -->
          <FixedPhone>03 9675 3477</FixedPhone>
        </Phone>
      </WorkPhone>
    </RelatedParty>
    <RelatedParty RelPartyType="Other" RelPartyDescription="Applicant">
      <Identifier Type="LenderAssigned" UniqueID="RelatedParty-Party-1"/>
      <PersonName>
        <FirstName>Borrower</FirstName>
        <Surname>Name</Surname>
      </PersonName>
    </RelatedParty>
    <RelatedParty RelPartyType="Other" RelPartyDescription="Access Provider">
      <Identifier Type="LenderAssigned" UniqueID="RelatedParty-Access-1"/>
      <PersonName>
        <FirstName>Inspection</FirstName>
        <Surname>Contact</Surname>
      </PersonName>
      <WorkPhone>
        <Phone>
          <FixedPhone AreaCode="03">123456</FixedPhone>
        </Phone>
      </WorkPhone>
      <WorkPhone>
        <Phone>
          <Mobile PreferredContactMethod="Yes">0413 153 105</Mobile>
        </Phone>
      </WorkPhone>
    </RelatedParty>
  </RelatedPartySegment>

Who Can Add Delays?

Delays in Valuation Exchange are entered by administrative valuation firm users or
valuers; typically through the interface. We give users a number of preset
reasons for the delay, and also ask for an expected end, as well as
any other comments pertaining to the delay.

The default expected end of a delay is typically 2 business days
from the point of adding a delay; but can be easily overridden by users.

When Can Delays Be Added?

We allow delays to be applied at any point during the life cycle of a job, not
just prior to an inspection - though this is typically when a delay is used.

What Happens When A Delay Is Added?

As soon as a delay is added to the job, valex check for any notification requirements of the client or related parties to the job. For LIXI client organisations a workflow packet is prepared and queued for sending; though other options exist such as email or fax.

What's In The Delay Workflow Packet?

A delay workflow packet is effectively the same as a regular valuation request or
response packet. The key differences are in where we input our information.

We also model a delay reason.

<Message>
    <Identifier UniqueID="Dummy_Value" Type="VPMAssigned"/>
    <MessageRelatesTo>
        <Identifier UniqueID="VXJ-000000012345" Type="VPMAssigned"/>
        <Identifier UniqueID="REF-001" Type="LenderAssigned"/>
    </MessageRelatesTo>
    <MessageBody Type="Information">
        <Status Name="Delayed">
            <Date>2006-10-18</Date>
        </Status>
    </MessageBody>
    <ValuationType>
        <Identifier UniqueID="Dummy_Value" Type="VPMAssigned"/>
        <WorkFlow Type="Status" DelayReason="TenantDeniedAccess" FromStatus="Accepted">
            <ExpectedValuationDate>
                <Date>2007-11-25</Date>
            </ExpectedValuationDate>
            <Comment>Owner unvailable until specified date</Comment>
        </WorkFlow>
    </ValuationType>
</Message>

The key bits of information here are

The status of the job

Message/MessageBody/Status

When the delay was added

Message/MessageBody/Status/Date

The user's delay reason

Message/ValuationType/WorkFlow/@DelayReason

The estimated end of the delay

Message\ValuationType\WorkFlow\ExpectedValuationDate\Date

The user's comments

Message\ValuationType\WorkFlow\Comment

Valex Specific Notes

1. Our system requires comments for all delays being added, even though this is not required by the XSD.
2. Any date you submit, our system will assume is YYYY-MM-DD 0:00:00. When possible, submit a Time as well for greater clarity.
3. Our system does not allow delays to be set in the past.

Delays, Workflow and Service Level Agreements

When we receive a workflow packet, we add a delay as soon as we process it. If there are any errors, a delay is not added to the job.

Due to conditions affecting our servers, your workflow packets may be queued for a short period of time (a few minutes, typically); which may slightly affect your service level agreements.

Timezones

We assume that all dates and times given are in the timezone of the job being processed Australia/Adelaide timezone. A better solution would be to assume the timezone of the job, or to send ISO 8601 dates - however we do not have specifc plans to implement either solution anytime soon.

Delay end date

When an expected valuation date is provided, ValEx assumes the close of business on that particular day (rather than what is specified in the /Time node). That is in sync with the user interface behaviour of ValEx - we may look at changing this if there is enough interest.

At valex we use a SOAP webservice which contains a LIXI payload. An example of the soap envelope is found here soap envelope. This soap envelope needs to contain an element AuthHeader which will be used to authentication. The format of the soap header is as follows:

 <SOAP-ENV:Header>
  <ns2:AuthHeader>
   <userName>Username_you_provided_us</userName>
   <password>Password_you_provided_us</password>
  </ns2:AuthHeader>
 </SOAP-ENV:Header>


This is the soap header we expect when you send a packet to us, and the soap header we send to authenticate against your webservice

Note: We'd very much like to standardize upon one simple existing method for authentication information, as illustrated in the example above. As such, we're unable to customize the authentication we use in many cases - this would break compatibility with many other clients or valuation firms; or entail a significant amount of work for each party.

AuthHeader vs vAuthHeader:
.NET developers may find this article useful.

The new updated XSD can be found in the attachments under the valfirm guide.

• MarketActivity, MarketDirection, and MultiTierMarket attributes from FullRegistered have been removed.
• EssentialRepairs attribute has been added to RiskAnalysis
• Comment element has been added to SalesMarket

To send or receive work from Valuation Exchange by any of our web services; you need to be able to login to our application.

If you don't have a login, let us know

You need:

• XMLSpy
• The xml you wish to validate.
• The xml should point to a copy of the latest XSD; in the root node of the document.
  For example:

  
  <ValuationTransaction xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="https://ws.valex.com.au/lixi/schema/1.3.1/ValuationTransaction.xsd">

Validating

1. Goto the XML menu
2. Choose validate

You will either be presented with one of two results - XML is not well formed (and a list of errors), or XML is valid.

Most common errors

If you've got an error you don't know how to resolve, let us know, and we'll pop it up here.

Why do I need to validate?

In short, if your xml can't be understood by our system we can't process it. We validate all incoming lixi information; and reject anything invalid.

Should I get this built in to my software?

By all means, please do! A quick google search can help you find examples on how to do this in your language.

By building in XSD validation before you send us any information; you can be assured that we'll have no trouble understanding and extracting the information we need.

Have a read of our article on XSD validation for more.

I don't have/can't get XMLSpy

We've built a limited XSD validation tool. You'll need to login with your valex username and password.

• For clients
• For valfirms

Welcome to developers.valex.com.au.

This site is currently in development and we will be constantly improving the documentation that's available. Our plans for this site are:

• Step by step guides for valfirms and clients
• Code Samples
• Complete XML examples
• FAQ

We have two guides up so far for clients and valfirms with xml examples.

As for questions either Email Us or ask in the Forum.