Non-conformance

Use this field to indicate at which site (location) or sites this incidence of non-conformance occurred. Leave the default site displayed or type in, or select from the Sites table (FACILITY) the required site code. This field is mandatory.

A non-conformance incident applies to a single site if any of the following conditions apply:

• This non-conformance was created directly from an associated transaction. It will display, and therefore apply to, the actual receiving site (purchase receipt, customer return) or production site (production/operation tracking), for example.
• The product for which this incident is being reported is stored at a specific location.
• A specific site is reporting this incident on behalf of the observer, or source.

 Reported by section

You can change the site code while this non-conformance is at status New. If you do change the site code, the QA manager and Planner fields revert to the default user codes.

You cannot change the site code once this non-conformance has started the corrective and preventive cycle, for example, when it has advanced to status In review. If you do need to change it and the corrective and preventive cycle has started, reject this non-conformance then close it (it needs to display status Closed). You can then create a new non-conformance for the correct site.

This field displays the unique identifier for this incidence of non-conformance.

Implementation > Sequence numbers

This field indicates the current stage of this non-conformance incident in the corrective or preventive cycle. It is updated when the QA manager assigned to this non-conformance incident selects the actions available to them to progress this incident.

The following stages are associated with the processing of a non-conformance:

Each non-conformance needs to follow the standard processing cycle.
For a non-conformance that will be processed through to completion the standard cycle is: New > In review > In planning > Being implemented > Completed > Closed
For a non-conformance that will be rejected the standard cycle is: New > In review > Rejected > Closed or New > Rejected > Closed

• You need to be logged in as the current QA manager for a non-conformance to change its status.
• A non-conformance cannot be reset to status New.
• You cannot change any key elements of a non-conformance once the corrective and preventive Action plan is being implemented (actioned). If the product code is incorrect, for example, reject then close the non-conformance, then create a new non-conformance with the element corrected.
• No changes are permitted at all once the non-conformance is closed.

Corrective or preventive cycle status summary

Use this field to select an image to display on this record.

Use this field to identify the probable or possible cause of this incident. This field is mandatory. Your suggested reason should reflect what you subsequently add to the free-format Additional information field (NCSDES) as the information will be used to help establish what the root cause of this incident might be.

The default code and the list of probable causes is defined in Miscellaneous table 804–Probable cause.

Use this field to provide a clear statement describing the problem in detail. Try to quantify your suggested value for the probable cause and maybe list several reasons why you think the selected value is correct. This will help you ensure you have thought about all the possible causes. Your list of reasons will assist the Quality assurance (QA) manager and the approvers when analyzing the problem. If you can, try to explain the potential consequences if the problem is not addressed and provide a clear request for corrective or preventive action. Ultimately, your statement is critical to the Quality control team for analyzing whether the design or production model complies with the set standard and can be considered "fit for purpose".

If this field contains a statement that was added when the incident was created in a source document (such as an operation tracking record) you can enhance or change the statement if you know or understand, or have additional information about the "problem".

Use this field to identify the type of transaction the observed "problem" or "defect", or failure or potential failure in design or production, or service, or process, or system has been reported against. For example, Purchase receipt, Customer return, Production tracking, Operation tracking - resource, Operation tracking - operation. If this non-conformance was created directly from an associated transaction this field will display the linked transaction type.

 If adding a document to the list of Source documents you can only select a document type associated with the supplier or customer identified as the original source or reporter of this incident if the Supplier or Customer field in the Home section contains a supplier/customer code.

 Production tracking documents need to be for a single (the same) work order if the first linked document (that is, the first document line) is a production tracking document and the NCSMULTIWO–Link prod tracking multiple WO parameter (TC chapter, NCS group) is set to No.

Use this field to identify the number of the source document or order.

Use this field to identify the associated line on the source document or order.

This field displays the product code from the selected source document or order line.

This field indicates which version of this product applies. Major versions might be used where there have been increased or significant changes to the original or previous version, that is the "form, fit or function" has changed.

This field is not populated if the product code defined in the Product field is not version managed.

This field indicates which minor version of this product applies. Minor versions might be used where there have been minor features or changes in functionality, or significant fixes applied to a specific major version.

This field is not populated if the product code defined in the Product field is not version managed.

