Micros SIM - How do you add a menu item to the check in a SIM script using LoadkybdMacro

Look at the help for the Key function, in particular there is a link at the bottom: "Click here to view key names and key codes"
From there you can see a list of Key Types, which should be helpful.

Each Key has a Type and a number that depends on the type. So for a Menu key type (3), the number would be the object number of the menu item. To add a Discount, you'd use key type (5).

All of the examples under LoadKybdMacro use function keys (key type = 1), but you can apply other key types in a macro:

That worked. I just didn't realize that I needed the @KEY_ENTER. Not clear in the Micros manuals. Thank you so much, I've been trying to figure this out for 3 days. Your advice helped me solve this issue in 10 minutes. Thanks again.

You're welcome. When you're constructing macros like this it can be helpful to think of everything you'd have to do if you were physically at the terminal. It will also depend on how you have the keys programmed. If your menu items require a reference, you'll have to provide one or the script will bork.

So the next step is to capture when the server attempts to delete the menu item off the check. I wrote the following test script to see if I could capture the VOID keypress. When I highlighed the menu item and pressed VOID, my test script did not fire. I'm using 3700POS, Res4.9. The 3700SIMComp_Man.pdf does not mention mi_void event. I just saw this in a 9700 SIM manual and hoped it would work for the 3700. Do you know the equivalent 3700 event names for capturing menu item voids and cancel check? the 3700 manual is very light on that information.

event mi_void : confirm
var text : a20 = "mi_void event works!"

// Use following 3 lines to confirm this event is getting called
window 2, 40
display 1, 2, text
waitforclear
endevent

Look at the help file: \Micros\Res\Pos\bin\Simhelp.hlp
This is different than the PDF manual and documents...well, not everything. I don't know if Micros bothers to update it anymore, but the Events are documented in there. You're looking for mi_void_items. You'll then probably want to loop through all of the detail items and test them using @Dtl_is_void to find which item was voided.

One little trick...go to the Find tab in the help file and click "Rebuild", then choose "Maximize search capabilities". This will include some extra information when you search the help file. It will also introduce a lot of extra noise, so you may opt to rebuild with the "Minimize" option if it's too much of a mess for you. The reason I suggest doing this is that there are some handy tidbits you can find digging through the help that aren't really accessible through the basic search.

Thanks for the tip on SimHelp.hlp. It's very helpful and I've been experimenting with many of the commands to understand the check.
I didn't find any reference to mi_void_items for the 3700 SimHelp.hlp file. I tried mi_void and mi_void_item(s) in a script with no luck. I did find dtl_changed which does work. What I wanted to do was capture the specific occurance of the item when it gets voided. I don't want the historical record of the same item if it was added and deleted many times on the check.
Do you know if a check uniquely identifies each line item on the check? For example, if I add 2 identical coupons to a check but coupon 1 is discounting a Hamburger and coupon 2 is discounting a Cheeseburger, and I want to delete the Hamburger coupon, how do I know which coupon is tied to the Hamburger? Both coupons have the same objnum value so when I loop through the @dtl records I can't distinquish between the 2 coupons. They both look the same.

There should be an events listing. Look for "Event...End Events" in the index. What version of RES are you on?
You may also be interested in using the Dsc_Void event which fires after a discount has been voided from the check.

Yes, each detail item on a check is unique. @DTL_SEQUENCE may be helpful.

You can loop through the detail items and check the status bits (see @DTL_STATUS). From this you can determine the state of the item in the detail, which may help you narrow in on your item of interest.


@DTL_TYPEDEF can also be useful if you want to differentiate between detail items based on how an item was configured. You use the same bit logic to pull info out of @DTL_TYPEDEF to view the flags set in configurator. Unfortunately there isn't a straightforward reference, but you can look at the definition tables in the database to figure it out. Menu item type definitions can be found in mi_type_class_def. The bits correspond with the ob_mi## fields. So ob_mi01_preset means that you can check for the preset flag on a menu item detail by checking to see if bit 1 in @DTL_TYPEDEF is set for that menu item.

Discounts and Service Charge typedef flags can be found in the dscv_def table: ob_dsc##..., ob_svc##..., ob_dsvc##...

This code hasn't been tested, but the general idea should be apparent: