Printable View
Thanks.. that's much clearer.. yes submitting the updates to the downloads is the right way to address this.. and it was my bad on commenting out the super_payments define.. so nice catch..Quote:
Originally Posted by cherven
I have some further MINOR updates (some PHP 5.3 compatibility updates that got overlooked) to make so I will wait for your version to be approved and then submit the updates I have..
Thank you! Your set of files were the proper solution for all the issues I was having, and everything is now working correctly!Quote:
Originally Posted by cherven
Your welcome! Let us know if you find anymore bugs.Quote:
Originally Posted by paperthreads
Thanks Diva,Quote:
Originally Posted by DivaVocals
I'll reinstall to pick up all the changes. Thanks for the help! Hope you're going someplace good.
The new version should set you right.. :smile:Quote:
Originally Posted by badarac
I was actually coming back when I wrote my other post from the airport.. Went drag racing this weekend!! Whoo hoo!!:clap::clap: My hubby is in the chase for the championship for his particular class in this particular sanctioning body!!
Hi DivaQuote:
Originally Posted by DivaVocals
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.
Hi DivaQuote:
Originally Posted by honda-crunch
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.
As I always say, it's software so the answer to "is it possible to do X" is "yes probably".Quote:
Originally Posted by honda-crunch
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)
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
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:
and the change was:PHP Code:<div style="page-break-before:always"><span style="display: none;"> </span></div>
PHP Code:<br style="page-break-before:always"><span style="display: none;"> </span>