User date rollover message not displaying after mid night
Just recently on the Dynamics GP Partner forum, my friend Japheth Nolt reported that some workstations at one of his clients would not display the warning dialog "It's 12:00 a.m. Would you like the user date to change to ...?" after the system clock crossed the 11:59:59 PM barrier, and that this issue would cause some users to enter transactions with the wrong date. After all, transaction windows in GP default with the user date, not the system date.
Japheth had already inspected the DEX.INI looking for the SuppressChangeDateDialog, making sure the key was not set to True. This setting prevents the user date rollover message from being displayed and was designed to prevent integrations running around mid night from failing in response to the warning dialog.
In addition, there were no macros running around the mid night timeframe either. When a macro fires up, all timed events crossing paths with the executing macro are re-queued by the runtime engine.
The first step towards solving the problem was replicating the problem experienced by the users. So, this implies changing my system's date and time to 11:59 PM., and check the Process Monitor to verify the status of the smChangeDateTimedEvent script timed event.
I noticed that past mid night, the smChangeDateTimedEvent script would move to the bottom of the queue, just as it would if a macro was executing when the timed event needed to be fired.
Something else was happening. I realized the date of the Fabrikam company is set to April 12, 2017, a far cry from my system date. Following, I changed the system date to April 12, 2017, 11:59 PM. Once the system date was changed, I waited patiently until the clock hit mid night... Bingo! The warning showed up!
As it turns out, the Dexterity Sanscript code checks that the system date matches the user date plus 1 day, before the user date is changed. Why? Since the Dynamics GP user date is managed by the user, the development team had to assume that if the user changed the user date, then the user wanted the date to remain in place regardless of any mid night change of date.
Until next post!
MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Japheth had already inspected the DEX.INI looking for the SuppressChangeDateDialog, making sure the key was not set to True. This setting prevents the user date rollover message from being displayed and was designed to prevent integrations running around mid night from failing in response to the warning dialog.
In addition, there were no macros running around the mid night timeframe either. When a macro fires up, all timed events crossing paths with the executing macro are re-queued by the runtime engine.
The first step towards solving the problem was replicating the problem experienced by the users. So, this implies changing my system's date and time to 11:59 PM., and check the Process Monitor to verify the status of the smChangeDateTimedEvent script timed event.
I noticed that past mid night, the smChangeDateTimedEvent script would move to the bottom of the queue, just as it would if a macro was executing when the timed event needed to be fired.
Something else was happening. I realized the date of the Fabrikam company is set to April 12, 2017, a far cry from my system date. Following, I changed the system date to April 12, 2017, 11:59 PM. Once the system date was changed, I waited patiently until the clock hit mid night... Bingo! The warning showed up!
As it turns out, the Dexterity Sanscript code checks that the system date matches the user date plus 1 day, before the user date is changed. Why? Since the Dynamics GP user date is managed by the user, the development team had to assume that if the user changed the user date, then the user wanted the date to remain in place regardless of any mid night change of date.
Until next post!
MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Comments