OLD Super Orders 2.0 (See v3.0 thread instead)

[profitshock]

In my last post I suggested in might be to do with a redirect and in trying to nail this down further so anyone with the skills/time can hopefully suggest a fix I remembered that ZC would kindly generated a myDEBUG-adm-xxx.log in the /cache folder for us :)
In my case the error message reads:

PHP Fatal error:  Call to undefined function date_diff() in /home/path/to/domain.com/public_html/admin/super_orders.php on line 123

I guess this means it's not because the redirect is wrong, it's just not completing hence no page being displayed.

These are the lines of code from 121 - 128 which should give some context to the error.
(line 123 begins with $zc_max_days = date_diff )

          if ($status == DOWNLOADS_ORDERS_STATUS_UPDATED_VALUE) {
            // adjust download_maxdays based on current date
            $zc_max_days = date_diff($check_status->fields['date_purchased'], date('Y-m-d H:i:s', time())) + DOWNLOAD_MAX_DAYS;

            $update_downloads_query = "update " . TABLE_ORDERS_PRODUCTS_DOWNLOAD . " set download_maxdays='" . $zc_max_days . "', download_count='" . DOWNLOAD_MAX_COUNT . "' where orders_id='" . (int)$oID . "'";
            $db->Execute($update_downloads_query);
          }
          $messageStack->add_session(SUCCESS_ORDER_UPDATED, 'success');

The note on ln 122 suggests something has been tweaked and I have no idea what date_diff is or does or even why it isn't defined.
Any ideas on what will break if I comment out line 123 ?
or is it simpler to define date_diff?

hth

Hi,

Having a problem with the update order when I add a new order status.

Instead of loading the order page witha note added to the message stack it is displaying a blank page.

A typical url of the problem would be:

https://mywebsite.co.uk/admin/super_...n=update_order

I have looked into the code (but not touched anything) and the action for update order at the moment seems to look like this (starting line 100 (approx) of admin/super_orders.php)

