Edit Orders v4.0 Support Thread

[RodG]

Honestly Rod, the discount coupon thing aside (which is a functional issue not a "bug"), I'm starting to wonder if the "bugs" you are finding are UNIQUE to the client site you are working on.. Otherwise it would stand to reason that others would have reported the same issues you are having..

Wonder no more. It is most certainly unique to this clients site.
Until this thread I really wasn't sure (and arguably, could still be in doubt), because this is the 1st store in which I've had the combination of

-----------------------------------
ZenCart V1.5.1
Edit Orders 4.1.2
Super Orders 4.0.7
Stock by Attribute 1.5.1.2
-----------------------------------

Although I'm now pretty much convinced the problem(s) pertain to the store/data itself, can you (or anyone) be 100% sure that there *isn't* a bug with this specific combination of inter related modules?

Again, I will stress that I'm now of the opinion that when I find what else is amiss with the data in this store that these versions of these modules will almost certainly behave as expected. Without reporting the 'bugs' and what I've needed to do to 'fix' them I don't think I could have gotten the feedback I needed to put me back on the right track. :)

Cheers
Rod

[OldNGrey]

I had problems installing Edit Order on a vanilla install of ZC. The solution / workaround is shown below.

The resulting error is:
"PHP Fatal error: 1366:Incorrect integer value: '' for column 'configuration_group_id' at row 1 :: INSERT INTO `zen_configuration_group` VALUES ('', 'Edit Orders', 'Settings for Edit Orders', '36', '1') in E:\web\zc151\includes\classes\db\mysql\query_factory.php on line 120
"

I have tracked it down to
admin\includes\auto_loaders\config.eo_onetime.php
--> admin\includes\init_includes\init_eo_install.php
--> admin\includes\classes\eo_plugin.php
--> admin\includes\classes\plugin.php
LINE 435
// Create configuration group
$db->Execute(
'INSERT INTO `' . TABLE_CONFIGURATION_GROUP . '` ' .
'VALUES (\'\', \'' . $this->getUniqueName() . '\', ' .
'\''. $this->getDescription() . '\', \'' . $max_sort . '\', \'1\')'
);]
The solution that works on my environment is to change to the value of configuration_group_id from '' to NULL
$db->Execute(
'INSERT INTO `' . TABLE_CONFIGURATION_GROUP . '` ' .
'VALUES (NULL, \'' . $this->getUniqueName() . '\', ' .
'\''. $this->getDescription() . '\', \'' . $max_sort . '\', \'1\')'
);

This can be replicated on a fresh database and Zen Cart demo installation

Configuration
PHP 5.3.8
Apache 2.2.21
MySQL 5.1
Windows 7 (test server)

I have posted the problem and the workaround here for future reference.

I have persevered with this as I have been using Edit Order on many version of ZC and simply find it difficult to admin a ZC site without it.

[lhungil]

I had problems installing Edit Order on a vanilla install of ZC.
...
The resulting error is:
"PHP Fatal error: 1366:Incorrect integer value: '' for column 'configuration_group_id' at row 1 :: INSERT INTO `zen_configuration_group` VALUES ('', 'Edit Orders', 'Settings for Edit Orders', '36', '1') in E:\web\zc151\includes\classes\db\mysql\query_factory.php on line 120
"
...

Thank You for catching this, reporting the issue, and providing a workaround / solution!

For the next release (of both Edit Orders and the Plugin module), I'll be replacing most UPDATE and INSERT statements with the "zen_db_perform" function.

[lunabug]

I'm curious as to why you "Changed the "local_sales_tax" line to no longer be editable (automatically generated based upon the order)" when "Not all order total modules are fully supported"???

