Enable different fees to be charged based on tag used


#1

A hub apply 3 different fees (%) depending on the situation of the member : 0%, 10%, 20%.
In my order cycle I create one line for the distributor “Alterconso Perrache”, and in tag I put “reduced fee”, and in entreprise fee I add the “10%” one. So all the users who have the tag “reduced fee”, when connecting to the shop, will see the prices that correspond to their situation.

My issue is: I cannot add “Alterconso Perrache” a second time as a distributor in the order cycle, to say that for tags “no fee”, we charge nothing (no entreprise fee added) and another line to say that for tags “full fees” we charge the fee "20%.

The only way to do today is to create for each OC, 3xOC with a different tag and fee for the “Alterconso Perrache” line in each of them.

I’m already creating 4 OC for this hub (they do deliveries on 4 days per week in 15 local hubs) so if I can’t find a solution I have to create 12 OC each week… which is sincerly not managable.

Questions:
1- Can we enable to call in outgoing multiple times the same distributor ? That would solve my problem.
2- Or can we add a new tag rule that makes a fee applicable/non applicable ? That way I could create a tag rule for each fee and then add the 10% et 20% on the same OC line, as each would apply only to the relevant buyer.

I will open a github issue but wanted to know which option would fit best our logic, and here are the discussions to agree on the spec, so here I am :slight_smile:

Ping @sstead @oeoeaio @nick @lin_d_hop @enricostn @Kirsten thanks for your input this is high priority in France.

Github issue when spec is ok : https://github.com/openfoodfoundation/openfoodnetwork/issues/1824


An enterprise can give a product multiple prices given customer category
WIKI - ordered inception backlog (discovery and inception)
#2

I think it would have to be the second option because if we put the same distributor in the same order cycle multiple times, we would likely have to do a lot of fiddling with how the shop loads the order cycles . .

but I am actually not that familiar with tag rules and have no idea how hard it is to change them. @oeoeaio would perhaps be the best person to comment on how doable that is


#3

I also can’t say whether option 1 or 2 would be easier to develop, but I think option 2 sounds more logical and easier to explain to a user.

I think the % discount tag for customers would work for this scenario? Rather than avoiding fees, you could apply a discount. I understand that discount tags is held up by the spree upgrade (due to tax issues), but I wonder if it would be better to focus on getting the discount tag working? Just a thought.


#4

@MyriamBoure’s option 2 would solve a problem I have also - I’ve been looking for a way to tag fees (for example to remove them or change them) for different distributors. But a further question @MyriamBoure about the reports at the back end. How will your coodinator (or you) calculate the different fees in order to make correct payments? I don’t think there is a ‘fees’ report that itemizes fees. I’d like to have one - is this something you’ve figured out?


#5

@sstead I think % discount tag could definitely work, the importance as pointed by @tschumilas will be to ensure that there are adapted reports that enable the hub to know which % paid each customers, and the total amount for each % fee. I’ll have some deep thinking on it and try to draw some mockup :wink:
@enricostn which version of spree should we wait before we can work on that ? This is kind of core for that buying group and I see them on Thursday so need to see how we can phase our answer to their need. I guess you also need that for your buying groups :wink:


#6

I agree, we need that report.


#7

I had another thought at all that and studied again the two options:

- Option 1 = Make en entreprise fee applicable / non applicable.
So imagine 2 enterprise fees : “10% reduced fee” and “20% normal fee”, in the OC outgoing distributor I put the two fees.
By default tag rule is that all fees apply to all customers.
One tag rule is: if customer tag = member, entreprise fee “20% normal fee” = unapplicable
The other is : if customer tag = non member, entreprise fee “10% reduced fee” = unapplicable
When the customer is logged in, only the fee corresponding to his tag applies so he sees the shopfront and products with the good price.
We need to check if you change something in the order that it recalculates fees correctly.
He can also set up another by default rule like:
Entreprise fee “10% reduced fee” = unapplicable to all customers
So even if the two fees are in the outgoing distributor section, by default customers will see the prices with the 20% fees applied.
Tag rule can then be : If customer tag = member, then “10% reduced fee” = applicable AND “20% normal fee” = unapplicable.
Another tag rule could be : If customer tag = low income, then “20% normal fee” = unapplicable (so the user has no fee applied to him)

Here is quick mock-up :


Note : if I remove a user tag, we need to make sure it doesn’t change the history in the past orders… I guess that’s ok but just to keep in mind.

- Option 2 = we take the % discount approach :
Default rule = no one has any discount
Tag rule can be : if customer tag = member, apply x% discount on all products in the shopfront.
The problem is that the discount logic is not implemented yet in OFN yet, so how would that appear in the shopfront and order ? The reduced price might be displayed as discount so that the customer is aware that a discount has been given to him, so even in terms of UX I guess it will be different. Like the price will be crossed and the new reduced price will appear as a side in bold or red.
In back office, only the reduced price should be taken into account even when we recalculate fees, even if the tag has been removed after the order has been made (so the system need to remember for each order which discount was applied to this given customer as the tag might have been removed).
I think the two logics are different, but you can easily apply a discount to a member by setting up a different fee and using the first logic.
It also has a calculation implication : If Pp=product master price, Pn = price for normal users, Pr = reduced price for members
1,2 Pp = Pn [20% fee on Pp to get the Pn]
Pn - YPn = Pr = 1,1 Pp [Y = discount, ex: 10% discount for members. Here assumption = the hub want to charge the member 10% fee instead of 20% so I need to calculate what discount to apply for that]
1,2 Pp = 1,1 Pp / (1-Y)
Y = 1-(1,1 Pp / 1,2 Pp)
Y is the discount to apply if the hub want to charge a 10% for this user instead of a 20% fee… it is not super friendly to ask the hub who has not this “discount” logic to make those kind of calculation in order to find the % discount, no ?

So I would suggest to implement both tag rules actually as they serve two different logics.
And as our user needs the first one I suggest to start with this one. Also it seems easier to me as we don’t need to build the discount logic.

@tschumilas @sstead @Kirsten @enricostn @lin_d_hop if that fine with you I suggest we move forward for now with the applicable/non-applicable entreprise fee tag rule as described above. I don’t even thing we need to change anything in the reports actually… we’ll need to check when moving forward.


An enterprise can give a product multiple prices given customer category
#8

Tagging Enterprise Fees sounds logical to me :slight_smile:


#9

Awesome, described the spec on Github https://github.com/openfoodfoundation/openfoodnetwork/issues/1824 waiting a few more days for people to react if they want, else we gonna go ahead with that :slight_smile:


#10

Closing that topic as listing potential solution for the need “charging different prices for different customer categories”. Using tag and fees is just one potential solution, but discovery is going on and other solutions are being considered. See An enterprise can give a product multiple prices given customer category for the main discovery thread.


#11

#12

#13

#14