This field displays the actual quantity from the source document or order line that relate to this incident. It will either reflect the original (full) quantity from the source document or order line or a manually entered (partial quantity) figure. For an incident resulting from the manufacturing process, for example, this will be the actual rejected quantity. The quantity is expressed in the stock unit.

 Select the Document line action to change this figure.

This field displays the quantity from the source document or order line. The quantity is expressed in the stock unit.

This field displays the unit in which the product is stored. It provides the key to prices, costs, volumes etc.

This field displays the key date from the Home section of the original document or order. For example, this can be the actual receipt date (purchase receipt), the return date (customer return), or the follow-up date (production/operation tracking).

This field displays the code of the supplier for which the source document or order was created. It is only displayed if the source Document type field (DOCTYP) is a purchasing document.

This field displays the code of the customer for which the source document or order was created. It is only displayed if the source Document type field (DOCTYP) is a sales document.

This field displays the associated project code. The content can be one of the following:

• A project code
• A project code and a project budget code
• A project code and a project task code, that is a material task code, a labor task code (sales only), or a combined (mixed) labor and material task code.

If the content of this field includes a character such as an exclamation mark "!" this field links to the structure of the project. The character is the separator between a project code and the structure, either the project cost structure or the project operational structure. For example, if a material task code is "USA-P3" and a project code is "USA12345678", this field displays a link to the project operational structure as "USA12345678!USA-P3".

To provide a quick and easy visual reference the link to the project or project structure is distinguishable by the number of separator characters used. If there is no separator, the link is made to the project. A single separator character such as an exclamation mark after the project code (the first code) indicates the link type is a task (the link is to the project operational structure). Two separators placed after the project code mean that the link corresponds to a budget code (link to the project budget structure).

This field indicates if this particular line is considered active and relevant to this non-conformance incident. Select the Deactivate document/Activate document action to change its status.

Select Customer return from the Actions icon to view the return details. The transaction you select determines the way in which you enter information, and how information is displayed and printed. If only one transaction has been set up you are not offered a choice, the default entry screen is displayed.

Select Production tracking from the Actions icon to view the production tracking details for the selected work order. This includes parent product (BOM) information, component information and operation details. The transaction you select determines the way in which you enter information, and how information is displayed and printed. If only one transaction has been set up you are not offered a choice, the default entry screen is displayed.

Select Purchase receipt from the Actions icon to view the purchase receipt details. The transaction you select determines the way in which you enter information, and how information is displayed and printed. If only one transaction has been set up you are not offered a choice, the default entry screen is displayed.

Select Deactivate document from the Actions icon to exclude (or cancel) this source document or order line. To reinstate this (cancelled) line, select Activate document.

Select Document line from the Actions icon to enter the actual quantity from this document or order line that relate to this particular non-conformance incident. This figure does not have to match the original quantity (although it cannot exceed the original quantity). You also use this action to deselect (or select) individual product lines associated with a specific lot, sublot or serial number which are not relevant to this non-conformance.

You can select the Select all/Deselect all actions in the Document line screen to select or clear all lines displayed in the table (grid).

Select Operation detail from the Actions icon to view the key details reported in the production tracking record against this work order operation that relate to this particular non-conformance incident. For ease of reference the information is grouped as follows:

• Details about the affected tracking document, the employee that recorded progress against this operation and when they recorded it
• Details about the work center against which their progress was recorded (and which possibly caused the non-conformity (resource or process))
• The Non-conformance quantity and the operation tracking, which is displayed as production quantities and times
• Information about any linked materials and the tool used for the operation. This is particularly important if this non-conformance incident was created against a process

Use this field to identify the single root cause of this incident. This field is mandatory.

The default root cause for an incidence of non-conformance created against a resource (work center) used for a work order operation is displayed if defined in the NCSROORES–Default resource root cause parameter (TC chapter, NCS group); if this incident was created against an operational process for a work order the default root cause is defined in the NCSROOPRO–Default process root cause parameter (TC chapter, NCS group). You can change the default root cause, if required.

 If as a result of the root cause analysis more than one cause is determined you are advised to create additional non-conformances to ensure each root cause is identified. This will ensure each root cause can be corrected or prevented with an Action plan. An example of multiple root causes for a single non-conformance might be that training was inadequate and written instructions were unclear.

