Max number of open guest checks

[Kenyonl]

We have run into an issue with keeping tickets open. We run a large bar and we keep several hundred tickets open at any given time. All servers use the same login since we do tip pooling. Therefore, we have discovered an interesting and quite painful system limit that I am hoping someone can assist with. I recognize the operational questions that this whole scenario raises. However, our situation is quite unique.

The system only allows us to show 176 total open guest checks at any one time. The list is in alpha order so by 2pm we can only see up to the letter M. Since the server cannot find a ticket for Mr. Smith they open another ticket for him. It makes for a mess at the end of the evening. Does anyone know of a way to increase this limit?

 

[hosehead78]

Right, didn't think of it that way until you mentioned it. I have a Micros Lab, let me see if I can get it to show past 176 check numbers.

 

[hosehead78]

So I tried this on my Lab. I had no issues listing Checks past 176 checks. I went to a Total of 199 in the video below and can continue to add.
Closing these checks is what's going to be fun.

https://www.youtube.com/watch?v=9AizGH7VyVw

 

[PosGuyUS]

If Hosehead's fix, whatever that is doesn't work out, I think going with what he said above about splitting up the sections. I've seen a number of bars do that. For each section of the bar, they have a terminal/server that they use which helps them find the tabs faster. Let's say they do 4 users, each user is a section of the dining room. Set a pre-programed user sign in button for each section so they don't need to think about the user number. Then have the 4 user numbers all contribute to one pool if you do tip pooling or just do a combined cashout if Micros allows that.
I think based on the video, your problem is something in the SLU that used to display the open checks. Might be the style, mind you I haven't touched a 3700 but I used to know 8700 very well and 2700 like the back of my...that thing at the end of my arm.

 

[Kenyonl]

Well, that sure looks like it is working on your end. That's reassuring. That means something will let it work. I will test your check number field again tomorrow just to make sure I tested it correctly. Even if that's not the culprit I'm happy to see that it is possible!

 

[hosehead78]

I'm going through my settings to see if there are any other options that would allow this. I also have a few other outlets I can check as well. I will get back to you with any new info.

 

[pmegan]

How about having the servers sign in with their own numbers, so their checks sort to the top, and then using a common cashier linked to all of their workstations and basing the tip pool on that cashier report?

 

[Kenyonl]

Hosehead:
Your test sure looked valid to us. The only difference we could think of is that we are displaying names rather than check numbers. However, I can't think of any reason that would effect this. MICROS finally got back to us and we spoke with a programmer and he stated that the limit was likely hard coded in the system. Your test seems to disprove that. The plot thickens...
We had a programmer code a custom interface for the system in the past so we're going to have him take a look at it to see if he can figure it out. Offhand he couldn't think of what would be causing this either.

Moregelan:
Agreed. We discussed taking that approach with the programmer if we fail to find the cause.

pmegan and PosGuyUS:
I will discuss your suggested possibilities with our F&B managers and see if that's a possibility for them. Thank you for the suggestion!

 

[hosehead78]

Question out of curiosity, if this was previously programmed (ISL Script), what is the Button/Key pointing to (Script, Other Function)?

I usually have our Pickup Buttons pointing to a Function > Check Begin/Pickup > 439 - Pickup Check SLU.

 

[hosehead78]

By the way, Micros version is v3.60.486 MR 12.

 

[pmegan]

It's quite possible that Micros has a hard coded limit, or at least a hard coded limit calculation, to avoid filling up the client's memory. Divide the expected available memory minus some margin by the amount of memory required by each check line. It makes sense from a programming viewpoint; better than locking up the workstation.

 

[hosehead78]

@pmegan, True I didn't create very large itemed checks, 1 item at most. I can do a little more testing in that aspect.

 

[pmegan]

@hosehead, it's tough to replicate check volume issues in a lab. This is a SIM I wrote to simulate a problem I had last year with an expediter KDS screen freezing during peak periods. The restaurant is a beast in Rockefeller Center, (18 workstations, 14 KDS units & 8 IP printers), and for the couple of hours between noon and 2:00pm during the holidays they average 8-12 orders per minute hitting the screen with the problem.

Here's all you have to do to use it:
[ul]
[li]Change the EmpNum to a sign in ID active on your system. Make sure the employee you use doesn't have any prompts when starting a check.[/li]
[li]Change the Menu Item variables to items that exists in your database[/li]
[li]Change the "20" in "KSend = key(9,20)" to your Send tmed number.[/li]
[li]Edit the IdleSec variable to change the order frequency if you want.[/li]
[/ul]

