Bug: tax_zone_type = shipping can apply wrong VAT logic for virtual products

  • Posts: 36
  • Thank you received: 2
  • Hikaserial Subscription Hikashop Business
1 month 19 hours ago #371515

-- HikaShop version -- : 6.0.0
-- Joomla version -- : 4.4.3
-- PHP version -- : 8.2

Hi, I realize we are running on HikaShop 6.0.0, so perhaps this bug is already fixed. If not, I am reporting it here for future versions.

Summary
When checkout has no shipping step (virtual/digital products), HikaShop can use the user’s default/session shipping address during order creation (created status), even though shipping is not selected in checkout. This causes VAT calculation/exemption differences between checkout display and created order.

Environment

HikaShop 6.0.0
Joomla site checkout with digital product (no shipping selection shown)
Config: Type of address used for tax = Shipping

Steps to Reproduce

  1. Set Type of address used for tax to Shipping.
  2. Set default shipping address to EU address without VAT ID.
  3. Add a digital product to cart (no shipping step available).
  4. Select billing address with valid EU VAT ID.
  5. Checkout/cart shows VAT-exempt as expected.
  6. Click Finish (PayPal Checkout) so order is created with created status.

Expected
For virtual-only checkout (no shipping context), order creation should use billing/fallback logic consistently, matching cart display.

Actual
Created order includes VAT (or otherwise differs), apparently using default/session shipping address for tax/VAT-type resolution.

Likely Cause
getCurrentUserAddress('shipping') in administrator/components/com_hikashop/classes/address.php can fall back to session shipping_address even when shipping is not required/selected in current checkout context.

Impact
Tax inconsistency between frontend checkout totals and backend created order, especially for EU VAT-ID scenarios on digital goods.

Please Log in or Create an account to join the conversation.

  • Posts: 85609
  • Thank you received: 14016
  • MODERATOR
1 month 14 hours ago #371517

Hi,

Thanks for the detailed analysis with the pointer to getCurrentUserAddress. After tracing the full flow, the root cause is actually a bit deeper and is in class.currency rather than class.address: the two functions that resolve the customer's address for tax purposes - getTaxType (which decides if the customer is individual / company / company_with_vat_number) and _matchPostCode (which checks post-code-restricted tax plans) - both read the "Type of address used for tax" setting unconditionally, without checking whether the current cart actually needs shipping. The address lookup then does its normal fallback chain and can legitimately end up on a shipping address (auto-selected by the cart loader, saved from a previous session, or picked up from the address block of your checkout), while the zone extraction in class.cart correctly falls back to the billing address because it explicitly gates on need-shipping. The tax "where" and the tax "who" were therefore decided against two different addresses for a virtual-only cart, and your VAT-exempt status on the billing address was being overridden by the shipping address that does not carry the VAT ID.

We have fixed this by making the address type used for the tax type and post-code matching follow the same need-shipping gate that class.cart already uses for the zone extraction. When the cart has no product to ship (no weight on any product, and force_shipping is not enabled), the billing address is used regardless of the "Type of address used for tax" configuration, so the VAT exemption from the billing address is kept. When at least one product does need shipping (or force_shipping is on), the behavior is unchanged.

The fix has been pushed to the 6.4.0 release package (it will also be in 6.4.1). Please download the latest package from your member area on our website and install it over your current installation. Let us know if you still see a discrepancy between the checkout total and the created order total after the update.

The following user(s) said Thank You: jcamus

Please Log in or Create an account to join the conversation.

Time to create page: 0.053 seconds
Powered by Kunena Forum