Yes, I did a normal purchase of the same product from the store-side. As noted above, the total is correct. See Store order detail.jpg file in post 1198, list item 5, and the first file attached.
Printable View
Yes, I did a normal purchase of the same product from the store-side. As noted above, the total is correct. See Store order detail.jpg file in post 1198, list item 5, and the first file attached.
... and you're having difficulties using EO to edit that order (or one created by your modifications to Admin New Order)?Quote:
Originally Posted by Dave224
one created by by my modified Admin New Order.
I'll suggest placing a "normal" order via the storefront and then placing the same order with your modifications, comparing the order-related database elements between the two to see what's different.Quote:
Originally Posted by Dave224
Comparing the database tables did not reveal anything unusual except the orders_total table for ot_total class was different, as expected. Also, the order of the classes in the orders_total table differed, with ot_shipping being the last entry for the order created using Admin New Order/ Edit Orders, but I don't think this is an issue.
I have struggled through the Edit Order code and debug log for the order. After the product is added and before shipping is added, at the step where getOrderInfo is called by edit_orders.php on line 655, everything looks correct including ot_total at this point. At the point where eo_update_database_order_totals, taxes/totals on entry called by edit_orders.php on line 656, everything looks correct. Then Checking taxes for ot_quantity_discount is encountered, followed by eo_update_database_order_totals, after_adjustments. After checking the order for virtual status, eo_update_database_order_totals, after process shows the first occurrence where order_total is incorrect. It's too low by the tax on the quantity discount. Specifically $order->info['total'] is wrong at this point.
Problem is, I get lost trying to follow the code in store-side ot_total class, which I think is called just before $order->info['total'] is printed at the point above. Any help would be appreciated. Could this problem be associated with the fixes for GitHub issue #56?
The issue has something to do with how Admin Add New Order does its processing and does not, IMO, have anything to do with issue #56.Quote:
Originally Posted by Dave224
Might I suggest an alternate approach to creating orders for customers: Encrypted Master Password. That allows you and/or a group of admins to place an order on behalf of the customer, logging into the customer's account with their admin password.
I respectfully disagree. I just ran another case where I created an order on the store-side, then went to edit orders. I added a product with a quantity discount in edit orders. The subtotal, discount, shipping, and tax were correct, but the order total was too low by $0.06. Then I clicked update, got a successful update message, and the subtotal, discount, shipping, and tax were the same and correct, but the order total was too low by the tax on the discount, exactly the same behavior that I saw when editing an order started in Admin New Order. I think there's a problem with Quantity Discount or a problem in Edit Orders with discounts. I plan to run further tests. Sorry for being a PIA on this problem.
Now we're getting somewhere! With all the discussion of integration with Admin New Order and your changes there-to, I missed the discussion where there's an EO issue with quantity discounts.Quote:
Originally Posted by Dave224
I'll look into that over the weekend.
There's a bug and correction in Quantity Discounts, reported in Quantity Discounts support thread in post #805. It has no effect on what I'm seeing in EO. I get the same result with and without the patch. The patch was in for my initial testing of EO. Then I took it out for my later testing and put it back in for tests after post #1207.
Please note that problems with the order total when a product with quantity discount is added in EO occurs without me using Quantity Discount in the EO drop-down menu.
I hope the information I am posting is helpful to you. If you want me to run specific test cases, I would be glad to do so.
Ran a case where a product with quantity discount was ordered on the store-side. Subtotal, discount, shipping, tax and total were all correct on the store side. Went in to EO to add a non-discountable taxable product. At EO entry, the subtotal, discount, shipping, tax and total were all correct. After adding a non-discountable product and before clicking update, the subtotal, discount, shipping, and tax were correct, but the total was incorrect but not by an amount equaling the tax on the discount. After clicking update, subtotal, discount, shipping, and tax were correct, and the total was too low by the tax on the discount, as I have been reporting.
So, it makes no difference whether the quantity discountable product was in the store order or added in EO, the result is the same. The order total is too low by the tax on the discount after clicking update.
personally, i am a BIG fan of this approach.Quote:
Originally Posted by lat9
i applaud @lat9 in getting this code into some sort of workable shape, but i have found EMP to be a good solution for admins needing to enter customer orders.
Ran another test case involving group discount and not quantity discount. In this case I ordered a non-quantity discountable but group discountable product on the store side, and added another non-quantity discountable but group discountable item in EO. At EO entry, subtotal, group discount, shipping, tax and total were all correct. After adding the product in EO, the subtotal, group discount, and shipping were correct. The tax was too high by 1 cent, and the total was incorrect. After clicking update, the tax was still off by one cent, and the total was the correct total for the subtotal, group discount, shipping and tax shown.
The total was NOT too low by the discount as seen in tests involving quantity discount. So EO is not encountering the problem with group discounts.
I suspect the tax error was caused by rounding up rather than rounding down somewhere. Repeating the order on the store side gave the correct tax.
Ran another test with both quantity discount and group discount involved. In this test, I ordered a non-quantity discountable product and a quantity-discountable product on the store-side. Both products subject to group discount. Subtotal, quantity discount, group discount, shipping, tax and order total were correct. After EO entry, the totals were all the same. Now, instead of adding any products, I just clicked update. The subtotal, quantity discount, group discount, shipping and tax were correct. The total was too low by an amount that equals the tax on the sum of the quantity discount and member discount!
So something goes wrong when update is clicked and a quantity discount is present. It doesn't matter if the quantity discount product was added by EO or was in the original order, the result is that the order total is too low by the sum of quantity and group discounts. If group discount is not present, the total is too low by the tax on the quantity discount. I have no way of seeing if any other discount types affect the total.
As a side note, on the EO page, the quantity discount is editable and in a box. There is no minus sign displayed and the number is displayed to four places to the right of the decimal point. The group discount is not editable, there is a minus sign and no box. The value is displayed with two decimal places. Not sure if this is significant to the problem at hand.
With edits...
Ran another test with both quantity discount and group discount involved. In this test, I ordered a non-quantity discountable product and a quantity-discountable product on the store-side. Both products were subject to group discount. Subtotal, quantity discount, group discount, shipping, tax and order total were all correct. After EO entry, the totals were all the same and correct. Now, instead of adding any products, I just clicked update. The subtotal, quantity discount, group discount, shipping and tax were all correct. The total was too low by an amount that equals the tax on the sum of the quantity discount and member discount!
So something goes wrong when update is clicked and a quantity discount is present. It doesn't matter if the quantity discount product was added by EO or was in the original order, the result is that the order total is too low by the tax on the sum of quantity and group discounts. If group discount is not present, the total is too low by the tax on the quantity discount. I have no way of seeing if any other discount types affect the total.
As a side note, on the EO page, the quantity discount is editable and in a box. There is no minus sign displayed and the number is displayed to four places to the right of the decimal point. The group discount is not editable, there is a minus sign and no box. The value is displayed with two decimal places. Not sure if this is significant to the problem at hand.
carlwhat,
I also am very grateful to lat9 for what she has done with Edit Orders. But the issue being addressed is not Admin New Order or EMP any longer. The issue is incorrect order totals when a quantity discount is present. And we still have not found out if the problem is in Quantity Discount or in EO. Thank you for your endorsement of EMP.
@Dave224, I appreciate the testing that you're doing to identify the issue(s) but the information you've supplied so far doesn't have enough information for me to replicate. You've probably identified some of this before, but a consolidation is appreciated:
Zen Cart version
EO version
Plugins installed (name/version)
When you click "Update" are you also ticking the "Recalculate totals" checkbox?
ZC 1.5.5e
edit_orders v4.3.1 (without your proposed mod in EO support thread post #1182, so as-released EO 4.3.1)
quantity discount v1.11 (with mod in quantity discount support thread post #805 and my discount categories, levels and amounts)
admin_new_customer v1.4
admin_new_order v1.4.1 (with mods to avoid calling ot_tax.php)
stock_by_attribute v1.5.3
shipping_by_quote v2.3
product_cost_display v1.1.0
Recalculate totals checkbox is ticked by default.
Hope this helps.
It's a start ...Quote:
Originally Posted by Dave224
In EO, are you using the default settings?
For Quantity Discounts, what are your settings?
Does the product in question use attributes? If so, are they under the control of SbA?
EO settings follow:
Edit Orders Version: 4.3.1
Reset Totals on Update-Default: on
Use a mock shopping cart: true
Strip tags from the shipping module name: true
Debug Action Level: 1
Quantity Discount settings follow:
This module is installed: true
Sort Order: 200
Include Tax: false
Re-calculate Tax: Standard
Discount Units: currency per item
Discount Basis: Total By Category
Counting Method: items
Discount Level 1: 5
Discount Amount 1: .25
Discount Level 2: 13
Discount Amount 2: .5
Discount Level 3: 25
Discount Amount 3: .75
Discount Level 4: 0
Discount Amount 4: 0
Discount Level 5: 0
Discount Amount 5: 0
The product I have been testing with is subject to a special discounting policy in includes/modules/order_total/ot_quantity_discount.php. See code fragment below:
This gives $1.00 off the price per item if five or more items are purchased. The discount levels and amounts in quantity discount settings apply to another discountable product category, but I have not used that product category in my testing to date.Code:function apply_special_category_discount($category, $count, &$disc_amount) {
switch ($category) {
case 102:
if ($count > 4) {
$disc_amount = 1.00; // discount from sale price
}
break;
case 99997:
$disc_amount = 75;
break;
}
There are no attributes associated with any of the products eligible for quantity discounts.
Also, please note the product I have been testing with has a Specials price at 50% off. The normal price is $6.00 per item, the special sale price is $3.00 per item, so if five or more items are purchased, the price is $2.00 per item. I don't think this special price makes any difference, but the information is provided for full disclosure.
There is only one tax class, a state sales tax of 6% based on where the item ships. The product I have been testing with is taxable and the dummy customer lives in the state with the tax.
I hope this helps with trying to replicate the problem.
@Dave224, thanks for the update. I've replicated the issue with Quantity Discounts v1.12.1 (the current version available), EO 4.3.1 and zc1.5.5f.
I'll continue looking for a solution to the combination (Quantity Discounts/EO) but based on the specialized tax-handling that's present in Quantity Discounts, I'm not particularly hopeful that I'll find one.
Thank you for your continued efforts to find a solution. I will also continue to look.
Also, I made a mistake in the quantity discount version I am using. I am using v1.12.1 (the current version), not 1.11 (which is what I was using with zc v1.5.1). Sorry for any confusion.
While trying to find the solution to the incorrect order total in Edit Orders, I found that function eo_update_database_order_totals in admin/includes/functions/extra_functions/edit_orders_functions.php calls function eoGetOrderTotalTax in admin/includes/classes/editOrders.php. For Quantity Discounts, MODULE_ORDER_TOTAL_QUANTITY_DISCOUNT_TAX_CLASS does not exist, so the routine returns zero. This value is subsequently subtracted from $order->info['tax'] and a little later from $order->info['total']. As a test to see if the lack of this ...TAX_CLASS was the source of my problem, I fudged the return from the routine with the tax on the quantity discount. Now when I reran my test case, the order total was correct, but the now the tax was too high by the tax on the discount. I am so confused now I must be missing the obvious. Any help would be gratefully appreciated. I really need to make this work for our store.
I could repro this issue with a Quantity Discount giving 5% off quantities of 5. Start with an order with quantity 4 of an item.
Sub-total: $400
Tax (7%): $28
Total: $428
Run EO and change quantity to 5.
The line items other than the total are correct.
Sub-total: $400
Quantity Discount: $25
Tax (7%): $33.25
Total: $506.50 // should be 508.25
Yep, that's pretty much what I did to replicate the issue. As mentioned above, I've not finding a way for EO to deal with the tax-calculation method that Quantity Discounts applies and there's no method defined to determine the amount of tax an order-total contributed (either via addition or subtraction) to the order.Quote:
Originally Posted by swguy
Whether or not I ticked the "reset totals" box, EO's results were the same.
Does EO work with a built in module like Group Pricing? If so, what's different?
Yes, it does. The difference is that Group Pricing makes changes to the products' prices and the base tax processing does its thing. For Quantity Discounts, the products' prices are left as-is and the deduction (both in product-cost and tax) is calculated after-the-fact.Quote:
Originally Posted by swguy
One thing that's different is that group discount has a tax_class, MODULE_ORDER_TOTAL_GROUP_PRICING_TAX_CLASS, while quantity discount does not. EO logic appears to return 0 for a quantity discount, instead of the tax on the quantity discount of the unedited order (I think). See my last post in this thread.
Are you thinking about something else maybe? The built-in Group Pricing module is an order total module just like the Quantity Discounts order total module. It doesn't change prices. It gives you a single line item discount.Quote:
Originally Posted by lat9
Dave, that setting only applies to Credit Note, which is not a supported setting in my mods.Quote:
Originally Posted by Dave224
I'm just grasping at straws at this point. I hope you two can figure this out!
It would be nice to know what $order->info['total'] and $order->info['tax'] is supposed to include and what is not to be included at the point in EO logic "after adjustments" in the EO debug logs.
Same problem occurs with Group Discounts. Run the order with no discount, add the customer to a discount group, edit the order - the total is wrong.
Group Discount include tax = false, include shipping = false, recalculate tax = standard.
Original Order:
Sub-Total $500
FL Tax 7% 35.00
Total $535.00
Add Group discount of 25%:
Sub-Total $500
Group Discount $125
FL Tax 7% 26.25
Total $392.50
should be $401.25.
Yep, I was thinking about the built-in quantity discounts' processing.:blush:Quote:
Originally Posted by swguy
If I trick function eoGetOrderTotalTax to return the tax on the quantity discount and make it a negative quantity, the order total and order tax is correct. In my test cases, the discount is $5.00 and the tax is 6%, or $0.30. See code below.
Code:// -----
// Cycle through the order-totals to see if any are currently taxed. If so, remove the
// tax from the current order in preparation for its recalculation.
//
foreach ($order->totals as $current_total) {
if (in_array($current_total['class'], array('ot_subtotal', 'ot_tax', 'ot_shipping', 'ot_total'))) {
continue;
}
$current_total_tax = $eo->eoGetOrderTotalTax($oID, $current_total['class']);
$current_total_tax = -0.3; // trick out function for test case
$order->info['tax'] -= $current_total_tax;
}
Unfortunately, the keyword there is trick; I'm looking for a reliable way to regenerate any tax applied by those order-total modules.Quote:
Originally Posted by Dave224
The "trick" was to demonstrate that the problem is that quantity discounts is not processed properly in function eoGetOrderTotalTax. If MODULE_ORDER_TOTAL_QUANTITY_DISCOUNT_TAX_CLASS were defined, the function would get the tax on the discount from the database, and no trick would be required. I'm trying to be helpful. If I'm not, tell me and I'll go away.
Should be "...the function would calculate the tax from the discount value in the database, and ...Quote:
Originally Posted by Dave224
Dave, you are being helpful and realize that the issues' source is based on the lack of "standardization" of how various order-total modules choose to apply/remove any tax-based values.Quote:
Originally Posted by Dave224
I think most modules have a _CALC_TAX setting, and the use of "Standard" is pretty common. You could start with that.Quote:
Originally Posted by lat9
This is still a trick. As I said earlier, the TAX_CLASS variables were defined to support Credit Notes. You're overloading it to mean something else. This is not a good approach.Quote:
Originally Posted by Dave224
Actually, I'm looking to use the calculate_deductions method, if it exists.Quote:
Originally Posted by swguy
Hmm, I ran this test on EO 4.3.1, ticking the "Reset totals" box and the calculation was correct. What version of EO are you testing with?Quote:
Originally Posted by swguy
I've been Googling but have not found anywhere that Zen Cart "Credit Note" functionality is defined. Could/would you fill in the blanks?Quote:
Originally Posted by swguy
I was on 4.2.3. Upgraded to 4.3.1, you're right - Group Discounts worked; Quantity Discounts did not.Quote:
Originally Posted by lat9
It's just a setting for tax recalc. I'm not positive it was ever fully implemented. You can see it in both ot_coupon.php and ot_group_pricing.php in includes/modules/order_total.Quote:
Originally Posted by lat9
Cindy, I wonder if the way to go here is just add up the line items to get the total, rather than depending on the individual machinations of mods (which were designed to run on the catalog side) updating $order->info['total'].
@swguy, I've also wondered why that path wasn't taken with the design ... although EO has been around (in various forms) since dinosaurs roamed the earth, so at this point it's not so much a design as a go-with-the-flow.Quote:
Originally Posted by swguy
Cindy,
I hate to tell you, but I found another problem in Edit Orders 4.3.1. If you add a product to an order or change the quantity of an item in the order, the change is made even if there is insufficient stock in inventory. Might be nice to bring up a warning message if there is insufficient stock when adding a product or increasing the quantity of a product.
Dave :(
Dave, thanks for the report. When I get back to my EO investigations, I've added that to the list!Quote:
Originally Posted by Dave224
Edit Orders 4.3.1 and my mods (Quantity Discounts, Better Together, et. al.):
This seems to work. In the function process() in the code file in includes/modules/order_total (e.g. includes/modules/order_total/ot_quantity_discount.php for Quantity Discounts)
Change
toCode:if ($this->calculate_tax != 'VAT') {
$order->info['total'] -= $od_amount[$key];
}
Code:if (!IS_ADMIN_FLAG) {
if ($this->calculate_tax != 'VAT') {
$order->info['total'] -= $od_amount[$key];
}
}
Thanks, @swguy. I'm in the process of vetting that integration; I'll give that change a go.Quote:
Originally Posted by swguy
Hello,
I have added the products price to my order confirmation email. The issue I have is that it is not formatted as currency ($-Canadian). See below:
3 x KARMA Wellness Water - Probiotics Blueberry Lemonade 12 x 532ml Plastic (KAR532PBL) @ 35.2 = $105.60
I want the price 35.2 to appear as $35.20 and don't know the syntax.
Below in red is what I changed/added in includes/classes/order.php
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\$sql_data_array = array('orders_id' => $zf_insert_id,
'products_id' => zen_get_prid($this->products[$i]['id']),
'products_model' => $this->products[$i]['model'],
'products_name' => $this->products[$i]['name'],
'products_description' => zen_get_products_description($this->products[$i]['id']), //added by JM
'products_price' => $this->products[$i]['price'],
'final_price' => $this->products[$i]['final_price'],
'onetime_charges' => $this->products[$i]['onetime_charges'],
'products_tax' => $this->products[$i]['tax'],
'products_quantity' => $this->products[$i]['qty'],
'products_priced_by_attribute' => $this->products[$i]['products_priced_by_attribute'],
'product_is_free' => $this->products[$i]['product_is_free'],
'products_discount_type' => $this->products[$i]['products_discount_type'],
'products_discount_type_from' => $this->products[$i]['products_discount_type_from'],
'products_prid' => $this->products[$i]['id']);
zen_db_perform(TABLE_ORDERS_PRODUCTS, $sql_data_array);
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
I also added the following in red:
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
$this->products[$index] = array('qty' => $products[$i]['quantity'],
'name' => $products[$i]['name'],
'model' => $products[$i]['model'],
'tax_groups'=>$taxRates,
'tax_description' => zen_get_tax_description($products[$i]['tax_class_id'], $taxCountryId, $taxZoneId),
'price' => zen_round($products[$i]['price'],$decimals),
'final_price' => zen_round($products[$i]['price'] + $_SESSION['cart']->attributes_price($products[$i]['id']), $decimals),
'onetime_charges' => $_SESSION['cart']->attributes_price_onetime_charges($products[$i]['id'], $products[$i]['quantity']),
'weight' => $products[$i]['weight'],
'products_priced_by_attribute' => $products[$i]['products_priced_by_attribute'],
'product_is_free' => $products[$i]['product_is_free'],
'products_discount_type' => $products[$i]['products_discount_type'],
'products_discount_type_from' => $products[$i]['products_discount_type_from'],
'id' => $products[$i]['id'],
'rowClass' => $rowClass);
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
the line that displays details of the product order has been changed to the following:
$this->products_ordered .= $this->products[$i]['qty'] . ' x ' . $this->products[$i]['name'] . ' ' .zen_get_products_description($this->products[$i]['id']) . ' ' . ($this->products[$i]['model'] != '' ? ' (' . $this->products[$i]['model'] . ') ' : '') . '@ ' .$this->products[$i]['price']. ' = ' .
Any help is appreciated.
Thanks in advance!
@allmart, why is this (re-)posted in the Edit Orders plugin's support thread?
My apologies yesterday I originally posted in the correct thread. Today when I checked the thread I didn't realize that I was viewing the wrong thread and saw nothing posted so I re-posted, now realizing that I was in the incorrect thread (edit orders).Quote:
Originally Posted by lat9
What a dope and I am sorry.
Cheers!
Please take the following with a grain of salt because it was tested on ZC 1.5.6 beta though the results were the same as reported by someone using ZC 1.5.5f.
There are centrally two issues, one for eventual consideration of design of the home grown support software to EO and the following primary issue.
Once an order is placed that contains any number of product with attributes, going to edit orders and selecting the update button causes the attributes of all product in the order to be removed.
The other issue (again with ZC 1.5.6 still being in development) is that the notifiers for adding buttons into the order page are modified away from what is used in the current version of Edit orders (4.3.1) which may be an issue with the software that detects the presence of applicable notifiers (though may not also) in a single install as between two different versions of ZC the "same" notifier may exist but by a different name. I have not looked into the operation to identify the capability but thought notification of that potential issue would help plan for such "control" if not already considered.
The first issue arises from the current EO design. When an order is updated, all products are removed/re-added ... including their attributes. Until I get time to go down a re-design path, that's the way it is.Quote:
Originally Posted by mc12345678
I'll check on those notifiers; I've been trying to keep them in-line with future ZC base values.
To be clear, the highlighted portion does not fully occur. The "product" itself remains, but the attributes associated are removed. Permanently. They can be "added" back in only if the product is added with the associated attributes (costs and other characteristics), but an update from the current page (whether adjusting the attributes or not) plain removes attributes from all product whether the product was edited or not.Quote:
Originally Posted by lat9
Seeing that little has/had changed in the base "direction" to remove and add product's to the order, my search led me to consider other "black boxes" with current review of the admin's attributes class because of the breadth of changes that were made between the current version and a version that I could readily identify as previously working (4.1.7). (I know a long time ago. :) ).
Well, :censored:. I've noted the issue on GitHub and address it over the weekend.Quote:
Originally Posted by mc12345678
OK, as usual, this was bugging me (no pun intended).Quote:
Originally Posted by lat9
The change (currently up on EO's GitHub repository) involves a teeny change to use the correct:blush: variable name.
In /YOUR_ADMIN/edit_orders.php, find the following section (around line 377):
and make the highlighted change:Code:if ($product_update['qty'] > 0) {
// Retrieve the information for the new product
$attrs = (isset($product_update['attr'])) ? $product_info['attr'] : '';
unset($product_update['attr']);
$new_product = eo_get_new_product(
$old_product['id'],
$product_update['qty'],
$attrs,
false
);
unset($attrs);
Code:if ($product_update['qty'] > 0) {
// Retrieve the information for the new product
$attrs = (isset($product_update['attr'])) ? $product_update['attr'] : '';
unset($product_update['attr']);
$new_product = eo_get_new_product(
$old_product['id'],
$product_update['qty'],
$attrs,
false
);
unset($attrs);
Certainly looks like that will fix it. (Note, there appear to be other "notice" related items to address besides what was done for that line.)
I'm sure there are; I'm holding off for the re-design to address those.Quote:
Originally Posted by mc12345678
I've just submitted v4.3.2 of EO to the Zen Cart plugins for review, containing changes associated with the following GitHub issues:
#66: Load EO functions only for EO's use.
#68: Log-file formatting updates.
#69: Attributes "lost" from ordered products when an order is updated.
See https://github.com/lat9/edit_orders for details. I'll post back here when it's available for download from the ZC Plugins.
Thank you for addressing this. The last piece of the puzzle for us to go live with 155f.Quote:
Originally Posted by lat9
No problems, thanks to you and @mc12345678 for identifying the issue ... it's hard to fix something I don't know about!Quote:
Originally Posted by athena
I just installed the latest edit order code with this fix included on my test server with 155f.Quote:
Originally Posted by athena
I can edit attributes OK and the attribute description changes OK but the associated price does not change! Probably I did something wrong somewhere, I just wondered if the price change works OK for you before I start digging into my update?
The older version of edit order works fine on my production server with 155e.
How is that product defined? What types of attributes (e.g. radio, dropdown) are you using? Is the product priced by attributes?Quote:
Originally Posted by marton_1
I'll try to replicate the issue, but those answers will save me some time.
Apologise in advance if it turns out to be my finger trouble.Quote:
Originally Posted by lat9
The product has a base price and larger sizes have an add-on price.
The size attribute is a drop down.
Here is a link to the live product, best way to answer your question?
Thanks in advance
English language here
I also tried with and without "Reset totals prior to update? " set.
Thanks, I was able to replicate the issue locally. I'll report back when I've found the source of the issue.
OK great, sorry to make work.Quote:
Originally Posted by lat9
You're not making work, you're helping to improve EO.Quote:
Originally Posted by marton_1
Look in your store's /admin/edit_orders.php, finding the following code section at around line 388:
and make the change highlighted below:Code:
// Handle the case where the product was deleted
// from the store. This should probably never be done.
// Removing the product will cause issues with links
// on invoices (order history) and will not allow the
// price(s) or tax(es) to be recalculated by Zen Cart.
if (!isset($new_product['price'])) {
$new_product['price'] = $old_product['price'];
$new_product['tax'] = $old_product['tax'];
if ($new_product['tax'] > 0) {
// Should match what is set by eo_get_product_taxes()
// When no description is present in the database but
// a tax rate exists on a product.
$new_product['tax_description'] = TEXT_UNKNOWN_TAX_RATE . ' (' . zen_display_tax_value($new_product['tax']) . '%)';
}
$new_product['products_discount_type'] = $old_product['products_discount_type'];
$new_product['products_discount_type_from'] = $old_product['products_discount_type_from'];
$new_product['products_priced_by_attribute'] = $old_product['products_priced_by_attribute'];
$new_product['product_is_free'] = $old_product['product_is_free'];
}
// Adjust the product information based upon the
// data found in update_products
$new_product = array_merge($new_product, $product_update);
The issue is that the updated line was resulting in the previous product ($product_update) information (most importantly, the calculated price) was overwriting the newly-calculated price!Code:
// Handle the case where the product was deleted
// from the store. This should probably never be done.
// Removing the product will cause issues with links
// on invoices (order history) and will not allow the
// price(s) or tax(es) to be recalculated by Zen Cart.
if (!isset($new_product['price'])) {
$new_product['price'] = $old_product['price'];
$new_product['tax'] = $old_product['tax'];
if ($new_product['tax'] > 0) {
// Should match what is set by eo_get_product_taxes()
// When no description is present in the database but
// a tax rate exists on a product.
$new_product['tax_description'] = TEXT_UNKNOWN_TAX_RATE . ' (' . zen_display_tax_value($new_product['tax']) . '%)';
}
$new_product['products_discount_type'] = $old_product['products_discount_type'];
$new_product['products_discount_type_from'] = $old_product['products_discount_type_from'];
$new_product['products_priced_by_attribute'] = $old_product['products_priced_by_attribute'];
$new_product['product_is_free'] = $old_product['product_is_free'];
}
// Adjust the product information based upon the
// data found in update_products
$new_product = array_merge($product_update, $new_product);
I'll get this issue (and the correction) up on the EO GitHub site, noting that the issue has been around since at least v4.1.5! Thanks for the catch.
I did not even notice that! Thank you! Fix seems to do the trick.Quote:
Originally Posted by marton_1
Wow, that was a lightning quick fix :smile: :clap:
Works great!
"been around since at least v4.1.5" LOL!
Sorry for my delay in replying, I had an unrelated customer problem.
I really must learn PHP. I had my first computer programming job 55 years ago but I have some sort of internal resistance to learning modern computer languages that do not require me to write some pages of definitions before I even start coding :D
Thanks for the report back ... customer issues always take first priority!Quote:
Originally Posted by marton_1
I still remember the first time I was introduced to C code and thinking "How could anyone ever figure out that funkiness?".
I've just submitted v4.3.3 of EO to the Zen Cart plugins for review and will post back here, once it's available. This release contains changes associated with the following issues, as identified by the GitHub issue number from https://github.com/lat9/edit_orders:
#67: Display message if insufficient product quantity is available.
#70: Product's price not updated if attributes changed.
#71: Align "notifications" with Zen Cart 1.5.6 and later.
Quote:
Originally Posted by lat9
EO v4.3.3 (containing the above changes) is now available for download from the Zen Cart plugins: https://www.zen-cart.com/downloads.php?do=file&id=1513Quote:
Originally Posted by lat9
I've got EO v4.3.4-beta1 available if anyone wants an early peek: https://github.com/lat9/edit_orders/...g/v4.3.4-beta1
That version currently contains changes associated with the following GitHub issues:
#65: Enable `ot_onetime_discount` to both add to and deduct from an order's total.
#72: Additional notifications for plugin support.
#73: Tax-handling corrections, enables proper integration with plugin order-totals.
#74: Correct PHP 7.1+ warning
Please note that change#73 could be disruptive for stores using Quantity Discounts. I've validated the integration using v1.12 of that plugin, with the edit suggested by this posting in the QD support thread.
Unless I hear of issues, I'll be packaging this up as v4.3.4 of EO later in the week.
Hi there
I just installed the module and am running into an issue that I have tracked down to the (IS_ADMIN_FLAG === true) in the /includes/classes/shipping file.
I am using Edit orders 4.1.7 and running Zen Cart 1.5.4
In the admin section the pages are not loading because of an file load error. If I hack the IS_ADMIN_FLAG then the pages loads with out errors. I am going with the assumption that there is an issue with the admin files calling the catalog files or that there is an issue with using a shipping file that is a core 1.5.5a when I am running 1.5.4. Any help would be appreciated.
Thanks
Code:if (IS_ADMIN_FLAG === true) {
$lang_file = zen_get_file_directory(DIR_FS_CATALOG . DIR_WS_LANGUAGES . $_SESSION['language'] . '/modules/shipping/', $include_modules[$i]['file'], 'false');
$module_file = DIR_FS_CATALOG . $module_file;
} else {
$lang_file = zen_get_file_directory(DIR_WS_LANGUAGES . $_SESSION['language'] . '/modules/shipping/', $include_modules[$i]['file'], 'false');
}
[20-Mar-2018 13:50:06 America/Los_Angeles] PHP Warning: include_once(includes/modules/shipping/canadapost.php): failed to open stream: No such file or directory in /home/xxx/public_html/includes/classes/shipping.php on line 64
[20-Mar-2018 13:50:06 America/Los_Angeles] PHP Warning: include_once(): Failed opening 'includes/modules/shipping/canadapost.php' for inclusion (include_path='.:/usr/local/lib/php') in /home/xxx/public_html/includes/classes/shipping.php on line 64
[20-Mar-2018 13:50:06 America/Los_Angeles] PHP Fatal error: Class 'canadapost' not found in /home/xxx/public_html/includes/classes/shipping.php on line 65
First question: does this file exist? Warning: include_once(includes/modules/shipping/canadapost.php): failed to open stream: No such file or directoryQuote:
Originally Posted by s-thomas
There may be some database remnant that is causing this issue.
Quote:
Originally Posted by lat9
array-merge "merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array. If the input arrays have the same string keys, then the later value for that key will overwrite the previous one"
(source: http://php.net/manual/en/function.array-merge.php)
$new_product must be overwritten by $product_update (but not vice versa - as exactly $product_update contains information about new price got from $_POST)
Thus, why the previous version is not correct ??
(I have got issue with price update exactly with latest code version, but never with previous...)Code:// Adjust the product information based upon the
// data found in update_products
$new_product = array_merge($new_product, $product_update);
I understand how array_merge works:smile:; unfortunately, the solution for the previous issue presented (i.e. that updated attributes' pricing wasn't being honored) required that the $new_product information (that includes that updated pricing) overwrite the values entered on the form ... resulting in the issue you've identified.Quote:
Originally Posted by yesaul
It looks like EO will need to record (in hidden inputs) the initial price displayed for each product and, if that price is updated, use the entered price instead of re-calculating.
FWIW, I've created this GitHub issue to discuss and track the above change.
Thank you for prompt reply.Quote:
Originally Posted by lat9
I'm pretty sure, you understand how array_merge works, but I haven't been sure if I do too...
To my happiness, I do not use products with attributes.
And is seems, for people like me the previous version of code is correct, but not new.
Until I think this through for the general case, you should reverse the order of that array_merge statement to its previous version:Quote:
Originally Posted by yesaul
... so that the values from the form ($product_update) overwrite the new calculations ($new_product).Code:$new_product = array_merge($new_product, $product_update);
Yes the file exists. If I set the IS_ADMIN_FLAG to true everything works fine.
@mc12345678 Yes the file exists. If I set the IS_ADMIN_FLAG to true everything works fine.Quote:
Originally Posted by s-thomas
1.5.5f
Super Orders 10K, Edit Orders 4.3.3, Ty-Package Tracker 3.1.5
PHP 5.6, only because Super Orders doesn't support 7 and above yet/ever...lol
I'm at a bit of a loss as everything has been working fine on our site until earlier today.
We updated to EditOrders 4.3.3, cleaned up SO code and got Ty Package Tracker working again 2 weeks ago and everything has been working great
Until earlier today when I suddenly began getting Admin Debug Logs complaining about some code in Admin/orders.php and the EditOrders screen stopped updating line items when I made changes and clicked on "Update"
mc12345678 helped me through the DeBug log issue, thank you very much, by supplying me with a couple of code changes to the SO code in admin/orders.php and admin/super_data_sheet.php, but I am still fighting the no update issue.
If I go to EditOrders from the SuperOrder's Order page, change the price of a line item and click "Update" the system acts like it is doing something, the screen refreshes and the changes I made are converted back to the original entry but no DeBug files are generated as if there was no error.
I'm starting to wonder if I should remove Super Orders but I really need the Split Order and payment functions.
Any assistance would be greatly appreciated
I enabled EOs debug feature and attached the file here if that will help.Attachment 17754Quote:
Originally Posted by wsworx
Although lat9 has temporarily reversed the suggestion of Post 1271, curious if that revision resolves the issue.Quote:
Originally Posted by wsworx
This is unusual and not fully clarified. The IS_ADMIN_FLAG has been part of ZC for some time and as edit_orders is run from the admin, the value should already be true it seems (haven't reviewed the code to validate/contradict that theory). Where in the code is this "new" setting being applied and is it something that is not properly managed in the problem shipping module?Quote:
Originally Posted by s-thomas
As a distinction, what I said was that for people who want to have control over the price (as opposed to having it re-calculated) that the reversion back will resolve that issue.Quote:
Originally Posted by mc12345678
Edit Orders v4.3.4-beta2 is now available (https://github.com/lat9/edit_orders/...g/v4.3.4-beta2) for those that want a pre-check.
That version (to be released as v4.3.4) now includes two additional configuration settings to allow a store to identify how product-price calculations should be handled. Those new settings are described in this GitHub issue: https://github.com/lat9/edit_orders/issues/75
I'm still mystified by all this as everything was running great and the boom out of no where this stuff starts.Quote:
Originally Posted by mc12345678
I went back as you suggested and changed it back to the original setup and it is now working.....lol.
Everything was running great for your setup; other stores (where attributes' pricing was in effect) were not previously working. The v4.3.4-beta2 update recognizes those setup differences, which I hadn't accounted for in the EO 4.3.3 update.Quote:
Originally Posted by wsworx
All I can say is it is a great PlugIn and I, as well as many others I am sure, can't thank you enough for your hard work and dedication.Quote:
Originally Posted by lat9
I've just submitted v4.3.4 of Edit Orders to the Zen Cart Plugins for review; once available for download, I'll post back here.
This release contains changes associated with the following GitHub issues, see https://github.com/lat9/edit_orders for additional information:
#65: Enable `ot_onetime_discount` to both add to and deduct from an order's total.
#72: Additional notifications for plugin support.
#73: Tax-handling corrections, enables proper integration with plugin order-totals.
#74: Correct PHP 7.1+ warning
#75: Entered product price no longer overrides calculations. In support of that change, two additional Edit Orders configuration settings are created!
#76: Changes to the order's `shipping method` don't "stick".
#77: Re-align `/YOUR_ADMIN/orders.php` notifiers with those present in Zen Cart 1.5.6 and later.
Now available for download from the Zen Cart plugins: https://www.zen-cart.com/downloads.php?do=file&id=1513Quote:
Originally Posted by lat9
Thank You lat9!Quote:
Originally Posted by lat9
Quote:
Originally Posted by s-thomas
I have just come across this issue. I have used Edit Orders extensively previously without seeing this.
Definitely, seems to be a relative path issue when the shipping modules are loaded from admin. The original OP says the file is there. Well, actually that is not strictly true. The current working directory is admin, so the inclusion of 'includes/modules/shipping/canadapost.php' in his case fails. And it should fail because we are in the admin folder.
If the CWD was the root directory this inclusion would work on his/her server. So, this is what I encountered anyway. My resolution to it was to change the CWD just before the shipping modules are included and then return it back to admin afterwards. Now everything works.
I am not sure if this is server specific, or php version specific. Someone with more sysadmin experience than me can comment about that. I guess there must be some complication if not everyone is experiencing this.
Nick
@niccol, the changes to the /includes/classes/shipping.php use the absolute directory when loaded via the admin (the pre-pending of the DIR_FS_CATALOG to the 'relative' directories). Is it perhaps that the DIR_FS_CATALOG identified in the admin's /includes/configure.php is empty?