Zen Cart Logo
Forums / Addon Admin Tools / Edit Orders v4.0 Support Thread

Edit Orders v4.0 Support Thread

Views: 345,926

Results 401 to 420 of 1,927
1 Dec 2013, 5:21 PM
#401
divavocals avatar

divavocals

Totally Zenned

Join Date:
Jan 2007
Location:
Los Angeles, California, United States
Posts:
10,011
Plugin Contributions:
3

Edit Orders v4.0 Support Thread

RodG:

But NOT in the edit orders code.

I've traced this back to the source and the bug is in the stock by attributes code.

I'll follow this up with the details in the appropriate forum tomorrow.

Must get sleep.... its been a loooong day.

Cheers
Rod

If the issue is in SBA (and you are going to address this on the SBA support thread), but will affect Edit Orders, could you share your findings here as well..

1 Dec 2013, 10:02 PM
#402
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

RodG:

...
Oh, while I'm on the topic, it took me a bit of head scratching to get the Discount Vouchers to work within the editor. It kept giving "Warning: The coupon code was not found in the title. The title / text of a coupon must be formated like "Discount Coupon : coupon_code :".
Sure enough, when I entered the data exactly like the warning suggests it worked as expected. ...
DivaVocals:

Not a bug.. this is how it works, and I believe the readme covers this..
Yup this is how it works (and why we added a message to tell people). Why? Because ot_coupon stores the coupon name and code as the "title" for the order total. So basically the title needs to be formatted to match what ot_coupon expects ;)

3 Dec 2013, 8:58 AM
#403
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Location:
Australia
Posts:
6,263
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

DivaVocals:

If the issue is in SBA (and you are going to address this on the SBA support thread), but will affect Edit Orders, could you share your findings here as well..

I'm still chasing this rabbit down the hole. .. and after following many threads it once again appears to be an Edit Orders issue and not directly related to the SBA mod.

Here's where I'm currently at:

ile: /admin/edit_orders.php

