Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X
Nice. Thanks for the clarification.
Mike
you referred to that page from this post http://communities.ptc.com/message/236220
so I came and have a look.
I do not find it that much out of date. We actually made one very similar too when we moved from Intralink to PDMLink.
However, I am always puzzled as to know why many people keep the file extension in the number ?
I appreciate that there are many different ways but to me the best practice is this
WTPart NUMBER = ERP NUMBER
For the 3D model, I see no reason why the 3D Model should have a different number than WTpart. WTpart and 3D model association is unique and the 3D model represent in 3D the wtpart therefore it seems logical to me that WTpart Number = 3D Model NUMBER
I purposely did not say EPMDocument as EPMDoc can be a drawing and obviously Drawing Number cannot be the same than the 3D model, but also even if it could, what would you do when you have ´more than one 2D drawing for the same 3D model.
So I would improve your slide by removing the extension in for the field Number.
There should be a one to one match between PDMLink and ERP in term of Number and Name/Description.
Why do some company have to have them different, and also create in PDMLink a parameter called ERP Number ?
Chris
agree with the WTpart number and ERP material number
In all my previous companies, we work as you said WTpart Number = 3D Model NUMBER. .I'm agree with you too.. more simple to have the same number. (even if duplicate the link information ) notably when CAD handle lot of informations like physical material definiton or color/texture. (so reallly near to the "real life" physical WTPart it describes),
But there's a new capability in Windchill 10, that we specify commonly with PTC R&D (not yet fully released). And now , a single 3D CADDocument can be linked as owner to several WTparts. and then drive several BOMs ...
That permit us to have a single CAD structure linked to different BOMs . Cause we have lot of products with same geometry, but with different color or material finishing. These products are not managed as "Option & variants". But more as a collection like in footwear and apparel business ...
regards
Gregory
Hello Greg
that is an interesting change. I did not know about that functionality. Damn, I should know by now!! we are going live with 10.1 in June and we are currently working on gap analysis.
I can see some advantages, as you said, but I think the risk here is to clearly define a boundary between linking different wtpart to the same CAD and using Option & Variants.
I do not know your business case and again many decisions are taken in conjunction of legacy data but at first glance, ideally, I would use Option and Variants instead of linking multiple wtpart to the same CAD. But as said, when you have existing data model, it is not always easy to change it to a new one so new functionalities are used correctly.
We will never be able to get away of this situation. How can existing data be quickly converted into new data model when systems are changing.
Hi.
Just a couple of comments:
1. The pptx is slightly inaccurate:
Name in the Creo File > New UI is the same as File Name on the CAD Doc
Common Name in the Creo File > New UI is the same as Name on the CAD Doc
IF you have left Common name blank, then CAD Doc Name is based on the File Name +/- extension (based on the server-side preference Upload Drop Name File Extension)
In your case, auto-numbering is turned off, correct?
Number is therefore not generated and is based on the File Name of the CAD Doc +/- extension (based on the server-side preference Upload Drop Number File Extension)
2. You commented "I am always puzzled as to know why many people keep the file extension in the number ?" The most common reason I know if is when you have multiple Creo files for the same WTPart and you want the Creo files to have the same base number. For example 0001234.prt, 0001234.mfg, 0001234.drw. If you drop extension in CAD Doc number, then you will have uniqueness issues.
Auto-Associate can be configured to not consider extension, even though you keep extension in the number of the CAD Document; therefore, it is also helpful to automatically relate multiple CAD Docs back to the same WTPart, 0001234.
3. I know Gregory is using the capability to drive multiple Parts from one CAD Document; but as both of you have noted, this is NOT of use in a case when you are trying to manage Options and Variants. This future functionality is really to support use cases when you are trying to manage Part structures that are the SAME; but vary just in color, finish and not in the geometry or BOM. If you are interested in more info, James Gehan gave a TC presentation in Jan 2012. Please discuss it with him or Jeff Zemsky.
Thanks
Jennifer
Hello Jennifer
1) Well spotted )
2) I have a different view here because it is creating a redundancy. The relationship between prt, asm mfg, drw, gph etc... are managed automatically by the system therefore trying to duplicate this in the partnumber and avoiding the uniqueness issue by adding the file extension is from my point of view additional work which is not necessary since the system manages the relationship automatically.
In addition, what would you do if you have more than 1 2D drawings for the same model. you will not be able to number your second drw 0001234.drw
Therefore, for us at least, all the EPMDocument have a unique number managed by the system (at the exception of the 3D models where sometime we need to maintain a legacy number)
In you example if the model is 0001234 then the drw will be 0001235 and the mfg file 0001236
and the wtpart will be 0001234
3) You are touching what I call the boundary. Why would a colour or finish not be part of Option & Variants ? I see the use of his new functionalities mainly based on companies own definition of how they want to use it.
Here PTC has introduced new flexibilities but the drawback is more complexity for the end users. (Should I use a new wtpart, or option & variants, and what about this and that, what is best to use etc.... etc.....)
In order to properly answer the question, the company will have to have a depth knowledge of its products (yes some companies, unfortunately are not clear how configurable their product is) and also the technology (which keep changing). But such dilemna is not new. how can some take an informed decision.
I am interested in that TC presentation. How can I contact James or Jeff.
Thank you very much
Dear Chris,
The reason I say that the new behavior provided is not well suited to Options and Variants is because I understand its limitations AND I understand how it can be enhanced.
If you are interested in this capability and making your own conclusion, then please get more information.
Jennifer.
Chris,
Our business is watchmaking and jewelery ... So similar to footwear and apparel interm of BOMs (as said by Jennifer , same BOM "duplicated" in term structures) but with color , finishing or material.
I'm agree that for a strict "definition" (let's says eBOM side), it would be more elegant to work with a Option & variant 150% BOM (and use O&V to configure Material or Color).
But as you say, regarding the historical context (CAD managed in a standalone system, and BOMs managed in ERP - and each variant of a product, managed as a single BOM instance in ERP ) too many system and organisational change ....
In our case, even if the eBOMs for each variant are the SAME. the equivalent mBOMs can be slighly different , due to notably of different manurfacturing process for each material .... And contrary to footwear and apparel ... our products have a "long" lifecycle ... propagate several Change in downstream BOMs (manufactruring and service) is not really easy today with O&V ...
For Jennifer: already in my mind to mix Multi owner with O&V
CAD multiowner to WTpart have a gap today for us. It is that Material definition is managed on the WTpart side. So we have to create our own material object and calculate mass etc ... regarding volume inherit from CAD ...
An over interesting topic ...
Feel free to contact us for exchanging around PLM and may be meet directly.
regards
Gregory
Ce serait avec grand plaisir. Mais je suis en Angleterre et avec un planning plus que chargé pour les 6 mois a venir.
Mais merci pour l'invitation.
Good discussion on this...
When going from Intralink 3.x to PDMLink some years ago, we must have (passionately) discussed the use of auton-umbering vs. manual numbering 25 times, with lots of people. Manual numbering won out - but we all agreed that auto would be better if we were starting a new company.
This decision drives a lot of other things, including for example having .DRW, .PRT, etc. with the same root number. Rename (Renumber) also becomes necessariy and a big pain since people start designs with "bracket, left" etc.
In any case, it is a great convenience to have the NAME field have some descriptive text in almost every situation.