I have a customer, and he sit on table 5 and ordered a Salad, but when I open the POS, I open table 3 and add the salad, I didn’t close yet, so I noticed my fault, then I cancelled the Salad and closed the table and moved to the right table 5
I want a feature or something to add, that when I cancel an order, it shows an input box for the reason of the cancellation, and it writes it in a log file, so I can check who cancelled which order and why, because It will be only Admins will be able to do that action.
Sorry but if I read that right your example is not required as you would just need to press select table again and choose table 5, and it would change the table number
As for recording cancels I don’t understand the need. You have void and cancel options, void is for an order already submitted and '“logged” which would include say printing to kitchen, void will not remove the entry but make it void tell the kitchen it’s been voided etc.
Cancel is built as an error correction option. Which is common practice on most pos system.
The reasons would never be very detailed - human error, human error, pressed wrong button/typo.
Are your sure your not looking for a void reason? That would make more sense as it’s already been submitted - sent to kitchen and understand that there would be more interest as to why it was voided? Also likely to have allot less voids that cancels to sift through
Excuse my ignorance on this one.
What would be the output from that? A long list of reasons (do date/time/ticketid)?
Could you put [:Ticket Id] - [?Reason for cancel]? or does it automatically time stamp it?
It would ask him to type a reason and it will simply put what he typed in the txt file. [?xx] brings up a dialog to input a custom value for the parameter. If you type [?Enter Reason] It will bring up a keyboard with caption Enter Reason and you can type whatever reason you want. What you type is then made the value.
It is a good way to create a dynamic value for an action instead of just inserting a static value.
Now you will get this, when you enter “oops” as the reason…
Keep in mind, the Ticket Id will only contain a value if the Ticket has already been created. If you simply add a product to a brand new ticket, and then immediately cancel it, the Ticket does not yet officially exist, so the the Ticket Id will be blank. This would not pose an issue with something like Void, since the Order has already been submitted, meaning the Ticket has been created as well.
Here is the output when I Order, then immediately Cancel … notice the Ticket ID is missing …
The significance of if the tickets created or not is simple when you think about it. When a ticket is actually created that means everything is written into the database. So once its written into the database then you have to decide what to do with it. When it is not written into the database there is no reason to log something that does not exist.
The only reason I could think of is to track staff mistakes.
Maybe add a product name to the log and see if there is a product that is done by mistake more often.
To tell me that maybe the buttons on the menu page are too small.
But as you say cant see accounting need.
Unless you suspect your staff are not ringing in items and canceling them. Only situation that would work would be adding all products giving them the bill then taking the last couple of items added on in that session/order off and pocketing the money.
Obviously wouldn’t work once the ticket is closed as they become submitted and require a void.
Most systems i’ve used have two levels of ‘void’ proper void and ‘error correct’ (cancel).
Cancel lightens the use of void allowing staff to correct their own mistakes like ‘typos’ without hassling management.
Could be useful as analitics tool - seeing is a particular menu page has bad layout causing excessive mistakes.
LOL hmmmm, it kinda is i think… maybe mistake is wrong work but they have added wrong product.
But as all have said there is little reason to log cancels, only one I can imagine is seeing if products on a particular page are excessively entered incorrectly - probably more useful to a larger corporate environment where admin is not actually using till POS on regular basis.
Its not added yet is my point. It really doesn’t matter how many times they add or take off before its submitted. What matters is whats submitted. Thats the point I am making. Its different in Retail POS when there is no submitted state.
I would be careful of how you use it though. If its just for your knowing then thats one thing but if you police your staff too much over something that is not really impacting business that could cause a negative effect. It also adds another step for something that should just be a quick fix.
I wouldn’t restrict cancel to admin. I could see void being admin but not cancel. People will make mistakes and nothing is submitted yet so requiring an admin at this point makes the customer suffer a wait. That’s not good.
@kendash I wholly agree with all you points there.
Would lower staff moral also if you pester them for making ‘typos’ which they should be capable of fixing themselves. and by not allowing them to do something so simple is almost saying they are incapable and untrusted to very low level.
What would have made more sense is if @ab0udamd elaborated with a reason he feels the need and perhaps a better proactive solution could be suggested. What are you trying to prevent/worried about?