We are in the middle of a TCRS implementation, and I am about to be handed the keys to the kingdom for user acceptance testing, and shortly thereafter I will be the primary administrator.
I've been doing a lot of planning on how Teamcenter will be used in our organization, and a dilemma we have surrounds smart numbering. We, like many old organizations have a (not so) smart numbering system that has been abused over the years, and adds less and less value every day. My preference would be to abandon the system and move to an automatic 6 digit numerical ID, but unfortunately that is not an option.
Our typical use of the part numbering system is that a part number is not assigned until the item is known to be destined for production. This is to avoid using up available smart numbers on "throwaway" designs. For prototype parts that need numbered, we will use a temporary prototype number and convert to a prduction number during comercialization.
Additionally, at the finished good level, we have many smart numbering systems for different product lines.
How should this be handled in Teamcenter? Can Item names be easily changed by an end user to a production number? Is it better to assign a non-intelligent ID as the item name and use the production part number as an attribute? Is there another, cleaner, way to do this?
FIrst, I think you are using the wrong terminology for Item Name, but correct me if I've miss understood you.
Item ID / Revision - Item Name = These are the 3 key properties you use in Teamcenter.
123456 / A - Spoke Assembly
Item names can be changed if it isn't locked by a status. Item ID on the other hand is not easily changeable and this is what I think you are referring to as your Part Number. You'd have to do a save as to a new number and decide how you keep a relation between 2 separate parts. Not the best solution but can be done. As you suggested, you can use an unintelligent part number for your Item ID and use the Item Name or another property to hold your "smart" part number. This removes having 2 parts in the system as you'd just update properties as you go through your process. You are trying to find a way to make the system hold your intelligence of the part so that could be in the properties and then it is searchable. You could even use classification but that is an added module with licenses so it adds cost.
If you are thinking of the new ID Generator be aware if you are using any CAD integration because the ID Generator doesn't work in the CAD integrations yet. You have to assign the part number in Teamcenter then consume it from CAD, you can't just assign from CAD. ID Generator also has some limitations so it may not work for all part numbering types.
I don't know how far into planning you are with your data model. You will need to make decisions if things need different Item Types or the same with multiple naming rules or multiple properties instead. Be aware that you can't save as from one Item Type to another. So plan accordingly.
This seems to be a very similar situation we where in not to long ago,
As Jamie mentions about Classification being used, it was our route forward meaning we've opted to keep the item i.d a sequential 6 digit number ( Not smart )
Then Classifing parts prior to release, our Prototype/ Production parts are dealt with using different status's and a series of workflows, So far its all working nicely this way.
Learning the Teamcenter jargon has been one of the most difficult parts of the journey so far. We are pretty early in planning of our data model. I will be starting to make final decisions once the UAT is complete. All of this is hypothetical untill I have access to the system, which will be in the next week.
For us, smart numbering being only available outside the integrations will definitely reduce its usefullness. We will, at least at first, be primarily creating items from the Solid Edge integration. It seems like disconnecting the part number from the item ID may be the way to go; it allows us to be more flexible with how we designate parts.
As a follow up to this idea, is there a way to ensure the part number as a custom property is unique? It would also be beneficial to be able to require a part number to be populated as a pre-requisite to the release status. A little context there; we plan to implement BOM management after initial check in-check out of CAD is in stable use by the engineering department. This will also run in parallel with our new ERP implementation, with the ultimate goal being all BOM's managed in Teamcenter and transmitted to the ERP system via a TBD connector software.
Thanks again for your help. Our implementation partner is pretty good as far as the infrastructure and setup, but we haven't been able to get much real world advice on what is or is not a good idea to do with the system.
The OOTB unique key for any item is Item ID - Revision - Item Name. If you want to add another field to this "key" to control uniqueness then you should investigate Multi Field Key (MFK). This has many ways of creating your custom combination to be unique for each Item. It is primarily used to allow more than one Item in the database with the same Item ID. So that could be done with 2 different Item Types (or domain) or you could add a 4th property to your key.
I've worked with Solid Edge and Teamcenter for about 8 years as a CAD Manager and now I'm a consultant. My advice is don't underestimate the importance of the CAD data and how it will work. Please sit down and put time into understand how you want this to work as it isn't the same as native SE. Plan out all areas of your part numbering to include your reference parts and how that would work in Teamcenter. If you are planning to migrated existing SE data, the sooner you start analyzing and cleaning the data the better as it needs to be perfect to go into Teamcenter. Also remember, once something goes into TC you can't change Item Types or save as to a different Item Type. You really should map out your processes well in advance of UAT in Teamcenter.
Mercury Digital Services
I would go with automatic sequence, and have the "smart" numbering as an item property (not revision). But like said, it would be best if you didn't need this at all, because it adds complexity and creates chances for error.
You can add checks in the workflow to validate that certain properties are populated. You can disallow start of workflow if certain properties are missing, or you can route a task to the creator/admin/somerole to fill in missing properties during the workflow. You could also make certain properties required already during item creation.
I think there might be limitations how you can configure uniqueness for a property, but I might be wrong. Normally you assign naming rule patterns, and Teamcenter takes care of the uniqueness. In your case you'd be only interested in the uniqueness. It is most likely achievable via customization, but possibly not codeless.
You also need to plan how and when the smart numbers are filled in if you intent to use them in the drawings (assuming you're using drawings in production). You should have your drawing metadata, including the smart number loaded from TC. The smart number should be in place prior to saving the drawing, or the drawing won't contain it. So if you only "reserve" the smart number late in the process, it means engineering is needed again to re-save the drawing, so you get all drawing metadata up to date.