Hello HCM Aces,

Just wondering if any of the Aces have any useful guides / docs on Absence / SSP Data Migration that they could share or point to.

Steve

Hi Steve
As a quick answer, best advice is to ensure all absences that are to be migrated have been closed off! Even if this means temporarily capping-off open-ended absences in order to migrate them over to Oracle, and then going back in and opening them up. Obviously you have to be careful with historic data as it is possible that Oracle will go and generate associated element entries for the absences as they are loaded. Data-fix scripts at the ready

In the dark ages we did not have the luxury of an absence API so anything went in terms of getting the data in. In the more enlightened times i believe there are API's although cannot confirm in there are supported API's for the core OSP/OMP functionality?

Unfortunately a lot of collateral that i have access to is restricted in terms of intellectual property rights (ie owned by the client or other agencies) so i am not in a position to upload or email.

You are more than welcome to post up any specific questions/issues that you encounter.

I'm sure that others may chip-in on this subject.

Regards

Barry

Thanks Barry.

Might have.... who wants to know?

Migration of absences these days needs to take into account whether or not there are any OSP plans in place. We had occasion to concern ourselves with this at a certain Civil Service organisation loosely connected with Northern Ireland last year. I might have something that could be construed as 'useful', however I am unsure about the issues of publishing here. If you PM me your email address I will sort something out.

The thing about migrating SSP average earnings though, is there is no API - you have to populate the table SSP_EARNINGS_CALCULATIONS yourself. This is not necessarily an issue, apart from the potential need to be very accurate with one's numbers in the period over which the migration is taking place - especially if the earnings levels are flirting around the threshold for qualifying for SSP. Harking back to that same client, we ended up having to migrate an element for each employee that contained the last 8 weeks of NIable earnings on the legacy system, so that any open sickness absences were able to have their average calcuated on the rolling 8 week period up to the point (Go-live +9wks) where all earnings were available on Oracle.

Oh, and 2 other things while I remember:

1. Make sure you migrate your absences in chronological order for each employee.
2. For any one employee, if an absence should fail to load for whatever reason, stop processing that employee's absences! Leave the rest unprocessed, otherwise you will not be able to go back and do the failed ones because of the presence of (linked) sickness absences.

Clive.

Thank-you. It is me, recently departed of Sunny Gosport. I think you have my e-mail address if you could send the useful info over, it would be much appreciated.

Just picking up on Barry's comments about deletion of any element entries created by the absence api. Why is the existense of the entries such an issue (and therefore the requirement to datafix / delete these entries)?

The periods prior to go-live for which there will exist a summy assignment will not be run, therefore no payroll / assignment action for the period should mean that retro does not have an action to compare against, so therefore they should not generate retro results. I assume I am missing a vital consideration here, can somebody please educate this poor brummy?

Thanks,

Steve

That is true for genuine historic absences. And it depends upon your go-live strategy.

One particular project in mind had a phased implementation, so there was a migration every 3-months into a production system. Hence we had absences going into a system for genuine live payroll periods that could be processed by retro.

I'm a "everything in its right place" sort of person. I dont like to see element entries kicking around the place that have not been processed. You never know who gets to poke their nose into the system, so these sort of things should be swept up and removed.

I can remember the only time I was actually placed as a funky was at Fat Boy Bloater Snackfood and Fizzy Pop co in Thatcham. Across the road from Yoda-fone, for those who vaguely know the place.

I remember we got round the creation of these spurious historical SSP element entries by create a custom withholding reason (I think it was called 'Migration' or similar), then using that as the reason for the stoppage of the whole of the SSP. I think we hit an issue with a couple of long-term absentees, but I cannot recall exactly how that was cured.

These days I think the creation of an entry is controlled by the 'enrollment' button on the absence screen. It would be worth investing a little time, I think, in establishing that it's still a problem.

Just to clear up a point. The 'enrollment' button only enrols the absence into your OSP Plan. The SSP element entries would still be generated whether you enrolled the absence or not.

Cheers,

Delboy

Yes, good point well made Del Boy.

Actually I have remembered what the issue was with long-term sickies being migrated... the use of the 'Migration' with-holding reason had the effect of reducing the number of qualifying days, which then effectively pushed out the latest date that the sickness could attract SSP by the same number of days. So we had to come up with another with-holding reason (something like 'Migration Max Weeks SSP Paid' to distinguish it from the seeded reason) to suppress any future payments beyond what would have been allowed under the rules of SSP.

A bit fiddly, but as I recall it not many employees fell into this category anyway.

Barry / Del / Clive,
Thank-you for the input.
Steve