E7 - Error: Current Business Date is Incorrect

All Micros POS systems work on the principal that the current sales get saved into the database under the current business date.

The business date does not always match the current date.
Example the business date might be 1st November 2010 but its just past midnight in your bar or restaurant and you dont exactly want the system to suddenly start saving data under the 2nd November because at the end of your night  you want all your sales in one place so you can balance your finances.

So you might ask how does the business date update and when?

Well there are two ways. You can set the business date to automatically change at a certain time eg 4am when you close your bar.

But the most common way to update the business date is to have the End of Day procedure do it for you. When you finish your days work the End of Day does things like print reports, backup the database, check for any open checks that someone might have missed and last but not least update the business date.

Honestly you can configure the End of Day to do whatever you want but this is the most common.

So for whatever reason the business date has not updated follow the below steps to get things back in order:

Step 1) Find out if any of the workstations have the correct business date. You can do this by pressing the E7 Info button on the POS screen. This is usually just an E7 icon. Once pressed you will get a little popup which gives some info and the first line will give the business date. If you find one or more workstations with the correct business date then proceed to Step 1a. If they are all on the wrong business date then proceed to Step 1b and if they are all on the wrong date but not all the same wrong date then move to Step 1c.

Step 1a) Ok so say we have the E7 PC on the correct date and all the workstations on the same wrong date. Easy fix but requires you to go to each workstation and perform the same task.
Process: Go to your workstation with the incorrect date. Sign in and go to the managers screen and select workstations.  You should now have a list of your workstations including your PC. Select the PC (or whatever workstation has the correct date) and on the right hand side you have an option to "Retrieve all Definitions". Select this and press ok. It will sync the definitions and update the business date. Sign out and press the E7 Info button on the sign in screen to confirm.
Repeat until all workstations are synced.

Step 2) If they are all on the wrong business date then you have not run your End of Day to update the business date. Sign into your system on the PC or workstations (doesnt matter which) and go to your touchscreen with the End of Day option. Select this and after a while it will do what it needs to do and update your business date.

Step 3) So your business dates are all over the place but none of them are correct. Find the workstation with the most recent business date and perform Step 1a above.
Once all your workstations have the same date perform Step 2 above.

All done.

9700 3.0 + - Info: Understanding Winstation and SarOps

In Micros 9700 Point of Sale above 3.0 there are two types of point of sale terminals that can be configured. Below 3.0 its all Winstation. There is nothing different in hardware its all software difference.

Overview:

Winstation: The winstation workstations setup requires constant network communication with the server. Each winstation configured has a dedicated process on the server called ops.exe which is responsible for facilitating the communication between the workstation and the database.

SarOps: This stands for Stand-Alone Resiliency. As the name suggests it has the ability to stand alone in the event of the server or network failure. There is a process on the server called Possrv.exe which manages multiple workstations.

Further Information:

Winstation: As mentioned above these workstations require constant communication with the server. If at any point the server or network fails then the pos system will be unusable. All workstations will revert to the default "Contrast up | Contrast Down" display and will show a communication error in a grey box in the middle of the display.

SarOps: If the server or network fails and you have a SarOps configuration then the workstations will advise you of the communications failure and enter offline mode. In offline mode you can process orders and take payments as usual. You will obviously not be able to perform tasks which require communication across the network but you can access the menu, print local orders and take payments. Once the server or network has been restored you can bring the workstations back online and it will upload the sales to the main database.

In theory the operations of Winstation's is much simpler and easier to configure but SarOps offers more stability.

RES 3700 - Error: XXXX number of checks have not been purged.

This is an error which indicates that old closed checks have not been purged from the database.
Two tables contain check details which need to be purged:
micros.chk_dtl and micros.trans_dtl

Micros 3700 is hard coded to keep check detail for 14 days. If the database fails to purge this data after 14 days it starts to give the "XXXX checks have not been purged" where XXXX is the number of check detail.

There is a stored procedure that should be in the End of Day/Night Audit steps called Purge History. This calls a stored procedure:
micros.sp_purgehistory();

Steps to resolve:

Step 1) Make sure the End of Day is being run at the end of your business date. If it is not being run then it wont be able to run the necessary stored procedure. As part of your end of day there should be a step configured which is a stored procedure called Purge Historical Totals.

Step 2) If the End of Day is being run then something is not working as it should.
Things to check:
a) Make sure you don't have loads of open checks from weeks ago on the system. If you do then close them off. After the end of day runs again it should purge the necessary data.
b) Make sure the purge step is part of the end of day.

Step 3) If still having problems open DBISQL. If you dont know what DBISQL is then click here for a quick tutorial on what it is. 

Run the following query:

Select min(business_date) from micros.trans_dtl

This will return to you a date. If the purge is running correctly this date should be no more than 14 days before the current business date. In your case it may be out by a few days or weeks depending on how long you have been seeing the error message. Make a note of this date.

