This may have started as a “by design” feature, but it is pretty troublesome, so it would be good to tweak the implementation…
I use various ticket types…
Reservations*
Sales
Guide planning*
Payroll
Budgets*
Expenses
Tickets with a (*) are pre-order tickets Bold tickets represent money coming in to the business and non-bold tickets represent money leaving the business (I have many different accounts and transaction types to facilitate this).
The problem I have is that sometime one of my staff with have multiple tickets open at the same time. When I attempt to load a ticket I am given the option to merge tickets. This functionality is incredibly helpful when they have multiple tickets of the same type (which they frequently do), but it is disaterous when they have tickets of different types becuse they end up all merging in to one ticket and due to the different nature of the items we put on each type of ticket the result is a complete mess and a headache to sort out.
Would it be possible to add an option (maybe to program settings) to determine how ticket merges are handled? For example:
How to merge tickets:
Merge all - All open tickets will be merged, regardless of ticket type (classic)
Merge similar - Only tickets of the same type will be merged (modern)
Can you be more specific. Are you assigning tickets to entities? And then trying to open the entity? Can you define ticket because if I make multiple tickets and load a ticket it does not do that. The only time it will do that is if you are creating multiple tickets assigned to the same entity. Is that what you mean?
Yes, all my tickets are assigned to a Customer entity (this is normally either a member of staff or a client). But sometimes one person has an open reservation at the same time they have an budget or guide planning ticket.
I changed this to a question because it is working as it was intended. What your asking makes sense I understand you. Your case is special though as this was designed for a simple function of having the ability to do separate tickets at the same table in a restaurant. Your using it for something else which is fine but before we change something that thousands of restaurants are using atm lets think it through. Maybe we can find something else that fits your specific case better. Lets discuss it further.
I understand. But I kind of think this should have been addressed the moment SambaPOS started supporting multiple ticket types. Multiple ticket types were presumably created to allow people to create tickets with very different uses…
I understand that any change needs to not affect any existing users, and that’s why I suggested a classic vs modern option in program settings, with classic being the default.
Maybe if there was some type of “before ticket merge” rule that we could hook in to in order to check the tickets are the same type, or when presented with the multiple open tickets to choose from, that list should be limited to only one tickets of the same type.
@Jesse with my description in that last message of this kind of being important for anyone using multiple ticket types, do you think it would be appropriate to categorize this back as an issue to be fixed?
Just thinking out load but as a work around in the mean time… isn’t merge ticket a role permission? Could you prevent it and make a custom flow for merge maybe?
I don’t understand how it can be described as working correctly… If you use multiple ticket types (which is a fully supported feature) and you use merge tickets (also a supported feature) then you get get unexpected results.
The purpose for the feature is working. Yes there are some unintended complications due to the nature of SambaPOS. But nothing is actually broken. However we can look at adding a feature to support the idea you have brought forth. It’s a good idea.
As I see it I would compair this to merge tickets and calculations.
We are prevented to merge tickets where they both have calculation.
Either restriction or option to prevent merging of different ticket types would make sence in the same way as calculations. Which type should be used after the merge as which calculation should be used.
I have yet to really do much work with multiple ticket types but can see how it would cause issue. And that if you implimented multiple types you wouldn’t want them being blindly merged.
My point is that if you use multiple ticket types normally, and you use merge tickets normally, you’ll be left with a nasty mess to clean up… That has to be an issue, rather than normal
He uses them for planning and accounting.
Preorder being a big issue by sound of it.
Using samba for non standard model.
Would imagine its customer entities rather than tables.
I know that was my point the purpose of this feature is specific to tables when it was implemented. The original reason for it is working. It’s not broken but I agree we can improve it. I think your misunderstanding me. Just because we don’t list it as an issue doesn’t mean we won’t look into improving it.
I have tangled with jesse before in situations like this :-p
It’s not a case of being aquard but often more a case of hashing it out to clarify a route to solution etc.
Perhaps approach with a parallel point applicable to restaurants may assist.
I own a restaurant with two ticket types… Eat-In and To-go… My waiters get paid commission based on the value of the tickets they process, so I assign waiters to tickets not just tables.
To-go and Eat-in tickets have different menus, prices and transaction accounts.
I find it useful to sometimes merge the tickets from one waiter for all the dine-in tables he is working on because… reasons
Unfortunately, the current functionality of merging tickets for this diver waiter is merging their open to-go and dine-in tickets…
Do you think this is an issue?
Do you think that example will tick the boxes @JTRTech
To be honest, it seems like whether it’s listed as an issue or not it is probably not going to change the speed of getting it resolved. I reported a massive issue with pre-order transaction dates a while back and that seems to be on the back-burner…