------------------ Updated to avoid the need for the strange syntax current required (my clients have a bit of a problem following the instructions, and would prefer to just enter the coupon code_

----------------- Original code ----------------------------------------
case 'ot_coupon':
preg_match('/([^:]+):([^:]+):/', $order_total['title'], $matches);
//DEBUG echo '<div>Coupon Matches</div><pre>'; var_dump($matches); echo '</pre>';
if(count($matches) > 2) {
$order_total['title'] = trim($matches[1]);
$cc_id = $db->Execute(
'SELECT coupon_id FROM ' . TABLE_COUPONS . ' ' .
'WHERE coupon_code='' . trim($matches[2]) . '''
);
if(!$cc_id->EOF) $_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
else {
$messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
$order_total['title'] = '';
$order_total['value'] = 0;
}
}
else {
$messageStack->add_session(WARNING_ORDER_COUPON_BAD_FORMAT, 'warning');
$order_total['title'] = '';
$order_total['value'] = 0;
}

break;

------------ Replacement code ----------------------------------------------
case 'ot_coupon':
$order_total['title'] = "Discount Coupon:" . $order_total['title'] .":" ;

 preg_match('/([^:]+):([^:]+):/', $order_total['title'], $matches);

//DEBUG echo '<div>Coupon Matches</div><pre>'; var_dump($matches); echo '</pre>'; die ;
$order_total['title'] = trim($matches[1]);
$cc_id = $db->Execute(
'SELECT coupon_id FROM ' . TABLE_COUPONS . ' ' .
'WHERE coupon_code='' . trim($matches[2]) . '''
);

           if(!$cc_id->EOF) $_SESSION['cc_id'] = $cc_id->fields['coupon_id'];
           else {
              $messageStack->add_session(WARNING_ORDER_COUPON_BAD, 'warning');
              $order_total['title'] = '';
              $order_total['value'] = 0;
              }
    break;

This same file /admin/edit_orders.php has a
switch($optionInfo['type']) block, with case references to:

PRODUCTS_OPTIONS_TYPE_RADIO
PRODUCTS_OPTIONS_TYPE_SELECT
PRODUCTS_OPTIONS_TYPE_TEXT
PRODUCTS_OPTIONS_TYPE_FILE
PRODUCTS_OPTIONS_TYPE_READONLY
PRODUCTS_OPTIONS_TYPE_CHECKBOX

These don't appear to be defined anywhere, so nothing matches. (bug?)

I've 'fixed' this problem by making the following edits to
/admin/includes/classes/attributes.php
(I thought this was from the SBA mod, but I've since found it to be from the Edit orders mod)

Added these defines at the beginning of the file

define('PRODUCTS_OPTIONS_TYPE_RADIO', 'Radio') ;
define('PRODUCTS_OPTIONS_TYPE_SELECT', 'Dropdown');
define('PRODUCTS_OPTIONS_TYPE_TEXT', 'Text') ;
define('PRODUCTS_OPTIONS_TYPE_FILE', 'File') ;
define('PRODUCTS_OPTIONS_TYPE_READONLY', 'Read Only') ;
define('PRODUCTS_OPTIONS_TYPE_CHECKBOX', 'Checkbox') ; // is this a valid option? It doesn't appear in the database as such?

These are probably best suited in another datafile, or at the very least, add a check to ensure they don't try to get redefined.

---- replaced the get_attributes_options with this ---------------

function get_attributes_options($zf_product_id, $readonly = false) {
global $db;

    $query = 'SELECT attr.products_attributes_id, attr.products_id, attr.options_id, opt.products_options_name, 
    type.products_options_types_name, type.products_options_types_id,
    val.products_options_values_name, opt.products_options_type, 
    products_options_size, opt.products_options_rows ' .
        'FROM ' . TABLE_PRODUCTS_ATTRIBUTES . ' AS attr ' .
        'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS .
            ' AS opt ON attr.options_id = opt.products_options_id ' .
        'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS_VALUES .
            ' AS val ON attr.options_values_id = val.products_options_values_id ' .
         'LEFT JOIN ' . TABLE_PRODUCTS_OPTIONS_TYPES . 
                ' AS type ON type.products_options_types_id = opt.products_options_type ' .
        'WHERE attr.products_id = \'' . (int)$zf_product_id . '\' ' .
            'AND val.language_id = \'' . (int)$_SESSION['languages_id'] . '\' ' .
            'AND val.language_id = opt.language_id ';


    // Don't include READONLY attributes if product can be added to cart without them
    if(PRODUCTS_OPTIONS_TYPE_READONLY_IGNORED == '1' && $readonly === false) {
        $query .= 'AND opt.products_options_type != \'' . PRODUCTS_OPTIONS_TYPE_READONLY . '\' ';
    }


    $query .= 'ORDER BY `opt`.`products_options_sort_order`, `attr`.`options_id`';


    if($this->cache_time == 0) $queryResult = $db->Execute($query);
    else $queryResult = $db->Execute($query, false, true, $this->cache_time);


    $retval = array();
    while (!$queryResult->EOF) {
                
        $retval[$queryResult->fields['products_attributes_id']] = array(
            'id' => $queryResult->fields['options_id'],
            'name' => $queryResult->fields['products_options_name'],
            'value' => $queryResult->fields['products_options_values_name'],
    //        'type' => $queryResult->fields['products_options_type'],
                            'type' => $queryResult->fields['products_options_types_name'],


            'length' => $queryResult->fields['products_options_length'],
            'size' => $queryResult->fields['products_options_size'],
            'rows' => $queryResult->fields['products_options_rows']
        );
        $queryResult->MoveNext();
    }

    return $retval;
}

These changes seems to cure most of the problems I was having with the site I'm working on.

Cheers
Rod

3 Dec 2013, 12:52 PM
#404
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,065
Plugin Contributions:
56

Re: Edit Orders v4.0 Support Thread

RodG:

This same file /admin/edit_orders.php has a
switch($optionInfo['type']) block, with case references to:

PRODUCTS_OPTIONS_TYPE_RADIO
PRODUCTS_OPTIONS_TYPE_SELECT
PRODUCTS_OPTIONS_TYPE_TEXT
PRODUCTS_OPTIONS_TYPE_FILE
PRODUCTS_OPTIONS_TYPE_READONLY
PRODUCTS_OPTIONS_TYPE_CHECKBOX

These don't appear to be defined anywhere, so nothing matches. (bug?)

I've 'fixed' this problem by making the following edits to
/admin/includes/classes/attributes.php
(I thought this was from the SBA mod, but I've since found it to be from the Edit orders mod)

Added these defines at the beginning of the file

define('PRODUCTS_OPTIONS_TYPE_RADIO', 'Radio') ;
define('PRODUCTS_OPTIONS_TYPE_SELECT', 'Dropdown');
define('PRODUCTS_OPTIONS_TYPE_TEXT', 'Text') ;
define('PRODUCTS_OPTIONS_TYPE_FILE', 'File') ;
define('PRODUCTS_OPTIONS_TYPE_READONLY', 'Read Only') ;
define('PRODUCTS_OPTIONS_TYPE_CHECKBOX', 'Checkbox') ; // is this a valid option? It doesn't appear in the database as such?

Oh no! Don't do that!:no: Those constants are defined in the database and provide a mapping to the products_options_types table row associated with that option name.

3 Dec 2013, 1:27 PM
#405
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Location:
Australia
Posts:
6,263
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

lat9:

Oh no! Don't do that!:no: Those constants are defined in the database and provide a mapping to the products_options_types table row associated with that option name.

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they didn't get defined on the clients site during whatever upgrade performed this function.

Time to follow this lead to see where it takes me. It'll probably avoid the need for those other changes I made :)

.... Other than the case 'ot_coupon' changes (which was for a different issue). If you can foresee any potential problems with that could you please let me know?

Thanks
RodG

3 Dec 2013, 2:00 PM
#406
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,065
Plugin Contributions:
56

Re: Edit Orders v4.0 Support Thread

RodG:

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they didn't get defined on the clients site during whatever upgrade performed this function.
They've been part of the Zen Cart "standard" database install since at least v1.3.8a (I've got a client that started with v1.3.7 and the constants are in that database). What Zen Cart version did your client start out with?

3 Dec 2013, 5:16 PM
#407
divavocals avatar

divavocals

Totally Zenned

Join Date:
Jan 2007
Location:
Los Angeles, California, United States
Posts:
10,011
Plugin Contributions:
3

Re: Edit Orders v4.0 Support Thread

RodG:

They're NOT defined in the database of the clients site that I'm working on.

They ARE defined in the configuration database of my own test site though (not associated with the clients site).

(That's why I suggested they should probably be checked to prevent a possible redefine).

I've not figured out how or where they got defined on my site, or more importantly, why they didn't get defined on the clients site during whatever upgrade performed this function.

Time to follow this lead to see where it takes me. It'll probably avoid the need for those other changes I made :)

.... Other than the case 'ot_coupon' changes (which was for a different issue). If you can foresee any potential problems with that could you please let me know?

Thanks
RodG

Honestly Rod, the discount coupon thing aside (which is a functional issue not a "bug"), I'm starting to wonder if the "bugs" you are finding are UNIQUE to the client site you are working on.. Otherwise it would stand to reason that others would have reported the same issues you are having..

3 Dec 2013, 8:37 PM
#408
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

RodG:

------------------ Updated to avoid the need for the strange syntax current required (my clients have a bit of a problem following the instructions, and would prefer to just enter the coupon code_
The correct stored format is "<module_title>: <coupon_code>".

Just a couple warnings about your code:

  • The module title is not static (and may vary depending upon store language and / or modifications).
  • Indexes on an array are not checked to verify they exist before using them (PHP 5.4+ potential issue).
  • It will break when the correct full title is passed (such as a order created by the checkout process).

Most users have not had any problems understanding the warning which is printed on the top of the screen by Edit Orders and taking the appropriate action. On the other hand, I do like the idea of allowing the entry of just the coupon code. With the upcoming 4.1.3 release, I have been focusing on usability, compatibility, and automatically finding / fixing certain common database issues (caused by errant code in OTHER modules).

I'll add the updating the handling of ot_coupon to the list for Edit Orders 4.1.3. :o)

RodG:

...
PRODUCTS_OPTIONS_TYPE_CHECKBOX

These don't appear to be defined anywhere, so nothing matches. (bug?)
Not a bug. These are core database entries relating to attributes in the Zen Cart database. Means the store you are working on has some serious database damage... You should re-add the appropriate entries to the database (and verify the SBA code is not incorrectly removing these).

RodG:

...
---- replaced the get_attributes_options with this ---------------
Not needed if you fix the core database entries relating to attributes. Also why did you change the code to use the "product's option's type" name instead of id? What happens if in the future the names are in a localized language? Or someone changes the name?

Other Thoughts
Sounds like your client's store has a large number of modifications (both to the database and files) including damage to some of the core Zen Cart database entries relating to attributes... I cannot say what introduced these "changes", but I would make sure it was not the SBA module you are using...

You will probably want to correct the current issues in the specific store you are working on instead of modifying the "Edit Orders" code (to work around the issues specific to the client's site). Applying bandages instead of stopping the root cause could cause problems down the road (such as when a new version of Zen Cart or Edit Orders is released).

NOTES: If the SBA module includes something to indicate it's presence (like EO_VERSION identifies Edit Orders is installed and which version)... And the SBA module does not break existing Zen Cart core attribute handling... I'm more than willing to add some additional code / code blocks to help "support" the SBA module... So if you do find what exactly is changed by the SBA module during the product selection and checkout process... Contributions are welcome (but expect them to be looked at to ensure they do not introduce unnecessary risks). :o)

4 Dec 2013, 3:48 AM
#409
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Location:
Australia
Posts:
6,263
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

lhungil:

The correct stored format is "<module_title>: <coupon_code>".

Thanks.

lhungil:

Just a couple warnings about your code:

  • The module title is not static (and may vary depending upon store language and / or modifications).
  • Indexes on an array are not checked to verify they exist before using them (PHP 5.4+ potential issue).
  • It will break when the correct full title is passed (such as a order created by the checkout process).

I find your 3rd point the most disconcerting. I'll need to check this before the client discovers this before I've taken steps to mitigate it :)

lhungil:

Most users have not had any problems understanding the warning which is printed on the top of the screen by Edit Orders and taking the appropriate action.

I could dispute this and suggest that most users simply haven't reported or commented about the issue, or that most users have probably never even attempted to use the discount coupons when editing an order. :)

lhungil:

On the other hand, I do like the idea of allowing the entry of just the coupon code. With the upcoming 4.1.3 release, I have been focusing on usability, compatibility, and automatically finding / fixing certain common database issues (caused by errant code in OTHER modules).

I'll add the updating the handling of ot_coupon to the list for Edit Orders 4.1.3. :o)

This is partially why I provided the info about how I 'solved' the problem and asked about the possible repercussions :)
I kinda figured that my solution was a little too easy.

lhungil:

Sounds like your client's store has a large number of modifications (both to the database and files) including damage to some of the core Zen Cart database entries relating to attributes...

You're not wrong there. This site has been a major headache since the 1st day I started working on the upgrade.
In hindsight if I were to do this one again I would have started with a fresh install of V1.5.1 and basically rebuilt it from scratch.

I can normally do such upgrade in a matter of hours. This one has had me going around in circles for weeks. (Thankfully the client has been very understanding and quite generous).

I cannot say what introduced these "changes", but I would make sure it was not the SBA module you are using...

lhungil:

You will probably want to correct the current issues in the specific store you are working on instead of modifying the "Edit Orders" code (to work around the issues specific to the client's site). Applying bandages instead of stopping the root cause could cause problems down the road (such as when a new version of Zen Cart or Edit Orders is released).

I agree 100%. I thought I had fixed all the 'current issues' (without any code patches) until this reported problem (which on first inspection appeared to be a simple bug in the code).
Thanks to you guys I now have another lead to follow up on. :)

FWIW, in regards to the missing CONSTANTS in the DB configuration table, I had a very quick look at this before calling it quits last night, and discovered that these entries are created (re-created?) when I went to the attributes controller and created some new entries. Alas, there still seems to be an issue (using unmodified code), so there is still a little more to the puzzle. I hope to get back onto it further later today. I suspect it is probably related to the fact that the current entries still have missing or incorrect data somewhere. At least now I have a means of comparison. :)

I seriously don't like the idea of adding bandaids/patches, especially with code modules that I'm unfamiliar with.

Cheers
Rod

4 Dec 2013, 4:02 AM
#410
rodg avatar

rodg

Deceased

Join Date:
Jan 2007
Location:
Australia
Posts:
6,263
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

DivaVocals:

Honestly Rod, the discount coupon thing aside (which is a functional issue not a "bug"), I'm starting to wonder if the "bugs" you are finding are UNIQUE to the client site you are working on.. Otherwise it would stand to reason that others would have reported the same issues you are having..

Wonder no more. It is most certainly unique to this clients site.
Until this thread I really wasn't sure (and arguably, could still be in doubt), because this is the 1st store in which I've had the combination of

ZenCart V1.5.1
Edit Orders 4.1.2
Super Orders 4.0.7
Stock by Attribute 1.5.1.2

Although I'm now pretty much convinced the problem(s) pertain to the store/data itself, can you (or anyone) be 100% sure that there isn't a bug with this specific combination of inter related modules?

Again, I will stress that I'm now of the opinion that when I find what else is amiss with the data in this store that these versions of these modules will almost certainly behave as expected. Without reporting the 'bugs' and what I've needed to do to 'fix' them I don't think I could have gotten the feedback I needed to put me back on the right track. :)

Cheers
Rod

4 Dec 2013, 6:57 AM
#411
oldngrey avatar

oldngrey

Zen Follower

Join Date:
Apr 2008
Location:
Qld, Australia
Posts:
417
Plugin Contributions:
0

Re: Edit Orders v4.0 Support Thread

I had problems installing Edit Order on a vanilla install of ZC. The solution / workaround is shown below.

The resulting error is:
"PHP Fatal error: 1366:Incorrect integer value: '' for column 'configuration_group_id' at row 1 :: INSERT INTO zen_configuration_group VALUES ('', 'Edit Orders', 'Settings for Edit Orders', '36', '1') in E:\web\zc151\includes\classes\db\mysql\query_factory.php on line 120
"

I have tracked it down to
admin\includes\auto_loaders\config.eo_onetime.php
--> admin\includes\init_includes\init_eo_install.php
--> admin\includes\classes\eo_plugin.php
--> admin\includes\classes\plugin.php
LINE 435
// Create configuration group
$db->Execute(
'INSERT INTO ' . TABLE_CONFIGURATION_GROUP . ' ' .
'VALUES ('', '' . $this->getUniqueName() . '', ' .
'''. $this->getDescription() . '', '' . $max_sort . '', '1')'
);]
The solution that works on my environment is to change to the value of configuration_group_id from '' to NULL
$db->Execute(
'INSERT INTO ' . TABLE_CONFIGURATION_GROUP . ' ' .
'VALUES (NULL, '' . $this->getUniqueName() . '', ' .
'''. $this->getDescription() . '', '' . $max_sort . '', '1')'
);

