I reported this problem also, right before the big crash. CpILL said he was too busy to look at it then... maybe he's had time by now? Sure hope so, since my client sells one of a kind items!

The purpose of this post is twofold.

First, it's a shameless bump (this issue is the only thing standing in my way of deploying an new web project that would primarily sell "one-of" items).

Second, and most importantly, I am looking for guidance on how hook_order is supposed to work with modules like uc_inventory_api.module.

Specifically, I assume function uc_inventory_api_order (line 246 of uc_inventory_api.module) is supposed to get called when function uc_cart_checkout_review_form_submit (line 1345 of uc_cart.module) is executed.

However, my testing leads me to believe that function uc_inventory_api_order is never actually getting called.

How is function uc_inventory_api_order supposed to get called by uc_cart.module?

Well, I just finished testing the uc_simpleinventory module, and it does not decrease stock in the uc_simpleinventory table upon ordering.

Looking through the module, I believe I understand how it's supposed to work (just like I think I understand how the Inventory API module is supposed to work).

Again, it appears that the function uc_simpleinventory_order is not getting called by hook_order when the cart is finally submitted. But I can't figure out why.

I assume you use simpleinventory for http://www.vingowine.com ???

Whew! I thought I was goin' crazy...

BTW, nice wine site. But I assume we are in the same boat...that sometimes you only have a few bottles (maybe even just one) of a particular vintage available.

Does anybody have a functioning inventory control system working with Ãœbercart?

Let me take my words back

I was looking at a different repo.

So here is the problem and also iam attaching the module. Works on PHP5 and drupal with latest ubercart.

Probably there was an update on the hook and we never took care of it. Its a simple change. Anyway iam reattaching the module

Removed some stupid Stuff..

Well, PHP5 doesn't seem to make any difference.

Which version of Ãœbercart are you using with your updated uc_simpleinventory? And (perhaps a stupid question) I assume you have verified that your stock levels are actually decreasing in the uc_simpleinventory table when ordering? I assume the decrease is supposed to occur when you click the last "submit" button...right before being taken to PayPal?

P.S. I'm currently trying the bazaar version of Ãœbercart.

Yes, I've done both actually.

I have tried completing the order all the way through PayPal until I am taken back to my site, and then "shipped the item", and then even run cron.

I have also tried just "submitting" the order, and then checked inventory in the uc_simpleinventory table after the first PayPal page loads up. (As far as I can tell by looking at the source, this should be sufficient to decrease the inventory.)

Perhaps I should revert back from the bazaar version to the 5.x-1.0-alpha7b version?

Perhaps I should restart with a fresh Drupal install with PHP5 as default?

Can you tell me which version of Drupal and Ãœbercart you have working with your most recent version of uc_simpleinventory? And I assume you have tested an order submission and your stock level actually decreased upon submitting the order? I can then set mine up just like yours.

No rush, my friend. With the long weekend ahead, I might just do a fresh install on a test server and play around with hook_order et al to see what makes it tick.

Thank you, Ryan, for the information. It was helpful. I think I understand the problem much better now. I hope to have some time over the long weekend to try a few hacks to see what might work for PayPal. My intention will be to play around with other payment methods, too, to see if I can come up with a blanket approach.

Idea (?): After an order is finished, the cart is emptied at some point. I mean, if the customer returns to the site and checks his cart after completing an order, the cart is empty. I have not had time to look into the code for this yet, but perhaps whatever trigger empties the cart could decrement inventory first. Just thinking out loud...we'll see what I can figure out.

Sorry it has taken so long for me to get back to this issue. It was consuming a lot of time, and I had to get another project off my plate. Now, back to this.

Sorry this post is so long. Most of it is just me thinking out loud again. Do I come up with any solutions? Sadly, no. But I'm hoping for an epiphany.

I did set up a test server with a fresh, new installation of Drupal, a few modules (Ubercart, TinyMCE, IMCE), clean URLs...I think that's it. I killed the PayPal payment method so I can test an internally controlled payment method, such as Checks. Paying by check works. The inventory decrements upon final submission of the order. So, I understood Ryan's last post correctly.

Now, to decide whether or not that is the best time to decrement the inventory...by what Ryan and CpILL said, it looks like this has been on their minds too.

