Tutorial: Log/Count Orders that Require Entity (Table/Customter) Selection before Close/Settle using Constraints for use with Kitchen Prinr/Orders [JTRTech]

[JTRTech]

So after playing with a few methods of forcing table selection I have settle for my favourite and wanted to share.
Had a go with using states and other methods but this is what I will be using from now on.

This setup will give you a way to specify products which require a table or customer to be selected.
While this would be required for default setup in order to close a ticket, I am a fan or the switch user config and although this setup would still require further development to work well with switch user (to delay kitchen printing until ticket is ready rather than when the ticket is closed and ‘held’ against user name it should work well if you want to require table selection for certain products when there is the option to settle the bill at time of order.

So…
Firstly after being shown the custom product/item tag ability my setup will use a item tag of Requires Table.
To do this first we need a Product Tag Caption which can be found in Manage --> Settings --> Program Settings --> General Settings

This will then give a new field in the Product Settings new column in the Product Tag Editor

In my setup I have opted to set Yes for products which require a entity to be selected before the order is submitted - See the Meal product settings.

Next lets make some Update Program Setting Actions, I have opted to make three seperate actions however this could use a generic action using the [:xxxx] to create dynamic instances of a single action.

You will need 3 actions if making them separately;

• One to increase the count
• One to decrease the count
• One to reset the count on ticket close/submit

I have also opted to use ‘non-local’ program setting as I like to use SQL manager to check my config is updating the program settings as expected and the use of {:CURRENTTERMINAL} in the setting name will keep the log for multiple terminals separate.

Now using these actions we make some rules to update the program setting;
Firstly we want two rules to increase and decrease the Table Required orders.
Tracking them like this means that is an order is added by mistake and then cancelled the requirement for a table will be removed.

Using {QUANTITY} for the Increase and Decrease values it will also take into account multiple quantity order additions/cancels.

Notice the constraint which checks if the order added have an {ITEM TAG:Table Required} value of Yes

So so far we have a program setting which will add and subtract a value for the number of orders on the ticket which require a table/customer to be selected.

Before setting the rules/constraints which will prevent ticket settle/close without table/customer selected if and new orders required one we should add an action to reset the count on the Ticket Closing rule.
I have added the Update Program Setting - Table Required Order Reset action to the Ticket Closing Rule just after the Execute Kitchen Orders Print Job action so that after any new orders are sent to the kitchen the count will be reset to 0 ready for the next ticket.

Now that the count for the require table orders is setup we can constrain the Settle and Close Ticket automation command rules.

I have done this in my setup by adding a constraint the default Rule action for Display Payment Screen and Close Ticket.

My constraint is;

'{SETTING:{:CURRENTTERMINAL}_NEWTRO}' == '0' || ('{ENTITY NAME:Tables}' != '' || '{ENTITY NAME:Customers}' != '')

This will check if the Table Required Order setting is not 0 (if it is, will fire) OR is a Table or Customer is already selected.

I also added an Ask Question action to notify the user that they cannot settle/close the ticket as a table or customer is required.
My constraint on this action is;

'{SETTING:{:CURRENTTERMINAL}_NEWTRO}' != '0' && ('{ENTITY NAME:Tables}' == '' && '{ENTITY NAME:Customers}' == '')

Which is pretty much the reverse of the other constraint, the message will show if the count setting is not 0 and netiher a table and customer has been selected;

These options should prevent a ticket from being submitted, either by settle or close ticket without an entity for table or customer if there are any orders which have an item tag for Table Required setting of Yes resulting in an ask question message of;

[emre]

You can use {ITEM TAG TOTAL:Table Required} tag (anywhere) to read total amount for orders that needs table selection. So if that amount > 0 you can assume ticket contains a meal like order and operator needs to select a table.

PS: {ITEM TAG TOTAL} will not include gifts or voids. If needed you can also use {ITEM TAG PLAIN TOTAL} tag to include them.

PS2: I should mention that technique first invented by @JohnS and we generally use Ticket’s {XX TOTAL} tags to determine existence of orders that has specific state, item tag or order tag.

[JTRTech]

That does sound allot easer, kinda wish I had see that before writing all that but oh well

My origionally thought was I needed to know New Orders.that required a table number but looking back for table selection required it wouldn’t matter unless for whatever reason you had to remove the table entity.
Maybe if they moved to the bar after food and someone else went on that table?

Also new order which is kitchen order would come in handy as am a fan of having a confirmation on close or settle that doing so will send new orders to the kitchen but obviously that would only be wanted if there were new kitchen orders not drinks etc.

Trying to visualise it but can’t work it out in my head but a formula type constraint on the action with ITEM TAG TOTAL:Table Required (for if kitchen order) && Order State Total is New > 0 would you give you a higher number I think as would count all new order rather than look for new orders that are table required…?
Does that make sence?

[emre]

Maybe using order states will be a better idea for your case. While adding order you can mark orders as table required and clear that state while successfully closing ticket to differ them from new lines. In this case you can use {ORDER STATE TOTAL:X} or {ORDER STATE QUANTITY TOTAL:X} tags to determine existence of such order lines.

[JTRTech]

Sounds ideal, will have a go that way.

The check if an entity is selected? Is there a simpler tag that can be used? Ie something to check if any entity is selected rather than Tables || Customers

[JTRTech]

@emre

Maybe using order states will be a better idea for your case. While adding order you can mark orders as table required and clear that state while successfully closing ticket to differ them from new lines. In this case you can use {ORDER STATE TOTAL:X} or {ORDER STATE QUANTITY TOTAL:X} tags to determine existence of such order lines.

Almost done with this alternative table required constraint, looks like its ideal