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.
Comments
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
Must have!!!
Category: General
Must have !!! Do we have a status on this?
Category: General
Must have for us! Would be great to have this implemented
Category: General
Must have!
Category: General
a really essential point which must be implemented!
Category: General
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
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
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
Agree with both the issue and the comment.
Category: General
Administrator on 9/24/2019 9:18:57 PM
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.