One test I performed...I initiated a purchase by putting a "one-of-a-kind" item in my cart, then started to checkout. But before clicking "Review", I logged into the back end database and manually decremented the stock level to 0. This should simulate another customer who put the same item in his cart, but the other guy "Submitted" his order before me. Then I went back and "Reviewed" and "Submitted" my order. Unfortunately but predictably, Ubercart allowed me to complete my purchase. Then I checked the database and found my stock level at -1. Again, this seems to be a symptom of "when do we check/change inventory level."

OK, so let's think about this...

Lets say I sell one-of-a-kind autographed t-shirts. I need to prevent two customers from putting the same t-shirt in their carts.

Let's say I had a brick-and-mortar store. Let's say Ryan takes an autographed ABBA t-shirt off the shelf, puts it in his cart, and continues shopping. (I didn't know Ryan was an ABBA fan, did you? ) If CpILL went to the shelf after Ryan, there would be no ABBA shirt for him to take. I guess CpILL would just have to go find a different t-shirt.

In Ubercart, could we/should we decrement the stock level when the item is actually placed in the cart?

Hmmm...let's keep going with the example.

Let's say Ryan changes his mind about buying the ABBA t-shirt. He leaves the cart in the back corner of the store somewhere and leaves. Several more customers go and check the shelf for that shirt, but it's still in Ryan's cart, so I miss several opportunities to sell it. Ok, this isn't good.

In my brick-and-mortar store, the shirt doesn't get put back on the shelf until I walk my around the store to clean up. But in Ubercart, couldn't we use "cart duration" to help us out? If the cart sits there with a t-shirt in it for more than 4 hours (or whatever duration), don't just delete the cart...instead, increment the stock levels first, then delete the cart (I think CpILL said that in his last post too, but I don't know how hard that would be to implement).

Using this method, you might still miss out on sales opportunities due to carts being abandoned all over the store, but at least the customer's perception of your inventory is accurate at the time they try to put something in their cart. Heh, it would really suck though if someone wrote a script to shop your entire store, putting ALL your inventory into carts, and then just left them there.

Another option would be to decrement stock levels when "Reviewing" the order, before "Submitting". That way, we get around the problem of NOT decrementing when using PayPal. But we still have the problem of carts lying around with inventory in them. We also still have the problem with multiple customers walking around with the same item in their carts. If the Ryan and CpILL both put that ABBA t-shirt in their carts, but CpILL "Reviews" his order first, what happens to the Ryan's shopping experience when he "Reviews" his order and learns that his ABBA t-shirt was bought out from under him. That's not good.

I think I'm leaning towards decrementing stock levels upon putting the item in the cart, and using cart duration and delete to put the items back into inventory.

One thing I might not understand is what CpILL meant when he said I decided that the API should be apart from the business logic as most shop setups will have their own rules they would like to implement. Is my example above too much "business logic"?

So what does everybody think so far?

EDIT: BTW, if the store had dozens of each shirt available, and I could still get more from my suppliers, then decrementing stock levels when the item is placed in the cart should not adversely affect the customer's shopping experience, nor should it affect the opportunity for the store to make the sales. It would only come into play when stock levels are low and NEED to be tracked accurately due to supply.

I think my vote would be to have the inventory get decremented AFTER the sale was made, thus it would be after the final submission. This way only actual sales have affected your inventory count. I would also prefer to capture the sales lead even if I didn't have the stock available as I might be able to offer a substitute or still close the sale (after ordering more of the item). I'm not sure how we could capture the sales lead, maybe institute some form of back order processing? Or provide some way to let the customer know when the product would be back in stock (automatic email)?

I also would vote for having at least 24 hour cart durations (maybe even as long as 2-3 days). I often times start to place an order online and get distracted with something else and then need to come back to the site to finish my order. If I come back and my cart is empty, I'm much less likely to fill it all back up!

Maybe we could make these options user configurable?

Jeff

