I’ve been trying to figure out an inconsistent pricing bug that I’ve noticed recently. I think I’ve made some progress during my testing; however, I’ll need some assistance on how to resolve it.
In WooCommerce > Settings > Tax, I have chosen to enter prices “including tax”. I have also selected “Including tax” for both the “Display prices in the shop” and “Display prices during cart and checkout” options.
Additionally, in HivePress > Settings > Vendors, I have enabled the option “Taxes - Include taxes in the balance calculations”.
I would like to ensure that all displayed prices remain consistent (inclusive of tax) regardless of the stage.
Here is what I’ve observed:
Vendor Setup: The price a vendor sets whilst creating their listing is shown on the listing page as expected (e.g., £10).
Checkout: The price shown to a buyer during checkout is also correct (e.g., £10).
Booking Page: If the buyer does not complete the checkout immediately, the price shown on the single booking page (e.g., /account/bookings/6666/) depends on the order status:
Unpaid/Pending status: The price is shown exclusive of tax.
Completed status: The price is shown inclusive of tax.
Could you please help me ensure the price is shown inclusive of tax on the “Bookings” page regardless of the order status?
I appreciate this is likely a bug, but if you’re able to provide a temporary fix until it’s able to make it into a release, it would be highly appreciated as always!
You’re right, there is an inconsistency in the price calculation when taxes are included in the price. This happens when the order has an unpaid status. The price that you and the user see at this stage is essentially the subtotal that was calculated when dates were selected on the listing page, before reaching the checkout. Since the checkout page hasn’t been reached yet, it doesn’t account for additional fees like taxes, or discounts (since coupons can only be entered at checkout). When the booking becomes confirmed, it then pulls and displays the actual order total from WooCommerce, which includes all these additional elements.
We’ve added this to our bug tracker to fix in future updates. In the meantime, if this is urgent for your use case, please let us know and we can provide guidance on how to adjust the calculation in the code.
It’s no problem, and thank you for looking into this for me.
In some ways, I’m glad to hear it’s a reproducible issue rather than being something else that’s caused by a third-party plugin or customisation I’ve made!
I’m in the process of attempting to resolve all/as many of the remaining issues on my site before, hopefully, having it all ready to launch soon. So, yes, if yourself or Ihor could kindly provide guidance on how to adjust the calculation before the future update - that would be amazing.