Hi all,

Is there any-way of doing the above?

Can this be done through a SIT, if so how can you pass the information from the SIT to the element entries.

All the help you can give would be much appreciated and if you need anymore info let me know

Chris

Hi Chris,

I dont know if this could be done using a SIT, however if you have used a SIT and stored the value in any of the segments in PER_ANALYSIS_CRITERIA then we sure can create a element defintion and call the SIT value in to the element entries using Hr_Entry_API.Insert_Element_Entry.

Hope this could help.

Rgds
MSA

Hey Chris,

Try Hr_Entry_API.Insert_Element_Entry to pass the SIT info to the element entries.

Rgds
MSA

Hi MSA.

Could you explain a bit further please, we are new customers to Oracle and trying to learn all the time

Thanks

Chris

I would look into using Oracle ICD (Individual Compensation Distribution) - its normally used for benefits allocation - but you could use it for overtime as it essentially uses the self service entry and approvals processes to add element entries.

This would save writing custom code and you would not need any more licenses as long as you have self service as far as i understand*

I am also not sure which version of HR this is available on - I am currently looking at in on 12.1.1.

Hope this helps,

Ian

(*don't take my word on the licenses though!!!!)

OTL? Oracle Time and Labour is designed specifically for this...

Create an Payroll Exceptions Timecard (Exceptions as you only want unusual payments to be entered, i.e. Overtime). Create an Alternative Name (which links to your Payroll Elements), say Overtime 1.5, Overtime 2.0, Overtime 2.5 etc.

With regards to ICD, I think that this should really only be used for recurring elements. This process effectively allows an employee to enrol themselves into plans... We used in a Gov't proj in Australia, it was slightly customised but was on 11.5.10.2; AU legislation... I wouldn't however take that as being right as they had a tendency to "hack" the system a lot!!

Chris,

I would tend to agree with Gavin. We use OTL at my current site to pay overtime but you would also need to run retropay every month as overtime is normally paid in arrears and the entries created from the timecards are posted to the payroll period in which they were worked, not when you might want them to be paid

Cheers,

Delboy

Thanks for all the info, We do have OTL - but dont find this very useful for the many different enhancements we have.

The other question would be what are the possibilities of trasnsfering the data from and SIT (Or EIT, which ever is best) to BEE?
Again is this possible, and does anyone have any advice on how this would/could be done?

Question for the techies, methinks. Definitely a custom process if achievable.

Delboy

This might be a somewhat simplistic approach, but why have this info as an SIT when ultimately it wants to be an element entry? Why not just create element entries? What benefit are you deriving from holding the same info in 2 places?

I would have thought that an overtime element, with a standard Web-ADI batch element entry upload, would do the job for you without the need to create expensive custom interfaces.

Assuming I am reading the first post correctly, because they want to enter the details via Self Service.

I assume an alternative to ICD is required.

Yes the details from the EIT/SIT can be transferred to BEE using a custom concurrent request using appropriate Apis.

BEE would be a good way to go as it gives you validation prior to loading elements against an employee. I personally prefer BEE to directly loading elements aainst employees

Ah, the old 'Reading the post heading' trick eh?

OK fair do's.

Yes, you can have something that trawls the SIT entries and 'copies' the information to an element entry. The issue as I see it would be around covering all the possibilities for creation/change/deletion of the SIT, and making the equivalent result happen on the element entry. In that respect, I think element batches would be OK unless there was the need to end-date or even purge something. I'm not 100% convinced that you can do that sort of stuff via BEE. Bear also in mind that SITs are not truly date-tracked, whereas element entries obviously are: so you have to think very carefully about the possible scenarios that can happen to an element entry in terms of changes, and then try and relate each of those to an equivalent event on the SIT.

Edit: I imagine that being to do with overtime, the resulting entry would in all probability be a non-recurring entry, in which case the only thing you might need to worry about is correcting things like number of hours, hourly rate etc. So BEE might actually be a good move, as my learned friend opines!

I'll concur with that. Added advantage you can rollback batches if something goes belly up.

Yep this is the main advantage over directly Api-ing Elements against employees...also allows the end user (non techy) to amend add details to the batch if required