developers.valex.com.au - Valex Developer Documentation

A lot of our lixi valuation firm partners in regional areas often come across the situation where they have to use out of date sales evidence to support their report.

This means the report is likely to need review by out compliance department. Previously, we've automatically generated the compliance note from the valuer in these cases.

Going forward, we'll be looking at //CompletionDetails/LendersCaution and //CompletionDetails/LendersCautionComment to populate this information.

At this time, we will not be rendering this to our LIXI clients and lenders.

ValEx will support this some time around January 2010 15th February 2010.

From December 14 2009, Valuation Exchange will commence Desktop Valuations.

Full LIXI Integration Not Supported

Although we will send a Valuation Request via LIXI and we will accept Assigned workflow, we do not accept a Final Valuation Response nor an Inspected Workflow. Valuers will be required to log into ValEx directly to complete the report.

If a final valuation response or Inspected workflow is sent to ValEx via LIXI, the following error message will be given: "An error was detected: Sorry your system does not currently have permission to update this job".

How to Recognise a Desktop Valuation

See SubTypeNote for how to discern a Desktop Valuation.

Escalations from a Desktop

In the case that a Desktop Valuation request is escalated to a Residential Short Form or a Construction Report, we will send another Valuation Request (with the same Job ID).

We've deployed the Large File Attachment implementation to our test and production servers.

Discussions on the lixi mailing lists about this has brought us:

The full URI for the attachment should be placed into the SourceDomain
attribute of the Attachment element. The user guide comment for Source
Domain in the current schema is as follows "The SourceDomain is intended to
be a URI that identifies where the attached file might be accessed from, or
just an identifier of the owner of the document. While it is anticipated
that it will generally be a URI scheme starting with "http://" or "ftp://",
there is no requirement for this to be the case."

If there is a separate filename then that would be placed into the Filename
attribute, and this would obviate the need for a "Type" attribute. In the
example that Daniel has provided below, the URI does not list the name of
the file, rather how one retrieves it. So the XML would look like:

<Attachment SourceDomain="http://vx.valex.com.au/documents/view.php?id=1"
FileName="1234.jpg" />

We'll be both parsing and rendering attachments in this way, on an opt-in basis.

If you would be interesting in trialling this, please contact us.

This article has been superseded by a new version.

Click here to see the old article.

                <-- Select funder -->
		<RelatedParty RelPartyType="ValuationFirm">
			<Identifier Type="VPMAssigned" UniqueID="VXV-2"/>
			<CompanyName BusinessName="Example Valuations"/>
                        <!-- It is safe to leave this optional fields blank -->
			<PersonName>
				<FirstName>Mr</FirstName>
				<Surname>Example</Surname>
			</PersonName>
			<WorkPhone PreferredContactMethod="Yes">
				<Phone>
					<FixedPhone AreaCode="08">81111111</FixedPhone>
				</Phone>
				<Phone>
					<Fax AreaCode="13">12345678</Fax>
				</Phone>
			</WorkPhone>
		</RelatedParty>

Some things just don't fit into LIXI. ValEx also produces a multitude more emails and other notifications that it does via webservices.

A quick and easy way to route / attach communications from ValEx to your system may be to look at our mail headings.

Typical emails produced by ValEx render information like:

X-ValEx-JobID: 1244566
X-ValEx-ValfirmID: 119
X-ValEx-ValuerID: 1009
X-ValEx-Valuer: Office Valuer
X-ValEx-Valfirm: Example Valfirm
X-ValEx-UserID: 50348
X-ValEx-ClientID: 1234
X-ValEx-ServiceID: 23
X-ValEx-Service: Const. Short Form
X-ValEx-FunderID: 0
X-ValEx-Funder: 
X-ValEx-Realm: valfirm

We've found this helpful for routing the massive amounts of email from inbox to inbox, as well as embedding relevant metadata.

If you are interested in this kind of thing, let us know.

Clients can indicate to us that a loan may incur mortgage insurance with the below xpath:

//RealEstate[@MortgageInsurance="Yes"]

This can also be set by the valuation firm.

We'll be introducing a new variant of a ShortForm report, a Retrospective valuation.

These valuations are done as a comparison to an original report, and use sales evidence from the period of original valuation.

For MIP (Mortgagee In Possession reports), we'll sometimes require a Forced Sale Value - what the subject property would fetch.

