Price Rules Overview
The pricing rules defined in CloudBilling express the pricing plan. Each pricing rule has an operator and is defined on a combination of a Product Cluster and Customer Cluster. It then applies to each Purchase whose customer is a descendant of the specified Customer Cluster and whose Product Cluster is a descendant of the specified Product Cluster. When we say descendant here, we mean any Product Cluster which is in the subtree rooted at the specified cluster (including this cluster itself). The rules are applied to the subset of Purchases they are applicable to under the conditions specified above. Each time a price rule is applied a result is generated, the collection of the results of these rule applications form the basis of the Invoice. On each pricing rule the option exists to specify whether or not to output the results to the Invoice. If this option is checked, the pricing rule results are transformed to InvoiceItems by adding an InvoiceLabel to them according to the specified key, otherwise, the results are not transformed into InvoiceItems and are therefore not shown on the Invoice.
CloudBilling has a number of different operators that allow us to support very complex pricing plans. Currently CloudBilling has defined the following operators:
| Operator | Description |
|---|---|
| Price | The Price operator specifies a unit price. |
| AdjustFixed | Adjusts a calculated result with a fixed amount. |
| AdjustPercentage | Adjusts a calculated result with a certain percentage. This operator can be used to calculate the VAT, discounts or indexation. When the value is negative the percentage is deducted from the calculated result. |
| Sum | The Sum operator sums all previous results over the specified product cluster. If there are no previous results, i.e., if the Sum rule is the first rule applied (before any price rule for instance), then the quantities are summed instead. This can be useful for applying ladder rules to the total usage in a period, instead of to individual Purchases. |
| GroupPrice | The GroupPrice operator acts like the Sum operator. Only after summing the values of the underlying items, the summed value is replaced with the operatorValue. |
| Ladder | The Ladder operator can be used for tiered pricing. This operator offers detailed functionality to apply it for various kinds of services. Both segmented and staggered ladders are supported. |
| MaxPrice | The MaxPrice operator can define a maximum price charged for a product cluster. |
| MinPrice | The MinPrice operator can define a minimum price charged for a product cluster. |
| Bundle | The bundle rule checks the usage against all of the bundles associated with the customer and determines whether it fits in any of the bundles. If so, the inBundle rate is applied. Otherwise nothing happens. This construction means that if an out of bundle rate needs to be applied, there has to be a separate price rule that is ran before the bundle rule to apply this rate. The bundle rule will then overwrite this default out of bundle rate if applicable. |
Rule Order
It is possible to apply multiple price rules on the same Customer Cluster and Product Cluster combination. When this is the case it is important to give each rule the right order. By default, rules in CB are applied in the following order:
- Starting at the most detailed Product Cluster, moving upwards;
- Then, ordered by the Rule Order value provided;
- Finally, from the least detailed (i.e. highest level) Customer Cluster level, moving downwards.
If there are 2 or more rules that share a Product Cluster, Rule Order, and Customer Cluster, we enter a situation known as “Component Pricing”. In this situation, these rules are executed in parallel, and as such, there will be a result created per rule in parallel “streams”. This is useful when you want to calculate pricing for items that are made up of several separate cost components, which will require different subsequent calculations.
Rule Validity
It is possible to define a Valid from Date and Valid to Date on each pricing rule. With these dates you give the price rule a validity. The rule will only be valid during this period and will only be applied to Purchases that have a timestamp within this validity period. Please be aware of upcoming end dates. If the valid to date is not selected, the rule will be applied indefinitely. If the Valid form Date is not defined either, the rule will be assumed to be valid at any point in time.
ProRata
Pro-rata options define how to handle time based Purchases with regards to pro-rata pricing. The charge per setting determines the amount of time that represents a full Purchase. I.e., charge per month means that usage of a full month counts as one unit purchased. If Purchases arrive with a duration that is part of this amount, the rounding parameters come into play. We can define how the start and end of the period should be rounded. There are 4 options for this round: Off, None, Up, and Down. Up specifies we should round up, so to the end of the month. Down specifies we round down, so to the start of the month. Off specifies we round up if we are on or past the halfway point of the month and down if we are before it. None means we do no rounding at all and simply use the value as is.
Billing Output Tags
Billing output tags allows additional output tags to be specified for a specific rule. Each of these output tags will be included in the XML invoice generated by CloudBilling. The output tag can be used in multiple ways, the most common use of billing output tags is to identify specific results that you want displayed on the PDF invoice. The tags can be imported to other systems also, like a general ledger classification for an accounting system.
Expressions and Conditions
When the normal conditions under which a price rules is applied are not sufficient for your pricing plan it is possible to a add Expressions and conditions to a price rule. We support expressions for both the Value and Cost of a price rule, allowing you to refer to properties of the customer, the Purchase and tabular data stored in the system. It is also possible to specify conditions, only when the condition is met the rule will be applied. We make a distinction between rule conditions and item conditions. Rule conditions are independent of specific Purchases, it allows you to set conditions on properties of the customer, for instance. Item conditions work on the purchase level. These conditions are checked for every Purchases that is matched against the rule. Therefore, these conditions can operate on properties of the Purchase as well.