!!!Cleaning Up Conversion Data 

!!Date Adjustments
All the date sensitive tables in the application, such as JOBS, POSITIONS and ASSIGNMENTS need to have a complete set of records that span from the beginning of time to the end of time. If there is a gap in time or an overlap within the records there could be errors generated during normal use of the screens or reports. 

Each date sensitive table has a corresponding date adjustment function within the application that will need to be run after the records have been loaded and converted. Each function will read through the records in the appropriate detail table in the P2K schema and look for overlapping records and gaps in time, starting with the records with the highest effective date and working backwards. 

If the first record it finds does not have an expiry date of 31-Dec-3999, the routine will change it to this date, making it the end of time. The routine will then continue going through the records in descending order looking at the expiry date of each record. If the expiry date is not equal to the effective date of the previous record less a day, the expiry date will be adjusted. This process will eliminate the gaps and overlaps in time for the table. However, if the last record it finds in the table does not start on 01-Jan-0001 it will not alter this record. Instead it will create a duplicate of the record with an effective date of the beginning of time and an expiry of the day before this record. This will fill in the gap at the beginning of time without altering the effective date of the record loaded and converted. 

The process of adjusting the dates requires the records to have the correct effective date on them. If the current record is loaded and converted with the beginning of time and then the historical records are loaded in after this the routine will cause the current record to become the most historical record in the table. It will expiry before all of the other records that have valid effective dates on them. 

The following table is a list of the date adjustment utilities in the application and the tables that they will scan through looking for gap and overlaps in time: 

||Function name	||Date Adjustment for …
|UMDA_ALP|      	... Leave Policies
|UMDA_BCG|     	... Benefit Coverage 
|UMDA_BEN|        	... Enrollments
|UMDA_DDP|        	... Departments
|UMDA_DEN|        	... Entities
|UMDA_DGR|        	... Groups
|UMDA_DJB|        	... Jobs
|UMDA_DPS|        	... Positions
|UMDA_DUN|        	... Units
|UMDA_DWR|        	... Work Rules
|UMDA_EAS|        	... Assignments
|UMDA_EPS|        	... Personals
|UMDA_MVR|        	... User Variables
|UMDA_PPR|        	... Payment Rules
|UMDA_PPRC|       	... Canadian Pay Rules
|UMDA_PPRU|       	... USA Pay Rules
|UMDA_SPM|        	... Premiums
|UMDA_SSR|        	... Salary Ranges
|UMDA_SWSS|       	... Wage Scale Steps
|UMDA_XPA |       	... Pension Accounts
|UMDA_XPO|        	... Pension Options
|UMDA_XPR|        	... Pension Recipients
|UMDA_XPT|        	... Pension Tables

Only run the functions from this list that you are actually loading and converting data for. If the data in these tables is being keyed into the application, the data entry screen will ensure that the beginning of time and end of time records are created correctly without gaps or overlaps.

!!Building Secure People Lists
For security and performance reasons, users will need to have a set of employees that they have been given access to. This is the “secure people list”. Any records created through the application screens will automatically be added to this list. However, the converted records will not be added to this list. 

A function within the application can be used to regenerate these lists, after all the date has been converted into the PERSONAL, EMPLOYMENTS and ASSIGNMENTS for the employees. Once the data for these tables has been loaded and converted into the application, run the [UEBSPL] function from the GO command window within the application. The report parameter screen will be displayed and will allow you to select the users that need to have the list generated for. By default the report will build the list for all users within the application. Left the report parameter set to this default value and run it. 

Once complete, you should be able to display any of the converted employees in any of the screens that have had data loaded and converted into.

For the future, any time a user is created, or security values are defined or changed with the [IMSV] screen, this function should be run again to build a secure people list for that user, using the new security values as defined.