How to handle overrides on purchases that cause an error on the invoice?

Modified on Tue, 27 Jun 2023 at 03:51 PM

Scenario

Purchases in CloudBilling can have Overrides for the Unit Price, Unit Cost, and Total Purchase Price. The Override Unit Price and the Override Unit Cost were ignored when passed to aggregating pricing rules (e.g. SUM, LADDER, GROUP PRICE). The quantities of the purchases were, at the same time, not taken into consideration by the aggregating pricing rules.

The change now enforces the overrides to be handled explicitly, by the use of a PRICE pricing rule.

Reason

Before this change, if a purchase with an override price or cost went into a sum rule without first passing through a price rule, the sum rule would simply take over the override price and cost of the purchase. This is not neccesarily correct for the price and almost certainly incorrect for the Override Cost (because the quantity is not considered). This may result in incorrect values or costs on your invoice.

What has been changed?

Aggregating pricing rules (e.g. SUM, LADDER, GROUP PRICE) will now not allow the input of Overrides on purchases, as this is very likely incorrect behaviour and will result in unexpected results on the invoice.

To make sure the abovementioned scenario does not occur unbeknownst to you, it will now cause an error on the invoice, enabling you to address the issue.

How does this functionality work?

When a purchase with an override price or cost goes into an aggregating pricing rule without first passing through a price rule, the invoice gets an 'Error' status. If you hover over the 'Error', it will show the text 'CalculatedError'.

How can you start using this functionality?

First verify internally why the overrides are used, what is the expected outcome of the use of the overrides on the purchases.

If the override is needed, the pricing plan might need to change as it is currently not functioning as expected (probably incorrect pricing plan).
If the override is not needed, the purchases should not specify an override, as it is not used in the pricing plan (do not use overrides that will be overridden and are useless).
If the override is not needed, but it still needs to be specified, we will make a PRICE pricing rule on a lower level than the lowest pricing rule in the price plan.

Attachment, Bouke's mails:

Hi all,

It seems to be that there are some misconceptions about the override handling change.

Before this change, the billing engine would ignore these overrides when passed to aggregating rules (sum, ladder, group price etc).
With this change, the billing engine enforces overrides to be handled explicitly (price).

Customers are creating purchases with overrides. With these changes, their invoices go into error. I've noticed that in order to fix the errors we've began adding price rules to ignore the overrides. This is not a good default! We need to assume that the customer has entered the overrides deliberately. And if they did that, then adding rules to ignore their deliberate action will result in incorrect invoices.

First verify with the customer why they are specifying overrides. School them on what an override is, how it works, and what it needs.

When they are aware, decide with them on the appropriate action:

they need to use the override: great, their price plan was wrong and needs changes
they don't want to use the override: they should stop specifying the override
they don't want to use the override, but need to keep specifying it: only then should we be creating price rules to ignore the overrides, but only as a last resort

Also note that the error is currently still opt-out. So if the error is blocking a billing run, ask Jesse to temporarily disable the check.

Met vriendelijke groet/kind regards,

Bouke Haarsma
CloudBilling

On 6 Jun 2023, at 10:32, Bouke Haarsma <Bhaarsma@cloudbilling.nl> wrote:
This is an announcement of a change in CloudBilling with regards to purchase overrides.
On a purchase you can specify overrides, which might get taken into account when calculating an invoice. There are three different overrides:, Unit Price, Total Purchase Price and Cost. Currently these overrides work as follows:
When a purchase is input to a rule with the Price operator:
When Override Total Purchase Price is set, no unit pricing is performed.
Value = Override Total Purchase Price
When Override Unit Price is set it overrides the per-unit price.
Value = Quantity * Override Unit Price
When Override Cost is set it overrides the per-unit cost.
Cost = Quantity * Override Cost
When a purchase is input to a rule with an operator other than Price:
The Override Total Purchase Price is ignored.
The Override Unit Price is used as the Value.
Value = Override Unit Price or 0
The Override Cost is used as the Cost.
Cost = Override Cost or 0
The behaviour in the case of the Price operator is as expected. However for rules with an operator other than Price the behaviour is deemed incorrect. We've already seen that this behaviour causes confusion and unexpected results. A purchase with an override for Total Purchase Price might for example show up as 0 on the invoice, where a purchase with an override for Unit Price might not take the purchase's quantity into account.
Next week we intend deploying a change to correct the behaviour for pricing rules other than Price. The new and expected behaviour will be as follows:
When a purchase is input to a rule with an operator other than Price:
The Override Total Purchase Price is used as the Value.
Value = Override Total Purchase Price or 0
The Override Unit Price is ignored.
The Override Cost is ignored.
You'll notice that the Override Cost is now ignored, which is expected as that override is specifically, like Override Unit Price, a per-unit amount. We don't expect this change to have a profound impact, as such purchases are typically already input to a rule with operator Price. Nevertheless this means that on the cost-side there might be differences as overrides no longer have an effect. It is not ideal to silently ignore input in such a critical process, so we're making this a configuration error and fail the invoice calculation in such cases. The error conditions will be as follows:
When a purchase is input to a rule with the Group Price operator:
Having any override results in an error.
When a purchase is input to a rule with an operator other than Price and Group Price:
Having overrides for Unit Price and/or Cost results in an error.
As we don't want to cause interruptions for the ongoing billing runs, these errors opt-in starting today. As we deploy the change depicted above, we simultaneously make the errors opt-out so we don't silently ignore overrides. The ability to opt-out will be removed after a few weeks to ensure proper functioning of all pricing rules. Jesse can arrange these opt-in and opt-outs on request starting today.
Met vriendelijke groet,

Bouke Haarsma
Solution Architect