Order State Not Switching to Submitted -- Not Printing to Kitchen

V5 Question
#1

I just got a call from a beta tester that they didn’t get a ticket in the kitchen. I had this same issue at this same place 4-7 weeks ago but assumed there was somehow a kitchen printer ip conflict like at my other location and just changed the ip.

This time I realized there is another serious problem. Maybe with my rules but to me it doesn’t seem like it. I tried to recreate the issue but it works perfectly fine when I try it.

Waitress said she added the order, hit pay and settled the ticket without hitting close. The ticket did not print to the kitchen because the status somehow got stuck to new.

issue.png1912×1088 78.3 KB

#2

Is there a reason we changed this to question? The order is in “NEW” state with the ticket paid. We can clearly see that Order Type Ticket Tag is “Waiting” and that the ticket was closed. How is it that the order state was not changed? It could be something with my rule, but I personally dont see how that is possible since all conditions were clearly met. Somehow samba must of skipped the rule conditions as not met. I removed the Ticket Type Name condition completely since I also had it set in the mapped Ticket Type settings. Maybe that caused an issue? Do you guys think it is more practical to set a condition in the constraint section or in the mapped settings?

Sorry dont mean to make this too urgent but my client was very worried for not getting his kitchen ticket since it is causing issues with food not being ready for customers since receipt is not coming back. They really need me to make sure this does not happen again.

This beta tester has been running for 5 months and that has only happened 3 times total. In some very rare condition, it seems like samba is not reading the custom constraints as met is what is happening from my knowledge.

#3

You know it doesn’t work that way. You know better. SambaPOS does what you tell it to do. This is not an Issue. It is a configuration error, plain and simple. The Issue Category is reserved for Fatal Errors when something is actually broken in the Application. Heck, I was about to post a Issue for this Topic, but refrained from doing so, because it had never happened before today, but had to think there must be something that I screwed up. Read that Topic, and you will see the problem was caused by my mis-configuration.

Install a vanilla DB and knock your socks off. Run 10000 tests. This “issue” will never happen, because it does not happen unless there is automation configured to make it do so.

Maybe not that Rule. Maybe another Rule.

Open the Rule Debugger and look what happens. The Rule is not firing, or Actions are not firing, or something is stopping the State change, or is changing the State back to New. That’s the problem with messing with any default States or Rules.

It isn’t a matter of “practical” so much as it is about how you want the flow to go.

Remember, you cannot base an Action Constraint on a value that is updated or set in a previous Action in the same Rule. The Rule needs to be split into 2 or 3 Rules. This is the most common configuration error I have ever seen, hands down.

For example, you cannot use an Update Program Setting Action, and then subsequently constrain following Actions based on the Program Setting. IT DOES NOT WORK. You must fire an AMC passing the Program Setting as the Command Value, and in the Rule for the second AMC, constrain the Actions (or the Rule) using the value from the Program Setting in the first Rule.

If you can reliably reproduce the problem, then you can find the solution. Send the DB to @emre if you think it will help. I bet he will find a problem in configuration.

Put a Show Message Action in that Rule to confirm it is firing. Or put an Add line to text file Action to log it’s invocation and add the Date and Time, the Ticket Type, Ticket Id, Ticket Number, Ticket State(s), and Ticket Tag(s), if you don’t want to be bothered by popups.

Let’s look at your Rule…

Ticket Status says Paid. So your Update Ticket Status Action will not fire because it requires the Current Status of the Ticket to be New Orders. Problem #1.

Show the config for the Action Execute Waiting Kitchens Order Print Job - that action can change the Order State, causing the subsequent Update Order Status Action to not fire, if the Current Status of the Order becomes not New …

3 Likes
#4

Thank you. All your replies are very informative and I learn a ton from them. I greatly appreciate that. I apologize if I make statements that sometimes dont seem very logical but to be honest I still have ALOT to learn and im doing my very best. What made me ask Emre to review it was the fact that it only happens 1% of the time with 5 months in testing. It was a simple add order and pay transaction which is done 50 times a day with no issues. So I figured that something was causing samba to act different that 1% of the time. All I was looking for is somewhere to start with fixing this issue and you gave it to me.

I will closely follow all your instructions and try to debug whats doing on.

Thanks a lot as always!

1 Like
#5

Can you PM me a backup?

#6

I couldn’t find an obvious configuration error but I can recommend trying to change ticket type mapping of the rule to default (*). Let me know if it makes a difference.

1 Like
#7

Okay, for future purposes, so it’s better to leave mapping alone and just set the constraints in the rule for the ticket type. I always wondered if it’s better to do it through mapping or the rule constraints?

Honestly I really didnt make many changes on the database I just simply added those constraints but I’ll check it more with the info q gave me.

#8

That depends on the implementation. In rule constraints ticket type gets read from ticket itself. On mapping that gets read from active ticket type. Active ticket type can be changed via automation or while changing entity screens. So if active ticket type changes (for a reason) when you’re inside the ticket rules that mapped to active ticket type won’t trigger. This is just a guess. Let me know it it helps or not.

PS: I’m guessing rule didn’t trigger because the original issue was printing not triggered. As both printing action and the action that switches the state are under the same rule probably rule didn’t triggered at all.