The list of factors that can cause a non-conformance that should be eliminated through process improvement are defined in Miscellaneous table 803–Root cause.

Use this field to summarize the reason why this problem arose in the first place. You should use this field to support the identified root cause following root cause analysis. This field is mandatory.

 If your selected reason could potentially lead to further questions being asked about the root cause then you are advised to further analyze the root cause.

The list of reasons for raising a non-conformance is defined in Miscellaneous table 802–Reasons for Non-conformance.

Use this field to indicate the urgency of corrective or preventive action on this non-conformance. This field is mandatory.

The following four severity levels are associated with the urgency of corrective or preventive action on a non-conformance incident:

Critical: The non-conformance needs to be corrected or prevented for the product to be approved as "fit for purpose". Corrections for the reported incident are therefore considered critical for the quality of the product or the success of the design.
For example, if a vehicle's airbag failed to deploy in an accident, elements of the design specification have failed. You would therefore create a non-conformance incident with the severity level "Critical".

Major: Correcting or preventing the non-conformance is considered high-priority and should be considered.

Moderate: Correcting or preventing the non-conformance is regarded as advisable.

Minor (cosmetic): Correcting or preventing the non-conformance is regarded as low-priority, for when time permits.

The list of severity levels is defined in Local menu 2030.

Use this field to provide an assessment of the impact implementing the "change" resulting from correcting or preventing this non-conformance will have on the current form, fit and function. Provide your assessment of the risk associated with this, ensuring you have considered the effect on existing (and validated) processes. This field is mandatory.

The following three risk assessments are associated with a non-conformance incident:

Major: The impact of the "change" resulting from correcting or preventing the non-conformance impacts the form, fit, function, or the technical specification. The "correction" is, however, considered critical.
For example, a non-conformance incident created to redesign the deployment sensors for a vehicle's airbag would be considered "major".

Minor: Any "change" resulting from addressing the non-conformance incident will not impact the form, fit, function, the technical specification or processes.

Unknown: The impact of any "change" to correct and prevent the incident from reoccurring is not known.

 The acceptable deviation from the original specification will vary from organization to organization, product to product, and part to part, and should be considered. For example, an interchangeable part such as a different sensor might require a new part number in some companies but not others.

The list of risk assessments of the impact in correcting or preventing reoccurrence is defined in Local menu 2031.

Use this field to provide a target completion date for delivery of the "corrected" product or system.

This field, if populated, displays the code and name of the last user to change the QA manager field on this non-conformance incident.

This field, if populated, displays the last date this non-conformance incident was reassigned to a different QA manager.

Use this field to identify the Planner (project manager) who will be responsible for planning the set of "global actions" that will form the corrective and preventive Action plan for this incidence of non-conformance. They will be responsible for planning the approach to be taken to eliminate the problem. They will also be responsible for controlling or managing the corrective or preventive actions, using their Action plan, through to a successful correction and approval of a product that is "fit for purpose".

The default planner is the user defined in the NCSPLADEF–Default planner parameter (TC chapter, NCS group). You can assign this non-conformance incident to a different planner, if required. Type in, or select a user code from the list of users approved for involvement in your Non-conformance management process as "planners".

 You can only change the default or the assigned planner if you meet one of the following conditions:

• You are the current QA manager or Planner for this non-conformance incident.
• The new planner's User record has approval for the site specified on this non-conformance incident.
• This non-conformance incident is currently active, that is, it is not at status Closed.

Use this field to identify the subject matter expert who has the authority to categorize, prioritize, approve or reject, and monitor corrections for the reported incidence of non-conformance. This field is mandatory. The default Quality assurance (QA) manager is the user defined in the NCSQADEF–Default QA manager parameter (TC chapter, NCS group).

You can assign this non-conformance incident to a different QA manager, if required. Type in, or select a user code from the list of users approved for involvement in your "non-conformance management" process as "QA managers".

The QA manager you define in this field ultimately has full control over this incident and the progress of it through the corrective and preventive cycle. They have administrative rights to advance or reverse the non-conformance through the stages of the corrective and preventive cycle as they deem necessary.

 You can only change the default or the assigned QA manager if you meet one of the following conditions:

