Jump to content

mattsc

Members
  • Content count

    49
  • Joined

  • Last visited

Everything posted by mattsc

  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. 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.
  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. 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.
  9. 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.
  10. 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?
  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.
  16. 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
  17. Running a customesed OSC install of 2.3.4 BS, and I'm having a problem with PayPal transactions not being covered with Seller Protection. I'm using the Hosted Solution module in the PayPal App v4.039 so that I can accept both PayPal and Credit Cards. Trying to find a resolution to this, the Business Development agent assigned to my account has informed me with the following: "I reviewed your account and see you are unfortunately not getting seller protection on the PayPal orders as PayPal is hosted via the PayPal pro hosted iFrame. This is not caused by anything you are doing wrong, it’s an issue when PayPal is hosted via the iFrame." I did a grep through all of the source, and I'm not seeing any frames or frame tags. Perhaps I'm not understanding what the issue is however and that the PayPal 4.039 version of the app/plugin is using frames in a means I'm not seeing here. His recommended solution is that I switch over to Express Checkout. I've looked into this in the past, but when I did this the shipping module was being bypassed. My shipping calculations are rather complex as the business is based out of Thailand and I have 4 different shipping methods and ship world wide. I've attached a screenshot of my PayPal configuration pages for the Hosted Solution and Express Checkout tabs, as well as my checkout screen where it shows the PayPal app loaded and offering both checkout via PayPal, or a provided Credit Card. I am getting Seller Protection when I use the Payments Standard module, so this seems to be solely related to Hosted Solution. I don't know how to use PayPal Express which won't also bypass the shipping methods. I've been experiencing some fraud lately and this problem with Seller Protection not being covered is no longer acceptable. I have no idea what to do at this point to get Seller Protection, and switching to Standard only isn't a viable option either as I have too many customers who want to pay by credit card and don't want to (knowingly) use PayPal for their transaction. I'm not really sure what path to take to go forward and could really use some advise or help here!
  18. OK so, a bit of a *********** but I've got things mostly sorted out on the site now. Pro Hosted Solution will never be covered by Seller Protection. Don't ask me why, but that's their policy. So, I had them disable the PayPal account payment method in the hosted solution, and that now only has the hosted credit card payment method. I spun up "Payments Standard" to accept payment via a PayPal account, and that is (as expected) being covered by Seller Protection. The screwy thing being, we can still accept a credit card payment via that payment method even if the person doesn't have a PayPal account, but PP doesn't seem to recognize a distinction there... Plus, paying via that method is a PITA and tends to end up with the funds locked up in escrow for a few weeks. Bleagh! It seems that you can also not have Pro Hosted enabled and Direct Payment both enabled at the same time. Also, Direct Payment then gives the site direct access to the customers credit card information, and pushes all of the PCI compliance onto us, and is ALSO not covered by Seller Protection. So, Pro Hosted it is, and we just have to manage our fraud settings and fraud exposure level ourselves. That ******* sucks, and totally baffles me, as it SEEMS like the payment processor and the credit card agency would have fraud prevention services there. There are 3D Secure settings, but that seems to be about as much control as we have over potential fraud, and our exposure is 100%... so a lot that the 3% payment processing charge gets us there! {rolls eyes} I also understand how and why the hosted connection is done inside of an iFrame. This is so we never have access to the credit card information as it's all encapsulated in the iFrame... and it just hands us the result code of the transaction. Makes perfect sense after I thought about it a bit. So, at least the PayPal account checkout flow is covered by Seller Protection. Thinking I might try to wrap some sort of "PayPal Buyer Protected" language around the PayPal checkout path to try and direct people over to it, but that's a business decision above my paygrade. :) LOL
  19. Howdy John, The marketing / business development droid I've been having to deal with at PayPal has finally put me in touch with one of their Merchant Integrations team members. His initial suggestion was to enable "Payments Standard" which I've done, so checkouts via that method will indeed be covered by Seller Protection now. They just made a change on the backend for our PayPal account, such that the PayPal account info is no longer showing inside of the iFrame. The frame that PayPal returns now only offers the credit card payment method. So on the payment elections page I now can have a paypal payment election, and a separate credit card payment election. Previously, the Hosted Solution payment method returned both, which was confusing customers... which is why we initially moved away from Payment Standard, not aware that doing so meant that even payments made through a PayPal account were STILL not being covered by Seller Protection. The change to Hosted Solution not showing in the paypal account method any more should resolve this finally. Any means of payment not contained inside of an iFrame, would mean that we would have access to the credit card info. That would push a much higher level of PCI compliance onto us, which isn't desired. There is also the "Direct Payment" module for the PayPal v4.039, but installing and configuring it, doesn't seem to have any impact. No additional payment election is showing on the checkout payment page, and I'm not seeing any errors in any of the log files, so I'm confused as to what it's doing. As to Express, when I enabled this early on in our implementation testing, we were getting a checkout button in the cart, and it jumped straight from the Cart to the Order Confirmation page, bypassing the payment method elections (makes sense) but also bypassed our Shipping Method election page, and allowed checkout without having elected (or had added to your payment) the charges for shipping. Could be we have something misconfiguration here, but for whatever reason, we were not getting Shipping Method election.
  20. Digging through the HTML, it turns out that the site is getting an iframe from PayPal in the Hosted Solution checkout app. I'm guessing this is coming in from the sourced javascript and is why I wasn't seeing it when I searched through all of my OSC sourcecode. So, looks like I can't tell PayPal to disable iframe support for my account. I don't know if updating to the PayPal 5.018 app would be safe with my 2.3.4BS install and would be the way to go with trying to get Seller Protection enabled, while still forcing customers through the shipping method selection so that shipping charged wouldn't be bypassed by Express Checkout in the cart. This is so frustrating! :(
  21. mattsc

    SPPC - for 2.3.4

    Mostly. I still don't know what to ake of the _cg_1 and _cg_2 tables. The products_groups table is straight forward enough... I just can't quite figure out the interaction(s) with the other two tables of pricing mystery. :)
  22. mattsc

    SPPC - for 2.3.4

    I'm running the greasemonkey version of SPPC with the BOOTSTRAP - SPPC 2.3.4 BS GOLD - v1.1b release. I'm doing a bulk price update of 5% across the board. For updating my pricing for my standard retail price, this is easy... just a quick db query of: update products set products_price=products_price * 1.05 However, for updating my pricing for all my customer groups (I have 6) I'm a little bewildered as to what to update! I have three tables here: products_group_prices_cg_1 products_group_prices_cg_2 products_groups All of them SEEM to have pricing info in them. I have no idea what needs to be updated tho. I'm unsure if the cg_ tables are still in use, to be honest. It might just be a holdover from prior work... but I have to say after grepping through the code I am still seeing references to the cg tables. The products_groups table SEEMS like it's the table I need to update: select * from products_groups order by products_id limit 12; +--------------------+-----------------------+-------------+ | customers_group_id | customers_group_price | products_id | +--------------------+-----------------------+-------------+ | 1 | 2058.0000 | 39 | | 2 | 1958.0000 | 39 | | 3 | 1858.0000 | 39 | | 4 | 1850.0000 | 39 | | 5 | 1900.0000 | 39 | | 6 | 1921.0000 | 39 | | 1 | 1675.5000 | 40 | | 2 | 2000.5000 | 40 | | 3 | 1950.5000 | 40 | | 4 | 1900.5000 | 40 | | 5 | 1850.5000 | 40 | | 6 | 1564.0000 | 40 | I THINK I would just need to do a similar update of products_groups of: update products_groups set customers_group_price = customers_group_price * 1.05; but, I'm TOTALLY not clear on what to make of, or what to do with, those mystifying products_group_prices_cg_1 and products_group_prices_cg_2 tables???
  23. mattsc

    New UPS XML Shipping Module available

    @@kymation: To answer your first question, yes I patched the admin/modules.php. I don't have the compatibility addon installed. Not sure what that is. I'm running Gold not Edge, so that may be related to that. From what I can tell at this point with further debugging, which is basically me stepping through the whole chain of function calls, I seem to be having a problem with the XML Class. The call into XML_unserialize is returning an empty array (verified with print_r and var_dump). Debugging into the xml.php in the XML_unserialize function, the call into $xml_parser->parse($xml) returns empty. The problem from what I can tell is coming up here: function parse($data){ $this->document = array(); $this->stack = array(); $this->parent = $this->document; return xml_parse($this->parser, $data, true) ? $this->document : NULL; } The function is fed in good XML which is what I've gotten back from UPS. This data is the XML stream received from the call to UPS, or by using the dummy xml test file, both call into _parseResult($xmlResult), which then calls XML_unserialize, and that's where the wheels come off. $xmlResult is valid, but XML_unserialize returns with the empty array. I did strip the & reference chars from the class due to the fatal "Call-time pass-by-reference has been removed" errors. Maybe I stripped one too many. Ah HAAAAA! Looks like that was the issue. I got over eager on my nuking of & characters. I'm getting quotes back now, finally! I've got a currency conversion issue to deal with, but THAT I can sort out.
  24. mattsc

    New UPS XML Shipping Module available

    Anyone??? This remaining issue is the final part of taking my store live. I'm getting valid XML back with a number of shipping quotes. The selections just aren't making it to the UI. I'm totally at a loss as to how to further figure out what's wrong. I've poured through the code and am apparently just being daft or something.
  25. mattsc

    New UPS XML Shipping Module available

    I have the 1.5.1 version installed, and it's pulling up correct rates in the return XML which I can see in the log file. I'm not getting rates / options to select to show up on the checkout_shipping.php page however. By all accounts it looks like the module is running and working, just not showing up as a selection for the shipping method selection. I'm running v2.3.4BS GOLD so I'm not certain if that would have anything to do with it or not... but I've been racking my brain on this one for a few days and have to admit I'm somewhat baffled as to why it's not working completely to the UI. OB debugging checks: Yes, the module is enabled, thus the correctly formatted XML query in the log Yes, all my ups creds are correct, thus the correctly formatted XML response in the log Yes, the shipping method option sort and display options are enabled (from a SPPC interaction) My other two shipping methods are showing up and working correctly, it's just the UPSXML shipping module results which aren't showing up (see attached screenshot) I've tried using the example_response.xml file also, just to see if there might be something with the returned XML that's causing my problems, no joy there either. Still not getting a result to the user selection in checkout_shipping.php Any insights into how to further debug or what could possibly be wrong here as to why I'm getting good rates back but it's not making it to the checkout_shipping.php selections would be greatly appreciated!
×