How to satisfy with AS9100 Clause 8.4.3 a, Information for external providers?

[ImLost]

Auditor issued a non-conformance stating, the process to communicate to external providers its requirements for the processes, products, and services to be provided including the identification of relevant technical data is not effective.

In this instance; purchase orders sent to the supplier did not have a configuration (Rev) level to be provided, however, drawings used in Receiving Inspection activities contain product configuration level.

As a business, we purchase exactly what the customer requests, and very rarely is a revision required. While we originally stated that the revision requirement would be removed in RI, the Auditor stated this is in relation to purchase orders, not RI.

We're stuck - we don't have to request revisions if there is no requirement (most items are COTS), and purchasing is toying with the idea of a statement "to latest mfg spec revision".
Can this even be done?

 

[Sidney Vianna]

Re: AS9100 Clause 8.4.3 a

In this instance; purchase orders sent to the supplier did not have a configuration (Rev) level to be provided, however, drawings used in Receiving Inspection activities contain product configuration level.

If the hardware being procured is subject of revision level changes, your purchasing documents MUST state the proper revision levels.

In the aerospace sector, sometimes, a hardware revision level results into a new part number. In those cases, a revision level would be redundant. But, and once again, if you can procure parts at different revision levels, that information must be in the PO or alternative documents.

Since prevention via risk based thinking is a given, to rely on receiving inspection to catch any possible discrepancy is not "preventive enough".

Rev. C of AS9100 was more explicit on the requirement:

7.4.2 Purchasing information shall describe the product to be purchased, including, where appropriate the identification and revision status of specifications, drawings, process requirements, inspection/verification instructions and other relevant technical data,

 

[Golfman25]

Well it does say "where appropriate."

In our case (non-aerospace) with our customers revisions levels are a mess. Somehow they constantly fail to inform us of rev level changes. We only find out because we verify the rev level when they order. So it is usually a good idea to know the latest rev level. So the question is why wouldn't you include the rev level? It should be relatively easy -- just keep your system updated.

 

[BoardGuy]

Re: AS9100 Clause 8.4.3 a

If the hardware being procured is subject of revision level changes, your purchasing documents MUST state the proper revision levels.

In the aerospace sector, sometimes, a hardware revision level results into a new part number. In those cases, a revision level would be redundant. But, and once again, if you can procure parts at different revision levels, that information must be in the PO or alternative documents.

Since prevention via risk based thinking is a given, to rely on receiving inspection to catch any possible discrepancy is not "preventive enough".

Rev. C of AS9100 was more explicit on the requirement:

Here is some clarification from the IAQG on 8.4.3:

Question: The standard 9100:2009, clause 7.4.2 requires that purchasing information shall identify purchased product including revision status of technical data. The standard 9100D, clause 8.4.3 does not include this requirement. This information is no more required?

Answer: The clause 8.4.3 requirement...identification of relevant technical data...would include the revision status.

Re. IAQG 9100:2016 Clarifications, Rev. Date: 11/2017

 

[ImLost]

So the question is why wouldn't you include the rev level? It should be relatively easy -- just keep your system updated.

But, not all parts have revisions - at least in our case, only parts which are custom - otherwise, the customer has no requirement (99% of the time) which revision we purchase/receive.
The impracticality of identifying a revision when
a) the customer has no requirement
b) we are never notified of a Revision rolls from a supplier
is large - its just not possible when the revision is not even known.

Putting a revision on every PO... are we just fighting the actuality that this just needs to be done?

 

[Golfman25]

But, not all parts have revisions - at least in our case, only parts which are custom - otherwise, the customer has no requirement (99% of the time) which revision we purchase/receive.
The impracticality of identifying a revision when
a) the customer has no requirement
b) we are never notified of a Revision rolls from a supplier
is large - its just not possible when the revision is not even known.

Putting a revision on every PO... are we just fighting the actuality that this just needs to be done?

I think you are overthinking it. If the revision is none, then it's none. So you identify it as "none, NA, 0, -" or something. As for not being kept up do date on the current revision, join the club. All you can do is according to the latest revision level you have notification of. Do you use some type of ERP or purchasing program where you could keep the revisions recorded? Should be real easy.

 

[BoardGuy]

But, not all parts have revisions - at least in our case, only parts which are custom - otherwise, the customer has no requirement (99% of the time) which revision we purchase/receive.
The impracticality of identifying a revision when
a) the customer has no requirement
b) we are never notified of a Revision rolls from a supplier
is large - its just not possible when the revision is not even known.

Putting a revision on every PO... are we just fighting the actuality that this just needs to be done?

You need to remember that it is the technical data (specifications, drawings etc.) you are communicating to your suppliers not the other way around. If you are ordering catalog items, then you should list within your purchasing procedure a statement something like this one modified from Paragraph 1.3 found on Page 13 of AS9102B:

“Unless contractually required by the customer, a revision indicator for standard catalogue items, Commercial-Off-the-shelf (COTS), or deliverable software does not apply.”

If you are ordering raw materials (metals, plastics, etc.) to an ANSI or ASTM specifications, then your purchase order should state the specification and its revision especially if you are receiving material test reports. If you do not specify, any revision of these materials will meet the PO requirements and contractually you’re stuck with it.

 

[Ralba]

So to summarize to make sure I understood the conclusion to the thread correctly, the revision requirement must be communicated when needed, and the process by which it may be communicated must be part of purchasing in order to ensure it is able to be done for the customers who require revision levels on components?

 

[Kronos147]

...purchase orders sent to the supplier did not have a configuration (Rev) level to be provided, however, drawings used in Receiving Inspection activities contain product configuration level.

Did the PO reference the drawing or configuration level?

Do you feel comfortable citing the exact wording of the objective evidence reviewed (minus any names and exact PO\part numbers, etc.)?

 

[Kirby]

I realize this is an older discussion and I'm hoping my issue is relevant, so... I'm trying to determine if a revision to our Customer Requirements doc is needed to address the communication to suppliers requirements. (This is an Opportunity for Improvement / Preventive Action rather than an audit finding CA.) The current practice has evolved from the original through revisions to the procedure that supports compliance to 8.4.3 and I have began to question if it has been a bit corrupted with respect to the information actually provided to the suppliers. A statement on our P.O.s directs suppliers to our website where our requirements can be reviewed. This document addresses some of the items noted in 8.4.3, but not all of them. I understand that the statement in 8.4.3 is that the organization shall communicate " its "requirements and I've read various opinions as to what that really means. Some say that you needn't include the items that do not typically apply while others feel it's just safer to include everything, with phrases such as "when applicable" or "when appropriate" or "when required" or "when requested", etc. I have a draft of a revision to our document that covers all of the items in 8.4.3 where I've used some of these terms - "Special requirements shall be provided, when applicable." (just an example, it's not written exactly like this). What's the consensus ? Has anyone had similar issues / questions, if so , what was the final resolution? Any input that you have would be appreciated. Thanks in advance.