Customer Price Lists and Quantity Breaks: What Should an Ordering App Decide?

Before adding customer-specific prices, define how the app chooses one applicable price for a particular customer, product, quantity and date. Then decide what happens when those inputs change. A collection of discount fields is not a pricing policy if two staff members can reach different answers from the same order.

This guide concerns selecting a price for a new or editable order. Whether an issued quote remains valid is a separate question. Tax treatment, consumer price disclosures and contractual commitments need appropriate professional review; the workflow below does not settle them.

Describe the price decision in one example

Bring a real pricing arrangement to the developer, with confidential details removed. Is a customer assigned a negotiated list? Does a product have a fixed special price? Does a larger quantity qualify for a different rate? Which currency applies?

A fictional trade customer might receive a negotiated product price while the public catalogue shows another price. That is not necessarily a percentage discount on today's public price. If the agreement is a fixed amount, storing only a discount percentage can change its meaning when the public price changes.

Odoo's official pricelist guide provides a concrete example of different rule types: discounts, formulas and fixed prices. It also documents a minimum quantity and a validity period. These capabilities illustrate the decisions to describe; they are not promises about your commissioned app.

Decide which rule wins

A customer agreement, category promotion and product-specific price may all appear relevant. Choose an explicit precedence rule instead of hoping that the lowest amount or the most recently entered record is always correct.

For example, Odoo states that a product-specific rule takes precedence over a product-category rule. That is a documented product behaviour, not a universal commercial rule. Your own agreement might exclude promotional stacking, allow a particular combination or require manual review.

Ask for an explanation beside the calculated price: the selected list and rule, the inputs used and any permitted adjustment. The internal explanation need not reveal your commercial agreements to every shopper. Specify who may see negotiated rules and whether the public storefront should display anything about them.

If two equally eligible rules conflict, choose a deliberate outcome: reject the configuration, require review or apply a documented tie-breaker. Do not allow a database row order to become an accidental business policy.

Make quantity thresholds unambiguous

A “ten or more” price needs a unit and a counting scope. Ten individual pieces, ten boxes and ten mixed products are not the same condition. Agree whether the threshold applies to one line, all lines of the same product, a category or a wider purchase commitment.

Also distinguish two different schemes. One can apply a new unit price to the entire qualifying line; another can apply different rates to successive bands of quantity. Neither should be inferred from the phrase “quantity discount.” Ask the developer to demonstrate the exact scheme you intend.

Changing quantity must trigger the agreed recalculation. If a customer reduces an editable order below its threshold, explain the new unit price before confirmation. An old discount must not survive merely because it was calculated earlier, unless preserving it is an explicit authorised exception.

Give dates and list changes a defined effect

A rule's start and end dates need a business time zone and clear boundaries. Decide whether the relevant date is order creation, confirmation, delivery or another agreed event. A screen showing a date range does not answer which event uses it.

Odoo documents a validity period during which a rule can apply to quotations. Do not turn that into a general claim about delivery dates, completed orders or your own implementation.

For saved drafts and open baskets, decide when prices are refreshed and how a change is explained. Recalculate before final confirmation according to the agreed policy, but do not silently rewrite historical prices on completed transactions. Preserve enough of the applied rule and amount to explain the recorded sale later. An issued quote needs its own version and validity policy rather than being treated as a live catalogue view.

Agree the fallback and the override

What happens when a customer has no valid assigned list, or the assigned list has no matching product? Possible policies include a public-price fallback or a request for staff review. Choose explicitly. A missing rule must not accidentally produce a zero price, reveal another customer's agreement or select an arbitrary list.

Manual adjustment is another separate requirement. Odoo's guide says pricelist suggestions can be overridden on the sales order. If you need restrictions, approvals or reasons, verify them in the chosen product or commission them explicitly. Do not assume a calculated value is uneditable.

For an allowed change, retain the original calculated price, adjusted price, reason and responsible person. State whether later quantity changes retain the adjustment or require fresh approval.

A short pricing acceptance exercise

For your ordering-app project, put these cases into the acceptance criteria:

• A public customer and a negotiated-price customer receive their intended results for the same product.
• A fixed customer price does not silently become a percentage-based agreement.
• Overlapping product and category rules have one explainable outcome.
• Quantities immediately below, at and above a threshold follow the specified unit and counting scope.
• The agreed whole-line or tiered calculation is demonstrated, not assumed.
• A price-rule boundary uses the specified business event and time zone.
• A changed draft shows the recalculated amount; a completed sale keeps its recorded historical price.
• Missing rules and manual adjustments follow their named fallback and approval paths.

The useful deliverable is a price that staff can explain and reproduce, not simply a complicated discount configuration screen.

Source boundary

The Odoo 19 documentation supports the examples of rule types, minimum quantity, validity, product-over-category precedence and sales-order overrides. The proposed explanations, threshold scopes, conflict handling and historical-price controls are planning requirements. It does not establish the legal effect of a price change or verify your tax and contract policies.