First Mortgage Attribute

The First Mortgage attributes flags that the report is going to be used for first mortgage purposes only. If this field is not supplied, ValEx will default to “Yes” (First Mortgage Purpose only).

/Title/Encumbrance/@FirstMortgage

Insert Title Here

An Action Update will act like a Delay, in the sense that it will not remove other status, like, appointment & inspected, however, when applied it will be the primary status of the job.

Marking the Job as Inspected will remove any previous Action Update (like a delay). However, an Action Update can be applied after an Inspection has been confirmed (like a delay).

When a Delay is applied to a Job already, the Action Update will not override the Delay. The Action Update will be applied as a sub status to the Delay on the Job, the Delay will remain the Primary Status. If an Action Update is on a Job and then a Delay is applied, the Delay will become the primary status of a Job, and the Action Update will not be removed, but will become a secondary status on the job.

New LIXI SOAP Operations

addActionUpdate(valexId, update_code, comment)

This is the standard operation that should be called for adding an Action Update to a job.
The update_code should correspond to one of the following action update categories in the mappings below:

actionUpdateFeeApproval(valexId, reason_code, fee_amount, comment)

This is the operation to call for adding an action update where the reason is to seek approval for a higher fee on a valuation request.
The reason_code should correspond to one of the following action update categories in the mappings below:

actionUpdateReassignment(valexId, comment, fee_amount)

This is the operation to call for adding an action update where the reason is to seek approval for a re-assignment of a previously completed valuation.

actionUpdateServiceTypeWithFeeApproval(valexId, comment, fee_amount)

This is the operation to call for adding an action update where the reason is to seek a service type change with a higher fee approval on a job.

Recommendation is a field within ValEx which will allow the valuer to indicate whether the property is appropriate to be considered as security for lending purposes.

Recommendation is generally an optional field for Valuers. Some clients may select (due to their Mortgage Insurer’s requirements) that this is a mandatory question to answer (please refer to the 'RequiresRecommendation' section below for more detail on this).

XPaths

Recommendation actually encompasses the following three fields in Lixi (these will be described in the following sections):

• //ValueComponent/@RequiresRecommendation
• //ValueComponent/@RecommendedSecurity
• //ValueComponent/@RecommendationReason

RequiresRecommendation

From a ValEx perspective there are settings which stipulates whether Recommendation is a mandatory field for valuers to answer for each Client or Funder. This will be sent from ValEx to the LIXI Firms via setting the RequiresRecommendation as “Yes” in the request when required:

<ValueComponent ... RequiresRecommendation=”Yes”> 

In turn, it will then be up to the valfirms to implement on their system to determine whether the Recommendation is required to be provided, based on what they receive from RequiresRecommendation.

RecommendedSecurity

This is the actual field for indicating whether the Security is an acceptable security to be considered for Lending Purposes.

There are currently 3 outputs for this field in Lixi:

When the Valuer is indicating that the Security is an acceptable security to be considered for Lending Purposes:

<ValueComponent ... RecommendedSecurity=”Yes”> 

When the Valuer is indicating that the Security is not an acceptable security to be considered for Lending Purposes:

<ValueComponent ... RecommendedSecurity=”No”> 

When the Valuer is not indicating either way (due to the setting being optional in ValEx per client/funder):

<ValueComponent ... >

RecommendedReason

When the Valuer indicates that the Security is not an acceptable security to be considered for Lending Purposes (i.e. RecommendedSecurity="No"), we will require comments to support this, at least 5 words will be required:

<ValueComponent ... RecommendedSecurity="No" RecommendationReason="This is not an acceptable security to be considered">

As per the new API Rewrite implementation post July 1st 2012, there have been changes in relation to the parsing of the values in Lixi for the Environmental and Heritage Issues under the RiskAnalysis node:

• //RiskAnalysis[@EnvironmentIssues]
• //RiskAnalysis[@HeritageIssues]

The following is how the fields are parsed by ValEx from Lixi into the report:

//RiskAnalysis[@EnvironmentIssues=""]
//RiskAnalysis[@HeritageIssues=""]

will simply populate as a blank option in the report.

//RiskAnalysis[@EnvironmentIssues="None"]
//RiskAnalysis[@HeritageIssues="None"]

will indicate as the 'None' option in the report.

On the other hand, if these fields are neither set to blank or None:

//RiskAnalysis[@EnvironmentIssues="There are Environmental Issues"]
//RiskAnalysis[@HeritageIssues="There are Heritage Issues"]

these will basically populates as actual comments in those fields.

rejectQuote() is a SOAP operation that may be optionally implemented as part of our LIXI Quote Process.

If the valuation firm decides to reject the quote request, the following SOAP operation should be called:

int rejectQuote(string valuationMessage)

We expect a standard LIXI message containing the following:

• ValEx VXJ Identifier (VPMAssigned)
• ValuationTransaction/Message/MessageBody/Status/@Name = Inquiring
• //Workflow[@Type="FeeNegotiation"]/@FeeNegotiationStatus = Rejected