Order Tagged Event Issue

Seems like Order Tagged event doesnt work in v5.5

I just got raised a question by the client about Order Tag Discounts not working. Well, discounting additional add-ons doesn’t work anymore

Example


Customer has 50% discount
Customer orders $1 coffee with milk (+0.5$)


Staff selects the customer
Staff selects coffee
POS automatically calculates discount and coffee gets -50% order tag
Staff selects Milk order tag
POS doesnt do anything (expected result is that it applies discount to an add-on order tag)


Upon further inspection I can see that there is something wrong with it as it completely ignored any previous Actions that tag the order, removes any Order Tags (from whichever groups) and when I use show message to debug it, it loops it indefinitely.

Is this really a bug or has something changes about this rule and it will no longer work this way?

UPDATE:
The event fails to do it until the calculation of the new order tag price comes to 0, then SambaPOS automatically cancels the rule.

Why this new loopy behavior happens I do not know but this was an update made from 5.2.6 to 5.5. Before that this worked normally

I even tried running an automation command that will Execute Once and result is the same.

So your trying to use order tagged event to tag an order again? Or just to update a different tag already on it?

Can you show the action

Instead of updating total Discount value, I am just calculating the price of any new order tag.

In this example


Customer has 50% discount
Customer orders a Coffe $1
From Coffe Extras group selects Milk (+0.5$) which then is calculated into $0.25


This is the calculation

[=(TN('[:OrderTagPrice]')*(TN('{ITEM TAG:{ENTITY DATA:Customer:Discount}}'))/100)]

Result is removal of all Order Tag values from any Order Tag group

P.S. The name of the rule and some other things are changed because Ive been troubleshooting and deleted old rules and started again.

Try passing it through acm executed. I’m still curious to see the action.

I did already, I even checked the “Execute Once” option and it did not work

Here is the action
image

Try the require selection part

No effect with True nor False in Require Selection

I’m not sure I ever tried updating a tag when a tag is applied.

I would thing it would cause a loop. You would just trigger it over and over.

Logically it should loop.


TagName	 	[:OrderTagName]
Tagvalue 		[:OrderTagValue]
TagPrice		[:OrderTagPrice]
TagCount		[:OrderTagCount]
TagQTY		[:OrderTagQuantity]
OldTagCount	[:OldOrderTagCount]
OldTagQTY	[:OldOrderTagQuantity]
ParentPrice	[:ParentPrice]

Just so you can see, all the values are passed and all the fields are correct. Even the calculation at the bottom calculates normally.

But why would that be? Because in previous version there was no looping of this action or event. It simply worked quite efficiently and as expected.

It should loop. Your tagging an order on order tagged event.

Even if thats the case, previous looping worked just fine, this one doesnt and since there is no new field or an option to enable/disable something new, I would call this a broken/buggy feature, especially since it used to work without a single issue

Since there is no rolling back to 5.2.6 I am forced to work around this and create an entirely different way staff/customer discounts work and prepare new reports using calculations instead

Perhaps we fixed an issue and it was not working correctly before. It’s hard to tell but we can look at this. @VehbiEmiroglu

Happy to zip and send you my database if it helps in your troubleshooting

I won’t have time to look at it. But you could send an email to support@sambapos.com with it and your detailed issue.

Is it really possible that I used this Event as a feature that by fault executed only once in previous version? :joy:

I guess Execute only once can be an True or False option :thinking:

I mean technically it should loop. You’re tagging an order in order tagged event. If it didnt loop before it was probably broken.

I know it loops and I see your point and both use cases make sense to me, I think what we are missing is the ability to handle both cases

Thats why I implemented it that way, because I didnt think it would be open to possibility of an infinite loop. Which I think is faulty :thinking: