Stock for D8: Architecture & high level functionality

In terms of multiple locations, I'm interested in how Commerce should calculate the availability of stock in different scenarios.

It looks like your proposed approach would involve having a stock level for each location and then calculating a total stock level at the product level which would be used as the stock count during checkout.

However, say I have a store that operates in the US and Canada, and fulfils orders from warehouses in Chicago (for the US) and Vancouver (for Canada).

Should stock in a Chicago warehouse be counted as "available" for an order placed for delivery in Canada? I'm not talking about the logistics of deciding how to fulfill the order, purely the question of whether the product should be considered "in stock" for a Canadian customer if it's available in the Chicago warehouse but not in the Vancouver warehouse.

Another scenario might be where I'm offering same day delivery in NYC, but can only achieve this if the stock is available in the NYC warehouse - the stock level for NYC might be used to determine whether the shipping rules return "Same day" as a shipping option.

I'm thinking this could be solved by having "location groups", where each location can be added to one or more location groups, and the total for each location group is calculated in the same way as your proposed product level stock level. The availability of a given product for a given customer would depend on the stock level of that product in the location group(s) available to that customer.

HI Guy - appreciate your feedback. Glad I'm on the right track!

Regarding the inventory_product_level, I agree that this is an unreliable measure if it's not being updated in realtime, and realtime updates will be costly in terms of load and resources.

However, I wonder if we need to know the inventory_product_level when checking if a product is in stock? The most frequent reason for a stock check will occur when loading a product page - do we show the Add to Cart button or an Out of Stock message? At that point, surely we just need to know if the product is in stock, not the level of the stock?

In other words, for these real-time "do we have enough stock to proceed?" checks, we probably just need to know that at least one of the locations in the location_group meets the stock level threshold to continue. This threshold would change during the checkout cycle. It might be 1 unit for the product page load but, if someone adds 5 units to their cart, we'd need to check that we have 5 available.

