This question has been flagged

mrp.property is a class created by the procurement module, and it looks like this:

class mrp_property_group(osv.osv):
    """
    Group of mrp properties.
    """
    _name = 'mrp.property.group'
    _description = 'Property Group'
    _columns = {
        'name': fields.char('Property Group', size=64, required=True),
        'description': fields.text('Description'),
    }
mrp_property_group()

class mrp_property(osv.osv):
    """
    Properties of mrp.
    """
    _name = 'mrp.property'
    _description = 'Property'
    _columns = {
        'name': fields.char('Name', size=64, required=True),
        'composition': fields.selection([('min','min'),('max','max'),('plus','plus')], 'Properties composition', required=True, help="Not used in computations, for information purpose only."),
        'group_id': fields.many2one('mrp.property.group', 'Property Group', required=True),
        'description': fields.text('Description'),
    }
    _defaults = {
        'composition': lambda *a: 'min',
    }
mrp_property()

My question is, more or less, what is this, and why does it exist?

Clearly it is a means of associating "properties" to various objects, such as procurement.order and sale.order.line. However, I can't see how they are currently used, nor even how they are intended to be used.

  1. You cannot associate mrp.property with product.product or product.template. From this, I gather that these are meant to exists "below" the product layer - that is, they are more like notes to the mrp workshop.

  2. You can associate mrp.property with sale.order.line. This goes against what I expected, since if these are notes to the mrp group, why does the sales team know about them? And since they are not part of the product, the only place to begin applying them is by the sales people?

  3. mrp.property is associated with procurement.order, but it is unclear what this is for.

  4. mrp.property, if specified on a sale.order.line, is not propagated to the created procurement.order for the lines. In other words, even if these were used at the sales layer, they effectively will never leave it.

  5. Similiarly, although mrp.property is associated with procurement.order, it doesn't go anywhere from here. It seems to be suggested that they could be used to pick a mrp.bom, since it is related there, but that is currently unused.

  6. A mrp.production is entirely unrelated to mrp.property, and each mrp.production.line is similiarly unrelated.

So, my questions are:

  1. Just what /is/ this?

  2. What can it be used for right now?

  3. What might one use it for? Can you offer examples?

Avatar
Discard

Did you see https://bugs.launchpad.net/openobject-addons/+bug/926107 - it looks like it is supposed to work and a patch to get it working is available, but I haven't confirmed this.

Author

I have seen that (and actually wrote an addon for v6 that patches it, so I don't need to touch the source). The only thing it fixes is #4 on my list, which still skips the main question: What is the point? Even with this bug fixed, are mrp properties actually useful? If so, to who? I can't think of a scenario where they would be.

For example you assemble computer and can install memory with different size. So you have one product - computer, that can have some variants - properties

Author

wowas: Okay, but what if I was selling and stocking completed computers? I'd need two products, because there is no inventory at the product+mrp_property level. Who is the audience for MRP properties? The salespeople? It can't be, because they can't filter products by properties. The MRP workers? Okay, but then who / where are the desired properties initially set? If on a product, why does MRP just not select another BOM? My point is that the role of MRP properties seems ambiguous at best and extraordinarily misleading at worst. Nobody has said they actually use them, just that "they could."

As I view, it facilitates life of sales person by redused products range. For product, that have many properties (for example - 10). Number of variants - 2^10 = 1024. I think it not suitable select needed from 1024 product, instead of specifying combination from 10 properties. Next: 11 properties - 2048 variants.

And if properties not binary (YES, NO) like color (GREEN, BLUE, RED ...). :(

BTW. It sutable for make to order. You have not stock with all variants. Properties must transfer from SALE to MRP, that select sutable BOM. Now it have bug (see above).

Author

Right, that's what i'm saying: even once things transfer, they can /only/ be used for make_to_order because stock is not kept at the property level. Thus, one cannot keep stock of, say, common configurations. It should be clearly specified, somewhere, anywhere, that even once fixed, it's only meant for make to order products.