Explaining the logic of price lookups in ERP5 Trade (needs review).
Table of Contents
Price lookup logic¶
Trade transaction (sale/purchase) is represented by a Movement which defines the
price charged. Price is obtained from the Movement by Movement.getPrice method.
The way the price is calculated works as follows:
-
if a price is set locally on the Movement, it is returned without any further ado
-
then look for a type-based method [PortalType]_getPriceCalculationOperandDict,
which if present should return a dict containig at least the 'price' key -
this price is then used
-
then the accessor uses a method "Movement_getPriceCalculationOperandDict" which:
- if the Movement has no 'resource' defined returns its 'default' argument
- if the Movement has 'explanation' related object (usu. and order or an invoice), looks for applicable TradeCondition objects
- calls Resource.getPriceCalculationOperandDict
-
the Resource.getPriceCalculationOperandDict looks for a type-based method [PortalType]_getPriceCalculationOperandDict
(but this time on the Resource's portal type)
-
then it looks for a type-based method [PortalType]_getPrice which can return
just a price
-
failing that, it applies a mindbogglingly complicated logic to calculate a
price and a number of price-related parameters (e.g. discount) from Sale/Purchase
Supply Lines, using also trade condition lines it may have received from the
caller
Customisation¶
In nearly all cases, it is sufficient to use either the first or the last point,
which means:
-
set the price locally on Movement using Movement.setPrice method
(programmatically or using a form field)
-
create and configure Sale/Purchase Supplies to define a price of a resource,
possibly differentiated by date, buyer, buyer's region, product variation or
whatever you want - Supplies are a powerful tool
If you really need to apply your own logic, create a [PortalType]_getPriceCalculationOperandDict
method, either for a Movement or for a Resource ([PortalType]_getPrice is
deprecated)
Related Articles¶