lafflam,
As you can see there are probably dozens of ways to do the stock tracking and they are based on the type of product (one off ABBA shirts or a more advances third party fulfillment system that can check with the manufacturer and see if the car part is still being manufactured or not and then order more as needed, etc). We did have a long debate on these forums, before the server went down, and I came to the conclusion that it was impossible to cover all the bases so instead I would make an API and a simple stock level tracing system that worked pretty much as 'cobrasound' outlined it above (and I thought it did work this way up until I got back from holidays this week, I'll try and fix the bug). That is stock is decremented when purchase is confirmed.

An immediate argument against the decrement when adding to cart is that say you have a site with 5000+ visits a day and 10% put the most popular t-shirt in their cart (of which you have only 300 in stock) and then only 10 of the 500 actually want to by that t-shirt. On a bad day they have a less than a 1/50 chance of actually getting a hold of that shirt. The more poplar the site the less likely some one can make a purchase, which isn't what you want.

Really, the merchants don't care about the 'fairness' of who gets the 'right to buy', they only care about selling in my experience. Last minute bidding on eBay has never disgruntled the people who get out bid at the last minute as everyone knows the rules and there is a level playing field and thats the best you can hope for. I'm sure if speedier checkouts is the result the merchant isn't going to be complaining.

Anyway, the option is there for you to write your own inventory manager that does it the way you like it while sharing the reusable part of the code, the API, which will get stronger the more people plug their managers into it.

Paypal, and all payment methods, should return a 'yes' or 'no' from the payment process, correct? I guess, decrement, when someone goes into Paypal, and then if it returns 'no' increment the stock again, if the orders state stays in 'pending' (i.e. when the customer is in the process of paying) indefinitely then the order system should ether time it out or it should be done manually by the order admin. This should happen for _all payment processes_, no?

So, I guess I will try and decrement the stock when the purchase phase is started, i.e. immediately after the 'review' screen, and increment if payment was declined. Is this possible Ryan?

@CpILL - To act on something once payment is initiated will be a little tricky. You can do one of a few things... probably the thing to do would be to use the submit $op for hook_order(). The problem is that for redirected payment services, you won't necessarily receive a confirmation. For example, someone could get all the way through checkout, go to PayPal to pay, and then just never complete payment. I suppose this is where the cron hook would do the clean up of carts in checkout.

@lafflam - I was looking at what it will require to add the code for removing items from the cart and it's more than a 2 minute fix. Otherwise I'd do it right now. As it is, I really want to get Alpha 7c out the door. Once I get it out, I'll add in a call to hook_cart_item() when a cart is emptied automatically, an item is removed through the update form, or a cart expires. I forgot I'd have to deal with it in all three places.

@lafflam - if you get it cranking send it over and I'll package it as part of the API as well as any changes to the API you think would make it more universal. The trouble with only doing one Manager is that sometimes you can't tell if your bending the API too much to your specific case or not.

@Ryan - For redirected payment services I was suggesting that the order stats go into something like 'payment pending' and then you can have a cron job scan for orders that have been in this state for X period of time (configurable via the admin on a per payment method basis to 'X minutes' or 'manual'). I guess to clean up the checkout process more 'states' need to be added to model clearly whats going on, which shouldn't be too difficult, more statements around discreet code blocks relating to state changes like:

Perhaps even a global (ugly but procedural) state object (nice OOP) that you can pass around and that has the above code in a change state method so all state functions are hooks, which would keep it consistent and modular. But maybe I'm being too OO...

@dougdagaz - The example of a "one-of-a-kind" autographed product is only perfect for those types of items. I wouldn't say its even typical if you take the number of rag trade shops online where they basiclly have X number of the same item (the industrial revolution for ya). What IS interesting about that case is that you might want different inventory managers for different kinds (classes) of products! aH! This would be the next extension to the Inventory API where you set the default manager in the admin settings but then have the option on a per-product basis to choose an manager.

note: This will need to integrate with the import/export.

Before this inventory problem, I would have considered myself a Drupal/PHP hack. Now, I'm learning more about PHP, and Drupal techniques specifically.

The client who wanted this went looking for a different solution, so I am no longer in a rush to just "mash" something together. Instead, I am trying to do this right. My intention is to use the API as written, but write a couple of backend managers for different situations. Or, better yet, if possible, one configurable manager.

Anyway, as soon as I come up with something that is even remotely useful, I will release it here.

CpILL, any progress on this? I am definitely getting a confirmed message from Paypal. The order is marked payment received. But the item, which was a one of a kind item, stock of 1, is still available for sale and the stock level hasn't been decremented.

I'm using Inventory API 1.9 with Simple Stock Levels 1.4. Thanks for anything you can do. Let me know if there are any tests that would be useful.

I guess the question is how can I get Inventory API and Simple Stock Levels to subtract an item when it gets sold and confirmed by Paypal. The module keeps one person from buying two of these one of a kind items, but once the sale is complete and the cart empties, the item is still in the stock of the store.

Yeah, PayPal may be independent of Ubercart checkout depending on which service you're using... trying to accommodate third party payment systems like Website Payments Standard might just not be feasible. I would just assume it goes ok.

Hall, in the latest code I've taken out that order status change b/c it was hard coded. Instead, I think what really needs to happen (and this will most likely be the only way to accommodate all the inventory needs) is for the PayPal module and inventory (whether it's CpILL's or something else) needs to be integrated with Workflow-ng. This way store owners can decide when to change order statuses and when to adjust stock levels. Trying to accommodate everyone in the code just won't work, I don't think.

Well... I'm still trying to figure out how it should best be integrated w/ Workflow, but that's the gist of it. You actually have to use a Workflow-ng hook to declare an action and write its function. I'm not knowledgeable enough to explain the process more than just to point to our existing *_workflow.inc files.

Problem is, how many points of integration does it need. Also, the action can only receive arguments of entities that have been defined... the pre-existing one is the order entity which will pass the whole order object. In which case you'd need to just have a single "decrement stock" action that would do it for any stock controlled item on an order.

I thought about it a little after posting that and realized it would take more thinking.

Has anyone found a solution or a hack to decrease the 'quantity' field in 'uc_stocklevels' table when using PayPal website payments standard or is it time to look for a different ecommerce solution? The uc_stock module is decreasing the 'stock' field in the 'uc_product_stock' table so couldn't i add an extra line of code when it executes to decrease the value in the 'quantity' field from the 'uc_stocklevels' table?

Thanks for the reply TR, someone told me in a previous thread that it should work if i use both modules so i tried that and couldn't get it to work. Then i tried disabling uc_stock module and leaving it up to Inventory API to handle it but this did not work either. Is Workflow-ng supposed to be handling the decreasing of stock?

Yeah...it's really irritating, especially to a new user of Ubercart. In this thread I see a lot of hand-waving and lofty ideas about what could be done in some imaginary dreamland, instead of actual action to fix something technically minor that everyone NEEDS to work. uc_stock doesn't prevent users from ordering more than the inventory holds, making it USELESS. uc_inventory_api and Simple Stock doesn't decrement stock via PayPal IPN like uc_stock does. You can't use both, you can't use either...how is anyone without PHP knowledge ever going to use Ubercart?

My point is that yes, there IS a quick hack to make this work, and I'm stunned that none of these intellectuals in this thread have pointed it out yet.

Simple. You want to add an action to your Workflow-ng "Update order status on full payment" configuration, which is executed when PayPal IPN reports success. Add an action, choose "Execute custom PHP code", and insert (in plaintext or source mode, beware TinyMCE users):

I could have overlooked some huge negative effect caused by this hack, please jump on it, I'm by no means an expert in Ubercart or PHP.

Forgive my crankiness but I just see huge glaring holes in this whole setup. Just be glad I'm sticking around to use Ubercart and contribute to the community, instead of jump ship to another commerce solution.

uc_stocklevels has been marked as abandoned for quite some time, and Ryan and others have said that it may not continue to work. I'm still using it, and it works for my purposes, but your mileage may vary. As I get time I'll update my client's site to use uc_stock. uc_stocklevels is somewhat of a "dead horse" at this point.

My point is that no one is updating the module. You seem pretty proficient with PHP and Ubercart. Maybe you'd like to take over uc_stocklevels and incorporate your changes? This thread http://www.ubercart.org/contrib/132 implies that it needs some love...

Just to add to my growing list of tricks to get my store doing things right, I wanted customers to see my current stock level. It cuts down on questions when they can't buy a product. I added this to my node.tpl.php file, at the place I wanted to show stock (after content):

This thread is very interesting. A client (who doesn't use PayPal) uses Inventory API & Simple Stock Levels and it works fine. Except for the problem mentioned above where the module decreases stock when it's added to the cart, *not* when it's purchased. This is leading to incorrect stock levels.

I see someone above mentioned the idea of hooking into the final submit order action. I'm unclear if this was ever added to the module before it was abandoned? If someone could clarify this for me (and perhaps provide a link), that would be great!

Thanks,

Jim