Run the following in dbisql:
call micros.sp_purgehistory();

Depending on how many days out your purge is this can take from a few seconds up to 10-15 minutes. (Ive seen it take an hour on an old system where the purge didn't run for months.)

After the procedure completes in the result section of dbisql it will say Procedure Completed.

Now run this statement again:
Select min(business_date) from micros.trans_dtl

The date should have changed to a more recent date. Keep running the "call micros.sp_purgehistory();" procedure until the date is to 14 days from the current business date.

You should now find that the errors on your tills have gone.

If your still having problems then contact your micros support as there may be some issues with the micros.chk_dtl or micros.trans_dtl database tables.

Im not going to get into diagnosing these problems here yet. If you believe you have a strong grasp of SQL and are comfortable updating and deleting rows from the SQL database then drop me an email and ill tell you what to look for.


RES 3700 - Error: Waiting on MDSHosts.xml

When ops is starting on all versions of micros workstations it loads a number of different modules.
The essential ones are as follows for correct operation of the workstations.
MDSHosts.xml
MDSServices.xml
MDSPrinters.xml
Ops.exe

You may also find KDS Display loading depending on your setup.

You may find that the Application Loader will stall on any one of these, the most common being MDSHosts.xml.

MDSHosts.xml contains IP address and Hostname information for the server and all workstations so its essential for operation.
On WS4, WS4LX, WS5 model workstations its located on the compact flash drive in cf\micros\etc
On Win32 workstations its located in c:\micros\common\etc.
Same applies for all the .xml files above.

Workstations should be kept up to date automatically with these files and should be downloaded upon installing ops using CAL.

If you find the Application Loader stalling there are a few simple steps you need to take.

Quick Fix: Transfer a copy of the MDSHosts.xml to the workstation. It is located on the server under D:\micros\common\etc and needs to be copied to the workstation. See above for the correct directory.

Long Term Fix:

Step 1) Make sure the MDSHosts.xml has a good copy on the server. It should be located in D:\micros\common\etc
Check the last modified date. It should be fairly recent ie. a few days. Reload the database via the Micros Control Panel (reload not restart). If the modified date has not updated and the workstation still not starting then proceed to step 2.

Step 2) Force the database to create a new copy. Open services.msc and restart the following services:

Micros Distributed Services Manager
Micros DB Update Service

Step 3) Reload the database via the Micros Control Panel. ( reload not restart ). The last modified date of the file should have updated to the current date/time.


RES 3700 - Low Disk Space Common Causes.

From time to time it is possible that the micros drives can run out of space. Below i will list the usual suspects.

Database backups:

If your backing up the micros database on the server you should be running database validation. If the validation fails it will create a .bad extension backup in the "%Database Dir%\micros\database\data" directory where %Database Dir%  is the drive the database is stored on.

For reasons i dont know why if a .bad file is created the archived backups will no longer rotate and it will store backups in the "%Database Dir%\micros\database\data\archives" until the hard  drive runs out of space.

Solution: Delete the .bad file and delete any unnecessary backups in the archives directory.

-----------------------------------------------------------------

3700d.log Verbosity:

In the D:\Micros\Res\Pos\Etc directory there are 7 days worth of 3700d.log files.
If the verbosity is turned up high in the logs and left like that it can eat up disk space very quickly.
To change the verbosity open the Micros Control panel via the command line.

cpanel.exe /verbosity

The Micros Control Panel will now open with a verbosity tab where you can change the verbosity for the services and workstations between 0 and 10. Normal use should all be 0.
-------------------------------------------------------------------

Database Log File size:

All RES 3700 databases have a file called micros.log kept in the "%Database Dir%\micros\database\data" directory along with the micros.db which is the database.

The micros.log file is essential for the database to run but on occasion this file has been known to vastly increase in size into the gigabytes. Usually they are less than a few meg if not less than a meg.


Version 3.2 and below:
Step 1) Stop the database.
Step 2) Start -> Run and type in "scview" without the quotes and press ok.
Step 3) Select utilities and select "Change log file information". You may need to add the adaptive server anywhere plugin to get these options.

Step 4) Browse to the micros.db file and press next.
Step 5) Use all the default options here except the step where it asks you to create a mirror log file, here select "no change"
Step 6) Tick the box to delete the old log file information and press finish.
Step 7) Once you press finish you will be given a summary of your settings, just press ok to this.

Step 8) Open a command prompt and change the directory to the micros database directory which contains the micros.db file and execute the following command.

dbsrv6.exe micros.db -f

The SQL adaptive server anywhere program should have opened and now shrank down to the system tray. Double click on the icon and select shutdown.

Now start the database via the Micros Control Panel and shazam you should have a started database and a brand new small micros.log file.


Version 4.0 and above:

Thankfully much easier than 3.2 and much less frequently needed.

