Is there some way to assign only specific attibutes to the Product? I have expected it to be possible via Produt Type or Product Familty (Group) but it does not seem to be the case. Am i missing something here?
What is intended purpose of the attributes at all - only to keep some data in the product card?
I have checked the documentation and found no information on further possible use of attributes, i dont see how attributes could be used to find (filter) products, shown in the columns on the forms or on the reports.
PS: i don`t like to spam the “general” section or many different sections with a lot of individual questions, but i have quite many of them. What would be best way here - just single “newbie” thread maybe?
Sorry for all the “duplicates”.
For some reason there was totally no indication that the post has been sent to moderator, just no reaction to button press at all
Below, I’ve included links to the relevant topics from our documentation. Neither of these docs address your specific question, but they provide more details about each of the features.
As far as I recall, using entity type = ProductType on an attribute would allow you to create custom attributes for a product type. From there you can create a Product Type and associate the custom attributes to that product type. Now, when you create a new product with that product type selected, the attributes should include attributes for that Product Type (as well as any attributes associated with entityType = Product). If you don’t want the latter to show up then I think the best practice is to make all of these attribute associated with a Product Type i.e. associate themw with the Default product type.
No worries. I don’t really understand the moderation process for Discourse well but it’s always been a slight pain in the neck. I’ll review our settings to see if there’s some way to make it more intuitive.
What is intended purpose of the attributes at all - only to keep some data in the product card?
Yeah we probably need some help with requirements here. The current version of product attributes (as well as the handling requirements) are more or less a display-only feature, primarily used as a visual cue to users on how to deal with certain products at certain points in the suppy chain, for example
Purchasing: Is this the right product to purchase for a given? What are the incoterms?
Receiving: Does this product require special handling requirements?
Putaway: Does this product require cold chain? Specific temperature control?
PS: i don`t like to spam the “general” section or many different sections with a lot of individual questions, but i have quite many of them. What would be best way here - just single “newbie” thread maybe?
Theses questions are fantastic (not spam) and should definitely be kept as separate topics. Dealing with multiple questions per topic is really painful and the threads become unwieldy.
Note: We get about one post every few weeks, so spam away!
I expected it to work that way, but there is no relation of Attribute to Product Type.
I have consulted the documentation and tried it myself in my test instance of OB.
The Attribute has Entity Type field with choice of either Product or Product Supplier, so it creates the attribute in one of those entities.
You’re right. I was thinking the attributes were bound to Product and Product Type, but it’s definitely Product and Product Supplier.
Attribute was originally conceived of a generic way of specifying custom attributes on all objects not just Product. Similar to Event and Comment. I had envisioned it being tacked onto Location, Shipment, Order, etc if we ever needed it and then again when we added the Party/Organization association. But we haven’t really taken advantage of it as fully as I had hoped.
I’ll add a discovery for the opportunity backlog as I want to think through the data model to make sure we can easily support more of these associations going forward.
cc @knagel I just wanted you to see this feature request. It seems like a good idea to support custom attributes at the product type level. But I haven’t put enough thought into how the precedence rules would work.
Some questions we’ll need to answer:
If attributes are bound to a product type, are those the only attributes that are displayed when creating a product?
If there are no attributes bound to the product type, then we display all product-bound attributes.
Should “required” be defined at the mapping between attribute and the entity? Rather than at the attribute level?
If attributes are bound to a product type, are those the only attributes that are displayed when creating a product?
If there are no attributes bound to the product type, then we display all product-bound attributes.
Both seems logical.
Could be further expanded if Product category would reference (optional) default Product Type, so any newly created product when assigned to this category would inherit its Product Type from Product Category (with the possibility to change the Type if needed). So keeping clean attributes structure would be much easier.
There are two Product Type hmm attributes: collections of Required Fileds and Displayed Fields. Frankliy speaking i was expecting that Displayed Fields was mentioned exactly for this purpose - showing or hiding some product fields (including attributes) depending on the Product type. But boy oh boy how i was wrong Probably it would be possible just to expand this list to include user-created attributes?
Frankliy speaking i was expecting that Displayed Fields was mentioned exactly for this purpose - showing or hiding some product fields (including attributes ) depending on the Product type. But boy oh boy how i was wrong
Honestly that’s what I thought as well. I’m still not 100% sure there’s no way to do this currently.
Probably it would be possible just to expand this list to include user-created attributes?
Yes that’s what I was thinking as well. But there’s enough additional work there to make usable / user-friendly to make it worthwhile to do it right. So I think I’d prefer a separate field to deal with custom attributes. The “supported attributes” field would be populated with “attributes bound to Product” and would override the default behavior i.e. (show all attributes bound to Product).
But please don’t get your hopes up. Hypothetically, we might be able to include this scope of work within an upcoming release, but I don’t see anything on the roadmap where this would fit. Perhaps “Product Hierarchy”, but that would be a stretch.
With that said, if there are improvements like this that you can’t live without, then I could provide a cost estimate and let you decide whether it’s worth it. This feels like maybe 10 hours of work on the development side, but I’d want to do a full discovery before I’m comfortable with that.
So just let me know if this is worth discussing further.
Probably it would be possible just to expand this list to include user-created attributes?