Maximo Open Forum

I am using Maximo 7.6.0.8.

I made a Classification, checked the box so that it generates the Description, made it so that it works with both Items and Assets, configured 7 Attributes to be used with both Items and Assets, and then 3 more Attributes to be used only with Assets.  So, 10 Attributes in total, but the last 3 should not appear on the Item record's Specs.

I made a Rotating Item record and put it in the Classification I made and filled in the seven Attribute (Specification) values.  All good there.

I made a Rotating Asset record that references that Rotating Item. It applied everything that the Item record has.  However, the Asset record is not showing the 3 additional Attributes. 

Is this expected behavior?  Is there something I can do -- other than manually adding the other 3 Attributes to every Asset in this particular Classification, which is going to be unsustainable -- to make those other 3 Attributes appear on the Asset Specs?  I fear the only way to make it happen is to disconnect it from the Rotating Item record and directly apply the Classification to the Asset record.

I can't speak to whether this is "working as designed" but I can tell you that similar behavior happens in the 9.1.11 (February 2026) build so it's not a version issue. The classstructureid attribute on asset calls the generateSpecSet function in the AssetCatalogService (Maximo 7.6.1.2 API - AssetCatalogService). This method takes two parameters (the asset MBO & itemnum) and calls the overloaded method generateSpecSet with a null value for baseMbo. 

The logic in the function stops processing after the item specs are added when the baseMbo is null. When the baseMbo is not null, it looks for missing specifications for the baseMbo object and adds them. What's weird is I can't find/think of a scenario where baseMbo is not null. Most objects like WORKORDER, SR, and JOBPLAN don't use this method at all for their specifications. POLINE, PRLINE, MRLINE, and LOCATIONS uses the same method as asset (without a baseMbo). 

Since it's been this way for years, I doubt IBM would accept it as a defect. But it makes sense to ask for it as an idea (IBM Sustainability Software - Ideas Portal). There are things that you would be interested in at an individual level (bad example since it exists on asset, but something like serialnum for example) that wouldn't make sense on the item record. Your use case of sharing a classification and specs from the item while adding asset specific make sense. 

Thanks for confirming that, Steven.  It is helpful to know that that is how it is still behaving.  I just submitted it as an idea -- Rotating Assets need to | IBM Sustainability Software - Ideas Portal

The specific use-case here was for boilers.  The Item needed Attributes like Type, Fuel, Pressure Rating, but our HVAC team wanted a place to record Asset-specific information such as the National Board number, State/Jurisdiction ID, and the year the boiler was built.

As a workaround for now, I went back to the Classification and configured those 3 Attributes to also be used on Items but not be included in the Description (but they are included in the Description on the Asset).  I included a default value on the Item side for each of those 3 Attributes -- basically "read this - delete this - leave this field blank on Item records."  If the user does not follow instructions, then when the Item is applied to an Asset record, the Asset Description gets these silly instructions three times.  Hopefully that's enough of a clue to go back and fix the Item record.

There's probably a more elegant scripting solution I could do that would nullify and/or make those 3 Attributes read-only on Item records placed in that Classification.  I have more important things to tackle right now. . .