developers.valex.com.au - Valex Developer Documentation

We'll be making a small change to what we parse from LIXI responses.

Previously, we would look at:

\\SalesEvidence[@OverallComparability] and \\SalesEvidence[@OtherSimilarity] - we would merge the two together if both were present.

We are changing that behavior around the start of October (Friday 3rd).

Now, we'll be only looking at \\SalesEvidence[@OtherSimilarity] - a string.

You can still specify both of the attributes if you want, however please do check that the OtherSimilarity attribute holds the comparison to subject property comments.

Connection Errors (SOAP)
Either end of the systems is unavailable - you can't connect to anything.

The people to fix it are usually IT.

"Missing" information transferring from your system to ValEx
Usually this is going to happen because of:

• There's something about this property which is extra / different from the large majority of others
• The valuer wasn't required to fill it out at your end, but ValEx wanted them to
• ValEx IT broke something
• There was some client requirement which wasn't clear at your end (see previous).

The quickest way to fix the majority of these is to log in to ValEx itself and see what fields are missing.

For instance, if your valuers know they filled it in in your system and it didn't come across, raise it with both IT departments. Putting in a job note (valex system) doesn't hurt either.
Or if it's a case of the valuer put in something quite sensible at your end and we've put it in a different/confusing place; certainly raise it with both IT departments.
We'll get actual valuers who know what's going on at either end to guide us to the correct outcome.

Information that is correct, but in the wrong order
Sometimes jobs can be reassigned, cancelled, assigned to a valuer twice, or completed and more information is sent - ValEx will usually give you a bit of an error if it notices this.

A valuer is already assigned, can't go back to an accepted state
ValEx models "I want to do this job" and assigning a valuer as the same event - other systems don't.

To work around that, when you accept a job, we assign it to a valuer named "Office Valuer".
If you try to accept a job twice; the system gives you an error - you've already got it assigned to you.

Job is not allocated to your valfirm, please contact ValEx Team for further information
Someone has reassigned the job to another valuation firm - they should have also given you a phone call or email beforehand.

Valuer Not Found
ValEx couldn't find the right valuer identifier, so it tried looking up by name, email and phone number.
It still couldn't work out which valuer you wanted.

