Kit quantities in multiple warehouses

Modifying a product page template so it displays the stock levels for multiple locations, and calculates the estimated dispatch date based on which location the stock is available. Kitted items are a big problem, as they don't hold stock in warehouse locations, the components do.

Using the [@build_quantity@] tag is no good as it does not know which locations the components are in.

Using the [%item_kitting%] function to list the components and check them is problematic as it only returns components that are 'visible on the webstore'. We have kits where the components are not available for sale individually, and that breaks item_kitting. I can't find a way to force it with preview:'y' or show_all:'1' parameters like other functions. [%cart_item_components%] returns all components of kits but not [%item_kitting%] ?!?

The docs and support team haven't been much help.

Ideas anyone?

Find more posts tagged with

Orders & Inventory

Settings & Configuration

Accepted answers

All comments

Erik Merkley

This is indeed a huge limitation that I have run into as well. I only have bad news for you - there is no workaround. It forced us to have all kit components approved, and instead use front-end hacks to prevent them being purchased.

@Pranay Shinde might like to escalate this to the developers. It should be a very simple change and is a major limitation when you start writing sophisticated B@SE code dealing with kits. [%item_kitting%] should support a preview:'y' param to include unapproved components when listing the contents of non-editable kits. Otherwise there is no way to access the contents of a kit which has unapproved components (an otherwise perfectly valid - and common - setup in Neto).

Deactivated Member

Hi @Dan H . Welcome to the Community.

Thank you for bringing up this issue in our community. It's clear that the limitations around kit quantities and components are causing challenges, and I appreciate your feedback and suggestions. It's indeed a complex issue, I'll make sure to escalate this suggestion to our development team for their consideration.

@Erik Merkley Thanks for your suggestion. While I cannot guarantee changes, I will ensure that your proposed solution is highlighted and discussed with the relevant team.

Dan H

Thanks for looking into this @Pranay Shinde . Yes, this is causing challenges, and it has been for a while looking at previous discussions around this.

While I agree that kitting itself is complex, I don't think the solution to this problem should be. @Erik Merkley has suggested the correct solution, which as he pointed out, does not seem like it should be a difficult fix.

I hope we see a fix to this soon, as kitting simply does not support multiple warehouse locations at all like this.

Deactivated Member

Hi @Dan H and @Erik Merkley

Regarding [%item_kitting%], our team acknowledges that it currently only returns active and approved components for the webstore.

While it may seem unusual, the function is primarily designed to show editable kit components. For non-editable kits, the components are added to the kit regardless of their active or approved status, as they are not meant to be individually sold on the webstore. Therefore, the function behaves as expected in this context. If you wish to see changes to this behavior it would be considered a feature request but we cannot guarantee this. I encourage you to raise this in our ideas portal with details like describing your goal (e.g., generating a list of kit components, including those out of stock), providing a code snippet you've attempted, and specifying the desired outcome.

As for your inquiry about attributing specific warehouses to kit quantities, our system typically determines the stock of a kitted product based on the lowest in-stock component. The details of how it selects stock when multiple warehouses are involved may not be readily accessible through template code. While you can loop through warehouse stock for a component SKU, determining how a particular warehouse's quantity contributes to the overall "kitting" may require advanced configurations that our team hasn't extensively tested.

I appreciate your feedback and understand that this could be a valuable feature to have. Please consider this response as our official position on the matter, and if you have any further questions or need assistance with any other aspects, please don't hesitate to reach out.

Best regards.

Dan H

FWIW I've created a suggestion for this: https://galaxy.maropost.com/s/bridea/a0L5g000004ctePEAQ/itemkitting-should-support-previewy-param-to-list-all-components

If you find this topic an issue that needs fixing, throw it a vote.

To add some value to this thread for anyone who lands here having a similar issue, the support team did give me some info on the KITTING_QTY_CALC_MODE advanced config:

This setting determines if the qty of the kit is based on the minimum quantity of components across different warehouses or if its determined by the total value of available quantities per warehouse.

Valid values are as follows:

'c' is Number of kitting can be built by components across all warehouses (Default)

'w' is Total of kitting can be built in individual warehouse

It looked to work as described with the testing we did, but it does not solve the issue of knowing which location the kits can be built from. For eg. you could have 2 kits available in 2 different locations.

For now we have no choice but to make all kit components approved, which seems crazy. This is a fragile solution, because a UI component be broken by a check box in the product control panel.

@Erik Merkley can you give any more details on the solution you settled on to prevent the sale of kit components?

Deactivated Member

Hi @Dan H. Hope you're doing well.

I am excited to share some great news! Your idea has been delivered and is included in our latest update. You can find the details in our release notes for July 23, 2024: Release Notes.

I appreciate your continued support and look forward to hearing more from you.