Skip to main content
S
SG_141184934-Participant
4-Participant
September 12, 2025
Question

How to interpret and structure "major.minor"

  • September 12, 2025
  • 1 reply
  • 467 views

Hi Gents. 
I have seen this same issue as this topic: Using Major/Minor revisions - PTC Community, - how to interpret and structure "major.minor", as R&D Lead in several organisations. (Defence, Oil & Gas, Consumer Electronics), and have found this thread while trying to understand what windchill implements as standard.

My take is this: Lets choose to interpret minor change as No NEGATIVE Impact on "FFF" **at the level of the item in question** AND NO change required to any production documentation, test procedures or impact on requirements.
Major change is the converse of this.

Rationale. In engineering assemblies, as long as the change we make on our part/assembly still meets the requirement on it with **at least** the same margins, AND impacts nothing else (as above) then it is **fully compatible**. It is a minor revision. The fact it may have improved something, is for the product manager to take advantage of at a higher BOM level when that becomes relevant for sales.

This makes it easy for the individual engineer to make a Yes/No judgement on whether it is a Minor change, based on the immediate usage of that part, in its place in the assembly.

Where the primary BOM management is in PLM, the ERP does not need to have all the change traceability. So now, PLM can handle major/minor notation with its standard fields.
For production, what you can do is concatenate the Part number and major revision into the ERP Part Number.. its a new part number !!
You put the minor revision in the ERP Revision field. (ERP's usually have only one rev. field)
With this method, you satisfy ERP and production use of Part Identification.. they get a new Part Number when there is an incompatible change, and a minor revision when a change on a part is fully compatible with current assembly instructions, and test procedures.

But what we have done, is preserved the full revision reference between design and production (ERP) domains.

I have seen this done between ARAS innovator and SAP, and I am now writing it up for my organisation to use with Windchill.

A variant on this, as someone has suggested here, is to use a separate "impact" revision number. I also think this is worth considering.
Advantages over traditional major-minor
1.   A change results in a single revision step, regardless.

2.  The designer is asked by PLM to specify only whether they **believe** at the time of design that this will be fully compatible, and PLM increments the separate Impact field from say 2, to 3 for that revision.

3.  The act of making the change is logged, and may even need to be released for production in order to test samples, but now if the impact is seen in test to be compatible or not, against what the engineer originally thought, then the impact number can be re-assessed and changed.

4. The Mapping would remain the same. Part Number Concatenated with Impact Number to ERP Part Number, and the PLM revision field to ERP revision field. The result is the same. New Part Number for non compatible items which therefore need a separate production BIN. 

Cheers,

Stephen

 

1 reply

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
September 12, 2025

I think you are adding extra business logic that shifts problem somewhere else. It might end up making things more complex. Take for example the question of next revision. The simple act of revise where Windchill looks at the series and chooses the next available letter or number in the sequence becomes custom logic and a user decision point. Do I increment the minor portion or the major portion, resetting the minor in response? All places in the system would need to be updated to implement this.

 

Next there is configuration specifications. Following normal rules, if these are all treated like revisions, when I ask for latest of a part structure, the latest major.minor revision applies and appears. But by the definition of a major change, it is not respecting interchangability when FFF mattered. Take the the simple example of an assembly and a component that undergoes a major change and the assembly response at its level with a minor change (change impact should dissepate as you move up a structure). If I looked in the history at the prior revision of that assembly with latest config spec, it will show the latest of that component, the latest major revision which by definition is FFF incompatible. You would need to address these in your solution which will eventually lead you to having to be revision specific at every instance of adding a component. 

 

Finally, there is your transfer to ERP system. You now have custom logic added outside both system (via transfer concatentation) that part 12345 A.1 equals part 12345A rev 1 in the ERP systems. Every single extract, comparison, translation or reference between the two system needs to enforce this new rule along with the users when looking things up. I have seen this early in my time at my current company with one program and it was a nightmare, quickly abandoned. 

 

The alternative is how things are now, simpler. Part number in one system equals part number in another. By enforcing FFF rules and number changes on PLM side, both sides agree internally and at rest. When we look up BOM structure, we can clearly see those major changes as part number changes, where they applied in history and it ensures that we cannot generate incompatible structures.  When a user needs to revise, rules are simple, next letter please. 

 

An alternative I have seen to support major/minor revisions seems to address  the magnitude of change impact. FFF rules still apply but you can accomodate changes like simple typos and inconsequential administrative cleanup, truely no impact. If you business process allows for this, you can simply iterate without revising. You need to clearly document the cases for this and which set of limited people can do this. You can also let revisions occur always but make the turn around process very quick. Minimal change documention, simplifed workflows and few sign-offs (fast fast track). Often when I see proposals for complex revision sequences, its the trap of "...then you'll know..." and the real issue issue is, "that process is too hard to follow, let's make an easier side path". 

    S
    SG_141184934-ParticipantAuthor
    4-Participant
    September 13, 2025

    Hi. 
    Thanks for your reply.

    The very last paragraph you wrote is the correct solution for sure .. major minor revisions, and the fields used exactly the same in PLM and ERP .. SAP in our case.

    but it's also where the problems I am trying so solve originate.

    SAP has as default one revision field only, and it's only 2 characters long.

    We need to differentiate between major and minor, the lack of it is causing all sorts of work arounds in every corner, .. routing on the shop floor, coloured labels to indicate part batches which are compatible and which are not.

    In Electronic CAD it's a major change to change the part number for every major step,, and the tools don't support it. So it's not LEAN for them.

    Even with windchill, I have asked what standard major minor schemes they have, and am told this is always a custom implementation.

    So you can see maybe that while my suggestions are a compromise from the ideal, I and trying to get something done when Our ERP management have forbidden more than single revision field of 2 characters, and won't budge.

    we want an interface to automate data transfer to SAP .. so resolving this is essential.

     

     

    avillanueva
    23-Emerald I
    avillanueva23-Emerald I
    23-Emerald I
    September 15, 2025

    Ahh, I too use SAP and know of the restriction you are dealing with. Yes, that is an immovable stone getting SAP to change. But let's step back and understand why it is only two characters.  This allows for 100 numeric or 676 alpha revisions. That is more than enough to support true revision changes.  So they are backing in some best practices.  Introducing even the period separator makes it fall apart. 

    I strongly would recommend the following. Ditch the major.minor. Let a revision be a revision and do nto care if its big or little. Do not confuse major with FFF changes where part number must change.  But, if you handle the impact of any revision change at the change object level (some documentation impact or no impact), things will flow better. Yes, you folks will have to read those and not assume revisions have no impact but overall system will be easy. 

     

    Keeping a complex major.minor will force you too a file based series I think and a manual controlled revision process (would need to have a workflow step for a key user to make these calls). Mapping to SAP would see you split the revision and put the minor in the rev field of SAP and tack the major to the part number but essentially what you are doing is changing the part number. This should only be done with FFF changes.  And we find ourselves back at the top again.  

     

    Curious when you say that electronic CAD does not support changing part number? Are these circuit design tools? 

      Terms & ConditionsCookie settingsAccessibility statement