Maximum quantity possible for kits and bundles (auto-assembly)

started a topic about 8 years ago

Please add one more parameter to product availability report - maximum quantity possible for auto-assembled items.

For sales channels there should be an option to choose to update quantities based on available quantity or based on calculated maximum possible availability. So this should resolve the issue with 0 quantities for bundles.

13 people like this idea
  • This is also important for us. We use bundles to sell packs to different customers types and this would give visibility for the sales team and additional sales channels (Shopify for example - through the API).

    1 person likes this
  • Yes please to this! We sell a product that's a collection of other products. Updating the inventory of the master product based on the availability of the child products would be HUGE :)

  • This would be critical for us signing up for your service. Thanks!

  • We sell printed shirts and we print them on demand so all of our product families, finished goods and basically the 70% of our inventory are "virtual" products created by a parent-child relation to the BOM. We need to keep track of all the stock of the base t-shirts whenever someone buys a printed shirt so having DEAR to update the inventory for these assembled products would be great and the final piece that would make DEAR the perfect inventory management software.
    Currently, support has adviced to manually update the inventory quantities for all those products since the system can't do it. And we have like 2000 products like that... :/   

  • Yep totally need this also. Please implement
  • This is one of our most important requirements, as we break down multi-packs and sell individually and also different quantities as sets with their own SKUs.
    Having seen auto-assemble and auto-disassemble, I initially assumed this is what it meant, but no.
    This is therefore a deal-breaker and will have to use another system.


  • I would like to be notified if and when this feature is implemented, as I sell many bundles and multi-packs and do not want to manage them all manually. This is a deal-breaker for me, so I will continue with the service I'm currently using. Thanks.


  • This is also quite a deal breaker for me too. I switched from an inventory management system that did let me manage inventory on bundle packs by taking inventory for say two components from other individual products, meaning I only had to update inventory on the individual product level. I was assured by Dear that this software did this, have now invested A LOT of both time and money to change over only to just be told a differing story now and that none of my bundles which are being auto-built have any inventory management without me having to manually enter them in the bundles.

    To me, this defeats the purpose of even having a bundle that is autobuilt from other components surely?!

    Had I knows this, I wouldn't have changed from my existing system which was working.
    Can someone please advise how far off approx a fix to rectify this might be?


  • Running into many clients that need/want this for the kits that they sell.

  • Happy to schedule this for development. Just need confirmation from you all subscribed. In the sample below we have two bundles with 2 the same components each.Please let us know how many items available we need to return to the sales channel

    Bundle 1 - ?

    Bundle 2 - ?


    Bundle 1:

    Component  1 -  1 item

    Component  2 - 1 item


    Bundle 2:

    Component  1 -  1 item

    Component  2 - 1 item


    Currently Available :

    Component  1 -  10 items

    Component  2 - 10 items


  • Hi, sorry I'm a little bit confused by what you're asking. I DESPERATELY though need this feature, otherwise I'm pretty much spending $200/mth for something my existing website system already does.

    In my case, I might have a bundle that is made up of 2 components (component A & B for example). Component A & B are also their own singular product on their own, so if someone buys it as a single product it'll need to deduct that sale from inventory there. But if someone buys the bundle, it'll need to deduct one of each off the inventory/product from component/product A & B each.

    Is that what you're meaning?



  • In this example, I would include a stock figure of 10 for Bundle 1 and 10 for Bundle two. If 1 x Bundle 1 is sold, then there should be 9 of bundle 1 and 9 of bundle two available. It might also be useful to include in the API callback some new values: OnHand - The total quantity of the product on hand OnHandInventory - The total quantity as inventory items (already assembled) OnHandFromComponents - The total quantity available to be made up from components.
  • My short answer to your question is:

    Bundle 1 - 10

    Bundle 2 - 10

    This is the number that would be visible in DEAR and for any integrated system.  

    I am good with the double counting, so long as all of the inventory numbers are updated as soon as an auto-assembly occurs.

    A couple of other thoughts related to this:

    Recursive availability

    In cases where there are subassembly within assemblies, I think the same functionality should be the same. That is, the functionality should do recursive availability. Using your example, say Component 1 had its own auto-assembly of Subcomponent A and Subcomponent B. The system would first do the auto-assembly availability of Component 1 based on the availability of Subcomponent A and Subcomponent B, and then calculate the Bundle 1 availability based on Component 1 and Component 2.

    Notation for actual vs. calculated availability

    It might be good to have DEAR might be some kind of notation that indicated that the value included some auto-assembly. For example:

    Bundle 1 - 10 (includes auto-assembly)

    Bundle 2 - 10 (includes auto-assembly)

    Keeping in mind that Bundle 1 could also be assembled manually, not just auto-assembled. So it is possible that Bundle 1 is already assembled with no ability to build additional kits, so the numbers for Bundle 1 would not include the notation, while Bundle 2 might.

    Bundle 1 - 10

    Bundle 2 - 10 (includes auto-assembly)

  • To clarify: "Notation for actual vs. calculated availability" is nice-to-have.

    And I am not sure to how many businesses the "Recursive availability" is important, so if they is going to significantly slow the implementation, then maybe that could be skipped for now, too.

    Getting the one level auto-assembly availability implemented is very important.

Login or Signup to post a comment

13 people like this idea
Log in or Sign up to post a comment