Best practice for dealing with opposite side parts numbering scheme

[dmayfield]

We are currently implementing PDMLink 10.2 and are having some big discussions on numbering schemes. Our current numbering scheme outside of a PDM system is a 7 digit numeric sequence followed by a -1 OR a -2 (if it is an opposite part). We know that you can add a suffix to the end of a part number, and possibly tie this to an optional attribute that will ask upon creation "is this part opposite" (if set as yes, it will append a -2 instead of a -1). Is there a better way of dealing with this?

Note the base number cannot be different, so it could look something like:

1234567-1

1234567-2

Whats the process of having your numbering scheme look for that attribute?

[bsindelar]

A few questions:

1. I am assuming by "opposite parts" you mean that it is a part that is a mirror image of another part (like a right-hand / left-hand type of thing).  Is this correct?  If not, can you elaborate?
2. Can you explain the original reason why the "samenumber-1 or 2" is being used?  Did this come from a best-practice in your industry?
3. Is there anything "smart" about the 7-digit number?  Or does it essentially just count up as new objects are made?
4. Do you intend to eventually integrate PDMLink to your other software outside of PDMLink (like ERP)?

As far as Windchill is concerned, yes you can add suffixes/prefixes in parts and get more complex with OIR autonumbering, but that may become more of an issue to maintain through additional configuration and through updates/upgrades through Windchill depending on how complex it is.

Options that you have include (but are not limited to):

• Creating objects as normal with regular 7-digit number only, then renumber object manually as necessary.
• If creating many objects at one time, there are server-side utilities to bulk import objects (depending on the object type) to pre-determine name, number, etc before the import.
• An unorthodox approach but still possible: split -1 and -2 parts for creation via soft types or contexts (or both), and have the suffix be fixed accordingly.  This strategy has pros and cons associated with it depending on how and where you create the object.
• Have an entirely systematic workflow kick off on objects where this needs to happen to automatically replace the name after creation (this is definitely custom code and has implications depending on the use cases)
• Depending on your answer to #4 above, you can use another attribute to serve as the "ERP Number" of sorts where users can manually put this in, and then let Windchill's OOTB "number" field only be used to drive object uniqueness.  Views/attribute pages can be updated to make the "ERP Number" more visible.

Feel free to contact me directly at robert.sindelar@eccellent.com if you'd like to discuss in further detail.

[dmayfield]

Thanks, there is a lot of good information here. To answer your questions:

1. Yes that is correct (left hand/right hand) parts.
2. This comes from a best practice in our industry/company. It is tied to a lot of our legacy data so we don't want to change the current scheme. It is important to note that a majority of our parts will have a -1 and a few will have the -2 suffix. So it isn't like a few of our parts have the need for this, all our parts will need some sort of ending suffix (mainly -1)
3. Nothing smart about it, it just counts up sequentially
4. Yes there are plans to integrate PDMlink with our ERP system

I liked all your options, we have actually discussed a few of them as solutions but am not sure if there was a best practice. I think we want to keep the enterprise parts matching up with our part numbers for simplicity reasons, although that is something we did consider. The workflow is an idea however we are in a rush to implement and want to stick as OOTB as possible. Can you clarify more on your 3rd point, we would like the -1/-2 to be created when the object is first created. We thought the best way to do this would be to create an option upon creation that you could "check" to indicate it as a -2 part and then the system would append the -2, although I'm not sure how this could be accomplished...

Thanks!

[doehr]

Hi there,

