Support group discounts

[raphaelm]

No description provided.

[anusha94]

i am interested @raphaelm

[raphaelm]

Hi @anusha94! It's very nice of you that you want to contribute!

Do you have any prior experience with Django? I'm not sure that this is a good place to start with this project, I did put the "big idea" label on this issue for a reason. If you don't have much prior experience I'd suggest to start with something simpler like #300 or #312.

[anusha94]

@raphaelm thank you for the suggestion :) i am new to Django, so let me start with something simpler.

[raphaelm]

Since 3c59a87 this can be implemented, so this is not urgent. However, it would be nice to have a more flexible mechanism at some point.

[DerDakon]

I would love to see this working, the "min amount" products have the problem that they do not take other ordered tickets into account for the minimum calculation.

[raphaelm]

FTR, I'm leaning towards implementing #1001 instead.

[raphaelm]

It's probably worth keeping this ticket, since the use case is significantly different from #1001:

My use case is like this:
if you order <5 you pay the full price
if you order 5-10 you will automatically get 5% discount without selecting any special product
if you order 4 and later order 3 you will get the discount for all of them
if you order 10 or more you will get 7% discount
The thing that I would to avoid is that the user has to select a special product.

[DerDakon]

I have looked into this and the plugin API. For me it looked like this could be implemented as a "fee". What looks missing is a callback for refunds, as the same code needs to run then. One would need the data about the other orders when the callback is run, especially in the refund callback: if one orders 4, then another 2 the discount would be used. If one then cancels the first order the remaining price has to be 2xfull price.

[raphaelm]

I have looked into this and the plugin API. For me it looked like this could be implemented as a "fee".

This looks like the easiest option, yes. Especially, so far it is the only option I could come up with that allows handling this in a plugin instead of the core system, so I like it.

The downside of using a fee is that it not actually changes the price of the order positions. This means that it a) shows up as a separate line in the cart and on the invoices (which might actually be a good thing), and b) makes the "order overview" and other statistics harder to read.

The alternative would be to somehow calculate this in every place where we call pretix.base.services.pricing.get_price, or give get_price additional context on other positions in the cart. However, this would require changes in a lot of places and it would be easy to get it wrong.

What looks missing is a callback for refunds, as the same code needs to run then. One would need the data about the other orders when the callback is run, especially in the refund callback: if one orders 4, then another 2 the discount would be used. If one then cancels the first order the remaining price has to be 2xfull price.

I'm not quite sure if we're talking about the same thing or just using different words, but yeah. We wouldn't need a hook for order refunds (since in an order refund, all tickets are returned always), but for manual order changes (i.e. when an order of size 10 gets changed to size 5), right?

I don't think we should try to apply the discount across orders, i.e. if the user orders two times three tickets in two separate orders.