As this is the case for my site (I'm running the Better Together addon), and I have to update the database directly with the correct sales tax (AND the total) as Edit Orders is not taking this discount into consideration when calculating the tax. I'd much rather be able to update it directly on the order edit page.

Thank,
Leslie

[lhungil]

... I'm curious as to why you "Changed the "local_sales_tax" line to no longer be editable (automatically generated based upon the order)" when "Not all order total modules are fully supported"??? ...

Because the "Local Sales Tax" module IS supported by Edit Orders with the noted changes in the readme. "Local Sales Tax" reads the product list from the order (not the cart) and works when loaded during checkout or from the administrative interface.

An Order Total module can be treated as "automatically" calculating or "editable" (not both) within "Edit Orders". Currently there are no plans to add an extra checkbox to each order total line to allow selecting the mode... Mostly because what a customer sees when they place an order via the checkout process should match what is shown when an administrative user edits / creates an order.

... As this is the case for my site (I'm running the Better Together addon), and I have to update the database directly with the correct sales tax (AND the total) ...

The calculations are NOT done by Edit Orders in version 4.1+ The calculations are done by the Order Total modules.

I sympathize with the issues you are experiencing, but they are not caused directly by "Edit Orders".

1. "Better Together" and "Local Sales Tax" are not friendly towards each other. Specifically, "Local Sales Tax" calculates tax separate from Zen Cart's tax tables and reads the products from the order. "Better Together" is not aware of the "Local Sales Tax" module and only calculates tax using Zen Cart's tax tables and does not modify the price of products in the order.
2. "Better Together" does currently support being loaded from the administrative interface. "Better Together" depends on access to the shopping cart (and does not make use of $order->products). "Edit Orders 4.1+" currently only populates $order as there is no shopping cart once an order has been placed.

If you must use an unsupported Order Total module (or have multiple Order Total modules which do not work well together), you may wish to uninstall "Edit Orders 4.1+" and go back to using "Edit Orders 4.0". Edit Orders 4.0 relied upon manual price adjustments vs. ones calculated by the Zen Cart Order Total modules.

Otherwise, continue reading for some of the things involved (not all) if you want to use "Edit Orders 4.1+", "Better Together", and "Local Sales Tax" together.

To address the first issue:
Modify "Better Together" and / or "Local Sales Tax" to play well together. I believe some of the other tax lookup modules have similar problems with discount modules which do not alter the price of the product directly... But I could be wrong...

To address the second issue:
Modify "Better Together" to use the order information (when available, instead of just the cart) -- or -- Modify "Edit Orders" to populate a "dummy" cart. This would allow automatic calculation for "Better Together" (and if item #1 is corrected tax rates should be calculated correctly).

You may also run into some issues with the automatic calculation of the stock Zen Cart taxes via ot_taxes without this compatibility issue being addressed. As "Better Together" does not see products in the shopping cart, it does not apply any corrections (including tax corrections).

[lat9]

I've got a question regarding what should be expected regarding Edit Orders' handling of orders that contain deleted products.

The scenario: The website that uses Edit Orders extensively has one class of products that are one-off. Once they're sold, they're no longer available. The store owner, in performing "routine" maintenance, has gone through and specifically deleted (not disabled) the one-off products that have been sold (including product ID#234).

The customer who has purchased product #234 calls the store owner and requests that an additional product be added to their order. Store owner adds product ID 456 to the order. Upon updating the order, the orders_products table entry for the deleted product #234 has been updated with the products_id and products_prid both set to 0 and the products_price set to 0.00 (interestingly, the products_final_price value is unchanged).

What I expected was for Edit Orders to use the product-related information from the orders_products table (i.e. the products_id, products_prid and products_price fields should not have been changed for product #234) unless a new product was added to the order, in which case the products table would need to be interrogated for that newly-added product.

[lhungil]

During an update, all products are removed from the order and re-added. The information about the product is first looked up from the database, then merged with the product information shown on the edit orders page...

I'll have to take another look at the code (out of town). I THINK the reason was to ensure the product info is fully populated for the order totals... Suspect I can add a workaround (although tax may be off without being able to pull the product's tax class and description)... Again will need to look back over the code.

Thank you for being patient and mentioning!

[lhungil]

Wonder no more. It is most certainly unique to this clients site.
Until this thread I really wasn't sure (and arguably, could still be in doubt) ...

Thank You for reporting back, if you see / saw any database pieces you feel could be "commonly" damaged, feel free to send me a PM / email with the information. If nothing else an installation check might be in order :)