Working on my loyalty/staff discount systems and run in to an issue that seems to be that updating calculation is kicking me out of order selected mode of menu item ‘autoselect’…
This is my update calculation rule.
Its in an execut automation command as had to ‘Background Delay’ the update as the report tags used dont seem to update/set quick enough on order added for ticket total changed to catch the new orders state values;
Its not the execute automation command thats causing as tried moving the update calculation directly to ticket total changed but still does it and then have the issue with the report exressions not including the state value in the total for the order added which changed the ticket total changed
Seems odd that it seems like ticket total changed happens before order is added?
Nothing to do with the perticular product didnt have a REGPriceList state as double checked after setting on.
Also double checked it wasnt something to do with the remove calculation by disabling (&& 1==2 on constraint) and no change.
This is a real snag as autoselect is used on many items especially food obviously and food discount was next option although that will be a % calculation.
So done mmore testing and its the ‘Reset Ticket’ options which seems to default to True.
Changing to false prevents the autoclose from beling closed however this then doesnt show the discount untill ticket is ‘reset’ which im not sure what exactly it is as the normal refresh ticket (display ticket 0) doesnt ‘reset’ the ticket but does close the autoselect option…
Interestingly selecting a portion does ‘reset’ the ticket and if I set reset in update calculation action to False it then doesnt show updated calculation on normal menu items (non autoselect) but selecting the portion on autoselect does ‘reset’ the ticket…
Not to be lazy but this discount system is going to have 6 discount types calculated in multiple ways ans its not going to be ideal if im going to have to duplicate the update calculations actions to only reset ticket is order isnt selected/autoselect…
@emre I know your busy with updates and whatever neptue is but is this behavior by design.
It would seem to me unless im missing something that updating a calculation from order added or ticket total updated would be fairly standard practice but to then need to ‘reset ticket’ in order to show the discount and in turn close an ‘autoselected’ product which is undoubtedly a major function in majority of systems seems to be impracticable from a userbility standpoint.
Thinking of other alternative ‘patch’ solutions im now thinking alternative migh be a 3rd line of automation flow to follow the update to reselect the last order based on a query to check if the last order is an ‘autoselect’ menu item however this seems like allot of addition fuss happening on every ticket total changed or order added event to countrer something which seems counter intuitive to me.
To be frank while im not doubting the reson I cant imagine why you would want to update calculation with this action but not show it on the ticket (other than to stop ‘autoselect’ from closing LOL) however it doesnt seem right to me.
I have no idea what is going on LOL, sorry, the Topic and description is too long for my feeble brain to read and understand at the moment (buried in JS QPOS ;))
Ok, think I have found a way to patch but defiantly adding unnecessary rules and still convinced this is a bug.
Having to use a third rule with second automation command event to define the command value as True or False which is put as the reset ticket field value based on if any orders are selected.
Has to be in its own ‘background’ triggered command as ticket total changed is happening before the autoselect is hapening so the background allows autoselect to happen and causes reset to false.
Its lucky closing a selected order triggers refresh else this would be a real pain.
It might be a bug… I mean getting knocked out of the Order Tag Screen by simply updating a Ticket Calculation should probably not happen.
That said, I know there have been complaints in the past about Updating Calculations that are not reflected on the Ticket unless a “Refresh” (Display Ticket with Id = 0) was subsequently fired.
So something that was probably changed somewhere in version updates is when using the Update Calculation Action is that it automatically refreshes the Ticket.
Unfortunately, that might be the reason for the closing of the Order Tag screen… I don’t know, but it kind of makes sense… in that case, yes, I would call it a bug.
It might be a bug… I mean getting knocked out of the Order Tag Screen by simply updating a Ticket Calculation should probably not happen.
That said, I know there have been complaints in the past about Updating Calculations that are not reflected on the Ticket unless a “Refresh” (Display Ticket with Id = 0) was subsequently fired.
So something that was probably changed somewhere in version updates is when using the Update Calculation Action is that it automatically refreshes the Ticket.
Unfortunately, that might be the reason for the closing of the Order Tag screen… I don’t know, but it kind of makes sense… in that case, yes, I would call it a bug.
Refresh ticket if I remember right didn’t update the displayed calculation amount.
The flow I setup above does seem to work but it is having to jump through several hoops to make the calculation correct.
First automation command executed rule needed to delay the flow untill the order has been added as ticket total changed triggers before the order is added/so quickly that order added status updates etc haven’t happened yet and also so the SELECTED ORDERS works as this also does not happen till after ticket total updated.
The seccond automation command action is needed to take the background delayed time to define/work out if order is selected using ORDER SELECTED ==/!= ‘’ to set command value as True/False to go into the update calculation command rule field for reset ticket.
Did it that way as will end up putting all the discount/promo calculations etc in this to save duplicating the update calculation actions over and over for reset or not.
Did try turnery expression in the field but that didn’t work lol.
but is this behavior by design.
