Jump to content

mattsc

Members
  • Content count

    49
  • Joined

  • Last visited

Profile Information

  • Real Name
    Matt Schreiner

Recent Profile Visitors

1,632 profile views
  1. I've verified the fix works for me. I have verified verified as working when an "other than default" currency is used: Expected discount to be applied: - Product discount with % - Product discount with set amount - Category discount with % - Order Sub-Total with % - Order Sub-Total with set amount As well as the Null conditions of where no discount should be applied: - Discount code which is expired - Discount code which does not apply to Order Total - Discount code for Category which does not apply to cart contents I basically dropped the proposed 4.4.1 variant over my 4.1.0 version, and all seems to be working well. It's not exactly a rigorous set of tests, but a diff between the versions looked like it would have been safe to drop over in place, and seems to be good. I say push the change.
  2. OK, more details! I was able to experiment some, and have determined it's only happening in the following situation: 1) Other than default currency 2) Only for a specific SKU / Product(s) The discount % is working fine in the default currency, which in this case is Thai Baht. The problem is when the customer has used an other than default currency, such as USD or Euro, as demonstrated below. The discount amounts in the screenshots in Thai Baht are the correct amount, which is setup for the SKU for part number BPCF-5102. The Baht price is ฿3,876. The 25% coupon works and is calculating a discount of ฿969. All is working fine. Then, change the currency to USD. The USD price is $121.50. The coupon is calculating a discount of $0.95. Wrong answer. It SHOULD be coming up with a discount of $30.38. I'm not sure how it's coming up with $0.95, but that's clearly not 25% of $121.50. It's not limited to just USD, as it's coming up with the wrong answer for the additional "other than default" currency. Here we can see it's getting the wrong answer for EURO as well: ...where a €106.36EURO part price is getting a -€0.73EURO discounted amount, so it's seems to only be working correctly for the default currency. The stores default currency is in Thai Baht / THB with a value of 1.00. The USD currency exchange rate is 0.03134758. So it's specific to an Other than Default currency, and only when the discount is limited to a specific product. The discount is being applied to a specific product vs an order sub-total: Doesn't work: Works, but isn't limited to a specific product(s) vs using Order Sub-Total: Which is showing the correctly calculated currency discount amount:
  3. Running into an issue with currencies where the discount percentage is only working correctly if applied to the default currency. One of my stores default currency is in Thai Baht, but when customers try and use the code in their local currency (JPN, EU, USD, etc) then the discount isn't calculating correctly. "Discount Codes 4.1 BS" is the code that's currently being used on the store, but all the changes between there and the current "4.4.0 BS" drop doesn't seem to have addressed anything currency related, mostly tax based changes it looks like. Seems to be related to % discount codes, as that's the only reproducible case that the store has been able to find a consistent reproducible case for thus far.
  4. Thanks DAVID3733, I had the same issue as my base currency is Thai Baht, so this fix ^^^ worked for me. I actually just created an additional quote function which I called quote_exapi_currency, and then changed the primary currency converter service in application top and the auto-update currencies to use the exapi function. function quote_exapi_currency($to, $from = DEFAULT_CURRENCY) { if ($to == $from) return 1; $ch = curl_init('https://api.exchangeratesapi.io/latest?&base=' . $from . '&symbols=' . $to); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $data = curl_exec($ch); curl_close($ch); $currencies = json_decode($data, true); if (isset($currencies['rates'][$to])) { return $currencies['rates'][$to]; } else { return false; } } My currencies are updating again. Wo0t!
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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}
  14. 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. :(
  15. 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.
×