Automatic discount based on customer discount-level with set amounts per product

[emre]

Wow @QMcKay that way you’ve handled much more cases than I’ve thought. Amazing…

While implementing states I was thinking I’m doing something not very useful as too few people will use it. However I’m glad I’ve did it so I’ll be able to learn a lot of things from talented people. I wish I could sit next to you and watch while you’re implementing it… It would teach me a lot of bad-ass ways to improve that.

Anyway how you’re pushing SambaPOS limits sufficiently makes me think about new ways to optimize things. Being able to implement such complex ideas with rules was just one of the essential steps. Now I think we should quickly improve these…

• Enable disable rules in group by rule tags so we can have multiple implementations of such discounts or similar promotional, loyalty implementations. That allows us to test how slightly different promotion methods performs.

• Implement something to align custom reports to promotional date ranges to compare differences with other promotional ranges. Learn new things from that experience, choose better performing one, optimize it more and create new ideas to test.

[Jesse]

States are awesome. So much flexibility with them.

[gerlandog]

@emre

I’ve added Hard Refresh Ticket action to refresh order display

I cant find this action, it will be usefull (I think) for my happy hour implementation…

Thanks!!!

G.

[QMcKay]

@gerlandog, I don’t think this is a new Action. It is the old “Refresh Ticket” Action that we use all the time: Display Ticket Action with Ticket Id = 0.

@emre is stating that the original flow of this discount required the “hard” refresh in 1 of the Rules, but as of v4.1.75, the refresh is not necessary, and it was removed from the Tutorial when 4.1.75 was released.

[QMcKay]

@Jesse

States are awesome. So much flexibility with them

I used to be deathly afraid of them because of a lack of understanding. When I came to realize that they are somewhat similar to Order Tags and Ticket Tags, yet more flexible/powerful, the fear went away. I mean, you can essentially use States in place of Tags in many scenarios…

[QMcKay]

@emre

you’ve handled much more cases than I’ve thought

So it got me wondering, after looking at the gigantic Rule-set: Is it worth it? It looks overly-complex to me at first glance. Happy Hour in itself is fairly simple. As is VIP discounts. But put them together and it looks scary. I can’t help but think there must be some opportunity for optimization in there somewhere…

Ticket States (named VIP) used:

• Active: customer has a VIP Level (1,2,3)
• InActive: customer does not have a VIP Level, or there is no customer assigned to the Ticket

Order States (named DiscountType) used:

• <> : (blank) when an Order is first added; will be updated immediately to ND
• ND : No Discount (same as blank, but easier to identify and work with)
• VIP : VIP Discount as defined by D1/D2/D3 Product Tags
• HH : Happy Hour Discount as defined by HH Product Tag; overrides VIP
• VR : VIP Removed (temporary holding State when VIP Customer removed from Ticket, or Customer changed to non-VIP Customer)
• HP : Happy Hour Pending (temporary holding State until we verify whether Item Order Time fell within the HH timeframe)

This is where I think I might be able to get rid of 1 or 2 States and Rules:

As I developed the flow, VR was necessary so that VIP-removal would not automatically become HH. Then I figured: why couldn’t it become HH if it qualified? We can check Order Time and apply HH if it qualified. So then I created HP to use while checking the Order Time, and would update it to HH or ND as applicable.

ND > VIP > VR > HP > HH or ND

If HH overrides VIP, how could that happen? In testing, I had manual control over turning HH on and off, and modifying the HH Start/End Times, that’s how. If I didn’t have that control, the above scenario would theoretically never come into play. So why do we need that flow? We probably don’t! This would be because: if the original Order Time was inside the HH Window, the flow would have been:

ND > HH

That should be the case whether or not a VIP Customer is selected on the Ticket. Now what happens when we are not inside HH Window? Depending on Customer VIP Level:

ND > VIP or simply ND … let’s assume ND > VIP

Now we remove VIP Level Customer:

VIP > VR

Why? So it doesn’t become HH. Why would it become HH? Because I wasn’t checking Order Time, it would automatically become HH if the HH PriceList was defined, which I was switching on/off at will. I shouldn’t be checking the PriceList status at all; instead I should be checking the HH Start/End Time and comparing it to the Order Time. But through development, that came later.

[QMcKay]

VIP and Happy Hour Discounts without Triggers. Happy Hour Discount overrides VIP Discount…

• 1 less State (VR)
• 5 less Rules that previously handled VR and updates to PriceList
• 1 less Action (Execute Automation Command wasn’t necessary)
• number of Actions being fired inside various Rules reduced substantially

Ticket States (named VIP) used:

• Active: customer has a VIP Level (1,2,3)
• InActive: customer does not have a VIP Level, or there is no customer assigned to the Ticket

Order States (named DiscountType) used:

• <> : (blank) when an Order is first added; to be updated to ND, HH, or VIP
• ND : No Discount (same as blank, but easier to identify and work with)
• VIP : VIP Discount as defined by D1/D2/D3 Product Tags
• HH : Happy Hour Discount as defined by HH Product Tag; overrides VIP
• HP : Happy Hour Pending (temporary holding State while we chech the Item Order Time against the HH Window) to be updated to HH or ND.

DB Tools Import Files:
Automation: Discount_VIP_HH_Automation.zip (2.1 KB)
VIP Order Tags: VIP_OrderTags.zip (588 Bytes)
HH Order Tag: HH_OrderTags.zip (563 Bytes)

---

Customer Entity Type VIP Level field:

Happy Hour Order Tag:

