Support of major/minor revisions

Pekholm · ‎Sep 11, 2015

A common requirement we are facing is the need of two different revision schemes. A major revision describing a larger change, while a minor change is a cosmetic change (misspelling, move a view on the drawing etc.). When a new revision is created and released, lot of work is generated downstream with distribution to suppliers and manufacturing. With two different revision labels, the customer can decide to only distribute major revisions.

Even if the can classify the change in the CM process, the final result is a new revision.

Have PTC any plans to support major/minor revisions?

BR

Per

HugoHermans · ‎Sep 12, 2015

Hi Per,

I think you are right. We have talked a lot about revisions in our company, and we came to a similar conclusion. Our approach is that the designer always starts with a revision whatsoever, the PLM-revision or the minor-revision. When he/she finishes his/here job, and forwards the drawings and designs to be released into the organisation, the minor revision might be upgraded to a major revision. This major revision is actually an ERP-revision, since in ERP only knows about this revision.

Even if Windchill would provide with a double revision scheme, minor or major, it will not be the designer who is going to decide whether it's a minor or major. At least, that was our conclusion.

Regards, Hugo.

syadala · ‎Sep 14, 2015

We had requirement from a client for a Major Minor revision. The client follows a revision mechanism lie A00, A01 etc. when the Object goes form AXX to B00 is called Major revision. we achieved this with a custom webject. This is way back in 2003 and in Windchill 6.2.6.

DonSenchuk · ‎Sep 15, 2015

As much a I disagree with the entire principle of this, there may be ways to use the system to get what you want (short of PTC implementing it).

The main problem a company may run into when implementing major/minor revisions is discipline. No matter what sort of implementation in used, users can bone it up rather quickly if they use the wrong method (major or minor) when making a change.

1st idea:

Use a new lifecycle state for minor revisions. Say a major revision has a final lifecycle state of Production Released. (Other states would be WIP, Under Review and Obsolete.) Introduce a new lifecycle state that Production Released could be moved to (Production Change? Production Revised?) for minor revisions. The engineering crew would be able to move the .drw and .prt/.asm to this state without increasing the revision, indicating that something minor (typo, dims overlapping, etc.) has been corrected but using the existing Production Released prints would still be ok. Any View/Print users searching would simply get the Production Change drawing at the same old major revision. Both are viable, both are correct, one is just a little more correct.

If Change Management (CN/CA) is used for major revisions, promotion workflows could be used to accomplish the state change for a minor revision.

You could also make a designated model/drawing parameter and tie it to a Windchill attribute. It would require manually changing the parameter during a minor change.

2nd idea:

If you have WTParts implemented, that is the file that actually describes your current major revision. This means the files linked within it -- like the .drw or .prt/.asm -- could have more advanced revision levels due to minor revisions. This would also require noting the major and minor revisions separately on the drawing. Unfortunately, when a user is looking for a print, they'll see the drawing revision in their search results table and get confused.

It's similar to what I've seen on some older drawings with different revision levels listed for the drawing and model. The difference would be the drawing lists the major and minor revisions.

It might also be a good idea to change the revision sequence to something closer to what Sudhakar mentioned above. Each letter revision has a certain number of numeric suffixes. You don't really need a webject to accomplish this; changing and updating the revision sequence is pretty straight forward. Then, when a minor revision occurs it automatically goes to the next number: A02 to A03. When a major revision occurs, the user will be forced to manually enter the next letter revision: B00.

-=-=-=-=-=-

In both cases, user discipline comes into play. Invariably, someone won't understand the proper way to accomplish the goal. You'll end up with what should be major revisions to the design on what is listed as a minor revision. You'll end up with major revisions in your system for a typo. This ties in to what Hugo mentioned; don't let the designer/drafter decide what is major and what is minor.

HugoHermans · ‎Sep 16, 2015

In our thinking, every change causes some actions in the organisation. When a change is backward compatible, it can be done as a revision, else it has to be a new article. This is something for the designer to decide.

For the designer, a revision is a revision. When people of order processing consider the change sufficient important, or they want to be able to determine where the revised parts are used, or think they want to be able to trace in the future where the new parts were used, they say 'hey, let's make it a major!'. Of course, this has impact on the product configurator and on so many things downstream. So they rather reluctant to have too many majors.

Pekholm · ‎Sep 16, 2015

Hi

Thanks for all feedback. I have met many customers explaining same need (most common from former TeamCenter customers). The main reason is related to the amount of work a revision generates in downstream processes. In many cases, the change is of type "misspelling in drawing or moving a drawing view" which has no impact of the purchasing or production. If we export these changes as new revisions, the ERP system will treat them in same way as a major revision and trigger supplier distribution, purchase and production planning. I agree that the decision should be taken in the CM process. I like the idea of having a attribute for "ERP Revision" while the PDM revision is as-is. When exporting the data to ERP, the ERP import can then read the ERP-revision to determine correct import action.

BR

Per

DonSenchuk · ‎Sep 17, 2015

