nij4t2

Hi all, I've looked at the Paypal IPN contribution with interest as a source of information for storing orders prior to moving to a different 3-rd party payment system. The thing I don't understand about it is that it stores the order in the confirmation() method. This seems to me to be earlier than necessary, and leaves orders around which 'get in the way of' orders that are real but did not get to an appropriate status for other reasons. So, by storing the order on the confirmation screen, orders get created for someone who just wanted to find out a shipping quote for an order... and just wanted to see the order total in a suitable form! (i.e. they may not even have planned to buy today at all). Wouldn't this be solved if the store-to-database element of the code was in the process_button() method instead? But as this makes so much sense to me, and the developers chose not to do it, I presume I must be missing something! :( Your thoughts appreciated, Nij

Hi, Before I begin, this is a nice contribution, and has provided some useful info even after just 3 days of being a live OSC site! I experienced some problems with the install, apparently due to setting up my Admin pages under a seperate SSL website structure. I found references to $PHP_SELF in recover_cart_sales.php to present problems, but changing to a direct reference to the filename, and using tep_href_link helped sort this out (even if it is just a hack!) So for example about 3 changes something like this had to be made: <form method=post action=<? // echo $PHP_SELF; echo tep_href_link('recover_cart_sales.php'); // NJR ?> > I also found the email structure to be worded very well, but the footer relies on HTTP_SERVER, which for my setup on the admin side is an ssl-relay address, and not the same as my catalog address. I think it should probably refer to HTTP_CATALOG_SERVER? I'd welcome thoughts from more experienced users! Best Regards, Nij

Hi, Anyway, I noticed that when a customer changes their address details, the VAT net and Inclusive prices became the same - even if the address change 'left' the customer in a vat-zone. The checkout process appeared to add the VAT correctly, but until then all displayed prices were incorrect. Logging the user out and in again resolved the problem, until they went in to change their address again. I believe the fault lies in two lines in address_book_process.php: $customer_country_id = $country_id; $country_id does not exist anywhere else that I can see on that file, and I believe a correction to both lines would be: $customer_country_id = $country; The fault means that the global $customer_country_id is set null, thus mucking up any future tax calculations in the tep_ functions. OK... so when I started writing this I thought that maybe TVA contrib was incorrect (hence posting in this forum), but a little research since suggests that in fact it is an error in MS2.2????? It's just made far more obvious by TVA changes, and my additional tweaks. Best Regards, nij