• You are the current QA manager for this non-conformance incident.
• Your User record has administrator rights.
• Your User record has approval for the site specified on this non-conformance incident.

Use this field to provide a statement of the root cause analysis.

Ensure you only use this field to provide fact. It should quantify the value assigned to the field Root cause; you could tailor it to fit the value assigned to the field Severity. For example, if the Severity field is set to Major you should include detail that will guarantee the quality of the product. Your statement should only focus on one cause. It could clarify elements of this incident that might be considered "human error".

Your statement is critical to the success of this incident. It will be used when defining the corrective and preventive actions required to eliminate the root cause or failure.

 If as a result of the root cause analysis more than one cause is determined you are advised to create additional non-conformances to ensure each root cause is identified. This will ensure each root cause can be corrected or prevented with an Action plan.

Use this field to identify the subject matter expert that has the expertise to review and confirm an incidence of non-conformance.

Subject matter experts, or "approvers", are authorized for involvement in your Non-conformance management process. They might be, for example, a member of your organization's Quality control team. They have the authority and skills to confirm a "problem" or "defect", such as a failure or potential failure in a design or production model, or in a service, or in a process, or in the system. They also have the skills to confirm quality processes and standards have been followed in making a product or system fit for purpose and can approve or reject the suggested incident for an assigned area of expertise.

Type in, or select a user code from the list of users approved for involvement in your Non-conformance management process as subject matter experts.

 You need to be logged in as the current QA manager for this non-conformance incident to assign an "approver" to it.

 This non-conformance incident needs to be at status In review.

This field displays the name of the selected Sage X3 user.

Use this field to identify a specific type of business transaction that needs to be assessed for the suggested non-conformity. The assigned approver will assess this transaction type for the suggested non-conformity from both a business and a technical perspective.

The list of transaction types is defined in Miscellaneous table 807–Transaction type.

Use this field to indicate the current status of the decision in the review of the suggested non-conformity for the assigned transaction type.

Leave as Pending while you (as the assigned approver) are reviewing the suggested defect or your post-review decision is undecided. When your review is complete and you have made a firm decision on the suggested non-conformity, select one of the following:

Approved: If your review concludes that the suggested non-conformity is valid for the assigned transaction type and prevention or correction is required (approved).

Rejected: If your review concludes that the suggested non-conformity for the assigned transaction type does not exist and is rejected.

• You need to be logged in as the assigned approver to set an "approval status".
• You can only set an "approval status" while this non-conformance incident is at status In review.
• The QA manager is not permitted to set your post-review decision on your behalf.

Use this field to summarize your decision on your review of the suggested non-conformity for the assigned transaction type (maximum 50 characters). You could use it, for example, to state assumptions or make recommendations to the Planner (project manager) responsible for planning the corrective and preventive actions.

This field is mandatory.

Use this field to summarize the reason the Quality control team is formally rejecting this reported non-conformity. This field is mandatory.

The list of rejection reasons is defined in Miscellaneous table 808–Reason for rejection.

This field, if populated, displays the date this reported non-conformity was formally rejected.

This field, if populated, displays the code and name of the user to formally reject this reported non-conformity.

Use this field to expand upon, or explain the defined reason for rejection. Type in a statement that quantifies the decision to formally reject this reported non-conformity.

This field, if populated, displays the closed status of this reported non-conformity. This will display Completed if this non-conformance is implemented and the product or solution is approved as "fit for purpose" and is complete, and if it is closed. It will display Rejected if this reported non-conformance is rejected and is closed. If this field is blank this non-conformance is still "in progress".

This field, if populated, displays the date this reported non-conformity was officially closed.

This field, if populated, displays the code and name of the user to formally close this reported non-conformity.

Use this free-format narrative field to explain or summarize the "change" that was implemented to correct the problem, or why this incident was rejected and closed.

If further documentary evidence to support its closure has been attached such as photographs and approved inspection reports you could mention it here.

This field identifies a supplier that has observed and reported this incident.

If a Supplier code is defined in the Home section their details are displayed in the first line of this table (grid). You can amend this supplier code if necessary.

If this field is blank you can add details for a supplier that reports this non-conformance incident. Type in, or select from the BP Suppliers table (BPSUPPLIER) the code of a supplier that observes and reports this incident.

