As we get ready to migrate from Intralink 3.4 to 9.1, I need to a define a strategy on EPMDocument names, numbers, & file names.
I would be interested in how others have approached this.
Fortunately for me, this will not be PDMLink, so I will not have to deal with WTParts.
Currently in 3.4, the object names are the same as the file names. We didn't have to think about it.
But in 9.1, the EPMDocument name, number, and Pro/E file-name can be completely different.
The potential for error & confusion could be significant.
It appears that the only thing that absolutely must be unique is the object number. Is that correct?
Names & files names do not need to be unique?
Can I force them to be unique? Is this a good idea?
And we have never used the Pro/E Common Name (PTC_COMMON_NAME) when creating models & drawings.
Should we consider such now?
If I understand correctly, in 9.1 the Pro/E Common Name is automatically mapped to the EPMDocument name.
We do not want to use any auto-numbering, as our part numbers are predefined externally, in an independent ERP system.
The users will be required to enter the already-assigned name/number/file-name when they create them in Pro/E.
Currently, models and drawings use the same base name (ex: 12345.prt & 12345.drw).
We definitely want to continue this method.
I was thinking that we would want the EPMDocument name, number & file-name to be identical (including .xxx extension).
What are the advantages & disadvantages of this (including migration of 3.4 files)?
Can I enforce all three to be the same? (object initialization rules?)
In 3.4 we followed the practice of naming theparts and assembliesbased on our part numbers (including dash number). Drawings just carried the base number (no dash).
When we transitioned to PDMLink, we mapped the file name to the "Name" and "Number" fields (minus the file extension). We have also recently begun having our userscreate a descriptive entry in the "Windchill Common Name" field, which gets mapped to the "Name" field in PDMLink. Whether you choose to use WTParts or not, this is kind of handy since it allows users to perform key word searches for documents when they don't know the number (our Program Management types like this).
It took a while for our users to adjust, but it seems to be working out well now.
We migrated from 3.4 to 9.1 and set NUMBER = NAME = FILENAME.
We are regretting that we did not set NAME = description for the objects.
Everything in Windchill embraces the use of NAME for a descritpion attribute; from the default table columns, to PSE, to thumbnail viewer, default promotion request naming.
NUMBER=FILENAME (preference), NAME=Description seems best.
We are currently investigating having the Drawing title block pull NAME (PTC_WGM_NAME i think), and some way to go set NAME to DESCRIPTION attribute to make this consistent with wtDocs.
Other options are to use preferences to set NAME = a Pro/E attribute, but I have found this only applies to populate NAME, not keep them insync.
When I worked at Psion Teklogix, we added some excellent customizations with the help of <u>www.najanaja.com</u> to Windchill for the issue of Windchill Name which has no history. PTC has yet to change this basic requirement since day one of Windchill. Najanaja customized the callout of Windchill Name to point to a custom IBA (history) called company_name for example. So with any function of Windchill Rename (reidentify object), save as, etc, the new value will both change Windchill Name (default at master level no history) and populate the IBA. Thus, when you browse the information pages of the objects of Windchill, the COMPANY_NAME will appear as the value of Windchill NAME. All the folders view NAME column has been switched with the new IBA company_name with a display value “NAME” so it looks like nothing has changed.Here's what I wrote in response to blogger on the PLM space regarding issues with managing File Namesand a movement to completely ignore them:
File Names is old mentality of managing data in a Windows Explorer folder. Really your management should be separated into 2 different categories: metadata management and file management. Uniqueness architecture in a database should be according to these 3 rules:
1. Physical part objects metadata are uniquely managed according to number and organization
2. CAD object metadata are uniquely managed according to number, type, authoring application and organization.
3. CAD file names are also uniquely managed according to filenames, authoring application and organization.
The physical part objects form the BOMs (RBOM, EBOM, MBOMs, SBOMs, PBOMs). Since physical BOMs may and may not have CAD data/files, CAD objects should not be the primary focus of generating the BOMs. It should control/build the order that it drives but in essence CAD BOMs are functional (i.e. mechanical, electrical, software) specific. Some PLM tools don't have this distinction or separation.
One must always accommodate multiple CAD integration since most OEMs, OCMs, partners and vendors share or duplicate files in but use different CAD tools for the same physical part. Thus, the file names may be identified with the same number and even filename+extension (i.e. ProE and SolidWorks with .prt). The same can be said with ECAD and MCAD to number the meta data the same (faster identification with grouping and searches). The CAD objects can all then be associated to the physical object.
I don't think it is futuristic because I've been implementing this for the past 10 years. I don't hide file names because most CAD users are very file and tool centric. It all depends on the user's view and requirements. I'm using PTC Windchil PDMLink/ProjectLink now with complete data integrity and moving to a database managed metadata managed system but allowing a direct synchronization functional groups to associate their CAD data packages to the physical object. Thus maintaining then intended attribute mapping.
For non-CAD user, we can change the view/display to place FileName as on of the last column or not even show it at all with filters and table configuration. As a past aircraft engineer, I know how important it is to communicate to MFGs, partners and vendors from both a physical object BOM and CAD file perspective. In most cases, the only importance of CAD file is to make sure that it is the exact configuration of files that generated the BOM. Most of the functional groups outside your CAD domain are not really interested in the filenames. But, your peer functional CAD person comply relies on filenames and uses a different view of you PLM interface where filenames are the first column in their search results.
To add, most/all of your authoring tools for documents, drawings, BOM and CAD files do not exist within the PLM Tool. Also most PLM tools are metadata form generators which cannot author some required standard document formats. Hence you have the more expensive authoring tools for CAD, Arbortext/XML, etc. In order to have accountability of your product information, PLM tools must be able to manage and control these files from these complex authoring tools. Most business properly manage their documents with part numbers or drawing/document numbers with revision control. Like I said, there can be more than one file that describes a part. You have to take into account of all authoring tools involved.
See attached. I've been sending this out and it should help you.
Good luck with Windchill. I hope you are not using Windchill like Pro/I. It would be such a waste of a good PLM product just to manage ProE files. You have to open solution to a more enterprise solution than just ProE CAD vaulting. Windchill can bring much more ROI rather it being a pretty expensive Pro/I replacement.
Resurrecting and old thread, but I'm wondering if anyone has found a fix to this without extensive customization. We're in the final stages of migrating from Intralink 3.4 to Windchill PDMLink 10. We will be using the NAME field as the descriptive name for the Pro/E part / assembly - this is fine. The system is set such that Number is driven by the File Name of the Pro/E object. This is fine until the Pro/E file needs to be renamed. The rename function allows you to enter a new "file name", but the value for thefield "Number" does not get updated accordingly (doesn't stay in sync and use the new file name). In the rename function the Number field is not editable, so you can't even manually apply the same text for thenew file name / Number.
Any suggestions? I was tempted initially to avoid this by using AutoNumbering and let "Number" essentially be meaningless, but PDMLink tends to be very Number centric for searches etc.
Thingworx Navigate content has a new home! Click here to access the new Thingworx Navigate forum!
Check out the Windchill Tips Board! We're talking about
Whirlpool's use of digital twin, augmented reality, and data-driven design!
The NAVIGATE WORKING GROUP is here! Come innovate with PTC!
The NAVIGATE WORKING GROUP is here! Come innovate with PTC!Sign up for a Working Group