Price Of Single Item Different During Certain Hours

[emre]

Also we can add a regex match like…

{DATE:ddd} Matches Sat|Sun

So it will work for Saturday or Sunday.

More details…

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

Yes it is what I’m thinking. We should change execution rule to Matches All and also decrease weekday check to a single constraint as {DATE:ddd} Matches Mon|Tue. This is not a general recommendation for everyone but as you’ve already have a product based discount implementation you don’t need price definitions for hh implementation. PS: I think something conflicts with :X so {DATE X} search returns better results. PS2: We might not need TN function for {DATE:HHmm} as greater/less comparisons…

[Jesse]

My goodness I have been not paying attention lately. I see that @QMcKay basically did this same thing in a more robust way already in a previous post. Well @Hasa you have several methods to think about hahaha.

The post I was referring too is here:

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

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 O…

[emre]

@Jesse

exactly what @gerlandog was wanting few months back I hope he sees this.

I’ve commented about that but nobody cared lol.

Close ticket rule

OK first of all let me give you some background information. We store prices in cache. That means as you add items to tickets SambaPOS does not read prices from database. When change price list action executes it raises a flag to clear cache and read prices from database. However if there is an open ticket we intentionally do not clear cache as soon as trigger executes. Since we can not determine when a trigger executes it may cause unpreventable errors. For example think of price change execute…

[Jesse]

I remember that now. I am really not sure why we didnt catch on then. I guess it took a specific need and desire to build it and then the interest shifted. Although I would think @gerlandog would have been interested haha

[Hasa]

What benefit would that other approach give me?

[Jesse]

possibly none. I just wanted to show you a more advanced use for this feature.

[Hasa]

Oh okay, Your method is perfect as far as im concerned… For my current needs atleast, haha.