morglum666
Well Known Member
I've stumbled into an ugly problem, and so far every solution I've worked out is just as ugly as the problem itself. Any tips would be appreciated.
Background:
The company I work for through many, many years used an alternative identifier for employees that was not "E". Let's call it "NE" for the fun of it.
Payroll, HR are implemented and all key employee references were still to the "E" account and they work. CSMS is used fairly extensively with 10-12 queues and for many years, the case management side has had the "NE" number attached to the assignee field in the calls.
Fast forward to today:
The JDE internal team recently completed a HR upgrade and some functionality of the HR module will not work with employee login accounts linked to non "E" addresses. So it was on to move employees to E, except for the fact literally thousands of cases have the "NE" assignee. Also for grins and giggles, CSMS screens pull information about the logged in user so cheating isn't an option (leaving csms related accounts at VE).
I've tried a few ideas to mass update these calls.
1) Contacted Oracle about mass updating them. Given that this is a CRM style problem, you'd think they would have something? - Not so much.
2) Considered a DB update. Ugly, not supported.. the plus is that its a small modules, but the negative is that the main program (P17500 which spawns a bunch of P90xx) average 40+ BSFN's each. I can't even imagine mapping that out, even via walking through the debugger.
3) Manually will work for all calls that are not closed, but for closed calls they have to be re-opened, re-assigned and then closed. Need bodies I don't have.
I've considering migrating just some of the cases manually, like the open ones and doing some reporting to bridge the gap. Does anyone have any experience with any other alternatives?
Cheers
Malcolm
Background:
The company I work for through many, many years used an alternative identifier for employees that was not "E". Let's call it "NE" for the fun of it.
Payroll, HR are implemented and all key employee references were still to the "E" account and they work. CSMS is used fairly extensively with 10-12 queues and for many years, the case management side has had the "NE" number attached to the assignee field in the calls.
Fast forward to today:
The JDE internal team recently completed a HR upgrade and some functionality of the HR module will not work with employee login accounts linked to non "E" addresses. So it was on to move employees to E, except for the fact literally thousands of cases have the "NE" assignee. Also for grins and giggles, CSMS screens pull information about the logged in user so cheating isn't an option (leaving csms related accounts at VE).
I've tried a few ideas to mass update these calls.
1) Contacted Oracle about mass updating them. Given that this is a CRM style problem, you'd think they would have something? - Not so much.
2) Considered a DB update. Ugly, not supported.. the plus is that its a small modules, but the negative is that the main program (P17500 which spawns a bunch of P90xx) average 40+ BSFN's each. I can't even imagine mapping that out, even via walking through the debugger.
3) Manually will work for all calls that are not closed, but for closed calls they have to be re-opened, re-assigned and then closed. Need bodies I don't have.
I've considering migrating just some of the cases manually, like the open ones and doing some reporting to bridge the gap. Does anyone have any experience with any other alternatives?
Cheers
Malcolm
