developers.valex.com.au - Valex Developer Documentation

We've put in place a small change to add in the Funder for certain jobs.

You can tell the two related parties apart with the identifier prefix.

Client:

//RelatedParty[@RelPartyType='Lender' and starts-with(Identifier/@UniqueID,'VXCL-')]/CompanyName/@BusinessName

The Client is the Bank. There is always only one Client per job.

Funder:

//RelatedParty[@RelPartyType='Lender' and starts-with(Identifier/@UniqueID,'VXF-')]/CompanyName/@BusinessName

In most cases there will be one funder per job. There will not be more than 1.

This change will be available as of Monday May 11th, 2009.

Some time ago we designed it so valuers were assigned before appointments in ValEx.

This has led to the often confusing error message of No office valuer exists, and is generally a pain for all parties.

To fix this, we'll be adding a 'default valuer' setting in our valuation firm setup areas.

Our valuation firm users won't have to change anything, however when we deploy there may be some setup and configuration changes we'll need to make.

We are currently looking at implementing this approximately Mon June 15th 2009.

We now support RequestSupportingDoc from clients. Example below:

<RequestSupportingDoc DocType="Image"
                      RequestorIncludedDoc="Yes"
                      ResponderToReturnDoc="No">
    <Identifier UniqueID="DOC0000001" Type="LenderAssigned"/>
</RequestSupportingDoc>

We require the document in the AttachmentSegment as per the article on Attachments (Reports, Images, Title Details etc).

Please be advised that as of 23 February 2009 we will require a Delay Reason to be sent with any Delay workflow.

Please also note that our Delay Reasons will also be modified slightly.

NOTE: The following article has now been DEPRECATED - please refer to the article on Expected Selling Period

LIXI 1.4.3

The new version of the LIXI standard defines an EstimatedSettlement element.

For a while now, we have have been capturing Expected Selling Period under the Value tab of reports. This is also rendered in our reports under the Additional Comments.

We accept:

• //FullRegistered/ValueComponent/EstimatedSettlement
• //FullRegistered/ValueComponent/EstimatedSettlement/Duration[@Length] as an int.
• //FullRegistered/ValueComponent/EstimatedSettlement/Duration[@Unit="Months"]

When we translate your integer to our enumeration; we use the following translation: for months <= 3, we assume a selling period of 3 months. Months 4-6, we assume a selling period of 6 months. Otherwise, we assume greater than 6 months.

To enter a comment, we will continue to read //ExpectedSellingPeriodComment as below.

This method was for LIXI 1.3, and an alternative is now present in LIXI 1.5

In our 1.3 series schema, we looked for:

• //FullRegistered/ValueComponent/ExpectedSellingPeriodComment
• //FullRegistered/ValueComponent/@ExpectedSellingPeriodInMonths as an enumeration of:
  • 0-2
  • 3-6
  • Over6

If the estimated selling period is greater than 3 months, an ExpectedSellingPeriodComment should be provided.

LIXI defines EstimatedValue as a mixed type.

LIXI defines EstimatedValue/@EstimateBasis as an enumeration of:

• ApplicantEstimate
• CertifiedValuation
• CustomerEstimate
• ContractPrice
• Database
• Other

Examples

Assessed Market Value

If the @EstimatedBasis is CertifiedValuation, we assume that the value is the Assessed Market Value.

<EstimatedValue EstimateBasis="CertifiedValuation">
    250,000.00
</EstimatedValue>

or

//ValueComponent/MarketValueAsIfComplete[@Type="SinglePoint"]/@ValueCeiling

See also: Assessed Market Value - best location

Contract Price

If the @EstimatedBasis is ContractPrice, we assume that the value is the Contract Price and we also require EstimatedValue/Date to determine the Contract Date.

<EstimatedValue EstimateBasis="ContractPrice">
    <Date>2004-01-01</Date>
    250,000.00
</EstimatedValue>

Estimated Market Value

If the @EstimatedBasis is omitted or otherwise set to CustomerEstimate or ApplicantEstimate, then we assume that it is the Estimated Market Value.

<EstimatedValue>315,000.00</EstimatedValue>

Or:

<EstimatedValue EstimateBasis="CustomerEstimate">
    250,000.00
