I’d like to request that a Change Department action be added. This appears to be something lacking for quite some time which has meant many people, including myself, have had to do workarounds or build functionality in different ways. I am not sure if there is a specific functional reason the action has never been added, but I believe it would bring a lot of benefit.
On all the setups we do, we typically setup different departments for Takeaway, Eat In, Delivery/Collection - reason is, they all typically would have different automation commands - like Delivery/Collection has a button to specify Delvery/Collection Time, Display Map, change Delivery Charge, these do not need to be on the Eat In or Takeaway departments. So far the only way to force reloading of automation commands is by changing department - even if you change Ticket Type part way through a ticket, none of the automation commands, calculations or payment types will change even you have them mapped to the new Ticket Type. This is partly beside this request but one underlying reasoning for it.
But currently the main reason we really need this action is we currently use Caller ID on quite a number of setups. We would sometimes like to be able to manipulate the number coming through from Caller ID before passing to the customer screen (and even possibly we may want to change the workflow). Because we have a “Delivery/Collection” department which we want selected for any tickets created by incoming Caller ID, it works perfectly with the built in Caller ID function as there is an option to specify the Department to use. However if we want to build our own workflow to handle how an incoming Caller ID is handled, there is no way we can replicate the built in functionality to change the department as there is no action available to Change Department.
This specifically causes us issues if we have a client with multiple terminals and they want to use Caller ID. The only way we can currently properly handle it is to supply multiple Caller ID devices (USB modems) - one for each terminal. What we should be able to do is capture the Caller ID event on the terminal with the Caller ID device connected them broadcast that to the other terminals. Whilst that is totally possible, we cannot do that because there is no way to enforce (change) the department to ensure it goes into “Delivery/Collection” and not whatever current department is selected.
I have another topics describing this in detail i posted almost a year ago, specifically the Caller ID issue about unable to change department if you have a custom workflow. Another forum member had the same issue also. I’ve also seen other topics about wanting to change department so I think this is a feature long overdue. I am assuming there is no technical / functional reason it hasn’t been implemented, given that the built in Caller ID module can change department without issue when using the default workflow.
@markjw Finally some one also requested this as am requested 2 years ago , however just using 2 departments for some reason, and the problem we faced is here many times a customer place order of 6 items with lot of order tags , if customer change his option we need to change the department means have to cancel all orders and enter them again in another department.
I got replies from forum can use ticket tags , etc but i believe that not met requirements what a individual department do… could be reporting or some other specific .
Looking forward for this to be added in future .
Yeah I am aware of this issue as well, we have it too in our setups. One workaround is to use Ticket Types (which we do anyway as well, we have separate Ticket Types for Restaurant, Takeaway, Delivery, Collection) but you still fall into the same problem like I mentioned above - even if you change ticket type of a ticket part way through, all the automation command, calculation type and payment type mappings based on it are not changed. This is all to do with caching, however it makes it very inconvenient.
So your case I believe is another valid reason for change department action - yes there are potential workarounds but I truly believe the ability to change department would make things a lot easier and have to rely less on some workarounds. I am unsure why it never got implemented before, like you say I wasn’t the only one asking, I have seen it asked multiple times. I wonder there is a reason @emre never implemented before, possibly due to caching, but at the same time, with the case I mention above, the Caller ID module default functionality allows changing of department, so why a separate action could not be made available is confusing.
Maybe a workaround they can implement for change department could if, if you are in middle of a ticket in lets say dine in department… You press takeaway department, it could save the ticket get you into take away menu, take the order then if you press dine in, it would bring up saved tickets to choose from.
Hmm… Department is the top level configuration item. Allowing to Change it (especially when editing a ticket) will create lots of different use cases to handle. I originally implemented Ticket Types to solve issues discussed here. Maybe focusing to Ticket Type changing related issues is a better idea.
In my case, I am using departments because I have restaurant, take away, delivery with different automation command buttons (quite a lot so otherwise the screen would be too busy to have all on one). With Ticket Types, if I change it after creating ticket, the automation command buttons don’t refresh, same goes for payment screen, mappings are ignored unless ticket is closed and reopened.
Also, I use caller ID, and I want calls to go to the Delivery department. This is fine, it lets me specify the department - however I also want to use my own workflow and not the default one for handling incoming calls (I may want to alter number, or I may want to log / save the number somewhere). If I want to create my own workflow, I can’t change department as there is no option.
So I appreciate what you say @emre I believe there is a lot of considerations about changing department, that’s why I thought it was never implemented, but these 2 use cases nothing else can compare to it. Also, default caller ID module functionality already allows change department and works, but can’t be done unless using the default workflow.
The more complicated my default setups are and the more features I add, I find I am restricted because of this - or otherwise I need to devise a totally new way of doing things, which is also a lot of work.
