This type of flow is in my opinion fairly complex.
I put together something similar to handle Customer VIP Discounts and Happy Hour Discounts using Ticket States, Order States, and Order Tags. It allows Order-line level discounting and removal based on Ticket State, Order State, and applies or removes discounts via Order Tags, based on Custom Product Tags and Customer VIP level data.
Although it isn’t exactly what you’re looking for, I believe the theory and flow are what you probably need to accomplish your task.
You need to keep in mind that you are trying to mix Order level and Ticket level discounts, which can be very difficult to handle, that is, they don’t really mix well natively. You should try to stick to Order-level calculations only in your case, IMO. The implementation I show above does not use Ticket-level calculations; it only uses Order-level calculations.
Yes Tax Templates are Ticket-level calculations based on their product mappings. Although the amount is derived via the Order-line, the calculation itself is applied at the Ticket-level.
So it doesn’t really matter if you apply a discount at the Order-level to negate the Tax Amount, the Tax will still be calculated based on the Discounted value of the item.
The same is true for other Ticket calculation Types, such as a Service Charge - they are applied against the Ticket with no regard for the value on the Order-line.
For your scenario, you may want to get rid of Tax Templates altogether and instead assign Custom Product Tags to your products to indicate their Tax amount/percent. That way, you can control what gets Taxed and by how much, and even remove the Tax from that Product at the Order-line level.
I can’t think of any other way around it for what you are trying to accomplish. Since you want to operate on the Order-line level, you are stuck at that level. Since Taxes are Ticket-level calculations, you can’t use it to apply Order-level calculations.
A Ticket Tag isn’t much different than a Ticket Note, or a Ticket State. It’s really just an indicator. Even though it could contain a numeric value that you can use to make a calculation via Calculation Type (which is at the Ticket-level), a Ticket Tag itself has no built-in calculation mechanism. Order Tags on the other hand, do have calculation a mechanism - the Order Tag Price.
Show the Rule(s) and Action(s) you are using for this.
It should be as simple as using a Update Ticket Calculation Action with Rule(s) to capture Ticket Tag Selected event and fire the Action(s). Then maybe a Ticket Refresh Action (Display Ticket action with Ticket Id = 0) to update the display.
You don’t actually require a Ticket Tag here at all. The Automation Command could directly fire the Update Ticket Calculation Action. Again, a Ticket Tag is simply an indicator.
In a previous post he had the rules and actions linked so we could see them. From looking at them it looked like he was still attempting to change it at order level which would be why it was not working. I did not test his actual setup though.
This is just some advice but I agree with @qmckay you should use the Custom Product Tag approach. You may think its complex but it looks like your not that bad with complex looking at some of the work you have done to attempt to change order level from ticket level calculation. @qmckay has posted some tutorials showing good use of Custom Product Tags, I have posted some basic stuff and @RickH has posted other variations. Read those and you will probably get a good grasp of it to accomplish what you want.
Several posts ago when you first started with this idea @emre suggested this method. He did not say it out right he kind of mentioned it genericly but Custom Product Tags is one alternative towards what @emre said when he told you to look at the various Discount tutorials and apply some of that logic to do what you want to do.
What I am saying is your avoiding it because you think it is too complex so your attempting very hard to work out a solution that is more than likely impossible I say more than likely because sometimes people can find ways that were not meant to be. Because of the nature of this situation I would recommend you stop trying to get the Tax Templates and Calculations to work and start attempting the alternatives we have mentioned. Even if for some reason you ever got the ticket level calculations to do what you want there is a good chance it might stop working in future versions because Ticket Level calculations were not meant to be used like this.
You could keep the Calculation for your normal orders. Use a method to take the calculation off and then switch to using the Product Tags instead. Do not try to do them both at same time in the same rule. If your using Ticket Tags to designate Takeaway or Dine In then you should use something like what @qmckay showed above to take the service charge off. If you have a mixed order which is where your problem started, then use the Ticket Tag to take the service charge off and use the Product Tags to add the Charge to specific products and leave it off for specific products.
I personally prefer states for this but either method works.
He used Action Constraints to save having to use another rule. He could have made a separate rule yes but using Action constraints reduces the number of rules he needed to accomplish the same thing.\
EDIT: Misunderstood what you were asking. But this explains the difference in yours vs his approach.
I could have used the SG StayGo button to accomplish the same thing. But you will need to explicitly define the Ticket Tag in that case.
The StayGo Tutorial does not explicitly define this Ticket Tag. It applies the Ticket Tag programmatically, but you cannot capture the Ticket Tag Selected event if the Tag is not explicitly defined as shown below.
Yes, that is likely the issue. Until you define the Ticket Tag, the event can’t be captured. You do not need a mapping for the Ticket Tag, but you need to give it a name and define the Sub Tags.
