Hi guys,
got some strange behaviour with the stocks. I recently started using that module and when I come into the orders details it states that it first decreased the stock, than comes the payment by paypal and than the stock is decreased again. I'm wondering how to stop this doppel decreasing.
thx!
Stock is decreased 2 times - once the customer buys - once the customer pays via paypal
Submitted by snicers on Tue, 06/17/2008 - 10:43
|
|
I can't remember where, but we've solved this issue before. I think the end solution was to adjust the default workflow configuration to add a condition so that it only decremented stock for PayPal orders if the balance was less than or equal to $0.
Hey -
So I'm battling with this in the latest 1.3 release. Using PayPal WPS and the stock keeps getting decremented twice, even though I added a condition to only fire the action if the payment method is PayPal WPS and the order balance is less than or equal to 0. Pretty significant show stopper on my end, keeping the site from launching. Any help would be appreciated!
I found the base cause of the problem on this one. The order is getting complete in 2 places: once when IPN fires, and again when a user is taken back to the merchant site, hitting this page, /cart/checkout/complete. So uc_cart_complete_sale() is getting called twice: once in the IPN processing and once on that landing page.
What's the correct solution here?
Unfortunately... the best solution is for me to break that function up into a few different functions and change the checkout logic. That's one of my least favorite functions in Ubercart. 
What if you added another condition to the stock decreasing configuration that checked the order status? The status should change between the first and second times that function gets called, so maybe you could prevent the second one with that...
Sorry it's such a pain.
Thanks for getting back about this. I've tried setting several conditions, and for some reason they are not catching. I've tried:
- only fire if order status is complete or order status is payment_complete
- only fire if order balance is not equal to 0
Aside from the inventor issue, are there any other drawbacks when uc_cart_complete_sale() gets fired twice? Seems like there's a lot of duplicate logic happening. As a simple patch, what about adding a condition inside of uc_cart_checkout_complete(), checking for order status? E.g.,
function uc_cart_checkout_complete() {
if (!$_SESSION['do_complete']) {
drupal_goto('cart');
}
$order = uc_order_load(intval($_SESSION['cart_order']));
if (empty($order)) {
// Display messages to customers and the administrator if the order was lost.
drupal_set_message(t("We're sorry. An error occurred while processing your order that prevents us from completing it at this time. Please contact us and we will resolve the issue as soon as possible."), 'error');
watchdog('uc_cart', t('An empty order made it to checkout! Cart order ID: @cart_order', array('@cart_order' => $_SESSION['cart_order'])), WATCHDOG_ERROR);
drupal_goto('cart');
}
// this is the new condition
if($order->status != 'complete' || $order->status != 'payment complete'){
$output = uc_cart_complete_sale($order, variable_get('uc_new_customer_login', FALSE));
}
// Add a comment to let sales team know this came in through the site.
uc_order_comment_save($order->order_id, 0, t('Order created through website.'), 'admin');
$page = variable_get('uc_cart_checkout_complete_page', '');
if (!empty($page)) {
drupal_goto(variable_get('uc_cart_checkout_complete_page', ''));
}
return $output;
}Well, I can't really change that function at this stage in the game because of how much code that would affect. All the separate bits of logic in there really just need to be broken out into their own functions instead of glued together into one monster function. Here's a thought... perhaps you can add a custom PHP condition to the configuration that checks the current URL using like so:
<?php
if (arg(2) == 'complete') {
return FALSE;
}
?>Not sure if you can do that off the top of my head, but if you added this along w/ the conditions for payment method and balance, that might prevent the duplicate stock decrease when the customer browses back...
Or... duh. Disable that configuration altogether and make a new one w/ a different event... like when a payment gets entered and the balance is <= $0.00. That would probably be even better.
Good suggestion, but still no luck. I reset the default stock configuration so it SHOULD be inactive. I then crated my own as you suggeted, firing on the payment entered event when the order balance is <=0. I added the stock decrement action, in addition to my own little custom action to adjust the value of a CCK field I'm using.
The result is that as soon as IPN fires, the stock gets decremented TWICE, and then when I hit the thankyou page, it does it a THIRD time. I'm assuming this is because uc_cart_complete_sale() fires the "checkout_complete" workflow event, which uc_stock_configuration() hooks into. But this seems like a major bug, as it should be disabled. This is all very muddled ... and I'm still at a bit of loss.
I attached a few files to illustrate: 1) log of what's happening to the order, 2) workflow configuration, 3) custom stock configuration.
Any ideas what other PayPal users are doing?
| Attachment | Size |
|---|---|
| order-comments.jpg | 34.25 KB |
| workflow-stock.jpg | 32.75 KB |
| workflow-config.jpg | 50.19 KB |
Mostly FYI ...
I ended up disabling the UC stock system and just rolled my own using a custom CCK field and workflow.
Awesome... probably works just as good if not better. 
Awesome... probably works just as good if not better.
Unfortunately for us, it does not... I have been getting this bug report from my client for months now, and have been working on other issues. They have been 'living' with it because of the relatively livable # of orders/products to manually update.
I have tried all the things in this article, save for the CCK/Workflow method. All the products in this particular store have a huge number of attributes, and thus, I don't see how a CCK-based solution would be scaleable and manageable.
Stock and inventory management seems like a pretty important aspect to e-commerce, especially when dealing with tangible goods.
I would like to know if there has been any further progress on fixing this issue from the core team (or uc_stock maintainer).
I'm willing to be a guinea pig in this case and test some things, but I don't have the time to devote to debugging this particular issue.
Any thoughts?
Replying to my own reply because it's fun...
It looks like this issue only occurs for a new user purchasing anonymously.
i have a drupal 5.10 ubercart 1.4 site using paypal in sandbox.
i get double stock decrements more details here: http://drupal.org/node/312507#comment-1027043
this happens with reg'd users
[later]
my solution is as follows: disable the original workflow rule, but add an action to either email or add a watchdog entry, to be sure I know if it fires.
then create a new workflow rule as follows:
Invoked on Event: A payment gets entered for an order
Condition: Order balance <=0 (this was to prevent a partial payment from triggering this)
Action: Decrement stock
I've just tested this and it works, it only decrements stock once.
Good call. I think the reason we didn't do this in core was to avoid an unnecessary dependency on the payment module. I like your thinking. 
I was having the same issue, so I went to follow your instructions.
When I went into workflow-ng's rule configurations page, I noticed "Decrement stock upon order submission" was already listed as inactive. (see ss1.jpg)
So I went to see if it was really inactive, and sure enough "This rule is active and should be evaluated when the associated event occurs." was checked. (see ss2.jpg)
So then I unchecked it. It stayed under Inactive. I then rechecked it, and it moved under the Active area.
If you then click reset, it will go back under Inactive but its still check as "active"
On a stock Ubercart 1.4 installation, I noticed the behavior works as expected. The only difference on my site is I upgraded Workflow-ng from 1.x to 2.1.
-- Jason
| Attachment | Size |
|---|---|
| ss2.jpg | 24.87 KB |
| ss1.jpg | 56.43 KB |
yes i had the same problem but with uber 1.3 and workflow 5.x-1.6. i didn't resolve it
im having the same issue on a live site
adding conditions to "Decrement stock upon order submission" or creating a new rule hasnt fixed the issue and also screws with my other payment methods
is there anyway to add stock after a paypal order has processed
what is causing this? is it an issue for everyone using paypal?
|
|
Joined: 09/20/2007