Title Versions
Creating Title Versions
On creating an application on LRS a draft version of the title sheet will be created and the sections of the title sheet will be populated as follows:
DWÂ deed over the whole of a registered plot -Â property, securities & burdens sections are brought forward on DW create.
FRÂ deed over an unregistered pot - no prior title version will exist so no sections are brought forward on FR create.
TPÂ deed over part of a registered plot -Â no prior title version will exist so no sections are brought forward on FR create.
VRÂ voluntary registration of an unregistered plot -Â no prior title version will exist so no sections are brought forward on FR create.
FAÂ deed over an unregistered plot to be added to an existing title sheet - property, securities & burdens sections are brought forward on FA create.
TAÂ deed over part of a registered plot to be added to an existing title sheet - property, securities & burdens sections are brought forward on TA create.
VA voluntary registration of an unregistered plot to be added to an existing title sheet - property, securities & burdens sections are brought forward on VA create.
TUÂ title update - property, proprietorship, securities & burdens section are brought forward on TU create.
An auto-import note will be added to the title workdesk automatically which will provide details of the title version from the which the sections were imported. This note must not be deleted.
Some application types in LRS (which do not have an application form as such), IC and RR which are related to the correction of inaccuracies in the land register are only created with the permission or by instruction of the Post-Registration Enquiries Team.
Registering Titles and Checking the Application Work Desk
The particular title version sitting behind any application, although updated by users as it passes through the various processes, only becomes the registered version when the application is completed in despatch at the end of the process. As highlighted previously, registering that version does nothing to other title versions sitting behind other applications. This is the way the LRS is designed and the way title versions are registered should not cause any problems as long as applications are processed in chronological order. Before starting work on an application it is vital to ensure that the title version is completely up to date and incorporates all changes made in prior applications. This means that the application work desk must be checked prior to commencing work on any application to ensure that there are no prior applications and if there are any, find out what they are and where they are in the process. The application work desk displays a record of all pending (open) applications under the 'Attachd/Rel (Opn) Apps' tab.
Where a prior pending application has gone beyond legal settle, the current application must be delayed until the prior application has been completed, all sections of the latest registered version of the title sheet must then be imported into the current version before commencing work on the current application. If this procedure is not followed, the latter application will be processed using the existing RG or DF title version at the time the application was created and will not take into consideration work done on the prior application since the current application was created. Failure to re-import will mean that when the current application is completed, the work done on the earlier applications will be overwritten and lost. To limit the risk of this situation occurring LRS has been enhanced so that on attempting to confirm an application on LRS an error message will appear where the latest registered version of the title has changed. The settler must then re-import the sections of the title sheet from the new registered version and complete the necessary updates required in relation to the application undergoing registration.
When processing more than one application at a time (e.g. FR and DW) it is imperative that they are not only physically attached, but are also correctly attached on the system. If they are correctly attached on the system it is the master title work desk that will be accessed and updated and the title version of the DW is deleted. It is the responsibility of the officer processing the applications to make sure that they have been correctly attached on the LRS.
Many data integrity issues are caused by the way certain applications have been processed on the system. For example an FR and a DW being processed together. The settler may have input the data correctly for both applications, via the FR title work desk, but by not attaching the DW to the FR, the work has been lost when each application is completed and then registered in chronological order. This is because when the unattached subsequent DW application is registered its incomplete title version overwrites the full FR title version. To avoid this happening the following basic rules must be followed when processing any application on the LRS:
- If there are prior or subsequent applications affecting the current title that are not attached to the application this must be investigated to find out what, and where, they are.
- If in doubt consult with a team leader or lead user who will advise.
Miscellaneous Applications
Staff creating miscellaneous applications (i.e. those other than FRs, FAs, TPs, TAs, VRs, VAs and DWs) must be aware of what they are doing with these miscellaneous applications, particularly if there are other applications being processed at the same time. Further guidance should be obtained from a team leader as necessary.
What Does All This Mean For Me?Â
Staff creating applications
When creating a subsequent application over a registered title the application will be created automatically using a copy of the the registered title version.  If the title is not registered  the application will be created automatically using a copy of the latest draft version. Remember a legal officer will need to re-import the last registered version of the title sheet if there has been a preceding application which has been completed separately and Intake have not had a registered version to import. Further considerations are also required when dealing with a TU application that forms part of a run of shared plot cases.
Registration officer
It is the responsibility of the officer processing the applications to make sure that they have been correctly attached on the LRS. A 2012 Act application should not be attached to a 1979 Act application, however.
The application workdesk must be thoroughly checked for all pending applications and legal settlers must only proceed with settling their application if it is safe to do so.
If there is a prior pending application you cannot continue processing your application. You must arrange for your case to be put aside pending completion of the application in front. Staff dealing with miscellaneous applications when there are prior pending applications must be extra careful.
The registration officer must ensure the application undergoing registration is updated to include all the appropriate detail if the latest title version has changed since the application was created. On attempting to confirm the application an error message will indicate if the title version has changed.Â
Despatch
If despatching physically attached applications, they must be attached on the system before completing the applications. If applications are not attached on the system, under no circumstances should the applications be moved on the LRS to the despatch location. Such applications must be referred to a team leader.
Â
Registers of Scotland (RoS) seeks to ensure that the information published in the 2012 Act Registration Manual is up to date and accurate but it may be amended from time to time.
The Manual is an internal document intended for RoS staff only. The information in the Manual does not constitute legal or professional advice and RoS cannot accept any liability for actions arising from its use.
Using this website requires you to accept cookies. More information on cookies.
Feedback