Author Topic: BUG: 1/2 Order edit in BE: Shipment VAT not displayed and calculated correctly  (Read 1484 times)


  • Beginner
  • *
  • Posts: 14
UPDATE: Please see reply #4:

The following situation is given:
- VM
- A product (book, 7% VAT) was ordered. The selected shipment method is "standard" for which 19% VAT is defined. See image cart
- Following the order is partially listed correctly in the BE: The product and its VAT are correct, as is the net amount for shipment. The VAT amount of the shipment is also correct, but is displayed incorrectly in the column "7% VAT". See image BE_order
- EDIT and SAVE will calculate an incorrect VAT amount for shipment, namely 7% (again in the wrong column "7% VAT"). See image BE_order_after_save


  • Beginner
  • *
  • Posts: 14
2/2 Order edit in BE: Shipment VAT not displayed and calculated correctly
« Reply #1 on: October 16, 2019, 19:15:37 pm »
The corresponding entries in the tables #__virtuemart_orders and #__virtuemart_order_calc_rules:
- After completion of the order: See images image009 and image007
- After EDIT and SAVE: See images image017 and image015


  • Global Moderator
  • Sr. Member
  • *
  • Posts: 3453
  • VirtueMart Version: 3.8.9
Check your configuration

Because when you edit there is an option to take the prevailing rate of Product VAT for shipping in order edit


Simplified VAT for shipping

Joomla 3.9.26
php 7.4


  • Beginner
  • *
  • Posts: 14
Simplified VAT for shipping

Very good idea, thank you for the hint.
But unfortunately deactivating this option did not help.


  • Beginner
  • *
  • Posts: 14
BUG: Order edit in BE: Shipment VAT not displayed and calculated correctly
« Reply #4 on: November 09, 2019, 15:43:18 pm »
The issue I have reported on October 16, 2019 is a BUG.

Steps to reproduce:
1. Install VM from (
2. Install sample VM entries
3. To make things easy to reproduce define this both VAT entries per product:
    - 7% Vat tax per product
    - 19 % Vat tax per product
4. In products list assign to 'Root Pattern' final price: 10 (per 'Calculate the Cost price') and 7% VAT
5. Open the payment method 'Cash on delivery' and empty at 'Configuration' the field 'Fee per transaction', also set 'Tax' to 'Apply no rule'
6. Create a new shipment method 'standard', set a 'Shipment Cost' of 5.17 and assign 'Tax' of 19% VAT
7. Then purchase 1 item of 'Cowboy Hat', thereby select shipment method 'standard' at cart and finish checkout - see Screenshot_2019-11-09 Shopping cart
8. Open the frontend Order Information (via displayed link after checkout): any price and tax amount is displayed correctly - see Screenshot_2019-11-09 Order Information
9. Go to VM backend, open the related order in Orders List, scroll down to button 'Edit ordered products' - see Screenshot_2019-11-09 Edit Order 1
    -> Only one VAT column is displayed, the column header is '7% VAT', which is wrong
10. Click button 'Edit ordered products' but do not change anything, then click 'Save'
11. The shipment VAT will be recalculated with 7%, which is wrong - see Screenshot_2019-11-09 Edit Order 2

1. If the VAT of a purchased product differs from the shipment VAT for this product the latter will not saved correctly.
2. When editing/saving the order in the backend the (not correct saved) shipment VAT will be downcalculated to the product's VAT.

This bug I would consider as important, since the given example - different VAT amounts for product and shipment - is a common scenario. Also it is common to decrease or increase the amount of a purchased item after checkout for instance to satisfy a customers demand via email or phone call.


  • Virtuemart Projectleader
  • Administrator
  • Super Hero
  • *
  • Posts: 10094
  • VM3.2 Cached and Optimized
    • VM3 Extensions
  • VirtueMart Version: VirtueMart 3 on joomla 3
Thank you for the good bug report.

In short, VM does not consider the set shipment tax editing the order. okey.
I should fix your bug, please support the VirtueMart project and become a member
Extensions approved by the core team:


  • Beginner
  • *
  • Posts: 14
Well, an update to 3.6.10 does not resolve this bug. And since the latest VM news did not promise to do so, this is just as one should expect.