Reverse calculation messes up price components on discount

In my case this is what happened:
1. The first rate was calculated and applied (25%)
2. The second rate was calculated and applied (12%). At the same time the previous rate was recalculated and reduced (22 cents disappeared).

I solved it with the following patch:

       // Reduce components proportionally.
       $amount_to_reduce_total = $vat_price['amount'];
       $amount_to_reduce_left = $vat_price['amount'];
       $nonzero_components = array();
       foreach ($data['components'] as &$component) {
         // Do not handle existing VAT components
         if (array_key_exists(explode('|', $component['name'])[1], commerce_vat_rates())) {
           continue;
         }

The function commerce_vat_commerce_line_item_rebase_unit_price() (which handles updating the components when existing line item price is modified) also needs to be updated for this proportional calculation model. Marking as Needs work.

(Note that rebasing is currently broken in other unrelated ways and requires the patch from #2237853: VAT not applied if order is changed in backend)

@nwpullman2, Can you provide the price of the item and the tax values you got and what you expected? As far as I can see, it is expected that the previous tax component gets reduced:
1. Starting base price 100 EUR.
2. 25% applied => Base price 80 EUR, 25% tax = 20 EUR.
3. 12% applied => Base price 71.43 EUR, 25% tax = 17.86 EUR, 12% tax = 10.71 EUR.

With these values, the taxes match: 25% tax is on top of untaxed price: 71.43 * 0.25 = 17.86. 12% tax is on top of the previous total: (71.43+17.86) * 0.12 = 10.71 EUR.

With your change AFAICS the end result would be base 69.29 EUR, 25% = 20 EUR, 12% = 10.71 EUR, which doesn't add up properly - the 25% is calculated on top of Base+12% and the 12% tax is calculated on top of Base+25% - but one of the taxes should be calculated based on the base price.

But maybe I misunderstood, so an example would be helpful :)

Works for us. Will get back here as soon as we are in production with this.

Note for self: this patch is needed to because in case of a discount/giftcard line item the 0th price component (base_price) is 0 so we want to alter the 1st price component (which is discount|something or giftcard).

A small fix to the patch. In case we have more than one vat components on a line item (which happens for coupons when using https://www.drupal.org/project/commerce_vat_proportional) we don't want to apply vat on a vat component.

Which is the same issue as #5 and #6 if I get it correctly.

Adding a check if there was a nonzero component at all to prevent some notices.

Updated patch: avoid division by zero

Thanks for the catch! The patch in #11 changes the formula though. But I'd rather return early instead anyway.

The interdiff.