So it was me being too smart
So I have simplified the rules and actions to just 3 Rules & 3 Actions (Plus a global Update Program Settings Action)
Action 1. Print Promo Ticket
Action 2. Update Ticket Tag
- Promo = [Setting Value]
Action 3. Reset Promo Ticket
- Set PromoTicket=0
Rule 1. User Login
- Action 1. Reset Promo Ticket
Rule 2. Enable Customer Promo Ticket using Customer Selected for Ticket trigger
- If the customer is Active (via Customer Group Code) then it sets PromoTicket=1
Rule 3. Print Promo Ticket for ticket total above an amount, ie $5, $10, etc using Payment Received trigger
- Setting Check - PromoTicket = 1
- Amount > 9.99
- Action 1. Ticket Tag Promo - Setting Value = Tooheys Esky
- Action 2. Print Promo Ticket
- Action 3. Reset Promo Ticket - PromoTicket=0
This is neat and tidy. What would be cool is if the Payment Received Rule also included the following conditions
- Ticket Tag (which can be set by purchase of a product if it is product driven Promo)
- Tag Name (as above)
- Customer Group Code
- Customer Note
These would allow removal of the Enable Promo Ticket rule and Promo Reset actions. So we would have only 2 Actions and 1 Rule.
Rule 1. Print Promo Ticket for ticket total above an amount, ie $5, $10, etc, for an Active Customer with Full Membership using Payment Received trigger
- Amount > 9.99
- Customer Group Code = Active
- Customer Note ? Full Member
- Action 1. Ticket Tag Promo - Setting Value = Tooheys Esky
- Action 2. Print Promo Ticket
All up, Promo tickets need to be printed only once payment received (never before), so the trick is getting the info needed to the payment process.
Being able to use {SETTING:xx} variables would allow nicer formatting for printed tickets and better Rule & Action handling for more complicated setups, but at the end of the day if the printed ticket has
Promo: XXXX via Ticket Tag then so be it.
Like I said, its about working with what we have, not reinventing the wheel.