So I know this topic of discussion came up a number of times before.
I also recently came across this issue when a client of ours started noticing “tickets were not saving” “Regardless of what order item you put, it would still print the lot”
Without searching the forum(Which I probably should’ve before hand) I started digging and found the culprit to be the exact same as the first link(above)…
Print job action not pointing to a valid Print Job…
(Amongst other issues as well)
I was also able to reproduce this in a test environment… (See Below).
Print Jobs
Print Job Action
Ticket Closing Rule
By deliberately changing the print job action name to a non existing print job…
You get the message below as soon as you put an item and press the “Close” button
Change the name to point it to a correct print job name that exists in Print Job tab… And it all works fine…
My concern here is 2 things…
-
The fact that it fails to execute to the next action in the rule (Which in this case was Update Ticket Status and Update Order Status(Which are needed to execute in order for ticket to correctly update the status of order and ticket))… This in return causes a break in the system which unless you come here and search for this issue… You would not know where to even start looking!
-
The message you get does not point you in any direction at all other than telling you that ticket changed and that’s it…
It isn’t until you open the rule debugger and go through the step of opening a ticket and closing it and notice that the next actions after a Print job action within the “ticket Closing” rule is not firing…
The order and ticket status actions did not get updated which caused the system to go into somewhat of a limbo.
Now firstly…
I suspect that the fact it is not firing the next action in a rule due to a broken action parameter is by design… (Possibly for good reason)
If it isn’t by design however… This should really be treated as a bug…
Secondly… If this is by design…
Then we really need to have a look at improving the message you receive when you come across this issue…
There could be possibly other causes that could give you the exact same message… And unless you are familiar with the software (Most restaurant owners are not, unless they had lots of time on their hands and learnt the ins and out of SambaPOS) this can cause quite a bit of drama.
Now while most if not all resellers are quite knowledgeable about SambaPOS and the client can come straight to you, and you( like I have done) can hop on their system, help them out, or they can reach out to SambaPOS to help directly.
Unless you have come across this issue before, and if you have not, you know to search the forum to try and see if someone else has reported this issue… You could quite easily fix this for the customer… But if you have never dealt with this before, and suppose the issue was not the print job but something else causing it… Then it takes quite a bit of time to troubleshoot and fix…
In a busy shop, time is of the essence if they rely completely on SambaPOS… As such, issues like this one… We really need to look at a method to improve the message that it pops up with, so that it can be a bit easier and faster to diagnose.
In my client’s case, they had to revert back to writing on dockets again causing lots of downtime and money loss until we rectified the issue for them… (It took about 1-2hrs to diagnose without having to look at the forum initially and never seeing this issue before)…
I had to run the rule debugger in order to get a hint on where to start looking. It wasn’t until I actually removed all print job actions and inserted each one back in until I discovered that it was a print job action which was causing the break. At this point I looked at the action and finally looked at the Print jobs to discover that the Print Job doesn’t exist… I created the appropriate print job, and tested it again and it worked…
Before this, I looked at all status update action parameters, compared all the print job actions and looked at any other rule that may have been created which could cause the ticket/order status to change before ticket actually closed…
All in all, I personally think we need to somehow look into better message outputs when stuff like this happens, or fix this bug(if it the Execute action is meant to look at firing the rest of the actions even if a parameter of one isn’t a good one (Maybe specific to print jobs)) Lets fix it somehow…
Personally I think, Important things in an out of the box experience such as Ticket and Order state changes should either be locked down and if a user goes to change it, they should receive a warning before been allowed to do so, at least so it implies that what they are about to change, may change the system behaviour) so a non educated user doesn’t simply go to change these settings…
Additionally changing the popup message to show what changed/didnt change would help… Or an additional debug popup should appear to show which/rule action it failed to execute . would drastically improve troubleshooting and diagnosing. (Open to ideas on this one)