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

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?

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 …

1 Like

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.

1 Like

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…

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).

check if it still has an entity on it?

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)?

I will test it on a stock database.

1 Like

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./

1 Like

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

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

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.

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…

I see what it is doing. Technically you wouldnt need to remove customer and then cancel orders anyway. You would just cancel orders and close ticket. I am playing with it to see if I can find out what its doing and if its something we can fix. I know the issue is its not updating it to Available. There is only 1 rule that does this… so it means this rule is not triggering. This rule is Entity Updated with constraint of Open Ticket Count = 0

So we need to figure out what is causing the rule not to fire… is it the constraint not met or is it the Entity Not Updating.

I am thinking its the Entity Not Updating because you removed the Entity without updating it. So maybe the rule is not triggering because there is no Entity to update anymore. This would explain why it clears it correctly when I opened an old ticket and closed it again. It technically put the entity there and then updated it to available since the old ticket was closed out so Open Ticket was 0 and it had an entity in the old ticket to update.

So since the issue is removing the entity before we update it… maybe we need a different rule to activate Available Status. Add it to Ticket Closing… but then we would need some constraint.

What I don’t understand is this: this seems to be just a standard install of sambapos, or not?

Yes and no. It is part of the sample rules and actions setup as a basic working system. Yes. But those are not technically standard install. They are samples to get you moving and setup as very basic setup. It is not a hard coded feature is what I am saying…

You would not need to remove an entity this way however if your canceling order.

So you mean this could have been like this for a long time already without anybody noticing because it’s not something you normally do?

Yes it could have… or if he recently added the ability to remove an Entity like that it might have came up. But 99% of people do not remove entities like this and then cancel orders… typically you just cancel orders and close ticket and it updates the entity to available.

We can fix this if you think you would be removing entities before canceling orders. We just need to find a better placement for the Available state since you do not have an Entity to update anymore./ The most logical and first thing I think of is Ticket Closing but this could impact other things if we dont constrain it right.

Well I wouldn’t normally do that in production, I was just testing things when this started happening. But of course it would be better to have it as fool-proof as possible.
Did you reproduce this on a new install or also on @emre’s database?
If not, I can do a fresh install and see if we already have it there, but that’s going to be for tomorrow then (it’s almost five in the morning here).

Fresh database install. You can load fresh basic databases without reinstalling SambaPOS… just change Local Settings to a new DB name and it will create one. Good little trick for testing.

You can also enable Multiple instances of SambaPOS in the Settings.txt file and load up 2 different databases at same time. This can be automated through rules :stuck_out_tongue: I sometimes have 3-4 databases and 3-4 SambaPOS instances open at same time for testing.

2 Likes