Change Request

Name Of Change :

CR Number :

Raised By

Date Submitted :

Exec Sponsor :

Version :

Priority : Low / Medium / High

SECTION 1 – TO BE COMPLETED BY CHANGE REQUESTOR

1.1 Current Situation

VDS first offered online Direct Debits (DDs) at Renewals 2018 so 2019 will be the first year where these practices will renew with an existing DD in place. In general, the process has worked well over the year with relatively few errors. There are two known issues which have arisen over the year:

1. Some practices cancelled the DD with their bank and then changed their mind and asked VDS to reinstate it. This is impossible to do with the existing DD Reference as the banks are not permitted under BACS rules to reinstate an identical DD arrangement once cancelled by the customer. As we use the Practice Ref as the DD Reference as the best identifier, we cannot reinstate the DD using the same Practice Ref and would otherwise have to recreate the practice identity – which clearly brings other complexities which we would rather not do. There are currently about 60 practices out of a total of 680 UK DDs which have cancelled for a variety of reasons.

2. A number of practices have changed their bank under new Switch Guarantee banking rules encouraging greater bank competition. When this happens the ‘new’ receiving bank automatically contacts DD originators and changes the bank details – in our case this means that the Paygate data is changed, but we may not pick this up and it’s likely that our VDSnet3 records will not be updated and the records will diverge from the Paygate data. To date, we have manually updated the VDSnet3 record but only when we have been told by the client. Again, the numbers are small but growing and the changes involve manual intervention. Given that there is a three-month gap between the final 2018 collection and the first 2019 collection at the end of January, there are likely to be several changed account cases taking place during the interval.

We intend to ensure that existing DD customers experience a smooth online renewals experience so changes will be limited to those which can be introduced without additional customer actions. The changes will therefore be primarily concerned with Paygate and VDSnet3.

1.2 Description of Required Change

The principles of the changes required are:

• We will cancel all the existing UK DDs after the final 2018 payment in October. The Paygate database (which will contain the most up to date bank details) will be downloaded and synchronised with the VDSnet3 data to ensure that this also now contains the most recent bank details.
• As users renew online, they will still be recognised by VDSnet3 as existing DD payers but, in practice set up a new DD with a new extended DD Reference – this will enable cancelled DDs to be reinstated if required.
• The final DD set up screen of the online renewal process, will be amended to provide an option for the user to set up a ‘new’ DD if they want to use different bank details.

The more detailed steps are:

1. All the current UK DDs will be cancelled after the last 2018 collection (26 Oct) with an AUDDIS OC message generated by Paygate – there will be no customer communication with this.
2. A copy of the Paygate database (which will include the most recent bank account details for those who have changed banks) will be obtained from Paygate and the VDSnet3 database will be updated where necessary to match. We should be confident therefore that the most recent bank changes will be reflected in this version with the DD flags correctly set.
3. When users, who already have a DD flag in place, renew, they will be identified as DD customers and provided with the option to automatically continue with their DD for 2019. It is likely that the great majority of them will select this option. However, in practice, this will be treated by Paygate as a new DD Instruction which will generate an AUDDIS ON message. This will, in turn, produce an email ‘Confirmation’ communication to the customer. The new DD Instruction will generate a new and different payer reference which will be in the format: 191XXXXXXXX, where XXXXXXXX is the existing practice reference. If a subsequent reinstatement is required the next instance which will be applied will be 192XXXXXXX etc
4. There will be some changes to the wording of the final renewal screens to make it obvious to the user that setting up a new DD is only required if they have recently changed bank account or if they choose to use a different account.

1.3 When is the Change Required

The changes are required to be in place in time for the start of the renewals and are shown on the attached page.

1.4 Business benefit of making the Change

The benefit of the change is to:

1. Control and reduce the impact of users changing bank details - and therefore the need for manual interventions to update VDSnet3
2. Provide a means to allow users to reinstate a cancelled DD
3. Permit users to provide updated bank details at renewal – or to change their bank account online should they prefer.

1.5 Impact of not making the Proposed Change

We could manage the DD renewals without these changes but with the additional and growing overhead of manual interventions required to handle exceptions of changes to customer bank details and requests to reinstate cancelled DDs.

1.6 Systems and Users affected by this Change

VDSnet3 will require changes to the data to match those held in Paygate (where bank changes have been made and not previously reflected in VDSnet3) VDSnet3 will require a modification to generate the new DD reference i.e. 191XXXXXX when a new DD instruction is generated. Should a practice cancel their DDI, flexibility to enable them to re-join the DD scheme is necessary, this would be done by creating the second DDI for the year with reference 192XXXXXXX. The proposed website DD set up page will be amended to ensure that the user understands that they only need to set up a new DD if they have recently changed their bank account or if they would prefer to use a different account and will display the existing account details to assist the user.

SECTION 2 – TO BE COMPLETED BY TEAMS INVOLVED IN MAKING THE CHANGE

2.1 Main Activities Required to Deliver This Change

What will you actually do (e.g. add a switch, update firmware, write a module, change database tables)

2.2 Impact on Other Work

Document the impact that delivery of this change will have on any other planned activities

2.3 Risks of Implementing this Change

What could go wrong by implementing this change – e.g. ‘The Network may go offline’, ‘stored procedures may fail’

2.4 Estimated Effort

How much effort in man days is required to deliver the change

2.5 Estimated Cost

How much effort in cost terms is required to deliver the change (if applicable)

2.6 Back out Strategy

If there are any issues associated with the implementation of this change, what is the expected course of action?

3. Lessons Learned

This section needs to be written after the change was made. Please provide any information on lessons learned which may be used to aid delivery of future changes or projects

Expected date for delivery of the change: yyyy-mm-dd

Person Responsible for Success/Failure of Request: name

Authorised by HoD / CEO: name

Authorised within IT Department by: name

Authorised Signature:

Authorised Date: