In projects or on the hotline, the question of how to deal with changes in tolerance limits comes up again and again. The real question is: how should the Q-DAS software deal with this? This "best practice" is therefore more of a list of possibilities, depending on the wishes of the end customer and the requirements of his process managers.
Comprehensive advice on this can only be given during the project; it is not possible to discuss this with the first level support (hotline).
Basic requirements: the files are written by a measurement system for upload. It is therefore necessary to "manage" changed specification limits from the upload.
Simply writing down changes to tolerances
Since version ME (around the turn of the millennium), all changes to specification limits have been logged when using databases. Described in the documentation as the "little brother of the change history", measured values can then be loaded only after the last change, or split up according to limit changes. The date of the first reading is the only way to know that a specification limit change was made before that reading.
The upload could send a message if a limit has been changed for existing characteristics:
Record changes to tolerance limits when data change log is enabled
Even if the full data change log is also enabled: In an upload system, you would only notice that the "user" who changed the limits was a customer of an upload, and the upload date would be the change date.
Specification limits as key field in upload
The specification limits could be used as key fields in the upload:
If a limit is then changed for an existing characteristic, the dataset will receive a new additional characteristic at the end of the dataset.
The only difference is that the user does not have to use the 'auto select' option to see the changes and assign the values to the correct limits. The disadvantage is that the new characteristic has to be placed by the system at the end of the dataset, the customer would need a way to sort the characteristics so that the "same" characteristics are next to each other.
Switching back to "old" specification limits would upload new values to an old status. (In most cases this is not the wish).
During the years of support, we cannot recommend this option as it causes too much confusion for users.
Specification limits as "Fields for automatic revision number".
This option defines that when a specification limit is changed in a characteristic, a new record is created in the database with a new entry in K1004 (Part Change Status).
Use drawing number and drawing index as key fields at part level.
You have to ask yourself when a change in specification limits occurs! This does not happen by chance, but after an upstream process, namely the specification change in the drawing, in the test plan.
If this information is also used in the dataflow, it can be used as key fields in the k-fields at part level:
This would also be the first evidence of who "confirmed" the specification limit change.
There are other possibilities. Of course, the upload could simply create a new record in the database with this key field combination. However, an extension would be to not allow this in the standard system and prevent the creation of new test plans:
Together with the email notification that a new inspection plan has been rejected, a responsible person can then review the inspection plan and only then manually save it as a new record in the database to give the upload a target record.