SearchUser loginPopular contentAll time:
Valuation Firm GuideClient Guide
|
APIValidationWondering about the different levels of validation within ValEx, and when you get certain errors? The different levels are:
Amending completed reportsWe'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 ChangesWithin 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 ChangesWe 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:
Last is a comment of 5 words or more explaining why the report needs amending. Pre-Valuation Status, Workflow and Construction workWe've just enabled a feature to improve our internal processes around sourcing documentation for construction jobs. Here's the detail, and how it affects LIXI, and how it improves what we record for a Valuation Firm SLA. Pre Valuation StatusThe concept of 'Pre Valuation', is that this new status is applied to Valuation Records, when Valuation Exchange needs to perform a function on the valuation record, prior to the Valuation Firm being able to set an appointment/complete a report. Valuations will now be directly allocated to you when the request is placed on ValEx (rather than ValEx holding the request internally until the documents are received). This will allow you to view the upcoming requests, soon to be available for you to action. Once the Valuation is assigned, it will be 'locked' in Pre Valuation Status, until Valuation Exchange uploads the building pack for you. Once Valuation Exchange sources and uploads the building pack, the Pre Valuation Status will be ‘completed’ and the Valuation will be ready to action and complete. Only Valuation Exchange can complete the Pre Valuation Status. NotificationsIf you are a Lixi Valuation Firm, you will be sent two notifications, a message when a Valuation Request is placed that is in the Pre Valuation Status – highlighting for you that you should not action the Valuation Request until the Documents have been sourced (as this is unable to be sent through with the packet request to your VMS at this stage. You will also receive the notification once the Valuation has completed the Pre Valuation Status – giving you to go ahead to now complete the request. SLA ReportingWhen a Valuation is in Pre Valuation Status the SLA clock has not commenced, as this time is allocated to Valuation Exchange sourcing the documents. Once the Valuation Request has completed the Pre Valuation Status then the clock will commence the 48/72 hour SLA – which is reported against the Valuation Firm/Valuer for performance. ImprovementAreasHow to set improvement areas:
Upcoming XSD changes - 1.3.7A heads up to our valuation firms, we'll be making minor changes to our XSD to be less restrictive. In particular,
We'll publish a few new sample packets to demonstrate the changes. The current schema is 1.3.6. The attached schema is a preview of 1.3.7 and may be subject to change. See also: Current LIXI Schema (XSD) Progress InspectionsWe will be supporting Note that any nodes such as those under ![]() LIXI Mappings for Progress Inspections
Builder's Invoice ProvidedWe look for Where the Valuer selected that the Builders Invoice has been provided, it will be mandatory for the Valuer to complete all of the Report Fields. Note that (even when a builders invoice has been selected as yes, and thus the fields are mandatory) the Cost to Complete is able to be left as $0 on a Final Inspection and a Previously Drawn is able to be left as $0 on a 1st Inspection or Final Inspection (in case that is the first time the valuer has reviewed it). Payment TypeThe payment type is determined by the service type. For progress payments, the service will be Progress Inspection. For final payments, the service will be Final Inspection. Inspection NumberAn enumeration 01..09. Inspection Number is not rendered in our reports and is purely for convenience. We render and parse from:
Stage CompletedThis is a percentage value that represents construction progress. We render and parse from:
We set Stage to 'Final' for Final Inspections otherwise we set it to 'Other'. We do not parse from it, we instead rely on
Contract PriceWe render to:
//ProgressInspection/ConstructionProgress/@ContractAmount
Previously DrawnFunds already advanced to the borrower. We render and parse from:
Payment Now DuePayment required this stage by the borrower. This will become the recommended progress payment unless overwritten by the valuer. We render to:
We parse from:
Cost to CompleteCost to Complete is Contract Price minus Value To Date. Value to Date is a sum of Previously Drawn and Payment Now Due. We parse from and render to:
Value to DateValue to Date is a sum of Previously Drawn and Payment Now Due. We parse from and render to:
CommentsComments describing progress completion details. E.g., "final payment recommended, construction completed to a satisfactory level." We parse from:
Unused LIXI fieldsWe do not use
These date fields are required by the LIXI schema. It is recommended to populate these fields as we may parse them in the future.
LIXI Sample<ProgressInspection InterestInProperty="Other" InspectionNumber="01" ValSubType="ShortForm" ReasonFor="Other"> <SubTypeNote>Final Inspection</SubTypeNote> <RealEstate Status="ToBeBuilt" Construction="Yes" MortgageInsurance="No" Occupancy="OwnerPrimary" LandAreaHectares="0" Transaction="Refinancing"> <Identifier UniqueID="Dummy_Value" Type="ValuerAssigned" /> <Residential Type="LicencedBuilderHouseConstruction" /> <EstimatedValue EstimateBasis="ContractPrice">250000.00</EstimatedValue> <Location> <Address> <StreetNo>100</StreetNo> <Street Type="Street">Waymouth</Street> <City>ADELAIDE</City> <State Name="SA" /> <Postcode>5000</Postcode> <Country>AU</Country> </Address> <Title TorrensLot="Lot" TorrensPlan="Plan" IsPrimaryTitle="Yes"> <Encumbrance Description="" EncumbranceAffectsValue="No"><Comment /></Encumbrance> </Title> </Location> </RealEstate> <ConstructionProgress Stage="Final" PerCentCompleted="100" FundsRqdThisStage="50000" FundsAlreadyAdvanced="200000" ContractAmount="250000" PostContractVarAmount="0" /> <!-- If the valuer has seen the builders invoice --> <ResponseSupportingDoc DocType="Other" DocAttached="No" RequestorToSight="No"> <Identifier UniqueID="VXD-0000000000" Type="VPMAssigned"></Identifier> <Description>BuilderInvoice</Description> </ResponseSupportingDoc> <ProgressCompletionDetails CostToDate="250000" CostToComplete="0" RecommendedProgressPayment="50000"> <ValuationValidFrom><Date>2008-10-10</Date></ValuationValidFrom> <DateOfInspection><Date>2008-10-10</Date></DateOfInspection> <Comment>We recommend final payment</Comment> </ProgressCompletionDetails> </ProgressInspection> TBE Builder Related PartyAfter some discussions with lixi and our users about Building Modification Details, we're implementing the TBE builder information in the following way. This functionality should be available as of October 31st and on our test site as of October 18th. Our first preference will be to look at: First; check if //FullRegistered/BuildingModification/@RelatedEntityRef exists; and read the relevant related party. Second; if it is unavailable, check for //Costing/Construction[@ConstructionBasis="RegisteredBuilder"] For maximum compatibility, we suggest valuation firms implement both scenarios. Example for TBE Dwelling / FullRegistered reportsFirst, our FullRegistered BuildingModification element <BuildingModification Type="ToBeErected" TenderPrice="500000" CheckCost="Yes"> <RelatedEntityRef RelatedID="TestBuilderId-12345"/> <ContractDate><Date>2007-12-05</Date></ContractDate> </BuildingModification> Then, in the RelatedPartySegment <RelatedParty RelPartyType="Builder"> <Identifier UniqueID="TestBuilderId-12345" Type="ValfirmAssigned"/> <CompanyName BusinessName="Most Excellent Building Company"/> <PersonName> <FirstName>Steve</FirstName> <Surname>Exampleton</Surname> </PersonName> </RelatedParty> Additional fields for use in Costing reportsA Costing report lets you map this even better. <Construction ConstructionBasis="RegisteredBuilder"> Steve Exampleton </Construction> MarketValueAsIfComplete, As If/Is Complete and TBE reportsIf you need to tell ValEx if your valuation is done on an existing property, or one being built, you want to use the //ValueComponent/MarketValueAsIfComplete/Description element. ValEx will look for the wording "As If Complete" in the Description node, otherwise assume the valuation is done on an As Is Complete basis. Example: a TBE Dwelling Example: an already established Dwelling ValSubType and SubTypeNote Service MappingsValuation Exchange facilitates a number of services on behalf of a lender or mortgage manager. Broadly speaking, they are all requests for a valuation firm to conduct a valuation and return a report. However, some specific products have specific processes which are associated with them. For instance, an Elite valuation or a Top Up valuation require slightly different steps to complete appropriately. TermsWithin the ValEx user interface; there are:
Product TypesTypically flagged with a job note (\\DetailedComment) where required.
Service TypesThis document explains how we parse and render SubTypeNote and ValSubType, which is related to our Service Types. SubTypeNote is found:
ValSubType is a required attribute and is found:
How we parse ValSubType (from clients) ValEx parses ValSubType, SubTypeNote and //RealEstate/@Construction to determine the service type when a Client orders a job via LIXI. Please note that if the supplied SubTypeNote matches directly against a ValEx Service Type, that Service Type will be selected regardless of the ValSubType and SubTypeNote fields. Below is a list of mappings. FullRegistered
FullRegistered - Non Valuation Services
ProgressInspection
RestrictedAccessAssessment
How we render ValSubType and SubTypeNote (to ValFirms and Clients) Below is a table of how we render ValSubType and SubTypeNote. This information is applicable to Valuation Firms and Clients. DetailedComment/Comment is a list of comma-separated strings. E.g., <DetailedComment><Comment>Elite Valuation Request, Top-up</Comment></DetailedComment> FullRegistered
ProgressInspection
Kerbsides See: Kerbside valuations Service Type IDs Outside of LIXI, we prefer to refer to Service Types by IDs. Below is a table of these ID mappings. We often refer to Service Type IDs in documentation as "serv_id". For example, the Panel/Fee Lookup Web Service requires a "serv_id" argument.
RSS feeds for comments, forum replies
Is available via RSS ![]() |
Related LinksNavigation |
Recent comments
10 years 12 weeks ago
11 years 4 weeks ago
11 years 6 weeks ago
11 years 6 weeks ago
11 years 11 weeks ago
11 years 35 weeks ago
11 years 40 weeks ago
11 years 45 weeks ago
11 years 45 weeks ago
11 years 45 weeks ago