Note on #56: Users must remember to manually press the button.
Printable View
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.Quote:
Originally Posted by swguy
:thumbsup:
That was quick! It's now available for download!Quote:
Originally Posted by lat9
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
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.Quote:
Originally Posted by lat9
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.
@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.Quote:
Originally Posted by 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:
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...Code: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
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.