This field displays the corporate or company name for the selected supplier.

Use this field to identify the contact within this supplier's organization that can be contacted about this observed, or reported non-conformity.

Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact within this supplier's organization.

 You can only add a contact that is associated with the selected supplier.

This field displays the name for the selected contact associated with the selected supplier.

This field displays the email address for the selected contact associated with the selected supplier.

This field displays the telephone number for the selected contact associated with the selected supplier.

This field identifies a customer that has observed and reported this incident.

If a customer code is defined in the Home section their details are displayed in the first line of this table (grid). You can amend this customer code if necessary.

If this field is blank you can add details for a customer that reports this non-conformance incident. Type in, or select from the BP Customers table (BPCUSTOMER) the code of a customer that observes and reports this incident.

This field displays the corporate or company name for the selected customer.

Use this field to identify the contact within this customer's organization that can be contacted about this observed, or reported non-conformity.

Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact within this customer's organization.

 You can only add a contact that is associated with the selected customer.

This field displays the name for the selected contact associated with the selected customer.

This field displays the email address for the selected contact associated with the selected customer.

This field displays the telephone number for the selected contact associated with the selected customer.

Use this field to identify the internal (from your organization) user that has observed and reported this "problem" or "defect", or failure or potential failure in a design or production model, or service, or process or system.

Type in, or select from the Users table (AUTILIS) the code of a user that observes and reports this incident.

This field displays the name of the selected Sage X3 user.

This field displays the email address defined on the User record.

This field displays the telephone number defined on the User record.

Use this field to identify the contact (external) that has observed, or reported this incident.

Type in, or select from the Contacts (relationship) table (CONTACTCRM) the code of the contact that observes and reports this incident.

This field displays the name for the selected contact.

This field displays the email address for the selected contact.

This field displays the telephone number for the selected contact.

Select the Review action to assign this non-conformance for review.

This stage is regarded as a "Qualification stage". It is not mandatory to set this non-conformance incident to In review as you (as the QA manager) can advance a non-conformance directly to status In planning.

 You need to be the assigned QA manager for this non-conformance incident before you (as the QA manager) can select this action.

 This action is not available if the framework of the Action plan has been outlined and the solution is ready for, or being implemented. This non-conformance will display status Being implemented.

Select the Plan action if the non-conformance incident has been reviewed and (as the QA manager) you are effectively handing over control of it to the assigned Planner (Project manager). The status of this non-conformance will advance to status In planning and the Planner will become responsible for planning approach to be taken to eliminate the problem.

 A Planner needs to be assigned to this non-conformance incident before you (as the QA manager) can select this action.

 A non-conformance can be reverted from status In planning to status In review. If the status is reverted the system automatically deletes the corrective and preventive Action plan.

 This action is directly linked with the status of the Action plan. It is not available if the current status is Being implemented. This means the framework of the Action plan has been outlined and the solution is ready for, or being implemented.

Select the Reject action to formally reject this non-conformance incident. This is mandatory if the Quality control team assess that there is no "problem" or "defect", or failure or potential failure in the design or production model, or the service, or the process and the product is "fit for purpose".

The status of this non-conformance will change to status Rejected. As a minimum, you need to define the reason the Quality control team is formally rejecting this non-conformance incident. You can optionally expand upon the reason for rejection in a free-format narrative field.

 Only the QA manager for this non-conformance incident is authorized to reject it.

 Having all approver post-review decisions at status Rejected is a not a prerequisite to setting the status of this non-conformance to Rejected.

 A non-conformance can be reverted from status Rejected to status In review. If the status is reverted the system automatically deletes all information in the Rejection section.

 This action is not available if the current status is Being implemented. This means the framework of the Action plan has been outlined and the solution is ready for, or being implemented.

Select the Close action when a "change" to a reported non-conformity is implemented and the product or solution is approved as "fit for purpose", and is complete and is closed. Or this reported non-conformance is rejected and is closed. You are presented with a free-format narrative field to complete to support the closure of this incident. The status of this non-conformance will advance to status Completed.

 You can only select this status if a non-conformance is currently at status Completed or Rejected.

 If you do not add a closure statement when you close this incident you cannot add it later.

Select the Action plans action to view or amend (Planners only) the corrective and preventive actions in the Action plan.