Stop Points earned for Gifts

V5 Question
1

I need some help when constraining to stop Points being issues if the order has a State of Gift. I will display the rule I have attempted but obviously need to know the “pecking order” of States.

Rule

InccreasePointsRule.JPG759×592 77.9 KB

Before and After Ticket Settlement

GiftBefore.JPG1103×294 37 KB

GiftEnd.JPG1100×330 52.9 KB

Debugger Output

As you see above points are still being issued.
I do not wish to REMAP to a whole new ticket.

Must be a way to refer to “other past States”? Well in fact “Gift” is still a current State which is my confusion :confused:

EDIT:
Wondering if I could do something here so State does not become Earned?

Ticket Payment Check

TicketPayment.JPG711×539 53 KB

umm @emre I thought the constraint below would of worked?

Gstatus.JPG744×558 61.3 KB

#And the Winner is:

GiftWinner.JPG969×574 68.8 KB

So can somebody please explain why these do not work as constraints!:

‘{ORDER STATE:GStatus}’ != ‘Gift’

TN(‘{ORDER STATE TOTAL:Gift}’) = 0

[=F(TN(‘{ORDER STATE TOTAL:Gift}’))] = 0

Just don’t understand why GStatus does not work when there is “GIFT” as a state on the Order? It sometimes hard to find references to the correct syntax for “==”. “=”, “!=” etc etc and when the value is Numeric or Character for testing purposes. It would be nice if the Debugger had accessible value assignments
i.e ORDER STATE TOTAL | Char | “1.50” as it work save the guesswork - then the system would really rock :sunglasses:

CREDITS:
JTRTech - searching for how to use " = 0"

2

Because the Rule (Event) you are using this constraint in is Ticket-based, and it cannot know which Order line you are referring to.

Neither of those are using comparison operators. You must use == instead.
The second one is missing the expression: [= ... ]
Th last one has F() which is a formatting function which will append decimals to the number, so: 0.00 != 0

You still really should work out a flow for proper Order State because what happens when you have 2 orders on the ticket, both are valid for points, but only 1 is a gift?

3

Oh yes thanks @QMcKay - its starting to fall into place with your help, much appreciated! - and that issue was on my mind. It was only by testing I found points being earned from gifts so it started to see how to constrain them.

The second test as you have suggested would of failed so now need to find a solution for multiple orders on the ticket.
So can you explain what each of these blue lines below represent? Order based right, but how do I refer to them?

Also can I assume this is the right syntax below:

'{ORDER STATE:GStatus}' != 'Gift'

Continuing on from above - can I constraint UPDATE ORDER EVENT as this would run for each Order? It where I started but picked the Ticket Event as I thought “Earned” was inappropriate…

UpdateOrdersPoints.JPG887×582 71.3 KB

Ah funny now thinking more about what you said then ZALP_Update Order's Promotion State is wrongly placed in the Ticket Event as well? Think I copied this from emre’s original tutorial which obviously was based on 1 order per ticket.

4

Submitted: {ORDER STATE:Status} == 'Submitted'
Earned: {ORDER STATE:Points} == 'Earned'
ND: {ORDER STATE:DiscountType} == 'ND'
Gift: {ORDER STATE:GStatus} == 'Gift'

Yes, you can constrain an Action with something like:

{ORDER STATE:GStatus} != 'Gift'

I see you have VIP/HH set up. Look at the Rules and the way they handle States to ensure a Discount is not being applied when an Order is Gifted/UnGifted. There are a few of them that handle the aaplied discount when GStatus is Toggled:

CD UnTag Order Discount for ND or Gift
CD Tag Order Discount when UnGifted
CD Tag Order Discount for VIP or HH

1 Like
5

Thanks Q - its a pity the Ticket Payment Check Rule ->Update Orders Promotional State constraint could not have an Order Line Test. Are there any? It would be so easy. Obviously the Update Order State must “fire” for each Order Line as all Orders are sequentially changed front Points -> Earned in this event.

Therefore each record I assume is updated but that is only in conventional databases. I was trying to avoid toggling states between Gifts and Points - which all happens before “Earned”…

6

Well I cheated:

GiftCheat.JPG885×573 69.4 KB

Untagging, tagging is probably a better workflow, but it takes a lot more rules & actions and also I seem to find new ways to break them which then requires more rules, actions…

So this one constraint does it all, which is what I was chasing but thanks for giving me a light bulb moment :bulb: on Ticket Event Vs Order Event, and not to mention the 4 order states above you have described. Applied all that learnt in 1 constraint.

For readers the only downside is the settled ticket has States: Earned + Gift on the same Order line BUT no points were earned. Not a problem as easily explained that a $0 value sale earns 0 points :smile:

7

Not necessarily. I think your setup is a great use-case for States, just as with VIP/HH setup. The tagging going on in VIP is just to apply a discount - the tags are not involved in making any flow decisions.

I think that is the same with the VIP/HH setup. It could have both VIP and Gift States, but the Discount Tag is not added when it detects Gift… but who cares? :stuck_out_tongue_winking_eye:

8

Hi @QMcKay - just one little question that has been bugging me all night.

Why in the above picture I can use alternative “State” qualifiers?
State Equals Earned
and
{ORDER STATE:GStatus} Equals NULL

If I try to answer my own question: Using “State” can relate to all States as long as there is one “Earned”. You can qualify this down by use “State Name” in which case I would use “Promotion” to ensure it is State qualifier for Promo.
Therefor to save 2 lines you can combine and be more specific and use “{State Name:State}” in one line.

The trick is (if I am correct) is when using 2 lines they need to follow each other i.e. State + State Name in the drop downs. Then you may specify a 2nd State + State Name.

Did I get any right :pensive:

9

Yes, different ways to get the data you want.

The thing to watch for is that “Matches” is a “bit of magic”. Well, not really, but the way it works is:

If you have the same thing on the Left side more than once, it acts like an OR for those lines.

So if we had:

State Name
State Name
State
State

… along with “Matches”, then it only needs to match 1 State Name and 1 State to be true and fire the Actions.

So sometimes, it is better (or simpler) to just be specific, and use something like:

State Name = Points
State = Earned
{ORDER STATE:GStatus} != Gift

1 Like
10

Ok Perfect :beers: So the Order or sequence make no difference as I may have thought, great.