This can be replicated on a fresh database and Zen Cart demo installation

Configuration
PHP 5.3.8
Apache 2.2.21
MySQL 5.1
Windows 7 (test server)

I have posted the problem and the workaround here for future reference.

I have persevered with this as I have been using Edit Order on many version of ZC and simply find it difficult to admin a ZC site without it.

4 Dec 2013, 1:58 PM
#412
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

RodG:

Wonder no more. It is most certainly unique to this clients site.
Until this thread I really wasn't sure (and arguably, could still be in doubt) ...
Thank You for reporting back, if you see / saw any database pieces you feel could be "commonly" damaged, feel free to send me a PM / email with the information. If nothing else an installation check might be in order :)

4 Dec 2013, 2:03 PM
#413
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

OldNGrey:

I had problems installing Edit Order on a vanilla install of ZC.
...
The resulting error is:
"PHP Fatal error: 1366:Incorrect integer value: '' for column 'configuration_group_id' at row 1 :: INSERT INTO zen_configuration_group VALUES ('', 'Edit Orders', 'Settings for Edit Orders', '36', '1') in E:\web\zc151\includes\classes\db\mysql\query_factory.php on line 120
"
...
Thank You for catching this, reporting the issue, and providing a workaround / solution!

For the next release (of both Edit Orders and the Plugin module), I'll be replacing most UPDATE and INSERT statements with the "zen_db_perform" function.

