Time Zone Issue
Hey - I haven't had any luck figuring this out and just wanted to drop this in here. If a user enters time into their time card and they exist in a different time zone it can screw up your time card for others. Below is a scenario:
Employee 1 is in EST - they enter their time detail at 09:00 (AM) on September 11, 2019. 8 hours
Employee 1 is in EST - they enter their time detail at 01:00 (AM) on Sept 12, 2019. 6 hours
Employee 2 is in MST - they view this time card for approval, the time on Sept 12 will be translated back to Sept 11 and show 14 hours worked. Obviously for overtime calculations that is completely wrong!
Has anyone else run into this? And if so how did you go about fixing that?
I'll let you all know the temporary solution - ensure all of your employees are in the same time zone on setup. If you don't and you happen to be working in more than 1 time zone you'll most likely run into this issue at some point.
I can't fathom how you can launch a product without thinking about time zones for time entry when it affects literally the only things a company needs to do to stay in business (invoicing customers and paying employees) but hey what can you do.
So the act of approving the time actually changed the hours on the Timecard? Ouch, definitely need to report that one to Acumatica support.
It isn't the approval that messes up the data - looking at the data entered from one time zone in another time zone will display it incorrectly. The worst part is the end user still sees what they entered and so cannot tell what the problem is.
User 1 enters 10 hours with a shift start at midnight in EST Oct 17
User 2 view that time card and sees 10 hours on Oct 16 as they are in MST and the shift start would be 22:00
Good idea I will submit a ticket and see what they say.
Ah, I see. So you'd expect User 2 to see 2 hours on Oct 16 and 8 hours on Oct 17 right?
No so I would expect to see 10 hours on Oct 17. I don't want Acumatica to guess what a user tried to enter 😉.
Shift work is just a lot different than regular 9-5 stuff, if you start work on the 17th that is your day of work, regardless of if you get off at 4am on the 18th. And Acumatica does respect that (good), the issue just arises that it puts an entire day of work on the wrong day if you're in a different time zone.
As another example imagine you're a small import/export company based out of the USA - say Houston. You were paying a contractor in the UK to receive your goods, but now it's better to have an employee there. They fill out there time in detail as a 6-3er (early shift), but working in different capacities because they are a small company and sometimes this person is an importer, sometimes a salesman, etc.
They fill their time in at 6am in London and that time would be midnight the previous day in Houston. So now when you check out this persons time card at the head office to pay them you'll have time from the wrong day on that day.
Below you can see an example from our company (not related to the fictitious import/export)
Interesting. I didn't realize that shift work all gets booked to the day when the shift started. At least Acumatica handles that part correctly.
Hopefully these time zone issues get resolved as Acumatica continues to expand their international footprint which should be helped by the recent BDO partnership:
They've since closed this ticket with me. The fix will be in the next patch for 2019 R2 and the following one for 2019 R1.
The agent I had was sketchy on the details of exactly how it will work and I don't know if their dev team was able to reproduce what I told them (I only say that because the temporary fix they gave me doesn't work). I'll let you know when we upgrade to the latest patch and see if it fixes the issue.
Not really. The issue persists, their fix was to make the warnings more prominent - but we can still replicate it. Doesn't seem like they would call it a problem/issue, it's a feature hah.
The work around for time zone issue is complicated, depending on what is needed by the Users. Technically, Acumatica stores the time & date in UTC. So when a user from another time zone opens the time card to approve, the start time recalcs to the users time zone (including date) - then displays the silly message that the time was originally entered in another time zone. POOR Planning to say the least. It gets even worse, if the day is the first day of the time card period. Because the time can move to a date OUTSIDE the time card period. AND, time card screen will show it as now the LAST DAY of the same week - because time is show by DAY, not date. Depending on Acu version (2019R1, before 108.0017), and time entry field order by User, the start time can be reset to 12midnight - which amplifies the issue exponentially.
here is how we worked around the issue for the client. The client has hundreds of users entering time, across the US - Main to Hawaii time zones.
1) set the start time for every work day to be 9am. (configuration | Work Calendar)
2) Make invisible the start time in time card so the user can't update. The client wasn't happy about expecting people to enter the start time anyway.
3) The client monitors which supervisors are assigned for approving time, and the time zone they are assigned to. With setting start time at 9am, the approver of time card can be 9hrs WEST before there is a move issue.
(NOTE-if you are using multiple steps in approval, time can move at each step)
4) Created GI's to report any time entry work date that is OUTSIDE the time card period, or time that is within 4 hours before midnight - as this was an indication the time has moved.
After the time card is Released to project, the time is reset to 12:00 anyway, so start time is only relevant if the client needs to see the progression of work for a user for a day.
Time & zones treatment is still the same in 20R1.
I am experiencing a similar issue where the dates for the weeks are showing incorrectly during certain times of the day.
On the Employee Time Cards screen the dates for week 38 shows as (09/14 - 09/20). In the time and Expenses preferences screen that week should have the following dates: (09/19 - 09/25)
When I open up the time card for that week and view the dates under the details tab it doesn't tie up with the week dates shown in the header. Week in the header shows as -> 2020-38 (09/14 - 09/20) while the dates under the details tab are showing dates that should not be there.
This has been an ongoing issue since 2019R2.
If the user logs in an hour or two later then everything shows correctly again. @nsmith is the database hosted by Acumatica?