Edit Orders v4.0 Support Thread

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

[lat9]

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.

Those pesky totals/taxes calculations were the reason for the addition of the additional configuration setting (and checkbox) in v4.3.0. When the checkbox is checked, EO's totals calculations are given a "restart" (i.e. setting the order's total and tax to 0).

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.

From what I remember from discussions with lhungil, the local_sales_tax plugin was always problematic for EO (it's even called out in the readme). Since I don't use that plugin with EO, I don't know if the "reset totals" processing will help or not.

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

Actually, I'm going in the opposite direction. I find that (although it tends to uglify the code) using $GLOBALS helps me to remember that a value is being used and/or set outside the scope of a function or class. I agree that there's no need for the $GLOBALS within the procedural portions (i.e. /admin/edit_orders.php) of the processing!

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.

No apologies necessary, fresh ideas and discussion are always welcomed!

[allmart]

Great mod!!
I was hoping I could get some direction with an issue I have. I have a field "products_description" that displays in orders.php, but after I modify the order, it no longer appears.

Thanks,