Nick1973:

Why is it that when I update the order status, no matter what status I change it to the price totals change to a lower price or zero? And how do I stop this happening?

Even if I add a product it is resetting the Order Total to Zero which is not correct. It doesn't appear to be calculating properly.

@Nick1973, what version of Edit Orders and what version of Zen Cart?

lat9:

@Nick1973, what version of Edit Orders and what version of Zen Cart?

edit_orders-4.3.5

Zen Cart 1.5.6a

I'm still working through the EO/zc156 integration (obviously) but should have something in a couple of weeks.

Does the issue arise only if you use EO to update the order's status? If so, just use the regular orders handling to perform that function.

lat9:

I'm still working through the EO/zc156 integration (obviously) but should have something in a couple of weeks.

Does the issue arise only if you use EO to update the order's status? If so, just use the regular orders handling to perform that function.

Yes that is correct. I think there's an issue with the refund button not working as well. It is for a client so I have told them to do exactly what you said.

Nick1973:

Yes that is correct. I think there's an issue with the refund button not working as well. It is for a client so I have told them to do exactly what you said.
Er, there's no refund button functionality provided by EO.

lat9:

Er, there's no refund button functionality provided by EO.

Sorry I haven't looked :-) I am working on something else at the minute and am going on what the client has said. Must be getting mixed up with something else. I apologise ;-)

I've got a close-to-release version (v4.4.0-beta5) of Edit Orders now staged on GitHub: https://github.com/lat9/edit_orders/releases/tag/v4.4.0-beta5

Please note that this is a **beta **version, not yet intended for live site integration! I'd appreciate any/all 3rd-party validation that the community can provide, with issues found reported via GitHub, please.

Here's the list of issues currently staged for update by that release: https://github.com/lat9/edit_orders/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+milestone%3Av4.4.0

Hi,

I need urgent help. When I edit a customer order, it gives me the following message for any sold out (or disabled products).

Caution: The product (…………….) is currently disabled. Updating the order will re-enable that product.

Sometimes I have products that are disabled but I still have "product quantity" because they are either on backorder or it needs to be disabled for various reason.

Now if I edit an order which has "disabled or soldout products", it is re-enabling" them in the shop. Why is this? If I have disabled it, then it's for a reason, I don't understand why it doesn't stay disabled (even if I temporarily have products listed in it)

What is happening now is that I am getting orders for products the are suppose to be disabled temporarily. I am assuming this has something to do with the EO Plugin because it only happens if I edit an order that has disabled products.

If the product quantity is on zero, then it remains disabled, so this is not an issue. I now have products all over the shop that are en-abled (after an order edit) which should remain disabled.

We upgraded recently from v1.3.9 to v1.5.6
Plugin Edit Orders v4.3.5

Thanks in advance for help……….. happy to provide more information if needed

