Requires checkout before clockout-aloha v4.421

[lawnmidget]

I have a bit of a connundrum here. Ive been working with a store for 2 months, and i cant seem to figure this issue out. The L3's can't figure it out. Maybe someone here can. The store uses generic "pm counter", "am counter" shifts when ringing in sales. the store is 24 hours. if there is an employee that is anything other than production *job code/access code* when the eod hits, and they try to clockout, they are required to checkout. this didnt happen before the FS replacement. the site is currently set to standard, with all the settings for job codes/access as such. I would think that this is a case of operator error, however, i had disabled the manage drawers function, so that they would have to use "assign own drawer" and "checkout" to try and limit any possibility that they arent using the system correctly. Debout.eod sheds no light on the issue, other than there is NEVER a carryovertransaction listed. and theyre usually busy during eod, so i think its unlikely that they NEVER have an open ticket...all the other config files seem correct. Restored the DB from a dated sub that dated before the FS replacement, and that was useless. had no bearing on the issue. However...if this really is just operator error, then wouldn't this have had occurred in the past as well? they havent hired on any new managers...so im lost at this point. Any ideas out there? please help!

 

[coorsman]

Delete (rename) the trans.log file when possible right after eod. This file is carried over at eod and contains all transactions for the current day and open checks and check outs for previous days. Stop FOH then delete it from data. Restart FOH.

 

[lawnmidget]

That's been done multiple times. a FS recovery has been performed, as well, also with no results. All the basic steps to TS this have been performed. Database has been reset to past days, as well, also with no results. Also, the client had said something about how the tech that performed the swap did "something weird with the trans.logs" but he doesn't remember exactly what. one other symptom is that the issue started on 6-22, however the checkout reports from 6-1 (before the swap, the subs were added at that time...) also show that this issue was happening. The client claimed that the reports have changed since the swap, and the "issue has infected the whole system". To me, its like the eod process is confused, and thinks the store is 24hr (which it is and it is set for) as well as thinking its NOT.