Jump to content

Supertex

Members
  • Content count

    309
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Supertex

  1. I will go back and check. In that second thread that you linked...the one you mentioned Gary in, actually details my useage of PDT pretty closely. Bob had found a PDT fix for mobile devices, prior to the release of the paypal app. HPDL had me turn it off to test things when he released the app...then figured out that there was a GET vs. POST issue and determined to update the app to fix it...which he eventually did. Currently, I do have a PDT Identity Token in place in the app, and I'll double check on whether or not I have PDT turned on in PayPal, but I -think- I do have it on. I do not, however, have any duplicate notices - save for when the customer returns and then the IPN lands. Could you post an image of what you're seeing? ...not that I can be of much help, but if I can, I will.
  2. @@Dan Cole I actually do use preparing. I just hid it from the orders list and individual orders, because I had so many orders that were never completed, it became an annoyance...I have lots of window shoppers. I'll read both of the threads you've listed carefully. I may end up with egg on my face, but hell, it wouldn't be the first time, and if it solves a the problem, I'd be happy enough not to care. However, I don't think that's the case here. I think this is something that people are missing, and 14Steve14's alluded to the same thing in the statement about checking paypal and emails as the final word in payment completion.
  3. Hi Steve, I have chosen to hide all orders with the "preparing" status (I've renamed this to "Temp" status). It actually occurs when the customer selects paypal as the payment option, and clicks to continue on to checkout_confirmation. So that status occurs before the customer ever even leaves your site. I -believe- it's unique to paypal orders, and its purpose is to establish an order number that can be compared to what is returned from paypal. I know that this status does not occur with authorize.net, money order, wire transfer, etc. Your "Order Placed" is the same as my "Payment Completed" (originally, I believe this was "Processing"). Indeed, this means the customer actually went to paypal, and submitted a payment. From here, IF the customer returns, and they do so before the IPN lands, you should see an 'internal status' of PayPal [Transactions] with the info string from PayPal. At this point, stock is decremented, the customer's cart is cleared, and the order status gets changed to your "Order Placed." OR if the customer does not return to your store, then the exact same thing occurs, but is initiated instead when the IPN lands. In this case, you will see "source: IPN" at the end of the info string. Incidentally, I've also had both the customer return and the IPN hit at the exact same moment, and BOTH ran the order completion process, ending up with a double stock decrement...but that's a discussion for another time. The green tick just indicates whether or not the customer was emailed concerning the status change, which of course depends in part (I think) on whether or not the new status is visible to the customer, as set in Localization->Orders Status -> "Show the order to the customer at this order status level" This is my point. The site cannot be trusted to show us if payment actually went through. It can only show us that a customer requested that paypal submit payment to us. However, it could...and I'd venture to say it 'easily' could, as the information needed to act as the switch is sent on EVERY communication from paypal, including IPNs. If someone can tell me how to extract the content of 'payment_status' => $details['PAYMENTSTATUS'], from its containing array, I believe it would be a simple matter to use it in a switch that determines whether to apply your "Order Placed" status, or a new intermediate status - one that says payment was submitted, but is under review...on hold...whatever. The benefit being that it would be visible in the orders list, and be distinguishable from orders where we've got full approval on the payment. It could also be made visible to the customer, so they understand why their order isn't being shipped. I agree that one solution is to monitor email and/or paypal account. However, it's not uncommon on a Monday, to come into the shop and have 50 orders that I have to pack and ship by 3pm. When you combine this with phone calls, email support, etc., etc., it makes for a hectic day that can easily result in missing the fact that one of the orders (lets hope it's not a $1k order) was lingering unapproved in paypal, and was mistakenly shipped out. What I'm suggesting avoids this scenario entirely, because as soon as you would see "OK to ship" in your paypal account, an IPN is dispatched (sometimes days later, as in the order in my last post) and lands on the site containing the go code - "Order Status: Complete" ...which would then change the store order status from the (new) intermediate status to "Order Placed"...which you would see in the order list.
  4. Right...my 'processing' (which I've named Payment Completed) is the same as your 'pending'. It's not the verbage that is my concern here. It's that regardless of which status you assign for "NEW_ORDERS_STATUS" (in your case, "Pending") the site does not distinguish between what PayPal says IS or IS NOT approved payments. Here is the most recent example of what I'm talking about: I just happened to notice that this order was not actually paid, and set it to a different status manually, to prevent it from being inadvertently shipped before it had actually been paid. The app does not check for this. It only has 2 assignable statuses - one for pre-payment submission, and one for post-payment submission. But submission doesn't mean the payment is actually approved. So we need to be able to assign an intermediate. Of course assuming it would be desirable for more than just myself, to be able to tell an order is unpaid by looking at the orders list, instead of going into each order and checking each payment. Everything we need to do it is already there. Paypal sends several discrete variables (one being payment status) that the app combines into a string for entry in the comment. I'm just not confident enough in my coding to do it. I've mentioned this to HPDL, but I haven't seen any activity from him since July. If I'm being dense, smack me...I can handle criticism. But I don't think folks realize what I'm saying here.
  5. Hi Dan, and thanks for the reply. My Problem isn't with the naming of the store's order status levels, or duplicity, but rather that the Paypal app only allows 2 store status levels for an order. As it is now, chances are high, that I've shipped a few orders with nothing more than a virtual "I.O.U." 1) Preparing - Customer has chosen shipping methods and PayPal as a payment method, and is sitting on the checkout_confirmation...perhaps they just wanted to determine the final cost for a cart. 2) Processing - Customer has submitted payment and either returned from PayPal or the IPN has come back. ("OK to ship") My issue is that PayPal may or may not have approved the transaction, yet at our store...there is no indication either way. Both payments that are on hold (as in the case of an e-check), and fully completed payments have the same store order status. The only way to tell is open the order up and inspect the comments. While it sounds trivial (if not just plain lazy on my part), when processing 30-50 orders on a Monday...things like that are easily overlooked. Not to mention, the order will slide down the list as new orders come in, making it more difficult to find it and check to see if it's status has been updated. Just seems like allowing the following conditions would be a big improvement: 1)Preparing - same as above 2)Pending - awaiting an update to completed payment status via IPN 3)Processing - O.K. to ship Of course, for most transactions, it would just go straight from 1 -> 3. But for those few occurrences where the payment is for whatever reason, on hold, it would help prevent shipping out an order that is unpaid.
  6. Looking at includes/modules/payment/paypal_standard.php, I find this around line 1200: $pptx_params = array('txn_id' => $details['TRANSACTIONID'], 'invoice' => $details['INVNUM'], 'custom' => $details['CUSTOM'], 'payment_status' => $details['PAYMENTSTATUS'], 'payer_status' => $details['PAYERSTATUS'], 'mc_gross' => $details['AMT'], 'mc_currency' => $details['CURRENCYCODE'], 'pending_reason' => $details['PENDINGREASON'], 'reason_code' => $details['REASONCODE'], 'address_status' => $details['ADDRESSSTATUS'], 'payment_type' => $details['PAYMENTTYPE']); is it feasible to make use of $details['PAYMENTSTATUS']... maybe as a global, and then use it as a switch here: function before_process() { global $order_id, $order, $languages_id, $currencies, $order_totals, $customer_id, $sendto, $billto, $payment; $new_order_status = DEFAULT_ORDERS_STATUS_ID; if ( OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID > 0) { $new_order_status = OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID; } tep_db_query("update " . TABLE_ORDERS . " set orders_status = '" . (int)$new_order_status . "', last_modified = now() where orders_id = '" . (int)$order_id . "'"); $sql_data_array = array('orders_id' => $order_id, 'orders_status_id' => (int)$new_order_status, 'date_added' => 'now()', 'customer_notified' => (SEND_EMAILS == 'true') ? '1' : '0', 'comments' => $order->info['comments']); tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array); To set only "Completed" (and "Refunded") to OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID, else set it to the store's 'default' order status? I'm making the assumption that since standard_ipn.php requires paypal_standard.php, that when the 'completed' IPN lands, the same switch will still apply, and then correctly set the order to OSCOM_APP_PAYPAL_PS_ORDER_STATUS_ID. Way over my head here. @@Bob Terveuren you saved my bacon with PayPal a few times before. Would be interested to have your take on this.
  7. Supertex

    UPSXML Saving Disallowed Shipping Methods

    Thanks Jim. I finally got it working last night by changing it as follows: switch ($action) { case 'save': $module_name = ''; // detect custom modules.. if( array_key_exists('MODULE_SHIPPING_USPS_STATUS', $HTTP_POST_VARS['configuration']) ){ $module_name = 'usps'; } else if( array_key_exists('MODULE_SHIPPING_UPSXML_RATES_STATUS', $HTTP_POST_VARS['configuration']) ){ $module_name = 'ups'; } reset($HTTP_POST_VARS['configuration']); while (list($key, $value) = each($HTTP_POST_VARS['configuration'])) { switch( $module_name ) { case 'usps': if( is_array( $value ) ){ $value = implode( ", ", $value); $value = ereg_replace (", --none--", "", $value); } break; case 'ups': if( is_array( $value ) ){ $value = implode( ", ", $value); $value = ereg_replace (", --none--", "", $value); } break; } tep_db_query("update " . TABLE_CONFIGURATION . " set configuration_value = '" . $value . "' where configuration_key = '" . $key . "'"); } tep_redirect(tep_href_link(FILENAME_MODULES, 'set=' . $set . '&module=' . $HTTP_GET_VARS['module'])); break; case 'install': case 'remove': Monkey-see, monkey-do, heh. Eagerly anticipating USPS Codes :)
  8. Supertex

    UPSXML returns incorrect pricing from UPS

    Not that this will help a long-since dead thread OP, but for anyone who stumbles across this while looking for a solution: In the config portion of that post, your handling fee is set to "flat" with "5" in the next field, so your site is adding $5 to each quote for handling.
  9. Supertex

    UPSXML Saving Disallowed Shipping Methods

    Well...I did follow the instructions, but apparently, going back to USPS Rates V7 (had to, in order to retain insured USPS) goofed up the UPS aspect of my modules.php. I never knew, because I never had to go back and change anything in the UPS shipping module...so previously-saved variables remained in place until I stupidly uninstalled it. Now, when I try to save the settings, it -appears- to work, except the methods don't stay checked. When I look at the configuration table in the DB, it just says "Array" where it should say "US_01, US_02" etc. Someone mind looking at this and tell me how to fix it so it saves my methods correctly without breaking the USPS module? if (tep_not_null($action)) { switch ($action) { case 'save': $module_name = ''; // detect custom modules.. if( array_key_exists('MODULE_SHIPPING_USPS_STATUS', $HTTP_POST_VARS['configuration']) ){ $module_name = 'usps'; } reset($HTTP_POST_VARS['configuration']); while (list($key, $value) = each($HTTP_POST_VARS['configuration'])) { switch( $module_name ) { case 'usps': /* * TODO: review * USPS Methods */ if( is_array( $value ) ){ $value = implode( ", ", $value); $value = ereg_replace (", --none--", "", $value); } /* * /end */ break; } tep_db_query("update " . TABLE_CONFIGURATION . " set configuration_value = '" . $value . "' where configuration_key = '" . $key . "'"); } tep_redirect(tep_href_link(FILENAME_MODULES, 'set=' . $set . '&module=' . $HTTP_GET_VARS['module'])); break; case 'install': case 'remove':
  10. Supertex

    FedEx - Web Services v9

    All I can do is cheer you on from the sidelines, as you're way over my head already. Let me know if there's some way I can help out.
  11. Supertex

    ULTIMATE Seo Urls 5 - by FWR Media

    I'm a dummy. I found an active child category within an inactive parent category. Turned off the child and the error went away.
  12. Supertex

    ULTIMATE Seo Urls 5 - by FWR Media

    Well, I've figured out the cause, but not what to do to fix it. Here's the deal: I have several categories that are not active...as in no products yet. I did not want my human-readable sitemap to show them. So, I added a "categories_status" column to the categories table and added a 'where' clause into the queries of the human-readable sitemap files - problem solved. I only recently became aware that the XML sitemaps were causing these hidden categories to be indexed by Google, so I added the same 'where' clause to the usu5_sitemaps/index.php. The problem appeared immediately after this. So it appears that this alone has caused the issue, but I don't understand why, or how to fix it. Here's the categories section of the usu5_sitemaps/index.php file: function categoriesFullScan(){ $sql = "SELECT categories_id, parent_id, date_added, last_modified FROM " . TABLE_CATEGORIES . " WHERE categories_status > 0 GROUP BY categories_id ORDER BY date_added ASC, last_modified ASC"; return tep_db_query($sql); } function buildCategoriesCache() { $result = categoriesFullScan(); while ( $row = tep_db_fetch_array( $result ) ) { $categories[$row['categories_id']] = array( 'id' => $row['categories_id'], 'parent' => $row['parent_id'], 'path' => '', 'last_mod' => ( strtotime( $row['last_modified'] ) > strtotime( $row['date_added'] ) ) ? $row['last_modified'] : $row['date_added'] ); } tep_db_free_result($result); // Housekeeping foreach ( $categories as $cat_id => $key ) { if ( $key['parent'] != '0' ) { ( isset( $categories[$key['parent']]['children'] ) && ( $categories[$key['parent']]['children'] !== null ) ) ? null : $categories[$key['parent']]['children'] = ''; $categories[$key['parent']]['children'] .= $key['id'] . ','; } else { $categories[$key['id']]['path'] .= $key['id']; } } foreach ( $categories as $cat_id => $key ) { $fullcatpath = ''; if( $key['parent'] != '0' ) { $fullcatpath = setCpath( $categories, $key['id'] ); $categories[$key['id']]['path'] = $fullcatpath; } } return $categories; } "WHERE categories_status > 0" is what I added to hide the appropriate categories from the XML sitemap. When I remove that text, the sitemap no longer produces the errant entry. Also, the errant entry is a ghost - it's not a category at all: <loc>http://www.mysite.com/index.php?cPath=_</loc> And I've checked the DB...all of my categories have a 'real' date, both for created and for modified, which is neither here nor there, as the entry isn't actually a category. And the time stamp is 'Unix epoch' time, so yes, it's a default that's being used because it can't find an actual date for created or modified. I could understand this if there were two different queries, and row counts didn't match, but from what I can tell here (and I'm no expert, mind you) the 'FullScan' is the only query in use. What have I missed here?
  13. Supertex

    ULTIMATE Seo Urls 5 - by FWR Media

    Actually, I'm not using the Google XML Sitemap SEO anymore (it doesn't create friendly urls), but instead just using the one that comes with USU5 Pro. I call the mysite.com/usu5_sitemap/index.php in a browser, daily. Bearing that in mind, you still think this has something to do with Google XML?
  14. Supertex

    ULTIMATE Seo Urls 5 - by FWR Media

    I've suddenly started getting a few errors show up in Webmaster Tools regarding a Dec 31, 1969 date. When I look at the XML file, the last entry of sitemapCategories, is: -<url> <loc>http://www.mysite.com/index.php?cPath=_</loc> <lastmod>1969-12-31</lastmod> <changefreq>weekly</changefreq> <priority>0.5</priority> </url> </urlset> All of the preceeding entries show correct, SEO-friendly links. Any idea why it's running into this at the end of the XML construct? Webmaster tools also shows the error coming from the sitemapIndex.xml, but I believe that's due to the reference in the index to sitemapCategories. It looks like it gets to the end of the categories list, and finds no remaining category, so of course no date, and the above entry is the result.
  15. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    You don't have any items with a cart quantity greater than your stock, do you...?
  16. Supertex

    [Contribution] - USPS Methods

    The newest version should be 7.3.1. But I see you've posted a similar message here: http://forums.oscommerce.com/topic/383307-usps-rate-v4-intl-rate-v2-official-support-thread/page-72#entry1732799 Are you using both?
  17. Supertex

    Blacklist

    I've recently installed this in my 2.3.1, and also noticed the multiple appearances of the same name. It's because of multiple address book entries for the customer. It really threw me at first, because I'd entered some customers' addresses as my own for testing. I couldn't figure out where it was getting them, until I looked closer. I know the thread is old, but someone (such as myself) may also run into this.
  18. Supertex

    PayPal App v4.039 - double stock decrement

    @@Bob Terveuren So, is this a built-in redundancy? It seems like I remember figuring out that normal order creation (money orders, for example) was handled by checkout_confirmation (or perhaps checkout_process?) but something about paypal required that an order ID be created sooner in the process, so for Paypal, orders were generated as the customer left checkout_payment. Is the code you quoted designed to delete the 'premature' order_id and replace it with the one generated 'normally' (by checkout_confirmation)?
  19. Supertex

    PayPal App v4.039 - double stock decrement

    Forgive my ignorance... Do you happen to know enough about that error that you might see how it would be capable of causing an order deletion? Or is the server error likely something that happens often (perhaps on every transaction), and the deletion is unrelated?
  20. Supertex

    PayPal App v4.039 - double stock decrement

    This morning, I made the changes from post 5. I had another order disappear on me...but this time I contacted my webhost with the date and time that the order was placed, and had them check the server log. Here's what they found: [Wed Jul 01 15:32:14 2015] [error] [client xxx.xxx.xxx.xxx] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php53/lib/php/extensions/no-debug-non-zts-20090626/memcache.so' - /usr/local/php53/lib/php/extensions/no-debug-non-zts-20090626/memcache.so: cannot open shared object file: No such file or directory in Unknown on line 0, referer: https://www.mysite.com/checkout_shipping.php The IP was in fact the IP of the customer. This query, and the discovery of the error seems to have piqued a larger response from the webhost than usual. I'm curious to see how this works out. I really have no idea though, if this error has anything to do with the missing order. I know in other cases, the customer was diverted by an ambiguous link in Paypal, that took him off course from checkout. By the time he got back on track, finished the order, and landed back on our site, he was shown an error, and the system had deleted his order. Not sure what happened on the paypal side of this latest transaction, but the fact that the server error log points to an event that occured after leaving checkout_shipping.php is interesting.
  21. Supertex

    Looking For Testers: New PayPal App

    Line 747 of catalog/includes/modules/payment/paypal_standard.php That is assuming you're using the 'standard' module, and you're aware of the consequence of allowing shipment to a non-verified address.
  22. Supertex

    FedEx - Web Services v9

    Has anyone successfully modified this to provide quotes with insurance? I've found a post that mentioned 3 places that must be modified, but nothing specific as to how it needs to be changed. All I need it to do is request insurance for the amount of the subtotal. I've already added an "enable insurance" field to the config, and a check whether or not it's true or false. Just no real idea where to go from here.
  23. Supertex

    ULTIMATE Seo Urls 5 - by FWR Media

    Any idea why I might find a cache file with the name: "1_index_manufacturers_id_243Fsort3D4actgacdCAEYACoUMTA1NTU3MTUyOTgyNzM1NDUyNzEyHDAwMjJhMzdjMmVhZTBhNzI6Y29tOmVuOlVTOkwusgAFQjCNF6xHLbJF9lRbY36cOH5hX1yctcOA.cache" I've seen similar strings reported when a site has been hacked, but I can't find any evidence pointing to that. Why would this even exist?
  24. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    Apologies. I caught the ascending -> descending change, but I missed the $sort_id change. However, I posted this inappropriately anyway; I should have started a new thread. The V4 intl rate V2 module failed to apply insurance on my international shipping, (as seen here) so I have the 'original' USPS module in place (Methods V7.3.1), and it doesn't have that line of code in it. I know that module has lots of problems, but it works for the 3 methods I offer, and the insurance works. I'd resigned to the fact that I was stuck with it until Jim's 'Codes' module is in release. My thoughts in posting here were that there might have been a way to order it in checkout_shipping. I know wouldn't be the 'right' fix, but it would make for a temporary workaround. I'll reinstall V4 intl rate V2 and see if I still have issues with insurance. Thanks for putting up with my nonsense.
  25. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    Thanks @a.forever. However, that would put Express Int'l on top in my case. Still, it would achieve my primary goal, which is to avoid the uninsured option being default...perhaps that would be enough. I have another question about how USPS (and other modules) handle address format alterations, but I think I need to put that in a different thread entirely.
×