Valuation Firm Guide

New XSD Published

We've been detailing some of the upcoming changes to our implementation of LIXI over the past few days. To assist in migration for third parties, we'd like to share with you an initial draft of our next version XSD.

It can be found at

It should be a few steps closer to the original LIXI standard. We'll be bringing this xsd into effect as of July 1.

Deprecated: EssentialRepairs under RiskAnalysis

In our effort to move closer to the LIXI standard we are deprecating our use of EssentialRepairs under the RiskAnalysis element.

We will no longer render this field on any outgoing valuation responses.

We will be outputting EssentialRepairs under the PropertyCharacteristics element, as per the lixi standard.

We will be still parsing any information submitted in the old location for a number of months, but intend on fully removing it at a future date.

Our rendering changes will take place as of July 1

Configuring Your Firewalls

We have a number of public IP addresses which need to be added to firewall configurations. Without this, third party systems may have difficulty in establishing a connection to and from us.

  • - this is our virtual IP address, which is where we accept incoming connections. All outgoing connections should also originate from this address.
  •,, - this is are our primary load balancers. In the event of an emergency, we may fail over to any of the IP addresses listed here. If that were to happen, connections from our system may appear come from either

These public addresses apply to both our test and production environments.

Recommend practice: provide dummy methods in your WSDLs

For easy and safe debugging of connection problems, we recommend the implementation of a "repeat" method in your web services end point. Ours lives at

Effectively, the entire implementation of the method would simply be:

     * Repeat a string back
     * @param string    $input
     * @return string   $input
    public function repeat($input) {
        return $input;

This allows people to connect easily to each other, and ensure what they send is correctly received.

It also could be used as a stub in your unit testing.

Recommended Practice: Test Driven Development

We extensively use unit testing here at ValEx.

A lot of the errors we see seem to be related to 'common-sense' failing - for instance, sending back date information in packets that can't be valid.

To prevent these types of errors, we suggest writing out unit tests ahead of time utilising one of the unit test frameworks in your language.

We recommend that your unit tests:

  • Validate sample packets generated from your system against an XSD
  • Deliberately try to generate wrong information (ie, dates), and expect your system to gracefully handle the error
  • Explicitly cover rendering (data to xml), parsing (xml to data), processing (data to actions), and generation (actions to data), connecting (xml -> outgoing soap request), and serving (incoming soap request -> xml)

Examples include:

  • Test that you cannot send a workflow packet containing inspection date details that are before the date of the job
  • Test that if you don't have certain information (ie, dates, comments), the node is removed from the tree, rather than simply blank
  • Test that you can't send certain information (ie, valuation response) before you've sent other data (workflow for valuation accepted)


Using some unit testing frameworks, it's very easy to generate Agile Documentation. Below is a some of our agile documentation, demonstrating just some of the tests we run against our lixi & webservices code. Implementing similar tests is definitely encouraged.


  • Delay status correctly parses
  • Assigned status correctly parses
  • Accepted status correctly parses
  • Inspected status correctly parses
  • Corrupt work flow delay causes failure
  • Corrupt work flow assigned causes failure
  • Corrupt work flow inspection causes failure
  • Stupid historical dates cause failure
  • Invalid time fails
  • Missing date of inspection fails
  • Inspection date is correctly parsed
  • Invalid inspection date fails
  • Lixi date objects should not default to today
  • Lixi time objects should behave correctly


  • Should correctly render workflow delay information
  • Should fail to render invalid delay information
  • Should correctly render workflow appointment information
  • Should fail to render invalid appointment information
  • Should correctly render workflow inspection information
  • Should fail to render invalid inspection information


  • Inbound workflow delay should add delay
  • Inbound workflow action should set appointment made
  • Inbound workflow action should set inspection date


  • Should parse response
  • Should raise value exception when given an unknown suburb in comparison sales data
  • Should find attached pdf report in response
  • Should find attached images in response
  • Should raise xml exceptions when given invalid xml


  • A valuation response containing a residential short form dwelling report should render correctly
  • Sales evidence comparison comments should map to lixi

How do Delays work in Valex?

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.

    <Identifier UniqueID="Dummy_Value" Type="VPMAssigned"/>
        <Identifier UniqueID="VXJ-000000012345" Type="VPMAssigned"/>
        <Identifier UniqueID="REF-001" Type="LenderAssigned"/>
    <MessageBody Type="Information">
        <Status Name="Delayed">
        <Identifier UniqueID="Dummy_Value" Type="VPMAssigned"/>
        <WorkFlow Type="Status" DelayReason="TenantDeniedAccess" FromStatus="Accepted">
            <Comment>Owner unvailable until specified date</Comment>

The key bits of information here are

The status of the job
When the delay was added
The user's delay reason
The estimated end of the delay
The user's comments

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.


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.

SOAP and Valex Authentication

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:


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.

Getting my account setup

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

How do I validate my lixi xml?

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=""


  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.

Syndicate content