@Dustie, that's a side-effect of EO's current product-related processing. When an order is updated, each product is "removed" from the order (and 're-stocked') and then re-added to the order. That unwanted re-enabling of the product(s) is needed -- otherwise, the product could not be re-added to the order (since it's disabled).

I'll note this side-effect in the EO issue associated with the change to EO's processing of the update. Please note, though, that the associated change will take some time. The good news is at least EO let you know what it was doing!

lat9:

@Dustie, that's a side-effect of EO's current product-related processing. When an order is updated, each product is "removed" from the order (and 're-stocked') and then re-added to the order. That unwanted re-enabling of the product(s) is needed -- otherwise, the product could not be re-added to the order (since it's disabled).

I'll note this side-effect in the EO issue associated with the change to EO's processing of the update. Please note, though, that the associated change will take some time. The good news is at least EO let you know what it was doing!

Hi,

thanks for your reply.

I had to think about your reply because I didn't quite understand what you meant, but now I realise it is the opposite problem to what we had with the V1.3.9. In the old Version, if I edited and deleted a item from an order and it was returned to a disable product that was "out of stock", it didn't automatically re-enable to show that the product was on stock again. I also had to make a note of the products and go back and re-enable them.

Now it's the opposite, it's re-enabling products that should not be showing. For me personally this issue is worse because if I "miss" the re-activating of a product, we have to refund money for products that are temporarily out of stock.

Majority of our edits are done on calculated postage, so it still doesn't make sense that it re-enables items that I didn't make any changes too.

If I understood correctly you will be working on this issue was well? Yes, it's good that at least EO is telling us what it's doing…

This is really causing us alot of stock problems and so I am wondering, would the older version work on v1.5.6 until the issue is resolved?

Dustie:

Hi,

thanks for your reply.

I had to think about your reply because I didn't quite understand what you meant, but now I realise it is the opposite problem to what we had with the V1.3.9. In the old Version, if I edited and deleted a item from an order and it was returned to a disable product that was "out of stock", it didn't automatically re-enable to show that the product was on stock again. I also had to make a note of the products and go back and re-enable them.

Now it's the opposite, it's re-enabling products that should not be showing. For me personally this issue is worse because if I "miss" the re-activating of a product, we have to refund money for products that are temporarily out of stock.

Majority of our edits are done on calculated postage, so it still doesn't make sense that it re-enables items that I didn't make any changes too.

If I understood correctly you will be working on this issue was well? Yes, it's good that at least EO is telling us what it's doing…

This is really causing us alot of stock problems and so I am wondering, would the older version work on v1.5.6 until the issue is resolved?
It depends on how old the "older version" is. Most versions of EO prior to v4.3.5 won't.

lat9:

It depends on how old the "older version" is. Most versions of EO prior to v4.3.5 won't.

In that case I assume if v4.3.5 is the newest one, then anything older won't work on v1.5.6.

Btw, it's a great mod. I hope the issues are resolved

lat9:

I've got a close-to-release version (v4.4.0-beta5) of Edit Orders now staged on GitHub: https://github.com/lat9/edit_orders/releases/tag/v4.4.0-beta5

Please note that this is a **beta **version, not yet intended for live site integration! I'd appreciate any/all 3rd-party validation that the community can provide, with issues found reported via GitHub, please.

Here's the list of issues currently staged for update by that release: https://github.com/lat9/edit_orders/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+milestone%3Av4.4.0
Updated the beta version to v4.4.0-beta10 (https://github.com/lat9/edit_orders/releases/tag/v4.4.0-beta10). This beta-release, which I now consider a release-candidate, corrects various tax-handling issues and adds notifications to enable other plugins to interoperate without changing the base files.

My plan is to release v4.4.0 later this week! Thanks to all the people that have provided additional testing and feedback!

Can't seem to anyone with the same problem as I do.

I can normally edit an order (quantity, add new product, comment, status, etc.) with no problem. Recently a HUGE order came in with over 400 items and can't be edited. Clicking update gives me a blank page that has the all the admin header, nav and footer and nothing else. I can add an item and it updates but not edit existing items.

debug_edit _orders_xxx.log ends with just this:

2019-05-31 15:03:13, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php

2019-05-31 08:58:11, Edit Orders entered (4.3.4) action (edit)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php
getOrderInfo, on entry: Called by /…/…/…/…/edit_orders.php on line #705
	Subtotal: (not set), Shipping: (not set), Shipping Tax: (not set), Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0000":"1"}
	$_SESSION['shipping']: (not set)

Order Totals
		ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
		ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
		ot_shipping. Text: $0.00, Value: 0.0000
		ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

	Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
	…..… LONG LIST……..

Checking order for virtual status.  Order contains 453 unique products, 0 of those are virtual


getProductTaxes(15.0% HST)
{"products_tax_class_id":"1"}{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX”,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}
getProductTaxes, returning 8.1.
…..… LONG LIST……..

	Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
	…..… LONG LIST……..

Checking order for virtual status.  Order contains 453 unique products, 0 of those are virtual
calculateOrderShippingTax returning 0.
getOrderInfo, on exit:
{"code":"delivertocustomer","title":"Delivery","description":"Deliver to Customer","icon":"","enabled":true,"sort_order":"0","tax_class":"0","tax_basis":"Shipping"}
	Subtotal: XXXXX.X, Shipping: 0, Shipping Tax: 0, Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0% HST”:XXXX.XX}
	$_SESSION['shipping']: {"title":"Delivery (Shipping costs will be calculated for final invoice)","id":"delivertocustomer_","cost":0}

Order Totals
		ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
		ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
		ot_shipping. Text: $0.00, Value: 0.0000
		ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

	Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
	…..… LONG LIST……..

Checking order for virtual status.  Order contains 453 unique products, 0 of those are virtual


============================================================
= Creating display of Order Product #2311
============================================================
Product Details:
{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}


Options ID #1
Product Attribute: 
["2682"]
Options Info:
{"options":{"2219":"Assorted","2218":"Amber","2214":"Black","2216":"Blue","2215":"Green","2217":"Pink"},"name":"Color","type":"6","length":"32","size":"32","rows":"0"}

…..… LONG LIST……..

2019-05-31 08:58:54, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php
```\[/CODE]

In a successful edit case, it would have the regular product and details populated after that. Help?!

ZC 1.5.5f
EO 4.3.4
Group Pricing (per Item) 155
Stock by Attributes" (version 1.5.3)
Admin New Order 1.4
Add Customers From Admin 2.0.9

jvdd:

Can't seem to anyone with the same problem as I do.

I can normally edit an order (quantity, add new product, comment, status, etc.) with no problem. Recently a HUGE order came in with over 400 items and can't be edited. Clicking update gives me a blank page that has the all the admin header, nav and footer and nothing else. I can add an item and it updates but not edit existing items.

debug_edit _orders_xxx.log ends with just this:

2019-05-31 15:03:13, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php

2019-05-31 08:58:11, Edit Orders entered (4.3.4) action (edit)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php
getOrderInfo, on entry: Called by /…/…/…/…/edit_orders.php on line #705
Subtotal: (not set), Shipping: (not set), Shipping Tax: (not set), Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0000":"1"}
$_SESSION['shipping']: (not set)

Order Totals
ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
ot_shipping. Text: $0.00, Value: 0.0000
ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual

getProductTaxes(15.0% HST)
{"products_tax_class_id":"1"}{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX”,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}
getProductTaxes, returning 8.1.
…..… LONG LIST……..

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual
calculateOrderShippingTax returning 0.
getOrderInfo, on exit:
{"code":"delivertocustomer","title":"Delivery","description":"Deliver to Customer","icon":"","enabled":true,"sort_order":"0","tax_class":"0","tax_basis":"Shipping"}
Subtotal: XXXXX.X, Shipping: 0, Shipping Tax: 0, Tax: XXXX.XX, Total: XXXXX.XX, Tax Groups: {"15.0% HST”:XXXX.XX}
$SESSION['shipping']: {"title":"Delivery (Shipping costs will be calculated for final invoice)","id":"delivertocustomer","cost":0}

Order Totals
ot_subtotal. Text: $XX,XXX.XX, Value: XXXXX.XXXX
ot_tax. Text: $X,XXX.XX, Value: XXXX.XXXX
ot_shipping. Text: $0.00, Value: 0.0000
ot_total. Text: $XX,XXX.XX, Value: XXXXX.XXXX

Checking whether the product's attribute is a download, option_id = 14, value_id = 196: (1)
…..… LONG LIST……..

Checking order for virtual status. Order contains 453 unique products, 0 of those are virtual

============================================================
= Creating display of Order Product #2311

Product Details:
{"qty":2,"id":"653","name”:”Product Name”,”model”:”XXX-XX,”tax":"15.0000","price”:”XX.XXXX”,”final_price”:”XX.XXXX”,”onetime_charges":"0.0000","products_priced_by_attribute":"1","product_is_free":"0","products_discount_type":"0","products_discount_type_from":"0","attributes":[{"option":"Color","value":"Amber","option_id":"1","value_id":"16","prefix":"+","price":"0.0000"}]}

Options ID #1
Product Attribute:
["2682"]
Options Info:
{"options":{"2219":"Assorted","2218":"Amber","2214":"Black","2216":"Blue","2215":"Green","2217":"Pink"},"name":"Color","type":"6","length":"32","size":"32","rows":"0"}

…..… LONG LIST……..

2019-05-31 08:58:54, Edit Orders entered (4.3.4) action (update_order)
Enabled Order Totals: ot_subtotal.php;ot_misc_cost.php;ot_group_pricing.php;ot_tax.php;ot_shipping.php;ot_total.php

> 
> In a successful edit case, it would have the regular product and details populated after that. Help?!
> 
> ZC 1.5.5f
> EO 4.3.4
> Group Pricing (per Item) 155
> Stock by Attributes" (version 1.5.3)
> Admin New Order 1.4
> Add Customers From Admin 2.0.9


Not sure if I am the right person to reply, or if my reply is correct, but I had the same problem editing existing items.  To edit items you need to go to -configuration / Edit Orders and then change both *Product Price Calculation — Method and Default to MANUAL!

Hope this helps and otherwise hopefully someone else can help :)

@jvdd, there was most likely an associated /logs/myDEBUG-adm-*.log file on/around the time of that EO log. My guess is that the processing is running out of memory, but a log will 'say' for sure.

Remember, if you're posting an admin log that it will contain your store's secret admin directory name, so be sure to xxx-out any path information before posting.

I've just submitted v4.4.0 of Edit Orders to the Zen Cart Plugins for review; I'll post back when it's available for download.

 This ***major ***release contains changes and corrections for the following GitHub issues:

#61: Order total doesn't add up when coupon applied.
#79: Incorrect total for products with attributes, when initially added; requires 'update' to correct.
#88: Remove double-definition of language constant.
#89: Add notifiers to enable external tax-handling.
#90: Correct various PHP warnings and notices.
#91: An extra ':' is added to the end of the shipping title.
#93: Correct tax-handling for 'ot_misc_cost' and 'ot_onetime_discount' order totals.
#94: Modify array formatting for EO logs.
#95: Correct rounding issues.
#97: Correct 'ot_misc_cost' rounding issues.
#98: No longer distribute core file changes; they're built into Zen Cart 1.5.6b and later.
#99: Can't update an order with automatic pricing, using specials' pricing.
#101: Use zc156 button styling when installed on a zc156 base.
#102: Enable integration with "Attribute Image Swapper".
#103: Modify shipping tax-related processing.
#104: Always use the 'mock' cart.
#105: Add a status-history note to the order each time the order is updated or a product is added.
#106: Coupon-related corrections.
#108: Additional notification, allowing customization of display-only order totals.
#109: Additional configuration settings (see the readme for more information).
#110: Additional notification, allowing the inclusion of additional javascript/jQuery scripts.
#112: Additional notification, enabling additional columns to the order's status-history table.
#113: Don't reset shipping calculations when totals are reset.
#114: Sanitize input values and maximum field lengths.
#116: Even more notifications added, to enable additional customizations without changing the base file.
#117: Include an 'Updated By' column in the status-history table, if that field is present in the database.
#119: Correct missing constant for 'ot_onetime_discount'
#120: Supply missing 'ot_coupon' constant for zc156b beta installations.

Compatible with zc155 and zc156 installations.

lat9:

I've just submitted v4.4.0 of Edit Orders to the Zen Cart Plugins for review; I'll post back when it's available for download.

 This ***major ***release contains changes and corrections for the following GitHub issues:

#61: Order total doesn't add up when coupon applied.
#79: Incorrect total for products with attributes, when initially added; requires 'update' to correct.
#88: Remove double-definition of language constant.
#89: Add notifiers to enable external tax-handling.
#90: Correct various PHP warnings and notices.
#91: An extra ':' is added to the end of the shipping title.
#93: Correct tax-handling for 'ot_misc_cost' and 'ot_onetime_discount' order totals.
#94: Modify array formatting for EO logs.
#95: Correct rounding issues.
#97: Correct 'ot_misc_cost' rounding issues.
#98: No longer distribute core file changes; they're built into Zen Cart 1.5.6b and later.
#99: Can't update an order with automatic pricing, using specials' pricing.
#101: Use zc156 button styling when installed on a zc156 base.
#102: Enable integration with "Attribute Image Swapper".
#103: Modify shipping tax-related processing.
#104: Always use the 'mock' cart.
#105: Add a status-history note to the order each time the order is updated or a product is added.
#106: Coupon-related corrections.
#108: Additional notification, allowing customization of display-only order totals.
#109: Additional configuration settings (see the readme for more information).
#110: Additional notification, allowing the inclusion of additional javascript/jQuery scripts.
#112: Additional notification, enabling additional columns to the order's status-history table.
#113: Don't reset shipping calculations when totals are reset.
#114: Sanitize input values and maximum field lengths.
#116: Even more notifications added, to enable additional customizations without changing the base file.
#117: Include an 'Updated By' column in the status-history table, if that field is present in the database.
#119: Correct missing constant for 'ot_onetime_discount'
#120: Supply missing 'ot_coupon' constant for zc156b beta installations.

Compatible with zc155 and zc156 installations.
Now available for download: https://www.zen-cart.com/downloads.php?do=file&id=1513

lat9:

@jvdd, there was most likely an associated /logs/myDEBUG-adm-*.log file on/around the time of that EO log. My guess is that the processing is running out of memory, but a log will 'say' for sure.

Remember, if you're posting an admin log that it will contain your store's secret admin directory name, so be sure to xxx-out any path information before posting.

Thanks for replying. I archived and reset the logs before that date and haven't gotten any new error log files after that. The reason why I enabled the EO logs was to see if there were any indication of errors.