Select orders where a state value is not set or group name is not set

V5 Question
#1

When changing ticket types order prices need to be updated as some items have different based on delivery/pickup. This is working but I need to constrain which orders are selected to update.

Any combos have fixed pricing no matter what. Right now the menu items that are part of a combo are reset to their default price whose sum is more than the combo price.

Using the Select Orders action, I would like to be able to select orders where PStatus is not set or Group Name is not set, or even Group Key is not set. Setting PStatus = No Promotion on order added (thinking I could use that constraint to select orders) interferes with combo automation, and group price is changed to 0.

I’ve tried to select by order state PStatus!=Promotion, Order.GroupTagName == "" as an expression with no luck.

Any help is most appreciated.

TIA

#2

Try {ORDER STATE:PStatus} != ‘’

#3

Thanks for the reply, Jesse. I seem to be missing something.

I need to select all orders whose PStatus state value is not set.

Here is the action:

2021-02-24_14;29_1614198597_Samba.Presentation

For A, B, and C I have tried the following:

  • {TICKET STATE:PStatus} = ''
  • {TICKET STATE:PStatus} == ''
  • '{TICKET STATE:PStatus}' = ''
  • '{TICKET STATE:PStatus}' == ''

{TICKET STATE:PStatus} == '' throws an exception with LINQ when used at C (something about { being invalid).

2021-02-24_14;30_1614198656_Samba.Presentation

Thanks

EDIT:

Also tried constraining the Update Orders action. No dice.

Same behaviour with Update All as True/False/Not Set

2021-02-24_14;51_1614199916_Samba.Presentation
2021-02-24_14;51_1614199916_Samba.Presentation751×425 10.2 KB

#4

Have you tried only carrying one field for the action.
Have in the past found that an empty field is not ignored.
Think it was portion on update order (May have been old version that has been changed since) but an empty field reverted product tp 1st/default portion rather than ignored.
Perhaps your empty other fields are being included causing all to be selected bypassing other fields filter expressions?

#5

Thanks for the suggestion, JTR. Unfortunately there’s no change.

All orders keep being selected.

Here’s where I’m at now:

2021-02-25_10;59_1614272349_Samba.Presentation

EDIT:

For State expression if I enter PStatus=Promotion is selects only the promotional items.

This works:
2021-02-25_12;20_1614277228_Samba.Presentation

This does not:
2021-02-25_12;20_1614277239_Samba.Presentation

#6

What about just =, does it have a default state?

#7

Bruv, you are a star! Thanks much!

#8

So now when there are only promotional items on the ticket, PStats= selects all orders.

2021-02-25_19;56_1614304574_Samba.Presentation

I thought about '{ORDER DETAILS:OS.PStatus}' == '' as an action constraint, but I’m not getting a value back from it.

Any thoughts?

#9

Never mind. I just used another order state that didn’t mess with promo automation.

#10

Well I spoke too soon. ffs

It seems that if nothing matches the expression all orders are selected.

#11

Just a different thought, what about using a loop value to change the prices?

#12

The looper would still requires selected orders IIRC. The select orders action doesn’t seem to be working the way I thought it did.

Or are you thinking select all orders then loop through them?

#13

Not necessarily selecting all orders, but rather getting the Unique Order Id (UOI) then, looping each UOI to set the price. You can constrain out the order based on the order state on the Loop Rule (or just adjust the price to same price).

#14

Well, it’s worth a shot. Thanks for the suggestion; I’ll let you know.

#15

I think the problem is that it only reads the order states after it has selected the orders not before. I might be wrong but I was doing some automation using order states and hit the same bump few months back.

#16

Try using {ORDER DETAILS:O.OrderUid:(OS.Status=New)} to build the list to loop (or another status).

I’m not sure it will work… just a thought

#17

A constraint is based on the rule event not the action, and guessing the select orders isn’t in an order based rule so has no like to orders. Or even if it were on say order added it would reference the order that was added not all ticket orders, and in that case there would be different flow anyway

I’m not quite following what your doing tbh lol

#18

If one calls in an order for pickup but then changes his mind and calls back to change to delivery I wanted a way to change the ticket type. States, pricing, etc. would need to be changed.

In the end I’m putting this on the back-burner. I’ve spent too much time on something that won’t be used often and isn’t critical.

#19

Cant you use different Entity Screens with different Ticket Types for this? Then you can also use Ticket Entity Changed Rules to change active ticket type, apply different price definitions, states across the board etc.

#20

You, and your selecting orders that aent promo to change price tag right?