Non-conformance
The Non-conformance function is the central function for managing incidents of non-conformance. It controls every stage of the "corrective and preventive" process within the context of 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. From the initial creating of a non-conformance incident through to the conclusion or successful resolution of a "problem", it manages business risk at every stage in making your product or process "fit for purpose".
Recommended approach to Sage X3 Non-conformance management
It’s generally regarded as good practice to schedule regular meetings to review quality systems, procedures, and regulations. Whether for changes to trends in sources of product and quality information or data information systems, these should include a formal review of results, risk analysis discussions, and to sign off procedures.
Quality control is a critical aspect of the development of a product and for the ongoing maintenance of a product. You can use this function to create or report incidents of non-conformance, or manage reported incidents of non-conformance created directly from an associated transaction such as a purchase receipt. Your quality procedures might indicate that a design or production model does not comply with specifications or a defect in a purchased component is observed. You use the Non-conformance function to gather the critical information, including "in-flight", cold call information into one central repository. The non-conformance incident forms the details of the non-conformity or problem. It becomes the source of the information to support investigations into the root cause, or failure.
All registered Sage X3 users can create non-conformance incidents.
Having created the initial incident, the Non-conformance function then uses standardized procedures to enable efficient handling of subsequent corrective and preventive procedures:
- Key personnel can be assigned to the incident that can challenge and determine if a problem has been identified. They can record findings from their root cause analysis. These personnel will also be able to provide input for any corrective actions.
- It provides visibility of all proposed corrective and preventive actions.
Personnel authorized for involvement in your "corrective and preventive" process can ensure the technical impact of the corrective and preventive actions are quality tested and approved. With easy access to data and the critical information needed to support the corrective and preventive actions, business risk is managed and minimized. - The corrective and preventive actions can be adapted where necessary to respond to changing business requirements or further root cause analysis. Unauthorized or unintended deviations can be prevented.
- The approach to be taken to deliver the corrective or preventive actions, and therefore to eliminate the cause of the problem can be outlined.
You use the Non-conformance function, therefore, to manage your end to end "corrective and preventive" processes in full. When combined with regular review meetings, it provides a highly effective and efficient control mechanism in making your products or processes "fit for purpose".
A non-conformance incident can only be deleted if the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) is set to Yes and the non-conformance is at New status. Otherwise it needs to remain on file for audit purposes.
Prerequisites
Refer to documentation Implementation
Screen management
The Non-conformance function contains a home section and one section per feature of the corrective and preventive process:
- Home section. The home section provides key tracking information. It contains the Status field which indicates the current stage of this non-conformance incident in the corrective and preventive cycle.
- Identification. This is the main section for this function. You use it to articulate the details of the reported, or observed non-conformity. It’s critical to the root cause analysis.
- Review. Use this section to support root cause analysis. The information you add to this block 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.
- Rejection. This section is used by the QA manager for this non-conformance incident when this incident is formally rejected. Access to the fields is controlled by the Status field in the home section.
- Close. This section provides closure information for this non-conformance incident.
- Reported by. Use this section to provide contact information for reporters or sources of this non-conformity.
Home section
The home section provides key tracking information. The critical field in this section is the Status field. This field indicates the current stage of this incidence of non-conformance in the corrective or preventive cycle.
If this non-conformance was created directly from a particular transaction such as a purchase receipt or customer return, many fields in this section are populated from that transaction document. You can leave the default values or change them.
You can identify a specific supplier or customer as the source of this incident, effectively implying this non-conformance is specific to them. Alternatively, you might decide that this non-conformance could affect multiple suppliers, customers, or internal or external users. Should this be the case you should leave the supplier / customer in this section blank and instead add multiple "reporters" directly into the Reported by section.
An incidence of non-conformance can apply to a specific product, or a system or non-stock item such as documentation, a procedure, or training. If a product is version managed, you can add an additional level of detail by specifying which major and minor version this incident is for.
This section displays the name of the person who created this incidence of non-conformance and when they created it.
The following rules apply if you intend to add a document from an associated transaction to support this incidence of non-conformance:
- If the Product field contains a product code, you can only link a document for that product.
- If the Supplier or Customer field contains a supplier / customer code, they’re the original source or reporter of this incident. You can only link a document associated with the defined supplier or customer. For example, if a particular supplier is specified in the Supplier field, you can only link a document such as a purchase receipt for that supplier.
There can be multiple non-conformance incidents per product code.
Quality assurance (QA) managers
As the QA manager for this incidence of non-conformance you ultimately have full control over this incident and the progress of it through the corrective or preventive cycle. To advance or reverse the status of this non-conformance, you need to be logged in as the current QA manager for this incident.
Site (field SITE) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The sites or locations where this incidence of non-conformance occurred. Leave the default site displayed or select the required site code. A non-conformance incident applies to a single site if any of the following conditions apply:
You can change the site code while this non-conformance is at New status. 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 after this non-conformance starts the corrective and preventive cycle, for example, when it advances to In review status. 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 the Closed status. You can then create a new non-conformance for the correct site. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Non-conformance (field NCSID) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The unique identifier for this incidence of non-conformance.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Status (field NCSSTA) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The current stage of this non-conformance incident in the corrective or preventive cycle. It’s updated when the QA manager assigned to this non-conformance incident selects the actions available to them to progress this incident.
Corrective or preventive cycle status summary
|
Tab Identification
Reporting a non-conformity for a "problem" or "defect", or failure or potential failure in a design or production model, or in a service, or in a process, or in the system is critical for delivering a product that's "fit for purpose". You use this section to articulate the details of the non-conformity.
-
You can attach an image such as a photograph of the problem.
You can provide an image for both a product-related incident and a non-product-related incident or process.You can use the Attachments icon on the Side bar to attach multiple images. If you do not want to display images, you can remove the Image block using the Customize screen functionality provided with your solution. - You can identify the probable or possible cause of the incident.
- The key element of the reported incident is a statement that describes the "problem" or failure in detail. You should try to quantify the suggested value for the probable cause and list several reasons why. This will help you ensure you have thought about all the possible causes.
You can provide this statement in a free-format narrative field.
Your list of reasons will assist the Quality control team in trying to track down the root cause of the incident. If you can explain the potential consequences if the problem or failure is not addressed, and provide a clear request for corrective or preventive action, this will also help. 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".
You can also use this section to link to and view actual documents the observed problem has been reported against.
If this non-conformance was created directly from an associated transaction such as a purchase receipt, its details are displayed in the Source documents block. A QA manager can manually add documents to this block to link the document with any in-progress non-conformance incident that's at In review, In planning, or Being implemented status. Once linked, quantities can be changed, and documents activated and deactivated.
Where a linked document is from a production tracking operation, the default product code is the first released product on a work order. The product code can therefore be changed to any product code associated with the work order while the non-conformance incident is at New status. This might be to a different released product code on the work order or to the routing product code if different to the released product code. The product code in the linked document line is also changed to the new non-conformance product code.
Linking documents, activating or deactivating documents, or amending the quantity from the source document or order line is blocked if the NCSDOCCHG–Linked document change parameter is set to No, the status of a non-conformance is Being implemented and the corrective and preventive action plan is being implemented or actioned.
The following rules apply if adding a document to the Source documents block:
- You can only select a transaction for the defined product if the Product field in the Home section contains a product code.
- You can only select a transaction 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 work order if the first linked document on 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.
Image
Image (field IMG) |
Select an image to display on this record. |
Description
Probable cause (field NCSPROCAU) |
The probable or possible cause of this incident. Your suggested reason should reflect what you subsequently add to the free-format Additional information field (NCSDES). 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 the 804–Probable cause miscellaneous table. |
Additional information (field NCSDES) |
The 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". |
Grid Source documents
Document type (field DOCTYP) |
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 displays 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 work order if the first linked document on 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. |
Document number (field VCRNUM) |
The number of the source document or order. |
Line number (field VCRLIN) |
The associated line on the source document or order. |
Product (field ITMREF) |
The product code from the selected source document or order line. |
Major version (field ECCVALMAJ) |
The major version of the product that applies. Major versions might be used where there have been increased or significant changes to the original or previous version. 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. |
Minor version (field ECCVALMIN) |
The minor version of the product that 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. |
NC quantity (field NCSQTY) |
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. |
Original quantity (field DOCQTY) |
The quantity from the source document or order line. The quantity is expressed in the stock unit. |
Stock unit (field STU) |
The unit in which the product is stored. It provides the key to prices, costs, volumes etc. |
Document date (field DOCDAT) |
The key date from the home section of the original document or order. For example, this can be the actual receipt date for a purchase receipt, the return date for a customer return, or the follow-up date for a production or operation tracking. |
Supplier (field BPSNUM) |
The code of the supplier the source document or order was created for. It’s only displayed if the source Document type field (DOCTYP) is a purchasing document. |
Customer (field BPCNUM) |
The code of the customer the source document or order was created for. It’s only displayed if the source Document type field (DOCTYP) is a sales document. |
Project (field PJT) |
The associated project code. The content can be one of the following:
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's 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 that the link type is a task (the link is to the project operational structure). 2 separators placed after the project code mean that the link corresponds to a budget code (link to the project budget structure). |
Line status (field LINSTA) |
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. |
Customer return | ||||||||||||||||||||||||||||||||||
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. |
||||||||||||||||||||||||||||||||||
Production tracking | ||||||||||||||||||||||||||||||||||
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. |
||||||||||||||||||||||||||||||||||
Purchase receipt | ||||||||||||||||||||||||||||||||||
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. |
||||||||||||||||||||||||||||||||||
Deactivate document/Activate document | ||||||||||||||||||||||||||||||||||
Select Deactivate document from the Actions icon to exclude or cancel this source document or order line. To reinstate this canceled line, select Activate document. |
||||||||||||||||||||||||||||||||||
Document line | ||||||||||||||||||||||||||||||||||
Field descriptions
Block number 1
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 need to match the original quantity. 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 that 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. |
||||||||||||||||||||||||||||||||||
Operation detail | ||||||||||||||||||||||||||||||||||
Field descriptions
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:
|
Tab Review
You use this section to support root cause analysis. It contains 2 blocks:
-
The Cause block is used to identify the single root cause of this incident.
If as a result of the root cause analysis more than one cause is determined, you could consider creating additional non-conformances to address each root cause. Each root cause will then be corrected or prevented with an individual action plan. - Within this block, the likely impact of this defect and the urgency of correcting or preventing it can be defined.
- As any identified "change" needs to be managed through the critical checkpoints to the conclusion or closure of it, you use this block to assign this incident to the default or an appropriate "QA manager". A QA manager is a subject matter expert with the authority to approve or reject any suggested changes. They might be a member of your organization’s Quality control team, such as a development manager or a test lead. Alternatively, they might be a product manager that assesses products for market suitability.
You can reassign this incident to a different QA manager if, and when necessary. - You can also assign the default, or an appropriate "planner" or project manager to be responsible for managing the "change".
A different planner can be assigned to this non-conformance if, and when necessary. - The Approvers block is used to assign personnel to this incident that can challenge and determine if a problem has been identified.
The information added to this section 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 you’re the QA manager for this non-conformance or a subject matter expert that has been assigned to support investigations into the root cause, or failure, you provide your feedback in this section. If you’re a stakeholder or member of your company's Quality control team or steering committee, you can use this section to view post-review decisions or conclusions.
QA managers
As the QA manager for this non-conformance incident, you use the Approvers block to identify subject matter experts that have the expertise to review and confirm this incidence of non-conformance. They might be, for example, a member of your organization's Quality control team.
You can assign "approvers" to analyze the root cause of this incident and "approvers" that have the skills to confirm quality processes and standards have been followed in making a product or system "fit for purpose". Your approvers should have the skills to approve or reject the suggested incident for an assigned area of expertise.
Your organization's Quality control team should consider the point at which the decision to approve or reject this incident is made. Essentially, at which stage in the review process you should manually advance this non-conformance to either In planning or Rejected status.
- You can only assign "approvers" to this non-conformance while it is at In review status.
- As the QA manager for this non-conformance, you’re the only user authorized to assign "approvers" to it.
- "Approvers" need to be authorized non-conformance management subject matter experts.
- You can associate multiple "approvers" with this non-conformance.
- You can associate a single "approver" with multiple transaction types.
- You do not have authorization to set the approvers post-review decisions.
- You’re responsible for manually advancing this non-conformance to selected stages in the corrective and preventive cycle.
- Having a complete set of approver post-review decisions is not a prerequisite to changing the status of this non-conformance.
Approvers
As an "approver" you’ve been assessed as having the expertise to review and confirm an incidence of non-conformance.
You should try to identify the root cause of this incident from the transaction types assigned to you.
Having determined or identified if a problem exists or not, you notify the QA manager for this non-conformance and the stakeholders by setting a post-review decision against each transaction type. One comment field per transaction type is available to you which you could use to quantify your decision. You could use it, for example, to state assumptions or make recommendations to the planner or project manager responsible for planning the corrective and preventive actions. The QA manager cannot set your approval status or add comments on your behalf.
-
You need to meet the following conditions to be able to update your assigned transaction type:
- You need to be logged into Sage X3 with your user name.
- You need to have approval for involvement in your company's Non-conformance management process as an approver. Your NCSAPPROVE–Approver user parameter (TC chapter, NCS group) is set to Yes.
- If site restrictions are in place, visibility of and access to this non-conformance is determined by the value of the Site field.
- You can only set an "approval status" while this non-conformance is at In review status.
- Your post-review decisions are not a prerequisite to the status of this non-conformance being changed.
- The QA manager is not permitted to set your post-review decisions or add comments on your behalf.
Cause
Root cause (field NCSROOCAU) |
The single root cause of this incident. The default root cause for an incidence of non-conformance created against a work center resource 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’re advised to create additional non-conformances to ensure that each root cause is identified. This will ensure that 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 the 803–Root cause miscellaneous table. |
Reason (field NCSREASON) |
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. If your selected reason could potentially lead to further questions being asked about the root cause, then you’re advised to further analyze the root cause. The list of reasons for creating a non-conformance is defined in the 802–Reasons for Non-conformance miscellaneous table. |
Severity (field SEVERITY) |
The urgency of corrective or preventive action on this non-conformance.
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. 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 or cosmetic: Correcting or preventing the non-conformance is regarded as low-priority, for when time permits.
|
Change impact (field IMPACT) |
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’ve considered the effect on existing validated processes.
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. 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 the 2031 local menu. |
Required date (field DATEREQ) |
The target completion date for delivery of the "corrected" product or system. |
Reassigned by (field CHGMANUSR) |
If populated, the code and name of the last user to change the QA manager field on this non-conformance incident. |
Reassigned date (field CHGMANDAT) |
If populated, the last date this non-conformance incident was reassigned to a different QA manager. |
Planner (field NCSPLANNER) |
The planner or project manager that 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’ll be responsible for planning the approach to be taken to eliminate the problem. They’ll 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's "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. 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 1 of the following conditions: |
QA manager (field NCSMANAGER) |
The subject matter expert with the authority to categorize, prioritize, approve, or reject, and monitor corrections for the reported incidence of non-conformance. 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. Select a user code from the list of users approved for involvement in your "non-conformance management" process as "QA managers". The QA manager that 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. |
Cause description
Cause description (field NCSCAUDES) |
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’re advised to create additional non-conformances to ensure that each root cause is identified. This will ensure that each root cause can be corrected or prevented with an action plan. |
Grid Approvers
Approver (field NCSAPPUSR) |
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. 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 In review status. |
Name (field USERNAM) |
The Sage X3 user name. |
Transaction type (field TRANSTYPE) |
The specific type of business transaction that needs to be assessed for the suggested non-conformity. The assigned approver needs to 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 the 807–Transaction type miscellaneous table. |
Approval status (field APPRSTAT) |
The current status of the decision in the review of the suggested non-conformity for the assigned transaction type.
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.
|
Reason (field APPRREASON) |
Your decision on your review of the suggested non-conformity for the assigned transaction type, in summary. You could use it, for example, to state assumptions or make recommendations to the planner or project manager responsible for planning the corrective and preventive actions. |
Tab Rejection
This section is used by the QA manager for this non-conformance incident. If you’re a stakeholder or member of your company's "change board" or steering committee, you can use it to view the formal rejection reason and conclusions.
This non-conformance can only be rejected by the QA manager assigned to it.
QA managers
As the QA manager for this non-conformance, you use this section to formally reject this incident. This is mandatory if the Quality control team conclude there's no problem and the product or solution is "fit for purpose". You might also choose to reject it if it has been created in error or is a duplicate of another non-conformance incident.
This non-conformance needs to be at Rejected status for the fields in this section to be available for entry. As a minimum, you need to define the reason the Quality control team is formally rejecting this non-conformance.
You can expand upon the reason for rejection in a free-format narrative field.
- You can only set a rejection reason if this non-conformance is at Rejected status.
- As the QA manager for this non-conformance you’re the only user authorized to reject it.
- Having all approver post-review decisions at Rejected status is not a prerequisite to the status of this non-conformance being set to Rejected.
Reason for rejection (field REJECTCOD) |
The reason the Quality control team is formally rejecting this reported non-conformity, in summary. The list of rejection reasons is defined in the 808–Reason for rejection miscellaneous table. |
Rejected date (field REJECTDAT) |
If populated, the date this reported non-conformity was formally rejected. |
Rejected by (field REJECTUSR) |
If populated, the code and name of the user to formally reject this reported non-conformity. |
Additional information (field REJDESC) |
Explains the defined reason for rejection. Enter a statement that quantifies the decision to formally reject this reported non-conformity. |
Tab Close
This section is updated when you close this non-conformance incident. It identifies who closed this incident and when it was closed.
There's a free-format narrative field which supports the reason for closure if it was completed when this incident was formally closed using the Close action.
Close description
Closed status (field CLOSEDST) |
The closed status of this reported non-conformity. Completed: If this non-conformance is implemented and the product or solution is approved as "fit for purpose" and is complete, and if it’s closed. Rejected: If this reported non-conformance is rejected and is closed. If blank, this non-conformance is still "in progress". |
Closed date (field CLOSEDATE) |
If populated, the date this reported non-conformity was officially closed. |
Closed by (field CLOSEDUSR) |
If populated, the code and name of the user to formally close this reported non-conformity. |
Close description (field NCSCLODES) |
Explains or summarizes 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. |
Tab Reported by
You use this section to provide contact information for a reporter or source of this incidence of non-conformance. Any internal or external user, customer, or supplier that has identified a "problem" or "defect", or failure or potential failure in a design or production model, or service, or process, or system can report it and be recorded as a reporter of it.
If you specify a customer or supplier in the home section, they’re regarded as the source of this reported non-conformance. Their details will be displayed on the first line of the appropriate table in the respective Supplier / Customer block. Otherwise you’re advised to provide the name and contact details for at least 1 source of the information at some stage in the corrective and preventive cycle. This will ensure that someone with knowledge of the incident is contactable should investigations or quality tests need clarification at any stage of the processing cycle.
The origin or source of an incidence of non-conformance is essential should further explanation be required or questions need answering. It might be difficult to obtain this information without the name and contact details for at least one source.
Examples of a source of an incidence of non-conformance might be:
- A product manager that has identified a potential stress test failure in your company’s line of business
- A customer that has identified a failure in a product when used under specific conditions
- A network engineer that has identified a lack of capacity in a device
- A service manager that has identified the failure of your company’s vendor contracts to meet agreed delivery times
- A Tier 1, 2, or 3 support engineer that has identified a defective part in a network element
- A security manager responding to a newly discovered vulnerability
All registered Sage X3 users can add contact details to any new or "in progress" non-conformance incident.
Grid Suppliers
Supplier (field BPSNUM) |
The supplier that 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. 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. Select the supplier code that observes and reports this incident. |
Supplier name (field BPSNAM) |
The corporate or company name for the selected supplier. |
Contact (field SUPPCONTAC) |
The contact within this supplier's organization that can be contacted about this observed, or reported non-conformity. Select the contact code within this supplier's organization. You can only add a contact that's associated with the selected supplier. |
Contact name (field SUPPCNTNAM) |
The name of the contact associated with the selected supplier. |
Email (field SUPPCNTEMA) |
The email address for the contact associated with the selected supplier. |
Telephone (field SUPPCNTETS) |
The telephone number for the contact associated with the selected supplier. |
Grid Customers
Customer (field BPCNUM) |
The customer that 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. 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. Select the customer code that observes and reports this incident. |
Customer name (field BPCNAM) |
The corporate or company name for the selected customer. |
Contact (field CUSTCONTAC) |
The contact within this customer's organization that can be contacted about this observed, or reported non-conformity. Select the contact code within this customer's organization. You can only add a contact that's associated with the selected customer. |
Contact name (field CUSTCNTNAM) |
The name of the contact associated with the selected customer. |
Email (field CUSTCNTEMA) |
The email address for the contact associated with the selected customer. |
Telephone (field CUSTCNTETS) |
The telephone number for the contact associated with the selected customer. |
Grid Users
User code (field USER) |
The internal 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. Select the user code that observes and reports this incident. |
User name (field USERNAME) |
The Sage X3 user name. |
Email address (field ADDEML) |
The email address defined on the User record. |
Telephone (field TELEP) |
The telephone number defined on the User record. |
Grid Others
Contact (field EXTCONTACT) |
The external contact that has observed, or reported this incident. Select the contact code that observes and reports this incident. |
Contact name (field EXTCNTNAME) |
The name of the contact. |
Email (field EXTCNTEMA) |
The email address for the contact. |
Telephone (field EXTCNTETS) |
The telephone number for the contact. |
Reports
By default, the following reports are associated with this function:
NCSRECENT: List of non-conformances
This can be changed using a different setup.
Specific actions
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 because you as the QA manager can advance a non-conformance directly to In planning status. 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 Being implemented status. |
Select the Plan action if the non-conformance incident has been reviewed and as the QA manager, you’re effectively handing over control of it to the assigned planner or project manager. The status of this non-conformance will advance to 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 In planning status to In review status. 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 that 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's 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 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 Rejected status is not a prerequisite to setting the status of this non-conformance to Rejected. A non-conformance can be reverted from Rejected status to In review status. 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 that 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’re 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 Completed. You can only select this status if a non-conformance is currently at Completed or Rejected status. If you do not add a closure statement when you close this incident you cannot add it later.
|
Menu bar
Select the Action plans action to view or amend (planners only) the corrective and preventive actions in the action plan. |
Limitations
Error messages
In addition to the generic error messages, the following messages can appear during the entry:
Supplier can be blank or enter $1$.or
Customer can be blank or enter $1$.
Entry of a supplier or customer code is optional. There are 2 locations in which you can report a supplier or customer as a reporter or source of a non-conformance: In the home section and in the Reported by section. The Supplier (NCSBPS field) or field in the home section is only available for entry if the Origin field (NCSCATEGOR) is set to Supplier, Internal, or External and the Customer field (NCSBPC) if the Origin field is set to Customer, Internal, or External. If you do not know the supplier / customer code, leave the field blank. In the Reported by section you use the respective Supplier field (BPSNUM)/Customer field (BPCNUM).
The Reason field must contain a valueor
The Severity field must contain a value
or
The impact field must contain a value
Why are you creating this Non-conformance? How significant is this defect likely to be? Select an appropriate value for this field to ensure that the appropriate "quality" team can be assigned to investigate the root cause or failure.
The general parameter NCSQADEF needs to contain a valueor
User $1$ is not a QA Manager – see user parameter NCSQAMAN
or
User $1$ is the default QA Manager – see parameter NCSQADEF
Where $1$ = Sage X3 user code. Each non-conformance record needs to have a nominated quality assurance (QA) manager (QA manager field). A QA manager is an active Sage X3 user who has been authorized to perform that particular role within your non-conformance management process. This means that the Active checkbox on their Sage X3 user record is selected and their "QA manager" approval parameter NCSQAMAN–QA manager (TC chapter, NCS group) is Yes. One "QA manager" user should be nominated as the default QA manager for all new reported incidents of non-conformance. You define the default QA manager by adding their Sage X3 user code to the folder or site level NCSQADEF–Default QA manager parameter (TC chapter, NCS group), but only after their user parameter is set.
Please enter Non-conformance Planneror
User $1$ is not a Planner – see user parameter NCSPLANNER
or
User $1$ is the default Planner – see parameter NCSPLADEF
or
No default QA Manager – see parameter NCSQADEF
Where $1$ = Sage X3 user code. Each non-conformance record needs to have a nominated planner (Planner field). A planner, or project manager, is an active Sage X3 user who has been authorized to perform that particular role within your non-conformance management process. This means that the Active checkbox on their User record is selected and their "planner" approval parameter NCSPLANNER–Planner (TC chapter, NCS group) is Yes. One "planner" user should be nominated as the default planner for all new reported incidents of non-conformance. You define the default planner by adding their user code to the folder or site level NCSPLADEF–Default planner parameter (TC chapter, NCS group), but only after their user parameter is set.
User $1$ is not an Approver for Non-conformanceor
The same transaction type for the same approver cannot be entered several times.
Where $1$ = Sage X3 user code. You can assign Sage X3 users as subject matter experts, or "approvers" to review and confirm an incidence of non-conformance. The Sage X3 user code selected is not valid. This might be because they are not an active Sage X3 user or because they have not been authorized for the particular non-conformance management role you tried to assign them to. Although you can associate multiple "approvers" and multiple transaction types with a single non-conformance, you can only associate a single "approver" with a single transaction type. Parameters
You can only change the status of this non-conformance if you are the assigned QA manager.
Existing plan will be removed. Are you sure you want to continue ?You can revert a non-conformance from In planning status to In review status. If you confirm your action, the system automatically deletes the corrective and preventive action plan. Are you sure you want to do this?
Non-conformance status is not valid.A non-conformance is status driven (New > In review > In planning > Being implemented > Completed > Close). You’ve attempted to change to a status that's not a preceding or the next status in the corrective and preventive cycle. Additionally, the statuses In planning, Being implemented, and Completed are directly linked with the status of the action plan. This can lock or prevent changes to the non-conformance while the action plan is in progress.
$1$ is not a contact for $2$Where $1$ = Contact within selected customer or supplier organization; $2$ = Customer/Supplier. You can only add a contact that's associated with the selected customer or supplier.
The Reason for rejection field must contain a valueWhy are you rejecting this incidence of non-conformance? Select the reason in the Reason for rejection field (REJECTCOD) to ensure the decision made by the Quality team is recorded formally. You’re advised to expand upon the selected reason in the Additional information field (REJDESC).
Duplicate Originator is not allowed.This incidence of non-conformance has already been reported for the defined product code by this source (supplier, customer, internal user, external contact).
No valid document line.This message is displayed if an internal link to the attached document line has failed. Check if the defined line on the attached document still exists. It might have been deleted.
Split receipt line selection not allowed.This message is displayed if the attached transaction line is a purchase receipt line that has been split. The original order quantity has been received in multiple deliveries or it has been distributed to multiple warehouses. You cannot specify a split receipt line. You could link this non-conformance to the transaction header instead of the transaction line.
You can only deactivate this user when all non-conformances to which they have been assigned are closed.A Sage X3 user can only be deactivated from a specific non-conformance role if all non-conformance incidents to which they have been assigned are closed.
Modifying this document may create discrepancies in the Non-conformances.Documents can be linked to incidents of non-conformance from a linked function such as purchase receipts when a non-conformity is observed, or added to a non-conformance incident manually. Once linked, non-conformance quantities can be changed and documents activated and deactivated. Changing the source document, however, does not change the non-conformance information potentially leading to discrepancies between the source document and the non-conformance.
Deleting this document does not delete the Non-conformances.Deleting a document linked to a non-conformance does not delete the non-conformance. A non-conformance incident can only be deleted if the NCSDEL–Delete non-conformance parameter (TC chapter, NCS group) is set to Yes and the non-conformance is at New status.
Non-conformance $1$ does not exist.or
Unknown error occurred while creating a Non-conformance.
or
Unknown error occurred while updating a Non-conformance.
Where $1$ = Non-conformance ID (NCSID field). This message is displayed if an internal link in the system has failed and it is not able to access the non-conformance incident selected. If a second attempt to access the non-conformance incident fails and the error is redisplayed you should contact your system administrator.
This Non-conformance is now closed. Amendment is forbidden.No changes are permitted at all after a non-conformance is closed.
You can only deactivate this user when all Non-conformance to which they have been assigned are closed.A Sage X3 user can only be deactivated from a specific non-conformance role if all non-conformance incidents to which they have been assigned are closed.
Tables used
Refer to documentation Implementation