Pricelists in Odoo have a structural problem and very severe shortcomings.

What is supported? What is not supported?

Odoo supports multiple price lists that are ordered sequentially. A single price list can be assigned to one (1) customer/contact. There can be also one (1) default price list.

For non-recurring products a price list supports different prices or discounts based on a minimum quantity and or time frames.

Recurring product prices on the other hand can only depend on the recurring plan (monthly, yearly,...) with no option to make them depend on a quantity and or time frame: 

Problem 1: Discounts or formulas are not supported for recurring products at all!

Real-Life Example

The company Contoso Ltd.

1. sells:
   
   
2. 1.  Software licenses (one-time purchase)
      
      
   2.  Software subscriptions (recurring).
      The price of the subscription depends on a minimum quantity (number of seats) and on the selected min. duration (customers selecting a longer initial contract duration get a discount).
      
      
   3.  Usage-based recurring products.
      Customers can use resources that are billed monthly. Customers get discounts if they cross certain thresholds.
      
      
3.  has different prices and discounts, depending on a geographical region and customer/partner level.

The only scenario that is supported by Odoo without restrictions is 1a (the one-time purchase of a simple product).

Problem 2: Recurring pricelists can not be applied a product category.

Every single recurring product has to be entered separately which makes pricelists basically unusable. A discount cannot be applied to all recurring products of a product category and not even to all variants of a single product.

Imagine a subscription product that has 7 variants, 3 billing periods (monthly, quaterly, yearly) and 10 applicable pricelists. This makes 210 individual recurring prices that need to be entered for a single product! 
Despite this insane amount of work, minimum quantities or duration discounts cannot be modeled at all!

Let's look at the structural problem of pricelists:
A pricelist assigned to a customer needs to contain prices for every single product the customer may receive a discount for – or else the default pricelist is being applied. There is only one (1) fallback.

Problem 3: Pricelists should be organized in a tree – not as a list.

Given a situation where

• different regions have different pricelists and
• within those regions different customer levels have different discounts and
• within those customer levels there might be individually negotiated prices,

it becomes clear that a tree-like structure is needed to model these requirements.
A pricelist needs to support a parent pricelist that is recursively applied if no matching condition is found within the current pricelist.

For example:

• Default Pricelist
• • Region A Pricelist
  • • Consumer Customers (Region A)
    • • Consumer A (Region A)
      • Consumer B (Region A)
    • Reseller Customers (Region A)
    • • Silver Partner Discount Pricelist (Region A)
      • Gold Partner Discount Pricelist (Region A)
      • Platinum Partner Discount Pricelist (Region A)
    • Silver Partner Discount Pricelist (Region A)
  • Region B Pricelist
  • • Consumer Customers (Region B)
    • • Consumer A (Region B)
      • Consumer B (Region B)
    • Reseller Customers (Region B)
    • • Silver Partner Discount Pricelist (Region B)
      • Gold Partner Discount Pricelist (Region B)
      • Platinum Partner Discount Pricelist (Region B)
        
    • Silver Partner Discount Pricelist (Region B)
      
  • Region C Pricelist
  • • Consumer Customers (Region C)
    • • Consumer A (Region C)
      • Consumer B (Region C)
    • Reseller Customers (Region C)
    • • Silver Partner Discount Pricelist (Region C)
      • Gold Partner Discount Pricelist (Region C)
      • Platinum Partner Discount Pricelist (Region C)
        
    • Silver Partner Discount Pricelist (Region C)

This tree needs to be traversed upwards until a matching condition is found. Otherwise all product prices would have to be duplicated. Updating product prices currently is a nightmare.

A region A silver-partner will be assigned a "Silver Partner Discount Pricelist (Region A)". If a product is not specific to silver partners, the Region A Pricelist may be applicable and ultimately the Default pricelist.

A tree-like structure is not only more efficient and faster, but also more flexible and user-friendly.