developers.valex.com.au - Valex Developer Documentation

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.

If a property matches against one on our property watchlist we will put a comment in the LIXI like: "This property may be on the ValEx Property Watch List....." followed by more detail.

This is rendered at /ValuationTransaction/Comment.

Valuation Risk Alerts are required by certain clients.

Each risk item on a report can either be checked or unchecked, and if checked a comment can be entered.

All risks must be answered either yes or no before the report will be delivered.

If unchecked we require a Rating of "1-Low", if flagged as a risk send "5-High".

Flagged as a risk:

<RiskRating Rating="5-High" RatingType="Other">
        <Identifier Type="VPMAssigned" UniqueID=”HighRiskOrNonResiPropType” Description="High Risk Security">
	        <Comment>The valuer notes that subject property is outside of CBA Guidelines </Comment>
        </Identifer>
</RiskRating>

Not flagged as a risk:

<RiskRating Rating="1-Low" RatingType="Other">
        <Identifier Type="VPMAssigned" UniqueID=”HighRiskOrNonResiPropType” Description="High Risk Security">
	        <Comment />
        </Identifer>
</RiskRating>

As of Novmeber 25th 2012, ValEx has utilised the following list of industry-wide Valuation Risk Alerts as per the implementation of the new Standing Instructions (please note that the first 3 of these, are existing CBA VRA’s):

Report Integrity Questions

Also displayed within ValEx are 'report integrity' questions. These are designed as prompts to the valuer to ensure they have covered off areas of concern.

Most report integrity questions have an additional option of "0-NotKnown":

<RiskRating Rating="0-NotKnown" RatingType="Other">
        <Identifier Type="VPMAssigned" UniqueID=”AgentIntervention” Description="Is the sale without intervention of a real estate agent">
	        <Comment />
        </Identifer>

</RiskRating> 

First sale in a recent construction?

Under contract

Where a property is under contract (valuer confirms contract price and date), and the valuer has sighted the contract. XPath: //RecentSale[@IsContract='Yes'] and //ResponseSupportingDoc[@DocType="Contract" and @DocAttached="No"] 

No Contract, Construction Loan

Where a property is not under contract, but for a transaction of Construction Loan. XPath: //RecentSale[@IsContract='No'] and //RealEstate[@Construction="Yes"]

Comments

Manual - encourage the valuer to make comment in their additional comments. Automatic - ValEx inserts a pre-defined clause. Yes/No; 5+ words - When answered, a comment by the valuer of 5 or more words is required. Valuation Exchange will render these comments in the additional comments section of a PDF. 

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

ValEx forked the 1.3 LIXI standard to allow more flexibility when specifying zoning information.

The standard allows several enumerations and an @OtherDescription attribute - something we overlooked initially.

         <xs:attribute name='ZoningType'>
            <xs:simpleType>
               <xs:restriction base='xs:NMTOKEN'>
                        <xs:enumeration value='Residential' />
                        <xs:enumeration value='Commercial' />
                        <xs:enumeration value='CommercialResidential' />
                        <xs:enumeration value='Rural' />
                        <xs:enumeration value='RuralResidential' />
                        <xs:enumeration value='ShortStayAccommodation' />
                        <xs:enumeration value='Urban' />
                        <xs:enumeration value='Other' />
                    </xs:restriction>
            </xs:simpleType>
         </xs:attribute>

      <xs:attribute name='OtherDescription' type='xs:string' />

We currently parse @ZoningType for the correct text to render. As of 4th July 2010, we'll be looking at @ZoningType first, then overwriting that information if @OtherDescription is populated.

At a later point (Our 1.4 XSD), we will enforce the original zoning restrictions.

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.

We have a new feature to allow a LIXI message to be uploaded via the Job Report interface within ValEx. This may be especially useful to Valuation Firms that do not want a full SOAP connection; or just want to quickly test if their LIXI packets are generating correctly.

You may access this feature by opening the Online Report and clicking on Copy Data under the File tab.

We've implemented support for parsing authorising signatures from the LIXI response as of March 15th, 2010.

An authorising valuer (also known as a co-signatory) is a qualified valuer who can authorise a report.

There are many different scenarios in which a signature is required; which aren't covered here.

ValEx has some authorising signatures configured on a valuation firm level, with a number of defaults set up.

To override these, in your LIXI response; submit a new related party as below.

<RelatedParty RelPartyType="AuthorisingValuer">
  <Identifier UniqueId="VXA-12345" type="VPMAssigned"> 
 <PersonName>
  <FirstName>Joe</firstname> 
  <Surname>Smith</surname> 
  </PersonName>
  </Identifier>
</RelatedParty>

Very importantly, the @RelPartyType must be AuthorisingValuer, and you must provide a correct Identifier.

To obtain the list of identifiers for your valuation firm....

1. Login to valfirm realm
2. Management
3. Company details
4. Report tab
5. Overview
6. Export CSV

At this time, you can only choose from configured valuers within the ValEx system. If you need to add additional authorising valuers, please contact ValEx's Valfirm Relationship Manager.

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.