We too must show if and when a traveler is revised. One routing line, all of them, or some header information. We have been audited to AS 9100 as well and our solution was a revision number in one of the custom fields. (only thing is you have to remember to do it) and we use who approved the revision not who made it.
Once a revision is made in routing then it should be identified on the Traveler showing who and when the revision was made. Additionally the most recent chnage should be identified or highlighted so all JB users are aware of the said change.
@Robert Brown - to clarify, this would be a revision level for the routing. The traveler does show the part number rev level, but a job (or specifically a template) may undergo multiple changes without it effecting the overall part number revision. Along with this "routing rev level" we are documenting the routings revision date, revision approval, and reason for revision, in a pseudo-operation in the routing (always op#1). This was our work-around solution.
So are you asking for a revision on the the traveler, which is to day what revision the printed traveler is? Or are you asking for a revision for the routing?
There are a couple of methods you can already use to achieve this.
1) If you have someone in your company that uses Crystal Reports, you can add a footer section and add any reference for the Traveler template there. We do this and highlight the revision # and our ECO number as a lookup for further details.
2) If you want traceability for your BOM and Routings per part you can always consider creating a new template job for the part when changes are made. As with above, it would be possible to add the template job reference to know the source for traceability etc when looking at the paper traveler.
To this point, in the aerospace industry (i.e. AS9100) we are required to not only track revisions of our travelers (routings) we also track when and how (who) approved them. Including maintaining a history of changes. Currently, we are facilitating this in JB by creating a pseudo-operation (1st operation of all travelers) and recording the revision lvl, approvals, and approval/change dates. It would be nice to have this controlled by the header job screen/tab.
We too must show if and when a traveler is revised. One routing line, all of them, or some header information. We have been audited to AS 9100 as well and our solution was a revision number in one of the custom fields. (only thing is you have to remember to do it) and we use who approved the revision not who made it.
Once a revision is made in routing then it should be identified on the Traveler showing who and when the revision was made. Additionally the most recent chnage should be identified or highlighted so all JB users are aware of the said change.
@Robert Brown - to clarify, this would be a revision level for the routing. The traveler does show the part number rev level, but a job (or specifically a template) may undergo multiple changes without it effecting the overall part number revision. Along with this "routing rev level" we are documenting the routings revision date, revision approval, and reason for revision, in a pseudo-operation in the routing (always op#1). This was our work-around solution.
Personally I'd like a revision number for the traveler, as well as highlighting the changes made since the last traveler revision.
So are you asking for a revision on the the traveler, which is to day what revision the printed traveler is? Or are you asking for a revision for the routing?
There are a couple of methods you can already use to achieve this.
1) If you have someone in your company that uses Crystal Reports, you can add a footer section and add any reference for the Traveler template there. We do this and highlight the revision # and our ECO number as a lookup for further details.
2) If you want traceability for your BOM and Routings per part you can always consider creating a new template job for the part when changes are made. As with above, it would be possible to add the template job reference to know the source for traceability etc when looking at the paper traveler.
This is a great idea
To this point, in the aerospace industry (i.e. AS9100) we are required to not only track revisions of our travelers (routings) we also track when and how (who) approved them. Including maintaining a history of changes. Currently, we are facilitating this in JB by creating a pseudo-operation (1st operation of all travelers) and recording the revision lvl, approvals, and approval/change dates. It would be nice to have this controlled by the header job screen/tab.