developers.valex.com.au - Valex Developer Documentation

The following examples are valid values for PropertyCharacteristics/@YearBuilt:

• Built About 1960
• Circa 1960
• 1960 (for the precise year)

The format must match exactly (the words are at the beginning of the string and cannot be misspelled), otherwise it will default back to "precise year" by truncating non-numeric characters.

We have a number of LIXI identifiers. This article discusses the ValEx Valuer ID, which is unique to a valuer in Valuation Exchange.

The valuer ID is an integer, which is formatted in LIXI as:

VXVLR-%06s

For example, a valuer ID of 123 becomes:

VXVLR-000123

The field is generally seen in //RelatedParty[@RelPartyType="Valuer"]/Identifier[@Type="VPMAssigned"]/@UniqueID, which is usually used in Assigned Workflow.

You can access a list of Valuers attached to a given Valuation Firm by navigating to Management -> Valuers -> Export CSV (you can log in with your SOAP credentials). The Valuer ID column is what should be used.

We noticed that a number of implementations did not appear to correctly implement replacement insurance transfer.

As of 4th July 2010 we'll now be enforcing this for all shortform based reports as a critical check.

The Replacement Insurance field will become a mandatory field within Valuation Exchange. The field will be able to accept a numerical entry (1234.56), or text provided by the valuer. It can no longer be empty.

We propose the following drop down selections that the valuer can choose to select:

• Body Corporate Responsibility
• Building Insurance arranged by Strata Corporation
• Building Insurance arranged by the Body Corporate
• Refer to Owners Corporation

Valuation Firms will need to ensure that this field is a mandatory field for the valuer to complete, otherwise Valuation Exchange will deliver a LIXI Error Message requesting the field prior to the completion of the report.

See also Replacement Insurance

Valuation Exchange initially designed our soap connectivity to make use of a number of response codes.

Time has shown us that this is simply a bad idea - the codes are uninformative, and it makes it harder to understand issues at both ends of a connection.

As a result, we'll be deprecating the use of response codes as of July 1st 2010.

Indicating success

Returning a '0' is still the preferred indication of a successful webservices call; and is the easiest for us to parse.

Raising Errors

We strongly encourage integration partners to simply raise a SoapFault (php, .NET, Java) with the appropriate error strings.

This allows both parties to see informative error or even backtrace information; and more quickly resolve problems.

Handling Errors

ValEx raises SoapFaults when an error is encountered. The only exception is when parsing responses - our queuing system processes the majority of business logic asynchronously. In these instances, we'll incidate a success on the original soap operation, but generate a failure email later.

We'll be looking to further improve this behaviour at a later date, with tools like our compliance web service.

The types of error messages you will see are covered in our article on common errors.

Response codes

This style of interaction is deprecated

Sample response

A successful response.

Just a quick note to let our users know - we've started rendering the correct timezone information for jobs in our LIXI correspondence.

We'll be incrementally rolling this out to all of our valuation partners in the near future.

Before we rendered:
<Time>08:00:00</Time>

Now we will render
<Time>08:00:00+10:30</Time> (or <Time>08:00:00+09:30</Time> when DST changes occur).

This should have little affect on implementors. According to ISO 8601,

If no time zone information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. It is usually preferable to indicate a time zone (zone designator) using the standard's notation.

If you have any questions regarding this topic, please post a comment.

Assigned workflow is sent by a Valuation Firm to notify that a Valuer has been assigned to a job and also to notify that an appointment has been made.

If an accepted workflow has not been sent previously, the job will also be accepted.

What fields are required for a Valuation Firm to send?

• The Valuation Firm must be provided as a RelatedParty.
• An authorised Valuer (identified by a Valuer ID) must be provided as a RelatedParty.
• A DateOfInspection containing the scheduled appointment time is optional. As soon as this information is available, we recommend it be sent.

More details on the main workflow article.

The LIXI draft standard has for a RelatedParty/@RelPartyType:

<xs:enumeration value='AccessFacilitator' />
<xs:enumeration value='Mortgagee' />

for our

<xs:enumeration value='Owner' />
<xs:enumeration value='Applicant' />

We will be parsing from Valuation Firms AccessFacilitator (which will map to Owner) and Mortgagee (which will map to Applicant).

To maintain backwards compatibility, we will not be rendering this information until this is out of a draft state; we will only be parsing for the time being.

Call for Testing Partners

This is currently implemented in version 1.3.9 of our LIXI schema, which is available for testing for interested Valuation Firms.

https://test.valex.com.au/lixi/schema/1.4.0/ValuationTransaction.xsd

We've updated our test site to the next version of ValEx code. Please let us know if you encounter any issues.

ValEx supports a number of WorkFlow events, but doesn't have a way to map "Attempting Contact" and "Appointment Cancelled".

We're looking for input on the best way to implement such functionality between us and our valuation firms.

Our suggestions are:

• Attempting Contact: After the initial 'instructed' / 'assigned' packets, sending one of these would represent 'attempting contact' and provide notes as appropriate.
• Appointment Cancelled: Sending an appointment workflow, and then an InProgress (without a new appointment date) would cancel an appointment