I'm trying to figure out how to have WC10 to "revise" a WtPart having the user to choose between Major and Minor Revision (normally WC has only a type of Revise)
The aim is to have something like:
- Source element part number: 151000001 versione 2.x, where
01 = Major revisione number
1.x = Minor revision + iteration
if revised Major : 151000002 1.1
if revised Minor : 151000001 2.1
On other environment I'd like to create a new Revise action to manage the "Major", but in WC this implies to modify further than my actual knowledge.
Wondering if better to rely on the std "Revise", having the user to select a specific revision numer (for example 'M') in the New Revision picking list and to customize somehow th Revise method to make it to create a new WtPart following the Major rev rule.
If the latter makes sense, can anyone suggest me where to look for Revise code in WC?
Do I understand correctly that you're currently using part of a part's number as it's version identifier? Are you doing "Save As" for major revisions now?
Are you already "in production" with this system? Have you considered using one-off versions? Or Options and variants?
in fact the aim is to make customer not to use the "Save As" command, that is not available (for example) in the ChangeNotice "Affected objects" page (which has the "Revise" command available only).
After that, the new part number is a completely a new number/part, with no interaction with the previous one, so it's not a revision, but really a "save as".
This behaviour is inherited from a previous numbering environment (SAP) on which the major revision number was maintained as the two rightmost characters and the minor as a separate field and we're trying to make users life simpler.
Moreover, however, I have a plenty of customers (using other PDMs/PLMs) which need to maintain major/minor rev for part number/bill of material configuration pourpoises, so I'm trying to figure out if there a way for them.
Fortunately, the current WC system is on development, so we can still speak about it!
It's hard to give advices without knowing your use case, so I can only share my general thoughts:
First of all, Windchill is not designed to handle versions this way, so I'd strongly suggest to find another approach. Even if it seems to work OK so far, if you later decide to use more of Windchill functionality, it may not align good with such approach. In your case it already doesn't wokr OK - as you correctly noticed, SaveAs makes new part, not a revision and doesn't consider the parts related.
This question is actually out of the scope of forum discussion. Just because it's impossible to give a right advice without knowing all the details. You really need a guy who knows Windchill well to discuss your processes, requirements and targets with him. So he would point you in the right direction. Moreover, you're likely to have more "architecture" questions. You're just designing your system and making wrong decisions will hurt you badly later, so it's very important to make right decisions at this stage.
Just for my curiosity - what do you use minor revisions for? What's it's purpose?
actuallyminor revision is intended as a low-impact change on the P/N, which has to be tracked but does not have to show anywhere outside PLM (for example in the ERP).
As Dylan is also saying correctly, we're facing a "historical" numbering system that has been established 15 years ago on a former PDM (CoCreate WorkManager), has passed (unchnaged!) through SAP PLM and now is "migrating" towards NAVISION (as ERP) and Windchill (PLM).
Customer is doing configuration control (BOM and documents) with this numbering system, keeping track of all products' changes: every major revision is really a NEW product, to be produced and sold separately from the previous revision.
For that "Save As" is a good solution, but has to be "sold" to Customer and it's not so straightforward as a "revise" in the ChangeNotice process.
Thanks for you understanding and "support". I'll go on investigating on that and let you know if anything "interesting" will arise...
People get themselves in a world of problems doing this sort of thing - mixing up the meaning of Revision, Iteration, State, etc. Do yourself and your company a huge favor and stick to the meanings provided.
I understand exactly where you're coming from. Many companies struggle with the same problem. It's sadly not always understood by every-one and a common reply is that 'you shouldn't do that' and 'that's not the right way', etc. The fact of the matter is these are often well established part numbering systems which were setup before there was such a thing as a computer. If you have the luxury of setting up a new part numbering system; yes; avoid too much intelligence into the PN. But that luxury may not be yours.
One possibility we once considered was to replace or remove the revisioning positions of the PN and use the Windchill revision instead for _parts_. The related CAD documents would still use the full PN including the revision, which could be created by merging the _part_ number with the revision. It was also suggested to create a parameter to the part, which would show this latest PN and use that instead.
However, this method was finally not selected, because it was feared to quickly become messy and difficult to automate without customization (..avoid customization...). Eventually, the save-a-copy method was selected, eventhough it is flawed. Alas it seems though Windchill is a great product, it doesn't seem to be able to be setup for these PN mechanisms.
Again, in your support and as a friendly lesson to others; this PN style is very common, like or not. One should be carefull to be too judgmental. These PN systems were used to build wonderous machines before any of us were born.
But, times _do_ change and maybe so should PN system. But, try selling THAT to a customer...
we have customized Windchill 8 so that our Part which is derived from WTPart has two attributes ChangeLevel1 and CangeLevel2. The internal Windchill ChangeLevel isn't shown to the user. Whene ever a user want's to revise a Part he gets a dialog to select whether he wants to do a minor or major change.
A minor change is a change that isn't affecting costs like a simple addition of explanation text on the drawing.
In oder to do this we had to hide the original Version Number within the search results and modify the revise functionality.
If you do this you'll also kepp in mind that the esi interface for transfers into an ERP system relies on a 1:1 relationship between a Windchill Part and a part in SAP. By using a new versioning scheme you break this logic and you will have to rewrite parts of the interface.
glad to see that someone has gone through the issue...
Dou you mean that the Windchill std revision number is not seen by the user anywhere, identity string included?
And, "revise" function has been modified to set both the std rev number and the customized ones?
In your opininion, not really feasible to control the overall numbering system, to have th part number to be changed (for exmaple from XXXXXX01 to XXXXXX02 if major rev and using the std revision field for minor?
Question: Dou you mean that the Windchill std revision number is not seen by the user anywhere, identity string included? And, "revise" function has been modified to set both the std rev number and the customized ones?
The partnumber is related to the part master -- changeing it will change the number for all versions -- this is no solution.