Who's Online Now
0 registered members (), 2 guests, and 4 spiders.
Key: Admin, Global Mod, Mod
Newest Members
Ravi Pasapula, kumar1900, B_DOYLE, rdeshab, samba
1296 Registered Users
Recent Posts
IR35 Legislation
by delboy. 14/05/20 01:20 PM
Top Posters(30 Days)
delboy 2
CT 1
Popular Topics(Views)
494,331 PAYE RTI
60,391 HR_PF.K RUP4
Previous Thread
Next Thread
Print Thread
Rate This Thread
#12211 - 07/03/19 10:20 PM Major Organization Restructure  
Joined: Mar 2019
Posts: 2
KVS Offline
KVS  Offline

Joined: Mar 2019
Posts: 2

We are planning to do a major organization restructuring in Oracle EBS. The existing organization structure and hierarchy was setup at the time of HR implementation and has never been maintained or kept up to date when people/departments moved. As a result, all the reporting out of HR is not meaningful anymore. People have been manipulating reporting lately in order to obtain some meaning from data, but overall it is a mess. So, now we are at a point where everyone agrees that its not the reporting that needs patching but the underlying organization structure needs to be recreated as a whole. We are still in very initial stage but here are some activities which we have identified:

1. End date existing organizations and positions.

2. Create new organizations and new positions.

3. Build a new Organization and position hierarchy with new org/positions.

3. Move employee assignments to new organizations and positions.

Does anyone ever had a similar experience in their organizations. Basically I am looking for any suggestions/best practices which we can follow and roadblocks which we might face while doing this whole exercise. And also, any possible impacts it might have on other applications like Payroll, Finance, Purchasing, SCM.

Thanks in advance.

#12212 - 08/03/19 12:39 PM Re: Major Organization Restructure [Re: KVS]  
Joined: Mar 2005
Posts: 2,117
CT Offline
CT  Offline


Joined: Mar 2005
Posts: 2,117
Off the top of my head, I would imagine that it could potentially impact costing, element eligibility criteria (whether by links or eligibility profiles), purchasing (e.g. authorisation levels)

In terms of an approach, I'd be inclined to do the thing programatically (using appropriate APIs of course) - mainly from the point of view of being better able to control the whole process, verify the results of each stage, repeat end-to-end tests more readily, and doing the whole thing as quickly as possible, thus minimising downtime.

Oh, and test it all to hell, too.

Good luck!

#12213 - 11/03/19 03:40 PM Re: Major Organization Restructure [Re: CT]  
Joined: Mar 2019
Posts: 2
KVS Offline
KVS  Offline

Joined: Mar 2019
Posts: 2
Thanks for the reply. We are good on the costing part as there is no costing defined on Organization level. It comes from Element entry/assignment and element links. Also, element eligibility criteria (whether by links or eligibility profiles) is defined on people groups rather than organizations, so, that part is safe as well. But yes, we do need to review and do an impact assessment on purchasing (e.g. authorisation levels).

And we are still thinking about If using the seeded 'Mass Move' functionality would be a better idea than writing APIs. I know Mass Move would be quicker, as we will save on time to write and test APIs, but It could also be less flexible than custom code using APIs. Any thoughts ??

Thanks. :)

#12214 - 12/03/19 11:40 AM Re: Major Organization Restructure [Re: KVS]  
Joined: Mar 2005
Posts: 2,117
CT Offline
CT  Offline


Joined: Mar 2005
Posts: 2,117
This is only my opinion, so take it with the required amount of salt. To me, Mass Move would be viable, if:

1. All the changes you need to make are within its remit

2. The Mass Move process can run in the background as a concurrent job, and preferably make use of any multi-threading capability your target system may possess (harking back to my comment about getting things wrapped up ASAP)

3. Mass Move has the ability to run in 'validate only' mode - to allow you to resolve whatever errors you are likely to encounter over the entire population, thus avoiding the risks associated with doing a piecemeal move (e.g. some moved and some didn't because of some data or other error).

There was a time when I could have answered 2 and 3 for you, however my memory is not that good any more - if it ever was to start with wink

Bear in mind that from your initial task list above, Mass Move will only do the last one for you. Also, you might be setting yourself up for a fall if you try end-dating 'defunct' organisations/positions (your step 1 above) before you've successfully moved the assignments over to their new orgs/positions. In fact, I'd have that as the last step. Ultimately even Mass Move will be using APIs to do its work. From bitter experience the update_assignment APIs (for example) will attempt to validate the target assignment record as it stands before attempting the required change, and will fail if it sees the assignment with an end-dated org/position.

If nothing else, all of the above should be enough to reinforce the need for some rigorous end-to-end testing!


Moderated by  Administrator, Geoff Dixon 

Forum Statistics
Most Online283
Dec 25th, 2019
Today's Birthdays
No Birthdays
Recent vacancies
Top Posters(All Time)
CT 2,117
delboy 1,308
bcooper 1,293
paulgos 439
SBi 427
pat 254
Gus 252
vkumar 223
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Powered by UBB.threads™ PHP Forum Software 7.6.0
Page Time: 0.026s Queries: 15 (0.010s) Memory: 2.7578 MB (Peak: 2.9098 MB) Zlib disabled. Server Time: 2020-05-28 20:47:43 UTC