developers.valex.com.au - Valex Developer Documentation

By the end of April 2011, ValEx will change its SalesEvidence comparison comment mapping behaviour.

Currently, we examine both @OverallComparability and a //Description, joining the two together in a single textual comment.

Moving forward, we'll be storing @OverallComparability seperately.

Please ensure your user interfaces prompt valuers to input both.

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.

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.