Of course, then there's the combination of a MIP Retrospective valuation - we aren't currently explictly modelling this, however may do so in the future.

Retrospective valuation requires a valuation date which is the date of original inspection and will be the 'valuation assessment' basis.

Check out the service type mappings.

Service type: XPaths

We'll parse and render a both of:

//FullRegistered[@ValSubType=ShortForm]
//FullRegistered/SubTypeNote/text() == "Retrospective Short Form"

To indicate we are ordering a Retrospective Short Form.

We'll parse and render both of:

//FullRegistered[@ValSubType=Standard]
//FullRegistered/SubTypeNote/text() == "Retrospective Long Form"

To indicate we are ordering a Retrospective Long Form.

Forced Sale Value: XPaths

ValEx will look for a Forced Sale Value in both of:

//ValueComponent[@OtherValue]
//ValueComponent[@OtherValueDescription="Forced Sale Value Range"]

Formatted as a xsd:decimal.

Valuation Date: XPaths

ValEx will model valuation date as an inspection appointment.

//FullRegistered/InspectionAppointment[0] # Normal inspection information
//FullRegistered/InspectionAppointment[1] # Retrospective valuation date

One common implementation problem we're running into is inline attachments for lixi packets.

The schema defines an element to base64 encode binary files. Typically, this runs from 1-6mb in packet size for a completed valuation report (PDFs, titles, invoices, etc).

<xs:element name="InlineAttachment" type="xs:base64Binary">

What tends to happen is someone deploys a system, and a few days later, packets are being rejected as they are beyond the capabilities of the server's default configuration.

We'd like to get opinions on how others have solved this, and also propose an idea or two.

The suggestion:
So, a lot of valuation systems are using SOAP and are doing so from web based systems.

Common tools for linux environments include things like 'wget' and there are an abundance of simple HTTP client libraries in a variety of languages.

HTTP also provides a mechanism to do authentication (HTTP Basic Authentication), as well as compression ("Accept-Encoding").

I'd like to suggest:

  <xs:element name="Attachment">
    <xs:complextype>
      <xs:sequence>
        <xs:element minoccurs="1" ref="Identifier">
        <xs:element minoccurs="1" ref="RelatedEntityRef">
        <xs:element minoccurs="1" ref="InlineAttachment">
      </xs:element>
      <xs:attribute name="SourceDomain" type="xs:string">
      <xs:attribute name="Filename" type="xs:string">
    </xs:attribute>
  </xs:attribute>

1. Loses the minOccurs=1 restriction on InlineAttachment
2. Either the Identifier element or a specific new element is used to capture a URL
   

   <Identifier uniqueid="http://vx.valex.com.au/documents/view.php?id=1">

   or

   <File href="https://vx.valex.com.au/documents/view.php?id=1" type="image/jpeg">

3. Implementors determine an authentication mechanism between the systems, based on HTTPS and HTTP Basic Authentication

   A simple client would:

   1. Match the domain against an internal list of usernames/passwords to use
   2. Send a HTTP GET, and provide the username/password
   3. If needed, the simple client specify it can accept gzip/other compression encoding to the server (just like your browser does)
   4. If needed, the simple client respect last-modified-times / e-tags (also like your browser)

So:
What do people think of such a thing?
How have others been dealing with this situation?

Opening a Query

We provide a requestValuationQuery() method for clients.

Within ValEx only allow one open query at a time - subsequent queries are appended as notes.

We would like to encourage our valuation firm users to implement a similar method in their soap services.

This will allow valuation firms to accept valuation queries in a meaningful way.

Resolving a Query

We provide a submitValuationQueryResponse(string xml, string resolution, string comment) method for indicating a resolution to a query.

We'd like all of our clients (to provide such a method in their soap service) and valuation firms (to send us responses) to consider implementing this.

The current resolutions within ValEx are:

• agree

  Will amend report

• disagree

  Query closed

Amending a report with no Open Query

We also allow valuation firms to send an amended report in some circumstances. This is documented here.

Rasika asks:
What's the XPath for 'Title Details > Further Details' is please?

We parse Torrens Title information from the //Title element.

We don't currently map all elements and attributes here, only @TorrensVolume, @TorrensLot, @TorrensFolio, @TorrensPlan, and @OtherTitleDescription.