cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Names, Numbers, & File-names (Oh my!)

Newbie

Names, Numbers, & File-names (Oh my!)

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?)

Gerry


16 REPLIES 16

Names, Numbers, & File-names (Oh my!)

Filename and Number need to be unique. I have them set to the same in
the preferences and it makes sense. Why have two fields that have be
unique but different? As for name, let that be the description of the
part or item. Drawing title? Ok, you have 12345.prt but what is it? Look
at the name. These are not unique but that's ok. OIR rules would not do
it. I believe its all in the system preferences.


Names, Numbers, & File-names (Oh my!)

Hi Gerry,

We moved from Intralink 3.4 to Windchill now 3 years ago. We discussed
this issue a lot upfront, and implemented your suggestion (three times
the same value). Users are used to it, now, so nobody is complaining,
but I don't feel to happy with it. One of the (minor) disadvantages is
that users have to enter three times the same value during a rename.
Since you aren't dealing with WTParts, and your ERP-system is
responsible for the unique identification, you could use the ERP-number
as the number in Windchill. The very big disadvantage of this approach
is that you have to have ERP-defined numbers before you can start your
creative process in ProE, for all your CADdocuments. Are your designers
going to like this? Or, you are going to rename your formally released
CADdocuments afterwards, and leaving the other CADdocuments in some grey
area?. Are you ending up in a situation where you have CADdocuments
with ERP-numbering, and other CADdocuments not identified by
ERP-numbers.
Second, filename is what your designers want to see in the model tree.
Can they read the model tree filled up with ERP-numbers? Everyone, also
the newbies? And regarding the first consideration, what will happen
with the readeability of the model tree when designers start renaming
their models, in order to allign them with the ERP-numbering?

What we have done, and I feel very comfortable with it, is that we
implemented the ERP-identification as a parameter in ProE, designated to
an attribute in Windchill. So, technically, in our Intralink 3.4 era,
our formal coupling with ERP is not driven by the CAD id, but with a CAD
attribute. And since you can add an attribute as an extra column in the
model tree, designers have filenames and ERP-numbers in ProE nicely next
to each other.
We continued this approach after the migration to Windchill, although we
implemented the WTPart-concept.

What I would do if I could revert back :
- I would implement autonumbering, and forget about this field in the
day-by-day business.
- Implement the ERP-number as an attribute in your CADdocuments and in
Windchill (so you avoid renaming and/or mixed naming strategies)
- synchronize filename and common name and use a composition of some
dominant words in the description of the object (so the name is a short
description).

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
B-8510 Kortrijk (Marke) - Belgium
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk

RE: Names, Numbers, & File-names (Oh my!)

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.

Names, Numbers, & File-names (Oh my!)

Steven,

Thank you for responding.
We follow the exact same file-naming standard in 3.4, and expect to continue to do so in 9.1

We current do not use the common name in 3.4.
We too will probably start using it in 9.1.
We do not have have PDMLink, so WTParts are not of concern. (Out of sight. Out of mind.
We have Intralink 9.1 only, so we only have to deal with EMPDocuments.

Gerry Champoux
Lead Engineer
Information Technology

Williams International
2280 E. West Maple Road
Walled Lake, MI 48390-3828

' (248) 960-2816

7 (248) 960-2607

* -

þ www.williams-int.com <outbind: 123=" www.williams-int.com=">

Names, Numbers, & File-names (Oh my!)

I was completely confused about this at the beginning of planning migration to PDMLink from Intralink. Attached is what I created to work thru understanding it.

The mapping between what a user enters and what results is:

- Very clear for non-CAD Documents

- Very unclear for Pro/E, because of the use of "Name" and "Common Name" in the create UI

Seems like a lot of people miss out on a lot of value of having the Document Name be something meaningful in words (like Name = Bracket, Module2 for example).

Auto or manual numbering affects this in a relatively big way depending on how much significance is assigned to the Number. We have manual number in place for all documents in all contexts - definitely not efficient because it requires a separate number-assignment system, but seemed like the best choice. A new company may be able to choose auto-number, but pretty tough for an existing company with existing data.

RE: Names, Numbers, & File-names (Oh my!)

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.

RE: Names, Numbers, & File-names (Oh my!)

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.

Names, Numbers, & File-names (Oh my!)

Gerry,

I am a little late to the discussion that you posted back in December.
We too are just starting down the Intralink 9.1 road and I have the same
exact question as you did. I saw the responses that were posted to the
message boards and I believe I understand the difference/limitation of
auto numbering and the various names within ProE/WIntrlaink.



From you description below it sounds like we have a very similar naming
convention. I intend on turning off auto numbering and training the
engineers to use PTC_COMMON_NAME as a description field. My question
is, during a rename task have you found a way to force the Intralink 9.1
number and file name to remain the same? Again, I don't care what the
PTC_COMMON_NAME is but I'd prefer that the name & file name match.
Assuming this can be done, am I missing something here? Is there any
good reason why you wouldn't want this to be the case?




RE: Names, Numbers, & File-names (Oh my!)

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.

Announcements

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!

Sign up for a Working Group