It would be pretty easy to expand from 4 menu items per order to however many you want. I wrote it to hit a bunch of order devices so the items that are ordered rotate, but if you're just trying to create a bunch of large checks you can just do away with that and order the same bunch of items every time.

RetainGlobalVar

// Globals
var IdleSec		: N1 = 8	// time in seconds between firing
var EmpNum		: N5 = 2211	// employee # to sign in for transactions

var Count		: N1	// loop counter
var KSend		: KEY	// "Send" keystroke

// Menu Item numbers
var ChkTable	: N4 = 1997
var aChili	: N5 = 2001
var aWings	: N5 = 2002
var aSoup	: N5 = 7002
var eCaesar	: N5 = 103001
var eChxSand	: N5 = 600004
var eTacos	: N5 = 206016

// initialize the script variables
Event init	
	// Set the idle time
    @idle_seconds = IdleSec
    
    // initialize the count
    Count = 1
    
    // Create a Send keystroke
    KSend = key(9,20)
EndEvent


// fire an order
Event idle_no_trans

	// array of menu item keys
	var KMi[4]	: KEY
	
	// loop control
    If Count >= 5
        Count = 1
    Else
    	Count = Count + 1
    EndIf
    
    // create five different orders, depending on the loop #
    if Count = 1
    	// 2 apps, 1 entree, placeholder
		KMi[1] = key(3,ChkTable)
		KMi[2] = key(3,aChili)
		KMi[3] = key(3,eChxSand)
		KMi[4] = key(3,eTacos)    
    ElseIf Count = 2
    	// 4 apps
		KMi[1] = key(3,aChili)
		KMi[2] = key(3,aWings)22113
		KMi[3] = key(3,aChili)
		KMi[4] = key(3,aSoup)
    ElseIf Count = 3
    	// 1 app, 2 entrees, placeholder
		KMi[1] = key(3,ChkTable)
		KMi[2] = key(3,aWings)
		KMi[3] = key(3,eTacos)
		KMi[4] = key(3,eTacos)
    ElseIf Count = 4
    	// 4 entrees
		KMi[1] = key(3,eCaesar)
		KMi[2] = key(3,eChxSand)
		KMi[3] = key(3,eTacos)
		KMi[4] = key(3,eChxSand)
    ElseIf Count = 5
    	// 2 apps, 1 entree, placeholder
		KMi[1] = key(3,ChkTable)
		KMi[2] = key(3,eChxSand)
		KMi[3] = key(3,aSoup)
		KMi[4] = key(3,eTacos)
    EndIf

	// sign in, order 4 items and Send
    LoadKybdMacro MakeKeys(EmpNum), @KEY_ENTER, KMi[1], KMi[2], KMi[3], KMi[4], KSend

EndEvent

 

[hosehead78]

That's great, was creating a script for this, this will help as it is simpler than the one I started on. Thanks.
And Yea, I agree it is hard to trouble shoot these kind of issues in a Lab when it isn't hit hard like our live. Even when doing full training/testing.

 

[Kenyonl]

Our precise version is 3.60.453
The check pick up leads to the SLU screen for us. We then have style options to pick from.

 

[hosehead78]

Any update on this from Micros?

Also, silly question, but you do have a Page UP/Down button on the SLU Screen correct?

 

[Kenyonl]

Nothing new from them. We have a programmer coming in later in the month to go through it. We do indeed have a pg up / pg down. We can page down several pages until we hit 176 checks. Since we are displaying customer names on that screen and that is being fed from a custom interface I suspect there is custom code on that display call. Therefore, I hypothesize that there is an arbitrary limit in there that is holding us up. We shall see...

 

[hosehead78]

The Button that is calling the Check up, isn't pointing to a SIM script is it? It should be pointing to the Pickup Check SLU (that I mentioned above). Can you send shot the button in question?

Question, When your cashier/servers create a new check, do they give it a check name (i.e., Table number)?

 

[hosehead78]

* Correction, send a screen shot of the button in question.

 

[PosGuyUS]

Does Micros have a search by check name feature? In POSitouch, we can search for a tab by the name, say 'Jo' and every Joe and John will show up on the screen. A lot faster than scrolling through screens of open checks. Can also search with a CC swipe if a card was attached or scan a barcode on the bottom of a printed check of course if you printed the check, you'd have the check number.

 

[hosehead78]

@PosGuyUS, kind of, it is similar, it is Pickup by ID, Pickup by Number or Pickup by Table. Micros 9700 doesn't allow searching by CC number or any type of barcode (at least not by default, would have to be programmed).