Okay so we want to do a migration with existing Employees numbers and then turn Auto numbering on.

So a few questions

1) In the old days we used to do the setting of the initial value in a sql script..is that still the case or can you do that in the App now
2) To load the emps with old numbers I beleive we need the numbering set to Manual, and then change it to 'Auto' after the load. Again I do not think the app lets you do this and it may have to be done in a sql script
3) Are there likley to be any issues if some of the loaded existing empnos start with a '0'
4) I realise this is pushing it a bit....suppose the legacy loaded empnos had an alpha character in them. Would there be any issues to turning auto numbering on for future hires ?? There is a little alarm bell saying so not do this, but I do not know why

All advice accepted

Cheers

Gus

Hello,

The application now allows you to switch auto-numbering on after implementing with manual. There is a process that you need to run which will actually do it for you. You need to decide if you are using global numbering or business group specific numbering.

Standard auto-numbering will not work with alpha-numeric numbering as it is unable to identify the existing maximum value from which to define it's starting point.

There is a third way these days which may be more applicable in your case. You can define a numbering fast-formula which enable you to define your own numbering system and which will work with alpha-numeric numbering.

Peter.

High Peter thank for the Info, from above

We will be using BG specific Numbering

Quote :- "Standard auto-numbering will not work with alpha-numeric numbering as it is unable to identify the existing maximum value from which to define it's starting point."

I thought that we could set the start point ?? using a SQL script to update per_number_generations ?? (from ancient memory)

Quote :- "You can define a numbering fast-formula which enable you to define your own numbering system and which will work with alpha-numeric numbering."

Do you have any further details on this it sounds interesting ??

Cheers

Gus

Hello,

Re. the auto-numbering, the seeded Oracle process examines the existing values, and will identify the next maximum value. The old-world way was never supported by Oracle, although they acknowledged it on Metalink -- if you look hard enough. You can still do it the old-world way, but you need to manually update a couple of tables, including the Org Information for the Business Group (can't remember specific table names). The problem with going alpha-numeric to numeric is that when auto-numbering is on, the (as far as I remember), the forms expect ALL the Employee Number values to be a numeric value.

Re. the Fast-Formula, again can't remember the specific set-up. Look at the following manuals: "Oracle Human Resources Management Systems Workforce Sourcing, Deployment, and Talent Management Guide (UK)", Release 11i, Part No. B15577-02, July 2006, Section "People Management" pp. 2-11 -- 2-13; and "Oracle Human Resources Management Systems FastFormula User Guide", Release 11i, Part No. B14471-03, June 2006, Section "FastFormula" pp. 1-120 -- 1-121.

Also, as far as I am aware, this process applies for R12 as well.

Peter.

Peter

I think this is the bit I am worrying about :-

"The problem with going alpha-numeric to numeric is that when auto-numbering is on, the (as far as I remember), the forms expect ALL the Employee Number values to be a numeric value."

Cheers

Gus

Hello,

There are alternatives ...

1. Use Custom Numbering -- the FastFormula approach.

2. Move all current employee numbers into the Additional Personal Details DFF for historic record keeping purposes, and use auto-numbering for ALL Oracle Employee Numbers -- both migrated and new hires.

You need to identify what the employee number will be used for outside of Oracle HCM. This should identify what structures down stream systems will accept, and provide some guidance as to what options you actually have.

Peter.

That was the path chosen when we did the migration for the NHS project.
In fact they had 2 legacy numbers - one for Payroll and one for HR!

It should also be noted that we pre-generated the employee numbers rather than using the auto-generation (due to performance reasons). We had 2 numeric ranges set up - 10000000 - 19999999 for the migration and 20000000 + for new hires.

For custom numbering you could do the FF approach, but what sort of volumes are you talking about? If its large there may be an unacceptable performance overhead associated with executing this FF for each employee being loaded.

Regards
Barry

2 Scenarios

1)
We are only migrating 1500 emps for this load. There legacy Employee Numbers are to be used but it is desireable to turn Auto Numbering on after Migration..this will obviously start at a higher numebr than the max number from the migration. Some Legacy Empnos start with Zeros....will this be an issue

2)
Employees already exist in another BG and have Manaul numbering on and also some empnos are Alphanumeric. I think we have agreed above that you have to leave these as is...unless you have an offering?

Are you really 'out of the country' ?

Cheers

Gus

The employee number field is a text field (as you know) - so its capable of handling leading zero's. HOWEVER since the auto generation uses a number the chances are it will not do leading zero's - so you'd need to use the FF-based solution (i think) or a custom solution (custom library or forms personalisation maybe).



Yes, you'd need to leave these as is unfortunately



Out IN the country

Rural isolation (except when i have to go to work)