Windchill Attributes/Global Attributes Question

[GregOlson]

So far in my 4 years as admin I have been creating a 1 to 1 relationship between attributes and global attributes.  I just got a request to store, in one document, 40 serial numbers....can I get away with creating a global attribute called serial number and then keep selecting it as I create the separate attributes in the type manager?  What is best practices?

Greg

[ChrisPLM]

Hi Greg,

many views and no answer. I am afraid I will not tell you to go one way or another but recommend if you have not already done it to set your various options into a test servers and validate them.

This is quite specific to your business I believe and therefore your decision should be based on your own testing with your users.

Best regards

[HugoHermans]

Hi Greg,

Starting from Windchill 10 you have multi valued attributes.  In my case, I have an attribute 'Document Language', with a predefined list.  But a document can be stated in more then one language.  In that case, the user can simple add an additional language.

Hugo.

[GregOlson]

Talked with PTC on this, their answer was that I should create 40 separate Global attributes first...then create the 40 doc specific attributes using the Global attributes that I have created.  A one to one relationship as I have been doing already.

[BenPerry]

This is silly - and really begs the question, "Why do we need to create the attribute in 2 places?"

It seems like duplication of work.  Why aren't the global attributes created on the fly or something?  Or some type of 1-stop-shop.  I have also been creating one-to-one relationships when I need new attributes.  1) Create the global attribute, 2) Create the IBA using the global attribute.  But I wished the process was more streamlined.

[GregOlson]

+1.....lots of admin work for a simple field.  Should have a save as button.  Once all the work is done, then you have to configure the layout and display of all the attributes.  HOURS of work!

[doehr]

Hi there,

My first question, why do they have to be 40 separate fields? Wouldn't a single multi-line String global attribute, perhaps called Serial Number List, work for you? And if you want to find everything in the system that references that particular serial number, either a wildcard search with * on both sides of the serial number in the Search field could find them, or failing that, a Query? Personally I would think that would serve all of your needs but be far easier to implement and maintain.

Daryl

[GregOlson]

The reason there is 40 different serial numbers is we are capturing data from a very special chassis.  There are two engines, one transmission, MANY pumps and motors, axles, and gearboxes.  Each having a unique part number and serial number that needs to be captured for future service info.

Engine 1: SN

Engine 2: SN

Transmission: SN

.... and so on.

[doehr]

That's fine, I'm not doubting that you need 40 entries...but why do you need 40 entries in individual data fields? Couldn't one single text field hold all of them?

[GregOlson]

Daryl:

One attribute field wouldn't be sufficient, how would the display layout look when a user is trying to consume that info?  Unless I am missing what you are trying to say.

Current setup below.

[doehr]

Ah....I see. 40 individual components per build, full serial number tracking, I'm guessing a build record. And you would need the individual data fields to remind users of all the bits of info they need to add, so yes one single text field would make it too easy for people to forget to add something.

Alright, knowing that...yeah, you may be screwed. Making new Global attributes does kind of define the baseline "type" or framework which local attributes on an object are based off of, so my only suggestion would be to try it out. My only suggestion would be to try it out on a test server. Make a single Serial Number single-line String type Global attribute, and then in the document create the 40 serial number sub-types all as Globals with unique internal names, and see if you can select the main Serial Number global attribute as their baseline type, and then see if the data can be used properly without messing with each other. I've never had to test this myself since we've never had to put this many similar attributes on a single object. Let us know how it goes, I'm quite curious to see if this works, or if you do indeed need to make a new primary Global attribute for every local one.

[GregOlson]

The system will only allow a Global Attribute to be use once per object type, something I realized while testing back in November.  So ONE to ONE it is.

We have since rolled what you saw in the earlier post into production and it works great...even to the point of not needing primary content document anymore.  I always try to ask the question "why do we need primary content?"....why can't it be a doc that just resides in Windchill without additional content.  At first departments acted as if I took Christmas away, but now it's the preferred method for new documents.

Just a lot of up front Admin work.

[doehr]

Ah well. At least it's a one-time setup, and once you have it working you never have to worry about it anymore. And yes, with all that data on the form itself a primary content attachment wouldn't really be needed if it is intended to be a build record.

Thanks for letting me know about the system-forced one to one ratio per object too, that may be handy in the future. Hopefully the setup for you goes smoothly.

Daryl

[ChrisPLM]

It looks to me like a BOM and further to product configuration.

in your product structure, each line item is a element and for each element (line) you can have the serial number in each element in the same column Serial Number.

Unless I have entirely misunderstood what you are trying to do. I do not see why you need 40 parameters for the same thing

[DavidCutter]

In looking at your various serial number elements, couldn't you have a single serial number attribute and then against each part type the specific serial number applied. Then your MBOM or build BOM captures the specific serial number against the part, then you could structure a report to gather and present a listing list what you're showing here?

I think this is similar to what Chris C was saying.

[ChrisPLM]

It sounds like it DavidCutter

[doehr]

I take it you guys are unfamiliar with build records?

He's running a production line that has to track the specific serial numbers of each of 40 main components that go inside the sold product. It is 40 part numbers with full serial number tracking on each one of them, for every build. If his assembly line is cranking out, let's say, 5 to 10 of these vehicles per day he can't keep editing that serial number attribute on each BOM item for each build, which is what I think you and Dave are recommending.

This has to be a Document type object with a very basic approval workflow, with all of those serial number fields, that can be cranked out as fast as his line cranks out the vehicles for long-term record keeping. Before I was my company's PDM site administrator I was a manufacturing engineer for a truck engine retrofit line, which is why I'm familiar with these (though ours weren't as big, we only had to track about 12 numbers per build).

[GregOlson]

Daryl is spot on!!

[ChrisPLM]

alright fair enough.

Have you considered your ERP system for that ?

[TomU]

Sound like you need the new guide, "Building the Digital Twin"  (Not available yet...) Then you can just match each vehicle to a unique "instance" in Windchill.  

Re: Upload Failures in DTI Using the Windows Explorer Integration