Edit Orders v4.0 Support Thread

[Niki]

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:

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.

[linniedarling]

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.

[lhungil]

... 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?

[linniedarling]

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?

Wow, I wasn't even aware of a Shipstation module. No, I'm not using any ZC Shipstation modules. I gave Shipstation an admin access and password and it updates the order(s) as shipped or cancelled and perhaps even does some other things.

The particular order that I had this problem with I had to modify not just the items in the order but also the shipping address as it was too long to print on the 4x6 label. I made the mistake, probably, of fixing the address within Shipstation. Afterwards I found out that the customer wanted a different color and then changed the items in her order and printed the packing slip. The next morning I pulled the order again from the Shipstation side which removed my address fix; I fixed the address a second time within Shipstation, prepped the label and found all the customs information had disappeared. I hand entered the customs information and then printed the shipping label at which time Shipstation sends back a "delivered" status. When I went back to my admin area I caught the bad total.

I'm waiting until I have to edit another order and will carefully monitor each step to see if I can catch where (and if) things go awry.

[DivaVocals]

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.

Wow, I wasn't even aware of a Shipstation module. No, I'm not using any ZC Shipstation modules. I gave Shipstation an admin access and password and it updates the order(s) as shipped or cancelled and perhaps even does some other things.

The particular order that I had this problem with I had to modify not just the items in the order but also the shipping address as it was too long to print on the 4x6 label. I made the mistake, probably, of fixing the address within Shipstation. Afterwards I found out that the customer wanted a different color and then changed the items in her order and printed the packing slip. The next morning I pulled the order again from the Shipstation side which removed my address fix; I fixed the address a second time within Shipstation, prepped the label and found all the customs information had disappeared. I hand entered the customs information and then printed the shipping label at which time Shipstation sends back a "delivered" status. When I went back to my admin area I caught the bad total.

I'm waiting until I have to edit another order and will carefully monitor each step to see if I can catch where (and if) things go awry.

Ummmmm there is a Shipstation module.. the only way your store could communicate with Shipstation is if a module is installed.. It's probably this one:
http://www.zen-cart.com/downloads.php?do=file&id=1324 (ShipStation USPS, UPS, and FedEx Shipping Module) Which is described as follows:
This module integrates your Zen Cart site with the ShipStation web-based shipping system.

and you've just described the problem and confirmed that the issue isn't with Edit Orders but with Shipstation overriding your order edits with the original order data.. (happens when you pull order from Shipstation back to Zen Cart)

[Niki]

Running zencart 1.51
Edit order vs 1.4.1 along side Admin New Customer 1.3 and Admin New Order 1.4

When entering order details via Edit Orders to add a new product, along each step I get the following 'error' messages from the browser i.e Done but with errors.... Object Required
Line numbers are in relation to "action Add Product" along each step
258 char 4 - <TR> tag
263 char 4 - seems to refer to If statement regarding eo_debug_action_level ??
268 char 4 - IF statement

After clicking [Add Now]
Line numbers are
1269 char 4 - </TR> closing table row tag
1274 char 4 - </TR> closing table row tag with <?php>.... unset ()

All error notifications don't seem to cause an issue with the function of the module. I'm just curious what could be throwing out these errors. What "object" are they requiring.

Also, I don't use TY Tracker as I'm in Australia. Can I remove these code blocks or will they just be ignored by the Edit Order module?
Thank you in advance for any input.

[DivaVocals]

Also, I don't use TY Tracker as I'm in Australia. Can I remove these code blocks or will they just be ignored by the Edit Order module?
Thank you in advance for any input.

Leave the code alone.. If you don't use Ty Tracker then the code doesn't need to be removed..

BTW, Ty Package Tracker isn't an "American" module, it is a SHIPPING TRACKING module.. which means it can be used with nearly any shipper you add when it is configured.. (Including those in Australia)

[lhungil]

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.

[DivaVocals]

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...

[lhungil]

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...

So you would be in favor of me splitting up this error message. :-)

One warning for when ZERO shipping information has been added AND if after looping through the current products in the order all items are virtual.

One warning for the actual reason this check was added (invalid country data which causes pricing, tax, and some order total modules to crash).