Table of Contents |
---|
This document shows some of the most obvious visual changes and describes some of the other changes in LRS to areas such as A. Section schedules, B.Section names and general picklists changes.
This can be accomplished by emailing IT Service Desk with the details of the Application(s)/Research Area and requesting that it/they be moved. If the application is on referral every attempt should be made take it back through the referral route before contacting the IT Service Desk.
It is only appropriate to "clone" a burden version when the text or editing of the existing version(s) is not suitable for your title. Such as when the colour references have been shown using different tints from those in the existing version(s) or some textual changes are required (this excludes typo's which should be referred to a designated person within each Registration Unit who has the Burden_Amend permission - see also Question 21 for a list of Users). Please note that when cloning a new version the element box should always be used to explain the difference within the version.
To activate the recall case function, open the Case Workdesk, select Tools>Recall Case and the "Select Case For Recall" will appear, input the Case [Application] number and select OK, subject to certain criteria [See below] the Case will appear on your Case Workdesk.
You will be able to recall a case only if the immediately preceding event was a "Release" and you personally Released it and you are performing the Recall in the same Group (i.e. Legal Settle) that the Release occurred.
You will NOT be able to recall a case if:
if you are attempting the recall on a Monday and the prior Release event occurred in a previous week, this is because the weekly EIS statistics have been run.
All requests for LRS permissions should be completed by the TL of the person requiring the permissions and emailed to the IT Service Desk.
Please note only permissions relevant to the user's role will be provided. Special Permissions such as Cancel, Burden Amend, Nap Support Manager and Intake should always be approved by Team Leaders in the first instance.
Where possible LRS permissions will normally be available to the LRS user on the following day to the request however it would be appreciated if the form is submitted as soon as possible. If permissions are urgently required then the Team Leader should contact the IT Service Desk (Ext 3166) who can push across an individual permission (please note that this process can affect the performance of the servers so these requests should not be widely used).
Permissions that are no longer required should be reported using the same application form or by the Team Leader to the LRS Support email folder so they can be removed.
Next Application Notes allow information to be added to any new or pending application or flagged against the Title Number the note has been created for. Such information can be Internal only or Internal and Public, Persistent or a one-off.
Where possible NAN's should be selected from the picklist. Obsolete NAN's should always be removed.
When CONFIRMING an Application (or on AUTOCONFIRM when Releasing an application) information is passed to the Finance System and BOPS, if either system is unavailable then an Error message is displayed.
The COMPLETE button can be "greyed out" usually for one of the following reasons
This can happen for the following reasons;
Where the application, usually a "DW", is to be cancelled and the "CANCEL" button is "greyed out" this normally happens when that Application's Title version has been "CONFIRMED" and has a status of "DFc". The application should be "referred" to the Legal Settler/Cancellation Office to "UnConfirm" the Title. This will update the title status to "DFu" and result in the "CANCEL" button being enabled once the application is released back to Despatch.
However if the application to be cancelled has a title status of either
The CANCEL button can also be "greyed out" if the selected Working Group permissions does not allow the "CANCEL" action to be performed.
This can happen for the following reasons;
A possible reason for this is that a HYPHEN has been used in one of the names searched for. HYPHENS should NOT be included in searches.
The LRS Common Links data is available on the LRS casework Desk under "Search". The link shown below explains the Common Links further and list's the current contact with the required permissions to make additions, amendments or delete existing entries. The actual pdf images for the Links can be found under the "Quick Links" section on the Intranet.
An "OUTSTANDING APPLICATION" is an application that has been sitting at or in transit to a Location or even with a person for an unexpected length of time.
An outstanding application can occur for a variety of reasons. Many still exist from the back conversion project in the late 1990's. Extensive work has been carried out over the years in an attempt to clear or reset them to the correct status but many still exist. Work is still ongoing. If current applications are not attached or completed properly they can soon turn in to outstanding applications. If applications are not completed properly or not completed in the correct order they can lead to Title Versions being overwritten.
Use the Production System Amendment form available via RoSnet .
Use the LRS Creditor Code request form available via RoSnet.
Static Data is a term used to describe data that has been mutually agreed for use on systems on a constant basis throughout the ROS network. On LRS this is generally available on the picklists. The data shown within these picklists has a corresponding affect on other system such as BOPS which rely on the uniformity of the data.
Although LRS has what is known as free data fields it is important that Users select the data from picklists where these exist.
LRS static data fields are currently maintained by the Data Integrity Unit.
See the "Data Integrity Information Paper 04/2008 LRS Picklists" on the availability of Picklists in LRS.
The "Data Integrity Information Paper 5/2008 Clarification on B. Section Entries" explains the use of the "As Entry" function on LRS. It is important this is used where appropriate. Settlers should be aware that the B. Section "Use in CC" tick box for the "As Entry" Entry may need to be de-selected when using this function.
The "Data Integrity Information Paper 8/2008 LRS Refresh/ View Personal Buttons" explains how to check.
ILR is an abbreviation of Inaccuracy in Land Register (Internal). Links to the appropriate page of the Registration Manual can be found on all workdesks of the LRS under the Help menu. Update, August 2023: The ILR form has been superseded by the Title Inaccuracy Service, found via the LRS Help menu.
See "Data Integrity Information Paper 12/2008 Internal Data Amendment (IDA) Forms" for full details.
The general rule is that Title/Plans N&I should only be used where information is permanently required as a means to explain why a decision has been made that affects the underlying Title. Current decisions such as "ROI is Clear" should be added to the Application N&I where this will not clutter up the Title Notes.
Where possible NAN's should be selected from the picklist. Obsolete NAN's should always be removed.
For more information see "Registration Manual - Adding Notes to the LRS".
A brief explanation is available on the LRS Support webpage "Burden Amend Permission – instructions". For those who have the Burden Amend permission, the actual deed-burden rules can be viewed via the following link. "Deed-Burden Rules".
Tables should be set up so that they do NOT exceed the width of the D. Section gridlines. See "D. Section table example".
See "Data Integrity Information Paper 06/2011 - Land Register- Use in CC option in B Section.". for full details.
If your Team Leader cannot give you an answer or is unavailable please e-mail the IT Service Desk.