Multiple stock location support

[michaelbromley]

Is your feature request related to a problem? Please describe.
Currently each ProductVariant has a stockOnHand which represents the number of units in stock. Some businesses have multiple stock locations and it can be useful to be able to associate a stock level with a particular location. For example, this can allow the storefront to display the stock level at a given outlet.

Describe the solution you'd like
Allow the configuration of multiple stock locations, and each ProductVariant has a stock level at each location.

Describe alternatives you've considered
Some kind of custom solution using custom fields could probably be implemented already, but it would lack the first-class support for automatic stock tracking that is built in to Vendure.

[tufail]

Hi @michaelbromley
Thank you for looking into this feature. When can we expect to be release this feature.

[michaelbromley]

@tufail it is planned for Vendure v2, which unfortunately I don't have a timeline for at the moment beyond "i want to release it this year". However, work on v2 has already begun and is available on the major branch and can also be used in your projects using the @vendure/core@next tag in npm. So it is possible that this specific feature will become available on the next tag sooner.

[asiz15]

Hi @michaelbromley !

Any news about this feature?
If not, could you briefly guide me on the solution you mention using custom fields?

Thanks!

[michaelbromley]

Hi @asiz15, any news will be reflected in this issue - so I've not started working on this yet.

So the idea with custom fields would be something like this:

• Define a new entity to represent a stock location
• Define a new entity to represent an amount of stock of a given variant in a given location
• Create a customField on ProductVariant relating one of those entities for each stock location, representing the stock of that variant in the given location.
• You'd need to add some custom logic to manage whether customer can actually add an item to the order based on this data. E.g. you could override the addItemToOrder mutation to include this check.

[michaelbromley]

Prior Art

• Sylius Multi-Source Inventory which is a feature of the paid Sylius Plus version.

the Sylius Plus Multi-Source Inventory gives you a possibility to create several Inventory Sources and specify different stock amounts of variants for different Inventory Sources.

Admin can create multiple Inventory Sources (IS). For each IS they can choose Channels it will be available for. Let’s say you have 2 channels - “DACH” and “France”, and you have three magazines in Paris, in Berlin, and in Vienna, so you’d probably want the “France” channel to be fulfilled from the Parisian magazine only.

• Magento 2 Multi Warehouse plugin from Amasty

  • multiple warehouses
  • linked to sales channels
  • warehouse selection algorithms (e.g. based on stock levels, proximity etc).

• Shopware multi warehouse plugin

  • You can create and administer any number of warehouses in the administration
  • you can assign any warehouse to a sales channel - or use the standard Shopware stock

Data Model

Here's a high-level outline of how I expect this to work:

StockLocation

One or more StockLocation entities will exist. We will create a "default StockLocation" as part of migrating from the existing schema, and then additional locations can be defined. This entity will accept custom fields so you can store things like geo location, description, address - whatever.

This entity represents a physical location where stock exists.

StockLevel

This entity represents the quantity of a given ProductVariant at a given StockLocation. So as part of the initial migration we would create a single StockLevel for every ProductVariant, and copy the current stockOnHand level over from the variant and relate it to the default StockLocation.

StockLocationStrategy

We'll need a strategy for defining:

1. How stock levels are calculated. The obvious default is to sum up all the StockLevels for each location. But it is conceivable that you might want to customize this based on other factors - membership of a CustomerGroup, physical location, active Channel etc.
2. How stock is allocated. When someone buys an item, we need to define the logic which selects which StockLocation it comes from. Again, the rules for this are highly requirements-specific so this strategy will allow us to support everything.
3. How adjustments are allocated. When stock is adjusted in, we need to know to which StockLocation(s) this should go. By default I guess we'd want to include the ID of a StockLocation in the input object and allocate the stock there, but perhaps again some custom logic might be wanted. Not sure about this one yet.

Other details

• Do we keep ProductVariant.stockOnHand? Technically it will be redundant because the value can be derived from the related StockLevel entities. However it may makes sense to keep it for reasons of efficiency (deriving the value in real-time might get slow) and also for better backwards-compatibility. In this case we be really careful that it does not get out of sync, so some kind of constraint mechanism might be needed to prevent it getting wrongly assigned.
• Same with ProductVariant.stockAllocated.
• This feature will have implications for ShippingCalculators, namely, the calculation would possibly want to take into account which StockLocation(s) the order will be fulfilled from. So we'd need a way to get this data in a calculator - possibly just via a service that can be injected and return the stock locations for a given Order.

[giovramirez]

Hi @michaelbromley!

Could be these ideas related to have a strategy to look into a external inventory?

Let's say our stock levels for X item go to 0 but I would like to check with our wholesalers' inventory (using an API) if they have availably for that item.

[michaelbromley]

@giovramirez That's a good point. Yes, I think the strategy method that returns available stock levels could also e.g. make an API call if nothing is in stock locally.

[martijnvdbrug]

@michaelbromley Can this issue be closed, since it's implemented in v2 beta?

[michaelbromley]

I will close it once the Admin UI parts are implemented.

[martijnvdbrug]

Ahh clear, my bad, thought that was already done 👌

[martijnvdbrug]

Question, not sure if it belongs here, but:

Let's say we want to track our inventory with an external service, like so:

(In our custom StockLocationStrategy )

getAvailableStock(
        ctx: RequestContext,
        productVariantId: ID,
        stockLevels: StockLevel[],
    ): AvailableStock | Promise<AvailableStock> {
    
    return this.externalService.getStock(productVariantId)
}

How would we then handle allocation? I would actually like that Vendure doesn't do anything with allocation, but rather have the external service handle saleable/allocated stock levels. Is this possible, or does Vendure always use the concept of allocation?

[michaelbromley]

@martijnvdbrug I think that's worth a separate issue.