How to Break Down Assembly Purchases

[SchrodingersGat]

Refer to this issue - #1192

Basically, some parts may be purchased from a supplier in a "kit" which contains multiple parts we are interested in. The SuppliePart / SKU references a single item, but that item can be "broken down" into multiple component items.

This would be a useful feature to have, but has some complexities with regard to implementation. Following are some ways we might be able to implement it (but there may well be alternative solutions which are superior)

Option 1: Assembly

Create a new internal part, marked as an assembly, which has a bill of materials. Define the bill of materials as the "contents" of the "kit". Also define the part as "purchaseable" so it can be received against purchase orders

When receiving an item again a purchase order which is an "assembly" the user has the option to break it down into component items

Advantages

• Makes use of existing data structures (Bills of Materials)

Problems

• No way of associating purchase price with individual items (if this even makes sense)

Option 2: Part Kit

Define a new type of part which is a "kit" - it functions much like an assembly in that it has a bill of materials, but instead of parts being "consumed" into the assembly, they are "gathered".

This may be a subtle distinction, and I'd have to think about this further

Option 3: ???

Looking for feedback on alternative ideas, or insight into how other similar software implements this

[miggland]

I think this is a great idea. Some thoughts:

• There will never be an automatic way of associating the purchase price with individual items, regardless of which technical solution InvenTree implements, which is always correct. If this is wanted, it would have to be somehow defined by a user.
• This would be useful not only when buying sets, but also when selling them. We sell "kits" of multiple items, which to the customer has only one SKU. At the moment, this item has a BoM and I make a BuildOrder when required. It's a few extra steps when handling the order, but doable. Doesn't happen often at the moment, but if it did, some kind of fast-build would be useful.
• The reverse process would be for buying - in other words, what is missing is a "reversibility" of the build process in that individual parts are put in stock, and the assembled item is removed from stock.

I think the difficulties start when considering how to speed up, and asking when the assembly/disassembly should be carried out.

• When selling:
  • as soon as all required parts are in stock?
  • whenever someone in the warehouse puts items in boxes?
  • when adding a line to a SO?
  • when allocating the item to a shipment?
• When buying:
  • When receiving the item?
  • Later on, for example when someone unpacks items?

Which answer is best may vary depending on workflows. Besides adding a the opposite of a BuildOrder, making the process quick for such sets would be helpful. But that raises questions as to where to take items from/put them (StockLocation).

[westinpigott]

This would be very helpful. I think about it as a more complex BOM process, where we treat a build order instead as a work order. We can specify the inputs 3X, 2Y, 7Z and the outputs 2H, 5G, 1J. This way a work order can be any level of complexity.

BOM would probably be better changed to a separate entity where it is a "Work Order Definition".

Adding the ability to add in labor cost/time as well as machine cost/time would be useful as well.

For cost flows, I would think we would have a ratio assigned to the outputs. We can default it where (above example) 2+5+1 = 8, so each gets 100/8 = 12.5% of the total cost. The user could change the cost allocation ratios in the Work Order Definition as well as long as it adds up to 100%.