Users can apply fees to specific products/variants

What is the need / problem ?

Currently users can add fees for:

  • Delivery costs
  • Payment methods
  • On the order cycle
  • On a supplier

A common use case is that individual products from a supplier might have differing fees/markups. Examples from the real world:

  • I want to add a higher markup to frozen goods than to non-temperature controlled foods
  • I want to change the mark up for some products when the supplier enters a lower cost that undercuts other suppliers.
  • I want to put a different mark up on different products from our wholesale supplier depending on the availability of other suppliers in different seasons.
  • I just want the cost price in OFN to accurately reflect how much we paid. I’m tired of manipulating product prices because you dont let me manipulate the enterprise fees per product
  • I want the 10kg bag of salad to have a 8% mark up but the 100g bag of salad to have a 15% markup.

Who does it impact ?

All users that run real and complex businesses. Some users put flat fees across all products from a supplier, but most want to have more flexibility and they want OFN to record this flexibility so that the reports are accurate. They want to be able to use OFN for paying suppliers but the figures currently don’t match because they manipulate the prices. This also means the transparency of the price breakdown does not work well which is misleading to shoppers.

What is the current impact of the problem ?

This renders OFN significantly less useful to larger enterprises and limits the growth of enterprises as they are not able to maximise their revenues streams. It also costs these hub managers in the time spent reconciling the accounts.

What is the benefit of focusing on this ?

Makes OFN a better fit to the industry standard for e-commerce. This is something that users are actually surprised we don’t do. For most it feels like a really obvious omission.

Potential solutions that will solve the problem ?

[brainstorming to list feature candidates]

  1. Put the fee on the Product which is where the tax code is specified to a product.
  2. Put the fee ont the variant.

We want this to be editable in a number of places and there will be an inheritance element to this as well eg inherent fee from supplier. Inherent fee from Product (if fee can be added to variant).

Lots to discuss to get the scope of this right…

Selection of a feature candidate

[value x ease matric if needed]

T-shirt size of our selected feature candidate

This will be quite curly as it will need to satisfy VAT requirements and the changes will need to flow throughout reports etc. Not to be underestimated!

Metrics to measure if need is satisfied after feature is implemented

Feature owners

Epic/projet where you can follow implementation


Connected wishlist and discovery discussions*

[list precedent discussions]

I think in the network feature we did also some thinking about pricing table logic that is per product base… we will need it anyway. That question to me the fees logic. If we review the fees in this perspective maybe we could see if heading toward the pricing table logic could be an option as well in term of implementation.

I think the idea of using this opportunity to develop the pricing table logic. That would be marvellous!