case 'update_order':
        $status = zen_db_scrub_in($_POST['status'], true);
        $comments = zen_db_scrub_in($_POST['comments']);

        $check_status = $db->Execute("select customers_name, customers_email_address, orders_status,
                                      date_purchased from " . TABLE_ORDERS . "
                                      where orders_id = '" . (int)$oID . "'");

        if ( ($check_status->fields['orders_status'] != $status) || zen_not_null($comments)) {
                  $db->Execute("update " . TABLE_ORDERS . "
                        set orders_status = '" . zen_db_input($status) . "', last_modified = date_add(now(), INTERVAL " . TIME_ZONE_OFFSET . " HOUR)
                        where orders_id = '" . (int)$oID . "'");
          $customer_notified = '0';
          if (isset($_POST['notify']) && ($_POST['notify'] == 'on')) {
            $customer_notified = '1';
          }

          update_status($oID, $status, $customer_notified, $comments);

          if ($customer_notified == '1') {
            email_latest_status($oID);
          }

          if ($status == DOWNLOADS_ORDERS_STATUS_UPDATED_VALUE) {
            // adjust download_maxdays based on current date
            $zc_max_days = date_diff($check_status->fields['date_purchased'], date('Y-m-d H:i:s', time())) + DOWNLOAD_MAX_DAYS;

            $update_downloads_query = "update " . TABLE_ORDERS_PRODUCTS_DOWNLOAD . " set download_maxdays='" . $zc_max_days . "', download_count='" . DOWNLOAD_MAX_COUNT . "' where orders_id='" . (int)$oID . "'";
            $db->Execute($update_downloads_query);
          }
          $messageStack->add_session(SUCCESS_ORDER_UPDATED, 'success');
        }
        else {
          $messageStack->add_session(WARNING_ORDER_NOT_UPDATED, 'warning');
        }

        zen_redirect(zen_href_link(FILENAME_SUPER_ORDERS, zen_get_all_get_params(array('action')) . 'action=edit', 'NONSSL'));
        break;
      case 'deleteconfirm':
        zen_remove_order($oID, $_POST['restock']);
        $so->delete_all_data();

        zen_redirect(zen_href_link(FILENAME_SUPER_ORDERS, zen_get_all_get_params(array('oID', 'action')), 'NONSSL'));
      break; 

Is this correct or am I missing something? If its all correct then what can I do to fix the bug?

Thanks

[totalsam]

Hate to be a pain but my system seems to have corrected itself :s if I find out more I will post

[profitshock]

The fix For non displaying page after altering order status.

open super_orders.php

on line 123 (or thereabouts) find

$zc_max_days = date_diff($check_status->fields['date_purchased'], date('Y-m-d H:i:s', time())) + DOWNLOAD_MAX_DAYS;

and replace with

$zc_max_days = zen_date_diff($check_status->fields['date_purchased'], date('Y-m-d H:i:s', time())) + DOWNLOAD_MAX_DAYS;

The difference is that date_diff is now zen_date_diff

For those interested in how I worked it out in case you want to try debugging minor errors, I used the developers tool kit and searched for 'date_diff'.
There wasn't a 'date_diff' but there were a few zen_date_diff references.
I put two and two together and voila :)

hths

Kevin

[totalsam]

Clever.

I have added the fix even though it appears to be working now. Hopefully it will prevent future issues!

[profitshock]

I've found out more and None! is displayed in the invoice by some clever logic that is only useful if your are based in the US.
See http://www.zen-cart.com/forum/showpo...&postcount=150 which is where BlindSide explains it more.

By removing the 00-0000000 number from
Configuration > Super Orders > Federal Tax Exempt Number in admin,
the Invoice now displays 0.00% in the Tax Column in stead of None!.
While it's an improvement it's still incorrect and not relevant to the European marketplace in it's current format.

I can't for the life of me see how it can be configured to use VAT so to all intents and purposes it can be 'hidden' for the time being or partially disabled and used for display only of an EU VAT number.

The other option is to call and display the correct rate from the original order (if it is stored). I say from the order rather than the current rate because the current rate may change. While that's fine if you are posting your invoice today it would be wrong if you tried to reprint for example an old invoice and the tax rate had changed from 15 - 17.5% or 17.5 - 20%.

hths

Kevin

I am experiencing the same issues as Centec2b.
Zen Cart version is 1.3.9e
PHP Version: 5.2.x
SO version: 2 - 139

Searching through the posts this issue was bought up with ZC 1.3.8 and due to the amount of activity probably got over looked.

Where 'None!' appears, based on what I see in the ZenCart invoice.php file I would expect to see the tax rate.

As far as I can work out the code affecting this is in super_invoice.php
Lines 239 - 245

      if ($display_tax) {
        echo zen_display_tax_value($order->products[$i]['tax']) . '%';
      }
      else {
        echo ENTRY_NO_TAX;
      }
      echo '</td>' . "\n" ;

The corresponding code (as far as I can tell) in invoice.php is

      echo '        <td class="dataTableContent" align="right" valign="top">' . zen_display_tax_value($order->products[$i]['tax']) . '%</td>' . "\n" .

The only thing I can think of is that the if($display_tax) in SO is not finding or reading the tax code but I wouldn't know where to fix it.
Given that the original invoice.php file uses other ZC functions to determine the tax rate etc I have to wonder why the 'if' statement exists at all. Is there a reason specific to SO ??

In my case the pricing of the tax calculation works fine so it is just a display issue in the product lines.

[brandname2007]

I have installed the files for SOv2 and for whatever reason I can not access any of the modules for it in the admin section. I can only access the configuration for it... any ideas?

I have had this thing working before on my last test server. I guess thats what I get for trying to start all over from the ground up!?

[brandname2007]

NEVERMIND... I figured out the problem and boy do I feel stupid!

If anyone else has this problem ask yourself if you have renamed your "admin" folder. The file structure from the download still has the admin folder named "admin"... be sure you change it to whatever you renamed your admin folder to before you upload the Super Order files. No wonder it wouldn't work.

All is great now.

[kkfok1]

HI,

Has anyone tried to incorporate printing with specific document format e.g. EMS, custom declaration form, etc into Super Orders ? Or how can I change the printing position of the current printing ?

Thanks
KK

[DivaVocals]

At long last I've got everyone's code compiled into our RC1 version.. We're testing it now, and hopefully we'll be able to submit this soon.. Stay tuned!!!

Highlights include:
General updates

1. Incorporate commenting updates from the default Zen Cart orders.php (most notably the hidden "admin only" comments functionality)
2. Correct errors with downloads flags not setting correctly

Edit Orders
(http://www.zencartmod.com/index.php?...&products_id=3)

1. Install package includes the modified files needed for those who use Edit Orders. (you must install Edit Orders BEFORE using these files)
2. We've made a few improvement to the Edit Order files as follows:
   
   • Incorporate commenting updates from the default Zen Cart orders.php (most notably the hidden "admin only" comments functionality)
   • There is now one button to take you back to to the Super Orders order details page for the order you are adding products to and another new button to take you back to the Edit Order page for the order you are adding products to.. (Currently in Edit Orders the "Add Products" section only has a "Back" button that returns you to the order details page for the order you are adding products to..)
   
   

Reporting & Order Update Improvements

1. Improved orders awaiting payment report
2. PDF printing options included in batch printing
3. Additional search options for Batch printing/update functions

Super Orders Payments Improvements

1. For orders paid with PayPal the store owner is no longer required to manually enter a payment in Super Orders. Super Orders will now automatically enter a payment record and show these orders as paid without requiring the store owner to enter a manually enter a payment record.1

Split Orders Improvements

1. Splitting an order now results in a “parent order” (original order number) and a child order (new order number). The resulting parent and child orders cannot be split.
2. Super Orders now correctly re-calculates BOTH the parent and the child order when an order is split. (The original shipping charges stay with the parent order)
3. If an order is paid in full, the split order function will distribute the payment correctly across both the parent and child orders so that you end up with two fully paid orders which true up to the amount of the original order amount.
4. The original payment information is displayed on both the parent and child orders. This display shows the original grand total paid. ($ Parent + $ Child = Grand Total)
5. For split orders paid via PayPal the “empty” PayPal payment notification data panel will no longer be displayed on child orders.
6. The split order packing list button now appears ONLY when the order is either a parent order or the resulting child order -- otherwise it will NOT display.. (Currently it displays on EVERY order when the order includes multiple items)
7. The split packing list details has been fixed to function as it was originally intended (but did not).
   
   • The packing list for the parent order displays the FULL original order with the items that were moved to the child order flagged as "Product(s) will ship separately"
   
   
   
   • The packing list for the child order displays the FULL original order with the items that remained on the parent order flagged as "Product(s) will ship separately"
   
   

About PayPal Payments:
1 There are a number of threads on the Super Orders support thread which discuss a number of methods for automating PayPal payments. Some of these methods include automating refunds as well. We chose not to implement any of these solutions or variations of them in order to maintain a level of consistency when it came to the module’s basic "out the box" functionality. This keeps the application functional across a wide variety of stores. While other payment methods (notably the Offline Credit Card Processing and Authorize.net modules) did not require the entry of a payment record, payments received through the PayPal payment module required shop owners to manually enter a payment record in Super Orders. (hence the reason for this change)

Furthermore, Super Orders does not include automated refunds processing for any other payment module (such as Authorize.net). Including automated refunds processing for ONLY the PayPal payment module while ignoring other payment modules would be building in a level of inconsistent functionality for a module that will be used by MANY different store owners each with different needs. Therefore the application's consistency was the guide in how this function was implemented.

That said, I fully recognize that there are shop owners who may want this specific functionality (automated refunds processing) for their particular store. There are lots of threads which cover how to add automated refunds for PayPal paid orders, and owners requiring this functionality should seek out those posts and see if they can adapt the suggested code for their needs. (I cannot offer any assistance in this regard)

[orange_juice]

Hallo,

(Thanx for the above posting, sounds great!)

When I update an order and click on the update button to send the email to the customer, I receive the following warning:

date_diff() expects parameter 1 to be DateTime, string given in [mydomain]/admin/super_orders.php on line 123

Line 123 reads:

$zc_max_days = date_diff($check_status->fields['date_purchased'], date('Y-m-d H:i:s', time())) + DOWNLOAD_MAX_DAYS;

I would appreciate your help.

Kind regards,
orange_juice