Super Orders v4.0 Support Thread for ZC v1.5.x

[DivaVocals]

For anybody who is having issues, try the fixed version here:
http://www.2shared.com/file/LDQccxnW/super_orders_4-0-4_final.html

I changed all the files to Unix Encoding, Instead of mac, and mixed (which was causing problems for me)
I Also fixed the problem when clicking on Payment or Purchase Order.

Let me know if this solves your problems, and if any problems still exist.

It would be helpful to provide details of this issue... Also it's better if you send potential bugfixes to me to test, evaluate and re-submit, OR you can submit an update to the downloads section.. This is better than having folks having to download two sets of files to install this add-on..

I also installed edit orders today, and the same thing with that showing up at the top banner as "success with install" and not going away, so it must be a problem with how that is updating on my server, but I don't know how to change it or fix it.

You need to contact your host as lhungil suggested in his earlier post..

[honda-crunch]

It would be helpful to provide details of this issue... Also it's better if you send potential bugfixes to me to test, evaluate and re-submit, OR you can submit an update to the downloads section.. This is better than having folks having to download two sets of files to install this add-on..

Hi Diva

Just one issue or at least I haven't seen it on the forum and one question, The issue I have hopefully sorted myself. Which is; while on SO, say you wanted to send a customer an email, you would click on the name and then be directed to the email creation page; no problem there... However, if you decided not to email them after all, the obvious choice would be is to hit cancel. This is where I found the error. It tries to redirect back to super_orders.php. As you know this file no-longer exists.

This is my edited result from admin/orders.php

replace line 1755 with:

echo '<a href="' . zen_href_link(FILENAME_MAIL, 'origin=orders.php&mode=NONSSL&selected_box=tools&customer=' . $orders->fields['customers_email_address'] . '&cID=' . $orders->fields['customers_id'], 'NONSSL') . '">' . $orders->fields['customers_name'] . '</a>';
?>

It now sends you back to the orders page and not a white screen with url not found on this server.

Now the question...
The only parts that we ask of super orders is to batch print and batch email along with tracking and edit orders. Batch printing works perfectly although very slow, maybe because we have many thousands of orders on our server. However, we have no use for the "Order Payment Data" part of SO. Not because we don't like it but because it doesn't work for our system. We use paypal express and Realex redirect card payments. Although you have seemingly fixed the paypal ipn promlem from v3. Our result is zero price and a date of 30-11-1999 logged for every sale within the green bar. I can only assume this is a communication problem between paypal and our server. As we are trying to save time, we don't want to edit every sale to update with price. With the original zencart orders.php, we are getting the price from paypal and all works normally. With the payment data in so it doesn't seem to collect the amount which is obviously there and gives the result £0.00, then uses the correct amount stored on the sever as a balance due. As for the Realex, there is no green bar and an invoice that says the customer still needs to pay the balance. I have already sorted the invoice by removing the code that creates the amount supplied and balance due part.

My question is, Can I scrap the whole super orders "order.php" file and use my old joint edit and tracking orders.php and just use your links to the batch print and email or is there other parts of orders.php that interfers with the batch mods.

Many thanks even if you can find the time even to read this, I know you must be very busy.

[honda-crunch]

Hi Diva
Although you have seemingly fixed the paypal ipn promlem from v3. Our result is zero price and a date of 30-11-1999 logged for every sale within the green bar. I can only assume this is a communication problem between paypal and our server.

Hi Diva

I do believe I have fixed the issue with the order payment data not working correctly with Paypal. However it has given another headache. After searching the paypal forum. DrByte (the Paypal expert) gave me a big clue.. He says that if you use paypal pro, communication is very poor between Paypal and zencart's IPN so it doesn't always work; hence why we never recieved full IPN data. He also goes on to say the only proper system to work with zencart is express checkout. As we do not use paypal pro any more (due to paypals RIP-OFF costs) I switched my Paypal express settings mode from payflow-uk to paypal. It now receives IPN data properly and uses it correctly in your super orders "order payment data". As for the headache, It would be too easy to say all is ok. While new orders work fine, if I open and close an older order processed with payflow-uk; its doesn't crash but gives the following warning: "There was a problem retrieving transaction details. (Transaction refused because of an invalid argument. See additional error messages for details.) 10004"
I found out this is due to the two different paypal modes. This can be fixed by changing the paypal mode back to payflow-uk but once the order has gone through successfully, how many times are you going to open old orders. If refund is required from an old order, we can always do it directly from paypal's website.

Obviously not your problem but it may help others getting the same issue.

It would be nice to know; for future reference, if it is possible to retrieve and use data from redirect payment methods such as our Realex module which directs customers to a secure server after the sale then back to us to complete. At present, super orders assumes that the order has not been paid thus giving no payment data.

