Re: Edit Orders v4.0 Support Thread
Hello all,
I have just installed this on a fresh 1.51 installation and it didn't throw up any error messages on installation.
Adding products to an existing order works without a hitch but attempting to edit an order in any way, such as the quantities, results in a HTTP 500 Internal Server Error being thrown up.
Can someone offer any advice or help troubleshooting?
Thanks!
Edit Orders 4.1.4
ZC 1.51
PHP Version 5.4.28
Re: Edit Orders v4.0 Support Thread
From the order details page, the order status can be updated without problems, however, when updating the status from the edit order page I get the same Error 500 but on clicking back, the order status has indeed been updated.
Re: Edit Orders v4.0 Support Thread
A "500" error typically indicates an error occured. Please check your server error logs. This should contain additional information (unless logging is disabled). Please post the error messages so we can help futher troubleshoot.
The most common causes are issues with the "manual" portion of the installation or 3rd party order total modules installed (and enabled) which do not support being loaded from the Zen Cart admin interface.
1 Attachment(s)
Re: Edit Orders v4.0 Support Thread
I've got some baffling math going on and not sure what to poke to get Edit Orders to wake up.
ZC 1.5.1, Edit Orders 4.1.4
I had to change one of the items in this person's order. Same price, different style. Everything seemed to be ok yesterday and I printed out a correct packing slip. When I glanced at the order this morning as I was preparing to ship, one item was missing ($17.47); this was not the item that was editted. So I manually added the missing item in and now the math is incorrect.
3@ $18 - $54
1@ $18 - $18
2@ $18 - $36
1@ $17.47
1@ $17.47
subtotal- $160.40 ?
the extra amount comes to $17.46. Note that this was a currency conversion order from Russia and so that would account for the penny.
No error messages or other warnings. There won't be a log file since I did not have this turned on initially. It's not stopping me from shipping but it would be nice to figure out what's going on...
Attachment 14122
Re: Edit Orders v4.0 Support Thread
Quote:
Originally Posted by
linniedarling
... I had to change one of the items in this person's order. Same price, different style. Everything seemed to be ok yesterday and I printed out a correct packing slip. When I glanced at the order this morning as I was preparing to ship, one item was missing ($17.47); this was not the item that was editted. ...
The list of products and product attributes for an order are stored in the database. You have indicated everything looked correct yesterday. If you still have a copy of the "packing slip" you printed yesterday can you double check and see if everything was correct yesterday?
If the packing slip was correct
This indicates something OTHER than this module most likely resulted in one of the products going missing from the database table "orders_products"... If this is the case it would be a really good idea to determine what the cause was to avoid running into it again.
I'd backup the database and then run a "repair" of the tables (if needed). If no repair was needed, I'd check the MySQL logs and the Zen Cart activity log (to see when and possibly what and who made the change).
If the packing slip was not correct
Are there any Zen Cart debug logs (these are enabled by default in Zen Cart 1.5.1)?
What order total modules are enabled?
Can you provide some additional details about your server environment ("admin" -> "version")?
Have you been able to duplicate this behavior with a test order? Specific steps to duplicate?
If occurs with specific products / attributes, what differs from other products?
Quote:
Originally Posted by
linniedarling
... So I manually added the missing item (using Edit Orders) and now the math is incorrect. ...
This is what I would expect if somehow one of the database tables relating to the order were somehow modified outside Edit Orders (or if a 3rd party order total module crashed during the update).
When a product is added the final price is added to the "subtotal" in the database.
When a product is removed the final price is subtracted to the "subtotal" in the database.
Basically what appears to have occurred is somehow the database entry storing the running "subtotal" for the order is out of sync with the actual order's subtotal.
If you know the order number and are comfortable working with phpmyadmin:
- Make a database backup to be on the safe side.
- Correct the products (including attributes, quantities, and price) using "Edit Orders".
- Calculate the correct "subtotal" and store for future reference.
- In phpmyadmin open up the "orders_total" database table and find the row matching the affected "orders_id" with "class"="ot_subtotal".
- Edit both the "text" and "value" columns in the row with the correct "subtotal".
- Go back to "Edit Orders" and click "update".
- Verify pricing is now correct.
NOTE: The above instructions will only work when the subtotal is calculated based only upon the products added to an order. There are some circumstances where the subtotal may contain additional costs or deductions.
Re: Edit Orders v4.0 Support Thread
Quote:
Originally Posted by
lat9
Running EO 4.1.2 on Zen Cart v1.5.1. Storefront highly customized; admin not so much! The only thing that might be interfering is the "Minimum Customer Account" plugin, since I'm getting the edit_orders message:
Code:
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.
This typically occurs if someone deletes or renames a country's name from Zen Cart ("Locations / Taxes"->"Countries"). You can fix the issue by doing one of the following:
Add the country (and name) back to the Zen Cart database.
Adjust the country name to match one of the country names in the Zen Cart database.
There is a virtual product that is $1.00 and the product-quantity is used to determine the final price. When an order is initially placed, the quantity is 1. I go to the admin to use edit_orders and change the quantity to 100 and click "Update", the line-item total for the product is updated to $100.00 but the order_totals total remains at $1.00. The order includes neither tax nor shipping.
I don't know if this is a procedural issue on my part, an incompatibility or something else. I'm off to investigate further.
--> One other thing I noticed is that the only order_total that is enabled is the ot_total (no ot_subtotal).
I got this same error when trying to edit orders for products that didn't require a shipping address such as virtual orders. I temporarily resolved this Warning error by editing the edit_order.php file from Edit Order 1.4.1. Line 655 was throwing the error as it was checking for a shipping address country when none was needed. So I commented out the line.
Original:
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');
to:
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');
This section
|| !is_array($order->delivery['country']) || !array_key_exists('id', $order->delivery['country'])
is commented out. Now is doesn't check for the country and no more error.
Might not be totally related to your problem but my issue gave the same error.
Re: Edit Orders v4.0 Support Thread
Hi Niki,
Thanks for the tip. I have not had to actually edit any orders since. I'm waiting until it happens again to try to debug further.
However I do think it's related to Shipstation "pushing" some of the order information back after I had editted. I'm in a one sided dialog right now trying to discover what's going on.
Re: Edit Orders v4.0 Support Thread
Quote:
Originally Posted by
Niki
I got this same error when trying to edit orders for products that didn't require a shipping address such as virtual orders. I temporarily resolved this Warning error by editing the edit_order.php file from Edit Order ...
I would caution against disabling warnings output by Edit Orders. Warnings are usually displayed for well thought out reasons. The one you mention exists to indicate the order details (specifically all of the addresses) are not fully populated in the database (or may contain invalid information). It goes on to let you know the missing / incorrect data may cause problems with some order total modules and tax calculation. This specific WARNING is only a warning and does not indicate a failure within Edit Orders.
You do bring up a good point however. Perhaps this warning should be split into two parts... One for missing information and a second one for invalid data. This would allow us to emit more accurate "how to fix" information. Or perhaps "Edit Orders" should just automatically copy the billing address to the shipping address fields when no shipping address is entered...
Some of the reasons for this warning message:
A handful of the order total modules for Zen Cart attempt to read addresses (such as the shipping address) and can crash / emit invalid totals when various address fields are not populated (or contain invalid data). When this address data is not present and one of these order total modules enabled, editing an order may result in corrupted order information (and pricing) in the database.
When a new order is created (on behalf of a customer - such as email or phone orders) directly in the administrative interface, this also serves as a reminder to the person entering the order to fill out all of the address fields which may be required by various order total modules.
For example, what happens if for some reason the order needs to have one of the products shipped? While a rare case, a customer may call in and ask instead for a physical copy and to have the physical copy shipped. Editing the order to add shipping will cause problems with pricing and tax if the billing address is not present
So even when a purchase may be for "virtual only" products, if you are going to edit the order, entering the shipping address (populating with the billing address) is usually a good idea.
NOTE 1: just as a reminder, Edit Orders should ONLY be used to edit customer details / addresses, products in the order, and order totals. It should not be used simply for changing the order status. If only changing the order status (or adding comments), it is always better to use the "details" button instead.
NOTE 2: If one reads the very next post after the one quoted by Niki, one will notice the actual cause of the problem for the OP (Edit Orders requires ot_subtotal enabled). The current versions of Edit Orders display a warning when ot_subtotal is not enabled.
Re: Edit Orders v4.0 Support Thread
Quote:
Originally Posted by
linniedarling
... I do think it's related to Shipstation "pushing" some of the order information back after I had editted. ...
Hmmm. I do not see any SQL statements in the Shipstation module (in the plugins section of this website) which would alter products or order totals... Are you using a different module for Shipstation?
Re: Edit Orders v4.0 Support Thread
Quote:
Originally Posted by
lhungil
So even when a purchase may be for "virtual only" products, if you are going to edit the order, entering the shipping address (populating with the billing address) is usually a good idea.
The front-end checkout skips the shipping step of the checkout if the entire order contains only virtual products. I would think that f the ENTIRE order contains only virtual products that Edit Orders should NOT throw this warning at all...