Every client completes at least one upgrade every year. From our experience, very few complete this in a comprehensive manner. Time tends to be the main issue as well as staff movement and knowledge

Here are a few things that you could consider that will have a huge impact on your system in the long term. You may not complete these every time, however you do need to be aware that they are important.

We recommend that any client who has not upgraded to the BRE version 8.13 yet, do this now.

___________________________________________________________

Technical staff are often not functional

• Your IT people or the hosting provider may complete the backend upgrade and you may complete the testing of the payrun. Who is performing the system administration tasks in between?

FLM

• FLM needs to be run before the upgrade to clear down old emails, expired reports etc. This shrinks the database prior to the upgrade and therefore speeds it up.

RPI

• RPI should be performed often (we rarely meet people who do this). PIT, PIN and PIC were designed as a temporary holding area of payroll information. They were put in as a great way of reporting on data in the pay files (EACT, NETT and VARI) prior to when you ran UPD. They were not meant for permanent storage. Holding 10 lines per person per pay, continuously, creates an excessively large file. The size of the EMPIT file is often the largest in the system. As such, PIT reports are slow, memory on the server is used up and the upgrade will take a long time as it has to upgrade this entire file.
• PIT should only hold 12-18 months of payroll data at most. If you report beyond this, it can be a more efficient use of resources to run LPI in the TEST platform on the on occasions when you need to run reports that date back before this.
• Prior to upgrade, if you run RPI and clear the whole file. It will create a much faster upgrade. You can then load back as many pays as possible after the upgrade (as long as you have kept the EACT, NETT and VARI files for the pays, they can always be loaded again. The exception to reloading is any STUPs).
• To complete this faster; if on SQL, you can truncate the files at the back end

DDV

• Do you run this before an upgrade and after it? You should! Also, do you know what this does or how you can use it?
• Many clients test the payrun process but don’t do anything with the customisations. We often find that custom fields have moved within a screen and that the data entry is not aligned with the field label.
• DDV deals with customisations.
• DDV performs two main functions:
  • 1. DDV CHECKS CUSTOMISATIONS:
  • It checks all customisations on the system by locating the “A” or “AAA” entries at the field, form and file levels. If there is a record and it matches the programmed record exactly, it will remove the customisation and restore it to the programmed one.
  • An example of a customisation where this is done is: At some point, you may have made a field flagged as mandatory and then later changed it to be optional. Changing this created a custom “A” record. The change back, still kept it flagged as being customised. The record has all the attributes of the programmed field in the system though.
  • DDV will restore it back completely.
  • The reason it does this, and that you run DDV before upgrading, is that an upgrade will not adjust the features of a customised field even if the vendor has programmed a change. To receive the benefit of the change, it needs to be seen by the program as being non-customised.
  • If you have not run DDV for a long time, or fields have been customised for a long time, there may be a lot of areas in the system that are not reflecting the programming of the vendor between versions
  • 2. DDV INFORMS ABOUT CUSTOMISATIONS:
  • DDV informs you of all customisations (what the system sees as customisations) in all areas of the system.
  • This is where your action comes into play. You have the ability to use this information to check, post upgrade, if your customisations are still operating as you expect them to be.
  • You can also use this information to manually delete the customisation, so it takes up the newly programmed attributes and then re-apply your customised settings.
  • This is important over-time especially where you have had a system administrator in the past who has performed a lot of simple changes such as labels, position on the forms, optional values and default values.

ABA files

• ABA files need to be deleted. We have seen systems with over 25years of ABA files sitting in their DAT directory.
• You are not going to use old ABA files again. They store bank details for staff. As such, wherever they are going, they should be removed.

Menu and ATT profile updates

• It is important to update the Menu’s for and the access records in ATT for new forms that are added as enhancements to the system. This is the case, even where you may not be using the new forms immediately.
• This is especially important for the system administrator and power users. This maintains the integrity of your system over time.

TAB

• Sometimes the release notes specify new records needing to be added to TAB. Where these are system related or related to a module you use, but not a function in use, still add them in.
• This is important for system integrity and ensures you have a fully functional system as your needs change.

Audit files

• These need to be archived every 6-12 months. Monthly is often too frequent because it can be extremely hard to report.

Rollback files

• These need to be removed often. They are large and sometimes set to be kept in the database well beyond their possible use.
• An example of this is the UPD rollback file. If you had issues with UPD, you would either find them straight away and rollback or if you found the issues after 5 days, you would fix them another way and not rollback.
• Therefore, if you have kept these files for a while, they are taking up a lot of space and are unlikely to be used again. Best to remove these prior to upgrading.

There are many little tips for upgrading and maintaining an efficient system. These are just a sample. If you need help with upgrades in any way, feel free to contact us.