During edit of an order, I am overriding the unit price of a line item.

Saving the order triggers the pricing calculation, including multiple tax rules. However, even though I confirmed my particular tax rule function is being called, the line_item object does not appear to be saving. Upon viewing the updated order, the tax value applied is not correct.

I added the "After updating an existing commerce line item" event to the standard "Calculating the sell price of a product" event to ensure my rule was firing.

This particular tax rule has 2 actions - the first is the standard "Calculate taxes for a line item" - this applies a 3% tax to the sub total. Everything is swell. The second rule applies custom logic to the tax, basically adjusting the rate based on exempt amounts, etc. I know the function is running and that it is calculating correctly. Once I view the order, though, the tax is the standard 3% as applied by action #1.

So, with order status "Pending," I can update the order status to cart (or use the new "refresh pricing rules" process), and the tax values apply as I expect. Of course they do this during normal order creation (admin order creation or standard guest purchase) as well.

Some other process is apparently modifying the line item after this rule, as I see it. I'm just not clear where.

Thanks so much for any help and input!

Comments

rszrama’s picture

Category: Bug report » Support request
Status: Active » Postponed (maintainer needs more info)

Have you turned on Rules logging to see what's being executed after your rule? And what is this custom action? If you're directly manipulating the price, perhaps you just aren't updating the amount and price components properly.

ben.hamelin’s picture

Thanks for the quick response. Enabled the logging.
The custom action is directly modifying one of the tax components as follows:
$line_item->commerce_unit_price['und'][0]['data']['components'][1]['price']['amount'] = $new_tax_total;
This of course works fine during standard ordering as well as when the order is forced to recalculate.

I'll review the logging and update tomorrow. Again, thanks for the very quick response!

rszrama’s picture

Just make sure that any manipulation you do of the components is reflected in the amount as well (if necessary that is, such as for VAT).

ben.hamelin’s picture

Ok, I've reviewed the Rules logs, and the code in commerce_tax_rate_apply().
Also changed my triggering event from "after saving line item" to "before saving line item."

Still no luck. Same symptoms, my action method is invoked and affects the tax price but is not saved. As soon as I use the "Apply Pricing Rules" form or place the item back into shopping cart, at which point price is recalculated to original base price, all taxes apply correctly.

So, from the rules logs, the event that DOES fire when applying pricing rules (or placing order back into shopping cart state) is the "Reacting on event Calculating the sell price of a product." This must be the process that is properly applying my tax amount override. Of course this is the same event that fires during initial creation of the order, where I have no problems, so that all makes sense.

My follow up question would be what is happening in sale price calculation process that differs from "After/Before saving a line item" processes?
The function is definitely called, but line item not saved. I thought about calling commerce_line_item_save() but that sounds like a recipe for infinite loop fun! You mentioned in one of your presentations that w/ PHP5 the line item is passed along by reference - this seems to me like that might NOT be happening during these other events?

donutdan4114’s picture

Not sure this is the same issue, but when overriding the line item unit price, it does not appear to save.
If I have a product that is $10, and I override the line item unit price to be $20, and save, it will show $20 in the admin interface (all good so far).

If I go to complete the checkout process, the order will show up with the $10 price (not good).

When I flush all caches, in the order admin the price will be changed back to $10 (not good).

So, not really sure what the issue is exactly.

donutdan4114’s picture

Component: Tax » Line item
Category: Support request » Bug report
Status: Postponed (maintainer needs more info) » Needs work
jmaties’s picture

The same issue with the new version 7.x-1.11 :(

jmaties’s picture

Version: 7.x-1.9 » 7.x-1.11
petu’s picture

Acording to https://www.drupal.org/node/2408705 try to downgrade rules to v 2.7

Important: Rules 2.8 has a critical regression that causes checkout rules to not work. Follow #2403851: Commerce pricing rule not working for more details, and downgrade to 2.7 for now.

It helps me with the same issue.

rszrama’s picture

Version: 7.x-1.11 » 7.x-1.x-dev
Category: Bug report » Support request
Status: Needs work » Closed (works as designed)

I'm not sure what to make of this issue, as it appears to be communicating three different things. However, as worded in the most recent comments, this seems to be working as designed. You cannot simply set a line item unit price / total price field directly and expect the custom values to persist through the shopping cart refresh. The refresh enacts a price calculation from scratch, which begins with the product base price and alters it according to a site's pricing rules. Direct manipulations are unsupported and instead need to be represented in the pricing rules.

sujith.nara’s picture

Line item not saved in my case too.

Event: After updating an existing commerce order
Action: (Custom rule action) which invokes commerce_line_item_unit_price_subtract()

This was actually used for 'split payout' action in commerce_payout sandbox module.