Autosequence Reports - Employee Time Card - Incorrect Results

[ATadros]

Micros RES 3700
When running the Employee Time Card Report from Autosequence Reports>Reports>Labor>Employee Time Card and selecting the starting date of 07/31/2016 and end date of 07/31/2016 for an employee (not sure if he is the only one that has this issue, but he is the one that we have found the issue occurring to), the returned report has his shift for 07/31/2016 but ALSO has 08/01/2016 shift included, even though the start and end date entered for the search are definitely being set to 07/31/2016.

Within Sql db, the clock in clock out and labor_date are correct. I do not see any reason for the report to think that the 08/01/2016 shift should be a result for 07/31/2016 query.

This is causing some issues for payroll and would greatly appreciate your support in finding out why Autosequence Report is returning additional information than it should be...

Thank you!!

Antoine

 

[hosehead78]

Does his/her shift begin on one business day and end on another?

If this is the case, have them clock out and also run their Z Tape (Close out their shift), then have them clock in on the next day and start a new business day, (generally after the End of Day (or Start of Day, which ever you want to call it).

 

[ATadros]

I think I discovered the issue.

I checked the Credit Card Batch and see that 07/31/2016 cc batch did not settle until 08/02/2016.

This tells me that an issue occurred which prevented the "End of Night" procedure to take place at 4:00AM as scheduled.

If in fact "End of Night" procedures did not take place, than that means "Change Business Day" Autosequence step did not get initiated. Therefore, any data from 07/31/2016 and 08/01/2016, were consolidated into one day.

Because the employee did work on 07/31/2016 and 08/01/2016, when you run the "Employee Time Card" report for 07/31/2016, the result will include the shift from 08/01/2016 due to the consolidated business day.

If anybody has any input regarding this theory, I would greatly appreciate confirmation or any input at all.

Thank you aall, thank you hosehead78 for your comment.

 

[hosehead78]

Yep, that sounds like the culprit. Micros is finicky like that and can happen. It does on occasion with 9700, where if the EOD is still running when the next business day is running, it gets confused and causes these types of issues.

 

[ATadros]

Hosehead78, I am going to make this issue a bit more interesting.

I recreated the issue on our test lab and was successful. I clocked an employee in @ 9:00 AM then clocked him out at 11:00 AM. Then shut down the server. The next morning (yesterday) i turned the server back on. last night at 4:00 AM "End of Night" procedure ran.

This morning when I ran the Employee Time Card report for 09/07/2016, I only received 09/07/2016. BUT then i modified the hours for that employee to represent the hours our issue employee worked (09/07/2016 4:21 PM to 10:10 PM and 09/08/2016 9:30 AM to 4:07 PM) ran the report again, and this time my report had 09/07/16 and 09/08/16 information. The theory was correct, both days were consolidated due to end of night not changing the business date, but what is specific about the hours worked that caused both times to appear on the second report and not on the first report???...


Now here is where things get even more interesting.

The employee that we discovered this issue for, worked on 07/31/2016.
He was originally clocked in at 07/31/216 9:30 AM clocked out at 4:07 PM. BUT THEN...

The manager on duty, for unknown reason, edited this time card entry and modified it to the following:
07/31/2016 4:21 PM clock in time and clock out time of 10:10 PM.

When the polling took place between CTUIT and Micros Server, Ctuit received the data AND on the payroll report they received, the employee shows up with TWO Shifts for 07/31/2016 and due to the fact that each shift is 13 mins apart, it created a Split Shift penalty.

Why would the payroll report that CTUIT has, consist of the original clock in clock out time. And not just the Modified time. so now it looks like the employee worked 07/31/2106 from 9:30 AM to 4:07 PM then from 4:21 PM to 10:10 PM on the same day. But he ONLY WORKED 07/31/2016 from 4:21 PM to 10:10 PM....

I hope all of this is clear

 

[ATadros]

To Clarify...

I recreated the issue on our test lab and was successful. I clocked an employee in 09/07/2016 @ 9:00 AM then clocked him out at 11:00 AM. Then shut down the server. The next morning (yesterday) i turned the server back on. then clocked the same employee in from 09/08/2016 11:00 AM to 1:00PM.... last night at 4:00 AM "End of Night" procedure ran.

 

[ATadros]

Employee Clocked in on 07/31/2016 4:21 PM and Clocked Out at 10:10 PM.

On 08/01/2016 Employee clocked in at 11:26 AM and clocked out at 4:07 PM.

On 08/01/2016 Employee actualy worked from 9:30 AM to 4:07 PM.

MOD adjusted Clock In Time from 11:26 AM to 9:30 AM. The fact that MOD modified the Clock In time does not play any role in this issue. The same issue would have happened if MOD would have left the start time as 11:26 AM.

CTUIT payroll report is basing the Business Date for Clock In Clock Out, from the Business Date of Micros Server, and not from the actual input day and time recorded on the time sheet.

On 08/01/2016, "End of Night" did not take place. This means increment business date, did not take affect. Therefore, the database now thinks that 08/01/2016 is actualy 07/31/2016.

Because "End of Night" did not take place, the Micros database thinks Employee worked on 07/31/2016 9:30 AM to 4:07 PM then again on 07/31/2016 from 4:21 PM to 10:10 PM, therefore creating a Split Shift Penalty on 07/31/2016.

If "End of Night" had taken place as expected, than the Payroll Report sent to CTUIT would have shown that he worked:

07/31/2016 Start: 4:21 PM to 10:10 PM
08/1/2016 Start: 9:30 AM to 4:07 PM

Since "End of Night" did not take place, the Payroll Report sent to CTUIT shows that Victor Moreno worked:

07/31/2016 Start: 9:30 AM to 4:07 PM
07/31/2016 Start: 4:21 PM to 10:10 PM

In order to resolve this issue so it does not take place again in the future, CTUIT would have to modify how their report determines the business date. I am guessing that CTUIT relies on the Business date reported by the Micros Server. Instead, it should rely on the Date and Time that are actually entered on the Clock In Clock out time sheet.

 

[ATadros]

Okay so I dont think my theories above are correct. Although I was able to produce the same issue in Autosequence and reports (where an unwanted business day shows up in a labor search for another business day). This is because i reproduced the scenario on our test lab and when I ran the reports from CTUIT, they were not consolidating the business days like they are on the Micros server.

Help?!?!