Part 2 - Appendix 9 - Batching Guidance – Recording FOR events as a batch, and recommended methods of batching
Appendix 9 - Batching Guidance – Recording FOR events as a batch, and recommended methods of batching
These notes provide guidance to caseworkers for batching posting events of FORs, Reminders, Warnings, Penalty Notices (PN1) and Penalty Notice Reminders (PN2). Other events suitable for batching include sending papers to CPR are also included. The use of batching is preferred wherever possible as part of the information gathering process. However, batching is not mandatory; the record of events (VO 7324) can also be used for individual FORs if required.
When recording posting events, whether part of a batch or not, photocopies of notices and letters are only required to be made where specified on the VO 7324.
The Record of Events form (VO 7324) can be used in respect of a “batch” of FORs; the VO 7324 can either record all events in a batch from start to finish, or merely record certain “batch events” in isolation. The Record of Events (VO 7324) can therefore be used to track all events relating to an individual FOR or a batch of FORs.
When seeking to batch a particular event in the FOR process, there are two recommended approaches:
-
Approach 1. “Self Contained” - Set up a “self-contained” batch and follow that batch from start to finish, recording all events in the FOR process on the same record of events form.
-
Approach 2. “Batch by Event” - Set up a batch at a particular point in time in respect of particular individual events capable of being batched, recording each batched event on a separate record of events. Such events would include posting and sending papers to CPR.
The first approach may lend itself well to appeal programmes, but is likely to become complicated should for any reason individual events within a batch become “out-of-step” with the rest of the batch. An example would be an agreement with a non-respondent to delay issue a penalty notices by up to two weeks, which would mean that it would have to be identified and excluded from the batch of penalty notices, and then sent two weeks later.
The second approach is not susceptible to individual events becoming out of step, but will mean that correspondence and appeal papers etc. in respect of individual FORs will have to be held separately to those papers relating to the batched events.
FORs can be issued in batches depending on local need. Such batches of FORs may be produced by RSA enquiries, or merely be the list of a variety of FORs to be sent on a particular day.
Whichever batching approaches are used following initial issue of the FORs, a list of FOR addresses in respect of each particular posting event should be produced from RSA, either via the Defence Support Package (DSP), or RSA main enquiry searches. The particular letters or notices concerned should be produced according to the list and, once placed in a posting box, the record of events signed as a statement of truth by the person posting the letters or notices on the list.
A suggested RSA main enquiry search routine is specified below. This will produce a list of all FORs at a particular point in time that have not been returned. When making up batches, it is advisable to prioritise, focussing on batching those FORs where the information requested is believed to be of greatest assistance before tackling those there the information is thought to be of less assistance.
Reminders – suggested primary parameters in Main Enquiries - RSA: “Form of Return”
Optional parameters (some of which are mutually exclusive)
| Billing Authority Code | xxxx |
| Sub Programme ID | xx/xxxx/xx |
| Sub Location 2005 | xxxx |
| Team Reference | xxxxxxx |
Essential Parameters (all of which are required)
| Date (FOR) issued between: | Either “<= xx/xxx/xxxx” or “From xx/xxx/xxxx To xx/xxx/xxxx”, where the “<=” or “To” date must be at least 30 days ago. Care also needed to make sure previous batches are “butted-up” properly and no potential reminders missed) |
| 1st Reminder Issued Date: | Is Null |
| Rent Status Ind | 9 |
Warnings – suggested primary parameters in Main Enquiries - RSA: “Form of Return”
Optional parameters (some of which are mutually exclusive)
| Billing Authority Code | xxxx |
| Sub Programme ID | xx/xxxx/xx |
| Sub Location 2005 | xxxx |
| Team Reference | xxxxxxx |
Essential Parameters (all of which are required)
| Date (FOR) issued between: | Either “<= xx/xxx/xxxx” or “From xx/xxx/xxxx To xx/xxx/xxxx”, where the “<=” or “To” date must be at least 44 days ago. Care also needed to make sure previous batches are “butted-up” properly and no potential warnings missed) |
| 1st Reminder Issued Date: | Is Not Null |
| Warning Notice Issued Date | Is Null |
| Rent Status Ind | 9 |
Penalty Notices – suggested primary parameters in Main Enquiries - RSA: “Form of Return”
Optional parameters (some of which are mutually exclusive)
| Billing Authority Code | xxxx |
| Sub Programme ID | xx/xxxx/xx |
| Sub Location 2005 | xxxx |
| Team Reference | xxxxxxx |
Essential Parameters (all of which are required)
| Date (FOR) issued between: | Either “<= xx/xxx/xxxx” or “From xx/xxx/xxxx To xx/xxx/xxxx”, where the “<=” or “To” date must be at least 61 days ago. Care also needed to make sure previous batches are “butted-up” properly and no potential penalty notices missed) |
| 1st Reminder Issued Date: | Is Not Null |
| Warning Notice Issued Date | Is Not Null |
| Penalty Notice 1 Issued Date | Is Null |
| Rent Status Ind | 9 |
Penalty Reminder – suggested primary parameters in Main Enquiries - RSA: “Form of Return”
Optional parameters (some of which are mutually exclusive)
| Billing Authority Code | xxxx |
| Sub Programme ID | xx/xxxx/xx |
| Sub Location 2005 | xxxx |
| Team Reference | xxxxxxx |
Essential Parameters (all of which are required)
| Date (FOR) issued between: | Either “<= xx/xxx/xxxx” or “From xx/xxx/xxxx To xx/xxx/xxxx”, where the “<=” or “To” date must be at least 61 days ago. Care also needed to make sure previous batches are “butted-up” properly and no potential penalty notices missed) |
| 1st Reminder Issued Date: | IS NOT NULL |
| Warning Notice Issued Date | IS NOT NULL |
| Penalty Notice 1 Issued Date | IS NOT NULL |
| Penalty Notice 2 Issued Date | IS NULL |
| Rent Status Ind | 9 |
Once caseworkers are satisfied that the search has produced the correct batch of FORs, a list should be produced. This can be achieved by adopting option 9 “Form of Return Summary Report” for a hardcopy report per billing authority, or option 10 “Form of Return Export to Spreadsheet”, which can be picked up in MS Excel in the usual way.
RSA also has a facility whereby it is possible to generate a warning of future posting events. This is found in RSA Main Menu/ 2:Rental Information/ 1:Rental Information/ 9:Reports Menu/ 7:FOR Warning. This is limited to one search per billing authority, per posting event. Although not designed with batching in mind, users in Groups with relatively few BAs may find it lends itself to the batching process.
It is also hoped that the Defence Support Package (DSP) will provide opportunities for making up batches, especially where seeking information in relation to programmed bundles of appeals.
The methods detailed above are not the only way of making up batches; other preferred alternative parameters may be devised depending on local need. Whichever method is used, it is essential to ensure that the lists are comprehensive and do not “miss” any items. It is also essential that the record of events (VO 7324) is properly annotated to the effect that all the items on the list(s) are posted in a post box by the person who completes the VO 7324.
It is possible to adopt a batch approach for events other than posting. These are:
-
Authorisation to issue PN1s
-
Appeals to VT – Notification to CPR of appeals received from VT
-
Appeals to VT – Final notification of outcome of appeals following settlement or VT hearing
-
Transmission of details to CPR authorising penalty recovery.
Certain events cannot be batched. These include:
-
Correspondence with a person on whom an FOR has been served (or their representative).
-
Telephone contact between the VO and a person on whom an FOR has been served (or their representative).
-
Appeal papers where appropriate
-
Details of mitigation where appropriate
In such cases, on the first occasion such an event occurs, a separate record of events (VO 7324) must be initiated for the individual case and used for all non-batched events in respect of the individual case thereafter. Where batch approach is “self contained”, these can be filed with the batch, where the batches are organised by event, those events that do not lend themselves to batching must be filed separately in FOR number order for easy retrieval as required.
Irrespective of how batches are organised, the main requirement is speedy retrieval of the information contained within the batch(es) when required. It is expected that all batch records of events that contain any reference to an individual FOR will need to be assembled. The best way to achieve this is to make the “date of record creation” part of the batch ID, and then file the batch(es) in “date of creation” order. In terms of “posting events”, this will mean that the RSA dates of notice creation would correspond directly with the Batch IDs, making retrieval that much more straightforward.
When dealing with self-contained batches, it is recommended that the batch ID be based on the nature of the batched FORs. For example, a batch based on a 2005 appeal programme may be identified as “29/01/2006 – Anytown Shops – 3450-ANY-4556”
When batching by event, it is recommended that the Batch ID be based on a combination of date and type of event, with a reference to the relevant event on the VO 7324, for example;
-
a batch of Warning letters may be identified as “29/01/2006 – Warnings”;
-
a batch of Appeals received may be identified as “29/01/2006 – Appeals Received”
When required for audit, tribunal or court purposes, it is essential that caseworkers are able to speedily retrieve all batch records of events in respect of individual FORs, and any associated papers.
This means copies of all postal and other batch events involving the FOR must be located (paragraphs 3 and 4 above), plus any separate record of events for the FOR, if applicable (paragraph 5).
All records of events and associated correspondence should be collated and sent to the caseworker making the request. Originals should be used wherever possible. It must be remembered that this information is considered restricted, as it forms part of ongoing compliance and recovery activity.