To fix:
Use the Valuer CSV export feature to get the right Valuer ID (http://developers.valex.com.au/?q=node/47).

Unable to change job because of existing state:
This job is currently in a state where you can't perform the action on it.

For instance, the job is marked as complete, so you can't further alter the details (Fix: Contact ValEx to lodge a post valuation query / amend the report)
Or the job is marked as 'logged', and you haven't accepted it / assigned a valuer.

You need to put some comments in
This usually happens if you add a delay to a job without putting in a brief explanation. We're fixing the wording of this one soon.

Please give more information
You are declining / rejecting a job without adding a comment. We're also improving the wording of this.

Unknown sales suburb detected
We can't recognize the combination of suburb name and postcode.

If you have a quick check of Australia Post, and your information is correct, let us know and we'll add a new one.

We are generally pretty up to date and import their information regularly.

Recent sale is not currently under contract, must enter a valid date
This happens when a job has a Contract Price, but the information provided back doesn't include a Contract Date; or you haven't indicated that it is currently under contract.

ValEx has a number of identifiers it uses in the //RelatedPartySegment/RelatedParty/Identifier section.

The most common ones you will encounter are:

VXV-001234: A valfirm ID, representing a Valuation Firm
VXF-001234: A funder ID, representing a Funder organization
VXCL-001234: A client ID, representing a Client/Mortgage Manager organization
VXVLR-000012: A valuer ID, representing the Valuer completing the valuation report
VXA-000012: An authorising valuer ID, representing a valuer who is an authorising signatory for the valuation report
VXJ-000000001234: A job ID, representing the process of a Valuation in ValEx

We strongly encourage implementers to avoid using raw strings like company name.

As an example, if person is married or a company acquired, this can break the existing functionality quite easily.

It is also worth noting that we tend to parse things which are //Identifier[@Type="VPMAssigned"]

RP IDs

ValEx renders an identifier from rpdata.com.

This is found in //RealEstate/Identifier[@Description="RP ID" AND @Type="VPMAssigned"]/@UniqueID when it is available.

A quick note to let our users know there's a slightly different version of the valuation firm LIXI schema.

We've simply added in a new //FullRegistered[@ValSubType], CheckVal (for check valuations).

See also: Current LIXI Schema (XSD)

In a valuation lifecycle, there are two distinct phases. The first in the valuation request; provided by the customer, who is rendering an estimated value on some basis - like a Contract amount.

The other is the valuation response, completed by the valuer.

Where a contract of sale is provided, the //RecentSale@SalePrice should generally be equal to, but not the same field as the //EstimatedValue figure.

Scenarios where this may differ? The valuer has found an updated contract of sale which is different to what the customer provided.

Mapping

ValEx expects to find //SalesMarket nodes for FullRegistered and other shortform related valuations.

We require:
//SalesMarket/RecentSale/Date
//SalesMarket/RecentSale/@SalePrice
//SalesMarket/RecentSale/@IsContract

and

//SalesMarket/@MarketActivity
//SalesMarket/@MarketDirection
//SalesMarket/@MultiTierMarket

Which is equivalent to the Sales Evidence tab in ValEx itself.

Important to remember:
//SalesMarket/MultiTierMarketComment is required when you specify //SalesMarket[@MultiTierMarket="Yes"]

Report Integrity

ValEx is looking to ask more questions around the contract of sale, you can read more in the main article

We'll be adding a New Document Upload notification in an release of ValEx (approximately July 27th), as discussed in the forum.

We'll also be adding new document types into ValEx itself.

You will be able to subscribe your valuation firm to this event, and receive emails with attached documents.

In the longer term, we'll model this in LIXI WorkFlow as an AmendedValuationRequest.

Just a quick note to point out the value of ensuring your maximum packet upload size is sufficient to handle a valuation response.

A construction valuation request with full supporting documents can reach anywhere up toe the 10MB mark regularly.

A typical valuation response will have a report PDF, as much data as can be put into the LIXI document itself, several photos - it's pretty easy to edge up to around the 3-4MB mark.

We suggest testing your service to handle large LIXI documents, and contacting us if you have any questions.

ValEx needs to know:

• Borrower(s)
• Inspection Contact(s) (Who will provide access to the property)

See our example request.

The xpaths we need are:

• //RelatedParty[@RelPartyType="Other" AND @RelPartyDescription="Applicant"] - A borrower / applicant
• //RelatedParty[@RelPartyType="Other" AND @RelPartyDescription="Access Provider"] - Access provider / inspection contact

ValEx also needs to have as much contact information as possible in the access provider segment.

Sometimes your Valuation Firm is just too busy to accept a job. ValEx models this process via the Declined workflow.

We'd love to see more Valuation Firms implement this, as it can be a handy timesaver - no more logging into two systems.

We're mainly interested in receiving:

A reason for rejecting - which must be one of the following:

• DoNotConductValuationsForClient
• DoNotCoverPostcode
• InsufficientFeeForLocality
• InsufficientFeeForValuationWouldConductFor
• Capacity
• ConflictOfInterest

XPath:
/ValuationTransaction/vx:Job/vx:Status/vx:Declined/@ReasonCode

A supporting comment for the rejection:

XPath:
//ValuationType/WorkFlow/Comment
For instance, "Valuation Firm is currently too busy"

Status:
//Message/MessageBody/Status[@Name="Declined"]

Take a look at the sample xml.

Rejecting a Valuation Request based on Fee for Localtity

If "InsufficientFeeForLocalityWouldConductFor” is selected as the rejection reason a second field can be passed in for the dollar amount of what the valuation would be done for:

    <vx:Job>
         <vx:Status>
             <vx:Declined ReasonCode="InsufficientFeeForLocalityWouldConductFor" Amount="250" />
         </vx:Status>
     </vx:Job>

XPath of the amount:
/ValuationTransaction/vx:Job/vx:Status/vx:Declined/@Amount

We've added the ability to understand In Progress workflow from Valuation Firms.

You can now add Appointments via this packet, and also remove all Delays from a Job - this is more in line with LIXI's specified behaviour.

There is no requirement for Valuation Firms to implement this new workflow at this time.