Cancel
Showing results for 
Search instead for 
Did you mean: 

Parts vs Items

Pioneer
Pioneer

I wonder how many of you are struggling with the same challenge, which is item types. It seems that in all Siemens demos all we see is the parent class Item in use. Maybe this was the first type ever available. And for historical reasons I suspect many other companies are also using just Items. How ever to get most out of the system, we should more granually define the type of data. We have been using just Item for years, but are seeing now that this is probably the wrong Item type to use for mechanical parts. Which typically is the majority of PDM contents. And going forward, taking new features into use, we see that we need to start migrating the data.

 

Just to give one example, we are hoping to have make/buy information on the structures to guide integrations and use of the data. There should be no need to for example transfer structures below buy level to ERP systems. The make/buy property however is only introduced at Part, which means you can't use it with Item.

Another challenge we have found is that the migration tool (item_to_part_design) doesn't work, at least with the version we are running (10.1.7). This further confuses, what is really the path forward. Is this tool and the use of parts a thing of the past of future?

 

I would greatly appreciate, if someone could share some insight into the Item types. Trade-offs, plans from Siemens, best practises... Anything really, because I haven't found too much information about these, outside of the technical documentation.

8 REPLIES

Re: Parts vs Items

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom
Best practice is to create your own Item type based on Item. This allows you to add custom properties to your Item type without affecting the default Item which Siemens can freely change in any release of Tc. Also adding the Vendor Management feature (no cost) expands the Item types available to include standard parts.

I disagree that you should not send Buy details to ERP where most Buyers actually perform their day-to-day function. Buyers need to know what is being consumed, how much they need to purchase, and any long lead buys they need to work on. Also, the Make/Buy decision may be different at the plant level for different locations and in-house equipment.

There isn't an easy fix for migrating one Item type to another and most have to create custom ITK to handle the data mapping correctly or risk data loss. Several companies I know have made the mistake of creating too many Item types and then have great difficulty performing a Save-As from one type to another as meta data is lost-in-translation. Another issue is when Users create the wrong Item type and then need the admin to change it. They have a lot of manual effort because of their lack of ITK capability and custom programs to handle the transfer.

Best advice, create only the Item types you actually require and not the Item types you think you need. Minimize wherever possible to avoid having to write too many ITK programs or increase the manual effort to resolve "type" issues. Always inherit from OOTB types and never add properties to OOTB types to reduce the impact of data model changes by Siemens. Install Vendor Management. Migrating to the Part vs Design methodology is admirable but keep in mind the additional cost of Multi-Structure editor for the Accountability Check and extra effort from Users. It does solve problems, like sending a "generalized" Part BOM to ERP instead of sending a CAD BOM and then adding a bunch of stuff on the ERP side. A Part BOM enables the use of Product Configurator for options and variants that include color options and other useful information that may be challenging or impossible with just a CAD BOM. It is a worthy goal.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Parts vs Items

Pioneer
Pioneer

Thanks for the response Randy,

I'm not sure I agree that creating custom Item types is a best practice. Customization in general is against all best practices. Modest additions to OOTB objects is not very risky. I understand that in some industries or segments you might know upfront that you need to invest heavily in customization, and then I'd agree with you to minimize the operational risk by making the changes to inherited custom object types.

I think you misunderstood the "Buy level". I meant the node in the structure which you purchase e.g. the top level of a welded steel structure. ERP does not need the weldings or piece parts, because those are never going to be purchased, stocked or handled in ERP. The same component may sometimes be manufactured instead of bought, even on the same plant. How to deal with that depends if it's a frequent situation, or an exception. If it's an exception it should not dictate the process. This is of course company specific...

Lack of tools to change Item type is definitely a problem. I've seen how this can be done properly (e.g. JIRA). You choose your target type, and the system tells you which information will be "sliced" off, and which can be moved as is. That's the way to do it... Teamcenter, not so easy. The only Siemens tool available does 1 direction, and even at that it's currently broken. So only custom tools exist... This doesn't encourage the use of different Item types unless absolutely necessary.

I agree what you say about trying to keep item types to minimum. It would still be nice to get an official statement from Siemens, which are the "minimum" or "recommended" types to use in given industry or operation model (ETO, CTO..) Now it's kind of "build-your-own" approach. We get a bunch of building blocks without any good explanation what they are for, and a bag of tape and glue to integrate the blocks. Even the Siemens demos often use just plain Item, which is confusing if we're supposed to really use Part.

