developers.valex.com.au - Valex Developer Documentation

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.

In the Value section of a report, we capture recommended documents to sight.

We look at:
\\ResponseSupportingDoc[@RequestorToSight="Yes"]\Description

Which will populate:

We iterate over all available \\ResponseSupportingDoc[@RequestorToSight="Yes"] and concatinate the descriptions

For example:

<ResponseSupportingDoc DocType="TitleSearch" DocAttached="No" RequestorToSight="Yes">
	<Identifier UniqueID="VXDR-0000030267" Type="VPMAssigned" /> 
	<Description>Certificate of title and survey plan</Description>
</ResponseSupportingDoc>
<ResponseSupportingDoc DocType="Other" DocAttached="No" RequestorToSight="Yes">
	<Identifier UniqueID="VXDR-0000030268" Type="VPMAssigned" /> 
	<Description>Pictures of cats</Description>
</ResponseSupportingDoc>

Should produce "Recommended Docs to Sight: Certificate of title and survey plan, Pictures of Cats".

We're seeing an increasing use of the comments field for information like:

• contact details such as 'best time to call'
• generic information such as title details

The comments field is located at: /ValuationTransaction/Comment

Example:

<Comment>
    As is (Completed Dwelling or Vacant Land); AgentVendor; 
    General Comments: BROKER CONTACT:JOHN SMITH - PHONE - 0211111111 
    Call during business hours.  
    Title Details: Tenure type: Freehold Is primary title: Yes Other title description: LOT X DP XYZ123   
</Comment>

Please ensure that you are correctly parsing this information as we anticipate that the value of the detail in this field may increase in the future.

We can now capture the BuildingModification fields from the packet if the report type is TBE-Dwelling or TBE-Unit.

LIXI Mappings

* We do not parse Check Cost from BuildingModification/@CheckCost, because it is an enumerated Yes|No type. As a workaround, we parse from BuildingModification/Description.

** BuildingModification/@Type should be set to ToBeErected.

Example

/ValuationTransaction/Message/ValuationType/FullRegistered/BuildingModification[@Type="ToBeErected"]

<BuildingModification Type="ToBeErected" TenderPrice="500000">         <Identifier UniqueID="Dummy_Value"/>         <Description>750/sqm</Description> 	<RelatedEntityRef RelatedID="TestBuilderId-12345"/> 	<ContractDate><Date>2007-12-05</Date></ContractDate> </BuildingModification>

Here's a quick summary of how our system maps LIXI //RealEstate/Residential/@Type Types to ValEx residential property types.

Note: Property types should not be confused with Report Type (or even Service Type).

We don't map and would fail on the following types:

• ConvertedCommercialProperty
• ConvertedMotelUnits
• ConvertedIndustrialProperty
• Timeshare
• RentalGuarentte
• GovtRentalGuarentee
• ResortUnit
• PropertyDevelopment
• LuxuryOther
• UnitSudentAccom
• MotalHotelUnit
• AgedCareUnit

Property Types for for NAB, Commercial, and Rural Security Categories

We also support Commercial and Rural property types under //vx:Job/vx:Property/@Type.

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.