CTR(E) IA 011204 - Reviewing Dwellinghouse Coding Details - Inactivated CR10 Reports
These Instructions and Advice were prepared for internal use within the Valuation Office Agency as part of work towards a council tax revaluation in England that was due to take effect on 1 April 2007. The government announced its intention to postpone the revaluation on 20th September 2005 and preparatory work for a revaluation in 2007 has now been stopped.
This IA contains details of procedures to be adopted in England as a precursor for the revaluation. For information only in Wales
Council Tax Instruction and Advice
|
||||||
1.1. |
This IA is the latest in a number of IAs dealing with the review of Dwellinghouse Coding details for inactivated CR10 reports. Previous IAs have been: |
|||||
Instructions for capturing details of alterations/extensions from hardcopy report schedules for inactivated CR10 reports. This IA also indicated that a facility would be introduced to enable all inactivated CR10 reports to be identified and exported from the Central database to an Excel spreadsheet. |
||||||
Instructions for dealing with inactivated CR10 Reports received on or after 1 April 2004 |
||||||
CTR(E) IA 210404 IS NOW CANCELLED as dwellinghouse codes for all inactivated CR10 reports should now be reviewed in accordance with this and future IAs. |
||||||
Changes to Council Tax Application. A number of CT Activity Codes were introduced including Code 29 for use when dealing with inactivated CR10 reports. It also introduced a new CT Main Enquiry Report parameter that enables CR10 reports that have had Activity Code 29 recorded to be excluded from an enquiry. |
||||||
1.2 |
The spreadsheet mentioned in CTR(E) 18034 is now available. It has been designed with a number of inbuilt functions that will enable it to be used to control the whole process for reviewing dwellinghouse codes for inactivated CR10 reports. |
|||||
1.3 |
The various functions of the spreadsheet will be introduced as the process develops. At present it should only be used as outlined in this IA. |
|||||
1.4 |
This IA provides guidance for downloading inactivated CR10 reports from the Central database to the CR10 Spreadsheet for the purpose of undertaking an initial sift to identify those reports that require no further action. |
|||||
1.5 |
The spreadsheet should be saved regularly in order to ensure that updates are not lost. It is not necessary to retain different versions of the spreadsheet. |
|||||
1.6 |
Before undertaking the task, Council Tax Reval Team Leaders should identify the Billing Authority (BA) order in which CR10s are to be reviewed, beginning in BAs where the Mass Data Capture exercise has been completed. Work should not commence on all BAs at the same time. |
|||||
|
||||||
2.1 |
A folder called ‘CR10 Reports For Review’ should be created on the ‘R drive’ with the title, The spreadsheet should then be set up and data exported from CT Main Enquiries for the nominated BA, following the guidance given in Appendix 1. |
|||||
|
||||||
3.1 |
All inactivated CR10 reports received since 1 April 1993 will be included in the download to the spreadsheet. Some of these reports will have been: - |
|||||
i |
received since 1 April 2004 and where the dwellinghouse coding details have been reviewed; |
|||||
ii |
submitted for minor alterations that are clearly value insignificant and would not affect the dwellinghouse coding details, e.g. new door between kitchen and garage .… new kitchen window ……. porch……..etc; |
|||||
iii |
incorrectly submitted as CR10s. Some BAs have submitted reports for reasons such as annexes, split, merger,. etc, using reason for report code CR10. |
|||||
3.2 |
CT Reval Team Leaders must arrange for an initial sift of the downloaded report details to be undertaken in order to identify those mentioned in para 3.1 above. The aim is to identify reports that require no further investigation and record ‘Activity Code 29 – Pending COT report details reviewed for R2007’ on the central database. Instructions for carrying out the sift are provided below. |
|||||
3.3 |
A function to ‘Show Limited Sift Details’ has been provided within the spreadsheet to assist the initial sifting of reports. This should be accessed from the ‘CR10 Menu’ icon in the toolbar at the top of the spreadsheet via: |
|||||
|
||||||
|
||||||
3.4 |
Reports received since 1 April 2004 where the dwh codes have already been reviewed |
|||||
3.4.1 |
The majority of these reports can be identified by using a filter on the ‘Reason’ column as follows: |
|||||
|
||||||
|
||||||
3.4.2 |
Where the ‘Group’, ‘Type’ and ‘Area’ are present for the dwellings, then it is deemed that the details of the alterations have already been determined and no further investigation of these reports is necessary. Therefore, ‘29’ should be input in the ‘User Info Key’ column against each report. |
|||||
3.4.3 |
If any of the ‘Group’, ‘Type’ or ‘Area’ fields are not complete for a dwelling, ‘29’ must not be input. This is because even though the ‘alteration’ has been reviewed a further opportunity needs to be taken to obtain missing data later in the CR10 process. |
|||||
3.4.4 |
Once completed, the operator should ensure that all reports are again listed in the spreadsheet by taking the filter off the ‘ Reason’ column. This can be done by clicking the filter arrow on the column and selecting ‘All’ |
|||||
|
||||||
3.4.5 |
When dealing with post 1 April 2004 inactivated logged reports, a number of dwh codes will have remained the same following the review and therefore Reason Code P will not have been recorded.. However, providing records have been maintained in accordance with CTR(E) 210404 paras. 3.4 and 3.5 it should be a relatively easy matter to identify these reports. When identified, ‘29’ should be input in the ‘User Info Key’ column against the appropriate report. |
|||||
3.4.6 |
It is recognised that the action now required for reports received and reviewed since 1 April 2004 may result in some duplication of effort, especially where locations have reviewed large numbers. However, this action is necessary so that these reports can be excluded from any future download to the spreadsheet and so that progress can be monitored. |
|||||
Reports submitted for minor alterations and those submitted incorrectly as CR10s |
||||||
3.5.1 |
Reports under para 3.4 should be excluded from this part of the sift as they will have been reviewed. To exclude the reports click on the filter arrow in the ‘User Info Key’ column and select ‘Blank’ |
|||||
|
||||||
3.5.2 |
Providing the guidance given in CTR(E) IA 18034 has been followed, details of any alterations/extensions, which were submitted with reports by BAs or identified by caseworkers, will be shown in the ‘Remarks’ column within ‘Show Limited Details’. |
|||||
3.5.3 |
The purpose of this review is to scroll through the reports and identify those that suggest: |
|||||
i. |
the alteration is value insignificant ( e.g. porch, new chimney, etc) or |
|||||
ii. |
the report should not have been a CR10 ( e.g. annexes, splits, mergers, etc). |
|||||
3.5.4 |
The use of a filter on the ‘Remarks’ column may assist this process. To use this function, click on the filter arrow in the appropriate column, scroll through the list of remarks and select any which suggest the report has been submitted for reasons shown in para 3.5.2 (a) and (b) above. This will identify reports submitted using the same set of remarks. |
|||||
3.5.5 |
For reports identified under 3.5.3(a) above and where the Group, Type and Area are complete, ‘29’ should be input in the ‘User Info Key’ column against each report in the spreadsheet. If any of the Group, Type or Area fields is not complete for a dwelling, ‘29’ must not be input. |
|||||
3.5.6 |
For reports identified under 3.5.3(b) as being incorrectly submitted, ‘29LO ‘ must be input in the ‘User Info Key’ column against each report irrespective of whether all of the Group,Type and Area are present. ‘29LO’ will indicate that ‘Activity Code 29’ must be recorded and a LO Report raised as the report was incorrectly submitted as a CR10. |
|||||
3.5.7 |
Once completed, the operator should ensure that all reports are listed by taking the filter off the ‘ User Info Key’. To ensure that everything is listed click on the Data Menu in the toolbar and select ‘Filter’ then ‘Show All’ |
|||||
|
||||||
|
||||||
4.1 |
When the sifting process has been completed, printed lists of reports identified as ‘29’ or ‘29LO’ should be taken from the ’Show Limited Sift Details’ page of the spreadsheet. (Lists can be printed periodically prior to completion but this will need to be managed carefully to ensure no prints are duplicated.) To print these lists: - |
|||||
|
||||||
4.2 |
These printouts will serve as input dockets. Each sheet should be dated and initialled by the ‘CR10 reviewer’ and passed to Support Staff without delay. The date and the initials of the ‘reviewer’ will be used to populate the ‘Start/End’ dates and caseworker boxes when ‘Activity Code 29’ is recorded in the Central database. |
|||||
4.3 |
Locations may wish to consider support staff accessing the spreadsheet directly rather than using the print option. |
|||||
|
||||||
5.1 |
Immediately on receipt of lists of reviewed CR10s, Support Staff should use the lists as input dockets to record ‘Activity Code 29 - Pending COT report details - reviewed for R2007’’ on the central database for all the reports. Additionally for those marked 29LO, it needs to be established if it is necessary to raise a LO Report. |
|||||
5.2 |
It will be necessary to access the Activity Code screen for each report shown. This Activity screen can be accessed from the CT Application via: |
|||||
|
||||||
5.3 |
Where ‘29’ is shown in the ‘User Info Key’ column for the report, the inputter should record Activity Code 29 in the Activity Code screen by inputting the ‘Start/End’ dates and Caseworker’s initials against the appropriate Code. The caseworker will have dated and initialled the input docket (see para 4.2 above) and the Activity ‘Start/End’ dates and ‘caseworker’ fields should be populated using this information. |
|||||
5.4 |
When Activity 29 has been recorded in the Central database the inputter should initial and date the entry on the input docket to indicate this has been done. |
|||||
5.5 |
Where reports have been incorrectly submitted as CR10s, Activity Code 29 should be recorded to show the report has been reviewed and establish the need for an LO Report to be raised. These reports will be identified by Code ’29 LO’ in the ‘User Info Key’ column of the input docket. Before recording the Activity Code the inputter should first access the CR10 report in the ‘Amend Report’ screen and input the following in the Remarks field:
|
|||||
5.6 |
The Activity Code screen should then be accessed from ‘Amend Report’ by pressing <Ctrl F5>. |
|||||
5.7 |
A request should be made immediately via the ‘LOR Request Spreadsheet’ for a LO report to be raised, using the correct “Reason for Report Type”. There will be no need to do this if the reason for report has already been actioned under another report, for example, if a CR10 report says new property but the property is already in the CT List. |
|||||
5.8 |
The inputter should initial and date the entry on the input docket to indicate that the Activity Code has been recorded on the central database and a request has been made for a LOR to be raised. |
|||||
5.9 |
When raising the LOR the following guidance should be followed: |
|||||
“Originally submitted incorrectly as CR10 – See BA Report No ***.” |
||||||
5.10 |
When the working docket, VO7453, is output, the LOR should be cased up in the normal way and passed to the Referencing Manager or referencer to deal with as current work. |
|||||
5.11 |
If, sometime in the future, the existing CR10 is activated, the report should be cleared as ‘No Action’ with the reason “ Dealt with under LO Report No ***” |
|||||
|
||||||
6.1 |
Providing action is taken in accordance with this IA, reports identified in para 3.1 can be excluded from any future download from the central database to the spreadsheet. |
|||||
6.2 |
A future IA will give instructions on the process to be adopted for reviewing the remaining inactivated CR10 reports. |
|||||
|
||||||
7.1 |
Future downloads to the spreadsheet will include all recently received reports. Further guidance will be given in an IA for sifting out CR10 reports at the receipt stage, where the alterations are deemed value insignificant. |
|||||
|
||||||
8.1 |
There is no requirement to keep manual records as progress can be monitored through a CT Main Enquiry search. |
|||||
The following is attached as a Word Document: Appendix 1 – Guidance Notes
December 2004