[DivaVocals]

It would be nice to know; for future reference, if it is possible to retrieve and use data from redirect payment methods such as our Realex module which directs customers to a secure server after the sale then back to us to complete. At present, super orders assumes that the order has not been paid thus giving no payment data.

As I always say, it's software so the answer to "is it possible to do X" is "yes probably".

HOW to achieve that is a question I cannot answer as whatever code is required would have to be written so that the Super Orders payment data can be captured from the Realex module, and I know nothing about this particular payment module. In order to work there needs to be a means to capture the Realex payment data and convert that data into a Super Orders payment record. (This is how the code for converting credit card transactions and PayPal transactions into Super Orders payment records works)

[joem83]

Didn't see anyone else mention this, when I try to print an invoice a new window opens, but it is blank. In the log files it shows: Invalid CRT parameters detected

[badarac]

I upgraded my clients site to the 4.0.4 level and found a couple problems.

The version in the sql is being set to 4.0.2. Easily fixed in the admin/config but incorrect none the less.

The new version fixed the problem with the add on admin profiles not having the authority to print. That's the good news. The bad news is that for some reason I was not able to update existing profiles to select the new checkboxes for SO. I clicked update and when I accessed the profile again the checkboxes were blank. I ended up creating brand new profiles which saved fine.

Batch form print generates html that will not page break in IE. It worked fine in Firefox. The pages just run together. I had to make a change to invoice.php and packingslip.php removing the div and replacing it with br. The old code was:

<div style="page-break-before:always"><span style="display: none;">&nbsp;</span></div> 

and the change was:

<br style="page-break-before:always"><span style="display: none;">&nbsp;</span> 

[lhungil]

The version in the sql is being set to 4.0.2. Easily fixed in the admin/config but incorrect none the less.

Thank You for the heads up (and for taking the time to share your recent experiences with Super Orders).

The new version fixed the problem with the add on admin profiles not having the authority to print. That's the good news. The bad news is that for some reason I was not able to update existing profiles to select the new checkboxes for SO. I clicked update and when I accessed the profile again the checkboxes were blank. I ended up creating brand new profiles which saved fine.

Glad you were able to get the profiles working. Out of curiosity are you using Zen Cart 1.5.0 or 1.5.1? There was a bug in the original Zen Cart 1.5.0 release which did not allow you to update authorization for existing profiles.

Batch form print generates html that will not page break in IE. It worked fine in Firefox. The pages just run together. I had to make a change to invoice.php and packingslip.php removing the div and replacing it with br.

I have not tested or used this feature myself, but you can probably just replace the block with:

<br style="page-break-before:always" />

I believe the admin pages in Zen Cart use XHTML 1.0 Transitional - which requires closing the br tag. The extra span was required to stop browsers from seeing an empty div / span and removing the div / span when rendering the page. This should not be needed if you are using a <br /> instead. Let us know if the change works!

[DivaVocals]

The new version fixed the problem with the add on admin profiles not having the authority to print. That's the good news. The bad news is that for some reason I was not able to update existing profiles to select the new checkboxes for SO. I clicked update and when I accessed the profile again the checkboxes were blank. I ended up creating brand new profiles which saved fine.

I see someone else already pointed this out, but I wanted to make sure I posted this again.. Not being able to update existing admin profiles is a ZEN CART bug.. Not a Super Orders bug.. and as was pointed out this is addressed in Zen Cart v1.5.1..

[picandnix]

Hi Diva

Just one issue or at least I haven't seen it on the forum and one question, The issue I have hopefully sorted myself. Which is; while on SO, say you wanted to send a customer an email, you would click on the name and then be directed to the email creation page; no problem there... However, if you decided not to email them after all, the obvious choice would be is to hit cancel. This is where I found the error. It tries to redirect back to super_orders.php. As you know this file no-longer exists.

This is my edited result from admin/orders.php

replace line 1755 with:

echo '<a href="' . zen_href_link(FILENAME_MAIL, 'origin=orders.php&mode=NONSSL&selected_box=tools&customer=' . $orders->fields['customers_email_address'] . '&cID=' . $orders->fields['customers_id'], 'NONSSL') . '">' . $orders->fields['customers_name'] . '</a>';
?>

It now sends you back to the orders page and not a white screen with url not found on this server.

thank you for this Honda-crunch,
F.Y.I Divavocals this issue remains the same in SU 4.05, thank you for the continued development of this great mod

[DivaVocals]

thank you for this Honda-crunch,
F.Y.I Divavocals this issue remains the same in SU 4.05, thank you for the continued development of this great mod

Ummm no... This was fixed in the current version..