Micros POS Tools - Blog

SIM Scripts in Simphony

Tue, 11 Aug 2020 14:29:07 GMT

If you are familiar with SIM Scripts (ISL Scripts) in the Oracle Micros Point of Sale product range then you will surely understand the pain of trying to do any complex work.

In Simphony versions 2 and above there have been some major enhancements to how SIM scripts can be written. We can now directly interact with .NET class libraries. This gives us the ability to move our complex logic into external libraries, create rich and fully featured user interfaces, interface to 3rd party applications and API's.

How does this work I hear you ask. Read on and ill show an example.

Simple C# Class Library Code

We shall compile the below code into a library called SimTestExample.dll

using System.Collections.Generic;

namespace SimTestExample
{
public class DoWork
{
public int Value { get; set; }

public DoWork(int value)
{
Value = value;
}

public List DoSomeTask()
{
// You can do whatever you need here and return a result to SIM

var ResultList = new List();

ResultList.Add(new DataModel() { Name = "jim", Value = 100.00m });
ResultList.Add(new DataModel() { Name = "mark", Value = 200.00m });

return ResultList;
}
}

public class DataModel
{
public string Name { get; set; }

public decimal Value { get; set; }
}
}

SIM script to use the SimTestExample.dll

The below script is a very simple example of how to call a .NET DLL from a SIM script.
// multiple namespaces can be imported by separating them with a comma
NetImport SimTestExample from "C:\MyLibrary\SimTestExample.dll"

Event Inq : 1

var Worker : object
var ResultList : object

Worker = new DoWork(1)
infomessage Worker.Value // This will display a message box with a value of 1.

ResultList = Worker.DoSomeTask() // ResultList will be populated with the List from our library.
infomessage ResultList[1].Name // This will display a message box with a value of mark.

EndEvent

E7 - Error: Current Business Date is Incorrect

Thu, 28 Jun 2012 20:40:01 GMT

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

Thu, 28 Jun 2012 20:39:01 GMT

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.

Thu, 28 Jun 2012 20:37:50 GMT

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, micros.trans_dtl and micros.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

Thu, 28 Jun 2012 20:34:32 GMT

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 ManagerMicros 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.

Thu, 28 Jun 2012 20:32:30 GMT

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.

Thu, 28 Jun 2012 20:29:20 GMT

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

Thu, 28 Jun 2012 20:28:25 GMT

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

Thu, 28 Jun 2012 20:27:34 GMT

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. 0 comments

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

Thu, 28 Jun 2012 20:26:45 GMT

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.