Personally, I would not mess with the default Order or Ticket States. Both of the States are of the Order Group called Status. There should be no reason to alter their flow - by default they are set up in such a way so the POS operates properly in a standard manner.
Instead, create a new Order State and use it for your manipulation and state flow. Call it HoldStatus or similar, and create 2 States for Held and NotHeld or similar. Then set and test for the HoldStatus State value in your flows in your Rules.
So when it comes to Printing, or other actions, you can modify the affected Rules to look for this new State in addition to, or in replacement of, any States that currently constrain them.
You can have unlimited states. I wouldnât advise going too complex but I always start with a new state if I am implementing something new. This keeps it separate from other things and really makes debugging easier.
Perhaps, though I canât say for sure what would work best for you. If this is simply a matter of knowing which Orders to Print, then that makes sense. But if you have other possible uses of the HoldStatus State, it might be better to go that way.
You could use both ultimately - thatâs what makes SambaPOS so great⊠you get to design your flow as you see fit.
I use 3 different Order States and 2 Ticket States in my setup. One of each of those State Types are the default Status State, while the others are various States I added to affect supplemental behavior of Orders and Tickets.
Thanks for the advice, it is kitchen printing issues Im trying to ensure are consolidated as sure chef would get angry if he were to get two ordered for the same table some through on two tickets and them ment to be all part of the same order.
I think I got it solved.
I added a KPrint status and have chosen NotOrdered and Ordered and configured the actions to set as appropriate.
Void did throw a snag so had to add Kprint status updates in void and cancel void.
Even managed to work out so that it seems to work as expected
So if âlayed awayâ it doesnt print but becomes submitted meaning the defult close ticket rule is uneffected. the status is NOTORDERED on adding order.
Kitchen printing is set to only work is the ticket is not âon holdâ and in that rule ive set to change the status to ORDERED.
Voids I had to play with a little and ended up adding two KPRINT status updates to void and cancel void which change status as needed - if not ordered (still on a ticket thats on hold) to sets it to a third state on VOID ORDER so that a void doesnt go to the kitchen that a order hasnt already been printed. If it is ORDERED it will revert it to NOTORDERED so that the kitchen will get a void order print.
In cancel void is where I had to play around a little to get straight in my head.
If it is set to VOID ORDER (ie an ticket on hold where no order or void has been sent to kitchen it reverts to NOTORDERED so it will send when table set. If NOTORDERED it reverts back to ORDERED as kitchen already has the original order.
I think the bit which confused me with the cancel void was the action ordering as first time roung i had them in that order which then ment both actions happened if VOID ORDER as first changed it to the staus the second action was looking for,
After switching the order it then works fine as they dont clash with each other.
I donât think there are any other situations to need to worry about as situation was only to hold off the printing until ticket way finalised and taken off the user hold.
Cancel shouldnt matter as wont have gone anywhere if cancel is available.
Gift will be like any other order.
⊠Refund I forgot, have made that to set Kprint to REFUND, as kitchen wouldnt need to know in same way as void - would already have been paid to need refund (would probably cause argument - âWhy did you refund that?â - sure you know what most chefs are likeâŠ
