unit price in order_itemmeta is wrong

[tofuSCHNITZEL]

I'm not 100% sure what is going on but the unit_price saved in _unit_price_raw, _unit_price_subtotal_raw, _unit_price_net_raw, _unit_price_subtotal_net_raw in order_itemmeta is wrong.

after checkout:

if I check "public function recalculate_unit_price()" in class-wc-gzd-order-item-product.php I see that its not using the products "_unit_price" attributes at all.

I don't get why there is so much calculating and "subtotals" in "recalculate_unit_price" at all... since the unit_price is fixed and does not depend on how many you buy. also to differentiate between unit_price in net and gross makes no sense imho. since the unit price follows the same logic as the sales price... is the shop in net values the unit_price is also net - is the shop in gross prices the unit_price is also in gross. so I dont see the need to have a seperate unitprice(subtotal)_net_raw)

[dennisnissle]

Hi there,

the thing is: Product prices (as well as unit prices) might change. That should not affect the order item. That is why on ordering or changing the product linked to the item, the unit price data is copied from the product to the order item and from now on all recalculating (e.g. when order totals are being recalculated) happens within that object without the need of using product data (which might have changed already). Net and gross prices might be necessary depending on the tax status of the current order object.

[dennisnissle]

Regarding your example: I guess that your data does not match automatic price calculation. See this thread for more info: https://wordpress.org/support/topic/grundpreis-falsch-auf-finaler-dankeseite-vorher-richtig/

[tofuSCHNITZEL]

yes I totally understand and welcome that product attributes get saved as order_itemmeta so that the attributes are preserved. But what I don't understand is why you need to calculate it on saving it to order_itemmata and not just copy the "_unit_price" attribute? Also why is there a subtotal version? the unit price is independent of how many items the customer gets?

In my case any automatic calculation will fail because we have products that cost 0€ but still have an unit price (for customer information), because the real price is determined in the shop when people pick up their order (because e.g. meat is weighed on pickup)

[dennisnissle]

What do you exactly mean by _unit_price? The actual price per unit or the formatted price? Not only do we need the actual unit price but the unit, unit_products and unit_base as well (to enable recalculation).

Check the following scenario: A customer has ordered a product in the store. Product prices are updated frequently (every hour). The order is now being processed. The shop manager wants to adjust the item prices (subtotal, total) because a mistake has been made. What would happen to the unit price? It would be wrong if no recalculation was made. Recalculations are only possible if the data exists. I know these are edge cases but still they do exist and lead to trouble.

In my case any automatic calculation will fail because we have products that cost 0€

Yep that might be a problem. You might want to use the woocommerce_gzd_recalculate_order_item_unit_price to hook into the item after recalculation has been done and adjust unit prices accordingly.

Cheers

[tofuSCHNITZEL]

with "_unit_price" I mean the meta field that exists for a product. which is, on a non "sales" product, equal to "_unit_price_regular" field -> "Regulärer Grundpreis" this is a float and not a formatted field.

yes my workaround now is just to overwrite the unit price order_itemmeta fields with the direct value of the products "_unit_price"