What is the best way to model a large sized product composed by other products?

In moqui, we have ProductAssoc to model the relationships within Products.
For a large sized Product , like a sofa having normally several components which are actually products Those components may or may not for sale. Buyers normally buy a sofa set, but the shipments are comming in forms of components with own packing as the size of them are large.

In service implementing mantle.shipment.CarrierServices.get#AutoPackageInfo, we could do trick to split the sofa set to the component. The delimma is that in this way it seems that the seller could not match directly from the sofa set to the components right away when inspecting shipment, and it may even cause trouble when to make a picklist for this sofa set. Or in some other places it breaks the moqui business logic.

Anyone has any thought?

Could you break this down more? (sorry a bit of a pun on the topic of products with assemblies)

The general model would apply, the main product (including variations if applicable) would each have a bill of materials configured using the ProductAssoc entity as you described. That would apply to sub-assembly products down as many layers as needed, all the way to raw materials if you track it that far (for analysis or for component sourcing).

About an implementation of the get#AutoPackageInfo service interface: That isn’t necessary to use Moqui for shipping and such, and it is really meant for high volume operations with consistent enough products that they can determine shipping weights and dimensions in advance. You could try to implement it for the potentially multiple packages involved, or even using values stored with the Product (in ProductDimension or something).

For the other things you mentioned about picklists and other places it breaks the logic, could you be more specific? Which services or screens/forms are you using and what sort of issues did you run into? I guess this gets down to the basic questions for issues (what did you do, what happened, how is that different from what expected), and some detail would be needed to pin down which parts of the system are involved. For example, are you trying to use pick assembly? What are these potential troubles and places things are breaking?

1 Like

Let me try to better organise it

The original situation is:

A sofa set composed by 3 components: sofa, chaise and ottoman, want to get deliver rate through mantle-shippo. Mantle-shippo needs packing box to send weight and height.etc to shippo. By a little effort, change it not to use packing box. Instead using dimensions from the component products of the sofa set…

Then I would have 4 product entities to be modelled. It follows that how the asset of then to be arranged. When someone have ordered a sofa set, should the asset of the sofa set to be changed? According the logic, it should be. So we keep the asset of the sofa set. It is wanted that the asset of the sofa set is kept in form of assets of the component products namely assets of the sofa, chaise and the ottoman such that when it comes to shipment, picklist, etc., the assets/products( productId, quantity ) of those component will be shipped, picked,

Another thing is to automate the entity creation of those 4 product . It is wanted that when create the sofa set product entity, By giving the sofa set information(selectable, standard features, category, like what createVariant service does ), then creat all the variant sofa sets, and their corresponding components products entities, including virtual and variant, Inheriting features, categories.

By inspecting ProductFeature entity and features interact entity definition, I see that automating is doable.

Asset modelling part , shipment, picklist, have not come up with a good idea.