I have done a setup of the advanced delivery with the configuration task but with some notable changes. But I did not change the customer/entity search part. The Ticket type of the entity screen is defined as ‘Delivery Ticket’. The issue is that when I select a customer then every second time the widget creates a ticket type of ‘Ticket’ instead of a ‘Delivery Ticket’.
The command buttons are the default ones defined as
Select Customer=Select
Edit Customer=Edit
Create New Customer=Create
and I guess there is some magic behind this to create the ticket with the associated ticket type.
Here a Rule debugger picture with 2 times selecting a customer. In the first instance of ticket creation it creates the ‘Delivery Ticket’ and in the second a normal ‘Ticket’.
Below are the details of the 2 ticket creation events which show the different ticket types being created.
Maybe someone has an idea what is going wrong here - I will probably just remove the select customer command and roll my own command button. Thanks.
I’ve found the issue which is caused by my implementation to get rid of the entity tab screen and do all navigations from the main navigation screen.
Therefore on all these screens I navigate back to the originating screen of a particular command.
E.g. I call the ‘delivery screen’ using a command button on the main navigation. I select a customer on the ‘delivery screen’ and press ‘Select Customer’. This creates a ‘Delivery Ticket’. After closing this ticket I navigate back to the ‘delivery screen’ with a Ticket Closed rule. Because of the issue I have put a ‘show message’ into this rule and noticed that in effect Samba shows first the POS Table Entity screen and by doing this changes the active ticket type to Ticket bc this type is associated with the . table entity or active department. This screen does not appear without the Show Message.
My work around here is to change back the active ticket type to ‘delivery ticket’ and then it works.
But in my humble opinion this behavior of Samba is semantically not correct. The close button on a modal dialog, which the TicketView becomes in that instance should lead back to the origin. This is what every user would expect.
I had issues with changing the ticket types. I went with an entity screen for creating tickets and the rules executed set a local setting for which ticket type is required and then on ticket created, check that local setting and change the ticket’s type. I then added checks to make sure customer entity is set before closing ticket.
You could also require selection of ticket type on creation, but one issue I ran into was that the menu was still shown which I initially solved with setting a blank menu for the tickets causing more automation needed to display the proper menu. The the other was the pre-order ticket which is only able to be set by automation and not direct creation so that was also a no-go.
