Thanks, swguy!
Printable View
Thanks, swguy!
Submitted. Just an asterisk was a bit hard to see so I changed it to "(OOS)".
So I guess a gating factor for the release of this update will be the release of the update to the Trustwave patch, right?
I'm waiting for 1.5.5a to be released so that I've got a tangible version of Zen Cart 1.5.5 that I can "target" for installation (and the time to get the readme and installation files updated).Quote:
Originally Posted by swguy
You probably already know this but: with the originally released admin sanitizers, product names such as "Foo & Bar" get changed to "Foo & Bar". Perhaps product name should not be an editable field - although I know that's just a workaround. Excitedly anticipating the update for this mod.
Installed Edit Orders v4.0 as addon to my zen cart and everything looks okay. Can call up orders to edit. Editing cusomter info, etc. is fine. Can edit and the when update it works. But, when editing any product info... qty, price etc. then hit update, POOF all the product order is gone. No product order info is left, just a blank order. Figure I have done something wrong but nor sure what.
It even says Success Order has been successfuly update!!Quote:
Originally Posted by kcallagmy
Zen Cart version is 1.5.5
If you're talking original, i.e. currently-released, versions of Zen Cart 1.5.5, then that happens when creating products, too. The forthcoming version of EO will check for Zen Cart 1.5.5 and then also for the presence of the enhanced sanitizer before allowing a Zen Cart 1.5.5 installation of EO to proceed.Quote:
Originally Posted by swguy
Quote:
Originally Posted by kcallagmy
Quote:
Originally Posted by kcallagmy
You're not specific when you say Edit Orders 4.0, is that the most recent version, v4.1.4? Edit Orders, as currently available from the Zen Cart Plugins, does not work with the as-currently-released versions of Zen Cart 1.5.5.Quote:
Originally Posted by kcallagmy
Once the ZC 1.5.5 "sanitizer" update is packaged and released, allowing some EO regression-testing, EO 4.1.4a's release will be forthcoming.
Well there in lies the problem. I took the as currently release versions of both only to find that they do not "like" each other. Me Bad!Quote:
Originally Posted by lat9
Zencart 1.5.4
Will EO work with 1.5.4? So many mods we use will not work with 1.5.5 and I am trying to get us up a few notches from 1.5.1. EO has become essential. Appreciate any insights.
The current version (4.1.4) of EO does not work with Zen Cart 1.5.5. There is an interim Zen Cart release (1.5.5a?) in the works that will incorporate some changes into the zc1.5.5-introduced feature that "broke" EO. Once the Zen Cart release is made, I'll need another couple of days to perform some regression tests and get the readme updated.
My question was will it work with 1.5.4?
Sorry, I've got my eyes properly screwed in this time: Yes, EO 4.1.4 works happily with Zen Cart 1.5.4.
Thank you so much!
Is it easy to go back to 1.5.4 from 1.5.5 ?
If you kept a backup before you upgraded, sure ... and if you don't mind losing any database records added since that backup, too.Quote:
Originally Posted by kcallagmy
Thanks for this mod.. we use it a lot.
Doing a fresh install of 1.5.4 for testing and am currently working on merging Edit Orders and Ty Tracker with admin/orders.php.
I can see where Ty Tracker has pretty clearly stated the BOF and EOF edits, but I can not make out the merging of the admin/orders.php file with EO.
So... FORGETTING Ty Tracker... and starting over and just working with the original admin/orders.php out of the box, still can not make sense of the merging of EO into orders.php. Compared it to our current 1.5.1 and must have been a genius back then, or miracle worker because it works for our 1.5.1 shop.
1st Question: Is blind faith an option with the 1.5.4 admin/orders.php where EO is concerned? Just drop it in?
2nd Question: Would anyone have a merged EO admin/orders.php from zen1.5.4 with Ty Tracker that works that I could see?
SBA is next... Omg...
The version of EO that is currently residing on GitHub (https://github.com/lat9/edit_orders/) has been pre-merged with the Zen Cart v1.5.4 orders.php (and I'm pretty sure that the TyPT changes are also included).
That version also has some changes for Zen Cart 1.5.5 and is waiting for the ZC 1.5.5a release for compatibility testing prior to its release as EO 4.1.4a.
Thanks... i was on my way there for SBA... cool...
I could swear the new sanitizers in 155a + latest Github EO are not playing well. Am I crazy?
A little more information would certainly help; how are they not playing well?Quote:
Originally Posted by swguy
I'll do an install on a clean system shortly and report back. Wasn't sure if anyone else had tried it and had bad results so I wanted to check first.
Update later: Dup'ed; see post below.
Does it make sense to pull the latest from https://github.com/lat9/edit_orders and call that the 1.5.4 version so we can get on with updating for 1.5.5? (last update to this plugin was 01/14 for 1.5.3.)
OK, I can repro the issue. What's happening is that on the 4th step (Add Now), on the default database with test products, I get correct attributes and options:
<input type='submit' value='Add now'><input type="hidden" name="id[3][value]" value="8"><input type="hidden" name="id[3][type]" value="0">
but on my database, these fields have been damaged:
<input type='submit' value='Add now'><input type="hidden" name="id[26]" value="Array"><input type="hidden" name="id[27]" value="Array">
(which creates empty values in orders_products_attributes.
So going back a step, on the default database in step 3, I get
<label class="attribsSelect" for="attrib-3">Model</label><select rel="dropdown" name="id[3][value]" id="attrib-3">
and on my database, I get
<label class="attribsSelect" for="attrib-27">Mounting Orientation:</label><select rel="dropdown" name="id[27][value]" id="attrib-27">
which looks the same to me.
Gets into init_sanitize fine, but goes from ./includes/classes/AdminRequestSanitizer.php into filterSimpleAlphanumPlus which clobbers the array (line 335).
It looks like on my side, the ParameterDefinitions array does not include the entry for MULTI_DIMENSIONAL.
One thing that looks interesting - why does admin/includes/extra_datafiles/eo_sanitization.php add an array entry for "update_products"
but not for add_prdct ? (I tried that and it didn't fix my issue but it's still curious.)
@swguy, you say you're using the demo products, but there's no option named "Mounting Options". If you could identify the specifics of the product and its attributes that you're trying to add to the order, I could probably help.
I'm also not sure what you mean by:
... although, in reviewing the sanitization array (in /ADMIN/includes/extra_datafiles/eo_sanitization.php) there's an entry for the update_order path, but not one for the add_prdct one.Code:It looks like on my side, the ParameterDefinitions array does not include the entry for MULTI_DIMENSIONAL.
OK, got one. Tried to add the "Big Linked" version of "A Bug's Life ..." entered all the attributes, clicked "Add" and came back to the same screen (with debug-logs generated). At this point, I've got something to work with and will report back when I've got a solution.
Quote:
Originally Posted by swguy
Morning lat9. Looks like a comparison of operation is being performed between a default zc store and a "live" store, which is the "my database" version. Considering the timing of the discussion and issues, should also note that there appears to be something amiss with the products_attributes table or related with that database as a change to another plugin was required to address sort orders of attributes. That change required not using the sort order provided by routine query to the products_attributes table and instead to use the sort order provided by the products_options_values table. A suggestion was made to correct the issue with the products_attributes table, the status of which is unknown, but alternate software (for more than one reason) was sought.Quote:
Originally Posted by lat9
Or perhaps it *is* something else as the issue can occur in the default database.
If you do a view source on the 4th step (with the Add button), do you getQuote:
Originally Posted by lat9
name="id[1] value="Array"
instead of
name="id[1][value]" id="attrib-1"
Because that means you're seeing the issue.
Mounting Options is something from my database (which exhibits the problem).Quote:
Originally Posted by lat9
Reproduced using the demo products; see this posting.
@swguy, would you apply the following update to your ADMIN/includes/extra_datafiles/eo_sanitization.php to see if that corrects your issue (it corrected the issue with the demo product)?
Code:<?php
// -----
// Part of the Edit Orders plugin, v4.1.5 or later. This file defines the level of "sanitization" required by the adminSanitizer function,
// introduced in a patch-level of Zen Cart v1.5.5, so need to make sure that the "proper" version of the class is included.
//
if (defined ('PROJECT_VERSION_MAJOR') && version_compare (PROJECT_VERSION_MAJOR . '.' . PROJECT_VERSION_MINOR, '1.5.5', '>=') && class_exists ('AdminRequestSanitizer') && method_exists ('AdminRequestSanitizer', 'getInstance')) {
$eo_sanitizer = AdminRequestSanitizer::getInstance();
$eo_group = array (
'update_products' => array (
'sanitizerType' => 'MULTI_DIMENSIONAL',
'method' => 'post',
'pages' => array ('edit_orders'),
'params' => array (
'update_products' => array ('sanitizerType' => 'CONVERT_INT'),
'qty' => array ('sanitizerType' => 'FLOAT_VALUE_REGEX'),
'name' => array ('sanitizerType' => 'PRODUCT_DESC_REGEX'),
'onetime_charges' => array ('sanitizerType' => 'FLOAT_VALUE_REGEX'),
'attr' => array (
'sanitizerType' => 'MULTI_DIMENSIONAL',
'params' => array (
'attr' => array ('sanitizerType' => 'CONVERT_INT'),
'value' => array ('sanitizerType' => 'PRODUCT_DESC_REGEX'),
'type' => array ('sanitizerType' => 'CONVERT_INT')
)
),
'model' => array ('sanitizerType' => 'WORDS_AND_SYMBOLS_REGEX'),
'tax' => array ('sanitizerType' => 'FLOAT_VALUE_REGEX'),
'final_price' => array ('sanitizerType' => 'FLOAT_VALUE_REGEX'),
)
),
'id' => array (
'sanitizerType' => 'MULTI_DIMENSIONAL',
'method' => 'post',
'pages' => array ('edit_orders'),
'params' => array (
'id' => array ('sanitizerType' => 'CONVERT_INT'),
'type' => array ('sanitizerType' => 'CONVERT_INT'),
'value' => array ('sanitizerType' => 'PRODUCT_DESC_REGEX'),
),
)
);
$eo_sanitizer->addComplexSanitization ($eo_group);
}
Will test as soon as I get home.
Never mind; that worked on my test setup (1.5.5+sanitizer updated from 4/12/2016) but fails using the sanitizer that's delivered as part of ZC1.5.5a.
ok -standing by.
The problem is this test
if (defined ('PROJECT_VERSION_MAJOR') && version_compare (PROJECT_VERSION_MAJOR . '.' . PROJECT_VERSION_MINOR, '1.5.5', '>=') && class_exists ('AdminRequestSanitizer') && method_exists ('AdminRequestSanitizer', 'getInstance')) {
1.5.5a will fail as version_compare("1.5.5a", "1.5.5") = -1
drbyte suggests
(int)(PROJECT_VERSION_MAJOR . '.' . PROJECT_VERSION_MINOR <= '1.5.5');
Post 934: https://www.zen-cart.com/showthread....51#post1310851
was GOLD on vanilla 1.5.5. Worked like a champ.
Wilt's point is well taken - that check will have to be beefed up for 1.5.5a.
Quote:
Originally Posted by wilt
Considering that this "feature" was considered to be applied to 1.5.5.a and future versions, I would suggest:Quote:
Originally Posted by wilt
Code:if (defined ('PROJECT_VERSION_MAJOR') && (version_compare (PROJECT_VERSION_MAJOR . '.' . PROJECT_VERSION_MINOR, '1.5.5.a', '=') || version_compare (PROJECT_VERSION_MAJOR . '.' . PROJECT_VERSION_MINOR, '1.5.5', '>')) && class_exists ('AdminRequestSanitizer') && method_exists ('AdminRequestSanitizer', 'getInstance')) {
Strictly speaking, this is enough: class_exists ('AdminRequestSanitizer') && method_exists ('AdminRequestSanitizer', 'getInstance')
Yes - this logic was intended to be added to all 1.5+ carts.
https://www.zen-cart.com/showthread....d-TWSL2016-006
Thanks, DrByte; I'll get that change incorporated.Quote:
Originally Posted by DrByte
Arggh, I'd seen that posting but hadn't "looked under the covers". Here's hoping that some store owner doesn't blindly install that patch on a store that uses Edit Orders (and possibly other plugins that don't yet know that they're broken)! Would it be possible to update that posting to provide some modicum of caution, possibly specifically referencing Edit Orders?Quote:
Originally Posted by swguy
I've got the change above incorporated and created a 4.1.5-beta2 distribution as it seems that we're getting closer to having a releasable version!
I think the way to go is just to update and improve the patch (using the fixes that you, wilt and DrByte have provided) so this isn't an issue.
There is another mod somewhere that also breaks Edit Orders when combined with even this updated patch, but I haven't isolated it.
---Quote (Originally by swguy)---
I think the way to go is just to update and improve the patch (using the fixes that you, wilt and DrByte have provided) so this isn't an issue.
There is another mod somewhere that also breaks Edit Orders when combined with even this updated patch, but I haven't isolated it.
---End Quote---
There are a fair number of "order totals" that are actually "shopping-cart and/or customer-session totals" that break Edit Orders (which has access to neither), so that's not new news.
@swguy, Why are you editing my posts?Quote:
Originally Posted by lat9
I've updated the EO GitHub repository to correct the missing parentheses (it's now at v4.1.5-beta3).
Your "fix" to the navigation is a "change" to the navigation that's been in EO forever, so it's not going to be changed in the EO repository. You're welcome to make that change to your installation.
I am aware of that - this is different. And when I say "breaks" I mean breaks in the "missing attributes" sense I had reported earlier.Quote:
Originally Posted by lat9
I just pushed a couple of fixes to EO - navigation at the top was wrong and there was a missing bracket in a sanitizer.
Finger trouble. :( Sorry about that - I have no idea what happened but I have restored the original content.Quote:
Originally Posted by lat9
I just uploaded v4.1.5 of Edit Orders to the plugins for review: https://www.zen-cart.com/downloads.php?do=file&id=1513
The following changes are included:
- BUGFIX: Correct "Unknown column 'p.products_quantity' in 'field list".
- BUGFIX: Corrections for coupons with category / product restrictions.
- CHANGE: Account for order-total modules that have been removed.
- CHANGE: Mimic storefront sort-order for attributes' display.
- BUGFIX: Correct incorrect tax-calculations after editing an order.
- BUGFIX: Correct multi-line comments display with \r\n.
- CHANGE: Include a "Miscellaneous Cost" order-total that's Edit Orders specific.
- BUGFIX: Correct interaction with stores that use the "Split Tax Lines" configuration.
- CHANGE: Remove reliance on the built-in currency initialization scripts.
- CHANGE: Add support for the "admin sanitization" introduced in Zen Cart 1.5.5.
Please note: This distribution includes a core-file change to the admin's /orders.php script, using the Zen Cart 1.5.4 version of the file as the change-basis. If you are installing on Zen Cart 1.5.5 or later, you'll need to merge the five (5) marked EO-related changes into your version of that file.
I have a strange problem, I could not see anyone else with this issue but I might have missed it in this thread.
I am using ZC 1.5.4 and EO 4.1.4. When I go to edit an order where the product has attributes the order changes from having a size of 0-3months to having a size: please select...
This cannot be edited.
If I go to add a product to the order from the edit product page, I cannot choose the options for the product I just get size: please select...
Have I got a setting wrong or is there a bug.
If I go back to the order without updating the order is as per the order when put on the system. If I update without making any changes then the product option changes to the size: please select. This is set as my display only option for the front of the site.
I have tired to follow the error log and which has confused my as to which table it is using for the product information. I have two tables orders_products_attributes and orders_products_attributes_stock and I am not sure which one is being used when to pull the attributes for the order from.
At one point I was missing the second table and getting an error when placing an order. That now seems to be fixed as I have generated the table but i am now wondering if this is linked to the error I am now getting.
Yes I have stock_by_attributes module as well.
thank you in advance for some advice on how to cure.
The second table: orders_products_attributes_stock is not accessed by SBA (yet) but is used to store data with an expectation that in the future it will be used. It should have no effect on EO unless other code has been incorporated to access a similar named table possibly having a different configuration. Otherwise the only change(s) made to the admin orders.php file in SBA are to support pulling the customid which still at this time uses live data rather than the order history data stored in the above referenced table. I therefore would say that the issue is related to something else though there could also be something going on if there are observers that are interacting with default ZC notifiers.Quote:
Originally Posted by MikeyG
@MikeyG: Have you, by any chance, installed the Trustwave Security Patch on your ZC1.5.4 site?
Lat9,
Could this cause issues if it has been installed?
mc12345678
Thanks for the reply, I have been through carefully to see what I might have tried to merge with these files, My mods are Superorders and edit orders, Stock by attributes, and then the tableau template by numinix which seems to incorporate Image handler 4. I have the google merchant feeder as well. No other mods so one of these must be causing the interference with edit orders. The only file in the admin/includes/classes/observers folder is the stock by attributes file. Not full understanding the classes system I am assuming that the problem could lie in any of the class files not just in the observer folder.
Yes. That's the same admin-level code change, introduced in Zen Cart 1.5.5, that led to the release of EO 4.1.5. That version of EO should be available real-soon-now from the Zen Cart plugins; you can get it now from EO's GitHub repository: https://github.com/lat9/edit_orders/releases/tag/v4.1.5Quote:
Originally Posted by MikeyG
Edit Orders v4.1.5 is now available for download from the Plugins section.
Installing the latest Trustwave Security Patch from the Announcements broke Edit Orders 4.1.5. Replacing the files from the Zencart 1.5.5a distribution fixed it. Is someone looking at it ?
Could you be more specific about what you mean when you say the latest Trustwave broke EO?
Like swguy said, what version of Zen Cart are you running? In what manner does the patch "break" EO?Quote:
Originally Posted by swguy
Zen Cart 1.5.5a and Edit orders 4.1.5 from Giithub. When I install the Trustwave patch, and try to edit an order, I get a red bar at the top that says I need to install the AdminRequestSanitizer class. I'll re apply the Trustwave patch to my test server and capture the message
This is the error I get.
Attachment 16361
When you say, "the Trustwave patch" - you know you have to get the files from Github, right? See
https://www.zen-cart.com/showthread....80#post1311680
Thanks, It's working now. I went and reread Dr. Byte's last post, and used the ones from Github, not the ones from his previous post.
Thanks, @swguy, for making that distinction, and to @henry3 for reporting back that all's well!
Hi,
I'm having issues when adding additional charges to orders via this module. I can add a line and price but it doesn't actually update the price of the order when I do so?
https://uploadir.com/u/33eqde1v
Any help would be appreciated :)
thanks
You'll need to supply a bit more information, like your Zen Cart version, your EO version and whether you've installed the updated "Trustwave" patch.
The current (4.1.5) version of EO doesn't display that "Choose a shipping module" line.
@Chad, are you using the 2_misc_cost add on under 4_optional_items in the Edit Orders install? @lat9 recently added it into the zip file, and it was just what my client wanted - give it a shot.
Wilt just updated this thread to remove the outdated files so others won't make the same mistake. Thanks for clarifying that Edit Orders 4.1.5 and Zen Cart 1.5.5/1.5.5a work well together with the latest Trustwave patches.Quote:
Originally Posted by henry3
Small fix to EO 4.1.5 - when on the (regular) order display page, the edit button at the bottom of the page doesn't work.
Fix is shown here:
https://github.com/lat9/edit_orders/pull/26/files
Also thanks to Scott(swguy) for reminding me to do that :)Quote:
Originally Posted by swguy
so, i managed to get the additional fee but now its totaling up wrong
https://uploadir.com/u/2ailcea7
ignore adding the vat - the total price should be £25.50
Chad, you haven't indicated what versions of Zen Cart and Edit Orders you're using, nor have you identified what order-total module you are using to create the "Test Fee".Quote:
Originally Posted by Chad Rebisz
Note also that once the totals get "out of whack", you'll usually require some database surgery to get them back in line.
one of my main complaints about EO. it's so easy to get the order_total to not total.Quote:
Originally Posted by lat9
i will look at what i have done in the past to address this issue, and post some suggestions.
Hi All
Zencart version 1.5.3
Super order 4.0.5
Edit Orders 4.1.4
I am having an issue where we raise an order and for example:
Once we use edit order (just to re-label something) and click Update, the total updates. So instead the order total reads:Quote:
Sub-Total: £369.00
Total (Delivery): £10.00
Trade Discount: -£184.50
UK VAT @ 20%: £38.90
Total: £233.40
Other Settings under Edit ordersQuote:
Sub-Total: £369.00
Total (Delivery): £10.00
Trade Discount: -£184.50
UK VAT @ 20%: £38.90
Total: £196.50
Use a mock shopping cart? true
Strip tags from the shipping module name? true Info
Debug Action Level 0
Please could anyone help or assist?
What are your store's settings for:
Configuration->My Store->Display Prices with Tax
Configuration->My Store->Display Prices with Tax Admin
Where did the "Trade Discount" order-total come from? Does it rely on the "storefront environment" to perform its calculations?
I'm having a hard time seeing where the totals' difference "went", as the difference is 36.90 (which isn't any of the listed values).
Note also that Edit Orders uses the Configuration->My Store->Display Prices with Tax setting in its calculations.
Hi Cindy
Configuration->My Store->Display Prices with Tax False
Configuration->My Store->Display Prices with Tax Admin True
The latter had to be set to true as it was displaying the same price including and excluding vat.
The discount trade is set by Customers > Group Pricing and assigned to an individual customer on registration/approval. I believe this is a standard setup in the ZenCart software.
What seemed to be happening originally, is the tax was doubling.
I hope this provides some insight.
Not sure why, but 36.90 is 20% * 184.50 which is both tax on the trade discount as well as the 20% tax on the total amount if delivery wasn't included in a sub-total.Quote:
Originally Posted by lat9
Might almost be interesting to see if upon re-edit if the value would go down again. Another would be to alter the trade discount as a general factor from the onset of a test purchase and see how the values change. Working with a 50% value somewhat means that the data could come from either the reduction or from the pre-total. Perhaps momentarily reduce the reduction (thus not losing out on some in process cash flow) or apply it to some test product, but do the same thing with that item as was done above and see how it changes.
@dharrison, would you set Configuration->Edit Orders->Debug Action Level to "TOTALS" and send me the file directly?
Are you receiving the EO warning message that indicates that the store's two "Display Prices with Tax" settings are not the same?
Hi @lat9
I do get the warning messages:
I have also set debug to TOTALS as requested and zipped the log and emailed to you.Quote:
Success: Order has been successfully updated.
Warning Warning: You have configured Zen Cart to display prices with tax. This page is currently displaying prices without tax.
Hi mcQuote:
Originally Posted by mc12345678
I have tried that and after the initial adjustment, the final total remains the same. The VAT goes down to normal level if you click update again, but that total remains the same.
There is a few components in the sub-total but it was accurate except for when the order is edited.
Anyway I have tried with a 40% discount:
On clicking Update this changes toQuote:
Sub-Total: £459.00
Free Shipping Options (Ex-Works): £0.00
Trade Discount: -£183.60
UK VAT @ 20%: £55.08
Total: £330.48
Clicking Update again this time, the VAT remains the same.Quote:
£459.00
Add Product
Sub-Total: £459.00
Trade Discount: -£183.60
UK VAT @ 20%: £55.08
Total: £293.76
Well, that does come out to reflect that on edit, the trade discount is taxed 20% and that tax is being subtracted from the bottom line total. So the two tests show that on update for some reason the final total is being reduced by an "unpublished" tax but it is all based on the above values and not on some "reuse" of the current final. Should help to figure out what's going on as one reviews the code. Not sure if more info than what has been provided is needed.Quote:
Originally Posted by dharrison
Thanks mc
Thanks for the insight. One of the Trade Discount (Group pricing) module settings is:
I will try without the re-calculate tax and go from thereQuote:
Trade Discount
This module is installed
true
Sort Order
290
Include Shipping
false
Include Tax
false
Re-calculate Tax
Standard
Tax Class
--none--
Nope it's made no difference. :cry:
I can set up a test login if that would help.
Yes, unfortunately, those EO logs weren't particularly helpful. PM sent.
Things with taxes will NOT work correctly if these are different. Thus the warning printed at the top.Quote:
Originally Posted by dharrison
This setting is used by various Zen Cart functions when calculating the tax, not just for "display". When enabled Zen Cart stores the product price in the order as (product price + tax). When disabled it stores just the product price.
So with your settings when a customer places an order the product is saved without tax in the database. When you open the order for editing with your settings, you are telling the Zen Cart functions the tax is already included with the product price (so it removes it from the total).
Thanks, @lhungil (I was hoping that you'd chime in!), that's part of the conclusion I'd arrived at as well (although I didn't "see" where the storefront/admin discrepancy beween the two settings had bearing in this instance) ...
The store's setting for Display Prices with Tax was changed from true to false, resulting in total-calculation issues when EO was then used to edit an order created while the setting was true.
Part of EO's total-processing involves backing-out all product-price (and tax, if indicated) values from the order's subtotal, total and tax elements prior to any re-calculation. So, an order that was created when DPwT was set to true will not have the applicable taxes backed-out from this calculation, resulting in (as you've seen) an incorrect Total value being calculated for the order.
I'm not sure why EO does that back-out, but perhaps @lhungil could fill in some of the EO history as to why the processing is as it is!
In any case, I suggest to @dharrison that a procedure be defined for this store's admins such that they don't use EO on any orders that were created when the DPwT setting was true as a work-around to the display issue.
Thanks all 3 of you for your help. I would be intrigued to get an insight into the EO history as well.
Happy days (?)
@Lat9Quote:
Originally Posted by lhungil
Did you ever find a fix for this?
I'm not sure what this is, but if this is the warnings issued about the missing shipping address when an order contains only virtual products, then the answer is currently "no".Quote:
Originally Posted by picandnix
Sorry yes, this was that :grin:Quote:
Originally Posted by lat9
Tee-hee! I've noted the change-request in EO's GitHub repository.
Thank you Cindy :hug:Quote:
Originally Posted by lat9
I this warning address message on all my orders that contain only virtual items. It's not really an issue except when the order should have taxes. If I try to edit the order, I lose everything about the taxes even if I do write the required percentage in the TAX box.
All my countries and set up for zone and description and such are done. I don't know what to do to have EO calculate the taxes as it should. I have to go directly to the database and manually add the info. Is there a way to fix this? I've search the thread but so far no luck as I don't have any modification to my files except for EO so far.Quote:
Warning: One or more of the customer address fields contains a country name unknown to Zen Cart ("Locations / Taxes"->"Countries").
Taxes and some shipping modules may not function correctly until the issue has been resolved.
This typically occurs if someone deletes or renames a country's name from Zen Cart ("Locations / Taxes"->"Countries"). You can fix the issue by doing one of the following: •Add the country (and name) back to the Zen Cart database.
•Adjust the country name to match one of the country names in the Zen Cart database.
@marieAA, I've reproduced your issue and noted it in the plugin's GitHub repository. I should have a solution "shortly".
THANK YOU!!!! greatly appreciated!Quote:
Originally Posted by lat9
Quote:
Originally Posted by lat9
I saw your note on changing the title to this
should tell you that I found this on an order that already had taxes applied to it... when I went in to add another product, the new product came up with 0% taxes and there was no ot_tax block at all and the order total didn't reflect it either.Quote:
Tax not added if an order doesn't "start" with taxes
hope this helps
Aha! Thanks for that additional information; it will definitely help me come up with the right solution (it helps to know what the problems are)!:P