I am having some difficulty changing Ticket types and getting some inconsistent results.
I have been running the system for a while using a single ticket type however this is creating some reporting issues for the following reasons.
I have a customer entity called ‘Owners’ which is for the owners of the Hotel to order food and beverages. Currently I apply a 100% discount to these tickets on selection of this entity and this allows kitchen and Bar orders to be printed. When the ticket is closed the Bill Value is zero and therefore this ticket disappears and does not require bill printing or Settle actions. This ticket has created a concurrent ticket number and thus leaves a reasonable number of zero value tickets on the system.
I have created a new ticket type called Owner Ticket which has its own Ticket Number Generator and is prefixed OWN-###.
I have created an Automation Command to select Owners which then then Changes the Ticket Type to Owners Ticket.
I am using the Set Active Ticket Type action and the flow is is follows
Waiter Selects Entity (Table or Customer or Room Entity) which creates ticket (Should be type Ticket)
Waiter selects Owners from Button executing an Automation Command called Change Ticket Type to Owners
I then run a rule to detect the above Automation Command called Set Ticket Type for Owners
Symptoms are as follows
Current Ticket Type is not changed
If I close the Ticket through the POS screen and start a new ticket then the process will work.However the subsequent ticket produced by the system also creates an Owner Ticket (sometimes)
I realise this is likely a cache issue and some system variable setting Ticket Type is not changed until a ticket is closed and opened. I thought the solution would be adding Close ticket and Create Ticket in the Rule but this stops the ticket type change event completely.
I thought this would be a simple way to change the Ticket Type but clearly I am messing with the Ticket creation flow in some significant way.
Am I using the wrong action to change Ticket Type? Or maybe fundementally I am approaching zero priced orders for Hotel Owners in the wrong way.
I am trying to use the Change Ticket Properties action to change the ticket type, but the update is not reflected straight away, for example, the following does not change…
The menu in use
The entity selection options
Command buttons which are ticket type specific
Payment methods which are ticket type specific
I have tried refreshing the ticket using Display Ticket with 0 as the TicketID, but it does not solve the problem.
The only solution I have found so far is to…
use a rule to close the ticket
catch the TicketId in a Ticket Closing rule (save this ID as a local program setting)
execute an automation command to open a ticket (read the ID from settings to re-open the ticket we just closed).
As you can see this is a bit of a messy way to just refresh a ticket view. Are there any other options available?
Very strange. I use the Change Ticket Properties Action to change the Ticket Type to Staff Ticket when an Employee is assigned to the Ticket. That way, the Ticket/Orders are not reported in regular Sales.
I have to load a different DB to show that it works. I’ll get back to you in a few…
No - Only one department, but using different ticket types to justify the different transaction types attached to each different ticket type.
It’s strange, if you change a state and refresh the ticket the buttons change, but changing the ticket tpye and refreshing does not have the same effect
I am doing a bunch of things to make sure Ticket Type and Menu change. This setup is based on Entity Custom Data Field named Staff Level. Regular Customers have 0 for this field, while Employees have a non-zero value.
So the Menu and Ticket Type are changing fine.
But…
Entity Select buttons are not always updating properly - it depends on when/what is selected first.
if I select an Entity that already has a Ticket of type “STAFF”, then a new Ticket is created instead of opening the existing Ticket.
Entity Q/Wy is STAFF (has a Staff Level > 0) and most other Entities are not Staff Level = 0).
The STAFF Ticket Type only has Customer Entities. No Tables, no Gift Certificates.
Regular Ticket Type has Customer, Table and Gift Certificates.
The STAFF Menu is limited - less Categories.
selecting STAFF Entity does NOT limit the Entity Selectors, but it DOES change the Menu.
selecting NON-Staff has the correct Entity Selectors, and Menu, and if you then CHANGE the Entity to a STAFF Entity, the Entity Selectors and Menu are both limited and changed properly.
notice Q/Wy already has a Ticket, but selecting that Entity does not load the existing Ticket; instead it creates a NEW Ticket. To get to the existing Ticket, I need to use Ticket List or Ticket Lister.
if I use Ticket List/Lister to load the Ticket, the Menu does NOT change properly, but the Entity Selectors DO change. Kind of the opposite of the first point.
Interestingly, I also have different Payment Methods depending on the type of ticket used, but I have found that if the ticket type changes the payment methods DO NOT change, even when I switch screens to the Settle screen.
@emre - Q and I are both finding the same issue with the ticket not refreshing when the ticket type is changed. Is there something you can do to help us out?
I know you have been away for a while (hope everything is OK?)
Not sure if you missed this topic - Any chance you could look at completely refreshing the ticket screen when the ticket type is changed (menu, automation command buttons and payment methods)?
@emre wonder if you can comment on this, as I’m also having this issue (payment buttons mapped to a specific ticket type not showing when ticket type is changed by Change Ticket Properties or Set Active Ticket Type actions).
I saw some tutorials, for example RickH’s one on Wastage Rick's Tutorial 11 - Wastage/Damaged Stock that appear to have previously worked when changing ticket type. Is it possible this has become broken in v5.2.2 / v5.2.3 or even an earlier version?
At what point are you changing it? Typically in the past we had to close the ticket and reopen it before we could see the change. In the tutorial you listed he never used a payment button on the settle screen. He used automation and the Pay Ticket action. He created the payment type only to use the Pay Ticket action.
I have done some stuff with changing ticket types and I can tell you almost certainly I had to close and reopen the ticket before the change was visible.
In fact one time I did some elaborate workarounds because of this including cloning the ticket into a new ticket with the new ticket type and using automation to do it making it appear seamless when it was really closing a ticket and opening a new one. Pretty sure that work was in one of my older refunds tutorial
As based on his tutorial, when you select the first order then click “Wastage”.
I wasn’t relating this to payment type buttons, in this example it is more specific about automation command buttons on ticket screen.
In his tutorial, in the screenshots at the start that show the workflow, you can see between steps 2 and 3, after clicking “Wastage” the below ticket buttons change - all are replaced with just the “Process Wastage” button. You can also see on both screenshots it is still a “New Ticket” therefore hasn’t been closed.
So I would have assumed the button changes is due to the automation commands being mapped to the ticket type. Now, I accept that Rick’s setup is very complex so it may well be the case he is hiding the other buttons using visible states. But also given he is logged in as Admin I don’t see any way you could easily remove all the other buttons and show just one with only using visible states.
This tutorial was just one example. I have had this problem before when changing ticket type of an open ticket. I am using this tutorial as an example because it appears to show it working as I had assumed. Indeed the workflow presented would not work the same if you had to close and reopen the ticket before using Pay Ticket.
I didn’t ask @RickH about this directly but maybe he can comment on this?
EDIT: Actually in this example, I think Rick had the same issue and had to use visible states to show/hide automation command buttons. I only found this after searching deeper:
The button changes are due to the State change. He mapped them to states not ticket type. If you notice in his screenshot ticket type for mapping is * Anyway what I said still stands you have to close the ticket and reopen it. Like I said I experienced this too and I worked around it by an elaborate automation that cloned all orders into a new ticket with new ticket type.
Yeah, I see that now also, as well as my edit above where he says he had to do it that way.
Yes, I have had to do the same before or even rework a whole idea to get around it. I used Rick’s tutorial as an example as I was building something based on it today anyway and it highlighted the issue again to me, and got me thinking it was possibly something that had worked in the past and didn’t now. Anyway I know now that’s not the case.
Only Emre knows for sure but based on my interactions with him and this issue in the past and my understanding of SambaPOS I would guess it has to do with how the caching works. He would more than likely have to change how that works to make this work which could cause other issues to come up with other peoples automation so it was just understood that its better to figure out a workaround.
My old refunds tutorials and prebuilt database for v4 had a fairly complex setup for processing refunds that did this. I dont use it anymore and its been a while but if I remember right I had it where it would clone specific orders into a new ticket or clone entire ticket but not before changing the original orders to void or some other state. It kept the original ticket as a papertrail of what was happening. But when it cloned it into a new ticket it changed ticket type.
The whole reason I did this was because I wanted Refunds on their own ticket type and I processed them with reverse accounting using a refund payment type. I had an entire accounting process built around just refunds.
That setup was built for retail because at the time we owned a small consignment shop. We still own the building etc but someone else is leasing the business from us so I am no longer involved in retail.
For food refunds I am just using accounting to do it and not worry about inventory or orders etc. I just refund money since 99% of time the food is waste anyway. So I built some automation that I use from the accounting module. Basically im just moving money from one account into another etc for bookkeeping.
I planned to build a new refund system but never got around to it. We grew sales this year by over 50% I have been very busy. Me and my wife are looking into another location in a nearby city in the next 2 years. We will keep this original location but there is a LOT more money to be made in the city next door.
Due to the poverty level here I have to keep my prices low so my margin is thin. In the city next door I can get much better margins. The best part of it is we are an old style diner that makes everything from scratch the old way and we have a unique home town diner feel to our place. That style of restaurant was pushed out years ago in the city for fast food… now with current climate and trends the appreciation of hand made food is making a come back and we can offer the atmosphere and good food that is missing in that area.
I am just very picky and it has to be the right location at the right price. I have had several people from the city approach me trying to get me to come in but their locations are too niche for me.
I have not been able to get that Action to work reliably.