VIP Discount Order Tags:

Product Tags:

Edit Discount Amounts in the Product Tag Editor:

Set your Happy Hour Days and Times via Rules:

Printer Template:

[<J00>Total FREE:|{ORDER STATE TOTAL:Gift}]

[<J00>Discounts:|[=F(TN('{ORDER TAG TOTAL:Discount}')+TN('{ORDER TAG TOTAL:VIP Discount}')+TN('{ORDER TAG TOTAL:HH Discount}'))]]

[<J00>TOTAL SAVINGS:|[=F(-1*(TN('{ORDER TAG TOTAL:Discount}')+TN('{ORDER TAG TOTAL:VIP Discount}')+TN('{ORDER TAG TOTAL:HH Discount}')+TN('{ORDER STATE TOTAL:Gift}')))]]

[CD1212]

Sorry to bump this topic again. I have an issue, I think caused by adding the Order Portion Changed event. A number of my products have the Auto Select property set, to prompt the user to select a portion size after adding it to the ticket.

The following screen appears correctly, but after tapping a portion, it does not automatically close. I manually have to click the bottom right Close button after selecting the portion.

I can add an action to the Order Portion Changed event of Display Ticket (with an empty id), which partially fixes this issue. It automatically closes the right portion selection screen, but leaves the order selected (so I still have the Cancel, Void etc buttons available on the right).

After adding the Display Ticket action this is not that much of a problem, but I wondered if you have any ideas of a (better) solution?

[QMcKay]

Not sure what your issue has to do with this Topic, but anyway…

Auto-Select is designed to open the Modifier Screen, which also happens to contain Portions (if any). By design, this screen will not close automatically - this is how it has always been.

If you want to add an Action to the Order Portion Changed Event to force the Order Tag screen to close, you could try Display Ticket Action with an ID of 0 (not blank).

On the other hand, if it is just Portions you want to look at for certain Items, without the need to open the Order Tag screen (i.e. do not use Auto-Select), you might want to set up the new features introduced in v4.1.78 …

[New 4.1.78] Mandatory Portion Selection (and a contest for fun)

I’ve created a printer template tag that returns portion buttons for an order. As a convention if a printer template tag contains Button keyword in it that will produce a result that can be used with Ask Question action. ###New tags {PORTION COUNT}: Returns portion count of an order. {PORTION BUTTONS}:Returns button list for portions of an order. By using these two tags we can implement a portion selection screen when an order that have multiple portions added to ticket. [image] ###Imple…

[emre]

It won’t automatically close as you’ve added Member Discount button. That will automatically close after portion selection if you have only portion buttons.

[pipo]

@QMcKay

Hmm… not sure what I did differently this time, but since I set this up a 2nd time from scratch just now, I find that I need to remove {QUANTITY} from the calculation. My setup is slightly different, as you see here:

[=-1*(TN(‘{ITEM TAG:D{ENTITY DATA:Customer:VIP Level}}’))]

Hm… I just got this same problem. What seems to happen is this:

• when you just click on an item in the menu, it applies the correct discount
• when you select this item now in the ticket, and click on +, it also is correct (doubles the discount)
• but if you first enter a number in the numberpad and then click on an item, the discount becomes double of what it should be

Not really a problem when you change
[=-1*(TN(‘{QUANTITY}’)TN(‘{ITEM TAG:{ENTITY DATA:Customer:Discount}}’))]
into
[=-1(TN(‘{ITEM TAG:{ENTITY DATA:Customer:Discount}}’))]
like @qmckay said, but it’s still a bit strange…

[pipo]

@emre

I’ve created something working. It will give some idea about implementation details.

SambaPOS49_201411021844SQM.zip (444.0 KB)

I’m not sure if it has anything to do with this implementation of customer discounts or something else, but I found a problem that’s already present when I use the database you uploaded.

When you choose any item from the menu (doesn’t matter if it has discount or not), then select a customer, then go back to ‘select customer’ screen but click on the cross (for no customer), then cancel the order and close the ticket. The ticket will stay orange on the floor plan (even though there’s no orders on it anymore).

[Jesse]

check if it still has an entity on it?

[pipo]

The customer is gone (only the table is still on the ticket)…

After disabling all the discount-related rules, the problem persists. Now there seems to be nothing else left but the standard rules.
Does anybody else have this problem (V4.1.75)?

[Jesse]

I will test it on a stock database.

[Jesse]

it works fine. Must be something you changed.

EDIT: NM I reproduced it. Its because the Table Entity Changed States it is not clearing this State Change of Table Entity. The Table is still assigned and the State is New Orders

I think this might be something we can fix. I am looking at the flow now./

[Jesse]

I think we may need to look at modifying Entity Updated default rule. It changes it to available if Open Ticket Count = 0. In this case I dont think its clearing the Ticket Count.

Ok I think its just a refresh cache issue… I opened a previous ticket for that table and closed it again and it cleared it to available.

EDIT: Not cache issue. It is simply not triggering the Entity Updated Rule

[pipo]

I checked this before, and ticket count is 0 when closing.

[Jesse]

So something with that unassigning the Entity causes it not to recognize the Entity Updated on Ticket Closed with no Open Ticket. Its not updating Table Entity to Available. But it will update it if you open an old closed ticket from that same table and then close it.

[pipo]

I can’t even find any tickets anymore. I could see them just minutes ago, but now when I do the same nothing comes up anymore.
They all still had a customer assigned to them, but when I open one it doesn’t show a customer on the ticket…