Step 1) Stop the database
Step 2) Delete the micros.log file
Step 3) Run the following command from the run prompt where D:\ is the drive of your database. You might notice something flash up for a split second but will most likely go unnoticed. (Capital F is important)

DM.exe -F D:\micros\database\data\micros.db

Step 4) Start the database via Micros Control Panel, you should now have a new micros.log file.


.

RES 3700 - Error: No communication with autosequence pc.

The service Autoseqserv.exe is responsible for managing scheduled autosequences as well as allowing autosequences such as end of shift reports,  to be executed from the pos operations.
If this service is frozen or simply not running you will get an error indicating that there was a failure communicating with the autosequence pc.
A lot of the time if the service is frozen you will simply have the pos operations hang for a few minutes before the error displays, if the service is not running you should get the error almost instantly.

RES 3.2 and below:
The autosequence service is located in the Micros Control Panel and can be turned on or off.

RES 4.0 and above
The autosequence service is located in windows services and is called "Micros Autosequence Service". If it is stopped start it, if it is started then restart it.

If you are unable to restart the service you will need to kill the executable via task manager or 3rd party program  such as pskill.exe which can be downloaded from microsoft.com.

RES 3700 - System Closed

.
System Closed is an error that you will get on the micros workstations when the system is set to "Back of House".

To resolve this open the Micros Control Panel. Start -> Programs -> Micros Applications -> Micros Control Panel.

Select Restaurant. On the right hand side you should have the option to press "Front of House" and then press ok.

All should be ok now.

9700 - Error: Printer System error / IP printer error

If you have IP network based printers tm-u220b M188B or similar which are setup on IPCC's then there is a process called ipcc.exe which is required for these to work.

Step 1) First we need to get to a micros prompt. In Version 3.00+ Type "micros" and press enter without the quotes. Go to step 2.
In versions less than 3.00 "Start -> Programs -> Micros Systems 9700 -> Nut Cracker". At the $ prompt type in "micros" and press enter. Go to step 2.

Step 2) At the micros prompt then type in "ps ipcc" without the quotes and press enter. If you are returned an ipcc process then this is not the problem. If you are not returned a process type in "reload" and press enter and then type "ps ipcc" and press enter. You should now be able to print.

RES 3700 - Licence is in Grace Period or has Expired

Micros RES requires a licence in order to operate.

If you dont have a licence you can put the product into Demo mode where it will operate with a reduced capacity.
To put it into demo mode "Start -> Programs -> Micros Applications -> Utilities -> Licence Manager" and enable DEMO.

If you have a licence but its still reporting as in grace period or has expired follow the below steps.

Step 1) Open the licence manager. See above. Make sure its not in demo mode.

Step 2) Open the Services list by typing services.msc into the run prompt. Restart the Micros Distributed Services Manager. If it fails to restart or freezes you will need to kill the process from the taskmanager. The service name is dsm.exe. Once killed start it from the services list.
Open the licence manager and press reload. If the licence now says "Key Present" you should be good to go.
NOTE: This problem is very frequent in 4.1 HF3. Look into upgrading if you have this version.

Step 3) If its still not working chances are the licence key is unplugged. It is a physical USB Key plugged into a USB port on the server. Very old micros versions will have a serial licence key plugged into the LPT1 port.

If you have a USB, reseat they key and Perform step 2. If you have a serial key reseat the key and reboot the server.

Step 4) If you cant find a USB licence key plugged into the server then contact your Micros Dealer. If you are part of a large chain you might have a MAL licence which is a software licence and you will need to contact your support.

RES 3700 - Error: No communication with Database server, Enter Stand Alone Mode

.

Stand Alone Mode - is a status where the tills can operate by themselves without any communication with the micros server. All checks will be stored on the workstation and any checks created on the other workstations will not be accessible from anywhere except the workstation it was created on.

A requirement for this to be successful in closing off checks and giving customer receipts is to have payment types designed for Stand alone mode.  These payment types are usually denoted by "O/L" before the payment type.OL = Off Line.

This is only a requirement if the Micros is integrated with a PMS system as to prevent the offline still attempting to communicate with the PMS system.

Troubleshooting

Step 1) Make sure the Micros server is turned on.

Step 2) Make sure the database is running. Open the Micros Control Panel "Start -> Programs -> Micros Applications -> Micros Control Panel". Select Restaurant and make sure that the system is set to "Front Of House".

Step 3) If the system is set to Front of House next thing to check is if the workstations are showing as green arrows in the control panel. If all the workstations are Red arrows then the problem is with the network communication between the server and the workstations.
If you dont see any workstations green or red then select View -> Show All Clients.
You should now be able to see whether they are Green or Red.

Step 4) Check the free diskspace on the database drive. If the drive has no space the system wont work.

