Checkbox for a product item to exclude it from "discount %" calculation


Order Added to Ticket would be the rule, and {ITEM TAG:DiscountEligable} would be the tag to check…


That would work if you always applied the 10% Discount, however not all Tickets will have a Discount so…

The method we want to use is to capture the click of the Discount button and iterate through the Order Lines on the Ticket to check that Product Tag and apply the discount accordingly - basically Tag each eligible Order line with a Discount.

Personally I would go one step further, I would add only one Item Tag indicating %of discount, and when you add an order in check if the %dicount is 0 do nothing if it is a value do a discount…
So you can have different discounts for different products


1 Like

Hi @emre,
Thank you for the suggestion. I think I understand the logic of your solution but do not know how to implement it. It seems you are suggesting:
0. If we don’t give any discount, we just print ticket. All prices are regular prices.

  1. If we give 10% discount (to qualified items only), we press a button that sets all qualified items to state = Discount
  2. At the same time, we update the ticket amount to apply the discount using {ORDER STATE TOTAL:Discount}

To be frank I don’t understand how to achieve either step. For #1, I don’t know how to change all orders (submitted and new orders) to a new order state (side: are you talking about status states or gift states?). For #2, I don’t know what action type to use and what syntax to type in (it seems “update ticket calculation” doesn’t fit the use case)

If you could describe/implement a solution for on-demand discounting for qualified items (i.e. customer presents a 10% discount card at the time he requests a bill, I click a button and all qualified items become 10% discounted), that would be really helpful. This is the only feature currently preventing me from deploying the system, aside from some slow client response concerns, which are mere inconveniences, not roadblocks.

You can define your own States you even do not have to define them from settings you can define them on the fly from the rules.

I’ve prepared a sample Database Tools import file to demonstrate my idea.

  • Please create a backup before importing it. There might be possible naming issues.
  • Please update to latest version before importing it.

Selective Discount (1.4 KB)

What it does is…

  1. You’ll edit products and set Discount tag as Y for selected products.
  2. As you add orders SambaPOS will mark orders for these products as Discount. Non admin users won’t see this state or it won’t appear in reports.
  3. That config keeps your current Discount % button adds a second “Discount” button. When you type a rate and click that only orders with discount state will taken into account while calculating discount.

Since this is a customized discount we store rate as a ticket tag. You can print it if needed or get order totals marked as discount with {ORDER STATE TOTAL:Discount} tag.

:clap::clap: Thank you very much for the generous donation. I’ve already prepared it before that but couldn’t released it because of the need of releasing new version. I mean we always welcome donations but it has no relation with requests or features we’ll implement :slight_smile: We’re trying to help everyone as time permits.


@ Emre
I import this database file and I see “Discount” Custom Tag in product I set one product with Y another with N and 3rd one leave empty.
I ring up all three product and press discount button on left that took me to the settle screen where I seen Discount % button too I entered 10 and press discount % it took whole order discount not only item mark with Y Discount tag.
can you tell me what am I doing wrong ? :frowning:

I’m getting the same problem here.
When I add a discount of 10% for a ticket with two orders (one for 15 with discount set to ‘N’, one for 15 with discount set to ‘Y’, it correctly adds the discount of 1.5 to the ticket, but on the ticket the individual items are both shown as 14.25.
Anyway to change this behavior @emre?

EDIT: it’s only showing these numbers on ticket in the payment screen. When I close the payment screen it’s showing 15 on the ticket (no discount shown for the individual orders), and the discount of 1.5 is applied to the ticket.
Is it possible to have the discount shown on the ticket for the individual order where discount is applied?

This is a tax issue or calculation causing this. Do you want the discount to come off the Taxed product or before tax? I ran into this issue as well. In my case I wanted my discount to apply before tax.

EDIT: I am looking at how it is setup to determine for sure if this was it or not. I am thinking now it was probly just how it is setup to run. We can more than likely fix this ourself.

I’m not using any taxes (my business is tax-free).
I just had a better look at @emre’s implementation, and it seems obvious now why there’s no discount shown for individual items as the discount is calculated by using {ORDER STATE TOTAL:Discount} and {TICKET TAG:Discount Rate}.
I just don’t understand yet why a discount is calculated for each individual item on the ticket in the payment screen.
I’m suspecting it has something to do with the DStatus being set which might trigger some older discount rules that I had setup earlier. I have to check that first…

When the order is added its checking for the Flag. If it finds the flag it is automatically updating the Order State with

[=TN('{ORDER STATE TOTAL:Discount}') * (TN('{TICKET TAG:Discount Rate}')/100)]

When you enter the discount from payment screen this updates the Order State because it throws that discount into the calculation I just showed you. IT has not affected ticket yet until it adds the calculation. But … there is no update Order its just using a calculation for the discount. For it to show the amount reflected per item on Ticket screen we would have to use Update Order.

Does this sound about right @emre or am I thinking too hard?

So as you mentioned below me Order Tags should be updated instead of Ticket Tag.

This sample is not item based discount. It is still a ticket discount but it calculates discount amount from selected orders. I mean it is same as adding a fixed discount amount to ticket but it simplifies process by ignoring specific items. As it is a fixed ticket discount payment screen distributes discount amount to all orders.

It was just an idea for the original question. If you track discounts by orders that should implemented with order tags.

1 Like

Maybe I should just start using actual examples before I try to explain anything as I am figuring it out. I tend to put stuff down in the forum as I am figuring it out and it confuses my actual intention.

I did run into funny behavior with Taxes a week ago. Wish I had written that down I could have explained it better here. It was leaving behind a penny and an unpaid amount that would only show up if ticket reopened. We fixed it but I do not remember what we did or what was causing it now.

That was probably a rounding issue. Tax Template’s Rounding setting is useful to solve such issues. Maybe you used it.

What I meant was it left a penny difference after settle… if you looked at ticket it settled with .01 left… but if you opened ticket and tried to close again it would suddenly have the discount amount as unpaid and not let you pay for it. Was really strange. We fixed it and maybe it was rounding… maybe that penny was what threw it off and made it behave as it did.

Yes this is a rounding issue. You should force SambaPOS to round calculated tax amounts to settle correctly. This is a setting because it should be handled differently for Tax Included tickets.

1 Like


I don’t understand why the automation command has a constraint that the tendered amount has to be less than 99?

And also why the Update Ticket Discount Rate sets the Discount rate to TENDEREDAMOUNT…

So the % discount is not 100% or greater. I am not completely sure but it makes sense to me that from payment screen an amount entered would be a Tendered Amount. It is tendering it into Discount instead of Payment Type.


I see, that makes sense.
Thanks for making that clear @kendash.

I learned it just now actually from your questions lol. So its kind of neat to know that you can read {TENDEREDAMOUNT} like that from that screen.

1 Like