Micros 3700 BUG Found in Autoseq Reports ANY RES Version Lower 5.7.5 Date Range Stops on 12/31/2020 24

[POSKitchen]

Dear all

In ANY Versions 3.2 up to 5.7

Some of you might already come across an issue with the RES Calendar End on 31.12.2020.
In any version lower than RES 5.7.5 the calendar in the system will end at 31.12.2020, starting from that date calendar will not be available so the customers will not be able to work.

Issue: RES Calendar End on 31.12.2020 -- Solution: Upgrade to RES 5.7.5.
there will be no Patch for any other version.


Pos Configurator same issue
Menu Item Prices > Date 2021+ Working
Schedule Classes Specific Date > Date not Working
Employee Stop Working > Different Calender Integrated Working

 

[ChefAndy]

Hi everyone...Running an old Micros RES 3700 V4.11 at my restaurant.
I'm aware it is horribly out of date, but it does everything I need
it to do, and haven't been in a contract for years...
Just stumbled upon this 2021 calendar bug, and am wondering if anyone
has any experience/insight on if it is patch-able on my
outdated version? I only need it for labor reports (hours)
and occasional daily sales reports (if I forget to print them at the end of the night)...
Thank you, Chef Andy

 

[zafrinali]

Hi everyone. Is there a way to fix this for RES 3700 ver 5.2? We’ve been out of contract for years

 

[DJ Mad Matt]

Chef Andy and Zafrinali - As far as I know, 5.4 is the oldest patchable version. Feel free to send me an email at djmadmatt74@gmail.com for some update/upgrade solutions that I have.

Best wishes,
DJ Mad Matt

 

[Solutech]

HI everyone!
I am new over here!
I am in the Netherlands Antilles Islands, we use here a fiscal solution for micros 3700. I updated a customer to the version 5.7.6.4 and ends up in having a really slow login process, it takes around 11 sec to login. Version prior to this one, we were deleting the .isl file from the workstations that were not using the fiscal printer, but with this patch we can no do it anymore. I understood that increasing memory will not help much. Any suggestions may somebody have !!!
Thank you for your help

 

[James Hirth]

@DJ Mad Matt

Would you please be so kind to add me to the drop box jameshirth7@gmail.com

Thank you,

James

 

[DJ Mad Matt]

Added James

 

[andyvill]

hi!

the definitive solution is:

using reshacker:

a) aopen the reshacker
b) open AutoSeqExec.exe (from reshacker)

c) in the window RCDATA -> TFRM_DLG_DATE
EDIT THE OBJECT
object spin_year: TSpinEdit [7]
CHANGE:
MaxValue = 2020
TO:
MaxValue = 2030

d) MENU ACTION -> Compile script

e) MENU FILE -> save as (AutoSeqExec.exe)

f) enjoy!


Andy.

 

[James Hirth]

Thanks Matt!

 

[mvelazquez]

@andyvill Thanks!!!!


It worked very well for me, Great Post.

 

[mrmicros]

Hello Matt.

Please can you add me to the dropbox link.
My email: gneal63@gmail.com
I need RES 5.4 5.5 5.6 5.7
Old customer with multiple sites and versions.

Much appreciated.

 

[WesleyCreed]

Hey Guys,

Found this post because I encountered the same issue for my RES 3700 build 4.5. Since I found myself SOL due to the old version, I decided to fiddle around (our restaurant is closed due to COVID restrictions, so this wasn't pressing). I found that while yes the calendar/year field doesn't like to roll into 2021 nor does it let you select it. I found that (atleast to run the Night Audit) at first the calendar selection shows the date as the previous year (ie correct day of the week for 2020), but if you cancel, continue, and try the Night Audit again, it'll still show "2020" in the year field, but the calendar will be correct (note the day of the week for Jan 7th). The Ending Business Date will always be correct from what i find.

Pressing on - the night audit reports reflect the correct dates too. Of course, when I tried i had no data since no restaurant was open - if anyone wants to try that does have a open business - go ahead and report back. Now i'm sure this isn't perfect, and I 100% expect problems down the road (ie pulling reports for previous dates in 2021+ won't be possible), but for those of you that just need your Night Audit and reports complete - then hopefully that works.

Thanks and good luck.

 

[DJ Mad Matt]

Mr.Micros - You were added.

 

[John T]

I am using Micros 3700 version 5.1. Do they have a fix for the date issue for this version?

 

[zafrinali]

@andyvill

Thanks a lot, Andy!
That worked great

 

[DJ Mad Matt]

John T ... Not that I know of. 5.4 on up only. You could try Andyvil's fix. Feel free to email me if you're interested in upgrading your server. djmadmatt74@gmail.com

 

[AndrewIHOPTX]

@DJ Mad Matt I only have the 700876-210s. Those run WinCE Pro Plus 5.0. Are you looking for the Win10 Enterprise IOT versions?

 

[AndrewIHOPTX]

Hello all!

So I've run into a rather bizarre complication. Back on 12/15/2020, I ran a test on the date roll issue at one of my locations (I backed up the DB, closed all open checks, clocked everyone out, and batched the CCs beforehand to mitigate complications). I changed the date forward to 1/10/2021 and rebooted the server to make the change take effect (I had to disable the auto-set feature for the time zone and date/time in Windows, but the date roll changed the date correctly). We are running 5.5 MR7, so the date change issue tested successfully showing the 2021 calendar in reports. I rolled the date back, rebooted the server to ensure the date change took effect, and had to run EOD for the business date to display correctly the 12/15/2020 date. MICROS operates normally, HOWEVER I'm stuck with an issue from a third-party reporting program that still reflects the incorrect business date. Unbeknownst to me, the database created a ghost business date that is still open.

In DBISQL, if I run "select * from micros.dly_sys_ttl where business_start_date is not null and where business_end_date is not null;", the resulting data shows that I have two business dates still open, 1/10/2021 and 1/11/2021. I had falsely assumed that the EOD last night would have closed the ghost business date, but that is not the case. Manually running EOD at this location this morning a second time still leaves the business date open for 1/10 and 1/11, and has no errors. The table micros.dly_sys_ttl is not editable, and I have max privileges, so I'm at a loss how to close this ghost date. Suggestions, advice, or scripts would be immensely helpful. Thank you all for your feedback, and I suggest you run this query on your DBs if you tested as I did to see if your results are similar.

Andrew

 

[andyvill]

in my case I don't have much knowledge of the internal workings of the system:

What I would do:

a) create server image using macrium (allows hot copy).
b) create virtual machine using virtualbox
c) restore the server copy using macrium in the virtual machine (it has an integrated tool that allows you to change hardware)
d) leave the virtual copy operational, without connection to any external network.
e) save a copy of the virtual machine.

now, using the virtual copy of the operating system:


1) I do all the tests I want, if it breaks I go back to the initial copy.
2) I set the business date you want
3) I guess I would go to the problem date and do the normal full closing, to see if the closing corrects the 2 business dates.

4) another thing is to try to change the owner of the table in the database, but always in virtual environment

I hope it helps you.

sorry for english, google translator

 

[AndrewIHOPTX]

The patch worked in my lab just fine, but a field test is always preferred to ensure a successful rollout. The ghost business date wasn't apparent in the lab as we don't use real-time data from the lab in our reporting software because it's a lab environment (any sales in the lab are for testing, so it would screw with our sales/labor matrix in the 3rd party programs). After seeing the data issue in the field, I confirmed it was doing it in the lab as well. But a solution hasn't been discovered yet for either.

 

[KrishnaK10]

This worked out very well for me. we'll thnx