Older versions of Edit Orders (< 4.1) allowed the store owner to manually modify almost the entire order (including order total lines). It was not uncommon to find problems with math (as these needed to be done by the person editing the order) in stores using older versions of Edit Orders. If you look through the forums there are a number of other posts regarding issues caused by older versions of Edit Orders (including other math related items).
As of Edit Orders 4.1.x, end users are no longer allowed to manually "adjust" the subtotal (and certain other order total lines) within Edit Orders to avoid such issues. And instead of Edit Orders handling any math related to the order total modules, the order total modules are actually run (same as during checkout). This allows the order total modules to do their own calculations based upon the order contents.
As a result, under Edit Orders 4.1.x if the "subtotal" was off before editing, it will be off after editing (it is not recalculated, just loaded from the database as-is and adjusted up / down when products are added / edited / removed).
If you create a new order in the new store, then attempt to edit the order:
- Are the order totals correct when the order is first loaded (no edits)?
- Change the product price and then press "update". Are the order totals correct?
- Add a product to the order and then press "update". Are the order totals correct?
I'll have to take a look at this. I think I know the cause, but want to verify the fix on a couple test sites.
If the database columns and tables were all set to use a CHARACTER SET of UTF8
previous to the upgrade, you are probably okay (you can check this in phpMyAdmin or similiar). This is rare because out of box Zen Cart < 1.5.0 always used iso-latin-1. When upgrading from Zen Cart < 1.5.0 if the 1.3.x database was iso-latin-1 you still need to manually address this (different store configurations need different massaging and conversions - especially multilingual stores, so this was not automated).
Ahhh, by default Zen Cart does not populate the "shipping" address when an order is completely virtual. If the shipping address contains an address with NO "country" (or a country not found in the Zen Cart database), this would be the cause of the message "
Warning: One or more of the customer address fields contains a country name unknown to Zen Cart ("Locations / Taxes"->"Countries"). Taxes and some shipping modules may not function correctly until the issue has been resolved."
If all of the products are indeed virtual (and shipping will NEVER be used), you can disable the warning by making the following change in "/admin/edit_orders.php":
Code:
if(!is_array($order->customer['country']) || !array_key_exists('id', $order->customer['country']) ||
!is_array($order->billing['country']) || !array_key_exists('id', $order->billing['country']) /*||
!is_array($order->delivery['country']) || !array_key_exists('id', $order->delivery['country'])*/) {
$messageStack->add(WARNING_ADDRESS_COUNTRY_NOT_FOUND, 'warning');
}
NOTE: Also make sure you apply all known bugfixes for Edit Orders 4.1.4. Some examples (there may be others, but these two come to mind): bugfix when downloadable products are disabled and coupon validation functions are missing from the Zen Cart admin.
Bookmarks