Conga Product Documentation

Welcome to the new doc site. Some of your old bookmarks will no longer work. Please use the search bar to find your desired topic.

Show Page Sections

Understanding Pricing

In order to work with prices, you will need to understand how pricing works. There are 2 forms of “pricing” logic:

  • The pricing used on the sales breakdown lines
  • The pricing used on standard items

Pricing on sales breakdown lines

In order to calculate one or multiple prices for a sales breakdown line, at least one pricing method needs to be defined, but in general, multiple pricing methods can be added. This can be graphically represented as follows:



The pricing algorithm works as follows:

  • Calculate prices bottom-upwards
  • Calculate prices in the order of modeling of the pricing methods
  • Calculate prices only if demanded by the user
  • Take into account session variables to include or exclude certain columns

The pricing calculation works bottom-upwards, as shown in the following table (begin with the green dot):



Moreover, the order of calculation between pricing methods follows the modeling order, as shown in

the following table by A, B and C:



Prices are only calculated when specifically demanded by the user, meaning that D and E will not be calculated:



Finally, session variables can be taken into account. If no special “pricing method” variables have been defined, all above-mentioned pricing methods will be calculated. However, if pricing method session variables have been defined, only those will be calculated.

CPE.Settings.Session.PricingMethod[1]=“PRGM/CustomerPrice”

CPE.Settings.Session.PricingMethod[2]=“PRGM/DistributorPrice”

These session variables will have as en effect that the pricing method “ReferencePrice” will not be calculated:



Standard item pricing

Prices on standard items follow a particular algorithm that works as follows:

  • For every alias used in the pricing method, determine the value.
  • Look up the standard item for which the price has to be determined in the pricing grid.
    • Look up the “most matching line” for that standard item, based on the line with matching values which has the minimum number of “*”.
    • Be careful of modeling a grid that returns only one “most matching line” for any case.
  • If the item has not been found, determine its sales product hierarchy, and do the same lookup for each ancestor, starting with the “closest” one.

This algorithm should always issue a result. In order to ensure that a result can be found, make sure that for each item, or at least for each sales product, at least one line exists which gives a default price.

Definition: A default price corresponds to a line which as “empty” values for all aliases.

In order to illustrate this algorithm, let’s have a look at the following example.

Example

In the following example, the standard item pricing grid associated to the pricing method contains 2 aliases, aCountry and aColor. aCountry is a “static” alias, pointing to a session variable. aColor is a “dynamic” alias, pointing to a form property in the current model:

NAME CPE
aCountry CPE.Settings.Session.myCountry
aColor CPE.workspace/CP/cpCar.workspace/FO/foBody.FP/fpColor.value


When the price of a standard item has to be calculated, the algorithm is executed. The following table shows an overview of which results will be issued in different situations. This table shows the price calculation for SI001, SI002 and SI003. SI001 and SI002 have a parent Sales Product SP001; SI003 does not have a parent.