Jump to content


  • Content count

  • Joined

  • Last visited

Profile Information

  • Real Name
    Matt Schreiner

Recent Profile Visitors

2,035 profile views
  1. I tried adding <script type="text/javascript"> window.onload = function() { window.print(); } </script> to the document head, but it's not working.
  2. I searched around and didn't see an answer to the question of how to get the packing slip to automatically pull up the print dialog when the page opens. I realize this isn't an OSC specific issue, and I tried to figure this out on my own, but couldn't figure out how to make it happen... Basically, when I click on the Orders "Packing Slip" button, and the page loads, I want to automatically have the system print dialog open so i can just hit Print. I know it's a bit trivial as it's just a few keystorkes of mouse clicks to make happen, but it would be a time saver that irritates me every time I have to do it. what do I need to add to packingslip.php to make the page open the system print dialog for me?
  3. Unfortunately I don't have access to the paypal account or logs. He reports he rarely (1 or 2 a month) would see a transaction not send the Order Process email with the PayPal Pro HS module. I recently enabled the PayPal Standard module for him, but I've been using it on my site for the last year and have never noticed a transaction not post the Order Process emails. They have duplicate code and the only difference in the stores is the catalog SKUs, and I have a different shipping module (a UPS mod) where as their store is all zones based to calculate shipping costs. I'm going to take an hour and see if I can manage to get the PayPal app migrated on my store, and if that works then I'll migrate the other two sites. wish me luck!
  4. My post might have been confusing. I was trying to provide as much info for the transactions which didn't have a problem vs the ones that do. That's why you are seeing the two different IPNs. In both orders, the results came back with "VERIFIED" to the was all. The double IPN records are exactly the same. The ext/modules/payment/standard_ipn.php script is OK. I've verified that with PayPal as well with making sure their callback was successful. The scripts are OK as well because MOST of the time, I don't get the duplicate IPN 10-15 seconds later. The only correlation I've found between the orders that have a problem and those that go through correctly is when there is this duplicated record. Earlier I had an issue where if the order totals differed, I also had the problem (see Not getting Order Process mail if Total Mismatch of $0.01) but I've since put in a variance check so when that issue is encountered, those orders are succeeding now. So I've just been working through one issue after another here. I considered adding to the prior post, but this seemed like it was different enough to justify a separate thread. I am getting multiple IPN from PayPal, but I don't know why. I would think that would be caused by something on the host failing but the PayPal integration tech guy tells me they are getting a success 200 reply so I'm a bit at a loss to explain why they are making the second attempt. I have other instances where the success happens at different times, so it's not always that _notify-sync and _notify-validate [IPN] occur at the same time or at different times... so that's not it either. No I -=AM=- getting Order Process email notifications for MOST of the PayPal Standard transactions. Just not all. I'm unsure at this point how to even attempt to debug this further as I'm not seeing any semblance of a pattern. Maybe I need to tell my client I need to take the website offline so I can update the PayPal module. They won't be happy about that in the least, but if that's really down to my last option to try and fix this then maybe that's what will need to be done. I am seeing a note in there about 2.3.4 BS compatibility. The timestamp is right around the time when I was doing the coding for the site, so maybe those changes not being there was why my attempt at updating failed the last time I tried to update the PayPal app code. That "lot of change" is what is making me nervous tho. I'm not sure how much effort or time it'll take to update the PayPal app, or how much time it'll take to "sort out any issues" once the changes and complete. I'll just have to present it as an option to them and let them make the call as to if it's a big enough of a deal to them or not.
  5. I would expect a setting on the paypal account would cause ALL orders to fail if something were set wrong... and with duplicate entries a I would think it would have to be something on the server, tho what, I do not know. There doesn't seem to be ANY commonality between the orders that "fail" with 3 IPN records and thus emails not being sent and inventory not being updated, and the ones that "succeed" with only getting the 2 records in the log. I have not updated the PayPal app. I don't remember what the problem was that I ran into when I tried to do it, as it was a while ago (about a year) when I attempted updating the PayPal app portion of OSC. Part of my problem is I no longer have an good means of creating an exact copy of the site in a development environment. So, any changes are made on a live system. I know, it's horrible, but it is what it is... so I'm VERY careful about the changes made, and considering more than half of all sales go through PayPal, I'm VERY pensive about making another go at doing the update.
  6. Running on 2.3.4BS PayPal App v4.039 here and I'm running into a problem with the PayPal Standard IPN module. For whatever reason I can not determine, occasionally I'm getting 3 messages logged to an order. Whenever I only get 2 updates, everything works as expected. All the emails are sent, stock is deducted from inventory, all is good. When I get 3 messages logged to the order from PayPal things go downhill. None of the emails are generated and stock isn't removed from inventory. I'm at a loss as to what the cause of the 3 messages being logged is, or why some of the PayPal Standard IPN orders only get "_notify-validate [IPN]" entries logged. Here is an example of where I get the problematic 3 entries in the order status, 12 seconds apart: Verses a "normal" transaction where I only get 2 log entries from PayPal which are all being processed 1 second apart: I'm not seeing anything weird in the PayPal log content wise other than it showing either the 2 or 3 entries in the log: The response code every time however is successful with a "VERIFIED" reply: and the duplicate _notify-validate [IPN] entries being exactly identical and also "VERIFIED" as the reply: I tried asking a PayPal integration engineer to look at their logs to see if there was anything odd, and he said there was not. His only thought was "maybe your system is timing out" but if it is, I'm unsure what I could change other than possible the php.ini default_socket_timeout value, which is current set to 60 seconds. I'm just running into one problem after another after another with the PayPal Standard IPN module here and can't figure out why it's working fine most of the time, but occasionally I get these three logged IPN entries, and the order somehow isn't completing with Order Process emails not going out and the stock not being updated. I am TOTALLY stumped here and have no idea where else to look. I've eat, slept, breathed, and died in the /include/modules/payment/paypal_standard.php, /order_process.php, and /ext/modules/payment/paypal/standard_ipn.php files.
  7. mattsc

    Bundled products

    Running into an issue where the weight of a bundled product sku is using the sum of the individual components for the weight. This is resulting in a weight which is too high and is messing with the shipping module calculations. Looking through the code tho, I don't see where I might be able to use an override for the bundled product given weight. Example product 1234 has three bundled products of X, Y and Z. The weights for each is given as say 10lbs each. In fact, the bundled products all combined are say 24lbs. In the products record there is a given weight of 24lbs, but this is being ignored, and it's taking the XYZ weights and adding them all up for the total 30#... The result is that the shipping calculation is then trying to use too heavy of a weight so the shipping calculation is off. My expectation is that given the bundle has a specified weight, it should be using that instead of adding everything in the bundle up. The only area in the code I think this might be coming from is in the shopping_cart.php class, where in the calculate() function, in the main while loop there is this on line 417: $this->weight += ($qty * $products_weight); where, what I would LIKE for it to do instead would be in the product is a bundle, to not sum up ever product weight for the bundle, but just use the specified weight. I'm not seeing anything anywhere else that looks like it might be causing what we are seeing in the shipping module for the shipments total weight of the cart.
  8. So far, the change is working flawlessly. I'm going to rewrite it somewhat to use a variable which can be set in the admin panel for how wide of a +- margin to allow. I'm still not sure why when I was testing for a variance of $0.02 it was occasionally still failing. All of the mismatch amounts seem to only be off by a rounding error of $0.01, so the $0.02 window SHOULD have worked. I'm going to at the very lease narrow it down to testing for only a $0.05 variance... but seems like this change resolves the problem.
  9. My uber ugly hack just to test if I'm in the IF loop at all or OSC Error is coming from somewhere else outside of paypal_standard.php looks like this now, to try and get it to be similar to paypal_pro_hs.php $invoice_amount = $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']); if ( $pptx_params['mc_gross'] != $invoice_amount ) { if ( ($pptx_params['mc_gross'] >= $invoice_amount - .50) && ($pptx_params['mc_gross'] <= $invoice_amount + .50) ) { $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' . $invoice_amount . ') but is within 0.50 of expected total, so still approving order to completed order status'; } else { $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' . $invoice_amount . ') and is NOT within acceptable +- acceptable total difference.'; } } I know, I know... It's ugly!!! Adding the "and is NOT" bit there, is to at least verify if the log says totals mismatch, and I don't see that text, then somehow I'm getting it someplace else... not that I can FIND where, but after I made the last change to the $0.50 I still had one kick out which made me doubt my IF block logic.
  10. Phil: I am getting a rounding error yes, and it's only showing as $0.01 in the emitted text, but I'm also dealing with 8 different currencies so I'm playing it safe for now with increasing it to $0.50 just as a method of testing to see if I'm having problems with that IF block, or if the OSC Error is coming from somewhere else that I can't find. We hand PayPal an amount with the total is all, and calculate shipping ourselves. No tax, as the company and factory are both offshore and product ships from overseas... Nobody is stressing out about the order being off by $0.01. That's not a big deal. What's a PROBLEM is the factory relies on the email to start the orders, and the packers and shippers then get the packing slips from the gals in the office who use email as the trigger to start an order and verify inventory levels and order replacement inventory or start production on parts based on sales. Believe me, it is NOT ideal, but it's how they work... I can't dictate workflow. I'm just the bits pusher here. ;) John: The response is coming back as VERIFIED for these rounding error transactions. Every time. Response VERIFIED So... that's not it. Like I said, I used to have this also happening with the Pro Hosted Solution code. I changed the OSC Error to OSC Warning in my test for the rounding error, and the problem stopped. Leaving it as an OSC Error, and for whatever reason, the email Order Process messages never go off inside of checkout_process.php. Because it's not making it into the before_process function, I'm thinking it ALSO means that inventory isn't being deducted when that happens. Plus the Low Stock emails don't get sent to the gals in the office. So, this is a bit of a big deal with trying to get fixed. I guess I don't even really CARE as to why having that OSC Error text in there is causing it to not function so much as just trying to make sure that the change to OSC Warning actually occurs inside of the IF block and the rounding error is successfully ignored. It's also not like this IF block in paypal_standard.php is all that different from paypal_pro_hs.php. So while my solution wasn't a direct copy/paste, it ain't THAT different! My solution of changing the "OSC Error" to "OSC Warning" seems to be working, so long as it's not -=SOMEHOW=- getting that text block from somewhere else in the code. I failed to restart the webserver after my changes so I thought maybe, somehow, one of the apache worker threads was using a cached version of the old PHP... I dunno. I'm sorta grasping at straws here. Waiting for another transaction to come through with the rounding error is the painful process for me here as I can't force it to happen. The cached thread is a stretch, I know! I can't figure out how the order manged to use the old code however as it came in 30 minutes after I'd made the change. I haven't had any orders come in with the rounding error since the apache service restart however. The office never told me that they were "sometimes not getting the emails" before, so I suspect the same issue has been happening a while now, but now that I DO know about it, I have to fix it.
  11. Well dammit!!! The very next transaction came through and had another rounding error which kicked it outside of my range of accepted payments. So, I widened up the criteria to be +- $0.50 and will see if that does it. This module confused the ever living ******** out of me! {sigh}
  12. I made the change, and while I can't explain WHY it works, it did. I very luckily had an order come in about 20 minutes after my change, and the Order Process email DID go out successfully, and had my change showing in the result: I REALLY don't understand why changing the "OSCOM Error" test to "OSCOM Warning" makes a difference, but for whatever reason it did. The payment modules are a bit perplexing to me with how they actually work. The rest of the OSC codebase largely make sense (or OK, can understand it about as well as any other huge open source project) with how it all works... I completely agree that the change doesn't make any sense. I've dug around through: /ext/modules/payment/paypal /includes/modules/payment/paypal_pro_hs.php /includes/modules/payment/paypal_standard.php /includes/classes/payment.php /checkout_process.php as well as general greping my way through the whole codebase... to no avail! I do have to make a status change in the paypal_pro_hs.php as you recommend: // BOF Bug: 143 - approve orders even if amounts only slightly differ $invoice_amount = $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']); if ($tx_payment_status == 'Completed') { if ($tx_amount == $invoice_amount) { $new_order_status = (OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID > 0 ? OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID : $new_order_status); } elseif ( ($tx_amount >= ($invoice_amount - 0.02)) && ($tx_amount <= ($invoice_amount + 0.02)) ) { $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' . tep_output_string_protected($tx_amount) . ') does not match order value (' . $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ') but is within 0.02 of expected total, so still approving order to completed order status.'; $new_order_status = (OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID > 0 ? OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID : $new_order_status); } else { $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' . tep_output_string_protected($tx_amount) . ') does not match order value (' . $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')'; } } // EOF Bug: 143 - approve orders even if amounts only slightly differ where I am setting $new_order_status to be the same as if the amounts are equal, but there's nothing like that in the paypal_standard.php module. Becasuse the verifyTransaction function is a void with no return, I'm mystified how it's working at all!!! Clearly something -=IS=- working, I lliterally just don't grok ******* how! I admit, it's a fugly fix, and I hang my head in shame as a dev! I've spent months of my life in the OSC codebase, and have practically committed to memory how it all works, but the PayPal methods are beyond my grasp at understanding. :(
  13. mattsc

    Bundled Products

    Well, I've got a little bit more information now. It seems that they ARE receiving SOME of the Order Confirmation emails. It looks like the ones they aren't receiving are when the order comes in via PayPal Standard and there is an order mismatch of $0.01, so this may not be related to the Bundled Products mod after all. I started a thread on that specific issue here: I'm still not sure if that's the reason why they aren't receiving all of the Order Process emails, but that's my best guess as to why currently... I'm not seeing any other difference between orders that come in and the Order Process message does go out, and the ones where it doesn't.
  14. With the PayPal Standard payment processing, if I get an Order Total mismatch of 0.01 I'm not getting the Order Process email notice. I'd like to disregard this error condition if the order total is within 0.02, and still get the Order Process email notice. With reading through the code tho, I can't see why this mismatch isn't allowing the emails to go out. This appears to be the only difference between orders where I receive an order process message, and those which I do not. I've made the following code changes, but because these Order Total mismatch differences happen so infrequently, I'm not sure if my change will work or not. Here's what I changed in paypal_standard.php: Before: if ( $pptx_params['mc_gross'] != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) ) { $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . ' ) does not match order value (' . $this->_app-formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')'; } After: if ( $pptx_params['mc_gross'] != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) ) { if ( ($pptx_params['mc_gross'] >= $total['value'] - .02) && ($pptx_params['mc_gross'] <= $total['value'] + .02) ) { $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' . $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ') but is within 0.02 of expected total, so still approving order to completed order status'; } else { $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' . $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')'; } } I made a similar change to the paypal_pro_hs.php code a LONG time ago, but don't remember if I made any other changes to get the Order Process messages to send. I can't seem to find anything anywhere that would otherwise prevent the email to go out however. Does this change look reasonable, or am I missing something else I would need to modify to get the messages to send on payment completion?
  15. mattsc

    Bundled Products

    I'm running 2.3.4BS here, and I'm trying to figure out something with how Bundles and the PayPal payment methods interact, in particular the function reduce_bundle_stock which is added into checkout_process.php The reduce_bundle_stock function declaration, as I understand it, would be needed in the PayPal payment methods as well, I would think. Wouldn't it make more sense to add this function into the include/functions/general.php location? Or is there some inheritance I'm not seeing here where the function declaration (and code) is somehow accessible in the other checkout methods and so I don't need to move it into general.php to still be successfully called in the paypal payment? I know there's some interesting ways that the alternate payment methods interact with checkout_process.php but this one has me confused. The concern I have is if I add the new reduce_bundle_stock function into each payment method, wouldn't I then get get a function conflict between checkout_process.php and the two paypal_standard.php and paypal_pro_hs.php payment methods? I tried putting the function into general.php as a a new function called tep_reduce_bundle_stock, and modified the function to call the function by this new name. With this change however, my customer is saying they are no longer receiving the confirmation email, but the orders table is being successfully updated by PayPal when the checkout process completes. I know that general.php is being loaded as there are other tep_* functions in paypal_standard.php which are successfully being called. I can't see why my change of moving the reduce_bundle_stock function from checkout_process.php into general.php would cause the confirmation emails to not go out tho. Checkout via standard methods are working and the bundle stock is being reduced in inventory correctly with the function moved to general.php, but for some reason things aren't working correctly when paypal_standard.php checkout method is being used. I'm a bit at a loss as to why the order process email isn't going out. I've attached the relevant changed files here, in case anyone might be able to see if I'm doing something stupid and just need another set of eyes on it to tell me where things are going off the rails. There is also a function added for LowStockCheck, where if inventory falls below a threshold, then an email goes out to alert that inventory may need to be re-ordered. Unfortunately I'm working with a live system that I'm modifying, so I can't really experiment TOO much here. I've not found a way to (at least without great efforts) replicate the entire store locally for debugging and testing which would FAR rather be my preference, so I have to just make a best effort to making sure I don't knock the store offline or do anything that would confuse customers and/or block checkout. general.php.new paypal_standard.php.new checkout_process.php.new