Drupal 8 port of Commerce Stock

I don't know, if you're actually working together, but there's a port available on Github: https://github.com/INsReady/drupal-commerce-stock

It's mentioned in here: https://insready.com/en/blog/case-study-launching-inventory-control-syst...

That's great news! :-)

Just wanted to ensure that no one wastes his valuable time because of not knowing that some other person has already done great work too...

I'm looking forward to commerce_stock :) (unfortunately (or luckily) I don't need it in my current e-commerce projects, so I won't have the need to contribute by myself here...)

Hows the progress? I will need this module for a D8 commerce project soon, am willing to help out.

HI Guy,

Hows development of commerce_stock for D8 coming along?

I'd be happy to do testing for you, wheres the latest code to be found?

Peter.

@tasmaniaman, Work is happening here in the d.o issue queue, with PRs at https://github.com/BBGuy/commerce_stock. Jump in! Jump on IRC and look for me (@steveoliver) if you need help finding an issue.

Any ETA on an alpha release?

Hello,

commerce_stock still requires commerce-2.x-dev, even if commerce 8.x-2.0-beta6 has come out. Maybe tag the beta as requirement? Would be nice to start using commerce 8.x-2.0-beta6, not the dev version.

Justas

What level of functionality can be expected from D8 commerce stock, now that D8 commerce core is getting closer to what they consider a release version?

@guy_schneerson, are the two listed blockers still accurate? Are they stalled out?

Linking in related issues. And changing this to postponed since we seem to be effectively blocked until those issues are resolved.

When is the next expected - commerce_stock 8.x-1.x-dev - branch release?

@guy_schneerson wrote:

"the availability manager in commerce core has not been finalized yet"

Does that statement imply that Drupal 8 Commerce 2.x is still really a beta component with an incomplete infrastructure?

DrupalSiteBuilder, The availability checker interface currently returns boolean values for availability checks, which works for hard yes/no responses, but is not very flexible for making decisions based on more qualified information like stock levels and specific reasons for responses.

Drupal 8 core and now Commerce 2.x's release schedule allows for progressive enhancements like this to APIs for those that are willing and able to follow the progress.

See #2710107: Finalize the availability manager service.

Subscribing,

looking forward for first working version Commerce Stock in D8!

Thanks already for all the effort for everybody working on this project!

Thanks for working on this component!

... ready and willing test with gusto as soon as some dev/alpha/beta code is available ...

... looking forward to a working version of this component with great appreciation! ....

One of the most missing to Drupal Commerce. Looking forward too for first working version D8.

Thanks for the hard work !

I would love to be able to use this module on my website. Is there any work that needs to be done so that PR #593 can be approved?
I'm not very experienced with Drupal yet, but I'm willing to contribute.

Hi All!

Thank you all for your hard work so far on this!

How far away from a alpha do you think we are? Is the current state of the effort reflected in the "Remaining Tasks" above? That seems to be very early days as Architecture is not indicated as being done yet.

Updating in the doc above may help minimize these annoying requests for status. Also, I'm another willing participant in helping this effort move forward on dev, testing, whatever!

Thanks!

Do you have a release date to communicate ?

I have just seen this and I have a client asking when stock could be added to there store and why it is not default like it is on other commerce solutions. So I apologise in advance but I need to add to the voices here as I could do with getting an idea if this is going to be a problem for me.

• Do you need help to get this through? if so what help do you need?
• Do you have a release date?
• Is there a simple stock we can use as a temporary solution, or we just going to have to wait it out?

@BigEd: I haven't observed the development of commerce_stock and how mature it already is, but building a (temporary) simple stock solution (only having a single stock location, etc) should be rather trivial.

I may miss one point, but basically you'll want to:

1. add a field to product variation
2. implement \Drupal\commerce\AvailabilityCheckerInterface
3. probably implement hook_form_alter() to manipulate the add to cart form (show message / hide button....)
4. react on commerce_order.place.post_transition event and reduce the stock on order placement (see https://docs.drupalcommerce.org/commerce2/developer-guide/orders/react-t...)

Yes I agree with agoradesign,

you can already use commerce_stock in D8.

We have a site running on D8 with basic stock support, coming from D8 commerce_stock and here are some fragments from our composer.json:

"require": {
"drupal/commerce_stock": "1.x-dev",

=> These are the patches we are using:

"drupal/commerce": {
"AvailabilityChecker": "patches/commerce_2710107-availability-response.patch",

"drupal/commerce_stock": {
"MultiStore + Availability checker": "patches/2847529-add-to-cart-availability-full.patch"

Ok this sounds really positive thanks for the quick response guys.

If I am reading right there are two different solutions here. @maxplus I assume the code we are adding is a dev version of this module with patches is that correct?
If so we can all test this to help this module along.

If its a problem and not working for me I can always try the simple stock trick that @agoradesign suggested that also sounds not too painful to put together.

Right.. of course the very best for the community would, if you try commerce_stock and if necessary, help to improve it

If you nevertheless don't have resources for that, the simplified custom solution should really be that easy as described. Another thing I forgot before and you'll probably want to do is to ensure that you can't modify the quantity on the cart form to a higher number that is on stock... but that's also just another form alter hook with an additional custom validate callback

ensure that you can't modify the quantity

In my opinion, quantities you're able to add to the cart have to be managed by the stock module. It's intrinsic.
Being able to use a select list (eventually with an high limit) instead of a simple field could be useful for that.

By the way, I don't know if it could be help, but what about founding a beta release? I mean, get funds of all guys who need a beta release (what do not break in later upgrades).
I'm not a coder, but I can help adding funds in a microfunding process, if it has sense for you.

I'm interested in testing the stock module: Current local sandbox is Core 8.5.0-beta1, commerce": "2.x-dev", commerce_shipping": "2.x-dev", commerce_stock": "1.x-dev", PHP 7.2.2

I am searching for documentation relating to the commerce_stock module configuration and use.

Thanks for getting back Guy, I'll give build 48492c5227 a try. 0d94acf was throwing quite a few errors which I assume was due to a combination of proper configuration and PHP 7.2

Hi, I have no the time to code to this project right now, but if I have a confirmation from a new project, Maybe I can contribute money to get a beta release according to @calbasi

What's blocking the beta?

Regards !

Testing 1.x-dev Stock configuration event handling.

When dealing with one of a kind items where "Stock Level" = 1 and the item is added to cart there is no method for reducing the stock level to make that item no longer available for selection.

As a result an item with "Stock Level" = 1 can be added to a cart by one or more customers unlimited times which implies there is no add_to_cart limit on any item regardless of stock level with level <> 0.

When an item is added to cart a negative transaction on stock level should occur resulting with that stock no longer available for selection beyond its available level.
When an item is removed from a cart the positive stock transaction should occur and make the stock available for selection again.

The "order complete" event is too late in the workflow for real-time interactive stock availability processing. Carts held for more than n hours could release their stock hold on items as well as incomplete orders.

Is there a way to move / configure the stock level manipulation event forward to the cart in order to more realistically represent a shopping item selection experience?

Hello @.jch, thanks for your effords. I think the question is somewhat out of scope for this issue, but anyway.

I can understand your point of view, though I'm not sure, that this should be the default behavior. @guy_schneerson should know if that was an frequently requested feature for the D7 branch. I wouldn't expect that. This introduces even more complexity (release stock from cart after x). We would need another state "reserved stock" or something ...

But I can see, that this behavior is more customer friendly and leads to better UX. So we should probably provide it in the long run. But I wouldn't implement this as default.

olafkarsten,

Thanks for getting back, I can see how from an implementation point of view, why not to adjust stock levels until after an order has been completed. However from a UX prospective being able to load up a cart with more items than physically exist and then proceed through the checkout workflow does not make sense especially when you can display 'n items in stock' and the customer can load n + whatever in the cart.

Or having two or more customers with the same item in carts totaling more than physically exist. Whoever checks out first wins?

I'm working on a marketplace model where by nature all items are unique and singular and will never be replicated. For my case I could probably simply implement a hook somewhere and flip the Boolean available switch in the variation when a item is added or removed from the cart.

I can imagine other scenarios with limited actual on-hand stock quantities out of sync with system stock levels that could cause problems leading to detrimental customer experience, loss of sales, and future site traffic.

Agreed. Good use case. The UX in such cases would be terrible. Though I wouldn't consider a market place with unique items as the common use case for commerce sites, right.

On the other side - if you have non-unique items (common consumer goods things), you may loss sales, if an item is in the cart, but never purchased. During the "reservation" time, other customers may leave the site.

Other store admins may want to adjust the stock level a little bit later. E.g. at the time the customers go to the checkout page, because cancelation at this point is less likely.

That makes me think, that the event that triggers stock adjustments needs to be configurable. And you somehow needs to trigger a positive stock adjustment (release reserved stock) after a configurable time. I guess thats not an easy thing todo. Furthermore, that doesn't make sense for items that are backorderable. I'm not sure @guy_schneerson likes the idea to add this to commerce stock core. Maybe this is a job for a contrib module. Howsoever, we need to keep this is mind and make sure, our code allows for such modifications.

@.jch

Or having two or more customers with the same item in carts totaling more than physically exist. Whoever checks out first wins?

I see that often in the wild, for "common" shops with consumer goods. I don't think this is exotic behavior, right?

especially when you can display 'n items in stock' and the customer can load n + whatever in the cart

I would label this a bug. A customer should never be able to put more items in cart, than the display suggests.

Hi olafkarsten,

I'm not sure why you would want to push stock adjustments further back. I think this would compound the problem. A configurable point in the flow would be ideal.

I still believe if a item was reserved at cart_add and returned to stock at remove_from_cart an accurate stock level could be maintained for items which would enable reliable item selection for customers regardless of any item acquisition competition.

As for abandoned carts there are various timestamps within the order, one of them being the field 'Created'. This becomes populated with the time the first item hits the cart. After reasonable time of say 2 hours (or configurable "reservation" time) the cart could be presumed abandoned and the contents returned to stock.

Without cart stock reservation, and even if a customer were not allowed to place an item in the cart with a quantity greater than the current "Stock Level", they or others could continue to add the item beyond the physical number in existence.

Example: If there were an item with a stock level of 5 there would be nothing preventing one or multiple customers from placing that item
in the cart with a quantity of 5 multiple times.

I'm not sure why you would want to push stock adjustments further back.

Personally I think the better UX is with reservation at cart_add.

But I know some people will freak out, if this would be the only option.
Because of that numbers:
https://www.statista.com/statistics/457078/category-cart-abandonment-rat...

For the avarage retailer you will block a lot of stock for nothing.

Hi gang. I love Drupal Commerce and would like to help out. I'll be looking over things at Midcamp. Anyone else going to be there?

By the way, there is a new module like this one: Commerce Inventory

@guy_schneerson wow, great news! I am going to test that soon!

What do you think regarding upgrade paths? Would you use the alpha version in production for a simple use case of local stock and only one inventory?

Alright, great! I'll test this in coming few days and report any issues I encounter.

Lets close this one. We have issues for open task and feature requests. The main work is done. The remaining stuff is business as usual.