The shipping & shipping charge system is fine if you only trade within your own country, or if you use "block weight" charging via couriers such as DHL, FedEx etc.
However it would be an absolute nightmare to attempt to configure it for use with the post office if you are in a global and competitive small shipments market. Why-oh-why do developers not consult with their posdt office before beginning to write the code?
Postal rates globally are based around 10-gram, 20-gram, or part-ounce weight increments for base-cost calculation, then the applicable weight is applied to a country + service schedule of prices.
As an example
-- most post offices offer 4 basic international services - Sea Mail, Economy Air, Airmail, EMS - the names may vary but they are essentially the same service types with similar delivery lead times. Each of those also usually has two price groups - small package (for under 2 Kg) and regular (for over 2Kg) = a minimum of 8 basic services.
-- each service type has different geo-zones - for example Sea Mail from here has 11 zones, Economy has 15, Airmail has 6, and EMS has 13 - the countries in any one zone for any one service are rarely the same group as for the same numbered zone by another service (e.g. there is no Airmail to the Falkland Islands from here, and no Sea Mail to Afghanistan)
Having applied the base cost by weight and service to the geo-zones, the optional services need added. A short list of options that have fixed prices per package regardless of service or destination include -
- Insured Delivery
- Registered Delivery
- Expedited Handling
- Addressee Receipt Return (A/R)
- Online Tracking (available as an option in some countries)
- Escorted Transit (e.g. air passenger courier)
and so on.
The problem is, I have never seen any shipping module cover these options (there is an osCommerce one for gift wrapping which can be duplicated and renamed for each of the above options, thus building the options list at shipping selection in checkout, but it gets buggy as your list grows if you hack it that way).
All of the above relates only to post office services (before adding in named couriers) and you can imagine the admin configuration gets massive quite quickly. So far, I've only found that osCommerce can handle it effectively by using tax zones as geo-zones for shipping, and tweaking and duplicating the shipping_zones module to make one module for each service, with the php file hacked to set the number of geo-zones for each service. It is stable if you do that.
Hopefully the authors of this extension will take the time to address the shortfalls in their shipping functions and bring VirtueMart up to a level where it is a true competitor to osCommerce - it would be so much nicer to not have to mess with bridges between the Joomla and osCommerce.