• Oracle Micros Point of Sale
  • Tools
    • QR Code Printing
    • ISLCrypt & ISLDecrypt
  • Blog
  • Contact
Micros POS Tools

9700 3.0 + - Info: Understanding Winstation and SarOps

6/28/2012

2 Comments

 
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.
2 Comments

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

6/28/2012

22 Comments

 
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.
22 Comments

9700 - Error: Printer System error / IP printer error

6/28/2012

0 Comments

 
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
0 Comments

9700 - Error: Check Detail Read Failed

6/28/2012

0 Comments

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

    Author

    Developer and Blogger about Micros POS Products.

    Archives

    August 2020
    June 2012

    Categories

    All
    3700
    9700
    E7
    Simphony

    RSS Feed

Powered by Create your own unique website with customizable templates.