Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Micros 2700 SLU Priority 1

Status
Not open for further replies.

Narvin

Programmer
Jul 27, 2011
18
US
I read that you can assign SLU priorities on the 3700. For instance, say you have a food prep screen with a bunch of condiments/modifiers listed alphabetically, all with the same SLU. Now let's say that out of those condiments, you want all the cheeses listed together. In the 3700 you could assign the same SLU priority to the cheeses and they would be grouped together.

Can this be done in the 2700? I didn't see anything in the menu table in zoom mode that looked promising. I suppose if that's not possible, I just won't alphabetize the screen and then program the items in the menu table in the order I want them to appear, being sure to leave plenty of open spaces for future modifications.

Also, as an aside, the items on an SLU screen appear vertically centered, which doesn't look good if the screen isn't full (in my opinion). I'd like them to appear starting on the top line. Hunting down these options is exhausting. Does anyone know how I can achieve this behavior?
 
No SLU priority on the 2700. It's either alpha or sequential menu item #.

To change the vertical layout; go into the database, touchscreen styles and zoom on the Type Def. That's where you change that layout.
 
Thanks for the response TobeThor. The arrange by row option did the trick for the button arrangement.

It's good to have confirmation that there are no SLU priorities. I'll just have to go the sequential route, plan the location of item blocks in the table carefully and populate the blocks sparsely so that future edits that maintain the organization of the screens are as painless as possible.
 
I don't understand the benefits of grouping like condiments together (cheeses) on a non-forced misc condiment screen? In alpha mode, servers know exactly where to look for American, Cheddar, Swiss etc. I think grouping them together makes it even harder to find what you're looking for but I could be wrong. I undertsand the value on a forced prep screen. Meat temps for eg: Rare, med-rare, medium, med-well... I think that works fine. You seem about to do a lot of work for IMO very little benefit.

Consider; you could create a "sheel screen" for the misc preps that have all of the most popular condiments in locked locations so that the servers never have to page down to find what is "a very popular condiment". That would also allow you to program the temps in one row or column as well (R, MR, M, MW, W), the temps would always be in the same locations and all the other condiments would just sort by alpha in the locations where you have not defined buttons on the condiment "shell screen".
 
Well, I don't mind putting in the leg-work on this project because this is a training project where I'm trying to develop the best technique or set of techniques for programming the 2700.

I had thought of attaching permanent buttons to the shell screen, as you suggested, for the most popular modifications/preps like temperatures, sauce on the side, chopped, etc. But I ultimately decided against it because when you scroll, those buttons will still be there. Say for instance you use the top two rows for "sticky" items. You've now reduced the page size for dynamic items to only 4 rows, which will increase the need to scroll.

If, on the other hand, you had the most popular preps just appear first, when you scrolled, the next page would be populated with 6 rows of new items, decreasing the likelihood that you'd have to scroll again.

But I do agree with you that for the most part, alpha ordering is the best way to arrange the items. I just wanted to have the best of both worlds where the things you would most likely need, say temps or cheeses would appear first, so most of the time you wouldn't have to scroll, but when you did, the rest of the buttons would be in alpha order.

This is what I've come up with: "Tabs". I'll break the preps into categories, then have a single row of buttons across the top that link to each category.

So, as an example, let's say I had three categories: temps, condiments a-m, condiments n-z. Each category is associated with a different SLU. So each button kind of mimics the tab interface we see in modern browsers.

Now you can set the screen style to alpha sort the items so they can be programmed in any order in the menu table. But you can also quickly jump to different categories.

What do you think?
 
Each touchscreen has a max of 60 buttons if they are all small (1x1). If you used the top row for "sticky" condiments, you'd then have approx 50 condiments sorting on each screen (50 "not 54" is due to the fact that you need a couple functions keys (serv, print, prev etc.) That is typically enough condiment buttons; we never used more than 100 but every restaurant is different.

How many condiments do you have?
Are you using condiments pre-fixes to minimize the # of condiments needed?
 
this is a training project where I'm trying to develop the best technique or set of techniques for programming the 2700"

Curious why you are developing this considering the Micros 2700 POS hasn't been produced in several years and the software (V 5.03) in it hasn't changed since the early 90's. Just curious...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top