V3: Internal debug system to investigate states and their workflow

Hi everybody, I am newbie here. Recently I was in need of a good, decent and feature-complete freeware POS system, so I researched what’s available, quickly enough I came across this very interesting software, investigated it a little before concluding that it is an outstanding, truly best-in-class solution that fully meets my needs, so right now I am playing with it (V3 - because I need it in French), to learn how it functions, to be able to customize it freely.

States workflow is until now the most difficult part to master. I was changing some values, to make it work differently, now the workflow appears to be broken, as I don’t know what I did anymore and now I feel I am unable to tune it to my needs - too complex to understand and too complex to track state changes during runtime.

It actually makes me think about C and its pointer-to-pointer topic :slight_smile: except that pointers are easier than SambaPOS states system, and they are way better documented too.

Is there some internal debugging system for that? So that entities, current ticket and current order’ states could all be seen during runtime, and their changes could also be seen? So that errors in workflow could quickly be figured out. That would be soooo nice… Currently I try to simulate states behaviour on paper, like what is actually going on when I do this, when I do that… though without success, I am still lost - too much things in play and they appear to be evenly distributed across plenty of different configuration windows, so it makes it extremely difficult to manage and even to understand what is clearly what.

I’ve read already States tutorials, but they are far from being complete, they explain only basic things. Any help would be greatly appreciated. And thanks for the outstanding software anyway - you are clearly beyond the competition.

1 Like

would also be very useful for V4. It would make customization easier as there’s no reference documentation yet. We could go by trial an error instead.


Currently I solved this problem like that:

I just written out to paper all the options that I played with, then I moved away my db.sdf to another location (as happily I’ve chosen SQL CE), so it reverted to defaults, then I was able to compare and to see the differences.

So it works for now, I just carefully applied some small hacks to the defaults, so that it is ok, at least it functions. So for the moment I am happy with it, even if I still don’t fully understand the whole states workflow :smiley:

Hello @niceguy thank you very much for the suggestions. What you’ve requested sounds great however it might take a while until we find enough free time to implement that.

I generally use Show Message action to ensure I can capture correct state change event.

I agree our documentation is not complete but I believe state tracking is not hard to understand as it seems. As new feedbacks comes I can update state documentation to cover more topics or give better examples.

Let me give an example…

States works like traffic lights. It can be red, yellow or green. There are two things you can do with states.

  1. You can handle the moment it changes from red to yellow or yellow to green with Ticket State Updated rule and execute specific actions to handle that change.
  2. You can display specific buttons for specific states. For example you can display “double horn” button when “state” is “red”

So you can create a new state called Delivery Status and have it two states such as Waiting and Delivered. You can:

  1. Display Deliver button when Delivery Status is Waiting.
  2. When Deliver button clicked you can change ticket state to Delivered.
  3. When Delivery Status changes from Waiting to Delivered you can execute an action that sends e-mail or sms message to customer.

If you ask the point you don’t understand I can try to give more specific example. We can talk about it under What does State mean? topic .