developers.valex.com.au - Valex Developer Documentation

Current Use is parsed from the vx namespace. This appears on the Summary tab.

Valid values are for //vx:Job/vx:Property/vx:Detail/vx:CurrentUse are:

Residential
MultiResidential
CommercialResidential
NonResidential
Commercial
ServicedApartment
ResidentialVacantLand
StudentAccommodation
SeniorsLiving
Rural
RuralResidential
None - to clear this field.

We have recently extended the LIXI standard by creating a new vx namespace.

To use this namespace, simply declare the namespace as below:

<ValuationTransaction
    xmlns:vx="https://vx.valex.com.au/lixi/schema/vx/0.1/#"
    ...>

You may then include nodes belonging to the vx namespace under the <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="skip"/> node as documented.

Schema Validation

• Main ValEx Schema Production
• VX Node Production
• Main ValEx Schema UAT
• VX Node UAT

Features supported:

• vx:Job/vx:Status/vx:Delay
• vx:Job/vx:Property/@Type
• vx:Job/vx:Property/vx:Detail/vx:CurrentUse
• vx:Job/vx:Property/vx:Detail/vx:BuildingType

We have created a ValEx namespace to escape LIXI limitations.

The first feature of this namespace enables valuation firms to specify a delay reason ID that relates directly to how delay reasons are modeled within ValEx.

If the vx:Delay node is supplied, then it will be used in favour of standard LIXI Workflow/@DelayReason.

An example follows:

<?xml version="1.0" encoding="utf-8"?>
<ValuationTransaction
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="https://vx.valex.com.au/lixi/schema/1.4.1/ValuationTransaction.xsd"
    xmlns:vx="https://vx.valex.com.au/lixi/schema/vx/0.1/#"
    ProductionData="No">
    
    <-- LIXI Standard Content here -->
        
        
        <vx:Job>
            <vx:Status>
                <vx:Delay ReasonID="4">
                    <vx:Comment>Unit test delay comment</vx:Comment>
                </vx:Delay>
            </vx:Status>
        </vx:Job>
        
        
</ValuationTransaction>

Delay reasons are:

ID	Reason
4	Next visit to Location
9	Request is Outside of Lender policy
13	Inspection Contacting Issues
14	Access Issues
15	Property Identification
16	Insufficient Documentation (Client/Lender/Broker to Provide)
17	Other
18	Cancellation Request
19	Request to Change Service Type
20	Fee Approval
22	Request to Change Service Type and Higher Fee Approval

Order test jobs using our testing tool.

Within ValEx, we have a LIXI Queue Log. This can be useful for debugging LIXI issues.

To access the Queue Log, simply log into ValEx, open a job record, and click on the Queue Log icon in the upper right-hand corner.

This is an explanation of some of the less obvious information:

You can download the following files:

• Raw: The raw SOAP Request
• Payload: The LIXI Message sent in the SOAP Request
• Response: The raw SOAP Response

Note: This is not for Clients! This is for Valuation Firms!

We support sending a copy of the final valuation response that is sent to the client to the valuation firm.

The implementation is a simple as adding a response(xs:string lixi_valuation_xml) to your SOAP server. We then need to implement this in your SOAP Client in ValEx (ValEx has a separate SOAP client per each Valuation Firm Integration Partner) and schedule time for testing.

The LIXI message will be similar (but not the same) as you send back to us. Basically, the response will be an interpretation of your response, which is a standard LIXI message (not a workflow). All ValEx identifiers will be in their usual locations.

If you want an example of the LIXI message that is sent, log into ValEx and check the Queue Log for any completed LIXI job. You should look for a response sent to the valfirm (we queue the LIXI message even if we do not support actually sending it).

Due to the queue system, the response may be delayed by up to 10 minutes on average.

One problem we have encountered a number of times is the requirement to go beyond the LIXI valuation standards.

This is because the LIXI standards really do represent the most common uses; but the ValEx platform and its partners are seeking to innovate - the two goals of innovation and standards often conflict.

Consequently for the 1.4.1 version of the ValEx XSD, we are introducing a minimal change to allow much greater extensibility.

We are introducing an <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="skip"/> node.

What this allows is for lixi partners to define information in a non-lixi namespace; without breaking schema validation.

For instance:

<ValuationTransaction xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:foo="http://foo.com"
ProductionData="No">
            
            <-- Appearing after the RelatedPartySegment or AttachmentSegment -->
            <foo:Foo>Hello! I'm a custom string, but could be any valid custom XML structure</foo:Foo>
</ValuationTransaction>

We are strongly advocating this amongst the LIXI valuation and CAL standards group as a way to move forward with custom or proprietry requirements; whilst still remaining LIXI standard compatible.

You can preview and update to the 1.4.1 schema; which is not yet in use by the ValEx application.

Between a job order being place and the valuation being completed, a job can be escalated. Two main circumstances trigger a Service Type Escalation:

• An EVR Desktop requires a Drive-by or esclation to Residential Short Form, or
• Similarly, upon the job being completed, reassessment of business rules may require the job to be reordered as a different service type. For example, now that the job has been completed, the LVR may be different due to a more accurate figure provided by the valuer.

Service type escalation implies that a service type is changed incrementally from a minor service (such as a Kerbside Inspection) to a major service (such as a Residential Short Form requiring full inspection).

escalate() Web Service

When a job is escalated, we send through a SOAP request to the escalate() operation (if implemented) on a Valuation Firm Web Service to notify the valuer. We expect to the Web Service to have the following semblance:

<message name="escalate">
    <part name="valuationMessage" type="xsd:string"/>
    <part name="reason" type="xsd:string"/>
    <part name="from_service_id" type="xsd:int"/>
    <part name="to_service_id" type="xsd:int"/>
    <part name="comments" type="xsd:string"/>
</message>

valuationMessage is a LIXI message, containing an updated valuation order (similar to what was sent in the initial request). The LIXI message will contain the new Service Type.

from_service_id and to_service_id are the Service Type Identifier. This is provided an alternative to parsing the LIXI message to determine the Service Type.

reason is string containing a humanised reason for escalation with a comment.

Escalation Reasons

A list of Reason IDs and their humanised strings is available.

We now parse PropertyCharacteristics/@YearModifed to populate Built Additions. The format is: [Year] [Description]. For example:

<PropertyCharacteristics YearModified="2005 Added a second storey." ...

This will populate the below two fields in ValEx:

ValueComponent/@LikelyWeeklyUnfRental supports a range value. For example:

<ValueComponent LikelyWeeklyUnfRental="200-250" ...>

This is available as of 1st December 2010.