@Jamie_Griffis I just realized that I would have around 40,000 combinations. It is unreasonable to make all those concatention rules. I only have 3 LOVs and a counter but one of the LOVs has 400 values. I think I'll create a concatenation rule between only the LOV with the 400 values and the counter. And then watch over the next year to see where I might need to create additionaly concatenation rules.
@CraigPoulson - 40000! Don't do it. I don't even know how long it would take to resolve that and bring back the right info to you in the UI. But how much do you do a Save As from one part to the next? Who doesn't save as to a new part number? That is the deal breaker for me on this thing. That is why I push unintellegent part numbers and store those LOV values or intellegence into properties to search on.
Right. And since the use of a smart number is a business requirement, I will drop back and just create a simple naming rule pattern that matches the format of the smart number.
The focus now changes from how to setup Teamcenter to how the company will procedurally minimize the negative impacts of using smart numbers, which is where the discussion should have started anyway.
Just to finish this up (and in no way advocate for smart numbering), we had a customer that wanted a prescriptive method for identifying documents in Teamcenter and it comes close to smart numbering. However, it uses the item display name as the place to put it all together, concatenating the object_name property and the item_id property like this:
The object_name property was defined as a complex property pointing to three other custom properties on their document object:
Finally, those three properties used a cascadingLOV (a LOV with sub-LOVs) to define the allowable values the user could choose when creating the item:
When it was finished, the display name on the item looked like this:
This approach would satisfy the format requirement, but it too has its limitations, especially when it comes to CAD integrations and quick searches. I just wanted to throw this out there for what it's worth since MFK and intelligent numbering don't fit the need...
@ArdenBedell, I hope Siemens will evolve Intelligent Part Numbering in the way you described, intelligent (AKA smart) numbers being derived from persistent properties because research indicates that this is the fundamental requirement. It is a significant difference that will probably require a lot more work by the Teamcenter development team. In my opinion, the additional development effort will make the difference between the wide-spread use of the Intelligent Part Numbering capability and it's languishing in it's current form.