During an audit I got questions from the auditor about the dates in our revision histories. For example I had an engineer update a document on January 10th 2020 and that's the date that he had in the revision history. Then when I approved the document and placed it in the released folder, I added the date that I released it in the footers of each page, but I left the revision date in the history at January 10th 2020. What are your practices in this situation?
Dating controlled documents after changes - Revision History
- Thread starter ISO_Man
- Start date
Elsmar Forum Sponsor
Thanks - the issue is that the revision history indicates the date that the document owner made the change and sometimes it doesn't get to me for release until a few days later, so the document date (in the header or footer) will be the released (effective ) date and it might be later than the revision date in the history.
Your release date is always later than the actual revision date (or the same date). You can not release a document until the revision is complete.
Do you have a written document control procedure? Does your document control procedure say that you do it this way?
The issue is that there are many, many ways a company can design a document control system. For example, you can have departmental, decentralized control, or you can have centralized document control, or you can have a hybrid system. A hybrid system is the most common.
What you have written here describes your system to some degree. You have a revision history (when the actual document was revised) and you have a release (effective) date. No big deal. The auditor asked questions, but apparently didn't give a nonconformance. The more complex your system, the more questions you can expect. As long as you can explain how your system works verbally or with a procedure, I don't see the problem. It is as simple as writing a procedure that describes how your system works.
The system described in the flow chart above is a very simple system in which the only date is the release date which is thee important date - The date it goes into effect. The date the document was actually revised, but not released, isn't important. In part that is because it is typical for a document to be revised in several iterations over more than one day, rather than on one specific day/date.
It is difficult to say which way was is 'best', and every company is different. Different management structure, different size, etc. Take Motorola - Many different facilities and different locations, but ultimately there is corporate, so document control practices typically have to address different requirements. No way to make a simple document control procedure.
Do you have a written document control procedure? Does your document control procedure say that you do it this way?
The issue is that there are many, many ways a company can design a document control system. For example, you can have departmental, decentralized control, or you can have centralized document control, or you can have a hybrid system. A hybrid system is the most common.
What you have written here describes your system to some degree. You have a revision history (when the actual document was revised) and you have a release (effective) date. No big deal. The auditor asked questions, but apparently didn't give a nonconformance. The more complex your system, the more questions you can expect. As long as you can explain how your system works verbally or with a procedure, I don't see the problem. It is as simple as writing a procedure that describes how your system works.
The system described in the flow chart above is a very simple system in which the only date is the release date which is thee important date - The date it goes into effect. The date the document was actually revised, but not released, isn't important. In part that is because it is typical for a document to be revised in several iterations over more than one day, rather than on one specific day/date.
It is difficult to say which way was is 'best', and every company is different. Different management structure, different size, etc. Take Motorola - Many different facilities and different locations, but ultimately there is corporate, so document control practices typically have to address different requirements. No way to make a simple document control procedure.
Why the delay?
The one date being the date of issue or effectivity should not confuse users with more than one date.
Or you could choose no dates on the doc itself provided its issue status is clear:
Draft - comments requested
Issued - for use and improvement
Letters for draft docs and numbers for issued docs (or vice versa).
The one date being the date of issue or effectivity should not confuse users with more than one date.
Or you could choose no dates on the doc itself provided its issue status is clear:
Draft - comments requested
Issued - for use and improvement
Letters for draft docs and numbers for issued docs (or vice versa).
Maybe you should define in an SOP that there is a difference between "released" and "effective". For example, you could say that a document is released on Mar-13, then training takes place, then the document is loaded into your QMS on Mar-20 at which point the document becomes effective. You should be allowed to do what you want... as long as you define it in an SOP somewhere 
.
.
