One of the first things you notice when you take a canter round a worker record in Talent (or, for that matter, the HR module in Finance and Operations), is that there are dates EVERYWHERE. If you’re looking to find or maintain a start date for a worker, there are no less than six different fields to choose from. This can be a little bit confusing when you’re first learning the product – but actually they all serve a slightly different purpose. Provided you know which ones are referenced elsewhere in the product, you can make an informed decision about which one to use for which purpose. In SAP this stuff was pretty much all recorded in infotype 0041. Quite why I can still remember that when it’s been six years since I last went anywhere near SAP as an end user, is anyone’s guess.
In this post I’ll look at each of the six in turn and talk about where and why you might want to use it. The important thing to remember though is that with a one exception, these fields are optional. If you don’t have a purpose for them – don’t use them. You’ll never be able to trust the data in them anyway if there’s confusion about what they’re used for, so better to steer clear.
Let’s start with the dates on the ‘Profile’ tab.
Right, let’s kick off with the (maybe not so) obvious. The dates held on the profile tab here are recorded directly against the worker. What that means is they’re independent of the worker’s employment with any given legal entity. This is significant in two scenarios:
- You have workers who transfer between legal entities and you need to be able to reference company start dates that are agnostic of the legal entity of employment
- Your workers may leave and return with a break in service, and you need to be able to recognise the previous service for entitlement to redundancy payment, benefits, etc, regardless of the start date of the current/latest period of employment.
Essentially these are just variations on the same scenario, but you get the idea.
Here’s what I usually use these dates for:
Original hire date
If you need it, this is the first hire date with the company. Remember this is regardless of any subsequent break in service. It’s manually maintained – you have to populate this field when you first create the worker – but if they leave and return, this date remains as the date first entered (this is because it’s linked directly to the worker, not to the employment). You can use this date to determine accrual rates for leave plans.
Seniority date
Like original hire date, this is manually maintained (manually populated when you create the worker) and remains in the event that someone leaves and returns. You can use it to determine accrual rates for leave plans. In UK terms, I consider this field to be the continuous service date. In many cases, this date will end up being the same as some of the other dates we’ll discuss. However – if you recognise previous service where someone leaves and returns after a break, you may find this date starts to differ. For example, UK school teachers pay and conditions allow for a break in service, with previous years of service being recognised. Let’s say I start teaching on 1 September 2010. I teach for 3 years, up to 31 August 2013. I then take a career break for a year to consider if teaching is really the career for me. When I return to teaching on 1 September 2014, my ‘original hire date’ (the date I was first hired by this employer) is still 1 Sept 2010. However, I’ve had a break in service, and I’m entitled to have my previous service recognised for the purposes of accruing leave. I have 3 years service, so we work back from 1 Sept 2014, and make my ‘seniority date’ 1 Sept 2011. It’s as though the break didn’t happen, but I didn’t accrue extra service while I was on my career break. (If you read ahead, my ‘Employment start date’ is still 1 September 2014 – so there’s room for all the relevant dates). We also often find this is relevant in TUPE scenarios, where you need to recognise service in a previous company.
Anniversary date
This date was actually added to the standard product for a customer of mine during their deployment phase. They made heavy use of contractors, and used ‘original hire date’ to record the original date of association with the organisation, with ‘anniversary date’ then recognising the date of joining as a direct employee. Seniority date was used to reflect recognised continuous service. You can use it to determine accrual rates for leave plans. Outside of this previous customer, I haven’t found anyone else with a particular need for it, and very often end up hiding it through personalisation.
On to the dates on the ‘Employment’ tab:
Once again, at the risk of stating the obvious, the dates here are specific to the current period of employment. If the worker leaves and returns, the dates shown in this form will be replaced by the dates relevant to the new employment record. The history can still be seen but you have to dig around for it a bit (go into the ’employment history’ form and hit ‘date manager’). This focuses the mind a little on how to use these dates.
Worth a little reminder that you can terminate a worker, and then rehire them, without creating a whole new worker record. The worker retains the same ID/Personnel Number, and many of the (worker-linked) details are carried across. Whether or not you choose to do this probably depends on your payroll solution in the UK – because HMRC require that each worker has a separate ID for each period of employment. Some of the Dynamics-specific payroll solutions and HR ISVs have got round this by adding the facility to give each employment a separate ID.
Start date
This one isn’t auto-populated by the hire process, and has to be manually maintained every time a new employment is created for a worker. This means if the worker transfers to a new legal entity it has to be manually entered again. To be honest, I don’t really see a use for this field unless we identify a customer specific one during the deployment phase, so my starting point is not to populate it.
Adjusted start date
Like start date, this isn’t auto-populated by the hire process, and has to be manually maintained every time a new employment is created for a worker. This field can be used to assign accrual rates for leave plans. The only reason I have ever come across for using this field would be for payroll purposes. Maybe we need to indicate a date with the beginning of the payroll period as a start date. I’d stick that in this field, then use employment start date as the actual start date. A bit vague I realise, but I very rarely use this field too.
Employment start date
This field is key and critical and used in all sorts of places. This is the start date of the worker with this legal entity. You can use it for assigning leave plan accrual rates, it’s used for validating position assignment dates (you can’t be assigned a position for a period where you don’t have a valid employment), it’s used for validating compensation, and it’s used (lots) in reports. This is the date which is populated on the ‘hire worker’ form – you can’t create an active worker without entering this date. This is the only start date you absolutely have to use – so accuracy matters.
So in summary – there are plenty of date fields, and how you use them really depends on what you need to capture for staff in your organisation. As a starting point, I usually end up with the mandatory ’employment start date’ and then ‘seniority date’ for recognised previous service. Any more than that and it’s a case of picking the best fit based on how you want to use it, and what happens if the worker leaves (i.e. will it still apply if they come back).
1 thought on “What are all these start dates for?”