So the stock check done during a product page load or add_to_cart action could involve cycling through the locations in the location_group until one is found with enough stock (or generating a running total if the first location doesn't meet the threshold), and stopping as soon as that happens, to avoid further load on the server.

We could streamline this further by making sure that locations that are more likely to have stock are checked first (e.g. a central hub before a regional spoke). To this end, we could provide a weighting value for each member of a location_group that determines the order in which we cycle through them. Another option would be to check locations that are marked as fulfilment locations (i.e. it may be that not all locations in the location_group are used to fulfil online orders).

Commerce 2.x has Store Entity. I am interested in learning how Stock would integrate with Store Entity. So, most use cases can be solved by different configurations instead of Commerce Stock Module providing out of box solutions.

Hi. Since D8 commerce has stores, will it be possible with the current architecture to enable tracking of a universal SKU across multiple stores? i.e. each store uses same SKU, so that total stock is sum of stock across stores.

Please see here for my initial post under commerce. https://www.drupal.org/node/2650294

Including me, I think more people are getting interested in following your direction. If you could, list out small issues or tasks, so that people can get started to help.

Hi Guy,

I'm really interested in the Stock movements transactions feature for the D8 version of commerce stock.

I'd love to be a tester for the development of the D8 version. :-)

Looking forward to helping out.

Peter.

Following @guy_schneerson's architecture, we are doing the development on Github https://github.com/INsReady/drupal-commerce-stock. Hopefully, this initial work can give us more details to discuss.

For example, I have a specific question: we are now setting Stock level tracking on Product Variant. As the time of writing, the current Commerce Stock has its own UI to select Stores. On the other hand, DC2 has this Visibility Setting, which allows admin to choose store. I am thinking if Commerce Stock should use that setting instead of creating its own. However, by using the DC2 visibility setting, admin won't be able to choose store for individual variant.

Let me know your thoughts?

I clarified with skyred that we should not be using stores as stock locations, those should be separate entities.

Spree has a sensible architecture worth copying: https://guides.spreecommerce.com/developer/inventory.html

@guy_schneerson , the github repo is just for us to do the development work, and your reviewing. If you a suggestion on how we should contribute at the early stage, please let me know.

Sure, stock locations can belong to stores. That makes sense, just like for orders.

@guy_schneerson, we have done a lot of development on Github, https://github.com/INsReady/drupal-commerce-stock with one objective to follow your original design as much as possible. We are aware that there are many codes not following the best practice or coding standard, but we have a production site to launch, therefore, the other goal was to make it work first, then improve it later.

Below are some screenshots

I've read your blog post (https://www.blue-bag.com/blog/stock-drupal-8-commerce-technical-overview...) and also tried to get a quick overview of the current implementation in the repository... First of all, the plan is great, absolutely makes sense! As you've written, there are different needs and use cases and it's therefore important to have a flexible approach, to be pluggable and exensible in order to cover all needs. And also to provide good default services like described

I only had a quick look at the repo, but here are a few thoughts:

• A look into the src directory is already quite confusing, as every class and interface is in the same directory (and I guess, it'll grow in future) - I'd vote for the one or other subpackage here in order to have a better overview. I'd either move your service implementations (local stock, always in stock) or structure by functionality (check, update, ...)
• Consider declaring the implementations of your three interfaces (StockCheckInterface, StockUpdateInterface & StockConfigurationInterface) also as services and inject them into the stock service instead.
  That would have several advantages: you provide even more flexibility by offering the possibility to even swap one single of these stock service parts, without having to swap the stock service itself.
  If more complex implementations also need other services (which is very likely), you can use dependency injection as well for them.
  These reasons further mean better testability and less problems in unit tests (think of you need some mock implementaions of other services instead,...). And last but not least you'd follow the typical Drupal/Symfony approach
• The "always in stock" service actually only makes sense, as soon as you have implemented the possibilty to use different services within a project - otherwise you'd not need to install commerce_stock at all
• Consider moving your two default implementaions into own sub modules to avoid to have unneeded services registered
• Is the local stock service actually implemented? The blog post seemed so, but I couldn't find it in the repo!?
• To be a little bit nitpicky: if you want to stick to common coding style guidelines, the sooner you go for it, the better it is. (Because later on, when more people participate and propose patches, their patches will break likely, just because you've done the changes at that time). Eg just on scanning through your classes, I saw multiple line breaks very often,...

I think, these are all my thoughts by now - I was interrupted a little bit during writing, so I may have missed something :D

I've totally overseen the submodule! :-)

In this context, the idea of the always in stock service is clear and makes absolutley sense to me! Don't panic, I don't think, that this is expensive. D8 and Symfony2 relies on heavy services usage in its architecture. That's ok

You're right. That kind of integration is really cool

I'm looking forward to the next steps :)

You're right - this is, what makes open source in general and especially Drupal! I'd really like to help you with some issues, but as you know for sure, the only problem mostly is having enough time... At our current (and first) two Drupal 8 Commerce projects, we won't need stock management at all. And I'm currently busy getting every feature in, I need. Most likely I will have to write a payment gateway integration, as soon as bojanz has committed the initial Payment API. But maybe (and hopefully) I will have a bit more time next month or so. That's definitely a feature, that i'm interesting in and willing to spend some spare time on it also, as soon as I have some again :D

Finally getting round to replying on here after I said I would at DrupalCon.

Getting the ecosystem around the core commerce modules has always been something I have been interested in and drew this diagram to illustrate it. The top right half is showing those systems required for a physical goods store, and the top left those for a digital; the bottom being common extensions.

http://dwkitchen.github.io/commerce-2.x-slides/#/4/3

There is a combination of modules that provide functionality around physical goods, stock, shipping, fulfilment; and not on the diagram, management.

I see the balance for the Commerce Stock module keeping its functionality limited without extending too far in the providing Stock management functions which might be done using a ERP system or a further Commerce Stock Management module.

The primary function I want from the stock module is controlling the sale of items based on rules. My experience with ERP systems is that this needs to happen in the Drupal application without relying on the ERPs API, which might be the sFTP transfer of a CSV file overnight.

The most common rules are going to be around holding stock; when someone adds a product to their cart it is allocated and the available stock level reduced, if the cart is abandoned it is returned to available stock. I have even done this where the customer gets a countdown timer until the stock allocation will be lost.

Those further rules might be around where the stock can be sourced from. In the multi-vendor marketplace environment (Amazon Marketplace example) where stores are selling the same product only the stock for the store the customer has selected can be used.

It looks like idea of the stock availability manager being the solution for further modules to provide more complex methods of checking availability. The Commerce Stock module having the simplest included as an example.

The stock transaction interface also is a good way of making this extensible with Commerce Stock having:
Stock Allocated
Stock Sold

But these can be extended by further modules; Commerce Stock ERP having Stock Received, Commerce RMA having Stock Returned.

Hi, not sure, that is the right issue (there are soo many ... )

The current stock module is in different places tightly coupled to one of multiple possible product architectures as it requires a product variation / variation_id here and there. (For those that havn't read that: https://drupalcommerce.org/blog/42500/commerce-2x-stories-products). Consider declaring the essential interfaces more generic and using PurchasedEntityInterface all of the place instead.

I learned a little bit what others do and found out, that they often have one thing in common. At least one object that holds the stock related data per product variant. Assume someone wants a "minimum stock level" setting per product/location and a "optimum stock level" , e.g. to issue warnings when the stock level falls below and backorder whatever it needs to reach the optimum level. I think I have seen this in nearly all inventory system I've come across.

Wonder how we would accomplish this with our current architecture.

@guy_schneerson love seeing all the work that being done on this module on Github! :-)

Had a thought about transactions and taxes, in Australia (not sure about other countries) when a transaction journal is created the value stored is always excluding tax.

So if you sold 1 x Widget for $22 in Australia the transaction journal would store $20 because of our 10% GST tax.

When looking at a STOCK ON HAND report you would always see the value of stock on hand less taxes.

I know the Tax implementation is being reworked at the moment before RC1 but it might be something to keep in mind.

@guy_schneerson - I'll put something together and create an issue - I have access to an accountant who has strong views on the financial side of things.. :-)

I do not think we will do any work with cost/price for the beta version of stock however I would like the database schema to be fixed so any changes to support future functionality should be made soon.

That is exactly what I'm trying to solve with my idea to separate transactions and metadata entities and make the metadata configurable by the user. We need an approach that is easily to extend, but do not interfere with our stock level calculation. We never ever will get a transaction database schema which tackles all valid use cases.

I'm totally agree that we need to learn as much as we can. I only think, we can't expect to have a future proof solution that will not need any changes. I'm fine with unit costs too, we will need the currency code to the amount, but I think I have seen that in one of steves PR's. I'm have serious doubts, that serialized metadata is the right solution. But I think we have an separat issue for that.

Design discussions around support for multiple stores #2858391: Add Support for multiple stores & clean up locations store relationship

Updated some bits of the issue summary, but needs some more cleanup.

- Removed the remaining tasks: This issue is not about getting things done, its about how we design the code.

I am working on a project with both commerce and non-commerce inventory needs, and the need for both serialized and non-serialized inventory tracking. I'll lay out a couple scenarios i'm familiar with and/or working on, and will offer a suggestion that I hope we're not too late in development to consider.

First, what is serialized inventory?

A serialized inventory item has a serial number (unique identifier). Although each copy of the Product is the same, it's quantity is the calculated total of serial numbers of that item in stock, each a qty of 1. The need for this comes when one needs to track the history of a specific inventory item.

Example:

Product type: Phone
Product: Pixel 6
Qty: 2 (calculated on number of serial numbers)
Serial numbers:
 - X6123: { sold: false }
 - X6124: { sold: true }
 - X6125: { sold: false }

Scenario 1: RC Car raceway

We sell services like race admission and yearly memberships. We sell merchandise (t-shirts, RC cars, parts) online and onsite and need to ensure availability. We sell food and beverage for which we want to inventory supplies (burger buns, patties). But we also want to inventory parts for our own RC Car repairs, and track serialized LiPo batteries' usage, charge cycles, and proper disposal (see which make/model batteries last longest).

Scenario 2: Satellite Dish Installer

We do fulfillment for DIRECTV, sending our techs out to complete residential installs.

We take in both unserialized and serialized equipment from DIRECTV. We have to track serialized equipment and ensure they are installed in a timely manner, or they must be returned to DIRECTV. We can be charged as much as $500 for each satellite TV box if it remains in our warehouse past a certain time threshold (60 days if I remember correctly). We must track transfer, installation, or return of said serial numbered boxes.

Proposed Solution

These scenarios highlight an important aspect of inventory--it's not always commerce related. I propose an Inventory control module that exists outside of the Drupal Commerce ecosystem, but that the commerce_stock module can take advantage of. It would need to be flexible, which can be tough to engineer. But if done, would open a MASSIVE development market where other ERP systems fall short, Drupal can again reign supreme in yet another vertical.

Comes to mind another use case - a print of something beautiful signed by the artist itself, limited number 0-100 - user can choose the number.

Okay, not sure i'm awake, but I don't see any bigger issues here. The availability calculation would be the same. It's not relevant which serial number you have in stock, when you want to know, if you have X of the serialized stuff available.

The crucial part is the stock transaction. One could swap out the stock service and use one, that is able to handle the serialized stuff. Thats where @steveoliver's unfinished work shines. If we would use chainresolvers for part of the stock services, and make the services plugins, one could put a focused service with a limited scope in place. Thats exactly the sexiness of the idea. Build a stack of stock services, that fit your needs.

I am optimistic that we will end up with a module that makes it easy to extend it with such functionality.

@guy_schneerson *knockknock* - It would be even easier if we had transactions as an entity. Put together your own type. Add a serialized field and your are done. Happy XMAS! But thats only an side issue in this case :D

@guy_schneerson
Lets decide finally for this release if want to make stock services plugins and use chainresolvers to resolve stockservice on runtime.

See: https://www.drupal.org/project/commerce_stock/issues/2858391#comment-123...

I'm all in for this. I think this will allow much more flexibility in extending the stock module. If we don't do this now, we have to wait for another major release and this may take years. This approach will be a such a architectural change, that you probably don't launch it a minor release.

We have some work done in PR35 referenced in the issue above ^_^. If you want to go this route. Lets open an issue and get this done.
The PR is somewhat WTF ... I know. But the stock service / chain resolver part would give us a good base to start.

i think we are done with meta discussions for now