Honestly...keep it simple. Your preference to the -1/-2 suffice based on part type that you were asking about involves making part "sub types" as separately instantiable objects (so when making a new part you would have the option of the Left or Right type)...the very critical problem to that is the numbering scheme. I'm familiar with what you're talking about (the specific details of how we do it via the numbering are different than you but that isn't important), and if you have two separate object types for the left and right variants...that's two separate pulls on the part Number pool. You need the left and right variants of the part to have the same base 7-digit part number to show everyone that they are mirror images of each other. If you use two different object subtypes to do the left and right variants, if you set them to different number sequence sources you're completely screwed; you'd have to renumber every single Right one you did. Even if set to the same number sequence you don't pull both simultaneously; you would pull the first one (let's say it's the Left one and you get number 1234567-1), and if you were then to instantly create the Right version you would get 1234568-2...it pulled the next number available in the base number sequence and you get a mismatch.

So the easiest, easiest, EASIEST option that you could implement right now with the most minimal amount of initial and future work, given that you said the majority are the "left" i.e. -1 parts (and for the sake of the argument, given what you mentioned I'm going to make the assumption that every single part number you pull has the suffix whether or not they will ever get a mirror version)...use a single part object type, leave its OIR on the existing 7-digit base number and hard code the -1 suffix to it, then for the uncommon times you have to make a mirror version just create the entry and manually renumber it based on which part it has to mirror. So basically option 1 as mentioned by Bob.

Daryl

[bsindelar]

My third bullet point is actually two different options (I am assuming the object you are working here is the WTPart)

1. "The Soft-Type Option" --> You can create a soft type of WTPart for each case and call one "Right-Hand WTPart" (say for -1) and "Left-Hand WTPart" (for -2) or whatever you want to call it.  This way, you can implement one OIR, organization-wide, that will automatically append the -1 prefix for any -1 parts made anywhere in Windchill.  The "regular" WTPart type will not attach a suffix.  Then, for the -2 type you can also institute manual numbering.  The idea here being that once you have the base number from the -1 object, you can make a new -2 part that will be manually numbered, and all you have to do is put in the base number there and the OIR will apply the -2.
2. "The Context Option" --> Instead of using soft types of WTPart (which may have challenges with EPMDocument association), you can deploy a similar concept to the above for OIRs, but instead of making them org-wide you can create 2 distinct products or libraries, one of which any WTPart created (only one "type" of WTPart here) will autonumber with a -1 appended, and the other context will be manually number with appending a -2.  So here you need 2 separate OIRs again, but on the SAME object type, just applied in 2 different products/libraries, instead of org-wide.  It too has its share of pros and cons.

Hope this helps!

[doehr]

Interesting...I personally have never done an OIR with that level of logic for auto-detecting a subtype and shifting the numbering accordingly, if you could submit a sample of the OIR code for that (perhaps using Standard, Lefty and Righty for the three main part subtypes) that would be handy to see.

For option 2 you mentioned...separating highly similar part data into different contexts and having context-specific access rules and OIRs is really a bad idea; as you say it has pros and cons but the cons FAR outweigh the pros.

PROS

-You get the automated numbering you want

CONS

-Having highly similar parts, in this case mirror images, handled in separate contexts with separately controlled context teams, separately controlled engineering change access, promotion request control etc...is a logistical nightmare. The vast majority of the time it's the exact same set of people working on both variants of the part. Keeping everything in one context profoundly simplifies the design, change control and use of both variants profoundly

-Having context-specific part and access definitions instead of org-wide is an utter logistical nightmare to maintain. From an administrator's standpoint you just can't see in one combined view the access that every context defines for every object. That view literally doesn't exist, you have to dig into each context one at a time. If one group goes "Hey, when we create a part it does X" and another group in another context goes "Hey, if we create a part it does Y" you've completely blown any quality certification your company has. ISO 9001, TS 16949...gone. You need consistency. If, however, you restrict all of those definitions to the Org and Site level it is effortless to see the whole picture in one shot and you keep everyone on the same page, which is also the industry standard; consistency. When I first inherited the Site Administrator position for our PDM system I discovered (to my horror) that we did have context-specific definitions. I immediately spent a week obliterating that out of existence and moving everything to the Org and Site level except for an emergency backup access line giving Full Control-All to WTObject to the Site Administrators group.

[bsindelar]

Well said Daryl - note that I did not make any actual recommendation here.  I was only supplying options .

[doehr]

Very true, and I didn't mean to give any offense to what you said if that is what I seemed to do, I only wanted to give counterproposals to ones that I have seen direct issues with.

Thanks,

Daryl