6 Dec 2013, 7:41 PM
#414
lunabug avatar

lunabug

New Zenner

Join Date:
Dec 2009
Posts:
94
Plugin Contributions:
0

Re: Edit Orders v4.0 Support Thread

I'm curious as to why you "Changed the "local_sales_tax" line to no longer be editable (automatically generated based upon the order)" when "Not all order total modules are fully supported"???

As this is the case for my site (I'm running the Better Together addon), and I have to update the database directly with the correct sales tax (AND the total) as Edit Orders is not taking this discount into consideration when calculating the tax. I'd much rather be able to update it directly on the order edit page.

Thank,
Leslie

6 Dec 2013, 10:28 PM
#415
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

lunabug:

... I'm curious as to why you "Changed the "local_sales_tax" line to no longer be editable (automatically generated based upon the order)" when "Not all order total modules are fully supported"??? ...
Because the "Local Sales Tax" module IS supported by Edit Orders with the noted changes in the readme. "Local Sales Tax" reads the product list from the order (not the cart) and works when loaded during checkout or from the administrative interface.

An Order Total module can be treated as "automatically" calculating or "editable" (not both) within "Edit Orders". Currently there are no plans to add an extra checkbox to each order total line to allow selecting the mode... Mostly because what a customer sees when they place an order via the checkout process should match what is shown when an administrative user edits / creates an order.

lunabug:

... As this is the case for my site (I'm running the Better Together addon), and I have to update the database directly with the correct sales tax (AND the total) ...
The calculations are NOT done by Edit Orders in version 4.1+ The calculations are done by the Order Total modules.

I sympathize with the issues you are experiencing, but they are not caused directly by "Edit Orders".

  1. "Better Together" and "Local Sales Tax" are not friendly towards each other. Specifically, "Local Sales Tax" calculates tax separate from Zen Cart's tax tables and reads the products from the order. "Better Together" is not aware of the "Local Sales Tax" module and only calculates tax using Zen Cart's tax tables and does not modify the price of products in the order.
  2. "Better Together" does currently support being loaded from the administrative interface. "Better Together" depends on access to the shopping cart (and does not make use of $order->products). "Edit Orders 4.1+" currently only populates $order as there is no shopping cart once an order has been placed.

If you must use an unsupported Order Total module (or have multiple Order Total modules which do not work well together), you may wish to uninstall "Edit Orders 4.1+" and go back to using "Edit Orders 4.0". Edit Orders 4.0 relied upon manual price adjustments vs. ones calculated by the Zen Cart Order Total modules.

Otherwise, continue reading for some of the things involved (not all) if you want to use "Edit Orders 4.1+", "Better Together", and "Local Sales Tax" together.

To address the first issue:
Modify "Better Together" and / or "Local Sales Tax" to play well together. I believe some of the other tax lookup modules have similar problems with discount modules which do not alter the price of the product directly... But I could be wrong...

To address the second issue:
Modify "Better Together" to use the order information (when available, instead of just the cart) -- or -- Modify "Edit Orders" to populate a "dummy" cart. This would allow automatic calculation for "Better Together" (and if item #1 is corrected tax rates should be calculated correctly).

You may also run into some issues with the automatic calculation of the stock Zen Cart taxes via ot_taxes without this compatibility issue being addressed. As "Better Together" does not see products in the shopping cart, it does not apply any corrections (including tax corrections).

8 Dec 2013, 4:49 PM
#416
lat9 avatar

lat9

Administrator

Join Date:
Sep 2009
Location:
Stuart, FL
Posts:
14,065
Plugin Contributions:
56

Re: Edit Orders v4.0 Support Thread

I've got a question regarding what should be expected regarding Edit Orders' handling of orders that contain deleted products.

The scenario: The website that uses Edit Orders extensively has one class of products that are one-off. Once they're sold, they're no longer available. The store owner, in performing "routine" maintenance, has gone through and specifically deleted (not disabled) the one-off products that have been sold (including product ID#234).

The customer who has purchased product #234 calls the store owner and requests that an additional product be added to their order. Store owner adds product ID 456 to the order. Upon updating the order, the orders_products table entry for the deleted product #234 has been updated with the products_id and products_prid both set to 0 and the products_price set to 0.00 (interestingly, the products_final_price value is unchanged).

What I expected was for Edit Orders to use the product-related information from the orders_products table (i.e. the products_id, products_prid and products_price fields should not have been changed for product #234) unless a new product was added to the order, in which case the products table would need to be interrogated for that newly-added product.

8 Dec 2013, 11:34 PM
#417
lhungil avatar

lhungil

Totally Zenned

Join Date:
Feb 2012
Location:
mostly harmless
Posts:
1,818
Plugin Contributions:
4

Re: Edit Orders v4.0 Support Thread

During an update, all products are removed from the order and re-added. The information about the product is first looked up from the database, then merged with the product information shown on the edit orders page...

I'll have to take another look at the code (out of town). I THINK the reason was to ensure the product info is fully populated for the order totals... Suspect I can add a workaround (although tax may be off without being able to pull the product's tax class and description)... Again will need to look back over the code.

Thank you for being patient and mentioning!

23 Dec 2013, 10:29 PM
#418
trademagic avatar

trademagic

New Zenner

Join Date:
Jul 2013
Location:
Lakewood, California, United States
Posts:
66
Plugin Contributions:
0

Re: Edit Orders v4.0 Support Thread

MagZ, You are a blessing. Was scared of not having edit orders and needing to completely reinstall many contributions. Thanks for all for having these forums, and participating with your knowledge and energy.

23 Dec 2013, 10:52 PM
#419
trademagic avatar

trademagic

New Zenner

Join Date:
Jul 2013
Location:
Lakewood, California, United States
Posts:
66
Plugin Contributions:
0

Re: Edit Orders v4.0 Support Thread

After getting edit orders functioning again, I am noticing I do not have a dropdown on adding additional orders for priced by attributes items. The first is a pulldown for product, but no pulldown for attributes like size, color etc. Is there something I must amend?

1.5.1
superorders4
editorders4.1.2
TyTracker etc

There are no other items I know of affecting this, but would appreciate any advice.

Attachment 13596

25 Dec 2013, 9:12 PM
#420
crixus avatar

crixus

New Zenner

Join Date:
Oct 2013
Location:
United States
Posts:
88
Plugin Contributions:
0

Re: Edit Orders v4.0 Support Thread

when i send Po using (POs - Send for Unknown Customer) Its's did't save to database history. how can save iT to my database please help