Calling all OSP experts...I have a requirement where employees can change from one OSP plan to another. When moving from Plan A to Plan B, the OSP Days taken under Plan A must be included in the OSP calculation for Plan B. I've set up two OSP plans using the standard Absence templates and the two plans do not 'talk' to each other. There is no way I can see of achieving this using standard functionality. The employee is simply given the full entitlement for the new OSP Plan and any days taken on the old plan are ignored. I do know about the Override OSP Entitlement EIT but I only really want to use it as a last resort - because it's fiddly to use and also because this occurs often enough to warrant an automated solution. Does anyone have any experience of doing this? Am I looking at a horribly complex customisation? Thanks Aces
Thanks Del. The only alternative I can think of is to just have one OSP Plan instead of two, with both sets of OSP Entitlement held in one Entitlement UDT. So I'll have two columns for Band1 Entitlement, one for contract type A and one for contract type B. So everyone gets enrolled into the same plan, and stays on that plan even if they change contract type. The problem here is that I'd need to ensure the entitlement calculation logic uses the contract type to determine which column in the Entitlement table to use. I have a horrible feeling that the Absence Participation Process does some of the OSP entitlement calculation, in which case I'd have to customise it, which is a bit of a no-no. Grateful for any advice from OSP gurus out there.
As standard I think we have limited option to using override EIT for people moving across plans. Thinking of small number of cases when this would be required generally clients get on and use the EITs.
Thanks, yes the Override OSP would be fine to use for a small number of cases. But we have a particular business process which means that we'll definitely have a fair number of these cases every year. So if it's possible to automate this it would be worthwhile, as long as it's not horrendously complicated.