That, to me anyway, seems more of a problem with the downstream process than anything else. That statement tells me the downstream process is simply not agile enough to cope with changes to the drawing that don't impact purchasing or production. But, companies are usually loathe to address this lack of agility in their system. Plus, my statement doesn't really solve the issue.

The big drawback to the attribute idea is the metadata in Windchill. When someone searches for somepart.drw, the search results will show the Windchill version, which will be more advanced than the ERP revision due to any accumulated minor changes. In most areas of Windchill the admin could simply make a custom view to take out the column showing the Windchill Version and replace it with attribute 'ERP Revision'. The search results table, however, has not had this ability implemented. The columns available are severely limited. (Another area where PTC wants us to use the system their way, not the way we want to use it?)

If I were forced into something like this and PTC hadn't yet implemented major/minor revisions, I would go with the Lifecycle State solution. This allows you to have the Windchill Version (revision+iteration) match the ERP Revision, while still having a solution that is easy to implement, easy for engineering to engage (make minor revs), and keeps end users from getting confused.

Sierra · ‎Aug 09, 2017

Hi All,

We are currently trying to overcome this issue and are leaning towards updating the Revision scheme to include a delimiter and then the minor revision (i.e. A, A-1, A-2).

The problem with using a Modification state, is that when the object is moved to that state, you aren't wanting downstream users to see it (as it's under change and un-verified). However, because the revision hasn't changed, that entire Revision is now not viewable for that object; to a factory viewer, all structures will now show the PREVIOUS released version, and documentation for that object will be of the PREVIOUS released version. This is not acceptable.

In my experience, Engineers have no problems with knowing whether they are wanting to do non-Revision change, or a change that will require a Revision change. The system default would be a minor change, e.g. A -> A-1, which would need to be over-ridden by the engineer if they wanted to actually go to B. If this should have been done, but wasn't, it still isn't a problem, as during the Release process you review what is being changed, and if it's something that actually warrants a Major Revision, then the reviewers can just Revise it as desired, and continue with the Release.

A useful customisation here would be an attribute that just shows the Major Revision (i.e. drops everything after the delimiter).

Regards,

Sam

Sierra · ‎Aug 09, 2017

Hi All,

We are currently trying to overcome this issue and are leaning towards updating the Revision scheme to include a delimiter and minor revision (i.e. A, A-1, A-2).

The problem with using a Modification state, is that when the object is moved to that state, you aren't wanting downstream users to see it (as it's under change and un-verified). However, because the revision hasn't changed, that entire revision is now not viewable for that object; to a factory viewer, all structures will now show the PREVIOUS released revision (i.e if you have Released C, but are now doing a minor change on it, factory will instead see B), and documentation for that object will be of the PREVIOUS released revision. This is not acceptable.

In my experience, Engineers have no problems with knowing whether they are wanting to do non-Revision change, or a change that will require a Revision change. The system default would be a minor change, e.g. A -> A-1, which would need to be over-ridden by the engineer if they wanted to actually go to B. If this should have been done, but wasn't, it still isn't a problem, as during the Release process you review what is being changed, and if it's something that actually warrants a Major Revision, then the reviewers can just Revise it as desired and continue with the Release.

A useful customisation here would be an attribute that is the Major Revision, calculated from the Revision by dropping everything after the delimiter.

But this is still a work-around. The best way would be if PTC introduced a Minor Revision attribute that functions just like the normal Revision.

BjoernRueegg · ‎Aug 10, 2017

A CAD Drawing can be revised and modified without touching the WTPart. This behaviour is OOTB if you work with calculated links. So you can revise the drawing and correct the typos or whatever since you cannot touch the CAD Model or CAD Assembly.

Unfortunately this works only for CAD Drawings. If you have model based definitions or also WTDocuments you need to have another solution for a "trivial change". I'm not fan to set the part to a state so the user can change everything. During this time no released part is available (or only an old revision).

I think it would help is to have a function to set the state with a new iteration. So at least the current iteration is still released.

What do you think?

Sierra · ‎Aug 10, 2017

I think it would help is to have a function to set the state with a new iteration. So at least the current iteration is still released.

Considered that, but the way Windchill works is that it treats the state of the latest iteration as the driving state for searches etc. So when they search for a document it will show them the previous revision release, (even though, if they go to the history for the object, they will be able to see the later version that is still released).

Also, many companies work that part and drawing Revision should be the same, so doesn't really work Revising the drawing without the part.

BjoernRueegg · ‎Aug 11, 2017

@Sierra you're absolutly right. There is the next problem. Even if a new revision with a released state exists, the search finds only the previous revision if a role has not access to all lifecycle states. E.g. Manufacture Engineer has only access to state "Released".

It's also confusing, that in the history you will find the newer released revision B. If you look at the details it's says next to number "Go to Latest". If you click, you will land again on the first revision A...

I will open up a case to discuss this once with PTC.

olivierlp · ‎Jan 05, 2022

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.