Part-Design concept has little to do with EBOM-MBOM, Configurator etc. I tried to explain that a bit in another post. You can use those tools/concepts with plain Items.

Re: Parts vs Items

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom
Thanks for giving us your point of view. Sounds like your mind is made up. Siemens does recommend, as a best practice, a custom Item type when adding properties as stated in the BMIDE Guide. Its up to you to determine if new properties are needed per your business requirement for any given object in Teamcenter. They don't tell you how to conduct your business but they certainly enable you to realize your vision of it.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Parts vs Items

Pioneer
Pioneer

@RandyEllsworthI was really interested in hearing people's thoughts about the use of the different OOTB Item types. "Part" to be more specific. If you have a custom type inherited from Part, then to me it's still Part and I'd still want to hear more. So if we can re-start from the original question/topic.. Smiley Embarassed

 

When it comes to customization, I have made up my mind, sorry Smiley Embarassed

By the way, I checked but couldn't find a section in the BMIDE Guide recommending custom item types. If you can find it again, please share it...

 

 

 

 

Re: Parts vs Items

Gears Phenom Gears Phenom
Gears Phenom

I agree with Randy. Never modify the OOTB item types. I've had this bite me before when Siemens change Item drastically. Adding "custom" item types is not customization but configuration. CONFIGURE your system to add your own Item Types under the appropriate Item Type which could be Part, Design, Document or Item. It depends on the functionality you want out of the Item Type. This is covered in the Admin training and how it is suggested by Siemens. 

 

If you are interested it the Part type also look at Design and the CAD-Part alignment or also called Design-Part alignment. I use this method often so that CAD datasets and CAD BOM's are contained in the Design and the eBOM is contained in the Part. It already has a relation to define a primary design of a part.  Using this method allows for extension to mBOM if the Manufacturing model is ever added later. 

 

Regards,

Jamie Griffis

Mercury Digital Services

Re: Parts vs Items

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

@pejokin, The following page numbers are directly from the PDF "Teamcenter 11.4 Business Modeler IDE"...

 

pg. 31/1214

Siemens PLM Software strongly urges you to plan out your business object creation. Perform an object-oriented analysis to determine the optimal business object structure, and the custom properties you want to place on the new business objects.

Other reading...

 

pg. 108/1214 - extending the Tc data model.

pg. 229/1214 - saving extensions and business rules in a template project.

pg. 281/1214 - extending Item.

 

Granted, it is not a "clear" recommendation but rather a strong urge. You can also call GTAC and ask their advice then share your findings with the community. Inheritence is your friend but only if you take advantage of it.


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Parts vs Items

Pioneer
Pioneer

@RandyEllsworth wrote:
adding the Vendor Management feature (no cost) expands the Item types available to include standard parts.


Randy, as far as I understood, Vendor Management provides 2 item types: Commercial Part and Vendor Part. Both inherit from Part, so they are used in the Part BOM. The Commercial Part has an OEM part number and the corresponding Vendor Part has a vendor part number.

Which item type is supposed to contain the CAD model of a standard part? Should I create another Item type, say "A98_StandardPart", under the Design item type? And then "Standard Part" item is a "representation for" a Vendor Part, which is in turn associated with a commercial part?

Re: Parts vs Items

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom
There is some good explanations of Vendor Management in Teamcenter Help:
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help/#uid:xid1256871:index_plm00184:id973276:xi...
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help/#uid:xid1256871:index_plm00184:id973276:xi...
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:xid1256871:index_plm00184:id973276:int...
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help/#uid:xid852453
https://www.bct-technology.com/en/support/tips-tricks/teamcenter-part-design-alignment.html

The Aerospace and Defence template uses Commercial Part for standard parts (and defining preferred parts).
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:id1675417
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help/#uid:id1675540
The A&D template includes Classification (for building libraries) so your mileage may vary.

I usually leverage Commercial Part for Standard Part however there is nothing stopping you for creating a Standard Part item type with your own set of properties. For the use-case you describe, I would create a Standard Part from the Design item type to hold the model and add the Standard Part to Commerical Part using the "Represented By" relation. Or just use the Commerical Part to hold the model directly using the "Specification" relation. Creating your own type allows for better control, for instance adding a librarian, which totally depends on your business processes.

Be purposeful when implementing the Part-Design Alignment methodology as it isn't supported by some downstream applications (yet) like Active Workspace and Technomatix products.

More reading:
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:id1528997
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:id1528997
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:c02a9003
https://docs.plm.automation.siemens.com/tdoc/tc/11.4/help#uid:creating_collaborative_design

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4