92

D365 for Talent uses datetime registrations at all levels (dd/mm/yyyy hh:mm:ss), including: 1) Worker position assignment 2) Employment 3) Term of employment 4) Position effective date This leads to a series of challenges: 1) D365 FT does not always default the timestamp correctly in different timezones. 2) End-users need to pay explicit attention to these timestamps. 3) Becasue of time conversion towards GMT, this leads to challenges when interfacing to other systems. For example 03/05/2019 00:00:00, becomes 02/05/2019 23:00:00 in GMT +1. This leads to extra conversion work on the interface and makes the solution more difficult to scale up, when faced with a customer active in a wide range of timezones. When the datetime behavior would be replaced by "date only" behavior, these issues will be solved. This is imo a best practice among competing HRIS solutions. Vote for this idea and make D365FT ready for the enterprise market.

Category: General
STATUS DETAILS
Under Review
Ideas Administrator

Thank you for your suggestion. We’re considering this functionality for a future release.  This posting is provided “as is” with no warranties, and confers no rights.

Comments

S

Must have, working with datetime fields should at least be optional. Has been a struggle for user input, data migration, interfaces and reporting on each project I've been involved with.

Category: General

S

Must have!!!

Category: General

S

Must have !!! Do we have a status on this?

Category: General

S

Must have for us! Would be great to have this implemented

Category: General

S

Must have!

Category: General

S

a really essential point which must be implemented!

Category: General

S

Absolutely a must, can only confirm what has been stated above! Having the timestamp creates issues with any kind of integration (payroll, power platform, etc). For organizations working on different time zones - hence almost any organization with multiple subsidiaries - it creates confusion, with employees having to think in GMT terms when entering dates where the time does not add value.

Category: General

S

Major pain point and issue for us too. Cannot see any benefit only negative from having the time zone in here. If I was hired on Jan 1, 2020 in Singapore when data is viewed from the US it indicates I started on Dec 31, 2019. That doesn't make any sense. Effectively when I pull data for our Reporting I need to be very careful to lift local time zone sensitive data rather than the data from the time zone I am working as this could and does result in inaccurate Headcount and FTE figures.

Category: General

S

We've just launched and this has caused us numerous issues with workarounds having to be applied to ensure colleagues are paid once data is passed through to LOKI.. This would be a game changer for us and would reduce the risk inaccuracies in keying

Category: General

S

Agree with both the issue and the comment.

Category: General