Step 5) If all of the above is ok then your next step is to check the status of the MICROS MDS HTTP SERVICE.
Open services list by typing Services.msc into the run prompt. Scroll down to the Micros mds http service and make sure its started. After it is started reload the database via the control panel. This service is required for communication between the workstations and the database.

Step 6) If all above has failed then restarting the server couldnt hurt.

Step 7) Further investigation into the logs would be needed.

.

RES 3700 - Error: Timeout while sending message, check fo server, ifc or cables.

.

This error is received when Micros point of sale is interfaced with another application. Most common application that micros interfaces with would be the Opera Property Management System. This application is used for managing the Hotel side of things.

Below are a list of things that you need to check in order to resolve this issue.

Step 1) Make sure the Micros Interface service is running. This can be in two locations depending on the version of RES 3700 installed.

Version 3700 3.2 and below
In 3.2 and below the interface service is located in the Micros Control panel. Open the control panel "Start -> Programs -> Micros Applications -> Micros Control Panel" and make sure there is a green tick beside the interface service.

Version 4.0 and above
In 4.0 and above all micros services except the "SQL Database Service" were moved from the Micros Control Panel to the windows services list. This services list can be accessed by typing Services.msc into the run prompt. Make sure the "Micros Interface Service" is started.

Step 2) Make sure the interface is running. The interface is generally located on another server/pc which is not the Micros server. This program acts as the middle man between Micros and the end product for example Opera PMS.

Step 3) Once you have confirmed that Step 1 and Step 2 are ok the next thing is making sure there is network communication between Micros and the Interface pc. Im not going to get into COM connections and am only going to focus on TCPIP connections.

Open the "Pos Configurator -> Devices -> Interfaces"  and select the interface which you are having trouble with. Select the interface tab on the right and you will see an ip address and port number. Make a note of these.

Open a command prompt and type in "Ping x.x.x.x" where x.x.x.x is the ip address without the quotes and press enter. If you get a reply then the network connection is active.

Next is to test the port number. Open a command prompt and type "telnet x.x.x.x yyyy" where x.x.x.x is the ip address and yyyy is the port number and press enter. If the command prompt goes blank with the blinking cursor in the top left then everything is ok and working, if it does not connect then there is a problem with the port. Consult the supplier of the interface for more info.

Step 4) If step 3 is successful then the problem is going to be with the end product eg Opera or with the connection between the Interface pc and the Opera server.

9700 - Error: Check Detail Read Failed

.

The error "Check Detail Read Failed" while trying to open a check/table on the micros 9700 point of sale system. This error is present is all versions of 9700.


This error is an indication that the check has become unreadable in the database. It can occur if the check is being accessed during a power failure or some other interruption to the operation of the micros system.


These checks are unrecoverable and can only be closed in the database.

Due to the nature of the databases used in Micros 9700 SQL 2000,2005,Oracle 9i and 10g; there are many ways to execute the necessary commands. Im going to assume that you know how to execute an SQL statement and just give the command.
Replace XXXX with the micros check number.

update microsdb.checks set checkclose=checkopen where checknumber=XXXX and checkclose is null

This command will close off any checks which are open and have the number you entered.

If you want to be more exact or if there are more than one check open with the same check number then follow the below steps.

Execute command where XXXX is the check number:

Select * from microsdb.checks where checknumber =XXXX and checkclose is null;

Make a note of the CHECKID number and execute the following where XXXXX is the CHECKID:

Update microsdb.checks set checkclose=checkopen where checkid=XXXXX;

And your check is closed.

RES 3700 - Error : Check Detail Read Failed

 .

The error "Check Detail Read Failed" while trying to open a check/table on the micros RES 3700 point of sale system. This error is present is all versions of RES but occurs much less frequently since RES 4.0


This error is an indication that the check has become unreadable in the database. It can occur if the check is being accessed during a power failure or some other interruption to the operation of the micros system.


These checks are unrecoverable and can only be closed in the database.

To proceed you will need to know the check number which is currently causing the error.


Step 1) On the Micros POS server open DBISQL. To do this press Start -> Run -> Type "dbisql" without the quotes.


Step 2) Enter the username and password:

Username: custom

Password: custom

or

Username: installer

Password: installer



Step 3) Type the following command and replace XXXX with your check number and execute:

Select chk_seq, chk_num, chk_open from micros.chk_dtl where chk_num = XXXX;


chk_seq = Check Sequence number is a unique number

chk_num = Four digit check number used to identify a transaction.

chk_open = True or False. True means the check is open, False means its closed.


Step 4)  Make a note of the number in the chk_seq column and type in the following command and replace XXXXXX with the chk_seq number and execute:

call micros.sp_forcechkclose(XXXXXX);


The check should now be closed.

.
-->

Disclaimer

All information on this web site is correct to the best of my knowledge at the time of writing.
I will not be held responsible for any damage caused through information on this website.