Prices aren't consistent showing in cart

[qbixx]

Bug Description

For some reason the prices are changing inside the cart itself. Sometimes it shows the prices incl. vat, sometimes excl. vat, etc. And even sometimes someone places an order an all the products are gone. They only pay for the shipping.

I'm currently using the {{ items_total }} variable. When I try to use the {{ total_including_tax }} variable I'm getting an error (see screenshots below):

Steps to reproduce

1. Create product and set the settings to show the prices including vat
2. Add product (one or more) to the shopping cart
3. Sometimes the prices show incl. tax and sometimes excl. tax
4. In some situation the product is removed from the cart before a user places on order

Environment

Statamic 3.3.15 Pro Laravel 9.17.0 PHP 8.0.20 doublethreedigital/simple-commerce 3.2.6

[duncanmcclean]

I don't suppose you'd be able to add me to your site's repository and I can take a look?

[qbixx]

No problem, I will add you to the repo

[duncanmcclean]

Thanks! I'll take a look this weekend.

[duncanmcclean]

Just had a look around your repository and wanted to leave some comments:

• The {{ total_including_tax }} variable should be used instead of the product's {{ price }}, not instead of the {{ items_total }} variable (apologies if I said it worked the other way around in an email)
• When you configure tax rates, the 'Include in price' should really say 'Do product prices ALREADY include tax?' (this will change in the next version). SC will subtract the tax amount from the product price, rather than adding onto it.
• I was unable to reproduce the issue where Mollie was receiving the wrong amount - we give Mollie the grand total of the order, so something must have caused that to be wrong (maybe the product amount was somehow 0?)... If you can reproduce this, would you be able to push up the order to the Git repository and let me know what the order ID is and I can take a further look?
• Regarding the empty state on the checkout complete page, this will be fixed in the next version.

Hopefully some of that will help with the issues... I'll keep this issue open though in case you find any other pricing related issues next week. (release will be out shortly)

[github-actions[bot]]

Released as part of v3.2.9.

[qbixx]

Hi Duncan,

Thanks for the checks.

The {{ total_including_tax }} variable should be used instead of the product's {{ price }}, not instead of the {{ items_total }} variable (apologies if I said it worked the other way around in an email)

When I replace the {{ price }} tag for the {{ total_include_tax }} tag I get a similar error message Call to a member function raw() on null

When you configure tax rates, the 'Include in price' should really say 'Do product prices ALREADY include tax?' (this will change in the next version). SC will subtract the tax amount from the product price, rather than adding onto it.

The prices that are added in the back office should be the prices incl. tax. So e.g. the price incl. tax is 10,-. In that case the price that is entered for the product in the back office is also 10,- and that price ideally should be used everywhere in the shop.

I've added a product with a price of 52.75 (incl. tax). I changed the settings for the tax and disabled the 'Include in price' option. In that case SC is adding the product tax to the total (see screenshot).

When you keep the option enabled it is subtracting the tax (see screenshot). As far as I understand, that shouldn't happen since the tax is already included in the price? In the screenshot above I'm looking for a way where the total is 59.70.

I was unable to reproduce the issue where Mollie was receiving the wrong amount - we give Mollie the grand total of the order, so something must have caused that to be wrong (maybe the product amount was somehow 0?)... If you can reproduce this, would you be able to push up the order to the Git repository and let me know what the order ID is and I can take a further look?

There are two orders where this happened. The order IDs are:

• 1528 - c606c447-fd2d-40bb-b074-56c837016f22

• 1533 - c01d81f9-7a1a-4f26-b33a-2484f45d23c4

[duncanmcclean]

The {{ total_including_tax }} variable should be used instead of the product's {{ price }}, not instead of the {{ items_total }} variable (apologies if I said it worked the other way around in an email)

It works fine for me - I'm adding to line 18 of your checkout/_cart.antlers.html view. Although, if the prices of your products already include tax, you probably don't need to do this.

When you configure tax rates, the 'Include in price' should really say 'Do product prices ALREADY include tax?' (this will change in the next version). SC will subtract the tax amount from the product price, rather than adding onto it.

Like I said previously, that setting it means the price of your product should already include tax.

So if you have it enabled, Simple Commerce will subtract the tax calculation from the product price to make the line item total.

If you have it disabled, Simple Commerce will add the tax calculation to the product price to make the line item total.

The 'tax calculation' can be found under the tax key on each line item (you'll need to view the order in your code editor to see it).

From what I can gather, what you want is the option enabled (as you include tax in the product prices), no?

I'm not sure I completely understand the issue though... say you have a $10 product, what would you expect all the totals to be?

I was unable to reproduce the issue where Mollie was receiving the wrong amount - we give Mollie the grand total of the order, so something must have caused that to be wrong (maybe the product amount was somehow 0?)... If you can reproduce this, would you be able to push up the order to the Git repository and let me know what the order ID is and I can take a further look?

Hmm, looks like neither of these orders have any line items on them which is odd. I wasn't able to reproduce this happening. Please open another issue with steps to reproduce if you run into it again.

[duncanmcclean]

Closing after 2 weeks of inactivity.