</EstimatedValue>

We've implemented in ValEx the ability for client to lodge post valuation queries.

Webservice changes

We have be published a new soap action in our production environment.

You can view the WSDL documentation:

requestValuationQuery(LIXIValuationResponse xml, int reason_id, string comment)

The first argument, xml is simply your updated valuation response packet.

The second is the reason for amending.

It is an int from 1-4; meaning:

1. Non value query - Typing error
2. Non value query - Insufficient documents (valfirm)
3. Non value query - Other
4. Value Query
5. ValEx Dispute Review
6. Non value query - Address/Title
7. Non value query - Comments
8. Non value query - Comparable sales
9. Non value query - Counter signatory
10. Non value query - Photos
11. Non value query - Insufficient documents (client)

Next is a comment of 5 words or more explaining why the report needs amending.

ValEx user interface

See also

Queries and Amendments

Suggestions welcome!

Finding LIXI Documentation / Getting Help

1. Look in the LIXI schema.
2. Search the LIXI specifications and documentation available at www.lixi.org.au (requires membership).
3. Search developers.valex.com.au for ValEx-specific quirks.
4. Use the LIXI Packet Tester, which documents required nodes for packet types (although business logic is not included).
5. Ask a ValEx developer.
6. Ask on LIXI forums.

A Suggested Testing Approach

Integration development process:

1. Get acquainted with the LIXI documentation.
2. Pass schema validation
3. Pass LIXI packet tester (optional)
4. Submit LIXI packet to ValEx Web Service
5. Packet processed successfully by ValEx
6. Pass Critical Validation Checks
7. Pass Validation Checks
8. Pass Compliance Checks (these are very high-level business logic, and is not a requirement for technical integration)
9. Check that all fields in the ValEx report can be populated (by previewing the PDF report in ValEx).

Development tips:

• Write unit tests first (and testable code).
  • Cover your SOAP endpoint to controller mapping/integration
  • Cover your LIXI rendering
  • Cover your LIXI parsing
  • Cover your action-in-system-generates-outgoing actions
• Decouple LIXI from SOAP

Wondering about the different levels of validation within ValEx, and when you get certain errors?

The different levels are:

1. SOAP - we ensure you are making well formed requests to our SOAP service
2. Authentication - we ensure you have valid login creditials
3. XML validation - we ensure that the xml data is well formed
4. XSD validation - we ensure that the LIXI data is conforms to the schema
5. Required data validation - we ensure that for a given report, you
   have provided the correct fields. Since certain things may affect different required fields in the job, this cannot be modeled in an XSD. For instance: you have indicated a risk rating of 5, please provide a comment
6. Data format validation - we ensure that for a given report, you have provided data in the correct format - number of words, comments.
7. Compliance and Risk checks - is the data you have provided within the client requirements or expectations? If not, have issues of risk been commented on correctly?

We'll be implementing some changes in ValEx to help make the Mortgage Manager Query/Valuer Report Amendment Process more efficient on Monday, December 15th 2008.

We will be allowing Valuers to amend reports without having to use the ValEx Team as an intermediary. Valuers' ability to open a report for amendment is based on Client preferences.

UI Changes

Within the user interface, we'll be allowing valuers to trigger an amendment, add a quick note as to why, and basically just get out of the way for trivial things - ie, typos or missing photos.

In the short term, we'll be improving the error emails we currently generate when a LIXI valuation response reaches us; to be more informative for users - in effect, please login to the site to open your report for amendment.

As a longer term goal, we'll be allowing valuation firms to submit an amended report with an amendment reason and comment.

Web Service Changes

We will be publishing a new soap action in our test environment by December 15th.

We will update our WSDL and this article when we have published it.

It will be along the lines of:

submitAmendedValuationResponse(LIXIValuationResponse xml, int reason_id, string comment)

The first argument, xml is simply your updated valuation response packet.

The second is the reason for amending.

It is an int from 1-4; meaning:

1. Typing Error - Spelling, unwanted formatting
2. Supporting documentation missing - Photos not in report, Title searches missing.
3. Report query - Non value - General amendment, more information needed
4. Report query - Value - Provide additional comparable sales to support a higher value.

Last is a comment of 5 words or more explaining why the report needs amending.