cancel
Showing results for 
Search instead for 
Did you mean: 

New Position requirements with Event Reasons

Mala_Fuller
Explorer
0 Kudos

Hello everyone,

We have requirements where certain actions/Event Reasons result in new positions being required i.e. new Job Codes, Legal Entity, Employee Classification Changes. To date, we've used the "Position Transfer" option in follow up activity which then creates and transfers the employee to the new position. This config also meant that when we do loads for Promotions for the yearly cycle, it would automate the position there as well.

With the 1H release, it seems SF has done away with this functionality and I'm looking to find out how do others manage this process - particularly with loads when you need 800+ new positions, all data mapped, job codes changed etc. etc. - I'm struggling to find a process that is going to work or make sense - and of course 1H goes to Prod right before we have to do the yearly loads so we don't have a lot of time to try and resolve.

Accepted Solutions (0)

Answers (1)

Answers (1)

nlgro023
Active Contributor
0 Kudos

Most of my customers use the other version of position management (i.e. position is adjusted and syncs to job info, not job info is updated and adds/updates position), which means your approach was not even a real option for them (although it does indeed have practical benefits).

I can imagine you're not keen to work with import and exports perhaps, but it should be the easiest approach to:
1. Get an extract out of the system of the current state of employees you wish to update for job info (potentially with future dated records) + the fields to update
2. Get a position export (as you'll likely need at least the parent position of the old one and lookup the impacted positions
3. Lookup the updated info from your job info and when that's stored generate a new id for the positions (via a formula)
4. Upload the new updated positions
5. Upload the new updated job info.

Not ideal I may imagine, but if you have mass information it is an approach.

Mala_Fuller
Explorer
0 Kudos

Hi Jasper,

We do it both ways - if it's changed from the position level is syncs to Job Info, and vice Versa. But there are certain Event Reasons where it uses the Position Transfer functionality such as Promotions, Transfers, Change to Employee Classification etc. where based on the Event Reason (and rules since we use Event Derivation) - it will automatically move them to the new position.

I could do it via loads - however to try and figure out the best way to do 800 promotions and undo all our existing config that now has to be updated and changed within 3 weeks and tested to accommodate for this change is significant (in the middle of annual performance & comp cycles at that). I was hoping there was another option not based on loads since the Position Transfer config also works on loads.

I'm still interested to know how other companies handle this - if you need to load hundreds of records that require a new position - is everyone creating the positions via load first and just copying the existing position, mapping it to the employee somehow, and then doing a job info load with an event reason that uses position reclassification so it writes any new updates back to the position?

nlgro023
Active Contributor
0 Kudos

Reclassification is a completely different story, then things are in fact a lot easier as you could technically import the updated positions in the position with the special sync column to sync it all to job info. Integration center would not allow the sync, but mass data management would become an option as described in more detail here (if you really don't want to do it via import): Employee Central Mass Data Management for Position | SAP Blogs or maybe even the old mdf version of it.

The exporting, excelling and importing scenario I've seen a few months ago with a customer with 400k employees even (likely one of SAP's biggest, if not the biggest customer) in that sense. If a customer of that size does it, I dare to say there are not a lot of alternatives (due to their volume mass data management didn't work as the batches were too small).