Taxes being added twice to unit price on initial display

we are experiencing the same issue.

i thought it might be something regarding jQuery version or theme based (we are using Adminimal), but it's not - i trie several versions and and the issues still appears.

thank you for tracking this down. i was digging trough the POS module, and looking for the reason there.

we have the same configuration (taxes are included, checkbox in tax configuration is active). but i need to make a fresh copy of the live site first to properly test it and give you feedback about it.

as you say there are some more issues when the product price includes taxes, so in general, would it make sense to store the netto price, then add tax and configure the rounding?
this just seems much more math then the other way around, and that can always cause issues, as we see.

Hey Ollie222,

My understand if this issue is that it is related to commerce in general and its general wonky tax logic, not anything specific to POS. Marking as "Works as Designed" but feel free to continue discussion in this issue if you want.

Cheers,

I tested the behavior in pos and trough the checkout when the VAT is not included in the product price.

When I was searching for the product trough the SKU-search-box in POS, i got the result displayed with price including the VAT. When I added the product to the list it used the price displayed (including VAT) and the result was exactly the same as before (too much VAT).
I reindexed the search index a couple of times, and flushed caches as well. The behavior remained the same.

It seems to me, that POS pre-calculate the price indexed, and then adds the VAT trough the GUI again..?

When ordering the same product trough the store and order process everything works like expected. The price is displayed processed, including VAT.

The POS is installed on a clean Drupal commerce setup, not on kickstarter, so could that be an issue?

Just ran some investigations. Tracked it down to the call to `$base_price = commerce_price_component_load($line_item_wrapper->commerce_unit_price->value(), 'base_price');` on line 242 of commerce_pos.transaction.inc.

The first time you add the item to the list, it loads the line item's "base price". But for whatever reason, the base price is the expected base price + inc vat, AS WELL as a vat price component. But then, like @mirko8003 @Ollie222 mentioned, if you click in the text field then back out, the line item comes in with the expected price components.

But the POS still displays some weirdness (pic). It again grabs the total, but really should just get the base price. I wasn't able to track it any further back to see if it's a commerce issue or POS though.

I'd like to add to @thejacer87 notes, that it's something related to line 255 of beta8 (and prev.) in CommercePosTransactionBaseActions.php

  public function setLineItemPrice($line_item_id, $price) {

which is somehow related to line 10 of commerce_pos.transaction.js

      $('.commerce-pos-hidden-element', context).each(function() {

Hope someone smarter can shed some light on it; I've made a pull request https://github.com/AcroMedia/commerce_pos/pull/14 which seems to fix the issue, yet it looks more complex than that.

I'm having the same problem. When I don't check "Display taxes of this type inclusive in product prices." in de Tax settings, then the correct price is calculated in the POS. But then customers see the prices with the tax not included, so this workaround is not an option for me.
As a workaround, I made the following change in the CommercePosTransactionBaseActions.php file:
below line 178, I added a line to recalculate the amount to the price without VAT:
$amount = $line_item_wrapper->commerce_unit_price->amount->raw();
$amount = $amount/1.21; // substracts the VAT from the amount

@eem88 This may be the way to go; what if we replace hard-coded VAT (1.21 in your case) by VAT value picked from, say, one of the Tax module hooks?

@wildkatana what are your thoughts on a full fix? I'd rather do that then a temp one, but if the full fix is a big effort, we should probably commit this temp one.

Setting this back to "needs work" to get a fix that shows the components properly as well.

Patch looks good from a manual code review, but it has conflicts preventing it from applying, mind rerolling/rebasing and I should be good to merge in.

merged