Edit Orders v4.0 Support Thread

[swguy]

Note on #56: Users must remember to manually press the button.

[lat9]

Note on #56: Users must remember to manually press the button.

Actually, it's changed from the prototype I sent you. The processing now has a checkbox field which, if set, causes the order's totals to be reset rather than a separate button. You can configure the default value for that checkbox field in Configuration->Edit Orders.

[swguy]

[lat9]

I've just submitted v4.3.0 of Edit Orders to the Zen Cart plugins for review. That release contains changes associated with the following GitHub issues:

#50: Correct product.products_ordered calculation (thanks @siliconforks!).
#52: Correct PHP warning when an order-total doesn't include a "TAX_CLASS" setting.
#53: Additional notifiers for address-field insertions.
#54: Invalid value used in "Mock Cart" processing.
#55: Correct PHP "notify" issues.
#56: Correct order-total calculations when order-totals re-compute tax (e.g. group pricing), as reported by @swguy here.
#57: Properly report missing notifiers

I'll post back here once the download is available.

That was quick! It's now available for download!

[Purecarsound]

Hi

Just updated to latest version. All works great (as expected!).

A wish list item for future versions/updates - not sure how hard it would be to incorporate - our site is UK based and we use 'state' (changed to 'County') as a dropdown which must be selected by a customer for UK Royal Mail shipping to be applied. Is it possible to have the 'state' field as a dropdown on the edit orders page so that we can ensure the correct state/county is selected?

Thanks

Mark www.johnwoodsmotorcare.co.uk/Shop | www.johnwoodsmotorcare.net

[lat9]

Sounds like a good idea; I've created an issue in Edit Orders' GitHub repository so that I don't lose the request!

[carlwhat]

Sounds like a good idea; I've created an issue in Edit Orders' GitHub repository so that I don't lose the request!

@lat9 when i have some time, i will take a look at this new release, and compare it to all of the changes i have done over the years.

without even thinking too much about it, i remember order total calculations, tax calculations (especially when using a different tax module) and changing line item quantities have been problematic. the last item caused me a bunch of grief, as the deletion of a record in orders_products and re-creation of a new record in that same table seems like overkill for changing the quantity from 2 to 3. and despite it being overkill, it overlooks the idea that a store owner could have additional fields in that table due to modifications, and that significant data gets lost. i am not sure if this version addresses that issue. but considering i do have clients using this add-on, and with your name on it, i will try and spend a bit of time on it.

if i find any issues that i think are of merit, lmk if you would prefer me to add something onto your github or if you would prefer to discuss them here.

best.

[lat9]

@carlwhat, this version still removes/recreates those orders_products and orders_products_attributes records. There are notifiers now issued by EO when it's preparing to remove and then re-instate those records, though, so an admin-level observer can keep those additional fields intact.

That said, I expect to have that processing changed in the next major release.

If you find any issues, please report them here since I think that this support thread has a wider audience.

[lat9]

@carlwhat, this version still removes/recreates those orders_products and orders_products_attributes records. There are notifiers now issued by EO when it's preparing to remove and then re-instate those records, though, so an admin-level observer can keep those additional fields intact.

That said, I expect to have that processing changed in the next major release.

If you find any issues, please report them here since I think that this support thread has a wider audience.

FWIW, I've created this GitHub issue to track this request.

[carlwhat]

ok... i have taken a cursory look, and i'll add a few comments and then i will move on.

first off, props to you @lat9 for taking this mess on! i appreciate all of the documentation you have added (not that i understand it..), and eventually this will possibly make more sense to me...

similar to you, i come from an old school background, learning old school procedural languages, before transitioning into OOP. unlike you, i have not picked it up nearly as well.... ;)

some of the things that i have been forced to focus on deal with totals, and how ot_* groups never add up.

let's look at ot_subtotal.

here is some code that i was forced to add:

function eo_update_order_subtotal($order_id, $product, $add = true) {
	global $currencies, $db, $order;
	// forget their stuff...  just recalculate
	
	$RunningSubTotal = 0;
	$RunningTax = 0;
	foreach($order->products as $products_details) {
		$RunningSubTotal += $products_details["qty"] * $products_details["final_price"];
		$RunningTax += (($products_details["tax"]/100) * ($products_details["qty"] * $products_details["final_price"]));
		$TaxRate = $products_details["tax"]/100;  // assume tax rate the same for all products
	}

	// Retrieve running subtotal

i have ZERO confidence in the amount in ot_subtotal. in fact, i had to create a new function to recalculate the ot_subtotal! granted, i'm making assumptions based on my knowledge of the constants stored in the configuration table, but still...

whether the ot_subtotal amount in your new version is correct now, i can not say.... but i swore off debugging this module! its just easier to recalculate it on my own.

with that said, i have made things work for my few ZC clients, without concern with how they will work for others.

another one of those things is taxes (you can see a little bit above). i make use of the ot_local_sales_tax which basically deals with 2 tax rates for orders. but more importantly, there is only ONE tax rate for any order. now, i am not sure how many ZC installs out there that have a different tax rate for different line items on the order, but i'm guessing they exist. i have non-ZC clients that is the case, although rare. mostly some items are for re-sale and not taxable and others are not. but there are no orders with 2 different non-zero rates.

if those exist, should ZC support those functions?

but i have never been able to get this add-on out of the box to calculate the tax correctly. especially when using a tax add-on module as the base ot_tax module does not work for my clients.

which is why i am forced to recalculate a tax rate above.

i hate the use of $GLOBALS. it would be great to eliminate all of those references.

ot_shipping, can include tax - although some times not.... depends on the store owners accountant (although they are no doubt interpreting tax law).... again, never got it to work.... and the same with ot_coupon. ot_coupon should reduce the tax amount of the order while a gift certificate should not.

i apologize. i suppose i am complaining more than doing anything constructive. if i get the energy to start with a vanilla install, add the ot_local_sales_tax module, then implement this edit_orders add-on and see how coupons and gift certificates work, how tax on shipping works, perhaps i can add more relevant information to the discussion.

at the end of the day, it just seems that there is too much reliant on numbers already stored in the DB as opposed to recalculating the numbers as they get done. whether that is the case in the new version i can not say... at least at this point.

again, i want to say that i appreciate all of your efforts, and i read all of your posts with interest as there is always the probability that i will learn something.

best.