Part and Part Version
Products are made up of Parts. They consist of Parts. Some Parts may compose an Assembly, a Module or a Component. These are clusters or sets of Parts that make up the Product.
Parts are often identified by Part Number. A Part Number should normally be a non-significant number possibly prefixed with a code that identifies the Origin of the Part (where does it come from: "place of birth").
The "Item Locator" is intended to be similar an URL that can be used globally within the Extended Enterprise with all their Partners. The Item Locator consists of an Owner Domain which identifies the "owner" of the Part Number Series at their own company within the Group, the Part Number and the Part Version. The format for each of these three components will have to be decided within the enterprise.
All Parts at all levels of the Product Structure will also have a Part Version. The normal rules should be as follows:
• When a Part at a lower level changes and gets a new Part Version, this is not reflected at the next higher level.
• When a Part at a lower level changes and gets a new Part Number, this is reflected at the next higher level where the Part gets a new Part Version. Changing the Part Versions higher up through the Product Structure is not recommended and it should never be mechanized.
This is normally adequate for all industries except aircraft and possibly car industries where it may be necessary to manage parallel versions of the same Part in manufacturing. This should be recorded for each built Product Instance. When and if this is necessary, it should not be recorded in the Nominal Product/PDM application but as information related to the built Product Instance (see Life Cycles and Views).
The decision of when an engineering change affects FFF and calls for a new Part Number is a decision that should be taken by humans and not be done through mechanized rules in the application.
Parts are often identified by Part Number. A Part Number should normally be a non-significant number possibly prefixed with a code that identifies the Origin of the Part (where does it come from: "place of birth").
The "Item Locator" is intended to be similar an URL that can be used globally within the Extended Enterprise with all their Partners. The Item Locator consists of an Owner Domain which identifies the "owner" of the Part Number Series at their own company within the Group, the Part Number and the Part Version. The format for each of these three components will have to be decided within the enterprise.
All Parts at all levels of the Product Structure will also have a Part Version. The normal rules should be as follows:
• When a Part at a lower level changes and gets a new Part Version, this is not reflected at the next higher level.
• When a Part at a lower level changes and gets a new Part Number, this is reflected at the next higher level where the Part gets a new Part Version. Changing the Part Versions higher up through the Product Structure is not recommended and it should never be mechanized.
This is normally adequate for all industries except aircraft and possibly car industries where it may be necessary to manage parallel versions of the same Part in manufacturing. This should be recorded for each built Product Instance. When and if this is necessary, it should not be recorded in the Nominal Product/PDM application but as information related to the built Product Instance (see Life Cycles and Views).
The decision of when an engineering change affects FFF and calls for a new Part Number is a decision that should be taken by humans and not be done through mechanized rules in the application.
0 Comments:
Post a Comment
<< Home